Thông tin
Hỏi đáp

Tổng quan về phần mềm và công nghệ phần mềm - Công nghệ thông tin | Đại học Hồng Đức

Tổng quan về phần mềm và công nghệ phần mềm - Công nghệ thông tin | Đại học Hồng Đức được sưu tầm và soạn thảo dưới dạng file PDF để gửi tới các bạn sinh viên cùng tham khảo, ôn tập đầy đủ kiến thức, chuẩn bị cho các buổi học thật tốt. Mời bạn đọc đón xem!

Môn:

Công nghệ thông tin(DHHD) 20 tài liệu

Trường:

Đại học Hồng Đức 130 tài liệu

Thông tin:

191 trang 6 tháng trước

Tác giả:

Nguyễn Vân

docx.com.vn

Bình luận

Vui lòng đăng nhập hoặc đăng ký để gửi bình luận.

Tổng quan về phần mềm và công nghệ phần mềm - Công nghệ thông tin | Đại học Hồng Đức

99 50 lượt tải Tải xuống

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

1.1. Một số khái niệm cơ bản

1.1.1. Phần mềm

Phần mềm thông thường được định nghĩa bao gồm:

- các lệnh máy tính nhằm thực hiện các chức năng xác định

- các cấu trúc dữ liệu cho phép chương trình thao tác với dữ liệu

- các tài liệu giúp cho người dùng có thể vận hành được phần mềm

Bốn thuộc tính chủ chốt mà một hệ phần mềm tốt phải có là:

- Có thể bảo trì được: phần mềm tuổi thọ dài phải được viết và được lập tư liệu

sao cho việc thay đổi có thể tiến hành được mà không quá tốn kém. Đây được coi là

đặc tính chủ chốt nhất của một phần mềm tốt. Để có thể bảo trì được, phần mềm phải

có một thiết kế tốt có tính modun hóa cao, được viết bằng ngôn ngữ bậc cao và được

lập tài liệu (tài liệu phân tích, thiết kế, chú thích mã nguồn, hướng dẫn người dùng...)

đầy đủ.

- Đáng tin cậy: phần mềm phải thực hiện được điều mà người tiêu dùng mong

mỏi và không thất bại nhiều hơn những điều đã được đặc tả. Điều này có nghĩa là phần

mềm phải thỏa mãn được nhu cầu của người dùng. Để đạt được yếu tố đáng tin cậy,

trước tiên người phát triển cần phải hiểu một cách đúng đắn yêu cầu của người dùng

và sau đó cần thỏa mãn được các yêu cầu này bằng các thiết kế và cài đặt tốt.

- Có hiệu quả: phần mềm khi hoạt động phải không lãng phí tài nguyên hệ

thống như bộ nhớ, bộ xử lý. Nếu phần mềm chạy quá chậm hay đòi hỏi quá nhiều bộ

nhớ... thì dù có được cài đặt rất nhiều chức năng cũng sẽ không được đưa vào sử dụng.

Tuy nhiên, ngoại trừ các phần mềm nhúng hay thời gian thực đặc biệt, người ta thường

không cực đại hóa mức độ hiệu quả vì rằng việc đó có thể phải dùng đếm các kỹ thuật

đặc thù và cài đặt bằng ngôn ngữ máy khiến cho chi phí tăng cao và phần mềm rất khó

thay đổi (tính bảo trì kém).

- Dễ sử dụng: giao diện người sử dụng phải phù hợp với khả năng và kiến thức

của người dùng, có các tài liệu hướng dẫn và các tiện ích trợ giúp. Đối tượng chính

của các phần mềm nghiệp vụ thường là người không am hiểu về máy tính, họ sẽ xa

lánh các phần mềm khó học, khó sử dụng.

Có thể thấy rõ, việc tối ưu hóa đồng thời các thuộc tính này là rất khó khăn. Các

thuộc tính có thể mẫu thuẫn lẫn nhau, ví dụ như tính hiệu quả và tính dễ sử dụng, tính

bảo trì. Quan hệ giữa chi phí cải tiến và hiệu quả đối với từng thuộc tính không phải là

tuyến tính. Nhiều khi một cải thiện nhỏ trong bất kỳ thuộc tính nào cũng có thể là rất

đắt.

Một khó khăn khác của việc phát triển phần mềm là rất khó định lượng các

thuộc tính của phần mềm. Chúng ta thiếu các độ đo và các chuẩn về chất lượng phần

mềm. Vấn đề giá cả phải được tính đến khi xây dựng một phần mềm. Chúng ta sẽ xây

dựng được một phần mềm dù phức tạp đến đâu nếu không hạn chế về thời gian và chi

phí. Điều quan trọng là chúng ta phải xây dựng một phần mềm tốt với một giá cả hợp

lý và theo một lịch biểu được định trước.

1.1.2. Hệ thống phần mềm

Tập (hệ thống) các phần mềm có thể hợp tác để thực hiện chức năng lớn hơn:

Mỗi phần mềm thực hiện một công việc và kết hợp các công việc để hoàn thành nhiệm

vụ chung

Mỗi phần mềm trong hệ thống còn được gọi là phân hệ/ hệ thống con

(subsystem) hay module phần mềm.

Ví dụ

- Có thể xem MSWord là một hệ thống phần mềm bao gồm

+ Module soạn thảo cơ bản

+ Module kiểm tra chính tả, ngữ pháp và sửa lỗi

+ Module xử lý công thức toán học và các ký tự đặc biệt

+ Module tìm kiếm, thay thế văn bản

+ Module tính toán excel

+ Module email, tạo website

...

- Phần mềm kế toán là hệ thống gồm

+ Module Kế toán Lương

+ Module Kế toán Thu

+ Module Kế toán Chi

+ Module Lập Báo cáo

1.2. Tầm quan trọng của phần mềm

- Phần mềm được ứng dụng trong mọi lĩnh vực kinh tế, văn hoá, khoa học, giáo

dục, giải trí, giao tiếp… mang lại hiệu suất và chất lượng cao

- Phần mềm làm thay đổi phong cách và hiệu quả làm việc và tạo ra sự khác

biệt giữa các cá nhân, tổ chức: Phong cách công nghiệp và Tăng năng suất, chất lượng

- Các ứng dụng phần mềm phát triển nhanh trên mọi lĩnh vực của xã hội.

+ Hàng không: PM điều khiển không lưu

+ Ngân hàng: PM giao dịch, liên ngân hàng

+ Giáo dục: PM chấm thi trắc nghiệm, PM quản lý đào tạo

…

- Sự phụ thuộc của các nền kinh tế vào phần mềm

+ Thu, chi từ phần mềm chiếm tỷ trọng đáng kể trong GDP của các nước phát

triển

1 Ấn Độ:

o 2006: xuất khẩu gần 30 tỷ $ phần mềm

o 2009: 50 tỷ S

o Dự kiến năm 2020: 225 tỷ $

2 Trung Quốc:

o Năm 2011: 30,4 tỷ

3 Thế giới có >7 triệu kỹ sư CNTT tạo ra 600 tỷ $/ năm

4 Chi phí cho phần mềm năm 2000 lên tới 770 tỷ $

+ Phần mềm sai hỏng kinh tế tổn thất

o Vệ tinh Ariane 5 nổ tung sau vài giây được phóng lên do lỗi phần

mềm ngày 4/6/1996, thiệt hại 500 triệu $.

o Máy trị xạ Therac – 25 do Canada và Pháp chế tạo, năm 1985 -1987

KTV thao tác lỗi, máy “hào phóng” cho quá liều đối với 6 BN 3

người chết.

1.3. Đặc trưng & chất lượng sản phầm phần mềm

1.3.1. Đặc trưng phần mềm

Chúng ta có thể thấy khó khăn hàng đầu của việc phát triển phần mềm là do

tính chất phần mềm là hệ thống logic, không phải là hệ thống vật lý. Do đó nó có đặc

trưng khác biệt đáng kể với các đặc trưng của phần cứng. Dưới đây là 3 yếu tố chính

tạo ra sự phức tạp trong quá trình phát triển cũng như sử dụng, bảo trì phần mềm.

a. Phần mềm không được chế tạo theo nghĩa cổ điển

Phần mềm cũng được được thiết kế, phát triển như phần cứng, nhưng nó không

định hình trước. Chỉ khi phát triển xong người ta có sản phẩm cụ thể và hiểu được nó

có hiệu quả hay không. Tức là ở các bước trung gian, chúng ta rất khó kiểm soát chất

lượng của phần mềm.

Giá thành của phần cứng chủ yếu bị chi phối bởi giá thành nguyên vật liệu và

chúng ta tương đối dễ kiểm soát. Trong khi đó, giá thành phần mềm chủ yếu tập chung

vào chi phí nhân công. Quá trình phát triển phần mềm phụ thuộc vào con người (hiểu

biết, khả năng vận dụng, kinh nghiệm và cách thức quản lý) và được tiến hành phát

triển trong điều kiện môi trường (kỹ thuật, xã hội) đa dạng và không ngừng thay đổi.

Do đó chúng ta rất khó ước lượng được chi phí cũng như hiệu quả của phần mềm.

b. Phần mềm không hỏng đi nhưng thoái hóa theo thời gian

Phần mềm không cảm ứng đối với những tác động của môi trường vốn gây cho

phần cứng bị mòn cũ đi, nhưng nó cũng thoái hóa theo thời gian. Thực tế, phần mềm

trải qua thời gian sử dụng cần phải được thay đổi (bảo trì) để đáp ứng nhu cầu luôn

thay đổi của tổ chức sử dụng nó. Mỗi khi thay đổi, sẽ xuất hiện thêm một số khiếm

khuyết mới không thể tránh làm cho số lỗi tiềm ẩn trong phần mềm tăng lên. Dần dần,

phần mềm bị thoái hóa do tỷ lệ sai hỏng ngày càng tăng lên đến mức gây ra những

thiệt hại không thể chấp nhận được.

Việc bảo trì phần mềm phức tạp hơn nhiều và có bản chất khác hẳn so với bảo

trì phần cứng do sự phức tạp của hệ thống phần mềm và sự không có sẵn phần thay thế

cho bộ phận bị lỗi. Chúng ta không thay thế bộ phận bị lỗi bằng cái có sẵn mà thực tế

phải tạo ra một môđun mới. Do đó, thông thường chỉ có nhà sản xuất phần mềm mới

bảo trì (sửa chữa) được hỏng hóc. Sẽ rất khó ước lượng được chi phí cho bảo trì phần

mềm.

c. Phần lớn phần mềm đều được xây dựng từ đầu, ít khi được lắp ráp từ thành

phần có sẵn

- Phần mềm không có danh mục các thành phần cố định như phần cứng.

- Phần mềm thường được đặt hàng theo một đơn vị hoàn chỉnh, theo yêu cầu

riêng của khách hàng.

- Phần mềm ít khi có thể lắp ráp theo một khuôn mẫu có sẵn. Yêu cầu với phần

mềm thay đổi theo môi trường cụ thể mà ở đó nó được xây dựng. Môi trường của phần

mềm (gồm phần cứng, phần mềm nền, con người và tổ chức) không thể định dạng từ

trước và lại thay đổi thường xuyên.

Những yếu tố này dẫn đến chi phí cho phần mềm cao và rất khó đảm bảo được

lịch biểu cho phát triển phần mềm.

1.3.2. Chất lượng sản phầm phần mềm

Chất lượng (Quality) bao gồm:

- Chức năng (functions) phần mềm thực hiện hay dịch vụ (services) được phần

mềm cung cấp

- Sử dụng được (Usability): Dùng được và có ích; Cần có giao diện tốt và đủ tài

liệu hướng dẫn

- Bảo trì được (Maintainability): Có thể sửa đổi khi yêu cầu thay đổi

- Tin cậy (Dependability)

+ An toàn (safety): Không gây thiệt hại cho hệ thống hoặc thiệt hại kinh tế cho

đơn vị sử dụng khi xuất hiện lỗi

+ An ninh (Security): Bảo đảm không bị phá hoại vô tình hoặc cố ý

- Hiệu suất (Efficiency): Sử dụng tài nguyên vừa phải, cho kết quả nhanh

- Chi phí thấp (Low cost): Chi phí để phát triển và Giá bán

Khó có thể thỏa mãn tất cả các tính chất, cần phải biết, với từng hệ thống, tính

chất nào quan trọng hơn để ưu tiên cho tính chất đó

1.4. Phân loại phần mềm

Chúng ta có thể chia phần mềm theo miền ứng dụng thành 7 loại như sau:

a. Phần mềm hệ thống

- Là một tập hợp các chương trình được viết để phục vụ cho các chương trình

khác

- Xử lý các cấu trúc thông tin phức tạp nhưng xác định (trình biên dịch, trình

soạn thảo, tiện ích quản lý tệp)

- Đặc trưng bởi tương tác chủ yếu với phần cứng máy tính

- Phục vụ nhiều người dùng

- Cấu trúc dữ liệu phức tạp và nhiều giao diện ngoài

b. Phần mềm thời gian thực

Phần mềm điều phối, phân tích hoặc kiểm soát các sự kiện thế giới thực ngay

khi chúng xuất hiện được gọi là phần mềm thời gian thực. Điển hình là các phần mềm

điều khiển các thiết bị tự động. Phần mềm thời gian thực bao gồm các thành tố:

- Thành phần thu thập dữ liệu để thu và định dạng thông tin từ môi trường ngoài

- Thành phần phân tích để biến đổi thông tin theo yêu cầu của ứng dụng

- Thành phần kiểm soát hoặc đưa ra đáp ứng môi trường ngoài

- Thành phần điều phối để điều hòa các thành phần khác sao cho có thể duy trì

việc đáp ứng thời gian thực

Hệ thống thời gian thực phải đáp ứng những ràng buộc thời gian chặt chẽ.

c. Phần mềm nghiệp vụ

Là các phần mềm phục vụ các hoạt động kinh doanh hay các nghiệp vụ của tổ

chức, doanh nghiệp. Đây có thể coi là lĩnh vực ứng dụng phần mềm lớn nhất. Điển

hình là các hệ thống thông tin quản lý gắn chặt với CSDL, các ứng dụng tương tác như

xử lý giao tác cho các điểm bán hàng.

d. Phần mềm khoa học và công nghệ

- Được đặc trưng bởi các thuật toán (tính toán trên ma trận số, mô phỏng...).

- Thường đòi hỏi phần cứng có năng lực tính toán cao.

e. Phần mềm nhúng

- Nằm trong bộ nhớ chỉ đọc và được dùng để điều khiển các sản phẩm và hệ

thống cho người dùng và thị trường công nghiệp.

- Có các đặc trưng của phần mềm thời gian thực và phần mềm hệ thống.

f. Phần mềm máy tính cá nhân

- Bùng nổ từ khi xuất hiện máy tính cá nhân, giải quyết các bài toán nghiệp vụ

nhỏ như xử lý văn bản, trang tính, đồ họa, quản trị CSDL nhỏ...

- Yếu tố giao diện người-máy rất được chú trọng.

g. Phần mềm trí tuệ nhân tạo

- Dùng các thuật toán phi số để giải quyết các vấn đề phức tạp mà tính toán hay

phân tích trực tiếp không quản lý nổi

- Các ứng dụng chính là: hệ chuyên gia (hệ cơ sở tri thức), nhận dạng (hình ảnh

và tiếng nói), chứng minh định lý và chơi trò chơi, mô phỏng.

Ngoài ra, chúng ta còn có thể kể đến một dạng phần mềm đặc biệt là phần mềm

phục vụ kỹ nghệ phần mềm. Đó là các phần mềm như chương trình dịch, phần mềm

gỡ rối, các công cụ hỗ trợ phân tích thiết kế (CASE)... Các phần mềm này có thể xuất

hiện dưới dạng phần mềm máy tính cá nhân, phần mềm hệ thống hoặc là phần mềm

nghiệp vụ.

1.5. Sự tiến hóa của phần mềm

Sự tiến hóa của phần mềm gắn liền với sự tiến hóa của phần cứng và có thể chia

làm 4 giai đoạn:

a. Những năm đầu (từ 1950 đến 1960):

- Giai đoạn này phần cứng thay đổi liên tục, số lượng máy tính rất ít và phần

lớn mỗi máy đều được đặt hàng chuyên dụng cho một ứng dụng đặc biệt.

- Phương thức chính là xử lý theo lô (batch), tức là “gói” các chương trình có sử

dụng kết quả của nhau lại thành một khối dể tăng tốc độ thực hiện.

- Thời kỳ này lập trình máy tính được coi là nghệ thuật “theo bản năng”, chưa

có phương pháp hệ thống. Việc phát triển phần mềm chưa được quản lý.

- Môi trường lập trình có tính chất cá nhân; thiết kế, tiến trình phần mềm không

tường minh, thường không có tài liệu. Sản xuất có tính đơn chiếc, theo đơn đặt hàng.

Người lập trình thường là người sử dụng và kiêm cả việc bảo trì và sửa lỗi.

b. Thời kỳ trải rộng từ những năm 1960 đến giữa những năm 1970:

- Các hệ thống đa nhiệm, đa người sử dụng (ví dụ: Multics, Unix,...) xuất hiện

dẫn đến khái niệm mới về tương tác người máy. Kỹ thuật này mở ra thế giới mới cho

các ứng dụng và đòi hỏi mức độ tinh vi hơn cho cả phần mềm và phần cứng.

- Nhiều hệ thống thời gian thực với các đặc trưng thu thập, phân tích và biến

đổi dữ liệu từ nhiều nguồn khác nhau và phản ứng (xử lý, tạo output) trong một

khoảng thời gian nhất định xuất hiện. - Tiến bộ lưu trữ trực tuyến làm xuất hiện thế hệ

đầu tiên của hệ quản trị CSDL.

- Số lượng các hệ thống dựa trên máy tính phát triển, nhu cầu phân phối mở

rộng, thư viện phần mềm phát triển, quy mô phần mềm ngày càng lớn làm nẩy sinh

nhu cầu sửa chữa khi gặp lỗi, cần sửa đổi khi người dùng có yêu cầu hay phải thích

nghi với những thay đổi của môi trường phần mềm (phần cứng, hệ điều hành, chương

trình dịch mới). Công việc bảo trì phần mềm dần dần tiêu tốn nhiều công sức và tài

nguyên đến mức báo động.

c. Thời kỳ từ giữa những năm 1970 đến đầu những năm 1990:

- Hệ thống phân tán (bao gồm nhiều máy tính, mỗi máy thực hiện một chức

năng và liên lạc với các máy khác) xuất hiện làm tăng quy mô và độ phức tạp của phần

mềm ứng dụng trên chúng.

- Mạng toàn cục và cục bộ, liên lạc số giải thông cao phát triển mạnh làm tăng

nhu cầu thâm nhập dữ liệu trực tuyến, nảy sinh yêu cầu lớn phát triển phần mềm quản

lý dữ liệu.

- Công nghệ chế tạo các bộ vi xử lý tiến bộ nhanh khiến cho máy tính cá nhân,

máy trạm để bàn, và các thiết bị nhúng (dùng cho điều khiển trong robot, ô tô, thiết bị

y tế, đồ điện gia dụng,...) phát triển mạnh khiến cho nhu cầu về phần mềm tăng nhanh.

- Thị trường phần cứng đi vào ổn định, chi phí cho phần mềm tăng nhanh và có

khuynh hướng vượt chi phí mua phần cứng.

d. Thời kỳ sau 1990:

- Kỹ nghệ hướng đối tượng là cách tiếp cận mới đang nhanh chóng thay thế

nhiều cách tiếp cận phát triển phần mềm truyền thống trong các lĩnh vực ứng dụng.

- Sự phát triển của Internet làm cho người dùng máy tính tăng lên nhanh chóng,

nhu cầu phần mềm ngày càng lớn, quy mô và độ phức tạp của những hệ thống phần

mềm mới cũng tăng đáng kể.

- Phần mềm trí tuệ nhân tạo ứng dụng các thuật toán phi số như hệ chuyên gia,

mạng nơ ron nhân tạo được chuyển từ phòng thí nghiệm ra ứng dụng thực tế mở ra khả

năng xử lý thông tin và nhận dạng kiểu con người.

1.6. Thực trạng và thách thức trong phát triển phần mềm

1.6.1. Thực trạng

Việc phát triển các ứng dụng > 5000 function points (~500,000 LOC) là một

trong những nhiệm vụ rủi ro nhất trong thế giới hiện đại (Capers Jones)

Những rủi ro dẫn đến hủi hoặc đình trệ tăng nhanh cùng với việc tăng của kích

thước các ứng dụng (Capers Jones):

- 65% các HT lớn (>1,000,000 LOC) bị hủi trước khi hoàn thành

- 50% các HT ước lượng sai kích thước > 1/2 million LOC

- 25 % các dự án > 100,000 LOC

Tỷ lệ thất bại (Failure or cancellation) của các dự án lớn là >20% (Capers

Jones)

Sau khi khảo sát 8,000 dự án IT, Standish Group cho biết khoảng 30% bị hủi

trước khi hoàn thành

Trung bình các dự án ở Mỹ bị hủi sau 1 năm tiến hành và tiêu tốn 200% kinh

phí dự kiến (Capers Jones).

Các dự án bị hủi chiếm khoảng 15% tổng kinh phí PM của Mỹ ($14 billion in

1993 dollars) (Capers Jones).

Thống kê của Standish Group (2006)

- Có tới 50% trong số các dự án phần mềm thất bại

- Chỉ có 16.2% dự án là hoàn thành đúng hạn và nằm trong giới hạn ngân sách,

đáp ứng tất cả tính năng và đặc tính như cam kết ban đầu

- Có 52.7% dự án được hoàn thành và đi vào hoạt động nhưng không hoàn

thành đúng hạn và bội chi, thêm nữa không đáp ứng đầy đủ tính năng và đặc tính như

thiết kế ban đầu

- Và có 31.1% dự án thất bại trước khi được hoàn thành

1.6.2. Thách thức

(1) Không có phương pháp mô tả rõ ràng định nghĩa yêu cầu của người dùng

(khách hàng), sau khi bàn giao sản phẩm dễ phát sinh những trục trặc (troubles)

(2) Với những phần mềm quy mô lớn, tư liệu đặc tả đã cố định thời gian dài, do

vậy khó đáp ứng nhu cầu thay đổi của người dùng một cách kịp thời trong thời gian đó

(3) Nếu không có Phương pháp luận thiết kế nhất quán mà thiết kế theo cách

riêng (của công ty, nhóm), thì sẽ dẫn đến suy giảm chất lượng phần mềm (do phụ

thuộc quá nhiều vào con người)

(4) Nếu không có chuẩn về làm tư liệu quy trình sản xuất phần mềm, thì những

đặc tả không rõ ràng sẽ làm giảm chất lượng phần mềm

(5) Nếu không kiểm thử tính đúng đắn của phần mềm ở từng giai đoạn màchỉ

kiểm ở giai đoạn cuốivà phát hiện ra lỗi, thì thường bàn giao sản phẩm không đúng

hạn

(6) Nếu coi trọng việc lập trình hơn khâu thiết kế thì thường dẫn đến làm giảm

chất lượng phần mềm

(7) Nếu coi thường việc tái sử dụng phần mềm (software reuse), thì năng suất

lao động sẽ giảm

(8) Phần lớn trong quy trình phát triển phần mềm có nhiều thao tác do con

người thực hiện, do vậy năng suất lao động thường bị giảm

(9) Không chứng minh được tính đúng đắn của phần mềm, do vậy độ tin cậy

của phần mềm sẽ giảm

(10) Chuẩn về một phần mềm tốt không thể đo được một cách định lượng, do

vậy không thể đánh giá được một hệ thống đúng đắn hay không

(11) Khi đầu tư nhân lực lớn vào bảo trì sẽ làm giảm hiệu suất lao động của

nhân

viên

(12) Công việc bảo trì kéo dài làm giảm chấtlượng của tư liệu và ảnh hưởng

xấu đến những việc khác

(13) Quản lý dự án lỏng lẻo kéo theo quảnlý lịch trình cũng không rõ ràng

(14) Không có tiêu chuẩn để ướclượng nhân lực và dự toán sẽ làm kéo dài thời

hạn và vượt kinh phí của dự án

1.7. Tổng quan về công nghệ phần mềm

1.7.1. Khái niệm

Có rất nhiều định nghĩa khác nhau về kỹ nghệ phần mềm, giới thiệu ở đây một

số định nghĩa

Bauer [1969]: SE là 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 1 cách kinh tế vừa tin cậy vừa làm việc hiệu quả trên các

máy thực.

Parnas [1987]: SE là việc xây dựng phần mềm nhiều phiên bản bởi nhiều người.

Sommerville [1995]: SE là một nguyên lý kỹ nghệ liên quan đến tất cả các mặt

(lý thuyết,phương pháp và công cụ) của sản phần mềm

IEEE [1993]:

1. việc áp dụng phương pháp tiếp cận có hệ thống, bài bản và được lượng hóa

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

2. nghiên cứu các phương pháp tiếp cận được dùng trong (1)

Pressman [1995]: SE 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

Một định nghĩa ban đầu về kỹ nghệ phần mềm do Fritz Bauer nêu ra là: 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 làm việc hiệu quả trên các máy thực. Kỹ 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:

- Phương pháp

- Công cụ

- Thủ tục

Các yếu tố này giúp người quản lý kiểm soát được tiến trình phát triển phần

mềm, cung cấp cho người kỹ sư phần mềm một nền tảng để xây dựng phần mềm chất

lượng cao theo một cách thức hiệu quả, trong những giới hạn nhất định.

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 và thủ tục thuật toán, mã hóa kiểm thử

và bảo trì. Các phương pháp cho kỹ nghệ phần mềm thường đưa ra 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à kỹ 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à chất keo dán 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. Thủ tục

bao gồm:

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

- Tạo 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 để đả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 đó 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ả.

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.7.2. Lịch sử phát triển

a. Giai đoạn 1:

Những năm 1970 là giai đoạn đề xướng, hình thành, gắn liền với giai đoạn lập

trình và cấu trúc dữ liệu, mang các đặc điểm

- Khái niệm về tính môđun

- Khái niệm thiết kế,lập trình top-down, chi tiết hóa từng bước(N. With)

- Lập trình có cấu trúc (Dijkstra)

- Phương pháp luận về qui trình thiết kế;phương pháp phân chia mô đun

- Trừu tượng hóa dữ liệu (Liskov)

b. Giai đoạn 2

Nửa đầu những năm 1980 là giai đoạn tăng trưởng, có các đặc điểm quan trọng

- Xuất hiện các phương pháp phát triển hệ thống

+ công nghệ CSDL (mô hình quan hệ)

+ phân tích, thiết kế hướng cấu trúc

- Các bộ công cụ phát triển

+ công cụ trợ giúp phân tích thiết kế

+ bộ khởi tạo chương trình (biên dịch)

+ Các ngôn ngữ bậc cao (FoxPro, SQL...)

- Bắt đầu quan tâm đến quản lý làm phần mềm

+ Các độ đo phần mềm

+ Quản lý theo thống kê

c. Giai đoạn 3:

Từ giữa những năm 80 là giai đoạn phát triển, có các đặc điểm

- Hoàn thiện công nghệ cấu trúc, ra đời công nghệ đối tượng

- Nhiều mô hình hướng cấu trúc được chuẩn hóa

- CASE hoàn thiện, đạt mức tự động hóa cao

- Công nghệ hướng đối tượng bắt đầu phát triển:

+ Quy trình RUP

+ Ngôn ngữ mô hình hóa thống nhất(UML)

+ Các công cụ phần mềm đầy đủ (ROSE, JIBULDER,..)

- Sử dụng lại chiếm vị trí quan trọng trong phát triển

- Phát triển các mô hình quản lý

- Chuẩn quản lý được công nhận (CMM, ISO9000-03)

- Nhiều mô hình tổ chức làm phần mềm được đề xuất

- Nhiều công cụ trợ giúp quản lý dự án hoàn thiện

Chương 2. Quy trình phát triển phần mềm

2.1. Vòng đời phần mềm

2.1.1. Khái niệm

Vòng đời phần mềm là thời kỳ tính từ khi phần mềm được sinh (tạo) ra cho đến

khi chết đi (từ lúc hình thành đáp ứng yêu cầu, vận hành, bảo dưỡng cho đến khi loại

bỏ không dùng)

Quy trình phần mềm (vòng đời phần mềm) được phân chia thành các pha chính:

phân tích, thiết kế, chế tạo, kiểm thử, bảo trì. Biểu diễn các pha có khác nhau theo từng

người

2.1.2. Mô hình vòng đời phần mềm của Boehm

2.1.3. Suy nghĩ mới về vòng đời phần mềm

(1) Pha xác định yêu cầu và thiết kế có vai trò quyết định đến chất lượng phần

mềm, chiếm phần lớn công sức so với lập trình, kiểm thử và chuyển giao phần mềm

(2) Pha cụ thể hóa cấu trúc phần mềm phụ thuộc nhiều vào suy nghĩ trên xuống

(top-down) và trừu tượng hóa, cũng như chi tiết hóa

(3) Pha thiết kế, chế tạo thì theo trên xuống, pha kiểm thử thì dưới lên (bottom-

up)

(4) Trước khi chuyển sang pha kế tiếp phải đảm bảo pha hiện nay đã được kiểm

thử không còn lỗi

(5) Cần có cơ chế kiểm tra chất lượng, xét duyệt giữa các phần nhằm đảm bảo

không gây lỗi cho pha sau

(6) Tư liệu của mỗi pha không chỉ dùng cho pha sau, mà chính là đối tượng

quan trọng cho kiểm tra và đảm bảo chính là đối tượng quan trọng cho kiểm tra và

đảm bảo chất lượng của từng quy trình và của chính phần mềm

(7) Cần chuẩn hóa mẫu biểu, cách ghi chép tạo tư liệu, cho từng pha, nhằm đảm

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

(8) Thao tác bảo trì phần mềm là việc xử lý quay vòng trở lại các pha trong

vòng đời phần mềm nhằm biến đổi, sửa chữa, nâng cấp phần mềm

2.2. Quy trình phát triển phần mềm

2.2.1. Khái niệm

Qui trình (process) phần mềm gồm một tập hợp các hoạt động được tổ chức mà

mục đích của nó là nâng cấp, xây dựng và phát triển phần mềm. Qui trình xác định ai

làm gì, khi nào và bằng cách nào để đạt được một mục tiêu nào đó. Quy trình phần

mềm xác định một bộ khung và tiêu chuẩn để triển khai công nghệ phần mềm.

Trong công nghiệp để giải quyết những vấn đề thực tế, những kỹ sư hay một

nhóm kỹ sư phần mềm phải cộng tác để đưa ra một chiến lược phát triển bao gồm qui

trình (process), phương pháp (method) và công cụ (tool). Cần phân biệt giữa qui trình

và phương pháp: Qui trình: Phải thực hiện những công việc gì?, trong khi phương

pháp: chỉ ra cách thực hiện những công việc cụ thể (“how to”).

Những loại hệ thống khác nhau sẽ cần những qui trình phát triển khác nhau, ví

dụ: Hệ thống thời gian thực yêu cầu phải hoàn thành đặc tả hệ thống trước khi chuyển

sang giai đoạn xây dựng nó. Hệ thống thương mại điện tử, chúng ta có thể vừa đặc tả

vừa xây dựng chương trình một cách đồng thời.

2.2.2. Các hoạt động

a. Kỹ nghệ và phân tích hệ thống

Kỹ nghệ và phân tích hệ thống bao gồm việc thu thập yêu cầu ở mức hệ thống

với một lượng nhỏ thiết kế và phân tích ở mức đỉnh. Mục đích của bước này là xác

định khái quát về phạm vi, yêu cầu cũng như tính khả thi của phần mềm.

b. Phân tích yêu cầu phần mềm

- Phân tích yêu cầu được tập trung việc thu thập và phân tích các thông tin cần

cho phần mềm, các chức năng cần phải thực hiện, hiệu năng cần có và các giao diện

cho người sử dụng.

- Kết quả của phân tích là tư liệu về yêu cầu cho hệ thống và phần mềm (đặc tả

yêu cầu) để khách hàng duyệt lại và dùng làm tài liệu cho người phát triển.

c. Thiết kế

- Là quá trình chuyển hóa các yêu cầu phần mềm thành các mô tả thiết kế

- Thiết kế gồm nhiều bước, thường tập trung vào 4 công việc chính: thiết kế

kiến trúc phần mềm, thiết kế cấu trúc dữ liệu, thiết kế chi tiết các thủ tục, thiết kế giao

diện và tương tác.

- Lập tư liệu thiết kế (là một phần của cấu hình phần mềm) để phê duyệt

d. Mã hóa

Biểu diễn thiết kế bằng một hay một số ngôn ngữ lập trình và dịch thành mã

máy thực hiện được.

e. Kiểm thử

Tiến trình kiểm thử bao gồm việc

i) phát hiện và sửa lỗi phần logic bên trong chương trình hay còn gọi là lỗi lập

trình,

ii) kiểm tra xem phần mềm có hoạt động như mong muốn không, tức là phát

hiện và sửa lỗi về chức năng như thiếu hụt, sai sót về chức năng; và kiểm tra xem phần

mềm có đảm bảo tính hiệu quả trong thực hiện hay không.

f. Bảo trì

Bao gồm các công việc sửa các lỗi phát sinh khi áp dụng chương trình hoặc

thích ứng nó với thay đổi trong môi trường bên ngoài (hệ điều hành mới, thiết bị ngoại

vi mới, yêu cầu người dùng) hoặc yêu cầu bổ sung chức năng hay nâng cao hiệu năng

cần có.

2.3. Một số mô hình thực hiện

Mô hình phát triển phần mềm là một thể hiện trừu tượng của quy trình phần

mềm. Nó biểu diễn các đặc tả về quy trình từ những khía cạnh cụ thể, do đó, nó chỉ

cung cấp một phần thông tin về quy trình phần mềm

2.3.1. Mô hình tuyến tính

Đôi khi còn được gọi là mô hình tuần tự tuyến tính hay mô hình thác nước, mô

hình này gợi ý một cách tiếp cận tuần tự, có hệ thống tới việc phát triển phần mềm vốn

bắt đầu từ mức hệ thống và tiến dần qua phân tích, thiết kế, mã hoá, kiểm thử và hỗ

trợ. Dưới đây minh hoạ mô hình thác nước cho kĩ nghệ phần mềm. Được mô hình hoá

theo chu kì kĩ nghệ qui ước, mô hình thác nước bao gồm các hoạt động sau:

Kĩ nghệ và mô hình hoá hệ thống /thông tin. Bởi vì phần mềm bao giờ cũng là

một phần của một hệ thống (hay nghiệp vụ) lớn hơn nên công việc bắt đầu từ việc thiết

lập yêu cầu cho mọi phần tử hệ thống và rồi cấp phát một tập con các yêu cầu đó cho

phần mềm. Quan điểm hệ thống này là điều bản chất khi phần mềm phải tương tác

với các thành phần khác như phần cứng, con người và CSDL. Kĩ nghệ và phân tích

hệ thống bao gồm việc thu thập yêu cầu ở mức hệ thống với một lượng nhỏ thiết kế và

phân tích mức đỉnh. Kĩ nghệ thông tin bao gồm việc thu thập yêu cầu tại mức nghiệp

vụ chiến lược và tại mức lĩnh vực nghiệp vụ.

Phân tích yêu cầu phần mềm. Tiến trình thu thập yêu cầu được tăng cường và

hội tụ đặc biệt vào phần mềm. Để hiểu được bản chất của các chương trình phải xây

dựng, kĩ sư phần mềm ("nhà phân tích") phải hiểu về lĩnh vực thông tin (được mô tả

trong phần sau) đối với phần mềm cũng như chức năng cần có, hành vi, hiệu năng và

giao diện. Các yêu cầu cho cả hệ thống và phần mềm cần phải được lập tư liệu và xét

duyệt cùng với khách hàng.

Thiết kế. Thiết kế phần mềm thực tế là một tiến trình nhiều bước tập trung vào

bốn thuộc tính phân biệt của chương trình: cấu trúc dữ liệu, kiến trúc phần mềm, biểu

diễn giao diện và chi tiết thủ tục (thuật toán). Tiến trình thiết kế dịch các yêu cầu thành

một biểu diễn của phần mềm có thể được định giá về chất lượng trước khi giai đoạn

mã hoá bắt đầu. Giống như các yêu cầu, việc thiết kế phải được lập tư liệu và trở

thành một phần của cấu hình phần mềm.

Sinh mã. Thiết kế phải được dịch thành dạng máy đọc được. Bước mã hoá thực

hiện nhiệm vụ này. Nếu thiết kế được thực hiện theo một cách chi tiết thì việc sinh mã

có thể được thực hiện một cách máy móc.

Kiểm thử. Một khi mã đã được sinh ra thì việc kiểm thử chương trình bắt đầu.

Tiến trình kiểm thử hội tụ vào nội bộ logic của phần mềm, đảm bảo rằng tất cả các câu

lệnh đều được kiểm thử, và vào bên ngoài chức năng; tức là tiến hành các kiểm thử để

làm lộ ra các lỗi và đảm bảo những cái vào đã định sẽ tạo ra kết quả thống nhất với kết

quả muốn có.

Vận hành và bảo trì. Phần mềm chắc chắn sẽ phải trải qua những thay đổi sau

khi nó được bàn giao cho khách hàng (một ngoại lệ có thể là những phần mềm nhúng).

Thay đổi sẽ xuất hiện bởi vì gặp phải lỗi, bởi vì phần mềm phải thích ứng với những

thay đổi trong môi trường bên ngoài (chẳng hạn như sự thay đổi do hệ điều hành mới

hay thiết bị ngoại vi mới), hay bởi vì khách hàng yêu cầu nâng cao chức năng hay hiệu

năng. Việc bảo trì phần mềm phải áp dụng lại các bước vòng đời nói trên cho chương

trình hiện tại chứ không phải chương trình mới.

Mô hình tuần tự tuyến tính là mô hình cũ nhất và được sử dụng rộng rãi nhất

cho kĩ nghệ phần mềm. Tuy nhiên, những chỉ trích về mô hình này đã làm cho những

người ủng hộ nó tích cực phải đặt vấn đề về tính hiệu quả của nó. Một số các vấn đề

thỉnh thoảng gặp phải khi dùng mô hình tuần tự tuyến tính này là:

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

dầu mô hình tuyến tính có thể cho phép lặp, nhưng điều đó chỉ làm gián tiếp. Kết quả

là những thay đổi có thể gây ra lẫn lộn khi tổ dự án tiến hành.

Khách hàng thường khó phát biểu mọi yêu cầu một cách tường minh. Mô hình

tuần tự tuyến tính đòi hỏi điều này và thường khó thích hợp với sự bất trắc tự nhiên tồn

tại vào lúc đầu của nhiều dự án.

Khách hàng phải kiên nhẫn. Bản làm việc được của chương trình chỉ có được

vào lúc cuối của thời gian dự án. Một sai lầm ngớ ngẩn, nếu đến khi có chương trình

làm việc mới phát hiện ra, có thể sẽ là một thảm hoạ.

Trong một phân tích thú vị về các dự án hiện tại, Brada thấy rằng bản chất

tuyến tính của vòng đời cổ điển dẫn tới "các trạng thái nghẽn" mà trong đó một số

thành viên tổ dự án phải đợi cho các thành viên khác của tổ hoàn thành các nhiệm vụ

phụ thuộc. Trong thực tế, thời gian mất cho việc chờ đợi có thể vượt quá thời gian

dành cho công việc sản xuất. Trạng thái nghẽn có khuynh hướng phổ biến vào lúc đầu

và cuối của tiến trình tuần tự tuyến tính.

Từng vấn đề trên đều là thực. Tuy nhiên, mô hình vòng đời cổ điển có một vị trí

quan trọng và xác định trong công việc về kĩ nghệ phần mềm. Nó đưa ra một tiêu bản

trong đó có thể bố trí các phương pháp cho phân tích, thiết kế, mã hoá, kiểm thử và

bảo trì. Bên cạnh đó, vòng đời cổ điển vẫn còn là một mô hình thủ tục được dùng rộng

rãi cho kĩ nghệ phần mềm. Trong khi nó quả thực còn điểm yếu, nó vẫn tốt hơn đáng

kể nếu so với cách tiếp cận ngẫu nhiên tới việc phát triển phần mềm.

2.3.2. Phát triển tiến hoá

a. Mô hình bản mẫu

Cách tiếp cận làm bản mẫu cho kỹ nghệ phần mềm 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

input và output.

- Người phát triển không chắc về hiệu quả của thuật toán, về thích nghi 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 làm 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.

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 nhiều công sức vào đánh giá bản mẫu.

b. 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. 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ến hành tiếp

hay dừng”. Nếu rủi ro quá lớn thì có thể đình chỉ dự án.

Mô hình xoắn ốc là cách tiếp cận thực tế cho việc phát triển cho các hệ thống và

phần mềm qui mô lớn. Bởi vì phần mềm tiến hoá khi tiến trình tiến hoá, nên người

phát triển và khách hàng hiểu rõ hơn và phản ứng với rủi ro tại từng mức tiến hoá. Mô

hình xoắn ốc dùng cách làm bản mẫu như một cơ chế làm giảm bớt rủi ro, nhưng điều

quan trọng hơn, làm cho người phát triển có khả năng áp dụng được cách tiếp cận

làm bản mẫu tại mọi giai đoạn trong tiến hoá của sản phẩm. Nó duy trì cách tiếp

cận từng bước một cách có hệ thống do cách tiếp cận vòng đời cổ điển gợi ý,

nhưng tổ hợp cách tiếp cận này vào một khuôn khổ lặp lại, vốn phản ánh được sát thực

hơn thế giới thực. Mô hình xoắn ốc đòi hỏi việc xem xét trực tiếp các rủi ro kĩ thuật tại

mọi giai đoạn của dự án, và nếu được áp dụng đúng thì nó có thể làm giảm rủi ro trước

khi chúng trở thành vấn đề thực sự.

Nhưng giống như các mô hình khác, mô hình xoắn ốc không phải là một

liều thuốc bách bệnh. Có thể khó thuyết phục những khách hàng (đặc biệt trong tình

huống có hợp đồng) rằng cách tiếp cận tiến hoá là kiểm soát được. Nó đòi hỏi tri thức

chuyên gia đánh giá rủi ro chính xác và dựa trên tri thức chuyên gia này mà đạt được

thành công. Nếu một rủi ro chính không được phát hiện và quản lí thì không nghi ngờ

gì nữa vấn đề sẽ xuất hiện. Cuối cùng, chính bản thân mô hình này cũng còn chưa

được sử dụng rộng rãi như mô hình trình tự tuyến tính hoặc làm bản mẫu. Cần

phải có thêm một số năm nữa trước khi tính hiệu quả của mô hình quan trọng này có

thể được xác định với sự chắc chắn hoàn toàn.

2.3.3. Phát triển dựa trên thành phần

Xuất phát từ quan điểm: "Buy do not build", tư tưởng của phát triển dựa trên

thành phần là xây dựng hệ thống bằng cách lắp ráp hoặc tích hợp từ những thành phần

đã có hoặc các thành phần thương mại COTS (Commercial-off-the-shelf). Do vậy,

kiến trúc phần mềm của hệ thống dựa vào kiến trúc phần mềm của các thành phần

phần mềm tiêu chuẩn nên hệ thống đạt chất lượng cao hơn.

Phương pháp phát triển dựa trên thành phần gần tương tự như phương pháp

phát triển hướng đối tượng. Hoạt động công nghệ bắt đầu với sự chỉ ra các lớp tham

dự để phát triển hệ thống. Nếu các lớp này được tìm thấy trong thư viện và sự thích

nghi là tốt, chúng sẽ được lấy ra và phát triển hệ thống. Ngược lại, chúng sẽ được phát

triển để sử dụng và bổ sung vào thư viện sử dụng lại.

Thành phần phần mềm được sử dụng lại có độ chính xác cao và có thể nói là

không chứa lỗi. Mặc dầu không thường xuyên được chứng minh về mặt hình thức

nhưng với việc sử dụng lại, lỗi được tìm thấy và loại trừ; chất lượng của thành phần

được cải thiện như là một kết quả.

Khi những thành phần sử dụng lại được ứng dụng thông qua tiến trình phần

mềm, chúng ta ít tốn thời gian để tạo ra kế hoạch, mô hình, tài liệu, mã và dữ liệu mà

chúng là cần thiết để tạo ra hệ thống. Thêm vào, chức năng cùng mức được phân phối

cho người sử dụng với đầu vào ít công sức hơn, do vậy, hiệu suất phần mềm được cải

thiện.

Với ưu điểm tái sử dụng các thành phần qua Thư viện / kho các lớp: tiết kiệm

70% thời gian, 80% giá thành, chỉ số sản xuất 26.2/16.9

Với UML như chuẩn công nghiệp đang triển khai

2.3.4. Kỹ thuật thế hệ thứ tư

Thuật ngữ kĩ thuật thế hệ thứ tư (4GT) bao gồm một phạm vi rộng các công cụ

phần mềm có một điểm chung: mỗi công cụ đều cho phép người kĩ sư phần mềm xác

định đặc trưng nào đó của phần mềm ở mức cao. Rồi công cụ đó tự động sinh ra mã

chương trình gốc dựa trên đặc tả của người phát triển. Người ta gần như không còn

bàn cãi về việc phần mềm có thể được xác định đối với một máy càng ở mức cao thì

chương trình có thể được xây dựng càng nhanh hơn. Mô hình 4GT cho kĩ nghệ phần

mềm tập trung vào khả năng xác định phần mềm bằng việc dùng các khuôn mẫu ngôn

ngữ đặc biệt hay kí pháp đồ hoạ vốn mô tả cho vấn đề cần được giải quyết dưới dạng

khách hàng có thể hiểu được.

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

gồm một số hay tất cả các công cụ sau:

- Ngôn ngữ phi thủ tục để hỏi đáp cơ sở dữ liệu.

- Bộ sinh báo cáo.

- Bộ thao tác dữ liệu.

- Bộ tương tác và xác định màn hình.

- Bộ sinh chương trình.

- Khả năng đồ hoạ mức cao.

- Khả năng làm trang tính và việc sinh tự động HTML.

- Các ngôn ngữ tương tự được dùng cho việc tạo ra trang Web thông qua

việc dùng các công cụ phần mềm tiên tiến.

Ban đầu nhiều trong những công cụ đã được nhắc tới đó đã có sẵn chỉ cho

những lĩnh vực ứng dụng rất đặc thù, nhưng ngày nay môi trường 4GT đã được mở

rộng để đề cập tới hầy hết các loại ứng dụng phần mềm.

Giống như các mô hình khác, 4GT bắt đầu từ bước thu thập yêu cầu. Một cách

lý tưởng, khách hàng sẽ mô tả các yêu cầu và các yêu cầu đó sẽ được dịch trực tiếp

thành một bản mẫu vận hành được. Nhưng điều này không thực hiện được. Khách

hàng có thể không chắc chắn mình cần gì, có thể có sự mơ hồ trong việc xác định các

sự kiện đã biết, có thể không có khả năng hay không sẵn lòng xác định thông tin theo

cách thức mà công cụ 4GT có thể giải quyết được. Bởi lí do này, đối thoại khách hàng/

người phát triển được mô tả cho các mô hình tiến trình khác vẫn còn là phần bản chất

của cách tiếp cận 4GT.

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ách dùng ngôn ngữ sinh thế hệ thứ tư phi thủ tục (4GL) hay một mô

hình bao gồm một mạng các biểu tượng đồ hoạ. Tuy nhiên với nỗ lực lớn hơn, cần

phải phát triển một chiến lược thiết kế cho hệ thống, ngay cả nếu có dùng 4GL. Việc

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

lượng kém, khó bảo trì, người dùng khó chấp nhận) mà chúng ta đã gặp phải khi phát

triển phần mềm bằng cách dùng các cách tiếp cận qui ước.

Việc cài đặt dùng 4GL làm cho người phát triển phần mềm biểu diễn được các

kết quả mong muốn theo cách là phát sinh tự động chương trình tính ra chúng. Hiển

nhiên, một cấu trúc dữ liệu với những thông tin có liên quan cần phải có sẵn và sẵn

sàng cho 4GL truy nhập vào.

Để biến đổi một cài đặt 4GT thành một sản phẩm, người phát triển phải tiến

hành việc kiểm thử toàn diện, xây dựng các tài liệu có ý nghĩa và thực hiện mọi hoạt

động tích hợp giải pháp khác vốn cần tới trong các mô hình kĩ nghệ phần mềm khác.

Bên cạnh đó, phần mềm được phát triển theo 4GT phải được xây dựng theo cách

làm cho việc bảo trì có thể được tiến hành một cách chóng vánh.

Giống như mọi mô hình kĩ nghệ phần mềm, mô hình 4GT có ưu điểm và nhược

điểm. Những người ủng hộ cho là 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 là các công cụ 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, rằng chương trình gốc do các công cụ này tạo ra là "không hiệu quả," và rằng

tính bảo trì cho các hệ thống phần mềm lớn được phát triển bằng cách dùng 4GT vẫn

còn là vấn đề mở.

Có đôi điều lợi ích trong các luận điểm của cả hai phía và có thể tóm tắt trạng

thái hiện tại của cách tiếp cận 4GT như sau:

1. Việc dùng 4GT là cách tiếp cận có thể tồn tại được cho nhiều lĩnh vực ứng

dụng khác nhau. Gắn với các công cụ kĩ nghệ phần mềm có máy tính hỗ trợ và bộ

sinh mã, 4GT cung cấp một giải pháp tin cậy được cho nhiều vấn đề phần mềm.

2. Dữ liệu được thu thập từ các công ty có dùng 4GT chỉ ra rằng thời gian cần

cho việc tạo ra phần mềm được giảm đáng kể đối với các ứng dụng vừa và nhỏ và rằng

khối lượng thiết kế và phân tích cho các ứng dụng nhỏ cũng được rút bớt.

3. Tuy nhiên, việc dùng 4GT cho các nỗ lực phát triển phần mềm lớn đòi hỏi

nhiều phân tích, thiết kế và kiểm thử (các hoạt động kĩ nghệ phần mềm) để đạt tới

việc tiết kiệm thời gian vốn nảy sinh từ việc xoá bỏ mã hoá.

Tóm lại, các kĩ thuật thế hệ thứ tư đã trở thành một phần quan trọng của kĩ nghệ

phần mềm. Khi đi đôi với cách tiếp cận dựa trên cấu phần (sẽ được trình bày ở mục

tiếp theo), mô hình 4GT có thể trở thành cách tiếp cận thống trị cho việc phát triển

phần mềm\

2.3.5. Phát triển nhanh ứng dụng (Rapid Application Development )

Mô hình này được đưa ra bởi IBM vào những năm 1980, qua sách của James

Martin. Mô hình RAD là sự ráp nối tốc độ cao của mô hình thác nước, xây dựng dựa

vào thành phần và sử dụng các ứng dụng tạo mã tự động.

Là quy trình phát triển phần mềm gia tăng, tăng dần từng bước (Incrimental

software development) với mỗi chu trình phát triển rất ngắn (60-90 ngày)

Xây dựng dựa trên hướng thành phần (Component-based construction) với khả

năng tái sử dụng (reuse).

Gồm một số nhóm (teams), mỗi nhóm làm 1 RAD theo các pha: Mô hình

nghiệp vụ, Mô hình dữ liệu, Mô hình xử lý, Tạo ứng dụng, Kiểmthử và đánh giá

(Business, Data, Process, Application Generation, Testing and Turnover)

Data modeling: các đối tượng dữ liệu cần để hỗ trợ nghiệp vụ (business). Định

nghĩa các thuộc tính của từng đối tượng và xác lập quan hệ giữa các đối tượng

Process modeling: Các đối tượng dữ liệu được chuyển sang luồng thông tin

thực hiện chức năng nghiệp vụ Tạo mô tả xử lý dễ cập nhật (thêm nghiệp vụ. Tạo mô

tả xử lý đễ cập nhật (thêm, sửa, xóa, khôi phục) từng đối tượng dữ liệu

Application Generation: Dùng các kỹ thuật thế hệ để tạo phần mềm từ các

thành phần có sẵn hoặc tạo ra các thành phần có thể tái dụng lại sau này. Dùng các

công cụ tự động để xây dựng phần mềm

Testing and Turnover: Kiểm thử các thành phần mới và kiểmchứng mọi giao

diện (các thành phần cũ đã được kiểm thử và dùng lại)

Luồng thông tin được mô hình hóa để trả lời các câu hỏi:

- Thông tin nào điều khiển xử lý nghiệp vụ?

- Thông tin gì được sinh ra?

- Ai sinh ra nó?

- Thông tin đi đến đâu?

- Ai xử lý chúng?

Ưu điểm

- Thời gian phát triển giảm nhờ dùng công cụ

- Chỉ cần ít người phát triển hơn, do họ thân thiện với vấn đề

- Nhanh chóng cho phép hình dung ra sản phẩm

- Dùng hiệu quả các framework và công cụ đóng gói (off-the-shelf tools and

frameworks)

- Giảm rủi ro nhờ có sự tham gia của khách hàng

Các hạn chế

- Thiếu sự tham gia tốt của người dùng trong chu kỳ sống của phần mềm

- Người phát triển phải có kỹ năng và được huấn luyện tốt cho việc sử dụng công cụ

và thời gian phát triển nhanh

- Hệ thống có khả năng phân tách module

- Cần có đáp ứng về thành phần sử dụng lại

- Người phát triển và khách hàng phải nỗ lực

- Người quản lý phải làm việc tận tụy với nhóm phát triển và khách hàng để nhanh

chóng đạt được các thỏa thuận

- Cần nguồn nhân lực dồi dào để tạo các nhóm cho các chức năng chính

- Yêu cầu hai bên giao kèo trong thời gian ngắn phải có phần mềm hoàn chỉnh, thiếu

trách nhiệm của một bên dễ làm dự án đổ vỡ

- RAD không phải tốt cho mọi ứng dụng nhất là với ứng dụng không thể môđun hóa

hoặc đòi hỏi tính năng cao

- Mạo hiểm kỹ thuật cao thì không nên dùng RAD

Khi nào nên sử dụng RAD

- Hệ thống dễ dàng phân chia module và có thể mở rộng

-,Hệ thống mà những yêu cầu được biết rõ và hợp lý

- Người dùng có thể tham gia tốt qua toàn bộ chu kỳ sống (life cycle)

- Dự án thời gian phát triển ngắn, dưới 60 ngày

- Những thành phần sử dụng lại có sẵn trong kho phần mềm

- Những hệ thống nhỏ, những hệ thống không có tính nghiêm ngặt (critical)…

2.3.6. Phát triển hình thức

Trong ngành khoa học máy tính, các phương pháp hình thức là các kỹ thuật toán học

cho việc đặc tả, phát triển và kiểm định các hệ thống phần mềm và phần cứng. Cách tiếp cận

này đặc biệt quan trọng đối với các hệ thống cần có tính toàn vẹn cao, chẳng hạn hệ thống

điều khiển lò phản ứng hạt nhân hay điều khiển tên lửa, khi an toàn hay an ninh có vai trò

quan trọng, để góp phần đảm bảo rằng quá trình phát triển hệ thống sẽ không có lỗi. Các

phương pháp hình thức đặc biệt hiệu quả tại giai đoạn đầu của quá trình phát triển (tại các

mứcyêu cầu và đặc tả hệ thống), nhưng cũng có thể được sử dụng cho một quá trình phát

triển hoàn chỉnh của một hệ thống.

Các phương pháp hình thức có thể được sử dụng tại nhiều mức:

 Mức 0: có thể được thực hiện và rồi một chương trình được phátĐặc tả hình thức

triển từ đặc tả này một cách không hình thức. Trong nhiều trường hợp, cách này

có thể là lựa chọn hiệu quả nhất về mặt chi phí.

 Mức 1: Sử dụng và hình thức để tạo một chương trình theophát triển kiểm định

một quy trình hình thức hơn. Ví dụ, có thể thực hiện các chứng minh về các tính

chất hoặc quá trình ( ) từ tới một chươngtinh chỉnh refinement đặc tả hình thức

trình. Đây có thể là lựa chọn phù hợp nhất đối với các hệ thống yêu cầu tính toàn

vẹn cao với các tiêu chí về và .an toàn an ninh

 Mức 2: Sử dụng các ( ) để thực hiện cácbộ chứng minh định lý theorem prover

chứng minh hình thức hoàn toàn và được kiểm chứng bằng máy móc. Việc này có

thể đòi hỏi chi phí rất cao và chỉ đáng lựa chọn trong thực tiễn nếu phí tồn cho

các lỗi sai là cực kỳ cao (ví dụ, trong các phần quan trọng của thiết kế bộ vi xử

lý).

Cùng với ngành con , các phương phápNgữ nghĩa hình thức của ngôn ngữ lập trình

hình thức có thể được phân loại tương đối như sau:

 Ngữ nghĩa ký hiệu ( ), trong đó ý nghĩa của một hệ thốngDenotational semantics

được biểu diễn bằng lý thuyết toán học về . Lợi điểm của nhữngmiền xác định

phương pháp này phụ thuộc vào bản chất được hiểu rõ của các miền xác định để

từ đó đem lại ý nghĩa cho hệ thống; các phê phán chỉ ra rằng không phải hệ thống

nào cũng có thể được nhìn một cách tự nhiên hoặc trực quan dưới dạng một hàm

số.

 Ngữ nghĩ hoạt động ( ), trong đó, ý nghĩa của một hệ thốngOperational semantics

được biểu diễn bằng một chuỗi các hành động của một mô hình tính toán (giả

thiết là) đơn giản hơn. Lợi điểm của phương pháp này là tính đơn giản của các mô

hình tạo nên sự trong sáng của biểu diễn; nhược điểm là phương pháp này đã trì

hoãn các vấn đề của ngữ nghĩa (ai định nghĩa ngữ nghĩa của các mô hình đơn giản

hơn?)

 Ngữ nghĩa tiên đề ( ), trong đó ý nghĩa của hệ thống đượcAxiomatic semantics

biểu diễn theo các ( ) và (tiền điều kiện precondition hậu điều kiện postcondition),

đây lần lượt là các điều kiện phải được thỏa mãn tại các thời điểm trước và sau

khi hệ thống thực hiện một nhiệm vụ. Những người ủng hộ phương pháp này nói

đến mối quan hệ của nó với kinh điển; những người phê phán nói rằnglôgic

những ngữ nghĩa thuộc dạng này không thực sự mô tả xem hệ thống cái gìlàm

(chỉ là cái gì đúng trước đó và sau đó).

2.3.7. Phát triển hướng đối tượng

- Hướng sử dụng lại dựa trên nền tảng của phát triển hệ thống hướng đối tượng

- Ý tưởng

+ Hệ thống cấu thành từ các đối tượng

+ Đối tượng bao gói cả dữ liệu và xử lý

+ Liên kết với nhau bằng truyền thông

- Bao gói, che dấu thông tin: bao gói cả dữ liệu và xử lý nên độc lập tương đối, che

dấu thông tin --> Tác động cục bộ, dễ bảo trì, dễ dùng lại

- Tính kế thừa: Xây dựng được các lớp cơ sở Nâng cao khả năng dùng lại

- Liên kết tự do, yếu Mở rộng đơn giản, không hạn chế

- Các hướng sử dụng lại: Định hướng thành phần, Định hướng mẫu, Phát triển khung

làm việc

- Các giai đoạn

+ Phân tích hệ thống thành các phần yêu cầu nhỏ

+ Cải biến các yêu cầu hướng

+ Thiết kế hệ thống hướng tới tái sử dụng

+ Phát triển và tích hợp

- Quan trọng, cần kinh nghiệm, công cụ còn hạn chế

2.3.8. Phát triển phần mềm mã nguồn mở

Có nhiều dạng bản quyền phần mềm và cách phân phối. Người ta có thể chia chúng

thành 2 dạng chính: Sự sẵn có của mã nguồn và giá tiền. Mã nguồn là mã của phần mềm

được viết bằng một ngôn ngữ lập trình cao cấp hơn. Không như mã nhị phân (binary code),

nó biểu đạt cấu trúc và nguyên lý của chương trình. Một phần mềm được phân phối ở dạng

mã nhị phân còn được gọi là phần mềm hoặc .mã nguồn đóng (closed source) blackbox

Mã nguồn mở không chỉ có nghĩa là cung cấp mã nguồn. Các điều khoản phân phối

của PMMNM phải tuân theo những tiêu chí sau:

 Phân phối miễn phí

 Mã nguồn

 Các sản phẩm gốc

 Toàn bộ mã nguồn của tác giả

 Không phân biệt người dùng hay nhóm

 Không phân biệt lĩnh vực làm việc

 Cung cấp license

 License không được chỉ định riêng cho 1 sản phẩm

 License không được hạn chế các phần mềm khác

 License phải trung lập về mặt công nghệ

Lợi ích

Bảo mật nhờ mở và Bảo mật nhờ đóng: Với các phần mềm Black-Box, sự bảo mật có

được bằng cách che giấu mã nguồn, ngược lại, PMMNM cho phép nhiều người dùng có thể

nhận biết các đoạn mã cũng như tuỳ biến chúng.

Tính tương thích: Khả năng định dạng là vô hạn, do đó các công ty có thể tuỳ biến

mã nguồn cho phù hợp với nhu cầu . Điều này cho phép mã nguồn liên tục được phát triển.

Hiệu năng: Hiệu năng của các PMMNM thường cao hơn so với phần mềm độ quyền

vì tính ổn định và độ tinh cậy.

Không lệ thuộc vào nhà sản xuất: Với mã nguồn mở sẽ không còn sự lệ thuộc vào

nhà sản xuất, không còn phải đối mặt với những vấn đề phát sinh như khi một nhà sản xuất

phần mềm độc quyền phá sản.

Chi phí: Chi phí mua PMMNM thấp hơn, nhưng chi phí huấn luyện ban đầu cao hơn

Nói chung, mã nguồn mở có giai đoạn kiểm nghiệm lâu dài hơn, cho phép nhiều thời

gian hơn để phát triển và hướng tới sự ổn định cao hơn. Đưa vào sử dụng khi đã ổn định

đồng nghĩa với giảm sự cố và chi phí.

Hạn chế

Đa dạng và phức tạp: đã phát triển nhiều ứng dụng đa dạngCộng đồng mã nguồn mở

với những chức năng tương tự nhau. Điều này gây khó khăn cho những người mới sử dụng

trong việc chọn lựa. Cơ cấu chọn lựa đã được thiết lập như nhà sản xuất, giá cả, thị phần

hoặc hỗ trợ chỉ cung cấp một sự giúp đỡ có hạn. Vấn đề thực sự là một khi gia tăng tính đa

dạng sẽ dẫn đến sự phức tạp trong khi với xã hội ngày nay, người ta luôn mong muốn sự

đơn giản. Một giải pháp khả thi cho vấn đề này có thể là sự chọn lựa trước của nhà phân

phối

Sự dư thừa: Sự chia nhánh mã nguồn có thể dẫn đến sự lãng phí trong quá trình phát

triển nó. Nếu các nguồn phát triển được kết hợp và tổ chức lại một cách tốt hơn thì hiệu suất

sẽ được nâng cao.

Thiếu các ứng dụng: Vẫn còn những lĩnh vực vắng bóng các PMMNM. (VD: một

trình biên soạn HTML như MS Frontpage)

Bất tiện: Mã nguồn mở thường chỉ tập trung vào các mã của nó mà ít chú ý đến thiết

kế giao diện và phát triển các tiện ích. Trong Microsoft World, hầu hết các phát triển trong

vài năm gần đây đều thuộc lĩnh vực tiện ích và phát triển giao diện người dùng.

2.3.9. Mô hình khác

a. Lập trình cực đoan (XP - eXtreme Programming)

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

tiên” và “lập trình đôi”.

* Tạo các ca thử nghiệm trước tiên

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 đoạn cuối của quá trình phát triển, khi bạn đã 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 bạn 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 bạn xác định một

cách rõ ràng giao diện của modun. Hơn thế, để tạo được ca thử nghiệm, bạn cần phải hiểu rõ

chức năng của nó. Tức là, XP yêu cầu bạn phải hiểu một cách rõ ràng các yêu cầu của

modun trước khi bạn bắt tay vào phát triển nó.

* Lập trình đôi

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 môđun 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 toàn 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 nhau và giữ được các nguyên tắc của XP.

b. Mô hình tăng dần

Đặc điểm

- Các yêu cầu được xác định và phân loại theo độ ưu tiên, độ ưu tiên cao cho những

chức năng chính và những chức năng có độ rủi ro cao

- Phân chia các yêu cầu cho các vòng và thiết kế kiến trúc của toàn bộ hệ thống

- Vòng đầu tiên tạo ra sản phẩm lõi (core product)

- Các bước sau bổ sung các chức năng khác và tích hợp vào hệ thống nhằm hoàn

thiện dần sản phẩm

- Mỗi chức năng cũng như hệ thống tích hợp phải được đánh giá theo từng giai đoạn

- Các yêu cầu và kiến trúc của toàn bộ hệ thống sẽ được điều chỉnh dựa vào những

sản phẩm phát hành theo từng vòng

Ưu điểm

- Những chức năng của hệ thống có thứ tự ưu tiên càng cao (chức năng chính, chức

năng rủi ro cao) sẽ được thực hiện trước, do đó chúng sẽ được kiểm thử nhiều hơn, sản

phẩm đươc hoàn thành phần cơ bản sớm

- Sau mỗi lần tăng vòng thì có thể chuyển giao kết quả cho khách hàng. Những kết

quả này đóng vai trò là mẫu thử để giúp tìm hiểu thêm các yêu cầu ở những vòng tiếp theo.

- Có thể thực hiện nhiều bước đồng thời, tách nhỏ công việc nhằm dễ quản lý hơn

(The “divide and conquer” rule)

- Giảm rủi ro trong việc thất bại của toàn bộ dự án, rủi ro trải ra nhiều phần nhỏ

- Sử dụng nhân viên giới hạn, họ có thể thực hiện nhưng công việc tương tự ở các

vòng

Nhược điểm

- Phải xác định chức năng đầy đủ và hoàn chỉnh trước khi xác định các vòng gia tăng

- Phải xác định rõ các giao tiếp (interface) cho các module mà thời gian hoàn thành

cách biệt nhiều

- Việc kiểm tra khó khăn hơn trên một hệ thống hoàn chỉnh

- Khách hàng khi thấy sản phẩm lõi có thể nghĩ là công,việc đơn giản ít tốn kém

- Đòi hỏi phải có kế hoạch và thiết kế tốt, phân chia công việc hợp lý, các nhân viên

phải công tác tốt

Nên sử dụng khi nào?

- Khi tất cả yêu cầu được hiểu rõ nhưng mong muốn có sự tiến hóa dần của sản phẩm

- Khi cần phải nhanh chóng đưa sản phẩm với chức năng cơ bản ra thị trường sớm

- Áp dụng cho những sản phẩm có thời gian phát triển dài hơn 1 năm

Chương 3. Quản lý dự án phần mềm

3.1. Giới thiệu

3.1.1. Dự án và dự án phần mềm

a. Dự án

Dự án là tập hợp các công việc được thực hiện bởi một tập thể (có thể có chuyên môn

khác nhau, thực hiện công việc khác nhau, thời gian tham gia dự án khác nhau), nhằm đạt

được một kết quả như dự kiến, trong thời gian dự kiến, với một kinh phí dự kiến.

Đặc trưng của dự án: Các hoạt động có mục tiêu, mang tính thời điểm (có bắt đầu, có

kết thúc), có các ràng buộc xác định và có nhiều rủi ro

b. Dự án phần mềm

Dự án phần mềm (Software project): Sản phẩm phần mềm

Đặc trưng của dự án phần mềm (PM)

o Sản phẩm PM là vô hình

o Không được xác định duy nhất (với cùng yêu cầu)

o Tiến trình phát triển tùy biến, không chuẩn hóa

o Không chấp nhận như các nguyên tắc kỹ nghệ thông thường khác

o Dự án nhiều biến động theo tính chất của sản phẩm & môi trường phát triển

3.1.2. Quản lý dự án

a. Khái niệm

Là ngành khoa học nghiên cứu về việc lập kế hoạch, tổ chức và quản lý, giám sát quá

trình phát triển của dự án nhằm đảm bảo cho dự án hoàn thành đúng thời gian, trong phạm

vi ngân sách đã được duyệt, đảm bảo chất lượng, đạt được các mục đích đề ra.

Là việc áp dụng các chức năng và hoạt động của quản lý vào suốt vòng đời của dự án

để dự án đạt được những mục tiêu đề ra.

Là hoạt động áp dụng các kiến thức, kỹ năng, công nghệ vào các hoạt động quản lý

của dự án.

Trong thuật ngữ của chuyên ngành kỹ nghệ phần mềm, quản lý dự án phần mềm là

các hoạt động trong lập kế hoạch, giám sát và điều khiển tài nguyên dự án (ví dụ như kinh

phí, con người), thời gian thực hiện, các rủi ro trong dự án và cả quy trình thực hiện dự án;

nhằm đảm bảo thành công cho dự án. Quản lý dự án phần mềm cần đảm bảo cân bằng giữa

ba yếu tố: thời gian, tài nguyên và chất lượng. Ba yếu tố này được gọi là tam giác dự án

b. Tại sao phải quản lý dự án

Các vấn đề thường xảy ra đối với một dự án phần mềm

 Thời gian thực hiện dự án vượt mức dự kiến

 Chi phí thực hiện dự án vượt mức dự kiến

 Kết quả của dự án không như dự kiến

Thống kê của Standish Group (2006)

 Có tới 50% trong số các dự án phần mềm thất bại

 Chỉ có 16.2% dự án là hoàn thành đúng hạnvànằmtrong giớihạn ngân sách, đáp

ứng tất cả tính năng và đặc tính như cam kết ban đầu

 Có 52.7% dự án được hoàn thành và đi vào hoạt động nhưng không hoàn thành

đúng hạn và bội chi, thêm nữa không đáp ứng đầy đủ tính năng và đặc tính như

thiết kế ban đầu

 Và có 31.1% dự án thất bại trước khi được hoàn thành

 -> hơn 83.8% dự án thất bại hoặc không đáp ứngnhững yêu cầu ban đầu

 2/3 dự án được hoàn thành vượt quá thời gian và kinh phí dự kiến (Capers Jones)

[bad

 estimates?]

 2/3 dự án được hoàn thành là có độ tin cậy và chất lượng thấp trong một năm đầu

triển khai (Jones).

 Tỷ lệ xảy ra lỗi của PM từ 0.5 đến 3.0 /1000 LOC (Bell Labs survey).

 Civilian software: tối thiểu 100 từ tiếng Anh được sinh ra cho mọi câu lệnh.

o Military: ~ 400 từ (Capers Jones)

3.2. Các hoạt động quản lý

3.2.1. Xác định dự án

a. Xác định yêu cầu chung

Trước tiên cần xác định các yêu cầu chức năng (công việc phần mềm thực hiện) cũng

như phi chức năng (công nghệ dùng để phát triển phần mềm, sử dụng trong hệ điều hành

nào...) của phần mềm. Sau đó cần xác định rõ tài nguyên cần thiết để xây dựng phần mềm.

Tài nguyên ở đây có thể gồm có nhân tố con người, các thành phần, phần mềm có thể sử

dụng lại, các phần cứng hoặc công cụ có sẵn cần dùng đến; trong đó nhân tố con người là

quan trọng nhất. Điều cuối cùng là xác định thời gian cần thiết để thực hiện dự án. Trong

quá trình này cần phải nắm bắt được bài toán thực tế cần giải quyết cũng như các hoạt động

mang tính nghiệp vụ của khách hàng để có thể xác định rõ ràng yêu cầu chung của đề án,

xem xét dự án có khả thi hay không.

b. Viết đề án

Viết đề án là quá trình xây dựng tài liệu mô tả đề án để xác định phạm vi của dự án,

trách nhiệm của những người tham gia dự án; là cam kết giữa người quản lý dự án, người tài

trợ dự án và khách hàng. Nội dung của tài liệu mô tả đề án thường có những nội dung sau:

- Bối cảnh thực hiện dự án: Căn cứ pháp lý để thực hiện dự án, hiện trạng công nghệ

thông tin của khách hàng trước khi có dự án, nhu cầu ứng dụng phần mềm của khách hàng,

đặc điểm và phạm vi của phần mềm sẽ xây dựng.

- Mục đích và mục tiêu của dự án: xác định mục đích tổng thể, tin học hóa hoạt động

nào trong quy trình nghiệp vụ của khách hành, xác định mục tiêu của phần mềm gồm lượng

dữ liệu xử lý, lợi ích phần mềm đem lại.

- Phạm vi dự án: Những người liên quan tới dự án, các hoạt động nghiệp vụ cần tin

học hóa.

- Nguồn nhân lực tham gia dự án: Cán bộ 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 sử dụng , người bảo trì dự án .khách hàng phần mềm phần mềm

- Ràng buộc thời gian thực hiện dự án: Ngày nghiệm thu dự án, ngày bàn giao dự án.

- Ràng buộc kinh phí: Kinh phí trong từng giai đoạn thực hiện dự án.

- Ràng buộc công nghệ phát triển: Công nghệ nào được phép sử dụng để thực hiện dự

án.

- các bên liên quan tới dự án.Chữ kí

c. Lập kế hoạch thực hiện dự án

Lập kế hoạch thực hiện dự án là hoạt động diễn ra trong suốt quá trình từ khi bắt đầu

thực hiện dự án đến khi bàn giao sản phẩm với nhiều loại kế hoạch khác nhau nhằm hỗ trợ

kế hoạch chính của dự án phần mềm về lịch trình và ngân sách.

Các loại kế hoạch thực hiện dự án

 Kế hoạch đảm bảo chất lượng: Mô tả các chuẩn, các qui trình được sử dụng trong

dự án.

 Kế hoạch thẩm định: Mô tả các 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ả các thủ tục, cấu trúc quản lý cấu hình được sử

dụng.

 Kế hoạch bảo trì: Dự tính các yêu cầu về 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ĩ năng và kinh nghiệm của các thành viên

trong nhóm dự án sẽ phát triển như thế nào.

Quy trình lập kế hoạch thực hiện dự án

 Thiết lập các ràng buộc của dự án: thời gian, nhân lực, ngân sách

 Đánh giá bước đầu về các "tham số" của dự án: quy mô, độ phức tạp, nguồn lực

 Xác định các mốc thời gian trong thực hiện dự án và sản phẩm thu được ứng với

mỗi mốc thời gian

Trong khi dự án chưa hoàn thành hoặc chưa bị hủy bỏ thì thực hiện lặp đi lặp lại các

công việc sau:

 Lập lịch thực hiện dự án

 Thực hiện các hoạt động theo lịch trình

 Theo dõi sự tiến triển của dự án, so sánh với lịch trình

 Đánh giá lại các tham số của dự án

 Lập lại lịch thực hiện dự án cho các tham số mới

 Thỏa thuận lại các ràng buộc và sản phẩm bàn giao của mỗi mốc thời gian

 Nếu có vấn đề nảy sinh thì xem xét lại các kĩ thuật khởi đầu đưa ra các biện pháp

cần thiết

Cấu trúc kế hoạch thực hiện dự án:

 Tổ chức dự án

 Phân tích các rủi ro

 Yêu cầu về 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 và báo cáo

3.2.2. Đo và ước lượng

3.2.3. Lập lịch

a. Tại sao phải lập lịch?

- Ước lượng cho chúng ta con số khái quát để làm cơ sở thực hiện dự án

+ Lịch trình cụ thể phụ thuộc vào mô hình lựa chọn

+ Số người tham gia thay đổi theo từng pha của dự án

- Cần phải phân tích chi tiết hơn và lập lịch để kiểm soát công việc

- Lập lịch để kiểm soát công việc (nhiệmvụ)

+ xác định nhiệm vụ

+ thời điểm bắt đầu, thời điểm kết thúc

+ người thực hiện

+ ràng buộc(mối liên hệ giữa các nhiệm vụ)

 cần có độ mềm dẻo về thời gian

b. Nội dung hoạt động lập lịch

* Lập lịch bao gồm các công việc

- Xác định ngày quan trọng: ngày bắt đầu, ngày kết thúc

- Xác định các giai đoạn quan trọng

- Liệt kê các công việc theo thứ tự thực hiện: chỉ ra qua hệ giữa các công việc

+ chỉ ra sự phụ thuộc giữa các công việc

 Các công việc có thể tiến hành đồng thời

 Các công việc chỉ thực hiện khi công việc khác kết thúc

+ giảm tối thiểu các phụ thuộc

 Hạn chế sự chậm trễ

+ thời gian thực hiện dự án phụ thuộc vào đường dài nhất trong đồ thị công việc

 Sơ đồ PERT

- Đánh giá nguồn tài nguyên cần thiết để hoàn thành mỗi công việc: nhân lực, thời

gian, ngân sách.

* Sử dụng bảng để biểu diễn lịch của dự án

- Bảng các giai đoạn quan trọng

Ngày Giai đoạn quan trọng

August 26 Project Kickoff (with client)

October 16 Analysis Review

October 26 System Design Review

November 7 Internal Object Design

Review

November 20 Project Review (with client)

- Bảng các công việc

Ngày bắt đầu – Ngày kết

thúc

Tên công việc

Jul 17-Aug 23 Preplanning Phase

Aug 26 - Sep 24 Project Planning

Sep 11-Oct 8 Requirements Analysis

Oct 9 - Oct 26 System Design

Oct 28-Nov 7 Object Design

Nov 8 - Nov 20 Implementation & Unit

Testing

- Bảng phân công

Tên công

việc

Người thực

hiện

Thời

gian

Công việc

A Hào 3 -

B Hà 2 -

C Loan 1 -

D Phú 2 A

* Có thể sử dụng sơ đồ để xây dựng, phân tích các lịch phức tạp

- Sơ đồ Gantt: biểu diễn quan hệ thời gian giữa con người và công việc

- Sơ đồ PERT: biểu diễ phụ thuộc giữa các công việc

c. Phương pháp đường găng (Critical Path Method)

* Phương pháp lập lịch và kiểm soát dùng cho các dự án phức tạp.

* Các khái niệm và ký pháp:

* Các bước

- Ví dụ: cho bảng công việc

Công

việc

Thòi

gian

Đi sau công

việc

Công

việc

Thòi

gian

Đi sau công

việc

A 1 - K 2 G, I

B 7 - L 3 I

C 8 - M 3 I

D 4 - N 2 K

E 4 A O 1 L, N

F 3 B P 2 G, I, H

G 3 C Q 3 G, I, H

H 4 D R 2 O, P

I 2 E, F S 1 R, Q

- Xác định các đỉnh trung gian của mạng: xét cột “công việc đi trước”

 Bước 1: Khoanh tròn các công việc (cv) là duy nhất/(2/3) trên dòng. Mỗi cv được

khoanh xác định 1 đỉnh ngay sau nó (như sơ đồ ví dụ có 12 đỉnh: a (1), b

       (2), c (3), d (4), i (6), g (7), k (8), h (10) và (e,f) (5), (l,n)

  (9), (o,p) (11),(r,q) (12)).

 Bước 2: Xóa tên cv đã khoanh mà có mặt trong các dòng chứa trên 2 cv và quay

về bước 1.

 Bước 3: Nếu hết các dòng chứa 1 cv chưa được khoanh hay chưa bị xóa, thì xét

đến dòng chứa 2/(3) cv chưa được khoanh hay chưa xóa, lặp lại bước 1 cho đến

hết.

- Vẽ sơ đồ mạng

 Bước 1: Vẽ đỉnh đầu tiên 0

 Bước 2: Từ đỉnh này, vẽ các cv đi ra khỏi nó (lần đầu tiên đó là các cv a, b, c, d

không đi sau cv nào). Thêm 1 đỉnh vào sau mỗi cv/(cặp cv) được khoanh tròn (cụ

thể là đỉnh (1) sau a, (2) sau b, (3) sau c, (4) sau d)

 Bước 3: Xuất phát từ mỗi đỉnh vừa thêm (lần đầu là 1),(2),(3),(4)) ta xét các cv đi

ra từ các đỉnh này, tức là đi sau các cv kết thúc ở đỉnh này và lặp lại bước 2. Nếu

1 cv không đi sau 1 cv nào được khoanh, tức là tất cả các cv đi trước nó đã bị xóa,

thì thêm 1 đỉnh giả có các cv giả đi từ đỉnh sau cv bị xóa đến nó. CV được xét đi

ra từ đỉnh giả này. Sau đó lặp lại bước 2

 Bước 4: Khi đã vẽ hết các cv, thì thêm đỉnh thứ n và những cv nào không có đỉnh

kết thúc sau nó thì cho chúng kết thúc tại đỉnh cuối cùng này

 Bước 5: Xét các cv có hơn 2 cv đi trước nó và trong số đó có cv đã bị xóa. Với

mỗi cv bị xóa, cần thêm 1 cv giả từ đỉnh sau cv bị xóa đến đỉnh mà cv được xét từ

đó đi ra.

Chú ý: Khi đánh số cho các đỉnh mạng phải đảm bảo: số đỉnh ở đầu mỗi cv

phải nhỏ hơn số đỉnh ở cuối cv.

- Thời điểm bắt đầu sớm nhất: ts: tính xuôi từ đỉnh đầu ts(0)=0

- Thời điểm bắt đầu muộn nhất: tm:tính ngược, từ đỉnh kết thúc tm(13)=ts(13)=18

- Thời gian dự phòng công việc: tdf

- Công việc găng, đường găng

- Biểu đồ lịch trình dự án (Gantt)

3.2.4. Tổ chức dự án

Tổ chức dự án rất quan trọng, là yếu tố quyết định cho sự thành công

Bao gồm các hoạt động

- Chọn nhân sự thích hợp

+ Các yếu tố cần xem xét khi chọn nhân sự

 Kinh nghiệm

o Hiểu biết lĩnh vực ứng dụn

o Kinh nghiệm với môi trường phát triển

o Hiểu biết về ngôn ngữ lập trình

 Đào tạo

 Khả năng

o Khả năng giao tiếp

o Khả năng thích ứng, khả năng học

 Thái độ

 Tính cách

- Chọn cấu trúc của nhóm

+ Nhóm phi hình thức

 Các thành viên của nhóm có vai trò như nhau

 Nhóm nhỏ

 Các thành viên đều có năng lực và kinh nghiệm

 Dự án khó

+ Nhóm chief-programmer

 Gồm có

o Trưởng nhóm (chief-programmer): thực hiện phân tích, thiết kế, mã hóa,

kiểm thử

o Trợ lý: hỗ trợ trưởng nhóm phát triển, kiểm thử

o Thư ký: quản lý thông tin

o Các chuyên gia hỗ trợ

 Quản lý, lập tài liệu, lập trình, kiểm thư,…

 Phụ thuộc chủ yếu vào trưởng nhóm

 Trưởng nhóm phải có năng lực

+ Nhóm phân cấp

 Dự án lớn được chia thành nhiều dự án nhỏ

 Mỗi dự án nhỏ được thực hiện bởi một nhóm

 Mỗi nhóm có một trưởng nhóm

 Mỗi thành viên cấp dưới phải báo cáo công việc với người quản lý trực tiếp

 Mỗi thành viên phải được đào tạo kỹ năng để thực hiện vai trò của mình

- Chọn kích thước của nhóm

+ Kích thước nhóm nên tương đối nhỏ: dưới 8 người

 Giảm thời gian giao tiếp

 Dễ dàng làm việc cùng nhau

+ Không nên quá nhỏ

 Nhóm bảo đảm tiếp tục làm việc, nếu có thành viên ra đi

+ Đối với một dự án, số người trong nhóm có thể thay đổi

+ Khi một dự án chậm trễ, thêm người vào dự án không bao giờ giải quyết được

vấn đề

- Xác định vai trò của các thành viên trong nhóm

+ Trưởng dự án

 Chịu trách nhiệm một dự án

 Bảo đảm nhóm có đầy đủ thông tin và nguồn tài nguyên cần thiết

 Phân công công việc cho các thành viên

 Kiểm tra thời hạn các công việc

 Giao tiếp với khách hàng

- Quản lý giao tiếp giữa các thành viên trong nhóm

+ Các đặc điểm trong giao tiếp nhóm

 Các thành viên có vị trí cao thường áp đặt các cuộc trao đổi

 Nhóm có cả nam và nữ thường giao tiếp tốt hơn

 Giao tiếp phải qua một người điều phối trung tâm thường không hiệu quả

 Tất cả các thành viên nên có sự tham gia vào các quyết định ảnh hưởng đến cả

nhóm

 Tính cách của các thành viên

o Quá nhiều thành viên có cùng tính cách cũng có thể không tốt

 Hướng công việc: mỗi người đều muốn thực hiện công việc riêng

 Hướng cá nhân: mỗi người đều muốn làm ông chủ

 Hướng tương tác: nhiều họp hành mà ít thực hiện cụ thể

o Một nhóm nên cân bằng giữa các tính cách.

3.2.5. Theo dõi thực hiện dự án, điều chỉnh lịch biểu

Khi xây dựng dự án, các thành viên của nhóm phải báo cáo việc sử dụng thời gian

cho mỗi hoạt động ở các giai đoạn. Hơn nữa, mỗi cá nhân phải viết một báo cáo ngắn về

tiến bộ của bản thân. Báo cáo này sẽ tóm lược chất lượng công việc, những vấn đề còn tồn

tại và các sai sót hoặc các mâu thuẫn khác có thể làm trì hoãn công việc. Nếu một công việc

bị chậm so với kế hoạch, thì anh ta phải giải trình về sự chậm trễ. Quản trị viên dự án và kỹ

sư hệ thống phải xem xét báo cáo và thời gian biểu để xem liệu có cần bổ sung thêm gì

không.

Cả kỹ sư phần mềm và quản trị viên dự án phải vạch ra các tiến bộ thật sự của các cá

nhân so với thời gian biểu dự kiến. Khi sự tiến triển có vẻ chậm lại, quản trị viên dự án cần

phải hỏi anh ta về các tồn tại cụ thể. Liệu đã đủ tiềm lực, hoặc liệu anh ta có nghĩ anh ta có

thể đáp ứng được các hoạch định không. Nếu công việc đã bị đánh giá thấp, kế hoạch phải

được kiểm tra lại để xem việc phân chia thời gian có làm chậm trễ công việc hay không, ảnh

hưởng tích lũy của sự thay đổi phải được kiểm tra để xem công việc có được hoàn tất

không. Nếu không, quản trị viên dự án cần thảo luận vấn đề với người quản lý của anh ta và

họ sẽ quyết định các hành động cần thiết phải làm.

Cần chú rằng phải sớm chỉ ra các vấn đề tiềm tàng trước khi chúng trở thành những

vấn đề lớn. Nếu một người không thể hoàn thành công việc chỉ vì anh ta được phân quá

nhiều công việc, phải phân công lại cho một người khác. Nếu họ không có đủ thời gian

kiểm định, phải thu xếp để có thêm thời gian. Sự quản lý tích cực sẽ ngăn chặn được nhiều

vấn đề. Vấn đề tiếp theo là tính kỹ luật và lao động ảnh hưởng lên kế hoạch các công việc

thay thế, điều chỉnh kế hoạch khi cần thiết và tiếp tục kiểm soát các vấn đề cho đến khi

chúng được giải quyết.

Khi cần thiềt, phải nói cho khách hàng biết về các vấn đề có thể không giải quyết

được do vậy họ sẽ được chuẩn bị cho sự chậm trễ nếu điều đó là không tránh khỏi. Khi sự

thay đổi là cần thiết, cho khách hàng biết về sự thay đổi về ngày giờ kế hoạch thậm chí khi

ngày hoàn tất công việc không thay đổi.

Có nhiều dạng vấn đề tồn đọng có thể xảy ra và quản trị viên dự án phải giám sát,

thay đổi trong suốt quá trình phát triển của dự án.

Trong việc xác định phạm vi dự án, quản trị viên dự án phải xem xét các điều sau:

 Khách hàng có hợp tác không?

 Tất cả các đối tác có nhìn nhận và quan tâm?

 Những người sử dụng được phỏng vấn có đưa ra những thông tin đầy đủ và chính

xác?

 Những người sử dụng có tham gia như mong đợi?

 Liệu có vấn đề chính sách bên ngoài nào được nêu ra?

 Quy mô, các công việc được xác định đã hợp lý chưa?

 Bằng việc phân tích, quản trị viên dự án biết hầu hết người sử dụng và họ làm

việc thế nào, cần chỉ ra những vấn đề chính sách tiềm tàng, giải quyết chúng và

nên hài lòng với quy mô dự án.

Các hoạt động được giao cho các ban liên quan:

 Liệu tất cả các nhà phân tích có biết quy mô hoạt động và làm việc trong khuôn

khổ đó?

 Công việc phân tích nhấn mạnh vào cái gì và như thế nào?

 Liệu mọi người có quan tâm và thích thú với công việc?

 Liệu có va chạm giữa các nhân viên của ban hoặc giữa những người sử dụng?

 Liệu mọi người có biết họ đang làm gì không?

 Có sự phản hồi liên tục được người sử dụng sửa đúng lại, trong kết quả phỏng

vấn?

 Các thành viên của ban có bắt đầu hiểu công việc và tình hình của người sử dụng?

 Các thành viên của ban dự án khách quan và không ép người sử dụng theo ý

tưởng của mình

 Các tài liệu viết ra đã hoàn thiện? Người sử dụng có đồng ý?

 Việc phân tích có chỉ đúng ra các vấn đề tồn tại của người sử dụng? Các nhân

viên có phân tích và mô tả chính xác các việc cần làm mà không thêm thắt?

 Việc đánh máy, in ấn, sao chụp và các hỗ trợ biên chép khác là có thể chấp nhận?

 Sự giao tiếp giữa các ban và giữa các ban và người sử dụng có đáng hài lòng

không?

 Dự án có đúng hạn? Tình trạng đường lối phê bình? Có thay đổi nếu công việc

kết thúc sớm?

 Tồn tại lớn nhất hiện tại ở đâu? Làm thế nào để làm nhẹ bớt các vấn đề tồn tại?

 Điều gì chúng ta không biết có thể làm thiệt hại đến công việc?

Các yêu cầu chức năng là kết quả từ việc phân tích cần mô tả ứng dụng nào sẽ được

áp dụng, và phải luôn cẩn thận trước các yêu cầu của người sử dụng. Một vấn đề mà nhiều

dự án gặp phải là người sử dụng muốn một ứng dụng chức năng đơn thuần nhưng các nhà

phân tích lại tạo ra một ứng dụng giá cao với các chức năng của người sử dụng nhưng có

nhiều đặc tính không cần thiết. Vấn đề này, nếu xảy ra, phải được giải quyết trước khi việc

phân tích kết thúc hoặc các chức năng phụ thêm sẽ được đưa vào ứng dụng kết quả. Khi vấn

đề thiết kế quá mức nảy sinh, điều quan trọng là phải cố gắng truy cập đến các phân tích cụ

thể để tái huấn luyện. Do vậy, quản trị viên dự án quan tâm đến:

 Các nhà phân tích có biết đến các ứng dụng?

 Việc chuyển dịch sang môi trường hoạt động có đúng và hoàn tất?

 Những người sử dụng có tham gia như mong đợi? Những người sử dụng có quan

tâm đúng mức đến việc thiết kế màn hình chạy thử và chấp nhận các phê bình?

 Mọi người có quan tâm và thích thú công việc?

 Có sự va chạm giữa các nhân viên hoặc giữa nhân viên và người sử dụng?

 Mọi người có biết họ đang làm gì?

 Các nhân viên có chú ý tới sự thay đổi trách nhiệm của họ và họ có cảm thấy

thoải mái để có thể tiếp tục công việc?

 Sự giao tiếp giữa các ban dự án và người sử dụng có hài lòng?

 Dự án diễn biến đúng kế hoạch? Tình trạng phê bình thế nào? Có thay đổi do

công việc hoàn thành sớm không?

 Vấn đề lớn nhất bây giờ là gì? Có thể làm gì để giảm nhẹ các vấn đề?

 Điều có thể gây nguy hại cho chúng ta mà không biết? Môi trường thực hiện có

thích hợp cho ứng dụng?

 Phần mềm quản lý dữ liệu có thể phù hợp với ứng dụng này không?

Do sự phát triển của chương trình nên số các thành viên dự án có thể thường xuyên

tăng thêm ngày càng nhiều. Sự trao đổi các thông tin là cần thiết để nắm bắt được vị trí của

mọi thành viên dự án và các thành viên cũng nắm bắt được sự phát triển của dự án. Nên quá

trình viết và kiểm thử chương trình sẽ được điều chỉnh trong quá trình trao đổi thông tin và

chạy chương trình.

Để đáp ứng được, phải quan tâm:

 Các thành viên dự án có biết được vai trò phần việc của họ trong dự án hay

không? Họ có đánh giá được phần việc của mình hay không? Các thành viên hiện

tham gia dự án có đảm đương được công việc mà họ và các thành viên đang làm

không?

 Thời gian kiểm thử chương trình đã đủ chưa? Thông tin truy cập đã đầy đủ chưa?

 Thành viên dự án có đủ hiểu biết về các công nghệ đang sử dụng để làm việc độc

lập không?

 Các thành viên mới có đủ trình độ để làm việc với các cố vấn có kinh nghiệm hay

không?

 Người sử dụng có yêu cầu thêm những thay đổi hay không?

 Người sử dụng có tham gia vào quá trình kiểm thử thiết kế, có dùng các tài liệu

về phát triển, nâng cấp, hướng dẫn hay không?

 Các thành phần sửa chữa phản hồi có gây cho khách hàng nghi ngờ chương trình

có lỗi không?

 Các giao thức sẽ được sử dụng ngày càng nhiều có thể hiện được ứng dụng hoạt

động như thế nào hay không?

 Qua từng bước thực hiện chương trình, có phát sinh ra lỗi không? Những lỗi này

có thể điều chỉnh được không?

Trong suốt quá trình thực hiện chương trình cũng như trong quá trình thực hiện các

bước kiểm thử, các kiểm tra về sự thích ứng của chương trình và về các mức hệ thống liên

quan sẽ tăng dần. Các cơ sở dữ liệu được thiết lập và hoàn chỉnh dần. Môi trường điều hành

được chuẩn bị.

Các cơ cấu liên quan được đưa ra từ ứng dụng được thực hiện dưới dạng mã làm cho

nó được thực thi một cách chính xác. Các dạng câu hỏi đặt ra cho người quản lý có thể có

các dạng sau:

 Các thành viên hiện tại của dự án có đảm nhiệm được phần công việc của mình

hay không? Mọi thành viên có hiểu được công việc họ đang làm hay không?

 Thời gian kiểm thử chương trình đã đủ chưa? Thông tin truy cập đã đầy đủ chưa?

 Người sử dụng có yêu cầu thêm những thay đổi hay không? Người sử dụng có

tham gia vào quá trình kiểm thử hay không?

 Các thành phần sửa chữa phản hồi có gây cho khách hàng các nghi ngờ chương

trình có lỗi không?

 Qua từng bước thực hiện chương trình, có phát sinh ra lỗi không? Những lỗi này

có thể điều chỉnh được không?

 Quá trình kiểm tra ở mức độ hệ thống có thể hiện được các chức năng như đã đặt

ra hay không?

 Quá trình kiểm tra sự thích ứng có xác thực được tất cả các liên kết trung gian hay

không? Nó có tác dụng như thế nào tới việc chứng tỏ độ tin cậy của các liên kết

này trong suốt quá trình kiểm thử hệ thống.

 Chúng ta không biết những gì về môi trường điều hành mà nó có thể ảnh hưởng

tới dự án?

 Phần mềm cơ sử dữ liệu làm việc có hoàn hảo không? Quy trình phục hồi và lưu

trữ dữ liệu có đầy đủ cho quá trình kiểm thử hay không?

 Chúng ta có thể sử dụng các kiểm tra về sự thích ứng của chương trình và về hệ

thống như thế nào để phát triển các giai đoạn kiểm tra hồi quy.

 Các thông tin đã hoàn tất chưa? Các thành viên dự án đã làm việc đúng khả năng

chưa? Chúng ta có thể đưa các thành viên trong dự án đến thực hiện các dự án

khác được không? Nếu chúng ta cho phép họ đi, thì ai sẽ thay thế vị trí họ khi có

các vấn đề xảy ra?

Khi quá trình kiểm thử kết thúc, các phần của ứng dụng đã thực sự sẵn sàng cho sử

dụng. Nên có một sơ đồ cho ứng dụng điều hành thực tế, điều đó sẽ dễ dàng cho người sử

dụng trong việc dùng chương trình để tránh có quá nhiều hỏng hóc. Sự dễ dàng trong quá

trình sử dụng này sẽ tạo cho người lập dự án có thời gian cố định những lỗi sai đã phát hiện

trong quá trình viết chương trình mà không có áp lực giám sát nào. Vấn đề hiện tại là tập

trung vào việc đưa ra ứng dụng làm việc trong môi trường đã được định hướng cho người sử

dụng nó. Các câu hỏi liên quan sẽ bao gồm:

 Vị trí đã được chuẩn bị đầy đủ chưa? Điều kiện về không gian đã đầy đủ? Thiết

kế về ánh sáng và môi trường làm việc đã đầy đủ?

 Người sử dụng đã được đào tạo hoàn hảo và đã sẵn sàng làm việc?

 Chu trình làm việc và đánh giá kết quả đã được chỉ ra đầy đủ cho phép việc tiến

hành và kiểm tra các kết quả đạt được.

 Khi tìm ra lỗi chúng có thể điều chỉnh được không?

 Người sử dụng có nắm bắt được công việc như dự kiến?

 Các thành viên hiện tại của dự án có thể đảm nhiệm được phần việc của họ? Tất

cả mọi người có đủ công việc để làm không? Họ có thời gian rỗi để tham gia các

dự án khác không?

 Thông tin trao đổi giữa các nhóm với nhau và giữa các nhóm với người sử dụng

có xuất hiện phù hợp không? Người sử dụng có thể nói bất kỳ khi nào có vấn đề

xảy ra không? Họ có tham gia vào quá trình lập nên các quy định cho vấn đề sửa

chữa lỗi hay không?

Các câu hỏi trên là những vấn đề kỹ thuật và nên được trình lên cho chủ dự án. Quản

trị viên dự án là người nắm bắt và quan tâm đến tất cả các vấn đề. Việc biên dịch các báo

cáo về tiến trình hoạt động cá nhân và tiến trình hoạt động dự án trong một dự án cho phép

người quản lý và bất kỳ nhân viên nào đều có thể xem xét lại những quyết định, các vấn đề

xuất hiện trong quá trình tiến hành.

3.2.6. Viết báo cáo dự án

PHẦN ĐẦU BÁO CÁO:

- Tóm tắt

- Lý do chọn đề tài

- Mục tiêu dự án

- Địa điểm thực hiện dự án

- Đối tượng thụ hưởng

- Những lợi ích về mặt phát triển cộng đồng, xây dựng bền vững và bảo vệ môi

trường

- Phương pháp nghiên cứu

- Các đối tác hỗ trợ mặt kinh phí và triển khai

- Sơ lược về chi phí/giá thành

- Kết quả dự kiến

PHẦN CHÍNH BÁO CÁO: nên chia thành các chương, mục như sau:

I. Thông tin chung về dự án (tối đa 1 trang A4)

1. Tên dự án

2.Trưởng nhóm dự án

3. Danh sách những người tham gia

II. Đặt vấn đề

Khái quát về tình hình nghiên cứu có liên quan đến đề tài. Từ đó làm nổi bật

sự cần thiết phải nghiên cứu.

III Mục tiêu và lợi ích của đề tài

1. Mục tiêu đề tài

2. Lợi ích đề tài đề tài có thể mang lại nếu được thực hiện

IV. Phương pháp nghiên cứu, cách tiếp cận

V. Nội dung nghiên cứu và kết quả đạt được

1. Mô tả chi tiết nội dung nghiên cứu và kết quả đạt được

2. Nêu ra các thuận lợi và khó khăn trong quá trình thực hiện từng giai đoạn cùng

với biện pháp khắc phục

3. Những chứng minh cho thấy khả năng ứng dụng dự án và duy trì dự án

4. Dự kiến sản phẩm và địa chỉ ứng dụng

* Loại sản phẩm:

* Địa chỉ có thể ứng dụng hoặc chuyển giao kết quả nghiên cứu:

5 . Dự kiến kinh phí thực hiện

VI. Kết luận và kiến nghị

- Những kết quả nghiên cứu chủ yếu đã thực hiện được. So sánh với mục đích yêu

cầu đề ra đã đạt được đến mức độ nào. Nêu những hạn chế, nguyên nhân.

- Nêu lên kiến nghị có liên quan đến đề tài / dự án. Đề xuất hướng tiếp tục nghiên

cứu, hoàn thiện hoặc biện pháp chuyển giao cho sản xuất...

VII. Tài liệu tham khảo

VI. Phụ lục

3.3. Các yếu tố quản lý

3.3.1. Quản lý tài nguyên

Chi phí (trả công) con người là phần chính của chi phí xây dựng phần mềm. Ngoài

ra, năng lực của người phát triển phần mềm lại rất biến thiên, kéo theo sự phức tạp trong

tính toán chi phí. Phát triển phần mềm được tiến hành theo nhóm. Kích thước tốt của nhóm

là từ 3 đến 8 ngưòi. Phần mềm lớn thường được xây dựng bởi nhiều nhóm nhỏ. Một nhóm

phát triển có thể gồm các loại thành viên sau:

• Người phát triển

• Chuyên gia về miền ứng dụng

• Người thiết kế giao diện

• Thủ thư phần mềm (quản lý cấu hình phần mềm)

• Người kiểm thử

Một nhóm phát triển cần có người quản lý, và người có vai trò lãnh đạo về mặt kĩ

thuật. Một đặc trưng của làm việc theo nhóm là sự trao đổi thông tin (giao tiếp) giữa các

thành viên trong nhóm. Thời gian dùng cho việc giao tiếp có thể chiếm đến nửa tổng thời

gian dành cho pháp triển phần mềm.

Ngoài ra, thời gian không dùng cho phát triển sản phẩm cũng chiếm một phần lớn

thời gian còn lại của người lập trình. Một người có thể đồng thời làm việc cho nhiều nhóm

(dự án) phần mềm khác nhau. Điều này làm cho việc tính toán giá thành phần mềm phức

tạp. Cần ghi nhớ, trong sản xuất phần mềm thì

- Năng lực của các thành viên là không đồng đều

- Người tốt (nhất) có thể sản xuất hơn 5 lần trung bình, người kém có thể không cho

kết quả gì

- Một số công việc quá khó đối với mọi người

Không nên tăng số thành viên một cách vô ý thức, vì như thế chỉ làm tăng sự phức

tạp giao tiếp giữa các thành viên, khiến công việc nhiều khi chậm lại. Một số việc (phức tạp,

đặc thù) chỉ nên để một người làm.

3.3.2. Quản lý cấu hình

Thực tế, có khá nhiều định nghĩa hoặc khái niệm khác biệt về quản lý cấu hình, tuy

rằng chúng vẫn có những điểm chung cơ bản. Trong phạm vi bài viết, chúng tôi muốn phần

nào làm sáng tỏ một số định nghĩa và thuộc tính cơ bản của quản lý cấu hình trong quy trình

sản xuất phần mềm.

Những ai quan tâm đến quy trình sản xuất phần mềm, chắc hẳn không ít lần gặp khái

niệm về quản lý cấu hình (Configuration Management). Ta dễ dàng tìm thấy các yêu cầu về

quản lý cấu hình (QLCH) một cách trực tiếp hay gián tiếp trong các bộ tiêu chuẩn hoặc mô

hình quy trình sản xuất phần mềm (QTSXPM) thông dụng hiện nay như CMM/CMMI, ISO

15504 hoặc ISO 9001:2000. Trong CMM và CMMI, QLCH là yêu cầu bắt buộc ngay từ

mức 2, là mức cơ bản nhất của hai mô hình này.

Thực tế, có khá nhiều định nghĩa hoặc khái niệm khác biệt về QLCH, tuy rằng chúng

vẫn có những điểm chung cơ bản. Trong phạm vi bài viết, chúng tôi muốn phần nào làm

sáng tỏ một số định nghĩa và thuộc tính cơ bản của QLCH trong QTSXPM.

a. Tại sao cần Quản lý cấu hình?

Chắc hẳn trong chúng ta đã ít nhất một lần gặp những tình huống sau:

• Một lỗi (bug) nào đó của phần mềm đang xây dựng đã tốn nhiều công sức sửa chữa,

bỗng “thình lình” xuất hiện trở lại.

• Một chức năng (function) nào đó của phần mềm đã được phát triển và kiểm tra cẩn

thận bổng thất lạc hoặc biến mất một cách khó hiểu.

• Một chương trình (program) đã được kiểm tra hết sức cẩn thận, bỗng nhiên không

“chạy” được nữa.

• Một chương trình gồm nhiều đơn thể (module), mỗi đơn thể gồm nhiều chức năng,

các chức năng được chia ra cho nhiều lập trình viên, mỗi chức năng bao gồm nhiều tập tin

mã nguồn (source code) với nhiều phiên bản (version) khác nhau. Khi tích hợp hệ thống và

biên dịch, trong hàng chục tập tin source code với hàng trăm version, tập tin nào, version

nào là đúng và cần phải lấy để tiến hành tích hợp?

Các vấn đề trên sẽ không xảy ra nếu như trong dự án, việc QLCH được thực hiện

nghiêm túc và kiểm soát chặt chẽ.

Ta có thể tham khảo định nghĩa ngắn gọn sau từ CMM và ISO 15504: “Mục đích của

QLCH là để thiết lập và bảo đảm tính toàn vẹn của các sản phẩm trung gian cũng như các

sản phẩm sau cùng của một dự án phần mềm, xuyên suốt chu kỳ sống của dự án đó.”

Nói cho dễ hiểu và gần gũi, QLCH bao gồm các công việc về nhận dạng, tổ chức, và

quản lý các thay đổi đối với những sản phẩm đang được xây dựng bởi một nhóm lập trình

viên, từ các sản phẩm trung gian đến sản phẩm sau cùng.

QLCH tốt sẽ giải quyết được hàng loạt những khó khăn trong các dự án, đặc biệt

trong các dự án lớn:

- Cập nhật đồng thời: Khi 2 hoặc nhiều lập trình viên làm việc cách biệt nhau nhưng

trên cùng một chương trình hoặc dự án, những thay đổi mà người này thực hiện có thể sẽ

phá vỡ kết quả làm việc của người khác. Ví dụ: Sản phẩm anh A sử dụng kết quả công việc

của anh B, sản phẩm của anh B thay đổi có thể làm cho sản phẩm anh A không chạy được

nữa.

- Chia sẻ source code: Trong các hệ thống lớn, khi các chức năng chung bị thay đổi,

tất cả những người liên quan phải được biết.

- Phiên bản phần mềm (release): Hầu hết các chương trình hoặc hệ thống lớn được

phát triển với nhiều release tiến hóa từ thấp đến cao. Trong trường hợp một release khách

hàng đang dùng, release khác đang được kiểm tra (test), và một release khác nữa đang trong

quá trình phát triển, khi có lỗi (bug) xảy ra, việc sửa lỗi phải đồng bộ giữa ba phần này, nếu

không quản lý source code tốt, vấn đề đồng bộ rất khó thực hiện được. Nếu lỗi ở release

khách hàng đang dùng, nó phải được sửa chữa trong tất cả các release sau đó.

Khi nào thì cần tiến hành QLCH? QLCH được thực hiện xuyên suốt chu kỳ sống của

dự án, từ lúc bắt đầu đến khi kết thúc, thậm chí vẫn còn trong giai đoạn bảo trì sản phẩm sau

dự án.

b. Hoạt động QLCH

Trước khi đi vào chi tiết, ta cần tìm hiểu 2 khái niệm rất cơ bản trong QLCH:

• Configuration Item - CI: định danh này trong QLCH là tên gọi của các sản phẩm,

sản phẩm trung gian, một tập tin (file) hoặc nhóm file, tài liệu hoặc nhóm tài liệu trong một

dự án mà ta cần phải quản lý và kiểm soát. Nói chung là những “món” được tạo ra trong

một dự án mà ta cần phải quản lý, ví dụ: một file source code, tài liệu về yêu cầu sản phẩm,

bản thiết kế v.v.

• Baseline: một điểm “mốc” được thỏa thuận bởi những người liên quan trong một dự

án, sao cho sau điểm “mốc” này, mọi thay đổi phải được thông báo tới tất cả những người

có liên quan.

Lập kế hoạch QLCH (Configuration Management planning)

Thông thường, việc lập kế hoạch cho QLCH được thể hiện trong tài liệu có tên Kế

hoạch quản lý cấu hình (Configuration Manegement Plan – CMP). Bản kế hoạch này

thường bao gồm:

• Ý nghĩa, mục đích và phạm vi áp dụng của bản kế hoạch

• Vai trò và trách nhiệm của nhóm, cá nhân trong dự án thực hiện các hoạt động khác

nhau liên quan đến QLCH. Định nghĩa rõ ràng ai thực hiện (perform), ai xem xét (review),

ai phê duyệt (approve) trên các CI của dự án, cũng như vai trò của khách hàng, người sử

dụng đầu cuối.

• Công cụ (tool), môi trường (environment) và cơ sở hạ tầng (infrastructure). Phần

này mô tả các công cụ phần mềm hoặc quy trình thủ tục được sử dụng hỗ trợ QLCH, chẳng

hạn công cụ quản lý phiên bản sản phẩm (version control); mô tả vị trí các máy chủ, máy

trạm, cấu hình hệ thống client-server,...

• Phương pháp định danh và thiết lập baseline trên các CI

• Quy ước đặt tên trong dự án, gồm cả tên file

• Quy trình xử lý và quản lý các thay đổi (change control process)

• Chỉ định thành viên nhóm Configuration Control Board (CCB)

• Thông tin nơi lưu trữ các CI

• Kiểm kê và báo cáo cấu hình (configuration accounting and reporting)

• Quy trình thủ tục lưu trữ và chép dự phòng (backup and archieve)

Các điểm trong bản kế hoạch trên sẽ được giải thích rõ trong các phần tiếp sau.

Định danh/đánh số các CI (Identification of Configuration Items)

Định danh là một trong những hoạt động nền tảng của QLCH. Mục đích của định

danh là để xác định tính duy nhất của một CI, cũng như mối quan hệ của nó với các CI

khác. Nó bao gồm việc mô tả tên, đánh số, đánh dấu đặc trưng, giúp nhận biết và phân biệt

một CI với các CI hay thành phần khác.

Bạn có thể nhận thấy hình thức định danh tương tự trong đời sống thực tế. Ví dụ,

người ta đánh số bàn trong nhà hàng nhằm giúp người phục vụ mang đúng thức ăn cho

khách.

Trong sản xuất phần mềm, một CI có thể bao gồm một hay nhiều file. Ví dụ: một

module tên ExpMod có thể được coi là một CI, module này có 2 file ExpMod.h và

ExpMod.c.

Ví dụ: PRJ001_REQB_1.0.4_draft_B cho biết:

Số ID của dự án: PRJ001

Số ID của Item : REQB

Phiên bản: 1.0.4_draft_B

Trong một dự án, thường có rất nhiều file source code, quy tắc cơ bản là: các file

cùng tạo nên một khối chức năng được gom chung thành một CI.

Kiểm soát phiên bản (Version Control)

Có nhiều định nghĩa và cách hiểu khác nhau về version control, ở đây chúng tôi chỉ

muốn định nghĩa nó ở khía cạnh thông dụng, sát với bản thân cụm từ nhất.

Version control là sự kiểm soát các phiên bản (version) khác nhau của một CI (bao

gồm việc định danh và sự lưu trữ CI đó).

Thế phiên bản là gì? một phiên bản là một thực thể mới của một CI sau khi đã qua

một hoặc nhiều lần xem xét và thay đổi.

Hiện có nhiều công cụ trên thị trường hỗ trợ cho việc kiểm soát phiên bản, một số

công cụ thông dụng là: Visual Source Safe của Microsoft, ClearCase của Rational, CVS

(nguồn mở).

Mỗi phiên phản sẽ có một số ID đầy đủ, và được tăng dần cho mỗi phiên bản mới.

Lưu ý rằng phiên bản của một CI khác với phiên bản của các file thành phần của CI

đó. Trong ví dụ trên, phiên bản của CI “ExpMod” khác với phiên bản của file thành phần

“ExpMod.h” và “ExpMod.c”.

Các phiên bản quan trọng của một CI có thể được đánh dấu để nhận biết một “mốc”

quan trọng trong tiến trình phát triển CI đó, phiên bản mà CI được phê duyệt hay baseline.

Quản lý baseline (Baseline Management)

Cũng như Version Control, baseline có nhiều cách hiểu khác nhau, trong phạm vi bài

viết này, chúng tôi chọn ý nghĩa tương đối phổ biến. Trong thực tế thường gặp các loại

baseline sau:

• Chức năng (functional)

• Kế hoạch (planning)

• Yêu cầu (requirements)

• Sản phẩm (product)

• Bản phân phối (release)

• Kiểm tra (test)

• Môi trường hoạt động (environment)

Quản lý baseline bao gồm:

• Chọn các CI cho mỗi loại baseline

• Tiến hành “ghim chết” baseline tại thời điểm sau khi các thay đổi đã được chấp

thuận và phê chuẩn.

Thông thường, baseline được tiến hành tại điểm kết thúc của mỗi giai đoạn hay tại

các “mốc” quan trọng trong dự án.

Đồng thời, trong quản lý baseline, vai trò và nhiệm vụ của những người thiết lập

hoặc phê chuẩn baseline cũng phải được định nghĩa.

Kiểm soát thay đổi (Change control)

Khi phát triển hoặc bảo trì một sản phẩm phần mềm, việc thay đổi yêu cầu là không

thể tránh khỏi.

Mục đích của change control là để kiểm soát đầy đủ tất cả các thay đổi ảnh hưởng

đến việc phát triển một sản phẩm. Đôi lúc chỉ một vài yêu cầu thay đổi nhỏ của khách hàng,

tất cả các chặng của quy trình phát triển phần mềm từ thiết kế, đến viết code, đến kiểm tra

sản phẩm đều phải thay đổi theo.

Nếu các thay đổi này không được kiếm soát chặt chẽ sẽ dẫn đến rất nhiều sai sót. Xét

ví dụ sau: 5 lập trình viên cùng làm trong một dự án, nhưng chỉ có 3 được thông báo về việc

thay đổi thiết kế. Kết quả là khi tích hợp, hệ thống sẽ không vận hành được.

Yêu cầu trong kiểm soát thay đổi là mọi sự thay đổi phải được thông báo đến tất cả

những người hoặc nhóm làm việc có liên quan.

Các bước cơ bản của kiểm soát thay đổi bao gồm:

• Nghiên cứu, phân tích

• Phê chuẩn hoặc không phê chuẩn

• Thực hiện việc thay đổi

• Kiểm tra việc thay đổi

• Xác lập baseline mới

Trong kiểm soát thay đổi, ta cũng thường gặp khái niệm “nhóm kiểm soát thay đổi”

gọi tắt là CCB (Change Control Board), nhóm này được thành lập trong từng dự án. CCB

thông thường bao gồm:

• Người QLC H (Configuration Manager)

• Trưởng dự án (Project Manager)

• Trưởng nhóm (Technical Lead)

• Trưởng nhóm kiểm soát chất lượng (Test Lead)

• Kỹ sư chất lượng (Quality Engineer)

• Và những ai bị ảnh hưởng bởi các thay đổi

Nhiệm vụ của CCB thường là:

• Bảo đảm tất cả các thay đổi là được các bộ phận liên quan nhận biết và tham gia

• Xem xét, phê chuẩn hoặc phủ quyết các thay đổi trên các baseline

• Kiểm tra, xác nhận các thay đổi

• Phê chuẩn các bản phân phối sản phẩm (release) đến khách hàng

Báo cáo tình trạng cấu hình (Configuration Status Accounting)

Công việc này bao gồm việc ghi nhận và báo cáo tình trạng của các CI cũng như yêu

cầu thay đổi, tập hợp số liệu thống kê về CI, đặc biệt là các CI góp phần tạo nên sản phẩm.

Nó trả lời những câu hỏi như: có bao nhiêu file bị ảnh hưởng khi sữa chữa một lỗi phần

mềm nào đó?

Kết quả của công việc này được ghi nhận trong một báo cáo mang tên Configuration

Status Accounting Report (CSAR). Báo cáo này thường làm rõ những điểm sau:

• Liệt kê tất cả baseline và CI thành phần hoặc có liên quan.

• Làm nổi bật các Cl đang được phát triển hoặc vừa bị thay đổi

• Liệt kê các thay đổi còn đang dang dở hay đang hoàn thành, và các baseline bị ảnh

hưởng (bởi sự thay đổi đó)

Việc báo cáo này được làm thường xuyên và định kỳ, xuyên suốt dự án.

Auditing

(Audit là một thuật ngữ rất thường dùng, cho nhiều ngành nghề khác nhau, tuy nhiên

trong lĩnh vực sofware, chúng tôi không tìm thấy từ tiếng Việt tương đương phản ánh đủ ý

nghĩa, do vậy xin giữ nguyên thuật ngữ gốc, nó có ý nghĩa gần với “kiểm tra” và “xem

xét”). Có 3 loại audit thường được thực hiện.

- CSAR Audit: Thường được làm sau mỗi lần một CSAR được tạo ra, việc kiểm tra

bao gồm:

• Bảo đảm các baseline mới nhất được liệt kê trong CSAR

• Bảo đảm tất cả CI tạo nên một baseline được liệt kê

• Kiểm tra các CI đã bị thay đổi từ lần baseline trước đó, so sánh chúng với các yêu

cầu thay đổi để khẳng định rằng sự thay đổi trên CI là hợp lý.

- Physical configuration audit (PCA): nhằm mục đích khẳng định xem những gì

khách hàng yêu cầu có được hiện thực hay không. Gồm 2 việc:

• Kiểm tra vết để phản ánh tính 2 chiều (traceability) giữa yêu cầu khách hàng và

việc hiện thực code trong dự án.

• Xác định những gì sẽ được phân phối cho khách hàng (executable files, source

code, tài liệu đi kèm...) có đáp ứng yêu cầu khách hàng hay không.

- Functional configuration audit (FCA): nhằm mục đích khẳng định những gì khách

hàng yêu cầu có được kiểm tra chặt chẽ trên sản phẩm tạo ra trước khi giao cho khách hàng

hay không. Gồm:

• Kiểm tra vết để phản ánh tính 2 chiều giữa yêu cầu khách hàng và việc kiểm tra

sản phẩm.

Quản lý release (Release management)

Trong thực tế, có nhiếu định nghĩa khác nhau về khái niệm “release”. Về cơ bản,

chúng ta có thể hiểu: Quá trình phát triển một phần mềm thường qua nhiều lần tích hợp, kết

quả của mỗi lần tích hợp là một bản “build”, trong rất nhiều bản “build” đó, một số bản đáp

ứng một số yêu cầu đã định hoặc lập kế hoạch trước (theo yêu cầu khách hàng), sẽ được gởi

cho khách hàng để kiểm tra hoặc đánh giá. Các bản build này được gọi là “release”; công

việc tạo ra và phân phối các bản release được gọi là công việc “release”. Theo cách hiểu

này, sản phẩm sau cùng cũng là một bản release, đôi khi được gọi là “final release”.

Trong quá trình release, việc quản lý đòi hỏi phải thực hiện các công việc sau:

• Baseline môi trường phát triển sản phẩm và các file, tài liệu (sẽ release)

• Thực hiện báo cáo CSAR (xem định nghĩa ở trên)

• Thực hiện các audit: PCA và FCA

• Đóng gói file và tài liệu sẽ release

• Xác nhận đã nhận bản release từ khách hàng

Lưu trữ và chép dự phòng (Backup & archive)

Lưu trữ và chép dự phòng là một hoạt động của QLCH và là một trong những hoạt

động quan trọng phải có của sản xuất phần mềm. Nó giúp khắc phục các trường hợp rủi ro

bị mất mát dữ liệu do thao tác sai, virus, hoặc sự cố phần cứng/ phần mềm. Ở khía cạnh

khác, nó hỗ trợ cho hoạt động version control (đã nói ở trên) trong trường hợp ta muốn sử

dụng những version khác nhau.

Lưu trữ và chép dự phòng đòi hỏi toàn bộ sản phẩm và sản phẩm trung gian của dự

án phải được định kỳ chép dự phòng trên những thiết bị hoặc những nơi khác một cách an

toàn.

Và khi dự án kết thúc, các hoạt động sau cần phải thực hiện:

• Lưu trữ toàn bộ dữ liệu của dự án, tuân thủ quy trình lưu trữ đã được thiết lập (định

nghĩa bởi dự án hoặc quy định ở cấp công ty).

• Lưu trữ hoặc huỷ bỏ các tài liệu ở dạng giấy.

• Dọn sạch dữ liệu hoặc thông tin của dự án vừa kết thúc, sau khi đã chép lưu trữ.

c. Vai trò của các thành viên trong dự án

Trong một dự án điển hình, thông thường có 4 (nhóm) chức năng sau (thường gọi tắt

là role) tham gia thực hiện các hoạt động QLCH:

CM (Configuration manager)

• Thiết lập và bảo trì kho lưu trữ (repository) của dự án.

• Phát triển và triển khai các quy trình thủ tục QLCH của dự án.

• Thiết lập các baseline, ghi nhận chi tiết các thay đổi trên các baseline

• Bảo đảm các baseline không bị thay đổi khi chưa được phê chuẩn.

• Tổ chức và điều phối các cuộc họp của CCB

Trưởng dự án (Project manager):

• Giám sát các hoạt động QLCH.

• Bảo đảm các yêu cầu cần thiết cho hoạt động QLCH. Ví dụ: số giờ thành viên dự án

bỏ ra cho QLCH, công cụ hỗ trợ cho QLCH...

CCB (Configuration Control Board)

Bao gồm các thành viên trong dự án, và có chức năng như đã nói ở trên.

Các thành viên của dự án

Các thành viên của dự án, kể cả CM, PM và thành viên CCB, có trách nhiệm:

• Tuân thủ tất cả các quy trình thủ tục của bản kế hoạch QLCH (CMP)

• Tham gia vào nhóm CCB khi có yêu cầu

Trên đây là vài nét hết sức cơ bản về QLCH - một lĩnh vực quan trọng và cơ bản

trong phát triển và sản xuất phần mềm. Thực tế, mỗi hoạt động thành phần của QLCH đều

có những chi tiết riêng phức tạp. Nếu có điều kiện, trong tương lai chúng tôi sẽ bàn sâu

thêm từng hoạt động thành phần, đặc biệt ở khía cạnh kỹ thuật và áp dụng thực tế.

3.3.3. Quản lý rủi ro

Rủi ro là yếu tố luôn tồn tại trong mọi hoạt động sản xuất và kinh doanh, và dự án

phần mềm cũng không ngoại lệ.

Rủi ro là yếu tố luôn tồn tại trong mọi hoạt động sảbn xuất và kinh doanh, và dự án

phần mềm cũng không ngoại lệ. Tuy nhiên, với đặc thù riêng của mình, nhận diện và kiểm

soát rủi ro trong dự án phần mềm là điều không đơn giản. Trong thực tế, nhiều dự án phần

mềm đã bỏ qua hoặc kiểm soát rủi ro sơ sài, chiếu lệ dẫn đến kết quả thất bại, khách hàng

phàn nàn về chất lượng hoặc lỗ vốn do chi phí tăng cao.

a. Rủi ro trong các dự án phần mềm

Thông thường, “rủi ro” dùng để chỉ một hay nhiều sự việc chưa nhưng có khả năng

xảy ra trong tương lai có tác động đến dự án, và khi sự việc đó xảy ra thường sẽ gây ảnh

hưởng xấu, thậm chí là “tai nạn” cho dự án, cản trở dự án đạt được mục tiêu của mình. Rủi

ro thường được nhận biết dựa vào một số dấu hiệu báo trước, đôi khi dựa vào kinh nghiệm

của các dự án tương tự trước đây.

Quản lý rủi ro có vai trò khá quan trọng trong toàn bộ tiến trình quản lý dự án. Trong

cả 2 bộ mô hình và tiêu chuẩn nổi tiếng được ứng dụng nhiều trong dự án phần mềm là

CMMi (Capability Maturity Model Integration) của viện Công nghệ Phần mềm Hoa Kỳ

(SEI) và PMP (Project Management Professional) của viện Quản trị Dự án PMI (Project

Management Institude) đều xem quản lý rủi ro là một trong những hoạt động cơ bản nhất

của quá trình quản trị dự án.

Mặc dù nhận diện và kiểm soát tốt rủi ro có khả năng ảnh hưởng đến dự án đòi hỏi sự

tham gia của nhiều người, tuy nhiên người có vai trò trực tiếp và quan trọng nhất là trưởng

dự án. Do đó, một tiêu chí bắt buộc của một trưởng dự án giỏi là khả năng kiểm soát tốt rủi

ro.

b. Quy trình quản lý rủi ro

Hình 1: Quy trình cơ bản quản lý rủi ro

Nhận diện và kiểm soát tốt rủi ro chỉ bằng kỹ năng và kinh nghiệm cá nhân không chưa đủ, việc

kiểm soát rủi ro phải được thực hiện theo một quy trình chặt chẽ và phù hợp với đặc thù, mục tiêu và ng

sách của dự án.

Tổng quát, quy trình cơ quản lý rủi ro bao gồm các bước chính được trình bày ở Hình

Ở mức chi tiết hơn, quy trình quản lý rủi ro bao gồm các bước cùng với trình tự xử lý

và mối quan hệ giữa chúng như trình bày ở Hình 2.

* Nhận diện rủi ro

Xác định được chính xác các nguồn có khả năng phát sinh rủi ro là điều không dễ

dàng. Thông thường rủi ro xuất hiện từ các nguồn sau:

• Ngân sách/nguồn tài trợ cho dự án

• Thời gian thực hiện dự án

• Thay đổi về phạm vi và yêu cầu dự án

• Khó khăn về kỹ thuật

• Vấn đề liên quan đến nhân lực

• Hợp đồng giữa 2 (hoặc nhiều) bên

• Trong kinh doanh

• Môi trường, luật pháp, chính trị, văn hóa...

Để nhận diện được rủi ro, có nhiều kỹ thuật được áp dụng. Các kỹ thuật này giúp cho

dự án “khoanh vùng” và xác định dấu hiệu xuất hiện rủi ro, vừa giúp tránh bỏ sót các dấu

hiệu, vừa làm tăng kết quả và độ tin cậy của việc nhận diện các rủi ro. Từng kỹ thuật đều có

những hạn chế riêng, do đó việc kết hợp các kỹ thuật để có kết quả tốt nhất là cần thiết. Các

kỹ thuật được sử dụng rộng rãi bao gồm:

- Xem xét tài liệu: Là cách thức xác định rủi ro cơ bản, đơn giản và thông dụng.

Phương thức này thường bao gồm việc xem xét các tài liệu của dự án như các kế hoạch, giả

định, cam kết với khách hàng, cơ chế thông tin giữa 2 bên, môi trường dự án, thông tin của

các dự án khác trong quá khứ..., từ đó nhận diện các yếu tố có khả năng gây ra rủi ro cho dự

án.

- Động não: Đây là kỹ thuật được sử dụng rộng rãi nhất để nhận diện rủi ro và hầu

như bất cứ ai trong đời cũng đã từng sử dụng kỹ thuật này cho nhiều vấn đề khác nhau trong

cuộc sống. Đó là sự đóng góp ý kiến từ nhiều người khác nhau, từ các chuyên gia đến các

thành viên của dự án, hoặc bất cứ ai có liên quan hoặc có kinh nghiệm về các vấn đề xảy ra

trong dự án. Từ những ý kiến này (có thể nhiều ý trùng nhau), các rủi ro sẽ được định vị

nhanh chóng.

- Kỹ thuật Delphi: Tương tự kỹ thuật "Động não", khác biệt chỉ là các thành viên tham

gia không biết nhau, do đó kỹ thuật này thích hợp nếu các thành viên ở xa nhau. Ngày nay kỹ thuật

Delphi thực hiện dễ hơn trước đây do sự trợ giúp của email và hệ thống hỗ trợ làm việc từ xa. Do

thành viên là “vô danh” nên kỹ thuật này hạn chế nhược điểm của kỹ thuật "Động não" là một vài

cá nhân (chẳng hạn sếp) sẽ có ảnh hưởng đến suy nghĩ của các thành viên khác.

Hình 2: Mối quan hệ và trình tự các bước trong quy trình kiểm soát rủi ro

- Nhóm danh nghĩa: Nhóm làm việc từ 7-10 người, mỗi thành viên sẽ ghi ý kiến

riêng của mình (thường là 1 rủi ro quan trọng nhất) trên 1 mẫu giấy. Các ý kiến sau đó được

tập hợp và nhóm sẽ phân tích và đánh giá trên từng ý kiến. Kết quả là rủi ro quan trọng nhất

được sắp xếp trên cùng. Kỹ thuật này không chỉ dùng để nhận biết mà còn để đánh giá rủi

ro; không loại bỏ hoàn toàn những người có ảnh hưởng; được thực hiện nhanh và ít tốn kém

hơn kỹ thuật Delphi

- Hỏi ý kiến chuyên gia: Thường được dùng để hỏi ý kiến cá nhân của những người

có nhiều kinh nghiệm từ các dự án tương tự hoặc các dự án đã hoàn thành trong quá khứ.

Công cụ sử dụng thường là bảng câu hỏi có trả lời sẵn để chọn lựa, hoặc để trống cho người

được hỏi tự ghi ý kiến hoặc trả lời.

- Sử dụng phiếu kiểm tra hoặc bảng câu hỏi: Phiếu kiểm tra hoặc bảng câu hỏi

thường đúc kết kinh nghiệm từ các dự án quá khứ đặc biệt và các dự án tương tự, trong đó

liệt kê những rủi ro thường hay gặp nhất. Phiếu này giúp cho dự án nhanh chóng xác định

rủi ro có thể xảy đến cho dự án.

Kỹ thuật này có thể tham khảo các kinh nghiệm từ bên ngoài, một trong những tham

khảo tốt theo cách này là sử dụng bảng phân loại và liệt kê các rủi ro thường gặp của viện

Kỹ thuật Phần mềm Hoa Kỳ (SEI Taxonomy-Based Risk Identification) có thể tải về miễn

phí tại http://www.sei.cmu.edu/publications/documents/93.reports/93.tr.006.html.

- Sử dụng biểu đồ: Sử dụng nhiều dạng biểu đồ khác nhau để phân tích và xác định

rủi ro, chẳng hạn biểu đồ xương cá (còn gọi là biểu đồ nhân quả) được sử dụng để chỉ sự

liên quan và ảnh hưởng của các yếu tố rủi ro khác nhau, từ đó xác định rủi ro có thể ảnh

hưởng đến dự án. Biểu đồ quy trình cho thấy sự nối tiếp trong chuỗi các sự kiện, từ đó xác

định các yếu tố có thể gây rủi ro cho dự án. Hình 3 là một ví dụ về việc sử dụng biểu đồ

xương cá để định vị các rủi ro.

* Phân tích và phân loại rủi ro

Trong thực tế, những rủi ro có thể xảy ra trong một dự án là khá nhiều, và việc giải

quyết hết tất cả các rủi ro là không cần thiết, cũng như sẽ làm phá sản ngân sách của dự án.

Thông thường người ta áp dụng nguyên tắc 20/80 để xác định và giải quyết những rủi

ro quan trọng, những nguyên nhân gốc có ảnh hưởng lớn nhất đến sự thành công của dự án,

trong chừng mực cân nhắc cẩn thận ngân sách dự án cũng như một số yếu tố đặc biệt khác.

Điều này dẫn đến việc dự án phải phân tích để chọn ra những rủi ro cần giải quyết đó. Có

nhiều kỹ thuật phân tích rủi ro được sử dụng, kỹ thuật thường được sử dụng bao gồm các

phân tích chính sau:

- Phân tích khả năng xuất hiện của rủi ro: Có 4 mức để đo lường khả năng xuất

hiện của rủi ro, mỗi mức độ được gán với một giá trị số (tùy dự án) để có thể ước lượng sự

quan trọng của nó.

• 6 - Thường xuyên: Khả năng xuất hiện rủi ro rất cao, xuất hiện trong hầu hết dự án

• 4 - Hay xảy ra: Khả năng xuất hiện rủi ro cao, xuất hiện trong nhiều dự án

• 2 - Đôi khi: Khả năng xuất hiện rủi ro trung bình, chỉ xuất hiện ở một số ít dự án

• 1 - Hiếm khi: Khả năng xuất hiện thấp, chỉ xuất hiện trong những điều kiện nhất định.

Hình 3: Ví dụ đơn giản dùng sơ đồ xương cá định vị rủi ro

- Phân tích mức tác động của rủi ro: Có 4 mức để đo lường mức tác động của rủi

ro, mỗi mức độ được gán với một giá trị số (tùy dự án) để có thể ước lượng sự tác động của

nó.

• 8 - Trầm trọng: Có khả năng rất cao làm dự án thất bại

• 6 - Quan trọng: Gây khó khăn lớn và làm dự án không đạt được các mục tiêu

• 2 - Vừa phải: Gây khó khăn cho dự án, ảnh hưởng việc đạt các mục tiêu của dự án

• 1 - Không đáng kể: Gây khó khăn không đáng kể.

- Phân tích thời điểm xuất hiện rủi ro: Có 4 mức để ước lượng thời điểm rủi ro

xuất hiện, mỗi mức được gán với một giá trị số (tùy dự án) để có thể ước lượng sự tác động

của nó.

• 6 - Ngay lập tức: Rủi ro xuất hiện gần như tức khắc

• 4 - Rất gần: Rủi ro sẽ xuất hiện trong thời điểm rất gần thời điểm phân tích

• 2 - Sắp xảy ra: Rủi ro sẽ xuất hiện trong tương lai gần

• 1 - Rất lâu: Rủi ro sẽ xuất hiện trong tương lai xa hoặc chưa định được.

• Ghi chú: Các giá trị số cho trên chỉ mang tính tham khảo và minh họa, giá trị của

chúng được định tùy tổ chức, tùy dự án.

- Ước lượng và phân hạng các rủi ro: Rủi ro sau đó được tính giá trị để ước lượng

bằng công thức: Risk Exposure = Risk Impact * Risk Probability * Time Frame

Tiếp theo rủi ro được phân hạng từ cao đến thấp dựa theo các giá trị Risk Exposure

tính toán được. Tùy theo tổ chức và đặc thù từng dự án, trưởng dự án (hoặc người được

phân công) sẽ xác định những rủi ro nào cần đưa vào kiểm soát, với các mức ưu tiên khác

nhau.

* Kiểm soát rủi ro

Kiểm soát rủi ro bắt đầu với việc chọn lựa chiến lược và phương pháp đối phó rủi ro.

Có nhiều chiến lược và phương pháp đối phó khác nhau, tùy theo tình huống dự án, môi

trường và đặc thù của từng rủi ro. Trong thực tế, các chiến lược phổ biến nhất bao gồm

(Hình 4):

- Tránh né: Dùng “đường đi khác” để né tránh rủi ro, đường đi mới có thể không có

rủi ro, có rủi ro nhẹ hơn, hoặc chi phí đối phó rủi ro thấp hơn. Chẳng hạn:

• Thay đổi phương pháp, công cụ thực hiện, thay đổi con người

• Thương lượng với khách hàng (hoặc nội bộ) để thay đổi mục tiêu.

- Chuyển giao: Giảm thiểu rủi ro bằng cách chia sẻ tác hại khi chúng xảy ra. Chẳng

hạn:

• Đề nghị với khách hàng chấp nhận và chia sẻ rủi ro (tăng thời gian, chi phí...)

• Báo cáo ban lãnh đạo để chấp nhận tác động và chi phí đối phó rủi ro

• Mua bảo hiểm để chia sẻ chi phí khi rủi ro xảy ra.

Hình 4: Một số chiến lược và minh họa các phương pháp đối phó rủi ro thường gặp

- Giảm nhẹ: Thực thi các biện pháp để giảm thiểu khả năng xảy ra rủi ro hoặc giảm

thiểu tác động và chi phí khắc phục rủi ro nếu nó xảy ra. Chẳng hạn:

• Cảnh báo và triệt tiêu các yếu tố làm cho rủi ro xuất hiện

• Điều chỉnh các yếu tố có liên quan theo dây chuyền để rủi ro xảy ra sẽ ít có tác

động

- Chấp nhận: Đành chấp nhận “sống chung” với rủi ro trong trường hợp chi phí loại

bỏ, phòng tránh, làm nhẹ rủi ro quá lớn (lớn hơn chi phí khắc phục tác hại), hoặc tác hại của

rủi ro nếu xảy ra là nhỏ hay cực kỳ thấp. Kế hoạch đối phó có thể là:

• Thu thập hoặc mua thông tin để có kế hoạch kiểm soát tốt hơn

• Lập kế hoạch khắc phục tác hại khi rủi ro xảy ra.

Hình 5: Minh họa Cây quyết định cho trường hợp đơn giản

- Sử dụng Cây quyết định

Trong một số trường hợp phức tạp, thường rất khó xác định rủi ro nào nên đặt ưu tiên

cao để kiểm soát, hoặc nên chọn chiến lược kiểm soát nào phù hợp nhất nên người ta

thường sử dụng kỹ thuật hỗ trợ ra quyết định thông dụng trong quản lý là Cây quyết định để

tính toán giá trị đạt được hoặc thiệt hại xảy ra khi thực hiện một hành động nào đó.

Cây quyết định là một biểu đồ dạng cây có nhiều nút, mỗi nút có nhiều nhánh rẽ, mỗi

nhánh sẽ trả lời câu hỏi “làm” hay “không làm”, hoặc là một khả năng để một tình huống

xuất hiện với một xác suất nào đó. Các giá trị cuối cùng của các nhánh sẽ giúp xác định xem

nên chọn phương án nào cho giá trị tốt nhất. Hình 5 là một Cây quyết định đơn giản để tính

toán giá trị đạt được theo các phương án khác nhau, giúp chọn lựa phương án tốt nhất, theo

đó phương án Y cuối cùng đã được chọn do giá trị trả về là lớn nhất.

* Giám sát và điều chỉnh

Bao gồm hoạt động giám sát để bảo đảm các chiến lược đối phó rủi ro được lên kế

hoạch và thực thi chặt chẽ. Việc giám sát cũng nhằm mục đích điều chỉnh các chiến lược

hoặc kế hoạch đối phó nếu chúng tỏ ra không hiệu quả, không khả thi, ngốn quá nhiều ngân

sách, hoặc để đáp ứng với rủi ro mới xuất hiện, hoặc sự biến tướng của rủi ro đã được nhận

diện trước đó.

Kết quả giám sát có thể được báo cáo định kỳ đến tất cả những người có liên quan,

đến quản lý cấp cao, hoặc đến khách hàng nếu cần thiết.

Trong thực tế, do các yếu tố liên quan đến dự án thay đổi liên tục, chu trình quản lý

rủi ro không đi theo đường thẳng mà được lặp lại và điều chỉnh liên tục giữa các chặng. Các

rủi ro liên tục được điều chỉnh hoặc nhận diện mới, do đó các chiến lược và kế hoạch đối

phó cũng luôn được thay đổi để bảo đảm chúng khả thi và có hiệu quả.

* Kết luận

Rủi ro là một yếu tố tồn tại trong mọi dự án phần mềm. Một người quản trị dự án giỏi

phải là người không ngạc nhiên và có khả năng xử lý bất kỳ sự kiện nào xảy ra có thể gây

bất lợi cho dự án, điều đó đồng nghĩa với việc các rủi ro ảnh hưởng đến dự án phải được

“thấy trước”, cùng với các kế hoạch để giảm thiểu khả năng xuất hiện cũng như tác hại khi

chúng xuất hiện. Quy trình kiểm soát chặt chẽ, kinh nghiệm chuyên gia kết hợp với kỹ thuật

nhận diện và kiểm soát rủi ro là những yếu tố quan trọng nhất để kiểm soát tốt rủi ro xảy ra

trong dự án.

3.3.4. Quản lý thay đổi

Quản lý thay đổi là việc lập kế hoạch giống như giới hạn cho những tiến trình lặp lại.

Theo dõi thay đổi trong những hiện tượng giả kỹ thuật là cốt yếu để hiểu được xu hướng

phát triển công nghệ thật sự và xu hướng chất lượng tiến tới đưa ra một sản phẩm cuối cùng

được thừa nhận hay phát hành tạm thời. Trong những quy trình quản lý phần mềm thông

thường, những kỹ thuật quản lý cấu hình giới hạn cho những hiện tượng giả kỹ thuật là hoạt

động sau này chiếm ưu thế vòng đời. Trong một quy trình quản lý hiện đại, trong đó những

yêu cầu và các bộ tạo tác thực hiệnsớm đạt được những yêu cầu khắt khe trong vòng đời và

phát triển qua nhiều thế hệ - quản lý thay đổi đã trở nên cơ bản đối với tất cả các giai đoạn

và hầu như tất cả các hoạt động.

Những thứ tự của sự thay đổi phần mềm(software change order)

Những đơn vị nguyên tử của công việc phần mềm được phép phát sinh, thay đổi hoặc

bỏ đi các thành phần trong một giới hạn cấu hình được gọi là thứ tự thay đổi phần mềm

(SCO). Những thứ tự thay đổi phần mềm là một cơ chế cho việc phân hoạch, cấp phát, lập

lịch công việc phần mềm ngược lại một giới hạn phần mềm đã được thiết lập và để đánh

giá sự tiến bộ và đánh giá chất lượng. Bằng cách vào dữ liệu tự động và khả năng duy trì

những bản ghi thay đổi một cách trực tuyến, việc bộ máy quản lý thay đổi kết hợp với các

độ đo báo cáo những hoạt động cũng có thể được tự động hoá.

Mức độ mà tại đó một SCO được viết vẫn luôn luôn là một vấn đề. Một sự thay đổi

riêng biệt là gì? Có phải là sự thay đổi một đơn vị chương trình hay thay đổi một thành

phần, một file, một hệ thống con? Có phải là một tính chất mới, một sự khắc phục khuyết

điểm, hay một sự nâng cấp thực hiện? Trong hầu hết các dự án, đơn vị nguyên tử của SCO

có xu hướng dễ dàng được chấp nhận. Một cách tổng quát, một SCO nên được viết ngược

lại một thành phần đơn do đó nó dễ dàng được cấp phát cho một cá thể đơn. Nếu một

quyết định yêu cầu hai người trong hai đội khác nhau thì hai SCO riêng biệt nên được viết.

Những trường cơ bản của SCO là tiêu đề, phần mô tả, các ma trận, những quyết định,

sự đánh giá và sự sắp xếp.

• Tiêu đề (title): Tiêu đề được đề xuất bởi người sáng tạo và được hoàn thành nhờ

vào sự chấp nhận của bảng kiểm soát cấu hình (CCB)Trường này nên bao gồm một sự tham

khảo một bản báo cáo vấn đề phần mềm bên ngoài nếu sự thay đổi được đưa ra bởi người

ngoài (ví dụ như người sử dụng)

• Phần mô tả (description): Phần mô tả các vấn đề bao gồm tên của người sáng tạo,

ngày phát minh, bộ chỉ định SCO được gán CCB, và bộ các chỉ định phiên bản liên quan

của phần mềm hỗ trợ. Phần miêu tả những vấn đề nguyên bản nên cung cấp chi tiết nhất có

thể những trích dẫn mã gắn vào, in màn hình hiển thị, thông báo lỗi và bất kỳ dữ liệu nào

khác có thể giúp tách vấn đề hoặc miêu tả việc thay đổi cần thiết.

• Độ đo (metric): Những độ đo đã tập hợp cho mỗi SCO là quan trọng cho việc lập

kế hoạch, lập lịch trình, và cho việc đánh giá cải tiến chất lượng. Những hạng mục thay đổi

là loại 0(lỗi giới hạn), loại 1(lỗi), loại 2(nâng cao), loại 3(đặc tính mới) và loại 4(những cái

khác), như sẽ được miêu tả sau trong phần này. Nhờ vào sự chấp nhận của SCO, những

đánh giá ban đầu được tạo thành bởi một số đứt đoạn(breakage) và yêu cầu nỗ lực để giả

quyết vấn đề. Mục đứt đoạn xác định số lượng thay đổi và mục làm lại(rework) xác định độ

phức tạp của sự thay đổi. Mục phân tích xác định số giờ cần thiết để hiểu những thay đổi

yêu cầu (phát minh lại, cách ly, và phát hiện lỗi vấn đề nếu thay đổi là loại 0 hoặc 1). Mục

thi hành xác định số giờ cần thiết để thiết kế và thi hành quyết định. Mục thử xác định số

giờ sử đụng để thử nghiệm quyết định, và mục tài liệu xác định tất cả sự nỗ lực bỏ ra để cập

nhật những hiện tượng giả khác ví dụ như sách hướng dẫn người sử dụng hoặc phần mô tả

phiên bản.Sự đứt đoạn xác định phạm vi của thay đổi và có thể được định nghĩa trong

những đơn vị của SLOC, những điểm hàm, các file, các thành phần hay các lớp. Trong

trường hợp của SLOC, một chương trình so sánh file nguồn xác định những khác biệt có thể

cung cấp một sự đánh giá của sự đứt đoạn. Nói chung, sự chính xác của số đứt đoạn là

tương đối không quan trọng. Những thay đổi giữa 0 và 100 dòng có thể lấy chính xác bằng

10, những thay đổi giữa 100 và 1000 lấy là 100 và cứ như vậy.

• Quyết định(resolution): Trường này bao gồm tên của những người có trách nhiệm

trong việc thi hiện những thay đổi, những thành phần thay đổi, những ma trận thực sự và

một phần mô tả của sự thay đổi. Mặc dù sự đúng đắn mức của các thành phần với một dự án

theo dõi những liên quan thay đổi có thể được mô tả bên ngoài, nói chung, mức thấp nhất

củatham chiếu thành phần nên được giữ tương đối tại một mức của việc cung cấp cho một

cá thể. Một ví dụ, một “thành” phần mà được cung cấp cho một đội không là một tham

chiếu đủ chi tiết.

• Sự định giá (assessment): Trường này miêu tả kỹ thuật đánh giá như sự kiểm tra,

phân tích, chứng minh hoặc thử. Nơi có thể được ứng dụng cũng nên tham chiếu tất cả các

trường hợp thử nghiệm tồn tại và những trường hợp thử nghiệm mới được thực hiện, và

cũng nên xác định tất cả các cấu hình thử nghiệm khác nhau, ví dụ như các nền, cấu trúc

liên kết và các trình biên dịch.

• Sự xếp đặt (deposition): SCO được gán với một trong những trạng thái sau đây bởi

CCB

- Được đề nghị : viết ra, xem xét lại CCB chưa giả quyết

- Được chấp nhận: CCB được chấp nhận cho cách giải quyết

- Bị bác bỏ: đóng với những lý do căn bản ví dụ như không một vấn đề, bản sao, sự

thay đổi quá hạn, giả quyết bỏi SCO khác

- Được lưu trữ: được chấp thuận nhưng bị hoãn lại cho đến khi có một sự đưa ra sau

- Đang tiến hành: đã được phân công và đang được giải quyết bởi một tổ chức phát

triển.

- Đang đánh giá: đã được giải quyết bởi một tổ chức phát triển; đang được đánh giá

bởi một tổ chức thử nghiệm

- Đóng: được giải quyết hoàn chỉnh với sự hợp tác của tất cả bộ phận CCB

Một bộ phận chỉ định quyền ưu tiên và nhả ra cũng có thể được phân công bởi CCB

để hướng dẫn .. và cách tổ chức của các hoạt động phát triển hiện tại.

Ranh giới cấu hình(configuration baseline)

Một ranh giới cấu hình là một bộ tên của các thaành phần phần mềm và những tài

liệu hỗ trợ là chủ thể để quản lý sự thay đổi và được nâng cấp, duy trì, thử nghiệm, như là

một đơn vị. Với những hệ thống quản lý cấu hình phức tạp, có nhiều tiêu chuẩn phạm vi dặc

biệt và dự án đặc biệt.

Nói chung có hai lớp của ranh giới: phiên bản sản phẩm ngoài và phiên bản kiểm tra

trong. Một ranh giới cấu hình là một tập tên của các thành phần được coi như là một đơn vị.

Nó đuợc quản lý một cách chính thức bởi vì nó sự trao đổi được đóng gói giữa các nhóm.

Một ví dụ, tổ chức phát triển có thể đưa ra một ranh giới cấu hình cho tổ chức kiểm tra hoặc

thậm chí là cho bản thân tổ chức đó. Một dự án có thể đưa ra một ranh giới cấu hình cho

người sử dụng để kiểm tra.

Nói chung, ba mức của ranh giới đưa ra là yêu cầu cho mọi hệ thống: lớn, nhỏ và tạm

thời. Mỗi mức tương ứng với một từ định danh ví dụ như N, M, X, trong đó N là lớn, M là

nhỏ và X là từ định danh cho mức tạm thời. Một phiên bản chính biểu diễn một thế hệ mới

của sản phẩm hay dự án, trong khi một phiên bảm phụ biểu diễn cùng một sản phẩm cơ sở

nhưng với những đặc điểm, hiệu suất, chất lượng được đề cao. Phiên bản chính và phụ được

dùng như các phiên bản sản phẩm bên ngoài mà liên tục và được hỗ trợ trong một thời kỳ.

Một phiên bản trong lúc chờ đọi tương ứng với một cấu hình tiến triển được dùng tạm thời.

Vòng đời của nó càng ngắn càng tốt. Hình 12-4 chỉ ra một ví dụ của một số tên phiên bản

cho hai trường hợp khác nhau.

Một khi phần mềm được thiết lập trong ranh giới kiểm soát, tất cả sự thay đổi được

theo dõi. Sự khác biệt chỉ là nguyên nhân của một sự thay đổi. Những loại thay đổi giống

như sau:

• Loại 0: thiếu khả năng tới hạn, đó là những thiếu sót gần như luôn luôn được sửa

chữa trước bất ky một phiên bản ngoài .Nói chung, loại của các thay đổi được biểu diễn

showstopper có một sự ảnh hưởng lên khả năng sử dụng của phần mềm trong những trường

hợp sử dụng tới hạn của nó.

• Loại 1: Một con bọ hay một thiếu sót không làm giảm khả năng sử dụng của hệ

thống hoặc có thể bị vòng. Những lỗi như vậy có thể gây ra phiền toái trong những trường

hợp sử dụng tới hạn hoặc những lỗi nghiêm trọng trong những trường hợp sử dụng phụ là

những trường hợp có khả năng xuất hiện thấp.

• Loại 2: Một sự thay đổi mà là một cách làm nổi bật hơn là một hỏng hóc. Mục

đích của nó là cải thiện hiệu suất, khả năng thử nghiệm, khả năng sử dụng hoặc những mặt

khác của chất lượng mà là một điển hình của kỹ thuật tốt.

• Loại 3: Một sự thay đổi cấn có để cập nhật những yêu cầu. Đây có thể là những

khả năng và tính chất mới nằm ngoài phạm vi của phiên bản và giao dịch hiện tại

• Loại 4: Một thay đổi chưa được dàn xếp giữa các hạng mục. Những ví dụ chỉ gồm

có tài liệu hoặc những phiên bản nâng cấp cho các thành phần thương mại.

Bảng kiểm soát cấu hình(Confirguration control board)

Một CCB là một đội cán bộ mà chức năng như là có quyền quyết định chấp nhận

những ranh giới cấu hình. Một CCB thường bao gồm giám đốc phần mềm, giám đóc thiết

kế phần mềm, giám đốc phát triển phần mềm, giám đốc định giá phần mềm và những

người khác (khách hàng, giám đốc dự án phần mềm, kỹ sư hệ thống, người sử dụng) đó là

những người được kết hợp để sự duy trì một hệ thống phân phối kiểm phần mềm kiểm

soát.Trong khi các CCB hoạt động qua trao đổi bảng, sự phân phối trực tuyến, hiện tại, và

sự chấp thuận của hoạt động CCB có thể tạo ra khả năng đánh giá dưới rất nhiều thực trạng

dự án.

Khái niệm hoạt động của một tiến trình phát triển lặp lại phải bao gồm quản lý sự

thay đổi chặt chẽ và mang tính toàn diện của những ranh giới phần mềm mở ra. Tiến trình

cơ bản cho việc kiểm soát sự phát triển phần mềm và duy trì những hoạt động được mô tả

thông qua một dãy các trạng thái được duyệt bởi một SCO. Những từ (trong ngoặc) tạo

thành các trạng thái của một SCO chuyển tiếp qua một quá trình.

• [Được đề nghị(propose)]. Một sự thay đổi được đề nghị được phác thảo và CCB

chấp nhận. Sự thay đổi được đề nghị phải bao gồm một phần miêu tả kỹ thuật của vấn đề và

đánh giá hiệu quả của quyết định.

• [Được chấp thuận, được hoàn thành hay bị loại bỏ]. CCB phân một bộ chỉ định

duy nhất và chấp thuận, hoàn thành hay loại bỏ mỗi sự thay đổi được đề nghị. Sự chấp thuận

bao gồm sự thay đổi của quyết định trong phiên bản tương lai; và sự loại bỏ với những sự

thay đổi được đề nghị khác hoặc nằm ngoài phạm vi. CCB kiểm tra tất cả các trường SCO

cho phù hợp và chính xác trước khi chấp nhận SCO, sau đó phân SCO cho một người có

trách nhiệm trong sự tổ chức phát triển cho quyết định.

• [Trong tiến trình]. Người có trách nhiệm phân tích, thực hiện và kiểm tra một giải

pháp phù hợp với SCO. Nhiệm vụ này bao gồm cập nhật tài liệu, đưa ra chú thích, và ma

trận SCO thật sự, và chấp nhận những SCO mới, nếu cần thiết. Thông quan hoàn thành một

giải pháp hoàn chỉnh, người có trách nhiệm hoàn thành bộ phận quyết định của SCO và đưa

cho đội thử nghiệm độc lập để định giá.

• [Trong định giá]. Đội thử nghiệm độc lập đánh giá nếu SCO được giải quyết hoàn

toàn. Khi đội thử nghiệm độc lập nghĩ rằng sự thay đổi được giải quyết ổn thoả, SCO được

đưa tới cho CCB để sắp xếp và đóng gói cuối cùng.

• [Đóng] Khi tổ chức phát triển, tổ chức thử nghiệm độc lập và CCB tán thành rằng

SCO đã được giải quyết, nó sẽ chuyển sang tình trạng đóng.

3.3.5. Quản lý chất lượng

a. Quản lý chất lượng là gì?

Lâu nay, nói đến chất lượng phần mềm (PM), không ít người nghĩ ngay đến vấn đề là

xác định xem PM đó có phát sinh lỗi hay không, có "chạy" đúng như yêu cầu hay không và

cuối cùng thường quy về vai trò của hoạt động kiểm tra phần mềm (testing) như là hoạt

động chịu trách nhiệm chính.

Với quan điểm của khách hàng, điều này có thể đúng, họ không cần quan tâm nội

tình của hoạt động phát triển PM, điều họ cần quan tâm là liệu sản phẩm cuối cùng giao cho

họ có đúng hạn hay không và làm việc đúng như họ muốn hay không.

Tuy nhiên theo quan điểm của người phát triển PM, thực

tế cho thấy hoạt động kiểm tra PM là quan trọng, nhưng không

đủ để đảm bảo sản phẩm sẽ được hoàn thành đúng hạn và đúng

yêu cầu. Kiểm tra sau cùng để phát hiện lỗi là điều tất nhiên phải

làm, nhưng trong rất nhiều trường hợp, điều đó thường quá trễ và

sẽ phải mất rất nhiều thời gian để sửa chữa.

Thực tế cho thấy, để đảm bảo được hai tiêu chí "đơn giản" trên

của khách hàng, đòi hỏi tổ chức không chỉ vận hành tốt khâu

kiểm tra PM, mà phải tổ chức và duy trì sự hoạt động nhịp nhàng

của cả một hệ thống các công việc liên quan đến một dự án PM, từ đây xuất hiện một khái

niệm có tên là "hệ thống quản lý chất lượng phần mềm" (HTQLCLPM), bao gồm các quy

trình được thực thi xuyên suốt chu kỳ phát triển của dự án PM.

Hiện có nhiều mô hình cung cấp các tiêu chuẩn cũng như hướng dẫn để triển khai

HTQLCLPM. Hai trong số những mô hình được áp dụng rộng rãi hiện nay là ISO 9001-

2000 và CMM/CMMi. Trong khi ISO 9001-2000 là tiêu chuẩn quản lý chất lượng dành cho

tất cả các ngành nghề với những điều khoản ngắn gọn và mang tính tổng quát, thì

CMM/CMMi là một bộ tập hợp khá đồ sộ các kinh nghiệm thực hành (gần 450 trang với

CMM, và gần 700 trang với CMMi) có thể làm người đọc chưa có kinh nghiệm khó biết

được các hoạt động và yếu tố đặc trưng cơ bản của HTQLCLPM là gì.

Qua một số tài liệu tham khảo, cũng như bằng kinh nghiệm bản thân khi nghiên cứu

và ứng dụng ISO 9001-2000 và CMM/CMMi, chúng tôi sẽ trình bày các khái niệm, hoạt

động cũng như yếu tố cơ bản cấu thành HTQLCLPM.

b. HTQLCLPM

Hình 1: Các mối

quan hệ.

Một HTQLCLPM thường có 2 mục tiêu (hình 1):

• Mục tiêu thứ nhất: xây dựng chất lượng cho PM ngay từ giai đoạn bắt đầu. Điều

này đồng nghĩa với việc bảo đảm các yêu cầu cho PM từ mọi nguồn khác nhau phải được

định nghĩa, diễn đạt và hiểu một cách đúng đắn, giữa người đưa ra yêu cầu và người thực

hiện yêu cầu.

• Mục tiêu thứ hai: bảo đảm chất lượng của PM xuyên suốt quá trình phát triển.

Một HTQLCLPM hoàn chỉnh bao gồm rất nhiều hoạt động và bộ phận cấu thành,

chúng khác nhau tùy theo từng tổ chức khi triển khai. Tuy nhiên, theo kinh nghiệm, chúng

tôi chỉ giới thiệu 10 hoạt động và yếu tố cơ bản nhất thường gặp:

1. Các tiêu chuẩn (Standards)

2. Lập kế hoạch (Planning)

3. Xem xét, xem lại (Reviewing)

4. Kiểm tra (Testing)

5. Phân tích lỗi (Defect analysis)

6. Quản lý cấu hình (Configuration Management)

7. Bảo mật (Security)

8. Đào tạo, huấn luyện (Education/Training)

9. Quản lý người cung cấp, thầu phụ (Vendor Management)

10. Quản lý rủi ro (Risk Management)

(Để đơn giản, từ đây, "10 hoạt động và yếu tố" được gọi tắt là "10 yếu tố")

Có mối liên hệ giữa 10 yếu tố cơ bản trên và các giai đoạn hay pha phát triển PM.

Hình 2 cho thấy sơ đồ liên hệ trong mô hình phát trình waterfall (xem bài "Tổng quan các

mô hình phát triển phần mềm", ID: A0508_106 và A0510_122). Ký hiệu "x" giao nhau giữa

một yếu tố và một pha biểu thị yếu tố được thực hiện tại pha đó. Phần sau đây sẽ làm rõ ý

nghĩa của 10 yếu tố cơ bản.

* Các tiêu chuẩn

Sản xuất PM ngày nay không còn đơn thuần mang tính sáng tạo ngẫu hứng như trước

đây, mà đang trở thành một lĩnh vực được kiểm soát chặt chẽ, theo những tiêu chuẩn nhất

định. Các tiêu chuẩn có thể là các kinh nghiệm hoặc các phương pháp hiệu quả nhất, được

đề xuất từ các hiệp hội nghề nghiệp như IEEE (The Institute of Electrical and Electronics

Engineers, Inc – Học viện các kỹ sư điện và điện tử), từ các tổ chức quốc tế như ISO

(International Organization for Standardization), hoặc các quy tắc chuẩn hóa để giao tiếp

giữa sản phẩm với nhau... hoặc đơn giản do chính tổ chức phát triển PM đề ra để áp dụng

cho chính họ.

Các tiêu chuẩn có thể bao gồm tất cả các khía cạnh của một chu kỳ phát triển PM,

trải dài suốt mọi pha phát triển. Bất kể tiêu chuẩn xuất phát từ đâu, từ nội bộ công ty, hoặc

từ ngoài, nó đều phải có một số đặc điểm sau:

• Tính cần thiết

• Tính khả thi

• Tính đo lường được

Các tiêu chuẩn nên được chọn và thể hiện sao cho khi sử dụng, các khía cạnh kỹ

thuật cần thiết sẽ được nhấn mạnh, tránh trường hợp hiểu sai hoặc sa vào những tiểu tiết phụ

trợ. Một ví dụ thường thấy là tiêu chuẩn định dạng cho tài liệu, mục đích của tiêu chuẩn là

để bảo đảm khía cạnh chất lượng về kỹ thuật của tài liệu. Tuy nhiên, trong rất nhiều trường

hợp tiêu chuẩn đã bị hiểu sai và sa đà vào việc kiểm tra các chi tiết về mặt hình thức. Lưu ý

là để bảo đảm các tiêu chuẩn được nghiêm túc thực hiện, chúng phải mang tính bắt buộc và

được quy định ở chính sách cấp công ty.

Một dạng phổ biến bắt buộc phải có của tiêu chuẩn là hệ thống các "quy trình", kèm

theo các bộ phận phụ thuộc như "thủ tục" "hướng dẫn" "mẫu biểu" "tiêu chuẩn" v.v. Tùy

theo lĩnh vực hỗ trợ mà chúng có các tên tương ứng, chẳng hạn: quy trình sản xuất PM, quy

trình kiểm soát chất lượng, quy trình kiểm tra...

* Lập kế hoạch

Lập kế hoạch là yêu cầu kinh điển cũng như thao tác cơ bản của hầu hết các

HTQLCLPM. Kết quả của hoạt động này thường là một (hoặc nhiều) tài liệu gọi là bản kế

hoạch.

Theo quan điểm quản lý hiện đại, các công việc gắn liền với những mục tiêu, ngắn

hạn hoặc dài hạn, đều có thể xem như là một dự án hoặc chuỗi các dự án. Kế hoạch cho dự

án thường bao gồm những điểm chính sau:

• Ước lượng phạm vi và kích thước dự án, khối lượng công việc phải làm

• Xác định nhân lực, vật lực và chi phí

• Chỉ định phương pháp, cách tiếp cận để thực thi dự án

• Lập kế hoạch làm việc chi tiết

• Kế hoạch phối hợp và hỗ trợ hoàn thành dự án

Đây là kế hoạch liên quan đến sự tham gia của những người có ảnh hưởng quan trọng

đến sự thành công hay thất bại của dự án (thuật ngữ chuyên môn gọi là stakeholders).

Những người nầy thường bao gồm: trưởng dự án, quản lý cấp cao, khách hàng, ban giám

đốc, thầu phụ, nhà cung cấp. Kế hoạch nầy phải bảo đảm cơ chế để các stakeholders có thể

tham gia vào dự án ở các mức độ và thời điểm mang lại hiệu quả cao nhất.

• Kế hoạch quản lý cấu hình và quản lý các rủi ro (xem chi tiết phần sau)

• Các kế hoạch khác

Tùy theo nhu cầu cho từng dự án, có thể có nhiều kế hoạch khác, cả về quản lý hoặc

kỹ thuật, một số kế hoạch thường gặp chẳng hạn: Kế hoạch kiểm tra, kế hoạch tích hợp sản

phẩm, kế hoạch huấn luyện...

• Tài liệu hóa và cập nhật (khi cần) các bản kế hoạch cho dự án

Lưu ý là các tài liệu kế hoạch của dự án không phải bất di bất dịch, nó phải được cập

nhật thậm chí thay đổi xuyên suốt dự án khi yêu cầu của dự án thay đổi.

* Xem xét, xem lại

Mục đích là để cung cấp thông tin trực quan về tình trạng của các hoạt động xảy ra

trong suốt quá trình sản xuất và cài đặt PM.

Xem xét trên sản phẩm – thường được gọi là xem xét kỹ thuật – bao gồm hai loại:

chính thức hoặc không chính thức. Xem xét không chính thức thường được thực hiện trong

quá trình phát triển sản phẩm, còn xem xét chính thức thường được thực hiện tại thời điểm

kết thúc các chặng phát triển.

Điểm khác nhau chính về mặt kỹ thuật giữa xem xét chính thức và không chính thức

là ở mức độ nghiêm ngặt của quy trình và các bước thực hiện. Chẳng hạn, xem xét chính

thức buộc phải lên kế hoạch, ghi nhận tất cả các lỗi phát hiện và giám sát đến khi tất cả lỗi

đã được sửa chữa, xem xét không chính thức thì không bắt buộc.

Trong thực tế, có khá nhiều định nghĩa và nhiều loại xem xét khác nhau. Về tổng

quan, IEEE định nghĩa có ba loại:

• Review: Cuộc họp chính thức nhằm trình bày một vấn đề, một tài liệu, một sản

phẩm... cho những người quan tâm, người sử dụng, khách hàng... nhằm thu thập ý kiến phản

hồi hoặc đạt được sự thỏa thuận phê chuẩn trên vấn đề, tài liệu hoặc sản phẩm được trình

bày.

• Walkthrough: Kỹ thuật đánh giá không chính thức, qua đó tác giả của một tài liệu,

sản phẩm... giải thích tài liệu, sản phẩm đó cho một nhóm đồng nghiệp. Các đồng nghiệp

này sẽ đặt câu hỏi hoặc cho ý kiến bổ sung về một số lĩnh vực để bảo đảm chất lượng kỹ

thuật của tài liệu hoặc sản phẩm.

• Inspection: Kỹ thuật đánh giá chính thức, qua đó tài liệu, sản phẩm... được những

người không phải là tác giả hoặc trực tiếp liên quan kiểm tra một cách chi tiết để phát hiện

lỗi, các vi phạm tiêu chuẩn, hoặc các vấn đề khác (nếu có). Về cơ bản, nó được tổ chức và

thực hiện chặt chẽ hơn walkthrough. Vai trò của những người tham gia được phân định rõ

ràng. Tài liệu chuẩn bị cho việc xem xét được chuẩn bị trước chu đáo.

Một điểm cần hết sức lưu ý để bảo đảm việc xem xét mang lại hiệu quả là: mục tiêu

chính của việc xem xét nhằm để tìm ra lỗi. Một trong những lý do chính khiến cho rất nhiều

cuộc xem xét không mang lại hiệu quả như mong muốn là các cuộc xem xét đó bị "lún" vào

việc thảo luận các giải pháp để sửa chữa lỗi. Sửa lỗi thường yêu cầu phải có sự phân tích kỹ

lưỡng cũng như phải chấp nhận các phản biện trên các phương pháp sửa lỗi, công việc nầy

hoàn toàn không phù hợp cho một buổi xem xét tìm lỗi. Một khi tìm thấy lỗi, nó nên được

giao cho một/nhóm người phân tích và giải quyết, việc xem xét chỉ nên chú tâm vào việc chỉ

ra các sai sót.

* Kiểm tra lỗi

Kiểm tra lỗi (testing) là một hoạt động sống còn trong sản xuất PM. Kiểm tra lỗi

nhằm mục đích chứng minh rằng các yêu cầu đối với PM là được thỏa mãn. Các hoạt động

kiểm tra bao gồm các bước: lập kế hoạch, thiết kế test, thi hành test, và báo cáo kết quả

kiểm tra.

* Phân tích lỗi

Trong thực tế, lỗi là phần "luôn hiện diện" trong mọi PM từ giai đoạn phát triển sơ

khởi đến khi nó không còn được sử dụng.

Các tổ chức PM thường dùng thuật ngữ "chất lượng" để chỉ zero, hay một lượng nhỏ

các lỗi trên sản phẩm PM, một số khác lại gắn liền khái niệm "chất lượng" với sự hài lòng

của khách hàng. Trên quan điểm khách hàng, bất kể lúc nào, hễ PM "chạy" không tốt,

không đáp ứng sự mong đợi đều được xem là có lỗi, bất kể do code sai, hoặc do hiểu nhầm

yêu cầu, thậm chí là một chức năng "nên có” nhưng hiện thời chưa sẵn sàng.

Phân tích lỗi được thực hiện trên tất cả lỗi được tìm thấy, nhằm mục đích tìm hiểu

nguyên nhân và xu hướng gây ra lỗi, định hướng cho việc sửa chữa các lỗi hiện hành cũng

như phòng ngừa, triệt tiêu khả năng xảy ra lỗi trong tương lai. Phân tích lỗi là con đường

chính yếu phục vụ cho việc giảm sự xuất hiện lỗi.

Phân tích lỗi không chỉ nhằm mục đích cải thiện tình trạng lỗi của phần mềm đang

xây dựng, xa hơn nó cho ta thấy được những điểm yếu cần cải tiến của quy trình phát triển

PM. Thông tin về lỗi của các dự án trong quá khứ sẽ cho ta thấy được nên cải tiến, thay đổi

quy trình phát triển PM như thế nào để các dự án trong tương lai tránh đi vào "vết xe đổ”

của các dự án trước.

Số liệu phục vụ cho việc phân tích lỗi có thể đến từ nhiều nguồn khác nhau. Mỗi tổ

chức tuỳ theo nhu cầu và đặc điểm riêng, tự định nghĩa và thu thập các số liệu nầy.

Lỗi trong quá trình phân tích và sửa chữa có thể được phân loại để có hành động phù

hợp, tuỳ theo các đặc tính khác nhau mà chúng thể hiện.

* Quản lý cấu hình

Mục đích của quản lý cấu hình (QLCH) là để thiết lập và bảo đảm tính toàn vẹn của

các sản phẩm trung gian cũng như các sản phẩm sau cùng của một dự án PM, xuyên suốt

chu kỳ sống của dự án đó.

QLCH bao gồm nhiều hoạt động, tuy nhiên về cơ bản chúng bao gồm bốn hoạt động

chính: nhận dạng (identification), kiểm soát (control), kiểm kê báo cáo (accounting) và kiểm

tra đánh giá (audit). Tùy theo độ lớn và độ phức tạp của dự án, phạm vi và mức độ áp dụng

của các hoạt động QLCH sẽ khác nhau. Với những hệ thống lớn và phức tạp, mỗi hoạt động

QLCH phải do những người được giao trách nhiệm (role) cụ thể phụ trách. Tùy yêu cầu,

một số hoạt động QLCH được làm không chính thức (informal) hoặc chính thức (formal),

nhằm quản lý tốt quá trình phát triển của phần mềm, đặc biệt là quản lý sự thay đổi trong dự

án.

* Bảo mật

Bảo mật luôn là vấn đề gây nhức nhối vì thường không được nhận thấy cho đến khi

hệ thống bị chọc thủng. Bảo mật có ba khía cạnh chính, bảo mật nội dung dữ liệu, bảo mật

dữ liệu đang được truyền (trên đường truyền) và bảo mật về mặt vật lý của vật chứa dữ liệu.

Các hoạt động bảo mật được áp dụng cho cả nội dung dữ liệu lẫn bản thân vật lý của vật

chứa dữ liệu.

Các yếu tố hay nguyên nhân tác động đến dữ liệu hoặc trung tâm dữ liệu của hệ

thống PM rất đa dạng. Đó có thể là tự nhiên hoặc cố ý, chẳng hạn thiên tai, cháy, virus,

hacker, phá hoại của chính nhân viên công ty, ăn cắp dữ liệu, thậm chí ngày nay còn do các

hoạt động khủng bố gây ra. Trong một số tổ chức, việc bảo mật dữ liệu lưu trữ và dữ liệu

chuyển dịch được xem là vấn đề sống còn.

Một lý do gây hỏng dữ liệu rất thường gặp là dữ liệu bị thay đổi một cách vô tình

không kiểm soát được. Một khi dữ liệu đã không đúng, điều tất yếu là hệ thống phần mềm

sử dụng dữ liệu đó sẽ cho ra những kết quả sai. Đối với người dùng, đó là một hệ thống

không tốt, thậm chí là không dùng được.

Một hệ thống PM "tốt" phải chú ý tới tất cả những yếu tố có thể ảnh hưởng đến dữ

liệu hoặc hoạt động của hệ thống. Một hệ thống "tốt" còn phải tính đến khả năng phục hồi

dữ liệu, phục hồi hoạt động của hệ thống khi xảy ra sự cố.

* Đào tạo/huấn luyện

Nói đơn giản, huấn luyện nhằm trang bị cho những người phát triển cũng như sử

dụng PM có đủ kiến thức và kỹ năng để thực hiện công việc của họ.

Tất cả mọi biện pháp quản lý, kỹ thuật sản xuất, công cụ hỗ trợ trong sản xuất PM

đều trở nên vô hiệu hoặc có hiệu quả hết sức hạn chế nếu những người tham gia phát triển

và sử dụng PM không đủ kiến thức, kỹ năng cần thiết. Liên quan đến lý do nầy, các tiêu

chuẩn quản lý chất lượng như ISO, CMM/CMMi đều xác lập khả năng, kiến thức và kỹ

năng của những người phát triển PM là một trong những yêu cầu cốt yếu để bảo đảm các

tiêu chí và mục tiêu về chất lượng.

Một khía cạnh khác thường được cho là ít quan trọng nhưng thực ra lại mang tính

quyết định, đó là khả năng hiểu để sử dụng PM của người sử dụng. Người sử dụng thường

chỉ có ý tưởng về yêu cầu đối với PM và không biết sử dụng hoặc sử dụng không đúng cách

làm PM "chạy" sai hoặc không hết chức năng. Do vậy huấn luyện cho người sử dụng cũng

là một khâu hết sức cơ bản. Nhưng thực tế những người phát triển PM lại không có thời

gian và kỹ năng thực hiện tốt việc huấn luyện, việc nầy thường phải do một bộ phận chuyên

trách trong công ty thực hiện.

* Quản lý người cung cấp

Trong các tổ chức PM, mua hay thuê sản phẩm hoặc dịch vụ từ một người cung cấp

thứ ba là rất phổ biến. Việc "mua" có thể bao gồm những mặt hàng đơn giản như máy tính,

máy in, cho đến những dịch vụ thuê gia công PM. Chất lượng của sản phẩm và dịch vụ

"mua" này nếu quản lý không tốt sẽ ảnh hưởng quan trọng đến sản phẩm hoặc dịch vụ của

tổ chức cung cấp cho khách hàng của mình.

Đối tượng sản phẩm hoặc dịch vụ cần mua hay thuê rất đa dạng, tùy mỗi loại và độ

phức tạp, các tổ chức sẽ có những biện pháp và mức độ quản lý chất lượng tương ứng.

* Quản lý rủi ro

Rủi ro (risk) là một yếu tố tồn tại trong mọi dự án. Quan niệm về quản trị dự án cho

rằng "người quản trị dự án giỏi là người không ngạc nhiên về các sự kiện xảy ra trong dự

án", điều nầy có nghĩa là mọi rủi ro tiềm ẩn phải được "nhìn thấy" trước, đi đôi với kế hoạch

giải quyết.

Rủi ro là một sự kiện chưa nhưng có khả năng xảy ra, và khi nó xảy ra thường sẽ đặt

một dự án vào tình huống xấu, hoặc thậm chí là một "tai nạn" cản trở khả năng hoàn thành

các mục tiêu của một dự án.

Hình 3: Mô hình tổ chức truyền thống.

3.4. Phương pháp & công cụ hỗ trợ quản lý

3.4.1. Microsoft Project

Microsoft Project là một chương trình chuyên dùng để quản lý các dự án, là chương

trình có những công cụ mạnh và thuận tiện. Microsoft Project có thể làm việc với nhiều chế

độ, nhiều công cụ, chức năng để thực hiện các thao tác tạo lập và hiệu chỉnh trên dự án đồng

thời tiết kiệm thời gian và tiền bạc.

Mục đích của Microsoft Project 2003 gồm:

 Tổ chức lập kế hoạch và quản lý dự án.

 Lên lịch công tác.

 Chỉ định các tài nguyên và chi phí cho các công việc trong dự án.

 Điều chỉnh kế hoạch để thích ứng với các điều kiện ràng buộc.

 Chuẩn bị các báo biểu cần thiết cho dự án.

 Dự trù các tác động đến tiến độ của dự án khi xảy ra những thay đổi có ảnh

hưởng lớn đến dự án.

 Xem xét lại dự án để đối phó với các tình huống ngẫu nhiên.

 Đánh giá tài chính chung của dự án.

 In ấn các báo biểu phục vụ dự án.

 Làm việc và quản lý theo nhóm.

 Rút kinh nghiệm trong khi thực hiện dự án.

Để chạy Microsoft Project 2003 phần cứng tối thiểu của máy tính là:

 Bộ vi xử lý 486 trở lên

 16 Mb RAM

 Window 9x

 Ổ cứng >100 Mb

Và cần có các phần mềm sau:

 Phần mềm Microsoft Project 2003

 Bộ gõ tiếng Việt

Microsoft Project hỗ trợ các công việc

 Thiết lập một dự án mới

 Nhập các thông tin quan trọng cho dự án

 Thiết lập hệ thống làm việc cho dự án

 nhập và tổ chức các công việc

 Tạo mốc dự án

 Thiết lập mối quan hệ giữa các công việc

 Phân công một Calendar đến dự án

 …

3.4.2. Microsoft SourceSafe

Source Safe nguyên thủy được sản xuất bởi 1 công ty tên là “One Tree Software” .

Version đầu tiên được phát hành là bản 3.1 , đó là 1 chương trình 16 bit. Microsoft thời

điểm đó cũng có 1 hê ¥ thống quản lý source code yếu hơn là Delta . Năm 1994 , Microsoft

mua lại công ty “One Tree Software” và câ ¥p nhâ ¥t lại phiên bản 3.1 . Kết quả là sự ra đời

phiên bản 4.0 của visual Source Safe . Đó là phiên bản 32 bit . Năm 1995 , nó được phát

hành rô ¥ng rãi .

Source Safe không phải là 1 trình quản lý source code dạng client/server. Nó chấp

nhâ ¥n cho hê ¥ thống người dùng đơn lẻ ít phải cấu hình hơn các hê ¥ thống quản lý source code

khác. Thêm vào đó, quy trình sao lưu dữ liê ¥u có thể đơn giản như viê ¥c copy toàn bô¥ nô ¥i

dung của cây thư mục. Tuy nhiên đối với môi trường nhiều người dùng , nó thiếu nhiều

chức năng quan trọng được tìm thấy trong các hê ¥ thống quản lý cấu hình khác

Source Safe thừa kế nhiều chức năng chia sẽ sử dụng hê ¥ thống điều khiển file để

thâm nhâ ¥p vào tất cả các file trong repository .

Khởi đầu với Visual Source Safe 2005, Microsoft đã thêm vào 1 chế đô ¥ client-server.

Trong chế đô ¥ này, người dùng không cần ghi các đường dẫn vào Server Message Block nơi

chúng có thể làm nguy hại tới Source Safe database. Thay vào đó, file phải được truy câ ¥p từ

các công cụ phía người dùng như : the VSS windows client, the VSS command-line tool ,

hoă ¥c các chương trình khác thích hợp ,hoă ¥c cạnh tranh với các chương trình phía người

dùng đó.

Như hầu hết các hê ¥ thống quản lý cấu hình khác, Source Safe tạo 1 thư viê ¥n ảo trên

các tâ ¥p tin máy tính . Người dùng có thể đọc bất kì file nào tại bất kì thời điểm nào ,nhưng

để thay đổi nó , người dùng phải “check out” nó trước . Sau khi chúng được sửa chữa , phải

“check in” nó lại . Những thay đổi sẽ được câ ¥p nhâ ¥t đối với tất cả người dùng sau khi nó

được “check in”.

Microsoft chỉ hỗ trợ Source Safe trên nền tảng Windows. Các đối tác của Microsoft

đưa ra các phiên bản không dành cho windows của Source Safe như :

• Dynamsoft đưa ra 1 sản phẩn tích hợp Source Safe đó là SourceAnywhere for VSS

phục vụ cho người dùng java .

• Metrowerks đưa ra sản phẩm quản lý cấu hình tương thích với Source Safe cho hê ¥

điều hành MacOS.

• SourceGear đưa ra sản phẩm tích hợp Source Safe là SourceOffSite cho người dùng

sử dụng Hê ¥ điều hành MacOS , Linux , Solaris.

3.4.3. Visio

Visio là một chương trình vẽ sơ đồ thông minh, được tích hợp vào bộ chương trình

Microsoft Office từ phiên bản 2003. MS cho phép thể hiện bản vẽ một cách trực quan.Visio

Visio cung cấp nhiều đặc tính khiến cho sơ đồ ý nghĩa hơn, linh động hơn và phù hợp với

nhiều nhu cầu khác nhau.

Visio có thể:

 sao chép bản vẽ từ qua các phần mềm khác (Word, Excel…) để tiện sửVisio

dụng.

 tạo các biểu đồ liên quan đến công việc như là: biểu đồ dòng (flowcharts), biểu đồ

tổ chức (organization charts), lịch trình dự án (project scheduling).

 tạo các biểu đồ mang tính kỹ thuật như tạo các bản vẽ xây dựng, thiết kế nhà, biểu

đồ mạng, biểu đồ phần mềm, biểu đồ trang web, biểu đồ máy móc…

MS Visio cho phép bạn thể hiện bản vẽ một cách trực quan. Hơn nữa, nó còn cung

cấp nhiều đặc tính khiến cho sơ đồ của bạn ý nghĩa hơn, linh động hơn và phù hợp hơn với

nhu cầu của bạn ,…) để tiện sử dụng cho công việc của bạn. Với MS Visio, bạn có thể tạo

các sơ đồ liên quan đến công việc như là : biểu đồ dòng (flowcharts), sơ đồ tổ chức

(organization charts), và lịch trình dự án (project scheduling). Ngoài ra, Visio còn cho phép

bạn tạo các sơ đồ mang tính kỹ thuật, chẳng hạn tạo các bản vẽ xây dựng, thiết kế nhà, sơ đồ

mạng, sơ đồ phần mềm, sơ đồ trang web, sơ đồ máy móc, và các sơ đồ kỹ thuật khác.

Chương 4. Ngôn ngữ mô hình hóa UML

4.1. Ngôn ngữ mô hình hóa thống nhất UML

4.1.1. Giới thiệu

Cùng với xu khung phát triển của công nghệ thông tin, công nghệ phần mềm đã và

đang trở thành lĩnh vực quan trọng của nhiều quốc gia trên thế giới. Ngày nay, việc phát

triển một phần mềm với qui mô và chất lượng cao không còn là công việc đơn lẻ của những

nhà lập trình, của một cá nhân, đó là sản phẩm của một tập thể, một công ty phần mềm theo

một qui trình công nghệ chuẩn được quản lý chặt chẽ và được hỗ trợ tối đa bởi các công cụ

và môi trường phát triển phần mềm. Do đó, việc lập trình ngày càng trở nên dễ dàng hơn và

nhường lại vai trò mấu chốt cho việc phân tích và thiết kế phần mềm, trong đó quan trọng

nhất là đặc tả và mô hình hoá thế giới thực.

Trong tình hình đó các công ty phần mềm lớn trên thế giới đã nhanh chóng đưa ra

nhiều công cụ hỗ trợ phân tích thiết kế dựa trên nhiều phương pháp khác nhau.

Những năm đầu thập kỷ 90 có rất nhiều phương pháp phân tích thiết kế khung đối

tượng ra đời và phát triển mạnh mẽ và mỗi phương pháp có các ký hiệu riêng (Năm 1994,

có khoảng hơn 50 OO phương pháp, như Fusion, Shlaer-Mellor, ROOM, Class-Relation,

Wirfs-Brock, Coad-Yourdon, MOSES, Syntropy, BOOM, OOSD, OSA, BON, Catalysis,

COMMA, HOOD, Ooram, DOORS … ). Ba phương pháp phổ biến nhất là OMT (Object

Modeling Technique)[James Rumbaugh], Booch91[Grady Booch] và OOSE (Object-

Oriented Software Enginering)[Ivar Jacobson]. Mỗi phương pháp đều có những điểm mạnh,

điểm yếu riêng. Ví dụ, OMT mạnh trong phân tích và yếu trong thiết kế, Booch91 thì mạnh

ở thiết kế và yếu ở phân tích. OOSE mạnh ở phân tích các ứng xử, đáp ứng của hệ thống mà

yếu ở các khâu khác.

Do các phương pháp chưa hoàn thiện nên người dùng rất phân vân trong việc chọn ra

một phương pháp phù hợp nhất để giải quyết bài toán của họ. Hơn nữa, cách ký hiệu khác

nhau của các phương pháp đã gây ra những sự mập mờ, nhầm lẫn khi mà một ký hiệu có thể

mang những ý nghĩa khác nhau trong mỗi phương pháp. Ví dụ như một hình tròn được tô

đen biểu hiện một multiplicity trong OMT lại là một aggregation trong Booch. Thời kỳ này

còn được biết đến với tên gọi là cuộc chiến giữa các phương pháp. Khoảng đầu năm 94,

Booch đã cải tiến phương pháp của mình trong đó có ứng dụng những ưu điểm của các

phương pháp của Rumbaugh và Jacobson. Tương tự Rumbaugh cũng cho đăng một loạt các

bài báo được biết đến với tên gọi phương pháp OMT-2 cũng sử dụng nhiều ưu điểm của

phương pháp của Booch. Các phương pháp đã bắt đầu hợp nhất, nhưng các kí hiệu sử dụng

ở các phương pháp vẫn còn nhiều điểm khác biệt. Cuộc chiến này chỉ kết thúc khi có sự ra

đời của UML - một ngôn ngữ mô hình hóa hợp nhất.

Theo một bài báo của một nhà khoa học nổi tiếng trong lĩnh vực công nghệ thông tin

– Sinan Si Alhir - với tựa đề “Tri thức – nhân tố quyết định của sự thành công!”, bài báo

viết “Tri thức là sức mạnh – đây là câu nói của một nhà triết gia nổi tiếng – FrancisBacon.

Ngày nay, trên thị trường toàn cầu – và nhất là trong lĩnh vực công nghệ thông tin – nơi mà

sự cạnh tranh trở nên rất phổ biến và quyết liệt, tri thức và khả năng áp dụng của chúng vào

công việc một cách hiệu quả sẽ mang lại cho chúng ta một lợi thế quan trọng vào loại bậc

nhất. Chính điều này đã dẫn tới một câu hỏi – làm thế nào một tổ chức có thể nắm bắt,

truyền đạt, trao đổi và nâng cao tri thức của mình để đạt được lợi thế cạnh tranh trên thị

trường? Có lé câu trả lời chính là ngôn ngữ UML từ hãng phần mềm Rational và tổ chức

OMG (Object Management Group)”. Vậy UML là gì, tại sao nó được giới thiệu ấn tượng

đến như thế?

UML (Unified Modeling Language) là gì?

UML – Unified Modeling Language - tạm dịch là ngôn ngữ mô hình hợp nhất, nó

được hiểu như là một ngôn ngữ thống nhất các xu khung và hình thái của cuộc cách mạng

tri thức trong lĩnh vực thông tin. Nó là một phương tiện giúp cho các tổ chức có thể nhận

thức được một cách tốt nhất các lợi thế cạnh tranh thông qua việc nắm bắt, truyền đạt, trao

đổi và nâng cao tri thức trong lĩnh vực công nghệ phần mềm. Chính xác hơn UML là một

ngôn ngữ mô hình hoá chuẩn dùng để đặc tả, trực quan hoá, xây dựng và làm tài liệu cho

các hệ thống phần mềm...

Unified (hợp nhất): UML được đưa ra lần đầu tiên bởi hãng Rational và ba chuyên

gia về phương pháp luận hàng đầu trong lĩnh vực hệ thống thông tin/kỹ thuật công nghệ

Grady Booch, James Rumbaugh, Ivar Jacobson. Nó là sự hợp nhất giữa những phương pháp

cũ (Booch, OMT, OOSE...), kết hợp với những kinh nghiệm, những kiến thức thực tế trong

lĩnh vực công nghệ thông tin. Hình chỉ ra sự hợp nhất của UML.

Modeling (mô hình hoá): giúp chúng ta hiểu được thế giới thực, mô hình hoá thế giới

thực để có thể hiểu được những đặc trưng, tính toán các thông số và dự đoán kết quả sẽ đạt

được.

Language (ngôn ngữ): các chức năng của UML như là một phương tiện để bày tỏ và

trao đổi tri thức. Nó có bốn đặc điểm chủ yếu có thể phân biệt với các ngôn ngữ mô hình

hoá khác: đa dụng (general purpose), có thể ứng dụng rộng rãi (Broadly applicable), được

hỗ trợ bởi các công cụ (Tool-supported), chuẩn công nghiệp (Industry standardized)

Sự ra đời của UML là một tất yếu khách quan trước sự bùng nổ của nghành công

nghệ thông tin, nó làm nổi bật những xu khung then chốt trong nghành công nghệ phần

mềm, đưa ra được những những vấn đề do sự phân rã của những phương thức mô hình hoá

trước đây gây ra. UML được hình thành trên cơ sở của các vấn đề chính - tại sao chúng ta

lại cần mô hình hoá phần mềm, xu khung phát triển trong nghành công nghệ phần mềm

ngày nay, sự hội tụ của các công nghệ...

Tầm quan trọng của việc mô hình hoá

Mô hình là gì? Đó chính là sự đơn giản hoá của thế giới thực.

Việc phát triển một mô hình cho một hệ thống trong công nghệ phần mềm cũng cần

thiết như là việc lập một bảng thiết kế cho một toà nhà lớn.

Những mô hình tốt giúp cho việc phối hợp giữa các nhóm phát triển tốt hơn.

Chúng ta cần xây dựng mô hình cho những hệ thống phức tạp bởi vì chúng ta không

thể hiểu được toàn bộ hệ thống trong một môi trường rộng lớn như thế, khi sự phức tạp của

hệ thống càng tăng, thì nó cũng đòi hỏi kỹ thuật mô hình hoá tốt hơn. Việc xây dựng mô

hình giúp chúng ta hiểu rõ hơn về hệ thống mà chúng ta đang xây dựng.

Mô hình cung cấp cho chúng ta một khuôn mẫu về thế giới thực, giúp chúng ta có thể

định khung trong quá trình xây dựng , có thể tính toán các chi phí, xác định các rủi ro, làm

tài liệu cho hệ thống...

Trong các nhân tố quyết định đến sự thành công của dự án, nhân tố cần thiết là một

mô hình chuẩn, đặc tả đầy đủ, chi tiết về thời gian thực.

Trong một hệ thống mà độ phức tạp càng tăng, việc trực quan hoá và mô hình hoá

càng cần thiết. Ngôn ngữ UML là một sự lựa chọn hoàn hảo và trên thực tế nó cũng đã được

sử dụng và được chấp nhận rộng rãi trên thế giới.

Sự hội tụ của các công nghệ

Trước khi UML ra đời, không có ngôn ngữ mô hình hoá nào trội hơn hẳn các ngôn

ngữ khác. Người dùng phải lựa chọn trong những ngôn ngữ khá tương tự nhau với những

khác biệt nhỏ và cùng chia sẻ trên một tập khái niệm chung. Sự thiếu tương đồng này đã

ngăn cản những người mới tiếp cận với các kỹ thuật khung đối tượng và mô hình khung đối

tượng.

Việc thường xuyên phải chi phí cho việc sử dụng và hỗ trợ cho nhiều ngôn ngữ mô

hình hoá đã thúc đẩy nhiều công ty đầu tư vào sản xuất hoặc sử dụng kỹ thuật mới, họ tán

thành và hỗ trợ cho việc phát triển ngôn ngữ UML.

UML đã làm được rất nhiều, ví dụ, Làm giảm đáng kể những chi phí thường xuyên

cho việc huấn luyện và thay đổi công cụ khi thay đổi dự án hoặc tổ chức; Cung cấp cơ hội

cho việc tích hợp mới giữa các công cụ, các tiến trình...; Tạo ra một kiểu mẫu chuẩn, thống

nhất cho các công việc.

So sánh với các phương pháp khác

Các nhà phát triến đã cố gắng duy trì tính đơn giản của UML, loại bỏ các thành phần

không được sử dụng trong thực tế từ các phương pháp Booch, OMT, OOSE, thêm vào các

thành phần và ý tưởng hiệu quả hơn từ các phương pháp khác nhau và chỉ xây dựng mới các

thành phần cần thiết. Một số khái niệm mới được sử dụng trong UML bao gồm:

Cơ chế mở rộng (extension mechanism)

Luồng (thread) và tiến trình (process)

Sự phân tán (distribution) và đồng thời (concurrency) (dùng để mô hình hóa các ứng

dụng ActiveX, DCOM và CORBA)

Khuôn mẫu (patterns) và sự cộng tác (collabarations)

Các biểu đồ hoạt động (activity diagrams)

Sự tinh chế (refinement): xử lý các mối liên quan giữa các mức trừu tượng.

Giao diện (interface) và thành phần (component)

Ngôn ngữ mô tả ràng buộc (constraint language)

UML không hoàn toàn tách biệt khỏi ba phương pháp cơ bản là Booch, OMT (Object

Modeling Technique), OOSE (Object-Oriented Software Engineering) mà nó tổng hợp tinh

hoa của cả ba phương pháp trên. Vì vậy, nếu trước đây bạn từng là người sử dụng các

phương pháp Booch, OMT, OOSE thì những kiến thức, kinh nghiệm, các công cụ vẫn còn

có giá trị sử dụng. UML có thể mô tả hệ thống một cách rõ ràng và thống nhất hơn so với

các phương pháp Booch, OMT, OOSE và các ngôn ngữ khác. Điều này có nghĩa rằng việc

chuyển qua dùng UML sẽ mang đến cho người sử dụng một giá trị nhất định nào đó, bởi vì

nó cho phép bạn lập mô hình mọi công việc trong dự án, điều mà trước đây chưa có ngôn

ngữ nào làm được.

Những người trước đây đã từng dùng các phương pháp và ngôn ngữ mô hình hoá

khác sẽ có được lợi ích khi chuyển qua sử dụng ngôn ngữ UML, nó giúp cho họ loại bỏ

những khác biệt không cần thiết về ngữ nghĩa và kỹ thuật thường xảy ra ở những ngôn ngữ

và phương pháp đã đề cập ở trên. UML có hệ thống ký hiệu rất rõ ràng, mang tính thống

nhất cao, được hỗ trợ bởi nhiều công cụ phát triển phần mềm. Đồng thời trên một công cụ

có hỗ trợ UML, người dùng có thể chuyển đổi các mô hình hiện tại của họ sang UML mà

không sợ mất đi thông tin nào.

UML là sự hợp nhất của các phương pháp khung đối tượng, vì vậy nó cũng kế thừa

một số khái niệm từ các phương pháp này, ví dụ:

Biểu đồ ca sử dụng (Ca sử dụng diagram): tương tự như trong phương pháp OOSE.

Biểu đồ lớp (class diagram) được kết hợp từ OMT và Booch và hầu hết các phương

pháp khung đối tượng khác.

Cơ chế mở rộng được định nghĩa trên nhiều loại biểu đồ và hỗ trợ cho nhiều loại mô

hình của UML để tạo ra các thành phần đa dạng mang đặc điểm riêng biệt của hệ thống

nhằm mục đích hỗ trợ các góc độ mô hình hoá khác nhau. Nhiều khái niệm mới được bổ

sung liên quan đến cơ chế mở rộng trước đây chưa từng được mô tả trong các ngôn ngữ mô

hình hoá chủ yếu khác bao gồm các khuôn mẫu (stereotypes), các ràng buộc (constraints) và

giá trị thẻ (tagged values)

Biểu đồ State – chart cơ bản dựa trên biểu đồ cùng loại của David Harel với một ít

thay đổi nhỏ. Biểu đồ hoạt động cũng dựa trên phần lớn các ngữ nghĩa cơ bản dùng để định

nghĩa State – chart của UML và tương tự như biểu đồ luồng công việc (workflow diagram)

trong nhiều phương pháp khác.

Biểu đồ tuần tự được tìm thấy trong nhiều phương pháo khung đối tượng dưới nhiều

tên gọi khác nhau (interaction, message trace hoặc event trace)

Biểu đồ cộng tác (collaboration diagram) được sửa đổi lại từ biểu đồ đối tượng

(object diagram) của Booch và biểu đồ tương tác đối tượng (object interaction) của Fusion.

Biểu đồ thực thi (Implementation diagram) hay còn gọi là biểu đồ thành phần và triển

khai bắt nguồn từ phương pháp của Booch. Tuy nhiên, chúng giờ đây mang tính chất khung

thành phần (component centered) và liên kết với nhau tốt hơn nhiều so với trước.

Stereotypes là một trong ba cơ chế mở rộng ngữ nghĩa của các thành phần UML sẵn

có. Các stereotype cho phép biến đổi UML theo khung mở rộng nghĩa là tạo ra các thành

phần mang ngữ nghĩa mới đặc trưng riêng của hệ thống mà vẫn giữ nguyên các thành phần

đã định nghĩa.

Ngôn ngữ mô tả ràng buộc (Object Constraint Language) được UML sử dụng để đặc

tả ngữ nghĩa và được xem là ngôn ngữ mô tả trong quá trình mô hình hoá. OCL có nguồn

gốc từ phương pháp Syntropy và chịu ảnh hưởng bởi một số ngôn ngữ cùng loại trong các

phương pháp khác như Catalysis nhưng được chuẩn hoá và mở rộng hơn.

Lịch sử phát triển

UML được phát triển bởi hãng Rational và những đối tác. Được bắt đầu phát triển

vào tháng 10 năm 1994, khi Grady Booch và Jim Rumbaugh bắt đầu công việc hợp nhất hai

phương pháp Booch và OMT. Bản phác thảo của phiên bản 0.8 được đưa ra vào tháng 10

năm 1995 với tên ban đầu là Unified Method. Mùa thu năm 1995, Ivar Jacobson cùng công

ty của ông quyết định phối hợp với hãng Rational, bằng nỗ lực kết hợp thêm phương pháp

OOSE, để tiếp tục phát triển Unified Method.

Với những nỗ lực của Booch, Rumbaugh, và Jacobson đã đưa ra phiên bản 0.9 và

0.91 vào tháng 6 và tháng 10 năm 1996 với tên là UML. Trong suốt năm 1996, nhóm các

tác giả của UML đã nhận được rất nhiều sự phản hồi từ phía người sử dụng và các chuyên

gai trong lĩnh vực, họ đúc kết và bổ sung từ những ý kiến này, nhưng rõ ràng cần phải có sự

quan tâm nhiều hơn nữa từ phía người sử dụng. Từ đây, UML được sự quan tâm nhiều hơn

từ các tổ chức, các công ty phần mềm lớn, và với sự cộng tác của những công ty hàng đầu

như Digital Equipment, HP, IBM, Microsoft, Oracle...phiên bản UML trở thành một ngôn

ngữ mô hình hoá được định nghĩa tốt hơn, rõ ràng, dễ hiểu, mạnh hơn và có khả năng ứng

dụng rộng rãi.

Phiên bản UML 1.1 là sự phát triển về mặt ngữ nghĩa của phiên bản 1.0 đồng thời

cũng tích hợp thêm những đóng góp của những nhà cộng tác mới. UML lần đầu tiên được

đệ trình lên tổ chức OMG vào tháng 1/1997 và lần cuối vào tháng 9/1997 trước khi được

đưa vào danh sách những kỹ thuật được thừa nhận của OMG vào tháng 11/1997. Kể từ đây

OMG chịu trách nhiệm cho sự phát triển của UML trong tương lai. Sau khi được thừa nhận

vào tháng 11/1997, OMG chịu trách nhiệm kiểm tra và phản hồi những kiến nghị từ phía

các đối tác sử dụng, đồng thời tổ chức OMG cũng chịu trách nhiệm xử lý các lỗi kỹ thuật,

những điểm bất đồng, những điểm còn mơ hồ và những thiếu sót nhỏ mà không cần phải

sửa đổi nhiều so với bản thảo ban đầu. Kể từ đây UML được đưa vào sử dụng rộng rãi và

được cải tiến không ngừng, phiên bản UML 1.3 alpha được giới thiệu vào tháng 3/1999 và

sau đó phiên bản UML 1.3 chính thức được giới thiệu vào tháng 6/1999.

4.1.2. Các đặc trưng và khả năng của UML

a. UML là một ngôn ngữ dùng để đặc tả

Có nghĩa là xây dựng các mô hình một các tỉ mỉ, rõ ràng, đầy đủ ở các mức độ chi

tiết khác nhau. Đặc biệt là UML thực hiện việc chi tiết hoá tất cả các quyết định quan trọng

trong phân tích, thiết kế và thực thi một hệ thống phần mềm.

b. UML là ngôn ngữ dùng để trực quan hóa

Đối với nhiều lập trình viên, không có khoảng cách giữa ý tưởng giải quyết một vấn

đề và việc thể hiện điều đó thông qua các đoạn mã. Họ nghĩ ra và họ viết mã. Thực tế, điều

này gặp một số vấn đề. Thứ nhất, việc trao đổi về ý tưởng giữa những người lập trình gặp

khó khăn, trừ khi tất cả đều nói cùng một ngôn ngữ. Thậm chí ngay cả khi không gặp trở

ngại về ngôn ngữ thì đối với từng công ty, từng nhóm cũng có những “ngôn ngữ” riêng của

họ. Điều này gây trở ngại cho người mới vào để có thể hiểu được những việc đang được tiến

hành. Hơn nữa, trong lĩnh vực phần mềm, nhiều khi khó có thể hiểu được nếu chỉ xem xét

các đoạn mã lệnh. Ví dụ như sự phân cấp của các lớp, ta có thể phải duyệt rất nhiều đoạn

lệnh để hiểu được sự phân cấp của các lớp. Và nếu như người lập trình không mô tả các ý

tưởng mà anh ta xây dựng thành mã lệnh thì nhiều khi cách tốt nhất là xây dựng lại trong

trường hợp một người khác đảm nhận tiếp nhiệm vụ của anh ta. Xây dựng mô hình sử dụng

ngôn ngữ UML đã giải quyết được các khó khăn trên. Khi trở thành một chuẩn trong việc

lập mô hình, mỗi kí hiệu mang một ý nghĩa rõ ràng và duy nhất, một nhà phát triển có thể

đọc được mô hình xây dựng bằng UML do một người khác viết. Những cấu trúc mà việc

nắm bắt thông qua đọc mã lệnh là khó khăn nay đã được thể hiện trực quan. Một mô hình rõ

ràng, sáng sủa làm tăng khả năng giao tiếp, trao đổi giữa các nhà phát triển.

c. UML là ngôn ngữ dùng để xây dựng

Các mô hình xây dựng bởi UML có thể ánh xạ tới một ngôn ngữ lập trình cụ thể

như : Java, C++... thậm chí cả các bảng trong một cơ sở dữ liệu quan hệ hay cơ sở dữ liệu

khung đối tượng. Việc các yêu cầu có khả năng thường xuyên thay đổi trong quá trình phát

triển hệ thống dẫn đến việc các cấu trúc và hành vi của hệ thống được xây dựng có thể khác

mô hình mà ta đã xây dựng. Điều này có thể làm cho một mô hình tốt trở nên vô nghĩa vì nó

không còn phản ánh đúng hệ thống nữa. Cho nên phải có một cơ chế để đồng bộ hóa giữa

mô hình và mã lệnh. UML cho phép cập nhật một mô hình từ các mã thực thi (ánh xạ

ngược). Điều này tạo ra sự nhất quán giữa mô hình của hệ thống và các đoạn mã thực thi mà

ta xây dựng cho hệ thống đó.

d. UML là ngôn ngữ dùng để lập và cung cấp tài liệu

Một tổ chức phần mềm mạnh ngoài việc tạo ra các đoạn mã lệnh (thực thi) thì còn

tạo ra tất cả các loại chế phẩm khác nhau để thêm vào cho các tài liệu như: Ghi chép về các

yêu cầu của hệ thống, kiến trúc của hệ thống, thiết kế, mã nguồn, kế hoạch dự án, kiểm thử,

các nguyên mẫu, ...

4.1.3. Kiến trúc trong UML

Kiến trúc phần mềm cho ta một cái nhìn khái quát về hệ thống phần mềm ở các góc

độ khác nhau. Kiến trúc của hệ thống phần mềm chuyên sâu được mô tả tốt nhất bằng năm

loại khung nhìn tương tác với nhau. Mỗi khung nhìn phản ánh về một khía cạnh của tổ chức

và cấu trúc của hệ thống, tập trung vào từng mặt cụ thể giúp cho ta hiểu và sử dụng hệ thống

tốt nhất. Mỗi khung nhìn được mô tả bằng một số biểu đồ, tuy nhiên không có sự phân biệt

rõ ràng giữa các khung nhìn vì một biểu đồ có thể là một bộ phận của nhiều hơn một khung

nhìn.

Hình 4.1. Các khung nhìn UML

a. Khung nhìn ca sử dụng (Ca sử dụng View)

Khung nhìn ca sử dụng mô tả chức năng của hệ thống sẽ phải cung cấp do được tác

nhân từ bên ngoài mong đợi. Tác nhân là thực thể tương tác với hệ thống; đó có thể là một

người sử dụng hoặc là một hệ thống khác. Khung nhìn cho ta cách sử dụng chức năng để

mô tả hành vi của hệ thống khi nhìn nhận dưới góc độ của người dùng cuối cùng, người

phân tích, người kiểm thử và người phát triển. Khung nhìn này được mô tả bởi biểu đồ ca sử

dụng và biểu đồ hoạt động. Cách sử dụng hệ thống nhìn chung sẽ được mô tả qua một loạt

các ca sử dụng trong khung nhìn ca sử dụng, nơi mỗi một ca sử dụng là một lời mô tả mang

tính đặc thù cho một tính năng của hệ thống (có nghĩa là một chức năng được mong đợi).

Khung nhìn ca sử dụng mang tính trung tâm, bởi nó đặt ra nội dung thúc đẩy sự phát

triển các khung nhìn khác. Mục tiêu chung của hệ thống là cung cấp các chức năng mô tả

trong khung nhìn này – cùng với một vài các thuộc tính mang tính phi chức năng khác – vì

thế khung nhìn này có ảnh hưởng đến tất cả các khung nhìn khác. Khung nhìn này cũng

được sử dụng để thẩm tra (verify) hệ thống qua việc thử nghiệm xem khung nhìn ca sử dụng

có đúng với mong đợi của khách hàng (Hỏi: "Đây có phải là thứ bạn muốn") cũng như có

đúng với hệ thống vừa được hoàn thành (Hỏi: "Hệ thống có hoạt động như đã đặc tả?”).

b. Khung nhìn logic (Logical View)

Khung nhìn logic mô tả phương thức mà các chức năng của hệ thống sẽ được cung

cấp. Chủ yếu nó được sử dụng cho các nhà thiết kế và nhà phát triển. Ngược lại với khung

nhìn ca sử dụng, khung nhìn logic nhìn vào phía bên trong của hệ thống. Nó mô tả kể cả cấu

trúc tĩnh (lớp, đối tượng, và quan hệ) cũng như sự tương tác động sẽ xảy ra khi các đối

tượng gửi thông điệp cho nhau để cung cấp chức năng đã định sẵn. Khung nhìn logic định

nghĩa các thuộc tính như trường tồn (persistency) hoặc song song (concurrency), cũng như

các giao diện cũng như cấu trúc nội tại của các lớp.

Cấu trúc tĩnh được mô tả bằng các biểu đồ lớp (class diagram) và biểu đồ đối tượng

(object diagram). Quá trình mô hình hóa động được mô tả trong các biểu đồ trạng thái (state

diagram), biểu đồ trình tự (sequence diagram), biểu đồ tương tác (collaboration diagram) và

biểu đồ hoạt động (activity diagram).

c. Khung nhìn triển khai (Deployment View)

Khung nhìn triển khai chỉ cho chúng ta sơ đồ triển khai về mặt vật lý của hệ thống, ví

dụ như các máy tính cũng như các máy móc và sự liên kết giữa chúng với nhau. Khung nhìn

triển khai giành cho các nhà phát triển, người tích hợp cũng như người thử nghiệm hệ thống

và được thể hiện bằng các biểu đồ triển khai. Khung nhìn này cũng bao gồm sự ánh xạ các

thành phần của hệ thống vào cấu trúc vật lý; ví dụ như chương trình nào hay đối tượng nào

sẽ được thực thi trên máy tính nào.

d. Khung nhìn thành phần (Component View)

Là một lời mô tả của việc thực thi các modul cũng như sự phụ thuộc giữa chúng với

nhau. Nó thường được sử dụng cho nhà phát triển và thường bao gồm nhiều biểu đồ thành

phần. Thành phần ở đây là các modul lệnh thuộc nhiều loại khác nhau, sẽ được chỉ ra trong

biểu đồ cùng với cấu trúc cũng như sự phụ thuộc của chúng. Các thông tin bổ sung về các

thành phần, ví dụ như vị trí của tài nguyên (trách nhiệm đối với một thành phần), hoặc các

thông tin quản trị khác, ví dụ như một bản báo cáo về tiến trình của công việc cũng có thể

được bổ sung vào đây.

e. Khung nhìn song song (Concurrency View)

Khung nhìn song song nhắm tới sự chia hệ thống thành các qui trình (process) và các

bộ xử lý (processor). Khía cạnh này, vốn là một thuộc tính phi chức năng của hệ thống, cho

phép chúng ta sử dụng một cách hữu hiệu các nguồn tài nguyên, thực thi song song, cũng

như xử lý các sự kiện không đồng bộ từ môi trường. Bên cạnh việc chia hệ thống thành các

tiểu trình có thể được thực thi song song, khung nhìn này cũng phải quan tâm đến vấn đề

giao tiếp và đồng bộ hóa các tiểu trình đó.

Khung nhìn song song giành cho nhà phát triển và người tích hợp hệ thống, nó bao

gồm các biểu đồ động (trạng thái, trình tự, tương tác và hoạt động) cùng các biểu đồ thực thi

(biểu đồ thành phần và biểu đồ triển khai).

4.1.4. Mô hình khái niệm của UML

Các khối chính tạo nên UML là: các khối xây dựng cơ bản của UML, các quy tắc

ngữ nghĩa và một số cơ chế chung được áp dụng cho việc mô hình hoá.

a. Các khối xây dựng

* Các sự vật cấu trúc (structural things)

1. Lớp (Class): Là một tập hợp các đối tượng có cùng một tập thuộc tính, các hành

vi, các mối quan hệ với những đối tượng khác.

Hình 4.2. Biểu diễn lớp

2. Sự cộng tác (Collaboration): Thể hiện một giải pháp thi hành bên trong hệ thống,

bao gồm các lớp/đối tượng, mối quan hệ và sự tương tác giữa chúng để đạt được một chức

năng mong đợi của ca sử dụng.

Hình 4.3. Biểu diễn cộng tác

3. Giao diện (Interface): Là một tập hợp các phương thức (operation) tạo nên dịch vụ

của một lớp hoặc một thành phần (component). Nó chỉ ra một tập các operation ở mức khai

báo chứ không phải ở mức thực thi (implementation).

Hình 4.4. Biểu diễn giao diện

4. Ca sử dụng (Ca sử dụng): là mô tả một tập hợp của nhiều hành động tuần tự mà

hệ thống thực hiện để đạt được một kết quả có thể quan sát được đối với một actor cụ thể

nào đó. Actor là những gì ở bên ngoài mà tương tác với hệ thống. Ca sử dụng mô tả sự

tương tác giữa actor và hệ thống. Nó thể hiện chức năng mà hệ thống sẽ cung cấp cho actor.

Tập hợp các Ca sử dụng của hệ thố các trường hợp mà hệ thống có thể

được sử dụng.

Hình 4.5. Biểu diễn ca sử dụng

5. Lớp hoạt động (Acitive class): là một lớp mà các đối tượng của nó thực hiện các

hoạt động điều khiển. Lớp tích cực cũng giống như lớp bình thường ngoại trừ việc các đối

tượng của nó thể hiện các phần tử mà ứng xử của chúng có thể thực hiện đồng thời với các

phần từ khác. Lớp này thường dùng để biểu diễn tiến trình (process) và luồng (thread)

Tên lớp

Thuộc tính

Phương thức

Hình 4.6. Biểu diễn lớp hoạt động

6. Thành phần (Component): là biểu diễn vật lý của mã nguồn. Trong hệ thống ta sẽ

thấy các kiểu khác nhau của component như các thành phần COM+ hay JavaBeans cũng

như là các thành phần như các file mã nguồn, các file nhị phân tạo ra trong quá trình phát

triển hệ thống.

Hình 4.7. Biểu diễn thành phần

7. Nút (Node): là thể hiện một thành phần vật lý như máy tính hay thiết bị phần cứng

Hình 4.8. Biểu diễn nút

* Các sự vật hành vi (behavioral things)

1. Sự tương tác (Interaction): bao gồm một tập các thông báo (message) trao đổi

giữa các đối tượng trong một ngữ cảnh cụ thể nào đó để thực hiện một chức năng nào đó.

Hình 4.9. Biểu diễn thông báo

2. Máy trạng thái (States machine): thể hiện các trạng thái của một đối tượng trong

thời gian sống của nó nhằm đáp ứng các sự kiện, các tác động từ bên ngoài.

* Các sự vật nhóm gộp (Grouping things)

Gói (Package): Dùng để nhóm các phần tử có một ý nghĩa chung nào đó vào thành

nhóm. Không giống như các thành phần (component - tồn tại trong lúc thực thi), một

package chỉ mang tính trừu tượng. Package dùng để nhìn hệ thống ở một mức độ tổng quát

hơn so với việc xem xét từng phần tử trong package.

* Sự vật giải thích (Annotational thing): là các chú thích dùng để mô tả, làm sáng tỏ

và ghi chú về bất cứ phần tử nào trong mô hình. Thường dùng nhất là Note gồm các ràng

buộc hoặc ghi chú, được gắn với một phần tử hoặc một tập hợp các phần tử.

Hình 4.10. Biểu diễn chú thích

* Các quan hệ (Relationships)

1. Quan hệ phụ thuộc (Dependency): Là mối quan hệ ngữ nghĩa giữa hai sự vật,

trong đó sự thay đổi của một sự vật (sự vật độc lập) có thể tác động đến ngữ nghĩa của một

sự vật khác (sự vật phụ thuộc).

Hình 4.11. Biểu diễn quan hệ phụ thuộc

2. Quan hệ kết hợp ( Association): Là mối quan hệ cấu trúc mô tả một tập các mối

liên kết giữa một số các đối tượng của một lớp. Nói một cách đơn giản, khi một đối tượng

của lớp này gửi thông điệp tới hoặc nhận thông điệp từ một đối tượng của lớp kia thì ta nói

giữa 2 lớp có mối quan hệ association.

Hình 4.12. Biểu điễn quan hệ kết hợp

3. Quan hệ tập hợp (Aggreagation): Là một dạng đặc biệt của quan hệ liên kết. Nó

thể hiện sự liên kết “chặt” hơn, đó là mối quan hệ toàn thể-bộ phận.

Hình 4.13. Biểu diễn quan hệ tập hợp

4. Quan hệ hợp thành (Composition): là một dạng đặc biệt của quan hệ tập hợp

(aggregation). Trong đó nếu như đối tượng toàn thể bị hủy thì các đối tượng bộ phận của nó

cũng bị hủy theo.

Hình 4.14. Biểu diễn quan hệ hợp thành

5. Quan hệ tổng quát hoá (Generalization): là mối quan hệ tổng quát hóa/cụ thể hóa

trong đó đối tượng cụ thể sẽ kế thừa các thuộc tính và phương thức( behavior) của đối tượng

tổng quát.

Hình 4.15. Biểu diễn quan hệ tổng quát hóa

6. Quan hệ sự thực hiện hóa (Realization): Là mối quan hệ ngữ nghĩa giữa các phân

lớp, sao cho các phân lớp khác nhau đảm nhiệm thực hiện những trách nhiệm khác nhau.

Mối quan hệ thực hiện được đưa vào hai vị trí: giữa các giao diện và các lớp hoặc các thành

phần thực hiện của nó. Một mối quan hệ thực hiện được xem như một mối quan hệ nằm

giữa mối quan hệ tổng quát và mối quan hệ phụ thuộc.

Hình 4.16. Biểu diễn quan hệ hiện thực hóa

b. Các quy tắc

Mô hình hoá một hệ thống không đơn giản là lắp ghép các khối được xây dựng của

UML một cách ngẫu nhiên. Như bất cứ một ngôn ngữ nào, UML có những quy tắc chỉ ra

rằng một mô hình tốt sẽ như thế nào. Một mô hình tốt là mô hình mang tính nhất quán và có

sự kết hợp hài hòa giữa các mô hình có liên quan của nó.

UML có một số quy tắc dành cho việc:

- Đặt tên: để có thể truy xuất các phần tử của mô hình thì phải đặt tên cho chúng như

tên của các quan hệ, biểu đồ...

- Xác định phạm vi: ngữ cảnh mang lại một ý nghĩa cụ thể cho một cái tên

- Tính nhìn thấy được: để có được sự đơn giản và dễ kiểm soát thì ở những ngữ cảnh

khác nhau cần chỉ ra rằng một cái tên là hiện hữu và được sử dụng bởi những đối tượng

khác như thế nào.

- Tính toàn vẹn: mọi thứ quan hệ một cách đúng đắn và nhất quán với nhau như thế

nào.

c. Các cơ chế chung

* Đặc tả (Specification)

Các phần tử mô hình có thuộc tính (Property) chứa các giá trị dữ liệu về phần tử này.

Một thuộc tính được định nghĩa với một tên và một (tagged value), thườnggiá trị đính kèm

chúng ở trong một dạng thông tin được xác định trước, ví dụ như số nguyên hay chuỗi kí tự.

Có một loạt thuộc tính đã được định nghĩa trước, ví dụ như tài liệu (docement), trách nhiệm

(Responsibility), sự trường tồn (Persistence) và tính song song (Conccurency).

Hình 4.17. Một cửa sổ đặc tả thể hiện các đặc tính của class

Thuộc tính được sử dụng để thêm các đặc tả bổ sung về một phần tử, những thông tin

bình thường ra không được thể hiện trong biểu đồ. Ví dụ tiêu biểu là một lớp sẽ được mô tả

bằng một tài liệu văn bản nhất định, cung cấp nhiều thông tin hơn về trách nhiệm cũng như

khả năng của lớp này. Loại đặc tả này bình thường ra không được chỉ ra trong các biểu đồ,

nhưng thường thì trong đa phần các công cụ mô hình hóa chúng sẽ có thể được truy cập qua

hành động nhấp nút vào một phần tử nào đó, hiệu quả là một cửa sổ chứa đặc tả với tất cả

các thuộc tính sẽ được chỉ ra (Hình 4.17).

* Bài trí (Adornments)

Các sự trang trí trực quan có thể được sử dụng kèm thêm vào các phần tử mô hình

trong biểu đồ. Động tác trang trí bổ sung thêm ngữ nghĩa cho phần tử. Một ví dụ là kỹ thuật

được sử dụng để phân biệt một loại thực thể (lớp) và một thực thể. Khi thể hiện một loại, tên

phần tử sẽ được in đậm. Khi cũng chính phần tử đó thể hiện chỉ một thực thể của loại này,

tên phần tử sẽ được gạch dưới và có thể được coi là cả tên của thực thể lẫn tên của loại đó.

Một hình chữ nhật thể hiện lớp với tên được in đậm sẽ thể hiện một lớp và tên được gạch

dưới sẽ thể hiện một đối tượng, đây là một ví dụ tiêu biểu của adornment. Cũng nguyên tắc

đó được áp dụng cho các nút mạng, khi ký hiệu nút được in đậm là thể hiện một loại nút, ví

dụ như máy in (Printer), khi ký hiệu được gạch dưới là thể hiện một thực thể của lớp nút

mạng này ví dụ John’s HP 5MP-printer. Các kiểu trang trí khác là các lời đặc tả về số lượng

trong quan hệ (multiplicity), nơi số lượng là một số hay một khoảng số chỉ ra bao nhiêu thực

thể của các loại thực thể được nối với nhau sẽ có thể tham gia trong một quan hệ. Kí hiệu

trang trí được viết gần phần tử mô hình được mà nó bổ sung thông tin (hình 4.18).

Hình 4.18. Phân biệt giữa lớp và đối tượng bằng trang trí

* Ghi chú (Note)

Cho dù một ngôn ngữ mô hình hóa có được mở rộng đến bao nhiêu chăng nữa, nó

cũng không thể định nghĩa tất cả mọi việc. Nhằm tạo điều kiện bổ sung thêm cho một mô

hình những thông tin không thể được thể hiện bằng phần tử mô hình, UML cung cấp khả

năng kèm theo lời ghi chú. Một lời ghi chú có thể được để bất kỳ nơi nào trong bất kỳ biểu

đồ nào, và nó có thể chứa bất kỳ loại thông tin nào. Dạng thông tin của bản thân nó là chuỗi

ký tự (string), không được UML diễn giải. Lời ghi chú thường đi kèm theo một số các phần

tử mô hình trong biểu đồ, được nối bằng một đường chấm chấm, chỉ ra phần tử mô hình nào

được chi tiết hóa hoặc được giải thích (Hình 4.19).

Một lời ghi chú thường chứa lời nhận xét hoặc các câu hỏi của nhà tạo mô hình, ví dụ

lời nhắc nhở cần phải xử lý vấn đề nào đó trong thời gian sau này. Lời ghi chú cũng có thể

chứa các thông tin dạng khuôn mẫu (stereotype).

Hình 4.19. Một ví dụ về ghi chú

* Các cơ chế mở rộng (extensibility mechanisms)

UML cung cấp những thành phần cơ bản để lập nên một mô hình cho một phần

mềm. Nhưng nó không thể nào bao quát hết theo thời gian mọi mô hình trong mọi lĩnh vực.

Do đó UML được thiết kế mở theo nghĩa là người dùng có thể mở rộng một số thành phần

để có thể áp dụng một cách tốt nhất cho hệ thống của họ mà lại không phải thay đổi hay

thiết kế lại các thành phần cơ sở của UML. Cơ chế đó bao gồm:

Khuôn mẫu (Stereotypes): mở rộng tập từ vựng của UML, cho phép tạo những thành

phần mới kế thừa những đặc điểm của những thành phần đã có đồng thời chứa thêm những

đặc điểm riêng gắn với một bài toán cụ thể nào đó.

Các giá trị thẻ (Tagged values): mở rộng thuộc tính của các thành phần của UML, nó

cho phép ta tạo thêm những thông tin mới về một phần tử. Ví dụ như khi làm việc hợp tác

để tạo ra một sản phẩm, ta muốn chỉ ra các phiên bản và tác giả của một đối tượng nào đó.

Điều này không được xây dựng sẵn trong UML mà có thể thực hiện thông qua việc thêm

vào một giá trị thẻ.

Các ràng buộc (Constraints): mở rộng ngữ nghĩa của các thành phần của UML, cho

phép tạo ra những quy tắc mới hoặc sửa chữa những quy tắc đã có.

1. Khuôn mẫu (Stereotype)

Cơ chế mở rộng khuôn mẫu định nghĩa một loại phần tử mô hình mới dựa trên một

phần tử mô hình đã tồn tại. Khuôn mẫu có thể được coi là "tương tự" như một phần tử đã có

sẵn, cộng thêm phần quy định ngữ nghĩa (semantic) riêng biệt không có trong phần tử gốc

kia. Khuôn mẫu của một phần tử có thể được sử dụng trong cùng tình huống như phần tử

căn bản. Khuôn mẫu dựa trên tất cả các loại phần tử mô hình sẵn có - lớp, nút mạng, thành

phần, cũng như các mối quan hệ như liên kết, khái quát hóa, sự phụ thuộc. Ngôn ngữ UML

có chứa một số lượng lớn các khuôn mẫu được định nghĩa sẵn và chúng được sử dụng để

sửa đổi các phần tử mô hình sẵn có, thay cho việc phải định nghĩa hoàn toàn mới. Cơ chế

này giúp gìn giữ tính đơn giản của nền tảng ngôn ngữ UML.

Khuôn mẫu được mô tả qua việc đưa tên của chúng vào trong một cặp ký tự ngoặc

nhọn <<>>, theo như trong Hình 4.20. Ký tự ngoặc nhọn này được gọi là guillements.

Khuôn mẫu cũng có thể có kí hiệu hình học riêng. Một phần tử của một loại khuôn mẫu cụ

thể có thể được thể hiện bởi tên khuôn mẫu đi kèm ký hiệu hình học mô tả phần tử căn bản,

hay là sự kết hợp của cả hai yếu tố này. Bất kỳ khi nào một phần tử mô hình được nối kết

với một tên hoặc kí hiệu khuôn mẫu, ta sẽ đọc "đây là một loại phần tử thuộc loại khuôn

mẫu...". Ví dụ, một lớp với <<Window>> sẽ được gọi là "một lớp trong dạng khuôn mẫu

cửa sổ", ý nghĩa của nó là một dạng lớp cửa sổ. Những thuộc tính cụ thể mà một lớp cửa sổ

cần phải có sẽ được định nghĩa khi khuôn mẫu này được định nghĩa.

Như đã nói, khuôn mẫu là một cơ chế mở rộng xuất sắc, là một cơ chế ngăn cho ngôn

ngữ UML không trở nên quá phức tạp, mặc dù vẫn cho phép thực hiện sự mở rộng và sửa

đổi cần thiết. Đa phần các phần tử mô hình mới mà bạn cần đến đều có một khuôn mẫu nền

tảng trong ngôn ngữ UML. Một khuôn mẫu sau đó có thể được sử dụng để cộng thêm các

ngữ nghĩa cần thiết, nhằm mục đích định nghĩa nên các phần tử mô hình còn thiếu.

Hình 4.20. Customer là một lớp khuôn mẫu <<Actor>>

2. Giá trị đính kèm (Tagged Value)

Như đã nói, các phần tử mô hình có thể có các thuộc tính chứa một cặp tên-giá trị về

bản thân chúng (Hình 4.21). Các thuộc tính này cũng còn được gọi là các gía trị đính kèm.

UML có chứa một loạt các thuộc tính được định nghĩa trước, nhưng kể cả người sử dụng

cũng có thể định nghĩa ra các thuộc tính mới để chứa các thông tin bổ sung về các phần tử

mô hình. Mọi hình dạng thông tin đều có thể được đính kèm vào phần tử: các thông tin

chuyên biệt về phương pháp, các thông tin của nhà quản trị về tiến trình mô hình hóa, các

thông tin được sử dụng bởi các công cụ khác, ví dụ như các công cụ tạo code, hay bất kỳ

một loại thông tin nào mà người sử dụng muốn đính kèm vào phần tử mô hình.

Hình 4.21. Một ví dụ về Tagged Value

3. Hạn chế (Constraint)

Một sự hạn chế là một sự giới hạn về sự sử dụng hoặc ý nghĩa của một phần tử. Sự

hạn chế hoặc sẽ được khai báo trong công cụ và được sử dụng nhiều lần trong rất nhiều biểu

đồ khác nhau, hay được định nghĩa và sử dụng trong chỉ một biểu đồ, theo như nhu cầu.

Hình 4.22 chỉ ra mối quan hệ nối kết giữa nhóm các công dân lớn tuổi và lớp con

người, chỉ ra rằng nhóm công dân có thể có nhiều người liên quan. Mặc dù vậy, để mô tả

rằng chỉ những người nào lớn hơn 60 tuổi mới có thể tham gia vào nhóm này, người ta định

nghĩa một sự hạn chế, hạn hẹp tiêu chuẩn tham gia đối với chỉ những người nào mà thuộc

tính tuổi tác có giá trị lớn hơn 60. Định nghĩa này sẽ hạn chế số lượng những người được sử

dụng trong mối quan hệ. Nếu không có nó, người ta rất dễ hiểu lầm khi diễn tả biểu đồ.

Trong trường hợp tồi tệ, nó có thể dẫn đến sự thực thi sai trái của hệ thống.

Trong trường hợp này, hạn chế được định nghĩa và ứng dụng trực tiếp trong chính

biểu đồ mà nó được cần tới. Nhưng nhìn chung thì hạn chế cũng có thể được định nghĩa với

tên cùng lời đặc tả riêng, ví dụ như: "công dân già" và "người có tuổi lớn hơn 60", và hạn

chế này sẽ được sử dụng trong nhiều biểu đồ khác nhau. UML có chứa một loạt các hạn chế

được định nghĩa sẵn, chúng được mô tả chi tiết trong các chương sau.

Hình 4.22. Một ràng buộc hạn chế đối tượng Person góp phần vào quan hệ kết hợp

4.1.5. Các biểu đồ

Biểu đồ là các hình vẽ bao gồm các ký hiệu phần tử mô hình hóa được sắp xếp để

minh họa một thành phần cụ thể hay một khía cạnh cụ thể của hệ thống. Một mô hình hệ

thống thường có nhiều loại biểu đồ, mỗi loại có nhiều biểu đồ khác nhau. Một biểu đồ là

một thành phần của một khung nhìn cụ thể; và khi được vẽ ra, nó thường thường cũng được

xếp vào một khung nhìn. Mặt khác, một số loại biểu đồ có thể là thành phần của nhiều

khung nhìn khác nhau, tùy thuộc vào nội dung của biểu đồ.

Phần sau mô tả các khái niệm căn bản nằm đằng sau mỗi loại biểu đồ. Tất cả các chi

tiết về biểu đồ, ngữ cảnh của chúng, ý nghĩa chính xác của chúng và sự tương tác giữa

chúng với nhau được mô tả chi tiết trong các chương sau (mô hình đối tượng – mô hình

động). Các biểu đồ lấy làm ví dụ ở đây được lấy ra từ nhiều loại hệ thống khác nhau để chỉ

ra nét phong phú và khả năng áp dụng rộng khắp của UML.

Có 9 loại biểu đồ được sử dụng trong UML như được thể hiện trong Hình 4.23.

Hình 4.23. Các biểu đồ trong UML

a. Biểu đồ ca sử dụng (Ca sử dụng Diagram)

Biểu đồ ca sử dụng để mô hình hoá các khía cạnh động của hệ thống. Nó là trung tâm

để mô hình hoá hành vi của hệ thống, một hệ thống con, một lớp. Mỗi biểu đồ chỉ ra một tập

các ca sử dụng, các tác nhân và các mối quan hệ giữa chúng.

Biểu đồ

ca sử dụng

Biểu đồ

cộng tác

Biểu đồ

thành phần

Biểu đồ

triển khai

Biểu đồ

đối tượng

Biểu đồ

trạng thái

Biểu độ

tuần tự

Biểu đồ lớp

Biểu đồ

hoạt động

Các

mô

hình

Mô hình hóa phần

động

Mô hình hóa phần

tĩnh

Biểu đồ ca sử dụng mô tả cách nhìn từ bên ngoài để thấy được bối cảnh mà trong đó

hệ thống đang tồn tại và những mối quan hệ giữa nó và môi trường, mô tả hoạt động của hệ

thống từ bên ngoài không lệ thuộc vào việc nó thực hiện các hoạt động đó như thế nào. Vì

vậy, mô hình ca sử dụng là phương tiện để mô tả các yêu cầu của hệ thống. Ta sử dụng biểu

đồ ca sử dụng để:Mô hình hoá ngữ cảnh của hệ thống và Mô hình hoá các yêu cầu của một

hệ thống.

Hình 4.24. Biểu đồ ca sử dụng

b. Biểu đồ lớp (Class Diagram)

Một biểu đồ lớp chỉ ra cấu trúc tĩnh của các lớp trong hệ thống (nhìn Hình 4.25). Các

lớp là đại diện cho các “vật” được xử lý trong hệ thống. Các lớp có thể quan hệ với nhau

trong nhiều dạng thức: liên kết (associated - được nối kết với nhau), phụ thuộc (dependent -

một lớp này phụ thuộc vào lớp khác), chuyên biệt hóa (specialized - một lớp này là một kết

quả chuyên biệt hóa của lớp khác), hay đóng gói ( packaged - hợp với nhau thành một đơn

vị). Tất cả các mối quan hệ đó đều được thể hiện trong biểu đồ lớp, đi kèm với cấu trúc bên

trong của các lớp theo khái niệm thuộc tính (attribute) và thủ tục (operation). Biểu đồ được

coi là biểu đồ tĩnh theo phương diện cấu trúc được mô tả ở đây có hiệu lực tại bất kỳ thời

điểm nào trong toàn bộ vòng đời hệ thống.

Một hệ thống thường sẽ có một loạt các biểu đồ lớp – chẳng phải bao giờ tất cả các

biểu đồ lớp này cũng được nhập vào một biểu đồ lớp tổng thể duy nhất – và một lớp có thể

tham gia vào nhiều biểu đồ lớp

Hình 4.25. Biểu đồ lớp

c. Biểu đồ triển khai (Deployment Diagram)

Biểu đồ triển khai chỉ ra kiến trúc vật lý của phần cứng cũng như phần mềm trong hệ

thống. Bạn có thể chỉ ra từng máy tính cụ thể và từng trang thiết bị cụ thể (node) đi kèm sự

nối kết giữa chúng với nhau, bạn cũng có thể chỉ ra loại của các mối nối kết đó. Bên trong

các nút mạng (node), các thành phần thực thi được cũng như các đối tượng sẽ được xác định

vị trí để chỉ ra những phần mềm nào sẽ được thực thi tại những nút mạng nào. Bạn cũng có

thể chỉ ra sự phụ thuộc giữa các thành phần.

Biểu đồ triển khai chỉ ra khung nhìn triển khai, mô tả kiến trúc vật lý thật sự của hệ

thống. Đây là một khung nhìn rất xa lối mô tả duy chức năng của khung nhìn ca sử dụng.

Mặc dù vậy, trong một mô hình tốt, người ta có thể chỉ tất cả những con đường dẫn từ một

nút mạng trong một kiến trúc vật lý cho tới những thành phần của nó, cho tới lớp mà nó

thực thi, cho tới những tương tác mà các đối tượng của lớp này tham gia để rồi cuối cùng,

tiến tới một ca sử dụng. Rất nhiều khung nhìn khác nhau của hệ thống được sử dụng đồng

thời để tạo ra một lời mô tả thấu đáo đối với hệ thống trong sự tổng thể của nó.

Hình 4.26. Biểu đồ triển khai

d. Biểu đồ đối tượng (Object Diagram)

Một biểu đồ đối tượng là một phiên bản của biểu đồ lớp và thường cũng sử dụng các

ký hiệu như biểu đồ lớp. Sự khác biệt giữa hai loại biểu đồ này nằm ở chỗ biểu đồ đối tượng

chỉ ra một loạt các đối tượng thực thể của lớp, thay vì các lớp. Một biểu đồ đối tượng vì vậy

là một ví dụ của biểu đồ lớp, chỉ ra một bức tranh thực tế có thể xảy ra khi hệ thống thực thi:

bức tranh mà hệ thống có thể có tại một thời điểm nào đó. Biểu đồ đối tượng sử dụng chung

các ký hiệu của biểu đồ lớp, chỉ trừ hai ngoại lệ: đối tượng được viết với tên được gạch dưới

và tất cả các thực thể trong một mối quan hệ đều được chỉ ra (nhìn Hình 4.27).

Biểu đồ đối tượng không quan trọng bằng biểu đồ lớp, chúng có thể được sử dụng để

ví dụ hóa một biểu đồ lớp phức tạp, chỉ ra với những thực thể cụ thể và những mối quan hệ

như thế thì bức tranh toàn cảnh sẽ ra sao. Một biểu đồ đối tượng thường thường được sử

dụng làm một thành phần của một biểu đồ cộng tác (collaboration), chỉ ra lối ứng xử động

giữa một loạt các đối tượng.

Hình 4.27. Biểu đồ đối tượng

e. Biểu đồ thành phần (Component Diagram)

Một biểu đồ thành phần chỉ ra cấu trúc vật lý của các dòng lệnh (code) theo khái

niệm thành phần code. Một thành phần code có thể là một tập tin source code, một thành

phần nhị phân (binary) hay một thành phần thực thi được (executable). Một thành phần

chứa các thông tin về các lớp logic hoặc các lớp mà nó thi hành, như thế có nghĩa là nó tạo

ra một ánh xạ từ khung nhìn logic vào khung nhìn thành phần. Biểu đồ thành phần cũng chỉ

ra những sự phụ thuộc giữa các thành phần với nhau, trợ giúp cho công việc phân tích hiệu

ứng mà một thành phần được thay đổi sẽ gây ra đối với các thành phần khác. Thành phần

cũng có thể được mô tả với bất kỳ loại giao diện nào mà chúng bộc lộ, ví dụ như giao diện

OLE/COM; và chúng có thể được nhóm góp lại với nhau thành từng gói (package). Biểu đồ

thành phần được sử dụng trong công việc lập trình cụ thể (xem Hình 4.28).

Hình 4.28. Biểu đồ thành phần

f. Biểu đồ sơ đồ trạng thái (Statechart Diagram)

Một biểu đồ trạng thái thường là một sự bổ sung cho lời mô tả một lớp. Nó chỉ ra tất

cả các trạng thái mà đối tượng của lớp này có thể có, và những sự kiện (event) nào sẽ gây ra

sự thay đổi trạng thái (Hình 4.29). Một sự kiện có thể xảy ra khi một đối tượng tự gửi thông

điệp đến cho nó - ví dụ như để thông báo rằng một khoảng thời gian được xác định đã qua

đi – hay là một số điều kiện nào đó đã được thỏa mãn. Một sự thay đổi trạng thái được gọi

là một sự (State Transition). Một chuyển đổi trạng thái cũng có thể cóchuyển đổi trạng thái

một hành động liên quan, xác định điều gì phải được thực hiện khi sự chuyển đổi trạng thái

này diễn ra. Biểu đồ trạng thái không được vẽ cho tất cả các lớp, mà chỉ riêng cho những

lớp có một số lượng các trạng thái được định nghĩa rõ ràng và hành vi của lớp bị ảnh hưởng

và thay đổi qua các trạng thái khác nhau. Biểu đồ trạng thái cũng có thể được vẽ cho hệ

thống tổng thể (Mô hình động).

Hình 4.29. Biểu đồ trạng thái

g. Biểu đồ hoạt động (Activity Diagram)

Một biểu đồ hoạt động chỉ ra một trình tự lần lượt của các hoạt động (activity) (Hình

4.30). Biểu đồ hoạt động thường được sử dụng để mô tả các hoạt động được thực hiện trong

một thủ tục, mặc dù nó cũng có thể được sử dụng để mô tả các dòng chảy hoạt động khác, ví

dụ như trong một Ca sử dụng hay trong một trình tự tương tác. Biểu đồ hoạt động bao gồm

các trạng thái hành động, chứa đặc tả của một hoạt động cần phải được thực hiện (một hành

động - action). Một trạng thái hành động sẽ qua đi khi hành động được thực hiện xong (khác

với biểu đồ trạng thái: một trạng thái chỉ chuyển sang trạng thái khác sau khi đã xảy ra một

sự kiện rõ ràng !). Dòng điều khiển ở đây chạy giữa các trạng thái hành động liên kết với

nhau. Biểu đồ còn có thể chỉ ra các quyết định, các điều kiện, cũng như phần thực thi song

song của các trạng thái hành động. Biểu đồ ngoài ra còn có thể chứa các loại đặc tả cho các

thông điệp được gửi đi hoặc được nhận về, trong tư cách là thành phần của hành động được

thực hiện.

Hình 4.30. Biểu đồ hoạt động cho một printer server

h. Biểu đồ trình tự (Sequence Diagram)

Một biểu đồ trình tự chỉ ra một cộng tác động giữa một loạt các đối tượng (xem Hình

4.31). Khía cạnh quan trọng của biểu đồ này là chỉ ra trình tự các thông điệp (message)

được gửi giữa các đối tượng. Nó cũng chỉ ra trình tự tương tác giữa các đối tượng, điều sẽ

xảy ra tại một thời điểm cụ thể nào đó trong trình tự thực thi của hệ thống. Các biểu đồ trình

tự chứa một loạt các đối tượng được biểu diễn bằng các đường thẳng đứng. Trục thời gian

có khung từ trên xuống dưới trong biểu đồ, và biểu đồ chỉ ra sự trao đổi thông điệp giữa các

đối tượng khi thời gian trôi qua. Các thông điệp được biểu diễn bằng các đường gạch ngang

gắn liền với mũi tên (biểu thị thông điệp) nối liền giữa những đường thẳng đứng thể hiện

đối tượng. Trục thời gian cùng những lời nhận xét khác thường sẽ được đưa vào phần lề của

biểu đồ.

Hình 4.31. Biểu đồ trình tự

i. Biểu đồ cộng tác (Collaboration Diagram)

Một biểu đồ cộng tác chỉ ra một sự cộng tác động, cũng giống như một biểu đồ trình

tự. Thường người ta sẽ chọn hoặc dùng biểu đồ trình tự hoặc dùng biểu đồ cộng tác. Bên

cạnh việc thể hiện sự trao đổi thông điệp (được gọi là ), biểu đồ cộng tác chỉ ra cáctương tác

đối tượng và quan hệ của chúng (nhiều khi được gọi là ngữ cảnh). Việc nên sử dụng biểu đồ

trình tự hay biểu đồ cộng tác thường sẽ được quyết định theo nguyên tắc chung sau: Nếu

thời gian hay trình tự là yếu tố quan trọng nhất cần phải nhấn mạnh thì hãy chọn biểu đồ

trình tự; nếu ngữ cảnh là yếu tố quan trọng hơn, hãy chọn biểu đồ cộng tác. Trình tự tương

tác giữa các đối tượng được thể hiện trong cả hai loại biểu đồ này.

Biểu đồ cộng tác được vẽ theo dạng một biểu đồ đối tượng, nơi một loạt các đối

tượng được chỉ ra cùng với mối quan hệ giữa chúng với nhau (sử dụng những ký hiệu như

trong biểu đồ lớp/ biểu đồ đối tượng). Các mũi tên được vẽ giữa các đối tượng để chỉ ra

dòng chảy thông điệp giữa các đối tượng. Các thông điệp thường được đính kèm theo các

nhãn (label), một trong những chức năng của nhãn là chỉ ra thứ tự mà các thông điệp được

gửi đi. Nó cũng có thể chỉ ra các điều kiện, chỉ ra những giá trị được trả về, v.v... Khi đã làm

quen với cách viết nhãn, một nhà phát triển có thể đọc biểu đồ cộng tác và tuân thủ theo

dòng thực thi cũng như sự trao đổi thông điệp. Một biểu đồ cộng tác cũng có thể chứa cả các

đối tượng tích cực (active objects), hoạt động song song với các đối tượng tích cực khác

(Hình 4.32).

Hình 4.32. Một biểu đồ cộng tác của một printer server

Mặc dù chín biểu đồ trên đã vượt xa nhu cầu chung nhất mà ta thường gặp trong thực

tế phát triển phần mềm khung đối tượng. Tuy nhiên, UML còn cung cấp những loại biểu đồ

khác cho phép mô hình hóa những trường hợp kinh tế hơn

4.1.6. Rational Rose

a. Giới thiệu

Rational Rose là một công cụ lập mô hình trực quan mạnh trợ giúp bạn phân tích và

thiết kế các hệ thống phần mềm hướng đối tượng. Nó được dùng để lập mô hình hệ thống

trước khi bạn viết mã (code). Dùng mô hình, bạn có thể bắt kịp những thiếu sót về thiết kế,

trong khi việc chỉnh sửa chúng vẫn chưa tốn kém.

Mô hình Rose là bức tranh về một hệ thống từ nhiều góc nhìn khác nhau. Nó bao

gồm tất cả các sơ đồ UML, các actor, các use case, các đối tượng, các lớp, các thành phần…

Nó mô tả chi tiết nội dung mà hệ thống sẽ gộp và cách nó sẽ làm việc.

Có thể xem một mô hình Rose tương tự như bản thiết kế mẫu. Giống như một căn

nhà có nhiều bản thiết kế mẫu cho phép các thành viên trong đội xây dựng xem xét nó từ

nhiều góc nhìn khác nhau như: hệ thống ống nước, hệ thống điện, hệ thống nền… Một mô

hình Rose chứa đựng các sơ đồ khác nhau cho phép các thành viên trong nhóm đề án xem

hệ thống từ các góc nhìn khác nhau như : khách hàng, nhà thiết kế, quản trị đề án, …

Khi đã có được bản thiết kế thì sẽ giảm bớt một số vấn đề phiền phức như: lập trình

theo truyền thống thì khi hoàn tất đề án, sau một thời gian sử dụng khách hàng yêu cầu thêm

một vài chức năng nào đó vì có cập nhật mới thì người lập trình phải xem lại toàn bộ hệ

thống rồi sau đó mới cập nhật. Điều này tốn rất nhiều thời gian. Nay nhờ có bản thiết kế thì

chỉ cần xem cập nhật đó nằm ở phần nào và chỉnh sửa, nâng cấp hệ thống. Điều đó sẽ linh

hoạt và giảm rất nhiều thời gian…

Có ba phiên bản khác nhau của Rose :

Rose Modeler: cho phép bạn tạo mô hình cho hệ thống, nhưng không hỗ trợ tiến trình

phát sinh mã hoặc thiết kế kỹ thuật đảo ngược.

Rose Professional: cho phép bạn phát sinh mã trong một ngôn ngữ

Rose Enterprise: cho phép bạn phát sinh mã cho C++, Java, Ada, Corba, Visual

Basic, Oracle… Một mô hình có thể có các thành phần được phát sinh bằng các ngôn ngữ

khác nhau.

b. Giao diện và cách làm việc

Giao diện chính của chương trình

Hình 4.33 – Giao diện chính của chương trình

Làm việc với Rational Rose

* Tạo các mô hình

- Bước đầu tiên khi làm việc với Rose đó là tạo một mô hình. Các mô hình có thể

được tạo từ đầu hoặc sử dụng một framework model hiện có (là các mô hình cài đặt sẵn

trong máy cho một số ngôn ngữ như Visual Basic, Java, C++, …). Mô hình Rose và tất

cả các sơ đồ, các đối tượng, các phần tử mô hình khác được lưu trong một tập tin đơn lẻ có

đuôi .mdl

- Để tạo một mô hình:

Chọn -> từ trình đơn, hoặc nhấn nút trên thanh công cụ chuẩn.File New

Nếu đã cài đặt Framework Wizard, danh sách các cơ cấu sẵn có sẽ xuất hiện (như

hình dưới đây). Lựa chọn cơ cấu rồi nhắp nút , hoặc nếu không dùng.OK Cancel

Hình 4.34. Giao diện của Rational Rose

* Lưu các mô hình

- Giống như các ứng dụng khác, bạn nên tạo thói quen lưu tập tin định kỳ, Rose

cũng vậy. Như đã nêu trên, nguyên cả mô hình được lưu trong một tập tin. Ngoài ra, bạn có

thể lưu sổ theo dõi (Log Window) ra một tập tin.

- Để lưu một mô hình :

+ Chọn File -> Save từ thanh trình đơn

+ Hoặc nhấn nút trên thanh công cụ chuẩn.

- Để lưu sổ theo dõi :

+ Lựa chọn cửa sổ theo dõi.

+ Chọn File -> Save Log As từ thanh trình đơn.

+ Nhập tên tập tin cửa sổ theo dõi. Hoặc :

+ Lựa chọn cửa sổ theo dõi.

+ Nhấn nút trên thanh công cụ chuẩn.

+ Nhập tên tập tin cửa sổ theo dõi.

* Xuất và nhập các mô hình :

Một trong những lợi ích chính của hướng đối tượng là khả năng dùng lại. Khả

năng dùng lại có thể áp dụng không những cho mã mà còn cho các mô hình. Để vận dụng

đầy đủ khả năng dùng lại, hỗ trợ phương pháp xuất (nhập) các mô hình và các phầnRose

tử của mô hình. Bạn có thể xuất một mô hình hoặc một phần của mô hình và nhập nó vào

các mô hình khác

4.2. Mô hình hóa ca sử dụng

4.2.1. Giới thiệu

Trong giai đoạn phân tích, người sử dụng cộng tác cùng nhóm phát triển phần mềm

tạo nên một tổ hợp thông tin quan trọng về yêu cầu đối với hệ thống. Không chỉ là người

cung cấp thông tin, bản thân người sử dụng còn là một thành phần hết sức quan trọng trong

bức tranh toàn cảnh đó và nhóm phát triển cần phải chỉ ra được phương thức hoạt động của

hệ thống tương lai theo khung nhìn của người sử dụng. Hiểu được điểm quan trọng này là

chìa khóa để tạo dựng được những hệ thống vừa thoả mãn các yêu cầu đặt ra vừa dễ dàng sử

dụng, thậm chí tạo niềm vui thích trong sử dụng.

Như vậy công cụ giúp ta mô hình hoá hệ thống từ khung nhìn của người sử dụng gọi

là Ca sử dụng. Và để trả lời rõ hơn về Ca sử dụng ta xét một trường hợp sau:

Giả sử tôi quyết định mua một chiếc máy fax mới. Khi đến cửa hàng máy văn phòng,

tôi mới nhận ra là phải chọn lựa trong một danh sách máy móc rất phong phú. Loại máy nào

sẽ được chọn đây? Tôi tự hỏi thật chính xác mình muốn làm gì với chiếc máy fax sẽ mua?

Tôi muốn có những tính năng nào? Tôi muốn dùng bằng giấy thường hay giấy thermal? Tôi

muốn copy bằng cái máy đó? Tôi muốn nối nó với máy tính của mình? Tôi muốn dùng nó

vừa làm máy fax vừa làm scanner? Tôi có cần phải gởi fax thật nhanh đến mức độ cần một

chức năng chọn số tăng tốc? Liệu tôi có muốn sử dụng máy fax này để phân biệt giữa một

cú điện thoại gọi tới và một bản fax gởi tới …?

Tất cả chúng ta đều trải qua những kinh nghiệm như vậy khi quyết định mua một

món hàng nào đó không phải vì niềm vui bộc phát. Việc chúng ta sẽ làm trong những

trường hợp như vậy là một dạng phân tích ca sử dụng: Chúng ta tự hỏi mình sẽ sử dụng sản

phẩm (hay hệ thống) sắp bắt ta bỏ ra một khoản tiền đáng kể đó ra sao? Trả lời xong câu hỏi

trên ta mới có khả năng chọn ra sản phẩm thoả mãn những đòi hỏi của mình. Điều quan

trọng ở đây là phải biết những đòi hỏi đó là gì.

Loại quy trình này đóng vai trò rất quan trọng đối với giai đoạn phân tích của một

nhóm phát triển hệ thống. Người dùng muốn sử dụng hệ thống tương lai, hệ thống mà bạn

sắp thiết kế và xây dựng, như thế nào?

Ca sử dụng là một công cụ trợ giúp cho công việc của nhà phân tích cùng người sử

dụng quyết định tính năng của hệ thống. Một tập hợp các ca sử dụng sẽ làm nổi bật một hệ

thống theo phương diện những người dùng định làm gì với hệ thống này.

Để làm rõ hơn, ta hãy xét một ví dụ nhà băng lẻ. Hệ thống tương lai trong trường hợp

này sẽ só nhiều người sử dụng, mỗi người sẽ giao tiếp với hệ thống cho một mục đích khác

biệt:

 Quản trị gia sử dụng hệ thống cho mục đích thống kê

 Nhân viên tiếp khách sử dụng hệ thống để thực hiện các dịch vụ phục vụ khách

hàng.

 Nhân viên phòng đầu tư sử dụng hệ thống để thực hiện các giao dịch liên quan

đến đầu tư.

 Nhân viên thẩm tra chữ ký sử dụng hệ thống cho mục đích xác nhận chữ ký và

bảo trì thông tin liên quan đến khách hàng.

 Khách hàng giao tiếp với hệ thống (nhà băng) cho các hoạt động sử dụng dịch vụ

như mở tài khoản, gửi tiền vào, rút tiền mặt, …

Quá trình tương tác giữa người sử dụng và hệ thống trong mỗi một tình huống kể trên

sẽ khác nhau và phụ thuộc vào chức năng mà người sử dụng muốn thực thi cùng hệ thống.

Nhóm phát triển hệ thống cần phải xây dựng nên một kịch bản nêu bật sự tương tác

cần thiết giữa người sử dụng và hệ thống trong mỗi khả năng hoạt động. Ví dụ như kịch bản

cho sự tương tác giữa nhân viên thu ngân và hệ thống của bộ phận tiết kiệm trong suốt tiến

trình của một giao dịch. Một kịch bản khác ví dụ là chuỗi tương tác xảy ra giữa bộ phận tiết

kiệm và bộ phận đầu tư trong một giao dịch chuyển tiền.

Nhìn chung, có thể coi một ca sử dụng như là tập hợp của một loạt các cảnh kịch

(scenario) về việc sử dụng hệ thống. Mỗi cảnh kịch mô tả một chuỗi các sự kiện. Mỗi một

chuỗi này sẽ được kích hoạt bởi một người nào đó, một hệ thống khác hay là một phần trang

thiết bị nào đó, hoặc là một chuỗi thời gian. Những thực thể kích hoạt nên các chuỗi sự kiện

như thế được gọi là các tác nhân (Actor). Kết quả của chuỗi này phải có giá trị sử dụng đối

với hoặc là tác nhân đã gây nên nó hoặc là một tác nhân khác.

Trong ví dụ nhà băng lẻ ở trên, một số những ca sử dụng dễ thấy nhất là:

 Một khách hàng mở một tài khoản mới.

 Phòng đầu tư tính toán tiền lãi cho các tài khoản đầu tư.

 Một chương trình đầu tư mới được đưa vào áp dụng.

 Yêu cầu chuyển tiền của khách hàng được thực hiện.

 Chuyển tiền theo kỳ hạn từ một tài khoản đầu tư sang một tài khoản tiết kiệm.

Ca sử dụng là một công cụ xuất sắc để khuyến khích những người dùng tiềm năng

nói về hệ thống từ khung nhìn của họ. Đối với người dùng, chẳng phải bao giờ việc thể hiện

và mô tả những ý định trong việc sử dụng hệ thống cũng là chuyện dễ dàng. Một hiện thực

có thật là người sử dụng thường biết nhiều hơn những gì mà họ có thể diễn tả ra: Công cụ ca

sử dụng sẽ giúp cho nhóm phát triển bẻ gãy "lớp băng" đó, ngoài ra một sự trình bày trực

quan cũng cho phép bạn kết hợp các biểu đồ ca sử dụng với các loại biểu đồ khác.

Sáng kiến chủ đạo là lôi cuốn được người dùng tham gia vào những giai đoạn đầu

tiên của quá trình phân tích và thiết kế hệ thống. Việc này sẽ nâng cao xác suất cho việc hệ

thống chung cuộc trở thành một công cụ quen thuộc đối với các người dùng mà nó dự định

sẽ trợ giúp – thay vì là một tập hợp khó hiểu và rối rắm của các khái niệm máy tính mà

người dùng trong giới doanh thương có cảm giác không bao giờ hiểu được và không thể làm

việc cùng.

Công tác lôi kéo người sử dụng tham gia tích cực vào quá trình phân tích là nền tảng

quan trọng cho việc tạo dựng một mô hình "thành công", một mô hình dễ được người sử

dụng hiểu và chấp nhận sau khi đã thẩm xác các nhiệm vụ căn bản. Ngoài ra, ca sử dụng

còn giúp nhóm phát triển quyết định các lớp mà hệ thống phải triển khai.

4.2.2. Mô hình hóa ca sử dụng

Ca sử dụng là một kỹ thuật mô hình hóa được sử dụng để mô tả một hệ thống mới sẽ

phải làm gì hoặc một hệ thống đang tồn tại làm gì. Một mô hình ca sử dụng được xây dựng

qua một quá trình mang tính vòng lặp (interative), trong đó những cuộc hội thảo bàn luận

giữa nhóm phát triển hệ thống và khách hàng (hoặc/và người sử dụng cuối) sẽ dẫn tới một

đặc tả yêu cầu được tất cả mọi người chấp nhận. Người cha tinh thần của mô hình hóa ca sử

dụng là Ivar Jacobson, ông đã tạo nên kỹ thuật mô hình hóa dựa trên những kinh nghiệm thu

thập được trong quá trình tạo hệ thống AXE của hãng Ericsson. Ca sử dụng đã nhận được

một sự quan tâm đặc biệt lớn lao từ phía cộng đồng khung đối tượng và đã tác động lên rất

nhiều phương pháp khung đối tượng khác nhau.

Những thành phần quan trọng nhất của một mô hình ca sử dụng là ca sử dụng, tác

nhân và hệ thống. Ranh giới của hệ thống được định nghĩa qua chức năng tổng thể mà hệ

thống sẽ thực thi. Chức năng tổng thể được thể hiện qua một loạt các ca sử dụng và mỗi một

ca sử dụng đặc tả một chức năng trọn vẹn, có nghĩa là ca sử dụng phải thực thi toàn bộ chức

năng đó, từ sự kiện được kích hoạt đầu tiên bởi một tác nhân ngoại cảnh cho tới khi chức

năng đòi hỏi được thực hiện hoàn tất. Một ca sử dụng luôn luôn phải cung cấp một giá trị

nào đó cho một tác nhân, giá trị này là những gì mà tác nhân mong muốn từ phía hệ thống.

Tác nhân là bất kỳ một thực thể ngoại cảnh nào mong muốn tương tác với hệ thống. Thường

thường, đó là một người sử dụng của hệ thống, nhưng nhiều khi cũng có thể là một hệ thống

khác hoặc là một dạng máy móc thiết bị phần cứng nào đó cần tương tác với hệ thống.

Trong kỹ thuật mô hình hóa ca sử dụng, hệ thống sẽ có hình dạng của một "hộp đen"

và cung cấp các ca sử dụng. Hệ thống làm điều đó như thế nào, các ca sử dụng được thực thi

ra sao, đó là những khía cạnh chưa được đề cập tới trong giai đoạn này. Trong thực tế, nếu

mô hình hóa ca sử dụng được thực hiện trong những giai đoạn đầu của dự án thì thường nhà

phát triển sẽ không biết ca sử dụng sau này sẽ được thực thi (tức là biến thành những dòng

code thật sự) như thế nào.

Mục tiêu chính yếu đối với các ca sử dụng là:

 Để quyết định và mô tả các yêu cầu về mặt chức năng của hệ thống, đây là kết

quả rút ra từ sự thỏa thuận giữa khách hàng (và/hoặc người sử dụng cuối) và

nhóm phát triển phần mềm.

 Để tạo nên một lời mô tả rõ ràng và nhất quán về việc hệ thống cần phải làm gì,

làm sao để mô hình có thể được sử dụng nhất quán suốt toàn bộ quá trình phát

triển, được sử dụng làm công cụ giao tiếp cho tất cả những người phát triển nên

các yêu cầu này, và để tạo nên một nền tảng cho việc tạo nên các mô hình thiết kế

cung cấp các chức năng được yêu cầu.

 Để tạo nên một nền tảng cho các bước thử nghiệm hệ thống, đảm bảo hệ thống

thỏa mãn đúng những yêu cầu do người sử dụng đưa ra. Trong thực tế thường là

để trả lời câu hỏi: Liệu hệ thống cuối cùng có thực hiện những chức năng mà khởi

đầu khách hàng đã đề nghị?

 Để cung cấp khả năng theo dõi các yêu cầu về mặt chức năng được chuyển thành

các lớp cụ thể cũng như các thủ tục cụ thể trong hệ thống.

100

 Để đơn giản hóa việc thay đổi và mở rộng hệ thống qua việc thay đổi và mở rộng

mô hình ca sử dụng, sau đó chỉ theo dõi riêng những ca sử dụng đã bị thay đổi

cùng những hiệu ứng của chúng trong thiết kế hệ thống và xây dựng hệ thống.

Những công việc cụ thể cần thiết để tạo nên một mô hình ca sử dụng bao gồm:

1. Định nghĩa hệ thống (xác định phạm vi hệ thống)

2. Tìm ra các tác nhân cũng như các ca sử dụng

3. Mô tả ca sử dụng

4. Định nghĩa mối quan hệ giữa các ca sử dụng

5. Kiểm tra và phê chuẩn mô hình.

Đây là một công việc mang tính tương tác rất cao, bao gồm những cuộc thảo luận với

khách hàng và những người đại diện cho các loại tác nhân. Mô hình ca sử dụng bao gồm các

biểu đồ ca sử dụng chỉ ra các tác nhân, ca sử dụng và mối quan hệ của chúng với nhau. Các

biểu đồ này cho ta một cái nhìn tổng thể về mô hình, nhưng những lời mô tả thực sự của

từng ca sử dụng thường lại là văn bản. Vì các mô hình trực quan không thể cung cấp tất cả

các thông tin cần thiết, nên cần thiết phải dùng cả hai kỹ thuật trình bày đó.

Có rất nhiều người quan tâm đến việc sử dụng các mô hình ca sử dụng. Khách hàng

(và/hoặc người sử dụng cuối) quan tâm đến chúng vì mô hình ca sử dụng đặc tả chức năng

của hệ thống và mô tả xem hệ thống có thể và sẽ được sử dụng ra sao. Các Ca sử dụng vì

vậy phải được mô tả trong những thuật ngữ và ngôn ngữ của khách hàng/người sử dụng.

Nhà phát triển cần đến các mô hình ca sử dụng để hiểu hệ thống cần phải làm gì, và

qua đó có được một nền tảng cho những công việc tương lai (các mô hình khác, các cấu trúc

thiết kế và việc thực thi xây dựng hệ thống bằng code).

Các nhóm chuyên gia thử nghiệm tích hợp và thử nghiệm hệ thống cần đến ca sử

dụng để thử nghiệm và kiểm tra xem hệ thống có đảm bảo sẽ thực hiện đúng chức năng đã

được đặc tả trong giai đoạn đầu.

Và cuối cùng, bất kỳ người nào liên quan đến những hoạt động liên kết đến chức

năng của hệ thống đều có thể quan tâm đến các mô hình ca sử dụng; ví dụ như các nhóm

tiếp thị, bán hàng, hỗ trợ khách hàng và các nhóm soạn thảo tài liệu.

Mô hình ca sử dụng mô tả khung nhìn ca sử dụng của hệ thống. Khung nhìn này là

rất quan trọng, bởi nó ảnh hưởng đến tất cả các khung nhìn khác của hệ thống. Cả cấu trúc

logic lẫn cấu trúc physic đều chịu ảnh hưởng từ các ca sử dụng, bởi chức năng được đặc tả

trong mô hình này chính là những chức năng được thực thi trong các cấu trúc kia. Mục đích

cuối cùng là thiết kế ra một giải pháp thỏa mãn các yêu cầu đó.

Mô hình hóa các ca sử dụng chẳng phải chỉ được dùng để nắm bắt các yêu cầu của hệ

thống mới; nó cũng còn được sử dụng để hỗ trợ cho việc phát triển một phiên bản mới của

hệ thống. Khi phát triển một phiên bản mới của hệ thống đang tồn tại, người ta sẽ bổ sung

thêm các chức năng mới vào mô hình ca sử dụng đã có bằng cách thêm vào các tác nhân

mới cũng như các ca sử dụng mới, hoặc là thay đổi đặc tả của các ca sử dụng đã có. Khi bổ

101

sung thêm vào mô hình ca sử dụng đang tồn tại, hãy chú ý để không bỏ ra bất kỳ một chức

năng nào vẫn còn được cần tới.

4.2.3. Biểu đồ ca sử dụng

Ca sử dụng được mô tả trong ngôn ngữ UML qua biểu đồ ca sử dụng và một mô hình

ca sử dụng có thể được chia thành một số lượng lớn các biểu đồ như thế. Một biểu đồ ca sử

dụng chứa các phần tử mô hình biểu thị hệ thống, tác nhân cũng như ca sử dụng và chỉ ra

các mối quan hệ giữa các ca sử dụng.

Lời mô tả nội dung ca sử dụng thường được cung cấp dưới dạng văn bản. Trong

UML, lời mô tả đó được coi là thuộc tính "văn bản" (document) của ca sử dụng. Lời mô tả

này bao chứa những thông tin quan trọng, định nghĩa các yêu cầu và chức năng cụ thể. Thay

cho việc mô tả ca sử dụng bằng văn bản, bạn cũng có thể vẽ một biểu đồ hoạt động (activity

diagram). Mặc dầu vậy, nên nhớ rằng một ca sử dụng cần phải được mô tả sao cho dễ hiểu

và dễ giao tiếp đối với người sử dụng, mà những cấu trúc phức tạp như một biểu đồ hoạt

động có thể gây cảm giác xa lạ đối với những người không quen sử dụng.

Tóm tắt: Một biểu đồ ca sử dụng thể hiện:

 Hệ thống

 Tác nhân và

 Ca sử dụng.

Ví dụ biểu đồ ca sử dụng trong UML:

Hình 4.35 - Một ví dụ biểu đồ ca sử dụng trong UML

Trong đó :

 Hệ thống được thể hiện qua hình chữ nhật với tên hệ thống ở bên trên

 Tác nhân được thể hiện qua kí hiệu hình nhân

 Ca sử dụng được thể hiện qua hình ellipse

a. Hệ thống

Vì hệ thống là một thành phần của mô hình ca sử dụng nên ranh giới của hệ thống

mà ta muốn phát triển cần phải được định nghĩa rõ ràng. Xin nhớ rằng một hệ thống không

phải bao giờ cũng nhất thiết là một hệ thống phần mềm; nó có thể là một chiếc máy, hoặc là

một doanh nghiệp. Định nghĩa các ranh giới và trách nhiệm của hệ thống không phải bao

giờ cũng là việc dễ dàng, bởi không phải bao giờ người ta cũng rõ ràng nhìn ra tác vụ nào có

khả năng được tự động hóa tốt nhất ở hệ thống này và tác vụ nào thì tốt nhất nên thực hiện

thủ công hoặc dành cho các hệ thống khác. Một khía cạnh khác cần chú ý là hệ thống cần

phải lớn tới mức độ nào trong phiên bản đầu tiên của nó. Cố gắng tối đa cho phiên bản đầu

102

tiên của hệ thống thường là cách mà người ta hay thực hiện, thế nhưng những mục tiêu quá

tầm như vậy có thể khiến cho hệ thống trở nên quá lớn và thời gian để cung cấp hệ thống

quá lâu. Một sáng kiến tốt hơn là xác nhận cho rõ các chức năng căn bản và tập trung vào

việc định nghĩa một kiến trúc hệ thống thích hợp, rõ ràng, có nền tảng rộng mở để nhiều

chức năng hơn có thể được bổ sung vào hệ thống này trong các phiên bản sau.

Yếu tố quan trọng là bạn phải tạo dựng được một bản catalog của các khái niệm (các

thực thể) trung tâm cùng với các thuật ngữ và định nghĩa thích hợp trong những giai đoạn

đầu của thời kỳ phân tích. Đây chưa phải mô hình phạm vi đối tượng, mà đúng hơn là một

cố gắng để mô tả các thuật ngữ của hệ thống hoặc doanh nghiệp mà chúng ta cần mô hình

hóa. Các thuật ngữ sau đó sẽ được dùng để mô tả ca sử dụng. Phương thức cụ thể của

catalog này có thể rất khác nhau; nó có thể là một mô hình khái niệm chỉ ra các mối quan hệ

đơn giản hoặc chỉ là một văn bản chứa các thuật ngữ cùng lời mô tả vắn tắt những thuật ngữ

này trong thế giới thực.

b. Tác nhân

Một tác nhân là một người hoặc một vật nào đó tương tác với hệ thống, sử dụng hệ

thống. Trong khái niệm "tương tác với hệ thống", ý chúng ta muốn nói rằng tác nhân sẽ gửi

thông điệp đến hệ thống hoặc là nhận thông điệp xuất phát từ hệ thống, hoặc là thay đổi các

thông tin cùng với hệ thống. Nói một cách ngắn gọn, tác nhân thực hiện các ca sử dụng.

Thêm một điều nữa, một tác nhân có thể là người mà cũng có thể là một hệ thống khác (ví

dụ như là một chiếc máy tính khác được nối kết với hệ thống của chúng ta hoặc một loại

trang thiết bị phần cứng nào đó tương tác với hệ thống).

Một tác nhân là một dạng thực thể (một lớp), chứ không phải một thực thể. Tác nhân

mô tả và đại diện cho một vai trò, chứ không phải là một người sử dụng thật sự và cụ thể

của hệ thống. Nếu một anh chàng John nào đó muốn mua hợp đồng bảo hiểm từ một hãng

bảo hiểm, thì vai trò của anh ta sẽ là người mua hợp đồng bảo hiểm, và đây mới là thứ mà

chúng ta muốn mô hình hóa, chứ không phải bản thân anh chàng John. Trong thực tế, một

con người cụ thể có thể đóng vai trò làm nhiều tác nhân trong một hệ thống: một nhân viên

ngân hàng đồng thời cũng có thể là khách hàng của chính ngân hàng đó. Mặt khác, số lượng

các vai trò mà một con người cụ thể được phép đảm trách trong một hệ thống cũng có thể bị

hạn chế, ví dụ cùng một người không được phép vừa soạn hóa đơn vừa phê duyệt hóa đơn

đó. Một tác nhân sẽ có một tên, và cái tên này cần phải phản ánh lại vai trò của tác nhân. Cái

tên đó không được phản ánh lại một thực thể riêng biệt của một tác nhân, mà cũng không

phản ánh chức năng của tác nhân đó.

Một tác nhân giao tiếp với hệ thống bằng cách gửi hoặc là nhận thông điệp, giống

như khái niệm chúng ta đã quen biết trong lập trình khung đối tượng. Một ca sử dụng bao

giờ cũng được kích hoạt bởi một tác nhân gửi thông điệp đến cho nó. Khi một ca sử dụng

được thực hiện, ca sử dụng có thể gửi thông điệp đến một hay là nhiều tác nhân. Những

thông điệp này cũng có thể đến với các tác nhân khác, bên cạnh chính tác nhân đã kích hoạt

và gây ra ca sử dụng.

Tác nhân cũng có thể được xếp loại. Một tác nhân chính (Primary Actor) là tác nhân

sử dụng những chức năng căn bản của hệ thống, tức là các chức năng chính. Ví dụ, trong

103

một hệ thống bảo hiểm, một tác nhân căn bản có thể là tác nhân xử lý việc ghi danh và quản

lý các hợp đồng bảo hiểm. Một tác nhân phụ (secondary actor) là tác nhân sử dụng các chức

nặng phụ của hệ thống, ví dụ như các chức năng bảo trì hệ thống như quản trị ngân hàng dữ

liệu, giao tiếp, back-up và các tác vụ quản trị khác. Một ví dụ cho tác nhân phụ có thể là nhà

quản trị hoặc là một nhân viên sử dụng chức năng trong hệ thống để rút ra các thông tin

thống kê về doanh nghiệp. Cả hai loại tác nhân này đều được mô hình hóa để đảm bảo mô tả

đầy đủ các chức năng của hệ thống, mặc dù các chức năng chính mới thật sự nằm trong mối

quan tâm chủ yếu của khách hàng.

Tác nhân còn có thể được định nghĩa theo dạng tác nhân chủ động (active actor) hay

tác nhân thụ động (passive actor). Một tác nhân chủ động là tác nhân gây ra ca sử dụng,

trong khi tác nhân thụ động không bao giờ gây ra ca sử dụng mà chỉ tham gia vào một hoặc

là nhiều ca sử dụng.

Tìm tác nhân

Khi nhận diện tác nhân, có nghĩa là chúng ta lọc ra các thực thể đáng quan tâm theo

khía cạnh sử dụng và tương tác với hệ thống. Sau đó chúng ta có thể thử đặt mình vào vị trí

của tác nhân để cố gắng nhận ra các yêu cầu và đòi hỏi của tác nhân đối với hệ thống và xác

định tác nhân cần những ca sử dụng nào. Có thể nhận diện ra các tác nhân qua việc trả lời

một số các câu hỏi như sau:

 Ai sẽ sử dụng những chức năng chính của hệ thống (tác nhân chính)?

 Ai sẽ cần sự hỗ trợ của hệ thống để thực hiện những tác vụ hàng ngày của họ?

 Ai sẽ cần bảo trì, quản trị và đảm bảo cho hệ thống hoạt động (tác nhân phụ)?

 Hệ thống sẽ phải xử lý và làm việc với những trang thiết bị phần cứng nào?

 Hệ thống cần phải tương tác với các hệ thống khác nào? Nhóm các hệ thống này

được chia ra làm hai nhóm, nhóm kích hoạt cho mối quan hệ với hệ thống, và

nhóm mà hệ thống cần phải xây dựng của chúng ta sẽ thiết lập quan hệ. Khái

niệm hệ thống bao gồm cả các hệ thống máy tính khác cũng như các ứng dụng

khác trong chính chiếc máy tính mà hệ thống này sẽ hoạt động.

 Ai hay cái gì quan tâm đến kết quả (giá trị) mà hệ thống sẽ sản sinh ra?

Khi đi tìm những người sử dụng hệ thống, đừng quan sát những người đang ngồi ở

trước màn hình máy tính. Nên nhớ rằng, người sử dụng có thể là bất kỳ người nào hay bất

kỳ vật nào tương tác hoặc trực tiếp hoặc gián tiếp với hệ thống và sử dụng các dịch vụ của

hệ thống này để đạt đến một kết quả nào đó. Đừng quên rằng mô hình hóa ca sử dụng được

thực hiện để mô hình hóa một doanh nghiệp, vì thế tác nhân thường thường là khách hàng

của doanh nghiệp đó. Từ đó suy ra họ không phải là người sử dụng theo nghĩa đơn giản và

trực tiếp là người ngồi trước màn hình máy tính và thao tác với máy tính.

Để có thể nhận dạng được tốt nhiều tác nhân khác nhau, hãy tiến hành nghiên cứu

những người sử dụng của hệ thống hiện thời (một hệ thống thủ công hoặc một hệ thống

đang tồn tại), hỏi xem họ đóng những vai trò nào khi thực thi công việc hàng ngày của họ

104

với hệ thống. Cũng người sử dụng đó có thể thực thi nhiều vai trò khác nhau tại nhiều thời

điểm khác nhau, tùy thuộc vào việc chức năng nào trong hệ thống đang được sử dụng.

Xin nhắc lại, một tác nhân là một vai trò (một lớp), chứ không phải một thực thể

riêng lẻ. Mặc dù vậy, khi cung cấp ví dụ là một vài các thực thể của một tác nhân, bạn có

thể đảm bảo rằng tác nhân đó thật sự tồn tại. Một tác nhân phải có một sự liên kết

(Association) nào đó với một hoặc là nhiều Ca sử dụng. Mặc dù có những tác nhân có thể

không kích hoạt nên một Ca sử dụng nào, nhưng tác nhân đó sẽ giao tiếp ít nhất với một Ca

sử dụng tại một thời điểm nào đó. Cần phải đặt tên cho tác nhân làm sao để tên phản ánh

đúng vai trò của tác nhân đó trong hệ thống.

Biểu diễn tác nhân trong ngôn ngữ UML

Tác nhân trong UML là một lớp với biệt ngữ "Actor" (Tác nhân) và tên của lớp này

là tên của tác nhân (phản ánh vai trò của tác nhân). Một lớp tác nhân có thể vừa có thuộc

tính (attribute) lẫn hành vi (method) cũng như một thuộc tính tài liệu (document) mô tả tác

nhân đó. Một lớp tác nhân có một biểu tượng chuẩn hóa, biểu tượng "hình nhân":

Hình 4.36 - biểu tượng tác nhân trong UML

c. Ca sử dụng

Một ca sử dụng là đại diện cho một chức năng nguyên vẹn mà một tác nhân nhận

được. Một ca sử dụng trong ngôn ngữ UML được định nghĩa là một tập hợp của các chuỗi

hành động mà một hệ thống thực hiện để tạo ra một kết quả có thể quan sát được, tức là một

giá trị đến với một tác nhân cụ thể. Những hành động này có thể bao gồm việc giao tiếp với

một loạt các tác nhân cũng như thực hiện tính toán và công việc nội bộ bên trong hệ thống.

Các tính chất tiêu biểu của một ca sử dụng là:

 Một ca sử dụng bao giờ cũng được gây ra bởi một tác nhân, được thực hiện nhân

danh một tác nhân nào đó. Tác nhân phải ra lệnh cho hệ thống để thực hiện ca sử

dụng đó, dù là trực tiếp hay gián tiếp. Hiếm khi có tác nhân không liên quan đến

việc gây ra một ca sử dụng nào đó.

 Một ca sử dụng phải cung cấp một giá trị cho một tác nhân. Giá trị đó không phải

bao giờ cũng cần thiết phải nổi trội ra ngoài, nhưng luôn phải được thấy rõ.

 Một ca sử dụng là phải hoàn tất. Một trong những lỗi thường gặp là sẻ chia một

ca sử dụng thành các ca sử dụng nhỏ hơn, và các ca sử dụng này thực thi lẫn nhau

giống như việc gọi hàm cho một ngôn ngữ lập trình. Một ca sử dụng sẽ không

được coi là hoàn tất chừng nào mà giá trị cuối cùng của nó chưa được sản sinh ra,

thậm chí ngay cả khi đã xẩy ra nhiều động tác giao tiếp (ví dụ như đối thoại với

người sử dụng).

105

Ca sử dụng được nối với tác nhân qua liên kết (association). Đường liên kết chỉ ra

những tác nhân nào giao tiếp với ca sử dụng nào. Mối liên kết bình thường ra là một mối

quan hệ 1-1 và không có khung. Điều đó muốn nói lên rằng một thực thể của lớp tác nhân sẽ

giao tiếp với một thực thể của một ca sử dụng và cả hai có thể giao tiếp với nhau trong cả

hai chiều. Một ca sử dụng sẽ được đặt tên theo một thực thể mà ca sử dụng sẽ thực hiện, ví

dụ như ký hợp đồng bảo hiểm, cập nhật danh sách, …, và thường là một cụm từ hơn là chỉ

một từ riêng lẻ.

Một ca sử dụng là một lớp, chứ không phải một thực thể. Nó mô tả trọn vẹn một

chức năng, kể cả các giải pháp bổ sung và thay thế có thể có, các lỗi có thể xảy ra cũng như

những ngoại lệ có thể xảy ra trong quá trình thực thi. Một kết quả của sự thực thể hóa một

ca sử dụng được gọi là một cảnh kịch (scenario) và nó đại diện cho một sự sử dụng cụ thể

của hệ thống (một đường dẫn thực thi riêng biệt qua hệ thống). Ví dụ một cảnh kịch của ca

sử dụng "Ký hợp đồng bảo hiểm" có thể là "John liên hệ với hệ thống qua điện thoại rồi sau

đó ký hợp đồng bảo hiểm ô tô cho chiếc xe Toyota Carolla mà anh ta vừa mua."

Tìm ca sử dụng

Quá trình tìm các ca sử dụng bắt đầu với các tác nhân đã được xác định ở phần trước.

Đối với mỗi tác nhân, hãy hỏi các câu hỏi sau:

- Tác nhân này cần những chức năng nào từ hệ thống? Hành động chính của tác nhân

là gì?

Ví dụ cho một giao dịch rút tiền bên máy ATM trong một nhà băng lẻ, các hành động

chính của khách hàng (tác nhân) có thể là :

+ Đút thẻ vào máy ATM

+ Nhập password

+ Nhập loại chuyển dịch

+ Nhập số tiền mặt muốn rút ra

+ Yêu cầu về loại tiền

+ Nhặt tiền ra từ máy

+ Rút thẻ và tờ in kết quả giao dịch

- Tác nhân có cần phải đọc, phải tạo, phải hủy bỏ, phải sửa chữa, hay là lưu trữ một

loại thông tin nào đó trong hệ thống?

Ví dụ :

+ Nhân viên nhà băng liệu có quyền truy xuất hay thay đổi mức tiền lãi?

+ Khách hàng có thể thay đổi password của mình.

- Tác nhân có cần phải báo cho hệ thống biết về những sự kiện nào đó? Những sự

kiện như thế sẽ đại diện cho những chức năng nào?

Ví dụ :

106

+ Khách hàng kết thúc tài khoản, nhân viên cung cấp những thông tin này cho hệ

thống.

+ Có một chương trình đầu tư mới, các chi tiết của chương trình này sẽ phải được

nhân viên nhà băng nhập vào hệ thống.

- Hệ thống có cần phải thông báo cho Actor về những thay đổi bất ngờ trong nội bộ

hệ thống?

+ Trong tài khoản còn quá ít tiền.

+ Ba kỳ liên tiếp tiền lương chưa đổ về tài khoản.

- Công việc hàng ngày của tác nhân có thể được đơn giản hóa hoặc hữu hiệu hóa qua

các chức năng mới trong hệ thống (thường đây là những chức năng tiêu biểu chưa được tự

động hóa trong hệ thống)?

- Các câu hỏi khác:

+ Ca sử dụng có thể được gây ra bởi các sự kiện nào khác?

Ví dụ :

Sự kiện thời gian: Cuối tháng, hết hạn đầu tư.

Sự kiện bình thường của hệ thống: Tự động chuyển tiền theo các lệnh xác định trước.

Các sự kiện bất bình thường: Hợp đồng đầu tư kết thúc trước thời hạn.

+ Hệ thống cần những thông tin đầu vào/đầu ra nào? Những thông tin đầu vào/đầu ra

đó từ đâu tới và sẽ đi đâu?

+ Khó khăn và thiếu hụt chính trong hệ thống hiện thời nằm ở đâu (thủ công /tự động

hóa)?

Đối với nhóm câu hỏi cuối không có nghĩa là ca sử dụng ở đây không có tác nhân,

mà tác nhân sẽ được nhận ra chỉ khi chúng ta nhận diện ra các ca sử dụng này và sau đó xác

định tác nhân dựa trên cơ sở là ca sử dụng. Xin nhắc lại, một ca sử dụng bao giờ cũng phải

được liên kết với ít nhất một tác nhân.

Ví dụ tìm ca sử dụng

Nhà băng ABC đưa ra các yêu cầu sau: Một khách hàng có thể muốn gửi tiền vào, rút

tiền ra hoặc đơn giản kiểm tra lại số tiền trong tài khoản của anh ta qua máy tự động rút tiền

(ATM). Khi đưa tiền vào hoặc rút tiền ra, cần phải ghi ra giấy kết quả những chuyển dịch đã

thực hiện và trao tờ giấy này cho khách hàng.

Quan sát các chức năng căn bản và các thành phần tham gia, ta thấy có hai tác nhân

dễ nhận ra nhất là khách hàng và nhân viên thu ngân.

107

Hình 4.37 – Các ca sử dụng trong hệ thống ATM

Qua đó, có thể nhân dạng các ca sử dụng sau:

+ Gửi tiền vào.

+ Rút tiền ra.

+ Kiểm tra mức tiền trong tài khoản

+ Thực hiện các chuyển dịch nội bộ hệ thống

+ In kết quả các chuyển dịch đã thực hiện.

Ca sử dụng gửi tiền vào và rút tiền ra phụ thuộc vào ca sử dụng thực hiện các chuyển

dịch trong nội bộ hệ thống, việc thực hiện này về phần nó lại phụ thuộc vào chức năng in ra

các công việc đã được thực hiện. Kiểm tra mức tiền trong tài khoản là một ca sử dụng độc

lập, không phụ thuộc vào các ca sử dụng khác.

4.2.4. Các biến thể trong một ca sử dụng

Mỗi ca sử dụng sẽ có một dòng hành động chính (Basic Course). Đó là tiến trình

bình thường hay tiến trình mong đợi đối với ca sử dụng này.

Ngoài ra, có thể còn có một hay nhiều dòng hành động thay thế (Alternative) khác.

Chúng có thể được chia làm hai nhóm chính:

+ Thay thế bình thường (Normal Alternative)

+ Điều kiện gây lỗi (Error Condidtions)

Những gì mang tính bình thường hơn trong ca sử dụng được gọi là thay thế bình

thường. Có thể mô tả các dòng hành động thay thế bằng từ ngữ (xem phần tài liệu ca sử

dụng ).

Ví dụ một khách hàng có thể chọn các loại giao dịch sau của ATM:

+ Gửi tiền vào

+ Rút tiền ra

+ Kiểm tra mức tiền trong tài khoản

Đây là những ví dụ cho các dòng hành động thay thế bình thường.

108

Hình 4.38 – Các tiến trình trong hệ thống ATM

Điều kiện gây lỗi đại diện cho những bước tiến hành bất bình thường trong một ca sử

dụng. Cần phải tính trước đến những điều kiện gây lỗi đó, ví dụ :

+ Mức tiền trong tài khoản không đủ để tiến hành giao dịch

+ Password không đúng

+ ATM bị nghẽn thẻ

Hình vẽ trên nêu bật dòng hành động chính và những dòng hành động thay thế cũng

như sự khác biệt của chúng đối với tiến trình mong đợi của ca sử dụng.

4.2.5. Quan hệ giữa các ca sử dụng

Có ba loại quan hệ ca sử dụng: Quan hệ mở rộng, quan hệ sử dụng và quan hệ tạo

nhóm. Quan hệ mở rộng và quan hệ sử dụng là hai dạng khác nhau của tính thừa kế. Quan

hệ tạo nhóm là một phương cách để đặt nhiều ca sử dụng chung với nhau vào trong một gói.

a. Quan hệ mở rộng

Nhiều khi trong quá trình phát triển ca sử dụng, người ta thấy một số ca sử dụng đã

tồn tại cung cấp một phần những chức năng cần thiết cho một ca sử dụng mới. Trong một

trường hợp như vậy, có thể định nghĩa một ca sử dụng mới là ca sử dụng cũ cộng thêm một

phần mới. Một ca sử dụng như vậy được gọi là một ca sử dụng mở rộng (Extended Ca sử

dụng ). Trong quan hệ mở rộng, ca sử dụng gốc (Base Ca sử dụng) được dùng để mở rộng

phải là một ca sử dụng hoàn thiện. Ca sử dụng mở rộng không nhất thiết phải sử dụng toàn

bộ hành vi của ca sử dụng gốc.

Biểu đồ sau chỉ ra ca sử dụng “Ký hợp đồng mua ô tô” là ca sử dụng mở rộng của

"Ký hợp đồng bảo hiểm”.

109

Hình 4.39 - Quan hệ mở rộng giữa các ca sử dụng

Quan hệ mở rộng giữa các ca sử dụng được biểu thị bằng đoạn thẳng với hình tam

giác rỗng trỏ về phía ca sử dụng được dùng để mở rộng, đi kèm với stereotype

<<extends>>.

b. Quan hệ sử dụng

Khi một nhóm các ca sử dụng cùng chung một hành vi nào đó thì hành vi này có thể

được tách riêng ra thành một ca sử dụng riêng biệt và nó có thể được sử dụng bởi các ca sử

dụng kia, một mối quan hệ như vậy được gọi là quan hệ sử dụng.

Trong quan hệ sử dụng, phải sử dụng toàn bộ ca sử dụng khái quát hóa, nói một cách

khác, ta có một ca sử dụng này sử dụng toàn bộ một ca sử dụng khác. Các hành động trong

ca sử dụng khái quát hóa không cần phải được sử dụng trong cùng một tiến trình. Chúng có

thể được trộn lẫn với các hành động xảy ra trong ca sử dụng chuyên biệt hóa.

Hình 4.40 - Quan hệ sử dụng giữa các ca sử dụng

Quan hệ sử dụng giữa các ca sử dụng được biểu thị bằng đoạn thẳng với hình tam

giác rỗng trỏ về phía ca sử dụng được sử dụng, đi kèm với stereotype <<uses>>.

c. Quan hệ chung nhóm

Khi một số các ca sử dụng cùng xử lý các chức năng tương tự hoặc có thể liên quan

đến nhau theo một phương thức nào đó, người ta thường nhóm chúng lại với nhau.

Nhóm các ca sử dụng được thực hiện bằng khái niệm "Gói" (Package) của UML. Gói

không cung cấp giá trị gia tăng cho thiết kế.

Ví dụ: tất cả các ca sử dụng có liên quan đến sự tương tác giữa khách hàng và nhân

viên thu ngân sẽ được nhóm thành "Package Khách hàng- N/v thu ngân"

110

Hình 4.41 – Package của UML

Tóm tắt về ca sử dụng với máy ATM trong ngân hàng lẻ:

Cho tới nay chúng ta đã xác định được một vài ca sử dụng, phân tích dòng hành động

chính cũng như các dòng hành động thay thế, cũng như rút ra các mối quan hệ giữa chúng.

Biểu đồ sau tổng hợp những thông tin đã thu thập được về nhóm các ca sử dụng căn bản của

một hệ thống ATM.

Hình 4.42 - Biểu đồ một số ca sử dụng trong hệ thống ATM

4.2.6. Mô tả ca sử dụng

Như đã trình bày, lời mô tả một ca sử dụng thường được thực hiện trong văn bản.

Đây là lời đặc tả đơn giản và nhất quán về việc các tác nhân và các ca sử dụng (hệ thống)

tương tác với nhau ra sao. Nó tập trung vào ứng xử đối ngoại của hệ thống và không đề cập

tới việc thực hiện nội bộ bên trong hệ thống. Ngôn ngữ và các thuật ngữ được sử dụng trong

lời mô tả chính là ngôn ngữ và các thuật ngữ được sử dụng bởi khách hàng/người dùng.

Văn bản mô tả cần phải bao gồm những điểm sau:

 Mục đích của ca sử dụng: Mục đích chung cuộc của ca sử dụng là gì? Cái gì cần

phải được đạt tới? Ca sử dụng nói chung đều mang tính khung mục đích và mục

đích của mỗi ca sử dụng cần phải rõ ràng.

 Ca sử dụng được khởi chạy như thế nào: Tác nhân nào gây ra sự thực hiện ca sử

dụng này? Trong hoàn cảnh nào?

 Chuỗi các thông điệp giữa tác nhân và ca sử dụng: Ca sử dụng và các tác nhân

trao đổi thông điệp hay sự kiện nào để thông báo lẫn cho nhau, cập nhật hoặc

nhận thông tin và giúp đỡ nhau quyết định? Yếu tố nào sẽ mô tả dòng chảy chính

của các thông điệp giữa hệ thống và tác nhân, và những thực thể nào trong hệ

thống được sử dụng hoặc là bị thay đổi?

111

 Dòng chảy thay thế trong một ca sử dụng: Một ca sử dụng có thể có những dòng

thực thi thay thế tùy thuộc vào điều kiện. Hãy nhắc đến các yếu tố này, nhưng chú

ý đừng mô tả chúng quá chi tiết đến mức độ chúng có thể “che khuất“ dòng chảy

chính của các hoạt động trong trường hợp căn bản. Những động tác xử lý lỗi đặc

biệt sẽ được mô tả thành các ca sử dụng khác.

 Ca sử dụng sẽ kết thúc với một giá trị đối với tác nhân như thế nào: Hãy mô tả khi

nào ca sử dụng được coi là đã kết thúc, và loại giá trị mà nó cung cấp đến tác

nhân.

Hãy nhớ rằng lời mô tả này sẽ xác định những gì được thực thi có liên quan đến tác

nhân bên ngoài, chứ không phải những sự việc được thực hiện bên trong hệ thống. Văn bản

phải rõ ràng, nhất quán, khiến cho khách hàng có thể dễ dàng hiểu và thẩm tra chúng (để rồi

đồng ý rằng nó đại diện cho những gì mà anh/cô ta muốn từ phía hệ thống). Tránh dùng

những câu văn phức tạp, khó diễn giải và dễ hiểu lầm.

Một ca sử dụng cũng có thể được mô tả qua một biểu đồ hoạt động. Biểu đồ hoạt

động này chỉ ra chuỗi các hành động, thứ tự của chúng, các quyết định chọn lựa để xác định

xem hành động nào sau đó sẽ được thực hiện.

Để bổ sung cho lời mô tả một ca sử dụng, người ta thường đưa ra một loạt các cảnh

kịch cụ thể để minh họa điều gì sẽ xảy ra một khi ca sử dụng này được thực thể hóa. Lời mô

tả cảnh kịch minh họa một trường hợp đặc biệt, khi cả tác nhân lẫn ca sử dụng đều được coi

là một thực thể cụ thể. Khách hàng có thể dễ dàng hiểu hơn toàn bộ một ca sử dụng phức

tạp nếu có những cảnh kịch được mô tả thực tiễn hơn, minh họa lại lối ứng xử và phương

thức hoạt động của hệ thống. Nhưng xin nhớ rằng, một lời mô tả cảnh kịch chỉ là một sự bổ

sung chứ không phải là ứng cử viên để thay thế cho lời mô tả ca sử dụng.

Sau khi các ca sử dụng đã được mô tả, một hoạt động và một công việc đặc biệt cần

phải thực hiện là thẩm tra xem các mối quan hệ có được nhận diện không. Trước khi tất cả

các ca sử dụng được mô tả, nhà phát triển chưa thể có được những kiến thức hoàn tất và

tổng thể để xác định các mối quan hệ thích hợp, thử nghiệm làm theo phương thức đó có thể

sẽ dẫn đến một tình huống nguy hiểm. Trong thời gian thực hiện công việc này, hãy trả lời

các câu hỏi sau:

 Tất cả các tác nhân liên quan đến một ca sử dụng có mối liên kết giao tiếp với ca

sử dụng đó không?

 Có tồn tại những sự tương tự giữa một loạt các tác nhân minh họa một vai trò

chung và nhóm này liệu có thể được mô tả là một lớp tác nhân căn bản (base

class)?

 Có tồn tại những sự tương tự giữa một loạt các ca sử dụng, minh họa một dòng

chảy hành động chung? Nếu có, liệu điều này có thể được mô tả là một mối quan

hệ sử dụng đến với một ca sử dụng khác?

 Có tồn tại những trường hợp đặc biệt của một ca sử dụng có thể được mô tả là

một mối quan hệ mở rộng?

112

 Có tồn tại một tác nhân nào hay một ca sử dụng nào không có mối liên kết giao

tiếp? Nếu có, chắc chắn ở đây đã có chuyện lầm lạc, sai trái: Tại sao lại xuất hiện

tác nhân này?

 Có lời yêu cầu nào về chức năng đã được xác định, nhưng lại không được bất kỳ

một ca sử dụng nào xử lý? Nếu thế, hãy tạo một ca sử dụng cho yêu cầu đó.

4.3. Biểu đồ hoạt động (Activity Diagram)

Biểu đồ hoạt động nắm bắt hành động và các kết quả của chúng. Biểu đồ hoạt động

tập trung vào công việc được thực hiện trong khi thực thi một thủ tục (hàm), các hoạt động

trong một lần thực thi một trường hợp sử dụng hoặc trong một đối tượng. Biểu đồ hoạt động

là một biến thể của biểu đồ trạng thái và có một mục tiêu tương đối khác, đó là nắm bắt

hành động (công việc và những hoạt động phải được thực hiện) cũng như kết quả của chúng

theo sự biến đổi trạng thái. Các trạng thái trong biểu đồ hoạt động (được gọi là các trạng

thái hành động) sẽ chuyển sang giai đoạn kế tiếp khi hành động trong trạng thái này đã được

thực hiện xong (mà không xác định bất kỳ một sự kiện nào theo như nội dung của biểu đồ

trạng thái). Một sự điểm phân biệt khác giữa biểu đồ hoạt động và biểu đồ trạng thái là các

hành động của nó được định vị trong các ( ). Một luồng sẽ gom nhóm cácluồng swimlane

hoạt động, chú ý tới khái niệm người chịu trách nhiệm cho chúng hoặc chúng nằm ở đâu

trong một tổ chức. Một biểu đồ hoạt động là một phương pháp bổ sung cho việc miêu tả

tương tác, đi kèm với trách nhiệm thể hiện rõ các hành động xảy ra như thế nào, chúng làm

gì (thay đổi trạng thái đối tượng), chúng xảy ra khi nào (chuỗi hành động), và chúng xảy ra

ở đâu (luồng hành động).

Biểu đồ hoạt động có thể được sử dụng cho nhiều mục đích khác nhau, ví dụ như:

 Để nắm bắt công việc (hành động) sẽ phải được thực thi khi một thủ tục được

thực hiện. Đây là tác dụng thường gặp nhất và quan trọng nhất của biểu đồ hoạt

động.

 Để nắm bắt công việc nội bộ trong một đối tượng.

 Để chỉ ra một nhóm hành động liên quan có thể được thực thi ra sao, và chúng sẽ

ảnh hưởng đến những đối tượng nằm xung quanh chúng như thế nào.

 Để chỉ ra một trường hợp sử dụng có thể được thực thể hóa như thế nào, theo khái

niệm hành động và các sự biến đổi trạng thái của đối tượng.

 Để chỉ ra một doanh nghiệp hoạt động như thế nào theo các khái niệm công nhân

(tác nhân), qui trình nghiệp vụ (workflow), hoặc tổ chức và đối tượng (các khía

cạnh vật lý cũng như tri thức được sử dụng trong doanh nghiệp).

Biểu đồ hoạt động có thể được coi là một loại Flow chart. Điểm khác biệt là Flow

Chart bình thường ra chỉ được áp dụng đối với các qui trình tuần tự, biểu đồ hoạt động có

thể xử lý cả các các qui trình song song.

Hành động và sự thay đổi trạng thái

Một hành động được thực hiện để sản sinh ra một kết quả. Việc thực thi của thủ tục

có thể được miêu tả dưới dạng một tập hợp của các hành động liên quan, sau này chúng sẽ

113

được chuyển thành các dòng code thật sự. Theo như định nghĩa ở phần trước, một biểu đồ

hoạt động chỉ ra các hành động cùng mối quan hệ giữa chúng và có thể có một điểm bắt đầu

và một điểm kết thúc. Biểu đồ hoạt động sử dụng cũng cùng những ký hiệu như trong biểu

đồ trạng thái bình thường.

Khi một người gọi tác vụ PrintAllCustomer (trong lớp CustomerWindow), các hành

động khởi động. hành động đầu tiên là hiện một hộp thông báo lên màn hình; hành động thứ

hai là tạo một tập tin postscript; hành động thứ ba là gởi file postscript đến máy in; và hành

động thứ tư là xóa hộp thông báo trên màn hình. Các hành động được chuyển tiếp tự động;

chúng xảy ra ngay khi hành động trong giai đoạn nguồn được thực hiện.

Các sự thay đổi có thể được bảo vệ bởi các điều kiện canh giữ (Guard-condition), các

điều kiện này phải được thỏa mãn thì sự thay đổi mới nổ ra. Một ký hiệu hình thoi được sử

dụng để thể hiện một quyết định. Ký hiệu quyết định có thể có một hoặc nhiều sự thay đổi

đi vào và một hoặc nhiều sự thay đổi đi ra được dán nhãn đi kèm các điều kiện bảo vệ. Bình

thường ra, một trong số các sự thay đổi đi ra bao giờ cũng được thỏa mãn (là đúng).

Một sự thay đổi được chia thành hai hay nhiều sự thay đổi khác sẽ dẫn đến các hành

động xảy ra song song. Các hành động được thực hiện đồng thời, mặc dù chúng cũng có thể

được thực hiện lần lượt từng cái một. Yếu tố quan trọng ở đây là tất cả các thay đổi đồng

thời phải được thực hiện trước khi chúng được thống nhất lại với nhau (nếu có). Một đường

thẳng nằm ngang kẻ đậm (còn được gọi là thanh đồng hộ hóa – Synchronisation Bar) chỉ

rằng một sự thay đổi được chia thành nhiều nhánh khác nhau và chỉ ra một sự chia sẻ thành

các hành động song song. Cũng đường thẳng đó được sử dụng để chỉ ra sự thống nhất các

nhánh.

Kí hiệu UML cho các thành phần căn bản của biểu đồ hoạt động:

Hoạt động (Activity): là một qui trình được định nghĩa rõ ràng, có thể được thực thi

qua một hàm hoặc một nhóm đối tượng. Hoạt động được thể hiện bằng hình chữ nhật bo

tròn cạnh.

Thanh đồng bộ hóa (Synchronisation bar): chúng cho phép ta mở ra hoặc là đóng lại

các nhánh chạy song song nội bộ trong tiến trình.

114

Hình 4.43 - Thanh đồng bộ hóa

Điều kiện canh giữ (Guard Condition): các biểu thức logic có giá trị hoặc đúng hoặc

sai. Điều kiện canh giữ được thể hiện trong ngoặc vuông, ví dụ: [Customer existing].

Điểm quyết định (Decision Point): được sử dụng để chỉ ra các sự thay đổi khả thi. Kí

hiệu là hình thoi.

Hình sau đây miêu tả một đoạn biểu đồ hoạt động của máy ATM. Sau khi thẻ được

đưa vào máy, ta thấy có ba hoạt động song song:

Xác nhận thẻ

Xác nhận mã số PIN

Xác nhận số tiền yêu cầu được rút

Chỉ khi sử dụng biểu đồ hoạt động, các hoạt động song song như vậy mới có thể

được miêu tả. Mỗi một hoạt động xác nhận bản thân nó cũng đã có thể là một quá trình

riêng biệt.

Hình 4.44 - Biểu đồ hoạt động của máy ATM

115

Chương 5. Nắm bắt và phân tích yêu cầu

5.1. Vai trò của nắm bắt và phân tích yêu cầu

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 kỹ 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 đặc tả yêu cầu, là tài

liệu ràng buộc giữa khách hàng và người phát triển và 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 yêu cầu và người phân tích hiểu, 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). 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 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, ví dụ như ở bước thiết kế hay mã hóa.

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ù của tổ chức đặt hàng nó, do đó nó thường

khó hiểu, khó định nghĩa và 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, thậm chí 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 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 kỹ sư phần mềm (người phát triển), kỹ sư hệ thống (sẽ làm việc bảo trì)...

116

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 đủ

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.

5.2. Các hoạt động phân tích và đặc tả yêu cầu

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

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ũ, đá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 các điểm

tốt và không tốt của các giải pháp đó (như tính năng của hệ thống, giá cả cài đặt, bảo trì,

việc đào tạo người sử dụng...). Đó 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 tâm

chí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 coi như nền tảng cho hầu hết các hệ thống (các

117

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

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

- chi phí cho 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 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 trôi chảy 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.

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

Sau khi nghiên cứu khả thi, bước quan trọng đầu tiên là phân tích hoặc suy luận các

yêu cầu. Các chuyên gia phát triển phần mềm làm việc với các khách hàng và người sử

dụng cuối cùng để tìm ra các lĩnh vực ứng dụng mà cấp hệ thống phần mềm phải đáp ứng,

việc thực hiện các yêu cầu hệ thống do phần mềm và các yếu tố khác quy định, chẳng hạn

như phần cứng, các thiết bị ngoại vi…

118

Phân tích yêu cầu là một bước quan trọng, tính khả thi của hệ thống sau này phụ

thuộc nhiều vào quá trình trao đổi giữa nhu cầu của khách hàng và nhà cung cấp với các

công việc được tự động hóa. Nếu việc phân tích không đáp ứng được nhu cầu thực của

khách hàng, hệ thống sau khi hình thành sẽ không đáp ứng được các yêu cầu.

Phân tích yêu cầu có thể còn liên quan đến sự đa dạng của các cấp bậc chức vụ khác

nhau của các nhân viên trong cùng một tổ chức. Hay nói cach khác, vấn đề bảo mật gây ra

rất nhiều khó khăn trong phân tích yêu cầu. Điều này ảnh hưởng tới người tác động cuối

cùng vào hệ thống, người tổ chức và thiết đặt hệ thống. Các nhà đầu tư có ảnh hưởng trực

tiếp hoặc gián tiếp tới những yêu cầu của hệ thống.

Bước phân tích là khó bởi một số lý do:

- Trong hầu hết các trường hợp, các nhà đầu tư không biết thực sự họ muốn gì ở hệ

thống máy tính. Thậm chí khi họ có một định hướng rõ ràng họ mới có thể biết hệ thống cần

phải làm gì, và rất khó khăn để kết hợp các yêu cầu lại với nhau. Họ có thể làm sai lệch nhu

cầu bởi họ không biết giá trị của câu hỏi.

- Các nhà đầu tư trong một hệ thống thường bộc lộ các yêu cầu với kiến thức ngầm

định trong công việc của họ. Còn người kỹ sư không có nhiều kinh nghiệm trong các lĩnh

vực của khách hàng, do vậy cần phải hiểu được những yêu cầu và dịch chúng sang một dạng

tài liệu chấp nhận được.

- Các nhà đầu tư khác nhau có những yêu cầu khác nhau và họ có thể tiến hành theo

những cách rất khác nhau. Người kỹ sư phải nhận biết được những điểm chung và những

điểm khác biệt đó.

- Việc phân tích lấy một không gian trong khung cảnh của tổ chức, những nhân tố

chính trị (chẳng hạn như việc phân quyền) có thể ảnh hưởng đến yêu cầu của hệ thống,

những nhân tố này có thể không rõ ràng mạch lạc tới người sử dụng cuối cùng. Ví dụ như

người lãnh đạo thường có quyền cao hơn đối với hệ thống.

- Việc phân tích lấy khía cạnh thương mại và kinh tế làm động lực. Nó chắc chắn sẽ

thay đổi trong quá trình phân tích. Từ đây, những yêu cầu riêng lẻ có thể thay đổi, những

yêu cầu mới có thể xuất hiện từ phía các nhà đầu tư mới. Các nhà đầu tư mới sẽ không phải

thăm dò lại từ đầu mà chỉ phải bổ sung thêm thông tin hay yêu cầu.

Để tiến hành phân tích yêu cầu, ta phải dựa vào sự hiểu biết nhất định trong các lĩnh

vực cụ thể, khi đó mô hình của tiến trình phân tích chắc chắn sẽ đơn giản hơn.

Mô hình sau đây nêu lên một số bước quan trọng trong tiến trình phân tích

119

Trong sơ đồ trên các bước bổ sung cho nhau, chu kỳ bắt đầu từ hiểu biết về các lĩnh

vực và cuối cùng là bản phê chuẩn các yêu cầu. Những hiểu biết của quá trình phân tích sẽ

dần được cải thiện sau mỗi chu trình.

- Hiểu biết về lĩnh vực ứng dụng: Phân tích phải được phát triển qua sự hiểu biết về

các lĩnh vực ứng dụng. Giả sử có một hệ thống siêu thị, quy trình phân tích phải tìm ra được

những điểm chung nhất, khái quát nhất giữa các siêu thị

- Thu thập yêu cầu: quy trình này liên quan đến các nhà đầu tư, người xây dựng hệ

thống phải thông qua họ để khám phá ra các yêu cầu. Từ đó sẽ nâng cao hiểu biết để phát

triển và xây dựng hệ thống.

- Phân loại yêu cầu: quá trình này lấy các yêu cầu một cách ngẫu nhiên, không có cấu

trúc và sắp xếp chúng một cách có hệ thống.

- Giải quyết xung đột: chắc chắn trong quá trình đưa ra yêu cầu, các nhà đầu tư do

không có chuyên môn nên xung đột có thể xảy ra. Công việc của người phân tích là cần phải

tìm ra và giải quyết các xung đột đó.

- Quyền ưu tiên: trong một tập hợp các yêu cầu bao giờ cũng có những yêu cầu quan

trọng và cấp bách hơn các yêu cầu khác, vì vậy ta phải khám phá ra các yêu cầu đó

- Làm cho các yêu cầu trở nên hiệu lực: các yêu cầu phải đảm bảo tính kiên định và

phù hợp với nhu cầu thực của nhà đầu tư. Từ đó mới xây dựng được hệ thống hữu ích.

Trong quá trình phân tích yêu cầu, một vài mô hình hệ thống khác nhau có thể được

sinh ra, mô hình là hình ảnh trừu tượng của hệ thống, các mô hình khác nhau sẽ có thông tin

khác nhau.

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

Xác định yêu cầu là mô tả trừu tượng về các dịch vụ mà hệ thống cần cung cấp và

các ràng buộc mà hệ thống cần tuân thủ khi vận hành. Nó chỉ mô tả các hành vi bên ngoài

của hệ thống mà không liên quan tới các chi tiết thiết kế. Yêu cầu nên được viết sao cho có

thể hiểu mà không cần một kiến thức chuyên môn đặc biệt nào.

Các yêu cầu được chia thành hai loại:

1) Các yêu cầu chức năng: các dịch vụ mà hệ thống cần cung cấp. Do vậy các yêu

cầu chức năng sẽ tác động trở lại các dữ liệu và có ảnh hưởng đến một số tình huống đặc

120

biệt. Trong một số trường hợp, yêu cầu chức năng cũng có thể có các trạng thái không phải

làm việc.

2) Các yêu cầu phi chức năng: các ràng buộc mà hệ thống cần tuân thủ, bao gồm ràng

buộc về thời gian, các chuẩn công nghệ trong quá trình xử lý.

Các yêu cầu phi chức năng có thể chia làm 3 kiểu:

i) Yêu cầu sản phẩm: các yêu cầu về tốc độ, bộ nhớ, độ tin cậy, về tính khả chuyển

và tái sử dụng...

ii) Yêu cầu về quá trình: yêu cầu đối với quá trình xây dựng sản phẩm như các chuẩn

phải tuân theo, các phương pháp thiết kế, ngôn ngữ lập trình...

iii) Yêu cầu khác: các yêu cầu không thuộc hai nhóm trên như về tính pháp lý, về chi

phí, về thành viên nhóm phát triển...

Các yêu cầu phi chức năng thường rất đặc thù với từng khách hàng và do đó khó

phân tích và đặc tả một cách đầy đủ và chính xác.

Về nguyên tắc, yêu cầu của hệ thống phải vừa đầy đủ vừa không được mâu thuẫn

nhau. Đối với các hệ thống lớn phức tạp thì chúng ta khó đạt được hai yếu tố này trong các

bước phân tích đầu. Một phần là do tính phức tạp của hệ thống, một phần do quan điểm

khác hau của nhu cầu người sử dụng. Trong các bước duyệt lại yêu cầu cần phải bổ sung,

chỉnh lý tư liệu yêu cầu.

Xác định yêu cầu được viết bằng ngôn ngữ tự nhiên, từ đó sẽ nảy sinh ra các vấn đề

- Tính thiếu rõ ràng: do viết bằng ngôn ngữ tự nhiên nên đôi khi mơ hồ, khó hiểu

- Sự lẫn lộn giữa các yêu cầu: không phân biệt được đâu là yêu cầu chức năng, đâu là

yêu cầu phi chức năng.

- Sự trộn lẫn trong các yêu cầu: các yêu cầu khác nhau có thể biểu diễn thành một

yêu cầu chung.

5.2.4. Đặc tả yêu cầu

Tài liệu xác định yêu cầu là mô tả hướng khách hàng và được viết bởi ngôn ngữ của

khách hàng. Khi đó có thể dùng ngôn ngữ tự nhiên và các khái niệm trừu tượng. Tài liệu dặc

tả yêu cầu (đặc tả chức năng) là mô tả hướng người phát triển, là cơ sở của hợp đồng làm

phần mềm. Nó không được phép mơ hồ, nếu không sẽ dẫn đến sự hiểu nhầm bởi khách

hàng hoặc người phát triển. Với một yêu cầu mơ hồ thì người phát triển sẽ thực hiện nó một

cách rẻ nhất còn khách hàng thì không muốn vậy. Do đó khách hàng có thể đòi hỏi sửa đổi

chức năng phần mềm khi nó đã gần hoàn thiện khiến cho chi phí tăng và chậm thời điểm

bàn giao. Chi phí cho sửa các sai sót trong phát biểu yêu cầu là rất lớn, đặc biệt là khi các

sai sót này được phát hiện khi đã bắt đầu xây dựng hệ thống. Theo một số thống kê thì 85%

mã phải viết lại do thay đổi yêu cầu và 12% lỗi phát hiện trong 3 năm đầu sử dụng là do đặc

tả yêu cầu không chính xác. Do đó, việc đặc tả chính xác yêu cầu là mối quan tâm được đặt

lên hàng đầu. Có hai phương pháp đặc tả là

1. Đặc tả phi hình thức: là cách đặc tả bằng ngôn ngữ tự nhiên

121

2. Đặc tả hình thức: là cách đặc tả bằng các ngôn ngữ nhân tạo (ngôn ngữ đặc tả), các

công thức và biểu đồ

Đặc tả phi hình thức (ngôn ngữ tự nhiên) thuận tiện cho việc xác định yêu cầu nhưng

nhiều khi không thích hợp với đặc tả yêu cầu vì:

 Không phải lúc nào người đọc và người viết đặc tả bằng ngôn ngữ tự nhiên cũng

hiều các từ như nhau.

 Ngôn ngữ tự nhiên quá mềm dẻo do đó các yêu cầu liên quan đến nhau có thể

được biểu diễn bằng các hình thức hoàn toàn khác nhau và người phát triển không

nhận ra các mối liên quan này.

 Các yêu cầu khó được phân hoạch một cách hữu hiệu do đó hiệu quả của việc đổi

thay chỉ có thể xác định được bằng cách kiểm tra tất cả các yêu cầu chứ không

phải một nhóm các yêu cầu liên quan.

Đặc tả hình thức là đặc tả mà ở đó các từ ngữ, cú pháp, ngữ nghĩa được định nghĩa

hình thức dựa vào toán học. Đặc tả hình thức có thể coi là một phần của hoạt động đặc tả

phần mềm. Các đặc tả yêu cầu được phân tích chi tiết. Các mô tả trừu tượng của các chức

năng chương trình có thể được tạo ra để làm rõ yêu cầu.

Đặc tả phần mềm hình thức là một đặc tả được trình bày trên một ngôn ngữ bao gồm:

từ vựng, cú pháp và ngữ nghĩa được định nghĩa. Định nghĩa ngữ nghĩa đảm bảo ngôn ngữ

đặc tả không phải là ngôn ngữ tự nhiên mà dựa trên toán học. Các chức năng nhận các đầu

vào trả lại các kết quả. Các chức năng có thể định ra các điều kiện tiền tố và hậu tố. Điều

kiện tiền tố là điều kiện cần thỏa mãn để có dữ liệu vào, điều kiện hậu tố là điều kiện cần

thỏa mãn sau khi có kết quả.

Có hai hướng tiếp cận đặc tả hình thức để phát triển các hệ thống tương đối phức tạp.

+ Tiếp cận đại số, hệ thống được mô tả dưới dạng các toán tử và các quan hệ.

+ Tiếp cận mô hình, mô hình hệ thống được câú trúc sử dụng các thực thể toán học

như là các tập hợp và các thứ tự.

Sử dụng đặc tả hình thức, ta có các thuận lợi:

 Cho phép chúng ta thấy và hiểu được bản chất bên trong của các yêu cầu, đây là

cách tốt nhất để làm giảm các lỗi, các thiếu sót có thể xảy ra và giúp cho công

việc thiết kế được thuận lợi.

 Do chúng ta sử dụng toán học cho việc đặc tả nên có thể dựa vào các công cụ

toán học khi phân tích và điều này làm tăng thêm tính chắc chắn và tính đầy đủ

của hệ thống.

 Đặc tả hình thức, bản thân nó cho chúng ta một cách thức cho việc kiểm tra hệ

thống sau này.

Tuy vậy, đặc tả hình thức cũng bộc lộ một vài khó khăn:

 Quản lý phần mềm có tính bảo thủ cố hữu của nó, không sẵn sàng chấp nhận các

kỹ thuật mới.

122

 Chi phí cho việc đặc tả hình thức thường cao hơn so với các đặc tả khác (tuy phần

cài đặt sẽ thấp hơn), nên khó để chứng minh rằng chi phí tương đối cao cho đặc tả

sẽ làm giảm tổng chi phí dự án.

 Phần lớn, những người đặc tả hệ thống không được đào tạo một cách chính quy

về việc sử dụng đặc tả hình thức cho việc đặc tả hệ thống mà dựa trên thói quen

của họ.

 Thông thường, nhiều thành phần của hệ thống là khó cho việc đặc tả bằng ngôn

ngữ hình thức. Thêm vào đó là khách hàng không thể hiểu được nó.

 Khách hàng không thích các đặc tả toán học.

Các ngôn ngữ đặc tả (đặc tả hình thức) khắc phục được các hạn chế của đặc tả phi

hình thức, tuy nhiên đa số khách hàng lại không thông thạo các ngôn ngữ này. Thêm nữa

mỗi ngôn ngữ đặc tả hình thức thường chỉ phục vụ cho một nhóm lĩnh vực riêng biệt và việc

đặc tả hình thức là một công việc tốn kém thời gian.

Một cách tiếp cận là bên cạnh các đặc tả hình thức người ta viết các chú giải bằng

ngôn ngữ tự nhiên để giúp khách hành dễ hiểu.

Các nguyên lý đặc tả.

Đặc tả có thể xem như một tiến trình biểu diễn. Mục đích cuối cùng của đặc tả là

các yêu cầu được biểu thị sao cho dẫn tới việc cài đặt phần mềm thành công. Balzer và

Goldman đề nghị 8 nguyên lý đặc tả tốt.

Nguyên lý 1: Phân tách chức năng với cài đặt.

Trước hết, theo định nghĩa, đặc tả là một mô tả về điều mong muốn, chứ không phải

là cách thực hiện nó (cài đặt). Đặc tả có thể chấp nhận 2 dạng hoàn toàn khác nhau. Dạng

thứ nhất là dạng của các hàm toán học: Với một tập dữ liệu đầu vào đã cho, tạo ra một tập

dữ liệu đầu ra đặc biệt. Dạng tổng quát của đặc tả như thế là tìm ra (một hoặc tất cả

những) kết quả ứng với P (đầu vào), với P biểu thị một tân từ bất kỳ. Trong đặc tả như thế,

kết quả thu được phải được diến đạt một cách đầy đủ, toàn vẹn, theo dạng đó là cái gì

(không phải đó là như thế nào). Một phần điều này là vì kết quả của một hàm (toán học) của

đầu vào (phép toán có điểm bắt đầu và điểm kết thúc đã xác định rõ) không bị ảnh hưởng

bởi môi trường bao quanh.

Nguyên lý 2: Cần ngôn ngữ đặc tả hệ thống hướng tiến trình.

Xét tình huống trong đó môi trường là động và sự thay đổi của nó ảnh hưởng tới

hành vi của thực thể nào đó tương tác với môi trường đó (như trong “hệ thống máy tính

nhúng”). Hành vi của nó không thể biểu diễn được ở dạng hàm (toán học) của đầu vào.

Thay vì thế, cần phải sử dụng cách biểu diễn khác - cách mô tả hướng tiến trình, trong đó

đặc tả cái gì đã đạt được bằng cách xác định một mô hình các thao tác mong muốn đạt được

của hệ thống dưới dạng các công việc đáp ứng chức năng đối với kích thích khác nhau từ

môi trường.

Những đặc tả hướng tiến trình như vậy, trình bày một mô hình về hành vi hệ

thống, thông thường đã bị loại ra khỏi các ngôn ngữ đặc tả hình thức, nhưng chúng lại là

bản chất nếu nhiều tình huống động phức tạp hơn cần phải được đặc tả. Trong thực tế, cần

123

phải thừa nhận rằng trong những tình huống như vậy cả tiến trình cần tự động hoá lẫn môi

trường tồn tại của nó đều phải được mô tả một cách hình thức. Tức là, toàn bộ hệ thống các

bộ phận tương tác phải được đặc tả chứ không chỉ một thành phần được đặc tả.

Nguyên lý 3: Đặc tả phải bao gồm hệ thống có phần mềm là một thành phần trong

đó

Một hệ thống bao gồm các thành phần tương tác nhau. Chỉ bên trong hoàn

cảnh của hệ thống toàn bộ và tương tác giữa các thành phần của nó thì hành vi của một

thành phần riêng mới có thể được xác định. Nói chung, một hệ thống có thể được mô hình

hoá như một tập hợp các sự vật tích cực và thụ động. Những sự vật này có liên quan lẫn

nhau và qua thời gian thì mối quan hệ giữa các sự vật thay đổi. Mối quan hệ động này đưa

ra sự kích thích cho các sự vật tích cực, còn gọi là các tác nhân, đáp ứng. Sự đáp ứng có

thể gây ra những thay đổi thêm nữa, và do đó, tạo ra thêm kích thích để cho các tác nhân

có thể đáp ứng lại.

Nguyên lý 4: Đặc tả phải bao gồm cả môi trường mà hệ thống vận hành.

Tương tự, môi trường mà trong đó hệ thống vận hành và tương tác với cũng phải

được xác định.

May mắn là điều này đơn thuần chỉ cần sự thừa nhận rằng bản thân môi trường cũng

là một hệ thống bao gồm các sự vật tương tác, cả tích cực lẫn thụ động, mà trong đó hệ

thống chỉ là một tác nhân. Các tác nhân khác, theo định nghĩa là không thay đổi bởi

vì chúng là một phần của môi trường, giới hạn phạm vi của việc thiết kế và cài đặt về sau.

Trong thực tế, sự khác nhau duy nhất giữa hệ thống và môi trường của nó là ở chỗ nỗ lực

thiết kế và cài đặt về sau sẽ vận hành chỉ trong đặc tả cho hệ thống. Đặc tả môi trường làm

cho “giao diện” của hệ thống được xác định theo cùng cách như bản thân hệ thống chứ

không đưa vào cách hình thức khác.

Cần phải chú ý rằng bức tranh đặc tả hệ thống được trình bày ở đây chính là bức

tranh của tập hợp các tác nhân xoắn xuýt nhau cao độ phản ứng với những kích thích trong

môi trường (thay đổi các sự vật) do các tác nhân đó tạo ra. Chỉ có thông qua những hành

động điều phối của tác nhân mà hệ thống mới đạt tới mục tiêu của nó. Sự phụ thuộc lẫn

nhau vi phạm vào nguyên lí phân tách (cô lập với các phần khác của hệ thống và môi

trường). Nhưng đây là một nguyên lí thiết kế, không phải là nguyên lí đặc tả. Thiết kế tuân

theo đặc tả, và quan tâm tới việc phân rã một đặc tả thành các mẩu gần tách biệt để chuẩn bị

cho cài đặt. Tuy nhiên đặc tả phải vẽ lại chính xác bức chân dung của hệ thống và môi

trường của nó như cộng đồng người dùng cảm nhận theo một cách thức nhiều chi tiết như

các giai đoạn cài đặt và thiết kế cần tới. Vì mức độ chi tiết cần thiết này là khó thấy trước,

nếu không nói là không thể, nên đặc tả, thiết kế và cài đặt phải được thừa nhận như một hoạt

động tương tác. Do đó điều mấu chốt là công nghệ cần có để bao quát thật nhiều cho hoạt

động này khi bản đặc tả được soạn thảo và thay đổi (trong cả hai giai đoạn phát triển khởi

đầu và bảo trì về sau).

Nguyên lý 5: Đặc tả hệ thống phải là một mô hình nhận thức.

Đặc tả hệ thống phải là một mô hình nhận thức chứ không phải là một mô hình thiết

kế hay cài đặt. Nó phải mô tả một hệ thống như cộng đồng người sử dụng cảm nhận thấy.

124

Các sự vật mà nó thao tác phải tương ứng với các sự vật của lĩnh vực đó; các tác nhân phải

mô hình cho các cá nhân, tổ chức và trang thiết bị trong lĩnh vực đó; còn các hành động

họ thực hiện thì phải mô hình cho những hoạt động thực tế xuất hiện trong lĩnh vực.

Đặc tả phải có khả năng tổ hợp vào trong nó những qui tắc hay luật bao trùm các

sự vật Newton). Những luật này, biểu thị cho “tính vật lí” của lĩnh vực, là phần cố

hữu của đặc tả hệ thống.

Nguyên lý 6: Đặc tả phải thể hiện tính vận hành.

Đặc tả phải đủ đầy đủ và hình thức để có thể được dùng trong việc xác định liệu một

cài đặt được đề nghị có thoả mãn đặc tả cho những trường hợp kiểm thử tuỳ ý không. Tức

là, với kết quả của việc cài đặt trên một tập dữ liệu được chọn một cách tuỳ ý, phải có thể

dùng đặc tả để xác định tính hợp lệ cho những kết quả đó. Điều này kéo theo rằng đặc tả,

mặc dầu không phải là một đặc tả hoàn toàn về cách thức, vẫn có thể hành động như một

bộ sinh các hành vi có thể trong số những hành vi phải có của cài đặt được đề nghị. Do đó,

theo một nghĩa mở rộng, đặc tả này phải là vận hành ...

Nguyên lý 7: Đặc tả chấp nhập dung sai về tính không đầy đủ.

Không đặc tả nào có thể là đầy đủ hoàn toàn. Môi trường trong đó nó tồn tại

thường quá phức tạp cho điều đó. Một đặc tả bao giờ cũng là một mô hình - một sự trừu

tượng hoá - của một tình huống thực (hay được mường tượng) nào đó. Do đó, nó sẽ không

đầy đủ. Hơn thế nữa, như đã được phát biểu nó sẽ tồn tại tại ở nhiều mức chi tiết. Tính vận

hành được yêu cầu ở trên không nhất thuộc lĩnh vực. Một số trong những trường hợp là luật

bài trừ những trạng thái nào đó của hệ thống (như “hai sự vật không thể đồng thời ở cùng

một chỗ và vào cùng một lúc”), và do đó giới hạn hành vi của các tác nhân hay chỉ ra nhu

cầu soạn thảo thêm để ngăn cản những trạng thái này khỏi nảy sinh. Các luật khác mô tả

cách các sự vật đáp ứng lại khi bị kích thích (như luật chuyển động của thiết là cần thiết.

Các công cụ phân tích được sử dụng để giúp cho người đặc tả và để kiểm thử đặc tả phải có

khả năng xử lí với tính không đầy đủ. Một cách tự nhiên điều này làm cho việc phân tích bị

yếu đi, khi có thể được thực hiện bằng cách mở rộng phạm vi các hành vi chấp nhận được

thỏa mãn cho đặc tả, nhưng một sự suy giảm như vậy phải phản ánh các mức độ bất trắc còn

lại.

Nguyên lý 8: Đặc tả phải được cục bộ hoá và được ghép lỏng lẻo.

Các nguyên lí trước xử lí đặc tả như một thực thể tĩnh. Thực thể này nảy sinh từ cái

động của đặc tả. Cần phải thừa nhận rằng mặc dầu mục tiêu chính của một đặc tả là để dùng

làm cơ sở cho thiết kế và cài đặt một hệ thống nào đó, nó không phải là một sự vật tĩnh

dựng sẵn mà là một sự vật động đang trải qua thay đổi đáng kể. Việc thay đổi như thế xuất

hiện trong ba hoạt động chính: phát biểu, khi một đặc tả ban đầu đang đươc tạo ra, phát

triển, khi đặc tả được soạn thảo trong quá trình thiết kế lặp để phản ánh môi trường đã thay

đổi và / hoặc các yêu cầu chức năng phụ.

Với nhiều thay đổi xuất hiện cho đặc tả, điều mấu chốt là nội dung và cấu trúc của

nó được chọn để làm phù hợp hoạt động này. Yêu cầu chính cho sự phù hợp đó là ở chỗ

thông tin bên trong đặc tả phải được cục bộ hoá sao cho chỉ một phần nhỏ (một cách lí

tưởng) cần phải sửa đổi khi thông tin thay đổi, và ở chỗ đặc tả cần được cấu trúc (ghép)

125

một cách lỏng lẻo để cho từng phần có thể được thêm vào hay loại bỏ một cách dễ dàng, và

cấu trúc được điều chỉnh một cách tự động.

Mặc dầu các nguyên lí được Balzer và Goldman tán thành tập trung vào tác động của

đặc tả trên định nghĩa về ngôn ngữ hình thức, những lời bình luận của họ áp dụng được cho

cả mọi dạng đặc tả. Tuy nhiên, các nguyên lí cần phải được dịch thành sự thực hiện. Trong

mục sau chúng ta sẽ xem xét một tập các hướng dẫn để tạo ra một đặc tả các yêu cầu.

Các mức trừu tượng của đặc tả.

Các đặc tả được thể hiện ở một vài mức trừu tượng khác nhau cùng với mối tương

liên giữa các mức ấy. Mỗi mức nhắm đến các đối tượng đọc khác nhau mà họ có quyền

quyết định về việc dựa vào đó mà thực hiện đánh giá bản thiết kế của các nhà phát triển

phần mềm. Các mức đó là:

Mức 1: Định ra yêu cầu.

Được thể hiện bằng ngôn ngữ tự nhiên về các dịch vụ mà hệ thống sẽ phải cung cấp.

Phần này phải được viết sao cho dễ hiểu đối với khách hàng và người quản lý hợp đồng,

người sẽ mua sản phẩm phần mềm và người sẽ sử dụng nó. Kỹ thuật đặc tả phi hình thức

là thích hợp cho mức đặc tả này.

Mức 2: Đặc tả yêu cầu.

Tài liệu nêu ra các dịch vụ một cách chi tiết hơn. Tài liệu này đôi khi còn được gọi là

tài liệu đặc tả chức năng. Yêu cầu đối với đặc tả ở mức này là phải chính xác đến mức có

thể làm cơ sở cho hợp đồng giữa nhà phát triển phần mềm và khách hàng. Đồng thời cũng

cần được viết sao cho dễ hiểu đối với nhân viên kỹ thuật của cả nơi mua phần mềm và nơi

phát triển hệ thống. Kỹ thuật đặc tả hình thức hẳn là thích hợp cho mức đặc tả như vậy,

tuy nhiên cũng còn tuỳ thuộc vào trình độ kiến thức cơ bản của khách hàng. Tốt hơn cả là

ta có thể dùng loại hình hỗn hợp để đặc tả.

Mức 3: Đặc tả phần mềm / đặc tả thiết kế (đây là mô tả trừu tượng cho phần mềm).

Dùng làm cơ sở cho việc thiết kế và thực thi. Cần thể hiện một quan hệ rõ ràng giữa

tư liệu này và đặc tả yêu cầu. Ta phải xác định rằng: đối tượng đọc ở đây chủ yếu là các

kỹ sư phần mềm chứ không phải là người sử dụng hoặc người quản lý. Kỹ thuật đặc tả hình

hình thức là hoàn toàn phù hợp cho mức đặc tả này.

5.3. Sản phẩm của phân tích và đặc tả yêu cầu

5.3.1. Báo cáo khả thi

a. Khi nào nên có báo cáo khả thi

Nếu tiếp cận dưới góc độ là một khoản đầu tư thì việc chủ đầu tư yêu cầu lập báo cáo

tiền khả thi để cân nhắc hiệu quả cũng như những khó khăn có thể gặp phải khi triển khai dự

án phần mềm là cần thiết và đúng đắn.

Có hai trường hợp mà chủ đầu tư cần lập báo cáo tiền khả thi. Một là do yêu cầu về

pháp lý: các tổ chức chính phủ, các doanh nghiệp nhà nước khi muốn triển khai một dự án

CNTT có giá trị lớn buộc phải qua bước này như là một trình tự không thể thiếu của đầu tư

xây dựng cơ bản. Hai là, do đơn vị có cơ cấu tổ chức quá phức tạp, quá nhiều nghiệp vụ đặc

126

thù, nhiều hệ thống con cần thay thế giao diện – tích hợp, đòi hỏi phải có sự lượng định rõ

ràng về giải pháp, đường hướng triển khai.

Trong cả hai trường hợp, trình tự của dự án thường là: (1) Lập báo cáo tiền khả thi;

(2) Thẩm định báo cáo; (3) Trình cấp có thẩm quyền phê duyệt; (4) Tổ chức đấu thầu chọn

nhà triển khai giải pháp. Nếu việc lập báo cáo được thuê ngoài thì sẽ có một bộ phận chức

năng của chủ đầu tư đóng vai trò là người thẩm định. Những dự án đặc biệt phức tạp, việc

lập báo cáo lẫn thẩm định có thể thuê hai đơn vị tư vấn khác nhau đảm nhiệm. Ở Việt Nam,

một số đơn vị do chưa đánh giá đúng tầm quan trọng của việc lập báo cáo tiền khả thi nên

lãnh đạo thường giao việc này cho bộ phận CNTT hay tài chính – kế toán thực hiện. Nếu

việc khảo sát sơ sài, thiếu thông tin thì kết quả báo cáo chỉ là tờ trình ngắn gọn, không đảm

bảo tính toàn diện, khách quan và nghiêm túc, ảnh hưởng đến hiệu quả thực thi dự án sau

này.

b. Nội dung cơ bản

Một báo cáo tiền khả thi đầy đủ thường phải trả lời những câu hỏi sau: Mục đích

hướng tới của dự án là gì? Hệ thống hiện tại có những bất cập nào? Các yêu cầu cụ thể của

nghiệp vụ ra sao? Đâu là những tham số chính (mô hình, quy mô, thời gian và kế hoạch

triển khai) của giải pháp? Số tiền đầu tư dự kiến là bao nhiêu?...

• Phân tích các mục tiêu lớn, tính cấp thiết của dự án. Mục tiêu – tính cấp thiết của

một dự án phần mềm nói riêng và CNTT nói chung thường dựa trên những mục tiêu chung,

những kế hoạch, đề án lớn của tổ chức, những đòi hỏi từ thực tế nghiệp vụ có liên quan tới

sự phát triển, ổn định, thậm chí là sự tồn tại của tổ chức.

• Cơ sở phương pháp luận và cách thức triển khai lập báo cáo. Đây là căn cứ để xác

định xem báo cáo có được xây dựng một cách thực sự khách quan, khoa học hay không.

• Phân tích các bối cảnh chung của dự án: mô hình tổ chức của đơn vị, hiện trạng

triển khai và ứng dụng CNTT trong tác nghiệp và quản lý, các dự án lớn đang được triển

khai có thể ảnh hưởng trực tiếp/gián tiếp tới dự án phần mềm đang đề cập.

• Liệt kê, hệ thống hóa và phân tích các nghiệp vụ có thể sẽ được tác nghiệp trên hệ

thống phần mềm tương lai. Cần chú ý rằng đây là các nghiệp vụ hiện có và không hẳn sẽ

được giải quyết hoàn toàn trên phần mềm vì phải tính đến đặc thù nghiệp vụ cũng như các

ràng buộc về nguồn lực (chi phí, thời gian triển khai)...

• Lựa chọn giải pháp. Người lập báo cáo phải chứng minh được đề xuất của mình

thông qua việc so sánh những ưu – nhược điểm và độ phù hợp với các yêu cầu nghiệp vụ

nêu trên của các giải pháp có trên thị trường, từ đó khuyến nghị một hoặc hai sự lựa chọn tối

ưu nhất.

• Xác định các tham số cơ bản của hệ thống: phạm vị địa lý của dự án; phạm vi

nghiệp vụ (các mô đun) và chi tiết từng nghiệp vụ; quy mô về người sử dụng và khối lượng

giao dịch; kiến trúc hệ thống (kết nối, truyền thông...); các yêu cầu về phần cứng và hạ tầng

đi kèm...

• Các ràng buộc về nguồn lực. Đầu tiên là phân chia giai đoạn và kế hoạch triển khai

cho các giai đoạn đầu tiên. Phần mềm luôn là một dự án lớn, việc triển khai thường được

127

phân thành nhiều giai đoạn với phạm vi địa lý/nghiệp vụ khác nhau. Trong trường hợp bản

thân từng giai đoạn tương đối dài và có quy mô tương đối lớn, có thể tại thời điểm lập báo

cáo chỉ lượng định được tương đối chi tiết cho một hoặc một số giai đoạn đầu tiên. Thứ hai

là dự toán tổng mức đầu tư, cũng như đã phân tích ở trên, phần này có thể bao gồm dự toán

cho giai đoạn đầu và khai toán cho các giai đoạn tiếp theo.

• Đánh giá kết quả của dự án. Nhìn chung, việc đưa ra các tiêu chí đánh giá về hiệu

quả đầu tư của một dự án CNTT là rất phức tạp và phụ thuộc nhiều vào chủ quan, dự án

phần mềm cũng không ngoại lệ. Tuy nhiên, người lập báo cáo vẫn cần đưa ra một số tiêu chí

(có thể là định tính) để lượng định về mức độ thành công của dự án sau này.

c. Những vấn đề cần cân nhắc

Điều đầu tiên phải cân nhắc khi quyết định lập báo cáo tiền khả thi là thời gian có thể

kéo dài hơn dự kiến. Thông thường, quá trình lựa chọn tư vấn, lập báo cáo, thẩm định, trình

duyệt, tổ chức đấu thầu thường kéo dài 6 tháng đến 1 năm. Chất lượng của báo cáo tiền khả

thi cũng như chất lượng của dự án phụ thuộc rất nhiều vào trình độ, kinh nghiệm và sự nhiệt

tình của nhà tư vấn.

Riêng đối với các đơn vị buộc phải lập báo cáo tiền khả thi do yêu cầu về pháp lý, có

thể sẽ vấp phải những bất cập trong các quy định pháp luật hiện hành. Rõ ràng nhất là việc

dự án CNTT phải tuân theo các trình tự, thủ tục, biểu mẫu và các định mức của xây dựng cơ

bản (XDCB). Các từ ngữ của ngành XDCB như “xây lắp”, “thi công” được gắn một cách

khiên cưỡng với các hạng mục khác nhau của dự án phần mềm. Không khó để nhận thấy độ

vênh đáng kể giữa hai loại dự án. Trong khi với dự án XDCB, phần giá trị nằm ở các hạng

mục mang tính vật chất (thiết bị, vật tư, khối lượng thi công...) thì hầu hết giá trị của một dự

án CNTT (trong đó có phần mềm) lại kết tinh chủ yếu trong một sản phẩm phi vật chất là

phần mềm. Bởi thế, định mức cho các hạng mục của dự án XDCB và dự án CNTT là rất

khác nhau. Đơn cử như chi phí cho phần tư vấn lập báo cáo tiền khả thi, vốn chiếm vị trí rất

quan trọng trong dự án CNTT, lại chỉ được xét 0,16% tổng mức đầu tư, nếu dùng định mức

của XDCB.

Về khuyến nghị lựa chọn giải pháp, nhiều người cho rằng, báo cáo tiền khả thi chỉ

nên đưa ra những yêu cầu cho hệ thống chứ không chỉ ra một sản phẩm cụ thể, vì có thể vi

phạm các quy định về đấu thầu. Tuy nhiên, các tiêu chí đánh giá chất lượng phần mềm

tương đối trừu tượng và mang nặng định tính, sẽ rất khó so sánh hai giải pháp khác nhau

nếu chỉ căn cứ vào hồ sơ dự thầu. Thực tế, đơn vị lập báo cáo khả thi sẽ là người có kiến

thức, kinh nghiệm thực tế để đánh giá chất lượng giải pháp, hơn là những thành viên của tổ

chuyên gia đấu thầu sau này.

5.3.2. Mô hình hệ thống

Chúng ta tạo ra các mô hình để thu được hiểu biết rõ hơn về thực thể thực tế cần xây

dựng. Khi thực thể là một vật vật lý (như toà nhà, máy bay, máy móc) thì ta có thể xây dựng

một mô hình giống hệt về hình dạng, nhưng nhỏ hơn về qui mô. Tuy nhiên, khi thực thể cần

xây dựng là phần mềm, thì mô hình của chúng ta phải mang dạng khác. Nó phải có khả

năng mô hình hóa thông tin mà phần mềm biến đổi, các chức năng (và chức năng con) làm

cho phép biến đổi đó thực hiện được, và hành vi của hệ thống khi phép biến đổi xảy ra.

128

Trong khi phân tích các yêu cầu phần mềm, chúng ta tạo ra các mô hình về hệ thống

cần xây dựng. Các mô hình tập trung vào điều hệ thống phải thực hiện, không chú ý đến

cách thức nó thực hiện. Trong nhiều trường hợp, các mô hình chúng ta tạo ra có dùng kí

pháp đồ hoạ mô tả cho thông tin, xử lý, hành vi hệ thống, và các đặc trưng khác thông qua

các biểu tượng phân biệt và dễ nhận diện. Những phần khác của mô hình có thể thuần túy

văn bản. Thông tin mô tả có thể được cung cấp bằng cách dùng một ngôn ngữ tự nhiên hay

một ngôn ngữ chuyên dụng cho mô tả yêu cầu. Các mô hình được tạo ra trong khi phân tích

yêu cầu còn đóng một số vai trò quan trọng:

 Mô hình trợ giúp cho người phân tích trong việc hiểu về thông tin, chức năng và

hành vi của hệ thống, do đó làm cho nhiệm vụ phân tích yêu cầu được dễ dàng và

hệ thống hơn.

 Mô hình trở thành tiêu điểm cho việc xem xét và do đó, trở thành phần mấu chốt

cho việc xác định tính đầy đủ, nhất quán và chính xác của đặc tả.

 Mô hình trở thành nền tảng cho thiết kế, cung cấp cho người thiết kế một cách

biểu diễn chủ yếu về phần mềm có thể được “ánh xạ” vào hoàn cảnh cài đặt.

Dưới đây là một số mô hình (phương pháp) hay được dùng trong phân tích:

1. Biểu đồ luồng dữ liệu

2. Mô hình phân cấp chức năng

3. Mô hình thực thể liên kết

4. Biểu đồ ca sử dụng

…

5.3.3. Tài liệu định nghĩa yêu cầu (requirement definition)

Là văn bản liệt kê các yêu cầu chức năng và yêu cầu phi chức năng.

Ví dụ

1. Các yêu cầu chức năng cơ bản:

* Dữ liệu sử dụng: số thực

* Có các nút bấm thực hiện các chức năng sau :

- Các phím số: dùng để nhập số.

- Dấu bằng (=) : để cho ra kết quả.

- Phép cộng (+) : dùng để cộng 2 hay nhiều số.

- Phép trừ (-): dùng để trừ 2 hay nhiều số.

- Phép nhân (x) : dùng để nhân 2 hay nhiều số.

- Phép chia (÷) : dùng để chia 2 hay nhiều số. Nếu chia cho 0 thì báo lỗi.

- Đổi dấu (±) : đổi dấu của một số từ âm sang dương và ngược lại.

- Tính căn thức(Sqrt) : tính được căn bậc hai của một số dương.

- Tính bình phương (x ) : tính được bình phương của một số bất kì.

- Xóa (Del) : Xóa chử số cuối cùng bên phải của số.

129

- Xóa toàn bộ (C) : xóa số và mọi cài đặt trên máy, để tiến hành tính toán lại.

- Trợ Giúp : để hướng dẫn sử dụng phần mềm.

- About: dùng giới thiệu phần mềm, tác giả...

2. Các yêu cầu phi chức năng:

- Giao diện :

 Thiên về đồ họa, với giao diện giống một chiếc máy tính bỏ túi loại nhỏ.

 Trực quan, dễ sử dụng. Đặc biệt đối với trẻ thơ thì hình ảnh phải sinh động,

ngộ nghĩnh để trẻ cảm thấy thích thú hơn trong lúc học.

 Sử dụng Tiếng Việt.

- Công cụ lập trình : Visual Studio 2008

- Tiến trình thực hiện :

 Ngày bắt đầu: 20/10/2010

 Ngày kết thúc: 18/11/2010

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

Kết quả của bước phân tích là tạo ra bản đặc tả yêu cầu phần mềm (Software

Requirement Specification - SRS). Đặc tả yêu cầu phải chỉ rõ được phạm vi của sản phẩm,

các chức năng cần có, đối tượng người sử dụng và các ràng buộc khi vận hành sản phẩm.

Có nhiều chuẩn khác nhau trong xây dựng tài liệu, dưới đây là một định dạng RSR thông

dụng (theo chuẩn IEEE 830-1984).

1. Giới thiệu

1.1. Mục đích

Mục này giới thiệu mục đích của tài liệu yêu cầu. Thường chỉ đơn giản là định nghĩa

“đây là tài liệu yêu cầu về phần mềm XYZ”.

1.2. Phạm vi

Nêu pham vi đề cập của tài liệu yêu cầu.

1.3. Định nghĩa

Định nghĩa các khái niệm, các từ viết tắt, các chuẩn được sử dụng trong tài liệu yêu

cầu.

1.4. Tài liệu tham khảo

Nêu danh mục các tài liệu tham khảo dùng để tạo ra bản đặc tả yêu cầu.

1.5. Mô tả chung về tài liệu

Mô tả khái quát cấu trúc tài liệu, gồm có các chương, mục, phục lục chính nào.

2. Mô tả chung

2.1. Tổng quan về sản phẩm

Mô tả khái quát về sản phẩm.

2.2. Chức năng sản phẩm

130

Khái quát về chức năng sản phẩm.

2.3. Đối tượng người dùng

Mô tả về đối tượng người dùng.

2.4. Ràng buộc tổng thể

Khái quát về các ràng buộc của phần mềm: ràng buộc phần cứng, môi trường sử

dụng, yêu cầu kết nối với các hệ thống khác...

2.5. Giả thiết và sự lệ thuộc

Mô tả các giả thiết khi áp dụng tài liệu: ví dụ như tên phần cứng, phần mềm, hệ điều

hành cụ thể.

3. Yêu cầu chi tiết

Mô tả các yêu cầu

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

Mô tả chi tiết về các yêu cầu chức năng.

3.1.1. Yêu cầu chức năng 1

3.1.1.1. Giới thiệu

3.1.1.2. Dữ liệu vào

3.1.1.3. Xử lý

3.1.1.4. Kết quả

3.1.2. Yêu cầu chức năng 2

...

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

3.2. Yêu cầu giao diện ngoài

Mô tả các giao diện của phần mềm với môi trường bên ngoài.

3.2.1. Giao diện người dùng

3.2.2. Giao diện phần cứng

3.2.3. Giao diện phần mềm

3.2.4. Giao diện truyền thông

3.3. Yêu cầu hiệu suất

Mô tả về hiệu suất, ví dụ như thời gian phản hồi với sự kiện, số giao dịch được thực

hiện/giây,...

3.4. Ràng buộc thiết kế

Mô tả các ràng buộc thiết kế, ví dụ các ràng buộc về ngôn ngữ, về công nghệ, về cơ

sở dữ liệu và về chuẩn giao tiếp.

3.5 Thuộc tính

Mô tả các thuộc tính của phần mềm.

3.5.1. Tính bảo mật, an toàn và khả năng phục hồi

131

Mức độ bảo mật dữ liệu, cách thức truy cập vào hệ thống. Độ an toàn của hệ thống

đối với các trường hợp bất thường như mất điện... Khả năng phục hồi của hệ thống sau khi

gặp sự cố.

3.5.2 Tính bảo trì

Các chức năng, giao diện đòi hỏi phải dễ sửa đổi (dễ bảo trì).

3.6. Các yêu cầu khác

Các yêu cầu khác liên quan đến sản phẩm.

5.3.5. Tài liệu yêu cầu

Cấu trúc chung của tài liệu yêu cầu phần mềm gồm các phần như sau:

- Giới thiệu: mô tả sự cần thiết của hệ thống. Nó cần sự mô tả sơ lược các chức năng

của mình và giải thích cách làm việc với các hệ thống khác. Nó cũng cần mô tả làm thế nào

hệ thống đáp ứng được toàn bộ các mục tiêu chiến lược và nghiệp vụ.

- Thuật ngữ: nó cần định nghĩa các khái niệm kỹ thuật được sử dụng trong tài liệu

này. Không được giả định người đọc đã có kinh nghiệm.

- Mô hình hệ thống: phần này lập một hoặc nhiều mô hình hệ thống cho biết các quan

hệ giữa các cấu thành hệ thống với hệ thống và môi trường của nó. Nó cần bao gồm các mô

hình đối tượng, mô hình luồng dữ liệu và ngữ nghĩa dữ liệu.

- Định nghĩa yêu cầu chức năng: các dịch vụ cung cấp cho người dùng cần được mô

tả trong mục này. Mô tả có thể dùng ngôn ngữ tự nhiên, sơ đồ hoặc các dạng ghi chép khác

cho phép khách hàng có thể hiểu được.

Các dịch vụ cung cấp cho người dùng cần được mô tả trong mục này. Mô tả có thể

dùng ngôn ngữ tự nhiên, sơ đồ hoặc các dạng ghi chép khác cho phép khách hàng có thể

hiểu được.

- Định nghĩa yêu cầu phi chức năng: các ràng buộc về phần mềm và các hạn chế đối

với thiết kế cần phải được mô tả trong phần này. Nó có thể bao gồm các chi tiết của biểu

diễn dữ liệu, thời gian đáp ứng và yêu cầu bộ nhớ,...Các tiêu chuẩn về sản phẩm và quy

trình cần tuân thủ cũng được mô tả.

- Tiến triển hệ thống: phần này mô tả các giả thiết căn bản làm cơ sở cho hệ thống và

dự đoán các thay đổi về phát triển phần cứng, yêu cầu người dùng

- Đặc tả yêu cầu: mô tả các yêu cầu cơ bản chi tiết hơn. Nếu cần các chi tiết hơn có

thể được thêm vào các yêu cầu phi chức năng, ví dụ giao diện với các hệ thống có thể được

định nghĩa.

- Ngoài ra, tài liệu yêu cầu phần mềm có thể bao gồm thêm các phần sau:

+ Phần cứng: nếu hệ thống được phát triển trên một phần cứng đặc biệt, phần cứng

này và giao diện cần được mô tả. Nếu phần cứng bán sẵn được sử dụng, các cấu hình cực

tiểu và cực đại phải được mô tả.

+ Yêu cầu dữ liệu: tổ chức logic của dữ liệu được sử dụng bởi hệ thống và các quan

hệ giữa chúng được mô tả, có thể dùng sơ đồ thực thể liên kết.

132

+ Chỉ mục có thể được cung cấp. Ví dụ chỉ mục theo chữ cái, chỉ mục theo chương,

theo chức năng....

Do hệ thống được vận hành trong thời gian dài, nên môi trường hệ thống và mục đích

nghiệp vụ có thể thay đổi. Khi đó tài liệu yêu cầu cũng cần phải thay đổi. Với mục đích tiến

triển, tài liệu yêu cầu thường được chia theo hai phân loại:

- Các yêu cầu ổn định: được suy dẫn từ các hoạt động cốt lõi của tổ chức tương đối

liên quan trực tiếp tới miền hệ thống.

- Các yêu cầu bất thường: các yêu cầu có thể thay đổi khi phát triển hệ thống sau này

như: các yêu cầu xuất hiện như là sự hiểu biết của khách hàng về sự phát triển của hệ thống

trong quá trình xây dựng hệ thống, các yêu cầu được sinh ra do sự xuất hiện của việc tin học

hóa làm thay đổi các quy trình nghiệp vụ,...

133

Chương 6. Thiết kế phần mềm

6.1. Khái niệm, nguyên lý, chất lượng thiết kế

6.1.1. Khái niệm

Có thể định nghĩa thiết kế là một quá trình áp dụng nhiều kỹ thuật và các nguyên lý

để tạo ra mô hình của một thiết bị, một tiến trình hay một hệ thống đủ chi tiết mà theo đó có

thể chế tạo ra sản phẩm vật lý tương ứng với nó.

Bản chất thiết kế phần mềm là một quá trình chuyển hóa các yêu cầu phần mềm

thành một biểu diễn thiết kế. Từ những mô tả quan niệm về toàn bộ phần mềm, việc làm

mịn (chi tiết hóa) liên tục dẫn tới một biểu diễn thiết kế rất gần với cách biểu diễn của

chương trình nguồn để có thể ánh xạ vào một ngôn ngữ lập trình cụ thể.

Mục tiêu thiết kế là để tạo ra một mô hình biểu diễn của một thực thể mà sau này sẽ

được xây dựng.

Mô hình chung của một thiết kế phần mềm là một đồ thị có hướng, các nút biểu diễn

các thực thể có trong thiết kế, các liên kết biểu diễn các mỗi quan hệ giữa các thực thể đó.

Hoạt động thiết kế là một loại hoạt động đặc biệt:

- Là một quá trình sáng tạo, đòi hỏi có kinh nghiệm và sự nhanh nhạy và sáng tạo

- Cần phải được thực hành và học bằng kinh nghiệm, bằng khảo sát các hệ đang tồn

tại, chỉ học bằng sách vở là không đủ.

Tầm quan trọng của thiết kế phần mềm có thể được phát biểu bằng một từ “chất

lượng” (quality). Thiết kế là nơi chất lượng phần mềm được nuôi dưỡng trong quá trình phát

triển: cung cấp cách biểu diễn phần mềm có thể được xác nhận về chất lượng, là cách duy

nhất mà chúng ta có thể chuyển hóa một cách chính xác các yêu cầu của khách hàng thành

sản phẩm hay hệ thống phần mềm cuối cùng. Thiết kế phần mềm là công cụ giao tiếp làm

cơ sở để có thể mô tả một cách đầy đủ các dịch vụ của hệ thống, để quản lý các rủi ro và lựa

chọn giải pháp thích hợp. Thiết kế phần mềm phục vụ như một nền tảng cho mọi bước kỹ

nghệ phần mềm và bảo trì. Không có thiết kế có nguy cơ sản sinh một hệ thống không ổn

định - một hệ thống sẽ thất bại. Một hệ thống phần mềm rất khó xác định được chất lượng

chừng nào chưa đến bước kiểm thử. Thiết kế tốt là bước quan trọng đầu tiên để đảm bảo

chất lượng phần mềm.

134

6.1.2. Nguyên lý

- Thiết kế trên cơ sở phân tích: Có thể không ánh xạ 1-1

- Không thiết kế lặp: Sử dụng lại các phần đã có

- Nhất quán và khả hợp: Thiết kế thường do nhiều nhóm cùng làm -> Phải cùng cách

biểu diễn + có thể tích hợp

- Có kiến trúc cao: Để dễ hiểu, tăng tính độc lập, dễ thay đổi

- Không phải là cài đặt: Tổng quát và dễ hiểu hơn cài đặt

- Thiết kế phải được đánh giá chất lượng và thẩm định

+ Chất lượng:

o Tính đúng,

o Tính đầy đủ,

o Tính module,

o Tính độc lập chức năng,

o Hiệu quả thuật toán,

o Hiệu quả tương tác,

o Tính dễ hiểu...

+ Thẩm định:

o Xét mức độ đạt các tiêu chuẩn chất lượng

- Thường xuyên review khi thiết kế: Quy trình thiết kế cần có những điểm mốc rò

ràng

6.1.3. Chất lượng thiết kế

Không có cách nào hay để xác định được thế nào là thiết kế tốt. Tiêu chuẩn dễ bảo trì

là tiêu chuẩn tốt cho người dùng. Một thiết kế dễ bảo trì có thể thích nghi với việc cải biên

các chức năng và việc thêm các chức năng mới. Một thiết kế như thế phải dễ hiểu và việc

sửa đổi chỉ có hiệu ứng cục bộ. Các thành phần thiết kế phải là kết dính (cohesive) theo

nghĩa là tất cả các bộ phận trong thành phần phải có một quan hệ logic chặt chẽ, các thành

phần ghép nối (coupling) với nhau là lỏng lẻo. Ghép nối càng lỏng lẻo thì càng dễ thích

nghi, nghĩa là càng dễ sửa đổi để phù hợp với hoàn cảnh mới.

Để xem một thiết kế có là tốt hay không, người ta tiến hành thiết lập một số độ đo

chất lượng thiết kế:

1) Sự kết dính của một môđun là độ đo về tính khớp lại vớiSự kết dính (Cohesion):

nhau của các phần trong môđun đó. Nếu một môđun chỉ thực hiện một chức năng logic hoặc

là một thực thể logic, tức là tất cả các bộ phận của môđun đó đều tham gia vào việc thực

hiện một công việc thì độ kết dính là cao. Nếu một hoặc nhiều bộ phận không tham gia trực

tiếp vào việc chức năng logic đó thì mức độ kết dính của nó là thấp. Thiết kế là tốt khi độ

kết dính cao. Khi đó chúng ta sẽ dễ dàng hiểu được từng môđun và việc sửa chữa một

môđun sẽ không (ít) ảnh hưởng tới các môđun khác. Constantine và Yourdon định ra 7 mức

kết dính theo thứ tự tăng dần sau đây:

135

a. Kết dính gom góp: các công việc không liên quan với nhau, song lại bị bó vào một

môđun.

b. Kết dính logic: các thành phần cùng thực hiện các chức năng tương tự về logic

chẳng hạn như vào/ra, xử lý lỗi,... được đặt vào cùng một mô đun.

c. Kết dính thời điểm: tất cả các thành phần cùng hoạt hóa một lúc, chẳng hạn như

các thao tác khởi tạo được bó lại với nhau.

d. Kết dính thủ tục: các phần tử trong môđun được ghép lại trong một dãy điều

khiển.

e. Kết dính truyền thông: tất cả các phần tử của môđun cùng thao tác trên một dữ liệu

vào và đưa ra cùng một dữ liệu ra.

f. Kết dính tuần tự: trong một môđun, đầu ra của phần tử này là đầu vào của phần tử

khác.

g. Kết dính chức năng: Mỗi phần của môđun đều là cần thiết để thi hành cùng một

chức năng nào đó. Các lớp kết dính này không được định nghĩa chặt chẽ và cũng không phải

luôn luôn xác định được. Một đối tượng kết dính nếu nó thể hiện như một thực thể đơn: tất

cả các phép toán trên thực thể đó đều nằm trong thực thể đó.

h. Kết dính đối tượng: mỗi phép toán đều liên quan đến thay đổi, kiểm tra và sử dụng

thuộc tính của một đối tượng, là cơ sở cung cấp các dịch vụ của đối tượng.

2) Ghép nối là độ đo sự nối ghép với nhau giữa các đơn vịSự ghép nối (Coupling):

(môđun) của hệ thống. Hệ thống có nối ghép cao thì các môđun phụ thuộc lẫn nhau lớn. Hệ

thống nối ghép lỏng lẻo thì các môđun là độc lập hoặc là tương đối độc lập với nhau và

chúng ta sẽ dễ bảo trì nó. Các mô đun được ghép nối chặt chẽ nếu chúng dùng các biến

chung và nếu chúng trao đổi các thông tin điều khiển (ghép nối chung nhau và ghép nối điều

khiển). Ghép nối lỏng lẻo đạt được khi bảo đảm rằng các thông tin cục bộ được che dấu

trong các môđun và các môđun trao đổi thông tin thông qua danh sách tham số (giao diện)

xác định. Có thể chia ghép nối thành các mức từ chặt chẽ đến lỏng lẻo như sau:

a. Ghép nối nội dung: hai hay nhiều môđun dùng lẫn dữ liệu của nhau, đây là mức

xấu nhất, thường xẩy ra đối với các ngôn ngữ mức thấp dùng các dữ liệu toàn cục hay lạm

dụng lệnh GOTO.

b. Ghép nối chung: một số môđun dùng các biến chung, nếu xẩy ra lỗi thao tác dữ

liệu, sẽ khó xác định được lỗi đó do môđun nào gây ra.

c. Ghép nối điều khiển: một môđun truyền các thông tin điều khiển để điều khiểnhoạt

động của một môđun khác.

d. Ghép nối dư thừa: môđun nhận thông tin thừa không liên quan trực tiếp đến chức

năng của nó, điều này sẽ làm giảm khả năng thích nghi của môđun đó.

e. Ghép nối dữ liệu: Các môđun trao đổi thông tin thông qua tham số và giá trị trả lại.

f. Ghép nối không có trao đổi thông tin: môđun thực hiện một chức năng độc lập và

hoàn toàn không nhận tham số và không có giá trị trả lại.

136

Ưu việt của thiết kế hướng đối tượng là do bản chất che dấu thông tin của đối tượng

dẫn tới việc tạo ra các hệ ghép nối lỏng lẻo. Việc thừa kế trong hệ thống hướng đối tượng lại

dẫn tới một dạng khác của ghép nối, ghép nối giữa đối tượng mức cao và đối tượng kế thừa

nó.

3) Sự hiểu được của thiết kế liên quan tới một sốSự hiểu được (Understandability):

đặc trưng sau đây:

a. Tính kết dính: có thể hiểu được thành phần đó mà không cần tham khảo tới một

thành phần nào khác hay không?

b. Đặt tên: phải chăng là mọi tên được dùng trong thành phần đó đều có nghĩa? Tên

có nghĩa là những tên phản ánh tên của thực thể trong thế giới thực được mô hình bởi thành

phần đó.

c. Soạn tư liệu: Thành phần có được soạn thảo tư liệu sao cho ánh xạ giữa các thực

thể trong thế giới thực và thành phần đó là rõ ràng.

d. Độ phức tạp: độ phức tạp của các thuật toán được dùng để thực hiện thành phần đó

như thế nào? Độ phức tạp cao ám chỉ nhiều quan hệ giữa các thành phần khác nhau của

thành phần thiết kế đó và một cấu trúc logic phức tạp mà nó dính líu đến độ sâu lồng nhau

của cấu trúc ifưthenưelsse. Các thành phần phức tạp là khó hiểu, vì thế người thiết kế nên

làm cho thiết kế thành phần càng đơn giản càng tốt. Đa số công việc về đo chất lượng thiết

kế được tập trung vào cố gắng đo độ phức tạp của thành phần và từ đó thu được một vài độ

đo về sự dễ hiểu của thành phần. Độ phức tạp phản ánh độ dễ hiểu, nhưng cũng có một số

nhân tố khác ảnh hưởng đến độ dễ hiểu, chẳng hạn như tổ chức dữ liệu và kiểu cách mô tả

thiết kế. Các số đo độ phức tạp có thể chỉ cung cấp một chỉ số cho độ dễ hiểu của một thành

phần.

4) Một thiết kế dễ bảo trì thì nó phải sẵn sàngSự thích nghi được (Adaptability):

thích nghi được, nghĩa là các thành phần của chúng nên được ghép nối lỏng lẻo. Một thành

phần có thể là ghép nối lỏng lẻo theo nghĩa là chỉ hợp tác với các thành phần khác thông qua

việc truyền các thông báo. Sự thích nghi được còn có nghĩa là thiết kế phải được soạn thảo

tư liệu tốt, dễ hiểu và nhất quán.

Để có độ thích nghi thì hệ thống còn cần phải phải tự chứa. Muốn là tự chứa một

cách hoàn toàn thì một hệ thống không nên dùng các thành phần khác được xác định ngoại

lai. Tuy nhiên, điều đó lại mâu thuẫn với kinh nghiệm nói rằng các thành phần hiện có nên

là dùng lại được. Vậy là cần có một cân bằng giữa tính ưu việt của sự dùng lại các thành

phần và sự mất mát tính thích nghi được của hệ thống. Một trong những ưu việt chính của

kế thừa trong thiết kế hướng đối tượng là các thành phần này có thể sẵn sàng thích nghi

được. Cơ cấu thích nghi được này không dựa trên việc cải biên thành phần đã có mà dựa

trên việc tạo ra một thành phần mới thừa kế các thuộc tính và các chức năng của thành phần

đó. Chúng ta chỉ cần thêm các thuộc tính và chức năng cần thiết cho thành phần mới. Các

thành phần khác dựa trên thành phần cơ bản đó sẽ không bị ảnh hưởng gì.

137

6.2. Nhiệm vụ thiết kế

6.2.1. Thiết kế kiến trúc (architectural design)

Thiết kế kiến trúc là quá trình xác định các hệ thống con của hệ thống và cơ cấu tổ

chức (framework) việc điều khiển giao tiếp giữa các hệ thống con. Kết quả ra của tiến trình

thiết kế kiến trúc là sự mô tả về kiến trúc phần mềm

Hệ thống con là một hệ thống trong hệ thống tổng thể mà các hoạt động của nó độc

lập với các dịch vụ được cung cấp từ các hệ thống con khác

Mô đun là một thành phần hệ thống cung cấp các dịch vụ cho các thành phần khác

nhưng không được xem như một hệ thống riêng biệt

Đặc điểm thiết kế kiến trúc phần mềm

- Là giai đoạn đầu của quá trình thiết kế

- Biểu diễn sự kết nối giữa đặc tả yêu cầu và các tiến trình thiết kế

- Thường tiến hành song song với các hoạt động đặc tả phần mềm

- Bao gồm việc xác định các thành phần hệ thống và giao tiếp giữa chúng

Vai trò của thiết kế kiến trúc phần mềm

- Giao tiếp giữa khách hàng và nhà phát triển

- Kiến trúc phần mềm là tiêu điểm cho sự thảo luận giữa khách hàng và nhà phát

triển

- Phân tích hệ thống

- Là phương tiện để phân tích khả thi về các yêu cầu phi chức năng của hệ thống

- Sử dụng lại

- Kiến trúc này có thể được sử dụng lại cho nhiều hệ thống

Tiến trình

- Cấu trúc hóa hệ thống: phân chia hệ thống thành các hệ con (sub-system) độc lập và

xác định trao đổi thông tin giữa các hệ con

- Mô hình hóa điều khiển: xác lập mô hình điều khiển giữa các phần của hệ thống

- Phân rã module: phân rã các hệ con thành các module

138

6.2.2. Thiết kế dữ liệu (data design)

Xây dựng mô hình biểu diễn thông tin cần xử lý: mức logic và mức vật lý

Tìm kiếm biểu diễn luận lý cho các phần tử dữ liệu đã được nhận diện trong giai

đoạn phân tích yêu cầu

Thiết kế các cấu trúc dữ liệu của chương trình và cơ sở dữ liệu

Thực hiện tinh chế từng bước

- Các tiêu chí thiết kế hệ cơ sở dữ liệu

+ Không dư thừa dữ liệu

+ Tối ưu hóa không gian lưu trữ

+ Chuẩn hóa cơ sở dữ liệu bằng lược đồ ERD và dạng chuẩn 3

- Một số nguyên tắc

+ Nhận diện cả cấu trúc dữ liệu và tác vụ truy xuất

+ Chú ý sử dụng từ điển dữ liệu

+ Trì hoãn thiết kế dữ liệu mức thấp cho đến cuối giai đoạn này

+ Che dấu biểu diễn bên trong của cấu trúc dữ liệu

+ Phát triển một thư viện các cấu trúc dữ liệu + tác vụ thường gặp

+ Nên áp dung kiểu ADT trong thiết kế cũng như trong lập trình

6.2.3. Thiết kế chức năng (functional design)

Thiết kế các thành phần, giải thuật xử lý thông tin

6.2.4. Thiết kế giao diện người dùng (interface design)

Thiết kế hệ thống máy tính bao gồm một phổ rất rộng các công việc từ thiết kế phần

cứng cho đến thiết kế giao diện người sử dụng. Giao diện của hệ thống thường là tiêu chuẩn

so sánh để phán xét về hệ thống. Giao diện được thiết kế kém sẽ gây ra những nhầm lẫn cho

người sử dụng, khiến cho họ không sử dụng được các chức năng cần thiết và trong trường

hợp xấu có thể thực hiện các thao tác nguy hiểm như phá hủy thông tin cần thiết.

Tầm quan trọng của giao diện còn được xem xét trên hai yếu tố:

- Khía cạnh nghiệp vụ: người dùng thông qua giao diện để tương tác với hệ thống,

đây là khâu nghiệp vụ thủ công duy nhất do đó nếu được thiết kế tốt sẽ nâng cao tốc độ xử

lý công việc và dẫn tới hiệu quả kinh tế cao.

- Khía cạnh thương mại: đối với các sản phẩm bán hàng loạt, giao diện được thiết kế

tốt (dễ sử dụng, đẹp) sẽ gây ấn tượng với khách hàng và là yếu tố chính khi khách hàng

chọn mua sản phẩm.

Ngoài các yếu tố hiệu quả công việc, đẹp, dễ học dễ sử dụng, một thiết kế giao diện

hiện đại nên có tính độc lập cao với khối chương trình xử lý dữ liệu. Đối với nhiều hệ thống,

giao diện là bộ phận có tầm quan trọng chủ chốt và có yêu cầu sửa đổi thường xuyên. Do

đó, để tiện cho việc sửa đổi, giao diện nên được thiết kế có tính môđun hóa cao và nên có độ

độc lập tối đa với khối chương trình xử lý dữ liệu. Điều này cũng dẫn đến khả năng chúng ta

139

có thể xây dựng nhiều giao diện khác nhau cho các đối tượng sử dụng khác nhau hay chạy

trên các hệ thống khác nhau.

a. Nguyên lý thiết kế giao diện

• Hướng người dùng: đối tượng người dùng phải rõ ràng, giao diện nên được thiết kế

có tính đến năng lực, thói quen... của loại đối tượng đó.

• Có khả năng tùy biến cao: giao diện nên có khả năng tùy biến cao để phục vụ cho

các cá nhân có cách sử dụng khác nhau, các môi trường hoạt động khác nhau.

• Nhất quán: các biểu tượng, thông báo, cách thức nhập dữ liệu phải nhất quán và nên

tuân theo các chuẩn thông thường.

• An toàn: nên có chế độ xác nhận lại đối với các thao tác nguy hiểm (như xóa dữ

liệu) và nên có khả năng phục hồi trạng thái cũ (undo).

• Dễ học, dễ sử dụng: giao diện luôn cần được thiết kế hướng tới tính dễ học, dễ sử

dụng, tức là không đòi hỏi người dùng phải có các năng lực đặc biệt. Ví dụ như không cần

nhớ nhiều thao tác, không đòi hỏi phải thao tác nhanh, các thông tin trên màn hình dễ

đọc... Một cách tốt nhất để xây dựng giao diện dễ học dễ sử dụng là tuân theo các chuẩn

giao diện thông dụng.

b. Các loại giao diện

Có hai dòng giao diện chính là:

- Giao diện dòng lệnh: là loại giao diện đơn giản nhất, thường được thiết kế gắn chặt

với chương trình và có tính di chuyển cao (tương đương với chương trình). Giao diện dòng

lệnh phù hợp với các ứng dụng thuần túy xử lý dữ liệu, nhất là đối với các chương trình mà

đầu ra là đầu vào của chương trình khác. Giao diện dòng lệnh gọn nhẹ, dễ xây dựng nhưng

thường khó học, khó sử dụng và chỉ phù hợp với người dùng chuyên nghiệp trong các ứng

dụng đặc thù.

- Giao diện đồ họa: sử dụng các cửa sổ, menu, icon... cho phép người dùng có thể

truy cập song song đến nhiều thông tin khác nhau; người dùng thường tương tác bằng cách

phối hợp cả bàn phím và con chuột; giao diện đồ họa dễ học, dễ sử dụng và trở nên rất

thông dụng và có độ chuẩn hóa cao.

Nhìn trên khía cạnh độc lập với khối chương trình xử lý, có một số cách thức xây

dựng giao diện khác nhau:

- Giao diện đồ họa (GUI) truyền thống: là giao diện đồ họa được thiết kế có độ liên

kết cao với chương trình (được xây dựng cùng ngôn ngữ, cùng bộ công cụ...), hầu hết các

chương trình trên máy tính cá nhân sử dụng loại giao diện này.

- X protocol: giao diện đồ họa sử dụng giao thức X protocol, phổ biến trên các máy

Unix/Linux. Loại giao diện này có ưu diểm là có thể hoạt động độc lập với khối chương

trình còn lại, tức là ta có thể chạy giao diện trên một máy tính trong khi đó phần xử lý bên

trong lại hoạt động trên một máy khác. Đáng tiếc là phương thức này vẫn chưa phổ biến trên

các máy tính cá nhân (chạy hệ điều hành MS Windows).

140

- Client/server: một cách tiếp cận để hướng tới tính độc lập và khả chuyển của giao

diện là xây dựng giao diện như là một chương trình client, tương tác với khối chương trình

xử lý (server) thông qua các giao thức trao đổi thông tin trên mạng (TCP/IP).

- Web based: một trong các cách thức xây dựng giao diện phổ biến hiện nay là dựa

trên nền web, sử dụng các trình duyệt web để trao dổi thông tin với server. Tuy có một số

nhược điểm về an toàn thông tin và tốc độ nhưng với tính độc lập hoàn toàn với phần xử lý,

độ chuẩn hóa cao và khả năng sẵn có trên hầu hết các thiết bị nối mạng, phương thức này

đang được ứng dụng rộng rãi.

c. Các cách tương tác

* Tương tác trực tiếp với thông tin

- ví dụ: soạn thảo; nhập dữ liệu vào các form…

- ưu điểm:

+ dễ học, dễ sử dụng

+ nhận được tức thời kết quả thao tác

- nhược điểm

+ cài đặt phức tạp, tốn tài nguyên phần cứng

* Tương tác gián tiếp

- ví dụ: chọn lệnh từ menu, giao diện dòng lệnh

- Nhược điểm: kém trực quan

- Ưu điểm: thuận tiện khi lặp lại thao tác phức tạp

- Có 2 cách: Sử dụng thực đơn (menu) và Đối thoại (Dialog)

+ Sử dụng thực đơn (menu): Không cần nhớ lệnh, Tối thiểu hóa dùng bàn phím,

Tránh các lỗi như sai lệnh, sai tham số, Dễ dàng tạo các trợ giúp theo ngữ cảnh

+ Đối thoại (Dialog): Dùng khi cần người dùng đưa ra lựa chọn quyết định

d. Một số vấn đề thiết kế

Trong thiết kế giao diện, cần chú ý tới một số vấn đề sau:

1. Thời gian phản hồi. Chúng ta cần quan tâm tới hai loại thời gian là

• Thời gian đáp ứng trung bình: là thời gian trung bình mà hệ thống phản hồi đối với

một yêu cầu của người dùng. Thời gian để sinh ra “kết quả thực sự” của yêu cầu sẽ phụ

thuộc vào bản chất yêu cầu, thuật toán, tốc độ của máy tính, tuy nhiên chúng ta cần quan

tâm khía cạnh tâm lý là nếu người dùng đợi quá lâu mà không nhận được thông tin gì thì họ

sẽ nghĩ là có vấn đề và có thể sẽ tiến hành các thao tác ngoài mong đợi như lặp lại thao tác

hay dừng hệ thống.

• Độ biến thiên của thời gian: độ biến thiên của thời gian cũng là đại lượng cần quan

tâm. Nếu độ biến thiên lớn, ví dụ một thao tác thường được đáp ứng trong 1 giây mà có

trường hợp phải mất 5 giây mới hoàn thành thì cũng có thể làm cho người dùng đưa ra các

thao tác sai.

141

2. Các tiện ích. Một giao diện tốt cần có các tiện ích để trợ giúp người sử dụng. Có

các loại tiện ích sau

• Tích hợp: là tiện ích được tích hợp vào giao diện như nút Help cung cấp các thuyết

minh về thao tác.

• Phụ thêm: là các tiện ích phụ thêm như các tài liệu trực tuyến.

• Macro: một số chương trình còn cho phép người dùng tự động hóa một số thao tác

bằng các lệnh kiểu macro.

3. Thông báo. Các thông báo do hệ thống đưa ra cần

• Có nghĩa: mọi thông báo cần có nghĩa đối với người dùng.

• Ngắn gọn: các thông báo cần ngắn gọn đi vào bản chất vấn đề, đặc biệt là đối với

kiểu giao diện dòng lệnh.

• Có tính xây dựng: thông báo nên có tính xây dựng như đưa ra các nguyên nhân và

các hướng khắc phục.

6.3. Yêu cầu đối với thiết kế

- Linh hoạt đối với những yêu cầu thay đổi không định trước.

- Dễ thử nghiệm.

- Tính sáng sủa, dễ đọc

- Kích thước module nhỏ

- Tính độc lập module (tính mở/đóng giứa các module), sử dụng yếu tố "hộp

- Phải quan hệ chặt chẽ giữa thiết kế và yêu cầu.

- Mỗi module hoàn toàn độc lập, nó thực hiện một chức năng duy nhất và thực hiện

trọn vẹn chức năng đó.

- Mọi thứ trong module ràng buộc với nhau qua việc xử lý nối tiếp nhau trên cùng

một dòng dữ liệu.

- Mọi thứ trong module được điều khiển bởi cùng một dữ liệu vào, hay cùng một

phức hợp thiết bị, hay cùng thực hiện từng phần của cùng một kết xuất.

- Module có thể hiểu được hoàn toàn dựa vào những tham biến truyền cho nó và

nhận từ nó.

- Khi thiết kế cố gắng giảm thiểu cấu trúc bằng việc tản ra nhiều và cố gắng co cụm

khi chiều sâu tăng thêm.

142

- Giữ phạm vi hiệu quả của một module bên trong phạm vi kiểm soát của module đó.

+ Phạm vi hiệu quả của module m được định nghĩa là tất cả các module khác bị ảnh

hưởng bởi một quyết định thực hiện trong module m.

+ Phạm vi kiểm soát của module m là tất cả các module và mọi module thuộc cấp và

thuộc cấp cuối cùng đối với module m.

- Ước lượng giao diện module để giảm độ phức tạp, dư thừa và tăng tính nhất

- Xác định các module có chức năng dự kiến được.

- Cố gắng giữ các module một đầu vào và một đầu ra, tránh các "mối nối bệnh

6.4. Phương pháp và công cụ

6.4.1. Phương pháp thiết kế

a. Hướng chức năng

* Cách tiếp cận hướng chức năng

Thiết kế hướng chức năng là một cách tiếp cận thiết kế phần mềm trong đó bản thiết

kế được phân giải thành một bộ các đơn thể tác động lẫn nhau, mà mỗi đơn thể có một chức

năng được xác định rõ ràng. Các chức năng có các trạng thái cục bộ nhưng chúng chia sẻ

với nhau trạng thái hệ thống, trạng thái này là tập trung và mọi chức năng đều có thể truy

cập được. Nhiều tổ chức đã phát triển các chuẩn và các phương pháp dựa trên sự phân giải

chức năng. Nhiều phương pháp thiết kế kết hợp với công cụ CASE đều là hướng chức năng.

Vô khối các hệ thống đã được phát triển bằng cách sử dụng phương pháp tiếp cận hướng

143

chức năng. Các hệ thống đó sẽ được bảo trì cho một tương lai xa xôi. Bởi vậy thiết kế

hướng chức năng vẫn sẽ còn được tiếp tục sử dụng rộng rãi.

Trong thiết kế hướng chức năng, người ta dùng các biểu đồ luồng dữ liệu (mô tả việc

xử lý dữ liệu), các lược đồ cấu trúc (nó chỉ ra cấu trúc của phần mềm), và các mô tả thiết kế

chi tiết. Thiết kế hướng chức năng gắn với các chi tiết của một thuật toán của chức năng đó

nhưng các thông tin trạng thái hệ thống là không bị che dấu. Việc thay đổi một chức năng và

cách nó sử dụng trạng thái của hệ thống có thể gây ra những tương tác bất ngờ đối với các

chức năng khác. Cách tiếp cận chức năng để thiết kế là tốt nhất khi mà khối lượng thông tin

trạng thái hệ thống được làm nhỏ nhất và thông tin dùng chung nhau là rõ ràng.

* Biểu đồ luồng dữ liệu

Biểu đồ luồng dữ liệu chỉ ra cách thức biến đổi dữ liệu vào thành dữ liệu ra thông qua

một dãy các phép biến đổi. Bước thứ nhất của thiết kế hướng chức năng là phát triển một

biểu đồ luồng dữ liệu hệ thống. Biểu đồ này không nhất thiết bao gồm các thông tin điều

khiển nhưng nên lập tư liệu các phép biến đổi dữ liệu. Biểu đồ luồng dữ liệu là một phần

hợp nhất của một số các phương pháp thiết kế và các công cụ CASE thường trợ giúp cho

việc tạo ra biểu đồ luồng dữ liệu.

* Lược đồ cấu trúc

Lược đồ cấu trúc chỉ ra cấu trúc các thành phần theo thứ bậc của hệ thống. Nó chỉ ra

rằng các phần tử của một biểu đồ luồng dữ liệu có thể được thực hiện như thế nào với tư

cách là một thứ bậc của các đơn vị chương trình. Lược đồ cấu trúc có thể được dùng như là

một mô tả chương trình nhìn thấy được với các thông tin xác định các sự lựa chọn và các

vòng lặp. Lược đồ cấu trúc được dùng để trình bày một tổ chức tĩnh của thiết kế.

* Các từ điển dữ liệu

Từ điển dữ liệu vừa có ích cho việc bảo trì hệ thống vừa có ích trong quá trình thiết

kế. Với mỗi khái niệm thiết kế, cần có một từ khóa mô tả ứng với từ khóa (entry) của từ

điển dữ liệu cung cấp thông tin về khái niệm đó (kiểu, chức năng của dữ liệu...). Đôi khi

người ta gọi cái này là một mô tả ngắn của chức năng thành phần. Các từ điển dữ liệu dùng

để nối các mô tả thiết kế kiểu biểu đồ và các mô tả thiết kế kiểu văn bản. Một vài bộ công

cụ CASE cung cấp một phép nối tự động biểu đồ luồng dữ liệu và từ điển dữ liệu.

b. Hướng đối tượng

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

Thiết kế hướng đối tượng dựa trên chiến lược che dấu thông tin cấu trúc vào bên

trong các thành phần. Cái đó ngầm hiểu rằng việc kết hợp điều khiển logic và cấu trúc dữ

liệu được thực hiện trong thiết kế càng chậm càng tốt. Liên lạc thông qua các thông tin trạng

thái dùng chung (các biến tổng thể) là ít nhất, nhờ vậy khả năng hiểu được nâng lên. Thiết

kế là tương đối dễ thay đổi vì sự thay đổi cấu trúc một thành phần có thể không cần quan

tâm tới các hiệu ứng phụ trên các thành phần khác.

Việc che dấu thông tin trong thiết kế hướng đối tượng là dựa trên sự nhìn hệ phần

mềm như là một bộ các đối tượng tương tác với nhau chứ không phải là bộ các chức năng

như cách tiếp cận chức năng. Các đối tượng có một trạng thái riêng được che dấu và các

144

phép toán trên trạng thái đó. Thiết kế biểu thị các dịch vụ được yêu cầu cùng với những hỗ

trợ mà các đối tượng có tương tác với nó cung cấp.

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

Thiết kế hướng đối tượng bao gồm các đặc trưng chính sau:

1. Không có vùng dữ liệu dùng chung. Các đối tượng liên lạc với nhau bằng cách

trao đổi thông báo.

2. Các đối tượng là các thực thể độc lập, dễ thay đổi vì rằng tất cả các trạng thái và

các thông tin biểu diễn chỉ ảnh hưởng trong phạm vi chính đối tượng đó thôi. Các thay đổi

về biểu diễn thông tin có thể được thực hiện không cần sự tham khảo tới các đối tượng

khác.

3. Các đối tượng có thể phân tán và có thể hoạt động tuần tự hoặc song song. Đây là

một trong những lý do khiến cho thiết kế hướng đối tượng được sử dụng rộng rãi trong các

hệ thống nhúng.

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

Cơ sở của thiết kế hướng đối tượng là các lớp. Lớp là một trừu tượng mô tả cho một

nhóm sự vật. Đối tượng của một lớp là một thực thể (cụ thể hóa) của lớp đó. Thiết kế của

một lớp bao gồm:

- Cấu trúc dữ liệu (thuộc tính)

- Hàm, thủ tục (chức năng)

- Giao diện (cung cấp khả năng trao đổi dữ liệu đối với các lớp khác, về bản chất là

các chức năng của đối tượng)

Việc cài đặt các giao diện là một yếu tố quan trọng để đảm bao che dấu cấu trúc dữ

liệu. Tức là thiết kế nội tại của đối tượng độc lập với giao diện do đó chúng ta có thể sửa đổi

thiết kế mà không sợ ảnh hưởng tới các đối tượng khác.

Các đối tượng trao đổi với nhau bằng cách truyền các thông báo. Tức là một đối

tượng yêu cầu một đối tượng khác thực hiện một chức năng nào đó. Thông báo bao gồm:

tên đối tượng, tên phương thức, và các tham số.

Vòng đời của một đối tượng khi hệ thống hoạt động như sau:

- Khởi tạo: hệ thống tạo ra đối tượng bằng cách xác lập vùng dữ liệu đồng thời tự

động thực hiện các chức năng liên quan đến khởi tạo đối tượng.

- Hoạt động: đối tượng nhận các thông báo và thực hiện các chức năng được yêu cầu.

- Phá hủy: hệ thống giải phóng vùng nhớ đã được cấp phát sau khi thực hiện tự động

các thao tác cần thiết để hủy đối tượng.

Nhờ có chức năng khởi tạo và phá hủy được gọi tự động chúng ta có thể tự động hóa

được một số công việc và tránh được nhiều sai sót trong lập trình như quên khởi tạo dữ liệu,

quên cấp phát hay quên giải phóng vùng nhớ động.

- Sự kế thừa. Kế thừa là một khái niệm quan trọng trong thiết kế hướng đối tượng.

Một lớp có thể được định nghĩa dựa trên sự kế thừa một hoặc nhiều lớp đã được định nghĩa.

Kế thừa ở đây bao gồm

145

- Kế thừa cấu trúc dữ liệu

- Kế thừa chức năng

Khả năng kế thừa giúp cho rút gọn được chương trình và nâng cao tính tái sử dụng.

Một chiến lược chung là trước tiên tạo ra các lớp trừu tượng (để có thể dùng chung) và đối

với các bài toán cụ thể tạo ra các lớp kế thừa bằng cách thêm các thông tin đặc thù.

* Các bước thiết kế

Thiết kế hướng đối tượng bao gồm các bước chính sau:

1. Xác định lớp đối tượng.

2. Xác định thuộc tính cho lớp: các biến của lớp

3. Xác định hành vi (chức năng): các hàm

4. Xác định tương tác giữa các lớp đối tượng: giao diện (thông báo).

5. Áp dụng tính kế thừa: xây dựng các lớp trừu tượng có các thuộc tính chung, đây là

một khâu đặc trưng của thiết kế hướng đối tượng.

Ví dụ, giả sử cần xây dựng các lớp hình tròn, elíp và đa giác. Có thể thấy elip và hình

tròn có một số các thuộc tính chung như tọa độ tâm, chúng ta có thể xây dựng lớp hình nón

chứa các thuộc tính chung này. Giữa hình nón và đa giác lại có thể tìm ra các thuộc tính

chung như mầu nền, mầu biên..., và có thể xây dựng lớp trừu tượng hình hình học chứa các

thuộc tính này.

Phương pháp xác định đối tượng Xác định đối tượng là một trong nhưng công đoạn

thiết kế quan trọng, phụ thuộc nhiều vào kinh nghiệm và bài toán cụ thể. Có một số phương

pháp được đề xuất, một trong các phương pháp này là phân tích từ vựng của “câu yêu cầu”.

Cụ thể là danh từ trong câu yêu cầu sẽ được coi là đối tượng và động từ sẽ được coi là chức

năng.

Ví dụ: Với yêu cầu Phần mềm Email cung cấp cho user khả năng gửi thư, đọc thư và

soạn thảo thư điện tử., chúng ta có thể sơ bộ tạo ra các đối tượng phần mềm, user, email và

các chức năng gửi, nhận, soạn thảo.

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

Thiết kế hướng đối tượng có các ưu điểm chính sau:

• Dễ bảo trì vì các đối tượng là độc lập. Các đối tượng có thể hiểu và cải biên như là

một thực thể độc lập. Thay đổi trong thực hiện một đối tượng hoặc thêm các dịch vụ sẽ

không làm ảnh hưởng tới các đối tượng hệ thống khác.

• Các đối tượng là các thành phần dùng lại được thích hợp do tính độc lập của chúng

và khả năng kế thừa cao.

• Có một vài lớp hệ thống thể hiện phản ánh quan hệ rõ ràng giữa các thực thể có

thực (chẳng hạn như các thành phần phần cứng) với các đối tượng điều khiển nó trong hệ

thống. Điều này đạt được tính dễ hiểu của thiết kế.

Nhược điểm chính của thiết kế hướng đối tượng là sự khó nhận ra các đối tượng của

một hệ thống. Cách nhìn tự nhiên đối với nhiều hệ thống là cách nhìn chức năng.

146

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

Thiết kế hướng đối tượng là một chiến lược thiết kế, không phụ thuộc vào ngôn ngữ

thực hiện cụ thể nào. Các ngôn ngữ lập trình hướng đối tượng có các khả năng bao gói đối

tượng, và kế thừa làm cho việc thực hiện thiết kế hướng đối tượng an toàn hơn và đơn giản

hơn.

Một thiết kế hướng đối tượng cũng có thể được thực hiện trong một ngôn ngữ thủ tục

kiểu như PASCAL hoặc C (không có các đặc điểm bao gói như vậy). Ada không phải là

ngôn ngữ lập trình hướng đối tượng vì nó không trợ giúp sự thừa kế của các lớp, nhưng lại

có thể thực hiện các đối tượng trong Ada bằng cách sử dụng các gói hoặc các nhiệm vụ

(tasks), do đó Ada cũng được dùng để mô tả các thiết kế hướng đối tượng.

Tuy nhiên, cũng phải nhấn mạnh rằng chúng ta có thể mô tả thiết kế hướng đối tượng

trên các ngôn ngữ truyền thống nhưng chúng ta không thể kiểm tra được sự tuân thủ tư

tưởng hướng đối tượng trên các ngôn ngữ này, nghĩa là người phát triển vẫn có thể truy cập

đến cấu trúc dữ liệu vật lý của đối tượng và việc đó làm vô nghĩa khái niệm che dấu thông

tin.

Việc chấp nhận thiết kế hướng đối tượng như là một chiến lược hữu hiệu dẫn đến sự

phát triển rộng rãi các phương pháp thiết kế hướng đối tượng và các ngôn ngữ lập trình

hướng đối tượng.

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

Có nhiều quan niệm khác nhau về quan hệ giữa thiết kế hướng đối tượng và thiết kế

hướng chức năng. Có người cho rằng, hai chiến lược thiết kế này hỗ trợ lẫn nhau, cụ thể là

- DFD đưa ra mô hình về các thuộc tính và chức năng

- Luồng giao tác đưa ra hướng dẫn về tương tác giữa các đối tượng (thông báo)

- Mô hình E - R đưa ra hướng dẫn xây dựng đối tượng

Thêm nữa, thiết kế nội tại của lớp đối tượng có nhiều điểm tương đồng với thiết kế

hướng chức năng.

Một quan điểm khác cho rằng thiết kế hướng đối tượng và thiết kế hướng chức năng

là hai cách tiếp cận hoàn toàn khác nhau, các khái niệm như che dấu thông tin, kế thừa là

đặc trưng quan trọng và bản chất của thiết kế hướng đối tượng và nếu không dứt bỏ cách

nhìn thiết kế hướng chức năng thì không thể khai thác hiệu quả các đặc trưng này.

6.4.2. Công cụ

a. Power Designer

* Giới thiệu chung về POWER DESIGNER

PowerDesigner là môi trường mô hình hóa tổng thể doanh nghiệp dưới dạng đồ họa

và dễ dàng sử dụng. Nó cung cấp:

- Việc mô hình hóa được tích hợp thông qua các phương pháp và các ký

hiệu

chuẩn.

o Data (E/R, Merise)

147

o Business (BPMN, BPEL, ebXML)

o Application (UML)

- Phát sinh code tự động thông qua các template có thể tùy chỉnh được

o SQL (with more than 50 supported DBMSs)

o Java

o .NET

- Khả năng đối chiếu mạnh mẽ để làm tài liệu và cập nhật các hệ thống hiện có.

- Khả năng tạo báo cáo tự động, có thể tùy chỉnh được

- Một môi trường có thể mở rộng, cho phép bạn thêm các luật, câu lệnh, khái niệm,

thuộc tính mới cho các phương pháp mã hóa và mô hình hóa

* Hỗ trợ của Power Designer đối với đội phát triển dự án

Một đội phát triển bao gồm chuyên viên phân tích nghiệp vụ, phân tích và thiết kế,

quản trị dữ liệu, lập trình viên, tester. Mỗi người sẽ sử dụng một số tính năng khác nhau

của Power Designer:

Business Analysts (chuyên viên phân tích nghiệp vụ): Xác định kiến trúc của tổ chức,

các yêu cầu nghiệp vụ, và các dòng chảy nghiệp vụ ở cấp cao. Họ có thể sử dụng các

component sau:

 Enterprise Architecture Model (EAM)

 Requirements Model (RQM):

 Business Process Model (BPM):

Data Analysts and Designers (Chuyên viên phân tích và thiết kế): Sẽ gắn kết các yêu

cầu kỹ thuật với các yêu cầu nghiệp vụ. Đi sâu hơn vào việc phân tích, bạn có thể định

nghĩa Use Cases và kết chúng với các yêu cầu. Bạn có thể mô tả các đặc điểm kỹ thuật

thuộc về chức năng và định nghĩa chính xác hơn bản chất và chi tiết của từng tiến trình, ứng

dụng và cấu trúc dữ liệu của ứng dụng. Bạn có thể sử dụng mô hình Tiến trình nghiệp vụ

(Business Process Model – BPM) và một mô hình dữ liệu quan niệm

 Conceptual Data Model (CDM):

Database Administrators (Quản trị cơ sở dữ liệu): Sử dụng cấu trúc dữ liệu đã được

định nghĩa tốt để tối đa hóa, và tạo cơ sở dữ liệu. Bạn sẽ sử dụng:

 Physical Data Model (PDM):

 Logical Data Model (LDM):

 Information Liquidity Model (ILM):

Developers (Lập trình viên): Sẽ viết các chi tiết kỹ thuật trong một Requirements

Model (RQM), và sẽ xây dựng ứng dụng, định nghĩa các hành vi và cấu trúc đối tượng và

các sơ đồ đối tượng/quan hệ.

 Object-Oriented Model (OOM):

 XML Model (XSM):

148

Team Leaders (Trưởng nhóm): Sẽ quan tâm tới tất cả các mô hình, và sẽ muốn đảm

bảo rằng tất cả các yêu cầu, các đối tượng thiết kế, và các tài liệu được liên kết với nhau

thông qua các liên kết lưu vết tính đến tác động phân tích và thay đổi sự quản lý.

 PowerDesigner Enterprise Repository: là khu vực trung tâm của sự lưu trữ. Kho

hỗ trợ chia sẽ dữ liệu lớn, phiên bản, và báo cáo cho các mô hình và các tài liệu

hệ thống khác; có một hệ thống bảo mật mạnh và hỗ trợ khả năng mở rộng

doanh nghiệp thực sự từ một trường hợp kho đơn.

 Report Editor: Bạn có thể đảm bảo rằng các tài liệu luôn được cập nhật và chính

xác. Report Editor cho phép bạn tự động hóa việc tạo ra các báo cáo chi tiết (theo

format RTF và HTML) trên bất cứ hoặc tất cả các thành phần của hệ thống

để chia sẻ thông tin thiết kế trong đội dự án và trong toàn công ty.

 Free Model (FEM): được sử dụng để tạo ra các sơ đồ để giải thích kiến trúc

hệ thống và các ứng dụng, kịch bản use-case của các ứng dụng, các sơ đồ dòng

chảy và các hình vẽ khác.

Tester (Kiểm thử viên): sẽ sử dụng Requirements Model (RQM), Conceptual Data

Model (CDM) và các mô hình khác cùng với các tài liệu thiết kế để hiểu được ứng dụng nên

làm việc thế nào và nó được phát triển như thế nào

b. Rational Rose

Rational Rose là một công cụ lập mô hình trực quan mạnh trợ giúp bạn phân tích và

thiết kế các hệ thống phần mềm hướng đối tượng. Nó được dùng để lập mô hình hệ thống

trước khi bạn viết mã (code). Dùng mô hình, bạn có thể bắt kịp những thiếu sót về thiết kế,

trong khi việc chỉnh sửa chúng vẫn chưa tốn kém.

Mô hình Rose là bức tranh về một hệ thống từ nhiều góc nhìn khác nhau. Nó bao

gồm tất cả các sơ đồ UML, các actor, các use case, các đối tượng, các lớp, các thành phần…

Nó mô tả chi tiết nội dung mà hệ thống sẽ gộp và cách nó sẽ làm việc.

Có thể xem một mô hình Rose tương tự như bản thiết kế mẫu. Giống như một căn

nhà có nhiều bản thiết kế mẫu cho phép các thành viên trong đội xây dựng xem xét nó từ

nhiều góc nhìn khác nhau như : hệ thống ống nước, hệ thống điện, hệ thống nền … Một mô

hình Rose chứa đựng các sơ đồ khác nhau cho phép các thành viên trong nhóm đề án xem

hệ thống từ các góc nhìn khác nhau như : khách hàng, nhà thiết kế, quản trị đề án, …

Khi đã có được bản thiết kế thì sẽ giảm bớt một số vấn đề phiền phức như: lập trình

theo truyền thống thì khi hoàn tất đề án, sau một thời gian sử dụng khách hàng yêu cầu thêm

một vài chức năng nào đó vì có cập nhật mới thì người lập trình phải xem lại toàn bộ hệ

thống rồi sau đó mới cập nhật. Điều này tốn rất nhiều thời gian. Nay nhờ có bản thiết kế thì

chỉ cần xem cập nhật đó nằm ở phần nào và chỉnh sửa, nâng cấp hệ thống. Điều đó sẽ linh

hoạt và giảm rất nhiều thời gian…

Có ba phiên bản khác nhau của Rose :

 Rose Modeler : cho phép bạn tạo mô hình cho hệ thống, nhưng không hỗ trợ tiến

trình phát sinh mã hoặc thiết kế kỹ thuật đảo ngược.

 Rose Professional : cho phép bạn phát sinh mã trong một ngôn ngữ

149

 Rose Enterprise : cho phép bạn phát sinh mã cho C--, Java, Ada, Corba, Visual

Basic, Oracle … Một mô hình có thể có các thành phần được phát sinh bằng các

ngôn ngữ khác nhau.

Chương 7. Lập trình

7.1. Ngôn ngữ lập trình

Ngôn ngữ lập trình là phương tiện để liên lạc giữa con người và máy tính. Tiến trình

lập trình - sự liên lạc thông qua ngôn ngữ lập trình - là một hoạt động con người. Lập trình

là bước cốt lõi trong tiến trình kỹ nghệ phần mềm.

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

Cách nhìn kỹ nghệ phần mềm về các đặc trưng của ngôn ngữ lập trình tập trung vào

nhu cầu xác định dự án phát triển phần mềm riêng. Mặc dầu người ta vẫn cần các yêu cầu

riêng cho chương trình gốc, có thể thiết lập được một tập hợp tổng quát những đặc trưng kỹ

nghệ:

(1) dễ dịch thiết kế sang chương trình,

(2) có trình biên dịch hiệu quả,

(3) khả chuyển chương trình gốc,

(4) có sẵn công cụ phát triển,

(5) dễ bảo trì.

Bước lập trình bắt đầu sau khi thiết kế chi tiết đã được xác định, xét duyệt và sửa đổi

nếu cần. Về lý thuyết, việc sinh chương trình gốc từ một đặc tả chi tiết nên là trực tiếp. Dễ

dịch thiết kế sang chương trình đưa ra một chỉ dẫn về việc một ngôn ngữ lập trình phản xạ

gần gũi đến mức nào cho một biểu diễn thiết kế. Một ngôn ngữ cài đặt trực tiếp cho các kết

cấu có cấu trúc, các cấu trúc dữ liệu phức tạp, vào/ra đặc biệt, khả năng thao tác bit, và các

kết cấu hướng sự vật sẽ làm cho việc dịch từ thiết kế sang chương trình gốc dễ hơn nhiều

(nếu các thuộc tính này được xác định trong thiết kế).

Mặc dầu những tiến bộ nhanh chóng trong tốc độ xử lý và mật độ nhớ đã bắt đầu làm

giảm nhẹ nhu cầu chương trình siêu hiệu quả, nhiều ứng dụng vẫn còn đòi hỏi các chương

trình chạy nhanh, gọn (yêu cầu bộ nhớ thấp). Các ngôn ngữ với trình biên dịch tối ưu có thể

150

là hấp dẫn nếu hiệu năng phần mềm là yêu cầu chủ chốt. Tính khả chuyển chương trình gốc

là một đặc trưng ngôn ngữ lập trình có thể được hiểu theo ba cách khác nhau:

- Chương trình gốc có thể được chuyển từ bộ xử lý này sang bộ xử lý khác và từ trình

biên dịch nọ sang trình biên dịch kia với rất ít hoặc không phải sửa đổi gì.

- Chương trình gốc vẫn không thay đổi ngay cả khi môi trường của nó thay đổi (như

việc cài đặt bản mới của hệ điều hành).

- Chương trình gốc có thể được tích hợp vào trong các bộ trình phần mềm khác nhau

với ít hay không cần thay đổi gì vì các đặc trưng của ngôn ngữ lập trình.

Trong số ba cách hiểu về tính khả chuyển này thì cách thứ nhất là thông dụng nhất.

Việc đưa ra các chuẩn (do tổ chức tiêu chuẩn quốc tế IFO hay Viện tiêu chuẩn quốc gia Mĩ -

ANSI) góp phần làm nâng cao tính khả chuyển. Tính sẵn có của công cụ phát triển có thể

làm ngắn bớt thời gian cần để sinh ra chương trình gốc và có thể cải thiện chất lượng của

chương trình. Nhiều ngôn ngữ lập trình có thể cần tới một loạt công cụ kể cả trình biên dịch

gỡ lỗi, trợ giúp định dạng chương trình gốc, các tiện nghi soạn thảo có sẵn, các công cụ

kiểm soát chương trình gốc, thư viện chương trình con mở rộng trong nhiều lĩnh vực ứng

dụng, các trình duyệt, trình biên dịch chéo cho phát triển bộ vi xử lý, khả năng bộ xử lý

macro, công cụ kỹ nghệ ngược và những công cụ khác. Trong thực tế, khái niệm về môi

trường phát triển phần mềm tốt (bao hàm cả các công cụ) đã được thừa nhận như nhân tố

đóng góp chính cho kỹ nghệ phần mềm thành công.

Tính dễ bảo trì của chương trình gốc có tầm quạn trọng chủ chốt cho tất cả các nỗ lực

phát triển phần mềm không tầm thường. Việc bảo trì không thể được tiến hành chừng nào

người ta còn chưa hiểu được phần mềm. Các yếu tố của cấu hình phần mềm (như tài liệu

thiết kế) đưa ra một nền tảng cho việc hiểu biết, nhưng cuối cùng thì chương trình gốc vẫn

phải được đọc và sửa đổi theo những thay đổi trong thiết kế.

Tính dễ dịch thiết kế sang chương trình là một yếu tố quan trọng để dễ bảo trì chương

trình gốc. Bên cạnh đó, các đặc trưng tự làm tài liệu của ngôn ngữ (như chiều dài được phép

của tên gọi, định dạng nhãn, định nghĩa kiểu, cấu trúc dữ liệu) có ảnh hưởng mạnh đến tính

dễ bảo trì.

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

Các đặc trưng của ngôn ngữ lập trình sẽ quyết định miền ứng dụng của ngôn ngữ.

Miền ứng dụng là yếu tố chính để chúng ta lựa chọn ngôn ngữ cho một dự án phần mềm. C

thường là một ngôn ngữ hay được chọn cho việc phát triển phần mềm hệ thống.

Trong các ứng dụng thời gian thực chúng ta hay gặp các ngôn ngữ như Ada, C, C--

và cả hợp ngữ do tính hiệu quả của chúng. Các ngôn ngữ này và Java cũng được dùng cho

phát triển phần mềm nhúng.

Trong lĩnh vực khoa học kỹ thuật thì FORTRAN với khả năng tính toán với độ chính

xác cao và thư viện toán học phong phú vẫn còn là ngôn ngữ thống trị. Tuy vậy, PASCAL

và C cũng được dùng rộng rãi.

COBOL là ngôn ngữ cho ứng dụng kinh doanh và khai thác CSDL lớn nhưng các

ngôn ngữ thế hệ thứ tư đã dần dần chiếm ưu thế.

151

BASIC vẫn đang tiến hóa (Visual Basic) và được đông đảo người dùng máy tính cá

nhân ủng hộ mặc dù ngôn ngữ này rất hiếm khi được những người phát triển hệ thống dùng.

Các ứng dụng trí tuệ nhân tạo thường dùng các ngôn ngữ như LISP, PROLOG hay

OPS5, tuy vậy nhiều ngôn ngữ lập trình (vạn năng) khác cũng được dùng.

Xu hướng phát triển phần mềm hướng đối tượng xuyên suốt phần lớn các miền ứng

dụng đã mở ra nhiều ngôn ngữ mới và các dị bản ngôn ngữ qui ước. Các ngôn ngữ lập trình

hướng đối tượng được dùng rộng rãi nhất là Smalltalk, C--, Java. Ngoài ra còn có Eiffel,

Objectư PASCAL, Flavos và nhiều ngôn ngữ khác.

Với đặc trưng hướng đối tượng, tính hiệu quả thực hiện cũng như có nhiều công cụ

và thư viện, C-- hiện đang được sử dụng rộng rãi trong lĩnh vực phát triển các ứng dụng

nghiệp vụ.

Java cũng là một ngôn ngữ hướng đối tượng đang được sử dụng rộng rãi cho phát

triển các dịch vụ Web và phần mềm nhúng vì các lý do độ an toàn cao, tính trong sáng, tính

khả chuyển và hướng thành phần. Theo một số thống kê thì tốc độ phát triển một ứng dụng

mới bằng Java cao hơn đến 2 lần so với các ngôn ngữ truyền thống như C hay thậm chí C--.

Các ngôn ngữ biên dịch (script) với những câu lệnh và thư viện mạnh hiện đang rất được

chú ý. ASP, JavaScript, PERL... đang được sử dụng rộng rãi trong lập trình Web.

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

Nói chung, chất lượng của thiết kế phần mềm được thiết lập theo cách độc lập với

các đặc trưng ngôn ngữ lập trình. Tuy nhiên thuộc tính ngôn ngữ đóng một vai trò trong

chất lượng của thiết kế được cài đặt và ảnh hưởng tới cách thiết kế được xác định. Ví dụ

như khả năng xây dựng mô đun và bao gói chương trình. Thiết kế dữ liệu cũng có thể bị ảnh

hưởng bởi các đặc trưng ngôn ngữ. Các ngôn ngữ lập trình như Ada, C--, Smalltalk đều hỗ

trợ cho khái niệm về kiểu dữ liệu trừu tượng - một công cụ quan trọng trong thiết kế và đặc

tả dữ liệu. Các ngôn ngữ thông dụng khác, như PASCAL, cho phép định nghĩa các kiểu dữ

liệu do người dùng xác định và việc cài đặt trực tiếp danh sách móc nối và những cấu trúc

dữ liệu khác. Các tính năng này cung cấp cho người thiết kế phạm vi rộng hơn trong các

bước thiết kế sơ bộ và chi tiết.

Các đặc trưng của ngôn ngữ cũng ảnh hưởng tới kiểm thử phần mềm. Các ngôn ngữ

trực tiếp hỗ trợ cho các kết cấu có cấu trúc có khuynh hướng giảm bớt độ phức tạp của

chương trình, do đó có thể làm cho nó dễ dàng kiểm thử. Các ngôn ngữ hỗ trợ cho việc đặc

tả các chương trình con và thủ tục ngoài (như FORTRAN) thường làm cho việc kiểm thử

tích hợp ít sinh lỗi hơn.

7.2. Các phương pháp lập trình

7.2.1. Lập trình tuần tự

Vào thủa sơ khai phương pháp lập trình là lập trình tuần tự. Một chương trình sẽ là

một tập hợp các câu lệnh có thứ tự chạy nối tiếp nhau.

152

Chương trình sẽ chạy từ câu lệnh đầu tiên, và kết thúc ở câu lệnh cuối cùng. Lập

trình thế này khó, lâu, và việc xử lý các bài toán lớn sẽ khó khăn, chương trình chỉ có thể

viết theo một cấu trúc duy nhất là tuần tự.

7.2.2. Lập trình cấu trúc

Đây là một phần của phương pháp , ở phương pháp lập trình này ngoài lập trình thủ tục

cấu trúc tuần tự, ta có thể viết chương trình theo các và kết cấu trúc rẽ nhánh, cấu trúc vòng lặp

hợp của các cấu trúc đó với nhau. Ở phương pháp lập trình này xuất hiện khái niệm về cấu

trúc điều khiển .. để khiển rẽ nhánh, hay(control structure) như if-else, switch case for, while để

điều khiển vòng lặp.

Phương pháp này đã khiến việc lập trình trở lên linh hoạt hơn rất nhiều, nhưng nó

vẫn thực sự hạn chế khi lập trình các hệ thống lớn. Hiện nay nó không còn là phương pháp

lập trình thông dụng. Nhưng nó vẫn tồn tại như là một phần không thể thiếu trong các

phương pháp lập trình hiện đại hơn.

7.2.3. Lập trình hướng đối tượng

Lập trình hướng đối tượng, hay còn được sử dụng với thuật ngữ OOP (Object-

Oriented Programming) Đây là phương pháp lập trình hiện đại và phổ biến nhất hiện nay.

Phương pháp lập trình hiện đại giúp cho công việc lập trình càng ngàng được trìu tượng hóa

và trở lên “gần với con người” hơn.

153

Việc lập trình không còn dừng ở việc thiết kế các thủ tục khô khan, phương pháp lập

trình hướng đối tượng xây dựng trên mô hình thế giới thực, khi mà mọi thứ đều là các đối

tượng. Các đối tượng sẽ chứa đựng trong nó các thuộc tính, các hành động của riêng nó. Ví

dụ như mỗi người sẽ có trong mình thuộc tính tên, tuổi, giới tính và có các hành động, đi,

chạy nhảy..

Phương pháp lập trình hướng đối tượng gắn liền với các thuật ngữ Lớp ( ), Đốiclass

tượng ( ), Thuộc tính ( ), Phương thức ( )object attribute method

Class là phân loại các đối tượng, một object phải thuộc một hay nhiều class nào đó.

Khi lập trình chúng ta phải xác định bài toán gồm các đối tượng nào, từ đó ta sẽ xác định

được bài toán gồm những class nào. Ví dụ quản lý lớp học thì ta sẽ có class giáo viên, học

sinh.

Object là một thể hiện của class, một Object phải là duy nhất. Ví dụ class giáo viên

thì sẽ có Cô A, Thầy B, class học sinh sẽ có thể hiện là Bạn D, bạn E.

Attribute là các thuộc tính, hay còn gọi là trường, hay dữ liệu. Ví dụ class Giáo viên

có thuộc tính là Tên giáo viên, Môn học (môn mà giáo viên dạy), class Học sinh thì có thuộc

tính là Tên học sinh, vị trí chỗ ngồi..v.v

Method là các phương thức, hành vi mà đối tượng có thể thực hiện. Ví dụ một đối

tượng giáo viên có phương thức chấm điểm, phương thức giảng bài, một đối tượng học sinh

thì có phương thức làm bài tập, giơ tay phát biểu..v.v

Vì lập trình hướng đối tượng thể hiện thế giới thực, nên nó cũng có các tính chất đặc

trưng: ,Tính trìu tượng tính đóng gói, tính đa hình tính kế thừa. ,

Lập trình hướng đối tượng đem lại cho người lập trình một phương pháp tư duy xây

dựng bài toán ở mức gần gũi với thế giới thực tế nhất. Mình thường nói vui việc lập trình

hướng đối tượng giống như việc chúa trời tạo ra thế giới vậy. Phương pháp lập trình hướng

đối ngoài ưu điểm như tái sử dụng, nó còn có các ưu điểm như tính bảo mật cao, tính nhất

quán dữ liệu.

Hầu hết các ngôn ngữ lập trình hiện đại đều có xu hướng hỗ trợ lập trình hướng đối

tượng. Các ngôn ngữ lập trình hướng đối tượng phổ biến: Objective-C, C--, JAVA, C#..

7.2.4. Lập trình logic

Trong lập trình logic, ta có thể sử dụng các vị từ để định nghĩa các khái niệm của tất

cả các môn khoa học khác.

154

Ví dụ định nghĩa một số nguyên tố:

Số nguyên tố N là một số nguyên lớn hơn 1, chỉ chia hết cho 1 và chính nó.

Để xét xem số N có phải là số nguyên tố hay không, người ta thường sử dụng dấu

hiệu nhận biết: Số nguyên tố là một số nguyên dương, không chia hết cho mọi số nguyên tố

nhỏ hơn nó và 2 là số nguyên tố nhỏ nhất.

Dấu hiệu này có thể mô tả bằng các vị từ như sau:

- 2 là một số nguyên tố.

- N là một số nguyên tố nếu N>0, M là số nguyên tố nào đó, M<N và N không chia

hết cho M.

Khi mô tả bài toán dưới dạng logic vị từ, ta có thể yêu cầu hệ thống tìm kiếm các lời

giải liên quan đến các khai báo đó. Bài toán cần giải được xem là “mục tiêu” mà hệ thống

phải chứng minh trên cơ sở các tri thức đã được khai báo.

Như thế, toàn bộ các ký hiệu của ngôn ngữ lập trình suy về một công thức đặc biệt:

- Phát sinh từ một yêu cầu.

- Nhằm chứng minh một mục tiêu. Để trả lời cho câu hỏi đó hệ thống xem nó như là

một “đích” và cố chứng minh “đích” đó bằng cách tạo những suy diễn trên cơ sở

các tri thức đã khai báo.

Một ngôn ngữ logic có thể được dùng trong giai đoạn đặc tả yêu cầu của quy trình xây

dựng một sản phẩm phần mềm. Hơn thế nữa, logic vị từ cho phép biểu diễn hầu hết các khái

niệm và các định lý trong các bộ môn khoa học.

Một trong những ngôn ngữ lập trình logic có hỗ trợ rất nhiều cho lĩnh vực trí tuệ nhân

tạo là ngôn ngữ Prolog

7.3. Phong cách lập trình

Phong cách lập trình bao hàm một triết lý về lập trình nhấn mạnh tới tính dễ hiểu của

chương trình nguồn. Các yếu tố của phong cách bao gồm: tài liệu bên trong chương trình,

phương pháp khai báo dữ liệu, cách xây dựng câu lệnh và các kỹ thuật vào/ra.

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

Tài liệu bên trong của chương trình gốc bắt đầu với việc chọn lựa các tên gọi định

danh (biến và nhãn), tiếp tục với vị trí và thành phần của việc chú thích, và kết luận với cách

tổ chức trực quan của chương trình. Việc lựa chọn các tên gọi định danh có nghĩa là điều

chủ chốt cho việc hiểu chương trình. Những ngôn ngữ giới hạn độ dài tên biến hay nhãn làm

các tên mang nghĩa mơ hồ. Cho dù một chương trình nhỏ thì một tên gọi có nghĩa cũng làm

tăng tính dễ hiểu.

Theo ngôn từ của mô hình cú pháp/ngữ nghĩa tên có ý nghĩa làm “đơn giản hóa việc

chuyển đổi từ cú pháp chương trình sang cấu trúc ngữ nghĩa bên trong”.

Một điều rõ ràng là: phần mềm phải chứa tài liệu bên trong. Lời chú thích cung cấp

cho người phát triển một ý nghĩa truyền thông với các độc giả khác về chương trình gốc.

Lời chú thích có thể cung cấp một hướng dẫn rõ rệt để hiểu trong pha cuối cùng của kỹ nghệ

phần mềm - bảo trì. Có nhiều hướng dẫn đã được đề nghị cho việc viết lời chú thích. Các

155

chú thích mở đầu và chú thích chức năng là hai phạm trù đòi hỏi cách tiếp cận có hơi khác.

Lời chú thích mở đầu nên xuất hiện ở ngay đầu của mọi modul. Định dạng cho lời chú thích

như thế là:

1. Một phát biểu về mục đích chỉ rõ chức năng mô đun.

2. Mô tả giao diện bao gồm:

- Một mẫu cách gọi

- Mô tả về dữ liệu

- Danh sách tất cả các mô đun thuộc cấp

3. Thảo luận về dữ liệu thích hợp (như các biến quan trọng và những hạn chế, giới

hạn về cách dùng chúng) và các thông tin quan trọng khác.

4. Lịch sử phát triển bao gồm:

- Tên người thiết kế modul (tác giả).

- Tên người xét duyệt và ngày tháng.

- Ngày tháng sửa đổi và mô tả sửa đổi.

Các chú thích chức năng được nhúng vào bên trong thân của chương trình gốc và

được dùng để mô tả cho các khối chương trình.

7.3.2 Khai báo dữ liệu

Thứ tự khai báo dữ liệu nên được chuẩn hóa cho dù ngôn ngữ lập trình không có yêu

cầu bắt buộc nào về điều đó. Các tên biến ngoài việc có nghĩa còn nên mang thông tin về

kiểu của chúng. Ví dụ, nên thống nhất các tên biến cho kiểu số nguyên, kiểu số thực... Cần

phải chú giải về mục đích đối với các biến quan trọng, đặc biệt là các biến tổng thể. Các cấu

trúc dữ liệu nên được chú giải đầy đủ về cấu trúc và chức năng, và các đặc thù về sử dụng.

Đặc biệt là đối với các cấu trúc phức tạp như danh sách móc nối trong C hay Pascal.

7.3.3 Xây dựng câu lệnh

Việc xây dựng luồng logic phần mềm được thiết lập trong khi thiết kế. Việc xây

dựng từng câu lệnh tuy nhiên lại là một phần của bước lập trình. Việc xây dựng câu lệnh

nên tuân theo một qui tắc quan trọng hơn cả: mỗi câu lệnh nên đơn giản và trực tiếp. Nhiều

ngôn ngữ lập trình cho phép nhiều câu lệnh trên một dòng. Khía cạnh tiết kiệm không gian

của tính năng này khó mà biện minh bởi tính khó đọc nảy sinh. Cấu trúc chu trình và các

phép toán điều kiện được chứa trong đoạn trên đều bị che lấp bởi cách xây dựng nhiều câu

lệnh trên một dòng.

Cách xây dựng câu lệnh đơn và việc tụt lề minh họa cho các đặc trưng logic và chức

năng của đoạn này. Các câu lệnh chương trình gốc riêng lẻ có thể được đơn giản hóa bởi:

- Tránh dùng các phép kiểm tra điều kiện phức tạp

- Khử bỏ các phép kiểm tra điều kiện phủ định

- Tránh lồng nhau nhiều giữa các điều kiện hay chu trình

- Dùng dấu ngoặc để làm sáng tỏ các biểu thức logic hay số học

- Dùng dấu cách và/hoặc các ký hiệu dễ đọc để làm sáng tỏ nội dung câu lệnh

156

- Chỉ dùng các tính năng chuẩn của ngôn ngữ

Để hướng tới chương trình dễ hiểu luôn nên đặt ra câu hỏi: Liệu có thể hiểu được

điều này nếu ta không là người lập trình cho nó không?

7.3.4 Vào/ra

Vào ra của các mô đun nên tuân thủ theo một số hướng dẫn sau:

- Làm hợp lệ mọi cái vào.

- Kiểm tra sự tin cậy của các tổ hợp khoản mục vào quan trọng.

- Giữ cho định dạng cái vào đơn giản.

- Dùng các chỉ báo cuối dữ liệu thay vì yêu cầu người dùng xác định “số các khoản

mục”.

- Giữ cho định dạng cái vào thống nhất khi một ngôn ngữ lập trình có các yêu cầu

định dạng nghiêm ngặt.

7.4. Lập trình tránh lỗi

Tránh lỗi và phát triển phần mềm vô lỗi dựa trên các yếu tố sau:

i) Sản phẩm của một đặc tả hệ thống chính xác.

ii) Chấp nhận một cách tiếp cận thiết kế phần mềm dựa trên việc bao gói dữ liệu và

che dấu thông tin.

iii) Tăng cường duyệt lại trong quá trình phát triển và thẩm định hệ thống phần mềm.

iv) Chấp nhận triết lý chất lượng tổ chức: chất lượng là bánh lái của quá trình phần

mềm.

v) Việc lập kế hoạch cẩn thận cho việc thử nghiệm hệ thống để tìm ra các lỗi chưa

được phát hiện trong quá trình duyệt lại và để định lượng độ tin cậy của hệ thống.

Có hai cách tiếp cận chính hỗ trợ tránh lỗi là:

Lập trình có cấu trúc: Thuật ngữ này được đặt ra từ cuối những năm 60 và có nghĩa

là lập trình mà không dùng lệnh goto, lập trình chỉ dùng các vòng lặp while và các phát biểu

if để xây dựng điều khiển và trong thiết kế thì dùng cách tiếp cận trên - xuống. Việc thừa

nhận lập trình có cấu trúc là quan trọng bởi vì nó là bước đầu tiên bước từ cách tiếp cận

không khuôn phép tới phát triển phần mềm. Lập trình có cấu trúc buộc người lập trình phải

nghĩ cẩn thận về chương trình của họ, và vì vậy nó ít tạo ra sai lầm trong khi phát triển. Lập

trình có cấu trúc làm cho chương trình có thể được đọc một cách tuần tự và do đó dễ hiểu và

dễ kiểm tra. Tuy nhiên nó chỉ là bước đầu tiên trong việc lập trình nhằm đạt độ tin cậy tốt.

Có một vài khái niệm khác cũng hay dẫn tới các lỗi phần mềm:

i) Các số thực dấu chấm động: các phép toán số thực được làm tròn khiến cho việc so

sánh các kết quả số thực, nhất là so sánh bằng giữa hai số thực là không khả thi. Số thực dấu

phẩy động có độ chính xác khác nhau khiến cho kết quả phép tính không theo mong muốn.

Ví dụ, trong phép tính tính phân chúng ta cần cộng các giá trị nhỏ trước với nhau nếu không

chúng sẽ bị làm tròn.

157

ii) Các con trỏ và bộ nhớ động: con trỏ là các cấu trúc bậc thấp khó quản lý và dễ gây

ra các lỗi nghiệm trọng đối với hệ thống. Việc cấp phát và thu hồi bộ nhớ động phức tạp và

là một trong các nguyên nhân chính gây lỗi phần mềm.

iii) Song song: lập trình song song đòi hỏi kỹ thuật cao và hiểu biết sâu sắc về hệ

thống. Một trong các vấn đề phức tạp của song song là quản lý tương tranh.

iv) Đệ quy.

v) Các ngắt.

Các cấu trúc này có ích, nhưng người lập trình nên dùng chúng một cách cẩn thận.

Phân quyền truy cập dữ liệu: Nguyên lý an ninh trong quân đội là các cá nhân chỉ

được biết các thông tin có liên quan trực tiếp đến nhiện vụ của họ. Khi lập trình người ta

cũng tuân theo một nguyên lý tương tự cho việc truy cập dữ liệu hệ thống. Mỗi thành phần

chương trình chỉ được phép truy cập đến dữ liệu nào cần thiết để thực hiện chức năng của

nó. Ưu điểm của việc che dấu thông tin là các thông tin bị che dấu không thể bị sập đổ (thao

tác trái phép) bởi các thành phần chương trình mà được xem rằng không dùng thông tin đó.

Tiến hóa của sự phân quyền truy cập là che dấu thông tin, hay nói chính xác hơn là che dấu

cấu trúc thông tin. Khi đó, chúng ta có thể thay đổi cấu trúc thông tin mà không phải thay

đổi các thành phần khác có sử dụng thông tin đó.

7.4.1 Lập trình thứ lỗi

Đối với các hệ thống đòi hỏi độ tin cậy rất cao như hệ thống điều khiển bay thì cần

phải có khả năng dung thứ lỗi (fault tolerance), tức là khả năng đảm bảo cho hệ thống vẫn

hoạt động chính xác ngay cả khi có thành phần sinh lỗi.

Có bốn hoạt động cần phải tiến hành nếu hệ thống là thứ lỗi:

i) Phát hiện lỗi.

ii) Định ra mức độ thiệt hại.

iii) Hồi phục sau khi gặp lỗi: Hệ thống phải hồi phục về trạng thái mà nó biết là an

toàn. Cũng có thể là chỉnh lý trạng thái bị hủy hoại (hồi phục tiến), cũng có thể là lui về một

trạng thái trước mà an toàn (hồi phục lùi).

vi) Chữa lỗi: Cải tiến hệ thống để cho lỗi đó không xuất hiện nữa. Tuy nhiên trong

nhiều trường hợp phát hiện được đúng nguyên nhân gây lỗi là rất khó khăn vì nó xẩy ra bởi

một tổ hợp của thông tin vào và trạng thái của hệ thống.

Thông thường, thứ lỗi được thực hiện bằng cách song song hóa các chức năng, kết

hợp với bộ điều khiển thứ lỗi. Bộ điều khiển sẽ so sánh kết quả của các khối chương trình

thực hiện cùng nhiệm vụ và sử dụng nguyên tắc đa số để chọn kết quả.

7.4.2. Lập trình phòng thủ

Lập trình phòng thủ là cách phát triển chương trình mà người lập trình giả định rằng

các mâu thuẫn hoặc các lỗi chưa được phát hiện có thể tồn tại trong chương trình. Phải có

phần mềm kiểm tra trạng thái hệ thống sau khi biến đổi và phải đảm bảo rằng sự biến đổi

trạng thái là kiên định. Nếu phát hiện một mâu thuẫn thì việc biến đổi trạng thái là phải rút

lại và trạng thái phải trở về trạng thái đúng đắn trước đó.

158

Nói chung một lỗi gây ra một sự sụp đổ trạng thái: các biến trạng thái được gán các

trị không hợp luật. Ngôn ngữ lập trình như Ada cho phép phát hiện ra các lỗi đó ngay trong

thời gian biên dịch. Tuy nhiên việc kiểm tra biên dịch chỉ hạn chế cho các giá trị tĩnh và một

vài phép kiểm tra thời gian thực là không thể tránh được. Một cách để phát hiện lỗi trong

chương trình Ada là dùng cơ chế xử lý bất thường kết hợp với đặc tả miền trị.

Hồi phục lỗi là một quá trình cải biên không gian trạng thái của hệ thống sao cho

hiệu ứng của lỗi là nhỏ nhất và hệ thống có thể tiếp tục vận hành, có lẽ là trong một mức suy

giảm.

Hồi phục tiến liên quan đến việc cố gắng chỉnh lại trạng thái hệ thống.

Hồi phục lùi liên quan đến việc lưu trạng thái của hệ thống ở một trạng thái đúng đã

biết.

Hồi phục tiến thường là một chuyên biệt ứng dụng. Có hai tình thế chung mà khi đó

hồi phục tiến có thể thành công:

1) Khi dữ liệu mã bị sụp đổ: Việc sử dụng kỹ thuật mã hóa thích hợp bằng cách thêm

các dữ liệu dư thừa vào dữ liệu cho phép sửa sai khi phát hiện lỗi.

2) Khi cấu trúc nối bị sụp đổ: Nếu các con trỏ tiến và lùi đã có trong cấu trúc dữ liệu

thì cấu trúc đó có thể tái tạo nếu như còn đủ các con trỏ chưa bị sụp. Kỹ thuật này thường

được dùng cho việc sửa chữa hệ thống tệp và cơ sở dữ liệu.

Hồi phục lùi là một kỹ thuật đơn giản liên quan đến việc duy trì các chi tiết của trạng

thái an toàn và cất giữ trạng thái đó khi mà sai lầm đã bị phát hiện. Hầu hết các hệ quản trị

cơ sở dữ liệu đều có bộ hồi phục lỗi. CSDL chỉ cập nhật dữ liệu một khi giao dịch đã hoàn

tất và không phát hiện được vấn đề gì. Nếu giao dịch thất bại thì CSDL không được cập

nhật.

Một kỹ thuật khác là thiết lập các điểm kiểm tra thường kỳ mà chúng là các bản sao

của trạng thái hệ thống. Khi mà một lỗi được phát hiện thì trạng thái an toàn đó được tái lưu

kho từ điểm kiểm tra gần nhất. Trường hợp hệ thống dính líu tới nhiều quá trình hợp tác thì

dãy các giao tiếp có thể là các điểm kiểm tra của các quá trình đó không đồng bộ và để hồi

phục thì mỗi quá trình phải trở lại trạng thái ban đầu của nó.

7.5. Lập trình hiệu quả

7.5.1. Tính hiệu quả chương trình

Tính hiệu quả của chương trình gốc có liên hệ trực tiếp với tính hiệu quả của thuật

toán được xác định trong thiết kế chi tiết. Tuy nhiên, phong cách lập trình có thể có một tác

động đến tốc độ thực hiện và yêu cầu bộ nhớ. Tập hợp các hướng dẫn sau đây bao giờ cũng

có thể áp dụng được khi thiết kế chi tiết được dịch thành chương trình:

- Đơn giản hóa các biểu thức số học và lôgic trước khi đi vào lập trình.

- Tính cẩn thận từng chu kỳ lồng nhau để xác định liệu các câu lệnh hay biểu thức có

thể được chuyển ra ngoài hay không

- Khi có thể, hãy tránh dùng mảng nhiều chiều

- Khi có thể hãy tránh việc dùng con trỏ và danh sách phức tạp

159

- Dùng các phép toán số học “nhanh”

- Không trộn lẫn các kiểu dữ liệu, cho dù ngôn ngữ có cho phép điều đó

- Dùng các biểu thức số học và logic bất kì khi nào có thể được

Nhiều trình biên dịch có tính năng tối ưu tự động sinh ra chương trình hiệu quả bằng

cách dồn nén các biểu thức lặp, thực hiện tính chu trình, dùng số học nhanh và áp dụng các

thuật toán có hiệu quả liên quan khác. Với những ứng dụng trong đó tính hiệu quả có ý

nghĩa quan trọng, những trình biên dịch như thế là công cụ lập trình không thể thiếu được.

7.5.2. Hiệu quả bộ nhớ

Tính hiệu quả bộ nhớ phải được tính vào đặc trưng phân trang của hệ điều hành. Nói

chung, tính cục bộ của chương trình hay việc bảo trì lĩnh vực chức năng qua các kết cấu có

cấu trúc là một phương pháp tuyệt vời làm giảm việc phân trang và do đó làm tăng tính hiệu

quả.

Hạn chế bộ nhớ trong phát triển phần mềm nhúng là mối quan tâm rất thực tế, mặc

dầu bộ nhớ giá thấp, mật độ cao vẫn đang tiến hóa nhanh chóng. Nếu yêu cầu hệ thống cần

tới bộ nhớ tối thiểu (như sản phẩm giá thấp, khối lượng lớn) thì trình biên dịch ngôn ngữ

cấp cao phải được trù tính cẩn thận với tính năng nén bộ nhớ, hay như một phương kế cuối

cùng, có thể phải dùng tới hợp ngữ.

7.5.3. Hiệu quả vào/ra

Các thiết bị vào ra thường có tốc độ chậm hơn rất nhiều so với khả năng tính toán

của máy tính và tốc độ truy cập bộ nhớ trong. Việc tối ưu vào ra có thể làm tăng đáng kể tốc

độ thực hiện. Một số hướng dẫn đơn giản để tăng cường hiệu quả vào/ra:

• Số các yêu cầu vào/ra nên giữ mức tối thiểu

• Mọi việc vào/ra nên qua bộ đệm để làm giảm phí tổn liên lạc.

• Với bộ nhớ phụ (như đĩa) nên lựa chọn và dùng phương pháp thâm nhập đơn giản

nhất chấp nhận được.

• Nên xếp khối vào/ra với các thiết bị bộ nhớ phụ.

• Việc vào/ra với thiết bị cuối hay máy in nên nhận diện các tính năng của thiết bị có

thể cải tiến chất lượng hay tốc độ.

Tổng kết: Bước lập trình là một tiến trình dịch (chuyển hóa) thiết kế chi tiết thành

chương trình mà cuối cùng được biến đổi thành các lệnh mã máy thực hiện được. Các đặc

trưng của ngôn ngữ lập trình có ảnh hưởng lớn đến quá trình xây dựng, kiểm thử cũng như

bảo trì phần mềm. Phong cách lập trình quyết định tính dễ hiểu của chương trình gốc. Các

yếu tố của phong cách bao gồm việc làm tài liệu bên trong, phương pháp khai báo dữ liệu,

thủ tục xây dựng câu lệnh, và kỹ thuật lập trình vào/ra. Lập trình cần hướng tới hiệu quả

thực hiện, tức là tích kiệm tài nguyên phần cứng (mức độ sử dụng CPU, bộ nhớ...). Mặc dầu

tính hiệu quả có thể là yêu cầu cực kì quan trọng, chúng ta nên nhớ rằng một chương trình

hoạt động hiệu quả mà lại không dễ hiểu dẫn đến khó bảo trì thì giá trị của nó cũng bị hạn

chế.

160

Chương 8. Kiểm thử và tích hợp

8.1. Giới thiệu

8.1.1. Khái niệm về kiểm thử phần mềm.

Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới những

điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá một khía cạnh nào đó của hệ

thống hay thành phần đó. (Theo Bảng chú giải thuật ngữ chuẩn IEEE của Thuật ngữ kỹ

nghệ phần mềm- IEEE Standard Glossary of Software Engineering Terminology).

Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìm ra

nhiều lỗi. ( ). Theo “The Art of Software Testing” – Nghệ thuật kiểm thử phần mềm

Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần

mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cung cấp cho người có

lợi ích liên quan những thông tin về chất lượng của sản phẩm hay dịch vụ phần mềm ấy.

Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm khuyết phần mềm nhằm đảm

161

bảo hiệu quả hoạt động tối ưu của phần mềm trong nhiều ngành khác nhau. (Theo Bách

khoa toàn thư mở Wikipedia).

Có thể định nghĩa một cách dễ hiểu như sau: là một tiến trìnhKiểm thử phần mềm

hay một tập hợp các tiến trình được thiết kế để đảm bảo mã hóa máy tính thực hiện theo cái

mà chúng đã được thiết kế để làm, và không thực hiện bất cứ thứ gì không mong muốn. Đây

là một pha quan trọng trong quá trình phát triển hệ thống, giúp cho người xây dựng hệ thống

và khách hàng thấy được hệ thống mới đã đáp ứng yêu cầu đặt ra hay chưa.

8.1.2. Mục đích của kiểm thử phần mềm.

Tìm ra nhiều lỗi bằng việc đưa ra các dòng thời gian.

Chứng minh được sản phẩm hoàn thành có những chức năng hay ứng dụng giống với

bản đặc tả yêu cầu.

Tạo ra các test case có chất lượng cao, thực thi hiệu quả…

Một số lỗi cơ bản trong kiểm thử phần mềm như: lỗi ngay từ khi phân tích yêu cầu,

lỗi từ bản đặc tả hệ thống, lỗi trong code, lỗi hệ thống và nguồn tài nguyên hệ thống, lỗi

trong vấn đề phần mềm, phần cứng…

8.1.3. Nguyên tắc trong kiểm thử phần mềm.

Để kiểm thử đạt hiệu quả thì khi tiến hành kiểm thử phần mềm cần phải tuân thủ một

số quy tắc sau:

Quy tắc 1: Một phần quan trọng của 1 ca kiểm thử là định nghĩa của đầu ra hay kết

quả mong muốn.

Quy tắc 2: Lập trình viên nên tránh tự kiểm tra chương trình của mình.

Quy tắc 3: Nhóm lập trình không nên kiểm thử chương trình của chính họ.

Quy tắc 4: Kiểm tra thấu đáo mọi kết quả của mỗi kiểm tra.

Quy tắc 5: Các ca kiểm thử phải được viết cho các trạng thái đầu vào không hợp lệ và

không mong muốn, cũng như cho các đầu vào hợp lệ và mong muốn.

Quy tắc 6: Khảo sát 1 chương trình để xem liệu chương trình có thực hiện cái mà nó

cần thực hiện chỉ là 1 phần, phần còn lại là xem liệu chương trình có thực hiện cái mà nó

không cần phải thực hiện hay không.

Quy tắc 7: Tránh các ca kiểm thử bâng quơ trừ khi chương trình thực sự là 1 chương

trình bâng quơ.

Quy tắc 8: Không dự kiến kết quả của kiểm thử theo giả thiết ngầm là không tìm

thấy lỗi.

Quy tắc 9: Xác suất tồn tại lỗi trong 1 đoạn chương trình là tương ứng với số lỗi đã tìm

thấy trong đoạn đó.

Quy tắc 10: Kiểm thử là 1 nhiệm vụ cực kỳ sáng tạo và có tính thử thách trí tuệ.

8.1.4. Phân loại kiểm thử.

a. Kiểm thử tĩnh( Static testing):

162

Là phương pháp thử phần mềm đòi hỏi phải duyệt lại các yêu cầu và các đặc tả bằng

tay, thông qua việc sử dụng giấy, bút để kiểm tra logic, lần từng chi tiết mà không cần chạy

chương trình. Kiểu kiểm thử này thường được sử dụng bởi chuyên viên thiết kế người mà

viết mã lệnh một mình.

Kiểm thử tĩnh cũng có thể được tự động hóa. Nó sẽ thực hiện kiểm tra toàn bộ bao

gồm các chương trình được phân tích bởi một trình thông dịch hoặc biên dịch mà xác nhận

tính hợp lệ về cú pháp của chương trình.

b. Kiểm thử động(Dynamic testing):

Là phương pháp kiểm thử thông qua việc dùng máy chạy chương trình để điều tra

trạng thái tác động của chương trình. Đó là kiểm thử dựa trê các ca kiểm thử xác định bằng

sự thực hiện của đối tượng kiểm thử hay chạy các chương trình. Kiểm thử động là kiểm tra

cách thức hoạt động của mã lệnh, tức là kiểm tra sự phản ứng vật lý từ hệ thống tới các biến

luôn thay đổi theo thời gian. Trong kiểm thử động, phần mềm phải thực sự được biên dịch

và chạy. Kiểm thử động thực sự bao gồm làm việc với phần mềm, nhập các giá trị đầu vào

và kiểm tra xem liệu đầu ra có như mong muốn hay không.

Các phương pháp kiểm thử động gồm có kiểm thử mức đơn vị – Unit Tests, kiểm thử

tích hợp – Intergration Tests, kiểm thử hệ thống – System Tests, và kiểm thử chấp nhận sản

phẩm – Acceptance Tests.

8.2. Các phương pháp kiểm thử

8.2.1. Phương pháp kiểm thử hộp đen – Black box testing.

a. Phân vùng tương đương

* Định nghĩa

Phân lớp tương đương là một phương pháp kiểm thử hộp đen chia miền đầu vào của

một chương trình thành các lớp dữ liệu, từ đó suy dẫn ra các ca kiểm thử. Phương pháp này

cố gắng xác định ra một ca kiểm thử mà làm lộ ra một lớp lỗi, do đó làm giảm tổng số các

trường hợp kiểm thử phải được xây dựng.

Thiết kế ca kiểm thử cho phân lớp tương đương dựa trên sự đánh giá về các lớp tương

đương với một điều kiện vào. Lớp tương đương biểu thị cho tập các trạng thái hợp lệ hay

không hợp lệ đối với điều kiện vào.

Một cách xác định tập con này là để nhận ra rằng 1 ca kiểm thử được lựa chọn tốt cũng

nên có 2 đặc tính khác:

- Giảm thiểu số lượng các ca kiểm thử khác mà phải được phát triển để hoàn thành

mục tiêu đã định của kiểm thử “hợp lý”.

- Bao phủ một tập rất lớn các ca kiểm thử có thể khác. Tức là, nó nói cho chúng ta một

thứ gì đó về sự có mặt hay vắng mặt của những lỗi qua tập giá trị đầu vào cụ thể.

Thiết kế Test-case bằng phân lớp tương đương tiến hành theo 2 bước:

- Xác định các lớp tương đương.

- Xác định các ca kiểm thử.

163

* Xác định các lớp tương đương.

Các lớp tương đương được xác định bằng bằng cách lấy mỗi trạng thái đầu vào

(thường là 1 câu hay 1 cụm từ trong đặc tả) và phân chia nó thành 2 hay nhiều nhóm.

Mẫu liệt kê các lớp tương đương:

Điều kiện đầu

vào

Các lớp tương đương

hợp lệ

Các lớp tương đương không

hợp lệ

- Điều kiện đầu vào là một giá trị đặc biệt, mảng số hay chuỗi, tập hợp hay điều kiện

đúng sai.

- Các lớp tương đương hợp lệ là mô tả các đầu vào hợp lệ của chương trình

- Các lớp tương đương không hợp lệ là mô tả các trạng thái khác của chương trình

như: sai, thiếu, không đúng…

* Nguyên tắc để xác định lớp tương đương.

- Nếu điều kiện đầu vào định rõ giới hạn của một mảng thì chia vùng tương đương

thành 3 tình huống:

- Xác định một lớp tương đương hợp lệ.

- Xác định hai lớp tương đương không hợp lệ.

- Nếu điều kiện đầu vào là một giá trị xác định thì chia vùng tương đương thành 3

tình huống:

- Một lớp tương đương hợp lệ.

- Hai lớp tương đương không hợp lệ.

- Nếu điều kiện đầu vào chỉ định là một tập giá trị thì chia vùng tương đương thành 2

tình huống như sau:

- Một lớp tương đương hợp lệ.

- Một lớp tương đương không hợp lệ.

- Nếu điều kiện đầu vào xác định là một kiểu đúng sai thì chia vùng tương đương

thành 2 tình huống:

- Một lớp tương đương hợp lệ.

- Một lớp tương đương không hợp lệ.

* Xác định các ca kiểm thử.

Với các lớp tương đương xác định được ở bước trên, bước thứ hai là sử dụng các lớp

tương đương đó để xác định các ca kiểm thử. Quá trình này như sau:

- Gán 1 số duy nhất cho mỗi lớp tương đương.

- Cho đến khi tất cả các lớp tương đương hợp lệ được bao phủ bởi (hợp nhất thành)

các ca kiểm thử. Viết 1 ca kiểm thử mới bao phủ càng nhiều các lớp tương đương đó chưa

được bao phủ càng tốt.

164

- Cho đến khi các ca kiểm thử của bạn đã bao phủ tất cả các lớp tương đương không

hợp lệ. Viết 1 ca kiểm thử mà bao phủ một và chỉ một trong các lớp tương đương không hợp

lệ chưa được bao phủ.

- Lý do mà mỗi ca kiểm thử riêng bao phủ các trường hợp không hợp lệ là vì các

kiểm tra đầu vào không đúng nào đó che giấu hoặc thay thế các kiểm tra đầu vào không

đúng khác.

Mặc dù việc phân lớp tương đương là rất tốt khi lựa chọn ngẫu nhiên các ca kiểm

thử, nhưng nó vẫn có những thiếu sót. Ví dụ, nó bỏ qua các kiểu test – case có lợi nào đó.

Hai phương pháp tiếp theo, phân tích giá trị biên và đồ thị nguyên nhân – kết quả, bao phủ

được nhiều những thiếu sót này.

* Ví dụ về phân lớp tương đương.

Cho bài toán như sau:

User:

Password:

Yêu cầu: Thiết kế test case sao cho khi người dùng nhập user vào ô text thì chỉ cho

nhập số ký tự [6 – 20 ].

Bài làm

Do yêu cầu của bài toán chỉ cho phép nhập số ký tự vào trong khi nhập của user nằm

[6 - 20] nên ta có tình huống kiểm thử sau:

 Nhập vào một trường hợp hợp lệ: nhập 7 ký tự.

 Nhập vào trường hợp không hợp lệ thứ nhất: nhập 5 ký tự.

 Nhập vào trường hợp không hợp lệ thứ hai: nhập vào 21 ký tự.

 Trường hợp đặc biệt: không nhập gì vào ô text đó (để trống).

Lập bảng các lớp tương đương:

Điều kiện đầu

vào

Các lớp tương đương hợp

lệ

Các lớp tương đương không

hợp lệ

Cho phép nhập số

ký tự nằm [ 6 – 20 ]

- -Nhập vào 7 ký tự Nhập vào 5 ký tự

- Nhập vào 21 ký tự

- Để trống ô đó

b. Phân tích giá trị biên – Boundary Values Analysis

* Định nghĩa.

Phân tích giá trị biên ( ) là kỹ thuật thiết kế test case và hoàn thành phân vùngBVA

tương đương.

Mục tiêu là lựa chọn các test case để thực thi giá trị biên.

Kiểm thử các dữ liệu vào bao gồm:

 Giá trị nhỏ nhất.

165

 Giá trị gần kề lớn hơn giá trị nhỏ nhất.

 Giá trị bình thường.

 Giá trị gần kề bé hơn giá trị lớn nhất.

 Giá trị lớn nhất.

Hình 3: Ví dụ về biểu thị phân tích giá trị biên

* Nguyên tắc chọn dữ liệu.

- Nếu giá trị đầu vào xác định là một mảng có biên là a và b(a < b) thì có thể thiết kế

được các test case như sau:

 Biên a

 Biên b

 Giá trị nhỏ hơn biên a

 Giá trị lớn hơn biên b

 Một giá trị nằm giữa a và b.

Khi một hàm chức năng F với hai biến x1 và x2 được cài đặt trong chương trình, các

biến đầu vào x1 và x2 sẽ có các giới hạn:

a<=x1<=b

c<=x2<=d

Các đoạn [a,b] và [c,d] được gọi là các miền giá trị của x1 và x2

Giả thiết lỗi đơn

Các lỗi của chương trình ít khi được gây ra bởi hai hay nhiều biến cùng một lúc

Ý tưởng chính của kiểm thử theo giá trị biên là sử dụng giá trị của biến đầu vào tại

giá trị nhỏ nhất, lớn hơn giá trị nhỏ nhất, giá trị thông thường, giá trị lớn nhất, và nhỏ hơn

giá trị lớn nhất

Kiểm thử theo giá trị biên với một biến:

Kiểm thử theo giá trị biên với hai biến:

166

Kiểm thử theo giá trị biên đầy đủ

- Là một mở rộng của kiểm thử theo giá trị biên bao gồm các giá trị nhỏ hơn giá trị

nhỏ nhất và lớn hơn giá trị lớn nhất (cho phép vượt quá miền giá trị)

- Là một hình thức kiểm thử với lỗi để biết được chương trình sẽ thực hiện như

thế nào nếu dữ liệu vào có lỗi

- Có thể không được áp dụng với một số ngôn ngữ lập trình có ràng buộc kiểu

Kiểm thử theo giá trị biên đầy đủ

Kiểm thử theo giá trị biên đầy đủ với hai biến

Kiểm thử theo giá trị biên xấu nhất (hai biến)

- Loại bỏ giả thiết chỉ có một lỗi đơn

- Cho phép các giá trị đầu vào có thể cùng nhận giá trị biên

167

Số lượng trường hợp kiểm thử

- Kiểm thử theo giá trị biên: 4n-1

- Kiểm thử theo giá trị biên đầy đủ: 6n-1

- Kiểm thử theo giá trị biên xấu nhất: 5

Với n là số lượng các biến

Nhược điểm của kiểm thử theo giá trị biên

- Các biến phải độc lập với nhau

- Không áp dụng được cho các biến thuộc kiểu logic

- Nếu miền giá trị đầu vào là một danh sách các giá trị thì có thể thiết kế các test case

như sau:

 Giá trị nhỏ nhất.

 Giá trị lớn hơn giá trị nhỏ nhất.

 Giá trị lớn nhất.

 Giá trị nhỏ hơn giá trị lớn nhất.

Ví dụ: Cho một danh sách như sau { 3,5,90,100,102} nên có thể thiết kế như sau:

 Giá trị nhỏ nhất: 3

 Giá trị lớn hơn giá trị nhỏ nhất: 5

 Giá trị lớn nhất: 102

 Giá trị nhỏ hơn giá trị lớn nhất: 100

- Nếu dữ liệu vào là điều kiện ràng buộc số giá trị thì có thể thiết kế được các test

case như sau:

 Số giá trị tối thiểu.

 Số giá trị tối đa.

 Và một số giá trị không hợp lệ.

* Phân loại miền biên.

- Điểm trên biên (Boundary point).

- Điểm cực biên (Extreme point).

- Điểm ngoài biên (Off point).

- Điểm trong biên ( )Interior point.

168

Hình 9: Phân loại miền biên

* Ví dụ cho phân tích giá trị biên

Kiểm tra tính hợp lệ của tháng trong năm thì ta có thể thiết kế như sau:

 Giá trị biên: 1 và 12

 Giá trị cận biên ở bên trong: 2 và 11

 Giá trị cận biên ở bên ngoài: 0 và 13

c. Đồ thị nguyên nhân – hệ quả.

* Định nghĩa.

Một điểm yếu của hai phương pháp trên là chúng không khảo sát sự kết hợp của các

trường hợp đầu vào. Việc kiểm tra sự kết hợp đầu vào không phải là một nhiệm vụ đơn giản

bởi vì nếu bạn phân lớp tương đương các trạng thái đầu vào, thì số lượng sự kết hợp thường

là rất lớn. Nếu bạn không có cách lựa chọn có hệ thống một tập con các trạng thái đầu vào,

có lẽ bạn sẽ chọn ra một tập tùy hứng các điều kiện, điều này có thể dẫn tới việc kiểm thử

không có hiệu quả.

Đồ thị nguyên nhân – kết quả hỗ trợ trong việc lựa chọn một cách có hệ thống tập

các ca kiểm thử có hiệu quả cao. Nó có tác động có lợi ảnh hưởng tới việc chỉ ra tình trạng

chưa đầy đủ và nhập nhằng trong đặc tả. Nó cung cấp cả cách biểu diễn chính xác cho các

điều kiện logic và hành động tương ứng.

Kỹ thuật gồm có 4 bước:

 Xác định điều kiện vào và hành động cho mỗi module cần kiểm định.

 Xác định đồ thị nguyên nhân – kết quả.

 Đồ thị được chuyển thành bảng quyết định.

 Những phần trong bảng quyết định được chuyển thành test case.

* Các ký hiệu cơ bản.

- Mỗi nút có giá trị là 0 hoặc 1.

- 0 mô tả trạng thái vắng mặt và 1 mô tả trạng thái có mặt.

169

Hình 10: Các ký hiệu của đồ thị nguyên nhân – kết quả.

- Hàm đồng nhất (Identity) nói:

 Nếu a là 1 thì b là 1

 Nếu a là 0 thì b là 0

- Hàm NOT nói:

 Nếu a là 1 thì b là 0

 Nếu a là 0 thì b là 1

- Hàm OR nói: (Cho phép số lượng đầu vào là bất kỳ)

 Nếu a hoặc b hoặc c là 1 thì d là 1

 Nếu a hoặc b hoặc c là 0 thì d là 0.

- Hàm AND nói: (Số lượng đầu vào là bất kỳ)

 Nếu cả a và b là 1 thì c là 1

 Nếu cả a và b là 0 thì c là 0.

* Các ký hiệu ràng buộc.

Hình 11: Các ký hiệu ràng buộc trong đồ thị nguyên nhân – kết quả.

- Ràng buộc E (Exclude – loại trừ):

 Khẳng định tối đa rằng, chỉ có thể a hoặc b là 1(a,b không đồng thời = 1)

- Ràng buộc I (Include – bao hàm):

 Khẳng định ít nhất một trong a,b hoặc c phải luôn là 1(a,b,c không đồng thời

bằng 0)

170

- Ràng buộc O (Only – chỉ một):

 Một và chỉ một a hoặc b là 1

- Ràng buộc R (Request – yêu cầu):

 Khi a là 1 thì b phải là 1

- Ràng buộc M (Mask – mặt lạ):

 Nếu kết quả a là 1 thì kết quả b bắt buộc phải là 0.

Bước tiếp theo là tạo bảng quyết định mục vào giới hạn – limited-entry decision

table. Tương tự với các bảng quyết định, thì nguyên nhân chính là các điều kiện và kết quả

chính là các hành động.

Quy trình được sử dụng là như sau:

 Chọn một kết quả để là trạng thái có mặt (1).

 Lần ngược trở lại đồ thị, tìm tất cả những sự kết hợp của các nguyên nhân

(đối tượng cho các rằng buộc) mà sẽ thiết lập kết quả này thành 1.

 Tạo một cột trong bảng quyết định cho mỗi sự kết hợp nguyên nhân.

 Với mỗi sự kết hợp, hãy quy định trạng thái của tất cả các kết quả khác và đặt

chúng vào mỗi cột.

Trong khi biểu diễn bước 2, cần quan tâm các vấn đề sau:

 Khi lần ngược trở lại qua một nút mà đầu ra của nó là 1, không bao giờ thiếtor

lập nhiều hơn 1 đầu vào cho nút là 1 một cách đồng thời. Điều này được gọior

là – . Mục tiêu của nó là để ngăn chặn dò lỗipath sensitizing làm nhạy đường đi

thất bại vì một nguyên nhân che đi một nguyên nhân khác.

 Khi lần ngược trở lại qua một nút mà đầu ra của nó là 0, dĩ nhiên, phải liệtand

kê tất cả các sự kết hợp đầu vào dẫn tới đầu ra 0. Tuy nhiên, nếu bạn đang khảo

sát trạng thái mà 1 đầu ra là 0 và một hay nhiều đầu ra khác là 1, thì không nhất

thiết phải liệt kê tất cả các điều kiện mà dưới điều kiện đó các đầu vào khác có

thể là 1.

Khi lần ngược trở lại qua một nút mà đầu ra của nó là là 0, chỉ cần liệt kê 1 điềuand

kiện trong đó tất cả đầu vào bằng 0. (Nếu nút ở chính giữa của đồ thị như vậy thì tất cảand

các đầu vào của nó xuất phát từ các nút trung gian khác, có thể có quá nhiều trạng thái mà

trong trạng thái đó tất cả các đầu vào của nó bằng 0.)

Những xem xét được dò theo đồ thị:

 Nếu x=1, không quan tâm về

trường hợp a=b=1 (sự xem xét

thứ 1)





Nếu x=0, liệt kê tất cả các trường

hợp trong đó a=b=0.



 Nếu =1, liệt kê tất cả các trườngx

171

hợp trong đó a=b=c=1.



 Nếu =0, bao gồm chỉ 1 trườngx

hợp mà (sự xem xét 3).a=b=c=0

Đối với các trạng thái mà abc là

001, 010, 100, 011, 101 và 110 ,

bao gồm chỉ 1 trường hợp mỗi

trạng thái (sự xem xét 2).

Hình 12: Các hình biểu diễn dò theo đồ thị

- Ví dụ cho bài toán nhập tháng trong một chương trình. Sử dụng phương pháp đồ thị

nguyên nhân – kết quả để thiết kế:

 Bước 1: Xác định điều kiện nhập vào.

Cause ( Điều kiện vào) Effect (Hành

động)

1. Số nguyên ≥ 1

2. Số nguyên ≤ 12

3. Số < 1

4. Số > 12

5. Chuỗi

6. Không phải số nguyên

A: Đúng

B: Sai

C: Nghi ngờ

 Xây dựng đồ thị. ( )có sử dụng các ký hiệu cơ bản và cá ký hiệu ràng buộc

Hình 13: Đồ thị của ví dụ nhập tháng.

Nhận xét:

Vẽ đồ thị nguyên nhân – kết quả là phương pháp tạo các ca kiểm thử có hệ thống mô

tả sự kết hợp của các điều kiện. Sự thay đổi sẽ là 1 sự lựa chọn kết hợp không thể dự tính

trước, nhưng khi thực hiện như vậy, có vẻ như bạn sẽ bỏ sót nhiều ca kiểm thử “thú vị”

được xác định bằng đồ thị nguyên nhân – kết quả .

172

Vì vẽ đồ thị nguyên nhân – kết quả yêu cầu chuyển một đặc tả thành một mạng logic

Boolean, nó cung cấp một triển vọng khác và sự hiểu biết sâu sắc hơn nữa về đặc tả. Trên

thực tế, sự phát triển của 1 đồ thị nguyên nhân – kết quả là cách hay để khám phá sự mơ hồ

và chưa đầy đủ trong các đặc tả.

Mặc dù việc vẽ đồ thị nguyên nhân – kết quả tạo ra tập các ca kiểm thử hữu dụng,

nhưng thông thường nó không tạo ra tất cả các ca kiểm thử hữu dụng mà có thể được nhận

biết. Ngoài ra, đồ thị nguyên nhân – kết quả không khảo sát thỏa đáng các điều kiện giới

hạn. Dĩ nhiên, bạn có thể cố gắng bao phủ các điều kiện giới hạn trong suốt quá trình.

Tuy nhiên, vấn đề trong việc thực hiện điều này là nó làm cho đồ thị rất phức tạp và

dẫn tới số lượng rất lớn các ca kiểm thử. Vì thế, tốt nhất là xét 1 sự phân tích giá trị giới hạn

tách rời nhau.

Vì đồ thị nguyên nhân – kết quả làm chúng ta mất thời gian trong việc chọn các giá

trị cụ thể cho các toán hạng, nên các điều kiện giới hạn có thể bị pha trộn thành các ca kiểm

thử xuất phát từ đồ thị nguyên nhân – kết quả. Vì vậy, chúng ta đạt được một tập các ca

kiểm thử nhỏ nhưng hiệu quả mà thỏa mãn cả 2 mục tiêu.

d. Đoán lỗi – Error Guessing

Một kỹ thuật thiết kế test-case khác là . Tester được đưa choerror guessing – đoán lỗi

1 chương trình đặc biệt, họ phỏng đoán, cả bằng trực giác và kinh nghiệm, các loại lỗi có

thể và sau đó viết các ca kiểm thử để đưa ra các lỗi đó.

Thật khó để đưa ra một quy trình cho kỹ thuật đoán lỗi vì nó là một quy trình có tính

trực giác cao và không thể dự đoán trước. Ý tưởng cơ bản là liệt kê một danh sách các lỗi có

thể hay các trường hợp dễ xảy ra lỗi và sau đó viết các ca kiểm thử dựa trên danh sách đó.

Một ý tưởng khác để xác định các ca kiểm thử có liên đới với các giả định mà lập trình viên

có thể đã thực hiện khi đọc đặc tả (tức là, những thứ bị bỏ sót khỏi đặc tả, hoặc là do tình cờ,

hoặc là vì người viết có cảm giác những đặc tả đó là rõ ràng). Nói cách khác, bạn liệt kê

những trường hợp đặc biệt đó mà có thể đã bị bỏ sót khi chương trình được thiết kế.

8.2.2. Phương pháp kiểm thử hộp trắng – White box testing.

Kiểm thử hộp trắng có liên quan tới mức độ mà các ca kiểm thử thực hiện hay bao

phủ tính logic (mã nguồn) của chương trình. Kiểm thử hộp trắng cơ bản là việc thực hiện

mọi đường đi trong chương trình, nhưng việc kiểm thử đầy đủ đường đi là một mục đích

không thực tế cho một chương trình với các vòng lặp. Các tiêu chuẩn trong kiểm thử bao

phủ logic gồm có:

a. Bao phủ câu lệnh.

Tư tưởng: Thực hiện mọi câu lệnh trong chương trình ít nhất 1 lần.

Xét ví dụ với đoạn mã lệnh JAVA sau:

public void A (int a, int b, int x){

if (a>1 && b==0) {x=x/a;}

if (a==2||x>1){x=x-1;}

}

173

Hình 14: Một chương trình nhỏ để kiểm thử

Bạn có thể thực hiện mọi câu lệnh bằng việc viết 1 ca kiểm thử đơn đi qua đường

ace. Tức là, bằng việc đặt A=2, B=0 và X=3 tại điểm a, mỗi câu lệnh sẽ được thực hiện 1

lần (thực tế, X có thể được gán bất kỳ giá trị nào).

Thường tiêu chuẩn này khá kém. Ví dụ, có lẽ nếu quyết định đầu tiên là phép or chứ

không phải phép thì lỗi này sẽ không được phát hiện. Hay nếu quyết định thứ hai màand

bắt đầu với , lỗi này cũng sẽ không được tìm ra. Cũng vậy, có 1 đường đi qua chươngx>0

trình mà ở đó không thay đổi (đường đi ). Nếu đây là 1 lỗi, thì lỗi này có thể không tìmx abd

ra. Hay nói cách khác, tiêu chuẩn bao phủ câu lệnh quá yếu đến nỗi mà nó thường là vô ích.

b. Bao phủ quyết định

Tư tưởng: Viết đủ các ca kiểm thử mà mỗi quyết định có kết luận đúng hay sai ít

nhất 1 lần. Nói cách khác, mỗi hướng phân nhánh phải được xem xét kỹ lưỡng ít nhất 1 lần.

Các ví dụ về câu lệnh rẽ nhánh hay quyết định là các câu lệnh switch, do-while, và if-

else. Các câu lệnh đa đường GOTO thường sử dụng trong một số ngôn ngữ lập trình như

FORTRAN.

Bao phủ quyết định thường thỏa mãn bao phủ câu lệnh. Vì mỗi câu lệnh là trên sự bắt

nguồn một đường đi phụ nào đó hoặc là từ 1 câu lệnh rẽ nhánh hoặc là từ điểm vào của

chương trình, mỗi câu lệnh phải được thực hiện nếu mỗi quyết định rẽ nhánh được thực

hiện. Tuy nhiên, có ít nhất 3 ngoại lệ:

 Những chương trình không có quyết định.

 Những chương trình hay thường trình con/phương thức với nhiều điểm vào.

Một câu lệnh đã cho có thể được thực hiện nếu và chỉ nếu chương trình được

nhập vào tại 1 điểm đầu vào riêng.

 Các câu lệnh bên trong các ON-unit. Việc đi qua mỗi hướng rẽ nhánh sẽ là

không nhất thiết làm cho tất cả các ON-unit được thực thi.

Vì chúng ta đã thấy rằng bao phủ câu lệnh là điều kiện cần thiết, nên một chiến lược

tốt hơn là bao phủ quyết định nên được định nghĩa bao hàm cả bao phủ câu lệnh. Do đó, bao

174

phủ quyết định yêu cầu mỗi quyết định phải có kết luận đúng hoặc sai, và mỗi câu lệnh đó

phải được thực hiện ít nhất 1 lần.

Phương pháp này chỉ xem xét những quyết định hay những sự phân nhánh 2 đường

và phải được sửa đổi cho những chương trình có chứa những quyết định đa đường. Ví dụ,

các chương trình JAVA có chứa các lệnh , các chương trình FORTRAN chứaselect (case)

các lệnh số học (ba đường) hoặc các lệnh tính toán hay số học , và các chương trìnhif GOTO

COBOL chứa các lệnh biến đổi hay các lệnh (các lệnhGOTO GO-TO-DEPENDING-ON

goto phụ thuộc). Với những chương trình như vậy, tiêu chuẩn này đang sử dụng mỗi kết

luận có thể của tất cả các quyết định ít nhất 1 lần và gọi mỗi điểm vào tới chương trình hay

thường trình con ít nhất 1 lần.

Trong hình 14, bao phủ quyết định có thể đạt được bởi ít nhất 2 ca kiểm thử bao phủ

các đường và hoặc và . Nếu chúng ta chọn khả năng thứ hai, thì 2 đầu vàoace abd acd abe

test-case là và .A=3, B=0, X=3 A=2, B=1, X=1

Bao phủ quyết định là 1 tiêu chuẩn mạnh hơn bao phủ câu lệnh, nhưng vẫn khá yếu.

Ví dụ, chỉ có 50% cơ hội là chúng ta sẽ tìm ra con đường trong đó không bị thay đổi (víx

dụ, chỉ khi bạn chọn khả năng thứ nhất). Nếu quyết định thứ hai bị lỗi (nếu như đáng lẽ phải

nói là thay vì ), lỗi này sẽ không được phát hiện bằng 2 ca kiểm thử trong ví dụx<1 x>1

trước.

c. Bao phủ điều kiện

Tư tưởng: Viết đủ các ca kiểm thử để đảm bảo rằng mỗi điều kiện trong một quyết

định đảm nhận tất cả các kết quả có thể ít nhất một lần.

Vì vậy, như với bao phủ quyết định, thì bao phủ điều kiện không phải luôn luôn dẫn

tới việc thực thi mỗi câu lệnh. Thêm vào đó, trong tiêu chuẩn bao phủ điều kiện, mỗi điểm

vào chương trình hay thường trình con, cũng như các ON-unit, được gọi ít nhất 1 lần. Ví dụ,

câu lệnh rẽ nhánh do k=0 to 50 while (j-k<quest) có chứa 2 điều kiện là k<=50, và j-

k<quest. Do đó, các ca kiểm thử sẽ được yêu cầu cho những tình huống k<=50, k>50 (để

đến lần lặp cuối cùng của vòng lặp), j-k<quest, và j-k>=quest.

Hình 2.1 có 4 điều kiện: Do đó các ca kiểm thử đầy đủ là cầnA>1, B=0, A=2, X>1.

thiết để thúc đẩy những trạng thái mà có mặt tại điểm và A>1, A<=1, B=0 và B<>0 a A=2,

A<>2, X>1, X<=1 có mặt tại điểm b. Số lượng đầy đủ các ca kiểm thử thỏa mãn tiêu chuẩn

và những đường đi mà được đi qua bởi mỗi ca kiểm thử là:

1. A=2, B=0, X=4 ace

2. A=1, B=1, X=1 abd

Chú ý là, mặc dù cùng số lượng các ca kiểm thử được tạo ra cho ví dụ này, nhưng

bao phủ điều kiện thường tốt hơn bao phủ quyết định là vì nó có thể (nhưng không luôn

luôn) gây ra mọi điều kiện riêng trong 1 quyết định để thực hiện với cả hai kết quả, trong

khi bao phủ quyết định lại không. Ví dụ trong cùng câu lệnh rẽ nhánh: DO K=0 TO 50

WHILE (J-K<QUEST) là 1 nhánh 2 đường (thực hiện thân vòng lặp hay bỏ qua nó). Nếu

bạn đang sử dụng kiểm thử quyết định, thì tiêu chuẩn này có thể được thỏa mãn bằng cách

cho vòng lặp chạy từ tới , mà chưa từng kiểm tra trường hợp trong đó mệnh đềK=0 51

175

WHILE bị sai. Tuy nhiên, với tiêu chuẩn bao phủ điều kiện, 1 ca kiểm thử sẽ cần phải cho ra

1 kết quả sai cho những điều kiện .J-K<QUEST

Mặc dù nếu mới nhìn thoáng qua, tiêu chuẩn bao phủ điều kiện xem ra thỏa mãn tiêu

chuẩn bao phủ quyết định, nhưng không phải lúc nào cũng vậy. Nếu quyết định IF (A&B)

được kiểm tra, thì tiêu chuẩn bao phủ điều kiện sẽ cho phép bạn viết 2 ca kiểm thử - A đúng,

B sai, và A sai, B đúng – nhưng điều này sẽ không làm cho mệnh đề của câu lệnh THEN IF

được thực hiện.

Ví dụ, 2 ca kiểm thử khác:

1. A=1, B=0, X=3

2. A=2, B=1, X=1

d. Bao phủ quyết định – điều kiện.

Tư tưởng: Thực hiện đủ các ca kiểm thử mà mỗi điều kiện trong 1 quyết định thực

hiện trên tất cả các kết quả có thể ít nhất 1 lần, và mỗi điểm vào được gọi ít nhất 1 lần.

Điểm yếu của bao phủ quyết định/điều kiện là mặc dù xem ra nó có thể sử dụng tất

cả các kết quả của tất cả các điều kiện, nhưng thường không phải vậy vì những điều kiện

chắc chắn đã cản các điều kiện khác.

Hình 15: Mã máy cho chương trình

Biểu đồ tiến trình trong hình 15 là cách 1 trình biên dich tạo ra mã máy cho chương

trình trong Hình 14. Các quyết định đa điều kiện trong chương trình nguồn đã bị chia thành

các quyết định và các nhánh riêng vì hầu hết các máy không được chế tạo để có thể thực

hiện các quyết định đa điều kiện. Khi đó 1 bao phủ kiểm thử tỉ mỉ hơn xuất hiện là việc sử

dụng tất cả các kết quả có thể của mỗi quyết định gốc. Hai ca kiểm thử bao phủ quyết định

trước không làm được điều này; chúng không thể sử dụng kết quả của quyết định H vàfalse

kết quả của quyết định K. true

Lí do, như đã được chỉ ra trong hình 15, là những kết quả của các điều kiện trong các

biểu thức và có thể cản trở hay ngăn chặn việc ước lượng các quyết định khác. Ví dụ,and or

nếu 1 điều kiện là sai, không cần kiểm tra các điều kiện tiếp theo trong biểu thức.and

Tương tự như vậy, nếu 1 điều kiện là đúng thì cũng không cần kiểm tra các điều kiện cònor

176

lại. Do đó, các lỗi trong biểu thức logic không phải lúc nào cũng được phát hiện bằng các

tiêu chuẩn bao phủ điều kiện và bao phủ quyết định/điều kiện.

e. Bao phủ đa điều kiện

Tư tưởng: Viết đủ các ca kiểm thử mà tất cả những sự kết hợp của các kết quả điều

kiện có thể trong mỗi quyết định, và tất cả các điểm vào phải được gọi ít nhất 1 lần.

Ví dụ, xét chuỗi mã lệnh sau:

NOTFOUND = TRUE;

DO I=1 TO TABSIZE WHILE (NOTFOUND); /*SEARCH TABLE*/

…searching logic…;

END;

Bốn tình huống để kiểm thử là:

1. I<= TABSIZE NOTFOUND và có giá trị đúng (đang duyệt)

2. I<= TABSIZE và NOTFOUND có giá trị sai (tìm thấy mục vào trước khi gặp

cuối bảng).

3. I>TABSIZE NOTFOUND và có giá trị đúng (gặp cuối bảng mà không tìm

thấy mục vào).

4. I>TABSIZE và có giá trị sai (mục vào là cái cuối cùng trongNOTFOUND

bảng).

Dễ nhận thấy là tập hợp các ca kiểm thử thỏa mãn tiêu chuẩn đa điều kiện cũng thỏa

mãn các tiêu chuẩn bao phủ quyết định, bao phủ điều kiện và bao phủ quyết định/điều kiện.

Quay lại hình 14, các ca kiểm thử phải bao phủ 8 sự kết hợp:

1. A>1, B= 0

2. A>1, B<>0

3. A<=1, B=0

4. A<=1, B<>0

5. A=2, X>1

6. A=2, X<=1

7. A<>2, X>1

8. A<>2, X<=1

Vì là ca kiểm thử sớm hơn, nên cần chú ý là các trường hợp từ 5 đến 8 biểu diễn các

giá trị tại vị trí câu lệnh thứ hai. Vì có thể thay đổi ở trên câu lệnh này, nên giá trịIF X IF

cần tại câu lệnh này phải được sao dự phòng thông qua tính logic để tìm ra các giá trị đầuIF

vào tương ứng.

Những sự kết hợp để được kiểm tra này không nhất thiết ngụ ý rằng cần thực hiện cả

8 ca kiểm thử. Trên thực tế, chúng có thể được bao phủ bởi 4 ca kiểm thử. Các giá trị đầu

vào kiểm thử, và sự kết hợp mà chúng bao phủ, là như sau:

A=2, B=0, X=4 Bao phủ trường hợp 1, 5

177

A=2, B=1, X=1 Bao phủ trường hợp 2, 6

A=1, B=0, X=2 Bao phủ trường hợp 3, 7

A=1, B=1, X=1 Bao phủ trường hợp 4, 8

Thực tế là việc có 4 ca kiểm thử và 4 đường đi riêng biệt trong hình 14 chỉ là sự

trùng hợp ngẫu nhiên. Trên thực tế, 4 ca kiểm thử này không bao phủ mọi đường đi, chúng

bỏ qua đường đi Ví dụ, bạn sẽ cần 8 ca kiểm thử cho quyết định sau mặc dù nó chỉacd.

chứa 2 đường đi:

If (x==y&&length(z)==0&&FLAG) { J=1;}

Else { I=1;}

Trong trường hợp các vòng lặp, số lượng các ca kiểm thử được yêu cầu bởi tiêu

chuẩn đa điều kiện thường ít hơn nhiều số lượng đường đi.

Tóm lại, đối với những chương trình chỉ chứa 1 điều kiện trên 1 quyết định, thì 1 tiêu

chuẩn kiểm thử nhỏ nhất là một số lượng đủ các ca kiểm thử để (1) gọi tất cả các kết quả

của mỗi quyết định ít nhất 1 lần và (2) gọi mỗi điểm của mục vào (như là điểm vào hay ON-

unit) ít nhất 1 lần, để đảm bảo là tất cả các câu lệnh được thực hiện ít nhất 1 lần. Đối với

những chương trình chứa các quyết định có đa điều kiện thì tiêu chuẩn tối thiểu là số lượng

đủ các ca kiểm thử để gọi tất cả những sự kết hợp có thể của các kết quả điều kiện trong mỗi

quyết định, và tất cả các điểm vào của chương trình ít nhất 1 lần.

8.3. Các chiến lược kiểm thử

Các cấp độ của kiểm thử phản ánh cấp độ trong mô hình thác nước của vòng đời

phát triển phần mềm. Ba cấp độ: Đặc tả, Thiết kế cơ bản, Thiết kế chi tiết tương ứng với ba

cấp độ của kiểm thử: kiểm thử đơn vị, kiểm thử tích hợp và kiểm thử hệ thống.

Thông thường, kiểm thử theo cấu trúc tương ứng với mức độ đơn vị, kiểm

thử theo chức năng tương ứng với mức độ hệ thống.

8.3.1. Unit Test – Kiểm tra mức đơn vị

Một Unit là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm tra được. Theo

định nghĩa này, các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc các phương

thức (Method) đều có thể được xem là Unit.

Unit Test thường do lập trình viên thực hiện. Công đoạn này cần được thực hiện càng

sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm. Thông

thường, Unit Test đòi hỏi kiểm tra viên có kiến thức về thiết kế và code của chương trình.

Mục đích của Unit Test là bảo đảm thông tin được xử lý và xuất (khỏi Unit) là chính xác,

trong mối tương quan với dữ liệu nhập và chức năng của Unit. Điều này thường đòi hỏi

tất cả các nhánh bên trong Unit đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi.

Một nhánh thường là một chuỗi các lệnh được thực thi trong một Unit, ví dụ: chuỗi các

lệnh sau điều kiện If và nằm giữa then … else là một nhánh. Thực tế việc chọn lựa các

nhánh để đơn giản hóa việc kiểm tra và quét hết Unit đòi hỏi phải có kỹ thuật, đôi khi phải

dùng thuật toán để chọn lựa.

178

Cũng như các mức kiểm tra khác, Unit Test cũng đòi hỏi phải chuẩn bị trước các

tình huống (test case) hoặc kịch bản (script), trong đó chỉ định rõ dữ liệu vào, các bước thực

hiện và dữ liệu mong chờ sẽ xuất ra. Các test case và script này nên được giữ lại để tái sử

dụng.

8.3.2. Integration Test – Kiểm tra tích hợp

Integration test kết hợp các thành phần của một ứng dụng và kiểm tra như một ứng

dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì

Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng.

Integration Test có 2 mục tiêu chính:

- Phát hiện lỗi giao tiếp xảy ra giữa các Unit.

- Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (subsystem) và cuối cùng là

nguyên hệ thống hoàn chỉnh (system) chuẩn bị cho kiểm tra ở mức hệ thống (System Test).

Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và cấu

trúc nội tại của Unit. Có một số phép kiểm tra đơn giản trên giao tiếp giữa Unit với các

thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit thật sự được kiểm tra

đầy đủ khi các Unit tích hợp với nhau trong khi thực hiện Integration Test.

Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những Unit đã được

kiểm tra cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã được sửa chữa. Một

số người hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với các giao tiếp giả

lập thì không cần phải thực hiện Integration Test nữa. Thực tế việc tích hợp giữa các

Unit dẫn đến những tình huống hoàn toàn khác.

Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từng Unit.

Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tích hợp trước đó

và đã hoàn tất (passed) các đợt Integration Test trước đó. Lúc này, ta chỉ cần kiểm tra giao

tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trước đó, điều này làm cho số

lượng kiểm tra sẽ giảm đi rất nhiều, sai sót sẽ giảm đáng kể.

Có 4 loại kiểm tra trong Integration Test:

- Kiểm tra cấu trúc (structure): Tương tự White Box Test (kiểm tra nhằm bảo đảm

các thành phần bên trong của một chương trình chạy đúng), chú trọng đến hoạt động của

các thành phần cấu trúc nội tại của chương trình chẳng hạn các lệnh và nhánh bên trong.

- Kiểm tra chức năng (functional): Tương tự Black Box Test (kiểm tra chỉ chú trọng

đến chức năng của chương trình, không quan tâm đến cấu trúc bên trong), chỉ khảo sát chức

năng của chương trình theo yêu cầu kỹ thuật.

- Kiểm tra hiệu năng (performance): Kiểm tra việc vận hành của hệ thống.

- Kiểm tra khả năng chịu tải (stress): Kiểm tra các giới hạn của hệ thống.

8.3.3. System Test - Kiểm tra mức hệ thống

Mục đích System Test là kiểm tra thiết kế và toàn bộ hệ thống (sau khi tích hợp) có

thỏa mãn yêu cầu đặt ra hay không. System Test bắt đầu khi tất cả các bộ phận của phầm

mềm đã được tích hợp thành công. Thông thường loại kiểm tra này tốn rất nhiều công sức

179

và thời gian. Trong nhiều trường hợp, việc kiểm tra đòi hỏi một số thiết bị phụ trợ, phần

mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố,

hoặc hệ thống nhúng. Ở mức độ hệ thống, người kiểm tra cũng tìm kiếm các lỗi, nhưng

trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến

chất lượng của toàn hệ thống.

Điểm khác nhau then chốt giữa Integration Test và System Test là System Test chú

trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự giao tiếp

giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau. Thông thường ta phải thực

hiện Unit Test và Integration Test để bảo đảm mọi Unit và sự tương tác giữa chúng hoạt

động chính xác trước khi thực hiện System Test.

Sau khi hoàn thành Integration Test, một hệ thống phần mềm đã được hình

thành cùng với các thành phần đã được kiểm tra đầy đủ. Tại thời điểm này, lập trình viên

hoặc kiểm tra viên (tester) bắt đầu kiểm tra phần mềm như một hệ thống hoàn chỉnh. Việc

lập kế hoạch cho System Test nên bắt đầu từ giai đoạn hình thành và phân tích các yêu

cầu. Phần sau ta sẽ nói rõ hơn về một quy trình System Test cơ bản và điển hình.

System Test kiểm tra cả các hành vi chức năng của phần mềm lẫn các yêu cầu về

chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật. Mức kiểm tra

này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm hoặc phần cứng bên

ngoài, chẳng hạn các lỗi “tắc nghẽn” (deadlock) hoặc chiếm dụng bộ nhớ. Sau giai đoạn

System Test, PM thường đã sẵn sàng cho khách hàng hoặc người dùng cuối cùng kiểm

tra để chấp nhận (Acceptance Test) hoặc dùng thử (Alpha/Beta Test).

Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Test

thường được thực hiện bởi một nhóm kiểm tra viên hoàn toàn độc lập với nhóm phát triển

dự án.

Bản thân System Test lại gồm nhiều loại kiểm tra khác nhau (xem hình 3), phổ biến

nhất gồm:

- Kiểm tra chức năng (Functional Test): bảo đảm các hành vi của hệ thống thỏa mãn

đúng yêu cầu thiết kế.

- Kiểm tra khả năng vận hành (Performance Test): bảo đảm tối ưu việc phân bổ tài

nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu

truy vấn…

- Kiểm tra khả năng chịu tải (Stress Test hay Load Test): bảo đảm hệ thống vận

hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất cùng lúc). Stress Test tập trung

vào các trạng thái tới hạn, các “điểm chết”, các tình huống bất thường…

- Kiểm tra cấu hình (Configuration Test)

- Kiểm tra khả năng bảo mật (Security Test): bảo đảm tính toàn vẹn, bảo mật của dữ

liệu và của hệ thống.

- Kiểm tra khả năng phục hồi (Recovery Test): bảo đảm hệ thống có khả năng khôi

phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan

trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến.

180

8.3.4. Kiểm thử chấp nhận – Acceptance test.

Thông thường, sau giai đoạn System Test là Acceptance Test, được khách hàng thực

hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đích của Acceptance Test là để

chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận

sản phẩm (và trả tiền thanh toán hợp đồng).

Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường hợp,

các phép kiểm thử của System Test và Acceptance Test gần như tương tự, nhưng bản chất

và cách thức thực hiện lại rất khác biệt.

Đối với những sản phẩm dành bán rộng rãi trên thị trường cho nhiều người sử dụng,

thông thường sẽ thông qua hai loại kiểm thử gọi là kiểm thử Alpha – và kiểmAlpha Test

thử Beta – . Với Alpha Test, người dùng kiểm thử phần mềm ngay tại nơi phátBeta Test

triển phần mềm, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa.

Với Beta Test, phần mềm sẽ được gửi tới cho người dùng để kiểm thử ngay trong môi

trường thực, lỗi hoặc phản hồi cũng sẽ gửi ngược lại cho lập trình viên để sửa chữa.

Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá trình

phát triển phần mềm thì kết quả Acceptance Test sẽ sai lệch rất lớn, mặc dù phần mềm đã

trải qua tất cả các kiểm thử trước đó. Sự sai lệch này liên quan đến việc hiểu sai yêu cầu

cũng như sự mong chờ của khách hàng. Ví dụ đôi khi một phần mềm xuất sắc vượt qua các

phép kiểm thử về chức năng thực hiện bởi nhóm thực hiện dự án, nhưng khách hàng khi

kiểm thử sau cùng vẫn thất vọng vì bố cục màn hình nghèo nàn, thao tác không tự nhiên,

không theo tập quán sử dụng của khách hàng v.v...

Gắn liền với giai đoạn Acceptance Test thường là một nhóm những dịch vụ và tài liệu

đi kèm, phổ biến như hướng dẫn cài đặt, sử dụng v.v... Tất cả tài liệu đi kèm phải được cập

nhật và kiểm thử chặt chẽ.

8.4. Các mức độ kiểm thử

Khi thử nghiệm hệ con và thử nghiệm hệ thống (tích hợp), có các chiến lược thử

nghiệm chính là thử nghiệm dưới lên (bottom-up testing) và thử nghiệm trên xuống (top-

down testing).

8.4.1 Thử nghiệm dưới lên

Thử nghiệm dưới lên tiến hành thử nghiệm với các mô đun ở mức độ thấp trước. Mô

đun thượng cấp (mô đun gọi) được thay thế bằng chương trình kiểm thử có nhiện vụ đọc dữ

liệu kiểm thử, gọi mô đun cần kiểm thử và kiểm tra kết quả. Nhược điểm của thử nghiệm

dưới lên là

- Phát hiện chậm các lỗi thiết kế

- Chậm có phiên bản thực hiện được của hệ thống

8.4.2 Thử ngiệm trên xuống

Thử nghiệm trên xuống tiến hành thử nghiệm với các mô đun ở mức cao trước, các

mô đun mức thấp được tạm thời phát triển với các chức năng hạn chế, có giao diện giống

như trong đặc tả. Mô đun mức thấp có thể chỉ đơn giản là trả lại kết quả với một vài đầu vào

định trước.

181

Thử nghiệm trên xuống có ưu điểm là

- Phát hiện sớm các lỗi thiết kế, do đó có thể thiết kế, cài đặt lại với giá rẻ

- Có phiên bản hoạt động sớm (với tính năng hạn chế) do đó có thể sớm tiến hành

thẩm định

Nhược điểm của kiểm thử trên xuống là các chức năng của mô đun cấp thấp nhiều

khi rất phức tạp do đó khó có thể mô phỏng được, dẫn đến không kiểm thử đầy đủ chức

năng hoặc phải đình chỉ kiểm thử cho đến khi các mô đun cấp thấp xây dựng xong.

8.4.3. Kiểm thử hồi quy (Regression Testing)

Phần mềm là một trong những loại sản phẩm thay đổi rất nhanh. Người sử dụng luôn

có yêu cầu cải tiến phần mềm và các chức năng mới. Vì vậy, sự chỉnh sửa phần mềm sau

khi đưa vào sử dụng là cần thiết. Mặt khác, bất kỳ sự sửa đổi nào cùng có thể dẫn đến các

lỗi mới. Phần mềm nhất thiết phải được kiểm thử lại sau khi sửa đổi, giai đoạn kiểm thử này

gọi là kiểm thử hồi quy.

Giai đoạn kiểm thử hồi quy thường tái sử dụng các bộ dữ liệu thử đã sử dụng trong

các giai đoạn trước nhằm kiểm tra rằng không có các lỗi mới được đưa vào. Vấn đề đặt ra ở

đây là trong giai đoạn này, các bộ dữ liệu thử nào được tái sử dụng: kiểm thử đơn vị, kiểm

thử tích hợp hay kiểm thử hệ thống?

Chương 9. Vận hành và bảo trì

9.1. Các hoạt động chuyển giao, bảo trì

Bảo trì phần mềm ( ) bao gồm điều chỉnh các lỗi màtiếng Anh software maintenance

chưa được phát hiện trong các giai đoạn trước của chu kỳ sống của một , nângphần mềm

cấp tính năng sử dụng và an toàn vận hành của phần mềm. Bảo trì phần mềm có thể chiếm

đến 65%-75% công sức trong chu kỳ sống của một phần mềm).

Quá trình phát triển phầm mềm bao gồm rất nhiều giai đoạn: thu thập yêu cầu, phân

tích, thiết kế, xây dựng, kiểm tra, triển khai và bảo trì phần mềm. Nhiệm vụ của giai đoạn

bảo trì phần mềm là giữ cho phần mềm được cập nhật khi môi trường thay đổi và yêu cầu

người sử dụng thay đổi.

Theo (1993), thì bảo trì phần mềm được định nghĩa là việc sửa đổi một phầnIEEE

mềm sau khi đã bàn giao để chỉnh lại các lỗi phát sinh, cải thiện hiệu năng của phần mềm

hoặc các thuộc tính khác, hoặc làm cho phần mềm thích ứng trong một môi trường đã bị

thay đổi. Bảo trì phần mềm được chia thành 4 loại:

 Sửa lại cho đúng (corrective): là việc sửa các lỗi hoặc hỏng hóc phát sinh. Các lỗi

này có thể do lỗi thiết kế, lỗi logic hoặc lỗi coding sản phẩm. Ngoài ra, các lỗi

cũng có thể do quá trình xử lý dữ liệu, hoặc hoạt động của hệ thống.

182

 Thích ứng (adaptative): là việc chỉnh sửa phần mềm cho phù hợp với môi trường

đã thay đổi của sản phẩm. Môi trường ở đây có nghĩa là tất các các yếu tố bên

ngoài sản phẩm như quy tắc kinh doanh, luật pháp, phương thức làm việc,...

 Hoàn thiện: chỉnh sửa để đáp ứng các yêu cầu mới hoặc thay đổi của người sử

dụng. Loại này tập trung vào nâng cao chức năng của hệ thống, hoặc các hoạt

động tăng cường hiệu năng của hệ thống, hoặc đơn giản là cải thiện giao diện.

Nguyên nhân là với một phần mềm thành công, người sử dụng sẽ bắt đầu khám

phá những yêu cầu mới, ngoài yêu cầu mà họ đã đề ra ban đầu, do đó, cần cải tiến

các chức năng.

 Bảo vệ (preventive): mục đích là làm hệ thống dễ dàng bảo trì hơn trong những

lần tiếp theo.

Bảo trì phần mềm bao gồm hai hoạt động chính: sửa chữa các lỗi đã không được phát

hiện trong giai đoạn phát triển và kiểm tra; nâng cấp phần mềm theo yêu cầu phát sinh hoặc

yêu cầu đã được hiểu không đúng trong giai đoạn phát triển.

Mỗi hoạt động bảo trì đều được thực hiện tương tự như một hoạt động trong giai

đoạn phát triển, yêu cầu để dẫn đến hành động bảo trì chính là yêu cầu thay đổi.

9.2. Vai trò của bảo trì

* Bảo trì để tu sửa

- Là bảo trì khắc phục những khiếm khuyết có trong phần mềm

- Một số nguyên nhân điển hình

+ Kỹ sư phần mềm và khách hiểu nhầm nhau

+ Lỗi tiềm ẩn của phần mềm do sơ ý của lập trình hoặc khi kiểm thử chưa bao quát

hết

+ Vấn đề tính năng của phần mềm: không đáp ứng được yêu cầu về bộ nhớ, tệp, . . .

Thiết kế sai,

biên tập sai . . .

+ Thiếu chuẩn hóa trong phát triển phần mềm (trước đó)

- Kỹ nghệ ngược (Reverse Engineering): dò lại thiết kế để tu sửa

- Những lưu ý

+ Mức trừu tượng

+ Tính đầy đủ

+ Tính tương tác

+ Tính định hướng

* Bảo trì để thích hợp

- Là tu chỉnh phần mềm theo thay đổi của môi trường bên ngoài nhằm duy trì và

quản lý phần mềm theo vòng đời của nó

- Thay đổi phần mềm thích nghi với môi trường: công nghệ phần cứng, môi trường

phần mềm

183

- Những nguyên nhân chính:

+ Thay đổi về phần cứng (ngoại vi, máy chủ,. . .)

+ Thay đổi về phần mềm (môi trường): đổi OS

+ Thay đổi cấu trúc tệp hoặc mở rộng CSDL

* Bảo trì để cải tiến

- Là việc tu chỉnh hệ phần mềm theo các yêu cầu ngày càng hoàn thiện hơn, đầy đủ

hơn, hợp lý hơn

- Những nguyên nhân chính:

+ Do muốn nâng cao hiệu suất nên thường hay cải tiến phương thức truy cập tệp

+ Mở rộng thêm chức năng mới cho hệ thống

+ Cải tiến quản lý kéo theo cải tiến tư liệu vận hành và trình tự công việc

+ Thay đổi người dùng hoặc thay đổi thao tác

- Còn gọi là tái kỹ nghệ (re-engineering)

- Mục đích: đưa ra một thiết kế cùng chức năng nhưng có chất lượng cao hơn

- Các bước thực hiện:

+ Xây dựng lưu đồ phần mềm

+ Suy dẫn ra biểu thức Boole cho từng dãy xử lý

+ Biên dịch bảng chân lí

+ Tái cấu trúc phần mềm

* Bảo trì để phòng ngừa

- Là công việc tu chỉnh chương trình có tính đến tương lai của phần mềm đó sẽ mở

rộng và thay đổi như thế nào

- Thực ra trong khi thiết kế phần mềm đã phải tính đến tính mở rộng của nó, nên thực

tế ít khi ta gặp bảo trì phòng ngừa nếu như phần mềm được thiết kế tốt

- Mục đích: sửa đổi để thích hợp với yêu cầu thay đổi sẽ có của người dùng

- Thực hiện những thay đổi trên thiết kế không tường minh

- Hiểu hoạt động bên trong chương trình

- Thiết kế / lập trình lại

- Sử dụng công cụ CASE

9.3. Các nội dung bảo trì

Quy trình bảo trì là gì ? Đó là quá trình trong vòng đời của phần mềm, cũng tuân theo

các pha phân tích, thiết kế, phát triển và kiểm thử từ khi phát sinh vấn đề cho đến khi giải

quyết xong

Thao tác bảo trì: Gồm 2 loại

– Tu chỉnh cải đã có (loại 1)

– Thêm cái mới (loại 2)

184

Sơ đồ bảo trì

- Hiểu phần mềm đã có

• Theo tài liệu nắm chắc các chức năng

• Theo tài liệu chi tiết hãy nắm vững đặc tả chi tiết, điều kiện kiểm thử, . . .

• Dò đọc chương trình nguồn, hiểu trình tự xử lý chi tiết của hệ thống

3 việc trên đều là công việc thực thi trên bàn

- Tu sửa phần mềm đã có

• Bảo trì chương trình nguồn, tạo các môđun mới và dịch lại

• Thực hiện kiểm thử unit và tu chỉnh những mục liên quan có trong tư liệu đặc tả

• Chú ý theo sát tác động của môđun được sửa đến các thành phần khác trong hệ

thống

- Phát triển phần mềm mới

• Khi thêm chức năng mới phải phát triển chương trình cho phù hợp với yêu cầu

• Cần tiến hành từ thiết kế, lập trình, gỡ lỗi và kiểm thử unit

• Phản ảnh vào giao diện của phần mềm (thông báo, phiên bản, . . .)

- Kiểm chứng tính nhất quán bằng kiểm thử kết hợp

• Đưa đơn vị (unit) đã dược kiểm thử vào hoạt động trong hệ thống

• Điều chỉnh sự tương tích giữa các môđun

• Dùng các dữ liệu trước đây khi kiểm thử để kiểm thử lại tính nhất quán

• Chú ý hiệu ứng làn sóng trong chỉnh sửa

- Kiểm tra khi hoàn thành bảo trì

• Kiểm tra nội dung mô tả có trong tư liệu đặc tả

• Cách ghi tư liệu có phù hợp với mô tả môi trường phần mềm mới hay không ?

- Lập biểu quản lý bảo trì

• Cần quản lý tình trạng bảo trì

• Lập biểu quản lý tình trạng bảo trì

185

 Ngày tháng, giờ

 Nguyên nhân

 Tóm tắt cách khắc phục

 Chi tiết khắc phục, hiệu ứng làn sóng

 Người làm bảo trì

Tài liệu tham khảo

[1]. Nguyễn Văn Vỵ, Nguyễn Việt Hà, Giáo trình kỹ nghệ phần mềm, NXB

Đại học quốc gia Hà Nội, 2008

[2]. Huỳnh Văn Đức, Giáo trình nhập môn UML, NXB Lao động xã hội, 2003.

[3]. Dương Kiều Hoa, Giáo trình phân tích hệ thống hướng đối tượng với

UML, NXB ĐH Quốc gia TP Hồ Chí Minh, 2007.

[4] . http://www.pcworld.com.vn/pcworld/printArticle.asp?atcl_id=5f5e5d585d5d58

186

MỤC LỤC

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

1.1. Một số khái niệm cơ bản.................................................................................1

1.1.1. Phần mềm.................................................................................................1

1.1.2. Hệ thống phần mềm.................................................................................1

1.2. Tầm quan trọng của phần mềm......................................................................2

1.3. Đặc trưng & chất lượng sản phầm phần mềm................................................3

1.3.1. Đặc trưng phần mềm................................................................................3

1.3.2. Chất lượng sản phầm phần mềm..............................................................3

1.4. Phân loại phần mềm........................................................................................4

1.5. Sự tiến hóa của phần mềm..............................................................................5

1.6. Thực trạng và thách thức trong phát triển phần mềm.....................................6

1.6.1. Thực trạng................................................................................................6

1.6.2. Thách thức................................................................................................6

1.7. Tổng quan về công nghệ phần mềm...............................................................7

1.7.1. Khái niệm.................................................................................................7

1.7.2. Lịch sử phát triển.....................................................................................8

Chương 2. Quy trình phát triển phần mềm........................................................10

2.1. Vòng đời phần mềm.....................................................................................10

2.1.1. Khái niệm...............................................................................................10

2.1.2. Mô hình vòng đời phần mềm của Boehm..............................................10

2.1.3. Suy nghĩ mới về vòng đời phần mềm....................................................10

2.2. Quy trình phát triển phần mềm.....................................................................10

2.2.1. Khái niệm...............................................................................................10

2.2.2. Các hoạt động........................................................................................11

2.3. Một số mô hình thực hiện.............................................................................11

2.3.1. Mô hình tuyến tính.................................................................................11

2.3.2. Phát triển tiến hoá..................................................................................13

187

2.3.3. Phát triển dựa trên thành phần...............................................................15

2.3.4. Kỹ thuật thế hệ thứ tư............................................................................15

2.3.5. Phát triển nhanh ứng dụng (Rapid Application Development ).............17

2.3.6. Phát triển hình thức................................................................................19

2.3.7. Phát triển hướng đối tượng....................................................................19

2.3.8. Phát triển phần mềm mã nguồn mở.......................................................20

2.3.9. Mô hình khác.........................................................................................21

Chương 3. Quản lý dự án phần mềm..................................................................23

3.1. Giới thiệu......................................................................................................23

3.1.1. Dự án và dự án phần mềm.....................................................................23

3.1.2. Quản lý dự án.........................................................................................23

3.2. Các hoạt động quản lý..................................................................................24

3.2.1. Xác định dự án.......................................................................................24

3.2.2. Đo và ước lượng....................................................................................25

3.2.3. Lập lịch..................................................................................................25

3.2.4. Tổ chức dự án........................................................................................29

3.2.5. Theo dõi thực hiện dự án, điều chỉnh lịch biểu......................................31

3.2.6. Viết báo cáo dự án.................................................................................34

3.3. Các yếu tố quản lý........................................................................................35

3.3.1. Quản lý tài nguyên.................................................................................35

3.3.2. Quản lý cấu hình....................................................................................36

3.3.3. Quản lý rủi ro.........................................................................................41

3.3.4. Quản lý thay đổi.....................................................................................46

3.3.5. Quản lý chất lượng.................................................................................50

3.4. Phương pháp & công cụ hỗ trợ quản lý........................................................55

3.4.1. Microsoft Project...................................................................................55

3.4.2. Microsoft SourceSafe.............................................................................56

3.4.3. Visio.......................................................................................................57

Chương 4. Ngôn ngữ mô hình hóa UML.............................................................58

4.1. Ngôn ngữ mô hình hóa thống nhất UML.....................................................58

4.1.1. Giới thiệu...............................................................................................58

4.1.2. Các đặc trưng và khả năng của UML....................................................62

4.1.3. Kiến trúc trong UML.............................................................................63

4.1.4. Mô hình khái niệm của UML.................................................................64

4.1.5. Các biểu đồ............................................................................................70

4.1.6. Rational Rose.........................................................................................75

4.2. Mô hình hóa ca sử dụng................................................................................77

4.2.1. Giới thiệu...............................................................................................77

4.2.2. Mô hình hóa ca sử dụng.........................................................................79

188

4.2.3. Biểu đồ ca sử dụng.................................................................................80

4.2.4. Các biến thể trong một ca sử dụng.........................................................85

4.2.5. Quan hệ giữa các ca sử dụng.................................................................86

4.2.6. Mô tả ca sử dụng....................................................................................88

4.3. Biểu đồ hoạt động (Activity Diagram).........................................................89

Chương 5. Nắm bắt và phân tích yêu cầu...........................................................92

5.1. Vai trò của nắm bắt và phân tích yêu cầu.....................................................92

5.2. Các hoạt động phân tích và đặc tả yêu cầu...................................................93

5.2.1. Nghiên cứu khả thi.................................................................................93

5.2.2. Phân tích yêu cầu...................................................................................94

5.2.3. Xác định yêu cầu....................................................................................95

5.2.4. Đặc tả yêu cầu........................................................................................96

5.3. Sản phẩm của phân tích và đặc tả yêu cầu..................................................100

5.3.1. Báo cáo khả thi.....................................................................................100

5.3.2. Mô hình hệ thống.................................................................................101

5.3.3. Tài liệu định nghĩa yêu cầu (requirement definition)..........................102

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

5.3.5. Tài liệu yêu cầu....................................................................................104

Chương 6. Thiết kế phần mềm...........................................................................106

6.1. Khái niệm, nguyên lý, chất lượng thiết kế..................................................106

6.1.1. Khái niệm.............................................................................................106

6.1.2. Nguyên lý.............................................................................................106

6.1.3. Chất lượng thiết kế...............................................................................107

6.2. Nhiệm vụ thiết kế........................................................................................109

6.2.1. Thiết kế kiến trúc (architectural design)..............................................109

6.2.2. Thiết kế dữ liệu (data design)..............................................................109

6.2.3. Thiết kế chức năng (functional design)................................................110

6.2.4. Thiết kế giao diện người dùng (interface design)................................110

6.3. Yêu cầu đối với thiết kế..............................................................................112

6.4. Phương pháp và công cụ.............................................................................113

6.4.1. Phương pháp thiết kế...........................................................................113

6.4.2. Công cụ................................................................................................116

Chương 7. Lập trình...........................................................................................119

7.1. Ngôn ngữ lập trình......................................................................................119

7.1.1 Đặc trưng của ngôn ngữ lập trình.........................................................119

7.1.2 Lựa chọn ngôn ngữ lập trình.................................................................120

7.1.3 Ngôn ngữ lập trình và và sự ảnh hưởng tới kỹ nghệ phần mềm...........120

7.2. Các phương pháp lập trình..........................................................................120

7.2.1. Lập trình tuần tự...................................................................................120

189

7.2.2. Lập trình cấu trúc.................................................................................121

7.2.3. Lập trình hướng đối tượng...................................................................121

7.2.4. Lập trình logic......................................................................................122

7.3. Phong cách lập trình...................................................................................123

7.3.1 Tài liệu chương trình.............................................................................123

7.3.2 Khai báo dữ liệu....................................................................................123

7.3.3 Xây dựng câu lệnh................................................................................124

7.3.4 Vào/ra....................................................................................................124

7.4. Lập trình tránh lỗi.......................................................................................124

7.4.1 Lập trình thứ lỗi....................................................................................125

7.4.2. Lập trình phòng thủ..............................................................................125

7.5. Lập trình hiệu quả.......................................................................................126

7.5.1. Tính hiệu quả chương trình..................................................................126

7.5.2. Hiệu quả bộ nhớ...................................................................................126

7.5.3. Hiệu quả vào/ra....................................................................................127

Chương 8. Kiểm thử và tích hợp........................................................................128

8.1. Giới thiệu....................................................................................................128

8.1.1. Khái niệm về kiểm thử phần mềm.......................................................128

8.1.2. Mục đích của kiểm thử phần mềm.......................................................128

8.1.3. Nguyên tắc trong kiểm thử phần mềm.................................................128

8.1.4. Phân loại kiểm thử...............................................................................129

8.2. Các phương pháp kiểm thử.........................................................................129

8.2.1. Phương pháp kiểm thử hộp đen – Black box testing...........................129

8.2.2. Phương pháp kiểm thử hộp trắng – White box testing........................137

8.3. Các chiến lược kiểm thử.............................................................................141

8.3.1. Unit Test – Kiểm tra mức đơn vị.........................................................142

8.3.2. Integration Test – Kiểm tra tích hợp....................................................142

8.3.3. System Test - Kiểm tra mức hệ thống..................................................143

8.3.4. Kiểm thử chấp nhận – Acceptance test................................................143

8.4. Các mức độ kiểm thử..................................................................................144

8.4.1 Thử nghiệm dưới lên.............................................................................144

8.4.2 Thử ngiệm trên xuống...........................................................................144

8.4.3. Kiểm thử hồi quy (Regression Testing)...............................................144

Chương 9. Vận hành và bảo trì..........................................................................145

9.1. Các hoạt động chuyển giao, bảo trì............................................................145

9.2. Vai trò của bảo trì.......................................................................................145

9.3. Các nội dung bảo trì....................................................................................146

Tài liệu tham khảo...............................................................................................148

MỤC LỤC.............................................................................................................149

190

191

Bấm Tải xuống để xem toàn bộ.

| 1/191

| | Tải xuống

Preview text:

Chương 1. Tổng quan về phần mềm và công nghệ phần mềm
1.1. Một số khái niệm cơ bản
1.1.1. Phần mềm
Phần mềm thông thường được định nghĩa bao gồm:
- các lệnh máy tính nhằm thực hiện các chức năng xác định
- các cấu trúc dữ liệu cho phép chương trình thao tác với dữ liệu
- các tài liệu giúp cho người dùng có thể vận hành được phần mềm
Bốn thuộc tính chủ chốt mà một hệ phần mềm tốt phải có là:
- Có thể bảo trì được: phần mềm tuổi thọ dài phải được viết và được lập tư liệu
sao cho việc thay đổi có thể tiến hành được mà không quá tốn kém. Đây được coi là
đặc tính chủ chốt nhất của một phần mềm tốt. Để có thể bảo trì được, phần mềm phải
có một thiết kế tốt có tính modun hóa cao, được viết bằng ngôn ngữ bậc cao và được
lập tài liệu (tài liệu phân tích, thiết kế, chú thích mã nguồn, hướng dẫn người dùng...) đầy đủ.
- Đáng tin cậy: phần mềm phải thực hiện được điều mà người tiêu dùng mong
mỏi và không thất bại nhiều hơn những điều đã được đặc tả. Điều này có nghĩa là phần
mềm phải thỏa mãn được nhu cầu của người dùng. Để đạt được yếu tố đáng tin cậy,
trước tiên người phát triển cần phải hiểu một cách đúng đắn yêu cầu của người dùng
và sau đó cần thỏa mãn được các yêu cầu này bằng các thiết kế và cài đặt tốt.
- Có hiệu quả: phần mềm khi hoạt động phải không lãng phí tài nguyên hệ
thống như bộ nhớ, bộ xử lý. Nếu phần mềm chạy quá chậm hay đòi hỏi quá nhiều bộ
nhớ... thì dù có được cài đặt rất nhiều chức năng cũng sẽ không được đưa vào sử dụng.
Tuy nhiên, ngoại trừ các phần mềm nhúng hay thời gian thực đặc biệt, người ta thường
không cực đại hóa mức độ hiệu quả vì rằng việc đó có thể phải dùng đếm các kỹ thuật
đặc thù và cài đặt bằng ngôn ngữ máy khiến cho chi phí tăng cao và phần mềm rất khó
thay đổi (tính bảo trì kém).
- Dễ sử dụng: giao diện người sử dụng phải phù hợp với khả năng và kiến thức
của người dùng, có các tài liệu hướng dẫn và các tiện ích trợ giúp. Đối tượng chính
của các phần mềm nghiệp vụ thường là người không am hiểu về máy tính, họ sẽ xa
lánh các phần mềm khó học, khó sử dụng.
Có thể thấy rõ, việc tối ưu hóa đồng thời các thuộc tính này là rất khó khăn. Các
thuộc tính có thể mẫu thuẫn lẫn nhau, ví dụ như tính hiệu quả và tính dễ sử dụng, tính
bảo trì. Quan hệ giữa chi phí cải tiến và hiệu quả đối với từng thuộc tính không phải là
tuyến tính. Nhiều khi một cải thiện nhỏ trong bất kỳ thuộc tính nào cũng có thể là rất đắt.
Một khó khăn khác của việc phát triển phần mềm là rất khó định lượng các
thuộc tính của phần mềm. Chúng ta thiếu các độ đo và các chuẩn về chất lượng phần 1
mềm. Vấn đề giá cả phải được tính đến khi xây dựng một phần mềm. Chúng ta sẽ xây
dựng được một phần mềm dù phức tạp đến đâu nếu không hạn chế về thời gian và chi
phí. Điều quan trọng là chúng ta phải xây dựng một phần mềm tốt với một giá cả hợp
lý và theo một lịch biểu được định trước.
1.1.2. Hệ thống phần mềm
Tập (hệ thống) các phần mềm có thể hợp tác để thực hiện chức năng lớn hơn:
Mỗi phần mềm thực hiện một công việc và kết hợp các công việc để hoàn thành nhiệm vụ chung
Mỗi phần mềm trong hệ thống còn được gọi là phân hệ/ hệ thống con
(subsystem) hay module phần mềm. Ví dụ
- Có thể xem MSWord là một hệ thống phần mềm bao gồm
+ Module soạn thảo cơ bản
+ Module kiểm tra chính tả, ngữ pháp và sửa lỗi
+ Module xử lý công thức toán học và các ký tự đặc biệt
+ Module tìm kiếm, thay thế văn bản + Module tính toán excel + Module email, tạo website ...
- Phần mềm kế toán là hệ thống gồm + Module Kế toán Lương + Module Kế toán Thu + Module Kế toán Chi + Module Lập Báo cáo
1.2. Tầm quan trọng của phần mềm
- Phần mềm được ứng dụng trong mọi lĩnh vực kinh tế, văn hoá, khoa học, giáo
dục, giải trí, giao tiếp… mang lại hiệu suất và chất lượng cao
- Phần mềm làm thay đổi phong cách và hiệu quả làm việc và tạo ra sự khác
biệt giữa các cá nhân, tổ chức: Phong cách công nghiệp và Tăng năng suất, chất lượng 2
- Các ứng dụng phần mềm phát triển nhanh trên mọi lĩnh vực của xã hội.
+ Hàng không: PM điều khiển không lưu
+ Ngân hàng: PM giao dịch, liên ngân hàng
+ Giáo dục: PM chấm thi trắc nghiệm, PM quản lý đào tạo …
- Sự phụ thuộc của các nền kinh tế vào phần mềm
+ Thu, chi từ phần mềm chiếm tỷ trọng đáng kể trong GDP của các nước phát triển 1 Ấn Độ:
o 2006: xuất khẩu gần 30 tỷ $ phần mềm o 2009: 50 tỷ S
o Dự kiến năm 2020: 225 tỷ $ 2 Trung Quốc: o Năm 2011: 30,4 tỷ
3 Thế giới có >7 triệu kỹ sư CNTT tạo ra 600 tỷ $/ năm
4 Chi phí cho phần mềm năm 2000 lên tới 770 tỷ $
+ Phần mềm sai hỏng kinh tế tổn thất 
o Vệ tinh Ariane 5 nổ tung sau vài giây được phóng lên do lỗi phần
mềm ngày 4/6/1996, thiệt hại 500 triệu $.
o Máy trị xạ Therac – 25 do Canada và Pháp chế tạo, năm 1985 -1987
KTV thao tác lỗi, máy “hào phóng” cho quá liều đối với 6 BN  3 người chết.
1.3. Đặc trưng & chất lượng sản phầm phần mềm
1.3.1. Đặc trưng phần mềm
Chúng ta có thể thấy khó khăn hàng đầu của việc phát triển phần mềm là do
tính chất phần mềm là hệ thống logic, không phải là hệ thống vật lý. Do đó nó có đặc 3
trưng khác biệt đáng kể với các đặc trưng của phần cứng. Dưới đây là 3 yếu tố chính
tạo ra sự phức tạp trong quá trình phát triển cũng như sử dụng, bảo trì phần mềm.
a. Phần mềm không được chế tạo theo nghĩa cổ điển
Phần mềm cũng được được thiết kế, phát triển như phần cứng, nhưng nó không
định hình trước. Chỉ khi phát triển xong người ta có sản phẩm cụ thể và hiểu được nó
có hiệu quả hay không. Tức là ở các bước trung gian, chúng ta rất khó kiểm soát chất lượng của phần mềm.
Giá thành của phần cứng chủ yếu bị chi phối bởi giá thành nguyên vật liệu và
chúng ta tương đối dễ kiểm soát. Trong khi đó, giá thành phần mềm chủ yếu tập chung
vào chi phí nhân công. Quá trình phát triển phần mềm phụ thuộc vào con người (hiểu
biết, khả năng vận dụng, kinh nghiệm và cách thức quản lý) và được tiến hành phát
triển trong điều kiện môi trường (kỹ thuật, xã hội) đa dạng và không ngừng thay đổi.
Do đó chúng ta rất khó ước lượng được chi phí cũng như hiệu quả của phần mềm.
b. Phần mềm không hỏng đi nhưng thoái hóa theo thời gian
Phần mềm không cảm ứng đối với những tác động của môi trường vốn gây cho
phần cứng bị mòn cũ đi, nhưng nó cũng thoái hóa theo thời gian. Thực tế, phần mềm
trải qua thời gian sử dụng cần phải được thay đổi (bảo trì) để đáp ứng nhu cầu luôn
thay đổi của tổ chức sử dụng nó. Mỗi khi thay đổi, sẽ xuất hiện thêm một số khiếm
khuyết mới không thể tránh làm cho số lỗi tiềm ẩn trong phần mềm tăng lên. Dần dần,
phần mềm bị thoái hóa do tỷ lệ sai hỏng ngày càng tăng lên đến mức gây ra những
thiệt hại không thể chấp nhận được.
Việc bảo trì phần mềm phức tạp hơn nhiều và có bản chất khác hẳn so với bảo
trì phần cứng do sự phức tạp của hệ thống phần mềm và sự không có sẵn phần thay thế
cho bộ phận bị lỗi. Chúng ta không thay thế bộ phận bị lỗi bằng cái có sẵn mà thực tế
phải tạo ra một môđun mới. Do đó, thông thường chỉ có nhà sản xuất phần mềm mới
bảo trì (sửa chữa) được hỏng hóc. Sẽ rất khó ước lượng được chi phí cho bảo trì phần mềm.
c. Phần lớn phần mềm đều được xây dựng từ đầu, ít khi được lắp ráp từ thành phần có sẵn
- Phần mềm không có danh mục các thành phần cố định như phần cứng.
- Phần mềm thường được đặt hàng theo một đơn vị hoàn chỉnh, theo yêu cầu riêng của khách hàng.
- Phần mềm ít khi có thể lắp ráp theo một khuôn mẫu có sẵn. Yêu cầu với phần
mềm thay đổi theo môi trường cụ thể mà ở đó nó được xây dựng. Môi trường của phần
mềm (gồm phần cứng, phần mềm nền, con người và tổ chức) không thể định dạng từ
trước và lại thay đổi thường xuyên.
Những yếu tố này dẫn đến chi phí cho phần mềm cao và rất khó đảm bảo được
lịch biểu cho phát triển phần mềm. 4
1.3.2. Chất lượng sản phầm phần mềm
Chất lượng (Quality) bao gồm:
- Chức năng (functions) phần mềm thực hiện hay dịch vụ (services) được phần mềm cung cấp
- Sử dụng được (Usability): Dùng được và có ích; Cần có giao diện tốt và đủ tài liệu hướng dẫn
- Bảo trì được (Maintainability): Có thể sửa đổi khi yêu cầu thay đổi - Tin cậy (Dependability)
+ An toàn (safety): Không gây thiệt hại cho hệ thống hoặc thiệt hại kinh tế cho
đơn vị sử dụng khi xuất hiện lỗi
+ An ninh (Security): Bảo đảm không bị phá hoại vô tình hoặc cố ý
- Hiệu suất (Efficiency): Sử dụng tài nguyên vừa phải, cho kết quả nhanh
- Chi phí thấp (Low cost): Chi phí để phát triển và Giá bán
Khó có thể thỏa mãn tất cả các tính chất, cần phải biết, với từng hệ thống, tính
chất nào quan trọng hơn để ưu tiên cho tính chất đó
1.4. Phân loại phần mềm
Chúng ta có thể chia phần mềm theo miền ứng dụng thành 7 loại như sau:
a. Phần mềm hệ thống
- Là một tập hợp các chương trình được viết để phục vụ cho các chương trình khác
- Xử lý các cấu trúc thông tin phức tạp nhưng xác định (trình biên dịch, trình
soạn thảo, tiện ích quản lý tệp)
- Đặc trưng bởi tương tác chủ yếu với phần cứng máy tính
- Phục vụ nhiều người dùng
- Cấu trúc dữ liệu phức tạp và nhiều giao diện ngoài
b. Phần mềm thời gian thực
Phần mềm điều phối, phân tích hoặc kiểm soát các sự kiện thế giới thực ngay
khi chúng xuất hiện được gọi là phần mềm thời gian thực. Điển hình là các phần mềm
điều khiển các thiết bị tự động. Phần mềm thời gian thực bao gồm các thành tố:
- Thành phần thu thập dữ liệu để thu và định dạng thông tin từ môi trường ngoài
- Thành phần phân tích để biến đổi thông tin theo yêu cầu của ứng dụng
- Thành phần kiểm soát hoặc đưa ra đáp ứng môi trường ngoài
- Thành phần điều phối để điều hòa các thành phần khác sao cho có thể duy trì
việc đáp ứng thời gian thực
Hệ thống thời gian thực phải đáp ứng những ràng buộc thời gian chặt chẽ. 5
c. Phần mềm nghiệp vụ
Là các phần mềm phục vụ các hoạt động kinh doanh hay các nghiệp vụ của tổ
chức, doanh nghiệp. Đây có thể coi là lĩnh vực ứng dụng phần mềm lớn nhất. Điển
hình là các hệ thống thông tin quản lý gắn chặt với CSDL, các ứng dụng tương tác như
xử lý giao tác cho các điểm bán hàng.
d. Phần mềm khoa học và công nghệ
- Được đặc trưng bởi các thuật toán (tính toán trên ma trận số, mô phỏng...).
- Thường đòi hỏi phần cứng có năng lực tính toán cao. e. Phần mềm nhúng
- Nằm trong bộ nhớ chỉ đọc và được dùng để điều khiển các sản phẩm và hệ
thống cho người dùng và thị trường công nghiệp.
- Có các đặc trưng của phần mềm thời gian thực và phần mềm hệ thống.
f. Phần mềm máy tính cá nhân
- Bùng nổ từ khi xuất hiện máy tính cá nhân, giải quyết các bài toán nghiệp vụ
nhỏ như xử lý văn bản, trang tính, đồ họa, quản trị CSDL nhỏ...
- Yếu tố giao diện người-máy rất được chú trọng.
g. Phần mềm trí tuệ nhân tạo
- Dùng các thuật toán phi số để giải quyết các vấn đề phức tạp mà tính toán hay
phân tích trực tiếp không quản lý nổi
- Các ứng dụng chính là: hệ chuyên gia (hệ cơ sở tri thức), nhận dạng (hình ảnh
và tiếng nói), chứng minh định lý và chơi trò chơi, mô phỏng.
Ngoài ra, chúng ta còn có thể kể đến một dạng phần mềm đặc biệt là phần mềm
phục vụ kỹ nghệ phần mềm. Đó là các phần mềm như chương trình dịch, phần mềm
gỡ rối, các công cụ hỗ trợ phân tích thiết kế (CASE)... Các phần mềm này có thể xuất
hiện dưới dạng phần mềm máy tính cá nhân, phần mềm hệ thống hoặc là phần mềm nghiệp vụ.
1.5. Sự tiến hóa của phần mềm
Sự tiến hóa của phần mềm gắn liền với sự tiến hóa của phần cứng và có thể chia làm 4 giai đoạn:
a. Những năm đầu (từ 1950 đến 1960):
- Giai đoạn này phần cứng thay đổi liên tục, số lượng máy tính rất ít và phần
lớn mỗi máy đều được đặt hàng chuyên dụng cho một ứng dụng đặc biệt.
- Phương thức chính là xử lý theo lô (batch), tức là “gói” các chương trình có sử
dụng kết quả của nhau lại thành một khối dể tăng tốc độ thực hiện.
- Thời kỳ này lập trình máy tính được coi là nghệ thuật “theo bản năng”, chưa
có phương pháp hệ thống. Việc phát triển phần mềm chưa được quản lý. 6
- Môi trường lập trình có tính chất cá nhân; thiết kế, tiến trình phần mềm không
tường minh, thường không có tài liệu. Sản xuất có tính đơn chiếc, theo đơn đặt hàng.
Người lập trình thường là người sử dụng và kiêm cả việc bảo trì và sửa lỗi.
b. Thời kỳ trải rộng từ những năm 1960 đến giữa những năm 1970:
- Các hệ thống đa nhiệm, đa người sử dụng (ví dụ: Multics, Unix,...) xuất hiện
dẫn đến khái niệm mới về tương tác người máy. Kỹ thuật này mở ra thế giới mới cho
các ứng dụng và đòi hỏi mức độ tinh vi hơn cho cả phần mềm và phần cứng.
- Nhiều hệ thống thời gian thực với các đặc trưng thu thập, phân tích và biến
đổi dữ liệu từ nhiều nguồn khác nhau và phản ứng (xử lý, tạo output) trong một
khoảng thời gian nhất định xuất hiện. - Tiến bộ lưu trữ trực tuyến làm xuất hiện thế hệ
đầu tiên của hệ quản trị CSDL.
- Số lượng các hệ thống dựa trên máy tính phát triển, nhu cầu phân phối mở
rộng, thư viện phần mềm phát triển, quy mô phần mềm ngày càng lớn làm nẩy sinh
nhu cầu sửa chữa khi gặp lỗi, cần sửa đổi khi người dùng có yêu cầu hay phải thích
nghi với những thay đổi của môi trường phần mềm (phần cứng, hệ điều hành, chương
trình dịch mới). Công việc bảo trì phần mềm dần dần tiêu tốn nhiều công sức và tài
nguyên đến mức báo động.
c. Thời kỳ từ giữa những năm 1970 đến đầu những năm 1990:
- Hệ thống phân tán (bao gồm nhiều máy tính, mỗi máy thực hiện một chức
năng và liên lạc với các máy khác) xuất hiện làm tăng quy mô và độ phức tạp của phần
mềm ứng dụng trên chúng.
- Mạng toàn cục và cục bộ, liên lạc số giải thông cao phát triển mạnh làm tăng
nhu cầu thâm nhập dữ liệu trực tuyến, nảy sinh yêu cầu lớn phát triển phần mềm quản lý dữ liệu.
- Công nghệ chế tạo các bộ vi xử lý tiến bộ nhanh khiến cho máy tính cá nhân,
máy trạm để bàn, và các thiết bị nhúng (dùng cho điều khiển trong robot, ô tô, thiết bị
y tế, đồ điện gia dụng,...) phát triển mạnh khiến cho nhu cầu về phần mềm tăng nhanh.
- Thị trường phần cứng đi vào ổn định, chi phí cho phần mềm tăng nhanh và có
khuynh hướng vượt chi phí mua phần cứng.
d. Thời kỳ sau 1990:
- Kỹ nghệ hướng đối tượng là cách tiếp cận mới đang nhanh chóng thay thế
nhiều cách tiếp cận phát triển phần mềm truyền thống trong các lĩnh vực ứng dụng.
- Sự phát triển của Internet làm cho người dùng máy tính tăng lên nhanh chóng,
nhu cầu phần mềm ngày càng lớn, quy mô và độ phức tạp của những hệ thống phần
mềm mới cũng tăng đáng kể. 7
- Phần mềm trí tuệ nhân tạo ứng dụng các thuật toán phi số như hệ chuyên gia,
mạng nơ ron nhân tạo được chuyển từ phòng thí nghiệm ra ứng dụng thực tế mở ra khả
năng xử lý thông tin và nhận dạng kiểu con người.
1.6. Thực trạng và thách thức trong phát triển phần mềm
1.6.1. Thực trạng
Việc phát triển các ứng dụng > 5000 function points (~500,000 LOC) là một
trong những nhiệm vụ rủi ro nhất trong thế giới hiện đại (Capers Jones)
Những rủi ro dẫn đến hủi hoặc đình trệ tăng nhanh cùng với việc tăng của kích
thước các ứng dụng (Capers Jones):
- 65% các HT lớn (>1,000,000 LOC) bị hủi trước khi hoàn thành
- 50% các HT ước lượng sai kích thước > 1/2 million LOC
- 25 % các dự án > 100,000 LOC
Tỷ lệ thất bại (Failure or cancellation) của các dự án lớn là >20% (Capers Jones)
Sau khi khảo sát 8,000 dự án IT, Standish Group cho biết khoảng 30% bị hủi trước khi hoàn thành
Trung bình các dự án ở Mỹ bị hủi sau 1 năm tiến hành và tiêu tốn 200% kinh
phí dự kiến (Capers Jones).
Các dự án bị hủi chiếm khoảng 15% tổng kinh phí PM của Mỹ ($14 billion in 1993 dollars) (Capers Jones).
Thống kê của Standish Group (2006)
- Có tới 50% trong số các dự án phần mềm thất bại
- Chỉ có 16.2% dự án là hoàn thành đúng hạn và nằm trong giới hạn ngân sách,
đáp ứng tất cả tính năng và đặc tính như cam kết ban đầu
- Có 52.7% dự án được hoàn thành và đi vào hoạt động nhưng không hoàn
thành đúng hạn và bội chi, thêm nữa không đáp ứng đầy đủ tính năng và đặc tính như thiết kế ban đầu
- Và có 31.1% dự án thất bại trước khi được hoàn thành
1.6.2. Thách thức
(1) Không có phương pháp mô tả rõ ràng định nghĩa yêu cầu của người dùng
(khách hàng), sau khi bàn giao sản phẩm dễ phát sinh những trục trặc (troubles)
(2) Với những phần mềm quy mô lớn, tư liệu đặc tả đã cố định thời gian dài, do
vậy khó đáp ứng nhu cầu thay đổi của người dùng một cách kịp thời trong thời gian đó
(3) Nếu không có Phương pháp luận thiết kế nhất quán mà thiết kế theo cách
riêng (của công ty, nhóm), thì sẽ dẫn đến suy giảm chất lượng phần mềm (do phụ
thuộc quá nhiều vào con người) 8
(4) Nếu không có chuẩn về làm tư liệu quy trình sản xuất phần mềm, thì những
đặc tả không rõ ràng sẽ làm giảm chất lượng phần mềm
(5) Nếu không kiểm thử tính đúng đắn của phần mềm ở từng giai đoạn màchỉ
kiểm ở giai đoạn cuốivà phát hiện ra lỗi, thì thường bàn giao sản phẩm không đúng hạn
(6) Nếu coi trọng việc lập trình hơn khâu thiết kế thì thường dẫn đến làm giảm chất lượng phần mềm
(7) Nếu coi thường việc tái sử dụng phần mềm (software reuse), thì năng suất lao động sẽ giảm
(8) Phần lớn trong quy trình phát triển phần mềm có nhiều thao tác do con
người thực hiện, do vậy năng suất lao động thường bị giảm
(9) Không chứng minh được tính đúng đắn của phần mềm, do vậy độ tin cậy của phần mềm sẽ giảm
(10) Chuẩn về một phần mềm tốt không thể đo được một cách định lượng, do
vậy không thể đánh giá được một hệ thống đúng đắn hay không
(11) Khi đầu tư nhân lực lớn vào bảo trì sẽ làm giảm hiệu suất lao động của nhân viên
(12) Công việc bảo trì kéo dài làm giảm chấtlượng của tư liệu và ảnh hưởng
xấu đến những việc khác
(13) Quản lý dự án lỏng lẻo kéo theo quảnlý lịch trình cũng không rõ ràng
(14) Không có tiêu chuẩn để ướclượng nhân lực và dự toán sẽ làm kéo dài thời
hạn và vượt kinh phí của dự án
1.7. Tổng quan về công nghệ phần mềm
1.7.1. Khái niệm
Có rất nhiều định nghĩa khác nhau về kỹ nghệ phần mềm, giới thiệu ở đây một số định nghĩa
Bauer [1969]: SE là 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 1 cách kinh tế vừa tin cậy vừa làm việc hiệu quả trên các máy thực.
Parnas [1987]: SE là việc xây dựng phần mềm nhiều phiên bản bởi nhiều người.
Sommerville [1995]: SE là một nguyên lý kỹ nghệ liên quan đến tất cả các mặt
(lý thuyết,phương pháp và công cụ) của sản phần mềm IEEE [1993]:
1. việc áp dụng phương pháp tiếp cận có hệ thống, bài bản và được lượng hóa
trong phát triển, vận hành và bảo trì phần mềm; 9
2. nghiên cứu các phương pháp tiếp cận được dùng trong (1)
Pressman [1995]: SE 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
Một định nghĩa ban đầu về kỹ nghệ phần mềm do Fritz Bauer nêu ra là: 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 làm việc hiệu quả trên các máy thực. Kỹ 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: - Phương pháp - Công cụ - Thủ tục
Các yếu tố này giúp người quản lý kiểm soát được tiến trình phát triển phần
mềm, cung cấp cho người kỹ sư phần mềm một nền tảng để xây dựng phần mềm chất
lượng cao theo một cách thức hiệu quả, trong những giới hạn nhất định. 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 và thủ tục thuật toán, mã hóa kiểm thử
và bảo trì. Các phương pháp cho kỹ nghệ phần mềm thường đưa ra 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à kỹ 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à chất keo dán 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. Thủ tục bao gồm:
- Xác định ra trình tự các phương pháp sẽ được áp dụng cho mỗi dự án.
- Tạo 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 để đả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 đó 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ả.
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. 10
1.7.2. Lịch sử phát triển a. Giai đoạn 1:
Những năm 1970 là giai đoạn đề xướng, hình thành, gắn liền với giai đoạn lập
trình và cấu trúc dữ liệu, mang các đặc điểm
- Khái niệm về tính môđun
- Khái niệm thiết kế,lập trình top-down, chi tiết hóa từng bước(N. With)
- Lập trình có cấu trúc (Dijkstra)
- Phương pháp luận về qui trình thiết kế;phương pháp phân chia mô đun
- Trừu tượng hóa dữ liệu (Liskov) b. Giai đoạn 2
Nửa đầu những năm 1980 là giai đoạn tăng trưởng, có các đặc điểm quan trọng
- Xuất hiện các phương pháp phát triển hệ thống
+ công nghệ CSDL (mô hình quan hệ)
+ phân tích, thiết kế hướng cấu trúc
- Các bộ công cụ phát triển
+ công cụ trợ giúp phân tích thiết kế
+ bộ khởi tạo chương trình (biên dịch)
+ Các ngôn ngữ bậc cao (FoxPro, SQL...)
- Bắt đầu quan tâm đến quản lý làm phần mềm + Các độ đo phần mềm + Quản lý theo thống kê c. Giai đoạn 3:
Từ giữa những năm 80 là giai đoạn phát triển, có các đặc điểm
- Hoàn thiện công nghệ cấu trúc, ra đời công nghệ đối tượng
- Nhiều mô hình hướng cấu trúc được chuẩn hóa
- CASE hoàn thiện, đạt mức tự động hóa cao
- Công nghệ hướng đối tượng bắt đầu phát triển: + Quy trình RUP
+ Ngôn ngữ mô hình hóa thống nhất(UML)
+ Các công cụ phần mềm đầy đủ (ROSE, JIBULDER,..)
- Sử dụng lại chiếm vị trí quan trọng trong phát triển
- Phát triển các mô hình quản lý
- Chuẩn quản lý được công nhận (CMM, ISO9000-03) 11
- Nhiều mô hình tổ chức làm phần mềm được đề xuất
- Nhiều công cụ trợ giúp quản lý dự án hoàn thiện 12
Chương 2. Quy trình phát triển phần mềm
2.1. Vòng đời phần mềm
2.1.1. Khái niệm
Vòng đời phần mềm là thời kỳ tính từ khi phần mềm được sinh (tạo) ra cho đến
khi chết đi (từ lúc hình thành đáp ứng yêu cầu, vận hành, bảo dưỡng cho đến khi loại bỏ không dùng)
Quy trình phần mềm (vòng đời phần mềm) được phân chia thành các pha chính:
phân tích, thiết kế, chế tạo, kiểm thử, bảo trì. Biểu diễn các pha có khác nhau theo từng người
2.1.2. Mô hình vòng đời phần mềm của Boehm
2.1.3. Suy nghĩ mới về vòng đời phần mềm
(1) Pha xác định yêu cầu và thiết kế có vai trò quyết định đến chất lượng phần
mềm, chiếm phần lớn công sức so với lập trình, kiểm thử và chuyển giao phần mềm
(2) Pha cụ thể hóa cấu trúc phần mềm phụ thuộc nhiều vào suy nghĩ trên xuống
(top-down) và trừu tượng hóa, cũng như chi tiết hóa
(3) Pha thiết kế, chế tạo thì theo trên xuống, pha kiểm thử thì dưới lên (bottom- up)
(4) Trước khi chuyển sang pha kế tiếp phải đảm bảo pha hiện nay đã được kiểm thử không còn lỗi
(5) Cần có cơ chế kiểm tra chất lượng, xét duyệt giữa các phần nhằm đảm bảo không gây lỗi cho pha sau
(6) Tư liệu của mỗi pha không chỉ dùng cho pha sau, mà chính là đối tượng
quan trọng cho kiểm tra và đảm bảo chính là đối tượng quan trọng cho kiểm tra và
đảm bảo chất lượng của từng quy trình và của chính phần mềm 13
(7) Cần chuẩn hóa mẫu biểu, cách ghi chép tạo tư liệu, cho từng pha, nhằm đảm
bảo chất lượng phần mềm
(8) Thao tác bảo trì phần mềm là việc xử lý quay vòng trở lại các pha trong
vòng đời phần mềm nhằm biến đổi, sửa chữa, nâng cấp phần mềm
2.2. Quy trình phát triển phần mềm
2.2.1. Khái niệm
Qui trình (process) phần mềm gồm một tập hợp các hoạt động được tổ chức mà
mục đích của nó là nâng cấp, xây dựng và phát triển phần mềm. Qui trình xác định ai
làm gì, khi nào và bằng cách nào để đạt được một mục tiêu nào đó. Quy trình phần
mềm xác định một bộ khung và tiêu chuẩn để triển khai công nghệ phần mềm.
Trong công nghiệp để giải quyết những vấn đề thực tế, những kỹ sư hay một
nhóm kỹ sư phần mềm phải cộng tác để đưa ra một chiến lược phát triển bao gồm qui
trình (process), phương pháp (method) và công cụ (tool). Cần phân biệt giữa qui trình
và phương pháp: Qui trình: Phải thực hiện những công việc gì?, trong khi phương
pháp: chỉ ra cách thực hiện những công việc cụ thể (“how to”).
Những loại hệ thống khác nhau sẽ cần những qui trình phát triển khác nhau, ví
dụ: Hệ thống thời gian thực yêu cầu phải hoàn thành đặc tả hệ thống trước khi chuyển
sang giai đoạn xây dựng nó. Hệ thống thương mại điện tử, chúng ta có thể vừa đặc tả
vừa xây dựng chương trình một cách đồng thời.
2.2.2. Các hoạt động
a. Kỹ nghệ và phân tích hệ thống
Kỹ nghệ và phân tích hệ thống bao gồm việc thu thập yêu cầu ở mức hệ thống
với một lượng nhỏ thiết kế và phân tích ở mức đỉnh. Mục đích của bước này là xác
định khái quát về phạm vi, yêu cầu cũng như tính khả thi của phần mềm.
b. Phân tích yêu cầu phần mềm
- Phân tích yêu cầu được tập trung việc thu thập và phân tích các thông tin cần
cho phần mềm, các chức năng cần phải thực hiện, hiệu năng cần có và các giao diện cho người sử dụng.
- Kết quả của phân tích là tư liệu về yêu cầu cho hệ thống và phần mềm (đặc tả
yêu cầu) để khách hàng duyệt lại và dùng làm tài liệu cho người phát triển. c. Thiết kế
- Là quá trình chuyển hóa các yêu cầu phần mềm thành các mô tả thiết kế
- Thiết kế gồm nhiều bước, thường tập trung vào 4 công việc chính: thiết kế
kiến trúc phần mềm, thiết kế cấu trúc dữ liệu, thiết kế chi tiết các thủ tục, thiết kế giao diện và tương tác.
- Lập tư liệu thiết kế (là một phần của cấu hình phần mềm) để phê duyệt 14 d. Mã hóa
Biểu diễn thiết kế bằng một hay một số ngôn ngữ lập trình và dịch thành mã máy thực hiện được. e. Kiểm thử
Tiến trình kiểm thử bao gồm việc
i) phát hiện và sửa lỗi phần logic bên trong chương trình hay còn gọi là lỗi lập trình,
ii) kiểm tra xem phần mềm có hoạt động như mong muốn không, tức là phát
hiện và sửa lỗi về chức năng như thiếu hụt, sai sót về chức năng; và kiểm tra xem phần
mềm có đảm bảo tính hiệu quả trong thực hiện hay không. f. Bảo trì
Bao gồm các công việc sửa các lỗi phát sinh khi áp dụng chương trình hoặc
thích ứng nó với thay đổi trong môi trường bên ngoài (hệ điều hành mới, thiết bị ngoại
vi mới, yêu cầu người dùng) hoặc yêu cầu bổ sung chức năng hay nâng cao hiệu năng cần có.
2.3. Một số mô hình thực hiện
Mô hình phát triển phần mềm là một thể hiện trừu tượng của quy trình phần
mềm. Nó biểu diễn các đặc tả về quy trình từ những khía cạnh cụ thể, do đó, nó chỉ
cung cấp một phần thông tin về quy trình phần mềm
2.3.1. Mô hình tuyến tính
Đôi khi còn được gọi là mô hình tuần tự tuyến tính hay mô hình thác nước, mô
hình này gợi ý một cách tiếp cận tuần tự, có hệ thống tới việc phát triển phần mềm vốn
bắt đầu từ mức hệ thống và tiến dần qua phân tích, thiết kế, mã hoá, kiểm thử và hỗ
trợ. Dưới đây minh hoạ mô hình thác nước cho kĩ nghệ phần mềm. Được mô hình hoá
theo chu kì kĩ nghệ qui ước, mô hình thác nước bao gồm các hoạt động sau:
Kĩ nghệ và mô hình hoá hệ thống /thông tin. Bởi vì phần mềm bao giờ cũng là
một phần của một hệ thống (hay nghiệp vụ) lớn hơn nên công việc bắt đầu từ việc thiết 15
lập yêu cầu cho mọi phần tử hệ thống và rồi cấp phát một tập con các yêu cầu đó cho
phần mềm. Quan điểm hệ thống này là điều bản chất khi phần mềm phải tương tác
với các thành phần khác như phần cứng, con người và CSDL. Kĩ nghệ và phân tích
hệ thống bao gồm việc thu thập yêu cầu ở mức hệ thống với một lượng nhỏ thiết kế và
phân tích mức đỉnh. Kĩ nghệ thông tin bao gồm việc thu thập yêu cầu tại mức nghiệp
vụ chiến lược và tại mức lĩnh vực nghiệp vụ.
Phân tích yêu cầu phần mềm. Tiến trình thu thập yêu cầu được tăng cường và
hội tụ đặc biệt vào phần mềm. Để hiểu được bản chất của các chương trình phải xây
dựng, kĩ sư phần mềm ("nhà phân tích") phải hiểu về lĩnh vực thông tin (được mô tả
trong phần sau) đối với phần mềm cũng như chức năng cần có, hành vi, hiệu năng và
giao diện. Các yêu cầu cho cả hệ thống và phần mềm cần phải được lập tư liệu và xét
duyệt cùng với khách hàng.
Thiết kế. Thiết kế phần mềm thực tế là một tiến trình nhiều bước tập trung vào
bốn thuộc tính phân biệt của chương trình: cấu trúc dữ liệu, kiến trúc phần mềm, biểu
diễn giao diện và chi tiết thủ tục (thuật toán). Tiến trình thiết kế dịch các yêu cầu thành
một biểu diễn của phần mềm có thể được định giá về chất lượng trước khi giai đoạn
mã hoá bắt đầu. Giống như các yêu cầu, việc thiết kế phải được lập tư liệu và trở
thành một phần của cấu hình phần mềm.
Sinh mã. Thiết kế phải được dịch thành dạng máy đọc được. Bước mã hoá thực
hiện nhiệm vụ này. Nếu thiết kế được thực hiện theo một cách chi tiết thì việc sinh mã
có thể được thực hiện một cách máy móc.
Kiểm thử. Một khi mã đã được sinh ra thì việc kiểm thử chương trình bắt đầu.
Tiến trình kiểm thử hội tụ vào nội bộ logic của phần mềm, đảm bảo rằng tất cả các câu
lệnh đều được kiểm thử, và vào bên ngoài chức năng; tức là tiến hành các kiểm thử để
làm lộ ra các lỗi và đảm bảo những cái vào đã định sẽ tạo ra kết quả thống nhất với kết quả muốn có.
Vận hành và bảo trì. Phần mềm chắc chắn sẽ phải trải qua những thay đổi sau
khi nó được bàn giao cho khách hàng (một ngoại lệ có thể là những phần mềm nhúng).
Thay đổi sẽ xuất hiện bởi vì gặp phải lỗi, bởi vì phần mềm phải thích ứng với những
thay đổi trong môi trường bên ngoài (chẳng hạn như sự thay đổi do hệ điều hành mới
hay thiết bị ngoại vi mới), hay bởi vì khách hàng yêu cầu nâng cao chức năng hay hiệu
năng. Việc bảo trì phần mềm phải áp dụng lại các bước vòng đời nói trên cho chương
trình hiện tại chứ không phải chương trình mới.
Mô hình tuần tự tuyến tính là mô hình cũ nhất và được sử dụng rộng rãi nhất
cho kĩ nghệ phần mềm. Tuy nhiên, những chỉ trích về mô hình này đã làm cho những
người ủng hộ nó tích cực phải đặt vấn đề về tính hiệu quả của nó. Một số các vấn đề
thỉnh thoảng gặp phải khi dùng mô hình tuần tự tuyến tính này là: 16
Các dự án thực hiếm khi tuân theo dòng chảy tuần tự mà mô hình đề nghị. Mặc
dầu mô hình tuyến tính có thể cho phép lặp, nhưng điều đó chỉ làm gián tiếp. Kết quả
là những thay đổi có thể gây ra lẫn lộn khi tổ dự án tiến hành.
Khách hàng thường khó phát biểu mọi yêu cầu một cách tường minh. Mô hình
tuần tự tuyến tính đòi hỏi điều này và thường khó thích hợp với sự bất trắc tự nhiên tồn
tại vào lúc đầu của nhiều dự án.
Khách hàng phải kiên nhẫn. Bản làm việc được của chương trình chỉ có được
vào lúc cuối của thời gian dự án. Một sai lầm ngớ ngẩn, nếu đến khi có chương trình
làm việc mới phát hiện ra, có thể sẽ là một thảm hoạ.
Trong một phân tích thú vị về các dự án hiện tại, Brada thấy rằng bản chất
tuyến tính của vòng đời cổ điển dẫn tới "các trạng thái nghẽn" mà trong đó một số
thành viên tổ dự án phải đợi cho các thành viên khác của tổ hoàn thành các nhiệm vụ
phụ thuộc. Trong thực tế, thời gian mất cho việc chờ đợi có thể vượt quá thời gian
dành cho công việc sản xuất. Trạng thái nghẽn có khuynh hướng phổ biến vào lúc đầu
và cuối của tiến trình tuần tự tuyến tính.
Từng vấn đề trên đều là thực. Tuy nhiên, mô hình vòng đời cổ điển có một vị trí
quan trọng và xác định trong công việc về kĩ nghệ phần mềm. Nó đưa ra một tiêu bản
trong đó có thể bố trí các phương pháp cho phân tích, thiết kế, mã hoá, kiểm thử và
bảo trì. Bên cạnh đó, vòng đời cổ điển vẫn còn là một mô hình thủ tục được dùng rộng
rãi cho kĩ nghệ phần mềm. Trong khi nó quả thực còn điểm yếu, nó vẫn tốt hơn đáng
kể nếu so với cách tiếp cận ngẫu nhiên tới việc phát triển phần mềm.
2.3.2. Phát triển tiến hoá
a. Mô hình bản mẫu
Cách tiếp cận làm bản mẫu cho kỹ nghệ phần mềm 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 input và output.
- Người phát triển không chắc về hiệu quả của thuật toán, về thích nghi 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 làm 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. 17
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.
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 nhiều công sức vào đánh giá bản mẫu.
b. 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. 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ệ 18
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ến hành tiếp
hay dừng”. Nếu rủi ro quá lớn thì có thể đình chỉ dự án.
Mô hình xoắn ốc là cách tiếp cận thực tế cho việc phát triển cho các hệ thống và
phần mềm qui mô lớn. Bởi vì phần mềm tiến hoá khi tiến trình tiến hoá, nên người
phát triển và khách hàng hiểu rõ hơn và phản ứng với rủi ro tại từng mức tiến hoá. Mô
hình xoắn ốc dùng cách làm bản mẫu như một cơ chế làm giảm bớt rủi ro, nhưng điều
quan trọng hơn, làm cho người phát triển có khả năng áp dụng được cách tiếp cận
làm bản mẫu tại mọi giai đoạn trong tiến hoá của sản phẩm. Nó duy trì cách tiếp
cận từng bước một cách có hệ thống do cách tiếp cận vòng đời cổ điển gợi ý,
nhưng tổ hợp cách tiếp cận này vào một khuôn khổ lặp lại, vốn phản ánh được sát thực
hơn thế giới thực. Mô hình xoắn ốc đòi hỏi việc xem xét trực tiếp các rủi ro kĩ thuật tại
mọi giai đoạn của dự án, và nếu được áp dụng đúng thì nó có thể làm giảm rủi ro trước
khi chúng trở thành vấn đề thực sự.
Nhưng giống như các mô hình khác, mô hình xoắn ốc không phải là một
liều thuốc bách bệnh. Có thể khó thuyết phục những khách hàng (đặc biệt trong tình
huống có hợp đồng) rằng cách tiếp cận tiến hoá là kiểm soát được. Nó đòi hỏi tri thức
chuyên gia đánh giá rủi ro chính xác và dựa trên tri thức chuyên gia này mà đạt được
thành công. Nếu một rủi ro chính không được phát hiện và quản lí thì không nghi ngờ
gì nữa vấn đề sẽ xuất hiện. Cuối cùng, chính bản thân mô hình này cũng còn chưa
được sử dụng rộng rãi như mô hình trình tự tuyến tính hoặc làm bản mẫu. Cần
phải có thêm một số năm nữa trước khi tính hiệu quả của mô hình quan trọng này có
thể được xác định với sự chắc chắn hoàn toàn.
2.3.3. Phát triển dựa trên thành phần
Xuất phát từ quan điểm: "Buy do not build", tư tưởng của phát triển dựa trên
thành phần là xây dựng hệ thống bằng cách lắp ráp hoặc tích hợp từ những thành phần 19
đã có hoặc các thành phần thương mại COTS (Commercial-off-the-shelf). Do vậy,
kiến trúc phần mềm của hệ thống dựa vào kiến trúc phần mềm của các thành phần
phần mềm tiêu chuẩn nên hệ thống đạt chất lượng cao hơn.
Phương pháp phát triển dựa trên thành phần gần tương tự như phương pháp
phát triển hướng đối tượng. Hoạt động công nghệ bắt đầu với sự chỉ ra các lớp tham
dự để phát triển hệ thống. Nếu các lớp này được tìm thấy trong thư viện và sự thích
nghi là tốt, chúng sẽ được lấy ra và phát triển hệ thống. Ngược lại, chúng sẽ được phát
triển để sử dụng và bổ sung vào thư viện sử dụng lại.
Thành phần phần mềm được sử dụng lại có độ chính xác cao và có thể nói là
không chứa lỗi. Mặc dầu không thường xuyên được chứng minh về mặt hình thức
nhưng với việc sử dụng lại, lỗi được tìm thấy và loại trừ; chất lượng của thành phần
được cải thiện như là một kết quả.
Khi những thành phần sử dụng lại được ứng dụng thông qua tiến trình phần
mềm, chúng ta ít tốn thời gian để tạo ra kế hoạch, mô hình, tài liệu, mã và dữ liệu mà
chúng là cần thiết để tạo ra hệ thống. Thêm vào, chức năng cùng mức được phân phối
cho người sử dụng với đầu vào ít công sức hơn, do vậy, hiệu suất phần mềm được cải thiện.
Với ưu điểm tái sử dụng các thành phần qua Thư viện / kho các lớp: tiết kiệm
70% thời gian, 80% giá thành, chỉ số sản xuất 26.2/16.9
Với UML như chuẩn công nghiệp đang triển khai
2.3.4. Kỹ thuật thế hệ thứ tư
Thuật ngữ kĩ thuật thế hệ thứ tư (4GT) bao gồm một phạm vi rộng các công cụ
phần mềm có một điểm chung: mỗi công cụ đều cho phép người kĩ sư phần mềm xác
định đặc trưng nào đó của phần mềm ở mức cao. Rồi công cụ đó tự động sinh ra mã
chương trình gốc dựa trên đặc tả của người phát triển. Người ta gần như không còn
bàn cãi về việc phần mềm có thể được xác định đối với một máy càng ở mức cao thì
chương trình có thể được xây dựng càng nhanh hơn. Mô hình 4GT cho kĩ nghệ phần
mềm tập trung vào khả năng xác định phần mềm bằng việc dùng các khuôn mẫu ngôn
ngữ đặc biệt hay kí pháp đồ hoạ vốn mô tả cho vấn đề cần được giải quyết dưới dạng
khách hàng có thể hiểu được. 20
Hiện tại, một môi trường phát triển phần mềm hỗ trợ cho mô hình 4GT bao
gồm một số hay tất cả các công cụ sau:
- Ngôn ngữ phi thủ tục để hỏi đáp cơ sở dữ liệu. - Bộ sinh báo cáo. - Bộ thao tác dữ liệu.
- Bộ tương tác và xác định màn hình. - Bộ sinh chương trình.
- Khả năng đồ hoạ mức cao.
- Khả năng làm trang tính và việc sinh tự động HTML.
- Các ngôn ngữ tương tự được dùng cho việc tạo ra trang Web thông qua
việc dùng các công cụ phần mềm tiên tiến.
Ban đầu nhiều trong những công cụ đã được nhắc tới đó đã có sẵn chỉ cho
những lĩnh vực ứng dụng rất đặc thù, nhưng ngày nay môi trường 4GT đã được mở
rộng để đề cập tới hầy hết các loại ứng dụng phần mềm.
Giống như các mô hình khác, 4GT bắt đầu từ bước thu thập yêu cầu. Một cách
lý tưởng, khách hàng sẽ mô tả các yêu cầu và các yêu cầu đó sẽ được dịch trực tiếp
thành một bản mẫu vận hành được. Nhưng điều này không thực hiện được. Khách
hàng có thể không chắc chắn mình cần gì, có thể có sự mơ hồ trong việc xác định các
sự kiện đã biết, có thể không có khả năng hay không sẵn lòng xác định thông tin theo
cách thức mà công cụ 4GT có thể giải quyết được. Bởi lí do này, đối thoại khách hàng/
người phát triển được mô tả cho các mô hình tiến trình khác vẫn còn là phần bản chất của cách tiếp cận 4GT.
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ách dùng ngôn ngữ sinh thế hệ thứ tư phi thủ tục (4GL) hay một mô
hình bao gồm một mạng các biểu tượng đồ hoạ. Tuy nhiên với nỗ lực lớn hơn, cần
phải phát triển một chiến lược thiết kế cho hệ thống, ngay cả nếu có dùng 4GL. Việc
dùng 4GT thiếu thiết kế (với các dự án lớn) sẽ gây ra cùng những khó khăn (chất
lượng kém, khó bảo trì, người dùng khó chấp nhận) mà chúng ta đã gặp phải khi phát
triển phần mềm bằng cách dùng các cách tiếp cận qui ước. 21
Việc cài đặt dùng 4GL làm cho người phát triển phần mềm biểu diễn được các
kết quả mong muốn theo cách là phát sinh tự động chương trình tính ra chúng. Hiển
nhiên, một cấu trúc dữ liệu với những thông tin có liên quan cần phải có sẵn và sẵn
sàng cho 4GL truy nhập vào.
Để biến đổi một cài đặt 4GT thành một sản phẩm, người phát triển phải tiến
hành việc kiểm thử toàn diện, xây dựng các tài liệu có ý nghĩa và thực hiện mọi hoạt
động tích hợp giải pháp khác vốn cần tới trong các mô hình kĩ nghệ phần mềm khác.
Bên cạnh đó, phần mềm được phát triển theo 4GT phải được xây dựng theo cách
làm cho việc bảo trì có thể được tiến hành một cách chóng vánh.
Giống như mọi mô hình kĩ nghệ phần mềm, mô hình 4GT có ưu điểm và nhược
điểm. Những người ủng hộ cho là 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 là các công cụ 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, rằng chương trình gốc do các công cụ này tạo ra là "không hiệu quả," và rằng
tính bảo trì cho các hệ thống phần mềm lớn được phát triển bằng cách dùng 4GT vẫn còn là vấn đề mở.
Có đôi điều lợi ích trong các luận điểm của cả hai phía và có thể tóm tắt trạng
thái hiện tại của cách tiếp cận 4GT như sau:
1. Việc dùng 4GT là cách tiếp cận có thể tồn tại được cho nhiều lĩnh vực ứng
dụng khác nhau. Gắn với các công cụ kĩ nghệ phần mềm có máy tính hỗ trợ và bộ
sinh mã, 4GT cung cấp một giải pháp tin cậy được cho nhiều vấn đề phần mềm.
2. Dữ liệu được thu thập từ các công ty có dùng 4GT chỉ ra rằng thời gian cần
cho việc tạo ra phần mềm được giảm đáng kể đối với các ứng dụng vừa và nhỏ và rằng
khối lượng thiết kế và phân tích cho các ứng dụng nhỏ cũng được rút bớt.
3. Tuy nhiên, việc dùng 4GT cho các nỗ lực phát triển phần mềm lớn đòi hỏi
nhiều phân tích, thiết kế và kiểm thử (các hoạt động kĩ nghệ phần mềm) để đạt tới
việc tiết kiệm thời gian vốn nảy sinh từ việc xoá bỏ mã hoá.
Tóm lại, các kĩ thuật thế hệ thứ tư đã trở thành một phần quan trọng của kĩ nghệ
phần mềm. Khi đi đôi với cách tiếp cận dựa trên cấu phần (sẽ được trình bày ở mục
tiếp theo), mô hình 4GT có thể trở thành cách tiếp cận thống trị cho việc phát triển phần mềm\
2.3.5. Phát triển nhanh ứng dụng (Rapid Application Development )
Mô hình này được đưa ra bởi IBM vào những năm 1980, qua sách của James
Martin. Mô hình RAD là sự ráp nối tốc độ cao của mô hình thác nước, xây dựng dựa
vào thành phần và sử dụng các ứng dụng tạo mã tự động.
Là quy trình phát triển phần mềm gia tăng, tăng dần từng bước (Incrimental
software development) với mỗi chu trình phát triển rất ngắn (60-90 ngày) 22
Xây dựng dựa trên hướng thành phần (Component-based construction) với khả
năng tái sử dụng (reuse).
Gồm một số nhóm (teams), mỗi nhóm làm 1 RAD theo các pha: Mô hình
nghiệp vụ, Mô hình dữ liệu, Mô hình xử lý, Tạo ứng dụng, Kiểmthử và đánh giá
(Business, Data, Process, Application Generation, Testing and Turnover)
Data modeling: các đối tượng dữ liệu cần để hỗ trợ nghiệp vụ (business). Định
nghĩa các thuộc tính của từng đối tượng và xác lập quan hệ giữa các đối tượng
Process modeling: Các đối tượng dữ liệu được chuyển sang luồng thông tin
thực hiện chức năng nghiệp vụ Tạo mô tả xử lý dễ cập nhật (thêm nghiệp vụ. Tạo mô
tả xử lý đễ cập nhật (thêm, sửa, xóa, khôi phục) từng đối tượng dữ liệu
Application Generation: Dùng các kỹ thuật thế hệ để tạo phần mềm từ các
thành phần có sẵn hoặc tạo ra các thành phần có thể tái dụng lại sau này. Dùng các
công cụ tự động để xây dựng phần mềm
Testing and Turnover: Kiểm thử các thành phần mới và kiểmchứng mọi giao
diện (các thành phần cũ đã được kiểm thử và dùng lại) 23
Luồng thông tin được mô hình hóa để trả lời các câu hỏi:
- Thông tin nào điều khiển xử lý nghiệp vụ?
- Thông tin gì được sinh ra? - Ai sinh ra nó? - Thông tin đi đến đâu? - Ai xử lý chúng? Ưu điểm
- Thời gian phát triển giảm nhờ dùng công cụ
- Chỉ cần ít người phát triển hơn, do họ thân thiện với vấn đề
- Nhanh chóng cho phép hình dung ra sản phẩm
- Dùng hiệu quả các framework và công cụ đóng gói (off-the-shelf tools and frameworks)
- Giảm rủi ro nhờ có sự tham gia của khách hàng Các hạn chế
- Thiếu sự tham gia tốt của người dùng trong chu kỳ sống của phần mềm
- Người phát triển phải có kỹ năng và được huấn luyện tốt cho việc sử dụng công cụ
và thời gian phát triển nhanh
- Hệ thống có khả năng phân tách module
- Cần có đáp ứng về thành phần sử dụng lại
- Người phát triển và khách hàng phải nỗ lực
- Người quản lý phải làm việc tận tụy với nhóm phát triển và khách hàng để nhanh
chóng đạt được các thỏa thuận
- Cần nguồn nhân lực dồi dào để tạo các nhóm cho các chức năng chính
- Yêu cầu hai bên giao kèo trong thời gian ngắn phải có phần mềm hoàn chỉnh, thiếu
trách nhiệm của một bên dễ làm dự án đổ vỡ 24
- RAD không phải tốt cho mọi ứng dụng nhất là với ứng dụng không thể môđun hóa
hoặc đòi hỏi tính năng cao
- Mạo hiểm kỹ thuật cao thì không nên dùng RAD Khi nào nên sử dụng RAD
- Hệ thống dễ dàng phân chia module và có thể mở rộng
-,Hệ thống mà những yêu cầu được biết rõ và hợp lý
- Người dùng có thể tham gia tốt qua toàn bộ chu kỳ sống (life cycle)
- Dự án thời gian phát triển ngắn, dưới 60 ngày
- Những thành phần sử dụng lại có sẵn trong kho phần mềm
- Những hệ thống nhỏ, những hệ thống không có tính nghiêm ngặt (critical)…
2.3.6. Phát triển hình thức
Trong ngành khoa học máy tính, các phương pháp hình thức là các kỹ thuật toán học
cho việc đặc tả, phát triển và kiểm định các hệ thống phần mềm và phần cứng. Cách tiếp cận
này đặc biệt quan trọng đối với các hệ thống cần có tính toàn vẹn cao, chẳng hạn hệ thống
điều khiển lò phản ứng hạt nhân hay điều khiển tên lửa, khi an toàn hay an ninh có vai trò
quan trọng, để góp phần đảm bảo rằng quá trình phát triển hệ thống sẽ không có lỗi. Các
phương pháp hình thức đặc biệt hiệu quả tại giai đoạn đầu của quá trình phát triển (tại các
mứcyêu cầu và đặc tả hệ thống), nhưng cũng có thể được sử dụng cho một quá trình phát
triển hoàn chỉnh của một hệ thống.
Các phương pháp hình thức có thể được sử dụng tại nhiều mức:
 Mức 0: Đặc tả hình thức có thể được thực hiện và rồi một chương trình được phát
triển từ đặc tả này một cách không hình thức. Trong nhiều trường hợp, cách này
có thể là lựa chọn hiệu quả nhất về mặt chi phí.
 Mức 1: Sử dụng phát triển và kiểm định hình thức để tạo một chương trình theo
một quy trình hình thức hơn. Ví dụ, có thể thực hiện các chứng minh về các tính
chất hoặc quá trình tinh chỉnh (refinement) từ đặc tả hình thức tới một chương
trình. Đây có thể là lựa chọn phù hợp nhất đối với các hệ thống yêu cầu tính toàn
vẹn cao với các tiêu chí về an toàn và an ninh.
 Mức 2: Sử dụng các bộ chứng minh định lý (theorem )
prover để thực hiện các
chứng minh hình thức hoàn toàn và được kiểm chứng bằng máy móc. Việc này có
thể đòi hỏi chi phí rất cao và chỉ đáng lựa chọn trong thực tiễn nếu phí tồn cho
các lỗi sai là cực kỳ cao (ví dụ, trong các phần quan trọng của thiết kế bộ vi xử lý).
Cùng với ngành con Ngữ nghĩa hình thức của ngôn ngữ lập trình, các phương pháp
hình thức có thể được phân loại tương đối như sau:  Ngữ
nghĩa ký hiệu (Denotational semantics), trong đó ý nghĩa của một hệ thống
được biểu diễn bằng lý thuyết toán học về miền xác định. Lợi điểm của những
phương pháp này phụ thuộc vào bản chất được hiểu rõ của các miền xác định để
từ đó đem lại ý nghĩa cho hệ thống; các phê phán chỉ ra rằng không phải hệ thống 25
nào cũng có thể được nhìn một cách tự nhiên hoặc trực quan dưới dạng một hàm số.  Ngữ
nghĩ hoạt động (Operational semantics), trong đó, ý nghĩa của một hệ thống
được biểu diễn bằng một chuỗi các hành động của một mô hình tính toán (giả
thiết là) đơn giản hơn. Lợi điểm của phương pháp này là tính đơn giản của các mô
hình tạo nên sự trong sáng của biểu diễn; nhược điểm là phương pháp này đã trì
hoãn các vấn đề của ngữ nghĩa (ai định nghĩa ngữ nghĩa của các mô hình đơn giản hơn?)  Ngữ
nghĩa tiên đề (Axiomatic semantics), trong đó ý nghĩa của hệ thống được
biểu diễn theo các tiền điều kiện (precondition) và hậu điều kiện (postcondition),
đây lần lượt là các điều kiện phải được thỏa mãn tại các thời điểm trước và sau
khi hệ thống thực hiện một nhiệm vụ. Những người ủng hộ phương pháp này nói
đến mối quan hệ của nó với lôgic kinh điển; những người phê phán nói rằng
những ngữ nghĩa thuộc dạng này không thực sự mô tả xem hệ thống làm cái gì
(chỉ là cái gì đúng trước đó và sau đó).
2.3.7. Phát triển hướng đối tượng
- Hướng sử dụng lại dựa trên nền tảng của phát triển hệ thống hướng đối tượng - Ý tưởng
+ Hệ thống cấu thành từ các đối tượng
+ Đối tượng bao gói cả dữ liệu và xử lý
+ Liên kết với nhau bằng truyền thông
- Bao gói, che dấu thông tin: bao gói cả dữ liệu và xử lý nên độc lập tương đối, che
dấu thông tin --> Tác động cục bộ, dễ bảo trì, dễ dùng lại
- Tính kế thừa: Xây dựng được các lớp cơ sở
Nâng cao khả năng dùng lại 
- Liên kết tự do, yếu Mở rộng đơn giản, không hạn chế 
- Các hướng sử dụng lại: Định hướng thành phần, Định hướng mẫu, Phát triển khung làm việc - Các giai đoạn
+ Phân tích hệ thống thành các phần yêu cầu nhỏ
+ Cải biến các yêu cầu hướng
+ Thiết kế hệ thống hướng tới tái sử dụng
+ Phát triển và tích hợp
- Quan trọng, cần kinh nghiệm, công cụ còn hạn chế
2.3.8. Phát triển phần mềm mã nguồn mở
Có nhiều dạng bản quyền phần mềm và cách phân phối. Người ta có thể chia chúng
thành 2 dạng chính: Sự sẵn có của mã nguồn và giá tiền. Mã nguồn là mã của phần mềm
được viết bằng một ngôn ngữ lập trình cao cấp hơn. Không như mã nhị phân (binary code), 26
nó biểu đạt cấu trúc và nguyên lý của chương trình. Một phần mềm được phân phối ở dạng
mã nhị phân còn được gọi là phần mềm mã nguồn đóng (closed source) hoặc blackbox.
Mã nguồn mở không chỉ có nghĩa là cung cấp mã nguồn. Các điều khoản phân phối
của PMMNM phải tuân theo những tiêu chí sau:  Phân phối miễn phí  Mã nguồn  Các sản phẩm gốc
 Toàn bộ mã nguồn của tác giả
 Không phân biệt người dùng hay nhóm
 Không phân biệt lĩnh vực làm việc  Cung cấp license
 License không được chỉ định riêng cho 1 sản phẩm
 License không được hạn chế các phần mềm khác
 License phải trung lập về mặt công nghệ Lợi ích
Bảo mật nhờ mở và Bảo mật nhờ đóng: Với các phần mềm Black-Box, sự bảo mật có
được bằng cách che giấu mã nguồn, ngược lại, PMMNM cho phép nhiều người dùng có thể
nhận biết các đoạn mã cũng như tuỳ biến chúng.
Tính tương thích: Khả năng định dạng là vô hạn, do đó các công ty có thể tuỳ biến
mã nguồn cho phù hợp với nhu cầu . Điều này cho phép mã nguồn liên tục được phát triển.
Hiệu năng: Hiệu năng của các PMMNM thường cao hơn so với phần mềm độ quyền
vì tính ổn định và độ tinh cậy.
Không lệ thuộc vào nhà sản xuất: Với mã nguồn mở sẽ không còn sự lệ thuộc vào
nhà sản xuất, không còn phải đối mặt với những vấn đề phát sinh như khi một nhà sản xuất
phần mềm độc quyền phá sản.
Chi phí: Chi phí mua PMMNM thấp hơn, nhưng chi phí huấn luyện ban đầu cao hơn
Nói chung, mã nguồn mở có giai đoạn kiểm nghiệm lâu dài hơn, cho phép nhiều thời
gian hơn để phát triển và hướng tới sự ổn định cao hơn. Đưa vào sử dụng khi đã ổn định
đồng nghĩa với giảm sự cố và chi phí. Hạn chế
Đa dạng và phức tạp: Cộng đồng mã nguồn mở đã phát triển nhiều ứng dụng đa dạng
với những chức năng tương tự nhau. Điều này gây khó khăn cho những người mới sử dụng
trong việc chọn lựa. Cơ cấu chọn lựa đã được thiết lập như nhà sản xuất, giá cả, thị phần
hoặc hỗ trợ chỉ cung cấp một sự giúp đỡ có hạn. Vấn đề thực sự là một khi gia tăng tính đa
dạng sẽ dẫn đến sự phức tạp trong khi với xã hội ngày nay, người ta luôn mong muốn sự
đơn giản. Một giải pháp khả thi cho vấn đề này có thể là sự chọn lựa trước của nhà phân phối 27
Sự dư thừa: Sự chia nhánh mã nguồn có thể dẫn đến sự lãng phí trong quá trình phát
triển nó. Nếu các nguồn phát triển được kết hợp và tổ chức lại một cách tốt hơn thì hiệu suất sẽ được nâng cao.
Thiếu các ứng dụng: Vẫn còn những lĩnh vực vắng bóng các PMMNM. (VD: một
trình biên soạn HTML như MS Frontpage)
Bất tiện: Mã nguồn mở thường chỉ tập trung vào các mã của nó mà ít chú ý đến thiết
kế giao diện và phát triển các tiện ích. Trong Microsoft World, hầu hết các phát triển trong
vài năm gần đây đều thuộc lĩnh vực tiện ích và phát triển giao diện người dùng.
2.3.9. Mô hình khác
a. Lập trình cực đoan (XP - eXtreme Programming)
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
tiên” và “lập trình đôi”.
* Tạo các ca thử nghiệm trước tiên
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 đoạn cuối của quá trình phát triển, khi bạn đã 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 bạn 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 bạn xác định một
cách rõ ràng giao diện của modun. Hơn thế, để tạo được ca thử nghiệm, bạn cần phải hiểu rõ
chức năng của nó. Tức là, XP yêu cầu bạn phải hiểu một cách rõ ràng các yêu cầu của
modun trước khi bạn bắt tay vào phát triển nó. * Lập trình đôi
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 môđun 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 toàn 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 nhau và giữ được các nguyên tắc của XP. 28
b. Mô hình tăng dần Đặc điểm
- Các yêu cầu được xác định và phân loại theo độ ưu tiên, độ ưu tiên cao cho những
chức năng chính và những chức năng có độ rủi ro cao
- Phân chia các yêu cầu cho các vòng và thiết kế kiến trúc của toàn bộ hệ thống
- Vòng đầu tiên tạo ra sản phẩm lõi (core product)
- Các bước sau bổ sung các chức năng khác và tích hợp vào hệ thống nhằm hoàn thiện dần sản phẩm
- Mỗi chức năng cũng như hệ thống tích hợp phải được đánh giá theo từng giai đoạn
- Các yêu cầu và kiến trúc của toàn bộ hệ thống sẽ được điều chỉnh dựa vào những
sản phẩm phát hành theo từng vòng Ưu điểm
- Những chức năng của hệ thống có thứ tự ưu tiên càng cao (chức năng chính, chức
năng rủi ro cao) sẽ được thực hiện trước, do đó chúng sẽ được kiểm thử nhiều hơn, sản
phẩm đươc hoàn thành phần cơ bản sớm
- Sau mỗi lần tăng vòng thì có thể chuyển giao kết quả cho khách hàng. Những kết
quả này đóng vai trò là mẫu thử để giúp tìm hiểu thêm các yêu cầu ở những vòng tiếp theo.
- Có thể thực hiện nhiều bước đồng thời, tách nhỏ công việc nhằm dễ quản lý hơn
(The “divide and conquer” rule)
- Giảm rủi ro trong việc thất bại của toàn bộ dự án, rủi ro trải ra nhiều phần nhỏ
- Sử dụng nhân viên giới hạn, họ có thể thực hiện nhưng công việc tương tự ở các vòng Nhược điểm
- Phải xác định chức năng đầy đủ và hoàn chỉnh trước khi xác định các vòng gia tăng
- Phải xác định rõ các giao tiếp (interface) cho các module mà thời gian hoàn thành cách biệt nhiều
- Việc kiểm tra khó khăn hơn trên một hệ thống hoàn chỉnh 29
- Khách hàng khi thấy sản phẩm lõi có thể nghĩ là công,việc đơn giản ít tốn kém
- Đòi hỏi phải có kế hoạch và thiết kế tốt, phân chia công việc hợp lý, các nhân viên phải công tác tốt Nên sử dụng khi nào?
- Khi tất cả yêu cầu được hiểu rõ nhưng mong muốn có sự tiến hóa dần của sản phẩm
- Khi cần phải nhanh chóng đưa sản phẩm với chức năng cơ bản ra thị trường sớm
- Áp dụng cho những sản phẩm có thời gian phát triển dài hơn 1 năm
Chương 3. Quản lý dự án phần mềm 3.1. Giới thiệu
3.1.1. Dự án và dự án phần mềm a. Dự án
Dự án là tập hợp các công việc được thực hiện bởi một tập thể (có thể có chuyên môn
khác nhau, thực hiện công việc khác nhau, thời gian tham gia dự án khác nhau), nhằm đạt
được một kết quả như dự kiến, trong thời gian dự kiến, với một kinh phí dự kiến.
Đặc trưng của dự án: Các hoạt động có mục tiêu, mang tính thời điểm (có bắt đầu, có
kết thúc), có các ràng buộc xác định và có nhiều rủi ro
b. Dự án phần mềm
Dự án phần mềm (Software project): Sản phẩm phần mềm
Đặc trưng của dự án phần mềm (PM) o Sản phẩm PM là vô hình o
Không được xác định duy nhất (với cùng yêu cầu) o
Tiến trình phát triển tùy biến, không chuẩn hóa o
Không chấp nhận như các nguyên tắc kỹ nghệ thông thường khác o
Dự án nhiều biến động theo tính chất của sản phẩm & môi trường phát triển
3.1.2. Quản lý dự án a. Khái niệm
Là ngành khoa học nghiên cứu về việc lập kế hoạch, tổ chức và quản lý, giám sát quá
trình phát triển của dự án nhằm đảm bảo cho dự án hoàn thành đúng thời gian, trong phạm
vi ngân sách đã được duyệt, đảm bảo chất lượng, đạt được các mục đích đề ra.
Là việc áp dụng các chức năng và hoạt động của quản lý vào suốt vòng đời của dự án
để dự án đạt được những mục tiêu đề ra.
Là hoạt động áp dụng các kiến thức, kỹ năng, công nghệ vào các hoạt động quản lý của dự án.
Trong thuật ngữ của chuyên ngành kỹ nghệ phần mềm, quản lý dự án phần mềm là
các hoạt động trong lập kế hoạch, giám sát và điều khiển tài nguyên dự án (ví dụ như kinh 30
phí, con người), thời gian thực hiện, các rủi ro trong dự án và cả quy trình thực hiện dự án;
nhằm đảm bảo thành công cho dự án. Quản lý dự án phần mềm cần đảm bảo cân bằng giữa
ba yếu tố: thời gian, tài nguyên và chất lượng. Ba yếu tố này được gọi là tam giác dự án
b. Tại sao phải quản lý dự án
Các vấn đề thường xảy ra đối với một dự án phần mềm 
Thời gian thực hiện dự án vượt mức dự kiến 
Chi phí thực hiện dự án vượt mức dự kiến 
Kết quả của dự án không như dự kiến
Thống kê của Standish Group (2006)
 Có tới 50% trong số các dự án phần mềm thất bại
 Chỉ có 16.2% dự án là hoàn thành đúng hạnvànằmtrong giớihạn ngân sách, đáp
ứng tất cả tính năng và đặc tính như cam kết ban đầu
 Có 52.7% dự án được hoàn thành và đi vào hoạt động nhưng không hoàn thành
đúng hạn và bội chi, thêm nữa không đáp ứng đầy đủ tính năng và đặc tính như thiết kế ban đầu
 Và có 31.1% dự án thất bại trước khi được hoàn thành
 -> hơn 83.8% dự án thất bại hoặc không đáp ứngnhững yêu cầu ban đầu
 2/3 dự án được hoàn thành vượt quá thời gian và kinh phí dự kiến (Capers Jones) [bad  estimates?]
 2/3 dự án được hoàn thành là có độ tin cậy và chất lượng thấp trong một năm đầu triển khai (Jones).
 Tỷ lệ xảy ra lỗi của PM từ 0.5 đến 3.0 /1000 LOC (Bell Labs survey).
 Civilian software: tối thiểu 100 từ tiếng Anh được sinh ra cho mọi câu lệnh. o
Military: ~ 400 từ (Capers Jones)
3.2. Các hoạt động quản lý
3.2.1. Xác định dự án
a. Xác định yêu cầu chung
Trước tiên cần xác định các yêu cầu chức năng (công việc phần mềm thực hiện) cũng
như phi chức năng (công nghệ dùng để phát triển phần mềm, sử dụng trong hệ điều hành
nào...) của phần mềm. Sau đó cần xác định rõ tài nguyên cần thiết để xây dựng phần mềm.
Tài nguyên ở đây có thể gồm có nhân tố con người, các thành phần, phần mềm có thể sử
dụng lại, các phần cứng hoặc công cụ có sẵn cần dùng đến; trong đó nhân tố con người là
quan trọng nhất. Điều cuối cùng là xác định thời gian cần thiết để thực hiện dự án. Trong
quá trình này cần phải nắm bắt được bài toán thực tế cần giải quyết cũng như các hoạt động
mang tính nghiệp vụ của khách hàng để có thể xác định rõ ràng yêu cầu chung của đề án,
xem xét dự án có khả thi hay không. 31 b. Viết đề án
Viết đề án là quá trình xây dựng tài liệu mô tả đề án để xác định phạm vi của dự án,
trách nhiệm của những người tham gia dự án; là cam kết giữa người quản lý dự án, người tài
trợ dự án và khách hàng. Nội dung của tài liệu mô tả đề án thường có những nội dung sau:
- Bối cảnh thực hiện dự án: Căn cứ pháp lý để thực hiện dự án, hiện trạng công nghệ
thông tin của khách hàng trước khi có dự án, nhu cầu ứng dụng phần mềm của khách hàng,
đặc điểm và phạm vi của phần mềm sẽ xây dựng.
- Mục đích và mục tiêu của dự án: xác định mục đích tổng thể, tin học hóa hoạt động
nào trong quy trình nghiệp vụ của khách hành, xác định mục tiêu của phần mềm gồm lượng
dữ liệu xử lý, lợi ích phần mềm đem lại.
- Phạm vi dự án: Những người liên quan tới dự án, các hoạt động nghiệp vụ cần tin học hóa.
- Nguồn nhân lực tham gia dự án: Cán bộ 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
, người bảo trì dự án phần mềm . phần mềm
- Ràng buộc thời gian thực hiện dự án: Ngày nghiệm thu dự án, ngày bàn giao dự án.
- Ràng buộc kinh phí: Kinh phí trong từng giai đoạn thực hiện dự án.
- Ràng buộc công nghệ phát triển: Công nghệ nào được phép sử dụng để thực hiện dự án.
- Chữ kí các bên liên quan tới dự án.
c. Lập kế hoạch thực hiện dự án
Lập kế hoạch thực hiện dự án là hoạt động diễn ra trong suốt quá trình từ khi bắt đầu
thực hiện dự án đến khi bàn giao sản phẩm với nhiều loại kế hoạch khác nhau nhằm hỗ trợ
kế hoạch chính của dự án phần mềm về lịch trình và ngân sách.
Các loại kế hoạch thực hiện dự án
 Kế hoạch đảm bảo chất lượng: Mô tả các chuẩn, các qui trình được sử dụng trong dự án.
 Kế hoạch thẩm định: Mô tả các 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ả các thủ tục, cấu trúc quản lý cấu hình được sử dụng.
 Kế hoạch bảo trì: Dự tính các yêu cầu về 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ĩ năng và kinh nghiệm của các thành viên
trong nhóm dự án sẽ phát triển như thế nào.
Quy trình lập kế hoạch thực hiện dự án
 Thiết lập các ràng buộc của dự án: thời gian, nhân lực, ngân sách
 Đánh giá bước đầu về các "tham số" của dự án: quy mô, độ phức tạp, nguồn lực 32
 Xác định các mốc thời gian trong thực hiện dự án và sản phẩm thu được ứng với mỗi mốc thời gian
Trong khi dự án chưa hoàn thành hoặc chưa bị hủy bỏ thì thực hiện lặp đi lặp lại các công việc sau:
 Lập lịch thực hiện dự án
 Thực hiện các hoạt động theo lịch trình
 Theo dõi sự tiến triển của dự án, so sánh với lịch trình
 Đánh giá lại các tham số của dự án
 Lập lại lịch thực hiện dự án cho các tham số mới
 Thỏa thuận lại các ràng buộc và sản phẩm bàn giao của mỗi mốc thời gian
 Nếu có vấn đề nảy sinh thì xem xét lại các kĩ thuật khởi đầu đưa ra các biện pháp cần thiết
Cấu trúc kế hoạch thực hiện dự án:  Tổ chức dự án  Phân tích các rủi ro
 Yêu cầu về 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 và báo cáo
3.2.2. Đo và ước lượng 3.2.3. Lập lịch
a. Tại sao phải lập lịch?
- Ước lượng cho chúng ta con số khái quát để làm cơ sở thực hiện dự án
+ Lịch trình cụ thể phụ thuộc vào mô hình lựa chọn
+ Số người tham gia thay đổi theo từng pha của dự án
- Cần phải phân tích chi tiết hơn và lập lịch để kiểm soát công việc
- Lập lịch để kiểm soát công việc (nhiệmvụ) + xác định nhiệm vụ
+ thời điểm bắt đầu, thời điểm kết thúc + người thực hiện
+ ràng buộc(mối liên hệ giữa các nhiệm vụ)
 cần có độ mềm dẻo về thời gian
b. Nội dung hoạt động lập lịch
* Lập lịch bao gồm các công việc
- Xác định ngày quan trọng: ngày bắt đầu, ngày kết thúc 33
- Xác định các giai đoạn quan trọng
- Liệt kê các công việc theo thứ tự thực hiện: chỉ ra qua hệ giữa các công việc
+ chỉ ra sự phụ thuộc giữa các công việc
 Các công việc có thể tiến hành đồng thời
 Các công việc chỉ thực hiện khi công việc khác kết thúc
+ giảm tối thiểu các phụ thuộc
 Hạn chế sự chậm trễ
+ thời gian thực hiện dự án phụ thuộc vào đường dài nhất trong đồ thị công việc  Sơ đồ PERT
- Đánh giá nguồn tài nguyên cần thiết để hoàn thành mỗi công việc: nhân lực, thời gian, ngân sách.
* Sử dụng bảng để biểu diễn lịch của dự án
- Bảng các giai đoạn quan trọng Ngày Giai đoạn quan trọng August 26 Project Kickoff (with client) October 16 Analysis Review October 26 System Design Review November 7 Internal Object Design Review November 20 Project Review (with client) - Bảng các công việc
Ngày bắt đầu – Ngày kết Tên công việc thúc Jul 17-Aug 23 Preplanning Phase Aug 26 - Sep 24 Project Planning Sep 11-Oct 8 Requirements Analysis Oct 9 - Oct 26 System Design Oct 28-Nov 7 Object Design Nov 8 - Nov 20 Implementation & Unit Testing - Bảng phân công Tên công Người thực Thời Công việc việc hiện gian trước A Hào 3 - B Hà 2 - C Loan 1 - 34 D Phú 2 A
* Có thể sử dụng sơ đồ để xây dựng, phân tích các lịch phức tạp
- Sơ đồ Gantt: biểu diễn quan hệ thời gian giữa con người và công việc
- Sơ đồ PERT: biểu diễ phụ thuộc giữa các công việc
c. Phương pháp đường găng (Critical Path Method)
* Phương pháp lập lịch và kiểm soát dùng cho các dự án phức tạp.
* Các khái niệm và ký pháp: * Các bước
- Ví dụ: cho bảng công việc Công Thòi Đi sau công Công Thòi Đi sau công việc gian việc việc gian việc A 1 - K 2 G, I B 7 - L 3 I C 8 - M 3 I D 4 - N 2 K E 4 A O 1 L, N F 3 B P 2 G, I, H G 3 C Q 3 G, I, H H 4 D R 2 O, P I 2 E, F S 1 R, Q
- Xác định các đỉnh trung gian của mạng: xét cột “công việc đi trước” 
Bước 1: Khoanh tròn các công việc (cv) là duy nhất/(2/3) trên dòng. Mỗi cv được
khoanh xác định 1 đỉnh ngay sau nó (như sơ đồ ví dụ có 12 đỉnh: a (1),  b
(2), c (3), d (4), i (6), g (7), k (8), h (10) và (e,f) (5), (l,n)
(9), (o,p) (11),(r,q) (12)). 
Bước 2: Xóa tên cv đã khoanh mà có mặt trong các dòng chứa trên 2 cv và quay về bước 1. 35 
Bước 3: Nếu hết các dòng chứa 1 cv chưa được khoanh hay chưa bị xóa, thì xét
đến dòng chứa 2/(3) cv chưa được khoanh hay chưa xóa, lặp lại bước 1 cho đến hết. - Vẽ sơ đồ mạng 
Bước 1: Vẽ đỉnh đầu tiên 0 
Bước 2: Từ đỉnh này, vẽ các cv đi ra khỏi nó (lần đầu tiên đó là các cv a, b, c, d
không đi sau cv nào). Thêm 1 đỉnh vào sau mỗi cv/(cặp cv) được khoanh tròn (cụ
thể là đỉnh (1) sau a, (2) sau b, (3) sau c, (4) sau d) 
Bước 3: Xuất phát từ mỗi đỉnh vừa thêm (lần đầu là 1),(2),(3),(4)) ta xét các cv đi
ra từ các đỉnh này, tức là đi sau các cv kết thúc ở đỉnh này và lặp lại bước 2. Nếu
1 cv không đi sau 1 cv nào được khoanh, tức là tất cả các cv đi trước nó đã bị xóa,
thì thêm 1 đỉnh giả có các cv giả đi từ đỉnh sau cv bị xóa đến nó. CV được xét đi
ra từ đỉnh giả này. Sau đó lặp lại bước 2 
Bước 4: Khi đã vẽ hết các cv, thì thêm đỉnh thứ n và những cv nào không có đỉnh
kết thúc sau nó thì cho chúng kết thúc tại đỉnh cuối cùng này 
Bước 5: Xét các cv có hơn 2 cv đi trước nó và trong số đó có cv đã bị xóa. Với
mỗi cv bị xóa, cần thêm 1 cv giả từ đỉnh sau cv bị xóa đến đỉnh mà cv được xét từ đó đi ra.
Chú ý: Khi đánh số cho các đỉnh mạng phải đảm bảo: số đỉnh ở đầu mỗi cv
phải nhỏ hơn số đỉnh ở cuối cv. 36
- Thời điểm bắt đầu sớm nhất: ts: tính xuôi từ đỉnh đầu ts(0)=0
- Thời điểm bắt đầu muộn nhất: tm:tính ngược, từ đỉnh kết thúc tm(13)=ts(13)=18
- Thời gian dự phòng công việc: tdf
- Công việc găng, đường găng 37
- Biểu đồ lịch trình dự án (Gantt)
3.2.4. Tổ chức dự án
Tổ chức dự án rất quan trọng, là yếu tố quyết định cho sự thành công Bao gồm các hoạt động
- Chọn nhân sự thích hợp
+ Các yếu tố cần xem xét khi chọn nhân sự  Kinh nghiệm o
Hiểu biết lĩnh vực ứng dụn o
Kinh nghiệm với môi trường phát triển o
Hiểu biết về ngôn ngữ lập trình  Đào tạo  Khả năng o Khả năng giao tiếp o
Khả năng thích ứng, khả năng học  Thái độ  Tính cách
- Chọn cấu trúc của nhóm + Nhóm phi hình thức
 Các thành viên của nhóm có vai trò như nhau  Nhóm nhỏ
 Các thành viên đều có năng lực và kinh nghiệm  Dự án khó 38 + Nhóm chief-programmer  Gồm có o
Trưởng nhóm (chief-programmer): thực hiện phân tích, thiết kế, mã hóa, kiểm thử o
Trợ lý: hỗ trợ trưởng nhóm phát triển, kiểm thử o
Thư ký: quản lý thông tin o Các chuyên gia hỗ trợ
 Quản lý, lập tài liệu, lập trình, kiểm thư,…
 Phụ thuộc chủ yếu vào trưởng nhóm
 Trưởng nhóm phải có năng lực + Nhóm phân cấp
 Dự án lớn được chia thành nhiều dự án nhỏ
 Mỗi dự án nhỏ được thực hiện bởi một nhóm
 Mỗi nhóm có một trưởng nhóm
 Mỗi thành viên cấp dưới phải báo cáo công việc với người quản lý trực tiếp
 Mỗi thành viên phải được đào tạo kỹ năng để thực hiện vai trò của mình
- Chọn kích thước của nhóm
+ Kích thước nhóm nên tương đối nhỏ: dưới 8 người
 Giảm thời gian giao tiếp
 Dễ dàng làm việc cùng nhau + Không nên quá nhỏ
 Nhóm bảo đảm tiếp tục làm việc, nếu có thành viên ra đi
+ Đối với một dự án, số người trong nhóm có thể thay đổi
+ Khi một dự án chậm trễ, thêm người vào dự án không bao giờ giải quyết được vấn đề
- Xác định vai trò của các thành viên trong nhóm + Trưởng dự án
 Chịu trách nhiệm một dự án
 Bảo đảm nhóm có đầy đủ thông tin và nguồn tài nguyên cần thiết
 Phân công công việc cho các thành viên
 Kiểm tra thời hạn các công việc
 Giao tiếp với khách hàng
- Quản lý giao tiếp giữa các thành viên trong nhóm
+ Các đặc điểm trong giao tiếp nhóm
 Các thành viên có vị trí cao thường áp đặt các cuộc trao đổi 39
 Nhóm có cả nam và nữ thường giao tiếp tốt hơn
 Giao tiếp phải qua một người điều phối trung tâm thường không hiệu quả
 Tất cả các thành viên nên có sự tham gia vào các quyết định ảnh hưởng đến cả nhóm
 Tính cách của các thành viên o
Quá nhiều thành viên có cùng tính cách cũng có thể không tốt
 Hướng công việc: mỗi người đều muốn thực hiện công việc riêng
 Hướng cá nhân: mỗi người đều muốn làm ông chủ
 Hướng tương tác: nhiều họp hành mà ít thực hiện cụ thể o
Một nhóm nên cân bằng giữa các tính cách.
3.2.5. Theo dõi thực hiện dự án, điều chỉnh lịch biểu
Khi xây dựng dự án, các thành viên của nhóm phải báo cáo việc sử dụng thời gian
cho mỗi hoạt động ở các giai đoạn. Hơn nữa, mỗi cá nhân phải viết một báo cáo ngắn về
tiến bộ của bản thân. Báo cáo này sẽ tóm lược chất lượng công việc, những vấn đề còn tồn
tại và các sai sót hoặc các mâu thuẫn khác có thể làm trì hoãn công việc. Nếu một công việc
bị chậm so với kế hoạch, thì anh ta phải giải trình về sự chậm trễ. Quản trị viên dự án và kỹ
sư hệ thống phải xem xét báo cáo và thời gian biểu để xem liệu có cần bổ sung thêm gì không.
Cả kỹ sư phần mềm và quản trị viên dự án phải vạch ra các tiến bộ thật sự của các cá
nhân so với thời gian biểu dự kiến. Khi sự tiến triển có vẻ chậm lại, quản trị viên dự án cần
phải hỏi anh ta về các tồn tại cụ thể. Liệu đã đủ tiềm lực, hoặc liệu anh ta có nghĩ anh ta có
thể đáp ứng được các hoạch định không. Nếu công việc đã bị đánh giá thấp, kế hoạch phải
được kiểm tra lại để xem việc phân chia thời gian có làm chậm trễ công việc hay không, ảnh
hưởng tích lũy của sự thay đổi phải được kiểm tra để xem công việc có được hoàn tất
không. Nếu không, quản trị viên dự án cần thảo luận vấn đề với người quản lý của anh ta và
họ sẽ quyết định các hành động cần thiết phải làm.
Cần chú rằng phải sớm chỉ ra các vấn đề tiềm tàng trước khi chúng trở thành những
vấn đề lớn. Nếu một người không thể hoàn thành công việc chỉ vì anh ta được phân quá
nhiều công việc, phải phân công lại cho một người khác. Nếu họ không có đủ thời gian
kiểm định, phải thu xếp để có thêm thời gian. Sự quản lý tích cực sẽ ngăn chặn được nhiều
vấn đề. Vấn đề tiếp theo là tính kỹ luật và lao động ảnh hưởng lên kế hoạch các công việc
thay thế, điều chỉnh kế hoạch khi cần thiết và tiếp tục kiểm soát các vấn đề cho đến khi
chúng được giải quyết.
Khi cần thiềt, phải nói cho khách hàng biết về các vấn đề có thể không giải quyết
được do vậy họ sẽ được chuẩn bị cho sự chậm trễ nếu điều đó là không tránh khỏi. Khi sự
thay đổi là cần thiết, cho khách hàng biết về sự thay đổi về ngày giờ kế hoạch thậm chí khi
ngày hoàn tất công việc không thay đổi.
Có nhiều dạng vấn đề tồn đọng có thể xảy ra và quản trị viên dự án phải giám sát,
thay đổi trong suốt quá trình phát triển của dự án. 40
Trong việc xác định phạm vi dự án, quản trị viên dự án phải xem xét các điều sau:
 Khách hàng có hợp tác không?
 Tất cả các đối tác có nhìn nhận và quan tâm?
 Những người sử dụng được phỏng vấn có đưa ra những thông tin đầy đủ và chính xác?
 Những người sử dụng có tham gia như mong đợi?
 Liệu có vấn đề chính sách bên ngoài nào được nêu ra?
 Quy mô, các công việc được xác định đã hợp lý chưa?
 Bằng việc phân tích, quản trị viên dự án biết hầu hết người sử dụng và họ làm
việc thế nào, cần chỉ ra những vấn đề chính sách tiềm tàng, giải quyết chúng và
nên hài lòng với quy mô dự án.
Các hoạt động được giao cho các ban liên quan:
 Liệu tất cả các nhà phân tích có biết quy mô hoạt động và làm việc trong khuôn khổ đó?
 Công việc phân tích nhấn mạnh vào cái gì và như thế nào?
 Liệu mọi người có quan tâm và thích thú với công việc?
 Liệu có va chạm giữa các nhân viên của ban hoặc giữa những người sử dụng?
 Liệu mọi người có biết họ đang làm gì không?
 Có sự phản hồi liên tục được người sử dụng sửa đúng lại, trong kết quả phỏng vấn?
 Các thành viên của ban có bắt đầu hiểu công việc và tình hình của người sử dụng?
 Các thành viên của ban dự án khách quan và không ép người sử dụng theo ý tưởng của mình
 Các tài liệu viết ra đã hoàn thiện? Người sử dụng có đồng ý?
 Việc phân tích có chỉ đúng ra các vấn đề tồn tại của người sử dụng? Các nhân
viên có phân tích và mô tả chính xác các việc cần làm mà không thêm thắt?
 Việc đánh máy, in ấn, sao chụp và các hỗ trợ biên chép khác là có thể chấp nhận?
 Sự giao tiếp giữa các ban và giữa các ban và người sử dụng có đáng hài lòng không?
 Dự án có đúng hạn? Tình trạng đường lối phê bình? Có thay đổi nếu công việc kết thúc sớm?
 Tồn tại lớn nhất hiện tại ở đâu? Làm thế nào để làm nhẹ bớt các vấn đề tồn tại?
 Điều gì chúng ta không biết có thể làm thiệt hại đến công việc?
Các yêu cầu chức năng là kết quả từ việc phân tích cần mô tả ứng dụng nào sẽ được
áp dụng, và phải luôn cẩn thận trước các yêu cầu của người sử dụng. Một vấn đề mà nhiều
dự án gặp phải là người sử dụng muốn một ứng dụng chức năng đơn thuần nhưng các nhà
phân tích lại tạo ra một ứng dụng giá cao với các chức năng của người sử dụng nhưng có 41
nhiều đặc tính không cần thiết. Vấn đề này, nếu xảy ra, phải được giải quyết trước khi việc
phân tích kết thúc hoặc các chức năng phụ thêm sẽ được đưa vào ứng dụng kết quả. Khi vấn
đề thiết kế quá mức nảy sinh, điều quan trọng là phải cố gắng truy cập đến các phân tích cụ
thể để tái huấn luyện. Do vậy, quản trị viên dự án quan tâm đến:
 Các nhà phân tích có biết đến các ứng dụng?
 Việc chuyển dịch sang môi trường hoạt động có đúng và hoàn tất?
 Những người sử dụng có tham gia như mong đợi? Những người sử dụng có quan
tâm đúng mức đến việc thiết kế màn hình chạy thử và chấp nhận các phê bình?
 Mọi người có quan tâm và thích thú công việc?
 Có sự va chạm giữa các nhân viên hoặc giữa nhân viên và người sử dụng?
 Mọi người có biết họ đang làm gì?
 Các nhân viên có chú ý tới sự thay đổi trách nhiệm của họ và họ có cảm thấy
thoải mái để có thể tiếp tục công việc?
 Sự giao tiếp giữa các ban dự án và người sử dụng có hài lòng?
 Dự án diễn biến đúng kế hoạch? Tình trạng phê bình thế nào? Có thay đổi do
công việc hoàn thành sớm không?
 Vấn đề lớn nhất bây giờ là gì? Có thể làm gì để giảm nhẹ các vấn đề?
 Điều có thể gây nguy hại cho chúng ta mà không biết? Môi trường thực hiện có thích hợp cho ứng dụng?
 Phần mềm quản lý dữ liệu có thể phù hợp với ứng dụng này không?
Do sự phát triển của chương trình nên số các thành viên dự án có thể thường xuyên
tăng thêm ngày càng nhiều. Sự trao đổi các thông tin là cần thiết để nắm bắt được vị trí của
mọi thành viên dự án và các thành viên cũng nắm bắt được sự phát triển của dự án. Nên quá
trình viết và kiểm thử chương trình sẽ được điều chỉnh trong quá trình trao đổi thông tin và chạy chương trình.
Để đáp ứng được, phải quan tâm:
 Các thành viên dự án có biết được vai trò phần việc của họ trong dự án hay
không? Họ có đánh giá được phần việc của mình hay không? Các thành viên hiện
tham gia dự án có đảm đương được công việc mà họ và các thành viên đang làm không?
 Thời gian kiểm thử chương trình đã đủ chưa? Thông tin truy cập đã đầy đủ chưa?
 Thành viên dự án có đủ hiểu biết về các công nghệ đang sử dụng để làm việc độc lập không?
 Các thành viên mới có đủ trình độ để làm việc với các cố vấn có kinh nghiệm hay không?
 Người sử dụng có yêu cầu thêm những thay đổi hay không?
 Người sử dụng có tham gia vào quá trình kiểm thử thiết kế, có dùng các tài liệu
về phát triển, nâng cấp, hướng dẫn hay không? 42
 Các thành phần sửa chữa phản hồi có gây cho khách hàng nghi ngờ chương trình có lỗi không?
 Các giao thức sẽ được sử dụng ngày càng nhiều có thể hiện được ứng dụng hoạt
động như thế nào hay không?
 Qua từng bước thực hiện chương trình, có phát sinh ra lỗi không? Những lỗi này
có thể điều chỉnh được không?
Trong suốt quá trình thực hiện chương trình cũng như trong quá trình thực hiện các
bước kiểm thử, các kiểm tra về sự thích ứng của chương trình và về các mức hệ thống liên
quan sẽ tăng dần. Các cơ sở dữ liệu được thiết lập và hoàn chỉnh dần. Môi trường điều hành được chuẩn bị.
Các cơ cấu liên quan được đưa ra từ ứng dụng được thực hiện dưới dạng mã làm cho
nó được thực thi một cách chính xác. Các dạng câu hỏi đặt ra cho người quản lý có thể có các dạng sau:
 Các thành viên hiện tại của dự án có đảm nhiệm được phần công việc của mình
hay không? Mọi thành viên có hiểu được công việc họ đang làm hay không?
 Thời gian kiểm thử chương trình đã đủ chưa? Thông tin truy cập đã đầy đủ chưa?
 Người sử dụng có yêu cầu thêm những thay đổi hay không? Người sử dụng có
tham gia vào quá trình kiểm thử hay không?
 Các thành phần sửa chữa phản hồi có gây cho khách hàng các nghi ngờ chương trình có lỗi không?
 Qua từng bước thực hiện chương trình, có phát sinh ra lỗi không? Những lỗi này
có thể điều chỉnh được không?
 Quá trình kiểm tra ở mức độ hệ thống có thể hiện được các chức năng như đã đặt ra hay không?
 Quá trình kiểm tra sự thích ứng có xác thực được tất cả các liên kết trung gian hay
không? Nó có tác dụng như thế nào tới việc chứng tỏ độ tin cậy của các liên kết
này trong suốt quá trình kiểm thử hệ thống.
 Chúng ta không biết những gì về môi trường điều hành mà nó có thể ảnh hưởng tới dự án?
 Phần mềm cơ sử dữ liệu làm việc có hoàn hảo không? Quy trình phục hồi và lưu
trữ dữ liệu có đầy đủ cho quá trình kiểm thử hay không?
 Chúng ta có thể sử dụng các kiểm tra về sự thích ứng của chương trình và về hệ
thống như thế nào để phát triển các giai đoạn kiểm tra hồi quy.
 Các thông tin đã hoàn tất chưa? Các thành viên dự án đã làm việc đúng khả năng
chưa? Chúng ta có thể đưa các thành viên trong dự án đến thực hiện các dự án
khác được không? Nếu chúng ta cho phép họ đi, thì ai sẽ thay thế vị trí họ khi có các vấn đề xảy ra?
Khi quá trình kiểm thử kết thúc, các phần của ứng dụng đã thực sự sẵn sàng cho sử
dụng. Nên có một sơ đồ cho ứng dụng điều hành thực tế, điều đó sẽ dễ dàng cho người sử 43
dụng trong việc dùng chương trình để tránh có quá nhiều hỏng hóc. Sự dễ dàng trong quá
trình sử dụng này sẽ tạo cho người lập dự án có thời gian cố định những lỗi sai đã phát hiện
trong quá trình viết chương trình mà không có áp lực giám sát nào. Vấn đề hiện tại là tập
trung vào việc đưa ra ứng dụng làm việc trong môi trường đã được định hướng cho người sử
dụng nó. Các câu hỏi liên quan sẽ bao gồm:
 Vị trí đã được chuẩn bị đầy đủ chưa? Điều kiện về không gian đã đầy đủ? Thiết
kế về ánh sáng và môi trường làm việc đã đầy đủ?
 Người sử dụng đã được đào tạo hoàn hảo và đã sẵn sàng làm việc?
 Chu trình làm việc và đánh giá kết quả đã được chỉ ra đầy đủ cho phép việc tiến
hành và kiểm tra các kết quả đạt được.
 Khi tìm ra lỗi chúng có thể điều chỉnh được không?
 Người sử dụng có nắm bắt được công việc như dự kiến?
 Các thành viên hiện tại của dự án có thể đảm nhiệm được phần việc của họ? Tất
cả mọi người có đủ công việc để làm không? Họ có thời gian rỗi để tham gia các dự án khác không?
 Thông tin trao đổi giữa các nhóm với nhau và giữa các nhóm với người sử dụng
có xuất hiện phù hợp không? Người sử dụng có thể nói bất kỳ khi nào có vấn đề
xảy ra không? Họ có tham gia vào quá trình lập nên các quy định cho vấn đề sửa chữa lỗi hay không?
Các câu hỏi trên là những vấn đề kỹ thuật và nên được trình lên cho chủ dự án. Quản
trị viên dự án là người nắm bắt và quan tâm đến tất cả các vấn đề. Việc biên dịch các báo
cáo về tiến trình hoạt động cá nhân và tiến trình hoạt động dự án trong một dự án cho phép
người quản lý và bất kỳ nhân viên nào đều có thể xem xét lại những quyết định, các vấn đề
xuất hiện trong quá trình tiến hành.
3.2.6. Viết báo cáo dự án PHẦN ĐẦU BÁO CÁO: - Tóm tắt - Lý do chọn đề tài - Mục tiêu dự án
- Địa điểm thực hiện dự án
- Đối tượng thụ hưởng
- Những lợi ích về mặt phát triển cộng đồng, xây dựng bền vững và bảo vệ môi trường - Phương pháp nghiên cứu
- Các đối tác hỗ trợ mặt kinh phí và triển khai
- Sơ lược về chi phí/giá thành - Kết quả dự kiến
PHẦN CHÍNH BÁO CÁO: nên chia thành các chương, mục như sau: 44
I. Thông tin chung về dự án (tối đa 1 trang A4) 1. Tên dự án 2.Trưởng nhóm dự án
3. Danh sách những người tham gia II. Đặt vấn đề
Khái quát về tình hình nghiên cứu có liên quan đến đề tài. Từ đó làm nổi bật
sự cần thiết phải nghiên cứu.
III Mục tiêu và lợi ích của đề tài 1. Mục tiêu đề tài
2. Lợi ích đề tài đề tài có thể mang lại nếu được thực hiện
IV. Phương pháp nghiên cứu, cách tiếp cận
V. Nội dung nghiên cứu và kết quả đạt được
1. Mô tả chi tiết nội dung nghiên cứu và kết quả đạt được
2. Nêu ra các thuận lợi và khó khăn trong quá trình thực hiện từng giai đoạn cùng
với biện pháp khắc phục
3. Những chứng minh cho thấy khả năng ứng dụng dự án và duy trì dự án
4. Dự kiến sản phẩm và địa chỉ ứng dụng * Loại sản phẩm:
* Địa chỉ có thể ứng dụng hoặc chuyển giao kết quả nghiên cứu:
5 . Dự kiến kinh phí thực hiện
VI. Kết luận và kiến nghị
- Những kết quả nghiên cứu chủ yếu đã thực hiện được. So sánh với mục đích yêu
cầu đề ra đã đạt được đến mức độ nào. Nêu những hạn chế, nguyên nhân.
- Nêu lên kiến nghị có liên quan đến đề tài / dự án. Đề xuất hướng tiếp tục nghiên
cứu, hoàn thiện hoặc biện pháp chuyển giao cho sản xuất... VII. Tài liệu tham khảo VI. Phụ lục
3.3. Các yếu tố quản lý
3.3.1. Quản lý tài nguyên
Chi phí (trả công) con người là phần chính của chi phí xây dựng phần mềm. Ngoài
ra, năng lực của người phát triển phần mềm lại rất biến thiên, kéo theo sự phức tạp trong
tính toán chi phí. Phát triển phần mềm được tiến hành theo nhóm. Kích thước tốt của nhóm
là từ 3 đến 8 ngưòi. Phần mềm lớn thường được xây dựng bởi nhiều nhóm nhỏ. Một nhóm
phát triển có thể gồm các loại thành viên sau: • Người phát triển
• Chuyên gia về miền ứng dụng 45
• Người thiết kế giao diện
• Thủ thư phần mềm (quản lý cấu hình phần mềm) • Người kiểm thử
Một nhóm phát triển cần có người quản lý, và người có vai trò lãnh đạo về mặt kĩ
thuật. Một đặc trưng của làm việc theo nhóm là sự trao đổi thông tin (giao tiếp) giữa các
thành viên trong nhóm. Thời gian dùng cho việc giao tiếp có thể chiếm đến nửa tổng thời
gian dành cho pháp triển phần mềm.
Ngoài ra, thời gian không dùng cho phát triển sản phẩm cũng chiếm một phần lớn
thời gian còn lại của người lập trình. Một người có thể đồng thời làm việc cho nhiều nhóm
(dự án) phần mềm khác nhau. Điều này làm cho việc tính toán giá thành phần mềm phức
tạp. Cần ghi nhớ, trong sản xuất phần mềm thì
- Năng lực của các thành viên là không đồng đều
- Người tốt (nhất) có thể sản xuất hơn 5 lần trung bình, người kém có thể không cho kết quả gì
- Một số công việc quá khó đối với mọi người
Không nên tăng số thành viên một cách vô ý thức, vì như thế chỉ làm tăng sự phức
tạp giao tiếp giữa các thành viên, khiến công việc nhiều khi chậm lại. Một số việc (phức tạp,
đặc thù) chỉ nên để một người làm.
3.3.2. Quản lý cấu hình
Thực tế, có khá nhiều định nghĩa hoặc khái niệm khác biệt về quản lý cấu hình, tuy
rằng chúng vẫn có những điểm chung cơ bản. Trong phạm vi bài viết, chúng tôi muốn phần
nào làm sáng tỏ một số định nghĩa và thuộc tính cơ bản của quản lý cấu hình trong quy trình sản xuất phần mềm.
Những ai quan tâm đến quy trình sản xuất phần mềm, chắc hẳn không ít lần gặp khái
niệm về quản lý cấu hình (Configuration Management). Ta dễ dàng tìm thấy các yêu cầu về
quản lý cấu hình (QLCH) một cách trực tiếp hay gián tiếp trong các bộ tiêu chuẩn hoặc mô
hình quy trình sản xuất phần mềm (QTSXPM) thông dụng hiện nay như CMM/CMMI, ISO
15504 hoặc ISO 9001:2000. Trong CMM và CMMI, QLCH là yêu cầu bắt buộc ngay từ
mức 2, là mức cơ bản nhất của hai mô hình này.
Thực tế, có khá nhiều định nghĩa hoặc khái niệm khác biệt về QLCH, tuy rằng chúng
vẫn có những điểm chung cơ bản. Trong phạm vi bài viết, chúng tôi muốn phần nào làm
sáng tỏ một số định nghĩa và thuộc tính cơ bản của QLCH trong QTSXPM.
a. Tại sao cần Quản lý cấu hình?
Chắc hẳn trong chúng ta đã ít nhất một lần gặp những tình huống sau:
• Một lỗi (bug) nào đó của phần mềm đang xây dựng đã tốn nhiều công sức sửa chữa,
bỗng “thình lình” xuất hiện trở lại.
• Một chức năng (function) nào đó của phần mềm đã được phát triển và kiểm tra cẩn
thận bổng thất lạc hoặc biến mất một cách khó hiểu. 46
• Một chương trình (program) đã được kiểm tra hết sức cẩn thận, bỗng nhiên không “chạy” được nữa.
• Một chương trình gồm nhiều đơn thể (module), mỗi đơn thể gồm nhiều chức năng,
các chức năng được chia ra cho nhiều lập trình viên, mỗi chức năng bao gồm nhiều tập tin
mã nguồn (source code) với nhiều phiên bản (version) khác nhau. Khi tích hợp hệ thống và
biên dịch, trong hàng chục tập tin source code với hàng trăm version, tập tin nào, version
nào là đúng và cần phải lấy để tiến hành tích hợp?
Các vấn đề trên sẽ không xảy ra nếu như trong dự án, việc QLCH được thực hiện
nghiêm túc và kiểm soát chặt chẽ.
Ta có thể tham khảo định nghĩa ngắn gọn sau từ CMM và ISO 15504: “Mục đích của
QLCH là để thiết lập và bảo đảm tính toàn vẹn của các sản phẩm trung gian cũng như các
sản phẩm sau cùng của một dự án phần mềm, xuyên suốt chu kỳ sống của dự án đó.”
Nói cho dễ hiểu và gần gũi, QLCH bao gồm các công việc về nhận dạng, tổ chức, và
quản lý các thay đổi đối với những sản phẩm đang được xây dựng bởi một nhóm lập trình
viên, từ các sản phẩm trung gian đến sản phẩm sau cùng.
QLCH tốt sẽ giải quyết được hàng loạt những khó khăn trong các dự án, đặc biệt trong các dự án lớn:
- Cập nhật đồng thời: Khi 2 hoặc nhiều lập trình viên làm việc cách biệt nhau nhưng
trên cùng một chương trình hoặc dự án, những thay đổi mà người này thực hiện có thể sẽ
phá vỡ kết quả làm việc của người khác. Ví dụ: Sản phẩm anh A sử dụng kết quả công việc
của anh B, sản phẩm của anh B thay đổi có thể làm cho sản phẩm anh A không chạy được nữa.
- Chia sẻ source code: Trong các hệ thống lớn, khi các chức năng chung bị thay đổi,
tất cả những người liên quan phải được biết.
- Phiên bản phần mềm (release): Hầu hết các chương trình hoặc hệ thống lớn được
phát triển với nhiều release tiến hóa từ thấp đến cao. Trong trường hợp một release khách
hàng đang dùng, release khác đang được kiểm tra (test), và một release khác nữa đang trong
quá trình phát triển, khi có lỗi (bug) xảy ra, việc sửa lỗi phải đồng bộ giữa ba phần này, nếu
không quản lý source code tốt, vấn đề đồng bộ rất khó thực hiện được. Nếu lỗi ở release
khách hàng đang dùng, nó phải được sửa chữa trong tất cả các release sau đó.
Khi nào thì cần tiến hành QLCH? QLCH được thực hiện xuyên suốt chu kỳ sống của
dự án, từ lúc bắt đầu đến khi kết thúc, thậm chí vẫn còn trong giai đoạn bảo trì sản phẩm sau dự án. b. Hoạt động QLCH
Trước khi đi vào chi tiết, ta cần tìm hiểu 2 khái niệm rất cơ bản trong QLCH:
• Configuration Item - CI: định danh này trong QLCH là tên gọi của các sản phẩm,
sản phẩm trung gian, một tập tin (file) hoặc nhóm file, tài liệu hoặc nhóm tài liệu trong một
dự án mà ta cần phải quản lý và kiểm soát. Nói chung là những “món” được tạo ra trong
một dự án mà ta cần phải quản lý, ví dụ: một file source code, tài liệu về yêu cầu sản phẩm, bản thiết kế v.v. 47
• Baseline: một điểm “mốc” được thỏa thuận bởi những người liên quan trong một dự
án, sao cho sau điểm “mốc” này, mọi thay đổi phải được thông báo tới tất cả những người có liên quan.
Lập kế hoạch QLCH (Configuration Management planning)
Thông thường, việc lập kế hoạch cho QLCH được thể hiện trong tài liệu có tên Kế
hoạch quản lý cấu hình (Configuration Manegement Plan – CMP). Bản kế hoạch này thường bao gồm:
• Ý nghĩa, mục đích và phạm vi áp dụng của bản kế hoạch
• Vai trò và trách nhiệm của nhóm, cá nhân trong dự án thực hiện các hoạt động khác
nhau liên quan đến QLCH. Định nghĩa rõ ràng ai thực hiện (perform), ai xem xét (review),
ai phê duyệt (approve) trên các CI của dự án, cũng như vai trò của khách hàng, người sử dụng đầu cuối.
• Công cụ (tool), môi trường (environment) và cơ sở hạ tầng (infrastructure). Phần
này mô tả các công cụ phần mềm hoặc quy trình thủ tục được sử dụng hỗ trợ QLCH, chẳng
hạn công cụ quản lý phiên bản sản phẩm (version control); mô tả vị trí các máy chủ, máy
trạm, cấu hình hệ thống client-server,...
• Phương pháp định danh và thiết lập baseline trên các CI
• Quy ước đặt tên trong dự án, gồm cả tên file
• Quy trình xử lý và quản lý các thay đổi (change control process)
• Chỉ định thành viên nhóm Configuration Control Board (CCB)
• Thông tin nơi lưu trữ các CI
• Kiểm kê và báo cáo cấu hình (configuration accounting and reporting)
• Quy trình thủ tục lưu trữ và chép dự phòng (backup and archieve)
Các điểm trong bản kế hoạch trên sẽ được giải thích rõ trong các phần tiếp sau.
Định danh/đánh số các CI (Identification of Configuration Items)
Định danh là một trong những hoạt động nền tảng của QLCH. Mục đích của định
danh là để xác định tính duy nhất của một CI, cũng như mối quan hệ của nó với các CI
khác. Nó bao gồm việc mô tả tên, đánh số, đánh dấu đặc trưng, giúp nhận biết và phân biệt
một CI với các CI hay thành phần khác.
Bạn có thể nhận thấy hình thức định danh tương tự trong đời sống thực tế. Ví dụ,
người ta đánh số bàn trong nhà hàng nhằm giúp người phục vụ mang đúng thức ăn cho khách.
Trong sản xuất phần mềm, một CI có thể bao gồm một hay nhiều file. Ví dụ: một
module tên ExpMod có thể được coi là một CI, module này có 2 file ExpMod.h và ExpMod.c.
Ví dụ: PRJ001_REQB_1.0.4_draft_B cho biết: Số ID của dự án: PRJ001 Số ID của Item : REQB 48 Phiên bản: 1.0.4_draft_B
Trong một dự án, thường có rất nhiều file source code, quy tắc cơ bản là: các file
cùng tạo nên một khối chức năng được gom chung thành một CI.
Kiểm soát phiên bản (Version Control)
Có nhiều định nghĩa và cách hiểu khác nhau về version control, ở đây chúng tôi chỉ
muốn định nghĩa nó ở khía cạnh thông dụng, sát với bản thân cụm từ nhất.
Version control là sự kiểm soát các phiên bản (version) khác nhau của một CI (bao
gồm việc định danh và sự lưu trữ CI đó).
Thế phiên bản là gì? một phiên bản là một thực thể mới của một CI sau khi đã qua
một hoặc nhiều lần xem xét và thay đổi.
Hiện có nhiều công cụ trên thị trường hỗ trợ cho việc kiểm soát phiên bản, một số
công cụ thông dụng là: Visual Source Safe của Microsoft, ClearCase của Rational, CVS (nguồn mở).
Mỗi phiên phản sẽ có một số ID đầy đủ, và được tăng dần cho mỗi phiên bản mới.
Lưu ý rằng phiên bản của một CI khác với phiên bản của các file thành phần của CI
đó. Trong ví dụ trên, phiên bản của CI “ExpMod” khác với phiên bản của file thành phần
“ExpMod.h” và “ExpMod.c”.
Các phiên bản quan trọng của một CI có thể được đánh dấu để nhận biết một “mốc”
quan trọng trong tiến trình phát triển CI đó, phiên bản mà CI được phê duyệt hay baseline.
Quản lý baseline (Baseline Management)
Cũng như Version Control, baseline có nhiều cách hiểu khác nhau, trong phạm vi bài
viết này, chúng tôi chọn ý nghĩa tương đối phổ biến. Trong thực tế thường gặp các loại baseline sau:
• Chức năng (functional)
• Kế hoạch (planning)
• Yêu cầu (requirements)
• Sản phẩm (product)
• Bản phân phối (release) • Kiểm tra (test)
• Môi trường hoạt động (environment) Quản lý baseline bao gồm:
• Chọn các CI cho mỗi loại baseline
• Tiến hành “ghim chết” baseline tại thời điểm sau khi các thay đổi đã được chấp thuận và phê chuẩn.
Thông thường, baseline được tiến hành tại điểm kết thúc của mỗi giai đoạn hay tại
các “mốc” quan trọng trong dự án. 49
Đồng thời, trong quản lý baseline, vai trò và nhiệm vụ của những người thiết lập
hoặc phê chuẩn baseline cũng phải được định nghĩa.
Kiểm soát thay đổi (Change control)
Khi phát triển hoặc bảo trì một sản phẩm phần mềm, việc thay đổi yêu cầu là không thể tránh khỏi.
Mục đích của change control là để kiểm soát đầy đủ tất cả các thay đổi ảnh hưởng
đến việc phát triển một sản phẩm. Đôi lúc chỉ một vài yêu cầu thay đổi nhỏ của khách hàng,
tất cả các chặng của quy trình phát triển phần mềm từ thiết kế, đến viết code, đến kiểm tra
sản phẩm đều phải thay đổi theo.
Nếu các thay đổi này không được kiếm soát chặt chẽ sẽ dẫn đến rất nhiều sai sót. Xét
ví dụ sau: 5 lập trình viên cùng làm trong một dự án, nhưng chỉ có 3 được thông báo về việc
thay đổi thiết kế. Kết quả là khi tích hợp, hệ thống sẽ không vận hành được.
Yêu cầu trong kiểm soát thay đổi là mọi sự thay đổi phải được thông báo đến tất cả
những người hoặc nhóm làm việc có liên quan.
Các bước cơ bản của kiểm soát thay đổi bao gồm:
• Nghiên cứu, phân tích
• Phê chuẩn hoặc không phê chuẩn
• Thực hiện việc thay đổi
• Kiểm tra việc thay đổi
• Xác lập baseline mới
Trong kiểm soát thay đổi, ta cũng thường gặp khái niệm “nhóm kiểm soát thay đổi”
gọi tắt là CCB (Change Control Board), nhóm này được thành lập trong từng dự án. CCB thông thường bao gồm:
• Người QLC H (Configuration Manager)
• Trưởng dự án (Project Manager)
• Trưởng nhóm (Technical Lead)
• Trưởng nhóm kiểm soát chất lượng (Test Lead)
• Kỹ sư chất lượng (Quality Engineer)
• Và những ai bị ảnh hưởng bởi các thay đổi
Nhiệm vụ của CCB thường là:
• Bảo đảm tất cả các thay đổi là được các bộ phận liên quan nhận biết và tham gia
• Xem xét, phê chuẩn hoặc phủ quyết các thay đổi trên các baseline
• Kiểm tra, xác nhận các thay đổi
• Phê chuẩn các bản phân phối sản phẩm (release) đến khách hàng
Báo cáo tình trạng cấu hình (Configuration Status Accounting)
Công việc này bao gồm việc ghi nhận và báo cáo tình trạng của các CI cũng như yêu
cầu thay đổi, tập hợp số liệu thống kê về CI, đặc biệt là các CI góp phần tạo nên sản phẩm. 50
Nó trả lời những câu hỏi như: có bao nhiêu file bị ảnh hưởng khi sữa chữa một lỗi phần mềm nào đó?
Kết quả của công việc này được ghi nhận trong một báo cáo mang tên Configuration
Status Accounting Report (CSAR). Báo cáo này thường làm rõ những điểm sau:
• Liệt kê tất cả baseline và CI thành phần hoặc có liên quan.
• Làm nổi bật các Cl đang được phát triển hoặc vừa bị thay đổi
• Liệt kê các thay đổi còn đang dang dở hay đang hoàn thành, và các baseline bị ảnh
hưởng (bởi sự thay đổi đó)
Việc báo cáo này được làm thường xuyên và định kỳ, xuyên suốt dự án. Auditing
(Audit là một thuật ngữ rất thường dùng, cho nhiều ngành nghề khác nhau, tuy nhiên
trong lĩnh vực sofware, chúng tôi không tìm thấy từ tiếng Việt tương đương phản ánh đủ ý
nghĩa, do vậy xin giữ nguyên thuật ngữ gốc, nó có ý nghĩa gần với “kiểm tra” và “xem
xét”). Có 3 loại audit thường được thực hiện.
- CSAR Audit: Thường được làm sau mỗi lần một CSAR được tạo ra, việc kiểm tra bao gồm:
• Bảo đảm các baseline mới nhất được liệt kê trong CSAR
• Bảo đảm tất cả CI tạo nên một baseline được liệt kê
• Kiểm tra các CI đã bị thay đổi từ lần baseline trước đó, so sánh chúng với các yêu
cầu thay đổi để khẳng định rằng sự thay đổi trên CI là hợp lý.
- Physical configuration audit (PCA): nhằm mục đích khẳng định xem những gì
khách hàng yêu cầu có được hiện thực hay không. Gồm 2 việc:
• Kiểm tra vết để phản ánh tính 2 chiều (traceability) giữa yêu cầu khách hàng và
việc hiện thực code trong dự án.
• Xác định những gì sẽ được phân phối cho khách hàng (executable files, source
code, tài liệu đi kèm...) có đáp ứng yêu cầu khách hàng hay không.
- Functional configuration audit (FCA): nhằm mục đích khẳng định những gì khách
hàng yêu cầu có được kiểm tra chặt chẽ trên sản phẩm tạo ra trước khi giao cho khách hàng hay không. Gồm:
• Kiểm tra vết để phản ánh tính 2 chiều giữa yêu cầu khách hàng và việc kiểm tra sản phẩm.
Quản lý release (Release management)
Trong thực tế, có nhiếu định nghĩa khác nhau về khái niệm “release”. Về cơ bản,
chúng ta có thể hiểu: Quá trình phát triển một phần mềm thường qua nhiều lần tích hợp, kết
quả của mỗi lần tích hợp là một bản “build”, trong rất nhiều bản “build” đó, một số bản đáp
ứng một số yêu cầu đã định hoặc lập kế hoạch trước (theo yêu cầu khách hàng), sẽ được gởi
cho khách hàng để kiểm tra hoặc đánh giá. Các bản build này được gọi là “release”; công
việc tạo ra và phân phối các bản release được gọi là công việc “release”. Theo cách hiểu
này, sản phẩm sau cùng cũng là một bản release, đôi khi được gọi là “final release”. 51
Trong quá trình release, việc quản lý đòi hỏi phải thực hiện các công việc sau:
• Baseline môi trường phát triển sản phẩm và các file, tài liệu (sẽ release)
• Thực hiện báo cáo CSAR (xem định nghĩa ở trên)
• Thực hiện các audit: PCA và FCA
• Đóng gói file và tài liệu sẽ release
• Xác nhận đã nhận bản release từ khách hàng
Lưu trữ và chép dự phòng (Backup & archive)
Lưu trữ và chép dự phòng là một hoạt động của QLCH và là một trong những hoạt
động quan trọng phải có của sản xuất phần mềm. Nó giúp khắc phục các trường hợp rủi ro
bị mất mát dữ liệu do thao tác sai, virus, hoặc sự cố phần cứng/ phần mềm. Ở khía cạnh
khác, nó hỗ trợ cho hoạt động version control (đã nói ở trên) trong trường hợp ta muốn sử
dụng những version khác nhau.
Lưu trữ và chép dự phòng đòi hỏi toàn bộ sản phẩm và sản phẩm trung gian của dự
án phải được định kỳ chép dự phòng trên những thiết bị hoặc những nơi khác một cách an toàn.
Và khi dự án kết thúc, các hoạt động sau cần phải thực hiện:
• Lưu trữ toàn bộ dữ liệu của dự án, tuân thủ quy trình lưu trữ đã được thiết lập (định
nghĩa bởi dự án hoặc quy định ở cấp công ty).
• Lưu trữ hoặc huỷ bỏ các tài liệu ở dạng giấy.
• Dọn sạch dữ liệu hoặc thông tin của dự án vừa kết thúc, sau khi đã chép lưu trữ.
c. Vai trò của các thành viên trong dự án
Trong một dự án điển hình, thông thường có 4 (nhóm) chức năng sau (thường gọi tắt
là role) tham gia thực hiện các hoạt động QLCH:
CM (Configuration manager)
• Thiết lập và bảo trì kho lưu trữ (repository) của dự án.
• Phát triển và triển khai các quy trình thủ tục QLCH của dự án.
• Thiết lập các baseline, ghi nhận chi tiết các thay đổi trên các baseline
• Bảo đảm các baseline không bị thay đổi khi chưa được phê chuẩn.
• Tổ chức và điều phối các cuộc họp của CCB
Trưởng dự án (Project manager):
• Giám sát các hoạt động QLCH.
• Bảo đảm các yêu cầu cần thiết cho hoạt động QLCH. Ví dụ: số giờ thành viên dự án
bỏ ra cho QLCH, công cụ hỗ trợ cho QLCH...
CCB (Configuration Control Board)
Bao gồm các thành viên trong dự án, và có chức năng như đã nói ở trên.
Các thành viên của dự án
Các thành viên của dự án, kể cả CM, PM và thành viên CCB, có trách nhiệm: 52
• Tuân thủ tất cả các quy trình thủ tục của bản kế hoạch QLCH (CMP)
• Tham gia vào nhóm CCB khi có yêu cầu
Trên đây là vài nét hết sức cơ bản về QLCH - một lĩnh vực quan trọng và cơ bản
trong phát triển và sản xuất phần mềm. Thực tế, mỗi hoạt động thành phần của QLCH đều
có những chi tiết riêng phức tạp. Nếu có điều kiện, trong tương lai chúng tôi sẽ bàn sâu
thêm từng hoạt động thành phần, đặc biệt ở khía cạnh kỹ thuật và áp dụng thực tế.
3.3.3. Quản lý rủi ro
Rủi ro là yếu tố luôn tồn tại trong mọi hoạt động sản xuất và kinh doanh, và dự án
phần mềm cũng không ngoại lệ.
Rủi ro là yếu tố luôn tồn tại trong mọi hoạt động sảbn xuất và kinh doanh, và dự án
phần mềm cũng không ngoại lệ. Tuy nhiên, với đặc thù riêng của mình, nhận diện và kiểm
soát rủi ro trong dự án phần mềm là điều không đơn giản. Trong thực tế, nhiều dự án phần
mềm đã bỏ qua hoặc kiểm soát rủi ro sơ sài, chiếu lệ dẫn đến kết quả thất bại, khách hàng
phàn nàn về chất lượng hoặc lỗ vốn do chi phí tăng cao.
a. Rủi ro trong các dự án phần mềm
Thông thường, “rủi ro” dùng để chỉ một hay nhiều sự việc chưa nhưng có khả năng
xảy ra trong tương lai có tác động đến dự án, và khi sự việc đó xảy ra thường sẽ gây ảnh
hưởng xấu, thậm chí là “tai nạn” cho dự án, cản trở dự án đạt được mục tiêu của mình. Rủi
ro thường được nhận biết dựa vào một số dấu hiệu báo trước, đôi khi dựa vào kinh nghiệm
của các dự án tương tự trước đây.
Quản lý rủi ro có vai trò khá quan trọng trong toàn bộ tiến trình quản lý dự án. Trong
cả 2 bộ mô hình và tiêu chuẩn nổi tiếng được ứng dụng nhiều trong dự án phần mềm là
CMMi (Capability Maturity Model Integration) của viện Công nghệ Phần mềm Hoa Kỳ
(SEI) và PMP (Project Management Professional) của viện Quản trị Dự án PMI (Project
Management Institude) đều xem quản lý rủi ro là một trong những hoạt động cơ bản nhất
của quá trình quản trị dự án.
Mặc dù nhận diện và kiểm soát tốt rủi ro có khả năng ảnh hưởng đến dự án đòi hỏi sự
tham gia của nhiều người, tuy nhiên người có vai trò trực tiếp và quan trọng nhất là trưởng
dự án. Do đó, một tiêu chí bắt buộc của một trưởng dự án giỏi là khả năng kiểm soát tốt rủi ro.
b. Quy trình quản lý rủi ro 53
Hình 1: Quy trình cơ bản quản lý rủi ro
Nhận diện và kiểm soát tốt rủi ro chỉ bằng kỹ năng và kinh nghiệm cá nhân không chưa đủ, việc
kiểm soát rủi ro phải được thực hiện theo một quy trình chặt chẽ và phù hợp với đặc thù, mục tiêu và ng sách của dự án.
Tổng quát, quy trình cơ quản lý rủi ro bao gồm các bước chính được trình bày ở Hình 4.
Ở mức chi tiết hơn, quy trình quản lý rủi ro bao gồm các bước cùng với trình tự xử lý
và mối quan hệ giữa chúng như trình bày ở Hình 2.
* Nhận diện rủi ro
Xác định được chính xác các nguồn có khả năng phát sinh rủi ro là điều không dễ
dàng. Thông thường rủi ro xuất hiện từ các nguồn sau:
• Ngân sách/nguồn tài trợ cho dự án
• Thời gian thực hiện dự án
• Thay đổi về phạm vi và yêu cầu dự án
• Khó khăn về kỹ thuật
• Vấn đề liên quan đến nhân lực
• Hợp đồng giữa 2 (hoặc nhiều) bên • Trong kinh doanh
• Môi trường, luật pháp, chính trị, văn hóa...
Để nhận diện được rủi ro, có nhiều kỹ thuật được áp dụng. Các kỹ thuật này giúp cho
dự án “khoanh vùng” và xác định dấu hiệu xuất hiện rủi ro, vừa giúp tránh bỏ sót các dấu
hiệu, vừa làm tăng kết quả và độ tin cậy của việc nhận diện các rủi ro. Từng kỹ thuật đều có
những hạn chế riêng, do đó việc kết hợp các kỹ thuật để có kết quả tốt nhất là cần thiết. Các
kỹ thuật được sử dụng rộng rãi bao gồm:
- Xem xét tài liệu: Là cách thức xác định rủi ro cơ bản, đơn giản và thông dụng.
Phương thức này thường bao gồm việc xem xét các tài liệu của dự án như các kế hoạch, giả 54
định, cam kết với khách hàng, cơ chế thông tin giữa 2 bên, môi trường dự án, thông tin của
các dự án khác trong quá khứ..., từ đó nhận diện các yếu tố có khả năng gây ra rủi ro cho dự án.
- Động não: Đây là kỹ thuật được sử dụng rộng rãi nhất để nhận diện rủi ro và hầu
như bất cứ ai trong đời cũng đã từng sử dụng kỹ thuật này cho nhiều vấn đề khác nhau trong
cuộc sống. Đó là sự đóng góp ý kiến từ nhiều người khác nhau, từ các chuyên gia đến các
thành viên của dự án, hoặc bất cứ ai có liên quan hoặc có kinh nghiệm về các vấn đề xảy ra
trong dự án. Từ những ý kiến này (có thể nhiều ý trùng nhau), các rủi ro sẽ được định vị nhanh chóng.
- Kỹ thuật Delphi: Tương tự kỹ thuật "Động não", khác biệt chỉ là các thành viên tham
gia không biết nhau, do đó kỹ thuật này thích hợp nếu các thành viên ở xa nhau. Ngày nay kỹ thuật
Delphi thực hiện dễ hơn trước đây do sự trợ giúp của email và hệ thống hỗ trợ làm việc từ xa. Do
thành viên là “vô danh” nên kỹ thuật này hạn chế nhược điểm của kỹ thuật "Động não" là một vài
cá nhân (chẳng hạn sếp) sẽ có ảnh hưởng đến suy nghĩ của các thành viên khác.
Hình 2: Mối quan hệ và trình tự các bước trong quy trình kiểm soát rủi ro
- Nhóm danh nghĩa: Nhóm làm việc từ 7-10 người, mỗi thành viên sẽ ghi ý kiến
riêng của mình (thường là 1 rủi ro quan trọng nhất) trên 1 mẫu giấy. Các ý kiến sau đó được
tập hợp và nhóm sẽ phân tích và đánh giá trên từng ý kiến. Kết quả là rủi ro quan trọng nhất
được sắp xếp trên cùng. Kỹ thuật này không chỉ dùng để nhận biết mà còn để đánh giá rủi
ro; không loại bỏ hoàn toàn những người có ảnh hưởng; được thực hiện nhanh và ít tốn kém hơn kỹ thuật Delphi
- Hỏi ý kiến chuyên gia: Thường được dùng để hỏi ý kiến cá nhân của những người
có nhiều kinh nghiệm từ các dự án tương tự hoặc các dự án đã hoàn thành trong quá khứ.
Công cụ sử dụng thường là bảng câu hỏi có trả lời sẵn để chọn lựa, hoặc để trống cho người
được hỏi tự ghi ý kiến hoặc trả lời.
- Sử dụng phiếu kiểm tra hoặc bảng câu hỏi: Phiếu kiểm tra hoặc bảng câu hỏi
thường đúc kết kinh nghiệm từ các dự án quá khứ đặc biệt và các dự án tương tự, trong đó 55
liệt kê những rủi ro thường hay gặp nhất. Phiếu này giúp cho dự án nhanh chóng xác định
rủi ro có thể xảy đến cho dự án.
Kỹ thuật này có thể tham khảo các kinh nghiệm từ bên ngoài, một trong những tham
khảo tốt theo cách này là sử dụng bảng phân loại và liệt kê các rủi ro thường gặp của viện
Kỹ thuật Phần mềm Hoa Kỳ (SEI Taxonomy-Based Risk Identification) có thể tải về miễn
phí tại http://www.sei.cmu.edu/publications/documents/93.reports/93.tr.006.html.
- Sử dụng biểu đồ: Sử dụng nhiều dạng biểu đồ khác nhau để phân tích và xác định
rủi ro, chẳng hạn biểu đồ xương cá (còn gọi là biểu đồ nhân quả) được sử dụng để chỉ sự
liên quan và ảnh hưởng của các yếu tố rủi ro khác nhau, từ đó xác định rủi ro có thể ảnh
hưởng đến dự án. Biểu đồ quy trình cho thấy sự nối tiếp trong chuỗi các sự kiện, từ đó xác
định các yếu tố có thể gây rủi ro cho dự án. Hình 3 là một ví dụ về việc sử dụng biểu đồ
xương cá để định vị các rủi ro.
* Phân tích và phân loại rủi ro
Trong thực tế, những rủi ro có thể xảy ra trong một dự án là khá nhiều, và việc giải
quyết hết tất cả các rủi ro là không cần thiết, cũng như sẽ làm phá sản ngân sách của dự án.
Thông thường người ta áp dụng nguyên tắc 20/80 để xác định và giải quyết những rủi
ro quan trọng, những nguyên nhân gốc có ảnh hưởng lớn nhất đến sự thành công của dự án,
trong chừng mực cân nhắc cẩn thận ngân sách dự án cũng như một số yếu tố đặc biệt khác.
Điều này dẫn đến việc dự án phải phân tích để chọn ra những rủi ro cần giải quyết đó. Có
nhiều kỹ thuật phân tích rủi ro được sử dụng, kỹ thuật thường được sử dụng bao gồm các phân tích chính sau:
- Phân tích khả năng xuất hiện của rủi ro: Có 4 mức để đo lường khả năng xuất
hiện của rủi ro, mỗi mức độ được gán với một giá trị số (tùy dự án) để có thể ước lượng sự quan trọng của nó.
• 6 - Thường xuyên: Khả năng xuất hiện rủi ro rất cao, xuất hiện trong hầu hết dự án
• 4 - Hay xảy ra: Khả năng xuất hiện rủi ro cao, xuất hiện trong nhiều dự án
• 2 - Đôi khi: Khả năng xuất hiện rủi ro trung bình, chỉ xuất hiện ở một số ít dự án
• 1 - Hiếm khi: Khả năng xuất hiện thấp, chỉ xuất hiện trong những điều kiện nhất định.
Hình 3: Ví dụ đơn giản dùng sơ đồ xương cá định vị rủi ro
- Phân tích mức tác động của rủi ro: Có 4 mức để đo lường mức tác động của rủi
ro, mỗi mức độ được gán với một giá trị số (tùy dự án) để có thể ước lượng sự tác động của nó.
• 8 - Trầm trọng: Có khả năng rất cao làm dự án thất bại 56
• 6 - Quan trọng: Gây khó khăn lớn và làm dự án không đạt được các mục tiêu
• 2 - Vừa phải: Gây khó khăn cho dự án, ảnh hưởng việc đạt các mục tiêu của dự án
• 1 - Không đáng kể: Gây khó khăn không đáng kể.
- Phân tích thời điểm xuất hiện rủi ro: Có 4 mức để ước lượng thời điểm rủi ro
xuất hiện, mỗi mức được gán với một giá trị số (tùy dự án) để có thể ước lượng sự tác động của nó.
• 6 - Ngay lập tức: Rủi ro xuất hiện gần như tức khắc
• 4 - Rất gần: Rủi ro sẽ xuất hiện trong thời điểm rất gần thời điểm phân tích
• 2 - Sắp xảy ra: Rủi ro sẽ xuất hiện trong tương lai gần
• 1 - Rất lâu: Rủi ro sẽ xuất hiện trong tương lai xa hoặc chưa định được.
• Ghi chú: Các giá trị số cho trên chỉ mang tính tham khảo và minh họa, giá trị của
chúng được định tùy tổ chức, tùy dự án.
- Ước lượng và phân hạng các rủi ro: Rủi ro sau đó được tính giá trị để ước lượng
bằng công thức: Risk Exposure = Risk Impact * Risk Probability * Time Frame
Tiếp theo rủi ro được phân hạng từ cao đến thấp dựa theo các giá trị Risk Exposure
tính toán được. Tùy theo tổ chức và đặc thù từng dự án, trưởng dự án (hoặc người được
phân công) sẽ xác định những rủi ro nào cần đưa vào kiểm soát, với các mức ưu tiên khác nhau. * Kiểm soát rủi ro
Kiểm soát rủi ro bắt đầu với việc chọn lựa chiến lược và phương pháp đối phó rủi ro.
Có nhiều chiến lược và phương pháp đối phó khác nhau, tùy theo tình huống dự án, môi
trường và đặc thù của từng rủi ro. Trong thực tế, các chiến lược phổ biến nhất bao gồm (Hình 4):
- Tránh né: Dùng “đường đi khác” để né tránh rủi ro, đường đi mới có thể không có
rủi ro, có rủi ro nhẹ hơn, hoặc chi phí đối phó rủi ro thấp hơn. Chẳng hạn:
• Thay đổi phương pháp, công cụ thực hiện, thay đổi con người
• Thương lượng với khách hàng (hoặc nội bộ) để thay đổi mục tiêu.
- Chuyển giao: Giảm thiểu rủi ro bằng cách chia sẻ tác hại khi chúng xảy ra. Chẳng hạn:
• Đề nghị với khách hàng chấp nhận và chia sẻ rủi ro (tăng thời gian, chi phí...)
• Báo cáo ban lãnh đạo để chấp nhận tác động và chi phí đối phó rủi ro
• Mua bảo hiểm để chia sẻ chi phí khi rủi ro xảy ra. 57
Hình 4: Một số chiến lược và minh họa các phương pháp đối phó rủi ro thường gặp
- Giảm nhẹ: Thực thi các biện pháp để giảm thiểu khả năng xảy ra rủi ro hoặc giảm
thiểu tác động và chi phí khắc phục rủi ro nếu nó xảy ra. Chẳng hạn:
• Cảnh báo và triệt tiêu các yếu tố làm cho rủi ro xuất hiện
• Điều chỉnh các yếu tố có liên quan theo dây chuyền để rủi ro xảy ra sẽ ít có tác động
- Chấp nhận: Đành chấp nhận “sống chung” với rủi ro trong trường hợp chi phí loại
bỏ, phòng tránh, làm nhẹ rủi ro quá lớn (lớn hơn chi phí khắc phục tác hại), hoặc tác hại của
rủi ro nếu xảy ra là nhỏ hay cực kỳ thấp. Kế hoạch đối phó có thể là:
• Thu thập hoặc mua thông tin để có kế hoạch kiểm soát tốt hơn
• Lập kế hoạch khắc phục tác hại khi rủi ro xảy ra.
Hình 5: Minh họa Cây quyết định cho trường hợp đơn giản
- Sử dụng Cây quyết định
Trong một số trường hợp phức tạp, thường rất khó xác định rủi ro nào nên đặt ưu tiên
cao để kiểm soát, hoặc nên chọn chiến lược kiểm soát nào phù hợp nhất nên người ta
thường sử dụng kỹ thuật hỗ trợ ra quyết định thông dụng trong quản lý là Cây quyết định để
tính toán giá trị đạt được hoặc thiệt hại xảy ra khi thực hiện một hành động nào đó.
Cây quyết định là một biểu đồ dạng cây có nhiều nút, mỗi nút có nhiều nhánh rẽ, mỗi
nhánh sẽ trả lời câu hỏi “làm” hay “không làm”, hoặc là một khả năng để một tình huống
xuất hiện với một xác suất nào đó. Các giá trị cuối cùng của các nhánh sẽ giúp xác định xem
nên chọn phương án nào cho giá trị tốt nhất. Hình 5 là một Cây quyết định đơn giản để tính
toán giá trị đạt được theo các phương án khác nhau, giúp chọn lựa phương án tốt nhất, theo
đó phương án Y cuối cùng đã được chọn do giá trị trả về là lớn nhất. 58
* Giám sát và điều chỉnh
Bao gồm hoạt động giám sát để bảo đảm các chiến lược đối phó rủi ro được lên kế
hoạch và thực thi chặt chẽ. Việc giám sát cũng nhằm mục đích điều chỉnh các chiến lược
hoặc kế hoạch đối phó nếu chúng tỏ ra không hiệu quả, không khả thi, ngốn quá nhiều ngân
sách, hoặc để đáp ứng với rủi ro mới xuất hiện, hoặc sự biến tướng của rủi ro đã được nhận diện trước đó.
Kết quả giám sát có thể được báo cáo định kỳ đến tất cả những người có liên quan,
đến quản lý cấp cao, hoặc đến khách hàng nếu cần thiết.
Trong thực tế, do các yếu tố liên quan đến dự án thay đổi liên tục, chu trình quản lý
rủi ro không đi theo đường thẳng mà được lặp lại và điều chỉnh liên tục giữa các chặng. Các
rủi ro liên tục được điều chỉnh hoặc nhận diện mới, do đó các chiến lược và kế hoạch đối
phó cũng luôn được thay đổi để bảo đảm chúng khả thi và có hiệu quả. * Kết luận
Rủi ro là một yếu tố tồn tại trong mọi dự án phần mềm. Một người quản trị dự án giỏi
phải là người không ngạc nhiên và có khả năng xử lý bất kỳ sự kiện nào xảy ra có thể gây
bất lợi cho dự án, điều đó đồng nghĩa với việc các rủi ro ảnh hưởng đến dự án phải được
“thấy trước”, cùng với các kế hoạch để giảm thiểu khả năng xuất hiện cũng như tác hại khi
chúng xuất hiện. Quy trình kiểm soát chặt chẽ, kinh nghiệm chuyên gia kết hợp với kỹ thuật
nhận diện và kiểm soát rủi ro là những yếu tố quan trọng nhất để kiểm soát tốt rủi ro xảy ra trong dự án.
3.3.4. Quản lý thay đổi
Quản lý thay đổi là việc lập kế hoạch giống như giới hạn cho những tiến trình lặp lại.
Theo dõi thay đổi trong những hiện tượng giả kỹ thuật là cốt yếu để hiểu được xu hướng
phát triển công nghệ thật sự và xu hướng chất lượng tiến tới đưa ra một sản phẩm cuối cùng
được thừa nhận hay phát hành tạm thời. Trong những quy trình quản lý phần mềm thông
thường, những kỹ thuật quản lý cấu hình giới hạn cho những hiện tượng giả kỹ thuật là hoạt
động sau này chiếm ưu thế vòng đời. Trong một quy trình quản lý hiện đại, trong đó những
yêu cầu và các bộ tạo tác thực hiệnsớm đạt được những yêu cầu khắt khe trong vòng đời và
phát triển qua nhiều thế hệ - quản lý thay đổi đã trở nên cơ bản đối với tất cả các giai đoạn
và hầu như tất cả các hoạt động.
Những thứ tự của sự thay đổi phần mềm(software change order)
Những đơn vị nguyên tử của công việc phần mềm được phép phát sinh, thay đổi hoặc
bỏ đi các thành phần trong một giới hạn cấu hình được gọi là thứ tự thay đổi phần mềm
(SCO). Những thứ tự thay đổi phần mềm là một cơ chế cho việc phân hoạch, cấp phát, lập
lịch công việc phần mềm ngược lại một giới hạn phần mềm đã được thiết lập và để đánh
giá sự tiến bộ và đánh giá chất lượng. Bằng cách vào dữ liệu tự động và khả năng duy trì
những bản ghi thay đổi một cách trực tuyến, việc bộ máy quản lý thay đổi kết hợp với các
độ đo báo cáo những hoạt động cũng có thể được tự động hoá.
Mức độ mà tại đó một SCO được viết vẫn luôn luôn là một vấn đề. Một sự thay đổi
riêng biệt là gì? Có phải là sự thay đổi một đơn vị chương trình hay thay đổi một thành 59
phần, một file, một hệ thống con? Có phải là một tính chất mới, một sự khắc phục khuyết
điểm, hay một sự nâng cấp thực hiện? Trong hầu hết các dự án, đơn vị nguyên tử của SCO
có xu hướng dễ dàng được chấp nhận. Một cách tổng quát, một SCO nên được viết ngược
lại một thành phần đơn do đó nó dễ dàng được cấp phát cho một cá thể đơn. Nếu một
quyết định yêu cầu hai người trong hai đội khác nhau thì hai SCO riêng biệt nên được viết.
Những trường cơ bản của SCO là tiêu đề, phần mô tả, các ma trận, những quyết định,
sự đánh giá và sự sắp xếp.
• Tiêu đề (title): Tiêu đề được đề xuất bởi người sáng tạo và được hoàn thành nhờ
vào sự chấp nhận của bảng kiểm soát cấu hình (CCB)Trường này nên bao gồm một sự tham
khảo một bản báo cáo vấn đề phần mềm bên ngoài nếu sự thay đổi được đưa ra bởi người
ngoài (ví dụ như người sử dụng)
• Phần mô tả (description): Phần mô tả các vấn đề bao gồm tên của người sáng tạo,
ngày phát minh, bộ chỉ định SCO được gán CCB, và bộ các chỉ định phiên bản liên quan
của phần mềm hỗ trợ. Phần miêu tả những vấn đề nguyên bản nên cung cấp chi tiết nhất có
thể những trích dẫn mã gắn vào, in màn hình hiển thị, thông báo lỗi và bất kỳ dữ liệu nào
khác có thể giúp tách vấn đề hoặc miêu tả việc thay đổi cần thiết.
• Độ đo (metric): Những độ đo đã tập hợp cho mỗi SCO là quan trọng cho việc lập
kế hoạch, lập lịch trình, và cho việc đánh giá cải tiến chất lượng. Những hạng mục thay đổi
là loại 0(lỗi giới hạn), loại 1(lỗi), loại 2(nâng cao), loại 3(đặc tính mới) và loại 4(những cái
khác), như sẽ được miêu tả sau trong phần này. Nhờ vào sự chấp nhận của SCO, những
đánh giá ban đầu được tạo thành bởi một số đứt đoạn(breakage) và yêu cầu nỗ lực để giả
quyết vấn đề. Mục đứt đoạn xác định số lượng thay đổi và mục làm lại(rework) xác định độ
phức tạp của sự thay đổi. Mục phân tích xác định số giờ cần thiết để hiểu những thay đổi
yêu cầu (phát minh lại, cách ly, và phát hiện lỗi vấn đề nếu thay đổi là loại 0 hoặc 1). Mục
thi hành xác định số giờ cần thiết để thiết kế và thi hành quyết định. Mục thử xác định số
giờ sử đụng để thử nghiệm quyết định, và mục tài liệu xác định tất cả sự nỗ lực bỏ ra để cập
nhật những hiện tượng giả khác ví dụ như sách hướng dẫn người sử dụng hoặc phần mô tả
phiên bản.Sự đứt đoạn xác định phạm vi của thay đổi và có thể được định nghĩa trong
những đơn vị của SLOC, những điểm hàm, các file, các thành phần hay các lớp. Trong
trường hợp của SLOC, một chương trình so sánh file nguồn xác định những khác biệt có thể
cung cấp một sự đánh giá của sự đứt đoạn. Nói chung, sự chính xác của số đứt đoạn là
tương đối không quan trọng. Những thay đổi giữa 0 và 100 dòng có thể lấy chính xác bằng
10, những thay đổi giữa 100 và 1000 lấy là 100 và cứ như vậy.
• Quyết định(resolution): Trường này bao gồm tên của những người có trách nhiệm
trong việc thi hiện những thay đổi, những thành phần thay đổi, những ma trận thực sự và
một phần mô tả của sự thay đổi. Mặc dù sự đúng đắn mức của các thành phần với một dự án
theo dõi những liên quan thay đổi có thể được mô tả bên ngoài, nói chung, mức thấp nhất
củatham chiếu thành phần nên được giữ tương đối tại một mức của việc cung cấp cho một
cá thể. Một ví dụ, một “thành” phần mà được cung cấp cho một đội không là một tham chiếu đủ chi tiết. 60
• Sự định giá (assessment): Trường này miêu tả kỹ thuật đánh giá như sự kiểm tra,
phân tích, chứng minh hoặc thử. Nơi có thể được ứng dụng cũng nên tham chiếu tất cả các
trường hợp thử nghiệm tồn tại và những trường hợp thử nghiệm mới được thực hiện, và
cũng nên xác định tất cả các cấu hình thử nghiệm khác nhau, ví dụ như các nền, cấu trúc
liên kết và các trình biên dịch.
• Sự xếp đặt (deposition): SCO được gán với một trong những trạng thái sau đây bởi CCB
- Được đề nghị : viết ra, xem xét lại CCB chưa giả quyết
- Được chấp nhận: CCB được chấp nhận cho cách giải quyết
- Bị bác bỏ: đóng với những lý do căn bản ví dụ như không một vấn đề, bản sao, sự
thay đổi quá hạn, giả quyết bỏi SCO khác
- Được lưu trữ: được chấp thuận nhưng bị hoãn lại cho đến khi có một sự đưa ra sau
- Đang tiến hành: đã được phân công và đang được giải quyết bởi một tổ chức phát triển.
- Đang đánh giá: đã được giải quyết bởi một tổ chức phát triển; đang được đánh giá
bởi một tổ chức thử nghiệm
- Đóng: được giải quyết hoàn chỉnh với sự hợp tác của tất cả bộ phận CCB
Một bộ phận chỉ định quyền ưu tiên và nhả ra cũng có thể được phân công bởi CCB
để hướng dẫn .. và cách tổ chức của các hoạt động phát triển hiện tại. 61
Ranh giới cấu hình(configuration baseline)
Một ranh giới cấu hình là một bộ tên của các thaành phần phần mềm và những tài
liệu hỗ trợ là chủ thể để quản lý sự thay đổi và được nâng cấp, duy trì, thử nghiệm, như là
một đơn vị. Với những hệ thống quản lý cấu hình phức tạp, có nhiều tiêu chuẩn phạm vi dặc
biệt và dự án đặc biệt.
Nói chung có hai lớp của ranh giới: phiên bản sản phẩm ngoài và phiên bản kiểm tra
trong. Một ranh giới cấu hình là một tập tên của các thành phần được coi như là một đơn vị.
Nó đuợc quản lý một cách chính thức bởi vì nó sự trao đổi được đóng gói giữa các nhóm.
Một ví dụ, tổ chức phát triển có thể đưa ra một ranh giới cấu hình cho tổ chức kiểm tra hoặc
thậm chí là cho bản thân tổ chức đó. Một dự án có thể đưa ra một ranh giới cấu hình cho
người sử dụng để kiểm tra. 62
Nói chung, ba mức của ranh giới đưa ra là yêu cầu cho mọi hệ thống: lớn, nhỏ và tạm
thời. Mỗi mức tương ứng với một từ định danh ví dụ như N, M, X, trong đó N là lớn, M là
nhỏ và X là từ định danh cho mức tạm thời. Một phiên bản chính biểu diễn một thế hệ mới
của sản phẩm hay dự án, trong khi một phiên bảm phụ biểu diễn cùng một sản phẩm cơ sở
nhưng với những đặc điểm, hiệu suất, chất lượng được đề cao. Phiên bản chính và phụ được
dùng như các phiên bản sản phẩm bên ngoài mà liên tục và được hỗ trợ trong một thời kỳ.
Một phiên bản trong lúc chờ đọi tương ứng với một cấu hình tiến triển được dùng tạm thời.
Vòng đời của nó càng ngắn càng tốt. Hình 12-4 chỉ ra một ví dụ của một số tên phiên bản
cho hai trường hợp khác nhau.
Một khi phần mềm được thiết lập trong ranh giới kiểm soát, tất cả sự thay đổi được
theo dõi. Sự khác biệt chỉ là nguyên nhân của một sự thay đổi. Những loại thay đổi giống như sau:
• Loại 0: thiếu khả năng tới hạn, đó là những thiếu sót gần như luôn luôn được sửa
chữa trước bất ky một phiên bản ngoài .Nói chung, loại của các thay đổi được biểu diễn
showstopper có một sự ảnh hưởng lên khả năng sử dụng của phần mềm trong những trường
hợp sử dụng tới hạn của nó.
• Loại 1: Một con bọ hay một thiếu sót không làm giảm khả năng sử dụng của hệ
thống hoặc có thể bị vòng. Những lỗi như vậy có thể gây ra phiền toái trong những trường
hợp sử dụng tới hạn hoặc những lỗi nghiêm trọng trong những trường hợp sử dụng phụ là
những trường hợp có khả năng xuất hiện thấp.
• Loại 2: Một sự thay đổi mà là một cách làm nổi bật hơn là một hỏng hóc. Mục
đích của nó là cải thiện hiệu suất, khả năng thử nghiệm, khả năng sử dụng hoặc những mặt
khác của chất lượng mà là một điển hình của kỹ thuật tốt.
• Loại 3: Một sự thay đổi cấn có để cập nhật những yêu cầu. Đây có thể là những
khả năng và tính chất mới nằm ngoài phạm vi của phiên bản và giao dịch hiện tại 63
• Loại 4: Một thay đổi chưa được dàn xếp giữa các hạng mục. Những ví dụ chỉ gồm
có tài liệu hoặc những phiên bản nâng cấp cho các thành phần thương mại.
Bảng kiểm soát cấu hình(Confirguration control board)
Một CCB là một đội cán bộ mà chức năng như là có quyền quyết định chấp nhận
những ranh giới cấu hình. Một CCB thường bao gồm giám đốc phần mềm, giám đóc thiết
kế phần mềm, giám đốc phát triển phần mềm, giám đốc định giá phần mềm và những
người khác (khách hàng, giám đốc dự án phần mềm, kỹ sư hệ thống, người sử dụng) đó là
những người được kết hợp để sự duy trì một hệ thống phân phối kiểm phần mềm kiểm
soát.Trong khi các CCB hoạt động qua trao đổi bảng, sự phân phối trực tuyến, hiện tại, và
sự chấp thuận của hoạt động CCB có thể tạo ra khả năng đánh giá dưới rất nhiều thực trạng dự án.
Khái niệm hoạt động của một tiến trình phát triển lặp lại phải bao gồm quản lý sự
thay đổi chặt chẽ và mang tính toàn diện của những ranh giới phần mềm mở ra. Tiến trình
cơ bản cho việc kiểm soát sự phát triển phần mềm và duy trì những hoạt động được mô tả
thông qua một dãy các trạng thái được duyệt bởi một SCO. Những từ (trong ngoặc) tạo
thành các trạng thái của một SCO chuyển tiếp qua một quá trình.
• [Được đề nghị(propose)]. Một sự thay đổi được đề nghị được phác thảo và CCB
chấp nhận. Sự thay đổi được đề nghị phải bao gồm một phần miêu tả kỹ thuật của vấn đề và
đánh giá hiệu quả của quyết định.
• [Được chấp thuận, được hoàn thành hay bị loại bỏ]. CCB phân một bộ chỉ định
duy nhất và chấp thuận, hoàn thành hay loại bỏ mỗi sự thay đổi được đề nghị. Sự chấp thuận
bao gồm sự thay đổi của quyết định trong phiên bản tương lai; và sự loại bỏ với những sự
thay đổi được đề nghị khác hoặc nằm ngoài phạm vi. CCB kiểm tra tất cả các trường SCO
cho phù hợp và chính xác trước khi chấp nhận SCO, sau đó phân SCO cho một người có
trách nhiệm trong sự tổ chức phát triển cho quyết định.
• [Trong tiến trình]. Người có trách nhiệm phân tích, thực hiện và kiểm tra một giải
pháp phù hợp với SCO. Nhiệm vụ này bao gồm cập nhật tài liệu, đưa ra chú thích, và ma 64
trận SCO thật sự, và chấp nhận những SCO mới, nếu cần thiết. Thông quan hoàn thành một
giải pháp hoàn chỉnh, người có trách nhiệm hoàn thành bộ phận quyết định của SCO và đưa
cho đội thử nghiệm độc lập để định giá.
• [Trong định giá]. Đội thử nghiệm độc lập đánh giá nếu SCO được giải quyết hoàn
toàn. Khi đội thử nghiệm độc lập nghĩ rằng sự thay đổi được giải quyết ổn thoả, SCO được
đưa tới cho CCB để sắp xếp và đóng gói cuối cùng.
• [Đóng] Khi tổ chức phát triển, tổ chức thử nghiệm độc lập và CCB tán thành rằng
SCO đã được giải quyết, nó sẽ chuyển sang tình trạng đóng.
3.3.5. Quản lý chất lượng
a. Quản lý chất lượng là gì?
Lâu nay, nói đến chất lượng phần mềm (PM), không ít người nghĩ ngay đến vấn đề là
xác định xem PM đó có phát sinh lỗi hay không, có "chạy" đúng như yêu cầu hay không và
cuối cùng thường quy về vai trò của hoạt động kiểm tra phần mềm (testing) như là hoạt
động chịu trách nhiệm chính.
Với quan điểm của khách hàng, điều này có thể đúng, họ không cần quan tâm nội
tình của hoạt động phát triển PM, điều họ cần quan tâm là liệu sản phẩm cuối cùng giao cho
họ có đúng hạn hay không và làm việc đúng như họ muốn hay không.
Tuy nhiên theo quan điểm của người phát triển PM, thực
tế cho thấy hoạt động kiểm tra PM là quan trọng, nhưng không
đủ để đảm bảo sản phẩm sẽ được hoàn thành đúng hạn và đúng
yêu cầu. Kiểm tra sau cùng để phát hiện lỗi là điều tất nhiên phải
làm, nhưng trong rất nhiều trường hợp, điều đó thường quá trễ và
sẽ phải mất rất nhiều thời gian để sửa chữa.
Thực tế cho thấy, để đảm bảo được hai tiêu chí "đơn giản" trên
của khách hàng, đòi hỏi tổ chức không chỉ vận hành tốt khâu Hình 1: Các mối
kiểm tra PM, mà phải tổ chức và duy trì sự hoạt động nhịp nhàng quan hệ.
của cả một hệ thống các công việc liên quan đến một dự án PM, từ đây xuất hiện một khái
niệm có tên là "hệ thống quản lý chất lượng phần mềm" (HTQLCLPM), bao gồm các quy
trình được thực thi xuyên suốt chu kỳ phát triển của dự án PM.
Hiện có nhiều mô hình cung cấp các tiêu chuẩn cũng như hướng dẫn để triển khai
HTQLCLPM. Hai trong số những mô hình được áp dụng rộng rãi hiện nay là ISO 9001-
2000 và CMM/CMMi. Trong khi ISO 9001-2000 là tiêu chuẩn quản lý chất lượng dành cho
tất cả các ngành nghề với những điều khoản ngắn gọn và mang tính tổng quát, thì
CMM/CMMi là một bộ tập hợp khá đồ sộ các kinh nghiệm thực hành (gần 450 trang với
CMM, và gần 700 trang với CMMi) có thể làm người đọc chưa có kinh nghiệm khó biết
được các hoạt động và yếu tố đặc trưng cơ bản của HTQLCLPM là gì.
Qua một số tài liệu tham khảo, cũng như bằng kinh nghiệm bản thân khi nghiên cứu
và ứng dụng ISO 9001-2000 và CMM/CMMi, chúng tôi sẽ trình bày các khái niệm, hoạt
động cũng như yếu tố cơ bản cấu thành HTQLCLPM. b. HTQLCLPM 65
Một HTQLCLPM thường có 2 mục tiêu (hình 1):
• Mục tiêu thứ nhất: xây dựng chất lượng cho PM ngay từ giai đoạn bắt đầu. Điều
này đồng nghĩa với việc bảo đảm các yêu cầu cho PM từ mọi nguồn khác nhau phải được
định nghĩa, diễn đạt và hiểu một cách đúng đắn, giữa người đưa ra yêu cầu và người thực hiện yêu cầu.
• Mục tiêu thứ hai: bảo đảm chất lượng của PM xuyên suốt quá trình phát triển.
Một HTQLCLPM hoàn chỉnh bao gồm rất nhiều hoạt động và bộ phận cấu thành,
chúng khác nhau tùy theo từng tổ chức khi triển khai. Tuy nhiên, theo kinh nghiệm, chúng
tôi chỉ giới thiệu 10 hoạt động và yếu tố cơ bản nhất thường gặp:
1. Các tiêu chuẩn (Standards)
2. Lập kế hoạch (Planning)
3. Xem xét, xem lại (Reviewing) 4. Kiểm tra (Testing)
5. Phân tích lỗi (Defect analysis)
6. Quản lý cấu hình (Configuration Management) 7. Bảo mật (Security)
8. Đào tạo, huấn luyện (Education/Training)
9. Quản lý người cung cấp, thầu phụ (Vendor Management)
10. Quản lý rủi ro (Risk Management)
(Để đơn giản, từ đây, "10 hoạt động và yếu tố" được gọi tắt là "10 yếu tố")
Có mối liên hệ giữa 10 yếu tố cơ bản trên và các giai đoạn hay pha phát triển PM.
Hình 2 cho thấy sơ đồ liên hệ trong mô hình phát trình waterfall (xem bài "Tổng quan các
mô hình phát triển phần mềm", ID: A0508_106 và A0510_122). Ký hiệu "x" giao nhau giữa
một yếu tố và một pha biểu thị yếu tố được thực hiện tại pha đó. Phần sau đây sẽ làm rõ ý
nghĩa của 10 yếu tố cơ bản. * Các tiêu chuẩn
Sản xuất PM ngày nay không còn đơn thuần mang tính sáng tạo ngẫu hứng như trước
đây, mà đang trở thành một lĩnh vực được kiểm soát chặt chẽ, theo những tiêu chuẩn nhất
định. Các tiêu chuẩn có thể là các kinh nghiệm hoặc các phương pháp hiệu quả nhất, được
đề xuất từ các hiệp hội nghề nghiệp như IEEE (The Institute of Electrical and Electronics
Engineers, Inc – Học viện các kỹ sư điện và điện tử), từ các tổ chức quốc tế như ISO
(International Organization for Standardization), hoặc các quy tắc chuẩn hóa để giao tiếp
giữa sản phẩm với nhau... hoặc đơn giản do chính tổ chức phát triển PM đề ra để áp dụng cho chính họ.
Các tiêu chuẩn có thể bao gồm tất cả các khía cạnh của một chu kỳ phát triển PM,
trải dài suốt mọi pha phát triển. Bất kể tiêu chuẩn xuất phát từ đâu, từ nội bộ công ty, hoặc
từ ngoài, nó đều phải có một số đặc điểm sau: • Tính cần thiết 66 • Tính khả thi
• Tính đo lường được
Các tiêu chuẩn nên được chọn và thể hiện sao cho khi sử dụng, các khía cạnh kỹ
thuật cần thiết sẽ được nhấn mạnh, tránh trường hợp hiểu sai hoặc sa vào những tiểu tiết phụ
trợ. Một ví dụ thường thấy là tiêu chuẩn định dạng cho tài liệu, mục đích của tiêu chuẩn là
để bảo đảm khía cạnh chất lượng về kỹ thuật của tài liệu. Tuy nhiên, trong rất nhiều trường
hợp tiêu chuẩn đã bị hiểu sai và sa đà vào việc kiểm tra các chi tiết về mặt hình thức. Lưu ý
là để bảo đảm các tiêu chuẩn được nghiêm túc thực hiện, chúng phải mang tính bắt buộc và
được quy định ở chính sách cấp công ty.
Một dạng phổ biến bắt buộc phải có của tiêu chuẩn là hệ thống các "quy trình", kèm
theo các bộ phận phụ thuộc như "thủ tục" "hướng dẫn" "mẫu biểu" "tiêu chuẩn" v.v. Tùy
theo lĩnh vực hỗ trợ mà chúng có các tên tương ứng, chẳng hạn: quy trình sản xuất PM, quy
trình kiểm soát chất lượng, quy trình kiểm tra... * Lập kế hoạch
Lập kế hoạch là yêu cầu kinh điển cũng như thao tác cơ bản của hầu hết các
HTQLCLPM. Kết quả của hoạt động này thường là một (hoặc nhiều) tài liệu gọi là bản kế hoạch.
Theo quan điểm quản lý hiện đại, các công việc gắn liền với những mục tiêu, ngắn
hạn hoặc dài hạn, đều có thể xem như là một dự án hoặc chuỗi các dự án. Kế hoạch cho dự
án thường bao gồm những điểm chính sau:
• Ước lượng phạm vi và kích thước dự án, khối lượng công việc phải làm
• Xác định nhân lực, vật lực và chi phí
• Chỉ định phương pháp, cách tiếp cận để thực thi dự án
• Lập kế hoạch làm việc chi tiết
• Kế hoạch phối hợp và hỗ trợ hoàn thành dự án
Đây là kế hoạch liên quan đến sự tham gia của những người có ảnh hưởng quan trọng
đến sự thành công hay thất bại của dự án (thuật ngữ chuyên môn gọi là stakeholders).
Những người nầy thường bao gồm: trưởng dự án, quản lý cấp cao, khách hàng, ban giám
đốc, thầu phụ, nhà cung cấp. Kế hoạch nầy phải bảo đảm cơ chế để các stakeholders có thể
tham gia vào dự án ở các mức độ và thời điểm mang lại hiệu quả cao nhất.
• Kế hoạch quản lý cấu hình và quản lý các rủi ro (xem chi tiết phần sau) • Các kế hoạch khác
Tùy theo nhu cầu cho từng dự án, có thể có nhiều kế hoạch khác, cả về quản lý hoặc
kỹ thuật, một số kế hoạch thường gặp chẳng hạn: Kế hoạch kiểm tra, kế hoạch tích hợp sản
phẩm, kế hoạch huấn luyện...
• Tài liệu hóa và cập nhật (khi cần) các bản kế hoạch cho dự án
Lưu ý là các tài liệu kế hoạch của dự án không phải bất di bất dịch, nó phải được cập
nhật thậm chí thay đổi xuyên suốt dự án khi yêu cầu của dự án thay đổi. * Xem xét, xem lại 67
Mục đích là để cung cấp thông tin trực quan về tình trạng của các hoạt động xảy ra
trong suốt quá trình sản xuất và cài đặt PM.
Xem xét trên sản phẩm – thường được gọi là xem xét kỹ thuật – bao gồm hai loại:
chính thức hoặc không chính thức. Xem xét không chính thức thường được thực hiện trong
quá trình phát triển sản phẩm, còn xem xét chính thức thường được thực hiện tại thời điểm
kết thúc các chặng phát triển.
Điểm khác nhau chính về mặt kỹ thuật giữa xem xét chính thức và không chính thức
là ở mức độ nghiêm ngặt của quy trình và các bước thực hiện. Chẳng hạn, xem xét chính
thức buộc phải lên kế hoạch, ghi nhận tất cả các lỗi phát hiện và giám sát đến khi tất cả lỗi
đã được sửa chữa, xem xét không chính thức thì không bắt buộc.
Trong thực tế, có khá nhiều định nghĩa và nhiều loại xem xét khác nhau. Về tổng
quan, IEEE định nghĩa có ba loại:
• Review: Cuộc họp chính thức nhằm trình bày một vấn đề, một tài liệu, một sản
phẩm... cho những người quan tâm, người sử dụng, khách hàng... nhằm thu thập ý kiến phản
hồi hoặc đạt được sự thỏa thuận phê chuẩn trên vấn đề, tài liệu hoặc sản phẩm được trình bày.
• Walkthrough: Kỹ thuật đánh giá không chính thức, qua đó tác giả của một tài liệu,
sản phẩm... giải thích tài liệu, sản phẩm đó cho một nhóm đồng nghiệp. Các đồng nghiệp
này sẽ đặt câu hỏi hoặc cho ý kiến bổ sung về một số lĩnh vực để bảo đảm chất lượng kỹ
thuật của tài liệu hoặc sản phẩm.
• Inspection: Kỹ thuật đánh giá chính thức, qua đó tài liệu, sản phẩm... được những
người không phải là tác giả hoặc trực tiếp liên quan kiểm tra một cách chi tiết để phát hiện
lỗi, các vi phạm tiêu chuẩn, hoặc các vấn đề khác (nếu có). Về cơ bản, nó được tổ chức và
thực hiện chặt chẽ hơn walkthrough. Vai trò của những người tham gia được phân định rõ
ràng. Tài liệu chuẩn bị cho việc xem xét được chuẩn bị trước chu đáo.
Một điểm cần hết sức lưu ý để bảo đảm việc xem xét mang lại hiệu quả là: mục tiêu
chính của việc xem xét nhằm để tìm ra lỗi. Một trong những lý do chính khiến cho rất nhiều
cuộc xem xét không mang lại hiệu quả như mong muốn là các cuộc xem xét đó bị "lún" vào
việc thảo luận các giải pháp để sửa chữa lỗi. Sửa lỗi thường yêu cầu phải có sự phân tích kỹ
lưỡng cũng như phải chấp nhận các phản biện trên các phương pháp sửa lỗi, công việc nầy
hoàn toàn không phù hợp cho một buổi xem xét tìm lỗi. Một khi tìm thấy lỗi, nó nên được
giao cho một/nhóm người phân tích và giải quyết, việc xem xét chỉ nên chú tâm vào việc chỉ ra các sai sót. * Kiểm tra lỗi
Kiểm tra lỗi (testing) là một hoạt động sống còn trong sản xuất PM. Kiểm tra lỗi
nhằm mục đích chứng minh rằng các yêu cầu đối với PM là được thỏa mãn. Các hoạt động
kiểm tra bao gồm các bước: lập kế hoạch, thiết kế test, thi hành test, và báo cáo kết quả kiểm tra. * Phân tích lỗi 68
Trong thực tế, lỗi là phần "luôn hiện diện" trong mọi PM từ giai đoạn phát triển sơ
khởi đến khi nó không còn được sử dụng.
Các tổ chức PM thường dùng thuật ngữ "chất lượng" để chỉ zero, hay một lượng nhỏ
các lỗi trên sản phẩm PM, một số khác lại gắn liền khái niệm "chất lượng" với sự hài lòng
của khách hàng. Trên quan điểm khách hàng, bất kể lúc nào, hễ PM "chạy" không tốt,
không đáp ứng sự mong đợi đều được xem là có lỗi, bất kể do code sai, hoặc do hiểu nhầm
yêu cầu, thậm chí là một chức năng "nên có” nhưng hiện thời chưa sẵn sàng.
Phân tích lỗi được thực hiện trên tất cả lỗi được tìm thấy, nhằm mục đích tìm hiểu
nguyên nhân và xu hướng gây ra lỗi, định hướng cho việc sửa chữa các lỗi hiện hành cũng
như phòng ngừa, triệt tiêu khả năng xảy ra lỗi trong tương lai. Phân tích lỗi là con đường
chính yếu phục vụ cho việc giảm sự xuất hiện lỗi.
Phân tích lỗi không chỉ nhằm mục đích cải thiện tình trạng lỗi của phần mềm đang
xây dựng, xa hơn nó cho ta thấy được những điểm yếu cần cải tiến của quy trình phát triển
PM. Thông tin về lỗi của các dự án trong quá khứ sẽ cho ta thấy được nên cải tiến, thay đổi
quy trình phát triển PM như thế nào để các dự án trong tương lai tránh đi vào "vết xe đổ” của các dự án trước.
Số liệu phục vụ cho việc phân tích lỗi có thể đến từ nhiều nguồn khác nhau. Mỗi tổ
chức tuỳ theo nhu cầu và đặc điểm riêng, tự định nghĩa và thu thập các số liệu nầy.
Lỗi trong quá trình phân tích và sửa chữa có thể được phân loại để có hành động phù
hợp, tuỳ theo các đặc tính khác nhau mà chúng thể hiện.
* Quản lý cấu hình
Mục đích của quản lý cấu hình (QLCH) là để thiết lập và bảo đảm tính toàn vẹn của
các sản phẩm trung gian cũng như các sản phẩm sau cùng của một dự án PM, xuyên suốt
chu kỳ sống của dự án đó.
QLCH bao gồm nhiều hoạt động, tuy nhiên về cơ bản chúng bao gồm bốn hoạt động
chính: nhận dạng (identification), kiểm soát (control), kiểm kê báo cáo (accounting) và kiểm
tra đánh giá (audit). Tùy theo độ lớn và độ phức tạp của dự án, phạm vi và mức độ áp dụng
của các hoạt động QLCH sẽ khác nhau. Với những hệ thống lớn và phức tạp, mỗi hoạt động
QLCH phải do những người được giao trách nhiệm (role) cụ thể phụ trách. Tùy yêu cầu,
một số hoạt động QLCH được làm không chính thức (informal) hoặc chính thức (formal),
nhằm quản lý tốt quá trình phát triển của phần mềm, đặc biệt là quản lý sự thay đổi trong dự án. * Bảo mật
Bảo mật luôn là vấn đề gây nhức nhối vì thường không được nhận thấy cho đến khi
hệ thống bị chọc thủng. Bảo mật có ba khía cạnh chính, bảo mật nội dung dữ liệu, bảo mật
dữ liệu đang được truyền (trên đường truyền) và bảo mật về mặt vật lý của vật chứa dữ liệu.
Các hoạt động bảo mật được áp dụng cho cả nội dung dữ liệu lẫn bản thân vật lý của vật chứa dữ liệu.
Các yếu tố hay nguyên nhân tác động đến dữ liệu hoặc trung tâm dữ liệu của hệ
thống PM rất đa dạng. Đó có thể là tự nhiên hoặc cố ý, chẳng hạn thiên tai, cháy, virus, 69
hacker, phá hoại của chính nhân viên công ty, ăn cắp dữ liệu, thậm chí ngày nay còn do các
hoạt động khủng bố gây ra. Trong một số tổ chức, việc bảo mật dữ liệu lưu trữ và dữ liệu
chuyển dịch được xem là vấn đề sống còn.
Một lý do gây hỏng dữ liệu rất thường gặp là dữ liệu bị thay đổi một cách vô tình
không kiểm soát được. Một khi dữ liệu đã không đúng, điều tất yếu là hệ thống phần mềm
sử dụng dữ liệu đó sẽ cho ra những kết quả sai. Đối với người dùng, đó là một hệ thống
không tốt, thậm chí là không dùng được.
Một hệ thống PM "tốt" phải chú ý tới tất cả những yếu tố có thể ảnh hưởng đến dữ
liệu hoặc hoạt động của hệ thống. Một hệ thống "tốt" còn phải tính đến khả năng phục hồi
dữ liệu, phục hồi hoạt động của hệ thống khi xảy ra sự cố.
* Đào tạo/huấn luyện
Nói đơn giản, huấn luyện nhằm trang bị cho những người phát triển cũng như sử
dụng PM có đủ kiến thức và kỹ năng để thực hiện công việc của họ.
Tất cả mọi biện pháp quản lý, kỹ thuật sản xuất, công cụ hỗ trợ trong sản xuất PM
đều trở nên vô hiệu hoặc có hiệu quả hết sức hạn chế nếu những người tham gia phát triển
và sử dụng PM không đủ kiến thức, kỹ năng cần thiết. Liên quan đến lý do nầy, các tiêu
chuẩn quản lý chất lượng như ISO, CMM/CMMi đều xác lập khả năng, kiến thức và kỹ
năng của những người phát triển PM là một trong những yêu cầu cốt yếu để bảo đảm các
tiêu chí và mục tiêu về chất lượng.
Một khía cạnh khác thường được cho là ít quan trọng nhưng thực ra lại mang tính
quyết định, đó là khả năng hiểu để sử dụng PM của người sử dụng. Người sử dụng thường
chỉ có ý tưởng về yêu cầu đối với PM và không biết sử dụng hoặc sử dụng không đúng cách
làm PM "chạy" sai hoặc không hết chức năng. Do vậy huấn luyện cho người sử dụng cũng
là một khâu hết sức cơ bản. Nhưng thực tế những người phát triển PM lại không có thời
gian và kỹ năng thực hiện tốt việc huấn luyện, việc nầy thường phải do một bộ phận chuyên
trách trong công ty thực hiện.
* Quản lý người cung cấp
Trong các tổ chức PM, mua hay thuê sản phẩm hoặc dịch vụ từ một người cung cấp
thứ ba là rất phổ biến. Việc "mua" có thể bao gồm những mặt hàng đơn giản như máy tính,
máy in, cho đến những dịch vụ thuê gia công PM. Chất lượng của sản phẩm và dịch vụ
"mua" này nếu quản lý không tốt sẽ ảnh hưởng quan trọng đến sản phẩm hoặc dịch vụ của
tổ chức cung cấp cho khách hàng của mình.
Đối tượng sản phẩm hoặc dịch vụ cần mua hay thuê rất đa dạng, tùy mỗi loại và độ
phức tạp, các tổ chức sẽ có những biện pháp và mức độ quản lý chất lượng tương ứng. * Quản lý rủi ro
Rủi ro (risk) là một yếu tố tồn tại trong mọi dự án. Quan niệm về quản trị dự án cho
rằng "người quản trị dự án giỏi là người không ngạc nhiên về các sự kiện xảy ra trong dự
án", điều nầy có nghĩa là mọi rủi ro tiềm ẩn phải được "nhìn thấy" trước, đi đôi với kế hoạch giải quyết. 70
Rủi ro là một sự kiện chưa nhưng có khả năng xảy ra, và khi nó xảy ra thường sẽ đặt
một dự án vào tình huống xấu, hoặc thậm chí là một "tai nạn" cản trở khả năng hoàn thành
các mục tiêu của một dự án.
Hình 3: Mô hình tổ chức truyền thống.
3.4. Phương pháp & công cụ hỗ trợ quản lý
3.4.1. Microsoft Project
Microsoft Project là một chương trình chuyên dùng để quản lý các dự án, là chương
trình có những công cụ mạnh và thuận tiện. Microsoft Project có thể làm việc với nhiều chế
độ, nhiều công cụ, chức năng để thực hiện các thao tác tạo lập và hiệu chỉnh trên dự án đồng
thời tiết kiệm thời gian và tiền bạc.
Mục đích của Microsoft Project 2003 gồm:
 Tổ chức lập kế hoạch và quản lý dự án.  Lên lịch công tác.
 Chỉ định các tài nguyên và chi phí cho các công việc trong dự án.
 Điều chỉnh kế hoạch để thích ứng với các điều kiện ràng buộc.
 Chuẩn bị các báo biểu cần thiết cho dự án.
 Dự trù các tác động đến tiến độ của dự án khi xảy ra những thay đổi có ảnh
hưởng lớn đến dự án.
 Xem xét lại dự án để đối phó với các tình huống ngẫu nhiên.
 Đánh giá tài chính chung của dự án.
 In ấn các báo biểu phục vụ dự án.
 Làm việc và quản lý theo nhóm.
 Rút kinh nghiệm trong khi thực hiện dự án.
Để chạy Microsoft Project 2003 phần cứng tối thiểu của máy tính là:
 Bộ vi xử lý 486 trở lên  16 Mb RAM  Window 9x  Ổ cứng >100 Mb 71
Và cần có các phần mềm sau:
 Phần mềm Microsoft Project 2003  Bộ gõ tiếng Việt
Microsoft Project hỗ trợ các công việc
 Thiết lập một dự án mới
 Nhập các thông tin quan trọng cho dự án
 Thiết lập hệ thống làm việc cho dự án
 nhập và tổ chức các công việc  Tạo mốc dự án
 Thiết lập mối quan hệ giữa các công việc
 Phân công một Calendar đến dự án  …
3.4.2. Microsoft SourceSafe
Source Safe nguyên thủy được sản xuất bởi 1 công ty tên là “One Tree Software” .
Version đầu tiên được phát hành là bản 3.1 , đó là 1 chương trình 16 bit. Microsoft thời
điểm đó cũng có 1 hê ¥ thống quản lý source code yếu hơn là Delta . Năm 1994 , Microsoft
mua lại công ty “One Tree Software” và câ ¥p nhâ ¥t lại phiên bản 3.1 . Kết quả là sự ra đời
phiên bản 4.0 của visual Source Safe . Đó là phiên bản 32 bit . Năm 1995 , nó được phát hành rô ¥ng rãi .
Source Safe không phải là 1 trình quản lý source code dạng client/server. Nó chấp
nhâ ¥n cho hê ¥ thống người dùng đơn lẻ ít phải cấu hình hơn các hê ¥ thống quản lý source code
khác. Thêm vào đó, quy trình sao lưu dữ liê ¥u có thể đơn giản như viê ¥c copy toàn bô ¥ nô ¥i
dung của cây thư mục. Tuy nhiên đối với môi trường nhiều người dùng , nó thiếu nhiều
chức năng quan trọng được tìm thấy trong các hê ¥ thống quản lý cấu hình khác
Source Safe thừa kế nhiều chức năng chia sẽ sử dụng hê ¥ thống điều khiển file để
thâm nhâ ¥p vào tất cả các file trong repository .
Khởi đầu với Visual Source Safe 2005, Microsoft đã thêm vào 1 chế đô ¥ client-server.
Trong chế đô ¥ này, người dùng không cần ghi các đường dẫn vào Server Message Block nơi
chúng có thể làm nguy hại tới Source Safe database. Thay vào đó, file phải được truy câ ¥p từ
các công cụ phía người dùng như : the VSS windows client, the VSS command-line tool ,
hoă ¥c các chương trình khác thích hợp ,hoă ¥c cạnh tranh với các chương trình phía người dùng đó.
Như hầu hết các hê ¥ thống quản lý cấu hình khác, Source Safe tạo 1 thư viê ¥n ảo trên
các tâ ¥p tin máy tính . Người dùng có thể đọc bất kì file nào tại bất kì thời điểm nào ,nhưng
để thay đổi nó , người dùng phải “check out” nó trước . Sau khi chúng được sửa chữa , phải
“check in” nó lại . Những thay đổi sẽ được câ ¥p nhâ ¥t đối với tất cả người dùng sau khi nó được “check in”.
Microsoft chỉ hỗ trợ Source Safe trên nền tảng Windows. Các đối tác của Microsoft
đưa ra các phiên bản không dành cho windows của Source Safe như : 72
• Dynamsoft đưa ra 1 sản phẩn tích hợp Source Safe đó là SourceAnywhere for VSS
phục vụ cho người dùng java .
• Metrowerks đưa ra sản phẩm quản lý cấu hình tương thích với Source Safe cho hê ¥ điều hành MacOS.
• SourceGear đưa ra sản phẩm tích hợp Source Safe là SourceOffSite cho người dùng
sử dụng Hê ¥ điều hành MacOS , Linux , Solaris. 3.4.3. Visio
Visio là một chương trình vẽ sơ đồ thông minh, được tích hợp vào bộ chương trình
Microsoft Office từ phiên bản 2003. MS Visio cho phép thể hiện bản vẽ một cách trực quan.
Visio cung cấp nhiều đặc tính khiến cho sơ đồ ý nghĩa hơn, linh động hơn và phù hợp với nhiều nhu cầu khác nhau. Visio có thể:
 sao chép bản vẽ từ Visio qua các phần mềm khác (Word, Excel…) để tiện sử dụng.
 tạo các biểu đồ liên quan đến công việc như là: biểu đồ dòng (flowcharts), biểu đồ
tổ chức (organization charts), lịch trình dự án (project scheduling).
 tạo các biểu đồ mang tính kỹ thuật như tạo các bản vẽ xây dựng, thiết kế nhà, biểu
đồ mạng, biểu đồ phần mềm, biểu đồ trang web, biểu đồ máy móc…
MS Visio cho phép bạn thể hiện bản vẽ một cách trực quan. Hơn nữa, nó còn cung
cấp nhiều đặc tính khiến cho sơ đồ của bạn ý nghĩa hơn, linh động hơn và phù hợp hơn với
nhu cầu của bạn ,…) để tiện sử dụng cho công việc của bạn. Với MS Visio, bạn có thể tạo
các sơ đồ liên quan đến công việc như là : biểu đồ dòng (flowcharts), sơ đồ tổ chức
(organization charts), và lịch trình dự án (project scheduling). Ngoài ra, Visio còn cho phép
bạn tạo các sơ đồ mang tính kỹ thuật, chẳng hạn tạo các bản vẽ xây dựng, thiết kế nhà, sơ đồ
mạng, sơ đồ phần mềm, sơ đồ trang web, sơ đồ máy móc, và các sơ đồ kỹ thuật khác. 73
Chương 4. Ngôn ngữ mô hình hóa UML
4.1. Ngôn ngữ mô hình hóa thống nhất UML
4.1.1. Giới thiệu
Cùng với xu khung phát triển của công nghệ thông tin, công nghệ phần mềm đã và
đang trở thành lĩnh vực quan trọng của nhiều quốc gia trên thế giới. Ngày nay, việc phát
triển một phần mềm với qui mô và chất lượng cao không còn là công việc đơn lẻ của những
nhà lập trình, của một cá nhân, đó là sản phẩm của một tập thể, một công ty phần mềm theo
một qui trình công nghệ chuẩn được quản lý chặt chẽ và được hỗ trợ tối đa bởi các công cụ
và môi trường phát triển phần mềm. Do đó, việc lập trình ngày càng trở nên dễ dàng hơn và
nhường lại vai trò mấu chốt cho việc phân tích và thiết kế phần mềm, trong đó quan trọng
nhất là đặc tả và mô hình hoá thế giới thực.
Trong tình hình đó các công ty phần mềm lớn trên thế giới đã nhanh chóng đưa ra
nhiều công cụ hỗ trợ phân tích thiết kế dựa trên nhiều phương pháp khác nhau.
Những năm đầu thập kỷ 90 có rất nhiều phương pháp phân tích thiết kế khung đối
tượng ra đời và phát triển mạnh mẽ và mỗi phương pháp có các ký hiệu riêng (Năm 1994,
có khoảng hơn 50 OO phương pháp, như Fusion, Shlaer-Mellor, ROOM, Class-Relation,
Wirfs-Brock, Coad-Yourdon, MOSES, Syntropy, BOOM, OOSD, OSA, BON, Catalysis,
COMMA, HOOD, Ooram, DOORS … ). Ba phương pháp phổ biến nhất là OMT (Object
Modeling Technique)[James Rumbaugh], Booch91[Grady Booch] và OOSE (Object-
Oriented Software Enginering)[Ivar Jacobson]. Mỗi phương pháp đều có những điểm mạnh,
điểm yếu riêng. Ví dụ, OMT mạnh trong phân tích và yếu trong thiết kế, Booch91 thì mạnh
ở thiết kế và yếu ở phân tích. OOSE mạnh ở phân tích các ứng xử, đáp ứng của hệ thống mà yếu ở các khâu khác. 74
Do các phương pháp chưa hoàn thiện nên người dùng rất phân vân trong việc chọn ra
một phương pháp phù hợp nhất để giải quyết bài toán của họ. Hơn nữa, cách ký hiệu khác
nhau của các phương pháp đã gây ra những sự mập mờ, nhầm lẫn khi mà một ký hiệu có thể
mang những ý nghĩa khác nhau trong mỗi phương pháp. Ví dụ như một hình tròn được tô
đen biểu hiện một multiplicity trong OMT lại là một aggregation trong Booch. Thời kỳ này
còn được biết đến với tên gọi là cuộc chiến giữa các phương pháp. Khoảng đầu năm 94,
Booch đã cải tiến phương pháp của mình trong đó có ứng dụng những ưu điểm của các
phương pháp của Rumbaugh và Jacobson. Tương tự Rumbaugh cũng cho đăng một loạt các
bài báo được biết đến với tên gọi phương pháp OMT-2 cũng sử dụng nhiều ưu điểm của
phương pháp của Booch. Các phương pháp đã bắt đầu hợp nhất, nhưng các kí hiệu sử dụng
ở các phương pháp vẫn còn nhiều điểm khác biệt. Cuộc chiến này chỉ kết thúc khi có sự ra
đời của UML - một ngôn ngữ mô hình hóa hợp nhất.
Theo một bài báo của một nhà khoa học nổi tiếng trong lĩnh vực công nghệ thông tin
– Sinan Si Alhir - với tựa đề “Tri thức – nhân tố quyết định của sự thành công!”, bài báo
viết “Tri thức là sức mạnh – đây là câu nói của một nhà triết gia nổi tiếng – FrancisBacon.
Ngày nay, trên thị trường toàn cầu – và nhất là trong lĩnh vực công nghệ thông tin – nơi mà
sự cạnh tranh trở nên rất phổ biến và quyết liệt, tri thức và khả năng áp dụng của chúng vào
công việc một cách hiệu quả sẽ mang lại cho chúng ta một lợi thế quan trọng vào loại bậc
nhất. Chính điều này đã dẫn tới một câu hỏi – làm thế nào một tổ chức có thể nắm bắt,
truyền đạt, trao đổi và nâng cao tri thức của mình để đạt được lợi thế cạnh tranh trên thị
trường? Có lé câu trả lời chính là ngôn ngữ UML từ hãng phần mềm Rational và tổ chức
OMG (Object Management Group)”. Vậy UML là gì, tại sao nó được giới thiệu ấn tượng đến như thế?
UML (Unified Modeling Language) là gì?
UML – Unified Modeling Language - tạm dịch là ngôn ngữ mô hình hợp nhất, nó
được hiểu như là một ngôn ngữ thống nhất các xu khung và hình thái của cuộc cách mạng
tri thức trong lĩnh vực thông tin. Nó là một phương tiện giúp cho các tổ chức có thể nhận
thức được một cách tốt nhất các lợi thế cạnh tranh thông qua việc nắm bắt, truyền đạt, trao
đổi và nâng cao tri thức trong lĩnh vực công nghệ phần mềm. Chính xác hơn UML là một
ngôn ngữ mô hình hoá chuẩn dùng để đặc tả, trực quan hoá, xây dựng và làm tài liệu cho
các hệ thống phần mềm...
Unified (hợp nhất): UML được đưa ra lần đầu tiên bởi hãng Rational và ba chuyên
gia về phương pháp luận hàng đầu trong lĩnh vực hệ thống thông tin/kỹ thuật công nghệ
Grady Booch, James Rumbaugh, Ivar Jacobson. Nó là sự hợp nhất giữa những phương pháp
cũ (Booch, OMT, OOSE...), kết hợp với những kinh nghiệm, những kiến thức thực tế trong
lĩnh vực công nghệ thông tin. Hình chỉ ra sự hợp nhất của UML.
Modeling (mô hình hoá): giúp chúng ta hiểu được thế giới thực, mô hình hoá thế giới
thực để có thể hiểu được những đặc trưng, tính toán các thông số và dự đoán kết quả sẽ đạt được.
Language (ngôn ngữ): các chức năng của UML như là một phương tiện để bày tỏ và
trao đổi tri thức. Nó có bốn đặc điểm chủ yếu có thể phân biệt với các ngôn ngữ mô hình 75
hoá khác: đa dụng (general purpose), có thể ứng dụng rộng rãi (Broadly applicable), được
hỗ trợ bởi các công cụ (Tool-supported), chuẩn công nghiệp (Industry standardized)
Sự ra đời của UML là một tất yếu khách quan trước sự bùng nổ của nghành công
nghệ thông tin, nó làm nổi bật những xu khung then chốt trong nghành công nghệ phần
mềm, đưa ra được những những vấn đề do sự phân rã của những phương thức mô hình hoá
trước đây gây ra. UML được hình thành trên cơ sở của các vấn đề chính - tại sao chúng ta
lại cần mô hình hoá phần mềm, xu khung phát triển trong nghành công nghệ phần mềm
ngày nay, sự hội tụ của các công nghệ...
Tầm quan trọng của việc mô hình hoá
Mô hình là gì? Đó chính là sự đơn giản hoá của thế giới thực.
Việc phát triển một mô hình cho một hệ thống trong công nghệ phần mềm cũng cần
thiết như là việc lập một bảng thiết kế cho một toà nhà lớn.
Những mô hình tốt giúp cho việc phối hợp giữa các nhóm phát triển tốt hơn.
Chúng ta cần xây dựng mô hình cho những hệ thống phức tạp bởi vì chúng ta không
thể hiểu được toàn bộ hệ thống trong một môi trường rộng lớn như thế, khi sự phức tạp của
hệ thống càng tăng, thì nó cũng đòi hỏi kỹ thuật mô hình hoá tốt hơn. Việc xây dựng mô
hình giúp chúng ta hiểu rõ hơn về hệ thống mà chúng ta đang xây dựng.
Mô hình cung cấp cho chúng ta một khuôn mẫu về thế giới thực, giúp chúng ta có thể
định khung trong quá trình xây dựng , có thể tính toán các chi phí, xác định các rủi ro, làm
tài liệu cho hệ thống...
Trong các nhân tố quyết định đến sự thành công của dự án, nhân tố cần thiết là một
mô hình chuẩn, đặc tả đầy đủ, chi tiết về thời gian thực. 76
Trong một hệ thống mà độ phức tạp càng tăng, việc trực quan hoá và mô hình hoá
càng cần thiết. Ngôn ngữ UML là một sự lựa chọn hoàn hảo và trên thực tế nó cũng đã được
sử dụng và được chấp nhận rộng rãi trên thế giới.
Sự hội tụ của các công nghệ
Trước khi UML ra đời, không có ngôn ngữ mô hình hoá nào trội hơn hẳn các ngôn
ngữ khác. Người dùng phải lựa chọn trong những ngôn ngữ khá tương tự nhau với những
khác biệt nhỏ và cùng chia sẻ trên một tập khái niệm chung. Sự thiếu tương đồng này đã
ngăn cản những người mới tiếp cận với các kỹ thuật khung đối tượng và mô hình khung đối tượng.
Việc thường xuyên phải chi phí cho việc sử dụng và hỗ trợ cho nhiều ngôn ngữ mô
hình hoá đã thúc đẩy nhiều công ty đầu tư vào sản xuất hoặc sử dụng kỹ thuật mới, họ tán
thành và hỗ trợ cho việc phát triển ngôn ngữ UML.
UML đã làm được rất nhiều, ví dụ, Làm giảm đáng kể những chi phí thường xuyên
cho việc huấn luyện và thay đổi công cụ khi thay đổi dự án hoặc tổ chức; Cung cấp cơ hội
cho việc tích hợp mới giữa các công cụ, các tiến trình...; Tạo ra một kiểu mẫu chuẩn, thống nhất cho các công việc.
So sánh với các phương pháp khác
Các nhà phát triến đã cố gắng duy trì tính đơn giản của UML, loại bỏ các thành phần
không được sử dụng trong thực tế từ các phương pháp Booch, OMT, OOSE, thêm vào các
thành phần và ý tưởng hiệu quả hơn từ các phương pháp khác nhau và chỉ xây dựng mới các
thành phần cần thiết. Một số khái niệm mới được sử dụng trong UML bao gồm:
Cơ chế mở rộng (extension mechanism)
Luồng (thread) và tiến trình (process)
Sự phân tán (distribution) và đồng thời (concurrency) (dùng để mô hình hóa các ứng
dụng ActiveX, DCOM và CORBA)
Khuôn mẫu (patterns) và sự cộng tác (collabarations)
Các biểu đồ hoạt động (activity diagrams)
Sự tinh chế (refinement): xử lý các mối liên quan giữa các mức trừu tượng.
Giao diện (interface) và thành phần (component)
Ngôn ngữ mô tả ràng buộc (constraint language)
UML không hoàn toàn tách biệt khỏi ba phương pháp cơ bản là Booch, OMT (Object
Modeling Technique), OOSE (Object-Oriented Software Engineering) mà nó tổng hợp tinh
hoa của cả ba phương pháp trên. Vì vậy, nếu trước đây bạn từng là người sử dụng các
phương pháp Booch, OMT, OOSE thì những kiến thức, kinh nghiệm, các công cụ vẫn còn
có giá trị sử dụng. UML có thể mô tả hệ thống một cách rõ ràng và thống nhất hơn so với
các phương pháp Booch, OMT, OOSE và các ngôn ngữ khác. Điều này có nghĩa rằng việc
chuyển qua dùng UML sẽ mang đến cho người sử dụng một giá trị nhất định nào đó, bởi vì 77
nó cho phép bạn lập mô hình mọi công việc trong dự án, điều mà trước đây chưa có ngôn ngữ nào làm được.
Những người trước đây đã từng dùng các phương pháp và ngôn ngữ mô hình hoá
khác sẽ có được lợi ích khi chuyển qua sử dụng ngôn ngữ UML, nó giúp cho họ loại bỏ
những khác biệt không cần thiết về ngữ nghĩa và kỹ thuật thường xảy ra ở những ngôn ngữ
và phương pháp đã đề cập ở trên. UML có hệ thống ký hiệu rất rõ ràng, mang tính thống
nhất cao, được hỗ trợ bởi nhiều công cụ phát triển phần mềm. Đồng thời trên một công cụ
có hỗ trợ UML, người dùng có thể chuyển đổi các mô hình hiện tại của họ sang UML mà
không sợ mất đi thông tin nào.
UML là sự hợp nhất của các phương pháp khung đối tượng, vì vậy nó cũng kế thừa
một số khái niệm từ các phương pháp này, ví dụ:
Biểu đồ ca sử dụng (Ca sử dụng diagram): tương tự như trong phương pháp OOSE.
Biểu đồ lớp (class diagram) được kết hợp từ OMT và Booch và hầu hết các phương
pháp khung đối tượng khác.
Cơ chế mở rộng được định nghĩa trên nhiều loại biểu đồ và hỗ trợ cho nhiều loại mô
hình của UML để tạo ra các thành phần đa dạng mang đặc điểm riêng biệt của hệ thống
nhằm mục đích hỗ trợ các góc độ mô hình hoá khác nhau. Nhiều khái niệm mới được bổ
sung liên quan đến cơ chế mở rộng trước đây chưa từng được mô tả trong các ngôn ngữ mô
hình hoá chủ yếu khác bao gồm các khuôn mẫu (stereotypes), các ràng buộc (constraints) và
giá trị thẻ (tagged values)
Biểu đồ State – chart cơ bản dựa trên biểu đồ cùng loại của David Harel với một ít
thay đổi nhỏ. Biểu đồ hoạt động cũng dựa trên phần lớn các ngữ nghĩa cơ bản dùng để định
nghĩa State – chart của UML và tương tự như biểu đồ luồng công việc (workflow diagram)
trong nhiều phương pháp khác.
Biểu đồ tuần tự được tìm thấy trong nhiều phương pháo khung đối tượng dưới nhiều
tên gọi khác nhau (interaction, message trace hoặc event trace)
Biểu đồ cộng tác (collaboration diagram) được sửa đổi lại từ biểu đồ đối tượng
(object diagram) của Booch và biểu đồ tương tác đối tượng (object interaction) của Fusion.
Biểu đồ thực thi (Implementation diagram) hay còn gọi là biểu đồ thành phần và triển
khai bắt nguồn từ phương pháp của Booch. Tuy nhiên, chúng giờ đây mang tính chất khung
thành phần (component centered) và liên kết với nhau tốt hơn nhiều so với trước.
Stereotypes là một trong ba cơ chế mở rộng ngữ nghĩa của các thành phần UML sẵn
có. Các stereotype cho phép biến đổi UML theo khung mở rộng nghĩa là tạo ra các thành
phần mang ngữ nghĩa mới đặc trưng riêng của hệ thống mà vẫn giữ nguyên các thành phần đã định nghĩa.
Ngôn ngữ mô tả ràng buộc (Object Constraint Language) được UML sử dụng để đặc
tả ngữ nghĩa và được xem là ngôn ngữ mô tả trong quá trình mô hình hoá. OCL có nguồn
gốc từ phương pháp Syntropy và chịu ảnh hưởng bởi một số ngôn ngữ cùng loại trong các
phương pháp khác như Catalysis nhưng được chuẩn hoá và mở rộng hơn. 78
Lịch sử phát triển
UML được phát triển bởi hãng Rational và những đối tác. Được bắt đầu phát triển
vào tháng 10 năm 1994, khi Grady Booch và Jim Rumbaugh bắt đầu công việc hợp nhất hai
phương pháp Booch và OMT. Bản phác thảo của phiên bản 0.8 được đưa ra vào tháng 10
năm 1995 với tên ban đầu là Unified Method. Mùa thu năm 1995, Ivar Jacobson cùng công
ty của ông quyết định phối hợp với hãng Rational, bằng nỗ lực kết hợp thêm phương pháp
OOSE, để tiếp tục phát triển Unified Method.
Với những nỗ lực của Booch, Rumbaugh, và Jacobson đã đưa ra phiên bản 0.9 và
0.91 vào tháng 6 và tháng 10 năm 1996 với tên là UML. Trong suốt năm 1996, nhóm các
tác giả của UML đã nhận được rất nhiều sự phản hồi từ phía người sử dụng và các chuyên
gai trong lĩnh vực, họ đúc kết và bổ sung từ những ý kiến này, nhưng rõ ràng cần phải có sự
quan tâm nhiều hơn nữa từ phía người sử dụng. Từ đây, UML được sự quan tâm nhiều hơn
từ các tổ chức, các công ty phần mềm lớn, và với sự cộng tác của những công ty hàng đầu
như Digital Equipment, HP, IBM, Microsoft, Oracle...phiên bản UML trở thành một ngôn
ngữ mô hình hoá được định nghĩa tốt hơn, rõ ràng, dễ hiểu, mạnh hơn và có khả năng ứng dụng rộng rãi.
Phiên bản UML 1.1 là sự phát triển về mặt ngữ nghĩa của phiên bản 1.0 đồng thời
cũng tích hợp thêm những đóng góp của những nhà cộng tác mới. UML lần đầu tiên được
đệ trình lên tổ chức OMG vào tháng 1/1997 và lần cuối vào tháng 9/1997 trước khi được
đưa vào danh sách những kỹ thuật được thừa nhận của OMG vào tháng 11/1997. Kể từ đây
OMG chịu trách nhiệm cho sự phát triển của UML trong tương lai. Sau khi được thừa nhận
vào tháng 11/1997, OMG chịu trách nhiệm kiểm tra và phản hồi những kiến nghị từ phía
các đối tác sử dụng, đồng thời tổ chức OMG cũng chịu trách nhiệm xử lý các lỗi kỹ thuật,
những điểm bất đồng, những điểm còn mơ hồ và những thiếu sót nhỏ mà không cần phải
sửa đổi nhiều so với bản thảo ban đầu. Kể từ đây UML được đưa vào sử dụng rộng rãi và
được cải tiến không ngừng, phiên bản UML 1.3 alpha được giới thiệu vào tháng 3/1999 và
sau đó phiên bản UML 1.3 chính thức được giới thiệu vào tháng 6/1999. 79
4.1.2. Các đặc trưng và khả năng của UML
a. UML là một ngôn ngữ dùng để đặc tả
Có nghĩa là xây dựng các mô hình một các tỉ mỉ, rõ ràng, đầy đủ ở các mức độ chi
tiết khác nhau. Đặc biệt là UML thực hiện việc chi tiết hoá tất cả các quyết định quan trọng
trong phân tích, thiết kế và thực thi một hệ thống phần mềm.
b. UML là ngôn ngữ dùng để trực quan hóa
Đối với nhiều lập trình viên, không có khoảng cách giữa ý tưởng giải quyết một vấn
đề và việc thể hiện điều đó thông qua các đoạn mã. Họ nghĩ ra và họ viết mã. Thực tế, điều
này gặp một số vấn đề. Thứ nhất, việc trao đổi về ý tưởng giữa những người lập trình gặp
khó khăn, trừ khi tất cả đều nói cùng một ngôn ngữ. Thậm chí ngay cả khi không gặp trở
ngại về ngôn ngữ thì đối với từng công ty, từng nhóm cũng có những “ngôn ngữ” riêng của
họ. Điều này gây trở ngại cho người mới vào để có thể hiểu được những việc đang được tiến
hành. Hơn nữa, trong lĩnh vực phần mềm, nhiều khi khó có thể hiểu được nếu chỉ xem xét
các đoạn mã lệnh. Ví dụ như sự phân cấp của các lớp, ta có thể phải duyệt rất nhiều đoạn
lệnh để hiểu được sự phân cấp của các lớp. Và nếu như người lập trình không mô tả các ý
tưởng mà anh ta xây dựng thành mã lệnh thì nhiều khi cách tốt nhất là xây dựng lại trong
trường hợp một người khác đảm nhận tiếp nhiệm vụ của anh ta. Xây dựng mô hình sử dụng
ngôn ngữ UML đã giải quyết được các khó khăn trên. Khi trở thành một chuẩn trong việc
lập mô hình, mỗi kí hiệu mang một ý nghĩa rõ ràng và duy nhất, một nhà phát triển có thể
đọc được mô hình xây dựng bằng UML do một người khác viết. Những cấu trúc mà việc
nắm bắt thông qua đọc mã lệnh là khó khăn nay đã được thể hiện trực quan. Một mô hình rõ
ràng, sáng sủa làm tăng khả năng giao tiếp, trao đổi giữa các nhà phát triển.
c. UML là ngôn ngữ dùng để xây dựng
Các mô hình xây dựng bởi UML có thể ánh xạ tới một ngôn ngữ lập trình cụ thể
như : Java, C++... thậm chí cả các bảng trong một cơ sở dữ liệu quan hệ hay cơ sở dữ liệu
khung đối tượng. Việc các yêu cầu có khả năng thường xuyên thay đổi trong quá trình phát
triển hệ thống dẫn đến việc các cấu trúc và hành vi của hệ thống được xây dựng có thể khác
mô hình mà ta đã xây dựng. Điều này có thể làm cho một mô hình tốt trở nên vô nghĩa vì nó
không còn phản ánh đúng hệ thống nữa. Cho nên phải có một cơ chế để đồng bộ hóa giữa
mô hình và mã lệnh. UML cho phép cập nhật một mô hình từ các mã thực thi (ánh xạ
ngược). Điều này tạo ra sự nhất quán giữa mô hình của hệ thống và các đoạn mã thực thi mà
ta xây dựng cho hệ thống đó.
d. UML là ngôn ngữ dùng để lập và cung cấp tài liệu
Một tổ chức phần mềm mạnh ngoài việc tạo ra các đoạn mã lệnh (thực thi) thì còn
tạo ra tất cả các loại chế phẩm khác nhau để thêm vào cho các tài liệu như: Ghi chép về các
yêu cầu của hệ thống, kiến trúc của hệ thống, thiết kế, mã nguồn, kế hoạch dự án, kiểm thử, các nguyên mẫu, ... 80
4.1.3. Kiến trúc trong UML
Kiến trúc phần mềm cho ta một cái nhìn khái quát về hệ thống phần mềm ở các góc
độ khác nhau. Kiến trúc của hệ thống phần mềm chuyên sâu được mô tả tốt nhất bằng năm
loại khung nhìn tương tác với nhau. Mỗi khung nhìn phản ánh về một khía cạnh của tổ chức
và cấu trúc của hệ thống, tập trung vào từng mặt cụ thể giúp cho ta hiểu và sử dụng hệ thống
tốt nhất. Mỗi khung nhìn được mô tả bằng một số biểu đồ, tuy nhiên không có sự phân biệt
rõ ràng giữa các khung nhìn vì một biểu đồ có thể là một bộ phận của nhiều hơn một khung nhìn.
Hình 4.1. Các khung nhìn UML
a. Khung nhìn ca sử dụng (Ca sử dụng View)
Khung nhìn ca sử dụng mô tả chức năng của hệ thống sẽ phải cung cấp do được tác
nhân từ bên ngoài mong đợi. Tác nhân là thực thể tương tác với hệ thống; đó có thể là một
người sử dụng hoặc là một hệ thống khác. Khung nhìn cho ta cách sử dụng chức năng để
mô tả hành vi của hệ thống khi nhìn nhận dưới góc độ của người dùng cuối cùng, người
phân tích, người kiểm thử và người phát triển. Khung nhìn này được mô tả bởi biểu đồ ca sử
dụng và biểu đồ hoạt động. Cách sử dụng hệ thống nhìn chung sẽ được mô tả qua một loạt
các ca sử dụng trong khung nhìn ca sử dụng, nơi mỗi một ca sử dụng là một lời mô tả mang
tính đặc thù cho một tính năng của hệ thống (có nghĩa là một chức năng được mong đợi).
Khung nhìn ca sử dụng mang tính trung tâm, bởi nó đặt ra nội dung thúc đẩy sự phát
triển các khung nhìn khác. Mục tiêu chung của hệ thống là cung cấp các chức năng mô tả
trong khung nhìn này – cùng với một vài các thuộc tính mang tính phi chức năng khác – vì
thế khung nhìn này có ảnh hưởng đến tất cả các khung nhìn khác. Khung nhìn này cũng
được sử dụng để thẩm tra (verify) hệ thống qua việc thử nghiệm xem khung nhìn ca sử dụng
có đúng với mong đợi của khách hàng (Hỏi: "Đây có phải là thứ bạn muốn") cũng như có
đúng với hệ thống vừa được hoàn thành (Hỏi: "Hệ thống có hoạt động như đã đặc tả?”).
b. Khung nhìn logic (Logical View)
Khung nhìn logic mô tả phương thức mà các chức năng của hệ thống sẽ được cung
cấp. Chủ yếu nó được sử dụng cho các nhà thiết kế và nhà phát triển. Ngược lại với khung
nhìn ca sử dụng, khung nhìn logic nhìn vào phía bên trong của hệ thống. Nó mô tả kể cả cấu
trúc tĩnh (lớp, đối tượng, và quan hệ) cũng như sự tương tác động sẽ xảy ra khi các đối
tượng gửi thông điệp cho nhau để cung cấp chức năng đã định sẵn. Khung nhìn logic định 81
nghĩa các thuộc tính như trường tồn (persistency) hoặc song song (concurrency), cũng như
các giao diện cũng như cấu trúc nội tại của các lớp.
Cấu trúc tĩnh được mô tả bằng các biểu đồ lớp (class diagram) và biểu đồ đối tượng
(object diagram). Quá trình mô hình hóa động được mô tả trong các biểu đồ trạng thái (state
diagram), biểu đồ trình tự (sequence diagram), biểu đồ tương tác (collaboration diagram) và
biểu đồ hoạt động (activity diagram).
c. Khung nhìn triển khai (Deployment View)
Khung nhìn triển khai chỉ cho chúng ta sơ đồ triển khai về mặt vật lý của hệ thống, ví
dụ như các máy tính cũng như các máy móc và sự liên kết giữa chúng với nhau. Khung nhìn
triển khai giành cho các nhà phát triển, người tích hợp cũng như người thử nghiệm hệ thống
và được thể hiện bằng các biểu đồ triển khai. Khung nhìn này cũng bao gồm sự ánh xạ các
thành phần của hệ thống vào cấu trúc vật lý; ví dụ như chương trình nào hay đối tượng nào
sẽ được thực thi trên máy tính nào.
d. Khung nhìn thành phần (Component View)
Là một lời mô tả của việc thực thi các modul cũng như sự phụ thuộc giữa chúng với
nhau. Nó thường được sử dụng cho nhà phát triển và thường bao gồm nhiều biểu đồ thành
phần. Thành phần ở đây là các modul lệnh thuộc nhiều loại khác nhau, sẽ được chỉ ra trong
biểu đồ cùng với cấu trúc cũng như sự phụ thuộc của chúng. Các thông tin bổ sung về các
thành phần, ví dụ như vị trí của tài nguyên (trách nhiệm đối với một thành phần), hoặc các
thông tin quản trị khác, ví dụ như một bản báo cáo về tiến trình của công việc cũng có thể được bổ sung vào đây.
e. Khung nhìn song song (Concurrency View)
Khung nhìn song song nhắm tới sự chia hệ thống thành các qui trình (process) và các
bộ xử lý (processor). Khía cạnh này, vốn là một thuộc tính phi chức năng của hệ thống, cho
phép chúng ta sử dụng một cách hữu hiệu các nguồn tài nguyên, thực thi song song, cũng
như xử lý các sự kiện không đồng bộ từ môi trường. Bên cạnh việc chia hệ thống thành các
tiểu trình có thể được thực thi song song, khung nhìn này cũng phải quan tâm đến vấn đề
giao tiếp và đồng bộ hóa các tiểu trình đó.
Khung nhìn song song giành cho nhà phát triển và người tích hợp hệ thống, nó bao
gồm các biểu đồ động (trạng thái, trình tự, tương tác và hoạt động) cùng các biểu đồ thực thi
(biểu đồ thành phần và biểu đồ triển khai).
4.1.4. Mô hình khái niệm của UML
Các khối chính tạo nên UML là: các khối xây dựng cơ bản của UML, các quy tắc
ngữ nghĩa và một số cơ chế chung được áp dụng cho việc mô hình hoá.
a. Các khối xây dựng
* Các sự vật cấu trúc (structural things)
1. Lớp (Class): Là một tập hợp các đối tượng có cùng một tập thuộc tính, các hành
vi, các mối quan hệ với những đối tượng khác. 82 Tên lớp Thuộc tính Phương thức
Hình 4.2. Biểu diễn lớp
2. Sự cộng tác (Collaboration): Thể hiện một giải pháp thi hành bên trong hệ thống,
bao gồm các lớp/đối tượng, mối quan hệ và sự tương tác giữa chúng để đạt được một chức
năng mong đợi của ca sử dụng.
Hình 4.3. Biểu diễn cộng tác
3. Giao diện (Interface): Là một tập hợp các phương thức (operation) tạo nên dịch vụ
của một lớp hoặc một thành phần (component). Nó chỉ ra một tập các operation ở mức khai
báo chứ không phải ở mức thực thi (implementation).
Hình 4.4. Biểu diễn giao diện
4. Ca sử dụng (Ca sử dụng): là mô tả một tập hợp của nhiều hành động tuần tự mà
hệ thống thực hiện để đạt được một kết quả có thể quan sát được đối với một actor cụ thể
nào đó. Actor là những gì ở bên ngoài mà tương tác với hệ thống. Ca sử dụng mô tả sự
tương tác giữa actor và hệ thống. Nó thể hiện chức năng mà hệ thống sẽ cung cấp cho actor.
Tập hợp các Ca sử dụng của hệ thố
các trường hợp mà hệ thống có thể được sử dụng.
Hình 4.5. Biểu diễn ca sử dụng
5. Lớp hoạt động (Acitive class): là một lớp mà các đối tượng của nó thực hiện các
hoạt động điều khiển. Lớp tích cực cũng giống như lớp bình thường ngoại trừ việc các đối
tượng của nó thể hiện các phần tử mà ứng xử của chúng có thể thực hiện đồng thời với các
phần từ khác. Lớp này thường dùng để biểu diễn tiến trình (process) và luồng (thread)
Hình 4.6. Biểu diễn lớp hoạt động
6. Thành phần (Component): là biểu diễn vật lý của mã nguồn. Trong hệ thống ta sẽ
thấy các kiểu khác nhau của component như các thành phần COM+ hay JavaBeans cũng
như là các thành phần như các file mã nguồn, các file nhị phân tạo ra trong quá trình phát triển hệ thống.
Hình 4.7. Biểu diễn thành phần
7. Nút (Node): là thể hiện một thành phần vật lý như máy tính hay thiết bị phần cứng
Hình 4.8. Biểu diễn nút
* Các sự vật hành vi (behavioral things)
1. Sự tương tác (Interaction): bao gồm một tập các thông báo (message) trao đổi
giữa các đối tượng trong một ngữ cảnh cụ thể nào đó để thực hiện một chức năng nào đó.
Hình 4.9. Biểu diễn thông báo
2. Máy trạng thái (States machine): thể hiện các trạng thái của một đối tượng trong
thời gian sống của nó nhằm đáp ứng các sự kiện, các tác động từ bên ngoài.
* Các sự vật nhóm gộp (Grouping things)
Gói (Package): Dùng để nhóm các phần tử có một ý nghĩa chung nào đó vào thành
nhóm. Không giống như các thành phần (component - tồn tại trong lúc thực thi), một
package chỉ mang tính trừu tượng. Package dùng để nhìn hệ thống ở một mức độ tổng quát
hơn so với việc xem xét từng phần tử trong package.
* Sự vật giải thích (Annotational thing): là các chú thích dùng để mô tả, làm sáng tỏ
và ghi chú về bất cứ phần tử nào trong mô hình. Thường dùng nhất là Note gồm các ràng
buộc hoặc ghi chú, được gắn với một phần tử hoặc một tập hợp các phần tử.
Hình 4.10. Biểu diễn chú thích
* Các quan hệ (Relationships)
1. Quan hệ phụ thuộc (Dependency): Là mối quan hệ ngữ nghĩa giữa hai sự vật,
trong đó sự thay đổi của một sự vật (sự vật độc lập) có thể tác động đến ngữ nghĩa của một
sự vật khác (sự vật phụ thuộc).
Hình 4.11. Biểu diễn quan hệ phụ thuộc
2. Quan hệ kết hợp ( Association): Là mối quan hệ cấu trúc mô tả một tập các mối
liên kết giữa một số các đối tượng của một lớp. Nói một cách đơn giản, khi một đối tượng
của lớp này gửi thông điệp tới hoặc nhận thông điệp từ một đối tượng của lớp kia thì ta nói
giữa 2 lớp có mối quan hệ association.
Hình 4.12. Biểu điễn quan hệ kết hợp
3. Quan hệ tập hợp (Aggreagation): Là một dạng đặc biệt của quan hệ liên kết. Nó
thể hiện sự liên kết “chặt” hơn, đó là mối quan hệ toàn thể-bộ phận.
Hình 4.13. Biểu diễn quan hệ tập hợp
4. Quan hệ hợp thành (Composition): là một dạng đặc biệt của quan hệ tập hợp
(aggregation). Trong đó nếu như đối tượng toàn thể bị hủy thì các đối tượng bộ phận của nó cũng bị hủy theo.
Hình 4.14. Biểu diễn quan hệ hợp thành
5. Quan hệ tổng quát hoá (Generalization): là mối quan hệ tổng quát hóa/cụ thể hóa
trong đó đối tượng cụ thể sẽ kế thừa các thuộc tính và phương thức( behavior) của đối tượng tổng quát.
Hình 4.15. Biểu diễn quan hệ tổng quát hóa
6. Quan hệ sự thực hiện hóa (Realization): Là mối quan hệ ngữ nghĩa giữa các phân
lớp, sao cho các phân lớp khác nhau đảm nhiệm thực hiện những trách nhiệm khác nhau.
Mối quan hệ thực hiện được đưa vào hai vị trí: giữa các giao diện và các lớp hoặc các thành
phần thực hiện của nó. Một mối quan hệ thực hiện được xem như một mối quan hệ nằm
giữa mối quan hệ tổng quát và mối quan hệ phụ thuộc. 85
Hình 4.16. Biểu diễn quan hệ hiện thực hóa b. Các quy tắc
Mô hình hoá một hệ thống không đơn giản là lắp ghép các khối được xây dựng của
UML một cách ngẫu nhiên. Như bất cứ một ngôn ngữ nào, UML có những quy tắc chỉ ra
rằng một mô hình tốt sẽ như thế nào. Một mô hình tốt là mô hình mang tính nhất quán và có
sự kết hợp hài hòa giữa các mô hình có liên quan của nó.
UML có một số quy tắc dành cho việc:
- Đặt tên: để có thể truy xuất các phần tử của mô hình thì phải đặt tên cho chúng như
tên của các quan hệ, biểu đồ...
- Xác định phạm vi: ngữ cảnh mang lại một ý nghĩa cụ thể cho một cái tên
- Tính nhìn thấy được: để có được sự đơn giản và dễ kiểm soát thì ở những ngữ cảnh
khác nhau cần chỉ ra rằng một cái tên là hiện hữu và được sử dụng bởi những đối tượng khác như thế nào.
- Tính toàn vẹn: mọi thứ quan hệ một cách đúng đắn và nhất quán với nhau như thế nào. c. Các cơ chế chung
* Đặc tả (Specification)
Các phần tử mô hình có thuộc tính (Property) chứa các giá trị dữ liệu về phần tử này.
Một thuộc tính được định nghĩa với một tên và một giá trị đính kèm (tagged value), thường
chúng ở trong một dạng thông tin được xác định trước, ví dụ như số nguyên hay chuỗi kí tự.
Có một loạt thuộc tính đã được định nghĩa trước, ví dụ như tài liệu (docement), trách nhiệm
(Responsibility), sự trường tồn (Persistence) và tính song song (Conccurency).
Hình 4.17. Một cửa sổ đặc tả thể hiện các đặc tính của class
Thuộc tính được sử dụng để thêm các đặc tả bổ sung về một phần tử, những thông tin
bình thường ra không được thể hiện trong biểu đồ. Ví dụ tiêu biểu là một lớp sẽ được mô tả
bằng một tài liệu văn bản nhất định, cung cấp nhiều thông tin hơn về trách nhiệm cũng như 86
khả năng của lớp này. Loại đặc tả này bình thường ra không được chỉ ra trong các biểu đồ,
nhưng thường thì trong đa phần các công cụ mô hình hóa chúng sẽ có thể được truy cập qua
hành động nhấp nút vào một phần tử nào đó, hiệu quả là một cửa sổ chứa đặc tả với tất cả
các thuộc tính sẽ được chỉ ra (Hình 4.17).
* Bài trí (Adornments)
Các sự trang trí trực quan có thể được sử dụng kèm thêm vào các phần tử mô hình
trong biểu đồ. Động tác trang trí bổ sung thêm ngữ nghĩa cho phần tử. Một ví dụ là kỹ thuật
được sử dụng để phân biệt một loại thực thể (lớp) và một thực thể. Khi thể hiện một loại, tên
phần tử sẽ được in đậm. Khi cũng chính phần tử đó thể hiện chỉ một thực thể của loại này,
tên phần tử sẽ được gạch dưới và có thể được coi là cả tên của thực thể lẫn tên của loại đó.
Một hình chữ nhật thể hiện lớp với tên được in đậm sẽ thể hiện một lớp và tên được gạch
dưới sẽ thể hiện một đối tượng, đây là một ví dụ tiêu biểu của adornment. Cũng nguyên tắc
đó được áp dụng cho các nút mạng, khi ký hiệu nút được in đậm là thể hiện một loại nút, ví
dụ như máy in (Printer), khi ký hiệu được gạch dưới là thể hiện một thực thể của lớp nút
mạng này ví dụ John’s HP 5MP-printer. Các kiểu trang trí khác là các lời đặc tả về số lượng
trong quan hệ (multiplicity), nơi số lượng là một số hay một khoảng số chỉ ra bao nhiêu thực
thể của các loại thực thể được nối với nhau sẽ có thể tham gia trong một quan hệ. Kí hiệu
trang trí được viết gần phần tử mô hình được mà nó bổ sung thông tin (hình 4.18).
Hình 4.18. Phân biệt giữa lớp và đối tượng bằng trang trí * Ghi chú (Note)
Cho dù một ngôn ngữ mô hình hóa có được mở rộng đến bao nhiêu chăng nữa, nó
cũng không thể định nghĩa tất cả mọi việc. Nhằm tạo điều kiện bổ sung thêm cho một mô
hình những thông tin không thể được thể hiện bằng phần tử mô hình, UML cung cấp khả
năng kèm theo lời ghi chú. Một lời ghi chú có thể được để bất kỳ nơi nào trong bất kỳ biểu
đồ nào, và nó có thể chứa bất kỳ loại thông tin nào. Dạng thông tin của bản thân nó là chuỗi
ký tự (string), không được UML diễn giải. Lời ghi chú thường đi kèm theo một số các phần
tử mô hình trong biểu đồ, được nối bằng một đường chấm chấm, chỉ ra phần tử mô hình nào
được chi tiết hóa hoặc được giải thích (Hình 4.19).
Một lời ghi chú thường chứa lời nhận xét hoặc các câu hỏi của nhà tạo mô hình, ví dụ
lời nhắc nhở cần phải xử lý vấn đề nào đó trong thời gian sau này. Lời ghi chú cũng có thể
chứa các thông tin dạng khuôn mẫu (stereotype). 87
Hình 4.19. Một ví dụ về ghi chú
* Các cơ chế mở rộng (extensibility mechanisms)
UML cung cấp những thành phần cơ bản để lập nên một mô hình cho một phần
mềm. Nhưng nó không thể nào bao quát hết theo thời gian mọi mô hình trong mọi lĩnh vực.
Do đó UML được thiết kế mở theo nghĩa là người dùng có thể mở rộng một số thành phần
để có thể áp dụng một cách tốt nhất cho hệ thống của họ mà lại không phải thay đổi hay
thiết kế lại các thành phần cơ sở của UML. Cơ chế đó bao gồm:
Khuôn mẫu (Stereotypes): mở rộng tập từ vựng của UML, cho phép tạo những thành
phần mới kế thừa những đặc điểm của những thành phần đã có đồng thời chứa thêm những
đặc điểm riêng gắn với một bài toán cụ thể nào đó.
Các giá trị thẻ (Tagged values): mở rộng thuộc tính của các thành phần của UML, nó
cho phép ta tạo thêm những thông tin mới về một phần tử. Ví dụ như khi làm việc hợp tác
để tạo ra một sản phẩm, ta muốn chỉ ra các phiên bản và tác giả của một đối tượng nào đó.
Điều này không được xây dựng sẵn trong UML mà có thể thực hiện thông qua việc thêm vào một giá trị thẻ.
Các ràng buộc (Constraints): mở rộng ngữ nghĩa của các thành phần của UML, cho
phép tạo ra những quy tắc mới hoặc sửa chữa những quy tắc đã có.
1. Khuôn mẫu (Stereotype)
Cơ chế mở rộng khuôn mẫu định nghĩa một loại phần tử mô hình mới dựa trên một
phần tử mô hình đã tồn tại. Khuôn mẫu có thể được coi là "tương tự" như một phần tử đã có
sẵn, cộng thêm phần quy định ngữ nghĩa (semantic) riêng biệt không có trong phần tử gốc
kia. Khuôn mẫu của một phần tử có thể được sử dụng trong cùng tình huống như phần tử
căn bản. Khuôn mẫu dựa trên tất cả các loại phần tử mô hình sẵn có - lớp, nút mạng, thành
phần, cũng như các mối quan hệ như liên kết, khái quát hóa, sự phụ thuộc. Ngôn ngữ UML
có chứa một số lượng lớn các khuôn mẫu được định nghĩa sẵn và chúng được sử dụng để
sửa đổi các phần tử mô hình sẵn có, thay cho việc phải định nghĩa hoàn toàn mới. Cơ chế
này giúp gìn giữ tính đơn giản của nền tảng ngôn ngữ UML.
Khuôn mẫu được mô tả qua việc đưa tên của chúng vào trong một cặp ký tự ngoặc
nhọn <<>>, theo như trong Hình 4.20. Ký tự ngoặc nhọn này được gọi là guillements.
Khuôn mẫu cũng có thể có kí hiệu hình học riêng. Một phần tử của một loại khuôn mẫu cụ
thể có thể được thể hiện bởi tên khuôn mẫu đi kèm ký hiệu hình học mô tả phần tử căn bản,
hay là sự kết hợp của cả hai yếu tố này. Bất kỳ khi nào một phần tử mô hình được nối kết
với một tên hoặc kí hiệu khuôn mẫu, ta sẽ đọc "đây là một loại phần tử thuộc loại khuôn
mẫu...". Ví dụ, một lớp với <> sẽ được gọi là "một lớp trong dạng khuôn mẫu
cửa sổ", ý nghĩa của nó là một dạng lớp cửa sổ. Những thuộc tính cụ thể mà một lớp cửa sổ
cần phải có sẽ được định nghĩa khi khuôn mẫu này được định nghĩa.
Như đã nói, khuôn mẫu là một cơ chế mở rộng xuất sắc, là một cơ chế ngăn cho ngôn
ngữ UML không trở nên quá phức tạp, mặc dù vẫn cho phép thực hiện sự mở rộng và sửa
đổi cần thiết. Đa phần các phần tử mô hình mới mà bạn cần đến đều có một khuôn mẫu nền 88
tảng trong ngôn ngữ UML. Một khuôn mẫu sau đó có thể được sử dụng để cộng thêm các
ngữ nghĩa cần thiết, nhằm mục đích định nghĩa nên các phần tử mô hình còn thiếu.
Hình 4.20. Customer là một lớp khuôn mẫu <>
2. Giá trị đính kèm (Tagged Value)
Như đã nói, các phần tử mô hình có thể có các thuộc tính chứa một cặp tên-giá trị về
bản thân chúng (Hình 4.21). Các thuộc tính này cũng còn được gọi là các gía trị đính kèm.
UML có chứa một loạt các thuộc tính được định nghĩa trước, nhưng kể cả người sử dụng
cũng có thể định nghĩa ra các thuộc tính mới để chứa các thông tin bổ sung về các phần tử
mô hình. Mọi hình dạng thông tin đều có thể được đính kèm vào phần tử: các thông tin
chuyên biệt về phương pháp, các thông tin của nhà quản trị về tiến trình mô hình hóa, các
thông tin được sử dụng bởi các công cụ khác, ví dụ như các công cụ tạo code, hay bất kỳ
một loại thông tin nào mà người sử dụng muốn đính kèm vào phần tử mô hình.
Hình 4.21. Một ví dụ về Tagged Value
3. Hạn chế (Constraint)
Một sự hạn chế là một sự giới hạn về sự sử dụng hoặc ý nghĩa của một phần tử. Sự
hạn chế hoặc sẽ được khai báo trong công cụ và được sử dụng nhiều lần trong rất nhiều biểu
đồ khác nhau, hay được định nghĩa và sử dụng trong chỉ một biểu đồ, theo như nhu cầu.
Hình 4.22 chỉ ra mối quan hệ nối kết giữa nhóm các công dân lớn tuổi và lớp con
người, chỉ ra rằng nhóm công dân có thể có nhiều người liên quan. Mặc dù vậy, để mô tả
rằng chỉ những người nào lớn hơn 60 tuổi mới có thể tham gia vào nhóm này, người ta định
nghĩa một sự hạn chế, hạn hẹp tiêu chuẩn tham gia đối với chỉ những người nào mà thuộc
tính tuổi tác có giá trị lớn hơn 60. Định nghĩa này sẽ hạn chế số lượng những người được sử
dụng trong mối quan hệ. Nếu không có nó, người ta rất dễ hiểu lầm khi diễn tả biểu đồ.
Trong trường hợp tồi tệ, nó có thể dẫn đến sự thực thi sai trái của hệ thống.
Trong trường hợp này, hạn chế được định nghĩa và ứng dụng trực tiếp trong chính
biểu đồ mà nó được cần tới. Nhưng nhìn chung thì hạn chế cũng có thể được định nghĩa với
tên cùng lời đặc tả riêng, ví dụ như: "công dân già" và "người có tuổi lớn hơn 60", và hạn
chế này sẽ được sử dụng trong nhiều biểu đồ khác nhau. UML có chứa một loạt các hạn chế
được định nghĩa sẵn, chúng được mô tả chi tiết trong các chương sau. 89
Hình 4.22. Một ràng buộc hạn chế đối tượng Person góp phần vào quan hệ kết hợp
4.1.5. Các biểu đồ
Biểu đồ là các hình vẽ bao gồm các ký hiệu phần tử mô hình hóa được sắp xếp để
minh họa một thành phần cụ thể hay một khía cạnh cụ thể của hệ thống. Một mô hình hệ
thống thường có nhiều loại biểu đồ, mỗi loại có nhiều biểu đồ khác nhau. Một biểu đồ là
một thành phần của một khung nhìn cụ thể; và khi được vẽ ra, nó thường thường cũng được
xếp vào một khung nhìn. Mặt khác, một số loại biểu đồ có thể là thành phần của nhiều
khung nhìn khác nhau, tùy thuộc vào nội dung của biểu đồ.
Phần sau mô tả các khái niệm căn bản nằm đằng sau mỗi loại biểu đồ. Tất cả các chi
tiết về biểu đồ, ngữ cảnh của chúng, ý nghĩa chính xác của chúng và sự tương tác giữa
chúng với nhau được mô tả chi tiết trong các chương sau (mô hình đối tượng – mô hình
động). Các biểu đồ lấy làm ví dụ ở đây được lấy ra từ nhiều loại hệ thống khác nhau để chỉ
ra nét phong phú và khả năng áp dụng rộng khắp của UML.
Có 9 loại biểu đồ được sử dụng trong UML như được thể hiện trong Hình 4.23. Biểu đồ lớp Biểu đồ Biểu đồ Biểu độ ca sử dụng đối tượng tuần tự Biểu đồ Biểu đồ Các cộng tác thành phần mô hình Biểu đồ Biểu đồ trạng thái triển khai Biểu đồ hoạt động Mô hình hóa phần Mô hình hóa phần động tĩnh
Hình 4.23. Các biểu đồ trong UML
a. Biểu đồ ca sử dụng (Ca sử dụng Diagram)
Biểu đồ ca sử dụng để mô hình hoá các khía cạnh động của hệ thống. Nó là trung tâm
để mô hình hoá hành vi của hệ thống, một hệ thống con, một lớp. Mỗi biểu đồ chỉ ra một tập
các ca sử dụng, các tác nhân và các mối quan hệ giữa chúng. 90
Biểu đồ ca sử dụng mô tả cách nhìn từ bên ngoài để thấy được bối cảnh mà trong đó
hệ thống đang tồn tại và những mối quan hệ giữa nó và môi trường, mô tả hoạt động của hệ
thống từ bên ngoài không lệ thuộc vào việc nó thực hiện các hoạt động đó như thế nào. Vì
vậy, mô hình ca sử dụng là phương tiện để mô tả các yêu cầu của hệ thống. Ta sử dụng biểu
đồ ca sử dụng để:Mô hình hoá ngữ cảnh của hệ thống và Mô hình hoá các yêu cầu của một hệ thống.
Hình 4.24. Biểu đồ ca sử dụng
b. Biểu đồ lớp (Class Diagram)
Một biểu đồ lớp chỉ ra cấu trúc tĩnh của các lớp trong hệ thống (nhìn Hình 4.25). Các
lớp là đại diện cho các “vật” được xử lý trong hệ thống. Các lớp có thể quan hệ với nhau
trong nhiều dạng thức: liên kết (associated - được nối kết với nhau), phụ thuộc (dependent -
một lớp này phụ thuộc vào lớp khác), chuyên biệt hóa (specialized - một lớp này là một kết
quả chuyên biệt hóa của lớp khác), hay đóng gói ( packaged - hợp với nhau thành một đơn
vị). Tất cả các mối quan hệ đó đều được thể hiện trong biểu đồ lớp, đi kèm với cấu trúc bên
trong của các lớp theo khái niệm thuộc tính (attribute) và thủ tục (operation). Biểu đồ được
coi là biểu đồ tĩnh theo phương diện cấu trúc được mô tả ở đây có hiệu lực tại bất kỳ thời
điểm nào trong toàn bộ vòng đời hệ thống.
Một hệ thống thường sẽ có một loạt các biểu đồ lớp – chẳng phải bao giờ tất cả các
biểu đồ lớp này cũng được nhập vào một biểu đồ lớp tổng thể duy nhất – và một lớp có thể
tham gia vào nhiều biểu đồ lớp
Hình 4.25. Biểu đồ lớp
c. Biểu đồ triển khai (Deployment Diagram)
Biểu đồ triển khai chỉ ra kiến trúc vật lý của phần cứng cũng như phần mềm trong hệ
thống. Bạn có thể chỉ ra từng máy tính cụ thể và từng trang thiết bị cụ thể (node) đi kèm sự
nối kết giữa chúng với nhau, bạn cũng có thể chỉ ra loại của các mối nối kết đó. Bên trong
các nút mạng (node), các thành phần thực thi được cũng như các đối tượng sẽ được xác định 91
vị trí để chỉ ra những phần mềm nào sẽ được thực thi tại những nút mạng nào. Bạn cũng có
thể chỉ ra sự phụ thuộc giữa các thành phần.
Biểu đồ triển khai chỉ ra khung nhìn triển khai, mô tả kiến trúc vật lý thật sự của hệ
thống. Đây là một khung nhìn rất xa lối mô tả duy chức năng của khung nhìn ca sử dụng.
Mặc dù vậy, trong một mô hình tốt, người ta có thể chỉ tất cả những con đường dẫn từ một
nút mạng trong một kiến trúc vật lý cho tới những thành phần của nó, cho tới lớp mà nó
thực thi, cho tới những tương tác mà các đối tượng của lớp này tham gia để rồi cuối cùng,
tiến tới một ca sử dụng. Rất nhiều khung nhìn khác nhau của hệ thống được sử dụng đồng
thời để tạo ra một lời mô tả thấu đáo đối với hệ thống trong sự tổng thể của nó.
Hình 4.26. Biểu đồ triển khai
d. Biểu đồ đối tượng (Object Diagram)
Một biểu đồ đối tượng là một phiên bản của biểu đồ lớp và thường cũng sử dụng các
ký hiệu như biểu đồ lớp. Sự khác biệt giữa hai loại biểu đồ này nằm ở chỗ biểu đồ đối tượng
chỉ ra một loạt các đối tượng thực thể của lớp, thay vì các lớp. Một biểu đồ đối tượng vì vậy
là một ví dụ của biểu đồ lớp, chỉ ra một bức tranh thực tế có thể xảy ra khi hệ thống thực thi:
bức tranh mà hệ thống có thể có tại một thời điểm nào đó. Biểu đồ đối tượng sử dụng chung
các ký hiệu của biểu đồ lớp, chỉ trừ hai ngoại lệ: đối tượng được viết với tên được gạch dưới
và tất cả các thực thể trong một mối quan hệ đều được chỉ ra (nhìn Hình 4.27).
Biểu đồ đối tượng không quan trọng bằng biểu đồ lớp, chúng có thể được sử dụng để
ví dụ hóa một biểu đồ lớp phức tạp, chỉ ra với những thực thể cụ thể và những mối quan hệ
như thế thì bức tranh toàn cảnh sẽ ra sao. Một biểu đồ đối tượng thường thường được sử
dụng làm một thành phần của một biểu đồ cộng tác (collaboration), chỉ ra lối ứng xử động
giữa một loạt các đối tượng.
Hình 4.27. Biểu đồ đối tượng
e. Biểu đồ thành phần (Component Diagram)
Một biểu đồ thành phần chỉ ra cấu trúc vật lý của các dòng lệnh (code) theo khái
niệm thành phần code. Một thành phần code có thể là một tập tin source code, một thành
phần nhị phân (binary) hay một thành phần thực thi được (executable). Một thành phần 92
chứa các thông tin về các lớp logic hoặc các lớp mà nó thi hành, như thế có nghĩa là nó tạo
ra một ánh xạ từ khung nhìn logic vào khung nhìn thành phần. Biểu đồ thành phần cũng chỉ
ra những sự phụ thuộc giữa các thành phần với nhau, trợ giúp cho công việc phân tích hiệu
ứng mà một thành phần được thay đổi sẽ gây ra đối với các thành phần khác. Thành phần
cũng có thể được mô tả với bất kỳ loại giao diện nào mà chúng bộc lộ, ví dụ như giao diện
OLE/COM; và chúng có thể được nhóm góp lại với nhau thành từng gói (package). Biểu đồ
thành phần được sử dụng trong công việc lập trình cụ thể (xem Hình 4.28).
Hình 4.28. Biểu đồ thành phần
f. Biểu đồ sơ đồ trạng thái (Statechart Diagram)
Một biểu đồ trạng thái thường là một sự bổ sung cho lời mô tả một lớp. Nó chỉ ra tất
cả các trạng thái mà đối tượng của lớp này có thể có, và những sự kiện (event) nào sẽ gây ra
sự thay đổi trạng thái (Hình 4.29). Một sự kiện có thể xảy ra khi một đối tượng tự gửi thông
điệp đến cho nó - ví dụ như để thông báo rằng một khoảng thời gian được xác định đã qua
đi – hay là một số điều kiện nào đó đã được thỏa mãn. Một sự thay đổi trạng thái được gọi
là một sự chuyển đổi trạng thái (State Transition). Một chuyển đổi trạng thái cũng có thể có
một hành động liên quan, xác định điều gì phải được thực hiện khi sự chuyển đổi trạng thái
này diễn ra. Biểu đồ trạng thái không được vẽ cho tất cả các lớp, mà chỉ riêng cho những
lớp có một số lượng các trạng thái được định nghĩa rõ ràng và hành vi của lớp bị ảnh hưởng
và thay đổi qua các trạng thái khác nhau. Biểu đồ trạng thái cũng có thể được vẽ cho hệ
thống tổng thể (Mô hình động).
Hình 4.29. Biểu đồ trạng thái
g. Biểu đồ hoạt động (Activity Diagram)
Một biểu đồ hoạt động chỉ ra một trình tự lần lượt của các hoạt động (activity) (Hình
4.30). Biểu đồ hoạt động thường được sử dụng để mô tả các hoạt động được thực hiện trong
một thủ tục, mặc dù nó cũng có thể được sử dụng để mô tả các dòng chảy hoạt động khác, ví
dụ như trong một Ca sử dụng hay trong một trình tự tương tác. Biểu đồ hoạt động bao gồm
các trạng thái hành động, chứa đặc tả của một hoạt động cần phải được thực hiện (một hành
động - action). Một trạng thái hành động sẽ qua đi khi hành động được thực hiện xong (khác
với biểu đồ trạng thái: một trạng thái chỉ chuyển sang trạng thái khác sau khi đã xảy ra một
sự kiện rõ ràng !). Dòng điều khiển ở đây chạy giữa các trạng thái hành động liên kết với
nhau. Biểu đồ còn có thể chỉ ra các quyết định, các điều kiện, cũng như phần thực thi song 93
song của các trạng thái hành động. Biểu đồ ngoài ra còn có thể chứa các loại đặc tả cho các
thông điệp được gửi đi hoặc được nhận về, trong tư cách là thành phần của hành động được thực hiện.
Hình 4.30. Biểu đồ hoạt động cho một printer server
h. Biểu đồ trình tự (Sequence Diagram)
Một biểu đồ trình tự chỉ ra một cộng tác động giữa một loạt các đối tượng (xem Hình
4.31). Khía cạnh quan trọng của biểu đồ này là chỉ ra trình tự các thông điệp (message)
được gửi giữa các đối tượng. Nó cũng chỉ ra trình tự tương tác giữa các đối tượng, điều sẽ
xảy ra tại một thời điểm cụ thể nào đó trong trình tự thực thi của hệ thống. Các biểu đồ trình
tự chứa một loạt các đối tượng được biểu diễn bằng các đường thẳng đứng. Trục thời gian
có khung từ trên xuống dưới trong biểu đồ, và biểu đồ chỉ ra sự trao đổi thông điệp giữa các
đối tượng khi thời gian trôi qua. Các thông điệp được biểu diễn bằng các đường gạch ngang
gắn liền với mũi tên (biểu thị thông điệp) nối liền giữa những đường thẳng đứng thể hiện
đối tượng. Trục thời gian cùng những lời nhận xét khác thường sẽ được đưa vào phần lề của biểu đồ.
Hình 4.31. Biểu đồ trình tự
i. Biểu đồ cộng tác (Collaboration Diagram)
Một biểu đồ cộng tác chỉ ra một sự cộng tác động, cũng giống như một biểu đồ trình
tự. Thường người ta sẽ chọn hoặc dùng biểu đồ trình tự hoặc dùng biểu đồ cộng tác. Bên
cạnh việc thể hiện sự trao đổi thông điệp (được gọi là tương tác), biểu đồ cộng tác chỉ ra các
đối tượng và quan hệ của chúng (nhiều khi được gọi là ngữ cảnh). Việc nên sử dụng biểu đồ
trình tự hay biểu đồ cộng tác thường sẽ được quyết định theo nguyên tắc chung sau: Nếu
thời gian hay trình tự là yếu tố quan trọng nhất cần phải nhấn mạnh thì hãy chọn biểu đồ
trình tự; nếu ngữ cảnh là yếu tố quan trọng hơn, hãy chọn biểu đồ cộng tác. Trình tự tương
tác giữa các đối tượng được thể hiện trong cả hai loại biểu đồ này.
Biểu đồ cộng tác được vẽ theo dạng một biểu đồ đối tượng, nơi một loạt các đối
tượng được chỉ ra cùng với mối quan hệ giữa chúng với nhau (sử dụng những ký hiệu như 94
trong biểu đồ lớp/ biểu đồ đối tượng). Các mũi tên được vẽ giữa các đối tượng để chỉ ra
dòng chảy thông điệp giữa các đối tượng. Các thông điệp thường được đính kèm theo các
nhãn (label), một trong những chức năng của nhãn là chỉ ra thứ tự mà các thông điệp được
gửi đi. Nó cũng có thể chỉ ra các điều kiện, chỉ ra những giá trị được trả về, v.v... Khi đã làm
quen với cách viết nhãn, một nhà phát triển có thể đọc biểu đồ cộng tác và tuân thủ theo
dòng thực thi cũng như sự trao đổi thông điệp. Một biểu đồ cộng tác cũng có thể chứa cả các
đối tượng tích cực (active objects), hoạt động song song với các đối tượng tích cực khác (Hình 4.32).
Hình 4.32. Một biểu đồ cộng tác của một printer server
Mặc dù chín biểu đồ trên đã vượt xa nhu cầu chung nhất mà ta thường gặp trong thực
tế phát triển phần mềm khung đối tượng. Tuy nhiên, UML còn cung cấp những loại biểu đồ
khác cho phép mô hình hóa những trường hợp kinh tế hơn
4.1.6. Rational Rose
a. Giới thiệu
Rational Rose là một công cụ lập mô hình trực quan mạnh trợ giúp bạn phân tích và
thiết kế các hệ thống phần mềm hướng đối tượng. Nó được dùng để lập mô hình hệ thống
trước khi bạn viết mã (code). Dùng mô hình, bạn có thể bắt kịp những thiếu sót về thiết kế,
trong khi việc chỉnh sửa chúng vẫn chưa tốn kém.
Mô hình Rose là bức tranh về một hệ thống từ nhiều góc nhìn khác nhau. Nó bao
gồm tất cả các sơ đồ UML, các actor, các use case, các đối tượng, các lớp, các thành phần…
Nó mô tả chi tiết nội dung mà hệ thống sẽ gộp và cách nó sẽ làm việc.
Có thể xem một mô hình Rose tương tự như bản thiết kế mẫu. Giống như một căn
nhà có nhiều bản thiết kế mẫu cho phép các thành viên trong đội xây dựng xem xét nó từ
nhiều góc nhìn khác nhau như: hệ thống ống nước, hệ thống điện, hệ thống nền… Một mô
hình Rose chứa đựng các sơ đồ khác nhau cho phép các thành viên trong nhóm đề án xem
hệ thống từ các góc nhìn khác nhau như : khách hàng, nhà thiết kế, quản trị đề án, …
Khi đã có được bản thiết kế thì sẽ giảm bớt một số vấn đề phiền phức như: lập trình
theo truyền thống thì khi hoàn tất đề án, sau một thời gian sử dụng khách hàng yêu cầu thêm
một vài chức năng nào đó vì có cập nhật mới thì người lập trình phải xem lại toàn bộ hệ
thống rồi sau đó mới cập nhật. Điều này tốn rất nhiều thời gian. Nay nhờ có bản thiết kế thì
chỉ cần xem cập nhật đó nằm ở phần nào và chỉnh sửa, nâng cấp hệ thống. Điều đó sẽ linh
hoạt và giảm rất nhiều thời gian…
Có ba phiên bản khác nhau của Rose : 95
Rose Modeler: cho phép bạn tạo mô hình cho hệ thống, nhưng không hỗ trợ tiến trình
phát sinh mã hoặc thiết kế kỹ thuật đảo ngược.
Rose Professional: cho phép bạn phát sinh mã trong một ngôn ngữ
Rose Enterprise: cho phép bạn phát sinh mã cho C++, Java, Ada, Corba, Visual
Basic, Oracle… Một mô hình có thể có các thành phần được phát sinh bằng các ngôn ngữ khác nhau.
b. Giao diện và cách làm việc
Giao diện chính của chương trình
Hình 4.33 – Giao diện chính của chương trình
Làm việc với Rational Rose * Tạo các mô hình
- Bước đầu tiên khi làm việc với Rose đó là tạo một mô hình. Các mô hình có thể
được tạo từ đầu hoặc sử dụng một framework model hiện có (là các mô hình cài đặt sẵn
trong máy cho một số ngôn ngữ như Visual Basic, Java, C++, …). Mô hình Rose và tất
cả các sơ đồ, các đối tượng, các phần tử mô hình khác được lưu trong một tập tin đơn lẻ có đuôi .mdl - Để tạo một mô hình:
Chọn File -> New từ trình đơn, hoặc nhấn nút
trên thanh công cụ chuẩn.
Nếu đã cài đặt Framework Wizard, danh sách các cơ cấu sẵn có sẽ xuất hiện (như
hình dưới đây). Lựa chọn cơ cấu rồi nhắp nút OK, hoặc Cancel nếu không dùng. 96
Hình 4.34. Giao diện của Rational Rose * Lưu các mô hình
- Giống như các ứng dụng khác, bạn nên tạo thói quen lưu tập tin định kỳ, Rose
cũng vậy. Như đã nêu trên, nguyên cả mô hình được lưu trong một tập tin. Ngoài ra, bạn có
thể lưu sổ theo dõi (Log Window) ra một tập tin. - Để lưu một mô hình :
+ Chọn File -> Save từ thanh trình đơn + Hoặc nhấn nút
trên thanh công cụ chuẩn. - Để lưu sổ theo dõi :
+ Lựa chọn cửa sổ theo dõi.
+ Chọn File -> Save Log As từ thanh trình đơn.
+ Nhập tên tập tin cửa sổ theo dõi. Hoặc :
+ Lựa chọn cửa sổ theo dõi. + Nhấn nút
trên thanh công cụ chuẩn.
+ Nhập tên tập tin cửa sổ theo dõi.
* Xuất và nhập các mô hình :
Một trong những lợi ích chính của hướng đối tượng là khả năng dùng lại. Khả
năng dùng lại có thể áp dụng không những cho mã mà còn cho các mô hình. Để vận dụng
đầy đủ khả năng dùng lại, Rose hỗ trợ phương pháp xuất (nhập) các mô hình và các phần
tử của mô hình. Bạn có thể xuất một mô hình hoặc một phần của mô hình và nhập nó vào các mô hình khác
4.2. Mô hình hóa ca sử dụng
4.2.1. Giới thiệu
Trong giai đoạn phân tích, người sử dụng cộng tác cùng nhóm phát triển phần mềm
tạo nên một tổ hợp thông tin quan trọng về yêu cầu đối với hệ thống. Không chỉ là người
cung cấp thông tin, bản thân người sử dụng còn là một thành phần hết sức quan trọng trong 97
bức tranh toàn cảnh đó và nhóm phát triển cần phải chỉ ra được phương thức hoạt động của
hệ thống tương lai theo khung nhìn của người sử dụng. Hiểu được điểm quan trọng này là
chìa khóa để tạo dựng được những hệ thống vừa thoả mãn các yêu cầu đặt ra vừa dễ dàng sử
dụng, thậm chí tạo niềm vui thích trong sử dụng.
Như vậy công cụ giúp ta mô hình hoá hệ thống từ khung nhìn của người sử dụng gọi
là Ca sử dụng. Và để trả lời rõ hơn về Ca sử dụng ta xét một trường hợp sau:
Giả sử tôi quyết định mua một chiếc máy fax mới. Khi đến cửa hàng máy văn phòng,
tôi mới nhận ra là phải chọn lựa trong một danh sách máy móc rất phong phú. Loại máy nào
sẽ được chọn đây? Tôi tự hỏi thật chính xác mình muốn làm gì với chiếc máy fax sẽ mua?
Tôi muốn có những tính năng nào? Tôi muốn dùng bằng giấy thường hay giấy thermal? Tôi
muốn copy bằng cái máy đó? Tôi muốn nối nó với máy tính của mình? Tôi muốn dùng nó
vừa làm máy fax vừa làm scanner? Tôi có cần phải gởi fax thật nhanh đến mức độ cần một
chức năng chọn số tăng tốc? Liệu tôi có muốn sử dụng máy fax này để phân biệt giữa một
cú điện thoại gọi tới và một bản fax gởi tới …?
Tất cả chúng ta đều trải qua những kinh nghiệm như vậy khi quyết định mua một
món hàng nào đó không phải vì niềm vui bộc phát. Việc chúng ta sẽ làm trong những
trường hợp như vậy là một dạng phân tích ca sử dụng: Chúng ta tự hỏi mình sẽ sử dụng sản
phẩm (hay hệ thống) sắp bắt ta bỏ ra một khoản tiền đáng kể đó ra sao? Trả lời xong câu hỏi
trên ta mới có khả năng chọn ra sản phẩm thoả mãn những đòi hỏi của mình. Điều quan
trọng ở đây là phải biết những đòi hỏi đó là gì.
Loại quy trình này đóng vai trò rất quan trọng đối với giai đoạn phân tích của một
nhóm phát triển hệ thống. Người dùng muốn sử dụng hệ thống tương lai, hệ thống mà bạn
sắp thiết kế và xây dựng, như thế nào?
Ca sử dụng là một công cụ trợ giúp cho công việc của nhà phân tích cùng người sử
dụng quyết định tính năng của hệ thống. Một tập hợp các ca sử dụng sẽ làm nổi bật một hệ
thống theo phương diện những người dùng định làm gì với hệ thống này.
Để làm rõ hơn, ta hãy xét một ví dụ nhà băng lẻ. Hệ thống tương lai trong trường hợp
này sẽ só nhiều người sử dụng, mỗi người sẽ giao tiếp với hệ thống cho một mục đích khác biệt:
 Quản trị gia sử dụng hệ thống cho mục đích thống kê
 Nhân viên tiếp khách sử dụng hệ thống để thực hiện các dịch vụ phục vụ khách hàng.
 Nhân viên phòng đầu tư sử dụng hệ thống để thực hiện các giao dịch liên quan đến đầu tư.
 Nhân viên thẩm tra chữ ký sử dụng hệ thống cho mục đích xác nhận chữ ký và
bảo trì thông tin liên quan đến khách hàng.
 Khách hàng giao tiếp với hệ thống (nhà băng) cho các hoạt động sử dụng dịch vụ
như mở tài khoản, gửi tiền vào, rút tiền mặt, … 98
Quá trình tương tác giữa người sử dụng và hệ thống trong mỗi một tình huống kể trên
sẽ khác nhau và phụ thuộc vào chức năng mà người sử dụng muốn thực thi cùng hệ thống.
Nhóm phát triển hệ thống cần phải xây dựng nên một kịch bản nêu bật sự tương tác
cần thiết giữa người sử dụng và hệ thống trong mỗi khả năng hoạt động. Ví dụ như kịch bản
cho sự tương tác giữa nhân viên thu ngân và hệ thống của bộ phận tiết kiệm trong suốt tiến
trình của một giao dịch. Một kịch bản khác ví dụ là chuỗi tương tác xảy ra giữa bộ phận tiết
kiệm và bộ phận đầu tư trong một giao dịch chuyển tiền.
Nhìn chung, có thể coi một ca sử dụng như là tập hợp của một loạt các cảnh kịch
(scenario) về việc sử dụng hệ thống. Mỗi cảnh kịch mô tả một chuỗi các sự kiện. Mỗi một
chuỗi này sẽ được kích hoạt bởi một người nào đó, một hệ thống khác hay là một phần trang
thiết bị nào đó, hoặc là một chuỗi thời gian. Những thực thể kích hoạt nên các chuỗi sự kiện
như thế được gọi là các tác nhân (Actor). Kết quả của chuỗi này phải có giá trị sử dụng đối
với hoặc là tác nhân đã gây nên nó hoặc là một tác nhân khác.
Trong ví dụ nhà băng lẻ ở trên, một số những ca sử dụng dễ thấy nhất là:
 Một khách hàng mở một tài khoản mới.
 Phòng đầu tư tính toán tiền lãi cho các tài khoản đầu tư.
 Một chương trình đầu tư mới được đưa vào áp dụng.
 Yêu cầu chuyển tiền của khách hàng được thực hiện.
 Chuyển tiền theo kỳ hạn từ một tài khoản đầu tư sang một tài khoản tiết kiệm.
Ca sử dụng là một công cụ xuất sắc để khuyến khích những người dùng tiềm năng
nói về hệ thống từ khung nhìn của họ. Đối với người dùng, chẳng phải bao giờ việc thể hiện
và mô tả những ý định trong việc sử dụng hệ thống cũng là chuyện dễ dàng. Một hiện thực
có thật là người sử dụng thường biết nhiều hơn những gì mà họ có thể diễn tả ra: Công cụ ca
sử dụng sẽ giúp cho nhóm phát triển bẻ gãy "lớp băng" đó, ngoài ra một sự trình bày trực
quan cũng cho phép bạn kết hợp các biểu đồ ca sử dụng với các loại biểu đồ khác.
Sáng kiến chủ đạo là lôi cuốn được người dùng tham gia vào những giai đoạn đầu
tiên của quá trình phân tích và thiết kế hệ thống. Việc này sẽ nâng cao xác suất cho việc hệ
thống chung cuộc trở thành một công cụ quen thuộc đối với các người dùng mà nó dự định
sẽ trợ giúp – thay vì là một tập hợp khó hiểu và rối rắm của các khái niệm máy tính mà
người dùng trong giới doanh thương có cảm giác không bao giờ hiểu được và không thể làm việc cùng.
Công tác lôi kéo người sử dụng tham gia tích cực vào quá trình phân tích là nền tảng
quan trọng cho việc tạo dựng một mô hình "thành công", một mô hình dễ được người sử
dụng hiểu và chấp nhận sau khi đã thẩm xác các nhiệm vụ căn bản. Ngoài ra, ca sử dụng
còn giúp nhóm phát triển quyết định các lớp mà hệ thống phải triển khai.
4.2.2. Mô hình hóa ca sử dụng
Ca sử dụng là một kỹ thuật mô hình hóa được sử dụng để mô tả một hệ thống mới sẽ
phải làm gì hoặc một hệ thống đang tồn tại làm gì. Một mô hình ca sử dụng được xây dựng 99
qua một quá trình mang tính vòng lặp (interative), trong đó những cuộc hội thảo bàn luận
giữa nhóm phát triển hệ thống và khách hàng (hoặc/và người sử dụng cuối) sẽ dẫn tới một
đặc tả yêu cầu được tất cả mọi người chấp nhận. Người cha tinh thần của mô hình hóa ca sử
dụng là Ivar Jacobson, ông đã tạo nên kỹ thuật mô hình hóa dựa trên những kinh nghiệm thu
thập được trong quá trình tạo hệ thống AXE của hãng Ericsson. Ca sử dụng đã nhận được
một sự quan tâm đặc biệt lớn lao từ phía cộng đồng khung đối tượng và đã tác động lên rất
nhiều phương pháp khung đối tượng khác nhau.
Những thành phần quan trọng nhất của một mô hình ca sử dụng là ca sử dụng, tác
nhân và hệ thống. Ranh giới của hệ thống được định nghĩa qua chức năng tổng thể mà hệ
thống sẽ thực thi. Chức năng tổng thể được thể hiện qua một loạt các ca sử dụng và mỗi một
ca sử dụng đặc tả một chức năng trọn vẹn, có nghĩa là ca sử dụng phải thực thi toàn bộ chức
năng đó, từ sự kiện được kích hoạt đầu tiên bởi một tác nhân ngoại cảnh cho tới khi chức
năng đòi hỏi được thực hiện hoàn tất. Một ca sử dụng luôn luôn phải cung cấp một giá trị
nào đó cho một tác nhân, giá trị này là những gì mà tác nhân mong muốn từ phía hệ thống.
Tác nhân là bất kỳ một thực thể ngoại cảnh nào mong muốn tương tác với hệ thống. Thường
thường, đó là một người sử dụng của hệ thống, nhưng nhiều khi cũng có thể là một hệ thống
khác hoặc là một dạng máy móc thiết bị phần cứng nào đó cần tương tác với hệ thống.
Trong kỹ thuật mô hình hóa ca sử dụng, hệ thống sẽ có hình dạng của một "hộp đen"
và cung cấp các ca sử dụng. Hệ thống làm điều đó như thế nào, các ca sử dụng được thực thi
ra sao, đó là những khía cạnh chưa được đề cập tới trong giai đoạn này. Trong thực tế, nếu
mô hình hóa ca sử dụng được thực hiện trong những giai đoạn đầu của dự án thì thường nhà
phát triển sẽ không biết ca sử dụng sau này sẽ được thực thi (tức là biến thành những dòng
code thật sự) như thế nào.
Mục tiêu chính yếu đối với các ca sử dụng là:
 Để quyết định và mô tả các yêu cầu về mặt chức năng của hệ thống, đây là kết
quả rút ra từ sự thỏa thuận giữa khách hàng (và/hoặc người sử dụng cuối) và
nhóm phát triển phần mềm.
 Để tạo nên một lời mô tả rõ ràng và nhất quán về việc hệ thống cần phải làm gì,
làm sao để mô hình có thể được sử dụng nhất quán suốt toàn bộ quá trình phát
triển, được sử dụng làm công cụ giao tiếp cho tất cả những người phát triển nên
các yêu cầu này, và để tạo nên một nền tảng cho việc tạo nên các mô hình thiết kế
cung cấp các chức năng được yêu cầu.
 Để tạo nên một nền tảng cho các bước thử nghiệm hệ thống, đảm bảo hệ thống
thỏa mãn đúng những yêu cầu do người sử dụng đưa ra. Trong thực tế thường là
để trả lời câu hỏi: Liệu hệ thống cuối cùng có thực hiện những chức năng mà khởi
đầu khách hàng đã đề nghị?
 Để cung cấp khả năng theo dõi các yêu cầu về mặt chức năng được chuyển thành
các lớp cụ thể cũng như các thủ tục cụ thể trong hệ thống. 100
 Để đơn giản hóa việc thay đổi và mở rộng hệ thống qua việc thay đổi và mở rộng
mô hình ca sử dụng, sau đó chỉ theo dõi riêng những ca sử dụng đã bị thay đổi
cùng những hiệu ứng của chúng trong thiết kế hệ thống và xây dựng hệ thống.
Những công việc cụ thể cần thiết để tạo nên một mô hình ca sử dụng bao gồm:
1. Định nghĩa hệ thống (xác định phạm vi hệ thống)
2. Tìm ra các tác nhân cũng như các ca sử dụng 3. Mô tả ca sử dụng
4. Định nghĩa mối quan hệ giữa các ca sử dụng
5. Kiểm tra và phê chuẩn mô hình.
Đây là một công việc mang tính tương tác rất cao, bao gồm những cuộc thảo luận với
khách hàng và những người đại diện cho các loại tác nhân. Mô hình ca sử dụng bao gồm các
biểu đồ ca sử dụng chỉ ra các tác nhân, ca sử dụng và mối quan hệ của chúng với nhau. Các
biểu đồ này cho ta một cái nhìn tổng thể về mô hình, nhưng những lời mô tả thực sự của
từng ca sử dụng thường lại là văn bản. Vì các mô hình trực quan không thể cung cấp tất cả
các thông tin cần thiết, nên cần thiết phải dùng cả hai kỹ thuật trình bày đó.
Có rất nhiều người quan tâm đến việc sử dụng các mô hình ca sử dụng. Khách hàng
(và/hoặc người sử dụng cuối) quan tâm đến chúng vì mô hình ca sử dụng đặc tả chức năng
của hệ thống và mô tả xem hệ thống có thể và sẽ được sử dụng ra sao. Các Ca sử dụng vì
vậy phải được mô tả trong những thuật ngữ và ngôn ngữ của khách hàng/người sử dụng.
Nhà phát triển cần đến các mô hình ca sử dụng để hiểu hệ thống cần phải làm gì, và
qua đó có được một nền tảng cho những công việc tương lai (các mô hình khác, các cấu trúc
thiết kế và việc thực thi xây dựng hệ thống bằng code).
Các nhóm chuyên gia thử nghiệm tích hợp và thử nghiệm hệ thống cần đến ca sử
dụng để thử nghiệm và kiểm tra xem hệ thống có đảm bảo sẽ thực hiện đúng chức năng đã
được đặc tả trong giai đoạn đầu.
Và cuối cùng, bất kỳ người nào liên quan đến những hoạt động liên kết đến chức
năng của hệ thống đều có thể quan tâm đến các mô hình ca sử dụng; ví dụ như các nhóm
tiếp thị, bán hàng, hỗ trợ khách hàng và các nhóm soạn thảo tài liệu.
Mô hình ca sử dụng mô tả khung nhìn ca sử dụng của hệ thống. Khung nhìn này là
rất quan trọng, bởi nó ảnh hưởng đến tất cả các khung nhìn khác của hệ thống. Cả cấu trúc
logic lẫn cấu trúc physic đều chịu ảnh hưởng từ các ca sử dụng, bởi chức năng được đặc tả
trong mô hình này chính là những chức năng được thực thi trong các cấu trúc kia. Mục đích
cuối cùng là thiết kế ra một giải pháp thỏa mãn các yêu cầu đó.
Mô hình hóa các ca sử dụng chẳng phải chỉ được dùng để nắm bắt các yêu cầu của hệ
thống mới; nó cũng còn được sử dụng để hỗ trợ cho việc phát triển một phiên bản mới của
hệ thống. Khi phát triển một phiên bản mới của hệ thống đang tồn tại, người ta sẽ bổ sung
thêm các chức năng mới vào mô hình ca sử dụng đã có bằng cách thêm vào các tác nhân
mới cũng như các ca sử dụng mới, hoặc là thay đổi đặc tả của các ca sử dụng đã có. Khi bổ 101
sung thêm vào mô hình ca sử dụng đang tồn tại, hãy chú ý để không bỏ ra bất kỳ một chức
năng nào vẫn còn được cần tới.
4.2.3. Biểu đồ ca sử dụng
Ca sử dụng được mô tả trong ngôn ngữ UML qua biểu đồ ca sử dụng và một mô hình
ca sử dụng có thể được chia thành một số lượng lớn các biểu đồ như thế. Một biểu đồ ca sử
dụng chứa các phần tử mô hình biểu thị hệ thống, tác nhân cũng như ca sử dụng và chỉ ra
các mối quan hệ giữa các ca sử dụng.
Lời mô tả nội dung ca sử dụng thường được cung cấp dưới dạng văn bản. Trong
UML, lời mô tả đó được coi là thuộc tính "văn bản" (document) của ca sử dụng. Lời mô tả
này bao chứa những thông tin quan trọng, định nghĩa các yêu cầu và chức năng cụ thể. Thay
cho việc mô tả ca sử dụng bằng văn bản, bạn cũng có thể vẽ một biểu đồ hoạt động (activity
diagram). Mặc dầu vậy, nên nhớ rằng một ca sử dụng cần phải được mô tả sao cho dễ hiểu
và dễ giao tiếp đối với người sử dụng, mà những cấu trúc phức tạp như một biểu đồ hoạt
động có thể gây cảm giác xa lạ đối với những người không quen sử dụng.
Tóm tắt: Một biểu đồ ca sử dụng thể hiện:  Hệ thống  Tác nhân và  Ca sử dụng.
Ví dụ biểu đồ ca sử dụng trong UML:
Hình 4.35 - Một ví dụ biểu đồ ca sử dụng trong UML Trong đó :
 Hệ thống được thể hiện qua hình chữ nhật với tên hệ thống ở bên trên
 Tác nhân được thể hiện qua kí hiệu hình nhân
 Ca sử dụng được thể hiện qua hình ellipse a. Hệ thống
Vì hệ thống là một thành phần của mô hình ca sử dụng nên ranh giới của hệ thống
mà ta muốn phát triển cần phải được định nghĩa rõ ràng. Xin nhớ rằng một hệ thống không
phải bao giờ cũng nhất thiết là một hệ thống phần mềm; nó có thể là một chiếc máy, hoặc là
một doanh nghiệp. Định nghĩa các ranh giới và trách nhiệm của hệ thống không phải bao
giờ cũng là việc dễ dàng, bởi không phải bao giờ người ta cũng rõ ràng nhìn ra tác vụ nào có
khả năng được tự động hóa tốt nhất ở hệ thống này và tác vụ nào thì tốt nhất nên thực hiện
thủ công hoặc dành cho các hệ thống khác. Một khía cạnh khác cần chú ý là hệ thống cần
phải lớn tới mức độ nào trong phiên bản đầu tiên của nó. Cố gắng tối đa cho phiên bản đầu 102
tiên của hệ thống thường là cách mà người ta hay thực hiện, thế nhưng những mục tiêu quá
tầm như vậy có thể khiến cho hệ thống trở nên quá lớn và thời gian để cung cấp hệ thống
quá lâu. Một sáng kiến tốt hơn là xác nhận cho rõ các chức năng căn bản và tập trung vào
việc định nghĩa một kiến trúc hệ thống thích hợp, rõ ràng, có nền tảng rộng mở để nhiều
chức năng hơn có thể được bổ sung vào hệ thống này trong các phiên bản sau.
Yếu tố quan trọng là bạn phải tạo dựng được một bản catalog của các khái niệm (các
thực thể) trung tâm cùng với các thuật ngữ và định nghĩa thích hợp trong những giai đoạn
đầu của thời kỳ phân tích. Đây chưa phải mô hình phạm vi đối tượng, mà đúng hơn là một
cố gắng để mô tả các thuật ngữ của hệ thống hoặc doanh nghiệp mà chúng ta cần mô hình
hóa. Các thuật ngữ sau đó sẽ được dùng để mô tả ca sử dụng. Phương thức cụ thể của
catalog này có thể rất khác nhau; nó có thể là một mô hình khái niệm chỉ ra các mối quan hệ
đơn giản hoặc chỉ là một văn bản chứa các thuật ngữ cùng lời mô tả vắn tắt những thuật ngữ
này trong thế giới thực. b. Tác nhân
Một tác nhân là một người hoặc một vật nào đó tương tác với hệ thống, sử dụng hệ
thống. Trong khái niệm "tương tác với hệ thống", ý chúng ta muốn nói rằng tác nhân sẽ gửi
thông điệp đến hệ thống hoặc là nhận thông điệp xuất phát từ hệ thống, hoặc là thay đổi các
thông tin cùng với hệ thống. Nói một cách ngắn gọn, tác nhân thực hiện các ca sử dụng.
Thêm một điều nữa, một tác nhân có thể là người mà cũng có thể là một hệ thống khác (ví
dụ như là một chiếc máy tính khác được nối kết với hệ thống của chúng ta hoặc một loại
trang thiết bị phần cứng nào đó tương tác với hệ thống).
Một tác nhân là một dạng thực thể (một lớp), chứ không phải một thực thể. Tác nhân
mô tả và đại diện cho một vai trò, chứ không phải là một người sử dụng thật sự và cụ thể
của hệ thống. Nếu một anh chàng John nào đó muốn mua hợp đồng bảo hiểm từ một hãng
bảo hiểm, thì vai trò của anh ta sẽ là người mua hợp đồng bảo hiểm, và đây mới là thứ mà
chúng ta muốn mô hình hóa, chứ không phải bản thân anh chàng John. Trong thực tế, một
con người cụ thể có thể đóng vai trò làm nhiều tác nhân trong một hệ thống: một nhân viên
ngân hàng đồng thời cũng có thể là khách hàng của chính ngân hàng đó. Mặt khác, số lượng
các vai trò mà một con người cụ thể được phép đảm trách trong một hệ thống cũng có thể bị
hạn chế, ví dụ cùng một người không được phép vừa soạn hóa đơn vừa phê duyệt hóa đơn
đó. Một tác nhân sẽ có một tên, và cái tên này cần phải phản ánh lại vai trò của tác nhân. Cái
tên đó không được phản ánh lại một thực thể riêng biệt của một tác nhân, mà cũng không
phản ánh chức năng của tác nhân đó.
Một tác nhân giao tiếp với hệ thống bằng cách gửi hoặc là nhận thông điệp, giống
như khái niệm chúng ta đã quen biết trong lập trình khung đối tượng. Một ca sử dụng bao
giờ cũng được kích hoạt bởi một tác nhân gửi thông điệp đến cho nó. Khi một ca sử dụng
được thực hiện, ca sử dụng có thể gửi thông điệp đến một hay là nhiều tác nhân. Những
thông điệp này cũng có thể đến với các tác nhân khác, bên cạnh chính tác nhân đã kích hoạt và gây ra ca sử dụng.
Tác nhân cũng có thể được xếp loại. Một tác nhân chính (Primary Actor) là tác nhân
sử dụng những chức năng căn bản của hệ thống, tức là các chức năng chính. Ví dụ, trong 103
một hệ thống bảo hiểm, một tác nhân căn bản có thể là tác nhân xử lý việc ghi danh và quản
lý các hợp đồng bảo hiểm. Một tác nhân phụ (secondary actor) là tác nhân sử dụng các chức
nặng phụ của hệ thống, ví dụ như các chức năng bảo trì hệ thống như quản trị ngân hàng dữ
liệu, giao tiếp, back-up và các tác vụ quản trị khác. Một ví dụ cho tác nhân phụ có thể là nhà
quản trị hoặc là một nhân viên sử dụng chức năng trong hệ thống để rút ra các thông tin
thống kê về doanh nghiệp. Cả hai loại tác nhân này đều được mô hình hóa để đảm bảo mô tả
đầy đủ các chức năng của hệ thống, mặc dù các chức năng chính mới thật sự nằm trong mối
quan tâm chủ yếu của khách hàng.
Tác nhân còn có thể được định nghĩa theo dạng tác nhân chủ động (active actor) hay
tác nhân thụ động (passive actor). Một tác nhân chủ động là tác nhân gây ra ca sử dụng,
trong khi tác nhân thụ động không bao giờ gây ra ca sử dụng mà chỉ tham gia vào một hoặc là nhiều ca sử dụng. Tìm tác nhân
Khi nhận diện tác nhân, có nghĩa là chúng ta lọc ra các thực thể đáng quan tâm theo
khía cạnh sử dụng và tương tác với hệ thống. Sau đó chúng ta có thể thử đặt mình vào vị trí
của tác nhân để cố gắng nhận ra các yêu cầu và đòi hỏi của tác nhân đối với hệ thống và xác
định tác nhân cần những ca sử dụng nào. Có thể nhận diện ra các tác nhân qua việc trả lời
một số các câu hỏi như sau:
 Ai sẽ sử dụng những chức năng chính của hệ thống (tác nhân chính)?
 Ai sẽ cần sự hỗ trợ của hệ thống để thực hiện những tác vụ hàng ngày của họ?
 Ai sẽ cần bảo trì, quản trị và đảm bảo cho hệ thống hoạt động (tác nhân phụ)?
 Hệ thống sẽ phải xử lý và làm việc với những trang thiết bị phần cứng nào?
 Hệ thống cần phải tương tác với các hệ thống khác nào? Nhóm các hệ thống này
được chia ra làm hai nhóm, nhóm kích hoạt cho mối quan hệ với hệ thống, và
nhóm mà hệ thống cần phải xây dựng của chúng ta sẽ thiết lập quan hệ. Khái
niệm hệ thống bao gồm cả các hệ thống máy tính khác cũng như các ứng dụng
khác trong chính chiếc máy tính mà hệ thống này sẽ hoạt động.
 Ai hay cái gì quan tâm đến kết quả (giá trị) mà hệ thống sẽ sản sinh ra?
Khi đi tìm những người sử dụng hệ thống, đừng quan sát những người đang ngồi ở
trước màn hình máy tính. Nên nhớ rằng, người sử dụng có thể là bất kỳ người nào hay bất
kỳ vật nào tương tác hoặc trực tiếp hoặc gián tiếp với hệ thống và sử dụng các dịch vụ của
hệ thống này để đạt đến một kết quả nào đó. Đừng quên rằng mô hình hóa ca sử dụng được
thực hiện để mô hình hóa một doanh nghiệp, vì thế tác nhân thường thường là khách hàng
của doanh nghiệp đó. Từ đó suy ra họ không phải là người sử dụng theo nghĩa đơn giản và
trực tiếp là người ngồi trước màn hình máy tính và thao tác với máy tính.
Để có thể nhận dạng được tốt nhiều tác nhân khác nhau, hãy tiến hành nghiên cứu
những người sử dụng của hệ thống hiện thời (một hệ thống thủ công hoặc một hệ thống
đang tồn tại), hỏi xem họ đóng những vai trò nào khi thực thi công việc hàng ngày của họ 104
với hệ thống. Cũng người sử dụng đó có thể thực thi nhiều vai trò khác nhau tại nhiều thời
điểm khác nhau, tùy thuộc vào việc chức năng nào trong hệ thống đang được sử dụng.
Xin nhắc lại, một tác nhân là một vai trò (một lớp), chứ không phải một thực thể
riêng lẻ. Mặc dù vậy, khi cung cấp ví dụ là một vài các thực thể của một tác nhân, bạn có
thể đảm bảo rằng tác nhân đó thật sự tồn tại. Một tác nhân phải có một sự liên kết
(Association) nào đó với một hoặc là nhiều Ca sử dụng. Mặc dù có những tác nhân có thể
không kích hoạt nên một Ca sử dụng nào, nhưng tác nhân đó sẽ giao tiếp ít nhất với một Ca
sử dụng tại một thời điểm nào đó. Cần phải đặt tên cho tác nhân làm sao để tên phản ánh
đúng vai trò của tác nhân đó trong hệ thống.
Biểu diễn tác nhân trong ngôn ngữ UML
Tác nhân trong UML là một lớp với biệt ngữ "Actor" (Tác nhân) và tên của lớp này
là tên của tác nhân (phản ánh vai trò của tác nhân). Một lớp tác nhân có thể vừa có thuộc
tính (attribute) lẫn hành vi (method) cũng như một thuộc tính tài liệu (document) mô tả tác
nhân đó. Một lớp tác nhân có một biểu tượng chuẩn hóa, biểu tượng "hình nhân":
Hình 4.36 - biểu tượng tác nhân trong UML
c. Ca sử dụng
Một ca sử dụng là đại diện cho một chức năng nguyên vẹn mà một tác nhân nhận
được. Một ca sử dụng trong ngôn ngữ UML được định nghĩa là một tập hợp của các chuỗi
hành động mà một hệ thống thực hiện để tạo ra một kết quả có thể quan sát được, tức là một
giá trị đến với một tác nhân cụ thể. Những hành động này có thể bao gồm việc giao tiếp với
một loạt các tác nhân cũng như thực hiện tính toán và công việc nội bộ bên trong hệ thống.
Các tính chất tiêu biểu của một ca sử dụng là:
 Một ca sử dụng bao giờ cũng được gây ra bởi một tác nhân, được thực hiện nhân
danh một tác nhân nào đó. Tác nhân phải ra lệnh cho hệ thống để thực hiện ca sử
dụng đó, dù là trực tiếp hay gián tiếp. Hiếm khi có tác nhân không liên quan đến
việc gây ra một ca sử dụng nào đó.
 Một ca sử dụng phải cung cấp một giá trị cho một tác nhân. Giá trị đó không phải
bao giờ cũng cần thiết phải nổi trội ra ngoài, nhưng luôn phải được thấy rõ.
 Một ca sử dụng là phải hoàn tất. Một trong những lỗi thường gặp là sẻ chia một
ca sử dụng thành các ca sử dụng nhỏ hơn, và các ca sử dụng này thực thi lẫn nhau
giống như việc gọi hàm cho một ngôn ngữ lập trình. Một ca sử dụng sẽ không
được coi là hoàn tất chừng nào mà giá trị cuối cùng của nó chưa được sản sinh ra,
thậm chí ngay cả khi đã xẩy ra nhiều động tác giao tiếp (ví dụ như đối thoại với người sử dụng). 105
Ca sử dụng được nối với tác nhân qua liên kết (association). Đường liên kết chỉ ra
những tác nhân nào giao tiếp với ca sử dụng nào. Mối liên kết bình thường ra là một mối
quan hệ 1-1 và không có khung. Điều đó muốn nói lên rằng một thực thể của lớp tác nhân sẽ
giao tiếp với một thực thể của một ca sử dụng và cả hai có thể giao tiếp với nhau trong cả
hai chiều. Một ca sử dụng sẽ được đặt tên theo một thực thể mà ca sử dụng sẽ thực hiện, ví
dụ như ký hợp đồng bảo hiểm, cập nhật danh sách, …, và thường là một cụm từ hơn là chỉ một từ riêng lẻ.
Một ca sử dụng là một lớp, chứ không phải một thực thể. Nó mô tả trọn vẹn một
chức năng, kể cả các giải pháp bổ sung và thay thế có thể có, các lỗi có thể xảy ra cũng như
những ngoại lệ có thể xảy ra trong quá trình thực thi. Một kết quả của sự thực thể hóa một
ca sử dụng được gọi là một cảnh kịch (scenario) và nó đại diện cho một sự sử dụng cụ thể
của hệ thống (một đường dẫn thực thi riêng biệt qua hệ thống). Ví dụ một cảnh kịch của ca
sử dụng "Ký hợp đồng bảo hiểm" có thể là "John liên hệ với hệ thống qua điện thoại rồi sau
đó ký hợp đồng bảo hiểm ô tô cho chiếc xe Toyota Carolla mà anh ta vừa mua." Tìm ca sử dụng
Quá trình tìm các ca sử dụng bắt đầu với các tác nhân đã được xác định ở phần trước.
Đối với mỗi tác nhân, hãy hỏi các câu hỏi sau:
- Tác nhân này cần những chức năng nào từ hệ thống? Hành động chính của tác nhân là gì?
Ví dụ cho một giao dịch rút tiền bên máy ATM trong một nhà băng lẻ, các hành động
chính của khách hàng (tác nhân) có thể là : + Đút thẻ vào máy ATM + Nhập password
+ Nhập loại chuyển dịch
+ Nhập số tiền mặt muốn rút ra
+ Yêu cầu về loại tiền + Nhặt tiền ra từ máy
+ Rút thẻ và tờ in kết quả giao dịch
- Tác nhân có cần phải đọc, phải tạo, phải hủy bỏ, phải sửa chữa, hay là lưu trữ một
loại thông tin nào đó trong hệ thống? Ví dụ :
+ Nhân viên nhà băng liệu có quyền truy xuất hay thay đổi mức tiền lãi?
+ Khách hàng có thể thay đổi password của mình.
- Tác nhân có cần phải báo cho hệ thống biết về những sự kiện nào đó? Những sự
kiện như thế sẽ đại diện cho những chức năng nào? Ví dụ : 106
+ Khách hàng kết thúc tài khoản, nhân viên cung cấp những thông tin này cho hệ thống.
+ Có một chương trình đầu tư mới, các chi tiết của chương trình này sẽ phải được
nhân viên nhà băng nhập vào hệ thống.
- Hệ thống có cần phải thông báo cho Actor về những thay đổi bất ngờ trong nội bộ hệ thống?
+ Trong tài khoản còn quá ít tiền.
+ Ba kỳ liên tiếp tiền lương chưa đổ về tài khoản.
- Công việc hàng ngày của tác nhân có thể được đơn giản hóa hoặc hữu hiệu hóa qua
các chức năng mới trong hệ thống (thường đây là những chức năng tiêu biểu chưa được tự
động hóa trong hệ thống)? - Các câu hỏi khác:
+ Ca sử dụng có thể được gây ra bởi các sự kiện nào khác? Ví dụ :
Sự kiện thời gian: Cuối tháng, hết hạn đầu tư.
Sự kiện bình thường của hệ thống: Tự động chuyển tiền theo các lệnh xác định trước.
Các sự kiện bất bình thường: Hợp đồng đầu tư kết thúc trước thời hạn.
+ Hệ thống cần những thông tin đầu vào/đầu ra nào? Những thông tin đầu vào/đầu ra
đó từ đâu tới và sẽ đi đâu?
+ Khó khăn và thiếu hụt chính trong hệ thống hiện thời nằm ở đâu (thủ công /tự động hóa)?
Đối với nhóm câu hỏi cuối không có nghĩa là ca sử dụng ở đây không có tác nhân,
mà tác nhân sẽ được nhận ra chỉ khi chúng ta nhận diện ra các ca sử dụng này và sau đó xác
định tác nhân dựa trên cơ sở là ca sử dụng. Xin nhắc lại, một ca sử dụng bao giờ cũng phải
được liên kết với ít nhất một tác nhân.
Ví dụ tìm ca sử dụng
Nhà băng ABC đưa ra các yêu cầu sau: Một khách hàng có thể muốn gửi tiền vào, rút
tiền ra hoặc đơn giản kiểm tra lại số tiền trong tài khoản của anh ta qua máy tự động rút tiền
(ATM). Khi đưa tiền vào hoặc rút tiền ra, cần phải ghi ra giấy kết quả những chuyển dịch đã
thực hiện và trao tờ giấy này cho khách hàng.
Quan sát các chức năng căn bản và các thành phần tham gia, ta thấy có hai tác nhân
dễ nhận ra nhất là khách hàng và nhân viên thu ngân. 107
Hình 4.37 – Các ca sử dụng trong hệ thống ATM
Qua đó, có thể nhân dạng các ca sử dụng sau: + Gửi tiền vào. + Rút tiền ra.
+ Kiểm tra mức tiền trong tài khoản
+ Thực hiện các chuyển dịch nội bộ hệ thống
+ In kết quả các chuyển dịch đã thực hiện.
Ca sử dụng gửi tiền vào và rút tiền ra phụ thuộc vào ca sử dụng thực hiện các chuyển
dịch trong nội bộ hệ thống, việc thực hiện này về phần nó lại phụ thuộc vào chức năng in ra
các công việc đã được thực hiện. Kiểm tra mức tiền trong tài khoản là một ca sử dụng độc
lập, không phụ thuộc vào các ca sử dụng khác.
4.2.4. Các biến thể trong một ca sử dụng
Mỗi ca sử dụng sẽ có một dòng hành động chính (Basic Course). Đó là tiến trình
bình thường hay tiến trình mong đợi đối với ca sử dụng này.
Ngoài ra, có thể còn có một hay nhiều dòng hành động thay thế (Alternative) khác.
Chúng có thể được chia làm hai nhóm chính:
+ Thay thế bình thường (Normal Alternative)
+ Điều kiện gây lỗi (Error Condidtions)
Những gì mang tính bình thường hơn trong ca sử dụng được gọi là thay thế bình
thường. Có thể mô tả các dòng hành động thay thế bằng từ ngữ (xem phần tài liệu ca sử dụng ).
Ví dụ một khách hàng có thể chọn các loại giao dịch sau của ATM: + Gửi tiền vào + Rút tiền ra
+ Kiểm tra mức tiền trong tài khoản
Đây là những ví dụ cho các dòng hành động thay thế bình thường. 108
Hình 4.38 – Các tiến trình trong hệ thống ATM
Điều kiện gây lỗi đại diện cho những bước tiến hành bất bình thường trong một ca sử
dụng. Cần phải tính trước đến những điều kiện gây lỗi đó, ví dụ :
+ Mức tiền trong tài khoản không đủ để tiến hành giao dịch + Password không đúng + ATM bị nghẽn thẻ
Hình vẽ trên nêu bật dòng hành động chính và những dòng hành động thay thế cũng
như sự khác biệt của chúng đối với tiến trình mong đợi của ca sử dụng.
4.2.5. Quan hệ giữa các ca sử dụng
Có ba loại quan hệ ca sử dụng: Quan hệ mở rộng, quan hệ sử dụng và quan hệ tạo
nhóm. Quan hệ mở rộng và quan hệ sử dụng là hai dạng khác nhau của tính thừa kế. Quan
hệ tạo nhóm là một phương cách để đặt nhiều ca sử dụng chung với nhau vào trong một gói.
a. Quan hệ mở rộng
Nhiều khi trong quá trình phát triển ca sử dụng, người ta thấy một số ca sử dụng đã
tồn tại cung cấp một phần những chức năng cần thiết cho một ca sử dụng mới. Trong một
trường hợp như vậy, có thể định nghĩa một ca sử dụng mới là ca sử dụng cũ cộng thêm một
phần mới. Một ca sử dụng như vậy được gọi là một ca sử dụng mở rộng (Extended Ca sử
dụng ). Trong quan hệ mở rộng, ca sử dụng gốc (Base Ca sử dụng) được dùng để mở rộng
phải là một ca sử dụng hoàn thiện. Ca sử dụng mở rộng không nhất thiết phải sử dụng toàn
bộ hành vi của ca sử dụng gốc.
Biểu đồ sau chỉ ra ca sử dụng “Ký hợp đồng mua ô tô” là ca sử dụng mở rộng của
"Ký hợp đồng bảo hiểm”. 109
Hình 4.39 - Quan hệ mở rộng giữa các ca sử dụng
Quan hệ mở rộng giữa các ca sử dụng được biểu thị bằng đoạn thẳng với hình tam
giác rỗng trỏ về phía ca sử dụng được dùng để mở rộng, đi kèm với stereotype <>.
b. Quan hệ sử dụng
Khi một nhóm các ca sử dụng cùng chung một hành vi nào đó thì hành vi này có thể
được tách riêng ra thành một ca sử dụng riêng biệt và nó có thể được sử dụng bởi các ca sử
dụng kia, một mối quan hệ như vậy được gọi là quan hệ sử dụng.
Trong quan hệ sử dụng, phải sử dụng toàn bộ ca sử dụng khái quát hóa, nói một cách
khác, ta có một ca sử dụng này sử dụng toàn bộ một ca sử dụng khác. Các hành động trong
ca sử dụng khái quát hóa không cần phải được sử dụng trong cùng một tiến trình. Chúng có
thể được trộn lẫn với các hành động xảy ra trong ca sử dụng chuyên biệt hóa.
Hình 4.40 - Quan hệ sử dụng giữa các ca sử dụng
Quan hệ sử dụng giữa các ca sử dụng được biểu thị bằng đoạn thẳng với hình tam
giác rỗng trỏ về phía ca sử dụng được sử dụng, đi kèm với stereotype <>.
c. Quan hệ chung nhóm
Khi một số các ca sử dụng cùng xử lý các chức năng tương tự hoặc có thể liên quan
đến nhau theo một phương thức nào đó, người ta thường nhóm chúng lại với nhau.
Nhóm các ca sử dụng được thực hiện bằng khái niệm "Gói" (Package) của UML. Gói
không cung cấp giá trị gia tăng cho thiết kế.
Ví dụ: tất cả các ca sử dụng có liên quan đến sự tương tác giữa khách hàng và nhân
viên thu ngân sẽ được nhóm thành "Package Khách hàng- N/v thu ngân" 110
Hình 4.41 – Package của UML
Tóm tắt về ca sử dụng với máy ATM trong ngân hàng lẻ:
Cho tới nay chúng ta đã xác định được một vài ca sử dụng, phân tích dòng hành động
chính cũng như các dòng hành động thay thế, cũng như rút ra các mối quan hệ giữa chúng.
Biểu đồ sau tổng hợp những thông tin đã thu thập được về nhóm các ca sử dụng căn bản của một hệ thống ATM.
Hình 4.42 - Biểu đồ một số ca sử dụng trong hệ thống ATM
4.2.6. Mô tả ca sử dụng
Như đã trình bày, lời mô tả một ca sử dụng thường được thực hiện trong văn bản.
Đây là lời đặc tả đơn giản và nhất quán về việc các tác nhân và các ca sử dụng (hệ thống)
tương tác với nhau ra sao. Nó tập trung vào ứng xử đối ngoại của hệ thống và không đề cập
tới việc thực hiện nội bộ bên trong hệ thống. Ngôn ngữ và các thuật ngữ được sử dụng trong
lời mô tả chính là ngôn ngữ và các thuật ngữ được sử dụng bởi khách hàng/người dùng.
Văn bản mô tả cần phải bao gồm những điểm sau:
 Mục đích của ca sử dụng: Mục đích chung cuộc của ca sử dụng là gì? Cái gì cần
phải được đạt tới? Ca sử dụng nói chung đều mang tính khung mục đích và mục
đích của mỗi ca sử dụng cần phải rõ ràng.
 Ca sử dụng được khởi chạy như thế nào: Tác nhân nào gây ra sự thực hiện ca sử
dụng này? Trong hoàn cảnh nào?
 Chuỗi các thông điệp giữa tác nhân và ca sử dụng: Ca sử dụng và các tác nhân
trao đổi thông điệp hay sự kiện nào để thông báo lẫn cho nhau, cập nhật hoặc
nhận thông tin và giúp đỡ nhau quyết định? Yếu tố nào sẽ mô tả dòng chảy chính
của các thông điệp giữa hệ thống và tác nhân, và những thực thể nào trong hệ
thống được sử dụng hoặc là bị thay đổi? 111
 Dòng chảy thay thế trong một ca sử dụng: Một ca sử dụng có thể có những dòng
thực thi thay thế tùy thuộc vào điều kiện. Hãy nhắc đến các yếu tố này, nhưng chú
ý đừng mô tả chúng quá chi tiết đến mức độ chúng có thể “che khuất“ dòng chảy
chính của các hoạt động trong trường hợp căn bản. Những động tác xử lý lỗi đặc
biệt sẽ được mô tả thành các ca sử dụng khác.
 Ca sử dụng sẽ kết thúc với một giá trị đối với tác nhân như thế nào: Hãy mô tả khi
nào ca sử dụng được coi là đã kết thúc, và loại giá trị mà nó cung cấp đến tác nhân.
Hãy nhớ rằng lời mô tả này sẽ xác định những gì được thực thi có liên quan đến tác
nhân bên ngoài, chứ không phải những sự việc được thực hiện bên trong hệ thống. Văn bản
phải rõ ràng, nhất quán, khiến cho khách hàng có thể dễ dàng hiểu và thẩm tra chúng (để rồi
đồng ý rằng nó đại diện cho những gì mà anh/cô ta muốn từ phía hệ thống). Tránh dùng
những câu văn phức tạp, khó diễn giải và dễ hiểu lầm.
Một ca sử dụng cũng có thể được mô tả qua một biểu đồ hoạt động. Biểu đồ hoạt
động này chỉ ra chuỗi các hành động, thứ tự của chúng, các quyết định chọn lựa để xác định
xem hành động nào sau đó sẽ được thực hiện.
Để bổ sung cho lời mô tả một ca sử dụng, người ta thường đưa ra một loạt các cảnh
kịch cụ thể để minh họa điều gì sẽ xảy ra một khi ca sử dụng này được thực thể hóa. Lời mô
tả cảnh kịch minh họa một trường hợp đặc biệt, khi cả tác nhân lẫn ca sử dụng đều được coi
là một thực thể cụ thể. Khách hàng có thể dễ dàng hiểu hơn toàn bộ một ca sử dụng phức
tạp nếu có những cảnh kịch được mô tả thực tiễn hơn, minh họa lại lối ứng xử và phương
thức hoạt động của hệ thống. Nhưng xin nhớ rằng, một lời mô tả cảnh kịch chỉ là một sự bổ
sung chứ không phải là ứng cử viên để thay thế cho lời mô tả ca sử dụng.
Sau khi các ca sử dụng đã được mô tả, một hoạt động và một công việc đặc biệt cần
phải thực hiện là thẩm tra xem các mối quan hệ có được nhận diện không. Trước khi tất cả
các ca sử dụng được mô tả, nhà phát triển chưa thể có được những kiến thức hoàn tất và
tổng thể để xác định các mối quan hệ thích hợp, thử nghiệm làm theo phương thức đó có thể
sẽ dẫn đến một tình huống nguy hiểm. Trong thời gian thực hiện công việc này, hãy trả lời các câu hỏi sau:
 Tất cả các tác nhân liên quan đến một ca sử dụng có mối liên kết giao tiếp với ca sử dụng đó không?
 Có tồn tại những sự tương tự giữa một loạt các tác nhân minh họa một vai trò
chung và nhóm này liệu có thể được mô tả là một lớp tác nhân căn bản (base class)?
 Có tồn tại những sự tương tự giữa một loạt các ca sử dụng, minh họa một dòng
chảy hành động chung? Nếu có, liệu điều này có thể được mô tả là một mối quan
hệ sử dụng đến với một ca sử dụng khác?
 Có tồn tại những trường hợp đặc biệt của một ca sử dụng có thể được mô tả là
một mối quan hệ mở rộng? 112
 Có tồn tại một tác nhân nào hay một ca sử dụng nào không có mối liên kết giao
tiếp? Nếu có, chắc chắn ở đây đã có chuyện lầm lạc, sai trái: Tại sao lại xuất hiện tác nhân này?
 Có lời yêu cầu nào về chức năng đã được xác định, nhưng lại không được bất kỳ
một ca sử dụng nào xử lý? Nếu thế, hãy tạo một ca sử dụng cho yêu cầu đó.
4.3. Biểu đồ hoạt động (Activity Diagram)
Biểu đồ hoạt động nắm bắt hành động và các kết quả của chúng. Biểu đồ hoạt động
tập trung vào công việc được thực hiện trong khi thực thi một thủ tục (hàm), các hoạt động
trong một lần thực thi một trường hợp sử dụng hoặc trong một đối tượng. Biểu đồ hoạt động
là một biến thể của biểu đồ trạng thái và có một mục tiêu tương đối khác, đó là nắm bắt
hành động (công việc và những hoạt động phải được thực hiện) cũng như kết quả của chúng
theo sự biến đổi trạng thái. Các trạng thái trong biểu đồ hoạt động (được gọi là các trạng
thái hành động) sẽ chuyển sang giai đoạn kế tiếp khi hành động trong trạng thái này đã được
thực hiện xong (mà không xác định bất kỳ một sự kiện nào theo như nội dung của biểu đồ
trạng thái). Một sự điểm phân biệt khác giữa biểu đồ hoạt động và biểu đồ trạng thái là các
hành động của nó được định vị trong các luồng (swimlane). Một luồng sẽ gom nhóm các
hoạt động, chú ý tới khái niệm người chịu trách nhiệm cho chúng hoặc chúng nằm ở đâu
trong một tổ chức. Một biểu đồ hoạt động là một phương pháp bổ sung cho việc miêu tả
tương tác, đi kèm với trách nhiệm thể hiện rõ các hành động xảy ra như thế nào, chúng làm
gì (thay đổi trạng thái đối tượng), chúng xảy ra khi nào (chuỗi hành động), và chúng xảy ra
ở đâu (luồng hành động).
Biểu đồ hoạt động có thể được sử dụng cho nhiều mục đích khác nhau, ví dụ như:
 Để nắm bắt công việc (hành động) sẽ phải được thực thi khi một thủ tục được
thực hiện. Đây là tác dụng thường gặp nhất và quan trọng nhất của biểu đồ hoạt động.
 Để nắm bắt công việc nội bộ trong một đối tượng.
 Để chỉ ra một nhóm hành động liên quan có thể được thực thi ra sao, và chúng sẽ
ảnh hưởng đến những đối tượng nằm xung quanh chúng như thế nào.
 Để chỉ ra một trường hợp sử dụng có thể được thực thể hóa như thế nào, theo khái
niệm hành động và các sự biến đổi trạng thái của đối tượng.
 Để chỉ ra một doanh nghiệp hoạt động như thế nào theo các khái niệm công nhân
(tác nhân), qui trình nghiệp vụ (workflow), hoặc tổ chức và đối tượng (các khía
cạnh vật lý cũng như tri thức được sử dụng trong doanh nghiệp).
Biểu đồ hoạt động có thể được coi là một loại Flow chart. Điểm khác biệt là Flow
Chart bình thường ra chỉ được áp dụng đối với các qui trình tuần tự, biểu đồ hoạt động có
thể xử lý cả các các qui trình song song.
Hành động và sự thay đổi trạng thái
Một hành động được thực hiện để sản sinh ra một kết quả. Việc thực thi của thủ tục
có thể được miêu tả dưới dạng một tập hợp của các hành động liên quan, sau này chúng sẽ 113
được chuyển thành các dòng code thật sự. Theo như định nghĩa ở phần trước, một biểu đồ
hoạt động chỉ ra các hành động cùng mối quan hệ giữa chúng và có thể có một điểm bắt đầu
và một điểm kết thúc. Biểu đồ hoạt động sử dụng cũng cùng những ký hiệu như trong biểu
đồ trạng thái bình thường.
Khi một người gọi tác vụ PrintAllCustomer (trong lớp CustomerWindow), các hành
động khởi động. hành động đầu tiên là hiện một hộp thông báo lên màn hình; hành động thứ
hai là tạo một tập tin postscript; hành động thứ ba là gởi file postscript đến máy in; và hành
động thứ tư là xóa hộp thông báo trên màn hình. Các hành động được chuyển tiếp tự động;
chúng xảy ra ngay khi hành động trong giai đoạn nguồn được thực hiện.
Các sự thay đổi có thể được bảo vệ bởi các điều kiện canh giữ (Guard-condition), các
điều kiện này phải được thỏa mãn thì sự thay đổi mới nổ ra. Một ký hiệu hình thoi được sử
dụng để thể hiện một quyết định. Ký hiệu quyết định có thể có một hoặc nhiều sự thay đổi
đi vào và một hoặc nhiều sự thay đổi đi ra được dán nhãn đi kèm các điều kiện bảo vệ. Bình
thường ra, một trong số các sự thay đổi đi ra bao giờ cũng được thỏa mãn (là đúng).
Một sự thay đổi được chia thành hai hay nhiều sự thay đổi khác sẽ dẫn đến các hành
động xảy ra song song. Các hành động được thực hiện đồng thời, mặc dù chúng cũng có thể
được thực hiện lần lượt từng cái một. Yếu tố quan trọng ở đây là tất cả các thay đổi đồng
thời phải được thực hiện trước khi chúng được thống nhất lại với nhau (nếu có). Một đường
thẳng nằm ngang kẻ đậm (còn được gọi là thanh đồng hộ hóa – Synchronisation Bar) chỉ
rằng một sự thay đổi được chia thành nhiều nhánh khác nhau và chỉ ra một sự chia sẻ thành
các hành động song song. Cũng đường thẳng đó được sử dụng để chỉ ra sự thống nhất các nhánh.
Kí hiệu UML cho các thành phần căn bản của biểu đồ hoạt động:
Hoạt động (Activity): là một qui trình được định nghĩa rõ ràng, có thể được thực thi
qua một hàm hoặc một nhóm đối tượng. Hoạt động được thể hiện bằng hình chữ nhật bo tròn cạnh.
Thanh đồng bộ hóa (Synchronisation bar): chúng cho phép ta mở ra hoặc là đóng lại
các nhánh chạy song song nội bộ trong tiến trình. 114
Hình 4.43 - Thanh đồng bộ hóa
Điều kiện canh giữ (Guard Condition): các biểu thức logic có giá trị hoặc đúng hoặc
sai. Điều kiện canh giữ được thể hiện trong ngoặc vuông, ví dụ: [Customer existing].
Điểm quyết định (Decision Point): được sử dụng để chỉ ra các sự thay đổi khả thi. Kí hiệu là hình thoi.
Hình sau đây miêu tả một đoạn biểu đồ hoạt động của máy ATM. Sau khi thẻ được
đưa vào máy, ta thấy có ba hoạt động song song: Xác nhận thẻ Xác nhận mã số PIN
Xác nhận số tiền yêu cầu được rút
Chỉ khi sử dụng biểu đồ hoạt động, các hoạt động song song như vậy mới có thể
được miêu tả. Mỗi một hoạt động xác nhận bản thân nó cũng đã có thể là một quá trình riêng biệt.
Hình 4.44 - Biểu đồ hoạt động của máy ATM 115
Chương 5. Nắm bắt và phân tích yêu cầu
5.1. Vai trò của nắm bắt và phân tích yêu cầu
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 kỹ 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 đặc tả yêu cầu, là tài
liệu ràng buộc giữa khách hàng và người phát triển và 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 yêu cầu và người phân tích hiểu, 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). 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 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, ví dụ như ở bước thiết kế hay mã hóa.
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ù của tổ chức đặt hàng nó, do đó nó thường
khó hiểu, khó định nghĩa và 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, thậm chí 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 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 kỹ sư phần mềm (người phát triển), kỹ sư hệ thống (sẽ làm việc bảo trì)... 116
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 đủ
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.
5.2. Các hoạt động phân tích và đặc tả yêu cầu
5.2.1. 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
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ũ, đá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 các điểm
tốt và không tốt của các giải pháp đó (như tính năng của hệ thống, giá cả cài đặt, bảo trì,
việc đào tạo người sử dụng...). Đó 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 tâm chí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 coi như nền tảng cho hầu hết các hệ thống (các 117
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
- sự ảnh hưởng tới các sản phẩm lợi nhuận khác
- chi phí cho 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 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 trôi chảy 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.
5.2.2. Phân tích yêu cầu
Sau khi nghiên cứu khả thi, bước quan trọng đầu tiên là phân tích hoặc suy luận các
yêu cầu. Các chuyên gia phát triển phần mềm làm việc với các khách hàng và người sử
dụng cuối cùng để tìm ra các lĩnh vực ứng dụng mà cấp hệ thống phần mềm phải đáp ứng,
việc thực hiện các yêu cầu hệ thống do phần mềm và các yếu tố khác quy định, chẳng hạn
như phần cứng, các thiết bị ngoại vi… 118
Phân tích yêu cầu là một bước quan trọng, tính khả thi của hệ thống sau này phụ
thuộc nhiều vào quá trình trao đổi giữa nhu cầu của khách hàng và nhà cung cấp với các
công việc được tự động hóa. Nếu việc phân tích không đáp ứng được nhu cầu thực của
khách hàng, hệ thống sau khi hình thành sẽ không đáp ứng được các yêu cầu.
Phân tích yêu cầu có thể còn liên quan đến sự đa dạng của các cấp bậc chức vụ khác
nhau của các nhân viên trong cùng một tổ chức. Hay nói cach khác, vấn đề bảo mật gây ra
rất nhiều khó khăn trong phân tích yêu cầu. Điều này ảnh hưởng tới người tác động cuối
cùng vào hệ thống, người tổ chức và thiết đặt hệ thống. Các nhà đầu tư có ảnh hưởng trực
tiếp hoặc gián tiếp tới những yêu cầu của hệ thống.
Bước phân tích là khó bởi một số lý do:
- Trong hầu hết các trường hợp, các nhà đầu tư không biết thực sự họ muốn gì ở hệ
thống máy tính. Thậm chí khi họ có một định hướng rõ ràng họ mới có thể biết hệ thống cần
phải làm gì, và rất khó khăn để kết hợp các yêu cầu lại với nhau. Họ có thể làm sai lệch nhu
cầu bởi họ không biết giá trị của câu hỏi.
- Các nhà đầu tư trong một hệ thống thường bộc lộ các yêu cầu với kiến thức ngầm
định trong công việc của họ. Còn người kỹ sư không có nhiều kinh nghiệm trong các lĩnh
vực của khách hàng, do vậy cần phải hiểu được những yêu cầu và dịch chúng sang một dạng
tài liệu chấp nhận được.
- Các nhà đầu tư khác nhau có những yêu cầu khác nhau và họ có thể tiến hành theo
những cách rất khác nhau. Người kỹ sư phải nhận biết được những điểm chung và những điểm khác biệt đó.
- Việc phân tích lấy một không gian trong khung cảnh của tổ chức, những nhân tố
chính trị (chẳng hạn như việc phân quyền) có thể ảnh hưởng đến yêu cầu của hệ thống,
những nhân tố này có thể không rõ ràng mạch lạc tới người sử dụng cuối cùng. Ví dụ như
người lãnh đạo thường có quyền cao hơn đối với hệ thống.
- Việc phân tích lấy khía cạnh thương mại và kinh tế làm động lực. Nó chắc chắn sẽ
thay đổi trong quá trình phân tích. Từ đây, những yêu cầu riêng lẻ có thể thay đổi, những
yêu cầu mới có thể xuất hiện từ phía các nhà đầu tư mới. Các nhà đầu tư mới sẽ không phải
thăm dò lại từ đầu mà chỉ phải bổ sung thêm thông tin hay yêu cầu.
Để tiến hành phân tích yêu cầu, ta phải dựa vào sự hiểu biết nhất định trong các lĩnh
vực cụ thể, khi đó mô hình của tiến trình phân tích chắc chắn sẽ đơn giản hơn.
Mô hình sau đây nêu lên một số bước quan trọng trong tiến trình phân tích 119
Trong sơ đồ trên các bước bổ sung cho nhau, chu kỳ bắt đầu từ hiểu biết về các lĩnh
vực và cuối cùng là bản phê chuẩn các yêu cầu. Những hiểu biết của quá trình phân tích sẽ
dần được cải thiện sau mỗi chu trình.
- Hiểu biết về lĩnh vực ứng dụng: Phân tích phải được phát triển qua sự hiểu biết về
các lĩnh vực ứng dụng. Giả sử có một hệ thống siêu thị, quy trình phân tích phải tìm ra được
những điểm chung nhất, khái quát nhất giữa các siêu thị
- Thu thập yêu cầu: quy trình này liên quan đến các nhà đầu tư, người xây dựng hệ
thống phải thông qua họ để khám phá ra các yêu cầu. Từ đó sẽ nâng cao hiểu biết để phát
triển và xây dựng hệ thống.
- Phân loại yêu cầu: quá trình này lấy các yêu cầu một cách ngẫu nhiên, không có cấu
trúc và sắp xếp chúng một cách có hệ thống.
- Giải quyết xung đột: chắc chắn trong quá trình đưa ra yêu cầu, các nhà đầu tư do
không có chuyên môn nên xung đột có thể xảy ra. Công việc của người phân tích là cần phải
tìm ra và giải quyết các xung đột đó.
- Quyền ưu tiên: trong một tập hợp các yêu cầu bao giờ cũng có những yêu cầu quan
trọng và cấp bách hơn các yêu cầu khác, vì vậy ta phải khám phá ra các yêu cầu đó
- Làm cho các yêu cầu trở nên hiệu lực: các yêu cầu phải đảm bảo tính kiên định và
phù hợp với nhu cầu thực của nhà đầu tư. Từ đó mới xây dựng được hệ thống hữu ích.
Trong quá trình phân tích yêu cầu, một vài mô hình hệ thống khác nhau có thể được
sinh ra, mô hình là hình ảnh trừu tượng của hệ thống, các mô hình khác nhau sẽ có thông tin khác nhau.
5.2.3. Xác định yêu cầu
Xác định yêu cầu là mô tả trừu tượng về các dịch vụ mà hệ thống cần cung cấp và
các ràng buộc mà hệ thống cần tuân thủ khi vận hành. Nó chỉ mô tả các hành vi bên ngoài
của hệ thống mà không liên quan tới các chi tiết thiết kế. Yêu cầu nên được viết sao cho có
thể hiểu mà không cần một kiến thức chuyên môn đặc biệt nào.
Các yêu cầu được chia thành hai loại:
1) Các yêu cầu chức năng: các dịch vụ mà hệ thống cần cung cấp. Do vậy các yêu
cầu chức năng sẽ tác động trở lại các dữ liệu và có ảnh hưởng đến một số tình huống đặc 120
biệt. Trong một số trường hợp, yêu cầu chức năng cũng có thể có các trạng thái không phải làm việc.
2) Các yêu cầu phi chức năng: các ràng buộc mà hệ thống cần tuân thủ, bao gồm ràng
buộc về thời gian, các chuẩn công nghệ trong quá trình xử lý.
Các yêu cầu phi chức năng có thể chia làm 3 kiểu:
i) Yêu cầu sản phẩm: các yêu cầu về tốc độ, bộ nhớ, độ tin cậy, về tính khả chuyển và tái sử dụng...
ii) Yêu cầu về quá trình: yêu cầu đối với quá trình xây dựng sản phẩm như các chuẩn
phải tuân theo, các phương pháp thiết kế, ngôn ngữ lập trình...
iii) Yêu cầu khác: các yêu cầu không thuộc hai nhóm trên như về tính pháp lý, về chi
phí, về thành viên nhóm phát triển...
Các yêu cầu phi chức năng thường rất đặc thù với từng khách hàng và do đó khó
phân tích và đặc tả một cách đầy đủ và chính xác.
Về nguyên tắc, yêu cầu của hệ thống phải vừa đầy đủ vừa không được mâu thuẫn
nhau. Đối với các hệ thống lớn phức tạp thì chúng ta khó đạt được hai yếu tố này trong các
bước phân tích đầu. Một phần là do tính phức tạp của hệ thống, một phần do quan điểm
khác hau của nhu cầu người sử dụng. Trong các bước duyệt lại yêu cầu cần phải bổ sung,
chỉnh lý tư liệu yêu cầu.
Xác định yêu cầu được viết bằng ngôn ngữ tự nhiên, từ đó sẽ nảy sinh ra các vấn đề sau:
- Tính thiếu rõ ràng: do viết bằng ngôn ngữ tự nhiên nên đôi khi mơ hồ, khó hiểu
- Sự lẫn lộn giữa các yêu cầu: không phân biệt được đâu là yêu cầu chức năng, đâu là yêu cầu phi chức năng.
- Sự trộn lẫn trong các yêu cầu: các yêu cầu khác nhau có thể biểu diễn thành một yêu cầu chung.
5.2.4. Đặc tả yêu cầu
Tài liệu xác định yêu cầu là mô tả hướng khách hàng và được viết bởi ngôn ngữ của
khách hàng. Khi đó có thể dùng ngôn ngữ tự nhiên và các khái niệm trừu tượng. Tài liệu dặc
tả yêu cầu (đặc tả chức năng) là mô tả hướng người phát triển, là cơ sở của hợp đồng làm
phần mềm. Nó không được phép mơ hồ, nếu không sẽ dẫn đến sự hiểu nhầm bởi khách
hàng hoặc người phát triển. Với một yêu cầu mơ hồ thì người phát triển sẽ thực hiện nó một
cách rẻ nhất còn khách hàng thì không muốn vậy. Do đó khách hàng có thể đòi hỏi sửa đổi
chức năng phần mềm khi nó đã gần hoàn thiện khiến cho chi phí tăng và chậm thời điểm
bàn giao. Chi phí cho sửa các sai sót trong phát biểu yêu cầu là rất lớn, đặc biệt là khi các
sai sót này được phát hiện khi đã bắt đầu xây dựng hệ thống. Theo một số thống kê thì 85%
mã phải viết lại do thay đổi yêu cầu và 12% lỗi phát hiện trong 3 năm đầu sử dụng là do đặc
tả yêu cầu không chính xác. Do đó, việc đặc tả chính xác yêu cầu là mối quan tâm được đặt
lên hàng đầu. Có hai phương pháp đặc tả là
1. Đặc tả phi hình thức: là cách đặc tả bằng ngôn ngữ tự nhiên 121
2. Đặc tả hình thức: là cách đặc tả bằng các ngôn ngữ nhân tạo (ngôn ngữ đặc tả), các công thức và biểu đồ
Đặc tả phi hình thức (ngôn ngữ tự nhiên) thuận tiện cho việc xác định yêu cầu nhưng
nhiều khi không thích hợp với đặc tả yêu cầu vì:
 Không phải lúc nào người đọc và người viết đặc tả bằng ngôn ngữ tự nhiên cũng hiều các từ như nhau.
 Ngôn ngữ tự nhiên quá mềm dẻo do đó các yêu cầu liên quan đến nhau có thể
được biểu diễn bằng các hình thức hoàn toàn khác nhau và người phát triển không
nhận ra các mối liên quan này.
 Các yêu cầu khó được phân hoạch một cách hữu hiệu do đó hiệu quả của việc đổi
thay chỉ có thể xác định được bằng cách kiểm tra tất cả các yêu cầu chứ không
phải một nhóm các yêu cầu liên quan.
Đặc tả hình thức là đặc tả mà ở đó các từ ngữ, cú pháp, ngữ nghĩa được định nghĩa
hình thức dựa vào toán học. Đặc tả hình thức có thể coi là một phần của hoạt động đặc tả
phần mềm. Các đặc tả yêu cầu được phân tích chi tiết. Các mô tả trừu tượng của các chức
năng chương trình có thể được tạo ra để làm rõ yêu cầu.
Đặc tả phần mềm hình thức là một đặc tả được trình bày trên một ngôn ngữ bao gồm:
từ vựng, cú pháp và ngữ nghĩa được định nghĩa. Định nghĩa ngữ nghĩa đảm bảo ngôn ngữ
đặc tả không phải là ngôn ngữ tự nhiên mà dựa trên toán học. Các chức năng nhận các đầu
vào trả lại các kết quả. Các chức năng có thể định ra các điều kiện tiền tố và hậu tố. Điều
kiện tiền tố là điều kiện cần thỏa mãn để có dữ liệu vào, điều kiện hậu tố là điều kiện cần
thỏa mãn sau khi có kết quả.
Có hai hướng tiếp cận đặc tả hình thức để phát triển các hệ thống tương đối phức tạp.
+ Tiếp cận đại số, hệ thống được mô tả dưới dạng các toán tử và các quan hệ.
+ Tiếp cận mô hình, mô hình hệ thống được câú trúc sử dụng các thực thể toán học
như là các tập hợp và các thứ tự.
Sử dụng đặc tả hình thức, ta có các thuận lợi:
 Cho phép chúng ta thấy và hiểu được bản chất bên trong của các yêu cầu, đây là
cách tốt nhất để làm giảm các lỗi, các thiếu sót có thể xảy ra và giúp cho công
việc thiết kế được thuận lợi.
 Do chúng ta sử dụng toán học cho việc đặc tả nên có thể dựa vào các công cụ
toán học khi phân tích và điều này làm tăng thêm tính chắc chắn và tính đầy đủ của hệ thống.
 Đặc tả hình thức, bản thân nó cho chúng ta một cách thức cho việc kiểm tra hệ thống sau này.
Tuy vậy, đặc tả hình thức cũng bộc lộ một vài khó khăn:
 Quản lý phần mềm có tính bảo thủ cố hữu của nó, không sẵn sàng chấp nhận các kỹ thuật mới. 122
 Chi phí cho việc đặc tả hình thức thường cao hơn so với các đặc tả khác (tuy phần
cài đặt sẽ thấp hơn), nên khó để chứng minh rằng chi phí tương đối cao cho đặc tả
sẽ làm giảm tổng chi phí dự án.
 Phần lớn, những người đặc tả hệ thống không được đào tạo một cách chính quy
về việc sử dụng đặc tả hình thức cho việc đặc tả hệ thống mà dựa trên thói quen của họ.
 Thông thường, nhiều thành phần của hệ thống là khó cho việc đặc tả bằng ngôn
ngữ hình thức. Thêm vào đó là khách hàng không thể hiểu được nó.
 Khách hàng không thích các đặc tả toán học.
Các ngôn ngữ đặc tả (đặc tả hình thức) khắc phục được các hạn chế của đặc tả phi
hình thức, tuy nhiên đa số khách hàng lại không thông thạo các ngôn ngữ này. Thêm nữa
mỗi ngôn ngữ đặc tả hình thức thường chỉ phục vụ cho một nhóm lĩnh vực riêng biệt và việc
đặc tả hình thức là một công việc tốn kém thời gian.
Một cách tiếp cận là bên cạnh các đặc tả hình thức người ta viết các chú giải bằng
ngôn ngữ tự nhiên để giúp khách hành dễ hiểu.
Các nguyên lý đặc tả.
Đặc tả có thể xem như một tiến trình biểu diễn. Mục đích cuối cùng của đặc tả là
các yêu cầu được biểu thị sao cho dẫn tới việc cài đặt phần mềm thành công. Balzer và
Goldman đề nghị 8 nguyên lý đặc tả tốt.
Nguyên lý 1: Phân tách chức năng với cài đặt.
Trước hết, theo định nghĩa, đặc tả là một mô tả về điều mong muốn, chứ không phải
là cách thực hiện nó (cài đặt). Đặc tả có thể chấp nhận 2 dạng hoàn toàn khác nhau. Dạng
thứ nhất là dạng của các hàm toán học: Với một tập dữ liệu đầu vào đã cho, tạo ra một tập
dữ liệu đầu ra đặc biệt. Dạng tổng quát của đặc tả như thế là tìm ra (một hoặc tất cả
những) kết quả ứng với P (đầu vào), với P biểu thị một tân từ bất kỳ. Trong đặc tả như thế,
kết quả thu được phải được diến đạt một cách đầy đủ, toàn vẹn, theo dạng đó là cái gì
(không phải đó là như thế nào). Một phần điều này là vì kết quả của một hàm (toán học) của
đầu vào (phép toán có điểm bắt đầu và điểm kết thúc đã xác định rõ) không bị ảnh hưởng
bởi môi trường bao quanh.
Nguyên lý 2: Cần ngôn ngữ đặc tả hệ thống hướng tiến trình.
Xét tình huống trong đó môi trường là động và sự thay đổi của nó ảnh hưởng tới
hành vi của thực thể nào đó tương tác với môi trường đó (như trong “hệ thống máy tính
nhúng”). Hành vi của nó không thể biểu diễn được ở dạng hàm (toán học) của đầu vào.
Thay vì thế, cần phải sử dụng cách biểu diễn khác - cách mô tả hướng tiến trình, trong đó
đặc tả cái gì đã đạt được bằng cách xác định một mô hình các thao tác mong muốn đạt được
của hệ thống dưới dạng các công việc đáp ứng chức năng đối với kích thích khác nhau từ môi trường.
Những đặc tả hướng tiến trình như vậy, trình bày một mô hình về hành vi hệ
thống, thông thường đã bị loại ra khỏi các ngôn ngữ đặc tả hình thức, nhưng chúng lại là
bản chất nếu nhiều tình huống động phức tạp hơn cần phải được đặc tả. Trong thực tế, cần 123
phải thừa nhận rằng trong những tình huống như vậy cả tiến trình cần tự động hoá lẫn môi
trường tồn tại của nó đều phải được mô tả một cách hình thức. Tức là, toàn bộ hệ thống các
bộ phận tương tác phải được đặc tả chứ không chỉ một thành phần được đặc tả.
Nguyên lý 3: Đặc tả phải bao gồm hệ thống có phần mềm là một thành phần trong đó
Một hệ thống bao gồm các thành phần tương tác nhau. Chỉ bên trong hoàn
cảnh của hệ thống toàn bộ và tương tác giữa các thành phần của nó thì hành vi của một
thành phần riêng mới có thể được xác định. Nói chung, một hệ thống có thể được mô hình
hoá như một tập hợp các sự vật tích cực và thụ động. Những sự vật này có liên quan lẫn
nhau và qua thời gian thì mối quan hệ giữa các sự vật thay đổi. Mối quan hệ động này đưa
ra sự kích thích cho các sự vật tích cực, còn gọi là các tác nhân, đáp ứng. Sự đáp ứng có
thể gây ra những thay đổi thêm nữa, và do đó, tạo ra thêm kích thích để cho các tác nhân có thể đáp ứng lại.
Nguyên lý 4: Đặc tả phải bao gồm cả môi trường mà hệ thống vận hành.
Tương tự, môi trường mà trong đó hệ thống vận hành và tương tác với cũng phải được xác định.
May mắn là điều này đơn thuần chỉ cần sự thừa nhận rằng bản thân môi trường cũng
là một hệ thống bao gồm các sự vật tương tác, cả tích cực lẫn thụ động, mà trong đó hệ
thống chỉ là một tác nhân. Các tác nhân khác, theo định nghĩa là không thay đổi bởi
vì chúng là một phần của môi trường, giới hạn phạm vi của việc thiết kế và cài đặt về sau.
Trong thực tế, sự khác nhau duy nhất giữa hệ thống và môi trường của nó là ở chỗ nỗ lực
thiết kế và cài đặt về sau sẽ vận hành chỉ trong đặc tả cho hệ thống. Đặc tả môi trường làm
cho “giao diện” của hệ thống được xác định theo cùng cách như bản thân hệ thống chứ
không đưa vào cách hình thức khác.
Cần phải chú ý rằng bức tranh đặc tả hệ thống được trình bày ở đây chính là bức
tranh của tập hợp các tác nhân xoắn xuýt nhau cao độ phản ứng với những kích thích trong
môi trường (thay đổi các sự vật) do các tác nhân đó tạo ra. Chỉ có thông qua những hành
động điều phối của tác nhân mà hệ thống mới đạt tới mục tiêu của nó. Sự phụ thuộc lẫn
nhau vi phạm vào nguyên lí phân tách (cô lập với các phần khác của hệ thống và môi
trường). Nhưng đây là một nguyên lí thiết kế, không phải là nguyên lí đặc tả. Thiết kế tuân
theo đặc tả, và quan tâm tới việc phân rã một đặc tả thành các mẩu gần tách biệt để chuẩn bị
cho cài đặt. Tuy nhiên đặc tả phải vẽ lại chính xác bức chân dung của hệ thống và môi
trường của nó như cộng đồng người dùng cảm nhận theo một cách thức nhiều chi tiết như
các giai đoạn cài đặt và thiết kế cần tới. Vì mức độ chi tiết cần thiết này là khó thấy trước,
nếu không nói là không thể, nên đặc tả, thiết kế và cài đặt phải được thừa nhận như một hoạt
động tương tác. Do đó điều mấu chốt là công nghệ cần có để bao quát thật nhiều cho hoạt
động này khi bản đặc tả được soạn thảo và thay đổi (trong cả hai giai đoạn phát triển khởi
đầu và bảo trì về sau).
Nguyên lý 5: Đặc tả hệ thống phải là một mô hình nhận thức.
Đặc tả hệ thống phải là một mô hình nhận thức chứ không phải là một mô hình thiết
kế hay cài đặt. Nó phải mô tả một hệ thống như cộng đồng người sử dụng cảm nhận thấy. 124
Các sự vật mà nó thao tác phải tương ứng với các sự vật của lĩnh vực đó; các tác nhân phải
mô hình cho các cá nhân, tổ chức và trang thiết bị trong lĩnh vực đó; còn các hành động
họ thực hiện thì phải mô hình cho những hoạt động thực tế xuất hiện trong lĩnh vực.
Đặc tả phải có khả năng tổ hợp vào trong nó những qui tắc hay luật bao trùm các
sự vật Newton). Những luật này, biểu thị cho “tính vật lí” của lĩnh vực, là phần cố
hữu của đặc tả hệ thống.
Nguyên lý 6: Đặc tả phải thể hiện tính vận hành.
Đặc tả phải đủ đầy đủ và hình thức để có thể được dùng trong việc xác định liệu một
cài đặt được đề nghị có thoả mãn đặc tả cho những trường hợp kiểm thử tuỳ ý không. Tức
là, với kết quả của việc cài đặt trên một tập dữ liệu được chọn một cách tuỳ ý, phải có thể
dùng đặc tả để xác định tính hợp lệ cho những kết quả đó. Điều này kéo theo rằng đặc tả,
mặc dầu không phải là một đặc tả hoàn toàn về cách thức, vẫn có thể hành động như một
bộ sinh các hành vi có thể trong số những hành vi phải có của cài đặt được đề nghị. Do đó,
theo một nghĩa mở rộng, đặc tả này phải là vận hành ...
Nguyên lý 7: Đặc tả chấp nhập dung sai về tính không đầy đủ.
Không đặc tả nào có thể là đầy đủ hoàn toàn. Môi trường trong đó nó tồn tại
thường quá phức tạp cho điều đó. Một đặc tả bao giờ cũng là một mô hình - một sự trừu
tượng hoá - của một tình huống thực (hay được mường tượng) nào đó. Do đó, nó sẽ không
đầy đủ. Hơn thế nữa, như đã được phát biểu nó sẽ tồn tại tại ở nhiều mức chi tiết. Tính vận
hành được yêu cầu ở trên không nhất thuộc lĩnh vực. Một số trong những trường hợp là luật
bài trừ những trạng thái nào đó của hệ thống (như “hai sự vật không thể đồng thời ở cùng
một chỗ và vào cùng một lúc”), và do đó giới hạn hành vi của các tác nhân hay chỉ ra nhu
cầu soạn thảo thêm để ngăn cản những trạng thái này khỏi nảy sinh. Các luật khác mô tả
cách các sự vật đáp ứng lại khi bị kích thích (như luật chuyển động của thiết là cần thiết.
Các công cụ phân tích được sử dụng để giúp cho người đặc tả và để kiểm thử đặc tả phải có
khả năng xử lí với tính không đầy đủ. Một cách tự nhiên điều này làm cho việc phân tích bị
yếu đi, khi có thể được thực hiện bằng cách mở rộng phạm vi các hành vi chấp nhận được
thỏa mãn cho đặc tả, nhưng một sự suy giảm như vậy phải phản ánh các mức độ bất trắc còn lại.
Nguyên lý 8: Đặc tả phải được cục bộ hoá và được ghép lỏng lẻo.
Các nguyên lí trước xử lí đặc tả như một thực thể tĩnh. Thực thể này nảy sinh từ cái
động của đặc tả. Cần phải thừa nhận rằng mặc dầu mục tiêu chính của một đặc tả là để dùng
làm cơ sở cho thiết kế và cài đặt một hệ thống nào đó, nó không phải là một sự vật tĩnh
dựng sẵn mà là một sự vật động đang trải qua thay đổi đáng kể. Việc thay đổi như thế xuất
hiện trong ba hoạt động chính: phát biểu, khi một đặc tả ban đầu đang đươc tạo ra, phát
triển, khi đặc tả được soạn thảo trong quá trình thiết kế lặp để phản ánh môi trường đã thay
đổi và / hoặc các yêu cầu chức năng phụ.
Với nhiều thay đổi xuất hiện cho đặc tả, điều mấu chốt là nội dung và cấu trúc của
nó được chọn để làm phù hợp hoạt động này. Yêu cầu chính cho sự phù hợp đó là ở chỗ
thông tin bên trong đặc tả phải được cục bộ hoá sao cho chỉ một phần nhỏ (một cách lí
tưởng) cần phải sửa đổi khi thông tin thay đổi, và ở chỗ đặc tả cần được cấu trúc (ghép) 125
một cách lỏng lẻo để cho từng phần có thể được thêm vào hay loại bỏ một cách dễ dàng, và
cấu trúc được điều chỉnh một cách tự động.
Mặc dầu các nguyên lí được Balzer và Goldman tán thành tập trung vào tác động của
đặc tả trên định nghĩa về ngôn ngữ hình thức, những lời bình luận của họ áp dụng được cho
cả mọi dạng đặc tả. Tuy nhiên, các nguyên lí cần phải được dịch thành sự thực hiện. Trong
mục sau chúng ta sẽ xem xét một tập các hướng dẫn để tạo ra một đặc tả các yêu cầu.
Các mức trừu tượng của đặc tả.
Các đặc tả được thể hiện ở một vài mức trừu tượng khác nhau cùng với mối tương
liên giữa các mức ấy. Mỗi mức nhắm đến các đối tượng đọc khác nhau mà họ có quyền
quyết định về việc dựa vào đó mà thực hiện đánh giá bản thiết kế của các nhà phát triển
phần mềm. Các mức đó là:
Mức 1: Định ra yêu cầu.
Được thể hiện bằng ngôn ngữ tự nhiên về các dịch vụ mà hệ thống sẽ phải cung cấp.
Phần này phải được viết sao cho dễ hiểu đối với khách hàng và người quản lý hợp đồng,
người sẽ mua sản phẩm phần mềm và người sẽ sử dụng nó. Kỹ thuật đặc tả phi hình thức
là thích hợp cho mức đặc tả này.
Mức 2: Đặc tả yêu cầu.
Tài liệu nêu ra các dịch vụ một cách chi tiết hơn. Tài liệu này đôi khi còn được gọi là
tài liệu đặc tả chức năng. Yêu cầu đối với đặc tả ở mức này là phải chính xác đến mức có
thể làm cơ sở cho hợp đồng giữa nhà phát triển phần mềm và khách hàng. Đồng thời cũng
cần được viết sao cho dễ hiểu đối với nhân viên kỹ thuật của cả nơi mua phần mềm và nơi
phát triển hệ thống. Kỹ thuật đặc tả hình thức hẳn là thích hợp cho mức đặc tả như vậy,
tuy nhiên cũng còn tuỳ thuộc vào trình độ kiến thức cơ bản của khách hàng. Tốt hơn cả là
ta có thể dùng loại hình hỗn hợp để đặc tả.
Mức 3: Đặc tả phần mềm / đặc tả thiết kế (đây là mô tả trừu tượng cho phần mềm) .
Dùng làm cơ sở cho việc thiết kế và thực thi. Cần thể hiện một quan hệ rõ ràng giữa
tư liệu này và đặc tả yêu cầu. Ta phải xác định rằng: đối tượng đọc ở đây chủ yếu là các
kỹ sư phần mềm chứ không phải là người sử dụng hoặc người quản lý. Kỹ thuật đặc tả hình
hình thức là hoàn toàn phù hợp cho mức đặc tả này.
5.3. Sản phẩm của phân tích và đặc tả yêu cầu
5.3.1. Báo cáo khả thi
a. Khi nào nên có báo cáo khả thi
Nếu tiếp cận dưới góc độ là một khoản đầu tư thì việc chủ đầu tư yêu cầu lập báo cáo
tiền khả thi để cân nhắc hiệu quả cũng như những khó khăn có thể gặp phải khi triển khai dự
án phần mềm là cần thiết và đúng đắn.
Có hai trường hợp mà chủ đầu tư cần lập báo cáo tiền khả thi. Một là do yêu cầu về
pháp lý: các tổ chức chính phủ, các doanh nghiệp nhà nước khi muốn triển khai một dự án
CNTT có giá trị lớn buộc phải qua bước này như là một trình tự không thể thiếu của đầu tư
xây dựng cơ bản. Hai là, do đơn vị có cơ cấu tổ chức quá phức tạp, quá nhiều nghiệp vụ đặc 126
thù, nhiều hệ thống con cần thay thế giao diện – tích hợp, đòi hỏi phải có sự lượng định rõ
ràng về giải pháp, đường hướng triển khai.
Trong cả hai trường hợp, trình tự của dự án thường là: (1) Lập báo cáo tiền khả thi;
(2) Thẩm định báo cáo; (3) Trình cấp có thẩm quyền phê duyệt; (4) Tổ chức đấu thầu chọn
nhà triển khai giải pháp. Nếu việc lập báo cáo được thuê ngoài thì sẽ có một bộ phận chức
năng của chủ đầu tư đóng vai trò là người thẩm định. Những dự án đặc biệt phức tạp, việc
lập báo cáo lẫn thẩm định có thể thuê hai đơn vị tư vấn khác nhau đảm nhiệm. Ở Việt Nam,
một số đơn vị do chưa đánh giá đúng tầm quan trọng của việc lập báo cáo tiền khả thi nên
lãnh đạo thường giao việc này cho bộ phận CNTT hay tài chính – kế toán thực hiện. Nếu
việc khảo sát sơ sài, thiếu thông tin thì kết quả báo cáo chỉ là tờ trình ngắn gọn, không đảm
bảo tính toàn diện, khách quan và nghiêm túc, ảnh hưởng đến hiệu quả thực thi dự án sau này.
b. Nội dung cơ bản
Một báo cáo tiền khả thi đầy đủ thường phải trả lời những câu hỏi sau: Mục đích
hướng tới của dự án là gì? Hệ thống hiện tại có những bất cập nào? Các yêu cầu cụ thể của
nghiệp vụ ra sao? Đâu là những tham số chính (mô hình, quy mô, thời gian và kế hoạch
triển khai) của giải pháp? Số tiền đầu tư dự kiến là bao nhiêu?...
• Phân tích các mục tiêu lớn, tính cấp thiết của dự án. Mục tiêu – tính cấp thiết của
một dự án phần mềm nói riêng và CNTT nói chung thường dựa trên những mục tiêu chung,
những kế hoạch, đề án lớn của tổ chức, những đòi hỏi từ thực tế nghiệp vụ có liên quan tới
sự phát triển, ổn định, thậm chí là sự tồn tại của tổ chức.
• Cơ sở phương pháp luận và cách thức triển khai lập báo cáo. Đây là căn cứ để xác
định xem báo cáo có được xây dựng một cách thực sự khách quan, khoa học hay không.
• Phân tích các bối cảnh chung của dự án: mô hình tổ chức của đơn vị, hiện trạng
triển khai và ứng dụng CNTT trong tác nghiệp và quản lý, các dự án lớn đang được triển
khai có thể ảnh hưởng trực tiếp/gián tiếp tới dự án phần mềm đang đề cập.
• Liệt kê, hệ thống hóa và phân tích các nghiệp vụ có thể sẽ được tác nghiệp trên hệ
thống phần mềm tương lai. Cần chú ý rằng đây là các nghiệp vụ hiện có và không hẳn sẽ
được giải quyết hoàn toàn trên phần mềm vì phải tính đến đặc thù nghiệp vụ cũng như các
ràng buộc về nguồn lực (chi phí, thời gian triển khai)...
• Lựa chọn giải pháp. Người lập báo cáo phải chứng minh được đề xuất của mình
thông qua việc so sánh những ưu – nhược điểm và độ phù hợp với các yêu cầu nghiệp vụ
nêu trên của các giải pháp có trên thị trường, từ đó khuyến nghị một hoặc hai sự lựa chọn tối ưu nhất.
• Xác định các tham số cơ bản của hệ thống: phạm vị địa lý của dự án; phạm vi
nghiệp vụ (các mô đun) và chi tiết từng nghiệp vụ; quy mô về người sử dụng và khối lượng
giao dịch; kiến trúc hệ thống (kết nối, truyền thông...); các yêu cầu về phần cứng và hạ tầng đi kèm...
• Các ràng buộc về nguồn lực. Đầu tiên là phân chia giai đoạn và kế hoạch triển khai
cho các giai đoạn đầu tiên. Phần mềm luôn là một dự án lớn, việc triển khai thường được 127
phân thành nhiều giai đoạn với phạm vi địa lý/nghiệp vụ khác nhau. Trong trường hợp bản
thân từng giai đoạn tương đối dài và có quy mô tương đối lớn, có thể tại thời điểm lập báo
cáo chỉ lượng định được tương đối chi tiết cho một hoặc một số giai đoạn đầu tiên. Thứ hai
là dự toán tổng mức đầu tư, cũng như đã phân tích ở trên, phần này có thể bao gồm dự toán
cho giai đoạn đầu và khai toán cho các giai đoạn tiếp theo.
• Đánh giá kết quả của dự án. Nhìn chung, việc đưa ra các tiêu chí đánh giá về hiệu
quả đầu tư của một dự án CNTT là rất phức tạp và phụ thuộc nhiều vào chủ quan, dự án
phần mềm cũng không ngoại lệ. Tuy nhiên, người lập báo cáo vẫn cần đưa ra một số tiêu chí
(có thể là định tính) để lượng định về mức độ thành công của dự án sau này.
c. Những vấn đề cần cân nhắc
Điều đầu tiên phải cân nhắc khi quyết định lập báo cáo tiền khả thi là thời gian có thể
kéo dài hơn dự kiến. Thông thường, quá trình lựa chọn tư vấn, lập báo cáo, thẩm định, trình
duyệt, tổ chức đấu thầu thường kéo dài 6 tháng đến 1 năm. Chất lượng của báo cáo tiền khả
thi cũng như chất lượng của dự án phụ thuộc rất nhiều vào trình độ, kinh nghiệm và sự nhiệt tình của nhà tư vấn.
Riêng đối với các đơn vị buộc phải lập báo cáo tiền khả thi do yêu cầu về pháp lý, có
thể sẽ vấp phải những bất cập trong các quy định pháp luật hiện hành. Rõ ràng nhất là việc
dự án CNTT phải tuân theo các trình tự, thủ tục, biểu mẫu và các định mức của xây dựng cơ
bản (XDCB). Các từ ngữ của ngành XDCB như “xây lắp”, “thi công” được gắn một cách
khiên cưỡng với các hạng mục khác nhau của dự án phần mềm. Không khó để nhận thấy độ
vênh đáng kể giữa hai loại dự án. Trong khi với dự án XDCB, phần giá trị nằm ở các hạng
mục mang tính vật chất (thiết bị, vật tư, khối lượng thi công...) thì hầu hết giá trị của một dự
án CNTT (trong đó có phần mềm) lại kết tinh chủ yếu trong một sản phẩm phi vật chất là
phần mềm. Bởi thế, định mức cho các hạng mục của dự án XDCB và dự án CNTT là rất
khác nhau. Đơn cử như chi phí cho phần tư vấn lập báo cáo tiền khả thi, vốn chiếm vị trí rất
quan trọng trong dự án CNTT, lại chỉ được xét 0,16% tổng mức đầu tư, nếu dùng định mức của XDCB.
Về khuyến nghị lựa chọn giải pháp, nhiều người cho rằng, báo cáo tiền khả thi chỉ
nên đưa ra những yêu cầu cho hệ thống chứ không chỉ ra một sản phẩm cụ thể, vì có thể vi
phạm các quy định về đấu thầu. Tuy nhiên, các tiêu chí đánh giá chất lượng phần mềm
tương đối trừu tượng và mang nặng định tính, sẽ rất khó so sánh hai giải pháp khác nhau
nếu chỉ căn cứ vào hồ sơ dự thầu. Thực tế, đơn vị lập báo cáo khả thi sẽ là người có kiến
thức, kinh nghiệm thực tế để đánh giá chất lượng giải pháp, hơn là những thành viên của tổ
chuyên gia đấu thầu sau này.
5.3.2. Mô hình hệ thống
Chúng ta tạo ra các mô hình để thu được hiểu biết rõ hơn về thực thể thực tế cần xây
dựng. Khi thực thể là một vật vật lý (như toà nhà, máy bay, máy móc) thì ta có thể xây dựng
một mô hình giống hệt về hình dạng, nhưng nhỏ hơn về qui mô. Tuy nhiên, khi thực thể cần
xây dựng là phần mềm, thì mô hình của chúng ta phải mang dạng khác. Nó phải có khả
năng mô hình hóa thông tin mà phần mềm biến đổi, các chức năng (và chức năng con) làm
cho phép biến đổi đó thực hiện được, và hành vi của hệ thống khi phép biến đổi xảy ra. 128
Trong khi phân tích các yêu cầu phần mềm, chúng ta tạo ra các mô hình về hệ thống
cần xây dựng. Các mô hình tập trung vào điều hệ thống phải thực hiện, không chú ý đến
cách thức nó thực hiện. Trong nhiều trường hợp, các mô hình chúng ta tạo ra có dùng kí
pháp đồ hoạ mô tả cho thông tin, xử lý, hành vi hệ thống, và các đặc trưng khác thông qua
các biểu tượng phân biệt và dễ nhận diện. Những phần khác của mô hình có thể thuần túy
văn bản. Thông tin mô tả có thể được cung cấp bằng cách dùng một ngôn ngữ tự nhiên hay
một ngôn ngữ chuyên dụng cho mô tả yêu cầu. Các mô hình được tạo ra trong khi phân tích
yêu cầu còn đóng một số vai trò quan trọng:
 Mô hình trợ giúp cho người phân tích trong việc hiểu về thông tin, chức năng và
hành vi của hệ thống, do đó làm cho nhiệm vụ phân tích yêu cầu được dễ dàng và hệ thống hơn.
 Mô hình trở thành tiêu điểm cho việc xem xét và do đó, trở thành phần mấu chốt
cho việc xác định tính đầy đủ, nhất quán và chính xác của đặc tả.
 Mô hình trở thành nền tảng cho thiết kế, cung cấp cho người thiết kế một cách
biểu diễn chủ yếu về phần mềm có thể được “ánh xạ” vào hoàn cảnh cài đặt.
Dưới đây là một số mô hình (phương pháp) hay được dùng trong phân tích:
1. Biểu đồ luồng dữ liệu
2. Mô hình phân cấp chức năng
3. Mô hình thực thể liên kết 4. Biểu đồ ca sử dụng …
5.3.3. Tài liệu định nghĩa yêu cầu (requirement definition)
Là văn bản liệt kê các yêu cầu chức năng và yêu cầu phi chức năng. Ví dụ
1. Các yêu cầu chức năng cơ bản:
* Dữ liệu sử dụng: số thực
* Có các nút bấm thực hiện các chức năng sau :
- Các phím số: dùng để nhập số.
- Dấu bằng (=) : để cho ra kết quả.
- Phép cộng (+) : dùng để cộng 2 hay nhiều số.
- Phép trừ (-): dùng để trừ 2 hay nhiều số.
- Phép nhân (x) : dùng để nhân 2 hay nhiều số.
- Phép chia (÷) : dùng để chia 2 hay nhiều số. Nếu chia cho 0 thì báo lỗi.
- Đổi dấu (±) : đổi dấu của một số từ âm sang dương và ngược lại.
- Tính căn thức(Sqrt) : tính được căn bậc hai của một số dương.
- Tính bình phương (x2) : tính được bình phương của một số bất kì.
- Xóa (Del) : Xóa chử số cuối cùng bên phải của số. 129
- Xóa toàn bộ (C) : xóa số và mọi cài đặt trên máy, để tiến hành tính toán lại.
- Trợ Giúp : để hướng dẫn sử dụng phần mềm.
- About: dùng giới thiệu phần mềm, tác giả...
2. Các yêu cầu phi chức năng: - Giao diện :
 Thiên về đồ họa, với giao diện giống một chiếc máy tính bỏ túi loại nhỏ.
 Trực quan, dễ sử dụng. Đặc biệt đối với trẻ thơ thì hình ảnh phải sinh động,
ngộ nghĩnh để trẻ cảm thấy thích thú hơn trong lúc học.
 Sử dụng Tiếng Việt.
- Công cụ lập trình : Visual Studio 2008
- Tiến trình thực hiện :
 Ngày bắt đầu: 20/10/2010
 Ngày kết thúc: 18/11/2010
5.3.4. Tài liệu đặc tả yêu cầu
Kết quả của bước phân tích là tạo ra bản đặc tả yêu cầu phần mềm (Software
Requirement Specification - SRS). Đặc tả yêu cầu phải chỉ rõ được phạm vi của sản phẩm,
các chức năng cần có, đối tượng người sử dụng và các ràng buộc khi vận hành sản phẩm.
Có nhiều chuẩn khác nhau trong xây dựng tài liệu, dưới đây là một định dạng RSR thông
dụng (theo chuẩn IEEE 830-1984). 1. Giới thiệu 1.1. Mục đích
Mục này giới thiệu mục đích của tài liệu yêu cầu. Thường chỉ đơn giản là định nghĩa
“đây là tài liệu yêu cầu về phần mềm XYZ”. 1.2. Phạm vi
Nêu pham vi đề cập của tài liệu yêu cầu. 1.3. Định nghĩa
Định nghĩa các khái niệm, các từ viết tắt, các chuẩn được sử dụng trong tài liệu yêu cầu.
1.4. Tài liệu tham khảo
Nêu danh mục các tài liệu tham khảo dùng để tạo ra bản đặc tả yêu cầu.
1.5. Mô tả chung về tài liệu
Mô tả khái quát cấu trúc tài liệu, gồm có các chương, mục, phục lục chính nào. 2. Mô tả chung
2.1. Tổng quan về sản phẩm
Mô tả khái quát về sản phẩm.
2.2. Chức năng sản phẩm 130
Khái quát về chức năng sản phẩm.
2.3. Đối tượng người dùng
Mô tả về đối tượng người dùng.
2.4. Ràng buộc tổng thể
Khái quát về các ràng buộc của phần mềm: ràng buộc phần cứng, môi trường sử
dụng, yêu cầu kết nối với các hệ thống khác...
2.5. Giả thiết và sự lệ thuộc
Mô tả các giả thiết khi áp dụng tài liệu: ví dụ như tên phần cứng, phần mềm, hệ điều hành cụ thể.
3. Yêu cầu chi tiết Mô tả các yêu cầu
3.1. Yêu cầu chức năng
Mô tả chi tiết về các yêu cầu chức năng.
3.1.1. Yêu cầu chức năng 1
3.1.1.1. Giới thiệu
3.1.1.2. Dữ liệu vào 3.1.1.3. Xử lý 3.1.1.4. Kết quả
3.1.2. Yêu cầu chức năng 2 ...
3.1.n. Yêu cầu chức năng n
3.2. Yêu cầu giao diện ngoài
Mô tả các giao diện của phần mềm với môi trường bên ngoài.
3.2.1. Giao diện người dùng
3.2.2. Giao diện phần cứng
3.2.3. Giao diện phần mềm
3.2.4. Giao diện truyền thông
3.3. Yêu cầu hiệu suất
Mô tả về hiệu suất, ví dụ như thời gian phản hồi với sự kiện, số giao dịch được thực hiện/giây,...
3.4. Ràng buộc thiết kế
Mô tả các ràng buộc thiết kế, ví dụ các ràng buộc về ngôn ngữ, về công nghệ, về cơ
sở dữ liệu và về chuẩn giao tiếp. 3.5 Thuộc tính
Mô tả các thuộc tính của phần mềm.
3.5.1. Tính bảo mật, an toàn và khả năng phục hồi 131
Mức độ bảo mật dữ liệu, cách thức truy cập vào hệ thống. Độ an toàn của hệ thống
đối với các trường hợp bất thường như mất điện... Khả năng phục hồi của hệ thống sau khi gặp sự cố. 3.5.2 Tính bảo trì
Các chức năng, giao diện đòi hỏi phải dễ sửa đổi (dễ bảo trì).
3.6. Các yêu cầu khác
Các yêu cầu khác liên quan đến sản phẩm.
5.3.5. Tài liệu yêu cầu
Cấu trúc chung của tài liệu yêu cầu phần mềm gồm các phần như sau:
- Giới thiệu: mô tả sự cần thiết của hệ thống. Nó cần sự mô tả sơ lược các chức năng
của mình và giải thích cách làm việc với các hệ thống khác. Nó cũng cần mô tả làm thế nào
hệ thống đáp ứng được toàn bộ các mục tiêu chiến lược và nghiệp vụ.
- Thuật ngữ: nó cần định nghĩa các khái niệm kỹ thuật được sử dụng trong tài liệu
này. Không được giả định người đọc đã có kinh nghiệm.
- Mô hình hệ thống: phần này lập một hoặc nhiều mô hình hệ thống cho biết các quan
hệ giữa các cấu thành hệ thống với hệ thống và môi trường của nó. Nó cần bao gồm các mô
hình đối tượng, mô hình luồng dữ liệu và ngữ nghĩa dữ liệu.
- Định nghĩa yêu cầu chức năng: các dịch vụ cung cấp cho người dùng cần được mô
tả trong mục này. Mô tả có thể dùng ngôn ngữ tự nhiên, sơ đồ hoặc các dạng ghi chép khác
cho phép khách hàng có thể hiểu được.
Các dịch vụ cung cấp cho người dùng cần được mô tả trong mục này. Mô tả có thể
dùng ngôn ngữ tự nhiên, sơ đồ hoặc các dạng ghi chép khác cho phép khách hàng có thể hiểu được.
- Định nghĩa yêu cầu phi chức năng: các ràng buộc về phần mềm và các hạn chế đối
với thiết kế cần phải được mô tả trong phần này. Nó có thể bao gồm các chi tiết của biểu
diễn dữ liệu, thời gian đáp ứng và yêu cầu bộ nhớ,...Các tiêu chuẩn về sản phẩm và quy
trình cần tuân thủ cũng được mô tả.
- Tiến triển hệ thống: phần này mô tả các giả thiết căn bản làm cơ sở cho hệ thống và
dự đoán các thay đổi về phát triển phần cứng, yêu cầu người dùng
- Đặc tả yêu cầu: mô tả các yêu cầu cơ bản chi tiết hơn. Nếu cần các chi tiết hơn có
thể được thêm vào các yêu cầu phi chức năng, ví dụ giao diện với các hệ thống có thể được định nghĩa.
- Ngoài ra, tài liệu yêu cầu phần mềm có thể bao gồm thêm các phần sau:
+ Phần cứng: nếu hệ thống được phát triển trên một phần cứng đặc biệt, phần cứng
này và giao diện cần được mô tả. Nếu phần cứng bán sẵn được sử dụng, các cấu hình cực
tiểu và cực đại phải được mô tả.
+ Yêu cầu dữ liệu: tổ chức logic của dữ liệu được sử dụng bởi hệ thống và các quan
hệ giữa chúng được mô tả, có thể dùng sơ đồ thực thể liên kết. 132
+ Chỉ mục có thể được cung cấp. Ví dụ chỉ mục theo chữ cái, chỉ mục theo chương, theo chức năng....
Do hệ thống được vận hành trong thời gian dài, nên môi trường hệ thống và mục đích
nghiệp vụ có thể thay đổi. Khi đó tài liệu yêu cầu cũng cần phải thay đổi. Với mục đích tiến
triển, tài liệu yêu cầu thường được chia theo hai phân loại:
- Các yêu cầu ổn định: được suy dẫn từ các hoạt động cốt lõi của tổ chức tương đối
liên quan trực tiếp tới miền hệ thống.
- Các yêu cầu bất thường: các yêu cầu có thể thay đổi khi phát triển hệ thống sau này
như: các yêu cầu xuất hiện như là sự hiểu biết của khách hàng về sự phát triển của hệ thống
trong quá trình xây dựng hệ thống, các yêu cầu được sinh ra do sự xuất hiện của việc tin học
hóa làm thay đổi các quy trình nghiệp vụ,... 133
Chương 6. Thiết kế phần mềm
6.1. Khái niệm, nguyên lý, chất lượng thiết kế
6.1.1. Khái niệm
Có thể định nghĩa thiết kế là một quá trình áp dụng nhiều kỹ thuật và các nguyên lý
để tạo ra mô hình của một thiết bị, một tiến trình hay một hệ thống đủ chi tiết mà theo đó có
thể chế tạo ra sản phẩm vật lý tương ứng với nó.
Bản chất thiết kế phần mềm là một quá trình chuyển hóa các yêu cầu phần mềm
thành một biểu diễn thiết kế. Từ những mô tả quan niệm về toàn bộ phần mềm, việc làm
mịn (chi tiết hóa) liên tục dẫn tới một biểu diễn thiết kế rất gần với cách biểu diễn của
chương trình nguồn để có thể ánh xạ vào một ngôn ngữ lập trình cụ thể.
Mục tiêu thiết kế là để tạo ra một mô hình biểu diễn của một thực thể mà sau này sẽ được xây dựng.
Mô hình chung của một thiết kế phần mềm là một đồ thị có hướng, các nút biểu diễn
các thực thể có trong thiết kế, các liên kết biểu diễn các mỗi quan hệ giữa các thực thể đó.
Hoạt động thiết kế là một loại hoạt động đặc biệt:
- Là một quá trình sáng tạo, đòi hỏi có kinh nghiệm và sự nhanh nhạy và sáng tạo
- Cần phải được thực hành và học bằng kinh nghiệm, bằng khảo sát các hệ đang tồn
tại, chỉ học bằng sách vở là không đủ.
Tầm quan trọng của thiết kế phần mềm có thể được phát biểu bằng một từ “chất
lượng” (quality). Thiết kế là nơi chất lượng phần mềm được nuôi dưỡng trong quá trình phát
triển: cung cấp cách biểu diễn phần mềm có thể được xác nhận về chất lượng, là cách duy
nhất mà chúng ta có thể chuyển hóa một cách chính xác các yêu cầu của khách hàng thành
sản phẩm hay hệ thống phần mềm cuối cùng. Thiết kế phần mềm là công cụ giao tiếp làm
cơ sở để có thể mô tả một cách đầy đủ các dịch vụ của hệ thống, để quản lý các rủi ro và lựa
chọn giải pháp thích hợp. Thiết kế phần mềm phục vụ như một nền tảng cho mọi bước kỹ
nghệ phần mềm và bảo trì. Không có thiết kế có nguy cơ sản sinh một hệ thống không ổn
định - một hệ thống sẽ thất bại. Một hệ thống phần mềm rất khó xác định được chất lượng
chừng nào chưa đến bước kiểm thử. Thiết kế tốt là bước quan trọng đầu tiên để đảm bảo chất lượng phần mềm. 134
6.1.2. Nguyên lý
- Thiết kế trên cơ sở phân tích: Có thể không ánh xạ 1-1
- Không thiết kế lặp: Sử dụng lại các phần đã có
- Nhất quán và khả hợp: Thiết kế thường do nhiều nhóm cùng làm -> Phải cùng cách
biểu diễn + có thể tích hợp
- Có kiến trúc cao: Để dễ hiểu, tăng tính độc lập, dễ thay đổi
- Không phải là cài đặt: Tổng quát và dễ hiểu hơn cài đặt
- Thiết kế phải được đánh giá chất lượng và thẩm định + Chất lượng: o Tính đúng, o Tính đầy đủ, o Tính module,
o Tính độc lập chức năng, o Hiệu quả thuật toán, o Hiệu quả tương tác, o Tính dễ hiểu... + Thẩm định:
o Xét mức độ đạt các tiêu chuẩn chất lượng
- Thường xuyên review khi thiết kế: Quy trình thiết kế cần có những điểm mốc rò ràng
6.1.3. Chất lượng thiết kế
Không có cách nào hay để xác định được thế nào là thiết kế tốt. Tiêu chuẩn dễ bảo trì
là tiêu chuẩn tốt cho người dùng. Một thiết kế dễ bảo trì có thể thích nghi với việc cải biên
các chức năng và việc thêm các chức năng mới. Một thiết kế như thế phải dễ hiểu và việc
sửa đổi chỉ có hiệu ứng cục bộ. Các thành phần thiết kế phải là kết dính (cohesive) theo
nghĩa là tất cả các bộ phận trong thành phần phải có một quan hệ logic chặt chẽ, các thành
phần ghép nối (coupling) với nhau là lỏng lẻo. Ghép nối càng lỏng lẻo thì càng dễ thích
nghi, nghĩa là càng dễ sửa đổi để phù hợp với hoàn cảnh mới.
Để xem một thiết kế có là tốt hay không, người ta tiến hành thiết lập một số độ đo chất lượng thiết kế:
1) Sự kết dính (Cohesion): Sự kết dính của một môđun là độ đo về tính khớp lại với
nhau của các phần trong môđun đó. Nếu một môđun chỉ thực hiện một chức năng logic hoặc
là một thực thể logic, tức là tất cả các bộ phận của môđun đó đều tham gia vào việc thực
hiện một công việc thì độ kết dính là cao. Nếu một hoặc nhiều bộ phận không tham gia trực
tiếp vào việc chức năng logic đó thì mức độ kết dính của nó là thấp. Thiết kế là tốt khi độ
kết dính cao. Khi đó chúng ta sẽ dễ dàng hiểu được từng môđun và việc sửa chữa một
môđun sẽ không (ít) ảnh hưởng tới các môđun khác. Constantine và Yourdon định ra 7 mức
kết dính theo thứ tự tăng dần sau đây: 135
a. Kết dính gom góp: các công việc không liên quan với nhau, song lại bị bó vào một môđun.
b. Kết dính logic: các thành phần cùng thực hiện các chức năng tương tự về logic
chẳng hạn như vào/ra, xử lý lỗi,... được đặt vào cùng một mô đun.
c. Kết dính thời điểm: tất cả các thành phần cùng hoạt hóa một lúc, chẳng hạn như
các thao tác khởi tạo được bó lại với nhau.
d. Kết dính thủ tục: các phần tử trong môđun được ghép lại trong một dãy điều khiển.
e. Kết dính truyền thông: tất cả các phần tử của môđun cùng thao tác trên một dữ liệu
vào và đưa ra cùng một dữ liệu ra.
f. Kết dính tuần tự: trong một môđun, đầu ra của phần tử này là đầu vào của phần tử khác.
g. Kết dính chức năng: Mỗi phần của môđun đều là cần thiết để thi hành cùng một
chức năng nào đó. Các lớp kết dính này không được định nghĩa chặt chẽ và cũng không phải
luôn luôn xác định được. Một đối tượng kết dính nếu nó thể hiện như một thực thể đơn: tất
cả các phép toán trên thực thể đó đều nằm trong thực thể đó.
h. Kết dính đối tượng: mỗi phép toán đều liên quan đến thay đổi, kiểm tra và sử dụng
thuộc tính của một đối tượng, là cơ sở cung cấp các dịch vụ của đối tượng.
2) Sự ghép nối (Coupling): Ghép nối là độ đo sự nối ghép với nhau giữa các đơn vị
(môđun) của hệ thống. Hệ thống có nối ghép cao thì các môđun phụ thuộc lẫn nhau lớn. Hệ
thống nối ghép lỏng lẻo thì các môđun là độc lập hoặc là tương đối độc lập với nhau và
chúng ta sẽ dễ bảo trì nó. Các mô đun được ghép nối chặt chẽ nếu chúng dùng các biến
chung và nếu chúng trao đổi các thông tin điều khiển (ghép nối chung nhau và ghép nối điều
khiển). Ghép nối lỏng lẻo đạt được khi bảo đảm rằng các thông tin cục bộ được che dấu
trong các môđun và các môđun trao đổi thông tin thông qua danh sách tham số (giao diện)
xác định. Có thể chia ghép nối thành các mức từ chặt chẽ đến lỏng lẻo như sau:
a. Ghép nối nội dung: hai hay nhiều môđun dùng lẫn dữ liệu của nhau, đây là mức
xấu nhất, thường xẩy ra đối với các ngôn ngữ mức thấp dùng các dữ liệu toàn cục hay lạm dụng lệnh GOTO.
b. Ghép nối chung: một số môđun dùng các biến chung, nếu xẩy ra lỗi thao tác dữ
liệu, sẽ khó xác định được lỗi đó do môđun nào gây ra.
c. Ghép nối điều khiển: một môđun truyền các thông tin điều khiển để điều khiểnhoạt
động của một môđun khác.
d. Ghép nối dư thừa: môđun nhận thông tin thừa không liên quan trực tiếp đến chức
năng của nó, điều này sẽ làm giảm khả năng thích nghi của môđun đó.
e. Ghép nối dữ liệu: Các môđun trao đổi thông tin thông qua tham số và giá trị trả lại.
f. Ghép nối không có trao đổi thông tin: môđun thực hiện một chức năng độc lập và
hoàn toàn không nhận tham số và không có giá trị trả lại. 136
Ưu việt của thiết kế hướng đối tượng là do bản chất che dấu thông tin của đối tượng
dẫn tới việc tạo ra các hệ ghép nối lỏng lẻo. Việc thừa kế trong hệ thống hướng đối tượng lại
dẫn tới một dạng khác của ghép nối, ghép nối giữa đối tượng mức cao và đối tượng kế thừa nó.
3) Sự hiểu được (Understandability): Sự hiểu được của thiết kế liên quan tới một số đặc trưng sau đây:
a. Tính kết dính: có thể hiểu được thành phần đó mà không cần tham khảo tới một
thành phần nào khác hay không?
b. Đặt tên: phải chăng là mọi tên được dùng trong thành phần đó đều có nghĩa? Tên
có nghĩa là những tên phản ánh tên của thực thể trong thế giới thực được mô hình bởi thành phần đó.
c. Soạn tư liệu: Thành phần có được soạn thảo tư liệu sao cho ánh xạ giữa các thực
thể trong thế giới thực và thành phần đó là rõ ràng.
d. Độ phức tạp: độ phức tạp của các thuật toán được dùng để thực hiện thành phần đó
như thế nào? Độ phức tạp cao ám chỉ nhiều quan hệ giữa các thành phần khác nhau của
thành phần thiết kế đó và một cấu trúc logic phức tạp mà nó dính líu đến độ sâu lồng nhau
của cấu trúc ifưthenưelsse. Các thành phần phức tạp là khó hiểu, vì thế người thiết kế nên
làm cho thiết kế thành phần càng đơn giản càng tốt. Đa số công việc về đo chất lượng thiết
kế được tập trung vào cố gắng đo độ phức tạp của thành phần và từ đó thu được một vài độ
đo về sự dễ hiểu của thành phần. Độ phức tạp phản ánh độ dễ hiểu, nhưng cũng có một số
nhân tố khác ảnh hưởng đến độ dễ hiểu, chẳng hạn như tổ chức dữ liệu và kiểu cách mô tả
thiết kế. Các số đo độ phức tạp có thể chỉ cung cấp một chỉ số cho độ dễ hiểu của một thành phần.
4) Sự thích nghi được (Adaptability): Một thiết kế dễ bảo trì thì nó phải sẵn sàng
thích nghi được, nghĩa là các thành phần của chúng nên được ghép nối lỏng lẻo. Một thành
phần có thể là ghép nối lỏng lẻo theo nghĩa là chỉ hợp tác với các thành phần khác thông qua
việc truyền các thông báo. Sự thích nghi được còn có nghĩa là thiết kế phải được soạn thảo
tư liệu tốt, dễ hiểu và nhất quán.
Để có độ thích nghi thì hệ thống còn cần phải phải tự chứa. Muốn là tự chứa một
cách hoàn toàn thì một hệ thống không nên dùng các thành phần khác được xác định ngoại
lai. Tuy nhiên, điều đó lại mâu thuẫn với kinh nghiệm nói rằng các thành phần hiện có nên
là dùng lại được. Vậy là cần có một cân bằng giữa tính ưu việt của sự dùng lại các thành
phần và sự mất mát tính thích nghi được của hệ thống. Một trong những ưu việt chính của
kế thừa trong thiết kế hướng đối tượng là các thành phần này có thể sẵn sàng thích nghi
được. Cơ cấu thích nghi được này không dựa trên việc cải biên thành phần đã có mà dựa
trên việc tạo ra một thành phần mới thừa kế các thuộc tính và các chức năng của thành phần
đó. Chúng ta chỉ cần thêm các thuộc tính và chức năng cần thiết cho thành phần mới. Các
thành phần khác dựa trên thành phần cơ bản đó sẽ không bị ảnh hưởng gì. 137
6.2. Nhiệm vụ thiết kế
6.2.1. Thiết kế kiến trúc (architectural design)
Thiết kế kiến trúc là quá trình xác định các hệ thống con của hệ thống và cơ cấu tổ
chức (framework) việc điều khiển giao tiếp giữa các hệ thống con. Kết quả ra của tiến trình
thiết kế kiến trúc là sự mô tả về kiến trúc phần mềm
Hệ thống con là một hệ thống trong hệ thống tổng thể mà các hoạt động của nó độc
lập với các dịch vụ được cung cấp từ các hệ thống con khác
Mô đun là một thành phần hệ thống cung cấp các dịch vụ cho các thành phần khác
nhưng không được xem như một hệ thống riêng biệt
Đặc điểm thiết kế kiến trúc phần mềm
- Là giai đoạn đầu của quá trình thiết kế
- Biểu diễn sự kết nối giữa đặc tả yêu cầu và các tiến trình thiết kế
- Thường tiến hành song song với các hoạt động đặc tả phần mềm
- Bao gồm việc xác định các thành phần hệ thống và giao tiếp giữa chúng
Vai trò của thiết kế kiến trúc phần mềm
- Giao tiếp giữa khách hàng và nhà phát triển
- Kiến trúc phần mềm là tiêu điểm cho sự thảo luận giữa khách hàng và nhà phát triển - Phân tích hệ thống
- Là phương tiện để phân tích khả thi về các yêu cầu phi chức năng của hệ thống - Sử dụng lại
- Kiến trúc này có thể được sử dụng lại cho nhiều hệ thống Tiến trình
- Cấu trúc hóa hệ thống: phân chia hệ thống thành các hệ con (sub-system) độc lập và
xác định trao đổi thông tin giữa các hệ con
- Mô hình hóa điều khiển: xác lập mô hình điều khiển giữa các phần của hệ thống
- Phân rã module: phân rã các hệ con thành các module 138
6.2.2. Thiết kế dữ liệu (data design)
Xây dựng mô hình biểu diễn thông tin cần xử lý: mức logic và mức vật lý
Tìm kiếm biểu diễn luận lý cho các phần tử dữ liệu đã được nhận diện trong giai đoạn phân tích yêu cầu
Thiết kế các cấu trúc dữ liệu của chương trình và cơ sở dữ liệu
Thực hiện tinh chế từng bước
- Các tiêu chí thiết kế hệ cơ sở dữ liệu
+ Không dư thừa dữ liệu
+ Tối ưu hóa không gian lưu trữ
+ Chuẩn hóa cơ sở dữ liệu bằng lược đồ ERD và dạng chuẩn 3 - Một số nguyên tắc
+ Nhận diện cả cấu trúc dữ liệu và tác vụ truy xuất
+ Chú ý sử dụng từ điển dữ liệu
+ Trì hoãn thiết kế dữ liệu mức thấp cho đến cuối giai đoạn này
+ Che dấu biểu diễn bên trong của cấu trúc dữ liệu
+ Phát triển một thư viện các cấu trúc dữ liệu + tác vụ thường gặp
+ Nên áp dung kiểu ADT trong thiết kế cũng như trong lập trình
6.2.3. Thiết kế chức năng (functional design)
Thiết kế các thành phần, giải thuật xử lý thông tin
6.2.4. Thiết kế giao diện người dùng (interface design)
Thiết kế hệ thống máy tính bao gồm một phổ rất rộng các công việc từ thiết kế phần
cứng cho đến thiết kế giao diện người sử dụng. Giao diện của hệ thống thường là tiêu chuẩn
so sánh để phán xét về hệ thống. Giao diện được thiết kế kém sẽ gây ra những nhầm lẫn cho
người sử dụng, khiến cho họ không sử dụng được các chức năng cần thiết và trong trường
hợp xấu có thể thực hiện các thao tác nguy hiểm như phá hủy thông tin cần thiết.
Tầm quan trọng của giao diện còn được xem xét trên hai yếu tố:
- Khía cạnh nghiệp vụ: người dùng thông qua giao diện để tương tác với hệ thống,
đây là khâu nghiệp vụ thủ công duy nhất do đó nếu được thiết kế tốt sẽ nâng cao tốc độ xử
lý công việc và dẫn tới hiệu quả kinh tế cao.
- Khía cạnh thương mại: đối với các sản phẩm bán hàng loạt, giao diện được thiết kế
tốt (dễ sử dụng, đẹp) sẽ gây ấn tượng với khách hàng và là yếu tố chính khi khách hàng chọn mua sản phẩm.
Ngoài các yếu tố hiệu quả công việc, đẹp, dễ học dễ sử dụng, một thiết kế giao diện
hiện đại nên có tính độc lập cao với khối chương trình xử lý dữ liệu. Đối với nhiều hệ thống,
giao diện là bộ phận có tầm quan trọng chủ chốt và có yêu cầu sửa đổi thường xuyên. Do
đó, để tiện cho việc sửa đổi, giao diện nên được thiết kế có tính môđun hóa cao và nên có độ
độc lập tối đa với khối chương trình xử lý dữ liệu. Điều này cũng dẫn đến khả năng chúng ta 139
có thể xây dựng nhiều giao diện khác nhau cho các đối tượng sử dụng khác nhau hay chạy
trên các hệ thống khác nhau.
a. Nguyên lý thiết kế giao diện
• Hướng người dùng: đối tượng người dùng phải rõ ràng, giao diện nên được thiết kế
có tính đến năng lực, thói quen... của loại đối tượng đó.
• Có khả năng tùy biến cao: giao diện nên có khả năng tùy biến cao để phục vụ cho
các cá nhân có cách sử dụng khác nhau, các môi trường hoạt động khác nhau.
• Nhất quán: các biểu tượng, thông báo, cách thức nhập dữ liệu phải nhất quán và nên
tuân theo các chuẩn thông thường.
• An toàn: nên có chế độ xác nhận lại đối với các thao tác nguy hiểm (như xóa dữ
liệu) và nên có khả năng phục hồi trạng thái cũ (undo).
• Dễ học, dễ sử dụng: giao diện luôn cần được thiết kế hướng tới tính dễ học, dễ sử
dụng, tức là không đòi hỏi người dùng phải có các năng lực đặc biệt. Ví dụ như không cần
nhớ nhiều thao tác, không đòi hỏi phải thao tác nhanh, các thông tin trên màn hình dễ
đọc... Một cách tốt nhất để xây dựng giao diện dễ học dễ sử dụng là tuân theo các chuẩn giao diện thông dụng.
b. Các loại giao diện
Có hai dòng giao diện chính là:
- Giao diện dòng lệnh: là loại giao diện đơn giản nhất, thường được thiết kế gắn chặt
với chương trình và có tính di chuyển cao (tương đương với chương trình). Giao diện dòng
lệnh phù hợp với các ứng dụng thuần túy xử lý dữ liệu, nhất là đối với các chương trình mà
đầu ra là đầu vào của chương trình khác. Giao diện dòng lệnh gọn nhẹ, dễ xây dựng nhưng
thường khó học, khó sử dụng và chỉ phù hợp với người dùng chuyên nghiệp trong các ứng dụng đặc thù.
- Giao diện đồ họa: sử dụng các cửa sổ, menu, icon... cho phép người dùng có thể
truy cập song song đến nhiều thông tin khác nhau; người dùng thường tương tác bằng cách
phối hợp cả bàn phím và con chuột; giao diện đồ họa dễ học, dễ sử dụng và trở nên rất
thông dụng và có độ chuẩn hóa cao.
Nhìn trên khía cạnh độc lập với khối chương trình xử lý, có một số cách thức xây
dựng giao diện khác nhau:
- Giao diện đồ họa (GUI) truyền thống: là giao diện đồ họa được thiết kế có độ liên
kết cao với chương trình (được xây dựng cùng ngôn ngữ, cùng bộ công cụ...), hầu hết các
chương trình trên máy tính cá nhân sử dụng loại giao diện này.
- X protocol: giao diện đồ họa sử dụng giao thức X protocol, phổ biến trên các máy
Unix/Linux. Loại giao diện này có ưu diểm là có thể hoạt động độc lập với khối chương
trình còn lại, tức là ta có thể chạy giao diện trên một máy tính trong khi đó phần xử lý bên
trong lại hoạt động trên một máy khác. Đáng tiếc là phương thức này vẫn chưa phổ biến trên
các máy tính cá nhân (chạy hệ điều hành MS Windows). 140
- Client/server: một cách tiếp cận để hướng tới tính độc lập và khả chuyển của giao
diện là xây dựng giao diện như là một chương trình client, tương tác với khối chương trình
xử lý (server) thông qua các giao thức trao đổi thông tin trên mạng (TCP/IP).
- Web based: một trong các cách thức xây dựng giao diện phổ biến hiện nay là dựa
trên nền web, sử dụng các trình duyệt web để trao dổi thông tin với server. Tuy có một số
nhược điểm về an toàn thông tin và tốc độ nhưng với tính độc lập hoàn toàn với phần xử lý,
độ chuẩn hóa cao và khả năng sẵn có trên hầu hết các thiết bị nối mạng, phương thức này
đang được ứng dụng rộng rãi.
c. Các cách tương tác
* Tương tác trực tiếp với thông tin
- ví dụ: soạn thảo; nhập dữ liệu vào các form… - ưu điểm: + dễ học, dễ sử dụng
+ nhận được tức thời kết quả thao tác - nhược điểm
+ cài đặt phức tạp, tốn tài nguyên phần cứng * Tương tác gián tiếp
- ví dụ: chọn lệnh từ menu, giao diện dòng lệnh
- Nhược điểm: kém trực quan
- Ưu điểm: thuận tiện khi lặp lại thao tác phức tạp
- Có 2 cách: Sử dụng thực đơn (menu) và Đối thoại (Dialog)
+ Sử dụng thực đơn (menu): Không cần nhớ lệnh, Tối thiểu hóa dùng bàn phím,
Tránh các lỗi như sai lệnh, sai tham số, Dễ dàng tạo các trợ giúp theo ngữ cảnh
+ Đối thoại (Dialog): Dùng khi cần người dùng đưa ra lựa chọn quyết định
d. Một số vấn đề thiết kế
Trong thiết kế giao diện, cần chú ý tới một số vấn đề sau:
1. Thời gian phản hồi. Chúng ta cần quan tâm tới hai loại thời gian là
• Thời gian đáp ứng trung bình: là thời gian trung bình mà hệ thống phản hồi đối với
một yêu cầu của người dùng. Thời gian để sinh ra “kết quả thực sự” của yêu cầu sẽ phụ
thuộc vào bản chất yêu cầu, thuật toán, tốc độ của máy tính, tuy nhiên chúng ta cần quan
tâm khía cạnh tâm lý là nếu người dùng đợi quá lâu mà không nhận được thông tin gì thì họ
sẽ nghĩ là có vấn đề và có thể sẽ tiến hành các thao tác ngoài mong đợi như lặp lại thao tác hay dừng hệ thống.
• Độ biến thiên của thời gian: độ biến thiên của thời gian cũng là đại lượng cần quan
tâm. Nếu độ biến thiên lớn, ví dụ một thao tác thường được đáp ứng trong 1 giây mà có
trường hợp phải mất 5 giây mới hoàn thành thì cũng có thể làm cho người dùng đưa ra các thao tác sai. 141
2. Các tiện ích. Một giao diện tốt cần có các tiện ích để trợ giúp người sử dụng. Có các loại tiện ích sau
• Tích hợp: là tiện ích được tích hợp vào giao diện như nút Help cung cấp các thuyết minh về thao tác.
• Phụ thêm: là các tiện ích phụ thêm như các tài liệu trực tuyến.
• Macro: một số chương trình còn cho phép người dùng tự động hóa một số thao tác
bằng các lệnh kiểu macro.
3. Thông báo. Các thông báo do hệ thống đưa ra cần
• Có nghĩa: mọi thông báo cần có nghĩa đối với người dùng.
• Ngắn gọn: các thông báo cần ngắn gọn đi vào bản chất vấn đề, đặc biệt là đối với
kiểu giao diện dòng lệnh.
• Có tính xây dựng: thông báo nên có tính xây dựng như đưa ra các nguyên nhân và các hướng khắc phục.
6.3. Yêu cầu đối với thiết kế
- Linh hoạt đối với những yêu cầu thay đổi không định trước. - Dễ thử nghiệm.
- Tính sáng sủa, dễ đọc - Kích thước module nhỏ
- Tính độc lập module (tính mở/đóng giứa các module), sử dụng yếu tố "hộp
- Phải quan hệ chặt chẽ giữa thiết kế và yêu cầu.
- Mỗi module hoàn toàn độc lập, nó thực hiện một chức năng duy nhất và thực hiện
trọn vẹn chức năng đó.
- Mọi thứ trong module ràng buộc với nhau qua việc xử lý nối tiếp nhau trên cùng một dòng dữ liệu.
- Mọi thứ trong module được điều khiển bởi cùng một dữ liệu vào, hay cùng một
phức hợp thiết bị, hay cùng thực hiện từng phần của cùng một kết xuất.
- Module có thể hiểu được hoàn toàn dựa vào những tham biến truyền cho nó và nhận từ nó.
- Khi thiết kế cố gắng giảm thiểu cấu trúc bằng việc tản ra nhiều và cố gắng co cụm khi chiều sâu tăng thêm. 142
- Giữ phạm vi hiệu quả của một module bên trong phạm vi kiểm soát của module đó.
+ Phạm vi hiệu quả của module m được định nghĩa là tất cả các module khác bị ảnh
hưởng bởi một quyết định thực hiện trong module m.
+ Phạm vi kiểm soát của module m là tất cả các module và mọi module thuộc cấp và
thuộc cấp cuối cùng đối với module m.
- Ước lượng giao diện module để giảm độ phức tạp, dư thừa và tăng tính nhất
- Xác định các module có chức năng dự kiến được.
- Cố gắng giữ các module một đầu vào và một đầu ra, tránh các "mối nối bệnh
6.4. Phương pháp và công cụ
6.4.1. Phương pháp thiết kế
a. Hướng chức năng
* Cách tiếp cận hướng chức năng
Thiết kế hướng chức năng là một cách tiếp cận thiết kế phần mềm trong đó bản thiết
kế được phân giải thành một bộ các đơn thể tác động lẫn nhau, mà mỗi đơn thể có một chức
năng được xác định rõ ràng. Các chức năng có các trạng thái cục bộ nhưng chúng chia sẻ
với nhau trạng thái hệ thống, trạng thái này là tập trung và mọi chức năng đều có thể truy
cập được. Nhiều tổ chức đã phát triển các chuẩn và các phương pháp dựa trên sự phân giải
chức năng. Nhiều phương pháp thiết kế kết hợp với công cụ CASE đều là hướng chức năng.
Vô khối các hệ thống đã được phát triển bằng cách sử dụng phương pháp tiếp cận hướng 143
chức năng. Các hệ thống đó sẽ được bảo trì cho một tương lai xa xôi. Bởi vậy thiết kế
hướng chức năng vẫn sẽ còn được tiếp tục sử dụng rộng rãi.
Trong thiết kế hướng chức năng, người ta dùng các biểu đồ luồng dữ liệu (mô tả việc
xử lý dữ liệu), các lược đồ cấu trúc (nó chỉ ra cấu trúc của phần mềm), và các mô tả thiết kế
chi tiết. Thiết kế hướng chức năng gắn với các chi tiết của một thuật toán của chức năng đó
nhưng các thông tin trạng thái hệ thống là không bị che dấu. Việc thay đổi một chức năng và
cách nó sử dụng trạng thái của hệ thống có thể gây ra những tương tác bất ngờ đối với các
chức năng khác. Cách tiếp cận chức năng để thiết kế là tốt nhất khi mà khối lượng thông tin
trạng thái hệ thống được làm nhỏ nhất và thông tin dùng chung nhau là rõ ràng.
* Biểu đồ luồng dữ liệu
Biểu đồ luồng dữ liệu chỉ ra cách thức biến đổi dữ liệu vào thành dữ liệu ra thông qua
một dãy các phép biến đổi. Bước thứ nhất của thiết kế hướng chức năng là phát triển một
biểu đồ luồng dữ liệu hệ thống. Biểu đồ này không nhất thiết bao gồm các thông tin điều
khiển nhưng nên lập tư liệu các phép biến đổi dữ liệu. Biểu đồ luồng dữ liệu là một phần
hợp nhất của một số các phương pháp thiết kế và các công cụ CASE thường trợ giúp cho
việc tạo ra biểu đồ luồng dữ liệu.
* Lược đồ cấu trúc
Lược đồ cấu trúc chỉ ra cấu trúc các thành phần theo thứ bậc của hệ thống. Nó chỉ ra
rằng các phần tử của một biểu đồ luồng dữ liệu có thể được thực hiện như thế nào với tư
cách là một thứ bậc của các đơn vị chương trình. Lược đồ cấu trúc có thể được dùng như là
một mô tả chương trình nhìn thấy được với các thông tin xác định các sự lựa chọn và các
vòng lặp. Lược đồ cấu trúc được dùng để trình bày một tổ chức tĩnh của thiết kế.
* Các từ điển dữ liệu
Từ điển dữ liệu vừa có ích cho việc bảo trì hệ thống vừa có ích trong quá trình thiết
kế. Với mỗi khái niệm thiết kế, cần có một từ khóa mô tả ứng với từ khóa (entry) của từ
điển dữ liệu cung cấp thông tin về khái niệm đó (kiểu, chức năng của dữ liệu...). Đôi khi
người ta gọi cái này là một mô tả ngắn của chức năng thành phần. Các từ điển dữ liệu dùng
để nối các mô tả thiết kế kiểu biểu đồ và các mô tả thiết kế kiểu văn bản. Một vài bộ công
cụ CASE cung cấp một phép nối tự động biểu đồ luồng dữ liệu và từ điển dữ liệu.
b. Hướng đối tượng
* Cách tiếp cận hướng đối tượng
Thiết kế hướng đối tượng dựa trên chiến lược che dấu thông tin cấu trúc vào bên
trong các thành phần. Cái đó ngầm hiểu rằng việc kết hợp điều khiển logic và cấu trúc dữ
liệu được thực hiện trong thiết kế càng chậm càng tốt. Liên lạc thông qua các thông tin trạng
thái dùng chung (các biến tổng thể) là ít nhất, nhờ vậy khả năng hiểu được nâng lên. Thiết
kế là tương đối dễ thay đổi vì sự thay đổi cấu trúc một thành phần có thể không cần quan
tâm tới các hiệu ứng phụ trên các thành phần khác.
Việc che dấu thông tin trong thiết kế hướng đối tượng là dựa trên sự nhìn hệ phần
mềm như là một bộ các đối tượng tương tác với nhau chứ không phải là bộ các chức năng
như cách tiếp cận chức năng. Các đối tượng có một trạng thái riêng được che dấu và các 144
phép toán trên trạng thái đó. Thiết kế biểu thị các dịch vụ được yêu cầu cùng với những hỗ
trợ mà các đối tượng có tương tác với nó cung cấp.
* Ba đặc trưng của thiết kế hướng đối tượng
Thiết kế hướng đối tượng bao gồm các đặc trưng chính sau:
1. Không có vùng dữ liệu dùng chung. Các đối tượng liên lạc với nhau bằng cách trao đổi thông báo.
2. Các đối tượng là các thực thể độc lập, dễ thay đổi vì rằng tất cả các trạng thái và
các thông tin biểu diễn chỉ ảnh hưởng trong phạm vi chính đối tượng đó thôi. Các thay đổi
về biểu diễn thông tin có thể được thực hiện không cần sự tham khảo tới các đối tượng khác.
3. Các đối tượng có thể phân tán và có thể hoạt động tuần tự hoặc song song. Đây là
một trong những lý do khiến cho thiết kế hướng đối tượng được sử dụng rộng rãi trong các hệ thống nhúng.
* Cơ sở của thiết kế hướng đối tượng
Cơ sở của thiết kế hướng đối tượng là các lớp. Lớp là một trừu tượng mô tả cho một
nhóm sự vật. Đối tượng của một lớp là một thực thể (cụ thể hóa) của lớp đó. Thiết kế của một lớp bao gồm:
- Cấu trúc dữ liệu (thuộc tính)
- Hàm, thủ tục (chức năng)
- Giao diện (cung cấp khả năng trao đổi dữ liệu đối với các lớp khác, về bản chất là
các chức năng của đối tượng)
Việc cài đặt các giao diện là một yếu tố quan trọng để đảm bao che dấu cấu trúc dữ
liệu. Tức là thiết kế nội tại của đối tượng độc lập với giao diện do đó chúng ta có thể sửa đổi
thiết kế mà không sợ ảnh hưởng tới các đối tượng khác.
Các đối tượng trao đổi với nhau bằng cách truyền các thông báo. Tức là một đối
tượng yêu cầu một đối tượng khác thực hiện một chức năng nào đó. Thông báo bao gồm:
tên đối tượng, tên phương thức, và các tham số.
Vòng đời của một đối tượng khi hệ thống hoạt động như sau:
- Khởi tạo: hệ thống tạo ra đối tượng bằng cách xác lập vùng dữ liệu đồng thời tự
động thực hiện các chức năng liên quan đến khởi tạo đối tượng.
- Hoạt động: đối tượng nhận các thông báo và thực hiện các chức năng được yêu cầu.
- Phá hủy: hệ thống giải phóng vùng nhớ đã được cấp phát sau khi thực hiện tự động
các thao tác cần thiết để hủy đối tượng.
Nhờ có chức năng khởi tạo và phá hủy được gọi tự động chúng ta có thể tự động hóa
được một số công việc và tránh được nhiều sai sót trong lập trình như quên khởi tạo dữ liệu,
quên cấp phát hay quên giải phóng vùng nhớ động.
- Sự kế thừa. Kế thừa là một khái niệm quan trọng trong thiết kế hướng đối tượng.
Một lớp có thể được định nghĩa dựa trên sự kế thừa một hoặc nhiều lớp đã được định nghĩa.
Kế thừa ở đây bao gồm 145
- Kế thừa cấu trúc dữ liệu - Kế thừa chức năng
Khả năng kế thừa giúp cho rút gọn được chương trình và nâng cao tính tái sử dụng.
Một chiến lược chung là trước tiên tạo ra các lớp trừu tượng (để có thể dùng chung) và đối
với các bài toán cụ thể tạo ra các lớp kế thừa bằng cách thêm các thông tin đặc thù.
* Các bước thiết kế
Thiết kế hướng đối tượng bao gồm các bước chính sau:
1. Xác định lớp đối tượng.
2. Xác định thuộc tính cho lớp: các biến của lớp
3. Xác định hành vi (chức năng): các hàm
4. Xác định tương tác giữa các lớp đối tượng: giao diện (thông báo).
5. Áp dụng tính kế thừa: xây dựng các lớp trừu tượng có các thuộc tính chung, đây là
một khâu đặc trưng của thiết kế hướng đối tượng.
Ví dụ, giả sử cần xây dựng các lớp hình tròn, elíp và đa giác. Có thể thấy elip và hình
tròn có một số các thuộc tính chung như tọa độ tâm, chúng ta có thể xây dựng lớp hình nón
chứa các thuộc tính chung này. Giữa hình nón và đa giác lại có thể tìm ra các thuộc tính
chung như mầu nền, mầu biên..., và có thể xây dựng lớp trừu tượng hình hình học chứa các thuộc tính này.
Phương pháp xác định đối tượng Xác định đối tượng là một trong nhưng công đoạn
thiết kế quan trọng, phụ thuộc nhiều vào kinh nghiệm và bài toán cụ thể. Có một số phương
pháp được đề xuất, một trong các phương pháp này là phân tích từ vựng của “câu yêu cầu”.
Cụ thể là danh từ trong câu yêu cầu sẽ được coi là đối tượng và động từ sẽ được coi là chức năng.
Ví dụ: Với yêu cầu Phần mềm Email cung cấp cho user khả năng gửi thư, đọc thư và
soạn thảo thư điện tử., chúng ta có thể sơ bộ tạo ra các đối tượng phần mềm, user, email và
các chức năng gửi, nhận, soạn thảo.
* Ưu nhược điểm của thiết kế hướng đối tượng
Thiết kế hướng đối tượng có các ưu điểm chính sau:
• Dễ bảo trì vì các đối tượng là độc lập. Các đối tượng có thể hiểu và cải biên như là
một thực thể độc lập. Thay đổi trong thực hiện một đối tượng hoặc thêm các dịch vụ sẽ
không làm ảnh hưởng tới các đối tượng hệ thống khác.
• Các đối tượng là các thành phần dùng lại được thích hợp do tính độc lập của chúng
và khả năng kế thừa cao.
• Có một vài lớp hệ thống thể hiện phản ánh quan hệ rõ ràng giữa các thực thể có
thực (chẳng hạn như các thành phần phần cứng) với các đối tượng điều khiển nó trong hệ
thống. Điều này đạt được tính dễ hiểu của thiết kế.
Nhược điểm chính của thiết kế hướng đối tượng là sự khó nhận ra các đối tượng của
một hệ thống. Cách nhìn tự nhiên đối với nhiều hệ thống là cách nhìn chức năng. 146
* Quan hệ giữa thiết kế và lập trình hướng đối tượng
Thiết kế hướng đối tượng là một chiến lược thiết kế, không phụ thuộc vào ngôn ngữ
thực hiện cụ thể nào. Các ngôn ngữ lập trình hướng đối tượng có các khả năng bao gói đối
tượng, và kế thừa làm cho việc thực hiện thiết kế hướng đối tượng an toàn hơn và đơn giản hơn.
Một thiết kế hướng đối tượng cũng có thể được thực hiện trong một ngôn ngữ thủ tục
kiểu như PASCAL hoặc C (không có các đặc điểm bao gói như vậy). Ada không phải là
ngôn ngữ lập trình hướng đối tượng vì nó không trợ giúp sự thừa kế của các lớp, nhưng lại
có thể thực hiện các đối tượng trong Ada bằng cách sử dụng các gói hoặc các nhiệm vụ
(tasks), do đó Ada cũng được dùng để mô tả các thiết kế hướng đối tượng.
Tuy nhiên, cũng phải nhấn mạnh rằng chúng ta có thể mô tả thiết kế hướng đối tượng
trên các ngôn ngữ truyền thống nhưng chúng ta không thể kiểm tra được sự tuân thủ tư
tưởng hướng đối tượng trên các ngôn ngữ này, nghĩa là người phát triển vẫn có thể truy cập
đến cấu trúc dữ liệu vật lý của đối tượng và việc đó làm vô nghĩa khái niệm che dấu thông tin.
Việc chấp nhận thiết kế hướng đối tượng như là một chiến lược hữu hiệu dẫn đến sự
phát triển rộng rãi các phương pháp thiết kế hướng đối tượng và các ngôn ngữ lập trình hướng đối tượng.
c. Quan hệ giữa thiết kế hướng đối tượng và hướng chức năng
Có nhiều quan niệm khác nhau về quan hệ giữa thiết kế hướng đối tượng và thiết kế
hướng chức năng. Có người cho rằng, hai chiến lược thiết kế này hỗ trợ lẫn nhau, cụ thể là
- DFD đưa ra mô hình về các thuộc tính và chức năng
- Luồng giao tác đưa ra hướng dẫn về tương tác giữa các đối tượng (thông báo)
- Mô hình E - R đưa ra hướng dẫn xây dựng đối tượng
Thêm nữa, thiết kế nội tại của lớp đối tượng có nhiều điểm tương đồng với thiết kế hướng chức năng.
Một quan điểm khác cho rằng thiết kế hướng đối tượng và thiết kế hướng chức năng
là hai cách tiếp cận hoàn toàn khác nhau, các khái niệm như che dấu thông tin, kế thừa là
đặc trưng quan trọng và bản chất của thiết kế hướng đối tượng và nếu không dứt bỏ cách
nhìn thiết kế hướng chức năng thì không thể khai thác hiệu quả các đặc trưng này.
6.4.2. Công cụ
a. Power Designer
* Giới thiệu chung về POWER DESIGNER
PowerDesigner là môi trường mô hình hóa tổng thể doanh nghiệp dưới dạng đồ họa
và dễ dàng sử dụng. Nó cung cấp:
- Việc mô hình hóa được tích hợp thông qua các phương pháp và các ký hiệu chuẩn. o Data (E/R, Merise) 147
o Business (BPMN, BPEL, ebXML) o Application (UML)
- Phát sinh code tự động thông qua các template có thể tùy chỉnh được
o SQL (with more than 50 supported DBMSs) o Java o .NET
- Khả năng đối chiếu mạnh mẽ để làm tài liệu và cập nhật các hệ thống hiện có.
- Khả năng tạo báo cáo tự động, có thể tùy chỉnh được
- Một môi trường có thể mở rộng, cho phép bạn thêm các luật, câu lệnh, khái niệm,
thuộc tính mới cho các phương pháp mã hóa và mô hình hóa
* Hỗ trợ của Power Designer đối với đội phát triển dự án
Một đội phát triển bao gồm chuyên viên phân tích nghiệp vụ, phân tích và thiết kế,
quản trị dữ liệu, lập trình viên, tester. Mỗi người sẽ sử dụng một số tính năng khác nhau của Power Designer:
Business Analysts (chuyên viên phân tích nghiệp vụ): Xác định kiến trúc của tổ chức,
các yêu cầu nghiệp vụ, và các dòng chảy nghiệp vụ ở cấp cao. Họ có thể sử dụng các component sau:
 Enterprise Architecture Model (EAM)  Requirements Model (RQM):
 Business Process Model (BPM):
Data Analysts and Designers (Chuyên viên phân tích và thiết kế): Sẽ gắn kết các yêu
cầu kỹ thuật với các yêu cầu nghiệp vụ. Đi sâu hơn vào việc phân tích, bạn có thể định
nghĩa Use Cases và kết chúng với các yêu cầu. Bạn có thể mô tả các đặc điểm kỹ thuật
thuộc về chức năng và định nghĩa chính xác hơn bản chất và chi tiết của từng tiến trình, ứng
dụng và cấu trúc dữ liệu của ứng dụng. Bạn có thể sử dụng mô hình Tiến trình nghiệp vụ
(Business Process Model – BPM) và một mô hình dữ liệu quan niệm
 Conceptual Data Model (CDM):
Database Administrators (Quản trị cơ sở dữ liệu): Sử dụng cấu trúc dữ liệu đã được
định nghĩa tốt để tối đa hóa, và tạo cơ sở dữ liệu. Bạn sẽ sử dụng:
 Physical Data Model (PDM):  Logical Data Model (LDM):
 Information Liquidity Model (ILM):
Developers (Lập trình viên): Sẽ viết các chi tiết kỹ thuật trong một Requirements
Model (RQM), và sẽ xây dựng ứng dụng, định nghĩa các hành vi và cấu trúc đối tượng và
các sơ đồ đối tượng/quan hệ.
 Object-Oriented Model (OOM):  XML Model (XSM): 148
Team Leaders (Trưởng nhóm): Sẽ quan tâm tới tất cả các mô hình, và sẽ muốn đảm
bảo rằng tất cả các yêu cầu, các đối tượng thiết kế, và các tài liệu được liên kết với nhau
thông qua các liên kết lưu vết tính đến tác động phân tích và thay đổi sự quản lý.
 PowerDesigner Enterprise Repository: là khu vực trung tâm của sự lưu trữ. Kho
hỗ trợ chia sẽ dữ liệu lớn, phiên bản, và báo cáo cho các mô hình và các tài liệu
hệ thống khác; có một hệ thống bảo mật mạnh và hỗ trợ khả năng mở rộng
doanh nghiệp thực sự từ một trường hợp kho đơn.
 Report Editor: Bạn có thể đảm bảo rằng các tài liệu luôn được cập nhật và chính
xác. Report Editor cho phép bạn tự động hóa việc tạo ra các báo cáo chi tiết (theo
format RTF và HTML) trên bất cứ hoặc tất cả các thành phần của hệ thống
để chia sẻ thông tin thiết kế trong đội dự án và trong toàn công ty.
 Free Model (FEM): được sử dụng để tạo ra các sơ đồ để giải thích kiến trúc
hệ thống và các ứng dụng, kịch bản use-case của các ứng dụng, các sơ đồ dòng
chảy và các hình vẽ khác.
Tester (Kiểm thử viên): sẽ sử dụng Requirements Model (RQM), Conceptual Data
Model (CDM) và các mô hình khác cùng với các tài liệu thiết kế để hiểu được ứng dụng nên
làm việc thế nào và nó được phát triển như thế nào
b. Rational Rose
Rational Rose là một công cụ lập mô hình trực quan mạnh trợ giúp bạn phân tích và
thiết kế các hệ thống phần mềm hướng đối tượng. Nó được dùng để lập mô hình hệ thống
trước khi bạn viết mã (code). Dùng mô hình, bạn có thể bắt kịp những thiếu sót về thiết kế,
trong khi việc chỉnh sửa chúng vẫn chưa tốn kém.
Mô hình Rose là bức tranh về một hệ thống từ nhiều góc nhìn khác nhau. Nó bao
gồm tất cả các sơ đồ UML, các actor, các use case, các đối tượng, các lớp, các thành phần…
Nó mô tả chi tiết nội dung mà hệ thống sẽ gộp và cách nó sẽ làm việc.
Có thể xem một mô hình Rose tương tự như bản thiết kế mẫu. Giống như một căn
nhà có nhiều bản thiết kế mẫu cho phép các thành viên trong đội xây dựng xem xét nó từ
nhiều góc nhìn khác nhau như : hệ thống ống nước, hệ thống điện, hệ thống nền … Một mô
hình Rose chứa đựng các sơ đồ khác nhau cho phép các thành viên trong nhóm đề án xem
hệ thống từ các góc nhìn khác nhau như : khách hàng, nhà thiết kế, quản trị đề án, …
Khi đã có được bản thiết kế thì sẽ giảm bớt một số vấn đề phiền phức như: lập trình
theo truyền thống thì khi hoàn tất đề án, sau một thời gian sử dụng khách hàng yêu cầu thêm
một vài chức năng nào đó vì có cập nhật mới thì người lập trình phải xem lại toàn bộ hệ
thống rồi sau đó mới cập nhật. Điều này tốn rất nhiều thời gian. Nay nhờ có bản thiết kế thì
chỉ cần xem cập nhật đó nằm ở phần nào và chỉnh sửa, nâng cấp hệ thống. Điều đó sẽ linh
hoạt và giảm rất nhiều thời gian…
Có ba phiên bản khác nhau của Rose :
 Rose Modeler : cho phép bạn tạo mô hình cho hệ thống, nhưng không hỗ trợ tiến
trình phát sinh mã hoặc thiết kế kỹ thuật đảo ngược.
 Rose Professional : cho phép bạn phát sinh mã trong một ngôn ngữ 149
 Rose Enterprise : cho phép bạn phát sinh mã cho C--, Java, Ada, Corba, Visual
Basic, Oracle … Một mô hình có thể có các thành phần được phát sinh bằng các ngôn ngữ khác nhau.
Chương 7. Lập trình
7.1. Ngôn ngữ lập trình
Ngôn ngữ lập trình là phương tiện để liên lạc giữa con người và máy tính. Tiến trình
lập trình - sự liên lạc thông qua ngôn ngữ lập trình - là một hoạt động con người. Lập trình
là bước cốt lõi trong tiến trình kỹ nghệ phần mềm.
7.1.1 Đặc trưng của ngôn ngữ lập trình
Cách nhìn kỹ nghệ phần mềm về các đặc trưng của ngôn ngữ lập trình tập trung vào
nhu cầu xác định dự án phát triển phần mềm riêng. Mặc dầu người ta vẫn cần các yêu cầu
riêng cho chương trình gốc, có thể thiết lập được một tập hợp tổng quát những đặc trưng kỹ nghệ:
(1) dễ dịch thiết kế sang chương trình,
(2) có trình biên dịch hiệu quả,
(3) khả chuyển chương trình gốc,
(4) có sẵn công cụ phát triển, (5) dễ bảo trì.
Bước lập trình bắt đầu sau khi thiết kế chi tiết đã được xác định, xét duyệt và sửa đổi
nếu cần. Về lý thuyết, việc sinh chương trình gốc từ một đặc tả chi tiết nên là trực tiếp. Dễ
dịch thiết kế sang chương trình đưa ra một chỉ dẫn về việc một ngôn ngữ lập trình phản xạ
gần gũi đến mức nào cho một biểu diễn thiết kế. Một ngôn ngữ cài đặt trực tiếp cho các kết
cấu có cấu trúc, các cấu trúc dữ liệu phức tạp, vào/ra đặc biệt, khả năng thao tác bit, và các
kết cấu hướng sự vật sẽ làm cho việc dịch từ thiết kế sang chương trình gốc dễ hơn nhiều
(nếu các thuộc tính này được xác định trong thiết kế).
Mặc dầu những tiến bộ nhanh chóng trong tốc độ xử lý và mật độ nhớ đã bắt đầu làm
giảm nhẹ nhu cầu chương trình siêu hiệu quả, nhiều ứng dụng vẫn còn đòi hỏi các chương
trình chạy nhanh, gọn (yêu cầu bộ nhớ thấp). Các ngôn ngữ với trình biên dịch tối ưu có thể 150
là hấp dẫn nếu hiệu năng phần mềm là yêu cầu chủ chốt. Tính khả chuyển chương trình gốc
là một đặc trưng ngôn ngữ lập trình có thể được hiểu theo ba cách khác nhau:
- Chương trình gốc có thể được chuyển từ bộ xử lý này sang bộ xử lý khác và từ trình
biên dịch nọ sang trình biên dịch kia với rất ít hoặc không phải sửa đổi gì.
- Chương trình gốc vẫn không thay đổi ngay cả khi môi trường của nó thay đổi (như
việc cài đặt bản mới của hệ điều hành).
- Chương trình gốc có thể được tích hợp vào trong các bộ trình phần mềm khác nhau
với ít hay không cần thay đổi gì vì các đặc trưng của ngôn ngữ lập trình.
Trong số ba cách hiểu về tính khả chuyển này thì cách thứ nhất là thông dụng nhất.
Việc đưa ra các chuẩn (do tổ chức tiêu chuẩn quốc tế IFO hay Viện tiêu chuẩn quốc gia Mĩ -
ANSI) góp phần làm nâng cao tính khả chuyển. Tính sẵn có của công cụ phát triển có thể
làm ngắn bớt thời gian cần để sinh ra chương trình gốc và có thể cải thiện chất lượng của
chương trình. Nhiều ngôn ngữ lập trình có thể cần tới một loạt công cụ kể cả trình biên dịch
gỡ lỗi, trợ giúp định dạng chương trình gốc, các tiện nghi soạn thảo có sẵn, các công cụ
kiểm soát chương trình gốc, thư viện chương trình con mở rộng trong nhiều lĩnh vực ứng
dụng, các trình duyệt, trình biên dịch chéo cho phát triển bộ vi xử lý, khả năng bộ xử lý
macro, công cụ kỹ nghệ ngược và những công cụ khác. Trong thực tế, khái niệm về môi
trường phát triển phần mềm tốt (bao hàm cả các công cụ) đã được thừa nhận như nhân tố
đóng góp chính cho kỹ nghệ phần mềm thành công.
Tính dễ bảo trì của chương trình gốc có tầm quạn trọng chủ chốt cho tất cả các nỗ lực
phát triển phần mềm không tầm thường. Việc bảo trì không thể được tiến hành chừng nào
người ta còn chưa hiểu được phần mềm. Các yếu tố của cấu hình phần mềm (như tài liệu
thiết kế) đưa ra một nền tảng cho việc hiểu biết, nhưng cuối cùng thì chương trình gốc vẫn
phải được đọc và sửa đổi theo những thay đổi trong thiết kế.
Tính dễ dịch thiết kế sang chương trình là một yếu tố quan trọng để dễ bảo trì chương
trình gốc. Bên cạnh đó, các đặc trưng tự làm tài liệu của ngôn ngữ (như chiều dài được phép
của tên gọi, định dạng nhãn, định nghĩa kiểu, cấu trúc dữ liệu) có ảnh hưởng mạnh đến tính dễ bảo trì.
7.1.2 Lựa chọn ngôn ngữ lập trình
Các đặc trưng của ngôn ngữ lập trình sẽ quyết định miền ứng dụng của ngôn ngữ.
Miền ứng dụng là yếu tố chính để chúng ta lựa chọn ngôn ngữ cho một dự án phần mềm. C
thường là một ngôn ngữ hay được chọn cho việc phát triển phần mềm hệ thống.
Trong các ứng dụng thời gian thực chúng ta hay gặp các ngôn ngữ như Ada, C, C--
và cả hợp ngữ do tính hiệu quả của chúng. Các ngôn ngữ này và Java cũng được dùng cho
phát triển phần mềm nhúng.
Trong lĩnh vực khoa học kỹ thuật thì FORTRAN với khả năng tính toán với độ chính
xác cao và thư viện toán học phong phú vẫn còn là ngôn ngữ thống trị. Tuy vậy, PASCAL
và C cũng được dùng rộng rãi.
COBOL là ngôn ngữ cho ứng dụng kinh doanh và khai thác CSDL lớn nhưng các
ngôn ngữ thế hệ thứ tư đã dần dần chiếm ưu thế. 151
BASIC vẫn đang tiến hóa (Visual Basic) và được đông đảo người dùng máy tính cá
nhân ủng hộ mặc dù ngôn ngữ này rất hiếm khi được những người phát triển hệ thống dùng.
Các ứng dụng trí tuệ nhân tạo thường dùng các ngôn ngữ như LISP, PROLOG hay
OPS5, tuy vậy nhiều ngôn ngữ lập trình (vạn năng) khác cũng được dùng.
Xu hướng phát triển phần mềm hướng đối tượng xuyên suốt phần lớn các miền ứng
dụng đã mở ra nhiều ngôn ngữ mới và các dị bản ngôn ngữ qui ước. Các ngôn ngữ lập trình
hướng đối tượng được dùng rộng rãi nhất là Smalltalk, C--, Java. Ngoài ra còn có Eiffel,
Objectư PASCAL, Flavos và nhiều ngôn ngữ khác.
Với đặc trưng hướng đối tượng, tính hiệu quả thực hiện cũng như có nhiều công cụ
và thư viện, C-- hiện đang được sử dụng rộng rãi trong lĩnh vực phát triển các ứng dụng nghiệp vụ.
Java cũng là một ngôn ngữ hướng đối tượng đang được sử dụng rộng rãi cho phát
triển các dịch vụ Web và phần mềm nhúng vì các lý do độ an toàn cao, tính trong sáng, tính
khả chuyển và hướng thành phần. Theo một số thống kê thì tốc độ phát triển một ứng dụng
mới bằng Java cao hơn đến 2 lần so với các ngôn ngữ truyền thống như C hay thậm chí C--.
Các ngôn ngữ biên dịch (script) với những câu lệnh và thư viện mạnh hiện đang rất được
chú ý. ASP, JavaScript, PERL... đang được sử dụng rộng rãi trong lập trình Web.
7.1.3 Ngôn ngữ lập trình và và sự ảnh hưởng tới kỹ nghệ phần mềm
Nói chung, chất lượng của thiết kế phần mềm được thiết lập theo cách độc lập với
các đặc trưng ngôn ngữ lập trình. Tuy nhiên thuộc tính ngôn ngữ đóng một vai trò trong
chất lượng của thiết kế được cài đặt và ảnh hưởng tới cách thiết kế được xác định. Ví dụ
như khả năng xây dựng mô đun và bao gói chương trình. Thiết kế dữ liệu cũng có thể bị ảnh
hưởng bởi các đặc trưng ngôn ngữ. Các ngôn ngữ lập trình như Ada, C--, Smalltalk đều hỗ
trợ cho khái niệm về kiểu dữ liệu trừu tượng - một công cụ quan trọng trong thiết kế và đặc
tả dữ liệu. Các ngôn ngữ thông dụng khác, như PASCAL, cho phép định nghĩa các kiểu dữ
liệu do người dùng xác định và việc cài đặt trực tiếp danh sách móc nối và những cấu trúc
dữ liệu khác. Các tính năng này cung cấp cho người thiết kế phạm vi rộng hơn trong các
bước thiết kế sơ bộ và chi tiết.
Các đặc trưng của ngôn ngữ cũng ảnh hưởng tới kiểm thử phần mềm. Các ngôn ngữ
trực tiếp hỗ trợ cho các kết cấu có cấu trúc có khuynh hướng giảm bớt độ phức tạp của
chương trình, do đó có thể làm cho nó dễ dàng kiểm thử. Các ngôn ngữ hỗ trợ cho việc đặc
tả các chương trình con và thủ tục ngoài (như FORTRAN) thường làm cho việc kiểm thử
tích hợp ít sinh lỗi hơn.
7.2. Các phương pháp lập trình
7.2.1. Lập trình tuần tự
Vào thủa sơ khai phương pháp lập trình là lập trình tuần tự. Một chương trình sẽ là
một tập hợp các câu lệnh có thứ tự chạy nối tiếp nhau. 152
Chương trình sẽ chạy từ câu lệnh đầu tiên, và kết thúc ở câu lệnh cuối cùng. Lập
trình thế này khó, lâu, và việc xử lý các bài toán lớn sẽ khó khăn, chương trình chỉ có thể
viết theo một cấu trúc duy nhất là tuần tự.
7.2.2. Lập trình cấu trúc
Đây là một phần của phương pháp lập trình thủ tục, ở phương pháp lập trình này ngoài
cấu trúc tuần tự, ta có thể viết chương trình theo các cấu trúc rẽ nhánh, cấu trúc vòng lặp và kết
hợp của các cấu trúc đó với nhau. Ở phương pháp lập trình này xuất hiện khái niệm về cấu
trúc điều khiển(control structure) như if-else, switch case.. để khiển rẽ nhánh, hay for, while để điều khiển vòng lặp.
Phương pháp này đã khiến việc lập trình trở lên linh hoạt hơn rất nhiều, nhưng nó
vẫn thực sự hạn chế khi lập trình các hệ thống lớn. Hiện nay nó không còn là phương pháp
lập trình thông dụng. Nhưng nó vẫn tồn tại như là một phần không thể thiếu trong các
phương pháp lập trình hiện đại hơn.
7.2.3. Lập trình hướng đối tượng
Lập trình hướng đối tượng, hay còn được sử dụng với thuật ngữ OOP (Object-
Oriented Programming) Đây là phương pháp lập trình hiện đại và phổ biến nhất hiện nay.
Phương pháp lập trình hiện đại giúp cho công việc lập trình càng ngàng được trìu tượng hóa
và trở lên “gần với con người” hơn. 153
Việc lập trình không còn dừng ở việc thiết kế các thủ tục khô khan, phương pháp lập
trình hướng đối tượng xây dựng trên mô hình thế giới thực, khi mà mọi thứ đều là các đối
tượng. Các đối tượng sẽ chứa đựng trong nó các thuộc tính, các hành động của riêng nó. Ví
dụ như mỗi người sẽ có trong mình thuộc tính tên, tuổi, giới tính và có các hành động, đi, chạy nhảy..
Phương pháp lập trình hướng đối tượng gắn liền với các thuật ngữ Lớp (class), Đối
tượng (object), Thuộc tính (attribute), Phương thức (method)
Class là phân loại các đối tượng, một object phải thuộc một hay nhiều class nào đó.
Khi lập trình chúng ta phải xác định bài toán gồm các đối tượng nào, từ đó ta sẽ xác định
được bài toán gồm những class nào. Ví dụ quản lý lớp học thì ta sẽ có class giáo viên, học sinh.
Object là một thể hiện của class, một Object phải là duy nhất. Ví dụ class giáo viên
thì sẽ có Cô A, Thầy B, class học sinh sẽ có thể hiện là Bạn D, bạn E.
Attribute là các thuộc tính, hay còn gọi là trường, hay dữ liệu. Ví dụ class Giáo viên
có thuộc tính là Tên giáo viên, Môn học (môn mà giáo viên dạy), class Học sinh thì có thuộc
tính là Tên học sinh, vị trí chỗ ngồi..v.v
Method là các phương thức, hành vi mà đối tượng có thể thực hiện. Ví dụ một đối
tượng giáo viên có phương thức chấm điểm, phương thức giảng bài, một đối tượng học sinh
thì có phương thức làm bài tập, giơ tay phát biểu..v.v
Vì lập trình hướng đối tượng thể hiện thế giới thực, nên nó cũng có các tính chất đặc
trưng: Tính trìu tượng, tính đóng gói, tính đa hình tính kế thừa. ,
Lập trình hướng đối tượng đem lại cho người lập trình một phương pháp tư duy xây
dựng bài toán ở mức gần gũi với thế giới thực tế nhất. Mình thường nói vui việc lập trình
hướng đối tượng giống như việc chúa trời tạo ra thế giới vậy. Phương pháp lập trình hướng
đối ngoài ưu điểm như tái sử dụng, nó còn có các ưu điểm như tính bảo mật cao, tính nhất quán dữ liệu.
Hầu hết các ngôn ngữ lập trình hiện đại đều có xu hướng hỗ trợ lập trình hướng đối
tượng. Các ngôn ngữ lập trình hướng đối tượng phổ biến: Objective-C, C--, JAVA, C#..
7.2.4. Lập trình logic
Trong lập trình logic, ta có thể sử dụng các vị từ để định nghĩa các khái niệm của tất
cả các môn khoa học khác. 154
Ví dụ định nghĩa một số nguyên tố:
Số nguyên tố N là một số nguyên lớn hơn 1, chỉ chia hết cho 1 và chính nó.
Để xét xem số N có phải là số nguyên tố hay không, người ta thường sử dụng dấu
hiệu nhận biết: Số nguyên tố là một số nguyên dương, không chia hết cho mọi số nguyên tố
nhỏ hơn nó và 2 là số nguyên tố nhỏ nhất.
Dấu hiệu này có thể mô tả bằng các vị từ như sau:
- 2 là một số nguyên tố.
- N là một số nguyên tố nếu N>0, M là số nguyên tố nào đó, Mhết cho M.
Khi mô tả bài toán dưới dạng logic vị từ, ta có thể yêu cầu hệ thống tìm kiếm các lời
giải liên quan đến các khai báo đó. Bài toán cần giải được xem là “mục tiêu” mà hệ thống
phải chứng minh trên cơ sở các tri thức đã được khai báo.
Như thế, toàn bộ các ký hiệu của ngôn ngữ lập trình suy về một công thức đặc biệt: -
Phát sinh từ một yêu cầu. -
Nhằm chứng minh một mục tiêu. Để trả lời cho câu hỏi đó hệ thống xem nó như là
một “đích” và cố chứng minh “đích” đó bằng cách tạo những suy diễn trên cơ sở
các tri thức đã khai báo.
Một ngôn ngữ logic có thể được dùng trong giai đoạn đặc tả yêu cầu của quy trình xây
dựng một sản phẩm phần mềm. Hơn thế nữa, logic vị từ cho phép biểu diễn hầu hết các khái
niệm và các định lý trong các bộ môn khoa học.
Một trong những ngôn ngữ lập trình logic có hỗ trợ rất nhiều cho lĩnh vực trí tuệ nhân tạo là ngôn ngữ Prolog
7.3. Phong cách lập trình
Phong cách lập trình bao hàm một triết lý về lập trình nhấn mạnh tới tính dễ hiểu của
chương trình nguồn. Các yếu tố của phong cách bao gồm: tài liệu bên trong chương trình,
phương pháp khai báo dữ liệu, cách xây dựng câu lệnh và các kỹ thuật vào/ra.
7.3.1 Tài liệu chương trình
Tài liệu bên trong của chương trình gốc bắt đầu với việc chọn lựa các tên gọi định
danh (biến và nhãn), tiếp tục với vị trí và thành phần của việc chú thích, và kết luận với cách
tổ chức trực quan của chương trình. Việc lựa chọn các tên gọi định danh có nghĩa là điều
chủ chốt cho việc hiểu chương trình. Những ngôn ngữ giới hạn độ dài tên biến hay nhãn làm
các tên mang nghĩa mơ hồ. Cho dù một chương trình nhỏ thì một tên gọi có nghĩa cũng làm tăng tính dễ hiểu.
Theo ngôn từ của mô hình cú pháp/ngữ nghĩa tên có ý nghĩa làm “đơn giản hóa việc
chuyển đổi từ cú pháp chương trình sang cấu trúc ngữ nghĩa bên trong”.
Một điều rõ ràng là: phần mềm phải chứa tài liệu bên trong. Lời chú thích cung cấp
cho người phát triển một ý nghĩa truyền thông với các độc giả khác về chương trình gốc.
Lời chú thích có thể cung cấp một hướng dẫn rõ rệt để hiểu trong pha cuối cùng của kỹ nghệ
phần mềm - bảo trì. Có nhiều hướng dẫn đã được đề nghị cho việc viết lời chú thích. Các 155
chú thích mở đầu và chú thích chức năng là hai phạm trù đòi hỏi cách tiếp cận có hơi khác.
Lời chú thích mở đầu nên xuất hiện ở ngay đầu của mọi modul. Định dạng cho lời chú thích như thế là:
1. Một phát biểu về mục đích chỉ rõ chức năng mô đun.
2. Mô tả giao diện bao gồm: - Một mẫu cách gọi - Mô tả về dữ liệu
- Danh sách tất cả các mô đun thuộc cấp
3. Thảo luận về dữ liệu thích hợp (như các biến quan trọng và những hạn chế, giới
hạn về cách dùng chúng) và các thông tin quan trọng khác.
4. Lịch sử phát triển bao gồm:
- Tên người thiết kế modul (tác giả).
- Tên người xét duyệt và ngày tháng.
- Ngày tháng sửa đổi và mô tả sửa đổi.
Các chú thích chức năng được nhúng vào bên trong thân của chương trình gốc và
được dùng để mô tả cho các khối chương trình.
7.3.2 Khai báo dữ liệu
Thứ tự khai báo dữ liệu nên được chuẩn hóa cho dù ngôn ngữ lập trình không có yêu
cầu bắt buộc nào về điều đó. Các tên biến ngoài việc có nghĩa còn nên mang thông tin về
kiểu của chúng. Ví dụ, nên thống nhất các tên biến cho kiểu số nguyên, kiểu số thực... Cần
phải chú giải về mục đích đối với các biến quan trọng, đặc biệt là các biến tổng thể. Các cấu
trúc dữ liệu nên được chú giải đầy đủ về cấu trúc và chức năng, và các đặc thù về sử dụng.
Đặc biệt là đối với các cấu trúc phức tạp như danh sách móc nối trong C hay Pascal.
7.3.3 Xây dựng câu lệnh
Việc xây dựng luồng logic phần mềm được thiết lập trong khi thiết kế. Việc xây
dựng từng câu lệnh tuy nhiên lại là một phần của bước lập trình. Việc xây dựng câu lệnh
nên tuân theo một qui tắc quan trọng hơn cả: mỗi câu lệnh nên đơn giản và trực tiếp. Nhiều
ngôn ngữ lập trình cho phép nhiều câu lệnh trên một dòng. Khía cạnh tiết kiệm không gian
của tính năng này khó mà biện minh bởi tính khó đọc nảy sinh. Cấu trúc chu trình và các
phép toán điều kiện được chứa trong đoạn trên đều bị che lấp bởi cách xây dựng nhiều câu lệnh trên một dòng.
Cách xây dựng câu lệnh đơn và việc tụt lề minh họa cho các đặc trưng logic và chức
năng của đoạn này. Các câu lệnh chương trình gốc riêng lẻ có thể được đơn giản hóa bởi:
- Tránh dùng các phép kiểm tra điều kiện phức tạp
- Khử bỏ các phép kiểm tra điều kiện phủ định
- Tránh lồng nhau nhiều giữa các điều kiện hay chu trình
- Dùng dấu ngoặc để làm sáng tỏ các biểu thức logic hay số học
- Dùng dấu cách và/hoặc các ký hiệu dễ đọc để làm sáng tỏ nội dung câu lệnh 156
- Chỉ dùng các tính năng chuẩn của ngôn ngữ
Để hướng tới chương trình dễ hiểu luôn nên đặt ra câu hỏi: Liệu có thể hiểu được
điều này nếu ta không là người lập trình cho nó không? 7.3.4 Vào/ra
Vào ra của các mô đun nên tuân thủ theo một số hướng dẫn sau:
- Làm hợp lệ mọi cái vào.
- Kiểm tra sự tin cậy của các tổ hợp khoản mục vào quan trọng.
- Giữ cho định dạng cái vào đơn giản.
- Dùng các chỉ báo cuối dữ liệu thay vì yêu cầu người dùng xác định “số các khoản mục”.
- Giữ cho định dạng cái vào thống nhất khi một ngôn ngữ lập trình có các yêu cầu
định dạng nghiêm ngặt.
7.4. Lập trình tránh lỗi
Tránh lỗi và phát triển phần mềm vô lỗi dựa trên các yếu tố sau:
i) Sản phẩm của một đặc tả hệ thống chính xác.
ii) Chấp nhận một cách tiếp cận thiết kế phần mềm dựa trên việc bao gói dữ liệu và che dấu thông tin.
iii) Tăng cường duyệt lại trong quá trình phát triển và thẩm định hệ thống phần mềm.
iv) Chấp nhận triết lý chất lượng tổ chức: chất lượng là bánh lái của quá trình phần mềm.
v) Việc lập kế hoạch cẩn thận cho việc thử nghiệm hệ thống để tìm ra các lỗi chưa
được phát hiện trong quá trình duyệt lại và để định lượng độ tin cậy của hệ thống.
Có hai cách tiếp cận chính hỗ trợ tránh lỗi là:
Lập trình có cấu trúc: Thuật ngữ này được đặt ra từ cuối những năm 60 và có nghĩa
là lập trình mà không dùng lệnh goto, lập trình chỉ dùng các vòng lặp while và các phát biểu
if để xây dựng điều khiển và trong thiết kế thì dùng cách tiếp cận trên - xuống. Việc thừa
nhận lập trình có cấu trúc là quan trọng bởi vì nó là bước đầu tiên bước từ cách tiếp cận
không khuôn phép tới phát triển phần mềm. Lập trình có cấu trúc buộc người lập trình phải
nghĩ cẩn thận về chương trình của họ, và vì vậy nó ít tạo ra sai lầm trong khi phát triển. Lập
trình có cấu trúc làm cho chương trình có thể được đọc một cách tuần tự và do đó dễ hiểu và
dễ kiểm tra. Tuy nhiên nó chỉ là bước đầu tiên trong việc lập trình nhằm đạt độ tin cậy tốt.
Có một vài khái niệm khác cũng hay dẫn tới các lỗi phần mềm:
i) Các số thực dấu chấm động: các phép toán số thực được làm tròn khiến cho việc so
sánh các kết quả số thực, nhất là so sánh bằng giữa hai số thực là không khả thi. Số thực dấu
phẩy động có độ chính xác khác nhau khiến cho kết quả phép tính không theo mong muốn.
Ví dụ, trong phép tính tính phân chúng ta cần cộng các giá trị nhỏ trước với nhau nếu không chúng sẽ bị làm tròn. 157
ii) Các con trỏ và bộ nhớ động: con trỏ là các cấu trúc bậc thấp khó quản lý và dễ gây
ra các lỗi nghiệm trọng đối với hệ thống. Việc cấp phát và thu hồi bộ nhớ động phức tạp và
là một trong các nguyên nhân chính gây lỗi phần mềm.
iii) Song song: lập trình song song đòi hỏi kỹ thuật cao và hiểu biết sâu sắc về hệ
thống. Một trong các vấn đề phức tạp của song song là quản lý tương tranh. iv) Đệ quy. v) Các ngắt.
Các cấu trúc này có ích, nhưng người lập trình nên dùng chúng một cách cẩn thận.
Phân quyền truy cập dữ liệu: Nguyên lý an ninh trong quân đội là các cá nhân chỉ
được biết các thông tin có liên quan trực tiếp đến nhiện vụ của họ. Khi lập trình người ta
cũng tuân theo một nguyên lý tương tự cho việc truy cập dữ liệu hệ thống. Mỗi thành phần
chương trình chỉ được phép truy cập đến dữ liệu nào cần thiết để thực hiện chức năng của
nó. Ưu điểm của việc che dấu thông tin là các thông tin bị che dấu không thể bị sập đổ (thao
tác trái phép) bởi các thành phần chương trình mà được xem rằng không dùng thông tin đó.
Tiến hóa của sự phân quyền truy cập là che dấu thông tin, hay nói chính xác hơn là che dấu
cấu trúc thông tin. Khi đó, chúng ta có thể thay đổi cấu trúc thông tin mà không phải thay
đổi các thành phần khác có sử dụng thông tin đó.
7.4.1 Lập trình thứ lỗi
Đối với các hệ thống đòi hỏi độ tin cậy rất cao như hệ thống điều khiển bay thì cần
phải có khả năng dung thứ lỗi (fault tolerance), tức là khả năng đảm bảo cho hệ thống vẫn
hoạt động chính xác ngay cả khi có thành phần sinh lỗi.
Có bốn hoạt động cần phải tiến hành nếu hệ thống là thứ lỗi: i) Phát hiện lỗi.
ii) Định ra mức độ thiệt hại.
iii) Hồi phục sau khi gặp lỗi: Hệ thống phải hồi phục về trạng thái mà nó biết là an
toàn. Cũng có thể là chỉnh lý trạng thái bị hủy hoại (hồi phục tiến), cũng có thể là lui về một
trạng thái trước mà an toàn (hồi phục lùi).
vi) Chữa lỗi: Cải tiến hệ thống để cho lỗi đó không xuất hiện nữa. Tuy nhiên trong
nhiều trường hợp phát hiện được đúng nguyên nhân gây lỗi là rất khó khăn vì nó xẩy ra bởi
một tổ hợp của thông tin vào và trạng thái của hệ thống.
Thông thường, thứ lỗi được thực hiện bằng cách song song hóa các chức năng, kết
hợp với bộ điều khiển thứ lỗi. Bộ điều khiển sẽ so sánh kết quả của các khối chương trình
thực hiện cùng nhiệm vụ và sử dụng nguyên tắc đa số để chọn kết quả.
7.4.2. Lập trình phòng thủ
Lập trình phòng thủ là cách phát triển chương trình mà người lập trình giả định rằng
các mâu thuẫn hoặc các lỗi chưa được phát hiện có thể tồn tại trong chương trình. Phải có
phần mềm kiểm tra trạng thái hệ thống sau khi biến đổi và phải đảm bảo rằng sự biến đổi
trạng thái là kiên định. Nếu phát hiện một mâu thuẫn thì việc biến đổi trạng thái là phải rút
lại và trạng thái phải trở về trạng thái đúng đắn trước đó. 158
Nói chung một lỗi gây ra một sự sụp đổ trạng thái: các biến trạng thái được gán các
trị không hợp luật. Ngôn ngữ lập trình như Ada cho phép phát hiện ra các lỗi đó ngay trong
thời gian biên dịch. Tuy nhiên việc kiểm tra biên dịch chỉ hạn chế cho các giá trị tĩnh và một
vài phép kiểm tra thời gian thực là không thể tránh được. Một cách để phát hiện lỗi trong
chương trình Ada là dùng cơ chế xử lý bất thường kết hợp với đặc tả miền trị.
Hồi phục lỗi là một quá trình cải biên không gian trạng thái của hệ thống sao cho
hiệu ứng của lỗi là nhỏ nhất và hệ thống có thể tiếp tục vận hành, có lẽ là trong một mức suy giảm.
Hồi phục tiến liên quan đến việc cố gắng chỉnh lại trạng thái hệ thống.
Hồi phục lùi liên quan đến việc lưu trạng thái của hệ thống ở một trạng thái đúng đã biết.
Hồi phục tiến thường là một chuyên biệt ứng dụng. Có hai tình thế chung mà khi đó
hồi phục tiến có thể thành công:
1) Khi dữ liệu mã bị sụp đổ: Việc sử dụng kỹ thuật mã hóa thích hợp bằng cách thêm
các dữ liệu dư thừa vào dữ liệu cho phép sửa sai khi phát hiện lỗi.
2) Khi cấu trúc nối bị sụp đổ: Nếu các con trỏ tiến và lùi đã có trong cấu trúc dữ liệu
thì cấu trúc đó có thể tái tạo nếu như còn đủ các con trỏ chưa bị sụp. Kỹ thuật này thường
được dùng cho việc sửa chữa hệ thống tệp và cơ sở dữ liệu.
Hồi phục lùi là một kỹ thuật đơn giản liên quan đến việc duy trì các chi tiết của trạng
thái an toàn và cất giữ trạng thái đó khi mà sai lầm đã bị phát hiện. Hầu hết các hệ quản trị
cơ sở dữ liệu đều có bộ hồi phục lỗi. CSDL chỉ cập nhật dữ liệu một khi giao dịch đã hoàn
tất và không phát hiện được vấn đề gì. Nếu giao dịch thất bại thì CSDL không được cập nhật.
Một kỹ thuật khác là thiết lập các điểm kiểm tra thường kỳ mà chúng là các bản sao
của trạng thái hệ thống. Khi mà một lỗi được phát hiện thì trạng thái an toàn đó được tái lưu
kho từ điểm kiểm tra gần nhất. Trường hợp hệ thống dính líu tới nhiều quá trình hợp tác thì
dãy các giao tiếp có thể là các điểm kiểm tra của các quá trình đó không đồng bộ và để hồi
phục thì mỗi quá trình phải trở lại trạng thái ban đầu của nó.
7.5. Lập trình hiệu quả
7.5.1. Tính hiệu quả chương trình
Tính hiệu quả của chương trình gốc có liên hệ trực tiếp với tính hiệu quả của thuật
toán được xác định trong thiết kế chi tiết. Tuy nhiên, phong cách lập trình có thể có một tác
động đến tốc độ thực hiện và yêu cầu bộ nhớ. Tập hợp các hướng dẫn sau đây bao giờ cũng
có thể áp dụng được khi thiết kế chi tiết được dịch thành chương trình:
- Đơn giản hóa các biểu thức số học và lôgic trước khi đi vào lập trình.
- Tính cẩn thận từng chu kỳ lồng nhau để xác định liệu các câu lệnh hay biểu thức có
thể được chuyển ra ngoài hay không
- Khi có thể, hãy tránh dùng mảng nhiều chiều
- Khi có thể hãy tránh việc dùng con trỏ và danh sách phức tạp 159
- Dùng các phép toán số học “nhanh”
- Không trộn lẫn các kiểu dữ liệu, cho dù ngôn ngữ có cho phép điều đó
- Dùng các biểu thức số học và logic bất kì khi nào có thể được
Nhiều trình biên dịch có tính năng tối ưu tự động sinh ra chương trình hiệu quả bằng
cách dồn nén các biểu thức lặp, thực hiện tính chu trình, dùng số học nhanh và áp dụng các
thuật toán có hiệu quả liên quan khác. Với những ứng dụng trong đó tính hiệu quả có ý
nghĩa quan trọng, những trình biên dịch như thế là công cụ lập trình không thể thiếu được.
7.5.2. Hiệu quả bộ nhớ
Tính hiệu quả bộ nhớ phải được tính vào đặc trưng phân trang của hệ điều hành. Nói
chung, tính cục bộ của chương trình hay việc bảo trì lĩnh vực chức năng qua các kết cấu có
cấu trúc là một phương pháp tuyệt vời làm giảm việc phân trang và do đó làm tăng tính hiệu quả.
Hạn chế bộ nhớ trong phát triển phần mềm nhúng là mối quan tâm rất thực tế, mặc
dầu bộ nhớ giá thấp, mật độ cao vẫn đang tiến hóa nhanh chóng. Nếu yêu cầu hệ thống cần
tới bộ nhớ tối thiểu (như sản phẩm giá thấp, khối lượng lớn) thì trình biên dịch ngôn ngữ
cấp cao phải được trù tính cẩn thận với tính năng nén bộ nhớ, hay như một phương kế cuối
cùng, có thể phải dùng tới hợp ngữ.
7.5.3. Hiệu quả vào/ra
Các thiết bị vào ra thường có tốc độ chậm hơn rất nhiều so với khả năng tính toán
của máy tính và tốc độ truy cập bộ nhớ trong. Việc tối ưu vào ra có thể làm tăng đáng kể tốc
độ thực hiện. Một số hướng dẫn đơn giản để tăng cường hiệu quả vào/ra:
• Số các yêu cầu vào/ra nên giữ mức tối thiểu
• Mọi việc vào/ra nên qua bộ đệm để làm giảm phí tổn liên lạc.
• Với bộ nhớ phụ (như đĩa) nên lựa chọn và dùng phương pháp thâm nhập đơn giản
nhất chấp nhận được.
• Nên xếp khối vào/ra với các thiết bị bộ nhớ phụ.
• Việc vào/ra với thiết bị cuối hay máy in nên nhận diện các tính năng của thiết bị có
thể cải tiến chất lượng hay tốc độ.
Tổng kết: Bước lập trình là một tiến trình dịch (chuyển hóa) thiết kế chi tiết thành
chương trình mà cuối cùng được biến đổi thành các lệnh mã máy thực hiện được. Các đặc
trưng của ngôn ngữ lập trình có ảnh hưởng lớn đến quá trình xây dựng, kiểm thử cũng như
bảo trì phần mềm. Phong cách lập trình quyết định tính dễ hiểu của chương trình gốc. Các
yếu tố của phong cách bao gồm việc làm tài liệu bên trong, phương pháp khai báo dữ liệu,
thủ tục xây dựng câu lệnh, và kỹ thuật lập trình vào/ra. Lập trình cần hướng tới hiệu quả
thực hiện, tức là tích kiệm tài nguyên phần cứng (mức độ sử dụng CPU, bộ nhớ...). Mặc dầu
tính hiệu quả có thể là yêu cầu cực kì quan trọng, chúng ta nên nhớ rằng một chương trình
hoạt động hiệu quả mà lại không dễ hiểu dẫn đến khó bảo trì thì giá trị của nó cũng bị hạn chế. 160
Chương 8. Kiểm thử và tích hợp 8.1. Giới thiệu
8.1.1. Khái niệm về kiểm thử phần mềm.
Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới những
điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá một khía cạnh nào đó của hệ
thống hay thành phần đó. (Theo Bảng chú giải thuật ngữ chuẩn IEEE của Thuật ngữ kỹ
nghệ phần mềm- IEEE Standard Glossary of Software Engineering Terminology).
Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìm ra
nhiều lỗi. (Theo “The Art of Software Testing” – Nghệ thuật kiểm thử phần mềm).
Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần
mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cung cấp cho người có
lợi ích liên quan những thông tin về chất lượng của sản phẩm hay dịch vụ phần mềm ấy.
Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm khuyết phần mềm nhằm đảm 161
bảo hiệu quả hoạt động tối ưu của phần mềm trong nhiều ngành khác nhau. (Theo Bách
khoa toàn thư mở Wikipedia).
Có thể định nghĩa một cách dễ hiểu như sau: Kiểm thử phần mềm là một tiến trình
hay một tập hợp các tiến trình được thiết kế để đảm bảo mã hóa máy tính thực hiện theo cái
mà chúng đã được thiết kế để làm, và không thực hiện bất cứ thứ gì không mong muốn. Đây
là một pha quan trọng trong quá trình phát triển hệ thống, giúp cho người xây dựng hệ thống
và khách hàng thấy được hệ thống mới đã đáp ứng yêu cầu đặt ra hay chưa.
8.1.2. Mục đích của kiểm thử phần mềm.
Tìm ra nhiều lỗi bằng việc đưa ra các dòng thời gian.
Chứng minh được sản phẩm hoàn thành có những chức năng hay ứng dụng giống với bản đặc tả yêu cầu.
Tạo ra các test case có chất lượng cao, thực thi hiệu quả…
Một số lỗi cơ bản trong kiểm thử phần mềm như: lỗi ngay từ khi phân tích yêu cầu,
lỗi từ bản đặc tả hệ thống, lỗi trong code, lỗi hệ thống và nguồn tài nguyên hệ thống, lỗi
trong vấn đề phần mềm, phần cứng…
8.1.3. Nguyên tắc trong kiểm thử phần mềm.
Để kiểm thử đạt hiệu quả thì khi tiến hành kiểm thử phần mềm cần phải tuân thủ một số quy tắc sau:
Quy tắc 1: Một phần quan trọng của 1 ca kiểm thử là định nghĩa của đầu ra hay kết quả mong muốn.
Quy tắc 2: Lập trình viên nên tránh tự kiểm tra chương trình của mình.
Quy tắc 3: Nhóm lập trình không nên kiểm thử chương trình của chính họ.
Quy tắc 4: Kiểm tra thấu đáo mọi kết quả của mỗi kiểm tra.
Quy tắc 5: Các ca kiểm thử phải được viết cho các trạng thái đầu vào không hợp lệ và
không mong muốn, cũng như cho các đầu vào hợp lệ và mong muốn.
Quy tắc 6: Khảo sát 1 chương trình để xem liệu chương trình có thực hiện cái mà nó
cần thực hiện chỉ là 1 phần, phần còn lại là xem liệu chương trình có thực hiện cái mà nó
không cần phải thực hiện hay không.
Quy tắc 7: Tránh các ca kiểm thử bâng quơ trừ khi chương trình thực sự là 1 chương trình bâng quơ.
Quy tắc 8: Không dự kiến kết quả của kiểm thử theo giả thiết ngầm là không tìm thấy lỗi.
Quy tắc 9: Xác suất tồn tại lỗi trong 1 đoạn chương trình là tương ứng với số lỗi đã tìm thấy trong đoạn đó.
Quy tắc 10: Kiểm thử là 1 nhiệm vụ cực kỳ sáng tạo và có tính thử thách trí tuệ.
8.1.4. Phân loại kiểm thử.
a. Kiểm thử tĩnh( Static testing): 162
Là phương pháp thử phần mềm đòi hỏi phải duyệt lại các yêu cầu và các đặc tả bằng
tay, thông qua việc sử dụng giấy, bút để kiểm tra logic, lần từng chi tiết mà không cần chạy
chương trình. Kiểu kiểm thử này thường được sử dụng bởi chuyên viên thiết kế người mà
viết mã lệnh một mình.
Kiểm thử tĩnh cũng có thể được tự động hóa. Nó sẽ thực hiện kiểm tra toàn bộ bao
gồm các chương trình được phân tích bởi một trình thông dịch hoặc biên dịch mà xác nhận
tính hợp lệ về cú pháp của chương trình.
b. Kiểm thử động(Dynamic testing):
Là phương pháp kiểm thử thông qua việc dùng máy chạy chương trình để điều tra
trạng thái tác động của chương trình. Đó là kiểm thử dựa trê các ca kiểm thử xác định bằng
sự thực hiện của đối tượng kiểm thử hay chạy các chương trình. Kiểm thử động là kiểm tra
cách thức hoạt động của mã lệnh, tức là kiểm tra sự phản ứng vật lý từ hệ thống tới các biến
luôn thay đổi theo thời gian. Trong kiểm thử động, phần mềm phải thực sự được biên dịch
và chạy. Kiểm thử động thực sự bao gồm làm việc với phần mềm, nhập các giá trị đầu vào
và kiểm tra xem liệu đầu ra có như mong muốn hay không.
Các phương pháp kiểm thử động gồm có kiểm thử mức đơn vị – Unit Tests, kiểm thử
tích hợp – Intergration Tests, kiểm thử hệ thống – System Tests, và kiểm thử chấp nhận sản phẩm – Acceptance Tests.
8.2. Các phương pháp kiểm thử
8.2.1. Phương pháp kiểm thử hộp đen – Black box testing.
a. Phân vùng tương đương * Định nghĩa
Phân lớp tương đương là một phương pháp kiểm thử hộp đen chia miền đầu vào của
một chương trình thành các lớp dữ liệu, từ đó suy dẫn ra các ca kiểm thử. Phương pháp này
cố gắng xác định ra một ca kiểm thử mà làm lộ ra một lớp lỗi, do đó làm giảm tổng số các
trường hợp kiểm thử phải được xây dựng.
Thiết kế ca kiểm thử cho phân lớp tương đương dựa trên sự đánh giá về các lớp tương
đương với một điều kiện vào. Lớp tương đương biểu thị cho tập các trạng thái hợp lệ hay
không hợp lệ đối với điều kiện vào.
Một cách xác định tập con này là để nhận ra rằng 1 ca kiểm thử được lựa chọn tốt cũng nên có 2 đặc tính khác:
- Giảm thiểu số lượng các ca kiểm thử khác mà phải được phát triển để hoàn thành
mục tiêu đã định của kiểm thử “hợp lý”.
- Bao phủ một tập rất lớn các ca kiểm thử có thể khác. Tức là, nó nói cho chúng ta một
thứ gì đó về sự có mặt hay vắng mặt của những lỗi qua tập giá trị đầu vào cụ thể.
Thiết kế Test-case bằng phân lớp tương đương tiến hành theo 2 bước:
- Xác định các lớp tương đương.
- Xác định các ca kiểm thử. 163
* Xác định các lớp tương đương.
Các lớp tương đương được xác định bằng bằng cách lấy mỗi trạng thái đầu vào
(thường là 1 câu hay 1 cụm từ trong đặc tả) và phân chia nó thành 2 hay nhiều nhóm.
Mẫu liệt kê các lớp tương đương: Điều kiện đầu Các lớp tương đương
Các lớp tương đương không vào hợp lệ hợp lệ
- Điều kiện đầu vào là một giá trị đặc biệt, mảng số hay chuỗi, tập hợp hay điều kiện đúng sai.
- Các lớp tương đương hợp lệ là mô tả các đầu vào hợp lệ của chương trình
- Các lớp tương đương không hợp lệ là mô tả các trạng thái khác của chương trình
như: sai, thiếu, không đúng…
* Nguyên tắc để xác định lớp tương đương.
- Nếu điều kiện đầu vào định rõ giới hạn của một mảng thì chia vùng tương đương thành 3 tình huống:
- Xác định một lớp tương đương hợp lệ.
- Xác định hai lớp tương đương không hợp lệ.
- Nếu điều kiện đầu vào là một giá trị xác định thì chia vùng tương đương thành 3 tình huống:
- Một lớp tương đương hợp lệ.
- Hai lớp tương đương không hợp lệ.
- Nếu điều kiện đầu vào chỉ định là một tập giá trị thì chia vùng tương đương thành 2 tình huống như sau:
- Một lớp tương đương hợp lệ.
- Một lớp tương đương không hợp lệ.
- Nếu điều kiện đầu vào xác định là một kiểu đúng sai thì chia vùng tương đương thành 2 tình huống:
- Một lớp tương đương hợp lệ.
- Một lớp tương đương không hợp lệ.
* Xác định các ca kiểm thử.
Với các lớp tương đương xác định được ở bước trên, bước thứ hai là sử dụng các lớp
tương đương đó để xác định các ca kiểm thử. Quá trình này như sau:
- Gán 1 số duy nhất cho mỗi lớp tương đương.
- Cho đến khi tất cả các lớp tương đương hợp lệ được bao phủ bởi (hợp nhất thành)
các ca kiểm thử. Viết 1 ca kiểm thử mới bao phủ càng nhiều các lớp tương đương đó chưa
được bao phủ càng tốt. 164
- Cho đến khi các ca kiểm thử của bạn đã bao phủ tất cả các lớp tương đương không
hợp lệ. Viết 1 ca kiểm thử mà bao phủ một và chỉ một trong các lớp tương đương không hợp lệ chưa được bao phủ.
- Lý do mà mỗi ca kiểm thử riêng bao phủ các trường hợp không hợp lệ là vì các
kiểm tra đầu vào không đúng nào đó che giấu hoặc thay thế các kiểm tra đầu vào không đúng khác.
Mặc dù việc phân lớp tương đương là rất tốt khi lựa chọn ngẫu nhiên các ca kiểm
thử, nhưng nó vẫn có những thiếu sót. Ví dụ, nó bỏ qua các kiểu test – case có lợi nào đó.
Hai phương pháp tiếp theo, phân tích giá trị biên và đồ thị nguyên nhân – kết quả, bao phủ
được nhiều những thiếu sót này.
* Ví dụ về phân lớp tương đương. Cho bài toán như sau: User: Password:
Yêu cầu: Thiết kế test case sao cho khi người dùng nhập user vào ô text thì chỉ cho
nhập số ký tự [6 – 20 ]. Bài làm
Do yêu cầu của bài toán chỉ cho phép nhập số ký tự vào trong khi nhập của user nằm
[6 - 20] nên ta có tình huống kiểm thử sau:
 Nhập vào một trường hợp hợp lệ: nhập 7 ký tự.
 Nhập vào trường hợp không hợp lệ thứ nhất: nhập 5 ký tự.
 Nhập vào trường hợp không hợp lệ thứ hai: nhập vào 21 ký tự.
 Trường hợp đặc biệt: không nhập gì vào ô text đó (để trống).
Lập bảng các lớp tương đương: Điều kiện đầu
Các lớp tương đương hợp
Các lớp tương đương không vào lệ hợp lệ Cho phép nhập số
- Nhập vào 7 ký tự
- Nhập vào 5 ký tự ký tự nằm [ 6 – 20 ]
- Nhập vào 21 ký tự
- Để trống ô đó
b. Phân tích giá trị biên – Boundary Values Analysis * Định nghĩa.
Phân tích giá trị biên (BVA) là kỹ thuật thiết kế test case và hoàn thành phân vùng tương đương.
Mục tiêu là lựa chọn các test case để thực thi giá trị biên.
Kiểm thử các dữ liệu vào bao gồm:  Giá trị nhỏ nhất. 165
 Giá trị gần kề lớn hơn giá trị nhỏ nhất.
 Giá trị bình thường.
 Giá trị gần kề bé hơn giá trị lớn nhất.  Giá trị lớn nhất.
Hình 3: Ví dụ về biểu thị phân tích giá trị biên
* Nguyên tắc chọn dữ liệu.
- Nếu giá trị đầu vào xác định là một mảng có biên là a và b(a < b) thì có thể thiết kế
được các test case như sau:  Biên a  Biên b
 Giá trị nhỏ hơn biên a
 Giá trị lớn hơn biên b
 Một giá trị nằm giữa a và b.
Khi một hàm chức năng F với hai biến x1 và x2 được cài đặt trong chương trình, các
biến đầu vào x1 và x2 sẽ có các giới hạn: a<=x1<=b c<=x2<=d
Các đoạn [a,b] và [c,d] được gọi là các miền giá trị của x1 và x2 Giả thiết lỗi đơn
Các lỗi của chương trình ít khi được gây ra bởi hai hay nhiều biến cùng một lúc
Ý tưởng chính của kiểm thử theo giá trị biên là sử dụng giá trị của biến đầu vào tại
giá trị nhỏ nhất, lớn hơn giá trị nhỏ nhất, giá trị thông thường, giá trị lớn nhất, và nhỏ hơn giá trị lớn nhất
Kiểm thử theo giá trị biên với một biến:
Kiểm thử theo giá trị biên với hai biến: 166
Kiểm thử theo giá trị biên đầy đủ
- Là một mở rộng của kiểm thử theo giá trị biên bao gồm các giá trị nhỏ hơn giá trị
nhỏ nhất và lớn hơn giá trị lớn nhất (cho phép vượt quá miền giá trị)
- Là một hình thức kiểm thử với lỗi để biết được chương trình sẽ thực hiện như
thế nào nếu dữ liệu vào có lỗi
- Có thể không được áp dụng với một số ngôn ngữ lập trình có ràng buộc kiểu
Kiểm thử theo giá trị biên đầy đủ
Kiểm thử theo giá trị biên đầy đủ với hai biến
Kiểm thử theo giá trị biên xấu nhất (hai biến)
- Loại bỏ giả thiết chỉ có một lỗi đơn
- Cho phép các giá trị đầu vào có thể cùng nhận giá trị biên 167
Số lượng trường hợp kiểm thử
- Kiểm thử theo giá trị biên: 4n-1
- Kiểm thử theo giá trị biên đầy đủ: 6n-1
- Kiểm thử theo giá trị biên xấu nhất: 5n
Với n là số lượng các biến
Nhược điểm của kiểm thử theo giá trị biên
- Các biến phải độc lập với nhau
- Không áp dụng được cho các biến thuộc kiểu logic
- Nếu miền giá trị đầu vào là một danh sách các giá trị thì có thể thiết kế các test case như sau:  Giá trị nhỏ nhất.
 Giá trị lớn hơn giá trị nhỏ nhất.  Giá trị lớn nhất.
 Giá trị nhỏ hơn giá trị lớn nhất.
Ví dụ: Cho một danh sách như sau { 3,5,90,100,102} nên có thể thiết kế như sau:  Giá trị nhỏ nhất: 3
 Giá trị lớn hơn giá trị nhỏ nhất: 5
 Giá trị lớn nhất: 102
 Giá trị nhỏ hơn giá trị lớn nhất: 100
- Nếu dữ liệu vào là điều kiện ràng buộc số giá trị thì có thể thiết kế được các test case như sau:
 Số giá trị tối thiểu.  Số giá trị tối đa.
 Và một số giá trị không hợp lệ.
* Phân loại miền biên.
- Điểm trên biên (Boundary point).
- Điểm cực biên (Extreme point).
- Điểm ngoài biên (Off point).
- Điểm trong biên (Interior point.) 168
Hình 9: Phân loại miền biên
* Ví dụ cho phân tích giá trị biên
Kiểm tra tính hợp lệ của tháng trong năm thì ta có thể thiết kế như sau:  Giá trị biên: 1 và 12
 Giá trị cận biên ở bên trong: 2 và 11
 Giá trị cận biên ở bên ngoài: 0 và 13
c. Đồ thị nguyên nhân – hệ quả. * Định nghĩa.
Một điểm yếu của hai phương pháp trên là chúng không khảo sát sự kết hợp của các
trường hợp đầu vào. Việc kiểm tra sự kết hợp đầu vào không phải là một nhiệm vụ đơn giản
bởi vì nếu bạn phân lớp tương đương các trạng thái đầu vào, thì số lượng sự kết hợp thường
là rất lớn. Nếu bạn không có cách lựa chọn có hệ thống một tập con các trạng thái đầu vào,
có lẽ bạn sẽ chọn ra một tập tùy hứng các điều kiện, điều này có thể dẫn tới việc kiểm thử không có hiệu quả.
Đồ thị nguyên nhân – kết quả hỗ trợ trong việc lựa chọn một cách có hệ thống tập
các ca kiểm thử có hiệu quả cao. Nó có tác động có lợi ảnh hưởng tới việc chỉ ra tình trạng
chưa đầy đủ và nhập nhằng trong đặc tả. Nó cung cấp cả cách biểu diễn chính xác cho các
điều kiện logic và hành động tương ứng.
Kỹ thuật gồm có 4 bước:
 Xác định điều kiện vào và hành động cho mỗi module cần kiểm định.
 Xác định đồ thị nguyên nhân – kết quả.
 Đồ thị được chuyển thành bảng quyết định.
 Những phần trong bảng quyết định được chuyển thành test case.
* Các ký hiệu cơ bản.
- Mỗi nút có giá trị là 0 hoặc 1.
- 0 mô tả trạng thái vắng mặt và 1 mô tả trạng thái có mặt. 169
Hình 10: Các ký hiệu của đồ thị nguyên nhân – kết quả.
- Hàm đồng nhất (Identity) nói:  Nếu a là 1 thì b là 1  Nếu a là 0 thì b là 0 - Hàm NOT nói:  Nếu a là 1 thì b là 0  Nếu a là 0 thì b là 1
- Hàm OR nói: (Cho phép số lượng đầu vào là bất kỳ)
 Nếu a hoặc b hoặc c là 1 thì d là 1
 Nếu a hoặc b hoặc c là 0 thì d là 0.
- Hàm AND nói: (Số lượng đầu vào là bất kỳ)
 Nếu cả a và b là 1 thì c là 1
 Nếu cả a và b là 0 thì c là 0.
* Các ký hiệu ràng buộc.
Hình 11: Các ký hiệu ràng buộc trong đồ thị nguyên nhân – kết quả.
- Ràng buộc E (Exclude – loại trừ):
 Khẳng định tối đa rằng, chỉ có thể a hoặc b là 1(a,b không đồng thời = 1)
- Ràng buộc I (Include – bao hàm):
 Khẳng định ít nhất một trong a,b hoặc c phải luôn là 1(a,b,c không đồng thời bằng 0) 170
- Ràng buộc O (Only – chỉ một):
 Một và chỉ một a hoặc b là 1
- Ràng buộc R (Request – yêu cầu):
 Khi a là 1 thì b phải là 1
- Ràng buộc M (Mask – mặt lạ):
 Nếu kết quả a là 1 thì kết quả b bắt buộc phải là 0.
Bước tiếp theo là tạo bảng quyết định mục vào giới hạn – limited-entry decision
table. Tương tự với các bảng quyết định, thì nguyên nhân chính là các điều kiện và kết quả
chính là các hành động.
Quy trình được sử dụng là như sau:
 Chọn một kết quả để là trạng thái có mặt (1).
 Lần ngược trở lại đồ thị, tìm tất cả những sự kết hợp của các nguyên nhân
(đối tượng cho các rằng buộc) mà sẽ thiết lập kết quả này thành 1.
 Tạo một cột trong bảng quyết định cho mỗi sự kết hợp nguyên nhân.
 Với mỗi sự kết hợp, hãy quy định trạng thái của tất cả các kết quả khác và đặt chúng vào mỗi cột.
Trong khi biểu diễn bước 2, cần quan tâm các vấn đề sau:
 Khi lần ngược trở lại qua một nút or mà đầu ra của nó là 1, không bao giờ thiết
lập nhiều hơn 1 đầu vào cho nút or là 1 một cách đồng thời. Điều này được gọi
là path sensitizing – làm nhạy đường đi. Mục tiêu của nó là để ngăn chặn dò lỗi
thất bại vì một nguyên nhân che đi một nguyên nhân khác.
 Khi lần ngược trở lại qua một nút and mà đầu ra của nó là 0, dĩ nhiên, phải liệt
kê tất cả các sự kết hợp đầu vào dẫn tới đầu ra 0. Tuy nhiên, nếu bạn đang khảo
sát trạng thái mà 1 đầu ra là 0 và một hay nhiều đầu ra khác là 1, thì không nhất
thiết phải liệt kê tất cả các điều kiện mà dưới điều kiện đó các đầu vào khác có thể là 1.
Khi lần ngược trở lại qua một nút and mà đầu ra của nó là là 0, chỉ cần liệt kê 1 điều
kiện trong đó tất cả đầu vào bằng 0. (Nếu nút and ở chính giữa của đồ thị như vậy thì tất cả
các đầu vào của nó xuất phát từ các nút trung gian khác, có thể có quá nhiều trạng thái mà
trong trạng thái đó tất cả các đầu vào của nó bằng 0.)
Những xem xét được dò theo đồ thị:
 Nếu x=1, không quan tâm về
trường hợp a=b=1 (sự xem xét thứ 1)
 Nếu x=0, liệt kê tất cả các trường hợp trong đó a=b=0.
 Nếu x =1, liệt kê tất cả các trường 171
hợp trong đó a=b=c=1.
 Nếu x=0, bao gồm chỉ 1 trường
hợp mà a=b=c=0 (sự xem xét 3).
Đối với các trạng thái mà abc là
001, 010, 100, 011, 101 và 110 ,
bao gồm chỉ 1 trường hợp mỗi
trạng thái (sự xem xét 2).
Hình 12: Các hình biểu diễn dò theo đồ thị
- Ví dụ cho bài toán nhập tháng trong một chương trình. Sử dụng phương pháp đồ thị
nguyên nhân – kết quả để thiết kế:
 Bước 1: Xác định điều kiện nhập vào. Cause ( Điều kiện vào) Effect (Hành động) 1. Số nguyên ≥ 1 A: Đúng 2. Số nguyên ≤ 12 B: Sai 3. Số < 1 C: Nghi ngờ 4. Số > 12 5. Chuỗi 6. Không phải số nguyên
 Xây dựng đồ thị. (có sử dụng các ký hiệu cơ bản và cá ký hiệu ràng buộc)
Hình 13: Đồ thị của ví dụ nhập tháng. Nhận xét:
Vẽ đồ thị nguyên nhân – kết quả là phương pháp tạo các ca kiểm thử có hệ thống mô
tả sự kết hợp của các điều kiện. Sự thay đổi sẽ là 1 sự lựa chọn kết hợp không thể dự tính
trước, nhưng khi thực hiện như vậy, có vẻ như bạn sẽ bỏ sót nhiều ca kiểm thử “thú vị”
được xác định bằng đồ thị nguyên nhân – kết quả . 172
Vì vẽ đồ thị nguyên nhân – kết quả yêu cầu chuyển một đặc tả thành một mạng logic
Boolean, nó cung cấp một triển vọng khác và sự hiểu biết sâu sắc hơn nữa về đặc tả. Trên
thực tế, sự phát triển của 1 đồ thị nguyên nhân – kết quả là cách hay để khám phá sự mơ hồ
và chưa đầy đủ trong các đặc tả.
Mặc dù việc vẽ đồ thị nguyên nhân – kết quả tạo ra tập các ca kiểm thử hữu dụng,
nhưng thông thường nó không tạo ra tất cả các ca kiểm thử hữu dụng mà có thể được nhận
biết. Ngoài ra, đồ thị nguyên nhân – kết quả không khảo sát thỏa đáng các điều kiện giới
hạn. Dĩ nhiên, bạn có thể cố gắng bao phủ các điều kiện giới hạn trong suốt quá trình.
Tuy nhiên, vấn đề trong việc thực hiện điều này là nó làm cho đồ thị rất phức tạp và
dẫn tới số lượng rất lớn các ca kiểm thử. Vì thế, tốt nhất là xét 1 sự phân tích giá trị giới hạn tách rời nhau.
Vì đồ thị nguyên nhân – kết quả làm chúng ta mất thời gian trong việc chọn các giá
trị cụ thể cho các toán hạng, nên các điều kiện giới hạn có thể bị pha trộn thành các ca kiểm
thử xuất phát từ đồ thị nguyên nhân – kết quả. Vì vậy, chúng ta đạt được một tập các ca
kiểm thử nhỏ nhưng hiệu quả mà thỏa mãn cả 2 mục tiêu.
d. Đoán lỗi – Error Guessing
Một kỹ thuật thiết kế test-case khác là error guessing – đoán lỗi. Tester được đưa cho
1 chương trình đặc biệt, họ phỏng đoán, cả bằng trực giác và kinh nghiệm, các loại lỗi có
thể và sau đó viết các ca kiểm thử để đưa ra các lỗi đó.
Thật khó để đưa ra một quy trình cho kỹ thuật đoán lỗi vì nó là một quy trình có tính
trực giác cao và không thể dự đoán trước. Ý tưởng cơ bản là liệt kê một danh sách các lỗi có
thể hay các trường hợp dễ xảy ra lỗi và sau đó viết các ca kiểm thử dựa trên danh sách đó.
Một ý tưởng khác để xác định các ca kiểm thử có liên đới với các giả định mà lập trình viên
có thể đã thực hiện khi đọc đặc tả (tức là, những thứ bị bỏ sót khỏi đặc tả, hoặc là do tình cờ,
hoặc là vì người viết có cảm giác những đặc tả đó là rõ ràng). Nói cách khác, bạn liệt kê
những trường hợp đặc biệt đó mà có thể đã bị bỏ sót khi chương trình được thiết kế.
8.2.2. Phương pháp kiểm thử hộp trắng – White box testing.
Kiểm thử hộp trắng có liên quan tới mức độ mà các ca kiểm thử thực hiện hay bao
phủ tính logic (mã nguồn) của chương trình. Kiểm thử hộp trắng cơ bản là việc thực hiện
mọi đường đi trong chương trình, nhưng việc kiểm thử đầy đủ đường đi là một mục đích
không thực tế cho một chương trình với các vòng lặp. Các tiêu chuẩn trong kiểm thử bao phủ logic gồm có:
a. Bao phủ câu lệnh.
Tư tưởng: Thực hiện mọi câu lệnh trong chương trình ít nhất 1 lần.
Xét ví dụ với đoạn mã lệnh JAVA sau:
public void A (int a, int b, int x){
if (a>1 && b==0) {x=x/a;}
if (a==2||x>1){x=x-1;} } 173
Hình 14: Một chương trình nhỏ để kiểm thử
Bạn có thể thực hiện mọi câu lệnh bằng việc viết 1 ca kiểm thử đơn đi qua đường
ace. Tức là, bằng việc đặt A=2, B=0 và X=3 tại điểm a, mỗi câu lệnh sẽ được thực hiện 1
lần (thực tế, X có thể được gán bất kỳ giá trị nào).
Thường tiêu chuẩn này khá kém. Ví dụ, có lẽ nếu quyết định đầu tiên là phép or chứ không phải phép
and thì lỗi này sẽ không được phát hiện. Hay nếu quyết định thứ hai mà
bắt đầu với x>0, lỗi này cũng sẽ không được tìm ra. Cũng vậy, có 1 đường đi qua chương
trình mà ở đó x không thay đổi (đường đi
). Nếu đây là 1 lỗi, thì lỗi này có thể không tìm abd
ra. Hay nói cách khác, tiêu chuẩn bao phủ câu lệnh quá yếu đến nỗi mà nó thường là vô ích.
b. Bao phủ quyết định
Tư tưởng: Viết đủ các ca kiểm thử mà mỗi quyết định có kết luận đúng hay sai ít
nhất 1 lần. Nói cách khác, mỗi hướng phân nhánh phải được xem xét kỹ lưỡng ít nhất 1 lần.
Các ví dụ về câu lệnh rẽ nhánh hay quyết định là các câu lệnh switch, do-while, và if-
else. Các câu lệnh đa đường GOTO thường sử dụng trong một số ngôn ngữ lập trình như FORTRAN.
Bao phủ quyết định thường thỏa mãn bao phủ câu lệnh. Vì mỗi câu lệnh là trên sự bắt
nguồn một đường đi phụ nào đó hoặc là từ 1 câu lệnh rẽ nhánh hoặc là từ điểm vào của
chương trình, mỗi câu lệnh phải được thực hiện nếu mỗi quyết định rẽ nhánh được thực
hiện. Tuy nhiên, có ít nhất 3 ngoại lệ:
 Những chương trình không có quyết định.
 Những chương trình hay thường trình con/phương thức với nhiều điểm vào.
Một câu lệnh đã cho có thể được thực hiện nếu và chỉ nếu chương trình được
nhập vào tại 1 điểm đầu vào riêng.
 Các câu lệnh bên trong các ON-unit. Việc đi qua mỗi hướng rẽ nhánh sẽ là
không nhất thiết làm cho tất cả các ON-unit được thực thi.
Vì chúng ta đã thấy rằng bao phủ câu lệnh là điều kiện cần thiết, nên một chiến lược
tốt hơn là bao phủ quyết định nên được định nghĩa bao hàm cả bao phủ câu lệnh. Do đó, bao 174
phủ quyết định yêu cầu mỗi quyết định phải có kết luận đúng hoặc sai, và mỗi câu lệnh đó
phải được thực hiện ít nhất 1 lần.
Phương pháp này chỉ xem xét những quyết định hay những sự phân nhánh 2 đường
và phải được sửa đổi cho những chương trình có chứa những quyết định đa đường. Ví dụ,
các chương trình JAVA có chứa các lệnh select (case), các chương trình FORTRAN chứa
các lệnh số học (ba đường) if hoặc các lệnh tính toán hay số học , và các chương trình GOTO COBOL chứa các lệnh
GOTO biến đổi hay các lệnh GO-TO-DEPENDING-ON (các lệnh
goto phụ thuộc). Với những chương trình như vậy, tiêu chuẩn này đang sử dụng mỗi kết
luận có thể của tất cả các quyết định ít nhất 1 lần và gọi mỗi điểm vào tới chương trình hay
thường trình con ít nhất 1 lần.
Trong hình 14, bao phủ quyết định có thể đạt được bởi ít nhất 2 ca kiểm thử bao phủ
các đường ace và abd hoặc acd và abe. Nếu chúng ta chọn khả năng thứ hai, thì 2 đầu vào
test-case là A=3, B=0, X=3 và A=2, B=1, X=1.
Bao phủ quyết định là 1 tiêu chuẩn mạnh hơn bao phủ câu lệnh, nhưng vẫn khá yếu.
Ví dụ, chỉ có 50% cơ hội là chúng ta sẽ tìm ra con đường trong đó x không bị thay đổi (ví
dụ, chỉ khi bạn chọn khả năng thứ nhất). Nếu quyết định thứ hai bị lỗi (nếu như đáng lẽ phải
nói là x<1 thay vì x>1), lỗi này sẽ không được phát hiện bằng 2 ca kiểm thử trong ví dụ trước.
c. Bao phủ điều kiện
Tư tưởng: Viết đủ các ca kiểm thử để đảm bảo rằng mỗi điều kiện trong một quyết
định đảm nhận tất cả các kết quả có thể ít nhất một lần.
Vì vậy, như với bao phủ quyết định, thì bao phủ điều kiện không phải luôn luôn dẫn
tới việc thực thi mỗi câu lệnh. Thêm vào đó, trong tiêu chuẩn bao phủ điều kiện, mỗi điểm
vào chương trình hay thường trình con, cũng như các ON-unit, được gọi ít nhất 1 lần. Ví dụ,
câu lệnh rẽ nhánh do k=0 to 50 while (j-kk50 (để
đến lần lặp cuối cùng của vòng lặp), j-k=quest.
Hình 2.1 có 4 điều kiện: A>1, B=0, A=2, X>1. Do đó các ca kiểm thử đầy đủ là cần
thiết để thúc đẩy những trạng thái mà A>1, A<=1, B=0 và B<>0 có mặt tại điểm a và A=2,
A<>2, X>1, X<=1 có mặt tại điểm b. Số lượng đầy đủ các ca kiểm thử thỏa mãn tiêu chuẩn
và những đường đi mà được đi qua bởi mỗi ca kiểm thử là: 1. A=2, B=0, X=4 ace 2. A=1, B=1, X=1 abd
Chú ý là, mặc dù cùng số lượng các ca kiểm thử được tạo ra cho ví dụ này, nhưng
bao phủ điều kiện thường tốt hơn bao phủ quyết định là vì nó có thể (nhưng không luôn
luôn) gây ra mọi điều kiện riêng trong 1 quyết định để thực hiện với cả hai kết quả, trong
khi bao phủ quyết định lại không. Ví dụ trong cùng câu lệnh rẽ nhánh: DO K=0 TO 50
WHILE (J-K là 1 nhánh 2 đường (thực hiện thân vòng lặp hay bỏ qua nó). Nếu
bạn đang sử dụng kiểm thử quyết định, thì tiêu chuẩn này có thể được thỏa mãn bằng cách
cho vòng lặp chạy từ K=0 tới
51, mà chưa từng kiểm tra trường hợp trong đó mệnh đề 175
WHILE bị sai. Tuy nhiên, với tiêu chuẩn bao phủ điều kiện, 1 ca kiểm thử sẽ cần phải cho ra
1 kết quả sai cho những điều kiện J-K.
Mặc dù nếu mới nhìn thoáng qua, tiêu chuẩn bao phủ điều kiện xem ra thỏa mãn tiêu
chuẩn bao phủ quyết định, nhưng không phải lúc nào cũng vậy. Nếu quyết định IF (A&B)
được kiểm tra, thì tiêu chuẩn bao phủ điều kiện sẽ cho phép bạn viết 2 ca kiểm thử - A đúng,
B sai, và A sai, B đúng – nhưng điều này sẽ không làm cho mệnh đề THEN của câu lệnh IF được thực hiện.
Ví dụ, 2 ca kiểm thử khác: 1. A=1, B=0, X=3 2. A=2, B=1, X=1
d. Bao phủ quyết định – điều kiện.
Tư tưởng: Thực hiện đủ các ca kiểm thử mà mỗi điều kiện trong 1 quyết định thực
hiện trên tất cả các kết quả có thể ít nhất 1 lần, và mỗi điểm vào được gọi ít nhất 1 lần.
Điểm yếu của bao phủ quyết định/điều kiện là mặc dù xem ra nó có thể sử dụng tất
cả các kết quả của tất cả các điều kiện, nhưng thường không phải vậy vì những điều kiện
chắc chắn đã cản các điều kiện khác.
Hình 15: Mã máy cho chương trình
Biểu đồ tiến trình trong hình 15 là cách 1 trình biên dich tạo ra mã máy cho chương
trình trong Hình 14. Các quyết định đa điều kiện trong chương trình nguồn đã bị chia thành
các quyết định và các nhánh riêng vì hầu hết các máy không được chế tạo để có thể thực
hiện các quyết định đa điều kiện. Khi đó 1 bao phủ kiểm thử tỉ mỉ hơn xuất hiện là việc sử
dụng tất cả các kết quả có thể của mỗi quyết định gốc. Hai ca kiểm thử bao phủ quyết định
trước không làm được điều này; chúng không thể sử dụng kết quả false của quyết định H và
kết quả true của quyết định K.
Lí do, như đã được chỉ ra trong hình 15, là những kết quả của các điều kiện trong các biểu thức và and
or có thể cản trở hay ngăn chặn việc ước lượng các quyết định khác. Ví dụ, nếu 1 điều kiện
and là sai, không cần kiểm tra các điều kiện tiếp theo trong biểu thức.
Tương tự như vậy, nếu 1 điều kiện or là đúng thì cũng không cần kiểm tra các điều kiện còn 176
lại. Do đó, các lỗi trong biểu thức logic không phải lúc nào cũng được phát hiện bằng các
tiêu chuẩn bao phủ điều kiện và bao phủ quyết định/điều kiện.
e. Bao phủ đa điều kiện
Tư tưởng: Viết đủ các ca kiểm thử mà tất cả những sự kết hợp của các kết quả điều
kiện có thể trong mỗi quyết định, và tất cả các điểm vào phải được gọi ít nhất 1 lần.
Ví dụ, xét chuỗi mã lệnh sau: NOTFOUND = TRUE;
DO I=1 TO TABSIZE WHILE (NOTFOUND); /*SEARCH TABLE*/ …searching logic…; END;
Bốn tình huống để kiểm thử là:
1. I<= TABSIZE và NOTFOUND có giá trị đúng (đang duyệt)
2. I<= TABSIZE và NOTFOUND có giá trị sai (tìm thấy mục vào trước khi gặp cuối bảng).
3. I>TABSIZE và NOTFOUND có giá trị đúng (gặp cuối bảng mà không tìm thấy mục vào). 4. I>TABSIZE và
NOTFOUND có giá trị sai (mục vào là cái cuối cùng trong bảng).
Dễ nhận thấy là tập hợp các ca kiểm thử thỏa mãn tiêu chuẩn đa điều kiện cũng thỏa
mãn các tiêu chuẩn bao phủ quyết định, bao phủ điều kiện và bao phủ quyết định/điều kiện.
Quay lại hình 14, các ca kiểm thử phải bao phủ 8 sự kết hợp: 1. A>1, B= 0 2. A>1, B<>0 3. A<=1, B=0 4. A<=1, B<>0 5. A=2, X>1 6. A=2, X<=1 7. A<>2, X>1 8. A<>2, X<=1
Vì là ca kiểm thử sớm hơn, nên cần chú ý là các trường hợp từ 5 đến 8 biểu diễn các
giá trị tại vị trí câu lệnh IF thứ
hai. Vì X có thể thay đổi ở trên câu lệnh IF này, nên giá trị
cần tại câu lệnh IF này phải được sao dự phòng thông qua tính logic để tìm ra các giá trị đầu vào tương ứng.
Những sự kết hợp để được kiểm tra này không nhất thiết ngụ ý rằng cần thực hiện cả
8 ca kiểm thử. Trên thực tế, chúng có thể được bao phủ bởi 4 ca kiểm thử. Các giá trị đầu
vào kiểm thử, và sự kết hợp mà chúng bao phủ, là như sau: A=2, B=0, X=4 Bao phủ trường hợp 1, 5 177 A=2, B=1, X=1 Bao phủ trường hợp 2, 6 A=1, B=0, X=2 Bao phủ trường hợp 3, 7 A=1, B=1, X=1 Bao phủ trường hợp 4, 8
Thực tế là việc có 4 ca kiểm thử và 4 đường đi riêng biệt trong hình 14 chỉ là sự
trùng hợp ngẫu nhiên. Trên thực tế, 4 ca kiểm thử này không bao phủ mọi đường đi, chúng
bỏ qua đường đi acd. Ví dụ, bạn sẽ cần 8 ca kiểm thử cho quyết định sau mặc dù nó chỉ chứa 2 đường đi:
If (x==y&&length(z)==0&&FLAG) { J=1;} Else { I=1;}
Trong trường hợp các vòng lặp, số lượng các ca kiểm thử được yêu cầu bởi tiêu
chuẩn đa điều kiện thường ít hơn nhiều số lượng đường đi.
Tóm lại, đối với những chương trình chỉ chứa 1 điều kiện trên 1 quyết định, thì 1 tiêu
chuẩn kiểm thử nhỏ nhất là một số lượng đủ các ca kiểm thử để (1) gọi tất cả các kết quả
của mỗi quyết định ít nhất 1 lần và (2) gọi mỗi điểm của mục vào (như là điểm vào hay ON-
unit) ít nhất 1 lần, để đảm bảo là tất cả các câu lệnh được thực hiện ít nhất 1 lần. Đối với
những chương trình chứa các quyết định có đa điều kiện thì tiêu chuẩn tối thiểu là số lượng
đủ các ca kiểm thử để gọi tất cả những sự kết hợp có thể của các kết quả điều kiện trong mỗi
quyết định, và tất cả các điểm vào của chương trình ít nhất 1 lần.
8.3. Các chiến lược kiểm thử
Các cấp độ của kiểm thử phản ánh cấp độ trong mô hình thác nước của vòng đời
phát triển phần mềm. Ba cấp độ: Đặc tả, Thiết kế cơ bản, Thiết kế chi tiết tương ứng với ba
cấp độ của kiểm thử: kiểm thử đơn vị, kiểm thử tích hợp và kiểm thử hệ thống.
Thông thường, kiểm thử theo cấu trúc tương ứng với mức độ đơn vị, kiểm
thử theo chức năng tương ứng với mức độ hệ thống.
8.3.1. Unit Test – Kiểm tra mức đơn vị
Một Unit là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm tra được. Theo
định nghĩa này, các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc các phương
thức (Method) đều có thể được xem là Unit.
Unit Test thường do lập trình viên thực hiện. Công đoạn này cần được thực hiện càng
sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm. Thông
thường, Unit Test đòi hỏi kiểm tra viên có kiến thức về thiết kế và code của chương trình.
Mục đích của Unit Test là bảo đảm thông tin được xử lý và xuất (khỏi Unit) là chính xác,
trong mối tương quan với dữ liệu nhập và chức năng của Unit. Điều này thường đòi hỏi
tất cả các nhánh bên trong Unit đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi.
Một nhánh thường là một chuỗi các lệnh được thực thi trong một Unit, ví dụ: chuỗi các
lệnh sau điều kiện If và nằm giữa then … else là một nhánh. Thực tế việc chọn lựa các
nhánh để đơn giản hóa việc kiểm tra và quét hết Unit đòi hỏi phải có kỹ thuật, đôi khi phải
dùng thuật toán để chọn lựa. 178
Cũng như các mức kiểm tra khác, Unit Test cũng đòi hỏi phải chuẩn bị trước các
tình huống (test case) hoặc kịch bản (script), trong đó chỉ định rõ dữ liệu vào, các bước thực
hiện và dữ liệu mong chờ sẽ xuất ra. Các test case và script này nên được giữ lại để tái sử dụng.
8.3.2. Integration Test – Kiểm tra tích hợp
Integration test kết hợp các thành phần của một ứng dụng và kiểm tra như một ứng
dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì
Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng.
Integration Test có 2 mục tiêu chính:
- Phát hiện lỗi giao tiếp xảy ra giữa các Unit.
- Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (subsystem) và cuối cùng là
nguyên hệ thống hoàn chỉnh (system) chuẩn bị cho kiểm tra ở mức hệ thống (System Test).
Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và cấu
trúc nội tại của Unit. Có một số phép kiểm tra đơn giản trên giao tiếp giữa Unit với các
thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit thật sự được kiểm tra
đầy đủ khi các Unit tích hợp với nhau trong khi thực hiện Integration Test.
Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những Unit đã được
kiểm tra cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã được sửa chữa. Một
số người hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với các giao tiếp giả
lập thì không cần phải thực hiện Integration Test nữa. Thực tế việc tích hợp giữa các
Unit dẫn đến những tình huống hoàn toàn khác.
Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từng Unit.
Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tích hợp trước đó
và đã hoàn tất (passed) các đợt Integration Test trước đó. Lúc này, ta chỉ cần kiểm tra giao
tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trước đó, điều này làm cho số
lượng kiểm tra sẽ giảm đi rất nhiều, sai sót sẽ giảm đáng kể.
Có 4 loại kiểm tra trong Integration Test:
- Kiểm tra cấu trúc (structure): Tương tự White Box Test (kiểm tra nhằm bảo đảm
các thành phần bên trong của một chương trình chạy đúng), chú trọng đến hoạt động của
các thành phần cấu trúc nội tại của chương trình chẳng hạn các lệnh và nhánh bên trong.
- Kiểm tra chức năng (functional): Tương tự Black Box Test (kiểm tra chỉ chú trọng
đến chức năng của chương trình, không quan tâm đến cấu trúc bên trong), chỉ khảo sát chức
năng của chương trình theo yêu cầu kỹ thuật.
- Kiểm tra hiệu năng (performance): Kiểm tra việc vận hành của hệ thống.
- Kiểm tra khả năng chịu tải (stress): Kiểm tra các giới hạn của hệ thống.
8.3.3. System Test - Kiểm tra mức hệ thống
Mục đích System Test là kiểm tra thiết kế và toàn bộ hệ thống (sau khi tích hợp) có
thỏa mãn yêu cầu đặt ra hay không. System Test bắt đầu khi tất cả các bộ phận của phầm
mềm đã được tích hợp thành công. Thông thường loại kiểm tra này tốn rất nhiều công sức 179
và thời gian. Trong nhiều trường hợp, việc kiểm tra đòi hỏi một số thiết bị phụ trợ, phần
mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố,
hoặc hệ thống nhúng. Ở mức độ hệ thống, người kiểm tra cũng tìm kiếm các lỗi, nhưng
trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến
chất lượng của toàn hệ thống.
Điểm khác nhau then chốt giữa Integration Test và System Test là System Test chú
trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự giao tiếp
giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau. Thông thường ta phải thực
hiện Unit Test và Integration Test để bảo đảm mọi Unit và sự tương tác giữa chúng hoạt
động chính xác trước khi thực hiện System Test.
Sau khi hoàn thành Integration Test, một hệ thống phần mềm đã được hình
thành cùng với các thành phần đã được kiểm tra đầy đủ. Tại thời điểm này, lập trình viên
hoặc kiểm tra viên (tester) bắt đầu kiểm tra phần mềm như một hệ thống hoàn chỉnh. Việc
lập kế hoạch cho System Test nên bắt đầu từ giai đoạn hình thành và phân tích các yêu
cầu. Phần sau ta sẽ nói rõ hơn về một quy trình System Test cơ bản và điển hình.
System Test kiểm tra cả các hành vi chức năng của phần mềm lẫn các yêu cầu về
chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật. Mức kiểm tra
này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm hoặc phần cứng bên
ngoài, chẳng hạn các lỗi “tắc nghẽn” (deadlock) hoặc chiếm dụng bộ nhớ. Sau giai đoạn
System Test, PM thường đã sẵn sàng cho khách hàng hoặc người dùng cuối cùng kiểm
tra để chấp nhận (Acceptance Test) hoặc dùng thử (Alpha/Beta Test).
Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Test
thường được thực hiện bởi một nhóm kiểm tra viên hoàn toàn độc lập với nhóm phát triển dự án.
Bản thân System Test lại gồm nhiều loại kiểm tra khác nhau (xem hình 3), phổ biến nhất gồm:
- Kiểm tra chức năng (Functional Test): bảo đảm các hành vi của hệ thống thỏa mãn
đúng yêu cầu thiết kế.
- Kiểm tra khả năng vận hành (Performance Test): bảo đảm tối ưu việc phân bổ tài
nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn…
- Kiểm tra khả năng chịu tải (Stress Test hay Load Test): bảo đảm hệ thống vận
hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất cùng lúc). Stress Test tập trung
vào các trạng thái tới hạn, các “điểm chết”, các tình huống bất thường…
- Kiểm tra cấu hình (Configuration Test)
- Kiểm tra khả năng bảo mật (Security Test): bảo đảm tính toàn vẹn, bảo mật của dữ
liệu và của hệ thống.
- Kiểm tra khả năng phục hồi (Recovery Test): bảo đảm hệ thống có khả năng khôi
phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan
trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến. 180
8.3.4. Kiểm thử chấp nhận – Acceptance test.
Thông thường, sau giai đoạn System Test là Acceptance Test, được khách hàng thực
hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đích của Acceptance Test là để
chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận
sản phẩm (và trả tiền thanh toán hợp đồng).
Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường hợp,
các phép kiểm thử của System Test và Acceptance Test gần như tương tự, nhưng bản chất
và cách thức thực hiện lại rất khác biệt.
Đối với những sản phẩm dành bán rộng rãi trên thị trường cho nhiều người sử dụng,
thông thường sẽ thông qua hai loại kiểm thử gọi là kiểm thử Alpha – Alpha Test và kiểm
thử Beta – Beta .
Test Với Alpha Test, người dùng kiểm thử phần mềm ngay tại nơi phát
triển phần mềm, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa.
Với Beta Test, phần mềm sẽ được gửi tới cho người dùng để kiểm thử ngay trong môi
trường thực, lỗi hoặc phản hồi cũng sẽ gửi ngược lại cho lập trình viên để sửa chữa.
Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá trình
phát triển phần mềm thì kết quả Acceptance Test sẽ sai lệch rất lớn, mặc dù phần mềm đã
trải qua tất cả các kiểm thử trước đó. Sự sai lệch này liên quan đến việc hiểu sai yêu cầu
cũng như sự mong chờ của khách hàng. Ví dụ đôi khi một phần mềm xuất sắc vượt qua các
phép kiểm thử về chức năng thực hiện bởi nhóm thực hiện dự án, nhưng khách hàng khi
kiểm thử sau cùng vẫn thất vọng vì bố cục màn hình nghèo nàn, thao tác không tự nhiên,
không theo tập quán sử dụng của khách hàng v.v...
Gắn liền với giai đoạn Acceptance Test thường là một nhóm những dịch vụ và tài liệu
đi kèm, phổ biến như hướng dẫn cài đặt, sử dụng v.v... Tất cả tài liệu đi kèm phải được cập
nhật và kiểm thử chặt chẽ.
8.4. Các mức độ kiểm thử
Khi thử nghiệm hệ con và thử nghiệm hệ thống (tích hợp), có các chiến lược thử
nghiệm chính là thử nghiệm dưới lên (bottom-up testing) và thử nghiệm trên xuống (top- down testing).
8.4.1 Thử nghiệm dưới lên
Thử nghiệm dưới lên tiến hành thử nghiệm với các mô đun ở mức độ thấp trước. Mô
đun thượng cấp (mô đun gọi) được thay thế bằng chương trình kiểm thử có nhiện vụ đọc dữ
liệu kiểm thử, gọi mô đun cần kiểm thử và kiểm tra kết quả. Nhược điểm của thử nghiệm dưới lên là
- Phát hiện chậm các lỗi thiết kế
- Chậm có phiên bản thực hiện được của hệ thống
8.4.2 Thử ngiệm trên xuống
Thử nghiệm trên xuống tiến hành thử nghiệm với các mô đun ở mức cao trước, các
mô đun mức thấp được tạm thời phát triển với các chức năng hạn chế, có giao diện giống
như trong đặc tả. Mô đun mức thấp có thể chỉ đơn giản là trả lại kết quả với một vài đầu vào định trước. 181
Thử nghiệm trên xuống có ưu điểm là
- Phát hiện sớm các lỗi thiết kế, do đó có thể thiết kế, cài đặt lại với giá rẻ
- Có phiên bản hoạt động sớm (với tính năng hạn chế) do đó có thể sớm tiến hành thẩm định
Nhược điểm của kiểm thử trên xuống là các chức năng của mô đun cấp thấp nhiều
khi rất phức tạp do đó khó có thể mô phỏng được, dẫn đến không kiểm thử đầy đủ chức
năng hoặc phải đình chỉ kiểm thử cho đến khi các mô đun cấp thấp xây dựng xong.
8.4.3. Kiểm thử hồi quy (Regression Testing)
Phần mềm là một trong những loại sản phẩm thay đổi rất nhanh. Người sử dụng luôn
có yêu cầu cải tiến phần mềm và các chức năng mới. Vì vậy, sự chỉnh sửa phần mềm sau
khi đưa vào sử dụng là cần thiết. Mặt khác, bất kỳ sự sửa đổi nào cùng có thể dẫn đến các
lỗi mới. Phần mềm nhất thiết phải được kiểm thử lại sau khi sửa đổi, giai đoạn kiểm thử này
gọi là kiểm thử hồi quy.
Giai đoạn kiểm thử hồi quy thường tái sử dụng các bộ dữ liệu thử đã sử dụng trong
các giai đoạn trước nhằm kiểm tra rằng không có các lỗi mới được đưa vào. Vấn đề đặt ra ở
đây là trong giai đoạn này, các bộ dữ liệu thử nào được tái sử dụng: kiểm thử đơn vị, kiểm
thử tích hợp hay kiểm thử hệ thống?
Chương 9. Vận hành và bảo trì
9.1. Các hoạt động chuyển giao, bảo trì
Bảo trì phần mềm (tiếng Anh software maintenance) bao gồm điều chỉnh các lỗi mà
chưa được phát hiện trong các giai đoạn trước của chu kỳ sống của một phần mềm, nâng
cấp tính năng sử dụng và an toàn vận hành của phần mềm. Bảo trì phần mềm có thể chiếm
đến 65%-75% công sức trong chu kỳ sống của một phần mềm).
Quá trình phát triển phầm mềm bao gồm rất nhiều giai đoạn: thu thập yêu cầu, phân
tích, thiết kế, xây dựng, kiểm tra, triển khai và bảo trì phần mềm. Nhiệm vụ của giai đoạn
bảo trì phần mềm là giữ cho phần mềm được cập nhật khi môi trường thay đổi và yêu cầu
người sử dụng thay đổi.
Theo IEEE (1993), thì bảo trì phần mềm được định nghĩa là việc sửa đổi một phần
mềm sau khi đã bàn giao để chỉnh lại các lỗi phát sinh, cải thiện hiệu năng của phần mềm
hoặc các thuộc tính khác, hoặc làm cho phần mềm thích ứng trong một môi trường đã bị
thay đổi. Bảo trì phần mềm được chia thành 4 loại:
 Sửa lại cho đúng (corrective): là việc sửa các lỗi hoặc hỏng hóc phát sinh. Các lỗi
này có thể do lỗi thiết kế, lỗi logic hoặc lỗi coding sản phẩm. Ngoài ra, các lỗi
cũng có thể do quá trình xử lý dữ liệu, hoặc hoạt động của hệ thống. 182
 Thích ứng (adaptative): là việc chỉnh sửa phần mềm cho phù hợp với môi trường
đã thay đổi của sản phẩm. Môi trường ở đây có nghĩa là tất các các yếu tố bên
ngoài sản phẩm như quy tắc kinh doanh, luật pháp, phương thức làm việc,...
 Hoàn thiện: chỉnh sửa để đáp ứng các yêu cầu mới hoặc thay đổi của người sử
dụng. Loại này tập trung vào nâng cao chức năng của hệ thống, hoặc các hoạt
động tăng cường hiệu năng của hệ thống, hoặc đơn giản là cải thiện giao diện.
Nguyên nhân là với một phần mềm thành công, người sử dụng sẽ bắt đầu khám
phá những yêu cầu mới, ngoài yêu cầu mà họ đã đề ra ban đầu, do đó, cần cải tiến các chức năng.
 Bảo vệ (preventive): mục đích là làm hệ thống dễ dàng bảo trì hơn trong những lần tiếp theo.
Bảo trì phần mềm bao gồm hai hoạt động chính: sửa chữa các lỗi đã không được phát
hiện trong giai đoạn phát triển và kiểm tra; nâng cấp phần mềm theo yêu cầu phát sinh hoặc
yêu cầu đã được hiểu không đúng trong giai đoạn phát triển.
Mỗi hoạt động bảo trì đều được thực hiện tương tự như một hoạt động trong giai
đoạn phát triển, yêu cầu để dẫn đến hành động bảo trì chính là yêu cầu thay đổi.
9.2. Vai trò của bảo trì
* Bảo trì để tu sửa
- Là bảo trì khắc phục những khiếm khuyết có trong phần mềm
- Một số nguyên nhân điển hình
+ Kỹ sư phần mềm và khách hiểu nhầm nhau
+ Lỗi tiềm ẩn của phần mềm do sơ ý của lập trình hoặc khi kiểm thử chưa bao quát hết
+ Vấn đề tính năng của phần mềm: không đáp ứng được yêu cầu về bộ nhớ, tệp, . . . Thiết kế sai, biên tập sai . . .
+ Thiếu chuẩn hóa trong phát triển phần mềm (trước đó)
- Kỹ nghệ ngược (Reverse Engineering): dò lại thiết kế để tu sửa - Những lưu ý + Mức trừu tượng + Tính đầy đủ + Tính tương tác + Tính định hướng
* Bảo trì để thích hợp
- Là tu chỉnh phần mềm theo thay đổi của môi trường bên ngoài nhằm duy trì và
quản lý phần mềm theo vòng đời của nó
- Thay đổi phần mềm thích nghi với môi trường: công nghệ phần cứng, môi trường phần mềm 183
- Những nguyên nhân chính:
+ Thay đổi về phần cứng (ngoại vi, máy chủ,. . .)
+ Thay đổi về phần mềm (môi trường): đổi OS
+ Thay đổi cấu trúc tệp hoặc mở rộng CSDL
* Bảo trì để cải tiến
- Là việc tu chỉnh hệ phần mềm theo các yêu cầu ngày càng hoàn thiện hơn, đầy đủ hơn, hợp lý hơn
- Những nguyên nhân chính:
+ Do muốn nâng cao hiệu suất nên thường hay cải tiến phương thức truy cập tệp
+ Mở rộng thêm chức năng mới cho hệ thống
+ Cải tiến quản lý kéo theo cải tiến tư liệu vận hành và trình tự công việc
+ Thay đổi người dùng hoặc thay đổi thao tác
- Còn gọi là tái kỹ nghệ (re-engineering)
- Mục đích: đưa ra một thiết kế cùng chức năng nhưng có chất lượng cao hơn - Các bước thực hiện:
+ Xây dựng lưu đồ phần mềm
+ Suy dẫn ra biểu thức Boole cho từng dãy xử lý
+ Biên dịch bảng chân lí
+ Tái cấu trúc phần mềm
* Bảo trì để phòng ngừa
- Là công việc tu chỉnh chương trình có tính đến tương lai của phần mềm đó sẽ mở
rộng và thay đổi như thế nào
- Thực ra trong khi thiết kế phần mềm đã phải tính đến tính mở rộng của nó, nên thực
tế ít khi ta gặp bảo trì phòng ngừa nếu như phần mềm được thiết kế tốt
- Mục đích: sửa đổi để thích hợp với yêu cầu thay đổi sẽ có của người dùng
- Thực hiện những thay đổi trên thiết kế không tường minh
- Hiểu hoạt động bên trong chương trình
- Thiết kế / lập trình lại - Sử dụng công cụ CASE
9.3. Các nội dung bảo trì
Quy trình bảo trì là gì ? Đó là quá trình trong vòng đời của phần mềm, cũng tuân theo
các pha phân tích, thiết kế, phát triển và kiểm thử từ khi phát sinh vấn đề cho đến khi giải quyết xong
Thao tác bảo trì: Gồm 2 loại
– Tu chỉnh cải đã có (loại 1)
– Thêm cái mới (loại 2) 184 Sơ đồ bảo trì
- Hiểu phần mềm đã có
• Theo tài liệu nắm chắc các chức năng
• Theo tài liệu chi tiết hãy nắm vững đặc tả chi tiết, điều kiện kiểm thử, . . .
• Dò đọc chương trình nguồn, hiểu trình tự xử lý chi tiết của hệ thống
3 việc trên đều là công việc thực thi trên bàn
- Tu sửa phần mềm đã có
• Bảo trì chương trình nguồn, tạo các môđun mới và dịch lại
• Thực hiện kiểm thử unit và tu chỉnh những mục liên quan có trong tư liệu đặc tả
• Chú ý theo sát tác động của môđun được sửa đến các thành phần khác trong hệ thống
- Phát triển phần mềm mới
• Khi thêm chức năng mới phải phát triển chương trình cho phù hợp với yêu cầu
• Cần tiến hành từ thiết kế, lập trình, gỡ lỗi và kiểm thử unit
• Phản ảnh vào giao diện của phần mềm (thông báo, phiên bản, . . .)
- Kiểm chứng tính nhất quán bằng kiểm thử kết hợp
• Đưa đơn vị (unit) đã dược kiểm thử vào hoạt động trong hệ thống
• Điều chỉnh sự tương tích giữa các môđun
• Dùng các dữ liệu trước đây khi kiểm thử để kiểm thử lại tính nhất quán
• Chú ý hiệu ứng làn sóng trong chỉnh sửa
- Kiểm tra khi hoàn thành bảo trì
• Kiểm tra nội dung mô tả có trong tư liệu đặc tả
• Cách ghi tư liệu có phù hợp với mô tả môi trường phần mềm mới hay không ?
- Lập biểu quản lý bảo trì
• Cần quản lý tình trạng bảo trì
• Lập biểu quản lý tình trạng bảo trì 185  Ngày tháng, giờ  Nguyên nhân
 Tóm tắt cách khắc phục
 Chi tiết khắc phục, hiệu ứng làn sóng  Người làm bảo trì Tài liệu tham khảo
[1]. Nguyễn Văn Vỵ, Nguyễn Việt Hà, Giáo trình kỹ nghệ phần mềm, NXB
Đại học quốc gia Hà Nội, 2008
[2]. Huỳnh Văn Đức, Giáo trình nhập môn UML, NXB Lao động xã hội, 2003.
[3]. Dương Kiều Hoa, Giáo trình phân tích hệ thống hướng đối tượng với
UML, NXB ĐH Quốc gia TP Hồ Chí Minh, 2007.
[4] . http://www.pcworld.com.vn/pcworld/printArticle.asp?atcl_id=5f5e5d585d5d58 186 MỤC LỤC
Chương 1. Tổng quan về phần mềm và công nghệ phần mềm...........................1
1.1. Một số khái niệm cơ bản.................................................................................1
1.1.1. Phần mềm.................................................................................................1
1.1.2. Hệ thống phần mềm.................................................................................1
1.2. Tầm quan trọng của phần mềm......................................................................2
1.3. Đặc trưng & chất lượng sản phầm phần mềm................................................3
1.3.1. Đặc trưng phần mềm................................................................................3
1.3.2. Chất lượng sản phầm phần mềm..............................................................3
1.4. Phân loại phần mềm........................................................................................4
1.5. Sự tiến hóa của phần mềm..............................................................................5
1.6. Thực trạng và thách thức trong phát triển phần mềm.....................................6
1.6.1. Thực trạng................................................................................................6
1.6.2. Thách thức................................................................................................6
1.7. Tổng quan về công nghệ phần mềm...............................................................7
1.7.1. Khái niệm.................................................................................................7
1.7.2. Lịch sử phát triển.....................................................................................8
Chương 2. Quy trình phát triển phần mềm........................................................10
2.1. Vòng đời phần mềm.....................................................................................10
2.1.1. Khái niệm...............................................................................................10
2.1.2. Mô hình vòng đời phần mềm của Boehm..............................................10
2.1.3. Suy nghĩ mới về vòng đời phần mềm....................................................10
2.2. Quy trình phát triển phần mềm.....................................................................10
2.2.1. Khái niệm...............................................................................................10
2.2.2. Các hoạt động........................................................................................11
2.3. Một số mô hình thực hiện.............................................................................11
2.3.1. Mô hình tuyến tính.................................................................................11
2.3.2. Phát triển tiến hoá..................................................................................13 187
2.3.3. Phát triển dựa trên thành phần...............................................................15
2.3.4. Kỹ thuật thế hệ thứ tư............................................................................15
2.3.5. Phát triển nhanh ứng dụng (Rapid Application Development ).............17
2.3.6. Phát triển hình thức................................................................................19
2.3.7. Phát triển hướng đối tượng....................................................................19
2.3.8. Phát triển phần mềm mã nguồn mở.......................................................20
2.3.9. Mô hình khác.........................................................................................21
Chương 3. Quản lý dự án phần mềm..................................................................23
3.1. Giới thiệu......................................................................................................23
3.1.1. Dự án và dự án phần mềm.....................................................................23
3.1.2. Quản lý dự án.........................................................................................23
3.2. Các hoạt động quản lý..................................................................................24
3.2.1. Xác định dự án.......................................................................................24
3.2.2. Đo và ước lượng....................................................................................25
3.2.3. Lập lịch..................................................................................................25
3.2.4. Tổ chức dự án........................................................................................29
3.2.5. Theo dõi thực hiện dự án, điều chỉnh lịch biểu......................................31
3.2.6. Viết báo cáo dự án.................................................................................34
3.3. Các yếu tố quản lý........................................................................................35
3.3.1. Quản lý tài nguyên.................................................................................35
3.3.2. Quản lý cấu hình....................................................................................36
3.3.3. Quản lý rủi ro.........................................................................................41
3.3.4. Quản lý thay đổi.....................................................................................46
3.3.5. Quản lý chất lượng.................................................................................50
3.4. Phương pháp & công cụ hỗ trợ quản lý........................................................55
3.4.1. Microsoft Project...................................................................................55
3.4.2. Microsoft SourceSafe.............................................................................56
3.4.3. Visio.......................................................................................................57
Chương 4. Ngôn ngữ mô hình hóa UML.............................................................58
4.1. Ngôn ngữ mô hình hóa thống nhất UML.....................................................58
4.1.1. Giới thiệu...............................................................................................58
4.1.2. Các đặc trưng và khả năng của UML....................................................62
4.1.3. Kiến trúc trong UML.............................................................................63
4.1.4. Mô hình khái niệm của UML.................................................................64
4.1.5. Các biểu đồ............................................................................................70
4.1.6. Rational Rose.........................................................................................75
4.2. Mô hình hóa ca sử dụng................................................................................77
4.2.1. Giới thiệu...............................................................................................77
4.2.2. Mô hình hóa ca sử dụng.........................................................................79 188
4.2.3. Biểu đồ ca sử dụng.................................................................................80
4.2.4. Các biến thể trong một ca sử dụng.........................................................85
4.2.5. Quan hệ giữa các ca sử dụng.................................................................86
4.2.6. Mô tả ca sử dụng....................................................................................88
4.3. Biểu đồ hoạt động (Activity Diagram).........................................................89
Chương 5. Nắm bắt và phân tích yêu cầu...........................................................92
5.1. Vai trò của nắm bắt và phân tích yêu cầu.....................................................92
5.2. Các hoạt động phân tích và đặc tả yêu cầu...................................................93
5.2.1. Nghiên cứu khả thi.................................................................................93
5.2.2. Phân tích yêu cầu...................................................................................94
5.2.3. Xác định yêu cầu....................................................................................95
5.2.4. Đặc tả yêu cầu........................................................................................96
5.3. Sản phẩm của phân tích và đặc tả yêu cầu..................................................100
5.3.1. Báo cáo khả thi.....................................................................................100
5.3.2. Mô hình hệ thống.................................................................................101
5.3.3. Tài liệu định nghĩa yêu cầu (requirement definition)..........................102
5.3.4. Tài liệu đặc tả yêu cầu.........................................................................103
5.3.5. Tài liệu yêu cầu....................................................................................104
Chương 6. Thiết kế phần mềm...........................................................................106
6.1. Khái niệm, nguyên lý, chất lượng thiết kế..................................................106
6.1.1. Khái niệm.............................................................................................106
6.1.2. Nguyên lý.............................................................................................106
6.1.3. Chất lượng thiết kế...............................................................................107
6.2. Nhiệm vụ thiết kế........................................................................................109
6.2.1. Thiết kế kiến trúc (architectural design)..............................................109
6.2.2. Thiết kế dữ liệu (data design)..............................................................109
6.2.3. Thiết kế chức năng (functional design)................................................110
6.2.4. Thiết kế giao diện người dùng (interface design)................................110
6.3. Yêu cầu đối với thiết kế..............................................................................112
6.4. Phương pháp và công cụ.............................................................................113
6.4.1. Phương pháp thiết kế...........................................................................113
6.4.2. Công cụ................................................................................................116
Chương 7. Lập trình...........................................................................................119
7.1. Ngôn ngữ lập trình......................................................................................119
7.1.1 Đặc trưng của ngôn ngữ lập trình.........................................................119
7.1.2 Lựa chọn ngôn ngữ lập trình.................................................................120
7.1.3 Ngôn ngữ lập trình và và sự ảnh hưởng tới kỹ nghệ phần mềm...........120
7.2. Các phương pháp lập trình..........................................................................120
7.2.1. Lập trình tuần tự...................................................................................120 189
7.2.2. Lập trình cấu trúc.................................................................................121
7.2.3. Lập trình hướng đối tượng...................................................................121
7.2.4. Lập trình logic......................................................................................122
7.3. Phong cách lập trình...................................................................................123
7.3.1 Tài liệu chương trình.............................................................................123
7.3.2 Khai báo dữ liệu....................................................................................123
7.3.3 Xây dựng câu lệnh................................................................................124
7.3.4 Vào/ra....................................................................................................124
7.4. Lập trình tránh lỗi.......................................................................................124
7.4.1 Lập trình thứ lỗi....................................................................................125
7.4.2. Lập trình phòng thủ..............................................................................125
7.5. Lập trình hiệu quả.......................................................................................126
7.5.1. Tính hiệu quả chương trình..................................................................126
7.5.2. Hiệu quả bộ nhớ...................................................................................126
7.5.3. Hiệu quả vào/ra....................................................................................127
Chương 8. Kiểm thử và tích hợp........................................................................128
8.1. Giới thiệu....................................................................................................128
8.1.1. Khái niệm về kiểm thử phần mềm.......................................................128
8.1.2. Mục đích của kiểm thử phần mềm.......................................................128
8.1.3. Nguyên tắc trong kiểm thử phần mềm.................................................128
8.1.4. Phân loại kiểm thử...............................................................................129
8.2. Các phương pháp kiểm thử.........................................................................129
8.2.1. Phương pháp kiểm thử hộp đen – Black box testing...........................129
8.2.2. Phương pháp kiểm thử hộp trắng – White box testing........................137
8.3. Các chiến lược kiểm thử.............................................................................141
8.3.1. Unit Test – Kiểm tra mức đơn vị.........................................................142
8.3.2. Integration Test – Kiểm tra tích hợp....................................................142
8.3.3. System Test - Kiểm tra mức hệ thống..................................................143
8.3.4. Kiểm thử chấp nhận – Acceptance test................................................143
8.4. Các mức độ kiểm thử..................................................................................144
8.4.1 Thử nghiệm dưới lên.............................................................................144
8.4.2 Thử ngiệm trên xuống...........................................................................144
8.4.3. Kiểm thử hồi quy (Regression Testing)...............................................144
Chương 9. Vận hành và bảo trì..........................................................................145
9.1. Các hoạt động chuyển giao, bảo trì............................................................145
9.2. Vai trò của bảo trì.......................................................................................145
9.3. Các nội dung bảo trì....................................................................................146
Tài liệu tham khảo...............................................................................................148
MỤC LỤC.............................................................................................................149 190 191