Bai giang ki thuat phan mem

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 [r]

ĐẠI HỌC QUỐC GIA HÀ NỘI Trường Đại học Công nghệ

Nguyễn Việt Hà

Bài giảng

MỤC LỤC

CHƯƠNG 1 - Phần mềm kỹ nghệ

phần mềm 1

1.1 Tầm quan trọng tiến hóa phần mềm 1

1.1.1 Tiến hóa phần mềm

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

b Thời kỳ trải rộng từ năm 1960 đến năm 1970: 1

c Thời kỳ từ năm 1970 đến đầu năm 1990: 2

d Thời kỳ sau 1990: 2

1.1.2 Sự ứng dụng phần mềm

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

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

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

d Phần mềm khoa học công nghệ 3

e Phần mềm nhúng 3

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

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

1.2 Khó khăn, thách thức phát triển phần mềm 4

1.2.1 Phần mềm phần mềm tốt

1.2.2 Đặc trưng phát triển vận hành phần mềm

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

b Phần mềm khơng hỏng thối hóa theo thời gian 6

c Phần lớn phần mềm xây dựng từ đầu, lắp ráp từ thành phần có sẵn 6

1.2.3 Nhu cầu độ phức tạp

1.3 Kỹ nghệ phần mềm 7

1.3.1 Định nghĩa

a Các phương pháp 7

b Các công cụ 7

c Các thủ tục 8

1.3.2 Mơ hình vịng đời cổ điển

a Kỹ nghệ phân tích hệ thống 8

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

c Thiết kế 8

d Mã hóa 9

e Kiểm thử 9

f Bảo trì 9

1.3.3 Mơ hình làm mẫu 10

1.3.4 Mơ hình xoắn ốc 11

1.3.5 Kỹ thuật hệ thứ tư 13

1.3.6 Mơ hình lập trình cực đoan 14

b) Lập trình đơi 14

1.3.7 Tổ hợp mơ hình 15

1.3.8 Tính khả thị trình kỹ nghệ 15

1.3.9 Vấn đề giảm kích cỡ phần mềm 16

1.4 Cái nhìn chung kỹ nghệ phần mềm 17

Chương 2 - Phân tích đặc tả yêu cầu 20

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

2.2 Nghiên cứu khả thi 21

2.3 Nền tảng phân tích yêu cầu 23

2.3.1 Các ngun lý phân tích 23

2.3.2 Mơ hình hóa 24

2.3.3 Người phân tích 26

2.4 Xác định đặc tả yêu cầu 27

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

2.4.2 Đặc tả yêu cầu 27

2.4.3 Thẩm định yêu cầu 28

2.5 Làm mẫu q trình phân tích 29

2.5.1 Các bước làm mẫu 29

2.6 Định dạng đặc tả yêu cầu 31

Chương 3 - Thiết kế phần mềm 34

3.1 Khái niệm thiết kế phần mềm 34

3.1.1 Khái niệm 34

3.1.2 Tầm quan trọng 34

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

3.1.4 Cơ sở thiết kế 36

3.1.5 Mô tả thiết kế 37

3.1.6 Chất lượng thiết kế 38

3.2 Thiết kế hướng chức 41

3.2.1 Cách tiếp cận hướng chức 41

3.2.2 Biểu đồ luồng liệu 42

3.2.3 Lược đồ cấu trúc 42

3.2.4 Các từ điển liệu 42

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

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

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

3.3.3 Cơ sở thiết kế hướng đối tượng 43

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

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

3.3.6 Quan hệ thiết kế lập trình hướng đối tượng 45

3.3.7 Quan hệ thiết kế hướng đối tượng hướng chức 46

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

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

Chương - Lập trình 50

4.1 Ngơn ngữ lập trình 50

4.1.1 Đặc trưng ngơn ngữ lập trình 50

4.1.2 Lựa chọn ngơn ngữ lập trình 51

4.1.3 Ngơn ngữ lập trình và ảnh hưởng tới kỹ nghệ phần mềm 52

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

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

4.2.2 Khai báo liệu 53

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

4.2.4 Vào/ra 54

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

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

4.3.2 Lập trình phịng thủ 56

4.4 Lập trình hướng hiệu thực 57

4.4.1 Tính hiệu chương trình 57

4.4.2 Hiệu nhớ 58

4.4.3 Hiệu vào/ra 58

Chương 5 - Xác minh thẩm định 60 5.1 Đại cương 60

5.2 Khái niệm phép thử 61

5.3 Thử nghiệm chức thử nghiệm cấu trúc 61

5.3.1 Thử nghiệm chức 61

5.3.2 Thử nghiệm cấu trúc 62

5.4 Quá trình thử nghiệm 63

5.4.1 Thử nghiệm gây áp lực 64

5.5 Chiến lược thử nghiệm 64

5.5.1 Thử nghiệm lên 64

5.5.2 Thử ngiệm xuống 65

Chương 6 - Quản lý dự án phát triển phần mềm 66

6.1 Đại cương 66

6.2 Độ đo phần mềm 67

6.2.1 Đo kích cỡ phần mềm 67

6.2.2 Độ đo dựa thống kê 68

6.3 Ước lượng 68

6.4 Quản lý nhân 69

6.5 Quản lý cấu hình 70

6.6 Quản lý rủi ro 71

CHƯƠNG

Phần mềm kỹ nghệ phần mềm

1.1 Tầm quan trọng tiến hóa phần mềm

Máy tính khác với máy móc thơng thường điểm thực nhiệm vụ khác cách sử dụng phần mềm khác Tức phần mềm tạo khác biệt máy tính định lực máy tính Cho đến năm 1990, xu hướng ngành cơng nghiệp máy tính phát triển phần cứng nhằm giảm giá thành hệ thống tăng lực xử lý lưu trữ liệu Do nhu cầu phần mềm tăng lên nhanh chóng, thách thức hay mục tiêu ngành cơng nghiệp máy tính cải thiện chất lượng giảm giá thành phần mềm

Có thể nói khả phần cứng biểu thị cho tiềm hệ thống phần mềm chế giúp khai thác tiềm Chúng ta xem xét tầm quan trọng phần mềm khía cạnh tiến hóa phạm vi ứng dụng chúng

1.1.1 Tiến hóa phần mềm

Sự tiến hóa phần mềm gắn liền với tiến hóa phần cứng chia làm giai đoạn:

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

- Giai đoạn phần cứng thay đổi liên tục, số lượng máy tính phần lớn máy đặt hàng chuyên dụng cho ứng dụng đặc biệt

- Phương thức xử lý theo lơ (batch), tức “gói” chương trình có sử dụng kết lại thành khối dể tăng tốc độ thực

- Thời kỳ lập trình máy tính coi nghệ thuật “theo năng”, chưa có phương pháp hệ thống Việc phát triển phần mềm chưa 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 người sử dụng kiêm việc bảo trì sửa lỗi

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

- Nhiều hệ thống thời gian thực với đặc trưng thu thập, phân tích biến đổi liệu từ nhiều nguồn khác phản ứng (xử lý, tạo output) khoảng thời gian định xuất

- Tiến lưu trữ trực tuyến làm xuất hệ hệ quản trị CSDL - Số lượng hệ thống dựa 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 lớn làm nẩy sinh nhu cầu sửa chữa gặp lỗi, cần sửa đổi người dùng có yêu cầu hay phải thích nghi với thay đổi 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 tiêu tốn nhiều công sức tài nguyên đến mức báo động

c Thời kỳ từ năm 1970 đến đầu năm 1990:

- Hệ thống phân tán (bao gồm nhiều máy tính, máy thực chức liên lạc với máy khác) xuất làm tăng quy mô độ phức tạp phần mềm ứng dụng chúng

- Mạng toàn cục 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 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ý liệu

- Công nghệ chế tạo vi xử lý tiến nhanh khiến cho máy tính cá nhân, máy trạm để bàn, thiết bị nhúng (dùng cho điều khiển robot, ô tô, thiết bị y tế, đồ điện gia dụng, ) phát triển mạnh khiến cho nhu cầu phần mềm tăng nhanh

- Thị trường phần cứng vào ổn định, chi phí cho phần mềm tăng nhanh 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 cách tiếp cận nhanh chóng thay nhiều cách tiếp cận phát triển phần mềm truyền thống lĩnh vực ứng dụng - Sự phát triển 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 lớn, quy mô độ phức tạp hệ thống phần mềm tăng đáng kể

1.1.2 Sự ứng dụng phần mềm

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

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

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

- Xử lý cấu trúc thông tin phức tạp 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 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 liệu phức tạp nhiều giao diện

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

Phần mềm điều phối, phân tích kiểm sốt kiện giới thực chúng xuất gọi phần mềm thời gian thực Điển hình phần mềm điều khiển thiết bị tự động Phần mềm thời gian thực bao gồm thành tố:

- Thành phần thu thập liệu để thu định dạng thơng tin từ mơi trường ngồi - Thành phần phân tích để biến đổi thơng tin theo u cầu ứng dụng

- Thành phần kiểm soát đưa đáp ứng mơi trường ngồi

- Thành phần điều phối để điều hòa thành phần khác cho trì việc đáp ứng thời gian thực

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

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

Là phần mềm phục vụ hoạt động kinh doanh hay nghiệp vụ tổ chức, doanh nghiệp Đây coi lĩnh vực ứng dụng phần mềm lớn Điển hình hệ thống thông tin quản lý gắn chặt với CSDL, ứng dụng tương tác xử lý giao tác cho điểm bán hàng

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

e Phần mềm nhúng

- Nằm nhớ đọc dùng để điều khiển sản phẩm hệ thống cho người dùng thị trường cơng nghiệp

- Có đặc trưng phần mềm thời gian thực phần mềm hệ thống

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

- Bùng nổ từ xuất máy tính cá nhân, giải toán nghiệp vụ 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 trọng

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

- Dùng thuật toán phi số để giải vấn đề phức tạp mà tính tốn hay phân tích trực tiếp khơng quản lý

- Các ứng dụng là: hệ chuyên gia (hệ sở tri thức), nhận dạng (hình ảnh tiếng nói), chứng minh định lý chơi trị chơi, mơ

Ngồi ra, cịn kể đến dạng phần mềm đặc biệt phần mềm phục vụ kỹ nghệ phần mềm Đó phần mềm chương trình dịch, phần mềm gỡ rối, cơng cụ hỗ trợ phân tích thiết kế (CASE) Các phần mềm xuất dạng phần mềm máy tính cá nhân, phần mềm hệ thống phần mềm nghiệp vụ

1.2 Khó khăn, thách thức phát triển phần mềm

Từ năm 60, nhiều dự án phần mềm lớn không thành công dự án OS 360 (tiêu tốn số tiền thời gian gấp nhiều lần dự kiến) TSS 360 (không đạt tiêu kỹ thuật, không hoạt động) IBM Do đó, việc phát triển phần mềm nhận thức lĩnh vực đầy khó khăn chứa nhiều rủi ro Chúng ta xem xét khó khăn thách thức khía cạnh đặc trưng, qui mơ nhu cầu phần mềm

1.2.1 Phần mềm phần mềm tốt

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

• Có thể bảo trì được: phần mềm tuổi thọ dài phải viết lập tư liệu cho việc thay đổi tiến hành mà không tốn Đây coi đặc tính chủ chốt phần mềm tốt Để bảo trì được, phần mềm phải có thiết kế tốt có tính modun hóa cao, viết ngơn ngữ bậc cao lập tài liệu (tài liệu phân tích, thiết kế, 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 điều mà người tiêu dùng mong mỏi không thất bại nhiều điều đặc tả Điều có nghĩa phần mềm phải thỏa mãn nhu cầu người dùng Để đạt yếu tố đáng tin cậy, trước tiên người phát triển cần phải hiểu cách đắn yêu cầu người dùng sau cần thỏa mãn yêu cầu thiết kế cài đặt tốt

• Có hiệu quả: phần mềm hoạt động phải khơng lãng phí tài ngun hệ thống nhớ, xử lý Nếu phần mềm chạy chậm hay địi hỏi q nhiều nhớ dù có cài đặt nhiều chức không đưa vào sử dụng Tuy nhiên, ngoại trừ 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 việc phải dùng đếm kỹ thuật đặc thù cài đặt ngơn ngữ máy khiến cho chi phí tăng cao phần mềm 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ả kiến thức người dùng, có tài liệu hướng dẫn tiện ích trợ giúp Đối tượng phần mềm nghiệp vụ thường người không am hiểu máy tính, họ xa lánh 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 thuộc tính khó khăn Các thuộc tính mẫu thuẫn lẫn nhau, ví dụ tính hiệu tính dễ sử dụng, tính bảo trì Quan hệ chi phí cải tiến hiệu thuộc tính khơng phải tuyến tính Nhiều cải thiện nhỏ thuộc tính đắt

1.2.2 Đặc trưng phát triển vận hành phần mềm

Chúng ta thấy khó khăn hàng đầu việc phát triển phần mềm tính chất phần mềm hệ thống logic, hệ thống vật lý Do có đặc trưng khác biệt đáng kể với đặc trưng phần cứng Dưới yếu tố tạo phức tạp trình phát triển sử dụng, bảo trì phần mềm

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

Phần mềm được thiết kế, phát triển phần cứng, khơng định hình trước Chỉ phát triển xong người ta có sản phẩm cụ thể hiểu có hiệu hay khơng Tức bước trung gian, khó kiểm sốt chất lượng phần mềm

Giá thành phần cứng chủ yếu bị chi phối giá thành nguyên vật liệu tương đối dễ kiểm soát Trong đó, giá thành phần mềm chủ yếu tập chung vào chi phí nhân cơng Q trình phát triển phần mềm phụ thuộc vào người (hiểu biết, khả vận dụng, kinh nghiệm cách thức quản lý) tiến hành phát triển điều kiện môi trường (kỹ thuật, xã hội) đa dạng không ngừng thay đổi Do khó ước lượng chi phí hiệu phần mềm

b Phần mềm khơng hỏng thối hóa theo thời gian

Phần mềm không cảm ứng tác động môi trường vốn gây cho phần cứng bị mịn cũ đi, thố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 thay đổi (bảo trì) để đáp ứng nhu cầu ln thay đổi tổ chức sử dụng Mỗi thay đổi, xuất thêm số khiếm khuyết tránh làm cho số lỗi tiềm ẩn phần mềm tăng lên Dần dần, phần mềm bị thối hóa tỷ lệ sai hỏng ngày tăng lên đến mức gây thiệt hại chấp nhận

Việc bảo trì phần mềm phức tạp nhiều có chất khác hẳn so với bảo trì phần cứng phức tạp hệ thống phần mềm khơng có sẵn phần thay cho phận bị lỗi Chúng ta không thay phận bị lỗi có sẵn mà thực tế phải tạo mơđun Do đó, thơng thường có nhà sản xuất phần mềm bảo trì (sửa chữa) hỏng hóc Sẽ khó ước lượng chi phí cho bảo trì phần mềm

c Phần lớn phần mềm xây dựng từ đầu, lắp ráp từ thành phần có sẵn

• Phần mềm thường đặt hàng theo đơn vị hoàn chỉnh, theo yêu cầu riêng khách hàng

• Phần mềm lắp ráp theo khn 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à xây dựng Môi trường phần mềm (gồm phần cứng, phần mềm nền, người tổ chức) định dạng từ trước lại thay đổi thường xuyên

Những yếu tố dẫn đến chi phí cho phần mềm cao khó đảm bảo lịch biểu cho phát triển phần mềm

1.2.3 Nhu cầu độ phức tạp

Tuy ngành công nghiệp máy tính bước sang giai đoạn phát triển thứ tư thách thức phát triển phần mềm máy tính khơng ngừng gia tăng ngun nhân sau:

- Khả xây dựng chương trình khơng giữ nhịp với nhu cầu phần mềm tăng lên nhanh chóng, đặc biệt Internet phát triển số lượng người dùng tăng cao Ngày nay, sản xuất phần mềm trở thành ngành công nghiệp không lồ suất không cao, khơng đáp ứng địi hỏi xã hội điều ảnh hưởng lớn đến giá thành chất lượng phần mềm Ngồi ra, cịn tồn nhiều chương trình thiết kế lập tài liệu sơ sài khiến cho việc bảo trì khó khăn tài nguyên Phát triển phần mềm dễ bảo trì để thay hệ thống cũ trở thành nhu cầu cấp bách

- Cùng với phát triển phần cứng, quy mô độ phức tạp phần mềm ngày tăng Một số phần mềm đại có kích thước tính đơn vị triệu dịng lệnh (HĐH Unix, Windows ) Một vấn đề khó khăn sản xuất phần mềm lớn độ phức tạp tăng vọt, kinh nghiệm sản xuất sản phẩm nhỏ không ứng dụng cho mơi trường làm việc theo nhóm phát triển sản phẩm lớn

1.3 Kỹ nghệ phần mềm

1.3.1 Định nghĩa

Một định nghĩa ban đầu kỹ nghệ phần mềm Fritz Bauer nêu là: Việc thiết lập sử dụng nguyên lý công nghệ đắn để thu phần mềm cách kinh tế vừa tin cậy vừa làm việc hiệu máy thực Kỹ nghệ phần mềm trình gồm loạt bước chứa đựng yếu tố chủ chốt:

• Phương pháp • Cơng cụ • Thủ tục

Các yếu tố giúp người quản lý kiểm soát tiến trình phát triển phần mềm, cung cấp cho người kỹ sư phần mềm tảng để xây dựng phần mềm chất lượng cao theo cách thức hiệu quả, giới hạn định

a Các phương pháp

Chỉ cách làm mặt kỹ thuật để xây dựng phần mềm, sử dụng bước: lập kế hoạch, ước lượng dự án, phân tích yêu cầu hệ thống phần mềm, thiết kế cấu trúc liệu, kiến trúc chương trình thủ tục thuật tốn, mã hóa kiểm thử bảo trì Các phương pháp cho kỹ nghệ phần mềm thường đưa ký pháp đồ họa hay hướng ngôn ngữ đặc biệt, cách thức thực tập tiêu chuẩn chất lượng sản phẩm phần mềm

b Các công cụ

Cung cấp hỗ trợ tự động hay bán tự động để phát triển phần mềm theo phương pháp khác Khi cơng cụ tích hợp đến mức thơng tin chúng tạo dùng cho cơng cụ khác hệ thống hỗ trợ phát triển phần mềm thiết lập cịn gọi 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 chất keo dán phương pháp công cụ lại với làm cho chúng sử dụng hợp lý hạn trình phát triển phần mềm Thủ tục bao gồm:

- Xác định trình tự phương pháp áp dụng cho dự án

- Xác định cột mốc mà có sản phẩm định bàn giao người quản lý phần mềm nắm tiến độ kiểm soát kết

Sau đây, xem xét số cách tiếp cận (cịn gọi mơ hình hay khn cảnh) tiến trình phát triển phần mềm

1.3.2 Mơ hình vịng đời cổ điển

Dưới mô tả kỹ nghệ phần mềm tiến hành theo mơ hình vịng đời cổ điển, đơi cịn gọi mơ hình thác nước (hình 1.1) Mơ hình u cầu tiếp cận cách hệ thống, chặt chẽ (xong bước chuyển sang bước sau) việc phát triển phần mềm, bắt đầu mức phân tích hệ thống tiến dần xuống phân tích, thiết kế, mã hóa, kiểm thử bảo trì:

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

Kỹ nghệ 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 lượng nhỏ thiết kế phân tích mức đỉnh Mục đích bước xác định khái quát phạm vi, yêu cầu tính khả thi 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 tập trung việc thu thập phân tích thơng tin cần cho phần mềm, chức cần phải thực hiện, hiệu cần có giao diện cho người sử dụng

- Kết phân tích tư liệu yêu cầu cho hệ thống phần mềm (đặc tả yêu cầu) để khách hàng duyệt lại dùng làm tài liệu cho người phát triển

c Thiết kế

- Là q trình chuyển hóa u cầu phần mềm thành mô tả thiết kế - Thiết kế gồm nhiều bước, thường tập trung vào cơng việc chính: thiết kế kiến trúc phần mềm, thiết kế cấu trúc liệu, thiết kế chi tiết thủ tục, thiết kế giao diện tương tác

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

d Mã hóa

Biểu diễn thiết kế hay số ngơn ngữ lập trình dịch thành mã máy thực

e Kiểm thử

i) phát sửa lỗi phần logic bên chương trình hay cịn gọi lỗi lập trình,

