Book_2008_Software_Engineering_By_Pankaj_Jalote (2).Pdf

Machine Translated by Google

Chủ đề đại học trong khoa học máy tính

Machine Translated by Google

Đối với các đầu sách khác được xuất bản trong sê-ri này,

hãy truy cập http://www.springer.com/series/7592

Các Chủ đề Đại học về Khoa học Máy tính (UTiCS) cung cấp nội dung giảng dạy chất lượng cao cho sinh viên mới tốt nghiệp đang theo học

trong tất cả các lĩnh vực khoa học máy tính và thông tin. Từ tài liệu lý thuyết và cơ sở cốt lõi đến các chủ đề và ứng dụng của năm

cuối, sách UTiCS có cách tiếp cận mới mẻ, ngắn gọn và hiện đại và lý tưởng cho việc tự học hoặc cho khóa học một hoặc hai học kỳ. Tất cả

các văn bản đều do các chuyên gia có uy tín trong lĩnh vực của họ soạn thảo, được xem xét bởi một ban cố vấn quốc tế và chứa đựng nhiều

ví dụ và vấn đề. Nhiều người bao gồm các giải pháp làm việc đầy đủ.

Machine Translated by Google

Pankaj Jalote

Giới thiệu ngắn gọn về

Kỹ thuật phần mềm

123

Machine Translated by Google

Andrew Pitts, Đại học Cambridge, Vương quốc Anh

Nhà xuất bản truyện dài tập

Steven Skiena, Đại học Stony Brook, Hoa Kỳ

Iain Stewart, Đại học Durham, Vương quốc Anh

Ian Mackie, Ecole Polytechnique, Pháp và Đại học Sussex, Vương quốc Anh

´

David Zhang, Đại học Bách khoa Hồng Kông, Hồng Kông

Các chủ đề đại học về Khoa học máy tính ISSN: 1863-7310 ISBN:

978-1-84800-301-9 e-ISBN: 978-1-84800-302-6 DOI: 10.1007/978-1-84800-302-6

Bảng điều khiển

Samson Abramsky, Đại học Oxford, Vương quốc Anh

Pankaj Jalote, Btech, MS, Tiến sĩ

Chris Hankin, Đại học Hoàng gia Luân Đôn, Vương quốc Anh

Khoa Khoa học Máy tính và Kỹ thuật

Dexter Kozen, Đại học Cornell, Hoa Kỳ

IIT Delhi, Ấn Độ

Hanne Riis Nielson, Đại học Kỹ thuật Đan Mạch, Đan Mạch

Bản ghi danh mục cho cuốn sách này có sẵn từ Thư viện Anh

Khoa học Springer+Truyền thông doanh

nghiệp springer.com

Thư viện Quốc hội Số kiểm soát: 2008933221

c Springer-Verlag London Limited 2008 Ngoài bất

kỳ thỏa thuận công bằng nào cho mục đích nghiên cứu hoặc nghiên cứu riêng tư, hoặc phê bình hoặc đánh giá, như được cho phép

theo Đạo luật Bản quyền, Kiểu dáng và Bằng sáng chế 1988, ấn phẩm này chỉ có thể được sao chép, lưu trữ hoặc truyền đi, trong

bất kỳ hình thức nào hoặc bằng bất kỳ phương tiện nào, với sự cho phép trước bằng văn bản của nhà xuất bản hoặc trong trường

hợp sao chép lại theo các điều khoản của giấy phép do Cơ quan cấp phép bản quyền cấp. Các câu hỏi liên quan đến việc sao chép

ngoài các điều khoản đó nên được gửi đến nhà xuất bản.

Nhà xuất bản không tuyên bố, rõ ràng hay ngụ ý, liên quan đến tính chính xác của thông tin trong cuốn sách này và không thể

chấp nhận bất kỳ trách nhiệm pháp lý hoặc trách nhiệm pháp lý nào đối với bất kỳ sai sót hoặc thiếu sót nào có thể xảy ra.

Biên mục thư viện Anh trong dữ liệu xuất bản

Việc sử dụng tên đã đăng ký, thương hiệu, v.v., trong ấn phẩm này không ngụ ý, ngay cả khi không có tuyên bố cụ thể, rằng

những tên đó được miễn trừ khỏi các luật và quy định có liên quan và do đó được sử dụng miễn phí.

