Tài liệu giảng dạy môn Công nghệ phần mềm - Nguyễn Khắc Quốc

Tài liệu môn Công nghệ phần mềm cung cấp cho người học những kiến thức như: Phần mềm và công nghệ phần mềm; Phân tích và đặc tả yêu cầu; Thiết kế phần mềm; Lập trình; Xác minh và thẩm định; Sưu liệu phần mềm; Quản lý dự án phần mềm;...Mời các bạn cùng tham khảo!

Trang 1

Phụ lục 5

TRƯỜNG ĐẠI HỌC TRÀ VINH

KHOA KỸ THUẬT VÀ CÔNG NGHỆ

TÀI LIỆU GIẢNG DẠY MÔN CÔNG NGHỆ PHẦN MỀM

GV biên soạn: Nguyễn Khắc Quốc

Trà Vinh, 5/2015 Lưu hành nội bộ

Trang 2

KHoA rY ruuAT vA cCxc NGHE

^A

BO h,{ON CONG NGIIE TX{OI{G TTN

A^\^

TRANG PF{E DUY&T TAI LIEU GIANG DAY

- TOn tai iiQu giAng dpy: CONG NGI{B' PHA.N MEM

- ltlgdy hoin chinh: Th6ng 612015

-1ac gia bidn soan: NG1IYEN rcfAC QUOC

- Eon vi c6ng t6c: B0 m6n COng nghQ Thdng tin

- Dia chi li0n l4c: B0 m6n C6ng nghQ Th6ng tin

Trd Vinh, ngdy l0 thdng 6 ndm 2015

PHE DUYET CUA BQ MON

D6ng y su dpng tai liQu staqs a+v ftg- vilt"{:, tk*) wrD't :

do [rq i,q.6i Nirr- \'!-.,nlr:::.'- bien soan dd giang day

A 4 tl tJ /' r\-

.,r-mdn tit:'.I

"l(r+ .[Jt6r,- .ncf-zn.

JJ

Trit Vinh, ng\, /,3 thang ( nitm 2015

TR.UCITqG TTO N{ON

PHE DUYET CUA KIIOA

Trang 3

Tài liệu giảng dạy môn: Công nghệ phần mềm i

MỤC LỤC

Chương 1 PHẦN MỀM VÀ CÔNG NGHỆ PHẦN MỀM 1

1.1 Phần mềm máy tính 1

1.1.1 Khái niệm 1

1.1.2 Đặc điểm 1

1.1.3 Phân loại 2

1.1.4 Kiến trúc phần mềm 3

1.1.5 Quá trình tạo phần mềm 4

1.2 Công nghệ phần mềm 4

1.2.1 Lịch sử ra đời 4

1.2.2 Định nghĩa 5

1.2.3 Mục tiêu nghiên cứu 6

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

1.3 Qui trình phát triển phần mềm 7

1.3.1 Mô hình vòng đời cổ điển (mô hình thác nước) (Waterfall Model) 7

1.3.2 Mô hình làm bản mẫu (Prototype) 12

1.3.3 Mô hình xoắn ốc 13

1.3.4 Kỹ thuật thế hệ thứ tư 14

1.3.5 Mô hình lập trình cực đoan 15

1.3.6 Tổ hợp các mô hình 16

1.3.7 Tính khả thị của quá trình 17

1.3.8 Vấn đề giảm kích cỡ của phần mềm 18

1.4 Cái nhìn chung về công nghệ phần mềm 18

1.5 Một số phương pháp xây dựng phần mềm 20

1.5.2 Phân loại 20

1.5.3 Cách tiếp cận 20

1.5.4 Cách tiến hành 21

1.6 Công cụ và môi trường phát triển phần mềm 23

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

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

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

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

Trang 4

Tài liệu giảng dạy môn: Công nghệ phần mềm ii

1.6.6 Phần mềm xây dựng phương án 24

Chương 2 PHÂN TÍCH VÀ ĐẶC TẢ YÊU CẦU 26

2.1 Đại cương về phân tích và đặc tả 26

2.2 Quá trình phân tích 28

2.2.1 Phân tích phạm vi dự án phần mềm 28

2.2.2 Nghiên cứu khả thi 28

2.2.3 Phân tích mở rộng yêu cầu nghiệp vụ 30

2.2.4 Phân tích yêu cầu bảo mật 31

2.2.5 Phân tích yêu cầu tốc độ 33

2.2.6 Phân tích yêu cầu vận hành 34

2.2.7 Phân tích khả năng mở rộng yêu cầu 34

2.2.8 Phân tích những yêu cầu sẵn có 35

2.2.9 Phân tích yêu tố con người 35

2.2.10 Phân tích yêu cầu tích hợp 36

2.2.11 Phân tích thực tiễn nghiệp vụ tồn tại 36

2.2.12 Phân tích yêu cầu khả năng quy mô 36

2.3 Người phân tích 37

2.4 Xác định và đặc tả yêu cầu 37

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

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

2.5 Mô hình hóa yêu cầu hệ thống 40

2.5.1 Các nguyên lý mô hình hóa 41

2.5.2 Sơ đồ phân rã chức năng 41

2.5.3 Sơ đồ luồng dữ liệu 42

2.5.4 Mô hình bản mẫu (protoype) 42

2.5.5 Mô hình hướng đối tượng 42

2.5.6 Đặc tả yêu cầu 44

2.5.7 Thẩm định yêu cầu 44

2.5.8 Định dạng đặc tả yêu cầu 45

Chương 3 THIẾT KẾ PHẦN MỀM 49

3.1 Tổng quan về thiết kế phần mềm 49

3.1.2 Tầm quan trọng 49

3.1.3 Quá trình thiết kế 50

Trang 5

Tài liệu giảng dạy môn: Công nghệ phần mềm iii

3.1.4 Các hoạt động thiết kế chính trong một hệ thống phần mềm lớn 51

3.1.5 Cơ sở của thiết kế 51

3.1.6 Mô tả thiết kế 52

3.1.7 Chất lượng thiết kế 54

3.2 Kỹ thuật thiết kế 56

3.2.1 Thiết kế trên xuống (Top-down) 56

3.2.2 Thiết kế từ dưới lên (Bottom–up) 57

3.2.3 Thiết kế hệ thống 57

3.2.4 Thiết kế bản mẫu (prototype) 57

3.2.5 Phân rã thiết kế 57

3.2.6 Phương pháp phân loại phân rã 57

3.3 Thiết kế dữ liệu 62

3.3.1 Cách tiếp cận hướng đối tượng 62

3.3.2 Ba đặc trưng của thiết kế hướng đối tượng 62

3.3.3 Cơ sở của thiết kế hướng đối tượng 63

3.3.4 Các bước thiết kế 64

3.3.5 Ưu nhược điểm của thiết kế hướng đối tượng 64

3.3.6 Quan hệ giữa thiết kế và lập trình hướng đối tượng 65

3.3.7 Quan hệ giữa thiết kế hướng đối tượng và hướng chức năng 65

3.4 Thiết kế giao diện người sử dụng 65

3.4.1 Một số vấn đề thiết kế 68

3.4.2 Một số hướng dẫn thiết kế 68

3.4.3 Kết quả thiết kế 69

3.4.4 Phân loại màn hình giao diện 70

3.4.5 Quá trình thiết kế 71

Chương 4 LẬP TRÌNH 79

4.1 Ngôn ngữ lập trình 79

4.1.1 Đặc trưng của ngôn ngữ lập trình 79

4.1.2 Lựa chọn ngôn ngữ lập trình 81

4.1.3 Môi trường lập trình 81

4.1.4 Chất lượng đòi hỏi cho một ngôn ngữ lập trình 82

4.1.5 Khả năng Module hóa của ngôn ngữ lập trình 82

4.1.6 Ngôn ngữ lập trình và sự ảnh hưởng tới công nghệ phần mềm 82

4.2 Phong cách lập trình 83

Trang 6

Tài liệu giảng dạy môn: Công nghệ phần mềm iv

4.2.1 Tài liệu chương trình 83

4.2.2 Khai báo dữ liệu 84

4.2.3 Xây dựng câu lệnh 84

4.2.4 Vào/ra 85

4.2.5 Các yếu tố quan trọng nhất của phong cách lập trình tốt 85

4.3 Lập trình tránh lỗi 86

4.3.1 Lập trình thứ lỗi 87

4.3.2 Lập trình phòng thủ 88

4.4 Lập trình hướng hiệu quả thực hiện 89

4.4.1 Tính hiệu quả chương trình 89

4.4.2 Hiệu quả bộ nhớ 89

4.4.3 Hiệu quả vào/ra 89

4.4 Đánh giá chất lượng công việc 90

4.4.1 Hiện thực tăng cường 90

4.4.2 Đánh giá lại thiết kế và chương trình 91

Chương 5 XÁC MINH VÀ THẨM ĐỊNH 93

5.1 Đại cương 93

5.2 Khái niệm về phép thử 95

5.3 Kiểm thử chức năng và kiểm thử cấu trúc 95

5.3.1 Kiểm thử hộp đen - Kiểm thử chức năng 95

5.3.2 Kiểm thử hộp trắng - Kiểm thử cấu trúc 98

5.3.3 Kiểm thử dựa trên đặc điểm kỹ thuật 99

5.3.4 Kiểm thử trực quan 99

5.4 Quá trình kiểm thử 100

5.5 Chiến lược kiểm thử 103

5.5.1 Kiểm thử dưới lên 103

5.5.2 Kiểm thử trên xuống 103

5.5.3 Một chu kỳ kiểm thử mẫu 103

5.5.4 Đảm bảo chất lượng phần mềm 104

Chương 6 SƯU LIỆU PHẦN MỀM 106

6.1 Tổng quan 106

6.2 Sưu liệu người dùng 106

6.2.1 Mô tả chức năng 107

6.2.2 Bảng Giới thiệu 107

Trang 7

Tài liệu giảng dạy môn: Công nghệ phần mềm v

6.2.3 Bảng tham khảo 107

6.2.4 Sưu liệu cài đặt 107

6.3 Sưu liệu hệ thống 108

6.4 Chất lượng của sưu liệu 109

6.5 Bảo trì sưu liệu 109

Chương 7 QUẢN LÝ DỰ ÁN PHẦN MỀM 111

7.1 Khái niệm dự án, dự án CNTT 111

7.1.1 Khái niệm dự án 111

7.1.2 Dự án Công nghệ thông tin 112

7.1.3 Đặc trưng của một dự án 112

7.1.4 Mục tiêu của dự án 112

7.2 Quy trình quản lý dự án 112

7.2.1 Khởi tạo dự án 113

7.2.2 Lập kế hoạch dự án 113

7.2.3 Triển khai 113

7.2.4 Giám sát và kiểm soát 113

7.2.5 Kết thúc 113

7.2.6 Các hoạt động chính trong quản lý dự án phần mềm 113

7.2.7 Mục đích của quản lý dự án 115

7.2.8 Phương pháp luận và kỹ thuật quản lý dự án 116

7.2.9 Nguyên nhân khiến dự án thất bại 116

7.3 Các nhiệm vụ trong các hoạt động QLDA 118

7.3.1 Quản lý thời gian của dự án 118

7.3.2 Quản lý kinh phí của dự án 118

7.3.3 Quản lý nguồn nhân lực của dự án 118

7.3.4 Quản lý các kết quả chuyển giao của dự án 118

7.4 Phân loại dự án 118

7.5 Ước lượng 119

7.6 Quản lý nhân sự 120

7.7 Quản lý cấu hình 121

7.8 Quản lý rủi ro 122

Trang 8

Tài liệu giảng dạy môn: Công nghệ phần mềm 1

Chương 1 PHẦN MỀM VÀ CÔNG NGHỆ PHẦN MỀM

 Mục tiêu học tập: Sau khi học xong chương này người có thể:

- Trình bày tổng quan về phần mềm và công nghệ phần mềm

- Vận dụng các qui trình vào xây dựng các dự án phần mềm

Tóm tắt chương

Trong chương này, tài liệu sẽ cung cấp cho sinh viên một số khái niệm liên quan đến việc xây dựng một phần mềm Đồng thời còn cung cấp cho sinh viên biết cách chọn lựa những giải pháp với chi phí hợp lý cho các bài toán thực tế bằng cách áp dụng kiến thức về công nghệ để xây dựng những hệ thống phần mềm có chất lượng…

1.1 Phần mềm máy tính

1.1.1 Khái niệm

Phần mềm máy tính (Computer Software) hay gọi tắt là Phần mềm (Software) là

một tập hợp những câu lệnh hoặc chỉ thị được viết bằng một hoặc nhiều ngôn ngữ lập trình theo một trật tự xác định, và các dữ liệu hay tài liệu liên quan nhằm tự động thực hiện một số nhiệm vụ hay chức năng hoặc giải quyết một vấn đề cụ thể nào đó

Phần mềm thực hiện các chức năng của nó bằng cách gửi các chỉ thị trực tiếp đến phần

cứng máy tính (Computer Hardware) hoặc bằng cách cung cấp dữ liệu để phục vụ các

chương trình hay phần mềm khác

Một phần mềm mới có thể được tạo ra bằng cách phát triển các chương trình mới, thay đổi và điều chỉnh hoặc tái sử dụng lại các phần mềm đã tồn tại

1.1.2 Đặc điểm

Trước đây, để tạo ra chương trình máy tính người ta phải làm việc trực tiếp với các con

số 0 hoặc 1 (sử dụng hệ số nhị phân), hay còn gọi là ngôn ngữ máy Công việc này vô cùng khó khăn, mất nhiều thời gian, công sức và đặc biệt dễ gây ra lỗi Để khắc phục nhược điểm này, người ta đề xuất ra hợp ngữ, một ngôn ngữ cho phép thay thế dãy 0 hoặc 1 này bởi các từ gợi nhớ bằng tiếng Anh Tuy nhiên, cải tiến này vẫn còn chưa thật sự thích hợp với đa số người dùng máy tính, những người luôn mong muốn các lệnh chính là ý nghĩa của các thao tác mà nó mô tả Vì vậy, ngay từ những năm của thập niên 50, người ta đã xây dựng những ngôn ngữ lập trình mà câu lệnh của nó gần với ngôn ngữ tự nhiên Các ngôn ngữ này được gọi là ngôn ngữ lập trình bậc cao

Chương trình máy tính thường được tạo ra bởi con người, những người này được gọi là

Trang 9

lập trình viên, tuy nhiên cũng tồn tại những chương trình được sinh ra bởi các chương trình khác

1.1.3 Phân loại

a Theo phương thức hoạt động

Phần mềm hệ thống: Dùng để vận hành máy tính và các phần cứng máy tính, ví dụ như

các hệ điều hành máy tính Windows, Linux, Unix,… các thư viện động hay còn gọi là thư

viện liên kết động (Dynamic Linked Library - DLL) của hệ điều hành, các trình điều khiển (Driver), phần sụn (Firmware) và hệ thống xuất nhập cơ bản (Basic Input/Output System - BIOS ) Đây là các loại phần mềm mà hệ điều hành liên lạc với chúng để điều khiển

và quản lý các thiết bị phần cứng

Phần mềm ứng dụng: Dùng để người sử dụng có thể hoàn thành một hay nhiều công việc nào đó, ví dụ như các phần mềm hỗ trợ công tác văn phòng (Microsoft Office, OpenOffice ), phần mềm doanh nghiệp, phần mềm quản lý nguồn nhân lực, phần

mềm giáo dục, cơ sở dữ liệu, phần mềm trò chơi, chương trình tiện ích, hay các loại phần mềm độc hại

Các phần mềm dịch mã: Bao gồm trình biên dịch và trình thông dịch: các loại chương

trình này sẽ đọc các câu lệnh từ mã nguồn được viết bởi các lập trình viên theo một ngôn ngữ lập trình và dịch nó sang dạng ngôn ngữ máy mà máy tính có thể hiểu đươc, hay dịch nó sang

một dạng khác như là tập tin đối tượng (object file) và các tập tin thư viện (library file) mà

các phần mềm khác (như hệ điều hành chẳng hạn) có thể hiểu để vận hành máy tính thực thi các lệnh

b Theo khả năng ứng dụng

Những phần mềm không phụ thuộc: Nó có thể được bán cho bất kỳ khách hàng nào trên

thị trường tự do Ví dụ: phần mềm về cơ sở dữ liệu như Oracle, Phtoshop, Corel Draw, MS Office

Ưu điểm: Thông thường đây là những phần mềm có khả năng ứng dụng rộng rãi cho nhiều nhóm người sử dụng

Hạn chế: Thiếu tính uyển chuyển, tùy biến

Những phần mềm được viết theo đơn đặt hàng: Đây là dạng phần mềm được thực hiện

theo đơn đặt hàng hay hợp đồng của một khách hàng cụ thể nào đó (một công ty, bệnh viện, trường học )

Ưu điểm: Có tính uyển chuyển, tùy biến cao để đáp ứng được nhu cầu của một nhóm người sử dụng nào đó

Hạn chế: Thông thường đây là những phần mềm ứng dụng cho một chuyên ngành hẹp

Trang 10

c Các loại khác

Cũng là một loại phần mềm, nhưng virus máy tính là các phần mềm có hại được viết để chạy với những mục đích riêng của một nhóm người nhằm lừa đảo, quảng cáo, ăn cắp, phá hoại thông tin, phá hoại phần cứng hoặc chỉ là để trêu chọc người dùng

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

Sau khi đã có các khái niệm cơ bản nhất về phần mềm, tiếp sau đây chúng ta sẽ đi sâu vào tìm hiểu cấu trúc chi tiết các thành phần bên trong phần mềm Phần mềm bao gồm 3 thành phần chính:

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

Cho phép tiếp nhận các yêu cầu về việc muốn thực hiện và cung cấp các dữ liệu nguồn liên quan đến công việc đó hoặc từ các thiết bị thu thập dữ liệu Cho phép trình bày các kết quả của việc thực hiện các yêu cầu cho người dùng (kết quả của công việc khi thực hiện trên máy tính) hoặc điều khiển họat động các thiết bị điều khiển

Một cách tổng quát, thành phần giao tiếp là hệ thống các hàm chuyên về việc nhập/xuất dữ liệu (hàm nhập/xuất) cùng với hình thức trình bày và tổ chức lưu trữ dữ liệu tương ứng, mục tiêu chính của các hàm này là đưa dữ liệu từ thế giới bên ngoài phần mềm vào bên trong hoặc ngược lại

Trong tài liệu này chỉ giới hạn xét đến giao tiếp với người sử dụng phần mềm và khi

đó có tên gọi cụ thể hơn là thành phần giao diện

Trang 11

có thể lưu trữ lại qua thành phần dữ lịêu

Một cách tổng quát, thành phần xử lý là hệ thống các hàm chuyên về xử lý tính toán, biến đổi dữ liệu Các hàm này sẽ dùng dữ liệu nguồn từ các hàm trong thành phần giao diện (hàm nhập) hay thành phần dữ liệu (hàm đọc dữ liệu) kiểm tra tính hợp lệ (hàm kiểm tra) và sau đó tiến hành xử lý (hàm xử lý) nếu cần thiết để cho ra kết quả mà sẽ được trình bày cho người dùng xem qua các hàm trong thành phần giao diện (hàm xuất) hoặc lưu trữ lại qua các hàm trong thành phần dữ liệu (hàm ghi)

1.1.5 Quá trình tạo phần mềm

a Về mặt thiết kế

Tùy theo mức độ phức tạp của phần mềm, người thiết kế phần mềm sẽ ít nhiều dùng đến các phương tiện để tạo ra mẫu thiết kế theo ý muốn (chẳng hạn như là các sơ đồ khối, các lưu đồ, các thuật toán và các mã giả), sau đó mẫu này được mã hoá bằng các ngôn ngữ lập trình và được các trình dịch chuyển thành các khối lệnh (module) hay/và các tệp khả thi Tập hợp các tệp khả thi và các khối lệnh đó tạo thành một phần mềm Thường khi một phần mềm được tạo thành, để cho hoàn hảo thì phần mềm đó phải được điều chỉnh hay sửa chữa từ khâu thiết kế cho đến khâu tạo thành phiên bản phần mềm một số lần Một phần mềm thông thường sẽ tương thích với một hay vài hệ điều hành, tùy theo cách thiết kế, cách viết mã nguồn và ngôn ngữ lập trình được dùng

b Sản xuất và phát triển

Việc phát triển và đưa ra thị trường một phần mềm là đối tượng nghiên cứu của bộ

môn kỹ nghệ phần mềm hay còn gọi là công nghệ phần mềm (Software Engineering) Bộ

môn này nghiên cứu các phương pháp tổ chức, cách thức sử dụng nguồn tài nguyên, qui trình sản xuất, cùng với các mối liên hệ với thị trường, cũng như liên hệ giữa các yếu tố này với nhau Tối ưu hoá qui trình sản xuất phần mềm cũng là đối tượng được ưu tiên xem xét của bộ môn

1.2 Công nghệ phần mềm

1.2.1 Lịch sử ra đời

Vào những năm 1950, khi máy tính ra đời chính thức (không chỉ được dùng trong các phòng thí nghiệm mà bắt đầu ứng dụng trong họat động xã hội) các phần mềm đầu tiên cũng được ra đời với số lượng còn rất ít và chủ yếu phục vụ cho lĩnh vực tính toán (đặc biệt trong quốc phòng)

Đến những năm 1960, trãi qua 10 năm phát triển số lượng các phần mềm đã tăng lên rất nhiều và được ứng dụng rộng rãi trong nhiều lĩnh vực Vào thời điểm này phát sinh một vấn

đề mà các chuyên gia gọi là “cuộc khủng hoảng phần mềm” Cuộc khủng hoảng phần mềm

Trang 12

thể hiện 2 yếu tố chính:

- Số lượng các phần mềm tăng vọt (do sự phát triển của phần cứng: tăng khả năng, giá thành hạ)

- Có quá nhiều hạn chế trong các phần mềm được dùng trong xã hội

+ Thực hiện không đúng yêu cầu (tính toán sai, không ổn định…)

+ Thời gian bảo trì, nâng cấp quá lâu, tốn chi phí cao, hiệu quả thấp

+ Khó sử dụng

+ Thực hiện chậm

+ Khó chuyển đổi dữ liệu giữa các phần mềm…

- Việc tăng vọt của số lượng phần mềm là điều hợp lý và điều này sẽ còn tiếp diễn

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

+ Cảm tính: Mỗi người theo một phương pháp riêng

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

+ Thủ công: Công cụ hỗ trợ chính khi xây dựng phần mềm chỉ là trình biên dịch Với các kết luận như trên, hội nghị đã đề xuất khai sinh một ngành khoa học mới đó là

Công nghệ phần mềm với nhiệm vụ chính là nghiên cứu về các phương pháp tiến hành xây

dựng phần mềm

1.2.2 Định nghĩa

Công nghệ phần mềm là 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ế, cài đặt các sản phấm phần mềm đạt được đầy đủ các yêu cầu về chất lượng phần mềm

Do quá trình tiến hóa của ngành công nghệ phần mềm nên các khái niệm về nó cũng thay đổi theo thời gian Hơn nữa nó là một lĩnh vực mới nên phụ thuộc rất nhiều vào quan điểm chủ quan của mỗi người khác nhau:

- Bauer (1969) Việc thiết lập và sử dụng các nguyên lý công nghệ đúng đắn để thu được

phần mềm một cách kinh tế vừa tin cậy vừa hiệu quả trên các máy thực

- Ghezzi (1991) Là một lĩnh vực của khoa học máy tính liên quan đến việc xây dựng các

phần mềm vừa lớn vừa phức tạp bởi một hay một nhóm kỹ sư

- IEEE (1993) Việc áp dụng phương pháp tiếp cận có hệ thống, bài bản và lượng hóa

trong phát triển, vận hành và bảo trì phần mềm

- Sommervile (1995) Là lĩnh vực liên quan đến lý thuyết, phương pháp và công cụ dùng

cho phát triển phần mềm

Trang 13

- Pressman (1995) Là bộ môn tích hợp cả qui trình, các phương pháp, các công cụ để

phát triển phần mềm máy tính

Có thể định nghĩa tóm tắt về công nghệ phần mềm như sau: “công nghệ phần mềm là một ngành khoa học nghiên cứu về việc xây dựng các phần mềm có chất lượng trong khoảng thời gian và chi phí hợp lý”

1.2.3 Mục tiêu nghiên cứu

Mục tiêu nghiên cứu của Công nghệ phần mềm là tìm ra phương pháp, công cụ nhằm xây dựng phần mềm có chất lượng, trong thời gian và chi phí hợp lý

Công nghệ phần mềm là một quá trình gồm một loạt các bước chứa đựng 3 yếu tố chủ chốt:

a Các phương pháp

Chỉ ra cách làm về mặt kỹ thuật để xây dựng phần mềm, được sử dụng trong các bước: Lập kế hoạch, ước lượng dự án, phân tích yêu cầu hệ thống và phần mềm, thiết kế cấu trúc dữ liệu, kiến trúc chương trình các thủ tục và thuật toán, mã hóa, kiểm thử và bảo trì…

Các phương pháp cho công nghệ phần mềm thường dùng các ký pháp đồ họa hay hướng ngôn ngữ đặc biệt, cách thức thực hiện và một tập các tiêu chuẩn về chất lượng của sản phẩm phần mềm

b Các công cụ

Cung cấp sự hỗ trợ tự động hay bán tự động để phát triển phần mềm theo từng phương pháp khác nhau Khi các công cụ được tích hợp đến mức các thông tin do chúng tạo ra có thể được dùng cho các công cụ khác thì hệ thống hỗ trợ phát triển phần mềm đã được thiết lập và

còn được gọi là công nghệ phần mềm có máy tính hỗ trợ (CASE - Computer Aided Software Engineering)

c Các thủ tục

Các thủ tục là sự kết nối các phương pháp và công cụ lại với nhau làm cho chúng được sử dụng hợp lý và đúng hạn trong quá trình phát triển phần mềm Các thủ tục bao gồm:

- Xác định trình tự các phương pháp sẽ được áp dụng cho mỗi dự án

- Tạo ra sản phẩm cần bàn giao (tài liệu báo cáo, bản mẫu, ) cần cho việc kiểm soát để

Trang 14

đảm bảo chất lượng và điều hòa thay đổi

- Xác định những cột mốc mà tại thời điểm đó có các sản phẩm nhất định được bàn giao

để cho người quản lý phần mềm nắm được tiến độ và kiểm soát được kết quả

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

Hướng đến việc xây dựng các phần mềm có chất lượng như đã nêu, ngành công nghệ phần mềm đưa ra 3 đối tượng nghiên cứu chính: Qui trình công nghệ, Phương pháp phát triển, Công cụ và môi trường phát triển phần mềm

- Qui trình công nghệ phần mềm: Hệ thống các giai đoạn mà quá trình phát triển phần

mềm phải trải qua Với mỗi giai đoạn cần xác định rõ mục tiêu, kết quả nhận được từ giai đoạn trước đó cũng chính là kết quả chuyển giao cho giai đoạn kế tiếp

- Phương pháp phát triển phần mềm: Hệ thống các hướng dẫn cho phép từng bước thực

hiện một giai đoạn nào đó trong qui trình công nghệ phần mềm

- Công cụ và môi trường phát triển phần mềm: Hệ thống các phần mềm trợ giúp chính

trong lĩnh vực xây dựng phần mềm Các phần mềm này sẽ hỗ trợ các kỹ sư tin học trong các bước xây dựng phần mềm theo một phương pháp nào đó với một qui trình được chọn trước

1.3 Qui trình phát triển phần mềm

Để xây dựng được phần mềm có chất lượng quá trình phát triển phải trãi qua rất nhiều giai đoạn Mỗi giai đoạn có mục tiêu và kết quả chuyển giao xác định Trình tự thực hiện các giai đoạn này chính là chu kỳ sống của một phần mềm

Nói cách khác, chu kỳ sống của một phần mềm là khoảng thời gian mà trong đó một sản phẩm phần mềm được phát triển, sử dụng và mở rộng cho đến khi sản phẩm phần mềm

đó không còn được sử dụng nữa

Chu kỳ sống của phần mềm được phân chia được phân chia thành các pha chính như: Xác định, phát triển, kiểm thử, bảo trì (vận hành) Phạm vi và thứ tự các pha khác nhau tùy theo từng mô hình cụ thể

Có nhiều mô hình tiếp cận khác nhau để triển khai các bước cơ bản trong quá trình phát triển phần mềm Mỗi mô hình sẽ chia vòng đời của phần mềm theo một cách khác nhau nhằm đảm bảo qui trình phát triển phần mềm sẽ dẫn đến thành công

Sau đây, chúng ta sẽ xem xét một số cách tiếp cận (còn gọi là mô hình hay khuôn cảnh)

cơ bản trong tiến trình phát triển phần mềm

1.3.1 Mô hình vòng đời cổ điển (mô hình thác nước) (W aterfall Model)

Vào năm 1970 trong bài báo của mình, Royce đã mô tả ở dạng khái niệm cái mà ngày nay được công nhận với tên gọi “mô hình thác nước” Mô hình thác nước là một trong những

mô hình đầu tiên và phổ biến được áp dụng trong quá trình phát triển phần mềm Mô hình này

Trang 15

chia quá trình phát triển phần mềm thành những giai đoạn tuần tự nối tiếp nhau Qui trình phát triển này giống như một dòng chảy, với các pha được thực hiện theo trật tự nghiêm ngặt Mỗi giai đoạn sẽ có một mục đích nhất định Kết quả cuả giai đoạn trước sẽ là thông tin đầu vào cho giai đoạn tiếp theo Tùy theo qui mô của phần mềm cần phát triển mà mô hình thác nước sẽ có những biến thể khác nhau như sau:

* Qui trình 2 giai đoạn: Là qui trình đơn giản nhất Theo qui trình này việc phát triển

phần mềm chỉ trãi qua 2 giai đoạn:

i) Xác định yêu cầu: Được tiến hành ngay khi có yêu cầu về việc xây dựng phần mềm

+ Mục tiêu: Xác định chính xác các yêu cầu đặt ra cho phần mềm sẽ xây dựng

+ Kết quả nhận: Thông tin về hoạt động của thế giới thực

+ Kết quả chuyển giao: Danh sách các yêu cầu (công việc sẽ thực hiện trên máy tính) cùng với các thông tin miêu tả chi tiết về các yêu cầu (cách thức thực hiện trong thế giới thực)

ii) Lập trình (cài đặt): Được tiến hành ngay sau khi kết thúc việc xác định yêu cầu

+ Mục tiêu: Tạo lập phần mềm mong muốn theo yêu cầu

+ Kết quả nhận: Danh sách các yêu cầu cùng các thông tin có liên quan

+ Kết quả chuyển giao: Chương trình nguồn của phần mềm với cấu trúc cơ sở dữ liệu tương ứng (nếu cần thiết) và chương trình thực hiện được trên máy tính (chương trình nguồn

đã được biên dịch)

* Qui trình 3 giai đoạn: Là qui trình cải tiến của qui trình 2 giai đoạn bằng cách bổ sung

thêm một giai đoạn trung gian mới giữa xác định yêu cầu và lập trình (có sửa đổi)

ii) Thiết kế: Được tiến hành ngay sau khi kết thúc việc xác định yêu cầu

+ Mục tiêu: Mô tả các thành phần của phần mềm (mô hình của phần mềm) trước khi tiến hành cài đặt

+ Kết quả nhận: Danh sách các yêu cầu và thông tin liên quan

+ Kết quả chuyển giao:

Mô tả thành phần giao diện: Các hàm nhập/xuất, cấu trúc dữ liệu nhập/xuất

Mô tả thành phần xử lý: Các hàm kiểm tra xử lý

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

Trang 16

iii) Lập trình (cài đặt): Được tiến hành ngay sau khi 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 quả nhận: Mô hình phần mềm

* Qui trình 4 giai đoạn: Là qui trình cải tiến của qui trình phía trước bằng cách bổ sung

thêm một giai đoạn mới giữa xác định yêu cầu và thiết kế (có sửa đổi)

ii) Phân tích: Được tiến hành ngay sau khi kết thúc việc xác định yêu cầu

+ Mục tiêu: Mô tả lại thế giới thực thông qua các mô hình (mô hình thế giới thực) trước khi thiết kế

Mô hình xử lý (hệ thống các công việc trong thế giới thực cùng với quan hệ giữa chúng)

Mô hình dữ liệu (hệ thống các loại thông tin được sử dụng trong thế giới thực cùng với quan hệ giữa chúng)

Các mô hình khác (không gian, thời gian, con người…) nếu cần thiết

iii) Thiết kế: Được tiến hành ngay sau khi kết thúc việc phân tích

+ Kết quả nhận: Mô hình thế giới thực

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

iv) Lập trình (cài đặt): Được tiến hành ngay sau khi kết thúc việc thiết kế

Trang 17

* Qui trình 5 giai đoạn: Qui trình này gộp giai đoạn xác định và phân tích thành 1 giai

đoạn Cải tiến lại qui trình phía trước bằng cách bổ sung thêm một giai đoạn mới sau giai đoạn lập trình nhằm tăng cường độ tin cậy của phần mềm

i) Xác định yêu cầu: Được tiến hành ngay khi có nhu cầu về việc xây dựng phần mềm