ii) kiểm tra xem phần mềm có hoạt động mong muốn không, tức phát sửa lỗi chức thiếu hụt, sai sót chức năng; kiểm tra xem phần mềm có đảm bảo tính hiệu thực hay khơng

f Bảo trì

Bao gồm công việc sửa lỗi phát sinh áp dụng chương trình thích ứng với thay đổi mơi trường bên ngồi (hệ điều hành mới, thiết bị ngoại vi mới, yêu cầu người dùng) yêu cầu bổ sung chức hay nâng cao hiệu cần có

Một số vấn đề gặp phải dùng mơ hình vịng đời cổ điển là:

1 Các dự án thực tuân theo dịng chảy mà mơ hình đề nghị Bao việc lặp lại xuất tạo vấn đề việc áp dụng mơ hình

2 Khách hàng thường khó phát biểu yêu cầu cách tường minh từ đầu Vòng đời cổ điển địi hỏi điều thường khó thích hợp với bất trắc tự nhiên tồn vào lúc đầu nhiều dự án

3 Đòi hỏi khách hàng phải kiên nhẫn Bản làm việc chương trình có vào lúc cuối thời gian dự án Một sai sót nhỏ phân tích/thiết kế đến có chương trình làm việc phát ra, thảm họa

Tuy vậy, mơ hình vịng đời cổ điển có vị trí quan trọng cơng việc kỹ nghệ phần mềm Nó đưa tiêu bố trí phương pháp cho phân tích, thiết kế, mã hóa, kiểm thử bảo trì Vịng đời cổ điển cịn mơ hình sử dụng rộng rãi, dự án vừa nhỏ

Phân tích

Thiết kế

Mã hố

Hình 1.1: Mơ hình vịng đời cổ điển

1.3.3 Mơ hình làm mẫu

Cách tiếp cận làm mẫu cho kỹ nghệ phần mềm cách tiếp cận tốt khi:

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

- Người phát triển không hiệu thuật tốn, thích nghi hệ điều hành hay giao diện người máy cần có

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

Làm mẫu tạo mơ hình cho phần mềm cần xây dựng Mơ hình có dạng:

1 Bản mẫu giấy hay máy tính mơ tả giao diện người-máy làm người dùng hiểu cách tương tác xuất

2 Bản mẫu cài đặt tập chức phần mềm mong đợi

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

Trước hết người phát triển khách hàng gặp xác định mục tiêu tổng thể cho phần mềm, xác định yêu cầu biết, miền cần khảo sát thêm Tiếp theo giai đoạn thiết kế nhanh, tập trung vào việc biểu diễn khía cạnh phần mềm thấy người dùng (input output), xây dựng mẫu Người dùng đánh giá làm mịn yêu cầu cho phần mềm Tiến trình lặp lặp lại mẫu thoả mãn yêu cầu khách hàng, đồng thời giúp người phát triển hiểu kỹ nhu cầu cần phải thực (hình 1.2)

Kiểm thử

Một biến thể mơ hình mơ hình thăm dị, u cầu cập nhật liên tục mẫu tiến hóa liên tục để trở thành sản phẩm cuối Mô hình làm mẫu có số vấn đề như:

• Do hồn thiện dần (tiến hóa) mẫu, phần mềm nhiều có tính cấu trúc khơng cao, dẫn đến khó kiểm sốt, khó bảo trì

• Khách hàng nhiều thất vọng với việc phát triển phần mềm họ nhầm tưởng mẫu sản phẩm cuối hướng tới người sử dụng Khách hàng khơng dành nhiều cơng sức vào đánh giá mẫu

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

1.3.4 Mơ hình xoắn ốc

Mơ hình xoắn ốc Boehm đưa năm 1988 Mơ hình đưa thêm vào việc phân tích yếu tố rủi ro Quá trình phát triển chia thành nhiều bước lặp lại, bước bắt đầu việc phân tích rủi ro tạo mẫu, cải tạo phát triển mẫu, duyệt lại, tiếp tục (hình 1.3) Nội dung bước gồm bốn hoạt động chính:

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

- Phân tích rủi ro: phân tích phương án xác định/giải rủi ro - Kỹ nghệ: phát triển sản phẩm “mức tiếp theo”

- Đánh giá: đánh giá khách hàng kết kỹ nghệ

Tập hợp Yêu cầu

Thiết kế nhanh

Xây dựng mẫu Đánh giá

khách hàng Làm mịn

yêu cầu

Sản phẩm cuối

Với lần lặp xoắn ốc (bắt đầu từ tâm), phiên hoàn thiện dần Nếu phân tích rủi ro u cầu khơng chắn mẫu sử dụng giai đoạn kỹ nghệ; mô hình mơ khác dùng để làm rõ vấn đề làm mịn yêu cầu

Tại vịng xoắn ốc, phân tích rủi ro phải đến định “tiến hành tiếp hay dừng” Nếu rủi ro q lớn đình dự án

Mơ hình xoắn ốc có số vấn đề khó thuyết phục khách hàng lớn cách tiếp cận tiến hóa kiểm sốt Nó địi hỏi tri thức chun gia đánh giá rủi ro xác dựa tri thức chuyên gia mà đạt thành cơng Mơ hình xoắn ốc địi hỏi lực quản lý cao, khơng quản lý tốt dễ rơi vào trạng thái sửa đổi cục khơng có kế hoạch mơ hình làm mẫu (thăm dị) Và mơ hình tương đối chưa sử dụng rộng rãi vòng đời làm mẫu Cần phải có thêm số năm trước người ta xác định tính hiệu mơ hình với chắn hồn tồn

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

Kế hoạch ban đầu Rủi ro ban đầu

Lập kế hoạch Phân tích rủi ro

Kế hoạch dựa đánh giá

khách hàng

Rủi ro dựa kế hoạch sửa đổi Làm tiếp

Đánh giá khách hàng

Đánh giá Kỹ nghệ

1.3.5 Kỹ thuật hệ thứ tư

Thuật ngữ kỹ thuật hệ thứ tư (4GT - fourth generation technology) bao gồm phạm vi rộng công cụ phần mềm có điểm chung:

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

2 Tự động sinh mã chương trình gốc theo nhu cầu người phát triển Hiển nhiên phần mềm biểu diễn mức trừu tượng cao chương trình xây dựng nhanh Mơ hình 4GT kỹ nghệ phần mềm tập trung vào khả xác định phần mềm máy mức độ gần với ngôn ngữ tự nhiên hay dùng ký pháp đem lại chức có ý nghĩa Hiện tại, môi trường phát triển phần mềm hỗ trợ cho khuôn cảnh 4GT bao gồm số hay tất công cụ sau:

1 ngôn ngữ phi thủ tục để truy vấn CSDL sinh báo cáo

3 thao tác liệu

4 tương tác xác định hình sinh chương trình

6 khả đồ họa mức cao khả làm trang tính khả tạo tài liệu

Mỗi công cụ tồn tại, cho vài lĩnh vực ứng dụng đặc thù Ví dụ: tính macro phần mềm bảng tính, sở liệu, khả tự sinh mã công cụ thiết kế giao diện “kéo - thả” Với ứng dụng nhỏ, chuyển trực tiếp từ bước thu thập yêu cầu sang cài đặt công cụ 4GT Tuy nhiên với hệ thống lớn, cần phải có chiến lược thiết kế Việc dùng 4GT thiếu thiết kế (với dự án lớn) gây khó khăn chất lượng kém, khó bảo trì khiến cho người dùng khó chấp nhận Vẫn cịn nhiều tranh cãi xung quanh việc dùng khuôn cảnh 4GT:

- Người ủng hộ cho 4GT làm giảm đáng kể thời gian phát triển phần mềm làm tăng nhiều hiệu suất người xây dựng phần mềm

không hiệu quả, việc bảo trì hệ thống phần mềm lớn phát triển cách dùng 4GT lại mở vấn đề

Có thể tóm tắt trạng cách tiếp cận 4GT sau:

1 Lĩnh vực ứng dụng cho 4GT giới hạn vào ứng dụng hệ thông tin nghiệp vụ, đặc biệt, việc phân tích thơng tin làm báo cáo nhân tố chủ chốt cho sở liệu lớn Tuy nhiên, xuất công cụ CASE hỗ trợ cho việc dùng 4GT để tự động sinh khung chương trình Đối với ứng dụng vừa nhỏ: thời gian cần cho việc tạo phần mềm

được giảm đáng kể khối lượng phân tích/thiết kế rút bớt

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

Tóm lại, 4GT trở thành phần quan trọng việc phát triển phần mềm nghiệp vụ sử dụng rộng rãi miền ứng dụng khác thời gian tới

1.3.6 Mơ hình lập trình cực đoan

Lập trình cực đoan (XP - eXtreme Programming) Kent Beck đề xuất phương pháp tiếp cận cho phát triển phần mềm XP đưa nhiều hướng dẫn mới, trái ngược lại với cách thức phát triển phần mềm đề xuất từ trước đến

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

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

Thông thường, thử nghiệm (và trước tạo ca thử nghiệm) tiến hành vào giai đoạn cuối trình phát triển, bạn có mã nguồn chuyển sang kiểm chứng tính đắn Nhiều trường hợp việc kiểm thử không coi trọng tiến hành bạn cịn thời gian kinh phí XP thay đổi quan niệm cách đặt cho kiểm thử tầm quan trọng ngang (có thể lớn hơn) việc viết mã Các ca kiểm thử thiết kế trước viết mã phải thực thành cơng chương trình đích tạo

phải hiểu rõ chức Tức là, XP yêu cầu bạn phải hiểu cách rõ ràng yêu cầu modun trước bạn bắt tay vào phát triển

b) Lập trình đơi

XP đưa 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) mã nguồn mơđun phải viết lập trình viên dùng chung máy tính Giá trị lập trình đơi người viết mã người thứ hai nghĩ Người thứ hai có đầu tranh toàn thể vấn đề cần giải quyết, không giải pháp đoạn mã lúc Điều gián tiếp đảm bảo chất lượng tốt dẫn tới giải pháp mang tính tổng thể Đồng thời, điều giúp cho họ theo dẫn XP, đặc biệt việc “tạo ca thử nghiệm trước” Nếu người lập trình, họ dễ từ bỏ việc này, với hai người lập trình làm việc họ thay đổi giữ nguyên tắc XP

1.3.7 Tổ hợp mơ hình

Chúng ta xem xét mơ hình kỹ nghệ phần mềm cách tiếp cận khác tới kỹ nghệ phần mềm cách tiếp cận bổ sung cho Tuy nhiên nhiều trường hợp nên tổ hợp khuôn cảnh để đạt sức mạnh khuôn cảnh cho dự án riêng lẻ Ví dụ, khn cảnh xoắn ốc thực điều cách trực tiếp, tổ hợp làm mẫu yếu tố vòng đời cổ điển cách tiếp cận tiến hóa tới kỹ nghệ phần mềm Các kỹ thuật hệ thứ tư dùng để cài đặt mẫu hay cài đặt hệ thống sản xuất bước mã hóa vịng đời cổ điển Chúng ta làm mẫu bước phân tích mơ hình vịng đời cổ điển

Kết luận không nên bị lệ thuộc với khn cảnh cụ thể Tính chất qui mô phần mềm cần phát triển yếu tố định tới chọn khuôn cảnh Mỗi cách tiếp cận có ưu điểm riêng cách tổ hợp khéo léo cách tiếp cận có phương pháp hỗn hợp ưu việt phương pháp dùng độc lập

1.3.8 Tính khả thị q trình kỹ nghệ

liệu như: báo cáo nghiên cứu khả thi, mơ hình hệ thống, phác họa u cầu, đặc tả yêu cầu

Chúng ta so sánh tính khả thị khn cảnh biết:

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

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

- 4GT dùng với ứng dụng nghiệp vụ đặc thù nên khó phát biểu tính khả thị

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

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

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

Các mơ hình phát triển truyền thống thường trọng tới khâu lập tài liệu để nâng cao tính khả thị Ngược lại, mơ hình lập trình cực đoan (XP) lại khơng khuyến khích việc tạo nhiều tài liệu

1.3.9 Vấn đề giảm kích cỡ phần mềm