In trên giấy không có axit

Machine Translated by Google

lời nói đầu

– Cung cấp cho sinh viên nền tảng khái niệm cần thiết để thực hiện các nghiên cứu

nâng cao về công nghệ phần mềm, thông qua các khóa học hoặc tự học.

Mục tiêu của cuốn sách này là giới thiệu cho sinh viên một số lượng hạn chế các

– Dạy cho học sinh những kỹ năng cần thiết để thực hiện một dự án thương mại nhỏ.

Khóa học giới thiệu về Kỹ thuật phần mềm vẫn là một trong những môn học khó dạy

nhất phần lớn do có nhiều chủ đề mà khu vực encom vượt qua. Tôi đã từng tin rằng

chúng ta thường có xu hướng dạy quá nhiều khái niệm và chủ đề trong một khóa học

nhập môn, dẫn đến kiến thức nông cạn và ít hiểu biết sâu sắc về ứng dụng của những

khái niệm này. Và Công nghệ phần mềm cuối cùng là về việc áp dụng các khái niệm để

thiết kế các giải pháp phần mềm tốt một cách hiệu quả.

Tôi tin rằng một khóa học giới thiệu về Kỹ thuật phần mềm nên tập trung vào việc

truyền đạt cho sinh viên kiến thức và kỹ năng cần thiết để thực hiện thành công

một dự án thương mại với nỗ lực vài tháng của một người trong khi áp dụng các

phương pháp và kỹ thuật phù hợp. Cần chỉ ra rằng phần lớn các dự án được thực hiện

trong ngành ngày nay thuộc phạm vi này—được thực hiện bởi một nhóm nhỏ trong vài

tháng. Tôi cũng tin rằng bằng cách lựa chọn cẩn thận các khái niệm và chủ đề, chúng

ta có thể đạt được điều này trong suốt một học kỳ. Đây là động lực của cuốn sách

này.

khái niệm và thực hành sẽ đạt được hai mục tiêu sau:

Bàn thắng

Machine Translated by Google

vi lời nói đầu

Khán giả mục tiêu

Tổ chức

Cuốn sách chủ yếu dành cho khóa học giới thiệu về Kỹ thuật phần mềm trong bất kỳ

chương trình đại học hoặc sau đại học nào. Nó được nhắm mục tiêu cho những sinh

viên biết lập trình nhưng chưa có cơ hội tiếp xúc chính thức với kỹ thuật phần

mềm.

Cuốn sách được tổ chức một cách đơn giản, với một chương cho mỗi nhiệm vụ

chính trong một dự án. Đối với kỹ thuật, các nhiệm vụ này là phân tích yêu cầu

và đặc điểm kỹ thuật, thiết kế kiến trúc, thiết kế cấp độ mô-đun, viết mã và kiểm

tra đơn vị và kiểm tra. Đối với quản lý dự án, các nhiệm vụ chính là lập kế hoạch

dự án và giám sát và kiểm soát dự án, nhưng cả hai đều được thảo luận cùng nhau

trong một chương về lập kế hoạch dự án vì ngay cả việc giám sát cũng phải được

lập kế hoạch. Ngoài ra, cuốn sách chứa một chương xác định rõ ràng lĩnh vực vấn

đề của Công nghệ phần mềm và một chương khác thảo luận về khái niệm trung tâm của

quy trình phần mềm tích hợp các nhiệm vụ khác nhau được thực hiện trong một dự án.

Cuốn sách cũng có thể được sử dụng bởi các chuyên gia ở tình trạng tương tự—

biết một số chương trình nhưng muốn được giới thiệu cách tiếp cận có hệ thống của

công nghệ phần mềm.

Tôi chỉ đưa vào cuốn sách này những khái niệm mà tôi tin là nền tảng và thông

qua đó có thể đạt được hai mục tiêu nêu trên. Các chủ đề nâng cao đã bị loại bỏ

một cách có ý thức. Vì việc thực hiện một dự án phần mềm đòi hỏi các kỹ năng ở

hai khía cạnh—kỹ thuật và quản lý dự án—cuốn sách này tập trung vào các nhiệm vụ

chính trong hai khía cạnh này, đồng thời thảo luận về các khái niệm và kỹ thuật