ii) Phân tích: Được tiến hành ngay sau khi kết thúc việc xác định yêu cầu

+ Mục tiêu: Mô tả lại thế giới thực thông qua các mô hình (mô hình thế giới thực) trước khi thiết kế

Mô hình xử lý (hệ thống các công việc trong thế giới thực cùng với quan hệ giữa chúng)

Mô hình dữ liệu (hệ thống các loại thông tin được sử dụng trong thế giới thực cùng với quan hệ giữa chúng)

Các mô hình khác (không gian, thời gian, con người…) nếu cần thiết

iii) Thiết kế: Được tiến hành ngay sau khi kết thúc việc phân tích

+ Kết quả nhận: Mô hình thế giới thực

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

iv)Lập trình (cài đặt): Được tiến hành ngay sau khi kết thúc việc thiết kế

Trang 18

v)Kiểm thử: Được tiến hành ngay sau khi đã có kết quả (từng phần) của việc lập trình

+ Mục tiêu: Tăng độ tin cậy của phần mềm

+ Kết quả nhận:

Danh sách yêu cầu

Mô hình phần mềm

Phần mềm

+ Kết quả chuyển giao: Phần mềm với độ tin cậy cao (đã tìm và sửa lỗi)

vi) Bảo trì và phát triển: Công việc của giai đoạn bao gồm việc cài đặt và vận hành