Như biết, phần mềm lớn, phức tạp Một mặt, lực nhóm lập trình khơng phải tuyến tính so với lực cá nhân Độ phức tạp tăng theo cấp số nhân, kéo theo chi phí tăng theo cấp số nhân so với kích cỡ chương trình cần phát triển Do đó, việc tìm cách giảm kích cỡ, độ phức tạp chương trình ưu tiên hàng đầu kỹ nghệ phần mềm Tại bước phân tích thiết kế, giảm kích cỡ thực thông qua áp dụng chiến lược “chia để trị” Tức chia phần mềm thành modun có tính độc lập cao Độ phức tạp modun nhỏ nhiều so với hệ thống, modun phát triển song song Tại giai đoạn mã hóa, giảm kích cỡ thực thơng qua phương thức như:

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

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

- Dùng ngôn ngữ bậc cao (các ngơn ngữ có cấu trúc lực biểu diễn cao) Chúng ta xem xét ví dụ việc lựa chọn ngôn ngữ Việc chọn ngôn ngữ phụ thuộc nhiều vào miền ứng dụng, ràng buộc hiệu phần mềm, nhiên lực biểu diễn ngôn ngữ yếu tố quan trọng Bảng 1.1 đưa thống kê liên quan đến lực biểu diễn ngơn ngữ: số dịng lệnh/đơn vị chức VB khơng phải ngơn ngữ có cấu trúc cao sử dụng rộng rãi ứng dụng vừa nhỏ cho môi trường Windows Ngồi tính dễ học, dễ dùng, ngun nhân giúp VB lan rộng lực biểu diễn cao

Bảng 1.1: Năng lực biểu diễn ngôn ngữ

Ngôn ngữ LOC/FP

Assembly C FORTRAN 77

COBOL 85 Ada 83

C++ Ada 95

Java Visual Basic

320 128 105 91 71 56 55 55 35

1.4 Cái nhìn chung kỹ nghệ phần mềm

Tiến trình phát triển kỹ nghệ phần mềm chứa ba giai đoạn mơ hình kỹ nghệ phần mềm chọn lựa Ba giai đoạn xác định, phát triển bảo trì, gặp phải dự án phát triển phần mềm, tới miền ứng dụng, kích cỡ độ phức tạp

Yêu cầu chủ chốt hệ thống phần mềm xác định Mặc dầu phương pháp áp dụng giai đoạn xác định thay đổi tùy theo mơ hình kỹ nghệ phần mềm (hay tổ hợp mơ hình) áp dụng, có ba bước riêng xuất dạng:

1 Phân tích hệ thống: Phân tích hệ thống xác định vai trị phần tử hệ thống dựa máy tính, tức vạch vai trị mà phần mềm (cần phát triển) giữ

2 Lập kế hoạch dự án phần mềm: Một vai trò phần mềm thiết lập, rủi ro phân tích, tài nguyên cấp phát, chi phí ước lượng phải xác định cụ thể công việc cần thực lập lịch thực chúng

3 Phân tích yêu cầu: Trong bước phân tích hệ thống xác định vai trị chung phần mềm Sau thức đinh phát triển phần mềm, cần phải phân tích để xác định chi tiết lĩnh vực thông tin, chức ràng buộc vận hành phần mềm

Phân tích yêu cầu khâu kỹ thuật quan trọng để đảm bảo chất lượng (tính đáng tin cậy) phần mềm Nếu xác định sai yêu cầu bước kỹ thuật khác có tốt đến đâu phần mềm không đưa vào sử dụng

Giai đoạn phát triển tập trung vào khái niệm Tức là, giai đoạn người phát triển phần mềm bước xác định cách cấu trúc liệu kiến trúc phần mềm cần xây dựng, cách chi tiết thủ tục cài đặt, cách dịch thiết kế vào ngơn ngữ lập trình (hay ngơn ngữ phi thủ tục) cách thực kiểm thử Phương pháp áp dụng giai đoạn phát triển thay đổi tùy theo mơ hình có ba bước đặc thù xuất dạng:

1 Thiết kế phần mềm: Là trình “dịch” yêu cầu phần mềm thành tập biểu diễn (dựa đồ họa, bảng, hay ngôn ngữ), mô tả cho cấu trúc liệu, kiến trúc, thủ tục thuật toán đặc trưng giao diện

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

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

1 Sửa đổi: Cho dù có hoạt động bảo đảm chất lượng tốt nhất, khách hàng phát khiếm khuyết phần mềm Bảo trì sửa đổi làm thay đổi phần mềm để sửa khiếm khuyết (lỗi lập trình, thuật tốn, thiết kế )

2 Thích nghi: Qua thời gian, môi trường ban đầu (như CPU, hệ điều hành, ngoại vi) để phát triển phần mềm thay đổi Bảo trì thích nghi thực việc sửa đổi phần mềm để thích hợp với thay đổi mơi trường ngồi

3 Nâng cao: Khi phần mềm dùng, khách hàng/người dùng nhận chức phụ có lợi Bảo trì hoàn thiện mở rộng phần mềm yêu cầu chức gốc

Tổng kết: Phần mềm trở thành phần tử chủ chốt hệ thống máy tính Phát triển phần mềm tiến hóa từ xây dựng cơng cụ xử lý thơng tin thành ngành công nghiệp Phần mềm phần tử lơgíc việc kiểm sốt khó nhiều so với phần tử vật lý Khó tối ưu hóa đồng thời tính cần có phần mềm Ví dụ, tính giao diện đồ họa dễ sử dụng hoạt động hiệu quả, tích kiệm tài nguyên hệ thống hầu hết trường hợp loại trừ lẫn Thách thức lớn việc phát triển phần mềm phải xây dựng phần mềm tốt theo lịch trình kinh phí định trước

Chương

Phân tích đặc tả yêu cầu

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

Phân tích định rõ yêu cầu bước kỹ thuật tiến trình kỹ nghệ phần mềm Cơng việc bước tìm hiểu xem phải phát triển gì, khơng phải phát triển Đích cuối khâu phân tích tạo đặc tả yêu cầu, tài liệu ràng buộc khách hàng người phát triển sở hợp đồng

Hoạt động phân tích hoạt động phối hợp khách hàng người phân tích (bên phát triển) Khách hàng phát biểu yêu cầu người phân tích hiểu, cụ thể hóa biểu diễn lại yêu cầu Hoạt động phân tích giữ vai trò đặc biệt quan trọng phát triển phần mềm, giúp cho đảm bảo chất lượng phần mềm (phần mềm đáng tin cậy) Phần mềm đáng tin cậy có nghĩa phải thực xác, đầy đủ u cầu 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 việc sửa chữa trở nên tốn Chi phí để sửa chữa sai sót yêu cầu tăng lên gấp bội sai sót phát muộn, ví dụ bước thiết kế hay mã hóa

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

- Các yêu cầu thường mang tính đặc thù tổ chức đặt hàng nó, thường khó hiểu, khó định nghĩa 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 yêu cầu thường đa dạng có mức ưu tiên khác nhau, chí mâu thuẫn lẫn

- Người đặt hàng nhiều nhà quản lý, người dùng thực việc phát biểu u cầu thường khơng xác

Trong phân tích cần phân biệt yêu cầu mục tiêu hệ thống Yêu cầu địi hỏi mà kiểm tra mục tiêu trừu tượng mà hướng tới Ví dụ, giao diện hệ thống phải thân thiện với người sử dụng mục tiêu tương đối khơng khách quan khó kiểm tra Có nghĩa với phát biểu chung chung khách hàng nhà phát triển khó định ranh giới rõ ràng để nói phần mềm thỏa mãn địi hỏi Với mục tiêu vậy, yêu cầu cho nhà phát triển giao diện đồ họa mà lệnh phải chọn menu

cơ sở cho hợp đồng người phát triển dựa vào để xây dựng phần mềm Do u cầu thường mơ tả nhiều mức chi tiết khác phục vụ cho đối tượng đọc khác Các mức là:

• Định nghĩa (xác định) u cầu: mô tả cách dễ hiểu, vắn tắt yêu cầu, hướng vào đối tượng người đọc người sử dụng, người quản lý

• Đặc tả yêu cầu: mô tả chi tiết yêu cầu, ràng buộc hệ thống, phải xác cho người đọc không hiểu nhầm yêu cầu, hướng vào đối tượng người đọ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ì)

Các tài liệu yêu cầu cần thẩm định để đảm bảo thỏa mãn nhu cầu người dùng Đây công việc bắt buộc để đảm bảo chất lượng phần mềm Đôi việc xác định đầy đủ yêu cầu trước phát triển hệ thống khơng thực tế việc xây dựng mẫu để nắm bắt yêu cầu cần thiết

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

2.2 Nghiên cứu khả thi

Đây giai đoạn có tầm quan trọng đặc biệt, liên quan đến việc lựa chọn giải pháp Trong giai đoạn người phân tích phải làm rõ điểm mạnh điểm yếu hệ thống cũ, đánh giá mức độ, tầm quan trọng vấn đề, định vấn đề cần phải giải (ví dụ: dịch vụ mới, thời hạn đáp ứng, hiệu kinh tế) Sau người phân tích phải định vài giải pháp (sơ bộ)

Báo cáo khả thi

Mơ hình

hệ thống Tài liệu định nghĩa yêu cầu

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

cứu khả thi

Phân tích yêu

cầu

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

Đặc tả yêu cầu

và so sánh cân nhắc điểm tốt không tốt giải pháp (như tính hệ thống, giá cài đặt, bảo trì, việc đào tạo người sử dụng ) Đó việc tìm điểm cân nhu cầu khả đáp ứng Mọi dự án khả thi nguồn tài nguyên vô hạn 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 hạn hẹp tài ngun khó (nếu khơng phải không thực) bảo đảm ngày bàn giao Phân tích khả thi rủi ro có liên quan với theo nhiều cách Nếu rủi ro dự án lớn tính khả thi việc chế tạo phần mềm có chất lượng bị giảm Trong giai đoạn nghiên cứu khả thi, tập trung vào bốn lĩnh vực quan tâm chính:

1 Khả thi 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 xây dựng đem lại Tính khả thi kinh tế thể nội dung sau:

- Khả tài tổ chức cho phép thực dự án

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

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

Một thuật ngữ hay dùng để tài liệu nghiên cứu khả thi kinh tế luận chứng kinh tế Luận chứng kinh tế nói chung coi tảng cho hầu hết hệ thống (các ngoại lệ hệ thống quốc phòng, hệ thống luật, hệ thống phục vụ cho nghiên cứu đặc biệt) Luận chứng kinh tế bao gồm:

- mối quan tâm, phân tích chi phí/lợi ích - chiến lược phát triển dài hạn công ty

- ảnh hưởng tới 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 phát triển thị trường tiềm

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

Rủi ro xây dựng: liệu phần tử hệ thống thiết kế cho đạt chức hiệu suất cần thiết thỏa mãn ràng buộc phân tích khơng?

Có sẵn tài nguyên: có sẵn nhân viên cho việc xây dựng phần tử hệ thống xét không? Các tài nguyên cần thiết khác (phần cứng 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 pháp lý: nghiên cứu đưa phán có hay khơng 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ận hành hệ thống Tính khả thi pháp lý bao gồm phạm vi rộng mối quan tâm kể hợp đồng, nghĩa vụ pháp lý, vi phạm vô số bẫy pháp lý khác mà thường nhân viên kỹ thuật tới Trong nước, vấn đề khả thi pháp lý chưa coi trọng cách mức có số luật liên quan đến CNTT bảo hộ quyền

4 Tính khả thi hoạt động: đánh giá tính khả thi việc vận hành hệ thống Trong phương án người ta cần xem xét hệ thống vận hành trơi chảy hay khơng khn khổ tổ chức điều kiện quản lý mà tổ chức (người dùng, khách hàng) có Mức độ phương án xem xét tới nghiên cứu khả thi thường bị giới hạn ràng buộc chi phí thời gian

2.3 Nền tảng phân tích yêu cầu

2.3.1 Các nguyên lý phân tích

Trên hai thập kỉ qua, người ta xây dựng số phương pháp phân tích đặc tả phần mềm Những người nghiên cứu xác định vấn đề nguyên nhân chúng, xây dựng qui tắc thủ tục để vượt qua chúng Mỗi phương pháp có kí pháp quan điểm riêng Tuy nhiên, tất phương pháp có quan hệ với tập hợp nguyên lý bản:

1 Miền thông tin vấn đề phải biểu diễn lại hiểu rõ

2 Các mơ hình mô tả cho thông tin, chức hành vi hệ thống cần phải xây dựng

4 Tiến trình phân tích phải từ thơng tin chất hướng tới chi tiết cài đặt Bằng cách áp dụng nguyên lý này, người phân tích tiếp cận tới vấn đề cách hệ thống

Miền thông tin cần xem xét cho người ta hiểu rõ chức cách đầy đủ Các mơ hình dùng việc trao đổi thông tin dễ dàng theo cách ngắn gọn Việc phân hoạch vấn đề sử dụng để làm giảm độ phức tạp Những cách nhìn nhận từ góc độ chất góc độ cài đặt phần mềm cần thiết để bao hàm ràng buộc logic yêu cầu xử lý áp đặt nên ràng buộc vật lý phần tử hệ thống khác áp đặt nên

2.3.2 Mơ hình hóa

Chúng ta tạo mơ hình để thu hiểu biết rõ thực thể thực tế cần xây dựng Khi thực thể vật vật lý (như nhà, máy bay, máy móc) ta xây dựng mơ hình giống hệt hình dạng, nhỏ qui mô Tuy nhiên, thực thể cần xây dựng phần mềm, mơ hình phải mang dạng khác Nó phải có khả mơ hình hóa thơng tin mà phần mềm biến đổi, chức (và chức con) làm cho phép biến đổi thực được, hành vi hệ thống phép biến đổi xảy

Trong phân tích yêu cầu phần mềm, tạo mơ hình 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 ý đến cách thức thực Trong nhiều trường hợp, mơ hình tạo có dùng kí pháp đồ hoạ mơ tả cho thông tin, xử lý, hành vi hệ thống, đặc trưng khác thông qua biểu tượng phân biệt dễ nhận diện Những phần khác mơ hình túy văn Thơng tin mơ tả cung cấp cách dùng ngơn ngữ tự nhiên hay ngôn ngữ chuyên dụng cho mơ tả u cầu Các mơ hình tạo phân tích u cầu cịn đóng số vai trị quan trọng:

• Mơ hình trợ giúp cho người phân tích việc hiểu thơng tin, chức hành vi hệ thống, làm cho nhiệm vụ phân tích yêu cầu dễ dàng hệ thống

• Mơ hình trở thành tiêu điểm cho việc xem xét đó, trở thành phần mấu chốt cho việc xác định tính đầy đủ, quán xác đặc tả

• Mơ hình trở thành tảng cho thiết kế, cung cấp cho người thiết kế cách biểu diễn chủ yếu phần mềm “ánh xạ” vào hoàn cảnh cài đặt

1 Biểu đồ luồng liệu

Khi thông tin qua phần mềm bị thay đổi loạt phép biến đổi Biểu đồ luồng liệu (Data Flow Diagram - DFD) kỹ thuật vẽ luồng liệu di chuyển hệ thống phép biến đổi áp dụng lên liệu Ký pháp biểu đồ luồng liệu minh họa hình 2.2

Hình 2.2: Ký pháp DFD

Biểu đồ luồng liệu dùng để biểu diễn cho hệ thống hay phần mềm mức trừu tượng Trong thực tế, DFD phân hoạch thành nhiều mức biểu diễn cho chi tiết chức luồng thơng tin ngày tăng Do phương pháp dùng DFD cịn gọi phân tích có cấu trúc Một DFD mức 0, gọi biểu đồ tảng hay biẻu đồ ngữ cảnh hệ thống, biểu diễn cho toàn phần tử phần mềm hình trịn với liệu vào ra mũi tên tới tương ứng Một DFD mức cụ thể hóa DFD mức chứa nhiều hình trịn (chức năng) với mũi tên (luồng liệu) nối lẫn Mỗi tiến trình biểu diễn mức chức tồn hệ thống mơ tả biểu đồ ngữ cảnh Hình 2.3 minh họa DFD cho hệ thống bán vé tầu

Tác nhân

Tiến trình

Kho liệu

Hình 2.3: Biểu đồ luồng liệu hệ thống bán vé tầu

2 Biểu đồ thực thể quan hệ

Ký pháp tảng cho mơ hình hóa liệu biểu đồ thực thể quan hệ (Entity -Relation Diagram) Tất xác định tập thành phần chủ yếu cho biểu đồ EưR: thực thể, thuộc tính, quan hệ nhiều báo kiểu khác Mục đích biểu đồ EưR biểu diễn liệu mối quan hệ liệu (thực thể)

Ký pháp biểu đồ EưR tương đối đơn giản Các thực thể biểu diễn hình chữ nhật có nhãn Mối quan hệ hình thoi Các mối nối vật liệu mối quan hệ thiết lập cách dùng nhiều đường nối đặc biệt (hình 2.4)

Khách hàng Hệ thống

bán vé Đặt vé

Vé

DFD mức 0

Khách hàng

Phân tích đơn đặt

vé

Kiểm tra tàu Bảng tàu

Đặt chỗ Phát hành vé

Chỗ đẵ đặt Bảng giá vé

Khách hàng

Hình 2.4: Mơ hình thực thể quan hệ người - phương tiện giao thông

2.3.3 Người phân tích

Người phân tích đóng vai trị đặc biệt quan trọng tiến trình phân tích Ngồi kinh nghiệm, người phân tích tốt cần có khả sau:

- Khả hiểu thấu khái niệm trừu tượng, có khả tổ chức lại thành phân tích logic tổng hợp giải pháp dựa dải phân chia - Khả rút kiện thích đáng từ nguồn xung khắc lẫn lộn - Khả hiểu môi trường người dùng/khách hàng

- Khả áp dụng phần tử hệ thống phần cứng và/hoặc phần mềm vào môi trường người sử dụng/khách hàng

- Khả giao tiếp tốt dạng viết nói

- Khả trừu tượng hóa/tổng hợp vấn đề từ kiện riêng lẻ

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

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

Xác định yêu cầu mô tả trừu tượng dịch vụ mà hệ thống cần cung cấp ràng buộc mà hệ thống cần tuân thủ vận hành Nó mơ tả hành vi bên ngồi hệ thống mà không liên quan tới chi tiết thiết kế Yêu cầu nên viết cho hiểu mà không cần kiến thức chuyên môn đặc biệt

Thực thể

Quan hệ

Thuộc tính

Kế thừa

Người Biển

đăng ký Phương tiện

giao thông

Xe máy C

Các yêu cầu chia thành hai loại:

1) Các yêu cầu chức năng: dịch vụ mà hệ thống cần cung cấp 2) Các yêu cầu phi chức năng: ràng buộc mà hệ thống cần tuân thủ Các yêu cầu phi chức chia làm kiểu:

i) Yêu cầu sản phẩm: yêu cầu tốc độ, nhớ, độ tin cậy, tính khả chuyển tái sử dụng

ii) Yêu cầu trình: yêu cầu trình xây dựng sản phẩm chuẩn phải tuân theo, phương pháp thiết kế, ngôn ngữ lập trình

iii) Yêu cầu khác: u cầu khơng thuộc hai nhóm tính pháp lý, chi phí, thành viên nhóm phát triển

Các yêu cầu phi chức thường đặc thù với khách hàng khó phân tích đặc tả cách đầy đủ xác

Về nguyên tắc, yêu cầu hệ thống phải vừa đầy đủ vừa không mâu thuẫn Đối với hệ thống lớn phức tạp khó đạt hai yếu tố bước phân tích đầu Trong 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

2.4.2 Đặc tả yêu cầu

Tài liệu xác định yêu cầu mô tả hướng khách hàng viết ngôn ngữ khách hàng Khi dùng ngơn ngữ tự nhiên 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) mô tả hướng người phát triển, sở hợp đồng làm phần mềm Nó khơng phép mơ hồ, không dẫn đến hiểu nhầm khách hàng người phát triển Với yêu cầu mơ hồ người phát triển thực cách rẻ cịn khách hàng khơng muốn Do khách hàng địi hỏi sửa đổi chức phần mềm gần hồn thiện khiến cho chi phí tăng chậm thời điểm bàn giao Chi phí cho sửa sai sót phát biểu yêu cầu lớn, đặc biệt sai sót phát bắt đầu xây dựng hệ thống Theo số thống kê 85% mã phải viết lại thay đổi yêu cầu 12% lỗi phát năm đầu sử dụng đặc tả u cầu khơng xác Do đó, việc đặc tả xác u cầu mối quan tâm đặt lên hàng đầu Có hai phương pháp đặc tả

1 Đặc tả phi hình thức: cách đặc tả ngơn ngữ tự nhiên

Đặc tả phi hình thức (ngôn ngữ tự nhiên) thuận tiện cho việc xác định u cầu nhiều khơng thích hợp với đặc tả u cầu vì:

i) Khơng phải lúc người đọc người viết đặc tả ngôn ngữ tự nhiên hiều từ

ii) Ngơn ngữ tự nhiên q mềm dẻo yêu cầu liên quan đến biểu diễn hình thức hồn tồn khác người phát triển không nhận mối liên quan

iii) Các yêu cầu khó phân hoạch cách hữu hiệu hiệu việc đổi thay xác định cách kiểm tra tất yêu cầu nhóm u cầu liên quan

Các ngơn ngữ đặc tả (đặc tả hình thức) khắc phục hạn chế trên, nhiên đa số khách hàng lại không thông thạo ngôn ngữ Thêm ngơn ngữ đặc tả hình thức thường phục vụ cho nhóm lĩnh vực riêng biệt việc đặc tả hình thức cơng việc tốn thời gian

Một cách tiếp cận bên cạnh đặc tả hình thức người ta viết giải ngôn ngữ tự nhiên để giúp khách hành dễ hiểu

2.4.3 Thẩm định yêu cầu

Một yêu cầu thiết lập cần thẩm định xem chúng có thỏa mãn nhu cầu khách hàng hay không Nếu thẩm định không tiến hành chặt chẽ sai sót lan truyền sang giai đoạn thiết kế mã hóa khiến cho việc sửa đổi hệ thống trở nên tốn Mục tiêu thẩm định kiểm tra xem yêu cầu mà người phân tích xác định có thỏa mãn yếu tố sau khơng:

1 Thỏa mãn nhu cầu người dùng: cần phải thỏa mãn nhu cầu chất người dùng (khách hàng)

2 Các yêu cầu không mâu thuẫn nhau: với hệ thống lớn yêu cầu đa dạng có khả mâu thn Khi người phân tích phải loại bớt yêu cầu (không chủ chốt) để sau cho yêu cầu mô tả tài liệu yêu cầu không mâu thuẫn

3 Các yêu cầu phải đầy đủ: cần chứa chức ràng buộc mà người dùng nhắm đến

2.5 Làm mẫu q trình phân tích

Đối với hệ thống phức tạp, nhiều không nắm yêu cầu khách hàng, khó đánh giá tính khả thi hiệu hệ thống Một cách tiếp cận trường hợp xây dựng mẫu Bản mẫu vừa dùng để phân tích yêu cầu vừa tiến hóa thành sản phẩm cuối Bản mẫu phần mềm hoàn toàn khác với mẫu phần cứng Khi phát triển hệ thống phần cứng, thực tế người ta phát triển mẫu hệ thống để thẩm định thiết kế hệ thống Một mẫu hệ thống điện tử thực thử nghiệm cách dùng thành phần chưa lắp ráp vào vỏ trước đầu tư vào mạch tích hợp chuyên dụng đắt tiền để thực đời sản phẩm hệ thống Bản mẫu phần mềm nhằm vào việc thẩm định thiết kế (thiết kế thường hoàn toàn khác với hệ thống phát triển cuối cùng), mà để thẩm định yêu cầu người sử dụng

2.5.1 Các bước làm mẫu

Xây dựng mẫu bao gồm bước sau:

Bước 1: Đánh giá yêu cầu phần mềm xác định liệu phần mềm cần xây dựng có xứng đáng để làm mẫu khơng Khơng phải tất phần mềm đưa tới làm mẫu Ta xác định số nhân tố làm mẫu: lĩnh vực ứng dụng, độ phức tạp ứng dụng, đặc trưng khách hàng đặc trưng dự án Để đảm bảo tính tương tác khách hàng với mẫu, cần đảm bảo điều kiện:

1 Khách hàng phải cam kết dùng tài nguyên để đánh giá làm mịn mẫu (chi tiết hóa yêu cầu)

2 Khách hàng phải có khả đưa định yêu cầu cách kịp thời

Bước 2: Với dự án chấp thuận được, người phân tích xây dựng cách biểu diễn vắn tắt cho yêu cầu Trước bắt đầu xây dựng mẫu, người phân tích phải biểu diễn miền thơng tin lĩnh vực, hành vi chức vấn đề xây dựng cách tiếp cận hợp lý tới việc phân hoạch Có thể ứng dụng nguyên lý phân tích tảng (phân tích topưdown) phương pháp phân tích yêu cầu

dữ liệu kiến trúc mức đỉnh không tập trung vào thiết kế thủ tục chi tiết

Bước 4: Phần mềm mẫu tạo ra, kiểm thử làm mịn Bản mẫu nên xây dựng cách nhanh chóng với chi phí nhỏ Một cách lý tưởng, mẫu nên lắp ráp từ khối chức (thư viện ) có Có thể dùng ngơn ngữ bậc cao hay công cụ tự động để xây dựng mẫu

Bước 5: Khách hàng đánh giá làm mịn yêu cầu Bước cốt lõi cách tiếp cận làm mẫu Chính mà khách hàng xem xét cách biểu diễn cài đặt cho yêu cầu phần mềm, gợi ý thay đổi làm cho phần mềm đáp ứng tốt với nhu cầu thực tế

Bước 6: Lặp lại bước tất yêu cầu hình thức hóa đầy đủ hay mẫu tiến hóa thành phần mềm hồn thiện 2.5.2 Lợi ích hạn chế phát triển mẫu Phát triển mẫu đem lại lợi ích sau:

1 Sự hiểu lầm người phát triển phần mềm người sử dụng phần mềm nhận thấy rõ chức hệ thống trình diễn

2 Sự thiếu hụt dịch vụ người dùng phát Sự khó sử dụng nhầm lẫn dịch vụ người dùng có

thể thấy rõ sửa lại

4 Đội ngũ phát triển phần mềm tìm đựơc yêu cầu không đầy đủ không kiên định họ phát triển mẫu Một hệ thống hoạt động (mặc dầu hạn chế)

chứng thuyết minh cho tính khả thi tính hữu ích ứng dụng cho nhà quản lý

6 Bản mẫu dùng làm sở cho việc viết đặc tả sản phẩm

Mặc dù mục tiêu chủ yếu việc tạo mẫu để phát triển, thẩm định yêu cầu phần mềm, có lợi ích khác như:

2 Dùng trình thử nghiệm hệ thống Điều nghĩa trường hợp thử vừa dùng cho thử mẫu vừa cho thử hệ thống Kết khác có nghĩa có sai sót

Tạo mẫu kỹ thuật giảm bớt rủi ro Một rủi ro lớn việc phát triển phần mềm sai sót mà đến giai đoạn cuối phát việc chỉnh sửa vào thời điểm tốn Kinh nghiệm cho thấy việc tạo mẫu giảm bớt số vấn đề đặc tả yêu cầu giá tổng cộng việc phát triển thấp ta phát triển mẫu Hạn chế cách tiếp cận tạo mẫu là:

1 Để đơn giản hóa việc tạo mẫu người ta bỏ qua yêu cầu phức tạp Sự thật tạo mẫu vài phần quan trọng hệ thống đặc điểm an toàn - nguy kịch

2 Các yêu cầu phi chức độ tin cậy, độ an toàn hay hiệu thường không biểu thị đầy đủ mẫu

3 Do tính chưa hồn thiện chức năng/hiệu năng, người dùng khơng dùng mẫu y cách dùng hệ thống thực hoạt động Do đó, chất lượng đánh giá khách hàng nhiều không cao

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

Kết bước phân tích tạo đặc tả yêu cầu phần mềm (Software Requirement Specification - SRS) Đặc tả yêu cầu phải rõ phạm vi sản phẩm, chức cần có, đối tượng người sử dụng ràng buộc vận hành sản phẩm Có nhiều chuẩn khác xây dựng tài liệu, đị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 giới thiệu mục đích tài liệu yêu cầu Thường đơn giản định nghĩa “đây tài liệu yêu cầu phần mềm XYZ”

1.2 Phạm vi

Nêu pham vi đề cập tài liệu yêu cầu

1.3 Định nghĩa

Định nghĩa khái niệm, từ viết tắt, chuẩn sử dụng tài liệu yêu cầu

1.4 Tài liệu tham khảo

Nêu danh mục tài liệu tham khảo dùng để tạo đặc tả yêu cầu

1.5 Mô tả chung tài liệu

Mô tả khái quát cấu trúc tài liệu, gồm có chương, mục, phục lục

2.1 Tổng quan sản phẩm

Mô tả khái quát sản phẩm

2.2 Chức sản phẩm

Khái quát chức sản phẩm

2.3 Đối tượng người dùng

Mô tả đối tượng người dùng

2.4 Ràng buộc tổng thể

Khái quát ràng buộc 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 hệ thống khác

2.5 Giả thiết lệ thuộc

Mô tả giả thiết áp dụng tài liệu: ví dụ 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ả yêu cầu

3.1 Yêu cầu chức

Mô tả chi tiết yêu cầu chức

3.1.1 Yêu cầu chức 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

3.1.2 Yêu cầu chức

3.1.n Yêu cầu chức n

3.2 Yêu cầu giao diện

Mô tả giao diện phần mềm với mơi trường bên ngồ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ả hiệu suất, ví dụ thời gian phản hồi với kiện, số giao dịch thực hiện/giây,

3.4 Ràng buộc thiết kế

Mô tả ràng buộc thiết kế, ví dụ ràng buộc ngôn ngữ, công nghệ, sở liệu chuẩn giao tiếp

3.5 Thuộc tính

Mơ tả thuộc tính phần mềm

3.5.1 Tính bảo mật, an tồn khả phục hồi

hệ thống sau gặp 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

Chương

Thiết kế phần mềm

3.1 Khái niệm thiết kế phần mềm

3.1.1 Khái niệm

Có thể định nghĩa thiết kế trình áp dụng nhiều kỹ thuật nguyên lý để tạo mơ hình thiết bị, tiến trình hay hệ thống đủ chi tiết mà theo chế tạo sản phẩm vật lý tương ứng với

Bản chất thiết kế phần mềm q trình chuyển hóa u cầu phần mềm thành biểu diễn thiết kế Từ mô tả quan niệm toàn phần mềm, việc làm mịn (chi tiết hóa) liên tục dẫn tới biểu diễn thiết kế gần với cách biểu diễn chương trình nguồn để ánh xạ vào ngơn ngữ lập trình cụ thể

Mục tiêu thiết kế để tạo mơ hình biểu diễn thực thể mà sau xây dựng

Mơ hình chung thiết kế phần mềm đồ thị có hướng, nút biểu diễn thực thể có thiết kế, liên kết biểu diễn quan hệ thực thể Hoạt động thiết kế loại hoạt động đặc biệt:

- Là trình sáng tạo, địi hỏi có kinh nghiệm nhanh nhạy sáng tạo

- Cần phải thực hành học kinh nghiệm, khảo sát hệ tồn tại, học sách không đủ

3.1.2 Tầm quan trọng

Hình 3.1: Vai trị thiết kế phần mềm trình kỹ nghệ

3.1.3 Quá trình thiết kế

Thiết kế phần mềm trình chuyển đặc tả yêu cầu dịch vụ thông tin hệ thống thành đặc tả hệ thống phần mềm Thiết kế phần mềm trải qua số giai đoạn sau:

1 Nghiên cứu để hiểu vấn đề. Khơng hiểu rõ vấn đề khơng thể có thiết kế hữu hiệu

2 Chọn (hay số) giải pháp thiết kế xác định đặc điểm thơ nó.

Chọn giải pháp phụ thuộc vào kinh nghiệm người thiết kế, vào cấu kiện dùng lại vào đơn giản giải pháp kéo theo Nếu nhân tố khác tương tự nên chọn giải pháp đơn giản

3 Mô tả trừu tượng cho nội dung giải pháp. Trước tạo tư liệu thức người thiết kế cần phải xây dựng mô tả ban đầu sơ khai chi tiết hóa Các sai sót khiếm khuyết mức thiết kế trước phát phải chỉnh sửa trước lập tư liệu thiết kế

