cong nghe phan mem – bai giang

Công nghệ Phần mềm là một lĩnh vực nghiên cứu của tin học nhằm đề xuất các nguyên lý, phương pháp, công cụ, cách tiếp cận phục vụ cho việc thiết kế, hiện thực các sản phẩm phần mềm [r]

ĐẠI HỌC CÔNG NGHỆ TP.HCM

CÔNG NGHỆ PHẦN MỀM

Biên soạn: Khoa Công nghệ Thông tin

Bộ môn Công nghệ Phần mềm

CÔNG NGHỆ PHẦN MỀM

MỤC LỤC

MỤCLỤC I HƯỚNGDẪN V

BÀI 1: GIỚI THIỆU

1.1CÁCKHÁINIỆMCƠBẢN

1.1.1 Phần mềm

1.1.2 Chất lượng phần mềm

1.1.3 Cơng nghệ Phần mềm

1.2QUYTRÌNHCƠNGNGHỆPHẦNMỀM 10

1.2.1 Bước Xác định 10

1.2.2 Bước Phát triển 11

1.2.3 Bước Bảo trì (Vận hành) 12

1.3MỘTSỐMƠHÌNHTRIỂNKHAI 12

1.3.1 Mơ hình Thác nước 12

1.3.2 Mơ hình Bản mẫu Phần mềm 15

1.3.3 Mơ hình Xoắn ốc 16

1.4CÁCPHƯƠNGPHÁPXÂYDỰNGPHẦNMỀM 16

1.4.1 Khái niệm 16

1.4.2 Phân loại 17

1.4.3 Các phương pháp xây dựng phần mềm 17

1.5CÔNGCỤ&MÔITRƯỜNGPHÁTTRIỂNPHẦNMỀM 21

1.5.1 Mở đầu 21

1.5.2 Phần mềm hỗ trợ thực giai đoạn 22

1.5.3 Phần mềm hỗ trợ tổ chức, quản lý việc triển khai 22

1.6YÊUCẦUĐỐIVỚIKỸSƯPHẦNMỀM 23

TÓMTẮT 24

BÀI 2: TÁC VỤ PHÂN TÍCH & ĐẶC TẢ YÊU CẦU 25

2.1TỔNGQUAN 25

2.2QTRÌNHPHÂNTÍCH 25

2.2.1 Phân tích Phạm vi dự án 25

2.2.2 Phân tích Mở rộng Yêu cầu Nghiệp vụ 27

2.2.3 Phân tích Yêu cầu Bảo mật 29

2.2.4 Phân tích Yêu cầu Tốc độ 31

2.2.5 Phân tích Yêu cầu Vận hành 32

2.2.6 Phân tích Khả Mở rộng Yêu cầu 33

2.2.7 Phân tích Yêu cầu Sẵn dùng 34

2.2.8 Phân tích Yếu tố Con người 34

2.2.9 Phân tích Yêu cầu Tích hợp 34

2.2.11 Phân tích Yêu cầu Khả Quy mô 36

2.3XÁCĐỊNHYÊUCẦU 36

2.3.1 Yêu cầu Mô tả yêu cầu 37

2.3.2 Phân loại yêu cầu 38

2.3.3 Các bước xác định yêu cầu 41

2.4MƠHÌNHHỐUCẦUHỆTHỐNG 48

2.4.1 Các Ngun lý Mơ hình hóa 48

2.4.2 Sơ đồ phân rã chức (FDD) 49

2.4.3 Mơ hình mẫu (Prototype) 51

2.4.4 Sơ đồ luồng liệu (Data Flow Diagram, DFD) 52

2.4.5 Mơ hình hướng đối tượng 52

2.4.6 Ví dụ minh họa từ u cầu sang mơ hình hóa 57

TÓMTẮT 58

BÀI 3: TÁC VỤ THIẾT KẾ PHẦN MỀM 59

3.1TỔNGQUANVỀTHIẾTKẾ 59

3.1.1 Kỹ thuật thiết kế 60

3.1.2 Thiết kế giao diện người dùng 67

3.1.3 Thiết kế hướng chức 69

3.1.4 Thiết kế hướng đối tượng 69

3.2KIẾNTRÚCPHẦNMỀM 70

3.3PHƯƠNGPHÁPTHIẾTKẾPHẦNMỀM 72

3.4VÍDỤMINHHOẠ 74

TÓMTẮT 76

BÀI 4: TÁC VỤ THIẾT KẾ & TỔ CHỨC DỮ LIỆU 77

4.1TỔNGQUAN 77

4.2KẾTQUẢCỦATHIẾTKẾ 77

4.3QUÁTRÌNHTHIẾTKẾ 82

4.4PHƯƠNGPHÁPTHIẾTKẾDỮLIỆU 85

4.4.1 Phương pháp Trực tiếp 85

4.4.2 Phương pháp Gián tiếp 86

TÓMTẮT 93

BÀI 5: TÁC VỤ THIẾT KẾ GIAO DIỆN 94

5.1TỔNGQUAN 94

5.1.1 Kết thiết kế 95

5.1.2 Phân loại hình giao diện 97

5.1.3 Quá trình thiết kế 98

5.1.4 Các vấn đề khác 101

5.1.5 Một số ý chung 104

5.2THIẾTKẾMÀNHÌNH 105

5.2.1 Mơ tả hình 105

5.2.3 Ví dụ 106

5.3THIẾTKẾMÀNHÌNHTRACỨU 107

5.3.1 Mơ tả hình tra cứu 107

5.3.2 Thể tiêu chuẩn tra cứu 108

5.3.3 Thể kết tra cứu 108

5.3.4 Thao tác người dùng xử lý phần mềm 110

5.4THIẾTKẾMÀNHÌNHNHẬPLIỆU 111

5.4.1 Mơ tả hình nhập liệu 111

5.4.2 Thiết kế hình nhập liệu dạng danh sách 113

5.4.3 Thiết kế hình nhập liệu dạng hồ sơ 114

5.4.4 Thiết kế hình nhập liệu dạng phiếu 114

TÓMLƯỢC 115

BÀI 6: TÁC VỤ XÂY DỰNG CHƯƠNG TRÌNH 116

6.1TỔNGQUAN 116

6.2MƠITRƯỜNGLẬPTRÌNH 119

6.2.1 Tiêu chí Chất lượng ngơn ngữ lập trình 119

6.2.2 Tiêu chí Khả mơ-đun hóa ngơn ngữ lập trình 119

6.2.3 Tiêu chí Giá trị tài liệu kỹ thuật ngôn ngữ lập trình 120

6.2.4 Tiêu chí Cấu trúc liệu ngơn ngữ lập trình 120

6.2.5 Ví dụ 121

6.3PHONGCÁCHLẬPTRÌNH 121

6.3.1 Tính cấu trúc 122

6.3.2 Ưu điểm diễn đạt 122

6.3.3 Cách thức trình bày bên ngồi 124

6.4ĐÁNHGIÁCHẤTLƯỢNGCƠNGVIỆC 124

6.4.1 Hiện thực tăng cường 124

6.4.2 Đánh giá lại thiết kế chương trình (Design and Code Review) 125

6.5VÍDỤMINHHOẠ 126

TĨMTẮT 127

BÀI 7: TÁC VỤ KIỂM THỬ PHẦN MỀM 128

7.1TỔNGQUAN 128

7.1.1 Lịch sử 128

7.1.2 Giới thiệu 129

7.1.3 Mơ hình chữ V 130

7.2UCẦUĐỐIVỚIKIỂMTHỬ 131

7.3CÁCKỸTHUẬTKIỂMTHỬ 132

7.3.1 Phương pháp Hộp đen (Black box) 132

7.3.2 Phương pháp Hộp trắng (White box) 132

7.3.3 Phương pháp Hộp xám (Grey box) 133

7.4CHIẾNLƯỢC&CÁCGIAIĐOẠN 134

7.4.2 Kiểm thử Chức (Functional Test) 137

7.4.3 Kiểm thử Tích hợp (Integration Test) 137

7.4.4 Kiểm thử Hệ thống (System Test) 139

7.4.5 Kiểm thử Chấp nhận (Acceptance Test) 139

7.4.6 Kiểm thử beta 140

7.4.7 Một số cơng việc khác 140

7.5VÍDỤMINHHOẠ 142

TÓMTẮT 144

BÀI 8: TÁC VỤ BẢO TRÌ PHẦN MỀM 145

8.1GIỚITHIỆU 145

8.2TẦMQUANTRỌNGCỦABẢOTRÌ 148

8.3KẾHOẠCHBẢOTRÌPHẦNMỀM 149

8.4QUYTRÌNHBẢOTRÌPHẦNMỀM 150

TĨMTẮT&ƠNTẬP 151

BÀI 9: QUẢN TRỊ DỰ ÁN PHẦN MỀM 152

9.1GIỚITHIỆU 152

9.1.1 Khái niệm dự án 152

9.1.2 Các vấn đề thường xảy dự án phần mềm 152

9.2TÓMLƯỢCVỀQUẢNTRỊDỰÁN 153

9.3HOẠTĐỘNGCỦAQUẢNTRỊDỰÁN 154

9.4ĐỘĐOPHẦNMỀM 157

9.4.1 Đo lường kích cỡ phần mềm 157

9.4.2 Độ đo dựa thống kê 158

9.5CÁCTÁCVỤCẦNTHIẾT 158

9.5.1 Ước lượng 158

9.5.2 Quản lý nhân 160

9.5.3 Quản lý cấu hình 161

9.5.4 Quản lý rủi ro 162

TÓMTẮT 163

BÀI 10: QUY TRÌNH PHÁT TRIỂN PHẦN MỀM 164

10.1GIỚITHIỆU 164

10.2GIỚITHIỆUVỀQUYTRÌNH 165

10.3QUYTRÌNHISO,CMM/CMMI 167

TÓMTẮT 169

PHỤLỤCA–BÀITẬP 170

PHỤLỤCB–THAMKHẢO 179

PHỤLỤCC–QUYTRÌNHRUP 182

HƯỚNG DẪN

MÔ TẢ MÔN HỌC

Môn học nhằm cung cấp cho sinh viên kiến thức sở liên quan đến đối tượng yếu lĩnh vực Cơng nghệ Phần mềm (quy trình cơng nghệ, phương pháp kỹ thuật thực hiện, phương pháp tổ chức quản lý, công cụ môi trường triển khai phần mềm,…), đồng thời giúp sinh viên hiểu biết tiến hành xây dựng phần mềm cách có hệ thống , có phương pháp Trong trình học, sinh viên giới thiệu nhiều phương pháp khác Từ giúp sinh viên hiểu, phân tích vận dụng linh hoạt mơ hình phương pháp xây dựng phần mềm để thực phát triển phần mềm tùy theo nhu cầu thực tế thân, tổ chức doanh nghiệp kiến thức khác

NỘI DUNG MÔN HỌC

- Bài 1: GIỚI THIỆU: trình bày khái niệm bản, quy trình cơng nghệ phần mềm, phương pháp xây dựng phần mềm, công cụ & môi trường phát triển phần mềm, yêu cầu kỹ sư phần mềm

- Bài 2: TÁC VỤ PHÂN TÍCH & ĐẶC TẢ YÊU CẦU: giới thiệu tổng quan mô hình hố u cầu hệ thống

- Bài 3: TÁC VỤ THIẾT KẾ PHẦN MỀM: trình bày tổng quan thiết kế, kiến trúc phần mềm, phương pháp thiết kế phần mềm, ví dụ minh hoạ

- Bài 4: TÁC VỤ THIẾT KẾ & TỔ CHỨC DỮ LIỆU: giới thiệu tổng quan thiết kế, kết thiết kế, trình thiết kế, phương pháp thiết kế liệu

- Bài 5: TÁC VỤ THIẾT KẾ GIAO DIỆN: trình bày tổng quan thiết kế hình, thiết kế hình tra cứu, thiết kế hình nhập liệu

- Bài 6: TÁC VỤ XÂY DỰNG CHƯƠNG TRÌNH: giới thiệu tổng quan tác vụ thực chương trình, mơi trường lập trình, phong cách lập trình, đánh giá chất lượng cơng việc, ví dụ minh hoạ

- Bài 8: TÁC VỤ BẢO TRÌ PHẦN MỀM: giới thiệu tầm quan trọng bảo trì phần mềm, kế hoạch bảo trì phần mềm, quy trình bảo trì phần mềm

- Bài 9: QUẢN TRỊ DỰ ÁN PHẦN MỀM: giới thiệu tóm lược quản trị dự án, hoạt động quản trị dự án, độ đo phần mềm, tác vụ cần thiết

- Bài 10: QUY TRÌNH PHÁT TRIỂN PHẦN MỀM: giới thiệu quy trình, quy trình ISO, CMM/CMMI

KIẾN THỨC TIỀN ĐỀ

Môn học Cơng nghệ Phần mềm địi hỏi sinh viên có kiến thức ngơn ngữ lập trình lập trình ứng dụng bản, có khả áp dụng cấu trúc liệu giải thuật, có hiểu biết kiến trúc máy tính, mạng máy tính

U CẦU MƠN HỌC

Người học cần học đầy đủ, đọc nội dung học trước đến lớp, làm tập nhà đảm bảo thời gian tự học nhà

CÁCH TIẾP NHẬN NỘI DUNG MÔN HỌC

Để học tốt môn này, người học cần ôn học, trả lời câu hỏi làm đầy đủ tập; đọc trước tìm thêm thơng tin liên quan đến học

Đối với học, người học đọc trước mục tiêu tóm tắt học, sau đọc nội dung học Kết thúc ý học, người đọc trả lời câu hỏi ôn tập kết thúc toàn học, người đọc làm tập

PHƯƠNG PHÁP ĐÁNH GIÁ MÔN HỌC

Môn học đánh giá gồm hai thành phần

- Điểm trình: 30% Hình thức nội dung giáo viên định, phù hợp với quy chế đào tạo tình hình thực tế nơi tổ chức học tập

BÀI 1: GIỚI THIỆU Học xong người học sẽ:

- Hiểu khái niệm Cơng nghệ Phần mềm

- Biết quy trình công nghệ phần mềm, phương pháp xây dựng phần mềm, công cụ & môi trường phát triển phần mềm

1.1 CÁC KHÁI NIỆM CƠ BẢN

1.1.1 Phần mềm

 Các khái niệm

- Chương trình máy tính: trình tự thị để hướng dẫn máy tính làm việc nhằm hồn thành cơng việc người dùng u cầu

- Phần mềm: hệ thống chương trình thực máy tính nhằm hỗ trợ chuyên gia lĩnh vực chuyên ngành thực tốt thao tác nghiệp vụ

- Nhiệm vụ yếu phần mềm: để chuyên gia thực công việc họ máy tính dễ dàng nhanh chóng so với thực cơng việc giới thực

- Hoạt động phần mềm: mô lại họat động giới thực góc độ thu hẹp máy tính

- Q trình sử dụng phần mềm: trình thực cơng việc máy tính để hồn tất cơng việc tương đương giới thực

- Mục tiêu ngành công nghệ phần mềm: hướng đến xây dựng phần mềm có chất lượng mà cịn cho phép xây dựng dễ dàng phần mềm từ phần mềm có sẵn lĩnh vực (thậm chí lĩnh vực khác)

Bảng 1.1: Các phần mềm lớp phần mềm tương ứng

STT Lớp phần mềm Các phần mềm

1 Hỗ trợ giải tập lượng giác, hình học, giải tích, số học, …

2 Trị chơi cờ carơ, cờ tướng, cờ vua, xếp hình, …

3 Xếp lịch biểu thi đấu, thời khóa biểu, hội nghị, …

4 Xét tuyển nhân sự, học sinh lớp 10…

5 Bình chọn Sản phẩm, cầu thủ, …

6 Quản lý học sinh Mầm non, trung học, trung tâm…

7 Bán hàng thuốc tây, vật liệu xây dựng, máy tính

8 Quản lý thuê bao điện, điện thoại, nước, …

9 Cho mượn sách, truyện, phim, …

 Phân loại

- Phần mềm hệ thống:

 Là phần mềm đảm nhận cơng việc tích hợp điều khiển thiết bị phần cứng,

 Tạo môi trường thuận lợi để phần mềm khác người sử dụng thao tác khối thống mà không cần quan tâm đến chi tiết kỹ thuật phức tạp bên (như cách trao đổi liệu nhớ đĩa, cách hiển thị văn lên hình )

- Phần mềm ứng dụng:

 Là phần mềm dùng để thực công việc xác định,

- Sản phẩm đại trà (Generic Product): phát triển để bán thị trường, đối tượng sử dụng tương đối đa dạng phong phú Những sản phẩm loại thường phần mềm dành cho máy tính

- Sản phẩm theo đơn đặt hàng (Bespoke Product Customised Product): phát triển theo yêu cầu cho khách hàng riêng lẻ Ví dụ: hệ thống phần mềm chuyên dụng cho doanh nghiệp riêng lẻ …

 Kiến trúc phần mềm

Về mặt cấu trúc, phần mềm bao gồm thành phần:

Thành phần Giao tiếp (giao diện)

Đây hệ thống phương thức chuyên việc nhập/xuất liệu (hàm nhập/xuất) với hình thức trình bày tổ chức lưu trữ liệu tương ứng, mục tiêu hàm đưa liệu từ giới bên phần mềm vào bên ngược lại Cụ thể là:

- Tiếp nhận yêu cầu việc cần thực hiện, cung cấp nguồn liệu liên quan đến việc từ thiết bị thu thập liệu (cân, đo nhiệt độ …)

- Trình bày kết việc thực yêu cầu cho người dùng (kết cơng việc thực máy tính) điều khiển họat động thiết bị điều khiển (đóng mở cửa, bật mở máy…)

Thành phần Dữ liệu

Đây hệ thống chức chuyên đọc ghi liệu (hàm đọc/ghi) với mô hình tổ chức liệu tương ứng Mục tiêu chức chuyển đổi liệu nhớ nhớ phụ Cụ thể là:

- Cho phép lưu trữ lại (hàm ghi) kết xử lý (việc mượn sách kiểm tra hợp lệ …) nhớ phụ với tổ chức lưu trữ xác định trước (tập tin có cấu trúc, tập tin nhị phân, sở liệu)

Thành phần xử lý

Đây hệ thống chức chuyên xử lý tính tốn, biến đổi liệu Chúng dùng liệu nguồn từ chức thành phần giao diện (hàm nhập) hay thành phần liệu (hàm đọc liệu) để kiểm tra tính hợp lệ (hàm kiểm tra), tiến hành xử lý (hàm xử lý) cần thiết, để tạo kết hiển thị cho người xem qua chức thành phần giao diện (hàm xuất), lưu trữ chức thành phần liệu (hàm ghi) Cụ thể là:

- Kiểm tra tính hợp lệ liệu nguồn người dùng nhập theo quy trình ràng buộc giới thực (cho mượn tối đa sách, …)

- Xử lý tạo kết mong đợi theo quy định có giới thực (quy tắc tính tiền phạt trả sách trễ …) theo thuật giải tự đề xuất,

- Việc xử lý dựa liệu nguồn từ người sử dụng cung cấp liệu lưu trữ có sẵn hai tùy vào xử lý cụ thể

- Tương tự, việc xử lý cho kết dùng để xuất cho người xem qua thành phần giao diện (xuất tiền phạt …), hay lưu trữ lại qua thành phần liệu (số sách mượn độc giả…) hai (bảng tồn kho …)

Bảng 1.2: Danh sách hàm ý nghĩa tương ứng STT Thành

phần

Hàm Ý nghĩa Ghi

1 Thành

phần giao diện

Hàm nhập Nhập yêu cầu, liệu nguồn Cần xác định hình thức nhập/xuất tổ chức liệu tương ứng

Hàm xuất Xuất kết xử lý

2 Thành

phần xử lý

Hàm kiểm tra Kiểm tra tính hợp lệ liệu Sử dụng hàm nhập, hàm đọc Sử dụng hàm nhập, hàm đọc, hàm xuất, hàm ghi

Hàm xử lý Xử lý tính tốn, phát sinh, biến đổi liệu

3 Thành

phần liệu

Hàm đọc Đọc liệu từ nhớ phụ vào nhớ

Cần xác định cáchh thức tổ chức lưu trữ liệu

1.1.2 Chất lượng phần mềm

Phần mềm tốt phần mềm phải đáp ứng chức theo yêu cầu, có hiệu tốt, có khả bảo trì, đáng tin cậy, người sử dụng chấp nhận Cụ thể hơn, chất lượng phần mềm thể qua tính chất sau :

 Tính đắn

Tính chất thể chổ sản phẩm thực đầy đủ xác yêu cầu người dùng

Theo nghĩa rộng, tính đắn cần hiểu chương trình cần phải thực trường hợp mà liệu đầu vào không hợp lệ

Ví dụ, chức phần mềm xếp tăng giảm tập tin có số lượng mẫu tin tùy ý theo cột bất kỳ, trường hợp sau vi phạm tính đắn chương trình khi:

- Không thể xếp theo chiều tăng hay giảm dần …

- Không thể thực (treo máy) tập khơng có mẫu tin

- Không thể thực hiện, thực cho kết sai, có nhiều mẫu tin mẫu tin có q nhiều cột

Tính đắn phần mềm xác định dựa sở sau đây:

- Tính đắn giải pháp xử lý thuật toán sở,

- Tính đắn chương trình chứng minh trực tiếp tập mã lệnh nội dung chương trình,

- Tính đắn khẳng định dần qua việc kiểm thử, việc áp dụng chương trình khoảng thời gian dài diện rộng với tần suất sử dụng cao (liên quan đến hiệu chương trình),

 Tính tiến hóa

Tính chất nhấn mạnh khả cho phép:

- Sản phẩm mở rộng, tăng cường mặt chức dễ dàng,

- Người dùng khai báo thay đổi quy định với phần mềm tùy theo thay đổi giới thực liên quan (như thay công thức tiền phạt …)

 Tính hiệu

Tính chất xác định qua tiêu chuẩn sau:

- Hiệu kinh tế, ý nghĩa, giá trị thu áp dụng sản phẩm - Hiệu sử dụng (tốc độ xử lý phần mềm …)

- Hiệu kỹ thuật (sử dụng tối ưu tài nguyên máy tính: CPU, nhớ, khơng gian xử lý …)

 Tính tiện dụng

Tính chất phần mềm dựa yếu tố sau đây: - Tính động linh hoạt sản phẩm

- Cảm nhận (về mặt tâm lý) người dùng về:

 Sản phẩm dễ học, có giao diện trực quan tự nhiên

 Các chức sản phẩm dễ thao tác …

 Tính tương thích

Tính chất khả trao đổi liệu với phần mềm khác có liên quan (ví dụ: nhận danh sách nhân viên từ tập tin Excel …), gồm Giao tiếp nội Giao tiếp bên

 Tính tái sử dụng

1.1.3 Công nghệ Phần mềm

 Sự đời

Trong thập niên 1950, máy tính điện tử đời, dùng phịng thí nghiệm bắt đầu ứng dụng họat động xã hội Các chương trình điều khiển (cịn gọi phần mềm) cho máy tính chế tạo với số lượng ít, chủ yếu dùng cho việc tính tốn đặc biệt lĩnh vực quốc phòng

Đến thập niên 1960, phần mềm chế tạo nhiều ứng dụng rộng rãi nhiều lĩnh vực Vào năm 1968, vấn đề “cuộc khủng hoảng phần mềm”1 phát sinh giới, thể qua yếu tố chính:

- Số lượng phần mềm tăng vọt, phát triển phần cứng làm tăng khả xử lý giảm giá thành chế tạo,

- Các phần mềm dùng mắc nhiều khuyết điểm như:

 Không đáp ứng u cầu, thiếu xác, khơng ổn định …

 Thời gian bảo trì, nâng cấp lâu với chi phí cao mà hiệu thấp

 Khó sử dụng thực chậm, Khó chuyển đổi liệu phần mềm … Để giải vấn đề trên, hội nghị triệu tập để bàn cách giải Hội nghị tiến hành xem xét, phân tích xác định nguyên nhân gây khủng hoảng phần mềm, đưa kết luận sau:

- Việc tăng vọt số lượng phần mềm điều hợp lý, điều tiếp diễn tương lai

- Các khuyết điểm phần mềm có nguồn gốc chủ yếu từ phương pháp cách thức tiến hành xây dựng phần mềm, là:

 Cảm tính: người/mỗi phận theo cách thức riêng

 Thô sơ, đơn giản: tập trung vào việc lập trình mà quan tâm đến việc quan trọng cần làm khác giai đoạn trước lập trình (khảo sát trạng, phân tích yêu cầu, thiết kế …)

 Thủ công: công cụ hỗ trợ xây dựng phần mềm trình biên dịch (compiler)

Từ kết luận trên, hội nghị đề xuất khai sinh ngành khoa học Công nghệ Phần mềm với nhiệm vụ nghiên cứu phương pháp tiến hành xây dựng phần mềm

 Định nghĩa

Công nghệ Phần mềm lĩnh vực nghiên cứu tin học nhằm đề xuất nguyên lý, phương pháp, công cụ, cách tiếp cận phục vụ cho việc thiết kế, thực sản phẩm phần mềm đạt đầy đủ yêu cầu chất lượng phần mềm

Do q trình tiến hóa ngành Cơng nghệ Phần mềm, nên khái niệm thay đổi theo thời gian Hơn nữa, lĩnh vực nên khái niệm phụ thuộc nhiều vào quan điểm chủ quan người khác Cụ thể sau:

- Theo tác giả Bauer [1969]: việc thiết lập sử dụng nguyên lý công nghệ đắn để thu phần mềm cách kinh tế vừa tin cậy vừa làm việc hiệu máy thực

- Theo tác giả Ghezzi [1991]: lĩnh vực khoa học máy tính liên quan đến việc xây dựng phần mềm vừa lớn vừa phức tạp hay số nhóm kỹ sư

- Theo IEEE [1993]: việc áp dụng phương pháp tiếp cận có hệ thống, bản, lượng hóa, vận hành, bảo trì phần mềm

- Theo tác giả Sommervile [1995]: lĩnh vực liên quan đến lý thuyết, phương pháp công cụ dùng cho phát triển phần mềm

ngun tắc xác định) tồn quy trình phát triển phần mềm nhằm nâng cao chất lượng sản xuất phần mềm

- Theo nhóm tác giả Pressman [1995]: mơn tích hợp quy trình, phương pháp, công cụ để phát triển phần mềm máy tính

Ta tóm tắt khái niệm Công nghệ Phần mềm sau: Công nghệ phần mềm nghành khoa học nghiên cứu việc xây dựng phần mềm có chất lượng khoảng thời gian chi phí hợp lý

Mục tiêu nghiên cứu ngành Công nghệ Phần mềm gồm: - Xây dựng phần mềm có chất lượng

- Xây dựng phần mềm thời gian chi phí hợp lý

 Đối tượng nghiên cứu

Hướng đến việc xây dựng phần mềm có chất lượng nêu trên, ngành Công nghệ Phần mềm đưa đối tượng nghiên cứu là:

- Quy trình công nghệ phần mềm: hệ thống giai đoạn mà trình phát triển phần mềm phải trải qua; với giai đoạn cần xác định rõ mục tiêu, kết nhận từ giai đoạn trước kết chuyển giao cho giai đoạn kết tiếp

- Phương pháp phát triển phần mềm: hệ thống hướng dẫn cho phép bước thực giai đoạn quy trình cơng nghệ phần mềm

- Công cụ môi trường phát triển phần mềm: hệ thống phần mềm trợ giúp lĩnh vực xây dựng phần mềm Các phần mềm hỗ trợ chuyên viên tin học bước xây dựng phần mềm theo phương pháp với quy trình chọn trước

 Các so sánh

Sự khác biệt cơng nghệ phần mềm khoa học máy tính

mềm phát triển mạnh lý thuyết khoa học máy tính khơng đủ để đóng vai trị tảng hồn thiện cho công nghệ phần mềm

Sự khác biệt công nghệ phần mềm công nghệ hệ thống

Công nghệ hệ thống liên quan tới tất khía cạnh q trình phát triển hệ thống dựa máy tính bao gồm: phần cứng, phần mềm, cơng nghệ xử lý Kỹ sư hệ thống phải thực việc đặc tả hệ thống, thiết kế kiến trúc hệ thống, tích hợp triển khai Cơng nghệ phần mềm phần quy trình này, có liên quan tới việc phát triển hạ tầng phần mềm, ứng dụng sở liệu hệ thống

1.2 QUY TRÌNH CƠNG NGHỆ PHẦN MỀM

Q trình xây dựng phần mềm có chất lượng cần trãi qua nhiều giai đoạn Mỗi giai đoạn có mục tiêu kết chuyển giao xác định Trình tự thực giai đoạn chu kỳ sống phần mềm

Tổng quát, chu kỳ sống phần mềm khoảng thời gian mà sản phẩm phần mềm phát triển, sử dụng mở rộng sản phẩm phần mềm khơng cịn sử dụng

Chu kỳ sống phần mềm phân chia thành pha như: Xác định, Phát triển, Kiểm thử, Bảo trì / Vận hành Phạm vi thứ tự pha khác tùy theo mơ hình cụ thể

Các bước xây dựng phần mềm:

1.2.1 Bước Xác định

Đây bước hình thành dự án, ta (nhóm phân tích thiết kế) cần:

- Biết vai trị phần mềm cần phát triển hệ thống, đồng thời phải ước lượng công việc, lập lịch biểu phân chia công việc

- Biết yêu cầu khách hàng Các yêu cầu cần phải thu thập đầy đủ, phân tích theo diện rộng sâu

1.2.2 Bước Phát triển

Trong bước này, dựa vào kết bước trên, ta (nhóm phát triển phần mềm) thực cơng đoạn Thiết kế, ta dùng ngơn ngữ đặc tả hình thức (dựa kiến trúc tốn học) phi hình thức (tựa ngơn ngữ tự nhiên) kết hợp hai để mô tả yếu tố sau chương trình:

- Giá trị nhập, giá trị xuất; Các phép biến đổi,

- Các yêu cầu cần đạt điểm chương trình

Phần đặc tả quan tâm chủ yếu đến giá trị vào/ra không quan tâm đến cấu trúc nội dung thao tác cần thực

Sau cơng đoạn Xây dựng để chuyển đặc tả chương trình thành sản phẩm phần mềm dựa ngơn ngữ lập trình cụ thể Trong cơng đoạn ta (nhóm lập trình viên) tiến hành thực (hay thi công, cài đặt, lập trình phát triển) thao tác cần thiết để thực yêu cầu đặc tả

Cơng đoạn cuối Kiểm thử, ta (nhóm kiểm tra chất lượng) cần chứng minh tính đắn chương trình sau tiến hành thực Thông thường, công đoạn ta xem chương trình hộp đen Vấn đề đặt ta cần xây dựng cách có chủ đích tập liệu thử nghiệm khác để nhập cho chương trình thực dựa vào kết thu để đánh giá chương trình Cơng việc gọi kiểm thử chương trình Cơng việc kiểm thử nhằm vào mục tiêu sau:

- Kiểm tra để phát lỗi chương trình Lưu ý kiểm thử khơng đảm bảo tuyệt đối tính đắn chương trình chất quy nạp khơng hồn tồn cách làm

- Kiểm tra để xác định tính ổn định, hiệu hiệu tối đa chương trình

1.2.3 Bước Bảo trì (Vận hành)