Hơn nữa, khách hàng hiếm khi phát biểu hết các yêu cầu trong giai đoạn phân tích

Mô hình này cũng có một hạn chế là chúng ta rất khó thực hiện các thay đổi một khi đã thực hiện xong một giại đoạn nào đó Điều này làm cho việc xây dựng phần mềm rất khó thay đổi các yêu cầu theo ý muốn của khách hàng Do đó, phương pháp này chỉ thích hợp cho những trường hợp mà chúng ta đã hiểu rất rõ các yêu cầu của khách hàng

Trang 19

Chú ý: Mô hình thác nước có thể được cải tiến bằng cách cho phép quay lui khi phát

hiện lỗi trong giai đoạn phía trước Tuy nhiên, càng đến giai đoạn cuối mà phát hiện lỗi xuất phát từ những giai đoạn đầu thì chi phí và thời gian khắc phục, sửa đổi rất tốn kém Chính vì vậy, chúng ta cần thực hiện chính xác, đầy đủ từ giai đoạn đầu

1.3.2 Mô hình làm bản mẫu (Prototype)

Cách tiếp cận làm bản mẫu là cách tiếp cận tốt nhất khi:

- Mục tiêu tổng quát cho phần mềm đã xác định, nhưng chưa xác định được rõ được đầu