có thể được áp dụng để thực hiện hiệu quả các nhiệm vụ này.

Mỗi chương mở đầu bằng một số lời giới thiệu và sau đó liệt kê rõ ràng các mục

tiêu của chương hoặc những gì người đọc có thể mong đợi học được từ chương này.

Đối với nhiệm vụ được đề cập trong chương này, các khái niệm quan trọng được thảo

luận trước tiên, sau đó là thảo luận về đầu ra của nhiệm vụ, các đặc tính chất

lượng mong muốn của đầu ra, và một số phương pháp và ký hiệu thực tế để thực hiện

nhiệm vụ. Các giải thích được hỗ trợ bởi các ví dụ và các bài học chính được tóm

tắt ở phần cuối cho người đọc. Chương kết thúc với một số bài tập tự đánh giá.

Machine Translated by Google

lời nói đầu vii

Hỗ trợ giảng dạy và tài nguyên bổ sung

Sự nhìn nhận

– Một số bài tập thực hành kiểm tra, thanh tra đơn vị.

Các tài nguyên có sẵn trên trang web bao gồm:

Pankaj Jalote

– Một nghiên cứu điển hình với hầu hết các kết quả đầu ra chính của dự án.

Tôi cũng muốn bày tỏ lời cảm ơn tới vợ tôi, Shikha, và hai con gái tôi là Sumedha và Sunanda

vì một lần nữa đã đồng hành cùng tâm trạng và những giờ phút kỳ quặc của tôi.

Mặc dù cuốn sách là độc lập, một số hỗ trợ giảng dạy và tài nguyên bổ sung có sẵn thông qua một

trang web. URL là: http://www.cse.iitd.ac.in/ConciseIntroToSE

đồ án của sinh viên trong khóa học.

Tôi muốn bày tỏ lòng biết ơn tới biên tập viên của tôi, Wayne Wheeler, người đã nghĩ ra ý tưởng

về một cuốn sách giới thiệu ngắn gọn và tạo ra cơ hội này.

– Các mẫu khác nhau cho các đầu ra khác nhau trong một dự án, có thể được sử dụng cho

– Các bài trình chiếu powerpoint cho từng chương ở định dạng ppt để giảng viên có thể thay đổi

cho phù hợp với phong cách của mình.

Niu Đê-li, tháng 5 năm 2008

Machine Translated by Google

nội dung

2. Quy trình phần mềm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 Quy trình Yêu cầu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.3

Đặc tả yêu cầu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.3.1 Các đặc điểm

mong muốn của một SRS . . . . . . . . . . . . . . . . . . . 41

1.1 Chi phí, Lịch trình và Chất lượng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Quy mô và Thay đổi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 1.3 Tổng kết . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7 bài tập tự đánh giá . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . số 8

3. Phân tích và Đặc tả Yêu cầu Phần mềm . . . . . . . . . . 37 3.1 Giá trị của một SRS

tốt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

1

2.3.5 Mô hình khung thời gian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25 2.3.6 Quy trình lập trình cực đoan và linh hoạt . . . . . . . . . . . . 28 2.3.7 Sử dụng Mô

hình Quy trình trong Dự án . . . . . . . . . . . . . . . . . . . . 30 2.4 Quy trình quản lý dự

án . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.5 Tóm

tắt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Bài Tập Tự Đánh Giá . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

1. Sự cố phần mềm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1 Quy trình và Dự án . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Quy trình phần mềm thành phần . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3 Mô

hình Quy trình Phát triển Phần mềm . . . . . . . . . . . . . . . . . . . . . . 13 2.3.1 Mô hình thác

nước . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.2 Tạo

mẫu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3.3 Phát

triển lặp lại . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.3.4 Quy trình

thống nhất hợp lý . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Machine Translated by Google

x nội dung

4.5.2 Theo dõi và Theo dõi Dự án . . . . . . . . . . . . . . . . . . . . . 87 4.6 Lập kế hoạch chi

tiết . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 4.7 Tóm

tắt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Bài Tập

Tự Đánh Giá . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

3.4.4 Phát triển các trường hợp sử dụng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56 3.5 Các Phương pháp Phân tích Khác . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.5.1 Sơ đồ

luồng dữ liệu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.5.2 Sơ đồ

ER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 3.6 Xác