Cơng tác quản lý việc triển khai sử dụng phần mềm vấn đề cần quan tâm quy trình phát triển phần mềm Trong trình xây dựng phần mềm, tất kết phần tích, thiết kế, thực hồ sơ liên quan cần phải lưu trữ quản lý cẩn thận, nhằm đảm bảo cho công việc tiến hành cách hiệu phục vụ cho cơng việc bảo trì phần mềm sau Công tác quản lý không dừng lại q trình xây dựng phần mềm mà cịn phải tiến hành liên tục suốt trình sống

1.3 MỘT SỐ MƠ HÌNH TRIỂN KHAI

Có nhiều dạng mơ hình khác để triển khai bước trình phát triển phần mềm Mỗi mơ hình chia vịng đời phần mềm theo cách khác nhau, để đảm bảo quy trình phát triển phần mềm thành cơng

1.3.1 Mơ hình Thác nước

Đây mơ hình phổ biến, áp dụng trình phát triển phần mềm Mơ hình chia q trình phát triển phần mềm thành giai đoạn nối tiếp Mỗi giai đoạn có mục đích định Kết giai đoạn trước thông tin đầu vào cho giai đoạn sau Dạng phức tạp mơ hình thác nước có giai đoạn gồm:

- Xác định yêu cầu: Được tiến hành có nhu cầu xây dựng phần mềm

 Mục tiêu: xác định xác yêu cầu cho phần mềm cần có

 Kết nhận: thơng tin hoạt động giới thực

 Kết chuyển giao: danh sách yêu cầu (công việc thực máy tính) với thơng tin miêu tả chi tiết yêu cầu (cách thức thực giới thực)

- Phân tích: tiến hành sau kết thúc việc xác định yêu cầu

 Mục tiêu: mô tả lại giới thực mơ hình trước thiết kế

 Kết chuyển giao:

o Mơ hình xử lý (hệ thống cơng việc giới thực với quan hệ chúng),

o Mơ hình liệu (hệ thống loại thông tin sử dụng giới thực

cùng với quan hệ chúng),

o Mơ hình khác (khơng gian, thời gian, người…) có

- Thiết kế: tiến hành sau kết thúc việc phân tích

 Mục tiêu: mơ tả thành phần phần mềm (mơ hình phần mềm) trước tiến hành cài đặt

 Kết nhận: mơ hình giới thực

 Kết chuyển giao:

o Mô tả thành phần giao diện: hàm/cấu trúc liệu nhập/xuất o Mô tả thành phần xử lý: hàm kiểm tra xử lý

o Mô tả thành phần liệu: hàm đọc/ghi, tổ chức lưu trữ nhớ phụ

- Hiện thực: tiến hành sau kết thúc việc thiết kế

 Mục tiêu: tạo lập phần mềm theo yêu cầu

 Kết nhận: mơ hình phần mềm

 Kết chuyển giao: chương trình nguồn phần mềm với cấu trúc liệu tương ứng chương trình thực máy tính

- Kiểm thử: tiến hành có kết việc lập trình

 Mục tiêu: tăng độ tin cậy phần mềm

 Kết nhận: u cầu, mơ hình phần mềm, phần mềm

 Kết chuyển giao: phần mềm có độ tin cậy cao (đã sửa lỗi)

- Bảo trì: Cơng việc giai đoạn bao gồm việc cài đặt vận hành phần mềm thực tế

 Kết nhận: phần mềm hoàn thành

 Kết chuyển giao: phản ánh khách hàng trình sử dụng phần mềm

Hình 1.1: Mơ hình thác nước  Nhận xét

Mơ hình Thác nước giúp ta dễ dàng phân chia trình xây dựng phần mềm thành giai đoạn hoàn toàn độc lập

Một số hạn chế mơ hình này:

- Các dự án lớn tuân theo dịng chảy mơ hình, chúng thường phải lặp lại bước để nâng cao chất lượng, khách hàng tuyên bố hết yêu cầu giai đoạn phân tích

- Ta khó thực thay đổi thực xong giai đoạn đó, điều làm cho việc xây dựng phần mềm khó thay đổi yêu cầu theo ý muốn khách hàng Do đó, phương pháp thích hợp cho trường hợp mà ta hiểu rõ yêu cầu khách hàng

- Mơ hình thích hợp yêu cầu tìm hiểu rõ ràng, thay đổi giới hạn rõ ràng suốt trình thiết kế

 Chú ý

1.3.2 Mơ hình Bản mẫu Phần mềm

Mơ hình Bản mẫu tương tự mơ hình thác nước với việc bổ sung vào giai đoạn thực phần mềm mẫu (ngay xác định yêu cầu nhằm mục tiêu phát nhanh sai sót u cầu) Các giai đoạn mơ hình mẫu tiến hành lặp lại mà khơng thiết theo trình tự định

Ngay sau giai đoạn Xác định yêu cầu, ta (nhóm phát triển phần mềm) đưa thiết kế sơ tiến hành thực mẫu đầu tiên, chuyển chúng cho người sử dụng Bản mẫu nhằm để mô tả cách thức phần mềm hoạt động cách người dùng tương tác với hệ thống

Người dùng sau xem xét phản hồi thơng tin cần thiết lại cho nhóm phát triển Nếu người dùng đồng ý với mẫu đưa, nhóm phát triển tiến hành thực thật Ngược lại, hai phải quay lại giai đoạn xác định yêu cầu Công việc lặp lại liên tục người sử dụng đồng ý với mẫu nhà phát triển đưa

Hình 1.2: Mơ hình mẫu

1.3.3 Mơ hình Xoắn ốc

Mơ hình Xoắn ốc kết hợp mơ hình mẫu thiết kế mơ hình thác nước lặp lại nhiều lần Ở lần lặp tiếp theo, hệ thống tìm hiểu xây dựng hồn thiện lần lặp trước đó, tức yêu cầu người dùng hiểu ngày rõ ràng hơn, mẫu phần mềm ngày hoàn thiện Ngoài ra, cuối lần lặp có thêm cơng đoạn Phân tích mức độ rủi ro để định xem có nên hướng hay khơng Mơ hình phù hợp với hệ thống phần mềm lớn có khả kiểm sốt rủi ro bước tiến hóa

Hình 1.3: Mơ hình xoắn ốc

1.4 CÁC PHƯƠNG PHÁP XÂY DỰNG PHẦN MỀM

1.4.1 Khái niệm

Để tiến hành xây dựng phần mềm, ta áp dụng nhiều phương pháp khác Mỗi phương pháp có:

- Có hướng dẫn cụ thể cơng việc cần thực giai đoạn quy trình xây dựng phần mềm,

- Quy định cách thức khác để trình bày kết thu trình xây dựng phần mềm; quy định có tính chất ngơn ngữ thống để thành viên tham gia xây dựng phần mềm trao đổi thơng tin việc xây dựng phần mềm

1.4.2 Phân loại

Các phương pháp xây dựng phần mềm chia làm nhóm khác dựa vào tính chất cơng việc cần thực hiện, gồm có:

- Phương pháp xây dựng: Phương pháp hướng chức năng; hướng liệu; hướng đối tượng

- Phương pháp tổ chức quản lý: Xây dựng phương án, Tổ chức nhân sự, Ước lượng rủi ro-chi phí, Lập theo dõi kế hoạch triển khai

1.4.3 Các phương pháp xây dựng phần mềm

 Cách tiếp cận

Tiếp cận từ xuống (top-down)

Đây cách giải vấn đề theo hướng phân tích Khi tiến hành xây dựng phần mềm theo cách này, ta bắt đầu với thành phần hệ thống Sau đó, thành phần phân tích thành thành phần chi tiết cụ thể Q trình phân tích kết thúc kết thu có mức độ phức tạp với ý muốn nhóm phát triển phần mềm

Tiếp cận từ lên (bottom-up)

 Cách tiến hành

Phương pháp Hướng Chức

Với phương pháp này, việc xây dựng phần mềm thực dựa chức mà hệ thống cần thực hiện, trọng đến thành phần xử lý với thao tác tính tốn, thao tác phát sinh, thao tác biến đổi …

Phương pháp chung để giải vấn đề áp dụng nguyên lý “chia để trị” Khi tiến hành xây dựng phần mềm theo phương pháp này, ta chia công việc lớn (mà hệ thống cần thực hiện) hành công việc nhỏ độc lập Việc phân chia công việc tiến hành công việc thu đủ nhỏ để ta tiến hành xây dựng hồn chỉnh (h1.4)

Hình 1.4: Minh họa Nguyên lý Chia để trị

Hình 1.5: Ví dụ minh họa DFD (nguồn [5])

Phương pháp Hướng Dữ liệu

Ngược lại với phương pháp trên, phương pháp Hướng Dữ liệu trọng nhiều đến thành phần liệu cần phải xử lý hệ thống tổ chức liệu, khối lượng lưu trữ, tốc độ truy xuất …

Khi tiến hành thiết kế theo phương pháp này, ta bắt đầu với việc thiết kế cấu trúc liệu cần thiết có tốn, sau tiến hành thiết kết thao tác để vận hành cấu trúc liệu thiết kế

Phương pháp thích hợp cho loại phần mềm có chức lưu trữ thao tác loại liệu Hạn chế không quan tâm đến chức mà hệ thống cần phải đáp ứng Điều dẫn đến việc có khả hệ thống sau thiết kế khơng có đầy đủ chức cần thiết

Hình 1.6: Minh hoạ ERD (nguồn [5])

Phương pháp Hướng Đối tượng

Phương pháp thiết kế Hướng Đối tượng kết hợp phương pháp Hướng Dữ liệu phương pháp Hướng Chức Phương pháp trọng đến thành phần liệu chức hệ thống

Theo phương pháp hướng đối tượng, hệ thống phần mềm tập hợp đối tượng có khả tương tác với Các đối tượng vật tượng vật lý trừu tượng có giới thực Mỗi đối tượng có liệu riêng che dấu với giới bên thao tác mà đối tượng thực thành phần liệu đối tượng

đối tượng đưọc bảo vệ cách chắn (xem thêm tài liệu Phân tích Thiết kế Hướng Đối tượng)

Hình 1.7: Minh họa sơ đồ lớp đối tượng (nguồn [5])

1.5 CÔNG CỤ & MÔI TRƯỜNG PHÁT TRIỂN PHẦN MỀM

1.5.1 Mở đầu

trường hợp tên gọi chung thường môi trường phát triển phần mềm (SDE, Software Development Environment), gồm hình thức chính:

- Cho lưu / cập nhật kết chuyển giao với phương pháp - Cho phát sinh kết chuyển giao cho giao đoạn

1.5.2 Phần mềm hỗ trợ thực giai đoạn

1.5.2.1 Phần mềm hỗ trợ phân tích

- Cơng việc hỗ trợ chính: Soạn thảo mơ hình giới thực, Ánh xạ vào mơ hình luận lý

- Các phần mềm: WinA&D, Analyst Pro, Rational Rose …

1.5.2.2 Phần mềm hỗ trợ thiết kế

- Cơng việc hỗ trợ chính: Soạn thảo mơ hình luận lý, Ánh xạ vào mơ hình vật lý - Các phần mềm: Power Designer, Oracle Designer, Rational Rose …

1.5.2.3 Phần mềm hỗ trợ lập trình

- Cơng việc hỗ trợ chính: Quản lý phiên (dữ liệu, chương trình nguồn, giao diện), biên dịch

- Các phần mềm: Visual Studio Net (Basic, C#, C++), Borland …

1.5.2.4 Phần mềm hỗ trợ kiểm chứng

- Công việc hỗ trợ chính: Phát sinh tự động liệu thử nghiệm, Phát lỗi - Các phần mềm: WinRuner, QuickTestPro …

1.5.3 Phần mềm hỗ trợ tổ chức, quản lý việc triển khai

1.5.3.1 Xây dựng phương án

1.5.3.2 Lập kế hoạch

- Công việc hỗ trợ chính: xác định cơng việc, phân cơng, lập lịch biểu, theo dõi thực

- Các phần mềm: MS Project, Visio

1.6 YÊU CẦU ĐỐI VỚI KỸ SƯ PHẦN MỀM

Quy trình xây dựng phần mềm thực môi trường chuyên nghiệp đòi hỏi tuân thủ nguyên tắc cách xác

Những kỹ sư phần mềm phải coi công việc họ trách nhiệm to lớn, không đơn việc ứng dụng kỹ thuật

Kỹ sư phần mềm phải ứng xử trung thực cách làm họ phải chuyên nghiệp quy tắc

Một số nguyên tắc cần thiết mà kỹ sư phần mềm phải thực

- Sự tin cẩn: kỹ sư phần mềm phải tạo tin cẩn từ phía nhân viên khách hàng

- Năng lực: kỹ sư phần mềm khơng nên trình bày sai khả mình, không nên nhận công việc vượt khả

- Các quyền tài sản trí tuệ: kỹ sư phần mềm nên quan tâm tài sản trí tuệ bảo hộ: sáng chế, quyền tác giả … để đảm bảo tất tài sản trí tuệ bảo hộ

- Lạm dụng máy tính: kỹ sư phần mềm khơng nên sử dụng kỹ để gây ảnh hưởng tới người khác Lạm dụng máy tính hiểu việc tầm thường (như chơi điện tử máy tính người khác) đến vấn đề nghiêm trọng (như phát tán virus)

TĨM TẮT

Bài học trình bày khái niệm Công nghệ Phần mềm như: - Các khái niệm

 Phần mềm (khái niệm, phân loại, kiến trúc phần mềm)

 Chất lượng phần mềm (tính đắn, tính tiến hóa, tính hiệu quả, tính tiện dụng, tính tương thích, tính tái sử dụng)

 Công nghệ phần mềm (nguồn gốc, định nghĩa …) - Quy trình cơng nghệ phần mềm

 Các bước xây dựng phần mềm (Xác định, Phát triển, Bảo trì /Vận hành)

 Một số mơ hình triển khai xây dựng phần mềm (Thác nước, Bản mẫu Phần mềm, Xoắn ốc)

- Các phương pháp xây dựng phần mềm: tổng quan (Khái niệm, Phân loại), phương pháp xây dựng phần mềm (Cách tiếp cận, tiến hành)

- Công cụ & môi trường phát triển phần mềm

 Phần mềm hỗ trợ thực giai đoạn (phân tích, thiết kế, lập trình, kiểm chứng)

 Phần mềm hỗ trợ tổ chức, quản lý việc triển khai (Xây dựng phương án, Lập kế hoạch)

- Yêu cầu kỹ sư phần mềm với tiêu chí tin cẩn, lực, quyền tài sản trí tuệ

BÀI 2: TÁC VỤ PHÂN TÍCH & ĐẶC TẢ YÊU CẦU

Học xong người học sẽ:

- Hiểu khái niệm mơ hình hố u cầu hệ thống

- Biết dạng thức quy trình phân tích u cầu, từ thực mơ hình hóa phần mềm dựa u cầu ban đầu

2.1 TỔNG QUAN

Tác vụ Phân tích u cầu gồm cơng đoạn nhỏ nghiên cứu khả thi, phân tích mơ hình hóa, đặc tả thẩm định yêu cầu Bước phối hợp tiến hành nhóm phát triển phần mềm khách hàng, đồng thời đóng vai trị đặc biệt quan trọng tiến trình phát triển phần mềm Đây bước hình thành dự án phần mềm, trưởng nhóm thiết kế người phân tích hệ thống phải biết nhu cầu người đặt hàng Các yêu cầu cần thu thập đầy đủ phân tích đủ rộng sâu Công cụ sử dụng chủ yếu giai đoạn sơ đồ phản ánh rõ đối tượng hệ thống: lưu đồ, sơ đồ dòng liệu, mạng, thực thể-quan hệ, sơ đồ cấu trúc phân cấp, mạng ngữ nghĩa (Xem thêm Phụ lục C – Phần B)

2.2 QUÁ TRÌNH PHÂN TÍCH

2.2.1 Phân tích Phạm vi dự án

 Phần triển khai phần mềm: yêu cầu nghiệp vụ khách hàng thực hóa thành phần mềm cụ thể,

 Phần thực người hay chương trình: giai đoạn vận hành sử dụng hệ thống

(a)

(b)

Hình 2.1: Minh họa phân tích phạm vi dự án (nguồn [5])

Việc định ranh giới hai phần cơng tác xác định quy trình trách nhiệm Khi định nghĩa trách nhiệm dự án ta cũng:

- Xác định vùng địa lý liên quan (chi nhánh văn phòng),

- Ước lượng số người dùng phần mềm, thời gian phần mềm trì, - Biết tính xác yêu cầu phần mềm,

- Hiểu khách hàng mong đợi dự án triển khai Tại thời điểm đó, ta có ý tưởng phạm vi dự án

Ta cần cân nhắc độ lớn dự án thời gian ràng buộc ngân sách để đảm bảo tính khả thi việc triển khai phần mềm Nếu dự án lớn thời gian chi phí, ta cần trao đổi với khách hàng để thương (thời gian hơn, chi phí, phạm vi dự …) Nếu phân tích tất tình giai đoạn đầu dự án, ta đảm bảo nhiều cho thành công dự án

2.2.2 Phân tích Mở rộng Yêu cầu Nghiệp vụ

 Xác định yêu cầu nghiệp vụ

Mỗi dự án có hay nhiều yêu cầu nghiệp vụ, gọi tác vụ, liên quan đến việc mô tả công việc cụ thể nghiệp vụ khách hàng ngôn ngữ phù hợp để giúp người dùng kiểm tra ràng buộc nghiệp vụ cách xác Một tác vụ cần chia nhỏ thành nhiều phần phần đủ để mơ tả cơng việc xác Khi mức độ thành phần chia nhỏ mức tối thiểu, chúng xác định lại trình tự thành phần

 Xác định yêu cầu chất lượng

Mỗi dự án phần mềm có yêu cầu liên quan đến khả đáp ứng nhanh, bảo mật, phụ thuộc, dễ dùng … Thực tế, ràng buộc thời gian tài làm cho chương trình dự án khó diễn hồn tất trọn vẹn Thay vào đó, điều quan trọng để định hoàn tất trọn vẹn dựa mức độ chấp nhận chất lượng thỏa mãn nhu cầu khách hàng

 Phân tích sở hạ tầng hành

Giải pháp phần mềm đưa vào - phù hợp với sở hạ tầng - phù hợp thay hệ thống hành (trừ khách hàng có yêu cầu thay thế, hệ thống hành lạc hậu với nhiều lỗi kỹ thuật hay hạn chế lớn) Khi đưa giải pháp, ta cần nhớ việc tương thích với sở hạ tầng hành đảm bảo khả thi cho giải pháp ta, dự án cần làm việc phần cứng phần mềm mà người dùng có Nếu ta biết hệ điều hành cài máy người dùng, loại mạng sử dụng, phần mềm không tương thích với chương trình hơn, biết thơng tin cấu hình máy chủ hay hệ điều hành, phần mềm chạy đó, giúp việc phân tích xác hiệu

 Phân tích ảnh hưởng kỹ thuật

Nếu cần mở rộng chức cho hệ thống hành, thường ta mong muốn thay đổi hệ thống cũ, ta nên lưu ý đến việc cải thiện hệ thống cũ tích hợp dễ dàng hệ thống

Ví dụ: chức chương trình kế tốn lưu trữ liệu nhỏ sở liệu MS Access Để tạo liệu truy xuất hiệu thỏa mãn yêu cầu giải pháp mới, ta chuyển toàn liệu sang hệ quản trị liệu SQL Server Việc định hướng trước giúp ta tiết kiệm thời gian sau như: trãi qua thời gian tìm hiểu khác biệt giao tác, bảo mật, chức khác kỹ thuật cũ giải pháp

2.2.3 Phân tích Yêu cầu Bảo mật

Khi hệ thống cung cấp cho người dùng khả lưu trữ, truy xuất liệu cá nhân (như thơng tin nhân sự, thẻ tín dụng, doanh số bán …) hay thơng tin riêng tư, ta cần có biện pháp đảm bảo an toàn liệu

 Xác định vai trò người dùng phần mềm

Tồn phần mềm khơng có mức độ bảo mật, ví dụ như: - Người dùng cuối (end-user) cần quyền truy xuất giới hạn

- Quản trị hệ thống, người thao tác viên cập nhật, người dùng có quyền truy cập cao cấp độ

Xử lý bảo mật phần mềm dựa vai trò người dùng (authorization) kỹ thuật dùng để cấp quyền sử dụng với mức độ bảo mật khác tương ứng quyền hạn độ chuyên nghiệp người dùng hệ thống

Lưu ý: Ta cần nhận biết lớp vai trị (role) yếu người dùng cần truy cập đến phần mềm, sau gán tên vai trị cho lớp người dùng gán mức độ tối thiểu truy xuất đến vai trị Mỗi lớp vai trị nên có đủ (và vừa đủ) mức quyền truy xuất đến công việc họ

 Xác định môi trường bảo mật phần mềm

Khi người dùng muốn sử dụng chức liên quan, phần mềm đòi hỏi họ thực đăng nhập vào phần mềm, nhằm để kiểm soát tài nguyên chia sẻ tập tin, dịch vụ hệ thống, sở liệu Mức độ kiểm soát phần mềm gọi ngữ cảnh bảo mật Ta cần làm việc với người dùng khác (như người quản trị mạng) để cấp quyền truy xuất phù hợp với chức phần mềm hay chia sẻ tài nguyên Độ bảo mật phần mềm không bị giới hạn người dùng

 Xác định ảnh hưởng bảo mật

Nếu tổ chức khách hàng có sẵn chế bảo mật, hệ thống ta nên điều chỉnh cho phù hợp với chế có Nếu ta thực hệ thống bảo mật mới, cần phân tích tác động hệ thống hệ thống tại:

- Hệ thống có địi hỏi phải hỗ trợ thêm đăng nhập mở rộng?

- Hệ thống có hạn chế số người dùng tập tin hay tài nguyên mà họ quyền truy cập trước đây?

 Kế hoạch vận hành

Khi tổ chức khách hàng thay đổi nhân sự, người thêm vào, người cũ cập nhật bỏ Những thao tác đòi hỏi ta hiệu chỉnh sở liệu bảo mật (nơi lưu thông tin quyền truy cập người dùng)

Nếu người dùng có vị trí (địa lý, luận lý …) khác nhau, ta cần lên kế hoạch tái tạo sở liệu bảo mật Việc tái tạo thay đổi hệ thống liệu nơi này, chép đến nơi khác, để tất thông tin bảo mật lưu giữ nơi Việc cần lên triển khai nhằm tạo thuận lợi người dùng đăng nhập thơng tin lưu vị trí gần so với vị trí gốc

Lưu ý: Ta cần lập kế hoạch cho điều kiện khẩn cấp để thực sở liệu bảo mật bị ngắt hay việc tạo bị hỏng

 Kế hoạch kiểm soát đăng nhập

Một hệ thống bảo mật tốt không thực theo chế xử lý thụ động Thay vào đó, chúng có chức trợ giúp kiểm soát hoạt động hệ thống cho vấn đề bảo mật, thể dạng nhật ký (log file) Tất thao tác hệ thống ghi nhận với hầu hết kiện liên quan đến bảo mật hệ thống Chức ghi nhận người dùng đăng nhập hay truy xuất đến tài nguyên, điều hiệu quả; thường chúng ghi nhận số thông tin đặc biệt (như việc cố gắng đăng nhập lỗi)

Lưu ý: Nếu ta đơn lưu trữ nhật ký hệ thống điều khơng có ý nghĩa Ta cần lập kế hoạch kiểm sốt nhật ký thường xun ta phân tích phát nghi ngờ thơng tin nhật ký hoạt động đưa đề nghị có điều nghi ngờ

 Xác định mức độ yêu cầu bảo mật

tính nhạy cảm cao, cách tốt để triển khai việc bảo mật lưu trữ thông tin “sự xác thực người dùng” Nếu ta lưu trữ thơng tin cần cho bảo mật, chi phí cho việc bảo mật thông tin đặc biệt cần kiểm chứng

Trong thực tế, có hệ thống đạt 100% bảo mật Ta cần xác định độ rủi ro bảo mật (là tỉ lệ % tương ứng khả bảo mật mà hệ thống khó đạt được) chấp nhận dựa liệu nhạy cảm hệ thống

 Rà soát bảo mật

Ta cần tuân thủ yêu cầu bảo mật phần mềm phân tích sách bảo mật tổ chức, để xác định việc bảo mật có đạt đến nhu cầu hệ thống hay không thảo luận vấn đề với người phụ trách hệ thống bảo mật tổ chức để tìm giải pháp mang lại lợi ích cao từ triển khai mở rộng bảo mật

2.2.4 Phân tích Yêu cầu Tốc độ

Tốc độ xử lý phần mềm yêu cầu khó khăn cho nhóm phát triển phần mềm Nếu phần mềm thiết kế tốt, chúng thực thi nhanh

Thuật ngữ tốc độ thường dùng đồng nghĩa với phản hồi liên quan đến thời gian xử lý để phản hồi lại hành động người dùng (response time) Thời gian phản hồi trung bình phần mềm đặc tính quan trọng, cần kết hợp chặt chẽ với yêu cầu khác giai đoạn thiết kế

Lưu ý:

- Trong phần mềm dạng phân tán, nói tốc độ, ta cần nhấn mạnh khác biệt quan trọng phần mềm có nhu cầu cao hay trung bình Tại số thời điểm, buổi tối hay cuối tuần, phần mềm phục vụ số lượng nhỏ người dùng, tốc độ trung bình Ở thời điểm khác số lượng người dùng tăng cao, tốc độ phần mềm thay đổi cho phép người dùng thực thi mức vừa đủ Vì vậy, phần mềm phân tán, mục tiêu tốc độ gồm tốc độ trung bình cao

Ta cần nhận biết rõ ràng yêu cầu tốc độ phần mềm trước bắt đầu quy trình thiết kế dựa theo tiêu chí sau:

- Tần suất giao dịch: việc cung cấp dịch vụ phụ thuộc vào số người dùng khoảng thời gian Số giao tác phút (transactions per minute, TPM) độ đo tốc độ hệ thống sở liệu

- Băng thông: phản hồi nhanh (hay chậm) phần mềm xác định mức băng thông mạng (độ rộng đường truyền mạng) cao (hay thấp) Băng thông thường đo megabit/giây

- Khả chứa: mức lưu trữ (cả phần nhớ phụ) ln sẵn sàng đáp ứng phần mềm vấn đề lưu tâm quan trọng cho tốc độ chung phần mềm Mức độ đòi hỏi sử dụng nhớ phần mềm gây khác biệt lớn cho tốc độ chúng

- Nút thắt: hệ thống có phần giới hạn tốc độ Ví dụ CPU có tốc độ nhanh khơng cải thiện phải chờ liệu từ ổ cứng thực thi chậm Lúc này, tốc độ ổ cứng nút thắt hệ thống Ta cần nhận biết nút thắt hệ thống để cải thiện chúng nhằm nâng cao tốc độ Việc nhận biết nút thắt thực công cụ báo cáo hệ thống Windows NT Performance Monitor

2.2.5 Phân tích Yêu cầu Vận hành

Khi vận hành phần mềm, chi phí triển khai chi phí vận hành vấn đề quan trọng cần xem xét cẩn thận với hướng giải sau:

- Chi phí triển khai giảm bớt cách phân phối trực tuyến hay phần mềm thủ tục tự động cài đặt, thao tác vận hành tự động hóa quy trình tin học

- Chi phí vận hành tiết giảm theo nhiều cách, cách tốt đảm bảo chương trình kiểm thử chạy kiểm tra (debug) đầy đủ trước đưa vào triển khai, điều giúp tăng chất lượng phần mềm giảm lỗi hay hỏng hóc xảy lúc vận hành nên giảm chi phí bảo trì giai đoạn vận hành - Ngoài ra, trường hợp phần cứng, phần mềm thành phần mua

người ủy thác sản phẩm Vận hành sản phẩm trung gian tiết kiệm chi phí thuê nhân viên hay huấn luyện lại nhân viên cũ để trì hay nhiều thành phần hệ thống

Giảm chi phí vận hành địi hỏi tự thỏa mãn lợi nhuận thời ngắn lợi ích tương lai Giảm chi phí vận hành lâu dài thường địi hỏi đầu tư đón đầu tự động hóa phần cứng phần mềm

2.2.6 Phân tích Khả Mở rộng Yêu cầu

Theo diễn tiến thời gian, yêu cầu giải pháp ban đầu dần thay đổi Người dùng cần chức mới, quy luật đặt ban đầu bị sửa đổi, dẫn đến phần cứng phần mềm cần thay đổi theo

Phần mềm thiết kế tốt phần mềm có khả mở rộng uyển chuyển cải thiện mà khơng phải xây dựng lại hoàn toàn Khả mở rộng phần mềm tỉ lệ nghịch với lượng công việc cần hoàn thành để thêm đặc trưng đạt thơng qua ý nghĩa khác

Có ba cách đạt đến khả hạn định là:

- Lưu trữ thông tin quy tắc nghiệp vụ vào sở liệu lập trình biểu diễn chúng đối tượng nghiệp vụ Theo đó, số chức hay thủ tục phần mềm ban đầu cần thay đổi, thay đổi sở liệu mà khơng cần thay đổi mã nguồn chương trình

- Đặt mã nguồn vào đoạn mã kịch (script) làm rõ biên dịch chương trình; đoạn script bị thay đổi cách dễ dàng khơng địi hỏi biên dịch hay cài đặt lại tập tin nhị phân

2.2.7 Phân tích Yêu cầu Sẵn dùng

Các phần mềm thiết kế để thực thi đặn hàng ngày Chúng cần thiết cho thành cơng doanh nghiệp cần có mức độ sẵn sàng cao để tránh bảo trì, sửa chữa, phát sinh không theo kế hoạch Với phần mềm có tính sẵn sàng, chúng khơng gây lỗi Bất kỳ thành phần phần mềm bị hỏng hay khơng sẵn sàng ta nên khởi động lại

Việc bảo trì có kế hoạch tác động đến tính sẵn sàng phần mềm Một máy chủ chứa phần mềm lý tưởng ln có lưu khởi động máy chủ bảo trì Phần mềm có độ sẵn sàng cao cần có cách luân phiên để kết nối mạng trường hợp mạng WAN, LAN ngưng hoạt động

Lưu ý: Tính sẵn sàng liên quan đến nghiệp vụ Tính sẵn sàng phần mềm cao, giá trị phần mềm cao Với hệ thống trọng yếu, giá trị tổ chức thời điểm hoàn toàn phù hợp dẫn đến điều chỉnh chi phí thiết kế 100% cho vấn đề phần mềm sẵn sàng Phần mềm khác đơn giản cần trở nên sẵn sàng hầu hết lúc

2.2.8 Phân tích Yếu tố Con người

Phần quan trọng thiết kế phần mềm phần liên quan đến yếu tố người Ta nên xác định kinh nghiệm sử dụng phần mềm mà người dùng cần có Với phần mềm nào, để có kinh nghiệm người dùng tốt chi phí chế tạo cao

Ta bắt đầu với việc định nghĩa mục tiêu người dùng, qua xác định dạng người dùng với nhu cầu đặc biệt liên quan, qua ta sửa đổi phần mềm thích ứng nhu cầu

2.2.9 Phân tích Yêu cầu Tích hợp

Khi nhu cầu phát sinh lớn hơn, sở liệu cần thiết kế lại dựa kỹ thuật thiết kế sở liệu để đáp ứng nhu cầu nâng cấp sở liệu hệ thống phần mềm Vấn đề cần thực cẩn thận chúng phá tất mã nguồn sở liệu Trước cải tiến cấu trúc liệu, ta cần đảm bảo mã nguồn truy xuất đến sở liệu Tất mã nguồn phải sốt lại, viết lại

2.2.10 Phân tích Thực tiễn Nghiệp vụ tồn

Phần định nghĩa quy tắc nghiệp vụ (business rule) có liên quan đến hiểu biết ngữ cảnh ta (nhóm phân tích) thao tác quy tắc Khi hiểu nghiệp vụ thực tế (liên quan đến phần mềm) doanh nghiệp, ta tránh sai sót đồng thời tìm cách tốt hơn, hiệu cho việc thực tiến trình nghiệp vụ Việc ta hiểu vấn đề thực tế tiến trình giúp ngăn ngừa lỗi tầm thường

Ngoài ra, việc hiểu cấu trúc tổ chức sơ đồ nghiệp vụ doanh nghiệp yếu tố định thành cơng bước phân tích u cầu xây dựng phần mềm Nếu ta không hiểu rõ sơ đồ tổ chức, ta khơng có thiết kế phù hợp cho phần mềm hay cho trình thực Sơ đồ tổ chức giúp ta tìm kiếm nhiều thơng tin hữu ích liên quan

Để có phần mềm tốt từ giai đoạn phát triển đến lúc sử dụng, ta cần biết chi tiết hệ thống mạng sách hạ tầng khách hàng để:

- Biết người chịu trách nhiệm bảo trì, bảo mật, tính tồn vẹn, khả phản hồi tương tác mạng,

- Học tiến trình, sách liên quan chạy phần mềm mới,

- Tìm cách kiểm sốt chất lượng chuẩn bị dịch vụ kiểm thử (sẵn sàng cho việc áp dụng vào phần mềm)

Ngoài ra, ta triển khai phương pháp đặc biệt (thiết kế, triển khai thực tế) nhằm đảm bảo kế hoạch thực phù hợp với ngân sách phát triển

được nhu cầu họ gì) cách giúp ta xây dựng thành cơng phần mềm phần mềm