Kết hoạt động thiết kế đặc tả thiết kế Đặc tả đặc tả trừu tượng, hình thức tạo để làm rõ yêu cầu, đặc tả phần hệ thống phải thực Khi trình thiết kế tiến triển chi tiết bổ sung vào đặc tả Các kết cuối

Thiết kế

Lập trình Mơ hình

thơng tin Mơ hình

cấu trúc

Các yêu cầu khác

Thiết kế kiến trúc Cấu trúc liệu

Thiết kế

thuật toán Mô đun

cùng đặc tả thuật toán cấu trúc liệu dùng làm sở cho việc thực hệ thống Các hoạt động thiết kế hệ thống phần mềm lớn:

Các nội dung thiết kế là:

- Thiết kế kiến trúc: Xác định hệ tổng thể phần mềm bao gồm hệ quan hệ chúng ghi thành tài liệu

- Đặc tả trừu tượng: đặc tả trừu tượng cho hệ dịch vụ mà cung cấp ràng buộc chúng phải tuân thủ

- Thiết kế giao diện: giao diện hệ với hệ khác thiết kế ghi thành tài liệu; đặc tả giao diện không mơ hồ cho phép sử dụng hệ mà khơng cần biết thiết kế nội

- Thiết kế thành phần: dịch vụ mà hệ cung cấp phân chia cho thành phần hợp thành

- Thiết kế cấu trúc liệu: thiết kế chi tiết đặc tả cấu trúc liệu (các mơ hình giới thực cần xử lý) dùng việc thực hệ thống - Thiết kế thuật toán: thuật toán dùng cho dịch vụ thiết kế chi

tiết đặc tả

Quá trình lặp lại thành phần hợp thành hệ xác định ánh xạ trực tiếp vào thành phần ngơn ngữ lập trình, chẳng hạn gói, thủ tục hàm

3.1.4 Cơ sở thiết kế

Chúng ta nên mơ đun hóa cần phải trì chi phí vùng lân cận chi phí tối thiểu Mơđun hóa cịn chưa đủ hay q mức nên tránh Một gợi ý cho kích cỡ mơđun sở môđun đảm nhận chức

Hình 3.2: Tính mơđun chi phí phần mềm

3.1.5 Mô tả thiết kế

Một thiết kế phần mềm mơ hình mơ tả đối tượng giới thực có nhiều thành phần mối quan hệ chúng với Việc mô tả thiết kế cần đảm bảo thực yêu cầu:

- Làm sở cho việc triển khai chương trình

- Làm phương tiện giao tiếp nhóm thiết kế hệ - Cung cấp đủ thông tin cho người bảo trì hệ thống

Thiết kế thường mơ tả hai mức: thiết kế mức cao (high level design) thiết kế chi tiết (low level design) Thiết kế mức cao hay thiết kế kiến trúc ra:

- Mơ hình tổng thể hệ thống

Số mô đun

C

hi

p

hí

- Cách thức hệ thống phân rã thành môđun - Mối quan hệ (gọi nhau) môđun

- Cách thức trao đổi thông tin môđun (giao diện, liệu dùng chung,

các thông tin trạng thái)

Tuy nhiên thiết kế mức cao không thứ tự thực hiện, số lần thực môđun, trạng thái hoạt động bên môđun

Nội dung môđun thể mức thiết kế chi tiết Các cấu trúc sở thiết kế chi tiết hay cịn gọi thiết kế thuật tốn là:

- Cấu trúc - Cấu trúc rẽ nhánh - Cấu trúc lặp

Mọi thuật tốn mơ tả dựa cấu trúc Có ba loại hình mơ tả thường sử dụng thiết kế:

- Dạng văn phi hình thức: Mơ tả ngôn ngữ tự nhiên thông tin hình thức hóa thơng tin phi chức Bên cạnh cách mô tả khác, mô tả văn thường bổ sung để làm cho thiết kế đầy đủ dễ hiểu

- Các biểu đồ: Các biểu đồ dùng để thể mối quan hệ thành phần lập lên hệ thống mơ hình mơ tả giới thực Việc mô tả đồ thị thiết kế có lợi tính trực quan cho tranh tổng thể hệ thống Trong thời gian gần đây, người ta xây dựng ngôn ngữ đồ thị dành riêng cho thiết kế phần mềm với tên gọi: ngôn ngữ mô hình hóa thống (Unified Modeling Model - UML) Tại mức thiết kế chi tiết, có số dạng biểu đồ hay sử dụng flow chart, JSP, NassiưShneiderman diagrams

- Giả mã (pseudo code): Hiện nay, giả mã công cụ ưa chuộng để mô tả thiết kế mức chi tiết Các ngôn ngữ thuận tiện cho việc mơ tả xác thiết kế, nhiên lại thiếu tính trực quan Dưới ví dụ sử dụng giả mã:

Procedure Write Name if sex = male

write "Mr." else

endif write name end Procedure

Nói chung ba loại biểu diễn sử dụng thiết kế hệ thống Thiết kế kiến trúc thường mô tả đồ thị (structure chart)và bổ sung văn phi hình thức, thiết kế liệu lôgic thường mô tả bảng, thiết kế giao diện, thiết kế cấu trúc liệu chi tiết, thiết kế thuật toán thường mô tả pseudo code

3.1.6 Chất lượng thiết kế

Khơng có cách hay để xác định thiết kế tốt Tiêu chuẩn dễ bảo trì tiêu chuẩn tốt cho người dùng Một thiết kế dễ bảo trì thích nghi với việc cải biên chức việc thêm chức Một thiết kế phải dễ hiểu việc sửa đổi có hiệu ứng cục Các thành phần thiết kế phải kết dính (cohesive) theo nghĩa tất phận thành phần phải có quan hệ logic chặt chẽ, thành phần ghép nối (coupling) với lỏng lẻo Ghép nối lỏng lẻo dễ thích nghi, nghĩa dễ sửa đổi để phù hợp với hoàn cảnh

Để xem thiết kế có tốt hay khơng, người ta tiến hành thiết lập số độ đo chất lượng thiết kế:

1) Sự kết dính (Cohesion) :Sự kết dính mơđun độ đo tính khớp lại với phần mơđun Nếu môđun thực chức logic thực thể logic, tức tất phận mơđun tham gia vào việc thực cơng việc độ kết dính cao Nếu nhiều phận không tham gia trực tiếp vào việc chức logic mức độ kết dính thấp Thiết kế tốt độ kết dính cao Khi dễ dàng hiểu môđun việc sửa chữa mơđun khơng (ít) ảnh hưởng tới mơđun khác Constantine Yourdon định mức kết dính theo thứ tự tăng dần sau đây:

a Kết dính gom góp: cơng việc khơng liên quan với nhau, song lại bị bó vào mơđun

b Kết dính logic: thành phần thực chức tương tự logic chẳng hạn vào/ra, xử lý lỗi, đặt vào mô đun

d Kết dính thủ tục: phần tử môđun ghép lại dãy điều khiển

e Kết dính truyền thơng: tất phần tử môđun thao tác liệu vào đưa liệu

f Kết dính tuần tự: môđun, đầu phần tử đầu vào phần tử khác

g Kết dính chức năng: Mỗi phần môđun cần thiết để thi hành chức Các lớp kết dính khơng định nghĩa chặt chẽ luôn xác định Một đối tượng kết dính thể thực thể đơn: tất phép tốn thực thể nằm thực thể Vậy xác định lớp kết dính là:

h Kết dính đối tượng: phép tốn liên quan đến thay đổi, kiểm tra sử dụng thuộc tính đối tượng, sở cung cấp dịch vụ đối tượng

2) Sự ghép nối (Coupling):Ghép nối độ đo nối ghép với đơn vị (mơđun) hệ thống Hệ thống có nối ghép cao mơđun phụ thuộc lẫn lớn Hệ thống nối ghép lỏng lẻo mơđun độc lập tương đối độc lập với dễ bảo trì Các mô đun ghép nối chặt chẽ chúng dùng biến chung chúng trao đổi thông tin điều khiển (ghép nối chung ghép nối điều khiển) Ghép nối lỏng lẻo đạt bảo đảm thông tin cục che dấu môđun 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 mức từ chặt chẽ đến lỏng lẻo sau:

a Ghép nối nội dung: hai hay nhiều môđun dùng lẫn liệu nhau, mức xấu nhất, thường xẩy ngôn ngữ mức thấp dùng liệu toàn cục hay lạm dụng lệnh GOTO

b Ghép nối chung: số môđun dùng biến chung, xẩy lỗi thao tác liệu, khó xác định lỗi mơđun gây

c Ghép nối điều khiển: môđun truyền thông tin điều khiển để điều khiển hoạt động môđun khác

e Ghép nối liệu: Các môđun trao đổi thông tin thông qua tham số giá trị trả lại

f Ghép nối khơng có trao đổi thơng tin: mơđun thực chức độc lập hồn tồn khơng nhận tham số khơng có giá trị trả lại Ưu việt thiết kế hướng đối tượng chất che dấu thông tin đối tượng dẫn tới việc tạo hệ ghép nối lỏng lẻo Việc thừa kế hệ thống hướng đối tượng lại dẫn tới dạng khác ghép nối, ghép nối đối tượng mức cao đối tượng kế thừa

3) Sự hiểu (Understandability): Sự hiểu thiết kế liên quan tới số đặc trưng sau đây:

a Tính kết dính: hiểu thành phần mà khơng cần tham khảo tới thành phần khác hay không?

b Đặt tên: phải tên dùng thành phần có nghĩa? Tên có nghĩa tên phản ánh tên thực thể giới thực mơ hình thành phần

c Soạn tư liệu: Thành phần có soạn thảo tư liệu cho ánh xạ thực thể giới thực thành phần rõ ràng

d Độ phức tạp: độ phức tạp thuật tốn dùng để thực thành phần nào? Độ phức tạp cao ám nhiều quan hệ thành phần khác thành phần thiết kế cấu trúc logic phức tạp mà dính líu đến độ sâu lồng cấu trúc ifưthenưelsse Các thành phần phức tạp khó hiểu, người thiết kế nên làm cho thiết kế thành phần đơn giản tốt Đa số công việc đo chất lượng thiết kế tập trung vào cố gắng đo độ phức tạp thành phần từ thu vài độ đo dễ hiểu thành phần Độ phức tạp phản ánh độ dễ hiểu, có số nhân tố khác ảnh hưởng đến độ dễ hiểu, chẳng hạn tổ chức liệu kiểu cách mô tả thiết kế Các số đo độ phức tạp cung cấp số cho độ dễ hiểu thành phần

Để có độ thích nghi hệ thống cịn cần phải phải tự chứa Muốn tự chứa cách hoàn tồn hệ thống khơng nên dùng thành phần khá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 thành phần có nên dùng lại Vậy cần có cân tính ưu việt dùng lại thành phần mát tính thích nghi hệ thống Một ưu việt kế thừa thiết kế hướng đối tượng thành phần sẵn sàng thích nghi Cơ cấu thích nghi không dựa việc cải biên thành phần có mà dựa việc tạo thành phần thừa kế thuộc tính chức thành phần Chúng ta cần thêm thuộc tính chức cần thiết cho thành phần Các thành phần khác dựa thành phần khơng bị ảnh hưởng

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

3.2.1 Cách tiếp cận hướng chức

Thiết kế hướng chức cách tiếp cận thiết kế phần mềm thiết kế phân giải thành đơn thể tác động lẫn nhau, mà đơn thể có chức xác định rõ ràng Các chức có trạng thái cục chúng chia sẻ với trạng thái hệ thống, trạng thái tập trung chức truy cập Nhiều tổ chức phát triển chuẩn phương pháp dựa phân giải chức Nhiều phương pháp thiết kế kết hợp với công cụ CASE hướng chức Vô khối hệ thống phát triển cách sử dụng phương pháp tiếp cận hướng chức Các hệ thống bảo trì cho tương lai xa xôi Bởi thiết kế hướng chứ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 biểu đồ luồng liệu (mô tả việc xử lý liệu), lược đồ cấu trúc (nó cấu trúc phần mềm), mô tả thiết kế chi tiết Thiết kế hướng chức gắn với chi tiết thuật toán chức thơng tin trạng thái hệ thống không bị che dấu Việc thay đổi chức cách sử dụng trạng thái hệ thống gây tương tác bất ngờ chức khác Cách tiếp cận chức để thiết kế tốt mà khối lượng thông tin trạng thái hệ thống làm nhỏ thông tin dùng chung rõ ràng

3.2.2 Biểu đồ luồng liệu

triển biểu đồ luồng liệu hệ thống Biểu đồ không thiết bao gồm thông tin điều khiển nên lập tư liệu phép biến đổi liệu Biểu đồ luồng liệu phần hợp số phương pháp thiết kế công cụ CASE thường trợ giúp cho việc tạo biểu đồ luồng liệu

3.2.3 Lược đồ cấu trúc

Lược đồ cấu trúc cấu trúc thành phần theo thứ bậc hệ thống Nó phần tử biểu đồ luồng liệu thực với tư cách thứ bậc đơn vị chương trình Lược đồ cấu trúc dùng mơ tả chương trình nhìn thấy với thông tin xác định lựa chọn vòng lặp Lược đồ cấu trúc dùng để trình bày tổ chức tĩnh thiết kế

3.2.4 Các từ điển liệu

Từ điển liệu vừa có ích cho việc bảo trì hệ thống vừa có ích q trình thiết kế Với khái niệm thiết kế, cần có từ khóa mơ tả ứng với từ khóa (entry) từ điển liệu cung cấp thông tin khái niệm (kiểu, chức liệu ) Đơi người ta gọi mô tả ngắn chức thành phần

Các từ điển liệu dùng để nối mô tả thiết kế kiểu biểu đồ mô tả thiết kế kiểu văn Một vài công cụ CASE cung cấp phép nối tự động biểu đồ luồng liệu từ điển liệu

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

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

Thiết kế hướng đối tượng dựa chiến lược che dấu thông tin cấu trúc vào bên thành phần Cái ngầm hiểu việc kết hợp điều khiển logic cấu trúc liệu thực thiết kế chậm tốt Liên lạc thông qua thông tin trạng thái dùng chung (các biến tổng thể) nhất, nhờ khả hiểu nâng lên Thiết kế tương đối dễ thay đổi thay đổi cấu trúc thành phần khơng cần quan tâm tới hiệu ứng phụ thành phần khác

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

Thiết kế hướng đối tượng bao gồm đặc trưng sau:

1 Khơng có vùng liệu dùng chung. Các đối tượng liên lạc với cách trao đổi thông báo

2 Các đối tượng thực thể độc lập, dễ thay đổi tất trạng thái thông tin biểu diễn ảnh hưởng phạm vi đối tượng thơi Các thay đổi biểu diễn thơng tin thực khơng cần tham khảo tới đối tượng khác

3 Các đối tượng phân tán hoạt động song song.

Đây lý khiến cho thiết kế hướng đối tượng sử dụng rộng rãi hệ thống nhúng

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

Cơ sở thiết kế hướng đối tượng lớp Lớp trừu tượng mơ tả cho nhóm vật Đối tượng lớp thực thể (cụ thể hóa) lớp Thiết kế lớp bao gồm:

- Cấu trúc liệu (thuộc tính) - Hàm, thủ tục (chức năng)

- Giao diện (cung cấp khả trao đổi liệu lớp khác, chất chức đối tượng)

Việc cài đặt giao diện yếu tố quan trọng để đảm bao che dấu cấu trúc liệu Tức thiết kế nội đối tượng độc lập với giao diện sửa đổi thiết kế mà khơng sợ ảnh hưởng tới đối tượng khác

Các đối tượng trao đổi với cách truyền thông báo Tức đối tượng yêu cầu đối tượng khác thực chức Thơng báo bao gồm: tên đối tượng, tên phương thức, tham số

Vòng đời đối tượng hệ thống hoạt động sau:

.) Khởi tạo: hệ thống tạo đối tượng cách xác lập vùng liệu đồng thời tự động thực chức liên quan đến khởi tạo đối tượng

.) Hoạt động: đối tượng nhận thông báo thực chức yêu cầu

Nhờ có chức khởi tạo phá hủy gọi tự động tự động hóa số cơng việc tránh nhiều sai sót lập trình qn khởi tạo 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 khái niệm quan trọng thiết kế hướng đối tượng Một lớp định nghĩa dựa kế thừa nhiều lớp định nghĩa Kế thừa bao gồm