thực . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.4.4 Phương pháp lập kế hoạch quản lý rủi ro thực tế . . . . . . 84 4.5 Kế hoạch Giám sát Dự

án . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.5.1 Phép

đo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

3.4.2 Ví dụ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.4.3

Phần mở rộng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.4.3 Kiểm soát rủi ro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

3.3.2 Các thành phần của một SRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.3.3

Cấu trúc của Tài liệu Yêu cầu . . . . . . . . . . . . . . . 46 3.4 Đặc tả chức năng với các Ca sử

dụng . . . . . . . . . . . . . . . . . . . . . 49 3.4.1 Khái niệm cơ

bản . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4. Lập kế hoạch cho một dự án phần mềm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.1 Ước

lượng Nỗ lực . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.1.1 Phương

pháp ước lượng từ trên xuống . . . . . . . . . . . . . . . . . . . . . 71 4.1.2 Phương pháp ước lượng

từ dưới lên . . . . . . . . . . . . . . . . . . . . . 74 4.2 Tiến độ dự án và nhân

sự . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.3 Lập kế hoạch chất

lượng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.4 Lập kế hoạch

quản lý rủi ro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.4.1 Khái niệm quản lý rủi

ro . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.4.2 Đánh giá rủi

ro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5. Kiến trúc phần mềm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.1 Vai trò của

Kiến trúc phần mềm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.2 Chế độ xem kiến

trúc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.3 Chế độ xem Thành

phần và Trình kết nối . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 5.3.1 Thành

phần . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 5.3.2 Đầu

nối . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.3.3 Ví

dụ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5.4 Kiểu kiến

trúc cho Chế độ xem C&C . . . . . . . . . . . . . . . . . . . . . . . . . . 108 5.4.1 Đường ống và Bộ

lọc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 5.4.2 Kiểu dữ liệu

được chia sẻ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

3.7 Tóm tắt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Bài Tập Tự Đánh Giá . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Machine Translated by Google

nội dung xi

6. Thiết kế . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

121 6.1 Ý tưởng thiết kế . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

6.1.1 Khớp nối . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

6.1.2 Sự gắn kết . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

6.6 Số liệu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

7. Viết mã và Kiểm tra đơn vị. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 7.1 Nguyên tắc

và hướng dẫn lập trình . . . . . . . . . . . . . . . . . . . . . 182 7.1.1 Lập trình có cấu

trúc . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 7.1.2 Ẩn thông

tin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 7.1.3 Một số Thực hành Lập

trình . . . . . . . . . . . . . . . . . . . . . . . . 187 7.1.4 Tiêu chuẩn mã

hóa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 7.2 Mã phát triển tăng

dần . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 7.2.1 Quá trình mã hóa gia

tăng . . . . . . . . . . . . . . . . . . . . . . 194 7.2.2 Phát triển dựa trên thử

nghiệm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 7.2.3 Lập trình

cặp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 7.3 Quản lý mã phát

triển . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

5.4.3 Kiểu máy khách-máy chủ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 5.4.4

Một số Style khác . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 5.5 Lập tài

liệu Thiết kế Kiến trúc . . . . . . . . . . . . . . . . . . . . . . . . . . 114 5.6 Đánh giá Kiến

trúc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 5.7 Tóm

tắt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Bài Tập

Tự Đánh Giá . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

6.1.3 Nguyên tắc Mở-Đóng . . . . . . . . . . . . . . . . . . . . . . . . . . 129 6.2 Thiết kế hướng chức

năng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 6.2.1 Biểu đồ cấu

trúc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 6.2.2 Phương pháp thiết

kế có cấu trúc . . . . . . . . . . . . . . . . . . . . . . 134 6.2.3 Ví

dụ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 6.3 Thiết kế hướng

đối tượng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 6.3.1 Khái niệm

OO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 6.3.2 Ngôn ngữ mô hình

hóa thống nhất (UML) . . . . . . . . . . . . . . . . . . . 147 6.3.3 Phương pháp thiết

kế . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 6.3.4 Ví

dụ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 6.4 Thiết kế

chi tiết . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 6.4.1 Thiết kế

Logic/Thuật toán . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 6.4.2 Mô hình hóa trạng

thái của các lớp . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 6.5 Xác

minh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