2.2.11 Phân tích u cầu Khả Quy mô

Sự thành công phần mềm thu hút người dùng Đặc biệt, phần mềm thực thi môi trường mạng Internet thành cơng phần mềm đồng nghĩa với việc tăng số lượng người dùng nhu cầu người dùng Để đáp ứng việc tăng quy mô nhu cầu người dùng, thiết kế phần mềm ta phải ý đến tính chất quy mơ phần mềm qua hỗ trợ nâng cấp cho phép phần mềm phục vụ nhiều người

Để nâng cao khả phục vụ phần mềm, giải pháp đơn giản nâng cấp sở hạ tầng (mua CPU nhanh hơn, nhiều RAM, kết nối mạng tốt hơn) phía người dùng phía hệ thống phục vụ (các máy chủ) Một giải pháp khác phát triển phần mềm dạng phân tán để hoạt động nhiều máy tính máy chủ lúc, từ giúp ta kiểm soát đáp ứng việc phân phối tài nguyên thời gian xử lý hợp lý Tuy nhiên, điều làm gia tăng đáng kể tính phức tạp hệ thống, nên chiến lược thiết kế cần cân nhắc theo hướng đáp ứng khả cao quy mô lớn cho phần mềm

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

 Mục tiêu việc xác định yêu cầu

Ta cần xác định thật xác đầy đủ yêu cầu đặt cho phần mềm xây dựng

 Kết nhận sau giai đoạn xác định yêu cầu

- Danh sách công việc (liên quan đến chức phần mềm) thực máy tính,

- Những mơ tả chi tiết công việc triển khai vận hành giới thực,

2.3.1 Yêu cầu Mô tả yêu cầu

- Yêu cầu (hay yêu cầu phần mềm) công việc (trong phần mềm) muốn thực máy tính liên quan Những công việc phải xuất phát từ thực tế không túy tin học

- Mô tả yêu cầu mô tả đầy đủ thông tin liên quan đến công việc tương ứng Các mô tả dùng làm sở để nghiệm thu đánh giá phần mềm chuyển giao

Các yêu cầu phần mềm (với thông tin liên quan đến công việc tương ứng) cần mô tả thật rõ ràng, cụ thể, đầy đủ xác Việc mô tả sơ sài, mơ hồ yêu cầu phần mềm dẫn đến việc hiểu nhầm chuyên viên tin học (người thực phần mềm) khách hàng (người đặt hàng thực phần mềm), gây nhiều hao tốn, lãng phí cơng sức chi phí

Khi xác định yêu cầu phần mềm, thông tin quan trọng ta cần lưu ý là:

- Tên công việc ứng với yêu cầu: ta cần xác định cụ thể, tránh dùng tên chung chung, mơ hồ Ví dụ: tên công việc “Quản lý độc giả” chung chung, mơ hồ nên ta cần cụ thể “Đăng ký mượn sách”, “Gia hạn thẻ độc giả”, “Trả sách”

- Người phận thực cơng việc: ta cần xác định xác người phận thực công việc máy tính (cịn gọi người dùng) Những người dùng có vai trị cơng việc thực tương tự xếp vào loại người dùng (thông thường loại tương ứng với phận giới thực) Cùng cơng việc có nhiều loại người dùng khác nhau; ngược lại loại người dùng thực nhiều cơng việc khác

- Thời gian Địa điểm thực cơng việc: ta cần xác định xác địa điểm, thời điểm tiến hành công việc Các thông tin có ý nghĩa định số trường hợp đặc thù

 Các quy định cần kiểm tra thực việc ghi nhận thơng tin Ví dụ quy định: cho mượn sách độc giả có thẻ độc giả cịn hạn, số sách mượn chưa đến sách mượn hạn

 Các quy định, cơng thức tính tốn thực việc tính tốn Ví dụ: quy định: ngày trả trễ phạt 1500 đồng/ngày Từ ngày trả trễ thứ 10 trở phạt 5000 đồng/ngày, thu hồi thẻ độc giả tuần

2.3.2 Phân loại yêu cầu

Các yêu cầu phân loại thể sơ đồ sau:

Hình 2.3: Phân loại yêu cầu  Đặc tả chi tiết loại yêu cầu:

(1) Yêu cầu chức năng: danh sách công việc thực máy tính với thông tin mô tả tương ứng

(2) Yêu cầu phi chức năng: yêu cầu liên quan đến chất lượng phần mềm, ràng buộc cách thức thực yêu cầu chức

(3) Yêu cầu chức nghiệp vụ: chức phần mềm tương ứng với cơng việc có thật giới thực

(5) Chức lưu trữ: Tương ứng với công việc ghi chép thông tin sổ sách (kèm theo quy định ghi chép) Ví dụ: Ghi nhận việc cho mượn sách thư viện theo quy định mượn …

(6) Chức tra cứu: tương ứng với cơng việc tìm kiếm, theo dõi hoạt động xem thông tin đối tượng Ví dụ: Tìm xem tình trạng sách

(7) Chức tính tốn: liên quan việc tính tốn (quy định/ cơng thức) Ví dụ: Tính tiền phạt trả sách trễ theo quy định phạt thư viện

(8) Chức kết xuất: tương ứng với việc lập báo cáo (theo biểu mẫu) Ví dụ: Lập báo cáo thống kê số lượt mượn sách theo loại năm

(9) Chức môi trường: định cấu hình thiết bị, thời gian, nhân … Ví dụ: Số nhân công, chọn loại máy in, khổ giấy, niên khóa hành …

(10) Chức mơ phỏng: mơ hoạt động giới thực Ví dụ: Mơ q trình hoạt động chức hay thao tác xử lý

(11) Chức tự động: tự động thơng báo, nhắc nhở người dùng Ví dụ: Nhắc nhở thủ thư gửi giấy báo đòi sách mượn hạn

(12) Chức phân quyền: phân quyền sử dụng cho loại người dùng Ví dụ: Phân quyền cho loại người dùng: (i) Quản trị hệ thống: có quyền sử dụng tất chức năng; (ii) Thủ thư: dùng chức liên quan đến việc cho mượn trả sách; (iii) Độc giả: sử dụng chức tra cứu

(13) Chức lưu: Sao lưu, phục hồi liệu Ví dụ: Sao lưu thông tin học sinh trường, phục hồi lại cần thiết

(14) Tính tiến hóa: yêu cầu liên quan đến việc cho phép người dùng thay đổi lại cách mô tả yêu cầu chức (quy định, quy tắc tính tốn), biểu mẫu dùng phần mềm chuyển giao Điều địi hỏi phải có dự kiến thay đổi thành phần liệu xử lý Ví dụ: Cho thay đổi quy định số sách mượn tối đa, mức phạt trả trễ

nhập hóa phiếu mượn hay trả sách dạng form, dòng nhập thể ô sáng báo lỗi số liệu nhập sai

(16) Tính hiệu quả: yêu cầu liên quan đến thời gian thực chức phần mềm, dung lượng lưu trữ, chi phí sử dụng tài nguyên hệ thống sử dụng tối ưu không gian, thao tác thực nhanh … Ví dụ: Thời gian tra cứu sách, tra cứu độc giả không 10 giây

(17) Tính tương thích: yêu cầu liên quan đến việc chuyển đổi liệu phần mềm xét phần mềm khác, qn hình hệ thống Ví dụ: Cho nhập thông tin sách từ tập tin hay từ thiết bị đọc mã vạch

(18) Tính tái sử dụng: (do chuyên viên tin học đảm trách)

(19) Tính bảo trì: (do chun viên tin học đảm trách) yêu cầu cho phép thay đổi mà khơng làm ảnh hưởng đến phần mềm

Hình 2.4: Quy trình Xây dựng Yêu cầu

2.3.3 Các bước xác định yêu cầu

 Quá trình thực xác định yêu cầu

Gồm bước là:

- Bước 1: Khảo sát trạng, kết nhận báo cáo trạng

- Bước 2: Lập danh sách yêu cầu, kết nhận danh sách yêu cầu thực máy tính

 Đối tượng tham gia xác định yêu cầu

Gồm nhóm người ln phối hợp chặt chẽ để xác định đầy đủ xác yêu cầu là:

- Chuyên viên tin học: người hiểu rõ khả máy tính Họ phải tìm hiểu thật chi tiết cơng việc chuyên gia nhằm tránh hiểu nhầm cho bước phân tích sau

- Chuyên gia: người hiểu rõ cơng việc Họ cần lắng nghe ý kiến chuyên viên tin học để đảm bảo yêu cầu họ thực với chi phí thời gian hợp lý

Sau ta phân tích chi tiết bước quy trình thực

2.3.3.1 Khảo sát trạng

Các chuyên viên tin học tìm hiểu trạng cơng việc chun gia

 Các hình thức thực phổ biến

- Quan sát: theo dõi hoạt động diễn giới thực có liên quan, ghi âm, ghi hình tình mang tính phức tạp, quan trọng, cần xác cao Ví dụ: Quan sát thao tác cho mượn sách thủ thư thư viện,

- Thu thập thông tin, tài liệu: công thức tính tốn, quy định; bảng biểu, mẫu giấy tờ có nhiều liên quan Ví dụ: Phiếu mượn sách thư viện trường đại học

 Quy trình thực

- Tìm hiểu tổng quan giới thực: bao gồm Quy mô hoạt động Các hoạt động mà đơn vị có tham gia

- Tìm hiểu trạng tổ chức (cơ cấu tổ chức): Người tiến hành khảo sát trạng cần hiểu rõ cấu tổ chức phận giới thực, đặc biệt yếu tố: trách nhiệm quyền hạn Việc hiểu rõ cấu tổ chức giúp xác định phận sử dụng phần mềm để lên kế hoạch tiếp tục khảo sát chi tiết phận Cơ cấu tổ chức bao gồm: Đối nội, Đối ngoại, Các chức danh (Ví dụ: nhân viên nhập liệu, thủ thư, …) Ta cần sử dụng sơ đồ để vẽ lại cấu tổ chức - Tìm hiểu trạng nghiệp vụ: Hiện trạng thường xảy ra vị trí cơng

việc Với phận chọn khảo sát chi tiết, người thực khảo sát cần lập danh sách công việc mà phận phụ trách, sau tìm hiểu thơng tin chi tiết cho công việc (thông tin mô tả yêu cầu phần mềm) Việc tìm hiểu dựa ý sau: Thơng tin đầu vào, Q trình xử lý, Thông tin kết xuất

- Tiến hành xếp loại nghiệp vụ vào loại sau nhằm tránh thiếu xót tìm hiểu thơng tin: lưu trữ, tra cứu, tính tốn, tổng hợp/thống kê

2.3.3.2 Lập danh sách yêu cầu

Để có danh sách đầy đủ xác các, q trình lập danh sách yêu cầu cầu theo bước sau:

 Xác định yêu cầu chức nghiệp vụ Cách tiến hành

Chuyên gia đề xuất chuyên viên tin học xem xét lại

Bước tiến hành

- Xác định công việc mà người dùng thực phần mềm theo loại cơng việc sau: Lưu trữ, Tra cứu, Tính toán, Kết xuất

- Lần lượt lập bảng yêu cầu chức nghiệp vụ, bảng quy định/công thức biểu mẫu

Mẫu 1: Bảng yêu cầu chức nghiệp vụ Bộ phận (người thực hiện): ……… Mã số: ………

STT Công việc Loại công việc Quy định/công thức liên quan Biểu mẫu liên quan Ghi

1

Mẫu 2: Bảng Quy định/ Công thức liên quan

STT Mã số Tên Quy định/ Công thức Mô tả chi tiết Ghi

1 QĐ QĐ

Các biểu mẫu mô tả chi tiết sau bảng quy định/Công thức Ví dụ: Xét phần mềm quản lý thư viện

(i) Bảng yêu cần chức

Bộ phận: Thủ thư Mã số: TT

STT Công việc Loại công việc Quy định/Công thức liên quan Biểu mẫu

liên quan Ghi

1 Cho mượn sách Lưu trữ TT_QĐ TT_BM

2 Nhận trả sách Lưu trữ Chỉ nhận lại sách cho mượn TT_BM Tính tiền phạt Tính tốn Mỗi ngày trả trễ phạt:

- 1000 đồng/ngày: từ ngày thứ đến ngày thứ - 3000 đồng/ngày: từ ngày thứ trở

4 Tính tiền đền Tính tốn Tiền đền cho sách bị dựa giá thị trường thời điểm hành

5 Tra cứu sách Tra cứu Việc tìm sách dựa thơng tin: tên sách, tên tác giả, nhà xuất bản, năm xuất

6 Gửi giấy báo đòi sách

Kết xuất Sách mượn hạn ngày tự động gửi giấy báo sách trả tính xong tiền đền sách

(ii) Bảng yêu cầu chức nghiệp vụ

STT Mã số Tên Quy định/ Công thức

Mô tả chi tiết Ghi

1 QĐ Quy định cho mượn sách

Chỉ cho mượn sách khi: - Thẻ độc giả hạn

- Độc giả chưa mượn hết số sách quy định - Độc giả khơng có sách mượn q hạn - Sách khơng có người mượn

Độc giả mượn sách phải gửi lại thẻ độc giả phận bạn đọc, nhận phiếu mượn sách

(TT_BM 1, tìm kiếm mã số sách mượn điền sách cần mượn vào phiếu, xong gửi cho thủ thư)

(iii) Bảng Quy định/ Công thức liên quan

TT_BM 1:

PHIẾU MƯỢN SÁCH

Số thẻ: ……… Số phiếu mượn: ……… Họ tên: ……… Ngày mượn: ………

[ ] Mượn nhà [ ] Đọc chỗ

STT Mã sách Tên sách Tác giả Mã loại

1

Ngày tháng năm

TT_BM 2:

GIẤY BÁO MƯỢN SÁCH QUÁ HẠN

Thân gửi: ……… Địa chỉ: ……… Chúng xin thông báo rằng, anh (chị) mượn thư viện sách sau:

STT Mã sách Tên sách Ngày mượn Đến hôm hạn

1

Vậy thơng báo anh(chị) vui lịng đem sách đến trả Và mang theo số tiền đồng để trả phí sách trễ

Bộ phận: Độc giả Mã số: ĐG STT Công

việc

Loại công việc

Quy định/ Công thức liên quan Biểu mẫu liên quan

Ghi

1 Tìm sách

Tra cứu Việc tìm sách dựa thơng tin: tên sách, tên tác giả, nhà xuất bản, năm xuất

2 Đăng ký mượn sách

Lưu trữ Độc giả phải có thẻ độc giả TT_BM Mọi độc giả có thẻ mượn sách đăng ký mượn sách Tuy nhiên, hệ thống thông báo thẻ mượn sách độc giả hết hạn sử

Bộ phận: Quản lý độc giả Mã số: QLĐG STT Công việc Loại

việc

Quy định/ Công thức liên quan Biểu mẫu liên quan

Ghi

1 Làm thẻ độc giả

Lưu trữ Chỉ cấp thẻ độc giả có độ tuổi từ 18 trở lên có chứng minh thư Lệ phí làm thẻ độc giả 5000 đồng/thẻ

Một số chứng minh thư có thẻ độc giả

QLDGBM1 QLDGBM2

Độc giả có yêu cầu làm thẻ mượn sách nhận phiếu đăng ký để điền thông tin vào (QLDG_BM 1), sau phận quản lý độc giả tiến hành cấp thẻ thu lệ phí theo quy định (QLDG_BM 2)

2 Gia hạn thẻ độc giả

Lưu trữ Gia hạn thẻ theo yêu cầu độc giả thời gian hạn không tháng Sau thời gian tháng, thẻ hết hạn bị hủy Huỷ thẻ độc

giả

Lưu trữ Hủy bỏ thẻ độc giả hạn đăng ký tháng

QLDG_BM 1:

PHIẾU ĐĂNG KÝ LÀM THẺ MƯỢN SÁCH

Họ tên: ……… Năm sinh: ………

Địa thường trú: ……… Nghề nghiệp: ……… Ngày đăng ký: ………

QLDG_BM 2:

THẺ ĐỘC GIẢ

Họ tên: ……… Địa chỉ: ……… Ngày tháng năm: ………

Bộ phận: Quản lý sách Mã số: QLS

STT Công việc Loại Quy định/ Công thức liên quan

Biểu mẫu liên quan

Ghi

1 Nhận sách vào kho sách

Lưu trữ QLSBM Khi có sách nhập về, phận quản lý sách có trách nhiệm rà xét xem số sách có hay chưa, chưa lập thẻ quản lý sách định mã số sách Nếu có gọi lại thẻ cũ để cập nhật bổ sung số lượng Thanh lý sách

cũ

Lưu trữ Các sách hư, không đọc Lập báo cáo

sách cần lý

Kết xuất

QLS_BM

4 Lập báo cáo sách mượn

Kết xuất

QLS_BM 1:

THẺ QUẢN LÝ SÁCH

Tên sách: ………

Tập: ……… Số trang: ………… Số lượng: ……… Năm xuất bản: ……… Mã ngôn ngữ: ……… Ngôn ngữ: ……… Mã nhà xuất bản: ……… Nhà xuất bản: ……… Mã phân loại: ……… Phân loại: ………

Mã tác giả: ……… Tác giả: ……… Mã vị trí: ……… Khu: ……… Kệ: ……… Ngăn: ………

QLS_BM 2:

DANH SÁCH CÁC SÁCH CẦN THANH LÝ

STT Mã sách Tên sách Tác giả Năm sản xuất Ngày nhập kho Tình trạng

2

Ngày lập báo cáo: ……… Người lập: ………

QLS_BM 3:

BÁO CÁO THỐNG KÊ SÁCH MƯỢN

Từ ngày: ……… Đến ngày: ………

STT Mã sách Tên sách Tác giả Số lượt mượn

1

Ngày lập báo cáo: ……… Người lập: ………

 Xác định yêu cầu chức hệ thống yêu cầu chất lượng Cách tiến hành

Chuyên viên tin học chuyên gia đề xuất xem xét yêu cầu

Bước tiến hành

- Bước 1: Xem xét yêu cầu chức hệ thống bản, thông dụng (yêu cầu phát sinh thêm thực cơng việc máy tính): phân quyền, lưu, phục hồi, định cấu hình hệ thống, …

- Bước 2: Xem xét yêu cầu chức hệ thống chuyên biệt (yêu cầu cơng việc mới, tiến hành thực máy tính)

- Bước 3: Xem xét yêu cầu chất lượng theo loại tiêu chuẩn sau: Tiến hóa, Tiện dụng, Hiệu quả, Tương thích

Mẫu 3: Bảng yêu cầu chức hệ thống

STT Nội dung Mô tả chi tiết Ghi

1

Mẫu 4: Bảng yêu cầu chất lượng

STT Nội dung Tiêu chuẩn Mô tả chi tiết Ghi

1

Ví dụ: Xét phần mềm quản lý thư viện (được xây dựng nhằm phục vụ cho phận là: độc giả, thủ thư, ban giám đốc quản trị hệ thống)

(i) Bảng yêu cầu chức hệ thống:

STT Nội dung Mô tả chi tiết Ghi

1 Phân quyền sử dụng

- Người quản trị: phép sử dụng tất chức - Độc giả: tra cứu sách đăng ký mượn sách

- Ban giám đốc: tra cứu sách lập báo cáo thống kê

- Thủ thư: tất chức năng, ngoại trừ chức phân quyền, lưu phục hồi liệu

(ii) Bảng yêu cầu chất lượng hệ thống:

STT Nội dung Tiêu chuẩn Mô tả chi tiết Ghi

1 Cho phép thay đổi quy định tính tiền phạt

Tiến hóa Người dùng phần mềm thay đổi đơn giá phạt biên mức phạt

2 Hình thức tra cứu thật tiện dụng, tự nhiên, trực quan

Dễ sử dụng cho người không chuyên tin học

Tiện dụng Hỗ trợ khả tra cứu gần đúng, tra cứu theo nội dung

3 Cho phép nhập sách từ tập tin Excel có sẵn Các hình có qn chung

Tương thích Có thể nhập trực tiếp danh sách sách có trước tập tin Excel với cấu trúc hợp lý Tốc độ thực việc cho mượn

và tra cứu sách nhanh

Hiệu Tối đa 30 giây cho phiếu mượn sách Hỗ trợ thiết bị đọc mã vạch

2.4 MƠ HÌNH HỐ U CẦU HỆ THỐNG

Các mô tả yêu cầu giai đoạn xác định yêu cầu trình bày chủ yếu thơng tin liên quan đến việc thực nghiệp vụ giới thực chưa thể rõ nét việc thực nghiệp vụ máy tính Mơ tả thông qua văn dễ gây nhầm lẫn khơng trực quan

Ví dụ: Xét u cầu lập phiếu mượn sách, yêu cầu mô tả biểu mẫu quy định lập phiếu chưa thể cách thức lập phiếu máy tính

Khi thực mơ hình hóa u cầu hệ thống, ta cần quan tâm đến:

- Mục tiêu: hiểu chi tiết ngữ cảnh vấn đề cần giải cách trực quan chất thông tin cốt lõi yêu cầu

- Kết quả: thu mơ hình mơ tả tồn hoạt động hệ thống

- Kỹ thuật phân tích: cách tiến hành để thu thập yêu cầu người sử dụng, từ trình bày lại nhu cầu mơ hình chi tiết hóa chúng đặc tả chức đặc tả liệu thơng qua phân tích góc nhìn, đối tượng, liệu thu thập bước

Trước vào tìm hiểu phương pháp biểu diễn mơ hình, ta xem qua số ngun lý phân tích

2.4.1 Các Ngun lý Mơ hình hóa

 Ngun lý Phân tích 1: Mơ hình hóa Miền thơng tin

Ta phải hiểu biểu diễn miền thông tin liên quan:

- Định danh liệu (đối tượng, thực thể), Định nghĩa thuộc tính - Thiết lập mối quan hệ liệu

 Nguyên lý Phân tích 2: Mơ hình hóa Chức

Bản chất phần mềm biến đổi thông tin, nên ta cần: - Định danh chức (biến đối thông tin)

- Xác định tác nhận tạo liệu tác nhân tiêu thụ liệu

 Ngun lý Phân tích 3: Mơ hình hóa Hành vi

Phần mềm (hệ thống) có trạng thái (hành vi), nên ta cần: - Xác định trạng thái hệ thống Ví dụ: giao diện đồ họa

- Xác định liệu làm thay đổi hành vi hệ thống Ví dụ: bàn phím, chuột, cổng thơng tin …

 Nguyên lý Phân tích 4: Phân hoạch Mơ hình

Ta cần làm mịn, phân hoạch, biểu diễn mơ hình mức khác nhau: - Làm mịn mơ hình liệu

- Tạo (mơ hình) phân rã chức

- Biểu diễn hành vi mức chi tiết khác

 Ngun lý Phân tích 5: Tìm hiểu Vấn đề chất

Ta xét chất yêu cầu không quan tâm đến cách cài đặt

2.4.2 Sơ đồ phân rã chức (FDD)

Sơ đồ (FDD, Function Decomposition Diagram) cho ta biểu diễn chức thông qua việc mô tả tính chất đầu vào đầu ra, nhằm: (i) Giúp xác định phạm vi hệ thống, (ii) Giúp phân hoạch hệ thống chức năng, (iii) Giúp tạo tảng cho thiết kế kiến trúc hệ thống

H

ìn

h

.6

:

M

in

h

h

ọ

a

F

D

D