Kế thừa cấu trúc liệu Kế thừa chức

Khả kế thừa giúp cho rút gọn chương trình nâng cao tính tái sử dụng Một chiến lược chung trước tiên tạo lớp trừu tượng (để dùng chung) toán cụ thể tạo lớp kế thừa cách thêm thông tin đặc thù

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

Thiết kế hướng đối tượng bao gồm bước sau: Xác định lớp đối tượng

2 Xác định thuộc tính cho lớp: biến lớp Xác định hành vi (chức năng): hàm

4 Xác định tương tá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 lớp trừu tượng có thuộc tính chung, khâu đặc trưng thiết kế hướng đối tượng

Ví dụ, giả sử cần xây dựng lớp hình trịn, elíp đa giác Có thể thấy elip hình trịn có số thuộc tính chung tọa độ tâm, xây dựng lớp hình nón chứa thuộc tính chung Giữa hình nón đa giác lại tìm thuộc tính chung mầu nền, mầu biên , xây dựng lớp trừu tượng hình hình học chứa thuộc tính

Phương pháp xác định đối tượng Xác định đối tượng công đoạn thiết kế quan trọng, phụ thuộc nhiều vào kinh nghiệm tốn cụ thể Có số phương pháp đề xuất, phương pháp phân tích từ vựng “câu yêu cầu” Cụ thể danh từ câu yêu cầu coi đối tượng động từ coi chức

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

Thiết kế hướng đối tượng có ưu điểm sau:

• Dễ bảo trì đối tượng độc lập Các đối tượng hiểu cải biên thực thể độc lập Thay đổi thực đối tượng thêm dịch vụ không làm ảnh hưởng tới đối tượng hệ thống khác

• Các đối tượng thành phần dùng lại thích hợp tính độc lập chúng khả kế thừa cao

• Có vài lớp hệ thống thể phản ánh quan hệ rõ ràng thực thể có thực (chẳng hạn thành phần phần cứng) với đối tượng điều khiển hệ thống Điều đạt tính dễ hiểu thiết kế

Nhược điểm thiết kế hướng đối tượng khó nhận đối tượng hệ thống Cách nhìn tự nhiên nhiều hệ thống cách nhìn chức

3.3.6 Quan hệ thiết kế lập trình hướng đối tượng

Thiết kế hướng đối tượng chiến lược thiết kế, không phụ thuộc vào ngôn ngữ thực cụ thể Các ngơn ngữ lập trình hướng đối tượng có khả bao gói đối tượng, kế thừa làm cho việc thực thiết kế hướng đối tượng an toàn đơn giản

Một thiết kế hướng đối tượng thực ngôn ngữ thủ tục kiểu PASCAL C (khơng có đặc điểm bao gói vậy) Ada khơng phải ngơn ngữ lập trình hướng đối tượng khơng trợ giúp thừa kế lớp, lại thực đối tượng Ada cách sử dụng gói nhiệm vụ (tasks), Ada dùng để mô tả thiết kế hướng đối tượng

Tuy nhiên, phải nhấn mạnh mơ tả thiết kế hướng đối tượng ngôn ngữ truyền thống kiểm tra tuân thủ tư tưởng hướng đối tượng ngôn ngữ này, nghĩa người phát triển truy cập đến cấu trúc liệu vật lý đối tượng việc làm vơ nghĩa khái niệm che dấu thơng tin

3.3.7 Quan hệ thiết kế hướng đối tượng hướng chức

Có nhiều quan niệm khác quan hệ thiết kế hướng đối tượng thiết kế hướng chức Có người cho rằng, hai chiến lược thiết kế hỗ trợ lẫn nhau, cụ thể

- DFD dưa mơ hình thuộc tính chức

- Luồng giao tác đưa hướng dẫn tương tác đối tượng (thông báo) - Mơ hình E - R đưa hướng dẫn xây dựng đối tượng

Thêm nữa, thiết kế nội lớp đối tượng có nhiều điểm tương đồng với thiết kế hướng chức

Một quan điểm khác cho thiết kế hướng đối tượng thiết kế hướng chức hai cách tiếp cận hoàn tồn khác nhau, khái niệm che dấu thơng tin, kế thừa đặc trưng quan trọng chất thiết kế hướng đối tượng không dứt bỏ cách nhìn thiết kế hướng chức khai thác hiệu đặc trưng

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

Thiết kế hệ thống máy tính bao gồm phổ rộng công việc từ thiết kế phần cứng thiết kế giao diện người sử dụng Giao diện hệ thống thường tiêu chuẩn so sánh để phán xét hệ thống Giao diện thiết kế gây nhầm lẫn cho người sử dụng, khiến cho họ không sử dụng chức cần thiết trường hợp xấu thực thao tác nguy hiểm phá hủy thông tin cần thiết

Tầm quan trọng giao diện xem xét 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, khâu nghiệp vụ thủ cơng thiết kế tốt nâng cao tốc độ xử lý công việc dẫn tới hiệu kinh tế cao

- Khía cạnh thương mại: sản phẩm bán hàng loạt, giao diện thiết kế tốt (dễ sử dụng, đẹp) gây ấn tượng với khách hàng yếu tố khách hàng chọn mua sản phẩm

đến khả xây dựng nhiều giao diện khác cho đối tượng sử dụng khác hay chạy hệ thống khác

Có hai dịng giao diện là:

- Giao diện dòng lệnh: loại giao diện đơn giản nhất, thường thiết kế gắn chặt với chương trình 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 ứng dụng túy xử lý liệu, chương trình mà đầu đầu vào chương trình khác Giao diện dịng lệnh gọn nhẹ, dễ xây dựng thường khó học, khó sử dụng phù hợp với người dùng chuyên nghiệp ứng dụng đặc thù

- Giao diện đồ họa: sử dụng cửa sổ, menu, icon cho phép người dùng truy cập song song đến nhiều thông tin khác nhau; người dùng thường tương tác cách phối hợp bàn phím chuột; giao diện đồ họa dễ học, dễ sử dụng trở nên thơng dụng có độ chuẩn hóa cao

Nhìn khía cạnh độc lập với khối chương trình xử lý, có 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: giao diện đồ họa thiết kế có độ liên kết cao với chương trình (được xây dựng ngôn ngữ, công cụ ), hầu hết chương trình máy tính cá nhân sử dụng loại giao diện

- X protocol: giao diện đồ họa sử dụng giao thức X protocol, phổ biến máy Unix/Linux Loại giao diện có ưu diểm hoạt động độc lập với khối chương trình cịn lại, tức ta chạy giao diện máy tính phần xử lý bên lại hoạt động máy khác Đáng tiếc phương thức chưa phổ biến máy tính cá nhân (chạy hệ điều hành MS Windows)

- Client/server: cách tiếp cận để hướng tới tính độc lập khả chuyển giao diện xây dựng giao diện chương trình client, tương tác với khối chương trình xử lý (server) thơng qua giao thức trao đổi thông tin mạng (TCP/IP)

Thiết kế giao diện khác với thiết kế chức khác phần mềm điểm hướng tới người sử dụng, cần người sử dụng đánh giá Các công đoạn thiết kế khác thiết kế liệu, thiết kế thuật toán che dấu hoạt động kỹ thuật chi tiết khỏi khách hàng Ngược lại, khách hàng (người dùng tiềm ẩn) nên tham gia vào trình thiết kế giao diện Kinh nghiệm khả họ cần phải tính đến thiết kế giao diện

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

Trong thiết kế giao diện, cần ý tới 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

• Thời gian đáp ứng trung bình: thời gian trung bình mà hệ thống phản hồi yêu cầu người dùng Thời gian để sinh “kết thực sự” yêu cầu phụ thuộc vào chất yêu cầu, thuật toán, tốc độ máy tính, nhiên cần quan tâm khía cạnh tâm lý người dùng đợi lâu mà khơng nhận thơng tin họ nghĩ có vấn đề tiến hành thao tác mong đợi lặp lại thao tác hay dừng hệ thống

• Độ biến thiên thời gian: độ biến thiên thời gian đại lượng cần quan tâm Nếu độ biến thiên lớn, ví dụ thao tác thường đáp ứng giây mà có trường hợp phải giây hồn thành làm cho người dùng đưa thao tác sai

2 Các tiện ích Một giao diện tốt cần có tiện ích để trợ giúp người sử dụng Có loại tiện ích sau

• Tích hợp: tiện ích tích hợp vào giao diện nút Help cung cấp thuyết minh thao tác

• Phụ thêm: tiện ích phụ thêm tài liệu trực tuyến

• Macro: số chương trình cịn cho phép người dùng tự động hóa số thao tác lệnh kiểu macro

3 Thông báo Các thông báo hệ thống đưa cần

• Có nghĩa: thơng báo cần có nghĩa người dùng

• Ngắn gọn: thông báo cần ngắn gọn vào chất vấn đề, đặc biệt kiểu giao diện dòng lệnh

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

Dưới số yếu tố mà giao diện tốt nên có:

• Hướng người dùng: đối tượng người dùng phải rõ ràng, giao diện nên thiết kế có tính đến lực, thói quen loại đối tượng

• Có khả tùy biến cao: giao diện nên có khả tùy biến cao để phục vụ cho cá nhân có cách sử dụng khác nhau, môi trường hoạt động khác

Các phần mềm hệ UNIX với giao diện theo chuẩn X protocol thường thiết kế có độ tùy biến cao

• Nhất qn: biểu tượng, thơng báo, cách thức nhập liệu phải quán nên tn theo chuẩn thơng thường

• An tồn: nên có chế độ xác nhận lại thao tác nguy hiểm (như xóa liệu) nên có khả phục hồi trạng thái cũ (undo)

• Dễ học, dễ sử dụng: giao diện ln cần thiết kế hướng tới tính dễ học, dễ sử dụng, tức khơng địi hỏi người dùng phải có lực đặc biệt Ví dụ khơng cần nhớ nhiều thao tác, khơng địi hỏi phải thao tác nhanh, thơng tin hình dễ đọc Một cách tốt để xây dựng giao diện dễ học dễ sử dụng tuân theo chuẩn giao diện thông dụng

Chương Lập trình

4.1 Ngơn ngữ lập trình

Ngơn ngữ lập trình phương tiện để liên lạc người máy tính Tiến trình lập trình - liên lạc thơng qua ngơn ngữ lập trình - hoạt động người Lập trình bước cốt lõi tiến trình kỹ nghệ phần mềm

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

Cách nhìn kỹ nghệ phần mềm đặc trưng 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 cần u cầu riêng cho chương trình gốc, thiết lập tập hợp tổng quát đặ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 thiết kế chi tiết xác định, xét duyệt sửa đổi cần Về lý thuyết, việc sinh chương trình gốc từ đặc tả chi tiết nên trực tiếp Dễ dịch thiết kế sang chương trình đưa dẫn việc ngơn ngữ lập trình phản xạ gần gũi đến mức cho biểu diễn thiết kế Một ngôn ngữ cài đặt trực tiếp cho kết cấu có cấu trúc, cấu trúc liệu phức tạp, vào/ra đặc biệt, khả thao tác bit, kết cấu hướng vật làm cho việc dịch từ thiết kế sang chương trình gốc dễ nhiều (nếu thuộc tính xác định thiết kế)

Mặc dầu tiến nhanh chóng tốc độ xử lý 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 đòi hỏi chương trình chạy nhanh, gọn (yêu cầu nhớ thấp) Các ngơn ngữ với trình biên dịch tối ưu hấp dẫn hiệu phần mềm u cầu chủ chốt Tính khả chuyển chương trình gốc đặc trưng ngơn ngữ lập trình hiểu theo ba cách khác nhau:

- Chương trình gốc khơng thay đổi mơi trường thay đổi (như việc cài đặt hệ điều hành)

- Chương trình gốc tích hợp vào trình phần mềm khác với hay khơng cần thay đổi đặc trưng ngơn ngữ lập trình

Trong số ba cách hiểu tính khả chuyển cách thứ thông dụng Việc đưa 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ơng cụ phát triển làm ngắn bớt thời gian cần để sinh chương trình gốc cải thiện chất lượng chương trình Nhiều ngơn ngữ lập trình cần tới loạt cơng cụ kể trình biên dịch gỡ lỗi, trợ giúp định dạng chương trình gốc, tiện nghi soạn thảo có sẵn, cơng cụ kiểm sốt chương trình gốc, thư viện chương trình mở rộng nhiều lĩnh vực ứng dụng, trình duyệt, trình biên dịch chéo cho phát triển vi xử lý, khả xử lý macro, công cụ kỹ nghệ ngược công cụ khác Trong thực tế, khái niệm môi trường phát triển phần mềm tốt (bao hàm công cụ) thừa nhận nhân tố đóng góp cho kỹ nghệ phần mềm thành cơng

Tính dễ bảo trì chương trình gốc có tầm quạn trọng chủ chốt cho tất 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ể tiến hành chừng người ta chưa hiểu phần mềm Các yếu tố cấu hình phần mềm (như tài liệu thiết kế) đưa tảng cho việc hiểu biết, cuối chương trình gốc phải đọc sửa đổi theo thay đổi thiết kế

Tính dễ dịch thiết kế sang chương trình yếu tố quan trọng để dễ bảo trì chương trình gốc Bên cạnh đó, đặc trưng tự làm tài liệu ngôn ngữ (như chiều dài phép tên gọi, định dạng nhãn, định nghĩa kiểu, cấu trúc liệu) có ảnh hưởng mạnh đến tính dễ bảo trì

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

Các đặc trưng ngơn ngữ lập trình định miền ứng dụng ngôn ngữ Miền ứng dụng yếu tố để lựa chọn ngơn ngữ cho dự án phần mềm C thường ngôn ngữ hay chọn cho việc phát triển phần mềm hệ thống

Trong lĩnh vực khoa học kỹ thuật FORTRAN với khả tính tốn với độ xác cao thư viện tốn học phong phú cịn ngơn ngữ thống trị Tuy vậy, PASCAL C dùng rộng rãi

COBOL ngôn ngữ cho ứng dụng kinh doanh khai thác CSDL lớn ngôn ngữ hệ thứ tư chiếm ưu

BASIC tiến hóa (Visual Basic) đơng đảo người dùng máy tính cá nhân ủng hộ ngơn 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 ngôn ngữ LISP, PROLOG hay OPS5, nhiều ngơn ngữ lập trình (vạn năng) khá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 miền ứng dụng mở nhiều ngôn ngữ dị ngôn ngữ qui ước Các ngôn ngữ lập trình hướng đối tượng dùng rộng rãi Smalltalk, C++, Java Ngồi cịn có Eiffel, Objectư PASCAL, Flavos nhiều ngôn ngữ khác

Với đặc trưng hướng đối tượng, tính hiệu thực có nhiều cơng cụ thư viện, C++ sử dụng rộng rãi lĩnh vực phát triển ứng dụng nghiệp vụ Java ngôn ngữ hướng đối tượng sử dụng rộng rãi cho phát triển dịch vụ Web phần mềm nhúng lý độ an tồn cao, tính sáng, tính khả chuyển hướng thành phần Theo số thống kê tốc độ phát triển ứng dụng Java cao đến lần so với ngôn ngữ truyền thống C hay chí C++ Các ngơn ngữ biên dịch (script) với câu lệnh thư viện mạnh ý ASP, JavaScript, PERL sử dụng rộng rãi lập trình Web

4.1.3 Ngơn ngữ lập trình và ảnh hưởng tới kỹ nghệ phần mềm

Các đặc trưng ngôn 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 kết cấu có cấu trúc có khuynh hướng giảm bớt độ phức tạp chương trình, làm cho dễ dàng kiểm thử Các ngôn ngữ hỗ trợ cho việc đặc tả chương trình thủ tục ngồi (như FORTRAN) thường làm cho việc kiểm thử tích hợp sinh lỗi

4.2 Phong cách lập trình

Phong cách lập trình bao hàm triết lý lập trình nhấn mạnh tới tính dễ hiểu chương trình nguồn Các yếu tố phong cách bao gồm: tài liệu bên chương trình, phương pháp khai báo liệu, cách xây dựng câu lệnh kỹ thuật vào/ra

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