6.6.1 Số liệu phức tạp cho thiết kế hướng chức năng . . . . . . 173 6.6.2 Các phép đo độ phức tạp cho

thiết kế OO . . . . . . . . . . . . . . . . . . . 175 6.7 Tóm

tắt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Bài Tập

Tự Đánh Giá . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Machine Translated by Google

xii nội dung

8. Thử nghiệm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 8.1

Khái niệm kiểm thử . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 8.1.1 Lỗi, Lỗi

và Thất bại . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 8.1.2 Trường hợp kiểm tra, Bộ kiểm tra

và Khai thác kiểm tra . . . . . . . . . . . . . . . 227 8.1.3 Tâm lý kiểm

tra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 8.1.4 Các mức kiểm

tra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 8.2 Quy trình kiểm

tra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 8.2.1 Kế hoạch kiểm

tra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

7.3.1 Kiểm soát và xây dựng mã nguồn . . . . . . . . . . . . . . . . . . . . . . 198

Thư mục . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

7.6.2 Số liệu về độ phức tạp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 7.7 Tóm

tắt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Bài Tập Tự Đánh

Giá . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

7.6.1 Số đo kích thước . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

Mục lục . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

8.3 Kiểm thử hộp đen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 8.3.1 Phân vùng

lớp tương đương . . . . . . . . . . . . . . . . . . . . . . . 237 8.3.2 Phân tích giá trị

biên . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 8.3.3 Kiểm tra theo

cặp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 8.3.4 Các trường hợp đặc

biệt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 8.3.5 Thử nghiệm dựa trên

trạng thái . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 8.4 Kiểm thử hộp

trắng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 8.4.1 Tiêu chí dựa trên luồng

điều khiển . . . . . . . . . . . . . . . . . . . . . . . . . 248 8.4.2 Tạo trường hợp thử nghiệm và hỗ trợ công

cụ . . . . . . . . . . . . . . . 251 8.5 Số

liệu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 8.5.1 Phân

tích Bảo hiểm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 8.5.2 Độ tin

cậy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 8.5.3 Hiệu quả loại bỏ

lỗi . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 8.6 Tóm

tắt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Bài Tập Tự Đánh

Giá . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

7.5.3 Họp Đánh giá Nhóm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 7.6 Số

liệu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

8.2.2 Thiết kế trường hợp thử nghiệm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

8.2.3 Thực hiện ca kiểm thử . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

7.3.2 Tái cấu trúc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 7.4 Kiểm

tra đơn vị . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 7.4.1 Các đơn

vị thủ tục thử nghiệm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 7.4.2 Kiểm tra đơn vị các

lớp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 7.5 Kiểm tra

mã . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 7.5.1 Lập kế

hoạch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 7.5.2 Tự đánh

giá . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Machine Translated by Google

Câu trả lời của sinh viên nói chung là từ 1 đến 3 tháng. Và, với kiến thức chuyên

môn về lập trình của sinh viên, rất có thể họ sẽ có thể xây dựng phần mềm và trình diễn

nó cho giáo sư trong vòng 2 tháng. Với thời gian hoàn thành là 2 tháng, năng suất của học

viên sẽ là 5000 dòng mã (LOC) mỗi người-tháng.

Mặc dù không có con số năng suất tiêu chuẩn và nó thay đổi rất nhiều, nhưng công bằng mà

nói con số năng suất 1000 LOC mỗi người-tháng là khá đáng nể (mặc dù nó có thể thấp tới

100 LOC mỗi người-tháng đối với các hệ thống nhúng).

Với năng suất này, một nhóm chuyên gia trong một tổ chức phần mềm sẽ mất 10 người-tháng

để xây dựng hệ thống phần mềm này.

Tại sao có sự khác biệt về năng suất trong hai kịch bản? Tại sao cùng một sinh viên

có thể sản xuất phần mềm với năng suất vài nghìn LỘC mỗi tháng khi còn học đại học lại

chỉ sản xuất được khoảng nghìn LỘC mỗi tháng khi làm việc trong một công ty?

Bây giờ chúng ta hãy lấy một tình huống thay thế—chúng ta đóng vai trò là khách hàng

và đặt vấn đề tương tự cho một công ty đang kinh doanh phát triển phần mềm cho khách hàng.

Hãy hỏi bất kỳ sinh viên nào đã có một số kinh nghiệm lập trình câu hỏi sau: Bạn được