vào (Input) và đầu ra (Output)

- Người phát triển chưa chắc chắn về hiệu quả của thuật toán, về tính thích nghi với hệ điều hành hay giao diện người - máy cần có

Khi đã có bản mẫu, người phát triển có thể dùng chương trình đã có hay các công cụ phần mềm trợ giúp để sinh ra chương trình làm việc

Làm bản mẫu là tạo ra một mô hình cho phần mềm cần xây dựng Mô hình có thể có 3 dạng:

1 Bản mẫu trên giấy hay trên máy tính, mô tả giao diện người-máy nhằm mục đích làm cho người dùng hiểu được cách các tương tác xuất hiện

2 Bản mẫu cài đặt chỉ một tập con chức năng của phần mềm mong đợi

3 Bản mẫu là một chương trình có thể thực hiện một phần hay tất cả chức năng mong muốn nhưng ở mức sơ lược và cần cải tiến thêm các tính năng khác tùy theo khả năng phát triển

Trước hết người phát triển và khách hàng gặp nhau và xác định mục tiêu tổng thể cho phần mềm, xác định các yêu cầu đã biết, các miền cần khảo sát thêm Tiếp theo là giai đoạn thiết kế nhanh, tập trung vào việc biểu diễn các khía cạnh của phần mềm thấy được đối với

người dùng (input và output), và xây dựng một bản mẫu Người dùng đánh giá và làm mịn

các yêu cầu cho phần mềm Tiến trình này lặp đi lặp lại cho đến khi bản mẫu thoả mãn yêu cầu của khách hàng, đồng thời giúp người phát triển hiểu kỹ hơn nhu cầu nào cần phải thực

hiện (hình 1.2)

Một biến thể của mô hình này là mô hình thăm dò, trong đó các yêu cầu được cập nhật liên tục và bản mẫu được tiến hóa liên tục để trở thành sản phẩm cuối cùng

Mô hình làm bản mẫu có một số vấn đề như:

• Do sự hoàn thiện dần (tiến hóa) của bản mẫu, phần mềm nhiều khi có tính cấu trúc

không cao, dẫn đến khó kiểm soát, khó bảo trì

• Khách hàng nhiều khi thất vọng với việc phát triển phần mềm do họ nhầm tưởng bản mẫu là sản phẩm cuối cùng hướng tới người sử dụng Khách hàng cũng có thể không dành

Trang 20

nhiều thời gian và công sức vào việc đánh giá bản mẫu

Hình 1.2: Mô hình làm bản mẫu

1.3.3 Mô hình xoắn ốc

Mô hình xoắn ốc được Boehm đưa ra năm 1988 Mô hình này đưa thêm vào việc phân tích yếu tố rủi ro Quá trình phát triển được chia thành nhiều bước lặp lại, mỗi bước bắt đầu bằng việc phân tích rủi ro rồi tạo bản mẫu, cải tạo và phát triển bản mẫu, duyệt lại, và cứ thế

tiếp tục (hình 1.3)

Nội dung một bước gồm bốn hoạt động chính:

- Lập kế hoạch: Xác định mục tiêu, các giải pháp và ràng buộc

- Phân tích rủi ro: Phân tích các phương án và xác định/giải quyết rủi ro

- Kỹ nghệ: Phát triển sản phẩm “mức tiếp theo”

- Đánh giá: Đánh giá của khách hàng về kết quả của kỹ nghệ

Với mỗi lần lặp xoắn ốc (bắt đầu từ tâm), các phiên bản được hoàn thiện dần Nếu phân

tích rủi ro chỉ ra rằng yêu cầu không chắc chắn thì bản mẫu có thể được sử dụng trong giai đoạn kỹ nghệ; các mô hình và các mô phỏng khác cũng được dùng để làm rõ hơn vấn đề và làm mịn yêu cầu

Tại một vòng xoắn ốc, phân tích rủi ro phải đi đến quyết định “tiếp tục hay dừng” Nếu

Tổng hợp yêu cầu

Thiết kế nhanh

Xây dựng bản mẫu

Đánh giá của khách hàng Làm mịn

yêu cầu

Trang 21

không có kế hoạch của mô hình làm bản mẫu (thăm dò)

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

1.3.4 Kỹ thuật thế hệ thứ tư

Thuật ngữ kỹ thuật thế hệ thứ tư (4GT - Fourth Generation Technology) bao gồm một

phạm vi rộng các công cụ phần mềm, có các điểm chung sau:

1 Cho phép người phát triển xác định một số đặc trưng của phần mềm ở mức cao

2 Tự động sinh ra mã chương trình gốc theo nhu cầu của người phát triển

Hiển nhiên là phần mềm được biểu diễn ở mức trừu tượng càng cao thì chương trình có thể được xây dựng càng nhanh hơn Mô hình 4GT đối với kỹ nghệ phần mềm tập trung vào khả năng xác định phần mềm đối với một máy ở mức độ gần với ngôn ngữ tự nhiên hay dùng một ký pháp khác đem lại chức năng có ý nghĩa

Hiện tại, một môi trường phát triển phần mềm hỗ trợ cho khuôn cảnh 4GT bao gồm một

số hay tất cả các công cụ sau:

1 Ngôn ngữ phi thủ tục để truy vấn cơ sở dữ liệu

2 Bộ sinh báo cáo

Trang 22

Mỗi một trong những công cụ này đã tồn tại, nhưng chỉ cho vài lĩnh vực ứng dụng đặc thù Ví dụ như các tính năng macro trong các phần mềm bảng tính, cơ sở dữ liệu, khả năng tự

sinh mã trong các công cụ thiết kế giao diện “kéo - thả”

Với những ứng dụng nhỏ, có thể chuyển trực tiếp từ bước thu thập yêu cầu sang cài đặt bằng công cụ 4GT Tuy nhiên với những hệ thống lớn, cần phải có một chiến lược thiết kế

Việc dùng 4GT thiếu thiết kế (với các dự án lớn) sẽ gây ra những khó khăn như chất lượng

kém, khó bảo trì khiến cho người dùng khó chấp nhận

Vẫn còn nhiều tranh cãi xung quanh việc dùng khuôn cảnh 4GT:

- Người ủng hộ cho rằng mô hình 4GT làm giảm đáng kể thời gian phát triển phần mềm

và làm tăng rất nhiều hiệu suất của người xây dựng phần mềm

- Những người phản đối cho rằng các công cụ của mô hình 4GT hiện tại không phải tất

cả đều dễ dùng hơn các ngôn ngữ lập trình, chương trình gốc do các công cụ này tạo ra là không hiệu quả, và việc bảo trì các hệ thống phần mềm lớn được phát triển bằng cách dùng 4GT lại mở ra vấn đề mới

Có thể tóm tắt hiện trạng của cách tiếp cận 4GT như sau:

1 Lĩnh vực ứng dụng hiện tại cho 4GT mới chỉ giới hạn vào các ứng dụng hệ thông tin nghiệp vụ, đặc biệt, việc phân tích thông tin và làm báo cáo là nhân tố chủ chốt cho các cơ sở

dữ liệu lớn Tuy nhiên, cũng đã xuất hiện các công cụ CASE mới hỗ trợ cho việc dùng 4GT

để tự động sinh ra khung chương trình

2 Đối với các ứng dụng vừa và nhỏ: Thời gian cần cho việc tạo ra phần mềm được giảm đáng kể và khối lượng phân tích/thiết kế cũng được rút bớt

3 Đối với ứng dụng lớn: Các hoạt động phân tích, thiết kế và kiểm thử chiếm phần lớn thời gian và việc loại bỏ bớt lập trình bằng cách dùng 4GT nhiều khi đem lại hiệu quả không đáng kể so với tính rườm rà, kém hiệu quả của phần mềm xây dựng bằng phương pháp này Tóm lại, 4GT đã trở thành một phần quan trọng của việc phát triển phần mềm nghiệp vụ

và rất có thể sẽ được sử dụng rộng rãi trong các miền ứng dụng khác trong thời gian tới

1.3.5 Mô hình lập trình cực đoan

Lập trình cực đoan (XP - eXtreme Programming) do Kent Beck đề xuất là một phương

pháp tiếp cận mới cho phát triển phần mềm XP đưa ra nhiều hướng dẫn mới, đôi khi trái ngược lại với các cách thức phát triển phần mềm được đề xuất từ trước đến nay

Hai khái niệm độc đáo mới và quan trọng hàng đầu trong XP là “tạo các ca thử nghiệm trước” và “lập trình đôi”

a Tạo các ca thử nghiệm trước

Thông thường, thử nghiệm (và trước đó là tạo ca thử nghiệm) được tiến hành vào giai

Trang 23

đoạn cuối của quá trình phát triển, khi đã có mã nguồn và chuyển sang kiểm chứng tính đúng đắn của nó Nhiều trường hợp việc kiểm thử không được coi trọng và chỉ được tiến hành khi còn thời gian và kinh phí

XP thay đổi quan niệm này bằng cách đặt cho kiểm thử một tầm quan trọng ngang bằng

(có thể là lớn hơn) việc viết mã Các ca kiểm thử được thiết kế trước khi viết mã và phải được

thực hiện thành công mỗi khi chương trình đích được tạo ra

Tạo ca thử nghiệm trước đem lại nhiều lợi thế Thứ nhất, nó giúp chúng ta xác định một cách rõ ràng giao diện của module Hơn thế, để tạo được ca thử nghiệm, chúng ta cần phải hiểu rõ chức năng của nó Tức là, XP yêu cầu chúng ta phải hiểu một cách rõ ràng các yêu cầu của modun trước khi chúng ta bắt tay vào phát triển nó

b Lập trình đôi (Pair Programming)