Tài liệu bên chương trình gốc bắt đầu với việc chọn lựa tên gọi định danh (biến nhãn), tiếp tục với vị trí thành phần việc thích, kết luận với cách tổ chức trực quan chương trình Việc lựa chọn tên gọi định danh có nghĩa đ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 tên mang nghĩa mơ hồ Cho dù chương trình nhỏ tên gọi có nghĩa làm tăng tính dễ hiểu Theo ngơn từ 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 Lời thích cung cấp cho người phát triển ý nghĩa truyền thông với độc giả khác chương trình gốc Lời thích cung cấp hướng dẫn rõ rệt để hiểu pha cuối kỹ nghệ phần mềm - bảo trì Có nhiều hướng dẫn đề nghị cho việc viết lời thích Các thích mở đầu thích chức hai phạm trù địi hỏi cách tiếp cận có khác Lời thích mở đầu nên xuất đầu modul Định dạng cho lời thích là:

1 Một phát biểu mục đích rõ chức mơ đun Mơ tả giao diện bao gồm:

- Một mẫu cách gọi - Mô tả liệu

- Danh sách tất mô đun thuộc cấp

3 Thảo luận liệu thích hợp (như biến quan trọng hạn chế, giới hạn cách dùng chúng) thông tin quan trọng khác

- Tên người thiết kế modul (tác giả) - Tên người xét duyệt ngày tháng - Ngày tháng sửa đổi mô tả sửa đổi

Các thích chức nhúng vào bên thân chương trình gốc dùng để mơ tả cho khối chương trình

4.2.2 Khai báo liệu

Thứ tự khai báo liệu nên chuẩn hóa cho dù ngơn ngữ lập trình khơng có u cầu bắt buộc điều Các tên biến ngồi việc có nghĩa cịn nên mang thơng tin kiểu chúng Ví dụ, nên thống tên biến cho kiểu số nguyên, kiểu số thực Cần phải giải mục đích biến quan trọng, đặc biệt biến tổng thể Các cấu trúc liệu nên giải đầy đủ cấu trúc chức năng, đặc thù sử dụng Đặc biệt cấu trúc phức tạp danh sách móc nối C hay Pascal

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

Việc xây dựng luồng logic phần mềm thiết lập thiết kế Việc xây dựng câu lệnh nhiên lại phần bước lập trình Việc xây dựng câu lệnh nên tuân theo qui tắc quan trọng cả: câu lệnh nên đơn giản trực tiếp Nhiều ngôn ngữ lập trình cho phép nhiều câu lệnh dịng Khía cạnh tiết kiệm khơng gian tính khó mà biện minh tính khó đọc nảy sinh Cấu trúc chu trình phép tốn điều kiện chứa đoạn bị che lấp cách xây dựng nhiều câu lệnh dòng

Cách xây dựng câu lệnh đơn việc tụt lề minh họa cho đặc trưng logic chức đoạn Các câu lệnh chương trình gốc riêng lẻ đơn giản hóa bởi:

- Tránh dùng phép kiểm tra điều kiện phức tạp - Khử bỏ phép kiểm tra điều kiện phủ định

- Tránh lồng nhiều điều kiện hay chu trình

- Dùng dấu ngoặc để làm sáng tỏ biểu thức logic hay số học

- Dùng dấu cách và/hoặc ký hiệu dễ đọc để làm sáng tỏ nội dung câu lệnh

- Chỉ dùng tính chuẩn ngơn ngữ

4.2.4 Vào/ra

Vào mô đun nên tuân thủ theo số hướng dẫn sau: - Làm hợp lệ vào

- Kiểm tra tin cậy tổ hợp khoản mục vào quan trọng - Giữ cho định dạng vào đơn giản

- Dùng báo cuối liệu thay yêu cầu người dùng xác định “số khoản mục”

- Giữ cho định dạng vào thống ngôn ngữ lập trình có u cầu định dạng nghiêm ngặt

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

Tránh lỗi phát triển phần mềm vô lỗi dựa yếu tố sau: i) Sản phẩm đặc tả hệ thống xác

ii) Chấp nhận cách tiếp cận thiết kế phần mềm dựa việc bao gói liệu che dấu thơng tin

iii) Tăng cường duyệt lại trình phát triển 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 bánh lái 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 lỗi chưa phát trình duyệt lại để định lượng độ tin cậy hệ thống

Có hai cách tiếp cận hỗ trợ tránh lỗi là:

Lập trình có cấu trúc: Thuật ngữ đặt từ cuối năm 60 có nghĩa lập trình mà khơng dùng lệnh goto, lập trình dùng vịng lặp while phát biểu if để xây dựng điều khiển thiết kế dùng cách tiếp cận - xuống Việc thừa nhận lập trình có cấu trúc quan trọng bước 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 chương trình họ, tạo sai lầm phát triển Lập trình có cấu trúc làm cho chương trình đọc cách dễ hiểu dễ kiểm tra Tuy nhiên bước việc lập trình nhằm đạt độ tin cậy tốt

i) Các số thực dấu chấm động: phép tốn số thực làm trịn khiến cho việc so sánh kết số thực, so sánh hai số thực không khả thi Số thực dấu phẩy động có độ xác khác khiến cho kết phép tính khơng theo mong muốn Ví dụ, phép tính tính phân cần cộng giá trị nhỏ trước với khơng chúng bị làm trịn

ii) Các trỏ nhớ động: trỏ cấu trúc bậc thấp khó quản lý dễ gây lỗi nghiệm trọng hệ thống Việc cấp phát thu hồi nhớ động phức tạp nguyên nhân gây lỗi phần mềm

iii) Song song: lập trình song song đòi hỏi kỹ thuật cao hiểu biết sâu sắc hệ thống Một vấn đề phức tạp song song quản lý tương tranh

iv) Đệ quy v) Các ngắt

Các cấu trúc có ích, người lập trình nên dùng chúng cách cẩn thận

Phân quyền truy cập liệu: Nguyên lý an ninh quân đội cá nhân biết thơng tin có liên quan trực tiếp đến nhiện vụ họ Khi lập trình người ta tuân theo nguyên lý tương tự cho việc truy cập liệu hệ thống Mỗi thành phần chương trình phép truy cập đến liệu cần thiết để thực chức Ưu điểm việc che dấu thơng tin thông tin bị che dấu bị sập đổ (thao tác trái phép) thành phần chương trình mà xem khơng dùng thơng tin Tiến hóa phân quyền truy cập che dấu thơng tin, hay nói xác che dấu cấu trúc thơng tin Khi đó, thay đổi cấu trúc thơng tin mà khơng phải thay đổi thành phần khác có sử dụng thơng tin

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

Đối với hệ thống đòi hỏi độ tin cậy cao hệ thống điều khiển bay cần phải có khả dung thứ lỗi (fault tolerance), tức khả đảm bảo cho hệ thống hoạt động xác có thành phần sinh lỗi

Có bốn hoạt động cần phải tiến hành hệ thống thứ lỗi: i) Phát lỗi

iii) Hồi phục sau gặp lỗi: Hệ thống phải hồi phục trạng thái mà biết an tồn Cũng chỉnh lý trạng thái bị hủy hoại (hồi phục tiến), lui 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 lỗi khơng xuất Tuy

nhiên nhiều trường hợp phát nguyên nhân gây lỗi khó khăn xẩy tổ hợp thơng tin vào trạng thái hệ thống Thông thường, thứ lỗi thực cách song song hóa chức năng, kết hợp với điều khiển thứ lỗi Bộ điều khiển so sánh kết khối chương trình thực nhiệm vụ sử dụng nguyên tắc đa số để chọn kết

4.3.2 Lập trình phịng thủ

Lập trình phịng thủ cách phát triển chương trình mà người lập trình giả định mâu thuẫn lỗi chưa phát tồn chương trình Phải có phần mềm kiểm tra trạng thái hệ thống sau biến đổi phải đảm bảo biến đổi trạng thái kiên định Nếu phát mâu thuẫn việc biến đổi trạng thái phải rút lại trạng thái phải trở trạng thái đắn trước

Nói chung lỗi gây sụp đổ trạng thái: biến trạng thái gán trị không hợp luật Ngơn ngữ lập trình Ada cho phép phát lỗi thời gian biên dịch Tuy nhiên việc kiểm tra biên dịch hạn chế cho giá trị tĩnh vài phép kiểm tra thời gian thực tránh Một cách để phát lỗi chương trình Ada dùng chế xử lý bất thường kết hợp với đặc tả miền trị

Hồi phục lỗi q trình cải biên khơng gian trạng thái hệ thống cho hiệu ứng lỗi nhỏ hệ thống tiếp tục vận hành, có lẽ 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 hệ thống trạng thái biết

Hồi phục tiến thường chun biệt ứng dụng Có hai tình chung mà hồi phục tiến thành cơng:

1) Khi liệu mã bị sụp đổ: Việc sử dụng kỹ thuật mã hóa thích hợp cách thêm liệu dư thừa vào liệu cho phép sửa sai phát lỗi

chưa bị sụp Kỹ thuật thường dùng cho việc sửa chữa hệ thống tệp sở liệu

Hồi phục lùi kỹ thuật đơn giản liên quan đến việc trì chi tiết trạng thái an toàn cất giữ trạng thái mà sai lầm bị phát Hầu hết hệ quản trị sở liệu có hồi phục lỗi CSDL cập nhật liệu giao dịch hoàn tất khơng phát vấn đề Nếu giao dịch thất bại CSDL khơng cập nhật

Một kỹ thuật khác thiết lập điểm kiểm tra thường kỳ mà chúng trạng thái hệ thống Khi mà lỗi phát trạng thái an tồn tái lưu kho từ điểm kiểm tra gần Trường hợp hệ thống dính líu tới nhiều q trình hợp tác dãy giao tiếp điểm kiểm tra q trình khơng đồng để hồi phục trình phải trở lại trạng thái ban đầu

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

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

Tính hiệu chương trình gốc có liên hệ trực tiếp với tính hiệu thuật toán xác định thiết kế chi tiết Tuy nhiên, phong cách lập trình có tác động đến tốc độ thực yêu cầu nhớ Tập hợp hướng dẫn sau áp dụng thiết kế chi tiết dịch thành chương trình:

- Đơn giản hóa biểu thức số học lơgic trước vào lập trình - Tính cẩn thận chu kỳ lồng để xác định liệu câu lệnh hay

biểu thức chuyển ngồi hay khơng - Khi có thể, tránh dùng mảng nhiều chiều

- Khi tránh việc dùng trỏ danh sách phức tạp - Dùng phép toán số học “nhanh”

- Không trộn lẫn kiểu liệu, cho dù ngôn ngữ có cho phép điều - Dùng biểu thức số học logic

4.4.2 Hiệu nhớ

Tính hiệu nhớ phải tính vào đặc trưng phân trang hệ điều hành Nói chung, tính cục chương trình hay việc bảo trì lĩnh vực chức qua kết cấu có cấu trúc phương pháp tuyệt vời làm giảm việc phân trang làm tăng tính hiệu Hạn chế nhớ phát triển phần mềm nhúng mối quan tâm thực tế, nhớ giá thấp, mật độ cao tiến hóa nhanh chóng Nếu yêu cầu hệ thống cần tới nhớ tối thiểu (như sản phẩm giá thấp, khối lượng lớn) trình biên dịch ngơn ngữ cấp cao phải trù tính cẩn thận với tính nén nhớ, hay phương kế cuối cùng, phải dùng tới hợp ngữ

4.4.3 Hiệu vào/ra

Các thiết bị vào thường có tốc độ chậm nhiều so với khả tính tốn máy tính tốc độ truy cập nhớ Việc tối ưu vào làm tăng đáng kể tốc độ thực Một số hướng dẫn đơn giản để tăng cường hiệu vào/ra:

• Số 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 đệm để làm giảm phí tổn liên lạc

• Với nhớ phụ (như đĩa) nên lựa chọn dùng phương pháp thâm nhập đơn giản chấp nhận

• Nên xếp khối vào/ra với thiết 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 tính thiết bị cải tiến chất lượng hay tốc độ

Chương

Xác minh thẩm định

5.1 Đại cương

Xác minh thẩm định kiểm tra việc phát triển phần mềm Là công việc xuyên suốt trình phát triển phần mềm, khơng khâu kiểm thử có mã nguồn Xác minh (verification) kiểm tra xem sản phầm có với đặc tả khơng, trọng vào việc phát lỗi lập trình Thẩm định (validation) kiểm tra xem sản phẩm có đáp ứng nhu cầu người dùng khơng, có hoạt động hiệu không, tức trọng vào việc phát lỗi phân tích, lỗi thiết kế

Tóm lại, mục đích thẩm định xác minh • Phát sửa lỗi phần mềm

• Đánh giá tính dùng phần mềm

Có hai khái niệm thẩm định/xác minh tĩnh thẩm định/xác minh động Thẩm định xác minh tĩnh kiểm tra mà khơng thực chương trình, ví dụ xét duyệt thiết kế, xét duyệt yêu cầu, nghiên cứu mã nguồn, sử dụng biến đổi hình thức (suy luận) để kiểm tra tính đắn chương trình Thẩm định xác minh tĩnh tiến hành khâu vịng đời phần mềm Về lý thuyết, phát hầu hết lỗi lập trình, nhiên phương pháp đánh giá tính hiệu chương trình

Thẩm định xác minh động kiểm tra thông qua việc thực chương trình, tiến hành sau phát triển chương trình (mã nguồn) Hiện kỹ thuật kiểm tra Cả hai hướng nêu quan trọng chúng bổ khuyết lẫn Trong chương này, sâu vào tìm hiểu thẩm định xác minh động, gọi thử nghiệm (kiểm thử) chương trình

Có hai loại thử nghiệm (động) là:

• Thử nghiệm (tìm) khuyết tật: thiết kế để phát khuyết tật hệ thống (đặc biệt lỗi lập trình)

• Thử nghiệm thống kê: sử dụng liệu (thao tác) phổ biến người dùng (dựa thống kê) để đánh giá tính dùng hệ thống Thử nghiệm cần phải có

chúng ta phải thử nghiệm lại (kể thử nghiệm thành cơng)

• Tính hệ thống: việc thử nghiệm phải tiến hành cách có hệ thống để đảm bảo kiểm thử trường hợp, tiến hành thử nghiệm cách ngẫu nhiên khơng đảm bảo điều

• Được lập tài liệu: để kiểm soát xem thực hiện, kết

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

Một phép thử gọi thành cơng phát khiếm khuyết phần mềm Chú ý phép thử chứng minh tồn lỗi hệ thống khơng chứng minh hệ thống khơng có lỗi Một phép thử (ca thử nghiệm) bao gồm

- Tên mô đun thử nghiệm - Dữ liệu vào

- Dữ liệu mong muốn (đúng)

- Dữ liệu thực tế (khi tiến hành thử nghiệm)

Các ca thử nghiệm nên thiết kế tạo tài liệu phân tích thiết kế, viết xong mã nguồn

5.3 Thử nghiệm chức thử nghiệm cấu trúc

Có hai kỹ thuật thử nghiệm tìm khuyết tật thử nghiệm chức thử nghiệm cấu trúc

5.3.1 Thử nghiệm chức

của vùng Theo kinh nghiệm, sai sót lập trình thường sảy liệu biên

Ví dụ, hàm tính trị tuyệt đối số nguyên, chia miền đối số thành vùng:

- Vùng liệu = - Vùng liệu <

Do liệu đầu vào để kiếm thử 100, ư20,

Ngồi ca thử nghiệm trên, thơng thường cần kiểm tra với liệu đặc thù như:

- Biên số máy tính (ví dụ ư32768, 32767) - 0, số âm, số thập phân

- Khơng có input - Input ngẫu nhiên - Input sai kiểu

Thử nghiệm chức giúp - Phát thiếu sót chức - Phát khiếm khuyết

- Sai sót giao diện mơ đun - Sự khơng hiệu chương trình - Lỗi khởi tạo, lỗi kết thúc

Tuy nhiên thử nghiệm chức dựa đặc tả nên kiểm thử trường hợp không khai báo đặc tả, không đảm bảo thử hết khối mã nguồn mô đun

Thử nghiệm chức khơng phát đoạn mã yếu (có khả sinh lỗi với trạng thái đặc biệt hệ thống), nhiều trường hợp việc đảm bảo xây dựng đầy đủ ca thử nghiệm khó khăn

Ví dụ, hàm tính trị tuyệt đối sau thử nghiệm chức có lỗi

int abs(int n) {

}

5.3.2 Thử nghiệm cấu trúc