(

n

g

u

ồ

n

[

5

Hình 2.7: Minh hoạ sơ đồ ngữ cảnh gồm chức

2.4.3 Mơ hình mẫu (Prototype)

Khi xác định yêu cầu, nhóm phát triển phần mềm dựa ý tưởng hay yêu cầu khách hàng để đưa thiết kế sơ với hình giao diện, từ tiến hành mơ hay giả lập sơ số chức Đây bước cài đặt mẫu để chuyển cho người sử dụng Bản mẫu nhằm để mô tả cách thức phần mềm hoạt động cách người dùng tương tác với hệ thống giúp người dùng hình dung giao diện ban đầu yêu cầu mà họ đặt Mô hình cần có hỗ trợ kỹ sư phân tích kỹ sư thiết kế phần mềm phối hợp thực

Người sử dụng xem xét mẫu đưa ý kiến đóng góp phản hồi thơng tin đồng ý hay khơng phương án thiết kế mẫu có

- Nếu người sử dụng đồng ý với mẫu đưa người phát triển tiến hành cài đặt thực

- Ngược lại hai phải quay lại giai đoạn xác định yêu cầu

2.4.4 Sơ đồ luồng liệu (Data Flow Diagram, DFD)

Đây mô hình cho phép xem tồn sơ đồ luồng liệu bên hệ thống cách thức liệu xử lý bên hệ thống với nhiều mức chi tiết khác Sơ đồ có nhiều biến thể mở rộng khác (tham khảo thêm tài liệu Phân tích Thiết kế Hệ thống Thơng tin)

Hình 2.8: Minh họa sơ đồ DFD (nguồn [5])

2.4.5 Mơ hình hướng đối tượng

Phương pháp phân tích hướng đối tượng (Object Oriented Analysis, OOA) hình thành thập niên 80 dựa ý tưởng lập trình hướng đối tượng Phương pháp hồn thiện phổ dụng, dựa khái niệm:

- Ðối tượng (Object): gồm liệu thủ tục tác động lên liệu

- Ðóng gói (Encapsulation): khả hạn chế tác động trực tiếp lên liệu đối tượng mà phải thông qua phương pháp trung gian

- Lớp (Class): nhóm đối tượng có chung cấu trúc liệu phương pháp

 Mơ hình nắm bắt u cầu hướng đối tượng UML

Mục đích hoạt động nắm bắt u cầu xây dựng mơ hình hệ thống cách sử dụng ca sử dụng (use case) Các điểm bắt đầu cho hoạt động đa dạng:

- Từ mơ hình nghiệp vụ (business model) cho phần mềm nghiệp vụ - Từ mơ hình lĩnh vực (domain model) cho phần mềm nhúng

- Từ đặc tả yêu cầu hệ thống nhúng tạo nhóm khác dùng phương pháp đặc tả khác (thí dụ hướng cấu trúc)

- Từ điểm nằm điểm xuất phát

Mơ hình ca sử dụng (Use Case Diagram)

Mơ hình gồm thành phần:

- Actor: người/ hệ thống ngoài/ thiết bị tương tác với hệ thống

- Use-case: chức có nghĩa hệ thống cung cấp cho actor (i) Luồng kiện (flow of events), (ii) Các yêu cầu đặc biệt use-case

- Đặc tả kiến trúc

- Các thiết kế mẫu giao diện người dùng

 Mơ hình phân tích hướng đối tượng với UML

Mục đích hoạt động phân tích u cầu xây dựng mơ hình phân tích với đặc điểm sau:

- Dùng ngôn ngữ nhà phát triển để miêu tả mơ hình - Thể gốc nhìn từ bên hệ thống

- Được cấu trúc từ lớp phân tích package phân tích

- Được dùng chủ yếu cho nhà phát triển để hiểu cách tạo hình hệ thống - Loại trừ chi tiết dư thừa, không quán

- Phát họa thực chất bên hệ thống

- Định nghĩa dẫn xuất use-case, dẫn xuất use-case cấp phân tích miêu tả phân tích use-case

Mơ hình phân tích

Mơ hình bao gồm:

- Các lớp (class) phân tích: lớp biên, lớp thực thể, lớp điều khiển

- Các dẫn xuất use case cấp phân tích: lược đồ lớp phân tích, lược đồ tương tác, luồng kiện, yêu cầu đặc biệt use-case

- Các gói (package) phân tích - Đặc tả kiến trúc

Hình 2.11: Minh họa sơ đồ lớp đối tượng mức thiết kế (nguồn [5])

2.4.6 Ví dụ minh họa từ u cầu sang mơ hình hóa

Ví dụ 1: Xét phần mềm quản lý thư viện với yêu cầu: Lập thẻ độc giả, Nhận sách, Cho mượn sách, Trả sách

 Giai đoạn 2: Mơ hình hóa yêu cầu

Sơ đồ luồng liệu cho công việc lập thẻ độc giả

- D1: Thông tin thẻ độc giả cần nhập

- D4: Thông tin thẻ độc giả cần lưu trữ kho - D5: Thông tin thẻ độc giả (trong giới thực)

- Xử lý thẻ độc giả: Kiểm tra tính hợp lệ thẻ trước ghi nhận in

Hình 2.13: Sơ đồ luồng liệu cho công việc lập thẻ độc giả

Sơ đồ luồng liệu cho công việc nhận sách

- D1: Thông tin thẻ sách cần nhập

- D4: Thông tin sách cần lưu trữ kho

- Xử lý nhập sách: Kiểm tra tính hợp lệ sách trước lưu vào kho

Hình 2.14: Sơ đồ luồng liệu cho công việc nhận sách

Sơ đồ luồng liệu cho công việc cho mượn sách

- D1: Thông tin độc giả sách muốn mượn

- D3: Thông tin sử dụng cho việc kiểm tra quy định mượn sách - D4: Thông tin việc mượn sách

Hình 2.15: Sơ đồ luồng liệu cho công việc cho mượn sách

Sơ đồ luồng liệu cho công việc trả sách

- D1: Thông tin độc giả sách trả

- D3: Thông tin sử dụng cho việc kiểm tra quy định trả sách - D4: Thông tin việc trả sách

- Xử lý trả sách: Kiểm tra tính hợp lệ việc trả sách, lưu vào kho

Hình 2.16: Sơ đồ luồng liệu cho cơng việc trả sách

TÓM TẮT

Bài học trình bày khái niệm Cơng nghệ Phần mềm như:

- Q trình Phân tích (Phạm vi dự án, Mở rộng Yêu cầu Nghiệp vụ, Yêu cầu Bảo mật, Yêu cầu Tốc độ, Yêu cầu Vận hành, Khả Mở rộng Yêu cầu, Yêu cầu Sẵn dùng, Yếu tố Con người, Yêu cầu Tích hợp, Thực tiễn Nghiệp vụ tồn tại, Khả Quy mô)

- Xác định Yêu cầu (Mô tả yêu cầu, Phân loại yêu cầu, bước xác định) - Các nguyên lý Mô hình hóa

- Sơ đồ phân rã chức (Function Decomposition Diagram, FDD) - Mơ hình mẫu (Prototype)

- Sơ đồ luồng liệu (Data Flow Diagram, DFD) - Mơ hình hướng đối tượng

BÀI 3: TÁC VỤ THIẾT KẾ PHẦN MỀM

Học xong người học sẽ:

- Hiểu khái niệm thiết kế, kiến trúc phần mềm, phương pháp thiết kế phần mềm

- Vận dụng kỹ thuật thiết kế (top-down, bottom-up …) phương pháp thiết kế (hướng chức năng, hướng đối tượng …) để phát triển kiến trúc phần mềm

3.1 TỔNG QUAN VỀ THIẾT KẾ

Mục tiêu việc thiết kế định hình hệ thống tìm dạng thức phần mềm (kể kiến trúc) để đáp ứng yêu cầu, kể yêu cầu phi chức ràng buộc khác, đặt cho hệ thống Kết thu từ bước phân tích trước (là mơ hình phân tích) thơng tin đầu vào (input) quan trọng cho công tác thiết kế (Xem thêm Phụ lục C – Phần C)

Mục đích quan trọng công tác thiết kế là:

- Hiểu biết sâu sắc yêu cầu phi chức ràng buộc có liên quan tới ngơn ngữ lập trình, mức độ tái sử dụng thành phần, thông tin kỹ thuật chuyên sâu (hệ điều hành, công nghệ phân tán, công nghệ sở liệu, công nghệ giao diện người dùng, công nghệ quản lý giao dịch …)

- Tạo đầu vào thích hợp điểm xuất phát cho hoạt động thực sau thông qua việc nắm bắt yêu cầu hệ thống cụ thể, giao diện lớp

- Nắm bắt sớm giao diện cốt lõi tương tác hệ thống vòng đời phần mềm Điều có ích ta suy luận kiến trúc ta sử dụng giao diện cơng cụ đồng nhóm phát triển khác

- Trực quan hóa suy luận thiết kế hệ thống ký pháp chung

- Tạo trừu tượng hóa liên tục cho việc thực hệ thống, tức cài đặt làm mịn dần thiết kế cách chi tiết hóa mà khơng thay đổi cấu trúc

Mục tiêu học giới thiệu số phương pháp kỹ thuật công tác thiết kế, việc triển khai hệ thống thành nhiều hệ thống hệ thống thành nhiều thành phần quản lý vấn đề liên quan đến cấu trúc nội thành phần hệ thống

3.1.1 Kỹ thuật thiết kế

- Thiết kế đặc tả đến kỹ thuật cốt lõi tiến trình cơng nghệ phần mềm cung cấp xem xét mơ hình tiến trình phần mềm sử dụng - Thiết kế phần mềm bước ba hoạt động kỹ thuật - thiết kế, phát

sinh mã nguồn, thử nghiệm –đó yêu cầu xây dựng phát triển phần mềm

Một điểm mấu chốt độ phức tạp hệ thống phần mềm trừu tượng Có hai phương pháp chính:

3.1.1.1 Thiết kế xuống (Top-down)

- Thiết kế bắt đầu với việc phân tích định nghĩa u cầu khơng nên xem xét việc thực chi tiết

3.1.1.2 Thiết kế từ lên (Bottom–up)

- Ý tưởng tảng: Hiểu phần cứng tầng chế trừu tượng

- Kỹ thuật: Thiết kế từ lên bắt đầu cho máy cụ thể liên tiếp phát triển máy trừu tượng sau máy khác thêm vào thuộc tính cần thiết máy đạt kết mà cung cấp chức người dùng yêu cầu

3.1.1.3 Thiết kế Hệ thống

Trong hệ thống lớn, tiến trình thiết kế bao gồm số yếu tố thiết kế cho hệ thống, chức phân chia thành chức phần mềm phần cứng

Những thuận lợi chức thực phần cứng thành phần phần cứng phân phối thực tốt đơn vị phần cứng Nút thắt hệ thống xác định thay thành phần phần cứng, việc tối ưu phần mềm tốn Ngoài ra, việc cung cấp tốc độ phần cứng có nghĩa thiết kế phần mềm cấu trúc cho khả thích ứng khả xem xét thực thi chức

3.1.1.4 Thiết kế Bản mẫu (Prototype)

Thiết kế mẫu tạo hình giao diện sơ bộ, hay thiết kế phác thảo nháp cho người dùng tham khảo trước vào thiết kế chi tiết cho toàn phần mềm hay cho chức cụ thể Các thiết kế soạn thảo dạng tài liệu kỹ thuật (tài liệu sưu tập, hay tài liệu kỹ thuật) số phần mềm có khả thiết kế nhanh giao diện, MS Visio, MS Visual Basic / C# / C++, MS Front Page / Visual Interdev … Đây bước đệm trước vào thực chi tiết cho chương trình hay mơ-đun …

3.1.1.5 Phân rã Thiết kế

hiện thực hóa phần thiết mức chi tiết đồng thời tác động đến phương pháp thiết kế Các nhóm phương pháp phân rã gồm:

 Phân rã hướng chức

- Ta dựa yêu cầu chức có định nghĩa yêu cầu để phân rã hướng đến tác nhiệm toàn hệ thống

- Ta sử dụng Sơ đồ phân rã chức (FDD) để nêu lên chức thông qua việc mô tả tính chất đầu vào đầu ra, đồng thời:

 Xác định phạm vi hệ thống

 Phân hoạch chức

 Tạo tảng cho thiết kế kiến trúc hệ thống

Hình 3.1: Sơ đồ minh họa tổ chức hệ thống

Ví dụ: Sơ đồ phân rã chức

Hình 3.2: Minh họa sơ đồ chức  Phân rã hướng liệu

Tiến trình thiết kế tập trung khía cạnh hệ thống hướng đến liệu Chiến lược thiết kế hướng đến đối tượng liệu cần thực Việc phân rã hệ thống dựa việc phân tích liệu, bao gồm phần:

Sơ đồ luồng liệu (Data flow diagram - DFD)

Ví dụ: DFD hệ thống bán vé

Hình 3.3: DFD mức

Hình 3.4: DFD mức

Các hướng tiếp cận để tạo lập sơ đồ luồng liệu gồm:

Tiếp cận từ xuống (top-down)

Quá trình thực theo hướng tiếp cần sau:

- Lập sơ đồ luồng liệu cấp (xem xét tất luồng liệu nhập xuất, tất yêu cầu xử lý phần mềm)

- Phân rã sơ đồ luồng liệu cấp thành sơ đồ luồng liệu cấp 1:

 Phân rã xử lý phần mềm thành nhiều xử lý định luồng liệu tương ứng xử lý

 Phân rã luồng liệu nhập xuất thành nhiều luồng liệu định xử lý tương ứng với luồng

- Quá trình kết thúc đạt đến sơ đồ tiếp tục phân rã (sơ đồ lá)

Thông thường sơ đồ tương ứng với công việc cụ thể chuyên gia giới thực

Nhận xét: Cách tiếp cận này:

- Đặc biệt thích hợp với loại phần mềm mà lý hệ thống yêu cầu chưa xác định rõ từ đầu (ví dụ phần mềm hệ thống) Và sử dụng

Hướng tiếp cận từ lên (bottom-up)

Quá trình thực theo hướng tiếp cận sau

- Lập sơ đồ luồng liệu mức cao Các sơ đồ không tiến hành phân rã thành sơ đồ có cấp lớn (thường sơ đồ ứng với công việc cụ thể người dùng giới thực)

- Tích hợp sơ đồ để tạo sơ đồ có cấp nhỏ (thơng thường sơ đồ chọn tích hợp theo tiêu chí cụ thể: người sử dụng, loại yêu cầu …) theo cách:

 Tích hợp xử lý sơ đồ cấp k vào sơ đồ cấp k-1 giữ nguyên luồng liệu sơ đồ cấp k

 Tích hợp đồng thời xử lý luồng liệu sơ đồ cấp k để tạo lập sơ đồ cấp k-1

 Quá trình kết thúc đạt đến sơ đồ cấp Nhận xét: Cách tiếp cận này:

- Thích hợp với phần mềm có hệ thống u cầu chi tiết, cụ thể có quy mơ u cầu (số lượng người dùng, số lượng yêu cầu) thuộc mức trung bình

- Khó thực quy mô yêu cầu lớn chưa thật rõ ràng chi tiết

Hướng tiếp cận phối hợp

Quá trình thực theo hướng tiếp cận sau:

 Lập sơ đồ luồng liệu cấp k theo tiêu chí xác định (sơ đồ cho người dùng hay phận, sơ đồ cho loại yêu cầu …)

 Phân rã sơ đồ cấp k thành nhiều sơ đồ cấp k+1 tiếp tục đạt sơ đồ

Nhận xét: Cách tiếp cận này:

- Thích hợp cho phần mềm có quy mơ u cầu lớn, phức tạp - Được sử dụng thường xuyên thực tế

Lập sơ đồ luồng liệu cho công việc

Do giới hạn nêu trên, việc lập sơ đồ luồng liệu cho toàn phần mềm quy việc lập sơ đồ luồng liệu cho công việc (sau thực đơn giản bước tích hợp để có sơ đồ cấp 0)

Q trình lập sơ đồ luồng liệu cho công việc tiến hành qua bước sau

Bước 1: Xác định liệu nhập

Dữ liệu nhập từ người dùng sử dụng đựơc xác định dựa vào biểu mẫu có liên quan với lưu ý sau:

- Khơng nhập vào liệu tính tốn dựa quy định hay cơng thức có

- Khơng nhập vào liệu lưu trữ trước (qua việc khác)

Dữ liệu nhập từ thiết bị nhập (khác với bàn phím) xem xét có yêu cầu đặc biệt số phần mềm đặc biệt (hệ thống thời gian thực, hệ thống đồ, nhập thông qua sử dụng điện thoại tổng đài điện thoại quản lý khách sạn …)

Dữ liệu nhập (đọc) từ nhớ phụ xác định dựa quy định công thức liên quan với số lưu ý:

- Chỉ đọc liệu thật cần thiết cho việc thực xử lý tương ứng (thông tin nhập chưa đủ để xử lý)

Bước 2: Xác định liệu xuất

Dữ liệu xuất cho người dùng xác định dựa biểu mẫu liên quan với số lưu ý sau:

- Các thơng báo (về việc xử lý có thực hay khơng) ln phải có khơng cần thiết thể sơ đồ (ví dụ thơng báo việc mượn sách không hợp lệ …) - Để tăng tính tiện dụng, tất xử lý (kể xử lý lưu trữ, xử lý tính tốn)

ta phải xuất cho người dùng nhiều thông tin Tuy nhiên vấn đề xem xét thực giai đoạn sau, ý sớm đến vấn đề làm phức tạp sơ đồ dễ phạm sai lầm tính đắn

Các liệu gửi thiết bị xuất (khác với hình) thơng thường máy in Để tăng tính tiện dụng ta tuân theo nguyên tắc sau “Tất liệu xuất hình cho phép người dùng xuất máy in” (có thể với cách trình bày khác) Tuy nhiên vấn đề dời lại xem xét chi tiết giai đoạn thiết kế Các loại thiết bị xuất khác có loại phần mềm đặc biệt yêu cầu tính tương thích

Dữ liệu xuất (ghi) vào nhớ phụ xác định dựa biểu mẫu liên quan với số lưu ý sau:

- Ghi liệu kết tạo lập liệu có bị thay đổi q trình thực xử lý

- Để tăng tính hiệu quả, ta ghi thơng tin bổ sung có liên quan đến yêu cầu khác Tuy nhiên cách tốt vấn đề cần xem xét chi tiết giai đoạn thiết kế

Bước 3: Mơ tả xứ lý

Khi mơ tả q trình xử lý liệu nhập để tạo liệu xuất, ta cần ý:

- Chỉ mô tả cách xử lý mà không cần ý đến cách thực nhập xuất (hình thức nhập, lưu trữ nhớ phụ, câu lệnh đọc, ghi …)

- Chỉ trọng đến tính đắn mà không nên xem xét sớm yêu cầu chất lượng khác

- Mơ tả xác thứ tự nhập/xuất (có thể đổi số trường hợp)

Xây dựng mơ hình thực thể liên kết (Entity Relation Diagram, ERD)

Mơ hình ERD (như ví dụ hình sau) dạng sơ đồ giúp thể đối tượng liệu đặc tả yêu cầu phần mềm, tạo tảng cho việc thiết kế chi tiết sở liệu cho phần mềm (xem thêm tài liệu Phân tích Thiết kế Hệ thống Thơng tin)

Hình 3.5: Biểu diễn ký hiệu sử dụng ERD  Phân rã hướng đối tượng

Tính chất hướng đối tượng hệ thống tập trung chủ yếu thiết kế với thành phần thể thông qua đối tượng khác Theo cách này, hệ thống phần mềm xem xét tập hợp đối tượng thông tin, đối tượng có cấu trúc liệu ẩn thao tác chúng thực cấu trúc Những điểm phân rã hướng đối tượng hướng đến tính đồng liệu thao tác dựa che dấu thống tin dẫn xuất kế thừa

3.1.2 Thiết kế giao diện người dùng

 Chế độ (modes)

Chế độ chương trình trường hợp mà người dùng thực số thao tác giới hạn Kỹ thuật tạo/sử dụng cửa sổ cung cấp dịch vụ có giá trị biểu diễn chế độ chương trình, đồng thời trợ giúp người thực thao tác tương ứng cửa sổ khác thể chế độ chương trình khác

Ví dụ: phần mềm có chế độ chương trình dạng giao diện hội thoại (dialog) MS Calculator, phần mềm đơn tài liệu (single document interface) Notepad, đa tài liệu (multiple document interface) MS Word

 Thực đơn (menu)

Người dùng chọn vào thực đơn trỏ chuột để hiển thị tất lệnh kích hoạt thao tác

Có hai dạng thực đơn:

- Dạng thực đơn bấm mở (Pop-up menu): dạng thiết kế hiệu để xuất vị trí

- Dạng thực đơn bấm thả xuống (Pull-down menu): dạng cho phép cấu trúc tốt việc mở rộng tập lệnh dễ dàng sử dụng

Ta phân loại menu theo tập lệnh thao tác, tập lệnh thao tác với tham số, tập lệnh chuyển đối chế độ người dùng

 Cửa sổ hội thoại (dialog window)

Cửa sổ hội thoại dạng giao diện đơn giản chương trình giúp người dùng tương tác linh hoạt

Khi thiết kế cửa sổ hội thoại, cần đảm bảo tính đồng giao diện người dùng, tránh giải thích dài dịng nên ngắn gọn động cách đặt nhãn Label, Checkbox, Button, List box

 Màu sắc (color)

thường dễ đọc cho khả làm việc hàng ngày, màu chữ trắng xanh khó đọc …

 Âm Thanh (sound)

Âm cách tốt tập trung ý người dùng Chúng phần mềm phù hợp tình xử lý lỗi, kiện không chắn, tạm thời Chúng ta nên tạo âm khác với kiện khác nhau, tránh dùng âm gây ồn

 Tính kiên định

Khi thiết kế giao diện, cần lưu ý:

- Thực đơn lệnh với chức giống nên vị trí giống (thậm chí chương trình khác nhau)

- Phím nóng nên phần mềm cho thực đơn lệnh nên cố định

- Nút lệnh với chức tương tự (trong cửa sổ hội thoại khác nhau) cần giống nhãn vị trí liên hệ

3.1.3 Thiết kế hướng chức

Thiết kế hướng chức có nghĩa tập trung thuật toán để giải vấn đề Chúng ta xem thuật tốn hàm tính tốn mà tính kết từ tham số cho Tại thời điểm bắt đầu giai đoạn thiết kế, thuật toán hộp đen mà nội dung khơng biết Chúng ta cần xây dựng thuật toán để giải tác nhiệm khó phức tạp phần mềm Như vậy, việc thực mơ-đun hóa để phân rã tác nhiệm thành tác nhiệm độc lập nhờ thuật toán xử lý tác nhiệm đó, tạo thành hộp đen Kết chung giải pháp trở thành mạng lưới thuật toán gộp lại

3.1.4 Thiết kế hướng đối tượng

Thiết kế hướng đối tượng tổ chức thiết kế xoay quanh đối tượng mối liên hệ chúng, bao gồm loại:

- Thiết kế giao diện: mô tả giao diện lớp đối tượng trách nhiệm chúng (khái niệm giao diện khái niệm giao diện người dùng hay giao diện đồ họa)

- Thiết kế liệu: Mô tả cách thức tổ chức lưu trữ đối tượng nhớ phụ (chỉ có khơng sử dụng sở liệu hướng đối tượng)

Ngoài ra, khả tái sử dụng đối tượng đóng vai trị quan trọng lập trình hướng đối tượng (đối với chuyên viên tin học phải thực nhiều phần mềm) Với tiếp cận hướng đối tượng, việc tái sử dụng dễ dàng, nhanh chóng, đồng thời tốn chi phí phần mềm lớp phần mềm gồm đối tượng tương tự nhau, cách xây dựng đối tượng tương tự cho phần mềm khác

Hình 3.6: Minh họa dạng kiến trúc phần mềm (nguồn [5])

3.2 KIẾN TRÚC PHẦN MỀM

Kiến trúc phần mềm bao gồm thành phần bản: Giao diện, Xử lý, Dữ liệu Khi thiết kế phần mềm, nhóm thiết kế phải chọn lựa định “vật liệu” dùng thành phần Khi định xong, kết đặc tả dạng vẽ phần mềm, dạng tài liệu kỹ thuật, tạo thành mơ hình phần mềm chứa đầy đủ thông tin gồm:

- Thành phần Giao diện2 với thông tin sau:

 Nội dung hình thức trình bày hình giao tiếp

 Hệ thống thao tác mà người dùng thực hình giao tiếp xử lý tương ứng

- Thành phần Xử lý gồm thông tin sau:

 Hệ thống kiểu liệu sử dụng phần mềm Các kiểu liệu mô tả cách tổ chức lưu trữ liệu nhớ phần mềm

 Hệ thống hàm sử dụng phần mềm Các hàm thể tương ứng tác nhiệm (trên máy tính) xử lý cơng việc giới thực (ví dụ kiểm tra tính hợp lệ việc cho mượn sách, ghi vào sổ việc cho mượn sách …)

- Thành phần Dữ liệu3 bao gồm:

 Các thông tin liên quan đến cách tổ chức lưu trữ liệu (nội dung ghi chép vào sổ sách giới thực) nhớ phụ,

 Dạng lưu trữ liệu sử dụng phần mềm,

 Hệ thống thành phần lưu trữ với quan hệ chúng

Hình 3.7: Minh họa kiến trúc tổng quan phần mềm (nguồn [5])

3.3 PHƯƠNG PHÁP THIẾT KẾ PHẦN MỀM

Tùy thuộc vào quy trình chọn thực phần mềm, việc thiết kế tiến hành theo phương pháp chính:

 Phương pháp trực tiếp

Phương pháp áp dụng thực phần mềm khơng thơng qua giai đoạn phân tích, việc thiết kế nhận kết chuyển giao trực tiếp từ giai đoạn xác định yêu cầu, từ mơ hình phần mềm xây dựng trực tiếp từ yêu cầu Cách tiếp cận khó khăn cho người thực với phần mềm có quy mô lớn (nhiều yêu cầu hay yêu cầu phức tạp …)

Mục tiêu việc thiết kế mô tả thành phần phần mềm (Giao diện, Xử lý, Dữ liệu) tương ứng với yêu cầu phần mềm (yêu cầu chức nghiệp vụ, yêu cầu chức hệ thống, yêu cầu phi chức năng)

 Phương pháp gián tiếp

Phương pháp áp dụng với quy trình có giai đoạn phân tích, việc thiết kế nhận phần kết chuyển giao trực tiếp từ giai đoạn xác định yêu cầu, phần yếu nhận gián tiếp qua giai đoạn phân tích, từ mơ hình phần mềm xây dựng tương ứng theo mơ hình giai đoạn phân tích Cách tiếp cận thuận lợi đa số trường hợp với phần mềm có quy mơ lớn

Với phương pháp gián tiếp, thiết kế phần mềm trình cho phép chuyển từ mơ hình giới thực (kết giai đoạn phân tích) đến mơ hình phần mềm tương ứng Mục tiêu việc mơ tả thành phần phần mềm (Giao diện, Xử lý, Dữ liệu) tương ứng với mơ hình giới thực (mơ hình xử lý, mơ hình liệu)

3.4 VÍ DỤ MINH HOẠ

Ví dụ sau nhằm minh họa trình thiết kế phần mềm sau thực giai đoạn mơ hình hóa u cầu Các kết trọng chủ yếu tính đắn bỏ qua yêu cầu chất lượng khác (tiến hóa, hiệu quả, tiện dụng) Kết thực tế xem xét đầy đủ yêu cầu chất lượng phức tạp khơng thích hợp cho việc minh họa

Ví dụ: Xét phần mềm quản lý thư viện với yêu cầu: Lập thẻ đọc giả, Nhận sách, Cho mượn sách, Trả sách

 Mơ hình hóa u cầu

Hình 3.9: Sơ đồ chức  Thiết kế phần mềm

Hệ thống hình giao diện gồm:

Màn hình

- Nội dung: Thông tin thư viện, Thông tin độc giả thư viện, Thông tin sách thư viện

- Thao tác người dùng: Tra cứu chọn độc giả, Tra cứu chọn sách

Màn hình Lập thẻ

- Nội dung: Thơng tin thẻ độc giả

- Thao tác người dùng: Nhập thông tin thẻ, Yêu cầu lập thẻ

Màn hình Cho mượn sách:

Màn hình Nhận sách:

- Nội dung: Ngày nhận sách, Danh mục sách nhận & thông tin liên quan

- Thao tác người dùng: Nhập thông tin việc cho nhận sách, Yêu cầu cho nhận sách

Màn hình Trả sách:

- Nội dung: Ngày trả sách, Thông tin việc trả sách

- Thao tác người dùng: Nhập thông tin trả sách, Yêu cầu trả sách

 Hệ thống hàm xử lý

- Hàm Lập thẻ: Kiểm tra tính hợp lệ lưu thẻ vào kho

- Hàm Tra cứu độc giả: Tìm thẻ độc giả theo tiêu chuẩn khác phép cập nhật hay xóa thẻ

- Hàm Xóa thẻ: Xóa thẻ kho

- Hàm Nhập sách: Kiểm tra tính hợp lệ sách lưu sách vào kho - Hàm Xóa sách: Xóa sách kho

- Hàm Cho mượn sách: Kiểm tra tính hợp lệ việc cho mượn sách ghi nhận thông tin cho mượn sách vào kho

- Hàm Tra cứu sách: Tìm sách theo tiêu chuẩn khác phép cập nhật hay xóa sách

- Hàm Tính số sách độc giả mượn: Tính số lượng sách độc giả mượn chưa trả

- Hàm Kiểm tra độc giả có sách mượn hạn: Kiểm tra độc giả có sách mượn hạn trả đúng, sai

- Hàm Kiểm tra tình trạng sách: Kiểm tra sách mượn trả sai

- Hàm Tra cứu phiếu cho mượn sách: Tra cứu phiếu mượn sách theo nhiều tiêu chuẩn để cập nhật hay số phiếu cho mượn

- Hàm Trả sách: Ghi nhận việc trả sách kho

- Hàm Tính tiền phạt: Tính tiền phạt độc giả trả sách trễ hạn

 Hệ thống bảng liệu

Hình 3.10: Sơ đồ ERD

- Bảng THU_VIEN: thông tin thư viện - Bảng DOC_GIA: thông tin độc giả - Bảng SACH: thông tin sách

- Bảng MUON_SACH: thơng tin mượn trả sách

TĨM TẮT

Trong này, quan tâm vấn đề liên quan đến phương pháp thiết kế như:

- Kỹ thuật thiết kế:

 Thiết kế từ xuống (Top-down), từ lên (Bottom–up)

 Thiết kế Hệ thống, Thiết kế Bản mẫu (Prototype)

 Phân rã Thiết kế

- Thiết kế giao diện người dùng

- Thiết kế hướng chức thiết kế hướng đối tượng - Kiến trúc phần mềm

- Phương pháp thiết kế phần mềm

BÀI 4: TÁC VỤ THIẾT KẾ & TỔ CHỨC DỮ LIỆU

Học xong người học sẽ:

- Hiểu khái niệm thiết kế, kết thiết kế, trình thiết kế, phương pháp thiết kế liệu

- Biết áp dụng phương pháp thiết kế liệu (trực tiếp hay gián tiếp) vào tác vụ xây dựng sở liệu cho hệ thống phần mềm

4.1 TỔNG QUAN

Mục tiêu việc thiết kế liệu mơ tả cách thức tổ chức lưu trữ liệu phần mềm Có hai dạng lưu trữ mà người thiết kế cần phải cân nhắc lựa chọn là:

- Lưu trữ dạng tập tin: Lưu trữ dạng tập tin thường thích hợp với số phần mềm đặc thù (từ điển, trò chơi …) với đặc điểm chung phần mềm trọng nhiều vào xử lý, hình thức giao diện không trọng nhiều đến việc lưu trữ lại thơng tin tiếp nhận q trình sử dụng phần mềm thơng thường thơng tin tiếp nhận xử lý

- Lưu trữ dạng sở liệu: Trong thực tế, cách tiếp cận thơng dụng đóng vai trò quan trọng việc thiết kế phần mềm cở vừa lớn dạng phân tán …

4.2 KẾT QUẢ CỦA THIẾT KẾ

- Thơng tin tổng qt: Cung cấp góc nhìn tổng quan thành phần lưu trữ, gồm có:

 Danh sách bảng liệu: liên quan đến việc lưu trữ cụ bảng liệu cụ thể

 Danh sách liên kết: liên quan đến việc thực mối liên kết liệu gữa bảng liệu

- Thông tin chi tiết:

 Danh sách thuộc tính thành phần: liên quan đến thông tin cần lưu trữ thành phần

 Danh sách miền giá trị toàn vẹn: liên quan đến quy định tính hợp lệ thơng tin lưu trữ

Có nhiều cách khác việc mô tả thông tin trên, sơ đồ luận lý cách tốt để biểu diễn thông tin tổng quát, bảng thuộc tính miền giá trị dùng để mô tả chi tiết thành phần sơ đồ

Sơ đồ luận lý cho phép thể hệ thống bảng liệu với quan hệ liên kết chúng (gần giống ERD), với ký hiệu dùng sau:

- Bảng: hình chữ nhật

- Liên kết: (xác định một): Mũi tên

Mũi tên hình có ngữ nghĩa: phần tử A xác định phần tử B, ngược lại phần tử B tương ứng với nhiều phần tử A

Ví dụ: Với phần mềm quản lý thư viện có sơ đồ luận lý sau:

Theo sơ đồ việc lưu trữ liệu phần mềm quản lý thư viện tổ chức bảng (DOCGIA, MUONSACH, SACH) với liên kết chúng Tuy nhiên, sơ đồ nhiều cách thức tổ chức lưu trữ liệu (tham khảo thêm tài liệu Phân tích Thiết kế Hệ thống thơng tin)

STT Thuộc tính Kiểu Miền giá trị Ý nghĩa Ghi

1 …

Bảng miền giá trị cho phép mô tả Miền giá trị thuộc tính thành phần hay nhiều thành phần khác

Mã Số Mô tả miền giá trị Thành phần liên quan Ghi

RB1 RB2 …

 Ghi

Bảng thuộc tính cho phép mơ tả chi tiết thành phần cần lưu trữ dùng báo cáo thiết kế liệu phần mềm Tuy nhiên cách mơ tả dài dịng, tài liệu sử dụng dạng trình bày đọng theo dạng lược đồ quan hệ Với dạng trình bày gồm tên bảng thuộc tính kèm, thuộc tính khóa gạch chân

Ví dụ:

DOC_GIA(MDG,HoTen,LoaiDG,NgaySinh, NgayLapThe, DiaChi)

SACH(MSACH, TenSach, TheLoai, NgayNhap, TacGia, NhaXuatBan, NamXuatBan)

MUON(MDG, MSACH, NgayMuon, NgayTra)

4.3 QUÁ TRÌNH THIẾT KẾ

Có cách tiếp cận để thiết kế liệu, là:

 Phương pháp trực tiếp

Từ yêu cầu xác định, ta tạo lập trực tiếp sơ đồ luận lý với bảng thuộc tính bảng miền giá trị Cách tiếp cận khó thực sơ đồ luận lý phức tạp

 Phương pháp gián tiếp

Từ yêu cầu xác định, ta tạo lập mơ hình quan niệm liệu, sau tạo lập sơ đồ luận lý, bảng thuộc tính, bảng miền giá trị đưa vào mơ hình Cách tiếp cận dễ thực mơ hình quan niệm liệu thường đơn giản (chứa thành phần liệu chất phần mềm)

Ứng với yêu cầu phần mềm, việc thiết kế liệu gồm bước lớn:

 Thiết kế với tính đắn: cần đảm bảo đầy đủ xác mặt ngữ nghĩa thông tin liên quan đến công việc yêu cầu Tuy nhiên, thông tin phục vụ cho yêu cầu chất lượng không xét đến bước thiết kế

 Thiết kế với yêu cầu chất lượng: cần đảm bảo tính đắn thỏa mãn thêm yêu cầu chất lượng khác (tiến hóa, tốc độ nhanh, lưu trữ tối ưu) bảo đảm tính đắn cải tiến sơ đồ luận lý

 Thiết kế với yêu cầu hệ thống: cần đảm bảo tính đắn yêu cầu chất lượng khác thỏa mãn thêm yêu cầu hệ thống (phân quyền, cấu hình phần cứng, mơi trường phần mềm …)

Sơ đồ luận lý

Các bảng thuộc tính

DOC_GIA(MDG, MLDG, HoTen, NgaySinh, DiaChi, DienThoai)

SACH(MSACH, MTG, MNXB, MLSACH, MNN, TenSach, NgayMua, SoTrang)

PHIEU_MUON(MPHM, NgayMuon)

CHI_TIET_MUON(MPHM, MSACH, NgayTra)

LOAI_SACH(MLSACH, TenLS, GhiChu)

LOAI_DOC_GIA(MLDG, TenLoaiDocGia, GhiChu)

NHA_XUAT_BAN(MNXB, TenNhaXuatBan, GhiChu)

TAC_GIA(MTG, Ten, GhiChu)

NGON_NGU(MNN, Ten, GhiChu)

Với phương pháp gián tiếp, kết cuối tương tự phương pháp trực tiếp, ta kết trung gian mơ hình quan niệm liệu sau:

Sơ đồ lớp đối tượng với đối tượng Sách, Độc giả quan hệ mượn lớp đối tượng Mơ hình chi tiết thành phần sơ đồ lớp: Xem chi tiết phụ lục B

Ví dụ 2: Xét phần mềm với yêu cầu: Lập thẻ độc giả, Nhận sách, Cho mượn sách, Trả sách

Thiết kế liệu với tính đắn

- Sơ đồ luận lý

- Chi tiết bảng

DOC_GIA(MDG, MLDG, HoTen, NgaySinh, DiaChi, DienThoai)

SACH(MSACH, MTG, MNXB, MLSACH, MNN, TenSach, NgayMua, SoTrang)

Thiết kế liệu với tính tiến hóa

- Sơ đồ luận lý

- Chi tiết bảng:

DOC_GIA(MDG, MLDG, HoTen, NgaySinh, DiaChi, DienThoaiNguoiLapThe, NgayHetHan)

SACH(MSACH, Tensach, MTL, NgayNhap, TacGgia, NamXuatBan, NhaXuatBan)

MUON_SACH(MDG, MSACH, NgayMuon, NgayTra, TienPhat)

THE_LOAI(MTL, TenTheLoai, GhiChu)

LOAI_DG(MLDG, TenLoaiDocGia, GhiChu)

Thiết kế với tính hiệu (truy xuất nhanh)

- Sơ đồ luận lý

Cùng sơ đồ luận lý trên, ta có bảng thuộc tính sau - Bảng thuộc tính

DOC_GIA(MDG, MLDG, HoTen, NgaySinh, DiaChi, DienThoaiNguoiLapThe, NgayHetHan, SoSachMuon, TinhTrangTra)

SACH(MSACH, TenSach, MTL, NgayNhap, TacGia,NamXuatBan, NhaXuatBan, TinhTrangMuon)

MUON_SACH(MDG, MSACH, NgayMuon, NgayTra, TienPhat)

THE_LOAI(MTL, TenTheLoai, GhiChu)

LOAI_DOC_GIA(MLDG, TenLDG, GhiChu)

Thiết kế liệu với tính hiệu (lưu trữ tối ưu)

- Sơ đồ luận lý

- Chi tiết bảng thuộc tính

DOC_GIA(MDG, MLDG, HoTen, NgaySinh, DiaChi, DienThoaiNguoiLapThe, NgayHetHan, SoSachMuon, TinhTrangTra)

SACH(MSACH, Tensach, MTL, NgayNhap, TacGia,NamXuatBan, NhaXuanBan, TinhTrangMuon)

MUON_SACH(MDG, MSACH, NgayMuon, NgayTra, TienPhat)

THE_LOAI(MTL, TenTheLoai, GhiChu)

LOAI_DOC_GIA(MLDG, TenLoaiDocGia, GhiChu)

Thiết kế liệu với yêu cầu phân quyền hệ thống

- Sơ đồ luận lý

- Chi tiết bảng

DOC_GIA(MDG, MLDG, HoTen, NgaySinh, DiaChi, DienThoaiNguoiLapThe, NgayHetHan, SoSachMuon, TinhTrangTra)

SACH(MSACH, Tensach, MTL, NgayNhap, TacGia,NamXuatBan, NhaXuanBan, TinhTrangMuon)

MUON_SACH(MDG, MSACH, NgayMuon, NgayTra, TienPhat)

CHI_TIET_MUON(MMUON, MSACH, NgayTra, TienPhat)

THE_LOAI(MTL, TenTheLoai, GhiChu)

LOAI_DOC_GIA(MLDG, TenLoaiDocGia, GhiChu)

NGUOI_DUNG(MND, HoTen, Ghichu)

CHUC_NANG(MCN, Ten_ChucNang, GhiChu)

QUYEN_HAN(MND, MCN)

4.4 PHƯƠNG PHÁP THIẾT KẾ DỮ LIỆU

4.4.1 Phương pháp Trực tiếp

 Bước

- Lập sơ đồ với thành phần nhất,

- Đánh giá tính đắn so với yêu cầu, chuyển sang bước cần

 Bước

- Tách số thuộc tính để tạo thành phần mới, - Xác định liên kết thành phần,

Cách 1: Dùng thành phần SACH

MSach, Ten, TheLoai, NgayMua, TacGia, NhaXuatBan, NamXuatBan HoTenDocGia, LoaiDocGia, NgayLamThe, NgayMuon, NgayTra

Cách 2: Dùng thành phần SACH, DOC_GIA

- Cách 2.1: Chỉ lưu trữ lần mượn sách cuối

SACH(MSACH, MADG, Ten, TheLoai, NgayMua, TacGia, NhaXuatBan, NamXuatBan, NgayMuon, NgayTra)

DOC_GIA(MDG, HoTen, LoaiDocGia, NgayLamThe)

- Cách 2.2: Chỉ cho phép độc giả mượn tối đa sách

SACH(MSACH, Ten, TheLoai, NgayMua, TacGia, NhaXB, NamXB, NgayMuon, NgayTra)

DOC_GIA(MDG, MSACH, HoTen, LoaiDocGia, NgayLamThe, NgayMuon)

- Cách 3: Dùng thành phần SACH, DOC_GIA, MUON_SACH

SACH(MSACH, Ten, TheLoai, NgayMua, TacGia, NhaXuatBan, NamXuatBan, NgayMuon, NgayTra)

DOC_GIA(MDG, HoTen, LoaiDocGia,NgayLamThe)

MUON_SACH(MMUON, MDG, MSACH, NgayMuon, NgayTra)

4.4.2 Phương pháp Gián tiếp

 Bước

- Lập sơ đồ lớp, Xác định lớp đối tượng, Xác định quan hệ lớp đối tượng lập sơ đồ

 Bước

- Ánh xạ từ sơ đồ lớp vào sơ đồ luận lý, Ánh xạ lớp đối tượng, Ánh xạ quan hệ lớp đối tượng

 Bước

4.4.2.1 Lập Sơ đồ Lớp

Ví dụ: Với phần mềm quản lý thư viện, đối tượng Độc giả, Sách quan hệ chúng quan hệ mượn sách

4.4.2.2 Ánh xạ Sơ đồ Lớp

Ánh xạ lớp đối tượng cho đối tượng sơ đồ lớp tương ứng với thành phần sơ đồ luận lý

Sơ đồ lớp: Sơ đồ luận lý:

4.4.2.3 Ánh xạ Quan hệ

- Quan hệ 1-n: biểu diễn liên kết lớp đối tượng A B (1 A với nhiều B) xác định từ A sang B sơ đồ luận lý

- Quan hệ m-n: biểu diễn liên kết lớp đối tượng A B tương ứng với thành phần C sơ đồ luận lý xác định với A, B

Sơ đồ lớp: Sơ đồ luận lý:

4.4.2.4 Hoàn chỉnh Sơ đồ Luận lý

 Bổ sung thành phần

- Đối tượng phụ: tương ứng với thành phần sơ đồ luận lý

- Các thành phần khác: Xét tính đắn bổ sung thêm cần thiết

 Mơ tả chi tiết thuộc tính thành phần

 Mỗi thành phần ứng với đối tượng (chính phụ) cần thuộc tính khóa riêng,

 Các thành phần cịn lại, tùy theo ý nghĩa sử dụng, có thuộc tính khóa riêng hay dùng tổ hợp thuộc tính khóa thành phần khác

Ví dụ: Các thành phần DOC_GIA, SACH, NHA_XUAT_BAN, TAC_GIA có thuộc tính khóa tương ứng MDG, MSACH, MNXB, MTG Thành phần MUON có khóa MMUON

- Thuộc tính khóa ngoại: Thể liên kết thành phần sơ đồ luận lý: A xác định B A có thuộc tính khố B ( khóa ngoại A)

Ví dụ: Thành phần MUON có khóa ngoại: MDG, MSACH; Thành phần SACH có khố ngoại: MNXB, MTG, MDG

- Các thuộc tính khác: Cần dựa vào yêu cầu lưu trữ, ý thuộc tính sau:

 Định danh: Tên

 Loại: Sự phân loại

 Thời gian: Ngày tháng

 Không gian: vị trí

 Định lượng: độ đo, tính chất … Ví dụ:

- DOC_GIA có thuộc tính khác như: HoTen (định danh) LoaiDG (loại) Ngaysinh (thời gian) Ngayhethan (thời gian) Diachi (khơng gian);

- SACH có thuộc tính khác như: TenSach (định danh) LoaiSach (loại) NgayMua (thời gian) GiaTien (định lượng)

 Thiết kế liệu với tính đắn

Các bước thực hiện:

 Nếu sơ đồ luận lý đáp ứng tiếp tục bước 3,

 Nếu sơ đồ luận lý không đáp ứng bổ sung vào sơ đồ thuộc tính (ưu tiên thành phần (ưu tiên 2) với thuộc tính liên kết tương ứng

- Bước 3: Quay lại bước xem xét đầy đủ yêu cầu dựa ghi chú:

 Với yêu cầu cần xác định rõ cần lưu trữ thơng tin dựa vào luồng liệu đọc/ghi sơ đồ luồng liệu tương ứng) tìm cách bổ sung thuộc tính để lưu trữ thông tin này,

 Chỉ xem xét tính đắn,

 Cần chọn yêu cầu theo thứ tự từ đơn giản đến phức tạp (thông thường yêu cầu tra cứu đơn giản nhất),

 Với yêu cầu phức tạp phải bổ sung vào sơ đồ luận lý nhiều thành phần

Thuộc tính khóa thành phần phải dựa ngữ nghĩa tương ứng giới thực

 Thiết kế liệu yêu cầu chất lượng Mục tiêu

Ta xem xét đánh giá sơ đồ luận lý theo yêu cầu chất lượng tiến hành cập nhật lại sơ đồ để bảo đảm tiêu chuẩn chất lượng Ngồi tính đắn cần ưu tiên hàng đầu, ta cần ý phần mềm, mức độ thỏa mãn tiêu chuẩn chất lượng cịn lại (đặc biệt tính tiến hóa)

Xem xét tính tiến hóa

Ví dụ: LOAI_DOC_GIA (thành phần độc giả): thư viện có loại độc giả ‘A’, ‘B’,’C’ khả có thêm loại độc giả thấp Ngơn ngữ (thành phần SACH): sách thư viện có loại ngơn ngữ ‘Việt’, ‘Anh’, ‘Pháp’ khả thêm sách thuộc ngôn ngữ thấp

Tuy nhiên, ta cần lưu ý khả biến động tập hợp giá trị thuộc tính rời rạc thấp khơng phải khơng có Khi xảy biến động (như thêm loại độc giả, thêm sách thuộc ngôn ngữ mới), ta không chuẩn bị trước thiết kế người dùng khai báo biến động với phần mềm, số chức khơng thực (ví dụ người dùng thêm sách với ngôn ngữ tiếng Hoa)

Như vậy, để chuẩn bị tốt cho biến động sau (nếu có) tập hợp giá trị thuộc tính rời rạc, ta tách thuộc tính thành thành phần sơ đồ luận lý Khi người dùng, q trình sử dụng, hồn tồn cập nhật lại tập hợp giá trị tương ứng với biến động thực tế giới thực

Sơ đồ luận lý tách thuộc tính rời rạc sau:

Xem xét tính hiệu (tốc độ)

Phạm vi xem xét:

- Ta giới hạn xem xét việc tăng tốc độ thực phần mềm cách bổ sung thêm thuộc tính vào bảng dùng lưu trữ thơng tin tính tốn trước (theo quy tắc từ thơng tin gốc lưu trữ) Ví dụ: số sách mượn độc giả

- Các thông tin phải tự động cập nhật có thay đổi thơng tin gốc liên quan Ví dụ: độc giả mượn thêm trả sách

Các bước tiến hành:

- Bước 2: Làm lại bước đến xét đầy đủ yêu cầu theo ghi chú:

 Sau bước, ta phải lập bảng danh sách thuộc tính tính tốn với thông tin liên quan

o Thông tin gốc

o Xử lý tự động cập nhật thông tin gốc (chi tiết xử lý mô tả

trong phần thiết kế xử lý)

 Nếu thông tin gốc thường xuyên bị thay đổi, việc bổ sung thuộc tính tính tốn để tăng tốc độ thực ý nghĩa hiệu ứng xấu

 Việc làm tăng tốc độ truy xuất dẫn đến việc lưu trữ không tối ưu

 Thứ tự xem xét yêu cầu theo thứ tự từ đầu đến cuối (không cần chọn bước thiết kế liệu)

Xem xét tính hiệu (lưu trữ)

Tính hiệu thiết kế liệu xem xét góc độ lưu trữ tối ưu Vấn đề đặt xây dựng sơ đồ luận lý cho bảo đảm lưu trữ đầy đủ thông tin theo yêu cầu với dung lượng lưu trữ nhỏ có Vấn đề đặc biệt quan trọng với phần mềm với hệ thống lưu trữ lớn nhiều phát sinh thông tin cần lưu trữ theo thời gian Khi ta cần đặc biệt quan tâm đến thành phần mà liệu tương ứng phát sinh nhiều theo thời gian Ta tìm cách bố trí lại sơ đồ luận lý cho đảm bảo thông tin mà dung lượng lưu trữ lại

Các bước tiến hành:

- Bước 1: Lập danh sách bảng cần xem xét để tối ưu hóa việc lưu trữ, cụ thể là:

 Xem xét xác định cơng việc có tần suất thực thường xuyên, bổ sung chúng vào danh sách chọn bảng sử dụng tương ứng công việc này,

- Bước 2: Tối ưu hóa việc lưu trữ bảng có khối lượng liệu lưu trữ lớn thông qua việc tối ưu hóa lưu trữ thuộc tính bảng, gồm:

 Xác định thuộc tính mà việc lưu trữ chưa tối ưu ưu tiên xem xét thuộc tính có kiểu chuỗi,

 Tối ưu hóa việc lưu trữ tùy theo trường hợp cụ thể,

 Một trường hợp thông dụng chuỗi có kích thước lớn giá trị sử dụng nhiều lần mẫu tin khác (ví dụ thuộc tính TacGia, NhaXuatBan bảng SACH phần mềm),

 Với trường hợp việc tối ưu hố thực thơng qua việc bổ sung bảng (bảng TAC_GIA, NHA_XUAT_BAN) tổ chức cấu trúc bảng SACH (thay thuộc tính TAC_GIA MTG, thay thuộc tính NHA_XB MNXB) - Bước 3: Tối ưu hóa bảng mà khóa bảng bao gồm nhiều thuộc tính Ta

phân rã bảng thành hai bảng, bảng chứa thuộc tính mà giá trị lặp lại nhiều lần lần thực công việc tương ứng giới thực Bảng cần có khóa riêng (sẽ bảng lại sử dụng để tham chiếu đến) Ta lưu ý là:

 Việc phân rã giúp cho lưu trữ tối ưu, nhiên:

o Tốc độ truy xuất chậm hơn,

o Việc xử lý khó khăn (thuật giải phức tạp hơn)

 Cần cân nhắc trước thực phân rã

 Việc đánh giá khóa riêng cho bảng phân cần kiểm tra thêm số phụ thuộc hàm

Ví dụ: Xét phần mềm quản lý thư viện

TÓM TẮT

Trong này, ta quan tâm đến vấn đề liên quan đến kỹ thuật thiết kế liệu sau:

- Quá trình thiết kế

- Phương pháp thiết kế liệu trực tiếp / gián tiếp: Lập sơ đồ lớp, Ánh xạ sơ đồ lớp, Ánh xạ quan hệ, Hoàn chỉnh sơ đồ luận lý

BÀI 5: TÁC VỤ THIẾT KẾ GIAO DIỆN

Học xong người học nắm nội dung sau:

- Hiểu khái niệm thiết kế giao diện liên quan dạng hình (tra cứu, nhập liệu …)

- Vận dụng phương pháp thiết kế để phác thảo giao diện người dùng hoàn chỉnh có tính phù hợp với hệ thống phần mềm

5.1 TỔNG QUAN

Bài học giới thiệu phương pháp thiết kế giao diện, cơng đoạn quan trọng q trình làm phần mềm cịn cơng đoạn phác thảo mẫu cho phần mềm, từ nhận phản hồi yêu cầu khách hàng chương trình để người thiết kế điều chỉnh theo yêu cầu đề

Tùy theo mục đích, yêu cầu độ phức tạp chương trình, người thiết kế giao diện nên ý:

- Biết thông tin người dùng (họ ai? mục đích người dùng gì? kỹ kinh nghiệm người dùng, nhu cầu họ?),

- Quan sát, ghi nhận hành vi người dùng hệ thống quen thuộc, - Thể hiện:

 Tính sẵn sàng chức giao diện phần mềm,

 Sự tương phản với giao diện chương trình người dùng thay đổi ứng xử,

 Tính tập trung (để giao diện tập trung ý nhiều hơn)

- Sử dụng biểu tượng sử dụng tắt (shortcut) để cung cấp cách thức cụ thể tóm tắt tác vụ làm phần mềm

- Cung cấp trợ giúp độ an toàn cho phần mềm, giao diện đẹp, hạn chế phụ thuộc vào ngữ cảnh người dùng …

5.1.1 Kết thiết kế

 Màn hình giao diện

Màn hình giao diện hình thức giao tiếp người sử dụng phần mềm họ thực cơng việc máy tính Mục tiêu thiết kế giao diện mơ tả hệ thống hình giao diện

 Kết thiết kế giao diện

Kết gồm phần:

- Sơ đồ hình: nhằm mơ tả thơng tin tổng qt hệ thống hình với quan hệ việc chuyển đổi điều khiển chúng

- Mô tả chi tiết hình: nhằm mơ tả chi tiết nội dung, hình thức trình bày thao tác thực hình

Ví dụ: Liệt kê phần sau: hình, ý nghĩa sử dụng Danh sách thao tác thực hiện:

STT Thao tác Ý nghĩa Xử lý liên quan Ghi

Sơ đồ hình

Hình 5.1: Tổ chức hình phần mềm

Ký hiệu:

Màn hình với tên tương ứng

Chuyển điều khiển đến hình khác

Mơ tả hình giao diện

Các thơng tin cần mơ tả hình giao diện bao gồm: Tên hình

Đó tên cơng việc tương ứng muốn thực máy tính Nội dung hình

Nội dung hình bao gồm cấu trúc thành phần bên hình Các thành phần chia làm loại:

- Thành phần liệu: chứa đựng thông tin liên quan đến công việc xét, như:

 Thông tin kết xuất: loại thông tin phần mềm chịu trách nhiệm cung cấp giá trị (ví dụ tổng tiền trả …)

- Thành phần xử lý: bao gồm nút điều khiển cho phép người dùng yêu cầu phần mềm thực xử lý

Ngồi ra, nội dung hình cịn liên quan đến hình thức trình bày, gồm:

- Cách thức bố trí xếp thành phần hình (như vị trí, màu sắc, kích thước …)

- Với hình có biểu mẫu liên quan, ta cần trình bày với biểu mẫu tương ứng, trình bày yêu cầu khách hàng

 Tuy nhiên ta cần lưu ý trường hợp biểu mẫu liên quan kết cuối cần ghi nhận (trước đạt đến kết đó), ta cần thực số cơng việc trung gian khơng có biểu mẫu rõ ràng Khi đó, ta cần bổ sung, sáng tạo hình thức trình bày hình trung gian thể cơng việc trung gian - Với hình khơng có biểu mẫu liên quan, hình thức trình bày hình hồn

tồn sáng tạo thiết kế

Các thao tác thực

Ta cần mô tả hệ thống thao tác mà người dùng thực hình với ý nghĩa chúng Có nhiều loại thao tác khác để cung cấp cho người dùng hình giao diện, quan trọng việc mô tả thao tác người dùng nhấn vào nút điều khiển, nút lệnh kết thúc việc nhập liệu thành phần nhập liệu

5.1.2 Phân loại hình giao diện

Quá trình sử dụng phần mềm bao gồm bước sau: - Chọn công việc muốn thực máy tính,

- Cung cấp thơng tin cần thiết tương ứng với công việc chọn, - Yêu cầu phần mềm thực hiện,

Dựa theo trình trên, hình giao diện chia thành nhiều loại tùy theo ý nghĩa sử dụng

- Màn hình chính: nhằm cho phép người dùng sử dụng chọn lựa công việc mong muốn thực máy tính từ danh sách cơng việc

- Màn hình nhập liệu lưu trữ: nhằm cho phép người dùng thực lưu trữ thông tin phát sinh giới thực

- Màn hình nhập liệu xử lý: nhằm cho phép người sử dụng cung cấp thông tin cần thiết cho việc thực cơng việc

- Màn hình kết quả: nhằm trình bày cho người sử dụng kết việc thực cơng việc

- Màn hình thơng báo: nhằm thông báo, nhắc nhở người sử dụng trình thực cơng việc

- Màn hình tra cứu: nhằm cho phép tìm kiếm thơng tin lưu trữ với tiêu chuẩn tìm kiếm

Một hình giao diện thuộc loại trên, hay tích hợp từ nhiều hình sở thuộc vào loại tùy theo chất công việc liên quan

Trong thực tế, cịn có nhiều hình khác, ta quan tâm loại hình quan trọng thơng dụng nhất: hình chính, hình tra cứu, hình nhập liệu lưu trữ

5.1.3 Quá trình thiết kế

Quy trình chung:

5.1.3.1 Thiết kế giao diện với tính đắn

 Sơ đồ hình

Giả sử cần thực n cơng việc máy tính, sơ đồ hình trường hợp bao gồm n+1 hình sau:

- Một hình cho phép chọn cơng việc

- n hình liên quan trực tiếp đến n công việc muốn thực

 Mô tả chi tiết hình Màn hình Chính

Mục tiêu hình xác định xác nội dung dựa danh sách công việc yêu cầu chọn hình thức trình bày đơn giản

Ví dụ: Phần mềm thư viện

Màn hình

1 Cho mượn sách Lập báo cáo độc giả

2 Nhận trả sách Nhận sách

3 Tìm sách 10 Thanh lý sách

4 Lập báo cáo mượn trả 11 Lập báo cáo sách

5 Lập thẻ độc giả 12 Thay đổi qui đinh tổ chức

6 Gian hạn thẻ độc giả 13 Thay đổi quy định mượn trả

7 Tìm độc giả 14 Thốt

Đây thiết kế cho dạng phần mềm thực thi độc lập (desktop-application máy tính, hay native-application thiết bị di động) hiển thị tất danh sách hình, cịn dạng phần mềm web ta tùy theo quyền hạn sử dụng để đưa hình có hạn chế hình tương tác cho người sử dụng

Màn hình Tra cứu

Màn hình giúp người dùng chọn tiêu chuẩn tra cứu đơn giản (chỉ có mã số) trả kết tìm kiếm đơn giản (có mã số hay khơng)

Màn hình Nhập liệu

Trong hình này, ta xác định xác nội dung dựa biểu mẫu thông tin liên quan đến công việc tương ứng chọn hình thức trình bày đơn giản có (liệt kê nội dung)

Ví dụ: Giao diện cho chức nhập sách, mượn sách (quản lý thư viện)

5.1.3.2 Thiết kế giao diện với tính tiện dụng

 Sơ đồ hình

Ta cần bổ sung vào sơ đồ hình cơng việc trung gian giúp cho việc sử dụng hình cơng việc dễ dàng hơn, tự nhiên

 Mô tả chi tiết hình Màn hình Chính

Màn hình Tra cứu

Trong hình này, ta mở rộng tiêu chuẩn tra cứu (các thông tin khác đối tượng cần tìm) kết tìm kiếm (các thơng tin liên quan đến đối tượng tìm thấy), sau cho phép người dùng xem kết tra cứu nhiều hình thức trình bày khác (các thứ tự khác với danh sách, dạng thể biểu đồ, hình ảnh, …)

Màn hình Nhập liệu

Màn hình giúp ta chọn dạng trình bày biểu mẫu liên quan (nếu có) bổ sung vào thơng tin giúp việc sử dụng thuận tiện Ngược lại, ta cố gắng thiết kế hình thức trình bày tự nhiên có

5.1.4 Các vấn đề khác

Đặc tả giao diện: ta thường thực phác thảo đơn giản qua sơ đồ (gồm dạng vẽ tay hay mô phỏng, gọi mock-up)

Hình 5.2: Mơ giao diện chức (nguồn [5])

Hình 5.3: Minh họa thành phần thiết kế giao diện (nguồn [5])

Hình 5.4: Minh họa giao diện chi tiết máy tính (nguồn [5])

Hình 5.6: Minh họa giao diện dạng web website Amazon

5.1.5 Một số ý chung

 Biểu diễn thông tin

Biểu diễn thông tin có liên quan tới việc hiển thị thơng tin hệ thống tới người sử dụng Thông tin biểu diễn cách trực tiếp chuyển thành nhiều dạng hiển thị khác như: dạng đồ hoạ, âm … Thông tin cần biểu diễn chia thành hai loại:

- Thông tin tĩnh: khởi tạo đầu phiên Nó khơng thay đổi suốt phiên dạng số dạng văn

- Thông tin động: thay đổi phiên sử dụng thay đổi phải người sử dụng quan sát

Nếu cần hiển thị số lượng lớn thơng tin nên trực quan hố liệu Trực quan hố phát mối quan hệ thực thể xu hướng liệu

Ví dụ: thơng tin thời tiết hiển thị dạng biểu đồ, trạng thái mạng điện thoại nên hiển thị nút có liên kết với

 Sử dụng màu

Ta thường sử dụng màu thiết kế giao diện Màu bổ sung thêm chiều cho giao diện giúp cho người sử dụng hiểu cấu trúc thông tin phức tạp Màu sử dụng để đánh dấu kiện ngoại lệ Tuy nhiên, sử dụng màu để thiết kế giao diện gây phản tác dụng Do đó, nên quan tâm tới số hướng dẫn sau:

- Giới hạn số màu sử dụng không nên lạm dụng việc sử dụng màu - Thay đổi màu thay đổi trạng thái hệ thống

- Sử dụng màu để hỗ trợ cho nhiệm vụ mà người sử dụng cố gắng thực

Khi người sử dụng tương tác với hệ thống, xảy lỗi hệ thống phải thông báo cho người sử dụng biết lỗi xảy có chuyện xảy với hệ thống Do đó, thiết kế thơng báo lỗi vơ quan trọng Nếu thơng báo lỗi nghèo nàn làm cho người sử dụng từ chối chấp nhận hệ thống

Vì vậy, thơng báo lỗi nên ngắn gọn, súc tích, thống nhất, có cấu trúc Việc thiết kế thông báo lỗi dựa vào kỹ kinh nghiệm người sử dụng

5.2 THIẾT KẾ MÀN HÌNH

5.2.1 Mơ tả hình

- Ý nghĩa sử dụng: hình cho phép người dùng chọn công việc mà họ muốn thực với phần mềm, thông thường phần mềm có hình

- Nội dung: gồm danh mục cơng việc thực với phần mềm - Hình thức trình bày: bao gồm thành phần như:

 Phím nóng: nhằm cho phép chọn nhanh công việc cần thực người sử dụng chuyên nghiệp, thông thường không sử dụng riêng rẻ mà phải kết hợp với hình thức khác

 Thực đơn: nhóm cơng việc theo chức (ví dụ lưu trữ, kết xuất), dạng sử dụng thông dụng

 Biểu tượng: thể công việc trực quan qua biểu tượng (ký hiệu hay hình ảnh tượng trưng cho cơng việc), tương tự phím nóng thơng dụng thường kết hợp với hình thức khác

 Sơ đồ: nhằm hiển thị trực quan đối tượng chính, thể qua thao tác trực tiếp sơ đồ

 Tích hợp: nhằm sử dụng đồng thời nhiều hình thức, thường hình thức thực đơn ưu tiên trước kết hợp với nhiều hình thức khác

5.2.2 Thiết kế hình dùng thực đơn (menu)

- Tổ chức thực đơn: Thực đơn bao gồm nhiều nhóm chức (tương ứng nhóm cơng việc) nhóm chức bao gồm nhiều chức năng, chức tương ứng với công việc

- Phân loại thực đơn: có loại:

 Thực đơn hướng chức năng: nhóm chức tương ứng với loại yêu cầu Ví dụ: (i) Tổ chức: công việc liên quan đến tổ chức, (ii) Lưu trữ: Các công việc liên quan đến lưu trữ, (iii) Tra cứu: Các công việc liên quan đến tra cứu tìm kiếm

 Thực đơn hướng đối tượng: nhóm chức tương ứng với lớp đối tượng Với sơ đồ lớp gồm n lớp đối tượng, thực đơn bao gồm (n+1) nhóm chức Trong đó:

o Một nhóm chức tương ứng với đối tượng giới thực o n nhóm chức tương ứng n lớp đối tượng

 Thực đơn hướng quy trình: nhóm chức tương ứng với giai đoạn hoạt động giới thực Thông thường giới thực bao gồm giai đoạn sau Tổ chức, Kế hoạch, Tiếp nhận, Hoạt động, Tổng kết

5.2.3 Ví dụ

Hình 5.8: Giao diện thực đơn hay tra cứu (nguồn [5])

5.3 THIẾT KẾ MÀN HÌNH TRA CỨU

5.3.1 Mơ tả hình tra cứu

- Ý nghĩa sử dụng: hình cho phép người dùng tìm kiếm xem thông tin đối tượng

- Nội dung: gồm có

 Tiêu chuẩn tra cứu: gồm thông tin sử dụng cho việc tìm kiếm (thơng thường thuộc tính)

 Kết tra cứu: biết có tìm thấy hay không, với thông tin đối tượng tìm kiếm (các thuộc tính) thơng tin trình hoạt động đối tượng (quan hệ với đối tượng khác)

- Hình thức trình bày: gồm có

 Tiêu chuẩn tra cứu: gồm biểu thức luận lý, cây, tích hợp

 Kết tra cứu: gồm thông báo, danh sách đơn, xâu danh sách, danh sách

- Thao tác người dùng: giúp người dùng nhập giá trị cho tiêu chuẩn tra cứu, yêu cầu bắt đầu tra cứu, xem chi tiết kết tra cứu

Hình 5.9: Minh họa hình tra cứu (nguồn [5])

5.3.2 Thể tiêu chuẩn tra cứu

- Tra cứu với biểu thức luận lý: Tiêu chuẩn thể dạng biểu thức luận lý có dạng sau:

<Biểu thức luận lý>=<biểu thức sở> Phép toán luận lý …

Phép toán AND, OR, NOT, phép so sánh

- Tra cứu với hình thức cây: Tiêu chuẩn thể qua mà nút phận tổ chức giới thực Hình thức thích hợp với giới thực có cấu trúc tổ chức phân cấp

- Tích hợp: Sử dụng đồng thời hai hình thức

5.3.3 Thể kết tra cứu

- Kết tra cứu dùng thông báo: kết tra cứu câu thơng báo cho biết có hay khơng đối tượng cần tìm Đây hình thức đơn giản nhất, có tính tiện dụng thấp Với hình thức người sử dụng khơng biết thêm thơng tin đối tượng tìm thấy Ví dụ việc tìm kiếm sách cho thơng báo “Hệ thống khơng có sách bạn cần tìm.”

phép người dùng biết thêm thông tin đối tượng tìm thấy khơng biết chi tiết hoạt động đối tượng qua quan hệ với đối tượng khác

Hình 5.10: Minh họa giao diện danh sách đơn (nguồn [5])

- Kết tra cứu dùng xâu danh sách: kết tra cứu gồm nhiều danh sách danh sách ds(k) chứa mô tả cho phần tử danh sách ds(k-1) trước Danh sách danh sách đơn hình thức Hình thức cho phép xem thơng tin đối tượng tìm thấy chi tiết hoạt động đối tượng qua quan hệ với đối tượng khác

- Cây danh sách: kết tra cứu mà nút danh sách (tương tự giao diện thư mục cửa sổ phần mềm Windows Explorer), với danh sách tương ứng nút thông tin mô tả chi tiết phần tử chọn danh sách nút cha danh sách danh sách đơn hình thức phía Hình thức cho phép xem trình hoạt động đối tượng với nhiều quan hệ, nhiều loại hoạt động khác

Hình 5.12: Minh họa giao diện danh sách

5.3.4 Thao tác người dùng xử lý phần mềm

- Nhập giá trị cho tiêu chuẩn tra cứu:

 Có thể nhập số tất tiêu chuẩn tra cứu,

 Với tiêu chuẩn thường dùng dùng giá trị định sẵn (loại sách thường tìm …) để tiện dụng cho người dùng

 Trong trình nhập liệu thơng thường, phần mềm khơng xử lý tính toán, chờ nhập giá trị cho tiêu chuẩn tra cứu

- Yêu cầu bắt đầu tra cứu:

 Dựa vào giá trị tiêu chuẩn tra cứu phần mềm tiến hành đọc xuất kết tra cứu tương ứng (xử lý tra cứu)

- Xem xét chi tiết kết tra cứu:

 Chọn đối tượng cần xem chi tiết danh sách kết tra cứu

 Nhập phạm vi thời gian cần quan sát (thường thời gian từ ngày … đến này… đơn vị thời gian cụ thể tháng … năm …)

 Dựa vào đối tượng chọn phạm vi thời gian, phần mềm đọc xuất kết tra cứu chi tiết theo loại hoạt động

- Yêu cầu kết xuất: Có thể bổ sung nút điều khiển tương ứng với việc in ấn ghi lên tập tin kết tra cứu Thơng thường kết tra cứu có nút riêng, dùng chung nút cho kết tra cứu (dựa vào kết hành) Việc kết xuất thông thường qua máy in, nhiên cho phép người dùng xác định lại đích kết xuất (tập tin Excel, trang web,…) tùy theo mục đích sử dụng

5.4 THIẾT KẾ MÀN HÌNH NHẬP LIỆU

5.4.1 Mơ tả hình nhập liệu

- Ý nghĩa sử dụng: Đây hình cho phép người dùng thực cơng việc có liên quan đến ghi chép giới thực

- Nội dung:

 Các thông tin nhập liệu: Với dạng thông tin này, người dùng chịu trách nhiệm nhập trực tiếp giá trị, phần mềm tiến hành kiểm tra tính hợp lệ giá trị nhập dựa vào quy định liên quan

- Hình thức trình bày: số hình thức thơng dụng gồm:

 Danh sách: hình nhập liệu có dạng danh sách giới thực (danh sách thể loại sách, danh sách lớp học)

 Hồ sơ: hình nhập liệu có dạng hồ sơ với nhiều thông tin chi tiết (hồ sơ học sinh, hồ sơ cầu thủ)

 Phiếu: hình nhập liệu có dạng phiếu với nhiều dịng chi tiết (hóa đơn bán hàng, phiếu nhập hàng …)

 Tích hợp: hình sử dụng đồng thời hình thức - Thao tác người dùng:

 Có thao tác hình nhập liệu

o Nút Ghi: để lưu trữ thông tin

o Nút Xóa: để loại bỏ thơng tin lưu trữ

o Nút Tìm: để tìm cập nhật lại thông tin lưu trữ

 Các thao tác khác nhằm tăng tính tiện dụng như:

o Tạo phím nóng: để xác định phím nóng tương ứng giá trị nhập liệu

thường dùng, cho phép tăng tốc độ nhập liệu

o Tạo nút chuyển điều khiển: để giúp chuyển điều khiển hành đến

màn hình liên quan đến việc nhập liệu hành (bổ sung thể loại sách mới, nhà xuất …)

Hình 5.13: Minh họa hình nhập liệu phức hợp (nguồn [5])

5.4.2 Thiết kế hình nhập liệu dạng danh sách

- Sử dụng: Dạng danh sách thích hợp cần nhập liệu bảng danh sách với kích thước nhỏ (danh sách thể loại sách, môn học,…)

- Thành phần nhập liệu:

 Thơng tin nhập liệu: thuộc tính bảng liên quan

 Thơng tin tính tốn: mã số thường tự động phát sinh - Thành phần xử lý:

 Ghi: ghi nhận thay đổi danh sách (thêm mới, sửa đổi)

 Xóa: loại bỏ dịng danh sách

 Thốt: quy hình trước - Các thao tác:

 Người dùng sửa đổi thơng tin dòng thêm dòng (vào cuối danh sách), chọn xóa dịng, lưu vào kho

5.4.3 Thiết kế hình nhập liệu dạng hồ sơ

- Sử dụng: Dạng hồ sơ thích hợp cần nhập liệu hồ sơ đối tượng giới thực (hồ sơ học sinh, đội bóng)

- Thành phần liệu:

 Thơng tin nhập liệu: thuộc tính bảng liên quan

 Thơng tin tính tốn: mã số thường tự động phát sinh - Thành phần xử lý: Thêm, Ghi, Xóa, Tìm, Thốt

- Các thao tác: Người dùng thêm hồ sơ mới, tìm lại hồ sơ lưu trữ, xố hay sửa đổi thơng tin hồ sơ tìm thấy cuối yêu cầu lưu trữ hồ sơ Tuy nhiên để tăng tính tiện dụng, số thao tác chuyển điều khiển bổ sung cho phép di chuyển nhanh đến hình nhập liệu liên quan cần thiết

5.4.4 Thiết kế hình nhập liệu dạng phiếu

- Sử dụng: Dạng phiếu thích hợp cần nhập liệu phiếu ghi nhận thông tin hoạt động đối tượng giới thực

- Thành phần liệu:

 Thông tin nhập liệu: thông tin liên quan đến bảng

 Thơng tin tính tốn: mã số thường tự động phát sinh

TÓM LƯỢC

Bài học nhằm cung cấp kiến thức về: - Phân loại hình giao diện

- Quá trình thiết kế giao diện với tính đắn tiện dụng - Thiết kế hình thơng thường dùng thực đơn (menu) - Thiết kế hình tra cứu

 Mơ tả hình tra cứu

 Thể tiêu chuẩn tra cứu

 Thể kết tra cứu

 Thao tác người dùng xử lý phần mềm - Thiết kế hình nhập liệu

 Mơ tả hình nhập liệu

 Thiết kế hình nhập liệu dạng danh sách

 Thiết kế hình nhập liệu dạng hồ sơ

 Thiết kế hình nhập liệu dạng phiếu

BÀI 6: TÁC VỤ XÂY DỰNG CHƯƠNG TRÌNH

Học xong người học sẽ:

- Hiểu khái niệm tác vụ thực chương trình, mơi trường lập trình, phong cách lập trình, đánh giá chất lượng cơng việc

- Áp dụng tiêu chí (chất lượng, mơ-đun hóa …) vào phong cách lập trình nhằm tối ưu mã nguồn tạo cho hệ thống phần mềm đảm bảo chất lượng mã nguồn nhận

6.1 TỔNG QUAN

Trong trình thiết kế, ta chuẩn bị đầy đủ kiến trúc hệ thống thành phần thiết kế để từ thực hệ thống dạng thành phần mã nguồn, kịch bản, tập tin nhị phân, tập tin thực thi, thư viện, bảng, liệu … Hơn nữa, việc xây dựng chương trình có chất lượng tốt phản ánh định thiết kế (Xem thêm Phụ lục C – Phần D)

Mục tiêu bước xây dựng chương trình bổ sung thêm thành phần giúp kiến trúc hệ thống trở thành khối hoàn chỉnh, cụ thể là:

- Lên kế hoạch tăng cường tích hợp hệ thống (system integration) bước phát triển lặp lại Điều có nghĩa hệ thống cài đặt dãy bước nhỏ liên tiếp quản lý

- Xây dựng lớp thiết kế hệ thống tìm trình thiết kế Đặc biệt, lớp thiết kế xây dựng thành thành phần dạng tập tin mã nguồn

- Kiểm thử đơn vị thành phần, tích hợp chúng biên dịch liên kết chúng lại với thành nhiều thành phần thực thi được, sau kiểm thử tích hợp kiểm thử hệ thống

Việc xây dựng chương trình cần dựa theo tiêu chí sau:

- Cấu trúc chương trình, cấu trúc liệu định nghĩa chọn lựa thiết lập suốt trình thiết kế thủ tục cần tổ chức tốt để dễ dàng nhận biết trình xây dựng chương trình,

- Mức trừu tượng thiết kế lớp đối tượng, mơ-đun, thuật tốn, cấu trúc liệu, kiểu liệu phải linh động trình thực hiện,

- Giao diện thành phần hệ thống phần mềm mô tả rõ ràng thực hiện,

- Quá trình thực kiểm tra độ tin cậy đối tượng thao tác với trình biên dịch (trước kiểm tra chương trình thực sự)

- Đảm bảo đặc trưng phụ thuộc vào việc chọn lựa ngơn ngữ thực kiểu lập trình

Hình 6.1: Minh họa sơ đồ thành phần phần mềm (nguồn [5])

Hình 6.3: Minh họa sơ đồ tác vụ thực (nguồn [5])

6.2 MÔI TRƯỜNG LẬP TRÌNH

Việc chọn lựa “đúng” ngơn ngữ lập trình cho q trình thực hóa vấn đề quan trọng quy trình lập trình Mức lý tưởng, việc thiết kế nên thực độc lập tránh liên quan đến dạng ngôn ngữ dùng thực sau đó, nhằm tạo thiết kế thực ngơn ngữ lập trình Việc chọn ngơn ngữ lập trình phù hợp cho trình xây dựng phần mềm cần tiêu chí sau:

6.2.1 Tiêu chí Chất lượng ngơn ngữ lập trình

Tiêu chí chất lượng thể qua yếu tố sau: Tính mơ-đun hóa

Giá trị tài liệu Cấu trúc liệu

Luồng điều khiển

Tính hiệu Hỗ trợ hộp thoại Yếu tố ngôn ngữ chuyên biệt

Khả tích hợp Tính khả chuyển

6.2.2 Tiêu chí Khả mơ-đun hóa ngơn ngữ lập trình

Khơng có khả mơ-đun hóa việc phân chia cơng việc giai đoạn thực trở nên khơng khả thi Những chương trình đơn trở nên khơng thể quản lý chúng khó bảo trì tài liệu kỹ thuật chúng thực với thời gian biên dịch dài

Nếu ngơn ngữ lập trình hỗ trợ phát thảo chương trình thành phần nhỏ, chúng phải đảm bảo thành phần phải hoạt động với Nếu thủ tục thực thi mô-đun khác, kiểm tra để biết thủ tục có thực tồn có sử dụng xác hay khơng (nghĩa số tham số kiểu liệu xác)

6.2.3 Tiêu chí Giá trị tài liệu kỹ thuật ngôn ngữ lập trình

Tiêu chí nhấn mạnh khả đọc bảo trì chương trình thông qua tài liệu kỹ thuật Điều quan trọng chương trình lớn hay phần mềm mà khách hàng tiếp tục phát triển

Tài liệu kỹ thuật chương trình mang lại giá trị cao kết đạt hành chương trình đó, tài liệu kỹ thuật tham khảo nhiều lần khai thác triệt để nhằm phục vụ trình bảo trì nâng cấp cho chương trình Hơn nữa, nhiều ngơn ngữ mở rộng với nhiều chức chuyên biệt, thiếu tài liệu kỹ thuật, ta khó hiểu tất chi tiết bên chương trình nên dẫn đến việc hiểu hay giải thích sai ý tưởng chúng

6.2.4 Tiêu chí Cấu trúc liệu ngơn ngữ lập trình

Khi thực hóa chương trình, liệu phức tạp cần xử lý hoàn chỉnh Khả (của ngơn ngữ lập trình) sẵn sàng hỗ trợ thực cấu trúc liệu đóng vai trị quan trọng q trình thực chương trình

Ví dụ: họ ngôn ngữ C cho phép khai báo trỏ cấu trúc liệu, điều cho phép cấu trúc liệu phức tạp, phạm vi cấu trúc chúng thay đổi thời điểm thực thi, nhiên không nghiêm ngặt truy xuất (khi so sánh với Java)

phần mềm phức tạp Đối với giải pháp mở rộng uyển chuyển, ngơn ngữ lập trình hướng đối tượng cung cấp tuỳ chọn đặc biệt tốt ngôn ngữ lập trình thơng thường khác

6.2.5 Ví dụ

Ví dụ: Ta xét giai đoạn thực phần mềm quản lý thư viện (các giai đoạn trước minh họa chương trước), cụ thể là:

- Ngơn ngữ lập trình lựa chọn: Visual Basic / C++ / C# hay Java … - Phần mềm sở liệu: MS Access / SQL Server hay Oracle …

- Hệ thống lớp đối tượng: tạo lập lớp đối tượng (THU_VIEN, DOC_GIA, SACH) theo mô tả phần thiết kế môi trường cụ thể đó,

- Hệ thống giao diện: tạo giao diện (màn hình chính, hình lập thẻ, hình cho mượn sách, hình nhận sách, hình trả sách) theo mô tả phần thiết kế môi trường cụ thể đó,

- Hệ thống lưu trữ: tạo lập cấu trúc sở liệu (các bảng THU_VIEN, DOC_GIA, SACH, MUON_SACH) theo mô tả phần thiết kế mơi trường cụ thể

6.3 PHONG CÁCH LẬP TRÌNH

Sau thực kiểm tra chương trình, hệ thống phần mềm sử dụng thời gian dài mà khơng có sửa đổi hay điều chỉnh Điều thực yêu cầu phần mềm cập nhật mở rộng (sau hoàn chỉnh sản phẩm hay suốt trình thực thao tác), ta thường khó phát lỗi hay thiếu sót phát sinh Vì vậy, giai đoạn thực phần mềm chắn phải sửa đổi mở rộng, đòi hỏi lặp lại việc đọc hiểu chương trình nguồn nhiều lần Trong trường hợp lý tưởng, chức thành phần chương trình tìm hiểu dựa chương trình nguồn mà khơng cung cấp thông tin từ tài liệu thiết kế Tuy nhiên, chương trình nguồn dạng tài liệu phản ánh trạng thực thi

cách lập trình người thực Việc viết chương trình để đọc tiến trình sáng tạo Phong cách lập trình người thực ánh hưởng đến khả đọc chương trình ngơn ngữ lập trình sử dụng

Các yếu tố quan trọng phong cách lập trình tốt là:

6.3.1 Tính cấu trúc

Tính chất thể việc:

- Phân rã hệ thống phần mềm dựa độ phức tạp thơng qua mức trừu tượng thành phần, tạo cấu trúc chương trình lớn,

- Hoặc chọn lựa thành phần chương trình phù hợp việc định thuật toán thủ tục con, tạo cấu trúc chương trình nhỏ

6.3.2 Ưu điểm diễn đạt

Quy trình thực hệ thống phần mềm bao gồm việc đặt tên đối tượng mô tả công việc thực thi đối tượng Việc chọn lựa tên đặc biệt quan trọng viết thuật toán

 Một số đề nghị

- Với hệ thống, ta gán tên dựa ngôn ngữ (ví dụ đừng dùng lẫn lộn tiếng Anh tiếng Việt)

- Nếu dùng chữ viết tắt, ta nên sử dụng tên đặt để giúp người đọc chương trình hiểu mà khơng cần giải thích Việc sử dụng từ viết tắt bao gồm ngữ cảnh

- Dùng chữ hoa chữ thường để phân biệt loại định nghĩa khác (như chữ hoa cho kiểu liệu, lớp, mô-đun, chữ thường cho biến), đặt tên dài để dễ hiểu (như CheckInputValue)

- Dùng danh từ cho giá trị, động từ cho hoạt động, thuộc tính cho điều kiện để làm rõ ý nghĩa nhận diện (như width, ReadKey, valid)

- Ghi rõ ràng đầy đủ diễn giải sử dụng, nhằm đóng góp cho khả đọc chương trình Hiệu chỉnh việc ghi chương trình khơng dễ dàng địi hỏi kinh nghiệm, sáng tạo khả diễn đạt thông điệp gọn gàng xác

 Một số luật cho cách tạo ghi

- Mỗi thành phần hệ thống (mô-đun hay lớp) nên bắt đầu với ghi chi tiết để cung cấp cho người đọc thông tin liên quan đến thành phần hệ thống như:

 Thành phần làm gì?

 Thành phần sử dụng ngữ cảnh gì?

 Những phương thức đặc biệt sử dụng

 Ai tác giả thành phần này?

 Thành phần viết nào?

 Những sửa đổi cập nhật thực

- Mỗi thủ tục phương thức nên cung cấp ghi mô tả công việc Điều cần đặc biệt phần mềm cho phần đặc tả giao diện

- Ghi để giải thích ý nghĩa biến

- Gán nhãn ghi cho thành phần có tác nhiệm riêng

- Những khối lệnh khó hiểu (hoặc thành phần hay thủ tục rắc rối) nên mô tả ghi cho người đọc dễ dàng hiểu chúng

- Phản ánh ghi cập nhật thay đổi chương trình liên quan phần khai báo khối lệnh thành phần

6.3.3 Cách thức trình bày bên

Ngoài việc chọn tên tạo ghi chú, khả đọc hệ thống phần mềm phụ thuộc vào cách thức trình bày bên ngồi

Một số luật đề nghị cho hình thức trình bày chương trình gồm:

- Mỗi thành phần chương trình, khai báo (của kiểu liệu, biến …) nên tách biệt phần khối lệnh

- Phần khai báo nên có cấu trúc đồng thứ tự sau: hằng, kiểu liệu, lớp, mô-đun, phương thức thủ tục

- Mô tả giao diện (danh sách tham số cho phương thức thủ tục) nên tách tham số nhập liệu, kết xuất nhập/xuất

- Phần ghi chương trình nguồn nên tách biệt

- Cấu trúc chương trình nên nhấn mạnh phần canh chỉnh lề (sử dụng phím tab cho từ đầu khối lệnh đến khối lệnh theo sau)

6.4 ĐÁNH GIÁ CHẤT LƯỢNG CÔNG VIỆC

6.4.1 Hiện thực tăng cường

Ý tưởng việc thực tăng cường gần với việc kết hợp giai đoạn thiết kế thực tách biệt hai giai đoạn này, mơ hình quy trình phát triển cổ điển đề Phương pháp cho thấy định thiết kế cài đặt có tác động lẫn nhau, ta tách biệt thiết kế rời rạc không đạt mục tiêu tăng cao chất lượng công việc

kiểm tra trước đó) tiến trình thiết kế tiếp tục, kiến trúc chấp nhận tương ứng với kiến thức thu thực thành phần

Hiệu phương pháp phụ thuộc vào việc mở rộng khả tích hợp thành phần hệ thống (được hoàn chỉnh theo chuẩn khác cấp độ khác nhau) toàn hệ thống để thực gần với thực tế Vài thành phần hệ thống (như giao diện người dùng mơ hình liệu) thể dạng khn mẫu, cịn thành phần khác (thư viện có sẵn, hay tồn thực hoàn chỉnh) thể dạng mã nguồn thực thi, thành phần hệ thống khác có sẵn thể đặc tả giao diện Đối với hợp lệ thiết kế hệ thống hành, giao diện người dùng triển khai tương ứng khn mẫu cần kích hoạt

6.4.2 Đánh giá lại thiết kế chương trình (Design and Code Review)

Việc xem lại (review) thiết kế chương trình giúp ta hồn chỉnh chất lượng hiệu cơng việc điều chỉnh thay đổi đơn lẻ trình phát triển phần mềm Trong phần mềm lớn, vấn đề quan trọng nhu cầu xem xét lại yêu cầu, đặc tả, thiết kế, chương trình ta, để từ giúp ta điều chỉnh thiếu sót, luận lý, cấu trúc, tính sáng tỏ Khi chương trình khơng rõ hay mơ hồ xáo trộn, việc thêm ghi hay viết lại cách đơn giản làm cho chương trình dễ đọc dễ hiểu

Mục đích việc xem lại để đảm bảo chương trình tạo đạt chất lượng cao Một số dạng xem lại thao tác kiểm duyệt, duyệt qua, xem xét mục riêng từ thiết dòng lệnh Việc xem lại dùng yêu cầu, thiết kế, hồ sơ tài liệu hay yếu tố sản phẩm

Công việc xem lại cho phép ta quay trở lại việc làm trước chương trình Nhóm phát triển nên đọc lại thiết kế chương trình, nghiên cứu để hiểu chúng tường tận nhằm sửa sai sót luận lý, cấu trúc hay tính rõ ràng, sau viết lại chương trình hay thêm ghi viết lại hoàn chỉnh cho phần nội dung không rõ ràng để làm cho chúng dễ đọc dễ hiểu

6.5 VÍ DỤ MINH HOẠ

Ví dụ: Xét phần mềm hỗ trợ giải tập phương trình đại số với yêu cầu Soạn đề bài, Soạn đáp án, Giải tập, Chấm điểm Các giai đoạn thực quy trình bao gồm:

 Giai đoạn 1: Xác định yêu cầu

- Yêu cầu 1: Soạn đề với mô tả quy tắc Soạn đề

- Yêu cầu 2: Soạn đáp án với mô tả, quy tắc, biểu mẫu Soạn đáp án - Yêu cầu 3: Giải tập với mô tả, quy tắc biểu mẫu Giải tập - Yêu cầu 4: Chấm điểm với mô tả, quy tắc Chấm điểm

 Giai đoạn 2: Sơ đồ luồng công việc cho chức

 Giai đoạn 3: Phân tích yêu cầu chức

 Giai đoạn 4: Thiết kế phần mềm

 Giai đoạn 5: Thực phần mềm

- Hệ thống Lớp đối tượng: tạo lớp đối tượng SACH_BAI_TAP, BAI_TAP theo mô tả thiết kế môi trường cụ thể (VB, C#, Java),

- Hệ thống giao diện: tạo (vẽ) giao diện (màn hình chính, hình soạn đề bài, hình soạn đáp án, hình giải tập, hình chấm điểm) theo mơ tả thiết kế môi trường cụ thể (VB, C#, Java),

- Hệ thống lưu trữ: tạo cấu trúc sở liệu (các bảng SACH_BAI_TAP, BAI_TAP, BAI_GIAI, BUOC_GIAI) theo mô tả phần thiết kế môi trường cụ thể (MS Access / SQL Server, Oracle …)

TÓM TẮT

Bài học cung cấp kiến thức về:

- Môi trường lập trình tiêu chí ngơn ngữ lập trình (Chất lượng, Khả mơ-đun hóa, Giá trị tài liệu kỹ thuật, Cấu trúc liệu)

- Phong cách lập trình vấn đề liên quan (Tính cấu trúc, Ưu điểm diễn đạt, Cách thức trình bày bên ngồi)

- Đánh giá chất lượng cơng việc thông qua việc Hiện thực tăng cường Đánh giá lại thiết kế chương trình

BÀI 7: TÁC VỤ KIỂM THỬ PHẦN MỀM

Học xong người học nắm nội dung sau:

- Hiểu khái niệm kiểm thử, yêu cầu kiểm thử, kỹ thuật kiểm thử, chiến lược kiểm thử & giai đoạn

- Vận dụng phương pháp kiểm thử (hộp đen, hộp trắng …) triển khai chiến lược kiểm thử (đơn vị, chức năng, tích hợp …) để giúp đảm bảo chất lượng sản phẩm phần mềm

7.1 TỔNG QUAN

7.1.1 Lịch sử

Sự tách biệt việc gỡ lỗi (sửa lỗi, debugging) với kiểm thử (testing) lần Glenford J Myers đưa vào năm 1979 Mặc dù quan tâm ông kiểm thử gián đoạn (“một kiểm thử thành cơng tìm lỗi”), điều minh họa mong muốn cộng đồng công nghệ phần mềm để tách biệt hoạt động phát triển bản, giống việc tách phần gỡ lỗi riêng khỏi trình kiểm thử Vào năm 1988, Dave Gelperin William C Hetzel phân loại giai đoạn mục tiêu kiểm thử phần mềm theo trình tự sau:

- Trước 1956: Hướng việc kiểm soát lỗi - 1957-1978: Hướng chứng minh lỗi - 1979-1982: Hướng tính phá hủy lỗi - 1983–1987: Hướng đánh giá lỗi

- 1988–2000: Hướng việc phịng ngừa lỗi

phí tránh việc kiểm thử phần mềm thực tốt Theo đó, kiếm khuyết tìm sớm chi phí để sửa chữa rẻ Bảng cho thấy chi phí sửa chữa khiếm khuyết tùy thuộc vào giai đoạn tìm Ví dụ, vấn đề tìm thấy sau phần mềm thức có chi phí gấp 10-100 lần giải vấn đề từ lúc tiếp nhận yêu cầu Với đời cách thức triển khai thực tiễn liên tục dịch vụ dựa đám mây, chi phí tái triển khai bảo trì làm giảm bớt theo thời gian

Chi phí sửa chữa khiếm khuyết

Thời gian phát Yêu cầu phần mềm

Kiến trúc phần mềm

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

Kiểm thử hệ thống

Sau phát hành

Thời gian sử dụng

Yêu cầu phần

mềm 1× 3× 5–10× 10× 10–100×

Kiến trúc

phần mềm – 1× 10× 15× 25–100×

Xây dựng

phầm mềm – – 1× 10× 10–25×

7.1.2 Giới thiệu

Kiểm thử phần mềm việc tiến hành thí nghiệm để so sánh kết thực tế với lý thuyết nhằm mục đích phát lỗi (Xem thêm Phụ lục C – Phần E)

Bộ thử nghiệm (test cases) liệu dùng để kiểm tra hoạt động chương trình Bộ kiểm thử tốt có khả phát lỗi chương trình Khi tiến hành kiểm thử, ta chứng minh tồn lỗi không chứng minh chương trình khơng có lỗi

Nội dung thử nghiệm gồm: - Tên mô-đun/chức muốn kiểm thử - Dữ liệu vào:

 Dữ liệu chương trình: số, xâu ký tự, tập tin,

 Môi trường thử nghiệm: phần cứng, hệ điều hành,

- Kết mong muốn

 Thông thường: số, xâu ký tự, tập tin …

 Màn hình, thời gian phản hồi - Kết thực tế

Không gian thử nghiệm tập số thử nghiệm Khơng gian nói chung lớn Nếu ta vét cạn khơng gian thử nghiệm chắn qua việc xử lý phép kiểm tra đơn vị chương trình khơng cịn lỗi Tuy nhiên điều khơng khả thi thực tế Do đề cập đến tính đắn phần mềm ta dùng khái niệm độ tin cậy

Phương pháp kiểm thử cách chọn số thử nghiệm để tăng cường độ tin cậy đơn vị cần kiểm tra Nói cách khác, phương pháp kiểm thử cách phân hoạch không gian thử nghiệm thành nhiều miền chọn số liệu thử nghiệm đại diện cho miền Như ta cần tránh trường hợp thử nghiệm rơi vào miền kiểm tra

7.1.3 Mô hình chữ V

Mơ hình (h7.1 h7.2) biểu diễn liên hệ kiểm thử tác vụ khác, đồng thời đại diện cho trình phát triển phần mềm (hay phần cứng) xem mở rộng mơ hình thác nước4

Hình 7.1: Mơ hình chữ V

Hình 7.2: Mơ hình chữ V chi tiết

Mơ hình chữ V thể mối quan hệ giai đoạn vòng đời phát triển giai đoạn liên quan thử nghiệm Các trục ngang dọc đại diện cho thời gian hay hoàn thiện dự án (từ trái qua phải) mức độ trừu tượng (thô tầng trừu tượng cao nhất), tương ứng Mơ hình chữ V hướng đến:

- Thực Xác nhận (Verification) với tác vụ phân tích yêu cầu, thiết kế hệ thống (kiến trúc, mô-đun …) mức cao mức chi tiết

- Kiểm tra Hợp lệ (Validation) với tác vụ kiểm thử (đơn vị, tương tác, hệ thống, chấp nhận, triển khai)

7.2 YÊU CẦU ĐỐI VỚI KIỂM THỬ

Ta cần ý yêu cầu sau đây: - Tính lặp lại:

 Kiểm thử phải lặp lại (kiểm tra lỗi sửa hay chưa)

 Dữ liệu/trạng thái phải mô tả

7.3 CÁC KỸ THUẬT KIỂM THỬ

7.3.1 Phương pháp Hộp đen (Black box)

Phương pháp kiểm thử dạng kiểm thử chức (functional test) dựa đặc tả chức Do đó, ta tâm đến phát sai sót chức mà không quan tâm đến cách thực cụ thể Với phương pháp ta có khả phát sai sót, thiếu sót mặt chức năng; sai sót giao diện mơ-đun, kiểm tra tính hiệu quả; phát lỗi khởi tạo, lỗi kết thúc

Do kiểm thử trường hợp thực tế, ta chia nhỏ không gian thử nghiệm dựa vào giá trị nhập xuất đơn vị cần kiểm tra Ứng với vùng liệu, ta thiết kế thử nghiệm tương ứng đặc biệt thử nghiệm giá trị biên vùng liệu

Để kiểm chứng chương trình giải phương trình bậc theo phương pháp hộp đen, ta phân chia không gian thử nghiệm thành vùng “Vơ nghiệm”, “Có nghiệm kép” hay “Có nghiệm riêng biệt”

Sau kiểm tra thử với thử nghiệm thiết kế, ta cần mở rộng thử nghiệm cho trường hợp đặc biệt như: biên số nguyên máy tính (32767, -32768), số không, số âm, số thập phân, liệu sai kiểu, liệu ngẫu nhiên

7.3.2 Phương pháp Hộp trắng (White box)

Phương pháp hướng đến việc kiểm thử cấu trúc ta chia không gian thử nghiệm dựa vào cấu trúc đơn vị cần kiểm tra

Hình 7.3: Cấu trúc hộp trắng

Trong đó:

- Kiểm tra liệu cục để đảm bảo liệu lưu trữ đơn vị toàn vẹn suốt q trình thuật giải thực Ví dụ: nhập liệu sai, tên biến sai, kiểu liệu không quán, ràng buộc hay ngoại lệ

- Kiểm tra điều kiện biên câu lệnh điều kiện vịng lặp để đảm bảo đơn vị ln chạy biên

- Kiểm tra để đảm bảo đường thực phải qua lần Con đường thực đơn vị chương trình dãy có thứ tự câu lệnh bên đơn vị thực kích hoạt đơn vị Ví dụ: Con đường thực p1 p2 sau:

Thủ tục Thủ tục Khi đó, ta có đường thực sau: Thủ tục 1: Lệnh  Lệnh  Lệnh  Lệnh

Thủ tục 2: Lệnh  Lệnh  Lệnh Lệnh 

Lệnh  Lệnh

Lệnh Lệnh Lệnh Lệnh

Lệnh

Nếu đk Lệnh

Ngược lại Lệnh Lệnh

7.3.3 Phương pháp Hộp xám (Grey box)

Phương pháp liên quan đến hiểu biết cấu trúc liệu bên thuật toán cho mục đích kiểm thử thiết kế Khi thực kiểm thử với người dùng mức độ hộp đen, nhóm kiểm tra khơng thiết phải truy cập vào mã nguồn phần mềm Ta thao tác với liệu đầu vào định dạng đầu không xác định (như hộp xám), đầu vào đầu rõ ràng bên hộp đen mà chúng hệ thống gọi trình kiểm thử Sự phân biệt đặc biệt quan trọng tiến hành kiểm thử tích hợp hai mơ-đun viết mã hai nhóm phát triển khác nhau, có giao diện bộc lộ để kiểm thử

Tuy nhiên, với kiểm thử có yêu cầu thay kho lưu trữ liệu bên hệ thống (back-end) – sở liệu hay tập tin đăng nhập – không xác định hộp xám, người dùng thay đổi kho lưu trữ liệu sản phẩm hoạt động bình thường

Khi biết khái niệm cách thức phần mềm hoạt động nào, nhóm kiểm tra thực kiểm thử phần mềm từ bên tốt so với bên ngồi Thơng thường, nhóm kiểm thử theo phương pháp Hộp Xám phép thiết lập môi trường kiểm thử bị cô lập với hoạt động liên quan sở liệu Các kiểm thử quan sát trạng thái sản phẩm kiểm thử (sau thực hành động định giống việc thực câu lệnh SQL sở liệu) thực truy vấn để đảm bảo thay đổi dự kiến phản ánh Kiểm thử hộp xám thực kịch kiểm thử thông minh, dựa thông tin hạn chế Điều đặc biệt áp dụng cho kiểu xử lý liệu, kể xử lý ngoại lệ

7.4 CHIẾN LƯỢC & CÁC GIAI ĐOẠN

Với dự án phần mềm lớn, người tham gia chia thành:

- Nhóm thứ nhất: gồm người tham gia dự án phát triển phần mềm Nhóm chịu trách nhiệm kiểm tra đơn vị chương trình để chắn chúng thực theo thiết kế

- Nhóm thứ hai: gồm chuyên gia tin học độc lập không thuộc nhóm thứ Nhóm có nhiệm vụ phát lỗi nhóm thứ chủ quan cịn để lại

Ví dụ minh họa kiểm thử phần mềm:

Hình 7.5: Phân tích kết kiểm thử phần mềm (nguồn [5])

Hình 7.6: Minh họa kịch ca kiểm thử tự động (nguồn [5])

Việc kiểm thử chương trình tiến hành qua giai đoạn sau:

7.4.1 Kiểm thử Đơn vị (Unit Test)

Vì đơn vị (unit) kiểm tra thường đoạn chương trình hay thủ tục khơng phải chương trình đầy đủ, đơn vị gọi thực thi đơn vị khác (hoặc gọi đến đơn vị khác để thực thi), nên dù chương trình hồn tất đầy đủ đơn vị, ta không nên giả thuyết tồn tính đắn đơn vị khác mà phải xây dựng mô-đun giả lập đơn vị gọi (đặt tên driver) đơn vị bị gọi (đặt tên stub):

- Driver đóng vai trị chương trình nhập số thử nghiệm gởi chúng đến đơn vị cần kiểm tra đồng thời nhận kết trả đơn vị cần kiểm tra

- Stub chương trình giả lập thay đơn vị gọi đơn vị cần kiểm tra Stub thực thao tác xử lý liệu đơn giản in ấn, kiểm tra liệu nhập trả kết

Hình 7.8: Mơ chương trình giả lập

7.4.2 Kiểm thử Chức (Functional Test)

Như trình bày phần “Phương pháp Hộp đen”, giai đoạn thực việc kiểm tra khả thực thi chức có đáp ứng đầy đủ yêu cầu (đã nêu đặc tả) chức hay khơng Vì thế, ta tập trung phát sai sót chức mà không quan tâm đến cách thực cụ thể Với phương pháp ta có khả phát sai sót, thiếu sót mặt chức năng; sai sót giao diện mơ-đun, kiểm tra tính hiệu quả; phát lỗi khởi tạo, lỗi kết thúc

7.4.3 Kiểm thử Tích hợp (Integration Test)

Giai đoạn tiến hành sau hồn tất cơng việc kiểm thử chức cho mơ-đun riêng lẻ cách tích hợp mơ-đun lại với Mục đích giai đoạn kiểm tra giao diện đơn vị kết hợp hoạt động chúng, kiểm tra tính đắn so với đặc tả, kiểm tra tính hiệu quả, với phương pháp thực chủ yếu sử dụng kiểm tra chức dựa chiến lược từ xuống, từ lên

 Hướng xử lý Trên Xuống (Top-Down)

Thuật giải hướng tiếp cận gồm bước sau:

- Lần lượt thay stub mô-đun thực sự, - Tiến hành kiểm tra tính đắn,

- Một tập hợp thử nghiệm hoàn tất hết stub,

- Kiểm tra lùi tiến hành để đảm bảo không phát sinh lỗi mới,

Hình 7.9: Phương pháp kiểm thử từ xuống

- Ưu điểm:

 Kiểm thử xuống kết hợp với phát triển xuống giúp phát sớm lỗi thiết kế làm giảm giá thành sửa đổi

 Nhanh chóng có phiên thực với chức Có thể thẩm định tính dùng sản phẩm sớm

- Nhược điểm: nhiều mơ-đun cấp thấp khó mơ phỏng: thao tác với cấu trúc liệu phức tạp, kết trả phức tạp…

 Hướng xử lý Dưới Lên (Bottom-Up)

Ta kiểm tra mô-đun (cấp thấp nhất) trước, ta khơng cần phải viết stub Thuật giải hướng là:

- Các mơ-đun cấp thấp nhóm thành nhóm (thực chức năng), - Viết driver điều khiển tham số nhập xuất,

Hình 7.10: Phương pháp kiểm thử từ lên

- Ưu điểm: Tránh xây dựng mô-đun tạm thời phức tạp, tránh sinh kết nhân tạo, thuận tiện cho phát triển mô-đun để dùng lại

- Nhược điểm: Chậm phát lỗi kiến trúc, chậm có phiên thực

7.4.4 Kiểm thử Hệ thống (System Test)

Đến giai đoạn này, công việc kiểm thử tiến hành với nhìn nhận phần mềm yếu tố hệ thống thông tin phức tạp hồn chỉnh

Cơng việc kiểm thử nhằm kiểm tra khả phục hồi sau lỗi, độ an toàn, hiệu giới hạn phần mềm

7.4.5 Kiểm thử Chấp nhận (Acceptance Test)

7.4.6 Kiểm thử beta

Đây giai đoạn mở rộng alpha testing Khi đó, việc kiểm thử thực số lượng lớn người sử dụng Công việc kiểm thử tiến hành cách ngẫu nhiên mà khơng có hướng dẫn nhà phát triển Các lỗi phát thông báo lại cho nhà phát triển

7.4.7 Một số cơng việc khác

Ngồi giai đoạn kiểm thử chủ chốt nêu trên, số cơng việc khác q trình kiểm thử bao gồm:

- Báo cáo kết kiểm thử: Sau hồn tất kiểm thử, nhóm kiểm tra tạo số liệu báo cáo cuối nỗ lực kiểm thử họ cho biết phần mềm có sẵn sàng để phát hành hay không

- Phân tích kết kiểm thử phân tích thiếu sót: thực nhóm phát triển kết hợp với khách hàng để đưa định xem thiếu sót cần phải chuyển giao, cố định từ bỏ (tức tìm phần mềm hoạt động xác) giải sau

- Kiểm tra lại khiếm khuyết: Khi khiếm khuyết xử lý đội ngũ phát triển, phải kiểm tra lại nhóm kiểm thử

- Kiểm thử hồi quy: ta thường xây dựng chương trình kiểm thử nhỏ tập hợp kiểm tra cho tích hợp mới, sửa chữa cố định phần mềm, để đảm bảo cung cấp khơng phá hủy điều tồn phần mềm cịn hoạt động cách xác

- Kiểm thử đóng gói: phép thử thỏa mãn tiêu truy xuất thu kết quan như: học kinh nghiệm, kết quả, ghi, tài liệu liên quan lưu trữ sử dụng tài liệu tham khảo cho dự án tương lai

mềm Tuy kiểm thử tự động chép tất thứ người làm hữu ích cho việc kiểm thử hồi quy Tuy nhiên, địi hỏi phải có kịch phát triển tốt để tiến hành kiểm thử

- Kiểm thử chức phi chức năng:

 Kiểm thử chức nhằm trả lời câu hỏi “người dùng có hay khơng làm với tính cụ thể này” (xem Phương pháp Hộp đen)

 Kiểm thử phi chức đề cập đến khía cạnh phần mềm không liên quan đến chức cụ thể hành động người dùng, chẳng hạn khả mở rộng hiệu suất khác, hành vi hạn chế bảo mật định Việc kiểm thử xác định điểm cuộn mà khả mở rộng thực điểm cực trị hoạt động không ổn định Những yêu cầu phi chức thường phản ánh chất lượng sản phẩm, đặc biệt bối cảnh quan điểm phù hợp người sử dụng

- Kiểm thử phá hủy: cố gắng làm hỏng phần mềm hệ thống Nó xác minh phần mềm có chức nhận đầu vào khơng hợp lệ khơng mong muốn, tạo vững mạnh xác nhận đầu vào thói quen quản lý lỗi Chèn lỗi phần mềm dạng mờ nhạt ví dụ kiểm thử thất bại Các cơng cụ kiểm thử phi chức thương mại liên kết từ trang chèn lỗi phần mềm mà có sẵn vơ số mã nguồn mở cơng cụ miễn phí để thực kiểm thử phá hủy phần mềm

- Kiểm thử hiệu suất phần mềm: thường chạy để xác định hệ thống hay hệ thống thực độ nhạy tính ổn định theo khối lượng cơng việc cụ thể Nó dùng để điều tra, đánh giá, xác nhận xác minh thuộc tính chất lượng khác hệ thống, chẳng hạn khả mở rộng, độ tin cậy sử dụng tài nguyên Dạng kiểm thử bao gồm số dạng như:

rộng phần mềm Các hoạt động kiểm thử lượng tải có liên quan thực hoạt động phi chức thường gọi kiểm thử sức chịu đựng

 Kiểm tra khối lượng cách để kiểm tra chức phần mềm số thành phần (ví dụ tập tin sở liệu) tăng triệt để kích thước Kiểm thử độ căng cách để kiểm tra độ bền đột xuất gặp theo khối lượng cơng việc

 Kiểm thử tính ổn định (thường tham chiến lượng tải kiểm thử độ bền) giúp kiểm tra xem phần mềm hoạt động tốt liên tục chu kỳ chấp nhận Có quy ước mục tiêu cụ thể kiểm thử hiệu suất là: Các thuật ngữ lượng tải, kiểm thử hiệu suất, kiểm thử tính mở rộng kiểm thử khối lượng, thường sử dụng thay cho

 Hệ thống phần mềm thời gian thực có ràng buộc xác thời gian Để kiểm thử ràng buộc thời gian đáp ứng người ta dùng phương pháp kiểm thử thời gian thực

- Kiểm thử tính khả dụng: cần thiết để kiểm tra xem giao diện có tiện dụng dễ hiểu với người dùng khơng, liên quan trực chủ yếu đến lực sử dụng phần mềm

- Kiểm thử khả tiếp cận: ý việc tuân thủ tiêu chuẩn sau:

 Đạo luật bất khả thi Mỹ năm 1990

 Mục 508 sửa đổi đạo luật Phục hồi năm 1973

 Sáng kiến tiếp cận Web (WAI) W3C

- Kiểm thử bảo mật: cần thiết việc xử lý liệu mật ngăn chặn hacker xâm nhập hệ thống

7.5 VÍ DỤ MINH HOẠ

Ví dụ: Xét phần mềm quản lý thư viện giai đoạn kiểm thử, giai đoạn thực trước trình bày trước

 Giai đoạn 6: Kiểm chứng phần mềm hướng đối tượng

 Chuẩn bị liệu thử nghiệm: Nhập liệu thử nghiệm cho bảng THU_VIEN, SACH, DOC_GIA, MUON_SACH

- Kiểm tra:

 Kiểm tra lớp đối tượng:

o Kiểm tra lớp THU_VIEN (Tra cứu độc giả, Tra cứu sách) o Kiểm tra lớp DOC_GIA (Lập thẻ, cho mượn sách)

o Kiểm trả lớp SACH (Nhận sách, Trả sách)

 Kiểm tra phối hợp lớp đối tượng

o Kiểm tra phối hợp lớp THU_VIEN lớp DOC_GIA (Lập thẻ sau

tra cứu độc giả)

o Kiểm tra phối hợp lớp THU_VIEN lớp SACH (Nhận sách sau tra

cứu sách)

o Kiểm tra phối hợp lớp DOC_GIA lớp SACH (Lập thẻ, Nhận sách, Cho

mượn sách Tra sách)

o Kiểm tra phối hợp lớp THU_VIEN, DOC_GIA lớp SACH

TÓM TẮT

Trong học này, giới thiệu kiến thức về: - Mơ hình chữ V

- Các yêu cầu kiểm thử - Các kỹ thuật kiểm thử

 Phương pháp Hộp đen (Kiểm thử chức năng)

 Phương pháp Hộp trắng (Kiểm thử cấu trúc) - Chiến lược kiểm thử & giai đoạn

 Kiểm thử Đơn vị (Unit Test)

 Kiểm thử Chức (Functional Test)

 Kiểm thử Tích hợp (Integration Test)

 Kiểm thử Hệ thống (System Test)

 Kiểm thử Chấp nhận (Acceptance Test)

 Kiểm thử beta

BÀI 8: TÁC VỤ BẢO TRÌ PHẦN MỀM

Học xong người học sẽ:

- Hiểu tầm quan trọng bảo trì phần mềm, kế hoạch bảo trì phần mềm, quy trình bảo trì phần mềm

- Biết xây dựng kế hoạch quy trình bảo trì hệ thống phần mềm

8.1 GIỚI THIỆU

Bảo trì phần mềm5 tác vụ sửa đổi sản phẩm phần mềm sau xây dựng, nhằm sửa chữa lỗi hay thiếu sót để cải thiện hiệu suất thuộc tính khác phần mềm Như hình minh họa sau đây, hệ thống bán vé máy bay hoạt động tốt giai đoạn 1990-2000 công nghệ cũ vận hành tảng công nghệ mới, dẫn đến vấn đề cấp thiết phải bảo trì hay nâng cấp

Hình 8.1: Hệ thống bán vé máy bay hoạt động công nghệ cũ

Trong thực tế, bảo trì phần mềm nhận định liên quan đến việc sửa chữa khiếm khuyết phần mềm Một nghiên cứu cho biết 80% công sức tác vụ dùng cho hoạt động khác việc khắc phục lỗi, người dùng thường gửi báo cáo vấn đề mà thực tế cải tiến chức cho hệ thống mà sửa lỗi Nhiều nghiên cứu gần đưa tỷ lệ lỗi cố định gần gũi với 21%

Việc bảo trì phần mềm cải tiến hệ thống nhóm nghiên cứu Meir M Lehman giải lần năm 1969 dẫn đến việc xây dựng Luật Lehman vào năm 1997 Trong nghiên cứu đó, phát (i) tác vụ bảo trì phần mềm thực việc phát triển tiến hóa, (ii) định bảo trì hỗ trợ hiểu biết xảy với hệ thống (và phần mềm) theo thời gian, đồng thời cho thấy hệ thống tiếp tục phát triển theo thời gian ngày phức tạp (trừ số hành động mã xếp thực để giảm phức tạp)

Trong bảo trì phần mềm, hai vấn đề quan trọng là:

- Vấn đề quản lý: liên kết với ưu tiên khách hàng, nhân viên, tổ chức thực bảo trì, ước tính chi phí

Bảo trì phần mềm hoạt động rộng, từ việc sửa lỗi, cải tiến chức đến loại bỏ chức lỗi thời tối ưu hóa Thực tế cho thấy, thay đổi chức hay yêu cầu phần mềm tránh khỏi, nên chế xử lý cần phát triển để đánh giá, kiểm sốt việc sửa đổi Vì thế, công việc thực để thay đổi phần mềm sau vào hoạt động xem công việc bảo trì Mục đích để bảo tồn giá trị phần mềm thời gian Giá trị nâng cao cách mở rộng tảng phần mềm, đáp ứng yêu cầu bổ sung, để việc sử dụng dễ dàng hiệu Bảo trì phần mềm kéo dài 20 năm, phát triển phần mềm diễn 1-2 năm

Hình 8.2: Minh họa hệ thống kiểm sốt bảo trì (nguồn [5])

8.2 TẦM QUAN TRỌNG CỦA BẢO TRÌ

Cuối năm 1970, nghiên cứu khảo sát tiếng nhận định phần lớn chi phí chu kỳ phát triển phần mềm tiêu hao cho cơng tác bảo trì Hoạt động bảo trì chia thành bốn dạng:

- Thích ứng (adaptive): nhằm sửa đổi hệ thống để đối phó với thay đổi môi trường phần mềm (như liệu, hệ điều hành)

- Hoàn bị (perfective): nhằm thực yêu cầu người dùng thay đổi liên quan đến cải tiến chức phần mềm

- Khắc phục (corrective): nhằm tìm & sửa lỗi, tìm thấy người dùng

- Phòng ngừa (preventive): nhằm tăng khả bảo trì phần mềm độ tin cậy để ngăn ngừa vấn đề xấu tương lai

Bảng sau mô tả tác động yếu tố điều chỉnh quan trọng bảo trì phần mềm (được xếp theo thứ tự tác động tích cực tối đa):

Yếu tố Bảo trì Mức  Yếu tố Bảo trì Mức 

1 Các chuyên gia bảo trì 35% 15.Đo lường chất lượng 16%

2 Kinh nghiệm nhân viên cao 34% 16.Kiểm tra mã sở thức 15%

3 Biến bảng điều khiển liệu 33% 17.Thư viện Kiểm tra hồi quy 15%

4 Độ phức tạp thấp mã sở 32% 18.Thời gian đáp ứng tuyệt vời 12%

5 Y2K cơng cụ tìm kiếm đặc biệt 30% 19.Đào tạo hàng năm người dùng nhiều 10 ngày

12%

6 Công cụ cấu lại 29% 20.Kinh nghiệm quản lý cao 12%

7 Các công cụ tái kỹ thuật 27% 21.Hỗ trợ tự động (help-desk) 12%

8 Ngơn ngữ lập trình mức cao 25% 22.Khơng có mơ-đun dễ bị lỗi 10%

9 Công cụ tái thiết kế 23% 23.Báo cáo lỗi trực tuyến 10%

10.Cơng cụ phân tích phức tạp 20% 24.Đo lường suất 8%

11.Các công cụ theo dõi lỗi 20% 25.Tuyệt vời dễ sử dụng 7%

12.Chuyên gia “cập nhật hàng loạt” Y2K

20% 26.Đo lường hài lòng người sử dụng

5%

13.Cơng cụ kiểm sốt thay đổi tự động

18% 27.Tinh thần đồng đội cao 5%

Các khảo sát cho thấy ~75% công sức bảo trì liên quan đến loại (21% cơng sức để sửa lỗi) Ngồi ra, người dùng cịn có đóng góp quan trọng q trình thu thập, phân tích u cầu Đó ngun nhân vấn đề q trình bảo trì cải tiến phần mềm

Theo bảng trên, ta thấy cố không yếu tố #22 mà cịn nhiều yếu tố khác, làm giảm hiệu suất phần mềm Tình làm giảm hiệu suất phổ biến thiếu công cụ bảo trì phù hợp, thiếu phần mềm theo dõi lỗi hay phần mềm quản lý thay đổi phần mềm thư viện kiểm tra Bảng sau mô tả số yếu tố phạm vi tác động bảo trì phần mềm (xếp theo thứ tự tác động tiêu cực tối đa)

Các yếu tố bảo trì Mức  Các yếu tố bảo trì Mức 

1 mơ-đun dễ bị lỗi -50% 15.Khơng có thư viện kiểm tra hồi quy -15%

2 Biến liệu nhúng -45% 16.Không hỗ trợ tự động -15%

3 Nhân viên thiếu kinh nghiệm -40% 17.Khơng có báo cáo lỗi trực tuyến -12%

4 Độ phức tạp cao mã nguồn -30% 18.Thiếu kinh nghiệm quản lý -15%

5 Cơng cụ tìm kiếm đặc biệt khơng có Y2K

-28% 19.Khơng có cơng cụ tái cấu trúc mã nguồn

-10%

6 Phương pháp kiểm sốt thay đổi thủ cơng

-27% 20.Khơng đào tạo hàng năm 10%

7 Ngơn ngữ lập trình cấp thấp -25% 21.Khơng có cơng cụ tái thiết kế -10%

8 Khơng có cơng cụ theo dõi lỗi -24% 22.Khơng có cơng cụ phân tích độ phức tạp

-10%

9 Khơng có chun gia "cập nhật hàng loạt" Y2K

-22% 23.Không đo lường suất -7%

10.Việc sử dụng nghèo nàn -18% 24.tinh thần đồng đội nghèo nàn -6%

11.Không đo lường chất lượng -18% 25.Khơng đo lường hài lịng người dùng

-4%

12.Khơng có chun gia bảo trì -18% 26.Khơng tốn tiền vượt 0%

13.Thời gian đáp ứng -16% Tổng hợp -500%

14.Thiếu kiểm tra mã nguồn -15%

8.3 KẾ HOẠCH BẢO TRÌ PHẦN MỀM

được cách người dùng yêu cầu sửa đổi báo cáo vấn đề trục trặc, đồng thời tính tốn ngân sách dự trù cho việc bảo trì phải liên quan đến nguồn tài nguyên chi phí cần dùng Việc bảo trì phần mềm (có thể kéo dài 5-6 năm lâu hơn, sau trình phát triển) địi hỏi cần có kế hoạch hiệu để xác định phạm vi cần bảo trì phần mềm, điều chỉnh trình triển khai tu, hay định dịch vụ bảo trì, ước tính chi phí cho q trình

8.4 QUY TRÌNH BẢO TRÌ PHẦN MỀM

Việc bảo trì phần mềm bao gồm quy trình sau:

- Quy trình thực cần có tác vụ chuẩn bị phần mềm chuyển giao, chuẩn bị để kiểm soát cố xác định giai đoạn phát triển phần mềm theo dõi quản lý cấu hình sản phẩm

- Quy trình phân tích cố hay thay đổi, trách nhiệm nhóm bảo trì, nhóm bảo trì cần phân tích u cầu, xác nhận (bằng cách tái tạo tình hình) & kiểm tra tính hợp lệ, điều tra đề xuất giải pháp, sau tài liệu hóa yêu cầu giải pháp đề xuất đó, cuối cần giấy phép để triển khai giải pháp cho yêu cầu thay đổi

- Quy trình xem xét việc thực sửa đổi nội

- Quy trình chấp thuận sửa đổi việc xác nhận chúng với người yêu cầu để đảm bảo việc sửa đổi thực

- Quy trình chuyển đổi (như tảng phần mềm) trường hợp đặc biệt cơng việc bảo trì hàng ngày Nếu phần mềm cần chuyển đổi sang tảng khác mà khơng thay đổi hệ thống chức năng, quy trình dùng nhóm bảo trì thực

TĨM TẮT & ƠN TẬP

Bài học cung cấp thông tin tổng quát về: - Tầm quan trọng bảo trì phần mềm

- Lập kế hoạch bảo trì phần mềm - Quy trình bảo trì phần mềm

BÀI 9: QUẢN TRỊ DỰ ÁN PHẦN MỀM

Học xong người học nắm nội dung sau:

- Hiểu khái niệm quản trị dự án, hoạt động quản trị dự án, độ đo phần mềm, tác vụ cần thiết

- Biết vận dụng tác vụ quy trình quản lý dự án phần mềm

9.1 GIỚI THIỆU

9.1.1 Khái niệm dự án

Dự án tập hợp công việc thực tập thể (có thể có chun mơn khác nhau, thực công việc khác nhau, thời gian tham gia dự án khác nhau), nhằm đạt kết dự kiến, thời gian dự kiến, với kinh phí dự kiến

Trong lĩnh vực Công nghệ phần mềm, công tác quản trị dự án phần mềm bao gồm hoạt động (trong suốt quy trình thực dự án) liên quan đến việc lập kế hoạch, giám sát điều phối tài nguyên dự án (ví dụ kinh phí, người, thời gian thực hiện) hay xử lý rủi ro, nhằm đảm bảo thành công cho dự án Quản trị dự án phần mềm cần đảm bảo cân ba yếu tố: thời gian, tài nguyên chất lượng Ba yếu tố gọi tam giác dự án

9.1.2 Các vấn đề thường xảy dự án phần mềm

9.2 TÓM LƯỢC VỀ QUẢN TRỊ DỰ ÁN

Quản trị dự án tầng quy trình phát triển phần mềm bước kỹ thuật sở kéo dài suốt chu trình phát triển phần mềm

Trách nhiệm người quản trị dự án bao gồm:

- Quản lý thời gian: lập lịch, kiểm tra đối chiếu trình thực dự án với lịch trình, điều chỉnh lịch trình cần thiết,

- Quản lý tài nguyên: xác định, phân bổ điều phối tài nguyên

- Quản lý sản phẩm: thêm, bớt chức phù hợp với yêu cầu khách hàng - Quản lý rủi ro: xác định, phân tích rủi ro, đề xuất cách khắc phục

- Tổ chức cách làm việc

Mục tiêu việc quản trị dự án đảm bảo cho dự án đáp ứng: - Đúng thời hạn

- Không vượt dự toán

- Đầy đủ chức định

- Đáp ứng yêu cầu khách hàng (tạo sản phẩm tốt) Quản lý dự án bao gồm pha công việc sau:

- Thiết lập: viết đề án - Ước lượng chi phí - Phân tích rủi ro - Lập kế hoạch - Chọn người

- Theo dõi kiểm soát dự án

- Viết báo cáo trình diễn sản phẩm

- Về mặt thời gian:

 Tạo lập kế hoạch, điều chỉnh kế hoạch

 Kiểm tra/đối chiếu tiến trình với kế hoạch

 Giữ mức độ mềm dẻo định kế hoạch

 Phối thuộc tiến trình

- Về mặt tài ngun: thêm kinh phí, thiết bị, nhân lực … - Về mặt sản phẩm: thêm bớt chức sản phẩm …

- Về mặt rủi ro: phân tích/tìm cách xử lý, chấp nhận số rủi ro

Ngoài ra, người quản trị dự án cần phải quan tâm đến phối thuộc với dự án khác thông tin cho người quản lý cấp … Phương pháp tiếp cận người quản trị dự án thường là:

- Hiểu rõ mục tiêu (tìm cách định lượng mục tiêu có thể), - Hiểu rõ ràng buộc (chi phí, lịch biểu, tính …),

- Lập kế hoạch để đạt dược mục tiêu ràng buộc, - Giám sát điều chỉnh kế hoạch,

- Tạo môi trường làm việc ổn định, động cho nhóm

Việc quản lý tồi dẫn đến chậm trễ dự án, tính yếu tăng chi phí phát triển Một ví dụ kinh điển quản lý tồi dự án hệ điều hành OS360 IBM bị chậm năm so với kế hoạch

9.3 HOẠT ĐỘNG CỦA QUẢN TRỊ DỰ ÁN

Các hoạt động quản trị dự án phần mềm gồm:

 Xác định dự án phần mềm cần thực

- Xác định yêu cầu chung:

 Sau ta xác định rõ tài nguyên cần thiết để xây dựng phần mềm, liên quan đến nhân lực, thành phần, phần mềm sử dụng lại, phần cứng cơng cụ có sẵn cần dùng đến; nhân tố người quan trọng

 Điều cuối xác định thời gian cần thiết để thực dự án Trong trình ta cần nắm bắt toán thực tế cần giải quyết, hoạt động mang tính nghiệp vụ khách hàng, để xác định rõ yêu cầu chung đề án, xem xét dự án có khả thi hay khơng

- Viết đề án:

 Đây trình xây dựng tài liệu mơ tả đề án để xác định phạm vi dự án, trách nhiệm người tham gia dự án; cam kết người quản trị dự án, người tài trợ dự án khách hàng Nội dung tài liệu mô tả đề án thường có nội dung sau:

o Bối cảnh thực dự án: pháp lý để thực dự án, trạng

công nghệ thơng tin khách hàng trước có dự án, nhu cầu phần mềm phần mềm khách hàng, đặc điểm phạm vi phần mềm xây dựng

o Mục đích mục tiêu dự án: xác định mục đích tổng thể như: Tin học

hóa hoạt động quy trình nghiệp vụ khách hàng? Xác định mục tiêu phần mềm: lượng liệu xử lý, lợi ích phần mềm đem lại

o Phạm vi dự án: người liên quan tới dự án, hoạt động nghiệp vụ

cần tin học hóa

o Nguồn nhân lực tham gia dự án: chuyên viên nghiệp vụ, người phân tích,

người thiết kế, người lập trình, người kiểm thử, người cài đặt triển khai dự án cho khách hàng, người hướng dẫn khách hàng sử dụng phần mềm, người bảo trì dự án phần mềm

o Ràng buộc thời gian thực dự án: Ngày nghiệm thu dự án, ngày bàn giao

dự án

o Ràng buộc công nghệ phát triển: công nghệ phép sử dụng để thực

hiện dự án

o Chữ kí bên liên quan tới dự án  Lập kế hoạch thực dự án

Lập kế hoạch thực dự án hoạt động diễn suốt trình từ bắt đầu thực dự án đến bàn giao sản phẩm với nhiều loại kế hoạch khác nhằm hỗ trợ kế hoạch dự án phần mềm lịch trình ngân sách

Các loại kế hoạch thực dự án gồm có:

- Kế hoạch đảm bảo chất lượng: mơ tả chuẩn, quy trình sử dụng

- Kế hoạch thẩm định: mô tả phương pháp, nguồn lực, lịch trình thẩm định hệ thống

- Kế hoạch quản lý cấu hình: mơ tả thủ tục, cấu trúc quản lý cấu hình sử dụng - Kế hoạch bảo trì: dự tính u cầu hệ thống, chi phí, nỗ lực cần thiết cho bảo trì - Kế hoạch phát triển đội ngũ: mơ tả kĩ kinh nghiệm thành viên

trong nhóm dự án phát triển Quy trình lập kế hoạch thực dự án bao gồm:

- Thiết lập ràng buộc dự án: thời gian, nhân lực, ngân sách,

- Đánh giá bước đầu tham số dự án: quy mô, độ phức tạp, nguồn lực, - Xác định mốc thời gian thực dự án sản phẩm thu ứng với

mỗi mốc thời gian,

- Trong dự án chưa hồn thành chưa bị hủy bỏ thực lặp lặp lại công việc sau:

 Lập lịch thực dự án

 Thực hoạt động theo lịch trình

 Theo dõi tiến triển dự án, so sánh với lịch trình

 Đánh giá lại tham số dự án

 Thỏa thuận ràng buộc sản phẩm bàn giao mốc thời gian

 Nếu có vấn đề nảy sinh xem xét lại kĩ thuật khởi đầu đưa biện pháp cần thiết

Cấu trúc kế hoạch thực dự án bao gồm: - Tổ chức dự án

- Phân tích rủi ro

- Yêu cầu tài nguyên phần cứng, phần mềm - Phân công công việc

- Lập lịch dự án

- Cơ chế kiểm soát báo cáo

 Tổ chức thực dự án

 Quản lý trình thực dự án

 Kết thúc dự án

9.4 ĐỘ ĐO PHẦN MỀM

Để quản lý dự án, ta cần định lượng đối tượng cần quản lý phần mềm quy trình phát triển Ta cần đo kích cỡ phần mềm, chất lượng phần mềm, suất phần mềm …

9.4.1 Đo lường kích cỡ phần mềm

Có hai phương pháp phổ biến để đo kích cỡ phần mềm đo số dòng lệnh (LOC – Lines Of Code) đo điểm chức (FP – Function Points)

Phương pháp Độ đo LOC tương đối trực quan, phụ thuộc nhiều vào ngôn ngữ lập trình cụ thể Từ kích cỡ phần mềm (tính theo đơn vị LOC), ta tính số giá trị sau:

- Chi phí = giá thành/KLOC

Các thơng số dự án phát triển khứ dùng dể phục vụ cho ước lượng cho phần mềm phát triển

Phương pháp Điểm chức (FP) tính dựa đặc tả yêu cầu độc lập với ngôn ngữ phát triển Tuy nhiên lại có phụ thuộc vào tham số thiết lập dựa kinh nghiệm Mơ hình sở tính điểm chức là: FP = a1I+ a2O

+ a3E + a4L + a5F

Trong đó: I: số Input, O: số Output, E: số yêu cầu, L: số tập tin truy cập, F: số giao diện ngoại lai (devices, systems)

9.4.2 Độ đo dựa thống kê

Một số độ đo phần mềm khác dựa thống kê sau:

- Độ tin cậy MTBF (Mean Time Between Failure): thời gian chạy liên tục hệ thống

- Thời gian khôi phục hệ thống MTTR (Mean Time To Repair) - Tính sẵn có tính MTBF/(MTBF + MTTR)

9.5 CÁC TÁC VỤ CẦN THIẾT

9.5.1 Ước lượng

Việc người quản trị dự án ước lượng kích cỡ, chi phí, thời gian tiến hành dự án Việc thông thường tiến hành cách phân rã phần mềm cần phát triển thành khối nhỏ áp dụng kinh nghiệm (các thơng số kích cỡ, chi phí, lực nhân viên …) phần mềm phát triển để ước lượng, đánh giá công việc

Một mơ hình ước lượng hay dùng mơ hình COCOMO (Constructive Cost Model) ước lượng chi phí từ số dịng lệnh Dùng mơ hình ta ước lượng thơng số sau:

- Thời gian phát triển T = c * Ed

- Số người tham gia N = E/T

Trong a, b, c, d tham số tùy thuộc vào loại dự án (xem bảng sau) Điểm đáng ý từ nỗ lực phát triển ta suy thời gian số người tham gia vào dự án

Hình 9.1: COCOMO - Các tham số sở

a b c d

Organic (đơn giản) 3.2 1.05 2.5 0.38 Semi-detached (trung bình) 3.0 1.12 2.5 0.35 Embeded (phức tạp) 2.8 1.2 2.5 0.32 Các bước tiến hành COCOMO sau:

- Thiết lập kiểu dự án (organic, semi-detached, embeded) - Xác lập mô-đun ước lượng dịng lệnh

- Tính lại số dịng lệnh sở tái sử dụng - Tính nỗ lực phát triển E cho mô-đun

- Tính lại E dựa độ khó dự án (mức độ tin cậy, kích cỡ sở liệu, yêu cầu tốc độ, nhớ …)

- Tính thời gian số người tham gia

Ví dụ: Phần mềm với 33.3 ngàn dòng lệnh, tham số a, b, c, d 3.0, 1.12, 2.5, 0.35, ta tính được:

- E = 3.0 * 33.31.12 = 152 người/tháng - T = 2.5*E0.35 = 14.5 tháng

- N = E / D ˜ 11 người

Ta cần nhớ đo phần mềm cơng việc khó khăn - Hầu hết thông số không đo cách trực quan - Rất khó thẩm định thông số

- Các kỹ thuật đo cịn thay đổi

Ta khơng thể kiểm sốt q trình sản xuất phần mềm khơng ước lượng (đo) Một mơ hình ước lượng nghèo nàn khơng có mơ hình phải liên tục ước lượng lại dự án tiến triển

9.5.2 Quản lý nhân

Chi phí (trả cơng) người phần chi phí xây dựng phần mềm Ngồi ra, lực người phát triển phần mềm lại biến thiên, kéo theo phức tạp tính tốn chi phí Phát triển phần mềm tiến hành theo nhóm Kích thước tốt nhóm từ đến ngưịi Phần mềm lớn thường xây dựng nhiều nhóm nhỏ Một nhóm phát triển gồm loại thành viên sau: (i) người phát triển, (ii) chuyên gia miền ứng dụng, (iii) người thiết kế giao diện, (iv) Thủ thư phần mềm (quản lý cấu hình phần mềm), (v) Người kiểm thử

Một nhóm phát triển cần có người quản trị, người có vai trò lãnh đạo mặt kĩ thuật Một đặc trưng phương pháp làm việc theo nhóm trao đổi thông tin (giao tiếp) thành viên nhóm Thời gian dùng cho việc giao tiếp chiếm đến nửa tổng thời gian dành cho pháp triển phần mềm

Ngồi ra, thời gian khơng dùng cho phát triển sản phẩm chiếm phần lớn thời gian cịn lại người lập trình Một người đồng thời làm việc cho nhiều nhóm (dự án) phần mềm khác Điều làm cho việc tính toán giá thành phần mềm phức tạp Ta cần ghi nhớ, sản xuất phần mềm thì:

- Năng lực thành viên không đồng

- Người tốt (nhất) sản xuất lần trung bình, người khơng cho kết

- Một số cơng việc q khó người

9.5.3 Quản lý cấu hình

Quản lý cấu hình phần mềm công việc quan trọng sản xuất phần mềm Mã nguồn (và liệu) sản phẩm dự án phần mềm Quản lý cấu hình tự động hóa thơng qua cơng cụ Nhiệm vụ cơng cụ quản lý là:

- Lưu trữ mã nguồn

- Tạo điểm truy cập (phiên thống nhất) cho người lập trình sửa đổi, thêm bớt mã nguồn

Do ta dễ dàng:

- Kiểm sốt tính thống mã nguồn,

- Kiểm soát sửa đổi, lý sửa đổi, lý lịch lần sửa đổi, - Dễ dàng lưu trữ, truy cập tới khác phần mềm, - Tối ưu hóa vùng đĩa cần thiết cho lưu trữ,

Phương thức hoạt động cơng cụ quản lý cấu hình là: - Quản lý tập chung (mã nguồn, tư liệu, công cụ phát triển …)

- Các tập tin tạo lần nhất, phiên sửa đổi ghi lại sai phân gốc

- Sử dụng cách kiểm xuất/nhập (check out/in) sửa đổi tập tin

Thông thường, người phát triển muốn sửa đổi mã nguồn thực thao tác check out tập tin Khi tập tin bị check out người phát triển khác mở tập tin dạng đọc Khi kết thúc sửa đổi ghi tập tin vào sở liệu, người sửa đổi tiến hành check in để thông báo kết thúc cơng việc sửa đổi, đồng thời ghi lại thông tin liên quan (lý sửa đổi …) đến sửa đổi

Dữ liệu lưu trữ dự án thông thường bao gồm: - Mã nguồn, Dữ liệu, Tư liệu

- Các ca kiểm thử

Một số công cụ quản lý cấu hình phổ biến RCS, CVS HĐH Solaris SourceSafe Microsoft

9.5.4 Quản lý rủi ro

Quản lý rủi ro cơng việc đặc biệt quan trọng khó khăn phát triển phần mềm Có nguyên nhân (rủi ro) sau dẫn đến chấm dứt dự án:

- Chi phí phát triển cao, - Quá chậm so với lịch biểu,

- Tính so với yêu cầu

Quản lý rủi ro bao gồm cơng việc sau: - Dự dốn rủi ro,

- Đánh giá khả xảy thiệt hại, - Tìm giải pháp khắc phục

Dưới rủi ro thường xảy phát triển phần mềm phương pháp khắc phục chúng:

- Thiếu người phát triển: sử dụng người tốt nhất; xây dựng nhóm làm việc; đào tạo người mới,

- Kế hoạch, dự tốn khơng sát thực tế: ước lượng phương pháp khác nhau; lọc, loại bỏ yêu cầu không quan trọng,

- Phát triển sai chức năng: chọn phương pháp phân tích tốt hơn; phân tích tính tổ chức/mơ hình nghiệp vụ khách hàng,

- Phát triển sai giao diện: phân tích thao tác người dùng; tạo kịch cách dùng; tạo mẫu,

- Yêu cầu cao: lọc bớt yêu cầu; phân tích chi phí/lợi ích,

TÓM TẮT

Bài học trình bày tóm lược cơng tác quản trị dự án phần mềm thông qua vấn đề sau đây:

- Khái niệm dự án

- Các vấn đề thường xảy dự án phần mềm - Hoạt động quản trị dự án

- Độ đo phần mềm (đo lường kích cỡ phần mềm, độ đo dựa thống kê) - Các tác vụ cần thiết

 Ước lượng

 Quản lý nhân

 Quản lý cấu hình

BÀI 10: QUY TRÌNH PHÁT TRIỂN PHẦN MỀM

Học xong người học nắm nội dung sau:

- Hiểu khái niệm quy trình, quy trình ISO, CMM/CMMI

- Biết ưu nhược điểm dạng quy trình, để từ áp dụng phù hợp thực tế

10.1 GIỚI THIỆU

Cũng ngành sản xuất khác, quy trình6 yếu tố quan trọng đem lại thành công cho đơn vị nhà sản xuất phần mềm, giúp cho thành viên dự án từ người cũ đến người mới, hay ngồi cơng ty xử lý đồng công việc tương ứng vị trí thơng qua cách thức chung cơng ty, cấp độ dự án

Quy trình phát triển / xây dựng phần mềm (Software Development / Engineering Process - SEP) có tính chất định để tạo sản phẩm chất luợng có tốt với chi phí thấp suất cao, có ý nghĩa quan trọng công ty sản xuất hay gia cơng phần mềm, từ giúp củng cố phát triển công nghiệp phần mềm đầy cạnh tranh

10.2 GIỚI THIỆU VỀ QUY TRÌNH

Quy trình hiểu phương pháp thực sản xuất sản phẩm Tương tự vậy, SEP phương pháp phát triển hay sản xuất sản phẩm phần mềm

Thơng thường quy trình bao gồm yếu tố sau: - Thủ tục (Procedures)

- Hướng dẫn công việc (Activity Guidelines) - Biểu mẫu (Forms/templates)

- Danh sách kiểm định (Checklists) - Công cụ hỗ trợ (Tools)

Quy trình gồm nhóm cơng việc chính:

- Đặc tả u cầu (Requirements Specification): “đòi hỏi” cho yêu cầu chức phi chức

- Phát triển phần mềm (Development): tạo phần mềm thỏa mãn yêu cầu “Đặc tả yêu cầu”

- Kiểm thử phần mềm (Validation/Testing): để bảo đảm phần mềm sản xuất đáp ứng “đòi hỏi” “Đặc tả yêu cầu”

- Thay đổi phần mềm (Evolution): đáp ứng yêu cầu thay đổi khách hàng Tùy theo mơ hình phát triển phần mềm, nhóm cơng việc triển khai theo cách khác Để sản xuất sản phẩm phần mềm người ta dùng mơ hình khác Tuy nhiên khơng phải tất mơ hình thích hợp cho phần mềm

Hình 10.1: Quy trình Rational Unified Process

10.3 QUY TRÌNH ISO, CMM/CMMI

Phần không sâu vào tìm hiểu mơ hình phát triển phần mềm mà cung cấp nhìn tổng quát chúng, mối quan hệ SEP với ISO CMM/CMMI

Vấn đề đặt làm cải tiến quy trình để cải thiện chất lượng suất? Câu trả lời khung quy trình (Process Framework - PF) PF yêu cầu mà quy trình phải đáp ứng tùy theo mức độ PF không quy trình cụ thể mà đưa yêu cầu mức độ trưởng thành khác quy trình phải đạt Đây hướng dẫn cho hoạt động cải tiến để nâng mức độ trưởng thành từ thấp lên cao

Trên giới có nhiều PF, phổ biến ISO (International Organization for Standardization, http://www.iso.org) CMM (Capability Maturity Model, http://www.sei.cmu.edu/cmm) tổ chức giới công nhận ISO nhắm chung đến nhiều loại tổ chức sản xuất lẫn dịch vụ, CMM dành riêng cho tổ chức phát triển phần mềm

Đối với phần mềm, ISO mức độ chất lượng yêu cầu tối thiểu mà SEP phải đạt (ISO certified) việc cải tiến quy trình thực thơng qua quy trình kiểm định, CMM bao gồm thực tiễn tốt (best practices) tập hợp từ nhiều tổ chức phát triển phần mềm khác chúng tổ chức thành mức độ sau

Hình 10.3: Các mức độ trưởng thành CMM

Level

Initial

Level

Processes are unpredictable, poorly controlled, reactive

Managed

Level

Processes are planned, documented, performed, monitored, and controlled at the projectlevel Often reactive

Defined

Level

Processes are well characterized and understood Processes, standards, procedures, tools, etc are defined at the

organizational (Organization X )level Proactive

Quantitatively Managed

Level

Processes are controlled using statistical and other quantitative techniques Optimizing Proc ess Mat urity Process performance continually improved through incremental and innovative technological improvements Level

Initial

Level

Processes are unpredictable, poorly controlled, reactive

Managed

Level

Processes are planned, documented, performed, monitored, and controlled at the projectlevel Often reactive

Defined

Level

Processes are well characterized and understood Processes, standards, procedures, tools, etc are defined at the

organizational (Organization X )level Proactive

Quantitatively Managed

Level

Ngày nay, phần mềm không đứng riêng mà thường phận hệ thống hồn chỉnh Do đó, CMMI (Capability Maturity Model Integration) đời hướng đến quy trình cho việc xây dựng hệ thống, bao gồm việc tích hợp để xây dựng bảo trì tồn hệ thống

Hình 10.4: Các thành phần hệ thống chuẩn CMM/CMMI

Mơ hình SEP cịn gọi chu trình hay vịng đời phần mềm (SLC - Software Life Cycle) SLC tập hợp công việc quan hệ chúng diễn trình phát triển phần mềm Có nhiều mơ hình SLC khác nhau, số ứng dụng phổ biến giới như:

Các mơ hình phiên (Single-version models) - Mơ hình Waterfall (Waterfall model)

- Mơ hình chữ V (V-model)

Các mơ hình nhiều phiên (Multi-version models) - Mơ hình mẫu (Prototype)

- Mơ hình tiến hóa (Evolutionary)

Maturity Levels (1 - 5)

Generic Practices

Generic Goals Process Area

Common Features

Process Area Process Area n

Verifying Implementation Specific Goals Specific Practices Ability

to Perform ImplementationDirecting

Required Required

Sub practices, typical work products, discipline amplifications, generic

practice elaborations, goal and practice titles, goal and practice notes,

and references

Commitment

to Perform

Sub practices, typical work products, discipline amplifications, generic

practice elaborations, goal and practice titles, goal and practice notes,

and references

Inform ative Informa

tive

Required Specific for each process area.

Required Common across all process areas.

Maturity Levels (1 - 5)

Generic Practices

Generic Goals Process Area

Common Features

Process Area Process Area n

Verifying Implementation Specific Goals Specific Practices Ability

to Perform ImplementationDirecting

Required Required

Sub practices, typical work products, discipline amplifications, generic

practice elaborations, goal and practice titles, goal and practice notes,

and references

Commitment

to Perform

Sub practices, typical work products, discipline amplifications, generic

practice elaborations, goal and practice titles, goal and practice notes,

and references

Inform ative Informa

tive

Required Specific for each process area. Required Specific for each process area.

- Mơ hình lặp tăng dần (Iterative and Incremental) - Mơ hình phát triển ứng dụng nhanh (RAD)

- Mơ hình xoắn (Spiral)

TĨM TẮT

Bài học cuối giới thiệu tóm lược đến người học vấn đề chuyên sâu lĩnh vực Công nghệ Phần mềm, là:

PHỤ LỤC A – BÀI TẬP

 CÂU HỎI LÝ THUYẾT

1 Nêu khác biệt giai đoạn thiết kế quy trình khác Nêu khác biệt giai đoạn lập trình quy trình khác

3 Khi tiến hành thực phần mềm qua giai đoạn (trong quy trình giai đoạn) phát sinh lỗi giai đoạn (kết chuyển giao khơng xác, thiếu sót, v.v…) Nêu lỗi (nếu phát sinh) giai đoạn nghiêm trọng

4 Trong giai đoạn quy trình cơng nghệ phần mềm, nêu giai đoạn: (i) quan trọng nhất, dễ thực nhất, tốn nhiều thời gian chi phí nhất, bỏ qua (trong trường hợp nào) Giải thích

5 Nêu khác biệt yêu cầu chức (yêu cầu nghiệp vụ, yêu cầu hệ thống) phi chức (yêu cầu chất lượng) Loại yêu cầu quan trọng Xác định yêu cầu chức hệ thống có phần mềm sau (chi

tiết quy định, biểu mẫu liên quan có mơ tả đề tài) a Phần mềm quản lý bán sách

b Phần mềm quản lý học sinh trường cấp c Phần mềm đánh cờ gánh

d Phần mềm hỗ trợ giải tập phương trình đại số e Phần mềm quản lý giải vơ địch bóng đá quốc giá

7 Mỗi phát biểu sau hay sai? Nếu đúng, giải thích Nếu sai, giải thích ví dụ minh họa

d Việc mơ hình hóa u cầu khơng cung cấp thêm thông tin yêu cầu phần mềm mà giúp trình bày lại yêu cầu phần mềm dạng trực quan

e Cho biết kết việc mơ hình hóa u cầu có sử dụng bước thiết kế giao diện đối tượng hay không

f Kết việc mơ hình hóa u cầu có sử dụng bước xác định thuộc tính đối tượng (giai đoạn thiết kế)

g kết việc mơ hình hóa yêu cầu có sử dụng bước xác định hàm xử lý đối tượng (giai đoạn thiết kế)

8 Nếu không thực qua bước mô hình hóa u cầu việc lập mơ hình đối tượng có khó khăn gì? Tại sao?

 BÀI TẬP ĐÁNH GIÁ

Hãy thực đánh giá giao diện của:

- http://www.google.com cho hình kết sau tìm kiếm xong - http://www.costco.com cho hình giới thiệu hình sản phẩm - Yahoo mail Google mail cho hình sau đăng nhập

- Một số website Việt nam (VN Express, …)

 BÀI TẬP PHÂN TÍCH

Bài tập 1: Quản lý thuê bao điện thoại Lưu trữ: Các thông tin

- Hợp đồng thuê điện thoại (Khách hàng, loại thuê bao, máy điện thoại) - Cuộc gọi (Máy điện thoại, Ngày, Giờ, Thời gian, Nơi gọi đến)

Tính tốn:

- Số tiền phải trả máy điện thoại tháng:

 Tiền thuê bao hàng tháng (phụ thuộc vào loại thuê bao với định mức riêng)

- Tính cơng nợ khách hàng khách hàng chưa toán tiền

Kết xuất:

- Hóa đơn tính tiền điện thoại cho khách hàng tháng - Danh sách khách hàng chưa toán tiền điện thoại

- Thống kê nơi gọi đến, thời điểm gọi theo khu vực tháng

Bài tập 2: Quản lý học sinh trường phổ thông trung học Lưu trữ: Các thông tin

- Học sinh: Họ, tên, lớp, ngày sinh, giới tính, địa chỉ, thành phần, kết học tập, điểm danh

Tra cứu: Thông tin học sinh

Tính tốn:

- Điểm trung bình mơn học theo học kỳ: Tính theo điểm hình thức kiểm tra (15 phút: HS1, tiết: HS2, thi học kỳ: HS3)

- Điểm trung bình HK1, HK2, năm (học kỳ 1: HS1, học kỳ 2: HS2)

- Xếp loại: Xuất sắc điểm trung bình niên khóa ≥ 9.0 khơng có mơn có điểm trung bình 7.5 Tiên tiến điểm trung bình niên khóa ≥ 7.5 khơng có mơn có điểm trung bình 6.0 Đạt u cầu điểm trung bình niên khóa ≥ khơng có mơn có điểm trung bình Khơng đạt u cầu có môn

Ghi chú: Nếu tổng số ngày vắng vượt 20  loại không đạt yêu cầu Nếu số ngày vắng vượt 10 hay số ngày vắng khơng phép vượt q bị hạ xuống bậc (chỉ áp dụng với loại xuất sắc tiên tiến)

Kết xuất:

- Danh sách học sinh theo lớp - Phiếu điểm cho học sinh

- Bảng điểm môn bảng điểm tổng kết cho lớp

Bài tập 3: Quản lý tài khoản ngân hàng Lưu trữ:

- Tài khoản: Khách hàng, loại tài khoản, số tiền, loại tiền, ngày gởi, tình trạng - Quá trình gửi rút tài khỏan: Khách hàng, ngày số tiền, hình thức

- Các quy định lãi suất tỷ giá

Tra cứu: Tài khoản theo tiêu chuẩn

- Mã số, Khách hàng, Loại tài khoản, Ngày mở, ngày đóng

Tính tốn:

- Lãi suất cho tài khoản đến kỳ hạn hay khách hàng rút trước kỳ hạn (chỉ không kỳ hạn)

Kết xuất:

- Danh sách biến động tài khoản

- Danh sách tài khoản số dư theo loại tài khoản - Tình hình gửi, rút tiền theo loại tài khoản

- Số dư ngân hàng theo ngày tháng

Bài tập 4: Theo dõi kế hoạch sản lượng cao su Lưu trữ: Các thông tin

Nông trường: Tên, diện tích lơ cao su theo năm Sản lượng kế hoạch theo tháng, năm loại mủ Sản lượng thực tế theo ngày loại mủ

Tính tốn:

Tỷ lệ đạt loại mủ theo nông trường theo kế hoạch Kế hoạch dự kiến cho năm tới

Kết xuất:

Báo cáo tháng

Kế hoạch năm cho nông trường cho loại mủ

Bài tập 5: Quản lý giải vơ địch bóng đá Lưu trữ: Các thông tin

- Các đội bóng tham gia giải: Tên đội bóng, tên huấn luyện viên, cầu thủ, sân nhà

- Lịch thi đấu: đội tham dự, sân, thời gian

- Kết trận đấu: Trọng tài, tỷ số, khán giả, cầu thủ sân đội vị trí tương ứng, việc ghi bàn, phạt thẻ

Tra cứu: Cầu thủ, đội bóng

Tính tốn:

- Tính điểm cho đội: trận thắng điểm, trận hòa điểm, trận thua điểm

- Xếp hạng cho đội: Dựa vào tiêu chuẩn: tổng số điểm, tổng số bàn thắng, hiệu số, đối kháng trực tiếp, bốc thăm

Kết xuất:

- Danh sách cầu thủ theo đội, vị trí - Lịch thi đấu

- Bảng xếp hạng đội bóng - Tổng kết việc ghi bàn giải - Tình hình phạt thẻ đội bóng

Bài tập 6: Thi trắc nghiệm máy tính Lưu trữ: Các thơng tin

- Thí sinh dự thi: Họ tên, mơn thi, ngày thi, địa chỉ, đề thi, làm, phòng thi - Câu hỏi trắc nghiệm: Nội dung câu hỏi, cầu trả lời có, đáp án, mức độ

Tính tốn:

- Phát sinh đề thi tương đương cho đề thi chọn cho mơn thi (đề thi tương có câu hỏi trắc nghiệm có số thứ tự khác trật tự câu trả lời khác nhau)

- Tính điểm thi cho thí sinh: Tổng điểm câu hỏi với thang điểm tương ứng

Kết xuất:

- Danh sách thí sinh theo phịng thi - Đề thi

- Bài làm thí sinh với điểm số - Danh sách kết thi môn thi

- Thống kê kết thi theo mức theo môn thi - Thống kê kết thi theo câu hỏi

Bài tập 7: Quản lý trung tâm giới thiệu việc làm sinh viên Lưu trữ: Các thông tin

- Sinh viên đăng ký tìm việc: Họ tên, ngày sinh, địa chỉ, tình hình sức khỏe, trình học tập cấp, cơng việc đảm nhận, yêu cầu tìm việc

- Đơn vị đăng ký tìm người: Tên, địa chỉ, người đại diện, công việc yêu cầu tuyển dụng

- Giới thiệu việc làm: Sinh viên, đơn vị, cơng việc, tình trạng

Tra cứu:

Sinh viên tra cứu công việc

- Loại cơng việc, Mức lương, Hình thức làm việc, Nơi làm việc

Đơn vị tuyển dụng tra cứu sinh viên

Tính tốn:

- Các cơng việc thích hợp cho sinh viên đăng ký làm việc

- Các sinh viên thích hợp cho cơng việc cần tuyển dụng đơn vị

Kết xuất:

- Danh sách sinh viên đăng ký theo công việc

- Danh sách số lượng sinh viên đăng ký theo loại công việc - Danh sách đơn vị tuyển dụng theo công việc

- Danh sách số lượng đơn vị tuyển dụng theo công việc - Thống kê tình hình giới thiệu việc làm thực năm

Bài tập 8: Phần mềm quản lý bán sách

 Khảo sát thực tế rút yêu cầu cần phải làm cho đề tài

Bài tập 9: Phần mềm quản lý bán vé chuyến bay

 Khảo sát thực tế rút yêu cầu cần phải làm cho đề tài

Bài tập 10: Phần mềm quản lý phòng mạch

 Khảo sát thực tế rút yêu cầu cấn phải làm cho đề tài

 YÊU CẦU THỰC HIỆN ĐỒ ÁN MÔN HỌC Yêu cầu chung

Mỗi sinh viên đăng ký thực phần mềm Kết gồm báo cáo viết, đĩa/CD (chương trình nguồn, EXE, báo cáo viết)

Cấu trúc báo cáo viết

1 Hiện trạng yêu cầu - Hiện trạng:

 Giới thiệu giới thực liên quan

 Mô tả quy trình cơng việc liên quan đến đề tài

 Mô tả quy định ràng buộc có liên quan

 Mơ tả quy định cơng thức tính có liên quan - Yêu cầu:

 Danh sách công việc hỗ trợ thực máy tính (dựa theo tóm tắt u cầu cho)

2 Mơ hình hóa u cầu

Mơ hình luồng liệu theo yêu cầu: - Sơ đồ luồng liệu cho yêu cầu - Mô tả chi tiết cho sơ đồ

Mơ hình luồng liệu chung cho tồn hệ thống Sơ đồ luồng liệu chung cho toàn bọê hệ thống Thiết kế phần mềm

Thiết kế liệu: - Sơ đồ luận lý

- Danh sách thành phần sơ đồ

Stt Tên Loại Ý nghĩa Ghi

- Danh sách thuộc tính thành phần Tên thành phần:

Stt Tên Loại Kiểu Miền giá trị Ý nghĩa

Thiết kế giao diện:

Stt Mã số Loại Ý nghĩa Ghi

- Mô tả chi tiết hình

 Danh sách biến cố xử lý tương ứng hình

Stt Biến cố Ý nghĩa Xứ lý tương ứng Mã số xử lý

Thiết kế xử lý

- Danh sách xử lý (Các xử lý quan trọng)

Stt Mã số Loại Ý nghĩa Ghi

- Mô tả chi tiết xử lý

 Sơ đồ luồng liệu

 Mô tả chi tiết sơ đồ Cài đặt thử nghiệm - Cài đặt

 Danh sách tình trạng cài đặt chức (mức độ hoàn thành)

Stt Chức Mức độ hoàn thành Ý nghĩa

- Thử nghiệm

 Nội dung bảng liệu

 Một số test-case chạy thử nghiệm

 Các báo biểu hình số liệu tương ứng Tổng kết

PHỤ LỤC B – THAM KHẢO PHẦN MỀM QUẢN LÝ THƯ VIỆN

 Mơ tả chi tiết thuộc tính Độc giả:

Stt Thuộc tính Kiểu Miền giá trị Ý nghĩa Ghi

1 MDG Chuỗi Khóa

2 MLDG Chuỗi Khóa ngoại

3 HoTen Chuỗi

4 NgaySinh Ngày

5 DiaChi Chuỗi

6 DienThoai Chuỗi

Sách

Stt Thuộc tính Kiểu Miền giá trị Ý ghĩa Ghi

1 MSACH Chuỗi Khóa

2 MTG Chuỗi Khóa ngoại

3 MNXB Chuỗi Khóa ngoại

4 MLSACH Chuỗi Khóa ngoại

5 MNN Chuỗi Khóa ngoại

6 TenSach Chuỗi

7 Ngàymua Ngày

8 SoTrang Số >0

Phiếu mượn

Stt Thuộc tính Kiểu Miền giá trị Ý nghĩa Ghi

1 MPHM Chuỗi Khóa

2 NgayMuon Ngày

Chi tiết mượn

Stt Thuộc tính Kiểu Miền giá trị Ý nghĩa Ghi

1 MPHM Chuỗi Khóa ngoại

2 MSACH Chuỗi Khóa ngoại

Loại sách

Stt Thuộc tính Kiểu Miền giá trị Ý nghĩa Ghi

1 MLSACH Chuỗi Khóa ngoại

2 TenLoai Chuỗi

3 Ghi Chu Chuỗi

Loại độc giả

Stt Thuộc tính Kiểu Miền giá trị Ý ghĩa Ghi

1 MLDG Chuỗi Khóa

2 Tenloại Chuỗi

3 GhiChu Chuỗi

Nhà xuất

Stt Thuộc tính Kiểu Miền giá trị Ý ghĩa Ghi

1 MNXB Chuỗi Khóa

2 Tenloai Chuỗi

3 GhiChu Chuỗi

Tác giả

Stt Thuộc tính Kiểu Miền giá trị Ý nghĩa Ghi

1 MTG Chuỗi Khóa

2 Ten Chuỗi

3 GhiChu Chuỗi

Ngôn ngữ

Stt Thuộc tính Kiểu Miền giá trị Ý nghĩa Ghi

1 MNN Chuỗi Khóa

2 Ten Chuỗi

3 GhiChu Chuỗi

 Mơ hình chi tiết thành phần sơ đồ lớp Đối tượng Độc Giả

Stt Thuộc tính Kiểu Miền giá trị Ý nghĩa Ghi

1 MDG Chuỗi

2 Loại độc giả Số giá trị rời rạc

4 NgaySinh Ngày từ 19 đến 90

5 DiaChi Chuỗi

6 DienThoai Chuỗi

Đối tượng Sách

Stt Thuộc tính Kiểu Miền giá trị Ý nghĩa Ghi

1 MSACH Chuỗi

2 Loại sách Số

3 Tác giả Chuỗi

4 Nhà xuất Chuỗi

5 Ngày nhập Chuỗi

6 TenSach Chuỗi

7 Ngôn ngữ Ngày

8 SoTrang Số >0

Quan hệ mượn

Stt Thuộc tính Kiểu Miền giá trị Ý nghĩa Ghi

1 Ngày mượn Ngay >=Ngày nhập

PHỤ LỤC C – QUY TRÌNH RUP

Một số hình ảnh minh họa quy trình RUP (Rational Unified Process,

http://www.ibm.com/software/rational/rup) phổ biến giới:

 Phần A – Quy trình chung

Hình 10.6: Information flow  Phần B – Quy trình phân tích yêu cầu

Hình 10.8: Workflow Detail: Analyze the Problem

Hình 10.10: Workflow Detail: Manage Changing Requirements

Hình 10.12: Workflow Detail: Manage the Scope of the System

 Phần C – Quy trình phân tích thiết kế

Hình 10.14: Analysis & Design Artifact Set

Hình 10.16: Workflow Detail: Perform Architectural Synthesis

Hình 10.18: Workflow Detail: Design Components

Hình 10.20: Workflow Detail: Design the Database  Phần D – Quy trình thực

Hình 10.21: Implementation Artifact

Set Hình 10.22: Workflow Detail: Structure

Hình 10.23: Workflow Detail: Plan the Integration

Hình 10.25: Workflow Detail: Integrate Each Subsystem

Hình 10.26: Workflow Detail: Integrate the System  Phần E – Quy trình kiểm thử