XP đưa ra khái niệm mang tính cách mạng (và trái ngược lại quan niệm từ trước đến nay) là mã nguồn của một module phải được viết bởi 2 lập trình viên dùng chung một máy

tính

Giá trị của lập trình đôi là trong khi một người viết mã thì người thứ hai nghĩ về nó

Người thứ hai này sẽ có trong đầu một bức tranh tổng thể về vấn đề cần giải quyết, chứ không chỉ là giải pháp của đoạn mã lúc đó Điều này sẽ gián tiếp đảm bảo một chất lượng tốt hơn và dẫn tới một giải pháp mang tính tổng thể hơn Đồng thời, điều này giúp cho họ theo

được các chỉ dẫn của XP, đặc biệt là việc “tạo ca thử nghiệm trước”

Nếu chỉ một người lập trình, họ sẽ rất dễ từ bỏ việc này, nhưng với hai người lập trình cùng làm việc thì họ có thể thay đổi cho nhau và giữ được các nguyên tắc của XP

1.3.6 Tổ hợp các mô hình

Chúng ta đã xem xét các mô hình kỹ nghệ phần mềm như là các cách tiếp cận khác nhau tới

kỹ nghệ phần mềm chứ không phải là các cách tiếp cận bổ sung cho nhau

Tuy nhiên trong nhiều trường hợp chúng ta có thể và cũng nên tổ hợp các khuôn cảnh

để đạt được sức mạnh của từng khuôn cảnh cho một dự án riêng lẻ

Ví dụ, khuôn cảnh xoắn ốc thực hiện điều này một cách trực tiếp, tổ hợp cả làm bản mẫu và các yếu tố của vòng đời cổ điển trong một cách tiếp cận tiến hóa tới kỹ nghệ phần mềm Các kỹ thuật thế hệ thứ tự có thể được dùng để cài đặt bản mẫu hay cài đặt hệ thống sản xuất trong bước mã hóa của vòng đời cổ điển Chúng ta có thể làm bản mẫu trong bước phân tích của mô hình vòng đời cổ điển

Kết luận ở đây là chúng ta không nên bị lệ thuộc với bất cứ khuôn cảnh cụ thể nào Tính chất và qui mô của phần mềm cần phát triển sẽ là yếu tố quyết định tới chọn khuôn cảnh Mỗi cách tiếp cận đều có ưu điểm riêng và bằng cách tổ hợp khéo léo các cách tiếp cận thì chúng

Trang 24

ta sẽ có một phương pháp hỗn hợp ưu việt hơn các phương pháp được dùng độc lập

Hình 1.4: Tổ hợp các mô hình

1.3.7 Tính khả thị của quá trình

Do đặc điểm là các phần tử logic nên quá trình phát triển phần mềm rất khó kiểm soát

Người ta tìm cách khắc phục vấn đề này bằng cách làm cho quá trình phát triển trở nên

“nhìn thấy được”, tức là ở mỗi bước (hoạt động) trong tiến trình phát triển phải tạo ra bằng

một sản phẩm hay tài liệu tương ứng

Người quản lý dự án và cả khách hàng sẽ tiến hành xét duyệt các tài liệu này Các tài liệu sẽ trở nên rất hữu ích cho công đoạn kiểm thử và nâng cấp phần mềm

Ví dụ, đối với hoạt động phân tích chúng ta có các tài liệu như: Báo cáo nghiên cứu khả thi, mô hình hệ thống, phác họa yêu cầu, đặc tả yêu cầu

Chúng ta hãy so sánh tính khả thị của các khuôn cảnh đã biết:

- Vòng đời cổ điển có tính khả thị cao do các bước phát triển tường minh, mô hình xoắn

ốc cũng có tính khả thị tốt

- Đối với mô hình làm bản mẫu, nếu tần số sửa chữa lớn thì tính khả thị kém và việc tạo

ra tài liệu là không hiệu quả

- 4GT thì mới chỉ được dùng với những ứng dụng nghiệp vụ đặc thù nên khó phát biểu

Tổng hợp yêu cầu ban đầu

Phân tích

yêu cầu

Làm bản mẫu

Mã hóa

Kiểm thử

Hệ thống hoạt động

Bảo trì 4GT

Trang 25

gì về tính khả thị của nó

Việc xây dựng tài liệu cũng có những vấn đề như:

- Tạo ra các chi phí phụ làm chậm tiến trình phát triển

- Khi phát hiện vấn đề về thiết kế, nhiều khi do không muốn thay đổi các tài liệu đã được xét duyệt, người phát triển có xu hướng dùng các giải pháp cục bộ không hiệu quả

Các mô hình phát triển truyền thống thường chú trọng tới khâu lập tài liệu để nâng cao

tính khả thị Ngược lại, mô hình lập trình cực đoan (XP) lại không khuyến khích việc tạo

nhiều tài liệu

1.3.8 Vấn đề giảm kích cỡ của phần mềm

Như chúng ta đã biết, phần mềm hiện nay càng lớn, càng phức tạp Một mặt, năng lực của nhóm lập trình không phải là tuyến tính so với năng lực của từng cá nhân Độ phức tạp cũng tăng theo cấp số nhân, kéo theo chi phí cũng tăng theo cấp số nhân so với kích cỡ của chương trình cần phát triển

Do đó, việc tìm cách giảm kích cỡ, độ phức tạp của chương trình là ưu tiên hàng đầu của công nghệ phần mềm Tại các bước phân tích thiết kế, giảm kích cỡ được thực hiện thông

qua áp dụng chiến lược “chia để trị” Tức là chúng ta chia phần mềm thành các module con

có tính độc lập cao Độ phức tạp của từng module sẽ nhỏ hơn nhiều so với cả hệ thống, các module con cũng có thể được phát triển song song

Tại giai đoạn mã hóa, giảm kích cỡ có thể thực hiện được thông qua các phương thức như:

- Dùng lại: Dùng lại các thư viện đã phát triển, các thư viện thương mại

- Tự sinh mã: Sử dụng các công cụ tự động hỗ trợ kỹ nghệ phần mềm (visual modeling tools, GUI builders, CASE tools )

- Kỹ thuật hướng đối tượng: Kỹ thuật hướng đối tượng hỗ trợ phát triển module có tính dùng lại cao nhờ có cơ chế che dấu thông tin và khả năng kế thừa

- Dùng các ngôn ngữ bậc cao (các ngôn ngữ có cấu trúc và năng lực biểu diễn cao)

1.4 Cái nhìn chung về công nghệ phần mềm

Tiến trình phát triển công nghệ phần mềm chứa ba giai đoạn chính bất kể mô hình công

nghệ phần mềm nào được chọn lựa Ba giai đoạn này là xác định, phát triển và bảo trì, được

gặp phải trong mọi dự án phát triển phần mềm, bất kể tới miền ứng dụng, kích cỡ và độ phức tạp

Giai đoạn xác định tập trung vào khái niệm cái gì Tức là trong khi xác định, người phát

triển phần mềm cố gắng tập trung vào xác định thông tin nào cần được xử lý, chức năng và hiệu năng nào là cần có, giao diện nào cần được thiết lập, ràng buộc thiết kế nào hiện có và tiêu

Trang 26

chuẩn hợp lệ nào cần có để xác định ra một hệ thống thành công

Yêu cầu chủ chốt của hệ thống và phần mềm cũng được xác định Mặc dù các phương pháp được áp dụng trong giai đoạn xác định thay đổi tùy theo mô hình công nghệ phần mềm

(hay tổ hợp các mô hình) được áp dụng, có ba bước riêng vẫn xuất hiện dưới dạng:

1 Phân tích hệ thống: Phân tích hệ thống xác định ra vai trò của từng phần tử trong một

hệ thống dựa trên máy tính, tức là vạch ra vai trò mà phần mềm (cần phát triển) sẽ giữ

2 Lập kế hoạch dự án phần mềm: Một khi vai trò của phần mềm đã được thiết lập, rủi

ro đã được phân tích, tài nguyên đã được cấp phát, chi phí đã được ước lượng thì phải xác định cụ thể các công việc cần thực hiện và lập lịch thực hiện chúng

3 Phân tích yêu cầu: Trong bước phân tích hệ thống chúng ta chỉ xác định được vai trò

chung của phần mềm Sau khi đã chính thức quyết định phát triển phần mềm, chúng ta cần phải phân tích để xác định chi tiết lĩnh vực thông tin, các chức năng cũng như các ràng buộc khi vận hành của phần mềm Phân tích yêu cầu là khâu kỹ thuật quan trọng đầu tiên để đảm

bảo chất lượng (tính đáng tin cậy) của phần mềm Nếu xác định sai yêu cầu thì các bước kỹ

thuật khác có tốt đến đâu thì phần mềm cũng sẽ không được đưa vào sử dụng

Giai đoạn phát triển tập trung vào khái niệm thế nào Tức là, trong giai đoạn này người

phát triển phần mềm từng bước xác định cách cấu trúc dữ liệu và kiến trúc phần mềm cần xây

dựng, cách các chi tiết thủ tục được cài đặt, cách dịch thiết kế vào ngôn ngữ lập trình (hay ngôn ngữ phi thủ tục) và cách thực hiện kiểm thử Phương pháp được áp dụng trong giai đoạn

phát triển sẽ thay đổi tùy theo mô hình nhưng có ba bước đặc thù bao giờ cũng xuất hiện dưới dạng:

1 Thiết kế phần mềm: Là quá trình “dịch” các yêu cầu phần mềm thành một tập các

biểu diễn (dựa trên đồ họa, bảng, hay ngôn ngữ), mô tả cho cấu trúc dữ liệu, kiến trúc, thủ tục

thuật toán và đặc trưng giao diện

2 Mã hóa: Các biểu diễn thiết kế phải được biểu diễn bởi một (hay một vài) ngôn ngữ nhân tạo (ngôn ngữ lập trình qui ước hay ngôn ngữ phi thủ tục được dùng trong khuôn cảnh 4GT) mà sẽ tạo ra kết quả là các lệnh thực hiện được trên máy tính

3 Kiểm thử phần mềm: Một khi phần mềm đã được cài đặt dưới dạng máy thực hiện

được, cần phải kiểm thử nó để phát hiện các lỗi phân tích, thiết kế, cài đặt và đánh giá tính hiệu quả

Giai đoạn bảo trì tập trung vào những thay đổi gắn với việc sửa lỗi, thích ứng khi môi

trường phần mềm tiến hóa và sự nâng cao gây ra bởi sự thay đổi yêu cầu của người dùng Giai đoạn bảo trì áp dụng lại các bước của giai đoạn xác định và phát triển, nhưng là việc thực hiện trong hoàn cảnh phần mềm hiện có Có ba kiểu thay đổi gặp phải trong giai đoạn bảo trì:

Trang 27

1 Sửa đổi: Cho dù có các hoạt động bảo đảm chất lượng tốt nhất, vẫn có thể là khách

hàng sẽ phát hiện ra khiếm khuyết trong phần mềm Bảo trì sửa đổi làm thay đổi phần mềm

để sửa các khiếm khuyết (lỗi lập trình, thuật toán, thiết kế )

2 Thích nghi: Qua thời gian, môi trường ban đầu (như CPU, hệ điều hành, thiết bị

ngoại vi) để phát triển phần mềm có thể sẽ thay đổi Bảo trì thích nghi thực hiện việc sửa đổi phần mềm để thích hợp với những thay đổi môi trường ngoài

3 Nâng cao: Khi phần mềm được dùng, khách hàng/người dùng sẽ nhận ra những chức

năng phụ sẽ có lợi Bảo trì hoàn thiện mở rộng phần mềm ra ngoài các yêu cầu chức năng gốc của nó