giao một bài toán mà bạn phải xây dựng một hệ thống phần mềm mà hầu hết sinh viên cảm

thấy sẽ có khoảng 10.000 dòng mã (chẳng hạn như C hoặc Java). Nếu bạn đang làm việc toàn

thời gian cho nó, bạn sẽ mất bao lâu để xây dựng hệ thống này?

Tất nhiên, câu trả lời là hai thứ khác nhau đang được xây dựng trong hai kịch bản.

Đầu tiên, một hệ thống sinh viên đang được xây dựng, chủ yếu dành cho mục đích trình diễn

và dự kiến sẽ không được sử dụng sau này. Bởi vì nó là

Vấn đề phần mềm

P. Jalote, A Concise Introduction to Software Engineering,

DOI: 10.1007/978-1-84800-302-6 1, c Springer-Verlag London Limited 2008

1

Machine Translated by Google

2 1. Vấn đề phần mềm

– Làm thế nào chi phí và năng suất được xác định và đo lường cho một dự án như vậy, và

Phần mềm sức mạnh công nghiệp rất đắt tiền chủ yếu là do việc phát triển phần mềm

cực kỳ tốn nhiều công sức. Để có được ý tưởng về các chi phí liên quan, chúng ta hãy

xem xét tình trạng thực hành hiện tại trong ngành. Các dòng mã (LOC) hoặc hàng nghìn

dòng mã (KLOC) được phân phối cho đến nay là nhiều nhất

Nhu cầu về chất lượng cao và để đáp ứng người dùng cuối có tác động lớn đến cách

phát triển phần mềm và giá thành của nó. Quy tắc ngón tay cái mà Brooks đưa ra gợi ý

rằng phần mềm sức mạnh công nghiệp có thể có giá gấp khoảng 10 lần phần mềm sinh viên

[16].

Mặc dù nhu cầu về chất lượng cao giúp phân biệt phần mềm sức mạnh công nghiệp với các

phần mềm khác, nhưng chi phí và tiến độ là những động lực chính khác cho phần mềm đó.

Trong lĩnh vực phần mềm sức mạnh công nghiệp, có ba yếu tố cơ bản đang diễn ra—chi phí,

tiến độ và chất lượng. Phần mềm nên được sản xuất với chi phí hợp lý, trong thời gian

hợp lý và phải có chất lượng tốt. Ba tham số này thường thúc đẩy và xác định một dự án

phần mềm.

sức mạnh) dự án phần mềm.

Mặt khác, một hệ thống phần mềm có sức mạnh công nghiệp được xây dựng để giải quyết

một số vấn đề của khách hàng và được tổ chức của khách hàng sử dụng để vận hành một số

bộ phận của doanh nghiệp và sự cố của một hệ thống như vậy có thể ảnh hưởng rất lớn về

mặt tài chính hoặc tổn thất kinh doanh, sự bất tiện cho người dùng hoặc mất mát tài sản

và tính mạng. Do đó, hệ thống phần mềm cần phải có chất lượng cao đối với các thuộc

tính như độ tin cậy, khả năng sử dụng, tính di động, v.v.

– Quy mô và sự thay đổi lớn đó là những thuộc tính quan trọng của miền vấn đề