Thử nghiệm cấu trúc (structural testing) thử nghiệm dựa phân tích chương trình Kỹ thuật xác định đường (path) chương trình (điều khiển) từ input đến output Mục đích thử nghiệm cấu trúc kiểm tra tất đường Tức đảm bảo lệnh thực lần ca thử nghiệm Thử nghiệm cấu trúc trọng vào phân tích cấu trúc rẽ nhánh vịng lặp

Ví dụ:

int max(int x, int y, int z) {

if (x>y) {

if (x>z) return x; else return z; }

else {

if (y > z) return y; else return z; }

}

Trong ví dụ có đường cần ca thử nghiệm để thử nghiệm tất đường Thử nghiệm cấu trúc xem xét chương trình mức độ chi tiết phù hợp kiểm tra mô đun nhỏ Tuy nhiên thử nghiệm cấu trúc khơng đầy đủ kiểm thử hết lệnh không chứng tỏ kiểm thử hết trường hợp Có khả tồn tổ hợp lệnh khác gây lỗi Ngồi ra, khơng thể kiểm thử hết đường vòng lặp lớn

Tóm lại, thử nghiệm chức thử nghiệm cấu trúc quan trọng chúng bổ khuyết lẫn

5.4 Quá trình thử nghiệm

Quá trình thử nghiệm chia làm giai đoạn sau:

• Thử nghiệm đơn vị: bước thử nghiệm chức (hàm) nhằm mục đích phát lỗi lập trình, thường sử dụng nhiều thử nghiệm cấu trúc

• Thử nghiệm hệ con: hệ thống bao gồm số hệ độc lập bước tiến hành thử nghiệm với hệ riêng biệt

• Thử nghiệm hệ thống (tích hợp): thử nghiệm hoạt động tổng thể hệ thống, kiểm tra tính đắn giao diện, tính đắn với đặc tả, tính dùng Chủ yếu sử dụng thử nghiệm chức

• Thử nghiệm nghiệm thu (alpha): thử nghiệm tiến hành nhóm nhỏ người sử dụng hướng dẫn người phát triển, sử dụng liệu thực, thẩm định tính dùng hệ thống

• Thử nghiệm beta: mở rộng thử nghiệm alpha, tiến hành với số lớn người sử dụng khơng có hướng dẫn người phát triển, kiểm tra tính ổn định, điểm tốt không tốt hệ thống

Các bước thử nghiệm ban đầu nặng kiểm tra lỗi lập trình (xác minh), bước thử nghiệm cuối thiên kiểm tra tính dùng hệ thống (thẩm định) Ngồi cịn bước hay khái niệm thử nghiệm khác gọi thử nghiệm quay lui Thử nghiệm quay lui tiến hành sửa mã chương trình:

- Khi sửa lỗi

- Khi nâng cấp chương trình

5.4.1 Thử nghiệm gây áp lực

Đối với số hệ thống quan trọng, người ta tiến hành thử nghiệm gây áp lực (stress testing) Đây loại (bước) thử nghiệm tiến hành có phiên làm việc, nhằm tìm hiểu hoạt động hệ thống trường hợp tải trọng lớn (dữ liệu lớn, số người sử dụng lớn, tài nguyên hạn chế ) Mục đích thử nghiệm áp lực

- Tìm hiểu giới hạn chịu tải hệ thống

- Tìm hiểu đặc trưng hệ thống đạt vượt giới hạn chịu tải (khi bị sụp đổ)

Ngồi thử nghiệm áp lực cịn nhằm xác định trạng thái đặc biệt tổ hợp số điều kiện dẫn đến sụp đổ hệ thống; tính an tồn liệu, dịch vụ hệ thống sụp đổ

5.5 Chiến lược thử nghiệm

5.5.1 Thử nghiệm lên

Thử nghiệm lên tiến hành thử nghiệm với mô đun mức độ thấp trước Mô đun thượng cấp (mô đun gọi) thay chương trình kiểm thử có nhiện vụ đọc liệu kiểm thử, gọi mô đun cần kiểm thử kiểm tra kết Nhược điểm thử nghiệm lên

- Phát chậm lỗi thiết kế

- Chậm có phiên thực hệ thống

5.5.2 Thử ngiệm xuống

Thử nghiệm xuống tiến hành thử nghiệm với mô đun mức cao trước, mô đun mức thấp tạm thời phát triển với chức hạn chế, có giao diện giống đặc tả Mơ đun mức thấp đơn giản trả lại kết với vài đầu vào định trước

Thử nghiệm xuống có ưu điểm

- Phát sớm lỗi thiết kế, thiết kế, cài đặt lại với giá rẻ - Có phiên hoạt động sớm (với tính hạn chế) sớm tiến hành thẩm định

Chương

Quản lý dự án phát triển phần mềm

6.1 Đại cương

Quản lý dự án tầng phát triển phần mềm Chúng ta gọi tầng quản lý bước kỹ thuật sở kéo dài suốt vòng đời phần mềm Mục tiêu việc quản lý dự án phát triển phần mềm đảm bảo cho dự án

• Đúng thời hạn • Khơng vượt dự tốn

• Đầy đủ chức định

• Thỏa mãn yêu cầu khách hàng (tạo sản phẩm tốt) Quản lý dự án bao gồm pha cơng việc sau

• Thiết lập: viết đề án • Ước lượng chi phí • Phân tích rủi ro • Lập kế hoạch • Chọn người

• Theo dõi kiểm sốt dự án

• Viết báo cáo trình diễn sản phẩm

Tiến hành quản lý dự án người quản lý dự án, có nhiệm vụ quyền hạn sau

• Thời gian

- Tạo lập kế hoạch, điều chỉnh kế hoạch

- Kiểm tra/đối chiếu tiến trình với kế hoạch - Giữ độ mềm dẻo định kế hoạch - Phối thuộc tiến trình

• Tài ngun: thêm tiền, thêm thiết bị, thêm người • Sản phẩm: thêm bớt chức sản phẩm

Ngồi ra, người quản lý dự án cịn cần phải quan tâm đến phối thuộc với dự án khác thông tin cho người quản lý cấp Phương pháp tiếp cận người quản lý dự án

• Hiểu rõ mục tiêu (tìm cách định lượng mục tiêu có thể)

• Hiểu rõ ràng buộc (chi phí, lịch biểu, tính ) • Lập kế hoạch để đạt dược mục tiêu ràng buộc • Giám sát điều chỉnh kế hoạch

• Tạo mơi trường làm việc ổn định, động cho nhóm

Quản lý tồi dẫn đến chậm trễ dự án, tính yếu tăng chi phí phát triển Một ví dụ kinh điển quản lý tồi dự án hệ điều hành OS360 IBM bị chậm năm so với kế hoạch

6.2 Độ đo phần mềm

Để quản lý cần định lượng đối tượng quản lý cần quản lý, phần mềm qui trình phát triển Chúng ta cần đo kích cỡ phần mềm, chất lượng phần mềm, suất phần mềm

6.2.1 Đo kích cỡ phần mềm

Có hai phương pháp phổ biến để đo kích cỡ phần mềm đo số dòng lệnh (LOC -Lines Of Code) đo điểm chức (FP - Function Points) Độ đo LOC tương đối trực quan, nhiên phụ thuộc nhiều vào ngơn ngữ lập trình cụ thể Từ kích cỡ phần mềm (LOC), tính số giá trị

- Hiệu = KLOC/ngườiưtháng - Chất lượng = số khiếm khuyết/KLOC - Chi phí = giá thành/KLOC

Các thông số dự án phát triển khứ dùng dể phục vụ cho ước lượng cho phần mềm phát triển Điểm chức FP tính dựa đặc tả yêu cầu độc lập với ngôn ngữ phát triển Tuy nhiên lại có phụ thuộc vào tham số thiết lập dựa kinh nghiệm Mơ hình sở tính điểm chức

FP = a1I+ a2O + a3 E + a4

L + a5F,

Trong

- O: số Output - E: số yêu cầu - L: số tệp truy cập

- F: số giao diện ngoại lai (devices, systems)

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

Người ta thiết lập số độ đo phần mềm dựa thống kê sau: - Độ tin cậy MTBF - Mean Time Between Failure: thời gian chạy liên tục

của hệ thống

- Thời gian khôi phục hệ thống MTTR - Mean Time To Repair - Tính sẵn có M TBF/(M TBF + M TTR)

6.3 Ước lượng

Công việc người quản lý dự án ước lượng - ước lượng kích cỡ, chi phí, thời gian tiến hành dự án Việc thông thường tiến hành cách phân rã phần mềm cần phát triển thành khối nhỏ áp dụng kinh nghiệm (các thông số kích cỡ, chi phí, lực nhân viên ) phần mềm phát triển để ước lượng, đánh giá cơng việc

Một mơ hình ước lượng hay dùng mơ hình COCOMO - Constructive Cost Model ước lượng chi phí từ số dịng lệnh Dùng mơ hình ta ước lượng thông số sau:

- Nỗ lực phát triển E = aLb - Thời gian phát triển T = cEd - Số người tham gia N = E/T

Trong a,b,c,d tham số tùy thuộc vào loại dự án (xem bảng 6.1) Điểm đáng ý từ nỗ lực phát triển suy thời gian số người tham gia vào dự án

Bảng 6.1: COCOMO - Các tham số sở a b c d organic 3.2 1.05 2.5 0.38 semiưdetached 3.0 1.12 2.5 0.35 embeded 2.8 1.2 2.5 0.32 Các bước tiến hành COCOMO sau:

- Thiết lập kiểu dự án (organic: đơn giản, semiưdetached: trung bình, embeded: phức tạp)

- Tính lại số dịng lệnh sở tái sử dụng - Tính nỗ lực phát triển E cho mơ đun

- Tính lại E dựa độ khó dự án (mức độ tin cậy, kích cỡ CSDL, yêu cầu

tốc độ, nhớ, )

- Tính thời gian số người tham gia

Ví dụ: Phần mềm với 33.3 nghìn dòng lệnh tham số a,b,c,d 3.0, 1.12, 2.5, 0.35, ta tính được:

E = 3.0*33.31.12 = 152ngườiưtháng T = 2.5*E 0.35 = 14.5 tháng

N = E/D ˜ 11người

Cần nhớ đo phần mềm cơng việc khó khăn

• Hầu hết thơng số khơng đo cách trực quan •Rất khó thẩm định thơng số

• Khơng có mơ hình tổng qt • Các kỹ thuật đo cịn thay đổi

Chúng ta khơng thể kiểm sốt q trình sản xuất phần mềm khơng ước lượng (đo) Một mơ hình ước lượng nghèo nàn khơng có mơ hình phải liên tục ước lượng lại dự án tiến triển

6.4 Quản lý nhân

Chi phí (trả cơng) người phần chi phí xây dựng phần mềm Ngoài ra, lực người phát triển phần mềm lại biến thiên, kéo theo phức tạp tính tốn chi phí Phát triển phần mềm tiến hành theo nhóm Kích thước tốt nhóm từ đến ngưòi Phần mềm lớn thường xây dựng nhiều nhóm nhỏ Một nhóm phát triển gồm loại thành viên sau:

• Người phát triển

• Chuyên gia miền ứng dụng • Người thiết kế giao diện

Một nhóm phát triển cần có người quản lý, người có vai trị lãnh đạo mặt kĩ thuật Một đặc trưng làm việc theo nhóm trao đổi thông tin (giao tiếp) thành viên nhóm Thời gian dùng cho việc giao tiếp chiếm đến nửa tổng thời gian dành cho pháp triển phần mềm

Ngồi ra, thời gian khơng dùng cho phát triển sản phẩm chiếm phần lớn thời gian cịn lại người lập trình Một người đồng thời làm việc cho nhiều nhóm (dự án) phần mềm khác Điều làm cho việc tính tốn giá thành phần mềm phức tạp Cần ghi nhớ, sản xuất phần mềm

- Năng lực thành viên không đồng

- Người tốt (nhất) sản xuất lần trung bình, người khơng cho kết

- Một số cơng việc q khó người

Khơng nên tăng số thành viên cách vơ ý thức, làm tăng phức tạp giao tiếp thành viên, khiến công việc nhiều chậm lại Một số việc (phức tạp, đăc thù) nên để người làm

6.5 Quản lý cấu hình

Quản lý cấu hình phần mềm (cịn gọi quản lý mã nguồn) công việc quan trọng sản xuất phần mềm Mã nguồn (và liệu) sản phẩm dự án phần mềm Quản lý cấu hình tự động hóa thơng qua cơng cụ Nhiệm vụ cơng cụ quản lý là:

• Lưu trữ mã nguồn

• Tạo điểm truy cập (phiên thống nhất) cho người lập trình sửa đổi, thêm bớt mã nguồn

Do dễ dàng:

• Kiểm sốt tính thống mã nguồn

• Kiểm sốt sửa đổi, lý sửa đổi, lý lịch lần sửa đổi • Dễ dàng lưu trữ truy cập tới phiên khác phần mềm • Tối ưu hóa vùng đĩa cần thiết cho lưu trữ

Phương thức hoạt động công cụ là:

• Quản lý tập chung (mã nguồn, tư liệu, cơng cụ phát triển )

• Sử dụng phương pháp check out/check in sửa đổi tệp

Thông thường, người phát triển muốn sửa đổi mã nguồn thực thao tác check out tệp Khi tệp bị check out người phát triển khác mở tệp dạng đọc Khi kết thúc sửa đổi ghi tệp vào CSDL, người sửa đổi tiến hành check in để thông báo kết thúc công việc sửa đổi, đồng thời ghi lại thơng tin liên quan (lý sửa đổi ) đến sửa đổi

Dữ liệu lưu trữ dự án thông thường bao gồm: • Mã nguồn

• Dữ liệu • Tư liệu

• Cơng cụ phát triển (chương trình dịch ), thường cần để đảm bảo tương thích với phiên cũ, để đảm bảo chương trình tạo lại (khi sửa lỗi ) phân phát cho khách hàng

• Các ca kiểm thử

Một số công cụ quản lý cấu hình phổ biến RCS, CVS HĐH Solaris SourceSafe Microsoft

6.6 Quản lý rủi ro

Quản lý rủi ro công việc đặc biệt quan trọng khó khăn phát triển phần mềm Có nguyên nhân (rủi ro) sau dẫn đến chấm dứt dự án:

• Chi phí phát triển cao • Quá chậm so với lịch biểu

• Tính q so với u cầu Quản lý rủi ro bao gồm cơng việc sau:

• Dự dốn rủi ro

• Đánh giá khả xảy thiệt hại • Tìm giải pháp khắc phục

Dưới rủi ro thường xẩy phát triển phần mềm phương pháp khắc phục chúng:

• Kế hoạch, dự tốn khơng sát thực tế: ước lượng phương pháp khác nhau; lọc, loại bỏ u cầu khơng quan trọng

• Phát triển sai chức năng: chọn phương pháp phân tích tốt hơn; phân tích tính tổ chức/mơ hình nghiệp vụ khách hàng

• Phát triển sai giao diện: phân tích thao tác người dùng; tạo kịch cách dùng; tạo mẫu

• Yêu cầu cao: lọc bớt yêu cầu; phân tích chi phí/lợi ích

Tài liệu tham khảo

[1] Kent Beck, Extreme Programming Explained, AddisonưWasley, 2000 [2] Bruce Eckel, Thinking in Java, 3rd ed., 2002

[3] Mike Gancarz, The Unix Philosophy, Digital Press, 1994

[4] Roger S Pressman (dịch: Ngô Trung Việt), Kỹ nghệ phần mềm, Tập I,II,III, NXB Giáo dục, 1997

[5] Walker Royce, Software Project Management - A Unified Framework, Addison-Wesley, 1998

[6] Stephen R Schach, Classical and ObjectưOriented Software Engineering with UML and C++, 4th ed., McGrawưHill, 1999

[7] Ian Sommerville, Software Engineering, 6th ed., AddisonưWasley, 2001

[8] Nguyễn Quốc Toản, Bài giảng Nhập mơn Cơng trình học phần mềm, Khoa Cơng nghệ, 1999

[9] Lê Đức Trung, Công nghệ phần mềm, NXB Khoa học Kỹ thuật, 2001

[10] Ngô Trung Việt, Nguyễn Kim ánh (biên soạn), Nhập môn Công nghệ phần mềm, NXB Khoa học kỹ thuật, 2003