1.5 Một số phương pháp xây dựng phần mềm

Để tiến hành xây dựng một phần mềm, chúng ta có thể áp dụng nhiều phương pháp khác nhau Mỗi phương pháp có những ưu điểm và hạn chế riêng và phù hợp với từng loại phần mềm cụ thể

Mỗi phương pháp sẽ có những hướng dẫn cụ thể các công việc cần phải thực hiện trong từng giai đoạn trong qui trình xây dựng phần mềm Bên cạnh đó, mỗi phương pháp cũng sẽ qui định những cách thức khác nhau để trình bày các kết quả thu được trong quá trình xây dựng phần mềm Những qui định này có tính chất như là ngôn ngữ thống nhất để các thành viên tham gia xây dựng phần mềm có thể trao đổi thông tin trong việc xây dựng phần mềm

1.5.2 Phân loại

Các phương pháp xây dựng phần mềm được chia làm 02 nhóm khác nhau dựa vào tính chất của công việc cần thực hiện

Phương pháp xây dựng:

• Phương pháp hướng chức năng;

• Phương pháp hướng dữ liệu;

• Phương pháp 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 lịch và theo dõi kế hoạch triển khai

1.5.3 Cách tiếp cận

a) Từ trên xuống

Trang 28

Đây là cách giải quyết 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, chúng ta bắt đầu với những thành phần chính của hệ thống Sau đó, các thành phần này sẽ được phân tích thành các thành phần chi tiết và cụ thể hơn Quá trình phân tích này sẽ kết thúc khi các kết quả thu được có mức độ phức tạp đúng với ý muốn của nhà xây dựng phần mềm

b) Từ dưới lên

Ngược lại với phương pháp từ trên xuống, phương pháp từ dưới lên là cách giải quyết vấn đề theo hướng tổng hợp Với phương pháp này, chúng ta tiến hành xây dựng những thành phần chi tiết, cụ thể mà chúng ta dự tính là sẽ có trong hệ thống Sau đó, các nhà phát triển phần mềm sẽ tiến hành kết hợp các thành phần chi tiết này lại với nhau để tạo nên các thành phần chính mà hệ thống cần phải có

1.5.4 Cách tiến hành

a) Phương pháp hướng chức năng

Với phương pháp này công việc xây dựng phần mềm được thực hiện dựa trên các

chức năng mà hệ thống cần thực hiện Hay nói cách khác chúng ta chú trọng đến thành phần

xử lý của hệ thống:

• Các thao tác tính toán

• Các thao tác phát sinh

• Các thao tác biến đổi…

Phương pháp chung để giải quyết vấn đề là á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, chúng ta sẽ chia các công việc lớn mà hệ thống cần thực hiện thành các công việc nhỏ hơn độc lập nhau Việc phân chia các công việc được tiến hành cho đến khi các công việc thu được đủ nhỏ để chúng ta có thể tiến hành xây dựng hoàn chỉnh

Phương pháp hướng chức năng chú trọng đến cách để giải quyết vấn đề nhưng không

có khả năng che dấu các thông tin trạng thái của hệ thống Điều này dẫn đến việc các chức năng của hệ thống không tương thích với nhau trong việc thực hiện thay đổi các thông tin trong hệ thống Chính vì vậy mà cách tiếp cận này chỉ thích hợp khi trong hệ thống có rất ít thông tin cần phải quản lý và chia sẻ giữa các chức năng với nhau Để mô hình hóa cách xử lý

thông tin trong hệ thống dùng lược đồ dòng dữ liệu (Data Flow Diagrams) DFD là một công

cụ đơn giản và hữu ích để miêu tả cách thức hoạt động của hệ thống

b) Phương pháp hướng dữ liệu

Ngược lại với phương pháp hướng chức năng, phương pháp hướng dữ liệu chú trọng

nhiều đến thành phần dữ liệu cần phải xử lý trong hệ thống:

Trang 29

• Tổ chức dữ 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 hướng dữ liệu chúng ta bắt đầu với việc thiết

kế các cấu trúc dữ liệu cần thiết có trong bài toán, sau đó mới tiến hành thiết kế các thao tác

để vận hành trên các cấu trúc dữ liệu đã thiết kế

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

Kết quả thu được sau khi thiết kế theo phương pháp hướng dữ liệu là mô hình thực thể

kết hợp (Entity Relationship Diagram) Một mô hình thực thể kết hợp điển hình gồm có 2

thành phần cơ bản là các thực thể và các mối kết hợp

• Một thực thể là một đối tượng trong thế giới thực mà hệ thống có quan hệ, hoặc tương tác qua lại

• Mối kết hợp biểu diễn sự kết hợp giữa hai hay nhiều thực thể

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

Phương pháp thiết kế hướng đối tượng là sự kết hợp của phương pháp hướng dữ liệu

và phương pháp hướng chức năng Phương pháp này chú trọng đến cả thành phần dữ liệu và chức năng của hệ thống

Theo phương pháp hướng đối tượng thì một hệ thống phần mềm là một tập hợp các đối tượng có khả năng tương tác với nhau Các đối tượng chính là các sự vật và hiện tượng vật lý cũng như trừu tượng mà chúng ta có trong thế giới thực Mỗi đối tượng có dữ liệu riêng được che dấu với thế giới bên ngoài và các thao tác mà đối tượng có thể thực hiện trên các thành phần dữ liệu của đối tượng

Các đối tượng liên lạc, trao đổi thông tin với nhau bằng cách gửi các thông điệp cho nhau Các thông điệp mà mỗi đối tượng có thể xử lý được gọi là giao diện của đối tượng Khi

đó mọi thao tác liên quan đến các đối tượng phải được thực hiện thông qua giao diện của đối tượng Điều này giúp chúng ta đảm bảo rằng các thông tin bên trong các đối tượng đưọc bảo

vệ một cách chắc chắn

Chúng ta có thể sử dụng nhiều hệ thống ký hiệu khác nhau để mô tả các đối tượng của

hệ thống cũng như mối liên hệ giữa chúng Một trong số các hệ thống ký hiệu phổ biến hiện

nay là hệ thống ký hiệu UML (Unified Modeling Language - Ngôn ngữ mô hình hóa thống

nhất)

Trang 30

UML sử dụng một hệ thống ký hiệu thống nhất biểu diễn các Phần tử mô hình (Model Elements) Tập hợp các phần tử mô hình tạo thành các sơ đồ UML (UML diagrams) Có các

loại sơ đồ UML chủ yếu sau:

- Sơ đồ lớp (Class Diagram);

- Sơ đồ đối tượng (Object Diagram);

- Sơ đồ tình huống sử dụng (Use Cases Diagram);

- Sơ đồ tuần tự (Sequence Diagram);

- Sơ đồ cộng tác (Collaboration Diagram hay là Composite Structure Diagram);

- Sơ đồ trạng thái (State Machine Diagram);

- Sơ đồ thành phần (Component Diagram);

- Sơ đồ hoạt động (Activity Diagram);

- Sơ đồ triển khai (Deployment Diagram);

- Sơ đồ gói (Package Diagram);

- Sơ đồ liên lạc (Communication Diagram);

- Sơ đồ tương tác (Interaction Overview Diagram - UML 2.0);

- Sơ đồ phối hợp thời gian (Timing Diagram - UML 2.0)

1.6 Công cụ và môi trường phát triển phần mềm

Các công cụ và môi trường phát triển phần mềm là các phần mềm hỗ trợ chính người phát triển trong quá trình xây dựng phần mềm Các phần mềm này có tên gọi chung là CASE

(Computer Aided Software Engineering) tools

Trong quá trình phát triển phần mềm theo các qui trình trên, các CASE tools có thể hỗ trợ cụ thể cho một giai đoạn nào đó hay cũng có thể hỗ trợ một số giai đoạn, trong trường hợp

này tên gọi chung thường là môi trường phát triển phần mềm - SDE (Software Development Environment)

Việc hỗ trợ của các CASE tools trong một giai đoạn bao gồm 2 hình thức chính:

- Cho phép lưu trữ, cập nhật trên kết quả chuyển giao với một phương pháp nào đó

- Cho phép phát sinh ra kết quả chuyển giao cho giao đoạn kế tiếp

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

- Công việc hỗ trợ chính

• Soạn thảo các mô hình thế giới thực;

• Ánh xạ vào mô hình logic

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

Trang 31

Phần mềm đã trở thành phần tử chủ chốt của các hệ thống máy tính Phát triển phần mềm

đã tiến hóa từ xây dựng một công cụ xử lý thông tin thành một ngành công nghiệp

Phần mềm là phần tử logic cho nên việc kiểm soát nó khó hơn nhiều so với phần tử vật

lý Khó có thể tối ưu hóa đồng thời các tính năng cần có của phần mềm Ví dụ, các tính năng như giao diện đồ họa dễ sử dụng và sự hoạt động hiệu quả, tiết kiệm tài nguyên hệ thống trong hầu hết các trường hợp là loại trừ lẫn nhau Thách thức lớn đối với việc phát triển phần mềm là chúng ta phải xây dựng phần mềm tốt theo một lịch trình và kinh phí định trước

Trang 32

Công nghệ phần mềm là một bộ môn tích hợp cả các phương pháp, công cụ và thủ tục

để phát triển phần mềm máy tính Có một số mô hình khác nhau cho công nghệ phần mềm, mỗi mô hình đều có những điểm mạnh và điểm yếu, nhưng nói chung tất cả đều có một dãy

các giai đoạn cơ bản là: Xác định, phát triển và bảo trì

 Câu hỏi và bài tập củng cố:

1) Nêu khái niệm, đặc điểm và phân loại phần mềm?

2) Phân biệt phần mềm và công nghệ phần mềm?

3) Trình bày các mô hình phát triển phần mềm? Nêu những ưu điểm và hạn chế của từng

mô hình?

4) Trình bày sự khác biệt của giai đoạn thiết kế trong các qui trình khác nhau?

5) Trình bày sự khác biệt của giai đoạn lập trình trong các qui trình khác nhau?

6) Khi tiến hành thực hiện phần mềm qua các giai đoạn (trong qui trình 5 giai đoạn) có thể phát sinh lỗi trong một giai đoạn nào đó (kết quả chuyển giao không chính xác, thiếu sót…) Theo các anh chị lỗi (nếu phát sinh) của giai đoạn nào là nghiêm trọng nhất? Vì sao?

7) Theo các anh chị trong các giai đoạn của qui trình công nghệ phần mềm:

- Giai đoạn nào là quan trọng nhất (tại sao)

- Giai đoạn nào dễ thực hiện nhất (tại sao)

- Giai đoạn nào là tốn nhiều thời gian và chi phí nhất (tại sao)

- Giai đoạn nào là có thể bỏ qua (trong trường hợp nào và tại sao)

Trang 33

Chương 2 PHÂN TÍCH VÀ ĐẶC TẢ YÊU CẦU

 Mục tiêu học tập: Sau khi học xong chương này người học có thể:

- Mô tả yêu cầu phần mềm

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

- Xác định các bước đặc tả yêu cầu, phân tích yêu cầu

- Viết đặc tả yêu cầu phần mềm

Tóm tắt chương

Trong các ngành kỹ thuật hệ thống và kỹ nghệ phần mềm, phân tích yêu cầu là công việc bao gồm các tác vụ xác định các yêu cầu cho một hệ thống mới hoặc được thay đổi, dựa trên cơ sở là các yêu cầu mà những người có vai trò quan trọng đối với hệ thống, chẳng hạn người sử dụng, đưa ra Việc phân tích yêu cầu có ý nghĩa quan trọng đối với thành công của một dự án