– Chất lượng, chi phí và tiến độ là những lực lượng chính thúc đẩy một (công nghiệp

không được sử dụng, không có gì quan trọng phụ thuộc vào phần mềm và sự hiện diện của

lỗi và thiếu chất lượng không phải là mối quan tâm chính. Các vấn đề chất lượng khác

như khả năng sử dụng, khả năng bảo trì, tính di động, v.v.

chất lượng của phần mềm được mô tả và đo lường như thế nào.

và cách tiếp cận giải pháp phải xử lý chúng.

Ngành công nghiệp phần mềm chủ yếu quan tâm đến việc phát triển phần mềm có sức

mạnh công nghiệp và lĩnh vực công nghệ phần mềm tập trung vào cách xây dựng các hệ

thống như vậy. Đó là, lĩnh vực vấn đề cho công nghệ phần mềm là phần mềm sức mạnh công

nghiệp. Trong phần còn lại của cuốn sách, khi chúng tôi sử dụng thuật ngữ phần mềm,

chúng tôi muốn nói đến phần mềm sức mạnh công nghiệp. Trong phần còn lại của chương

này, chúng ta sẽ học

1.1 Chi phí, Lịch trình và Chất lượng

Machine Translated by Google

1.1 Chi phí, Lịch trình và Chất lượng 3

Rõ ràng, do đó, việc giảm chi phí và thời gian chu kỳ phát triển phần mềm là mục

tiêu trọng tâm của công nghệ phần mềm. Năng suất tính theo đầu ra (KLOC) mỗi người￾tháng có thể phản ánh đầy đủ cả mối quan tâm về chi phí và lịch trình. Nếu năng suất

cao hơn, rõ ràng là chi phí tính theo tháng người sẽ thấp hơn (hiện tại công việc tương

tự có thể được thực hiện với ít người-tháng hơn). Tương tự, nếu năng suất cao hơn, tiềm

năng phát triển phần mềm trong thời gian ngắn hơn sẽ cải thiện—một nhóm có năng suất

cao hơn sẽ hoàn thành công việc trong thời gian ngắn hơn so với nhóm cùng quy mô có

năng suất thấp hơn. (Dĩ nhiên, thời gian thực tế mà dự án sẽ mất cũng phụ thuộc vào số

lượng người được phân bổ cho dự án.) Do đó, việc theo đuổi năng suất cao hơn là động

lực cơ bản đằng sau công nghệ phần mềm và là lý do chính để sử dụng các công cụ và phần

mềm khác nhau. kỹ xảo.

Năng suất trong ngành công nghiệp phần mềm để viết mã mới thường dao động từ vài

trăm đến khoảng hơn 1000 LỘC mỗi người-tháng. Tính năng sản xuất này nằm trong toàn

bộ chu kỳ phát triển, không chỉ nhiệm vụ viết mã. Các công ty phần mềm thường tính phí

khách hàng mà họ đang phát triển phần mềm từ $3000 - $15.000 mỗi người-tháng. Với năng

suất 1000 LOC mỗi người-tháng, điều đó có nghĩa là mỗi dòng mã được phân phối có giá

từ 3 đến 15 đô la! Và ngay cả những dự án nhỏ cũng có thể dễ dàng kết thúc với phần

mềm 50.000 LỘC.

Thật không may, lịch sử của phần mềm đầy rẫy những trường hợp các dự án về cơ bản bị

trễ.

Và năng suất thường được đo lường trong ngành theo LOC (hoặc KLOC) mỗi người-tháng.

Rõ ràng, phát triển phần mềm chất lượng cao là một mục tiêu cơ bản khác của công nghệ

phần mềm. Tuy nhiên, trong khi chi phí nhìn chung đã được hiểu rõ, khái niệm về chất

lượng trong bối cảnh phần mềm cần được giải thích thêm.

Lịch trình là một yếu tố quan trọng khác trong nhiều dự án. Xu hướng kinh doanh

đang chỉ ra rằng thời gian đưa sản phẩm ra thị trường phải giảm xuống; nghĩa là thời

gian chu kỳ từ ý tưởng đến giao hàng phải nhỏ. Đối với phần mềm, điều này có nghĩa là

nó cần được phát triển nhanh hơn và trong thời gian quy định.

phép đo kích thước phần mềm thường được sử dụng trong ngành. Vì chi phí chính của việc

sản xuất phần mềm là nhân lực được tuyển dụng, nên chi phí phát triển phần mềm thường

được đo bằng số tháng công sức dành cho người phát triển.

Bên cạnh chi phí và lịch trình, yếu tố chính khác thúc đẩy kỹ thuật phần mềm là

chất lượng. Ngày nay, chất lượng là một trong những câu thần chú chính và các chiến

lược kinh doanh được thiết kế xung quanh nó. Thật không may, một số lượng lớn các

trường hợp đã xảy ra liên quan đến tính không đáng tin cậy của phần mềm—phần mềm thường

không thực hiện những gì nó phải làm hoặc thực hiện một số việc mà nó không được phép thực hiện.

Tiêu chuẩn quốc tế về chất lượng sản phẩm phần mềm [55] gợi ý rằng

Với năng suất này, một dự án phần mềm như vậy sẽ có giá từ 150.000 đến 750.000 USD!

Machine Translated by Google