Việc phân tích yêu cầu một cách có hệ thống còn được gọi là kỹ nghệ yêu

cầu (Requirements Engineering) Đôi khi nó còn được gọi bằng những cái tên như thu thập yêu cầu (Requirements Gathering, Requirements Capture), hoặc đặc tả yêu cầu (Requirements Specification)

Các yêu cầu phải có tính đo được, kiểm thử được, có liên quan đến các nhu cầu hoặc cơ hội doanh nghiệp đã được xác định, và các yêu cầu phải được định nghĩa ở một mức độ chi tiết đủ cho việc thiết kế hệ thống

2.1 Đại cương về phân tích và đặc tả

Phân tích và định rõ yêu cầu là bước kỹ thuật đầu tiên trong tiến trình của công nghệ

phần mềm Công việc ở bước này là tìm hiểu xem chúng ta phải phát triển cái gì, chứ không

phải là phát triển như thế nào Đích cuối cùng của khâu phân tích là tạo ra tài liệu đặc tả yêu cầu, đây là tài liệu ràng buộc giữa khách hàng và người phát triển, và đó cũng là cơ sở của

hợp đồng

Hoạt động phân tích là hoạt động phối hợp giữa khách hàng và người phân tích (bên phát triển) Khách hàng phát biểu các yêu cầu của hệ thống cần phát triển Người phân tích

cần hiểu rõ, cụ thể hóa và biểu diễn lại yêu cầu

Hoạt động phân tích giữ một vai trò đặc biệt quan trọng trong phát triển phần mềm,

giúp cho đảm bảo chất lượng của phần mềm (phần mềm đáng tin cậy - có nghĩa là phải thực

hiện được chính xác, đầy đủ yêu cầu của người sử dụng

Nếu phân tích không tốt dẫn đến hiểu lầm yêu cầu thì việc sửa chữa sẽ trở nên rất tốn

Trang 34

kém Chi phí để sửa chữa sai sót về yêu cầu sẽ tăng lên gấp bội nếu như sai sót đó được phát hiện muộn

Việc phân tích, nắm bắt yêu cầu thường gặp các khó khăn như:

- Các yêu cầu thường mang tính đặc thù riêng của một tổ chức, do đó nó thường khó hiểu, khó định nghĩa và đôi khi không có chuẩn để biểu diễn

- Các hệ thống thông tin lớn có nhiều người sử dụng thì các yêu cầu thường rất đa dạng

và có các mức ưu tiên khác nhau, đôi khi mâu thuẫn lẫn nhau

- Người đặt hàng nhiều khi là các nhà quản lý, không phải là người dùng thực sự do đó việc phát biểu yêu cầu thường không đầy đủ và chính xác

Trong phân tích cần phân biệt giữa yêu cầu và mục tiêu của hệ thống Yêu cầu là một

đòi hỏi mà chúng ta có thể kiểm tra được còn mục tiêu là cái trừu tượng hơn mà chúng ta hướng tới

Ví dụ, giao diện của hệ thống phải thân thiện với người sử dụng là một mục tiêu và nó

tương đối không khách quan và khó kiểm tra Có nghĩa là với một phát biểu chung chung như vậy thì khách hàng và nhà phát triển khó định ra được một ranh giới rõ ràng để nói rằng phần mềm đã thỏa mãn được đòi hỏi đó Với một mục tiêu như vậy, một yêu cầu cho nhà phát triển

có thể là giao diện đồ họa mà các lệnh phải được chọn bằng menu…

Mục đích của giai đoạn phân tích là xác định rõ các yêu cầu của phần mềm cần phát triển

Tài liệu yêu cầu nên dễ hiểu với người dùng, đồng thời phải chặt chẽ để làm cơ sở cho hợp đồng và cho người phát triển dựa vào đó để xây dựng phần mềm Do đó yêu cầu thường được mô tả ở nhiều mức chi tiết khác nhau phục vụ cho các đối tượng đọc khác nhau Các mức đó có thể là:

• Định nghĩa (xác định) yêu cầu: Mô tả một cách dễ hiểu, vắn tắt về yêu cầu, hướng vào

đối tượng người đọc là người sử dụng, người quản lý

• Đặc tả yêu cầu: Mô tả chi tiết về các yêu cầu, các ràng buộc của hệ thống, phải chính xác, sao cho người đọc không hiểu nhầm yêu cầu, hướng vào đối tượng người đọc là các nhà

xây dựng phần mềm (người phát triển), các nhà quản trị hệ thống (sẽ làm việc bảo trì)

Các tài liệu yêu cầu cần được thẩm định để đảm bảo thỏa mãn nhu cầu người dùng Đây

là công việc bắt buộc để đảm bảo chất lượng phần mềm Đôi khi việc xác định đầy đủ các yêu cầu trước khi phát triển hệ thống là không thực tế và khi đó việc xây dựng các bản mẫu để nắm bắt yêu cầu là cần thiết

Trang 35

Hình 2.1: Quá trình hình thành các yêu cầu

2.2 Quá trình phân tích

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

Người phân tích hệ thống dùng thuật ngữ phạm vi để chỉ trách nhiệm dự án phải thực thi Ngược lại, phạm vi dự án là nhiệm vụ lớn và phức tạp được thực hiện bởi chương trình Để xác định phạm vi dự án, bằng xác định quá trình nghiệp vụ ứng dụng sẽ đối đầu Đó là những phạm vi vấn đề của ứng dụng Nói chung, có hai phần đối với bất kỳ giải pháp nghiệp vụ là phần triển khai ứng dụng và phần thực hiện bởi con người hay chương trình Định ra ranh giới ứng dụng tức là xác định qui trình trách nhiệm

Một khi đã định nghĩa trách nhiệm của dự án cần:

• Chia trách nhiệm thành những nhiệm vụ con để đưa ra ý tưởng cho chính mình về bao nhiêu module chương trình khác nhau yêu cầu?

• Xác định bao nhiêu vùng địa lý liên quan (chi nhánh văn phòng)

• Ước lượng số người dùng ứng dụng và thời gian ứng dụng được duy trì

• Tính chính xác

• Cuối cùng, hiểu khách hàng mong đợi gì ở dự án khi được triển khai

Tại thời điểm này, chúng ta có ý tưởng phạm vi dự án Cân nhắc độ lớn dự án đối với thời gian và ràng buộc ngân sách Nếu dự án quá lớn về thời gian và tiền bạc cho chi trả thì bàn bạc vấn đề với khách hàng để đưa ra quyết định thương lượng cho thõa đáng Chúng ta phải chọn lựa hoặc nhiều thời gian hơn, hoặc nhiều tiền hơn hoặc cả hai Hoặc chúng ta phải giảm phạm vi dự án xuống Phân tích tất cả những tình huống ở giai đoạn đầu của dự án sẽ làm cho dự án thành công nhiều hơn

2.2.2 Nghiên cứu khả thi

Đây là giai đoạn có tầm quan trọng đặc biệt, vì nó liên quan đến việc lựa chọn giải

Nghiên cứu khả thi

Phân tích yêu cầu

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

Đặc tả yêu cầu Báo cáo

khả thi Mô hình

hệ thống Tài liệu

định nghĩa yêu cầu

Tài liệu Yêu cầu

Tài liệu đặc tả yêu cầu

Trang 36

pháp Trong giai đoạn này người phân tích phải làm rõ được các điểm mạnh và điểm yếu của

hệ thống cũ (nếu có), đánh giá được mức độ, tầm quan trọng của từng vấn đề, định ra các vấn

đề cần phải giải quyết (ví dụ: những dịch vụ mới, thời hạn đáp ứng, hiệu quả kinh tế…) Sau

đó người phân tích phải định ra một vài giải pháp có thể (sơ bộ) và so sánh, cân nhắc những

ưu điểm, những hạn chế của các giải pháp đó (như tính năng của hệ thống, giá thành, bảo trì, đào tạo người sử dụng ) Đó chính là việc tìm ra một điểm cân bằng giữa nhu cầu và khả

năng đáp ứng

Mọi dự án đều khả thi khi nguồn tài nguyên vô hạn và thời gian vô hạn Nhưng việc xây

dựng hệ thống lại phải làm với sự hạn hẹp về tài nguyên và khó (nếu không phải là không hiện thực) bảo đảm đúng ngày bàn giao Phân tích khả thi và rủi ro có liên quan với nhau theo

nhiều cách Nếu rủi ro của dự án là lớn thì tính khả thi của việc chế tạo phần mềm có chất lượng sẽ bị giảm đi

Trong giai đoạn nghiên cứu khả thi, chúng ta tập trung vào bốn lĩnh vực quan trọng như:

1 Khả thi về kinh tế: Chi phí phát triển cần phải cân xứng với lợi ích mà hệ thống được

xây dựng đem lại Tính khả thi về kinh tế thể hiện trên các nội dung sau:

- Khả năng tài chính của tổ chức cho phép thực hiện dự án

- Lợi ích mà dự án phát triển HTTT mang lại đủ bù đắp chi phí phải bỏ để ra xây dựng

nó

- Tổ chức chấp nhận được những chi phí thường xuyên khi hệ thống hoạt động

Một thuật ngữ hay dùng để chỉ tài liệu nghiên cứu khả thi về kinh tế là luận chứng kinh

tế Luận chứng kinh tế nói chung được xem như nền tảng cho hầu hết các hệ thống (các ngoại

lệ là hệ thống quốc phòng, hệ thống luật, các hệ thống phục vụ cho các nghiên cứu đặc biệt) Luận chứng kinh tế bao gồm:

- Các mối quan tâm, nhất là phân tích chi phí/lợi ích

- Chiến lược phát triển dài hạn của công ty, đơn vị

- Sự ảnh hưởng tới các sản phẩm lợi nhuận khác

- Chi phí tài nguyên cần cho việc xây dựng và phát triển thị trường tiềm năng

2 Khả thi về kỹ thuật: Khảo cứu về chức năng, hiệu suất và ràng buộc có thể ảnh hưởng

tới khả năng đạt tới một hệ thống chấp nhận được Nói cách khác, khả thi kỹ thuật là xem xét khả năng kỹ thuật hiện tại có đủ đảm bảo thực hiện giải pháp công nghệ dự định áp dụng hay không

Khả thi kỹ thuật thường là lĩnh vực khó thâm nhập nhất tại giai đoạn phân tích

Điều thực chất là tiến trình phân tích và xác định nhu cầu cần được tiến hành song song

Trang 37

với việc xác nhận tính khả thi kỹ thuật Các xem xét thường được gắn với tính khả thi kỹ thuật bao gồm:

Rủi ro xây dựng: Liệu các phần tử hệ thống có thể được thiết kế sao cho đạt được chức năng và hiệu suất cần thiết thỏa mãn những ràng buộc trong khi phân tích không?

Có sẵn tài nguyên: Có sẵn các nhân viên cho việc xây dựng phần tử hệ thống đang xét

không? Các tài nguyên cần thiết khác (phần cứng và phần mềm) có sẵn cho việc xây dựng hệ

thống không?

Công nghệ: Công nghệ liên quan đã đạt tới trạng thái sẵn sàng hỗ trợ cho hệ thống chưa?

3 Khả thi về pháp lý: Nghiên cứu và đưa ra phán quyết về có hay không sự xâm phạm, vi

phạm pháp luật hay khó khăn pháp lý từ việc xây dựng và vận hành hệ thống?

Tính khả thi pháp lý bao gồm một phạm vi rộng các mối quan tâm kể cả hợp đồng, nghĩa vụ pháp lý, sự vi phạm và vô số các bẫy pháp lý khác mà thường là các nhân viên kỹ thuật không biết tới Trong nước, vấn đề khả thi về pháp lý vẫn chưa được coi trọng một cách đúng mức mặc dù đã có một số luật liên quan đến CNTT và bảo hộ bản quyền…

4 Tính khả thi về hoạt động: Đánh giá tính khả thi của việc vận hành hệ thống

Trong mỗi phương án người ta cần xem xét hệ thống có thể vận hành thuận lợi hay

không trong khuôn khổ tổ chức và điều kiện quản lý mà tổ chức đó (người dùng, khách hàng)

có

Mức độ các phương án được xem xét tới trong nghiên cứu khả thi thường bị giới hạn bởi các ràng buộc về chi phí và thời gian

2.2.3 Phân tích mở rộng yêu cầu nghiệp vụ

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

Mỗi dự án sẽ có một hay nhiều yêu cầu nghiệp vụ Mỗi yêu cầu nghiệp vụ là một mô tả tác vụ cụ thể trong nghiệp vụ của khách hàng Một tác vụ cần chia nhỏ thành những phần chắc chắn cho đến khi mỗi phần đủ để mô tả công việc chính xác

Khi mức độ của thành phần chia nhỏ dưới mức tối thiểu, xác định lại trình tự thành phần

Mỗi tác vụ được gọi là yêu cầu nghiệp vụ hay quy tắc nghiệp vụ Quy tắc doanh nghiệp được viết theo ngôn ngữ được hiểu bởi những người không chuyên máy tính sao cho người dùng có thể kiểm tra một cách chính xác

b Xác định yêu cầu chất lượng khách hàng

Mỗi dự án phần mềm có thể yêu cầu nhanh, bảo mật, phụ thuộc, dễ dùng Trong thế giới thực, thời gian và ràng buộc tài chính làm cho không thể tạo ra những chương trình dự án

Trang 38

hoàn chỉnh Thay vào đó, điều quan trọng để quyết định dựa trên mức độ chấp nhận của chất lượng thõa mãn khách hàng

c Phân tích hạ tầng cơ sở hiện hành

Phần quan trọng trong thiết kế giải pháp là phân tích kỹ thuật thay thế Điển hình, giải pháp phần mềm được đưa vào hơn là thay thế hệ thống hiện hành Dự án cần làm việc trên phần cứng và phần mềm mà người dùng hiện có Biết được hệ điều hành khách hàng đang dùng, loại mạng đang sử dụng, và nếu người dùng đang chạy phần mềm không tương thích với chương trình mới hơn Nên bỏ thời gian tìm hiểu máy chủ hiện hành, hệ điều hành, phần mềm đang chạy Khi đưa giải pháp, nhớ rằng cơ sở hạ tầng hiện hành đảm bảo giải pháp của chúng ta có thể tương thích

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

Nếu cần mở rộng chức năng cho hệ thống hiện hành, chúng ta mong ước thay đổi hệ thống cũ cả việc cải thiện hệ thống cũ và tích hợp dễ dàng hơn hệ thống mới

Việc suy nghĩ trước sẽ tiết kiệm thời gian sau đó: Trãi qua thời gian tìm hiểu sự khác biệt về giao tác, bảo mật, và những chức năng khác giữa kỹ thuật cũ và giải pháp mới

Chúng ta nên tìm hiểu thủ tục chuyển đổi dữ liệu từ kỹ thuật cũ sang kỹ thuật mới Đảm bảo được phép thực nghiệm những thủ tục này, và có kế hoạch bảo lưu trong trường hợp thực hiện vấn đề này bị lỗi Đảm bảo chắc chắn những tác động chuyển đổi trên mọi thành phần của hệ thống, không chỉ phần tử gần nhất thay đổi

2.2.4 Phân tích yêu cầu bảo mật

Khi hệ thống lưu trữ, truy xuất dữ liệu cá nhân như thông tin nhân sự, thẻ tín dụng, doanh số bán hàng hay thông tin riêng tư… Chúng ta cần có biện pháp đảm bảo an toàn những dữ liệu này

a Xác định vai trò

Toàn bộ ứng dụng không chỉ có 1 mức độ bảo mật Người dùng cuối chỉ cần quyền truy xuất giới hạn vào hệ thống Quản trị hệ thống, người thao tác viên cập nhật, và người dùng có quyền truy cập cao hơn ở mọi cấp độ Bảo mật dựa trên vai trò là kỹ thuật dùng để cấp quyền mức độ bảo mật khác nhau tương ứng quyền hạn và độ chuyên nghiệp của mỗi người dùng trong hệ thống

Lưu ý: Nhận biết những lớp chính của những người dùng cần truy cập đến ứng dụng

của chúng ta Gán tên vai trò cho mỗi lớp người dùng Cuối cùng, gán mức độ tối thiểu có thể truy xuất đến mỗi vai trò Mỗi lớp người dùng nên có đủ quyền truy xuất đến công việc của

họ, và không nhiều hơn

b Xác định môi trường bảo mật ứng dụng

Trang 39

Độ bảo mật không bị giới hạn người dùng hệ thống Chỉ người dùng đăng nhập vào ứng dụng để kiểm soát tài nguyên chia sẻ như tập tin, dịch vụ hệ thống, cơ sở dữ liệu Mức độ kiểm soát của ứng dụng được gọi là ngữ cảnh bảo mật Chúng ta cần phải làm việc với nhiều người dùng khác như quản trị mạng, cấp quyền truy xuất phù hợp ứng dụng để chia sẻ tài nguyên

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

Nếu công ty có sẵn cơ chế bảo mật thay vào đó hệ thống của chúng ta nên điều chỉnh cho phù hợp với cơ chế đã có Nếu chúng ta đang thực thi hệ thống bảo mật mới hay một hệ thống khác, cần phải phân tích tác động của hệ thống trên hệ thống hiện tại:

• Hệ thống mới có làm hỏng chức năng của phần mềm hiện tại?

• Hệ thống đòi hỏi phải hỗ trợ thêm một phần người dùng – đăng nhập mở rộng?

• Hệ thống sẽ khóa một vài người dùng trên những tập tin hay những tài nguyên mà họ được quyền truy cập trước đây

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

Khi tổ chức phát triển và thay đổi, người dùng mới được thêm vào, người cũ được cập nhật và bỏ đi Những thao tác này đòi hỏi thay đổi cơ sở dữ liệu bảo mật, đó là nơi thông tin người dùng và quyền hạn truy cập của họ được lưu Những thông tin này được lưu trữ hiện thời

Nếu người dùng có vị trí địa lý khác nhau, ở văn phòng khác nhau, chúng ta cần lên kế hoạch tái tạo cơ sở dữ liệu bảo mật Sự tái tạo là sự thay đổi hệ thống dữ liệu tại nơi này sao chép đến nơi khác sao cho tất cả thông tin bảo mật được lưu giữ mỗi nơi Thuận lợi cho việc tạo bản sao là người dùng có thể đăng nhập dùng thông tin được lưu ở vị trí gần hơn so với vị trí địa lý Nếu hệ thống mạng bị ngừng hoạt động, ví dụ người dùng vẫn có thể đăng nhập Việc tạo bản sao cần được lên kế hoạch và vận hành

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

Một hệ thống bảo mật tốt không là cơ chế thụ động Thay vào đó, chứa chức năng trợ giúp kiểm soát hoạt động của hệ thống cho vấn đề bảo mật Vấn đề chung của chức năng này

là nhật ký Toàn bộ thao tác của hệ thống có thể được ghi nhận hầu như toàn bộ sự kiện liên quan đến bảo mật hệ thống Có thể ghi nhận mỗi khi đăng nhập, truy xuất đến mọi tài nguyên nhưng điều này hiếm khi hiệu qủa; thường chúng ta sẽ ghi nhận một số tập thông tin này như việc cố gắng đăng nhập lỗi

Lưu ý: Nhật ký hệ thống tự nó thì không có ý nghĩa; chúng ta phải kế hoạch kiểm soát

thường xuyên bởi ta có thể phát hiện những nghi ngờ những mẫu nhật ký hoạt động Người kiểm soát được huấn luyện nên phân tích nhật ký trên cơ sở thường xuyên, đưa ra những đề

Trang 40

nghị nếu có bất kỳ điều nghi ngờ

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

Bảo mật cũng giống như những phần khác trong thiết kế ứng dụng, là sự cân nhắc giữa hiệu quả và chi phí Nếu hệ thống không lưu giữ những dữ liệu có tính nhạy cảm cao, cách tốt nhất để triển khai hệ thống đó là “giữ sự xác thực của người dùng” đòi hỏi lưu trữ Nếu chúng

ta lưu trữ thông tin cần cho bảo mật, chi phí cho bảo mật thông tin đặc biệt phải được kiểm chứng

Không có hệ thống nào bảo mật 100% Chúng ta phải xác định mức độ rủi ro bảo mật

có thể chấp nhận được Độ rủi ro bảo mật diễn tả tỉ lệ phần trăm tương xứng khả năng mà bảo mật hệ thống không bao giờ đạt đến Điều đó là có thể, nhưng phí tổn để xây dựng hệ thống bảo mật 99% Chúng ta hay khách hàng phải xác định mức độ rủi ro có thể chấp nhận được dựa trên dữ liệu nhạy cảm của hệ thống

g Rà soát bảo mật hiện tại

Chúng ta nên trung thành ý tưởng của yêu cầu bảo mật của ứng dụng Ở thời điểm phân tích chính sách bảo mật hiện tại của công ty để xác định bảo mật có đạt đến những nhu cầu của hệ thống hay không Nếu không, thảo luận vấn đề với người gách vác hệ thống bảo mật ở công ty để tìm ra giải pháp mang lại lợi ích để triển khai mở rộng bảo mật

2.2.5 Phân tích yêu cầu tốc độ

Tốc độ của ứng dụng có thể đòi hỏi khó Đối với người dùng, ứng dụng sẽ hầu như chạy quá chậm nhưng muốn có một ứng dụng chạy nhanh cần phải có một thiết kế tốt mới có thể mang lại giá trị cao

Lưu ý: Việc chạy nhanh một ứng dụng thiết kế kém thì dễ, nhiều ứng dụng có thể chạy chậm bởi thiết kế thiếu sót, những không bởi không tương thích giữa phần ứng và các yếu tố bên ngoài

Chúng ta nên nhận thức yêu cầu tốc độ ứng dụng trước khi bắt đầu qui trình thiết kế Yêu cầu tốc độ dựa theo các mục sau:

Mỗi phút giao dịch: Cung cấp dịch vụ phụ thuộc vào số lượng lớn người dùng, ứng

dụng phân tán dùng những giao tác Số giao tác mỗi phút là độ đo tốc độ hệ thống cơ sở dữ liệu

Băng thông: Ứng dụng phân tán làm nghẽn việc sử dụng mạng Sự phản hồi của ứng

dụng xác định định băng thông mạng (độ rộng của đường truyền mạng) Băng thông thường được đo bằng megabit/s

Khả năng chứa: Lượng lưu trữ - cả bộ nhớ chính và phụ - sẵn sàng đối với ứng dụng là

vấn đề lưu tâm quan trọng cho tốc độ chung của ứng dụng Bộ nhớ RAM đòi hỏi của ứng

Định dạng
Số trang	136
Dung lượng	3,9 MB