3f-hedspi.

net

Phần I Giới thiệu chung về CNHPM
Chương 1: Bản chất phần mềm 1.1 1.2 1.3 1.4 1.5 1.6 Định nghĩa chung về phần mềm Kiến trúc phần mềm Các khái niệm Đặc tính chung của phần mềm Thế nào là phần mềm tốt ? Các ứng dụng phần mềm

1.1. Định nghĩa chung về phần mềm • • • Phần mềm (Software - SW) như một khái niệm đối nghĩa với phần cứng (Hardware - HW), tuy nhiên, đây là 2 khái niệm tương đối Từ xưa, SW như thứ được cho không hoặc bán kèm theo máy (HW) Dần dần, giá thành SW ngày càng cao và nay cao hơn HW

Các đặc tính của SW và HW HW Vật cứng Kim loại Vật chất Hữu hình Sản xuất công nghiệp bởi máy móc là chính Định lượng là chính Hỏng hóc, hao mòn Định nghĩa 1: Phần mềm là • • • Các lệnh (chương trình máy tính) khi được thực hiện thì cung cấp những chức năng và kết quả mong muốn Các cấu trúc dữ liệu làm cho chương trình thao tác thông tin thích hợp Các tư liệu mô tả thao tác và cách sử dụng chương trình SW Vật mềm Kỹ thuật sử dụng Trừu tượng Vô hình Sản xuất bởi con người là chính Định tính là chính Không hao mòn mà tốt lên qua mỗi lần phát hiện lỗi (error, bug) và sửa lỗi

SW đối nghĩa với HW • Vai trò SW ngày càng thể hiện trội

Kỹ nghệ phần mềm

Page 1

3f-hedspi.net • • • Máy tính là . . . chiếc hộp không có SW Ngày nay, SW quyết định chất lượng một hệ thống máy tính (HTMT), là chủ đề cốt lõi, trung tâm của HTMT Hệ thống máy tính gồm HW và SW

Định nghĩa 2 Trong một hệ thống máy tính, nếu trừ bỏ đi các thiết bị và các loại phụ kiện thì phần còn lại chính là phần mềm (SW) • • Nghĩa hẹp: SW là dịch vụ chương trình để tăng khả năng xử lý của phần cứng của máy tính (như hệ điều hành - OS) Nghĩa rộng: SW là tất cả các kỹ thuật ứng dụng để thực hiện những dịch vụ chức năng cho mục đích nào đó bằng phần cứng

SW theo nghĩa rộng • • • Không chỉ SW cơ bản và SW ứng dụng Phải gồm cả khả năng, kinh nghiệm thực tiễn và kỹ năng của kỹ sư (người chế ra phần mềm): Know-how of Software Engineer Là tất cả các kỹ thuật làm cho sử dụng phần cứng máy tính đạt hiệu quả cao

Phần mềm là gì ?

Nhóm các kỹ thuật, phương pháp luận

Nhóm các chương trình

Nhóm các tư liệu

Kỹ nghệ phần mềm

Kinh nghiệm kỹ sư, know-how

Page 2

3f-hedspi.net

Nhóm các kỹ thuật, phương pháp luận • • • • Các khái niệm và trình tự cụ thể hóa một hệ thống Các phương pháp tiếp cận giải quyết vấn đề Các trình tự thiết kế và phát triển được chuẩn hóa Các phương pháp đặc tả yêu cầu, thiết kế hệ thống, thiết kế chương trình, kiểm thử, toàn bộ quy trình quản lý phát triển phần mềm

Nhóm các chương trình • • • Là phần giao diện với phần cứng, tạo thành từ các nhóm lệnh chỉ thị cho máy tính biết trình tự thao tác xử lý dữ liệu Phần mềm cơ bản: với chức năng cung cấp môi trường thao tác dễ dàng cho người sử dụng nhằm tăng hiệu năng xử lý của phần cứng (ví dụ như OS là chương trình hệ thống) Phần mềm ứng dụng: dùng để xử lý nghiệp vụ thích hợp nào đó (quản lý, kế toán, . . .), phần mềm đóng gói, phần mềm của người dùng, . . .

Nhóm các tư liệu • • Những tư liệu hữu ích, có giá trị cao và rất cần thiết để phát triển, vận hành và bảo trì phần mềm Để chế ra phần mềm với độ tin cậy cao cần tạo ra các tư liệu chất lượng cao: đặc tả yêu cầu, mô tả thiết kế từng loại, điều kiện kiểm thử, thủ tục vận hành, hướng dẫn thao tác

Những yếu tố khác • Sản xuất phần mềm phụ thuộc rất nhiều vào con người (kỹ sư phần mềm). Khả năng hệ thống hóa trừu tượng, khả năng lập trình, kỹ năng công nghệ, kinh nghiệm làm việc, tầm bao quát, . . .: khác nhau ở từng người Phần mềm phụ thuộc nhiều vào ý tưởng (idea) và kỹ năng (know-how) của người/nhóm tác giả

1.2 Kiến trúc phần mềm 1.2.1 Phần mềm nhìn từ cấu trúc phân cấp • • • Cấu trúc phần mềm là cấu trúc phân cấp (hierarchical structure): mức trên là hệ thống (system), dưới là các hệ thống con (subsystems) Dưới hệ thống con là các chương trình Dưới chương trình là các Modules hoặc Subroutines với các đối số (arguments)

Kỹ nghệ phần mềm

Page 3

3f-hedspi.net

1.2.2 Phần mềm nhìn từ cấu trúc và thủ tục. • Hai yếu tố cấu thành của phần mềm – – • • Phương diện cấu trúc Phương diện thủ tục

Cấu trúc phần mềm: biểu thị kiến trúc các chức năng mà phần mềm đó có và điều kiện phân cấp các chức năng (thiết kế cấu trúc) Thiết kế chức năng: theo chiều đứng (càng sâu càng phức tạp) và chiều ngang (càng rộng càng nhiều chức năng, qui mô càng lớn)

Kỹ nghệ phần mềm

Page 4

3f-hedspi.net

Thủ tục (procedure) phần mềm • • • • Là những quan hệ giữa các trình tự mà phần mềm đó có Thuật toán với những phép lặp, rẽ nhánh, điều khiển luồng xử lý (quay lui hay bỏ qua) Là cấu trúc lôgic biểu thị từng chức năng có trong phần mềm và trình tự thực hiện chúng Thiết kế cấu trúc trước rồi sang chức năng

1.3 Các khái niệm • Khi chế tác phần mềm cần nhiều kỹ thuật – – • • • • • • Phương pháp luận (Methodology): những chuẩn mực cơ bản để chế tạo phần mềm với các chỉ tiêu định tính Các phương pháp kỹ thuật (Techniques): những trình tự cụ thể để chế tạo phần mềm và là cách tiếp cận khoa học mang tính định lượng

Từ phương pháp luận triển khai đến kỹ thuật Khái niệm tính môđun (modularity concept) Khái niệm chi tiết hóa dần từng bước (stepwise refinement concept) Khái niệm trừu tượng hóa (abstraction concept): về thủ tục, điều khiển, dữ liệu Khái niệm che giấu thông tin (information hiding concept) Khái niệm hướng đối tượng (object oriented)

Kỹ nghệ phần mềm

Page 5

3f-hedspi.net

1.3.1 Tính môđun (Modularity) • • Là khả năng phân chia phần mềm thành các môđun ứng với các chức năng, đồng thời cho phép quản lý tổng thể: khái niệm phân chia và trộn (partion and merge) Hai phương pháp phân chia môđun theo chiều – – • sâu (depth, thẳng đứng): điều khiển phức tạp dần rộng (width, nằm ngang): môđun phụ thuộc dần

Quan hệ giữa các môđun: qua các đối số (arguments)

Chuẩn phân chia môđun Kỹ nghệ phần mềm Page 6

3f-hedspi.net

1.3.2 Chi tiết hóa từng bước

Ví dụ: Trình tự giải quyết vấn đề từ mức thiết kế chương trình đến mức lập trình • • • Bài toán: từ một nhóm N số khác nhau tăng dần, hãy tìm số có giá trị bằng K (nhập từ ngoài vào) và in ra vị trí của nó Giải từng bước từ khái niệm đến chi tiết hóa từng câu lệnh bởi ngôn ngữ lập trình nào đó Chọn giải thuật tìm kiếm nhị phân (pp nhị phân)

Cụ thể hóa thủ tục qua các chức năng

Kỹ nghệ phần mềm

Page 7

3f-hedspi.net Cụ thể hóa theo bước

Mức mô tả chương trình (bằng PDL) Bắt đầu Đọc K Nhận giá trị cho mảng 1 chiều A(I), (I =1, 2, . . . ,.N) MIN = 1 MAX = N DO WHILE (Có giá trị bằng K không, cho đến khi MIN > MAX) Lấy MID = (MIN + MAX) / 2 IF A(MID) > K THEN MAX = MID - 1 ELSE IF A(MID) < K THEN MIN = MID + 1 ELSE In giá trị MID ENDIF ENDIF ENDDO KếtThúc

Kỹ nghệ phần mềm

Page 8

3f-hedspi.net 1.3.3 Khái niệm Che giấu thông tin Để phân rã phần mềm thành các môđun một cách tốt nhất, cần tuân theo nguyên lý che giấu thông tin: “các môđun nên được đặc trưng bởi những quyết định thiết kế sao cho mỗi môđun ẩn kín đối với các môđun khác” [Parnas1972] • Rất hữu ích cho kiểm thử và bảo trì phần mềm

Khái niệm Trừu tượng hóa • • Abstraction cho phép tập trung vấn đề ở mức tổng quát, gạt đi những chi tiết mức thấp ít liên quan 3 mức trừu tượng – – – • Trừu tượng thủ tục: dãy các chỉ thị với chức năng đặc thù và giới hạn nào đó Trừu tượng dữ liệu: tập hợp dữ liệu mô tả đối tượng dữ liệu nào đó Trừu tượng điều khiển: Cơ chế điều khiển chương trình không cần đặc tả những chi tiết bên trong

Ví dụ: Mở cửa. Thủ tục: Mở gồm . . .; Dữ liệu: Cửa là . . .

1.4 Đặc tính chung của phần mềm • • • • • • • • • Là hàng hóa vô hình, không nhìn thấy được Chất lượng phần mềm: không mòn đi mà có xu hướng tốt lên sau mỗi lần có lỗi (error/bug) được phát hiện và sửa Phần mềm vốn chứa lỗi tiềm tàng, theo quy mô càng lớn thì khả năng chứa lỗi càng cao Lỗi phần mềm dễ được phát hiện bởi người ngoài Chức năng của phần mềm thường biến hóa, thay đổi theo thời gian (theo nơi sử dụng) Hiệu ứng làn sóng trong thay đổi phần mềm Phần mềm vốn chứa ý tưởng và sáng tạo của tác giả/nhóm làm ra nó Cần khả năng “tư duy nhị phân” trong xây dựng, phát triển phần mềm Có thể sao chép rất đơn giản

Kỹ nghệ phần mềm

Page 9

3f-hedspi.net 1.5 Thế nào là phần mềm tốt ?

1.5.1 Các chỉ tiêu cơ bản • • • • • Phản ánh đúng yêu cầu người dùng (tính hiệu quả - effectiveness) Chứa ít lỗi tiềm tàng Giá thành không vượt quá giá ước lượng ban đầu Dễ vận hành, sử dụng Tính an toàn và độ tin cậy cao

1.5.2 Hiệu suất xử lý cao • Hiệu suất thời gian tốt (efficiency): – – – • Độ phức tạp tính toán thấp (Time complexity) Thời gian quay vòng ngắn (Turn Around Time: TAT) Thời gian hồi đáp nhanh (Response time)

Sử dụng tài nguyên hữu hiệu: CPU, RAM, HDD, Internet resources, . . .

1.5.3 Tính dễ hiểu • • • Kiến trúc và cấu trúc thiết kế dễ hiểu Dễ kiểm tra, kiểm thử, kiểm chứng Dễ bảo trì

Kỹ nghệ phần mềm

Page 10

3f-hedspi.net • Có tài liệu (mô tả yêu cầu, điều kiện kiểm thử, vận hành, bảo trì, FAQ, . . .) với chất lượng cao

1.6 Các ứng dụng phần mềm • • • • • • • • Phần mềm hệ thống (System SW) Phần mềm thời gian thực (Real-time SW) Phần mềm nghiệp vụ (Business SW) Phần mềm tính toán KH&KT (Eng.&Scie. SW) Phần mềm nhúng (Embedded SW) Phần mềm máy cá nhân (Personal computer SW) Phần mềm trên Web (Web-based SW) Phần mềm trí tuệ nhân tạo (AI SW)

Chương 2 2.1 Định nghĩa: Công nghệ học phần mềm • • • • • Bauer [1969]: CNHPM là việc thiết lập và sử dụng các nguyên tắc công nghệ học đúng đắn dùng để thu được phần mềm một cách kinh tế vừa tin cậy vừa làm việc hiệu quả trên các máy thực Parnas [1987]: CNHPM là việc xây dựng phần mềm nhiều phiên bản bởi nhiều người Ghezzi [1991]: CNHPM là một lĩnh vực của khoa học máy tính, liên quan đến xây dựng các hệ thống phần mềm vừa lớn vừa phức tạp bởi một hay một số nhóm kỹ sư Sommerville [1995]: CNHPM là lĩnh vực liên quan đến lý thuyết, phương pháp và công cụ dùng cho phát triển phần mềm K. Kawamura [1995]: CNHPM là lĩnh vực học vấn về các kỹ thuật, phương pháp luận công nghệ học (lý luận và kỹ thuật được hiện thực hóa trên những nguyên tắc, nguyên lý nào đó) trong toàn bộ quy trình phát triển phần mềm nhằm nâng cao cả chất và lượng của sản xuất phần mềm

Công nghệ học phần mềm là lĩnh vực khoa học về các phương pháp luận, kỹ thuật và công cụ tích hợp trong quy trình sản xuất và vận hành phần mềm nhằm tạo ra phần mềm với những chất lượng mong muốn [Software Engineering is a scientìic field to deal with methodologies, techniques and tools integrated in software production-maintenance process to obtain software with desired qualities] Kỹ nghệ phần mềm

Page 11

3f-hedspi.net Công nghệ học trong CNHPM ? (1) Như các ngành công nghệ học khác, CNHPM cũng lấy các phương pháp khoa học làm cơ sở (2) Các kỹ thuật về thiết kế, chế tạo, kiểm thử và bảo trì phần mềm đã được hệ thống hóa hóa thành phương pháp luận và hình thành nên CNHPM (3) Toàn bộ quy trình quản lý phát triển phần mềm gắn với khái niệm vòng đời phần mềm, được mô hình hóa với những kỹ thuật và phương pháp luận trở thành các chủ đề khác nhau trong CNHPM (4) Trong vòng đời phần mềm không chỉ có chế tạo mà bao gồm cả thiết kế, vận hành và bảo dưỡng (tính quan trọng của thiết kế và bảo dưỡng) (5) Trong khái niệm phần mềm, không chỉ có chương trình mà cả tư liệu về phần mềm (6) Cách tiếp cận công nghệ học (khái niệm công nghiệp hóa) thể hiện ở chỗ nhằm nâng cao năng suất (tính năng suất) và độ tin cậy của phần mềm, đồng thời giảm chi phí giá thành 2.2 Vòng đời phần mềm(Software life-cycle) • • Vòng đời phần mềm là thời kỳ tính từ khi phần mềm được sinh (tạo) ra cho đến khi chết đi (từ lúc hình thành đáp ứng yêu cầu, vận hành, bảo dưỡng cho đến khi loại bỏ không đâu dùng) Quy trình phần mềm (vòng đời phần mềm) được phân chia thành các pha chính: phân tích, thiết kế, chế tạo, kiểm thử, bảo trì. Biểu diễn các pha có khác nhau theo từng người

Mô hình vòng đời phần mềm của Boehm Kỹ nghệ phần mềm Page 12

3f-hedspi.net Suy nghĩ mới về vòng đời phần mềm (1) Pha xác định yêu cầu và thiết kế có vai trò quyết định đến chất lượng phần mềm, chiếm phần lớn công sức so với lập trình, kiểm thử và chuyển giao phần mềm (2) Pha cụ thể hóa cấu trúc phần mềm phụ thuộc nhiều vào suy nghĩ trên xuống (top-down) và trừu tượng hóa, cũng như chi tiết hóa (3) Pha thiết kế, chế tạo thì theo trên xuống, pha kiểm thử thì dưới lên (bottom-up)

(4) Trước khi chuyển sang pha kế tiếp phải đảm bảo pha hiện nay đã được kiểm thử không còn lỗi (5) Cần có cơ chế kiểm tra chất lượng, xét duyệt giữa các pha nhằm đảm bảo không gây lỗi cho pha sau (6) Tư liệu của mỗi pha không chỉ dùng cho pha sau, mà chính là đối tượng quan trọng cho kiểm tra và đảm bảo chất lượng của từng quy trình và của chính phần mềm (7) Cần chuẩn hóa mẫu biểu, cách ghi chép tạo tư liệu cho từng pha, nhằm đảm bảo chất lượng phần mềm (8) Thao tác bảo trì phần mềm là việc xử lý quay vòng trở lại các pha trong vòng đời phần mềm nhằm biến đổi, sửa chữa, nâng cấp phần mềm

Các phương pháp luận và kỹ thuật cho từng pha Tên pha Xác định yêu cầu Thiết kế hệ thống Thiết kế chương trình Nội dung nghiệp vụ Đặc tả yêu cầu người dùng Xác định yêu cầu phần mêm Thiết kế cơ bản phần mềm Thiết kế cấu trúc bên ngoài phần mềm Là thiết kế chi tiết: Thiết kế cấu trúc bên trong của phần mềm (đơn vị chương trình hoặc môđun) Mã hóa bởi ngôn ngữ lập trình Kiểm tra chất lượng phần mêm đã phát triển Sử dụng, vần hành phần mềm đã phát triển. Biến đổi, điểu chỉnh phần mềm Phương pháp, kỹ thuật Phân tích cấu trúc hóa Thiết kế cấu trúc hóa Lập trình cấu trúc Phương pháp Jackson Phương pháp Warnier Mã hóa cấu trúc hóa Phương pháp kiểm thử chương trình Chưa cụ thể

Lập trình Đảm bảo chất lượng Vận hành bảo trì

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

Kỹ nghệ phần mềm

Page 13

3f-hedspi.net

2.3.1 Capability Maturity Model (CMM) by SEI: Mô hình thuần thục khả năng • • • • • Level 1: Initial (Khởi đầu). Few processes are defined. Success depends on individual effort Level 2: Repeatable (Lặp lại). Basic project management processes. Repeat earlier succeses on projects with similar applications Level 3: Defined (Xác định). Use a documented and approved version of the organization’s process for developing and supporting software Level 4: Managed (Quản trị). Both SW process and products are quantitatively understood and controlled using detailed measures Level 5: Optimizing (Tối ưu). Continuous process improvement is enabled by quantitative feedback from the process and from testing innovative ideas and technologies

Kỹ nghệ phần mềm

Page 14

3f-hedspi.net 18 key process areas (KPAs) for CMM

Để giải quyết vấn đề thực tế trong khung cảnh công nghiệp, người kỹ sư phần mềm hay một tổ chức các kỹ sư phải hợp nhất vào một chiến lược phát triển bao quát cả các tầng tiến trình, phương pháp và công cụ cùng các pha thực hiện tổng quát. Chiến lược này thường được nói tới là mô hình tiến trình hay mô thức kỹ nghệ phần mềm. Mô hình tiến trình cho kỹ nghệ phần mềm được lựa chọn dựa trên bản chất dự án và ứng dụng, phương pháp và công cụ được dùng, và việc kiểm soát và chuyển giao được yêu cầu. Mọi việc phát triển phần mềm đểu cóthể được đặc trưng như chu trình giải quyết vần đề (Hình 2.1a) trong đó bốn giai đoạn phân biệt được gặp phải: hiện trạng, định nghĩa vấn đề, phát triển kỹ thuật và tích hợp giải pháp.     Hiện trạng: biểu diễn cho trạng thái hiện thời của sự việc Định nghĩa vấn đề: nhận diện vấn đề đặc biệt cần giải quyết Phát triển kỹ thuật: giải quyết vấn đề qua việc áp dụng công nghệ nào đó Tích hợp giải pháp: Chuyển giao kết quả (tài liệu, chương trình, dữ liệu, chức năng, nghiệp vụ mới, sản phẩm mới) cho những người yêu cầu giải pháp Các pha kỹ nghệ phẩn mềm tổng quát và các bước dễ dàng được ánh xạ và các giai đoạn này.

Kỹ nghệ phần mềm

Page 15

3f-hedspi.net

a Định nghĩa vấn đề

Hiện trạng

Phát triển kỹ thuật

Tích hợp giải pháp

b

Hiện trạng

Hình 2.1(a).Các pha của chu trình giải quyết vấn đề (b). Các pha bên trong chu trình giải quyết vấn đề

Kỹ nghệ phần mềm

Page 16

3f-hedspi.net Chu trình giải quyết vấn đề này áp dụng cho công việc kỹ nghệ phần mềm tại nhiều mức độ giải pháp khác nhau. Nó có thể được dùng tài mức vĩ mô khi toàn bộ ứng dụng được xem xét, tịa mức trung khi cấu trúc trung khi cấu trúc chương trình được đưa và bố trí, và thậm chí tới mức lập trình. Do đó cách biểu diễn lồng nhau có thể được dùng để cung cấp một góc nhìn lý tưởng hóa về tiến trình. Trong hình 2.1b, mỗi giai đoạn trong chu trình giải quyết vấn đề lại chứa chu trình giải quyết vấn đề giống thế, rồi bên trong nó lại chứa chu trình giải quyết vấn đề khác (điều này tiếp tục tới một biên giới hợp lí nào đó; với phần mềm thì tới dòng mã lệnh). Trong thực tế, khó mà đóng gói được thật rõ rệt như hình 2.1b bởi vì có nhiều việc đan chéo bên trong và xuyên ngang các giai đoạn. Vậy góc nhìn đơn giản hóa này dẫn tới một ý tưởng rất quan trọng: bất kể tới mô hình tiến trình nào được chọn cho dự án phần mềm, tất cả các giai đoạn- hiện trạng, định nghĩa vấn đề,phát triển kỹ thuật và tích hợp giải pháp -đều cùng tồn tại đồng thời ở mức độ chi tiết nào đó. Với bản chất đệ quy, bốn giai đoạn trên được áp dụng như nhau cho việc phân tích ứng dụng đầy đủ và cho việc sinh ra các đoạn mã nhỏ. 2.4 Mô hình tuyến tính

kỹ nghệ hệ thống thông tin

Phân tích

Thiết kế

Lập trình

Kiểm thử

Vận hành

Hình 2.2 Mô hình tuyến tính tuần tự Đôi khi còn được gọi là vòng đời cổ điển (classical life circle) hay mô hình thác nước (waterfall model). Được mô hình hóa theo chu kì kỹ nghệ quy ước, mô hình tuần tự tuyến tính bao gồm các hoạt động sau: • Công nghệ học Hệ thống / Thông tin và mô hình hóa (System / Information engineering and modeling): thiết lập các yêu cầu, ánh xạ một số tập con các yêu cầu sang phần mềm trong quá trình tương tác giữa phần cứng, người và CSDL Phân tích yêu cầu (Requirements analysis): hiểu lĩnh vực thông tin, chức năng, hành vi, tính năng và giao diện của phần mềm sẽ phát triển. Cần phải tạo tư liệu và bàn thảo với khách hàng, người dùng

Kỹ nghệ phần mềm

Page 17

3f-hedspi.net • Thiết kế (Design): là quá trình nhiều bước với 4 thuộc tính khác nhau của một chương trình: cấu trúc dữ liệu, kiến trúc phần mềm, biểu diễn giao diện và chi tiết thủ tục (thuật toán). Cần tư liệu hóa và là một phần quan trọng của cấu hình phần mềm Tạo mã / lập trình (Code generation / programming): Chuyển thiết kế thành chương trình máy tính bởi ngôn ngữ nào đó. Nếu thiết kế đã được chi tiết hóa thì lập trình có thể chỉ thuần túy cơ học Kiểm thử (Testing): Kiểm tra các chương trình và môđun cả về lôgic bên trong và chức năng bên ngoài, nhằm phát hiện ra lỗi và đảm bảo với đầu vào xác định thì cho kết quả mong muốn Hỗ trợ / Bảo trì (Support / Maintenance): Đáp ứng những thay đổi, nâng cấp phần mềm đã phát triển do sự thay đổi của môi trường, nhu cầu

• •

Mô hình tuyến tình là mô hình cũ nhất và được sử dụng rộng rãi nhất trong kỹ nghệ phần mềm. Điểm yếu của mô hình tuyến tính  Thực tế các dự án ít khi tuân theo dòng tuần tự của mô hình, mà thường có lặp lại (Như mô hình của Boehm). Mặc dù mô hình tuyến tính có thể cho phép lặp nhưng điều đó chỉ làm gián tiế. Kết quả là những thay đổi có thể g ay ra lẫn lộn khi tổ dự án tiến hành. Khách hàng ít khi tuyên bố rõ ràng khi nào xong hết các yêu cầu Khach hàng phải kiên nhẫn. Bản làm việc của chương trình chỉ có được vào lúc cuối của thời gian dự án. Một sai lầm ngớ ngẩn, nếu đến khi có chương trinhfl àm việc mới phát hiện ra có thể sẽ là một thảm họa.

 

Trong một phân tích thú vị về các dự án, Bradax thấy rằng bnar chất của tuyến tính của vòng đời cổ điển dãn tới " các trạng thái tắc nghẽn" mà trong đó một số thành viên của tổ dự án phải đới các thành việc khác của tổ hoàn thành các nhiệm vụ phụ thuộc. Trong thực tế, thời gian mất cho việc chờ đợi có thể vượt quá thời gian dành cho công việc sản xuất! Trạng thái nghẽ có khuynh hướng phổ biến vào lúc đầu và lúc cuối của tiến trình tuần tự tuyến tính. Nhận xét Tuy nhiên mô thức vòng đời cổ điển có một vị trí quan trọng và xác định trong công việc về kỹ nghệ phần mềm. Nó đưa ra một tiêu bản trong đó có thể bố trí các phương pháp cho phân tích, thiết kế, mã hóa, kiểm thử và bảo trì. Bên cạnh đó, Vòng đời cổ điển vẫn còn là mộ mô hình thủ tục được dùng rộng rãi cho kỹ nghệ phần mềm. Trong khí nó quả thực vẫn còn điểm yếu, nó vẫn tốt hơn đáng kể nếu so với cách tiếp cận ngẫu nhiên tới việc phát triến phần mềm.

• •

2.5 Mô hình chế thử (Prototyping Model) Mô hình chế thử được sử dụng khi : Khi mới rõ mục đích chung chung của phần mềm, chưa rõ chi tiết đầu vào hay xử lý ra sao hoặc chưa rõ yêu cầu đầu ra Dùng như “Hệ sơ khai” để thu thập yêu cầu người dùng qua các thiết kế nhanh

Kỹ nghệ phần mềm

Page 18

3f-hedspi.net Các giải thuật, kỹ thuật dùng làm bản mẫu có thể chưa nhanh, chưa tốt, miễn là có mẫu để thảo luận gợi yêu cầu của người dùng Các giai đoạn  Mô thức làm bản mẫu bắt đầu với việc thụ thập yêu cầu khác hàng. Người phát triển và khách hàng phải gặp nhau và xác định các mục tiêu tổng thể cho phần mềm, xác định các yêu cầu nào đã biết và miền nào bắt buộc phải xác định thêm.  Thiết kế nhanh tập trung vào việc biểu diễn các khía cạnh cuản phần mềm thấy được đối với người dùng( như cách đưa vào và định dạng đưa ra). Thiết kế nhanh dẫn tới việc xây dựng một bnar mẫu.  Bản mẫu được người dùng đánh giá và làm mịn để yêu cầu đối với phần mềm càn phát triển.  Tiến trình lặp đi lặp lại để bản mẫu được vi chỉnh thỏa mãn nhu cầu của khách hàng trong khi đồng thời làm cho người phát triển hiểu kỹ hơn về cần phải thực hiện nhu cầu nào. Một cách lý tưởng, bản mẫu phục vụ như một cơ chế để xác định yêu cầu phần mềm. Nếu một bản mãu làm việc được xây dựng thì người phát triển có thể dùng được các đoạn chương trình đã có hay áp dụng các công cụ (như sinh báo cáo , bộ quản lý cửa sổ...) để nhanh chóng đưa chương trình ra làm việc. Hình 2.3 Mô thức làm bản mẫu •

Nghe khách hàng trình bày

Tạo/ sửa bản mẫu

Khác kiểm tra bản mẫu

Kỹ nghệ phần mềm

Page 19

3f-hedspi.net
Bản mẫu có thể phục vụ như "hệ đầu tiên" - cái mà Brook lưu ý chúng ta nên vứt đi. Nhưng điều này có thể là một cách nhìn lý tưởng hóa. Gióng như mô hình tuyến tính tuần tự, việc làm bản mẫu tựu như một mô thức cho kỹ nghệ phần mềm có thể trở thành vấn đề với những lý do sau: Khác hàng thấy được cái dường như là phiên bản làm việc của phần mềm mà không biết rằng bản mẫu được gắn lại "bằng kẹo cao su và dây gói hàng", không biết rằng trong khi xô đẩy để cho nó làm việc thì chẳng ai xem xét tới chất lượng phần mềm tổng thể hay tính bảo trì thời gian dài. Khi được thông báo rằng sản phầm phải được xây dựng lại để có thể đạt tới mức độ chất lượng cao, thì khách hàng kêu trời và đòi hỏi "phải ít sửa chữa" để làm bản mẫu thành sản phẩm làm việc. Thường như vậy việc quản lý phát triển phần mềm sẽ bị buông lỏng  Người phát triển thường hay thỏa hiệp cài đặt để có được bản mẫu làm việc nhanh chóng. HĐH hay NNLT không thích hợp có thể được dùng đơn giản bởi vì nó có sẵn và đã biết; một thuật toán không hiệu quả có thể được cài đặt để chứng tỏ khả năng. Sau một thời gian, người phát triển mới có thể trở nên quen thuộc với những lựa chọn này và quên mất mọi lí do tại sao chúng lại không thích hợp. Việc lựa chọn không theo lý tưởng bây giờ lại trở thành một phần tích hợp của hệ thống. Mặc dù vấn để có thể xuất hiện, việc làm bản mẫu có thể làm ột mô thức hiệu quả cho kỹ nghệ phần mềm. Chìa khóa là đinh nghĩa ra các quy tắc cửa trò chơi ngay từ lúc bắt đầu; tức là khách hàng và người phát triển phải cùng đồng ý rằng bản mẫu được xây dựng để phục vụ làm cơ chế xác định yêu cầu. Thể rồi nó phải bị loại bỏ đi (ít nhất cũng một phần) và phần mềm thực tại được đưa vào kỹ nghệ với con mắt hường về chất lượng và bảo trì được. 

2.5Mô hình gia tăng(The incremental model) • • • • Kết hợp mô hình tuần tự và ý tưởng lặp lại của chế bản mẫu Sản phẩm lõi với những yêu cầu cơ bản nhất của hệ thống được phát triển Các chức năng với những yêu cầu khác được phát triển thêm sau (gia tăng) Lặp lại quy trình để hoàn thiện dần

Kỹ nghệ phần mềm

Page 20

3f-hedspi.net

Ví dụ: Phẩn mềm xử lý văn bản: o o o o lần tăng đầu: quản lý tệp cơ sở, soạn thảo, các chức năng sản xuất văn bản lần tăng thứ hai:sạn thảo và những khả năng tạo văn bản phức tạp hơn lần tăng thứ ba:kiểm tra chính tả và văn phạm lần tăng thứ tư:bố trí trang phức tạp

Luồng tiến trình này cho bất kì lần tăng nào có thể tổ hợp mô thức làm bản mẫu. Lần tăng đầu thường là sản phẩm lõi( tức là có đủ các yêu cầu cơ bản, nhưng các tính năng phụ chưa được chuyển giao). Sản phẩm lõi được khách hàng sử dụng và dánh giá→Bản kế hoạch chi tiết cho lần tăng tiếp. Bản kế hoạch này gồm: sửa đổi sản phẩm lõi để đáp ứng tốt hơn nhu cầu khách hàng và việc chuyển giao các tính năng , chức năng phụ. Tiến trình được lặp đi lặp lại tiếp sau việc chuyển giao từng lần tăng, cho tới khi sản phầm hoàn chính được tạo ra. Nhận xét Mô hình tăng dần, giống như làm bản mẫu và các cách tiếp cận tiến hóa khác, về bản chất mang tính lặp. Nhung không giống như làm bản mẫu, mô hình tăng dần hội tụ và việc chuyển giao sản phầm vận hạnh với từng việc tăng lên. Những việc tăng ban đầu được trượt dần xuống phiền bản của sản phẩm cuối cùng, nhưng chúng quả có cung cấp khả năng phục vụ cho người cùng và cũng cung cấp một nền tản cho người dùng đánh giá. Phát triển không tăng dần đặc biệt hữu dụng khi nhân viên không sẵn để thực hiện đầy đủ theo thạn chót nghiệp vụ đã được thiết lập cho dự án. Nhưng việc tăng ban đầu có thể được thực hiện với ít người hơn. Nếu sản phẩm lõi được đón nhận tốt, thì nhân viên phụ (nếu cần) có thể được bổ sung để thực hiện việc tăng tiếp theo. Bên cạnh đó, việc tăng có thể được lập kế hoạch để quản lý các rủi ro kỹ thuật. Kỹ nghệ phần mềm Page 21

3f-hedspi.net Chẳng hạn, hệ thống chính có thể đòi hỏi việc sẵn có của phần cứng mới còn đang được phát triển và ngày chuyển giao còn chưa chắc chắn. Có thể lập kế hoạch tăng sớm theo cách tránh việc dùng phần cứng này, do đó tạo khả năng chức năng bộ phần được chuyển giao cho người dùng cuối mà không bị chậm trễ bất thường.

Phần II Yêu cầu người dùngUser’s Requirements
Chương 3: Phương pháp xác định yêu cầu 3.1. 3.2. 3.3. Kỹ thuật xác định yêu cầu Nội dung xác định yêu cầu Các nguyên lý phân tích yêu cầu

3.1. Kỹ thuật xác định yêu cầu phần mềm (SW Requirements Engineering) • Yêu cầu phần mềm: là tất cả các yêu cầu về phầm mềm do khách hàng - người sử dụng phần mềm - nêu ra, bao gồm: các chức năng của phần mềm, hiệu năng của phần mềm, các yêu cầu về thiết kế và giao diện, các yêu cầu đặc biệt khác Thông thường các yêu cầu phần mềm được phân loại theo 4 thành phần của phần mềm: Các yêu cầu về phần mềm (Software) Các yêu cầu về phần cứng (Hardware) Các yêu cầu về dữ liệu (Data) Các yêu cầu về con người (People, Users) • Mục đích: mục đích của yêu cầu phần mềm là xác định được phần mềm đáp ứng được các yêu cầu và mong muốn của khách hàng - người sử dụng phần mềm

Tại sao cần phải đặt ra yêu cầu phần mềm  Khách hàng chỉ có những ý tưởng mơ hồ về phần mềm cần phải xây dựng để phục vụ công việc của họ, chúng ta phải sẵn sàng, kiên trì theo đuổi để đi từ các ý tưởng mơ hồ dó đến "Phần mềm có đầy đủ các tính năng cần thiết". Khách hàng rất hay thay đổi các đỏi hỏi của mình, chúng ta cần nắm bắt được các thay đổi đó và sửa đổi các mô tả một cách hợp lý

3.2. Nội dung xác định yêu cầu phần mềm (Contents of Requirements Engineering) Kỹ nghệ phần mềm

Page 22

3f-hedspi.net • • • • • • Phát hiện các yêu cầu phần mềm (Requirements elicitation) Phân tích các yêu cầu phần mềm và thương lượng với khách hàng (Requirements analysis and negotiation) Mô tả các yêu cầu phần mềm (Requirements specification) Mô hình hóa hệ thống (System modeling) Kiểm tra tính hợp lý các yêu cầu phần mềm (Requirements validation) Quản trị các yêu cầu phần mềm (Requirements management)

Quy trình xác định yêu cầu phần mềm

The Analysis Model

Kỹ nghệ phần mềm

Page 23

3f-hedspi.net

3.2.1. Phát hiện yêu cầu phần mềm (Requirements Elicitation) Các vấn đề của phát hiện yêu cầu phần mềm (Problems) • • • Phạm vi của phần mềm (Scope) Hiểu rõ phần mềm (Understanding) Các thay đổi của hệ thống (Volatility)

Phương pháp phát hiện yêu cầu phần mềm (Requirements Elicitation Methodology) • • • • • • Xác định các phương pháp sử dụng phát hiện các yêu cầu phần mềm: phỏng vấn, làm việc nhóm, các buổi họp, gặp gỡ đối tác, v.v. Tìm kiếm các nhân sự (chuyên gia, người sử dụng) có những hiểu biết sâu sắc nhất, chi tiết nhất về hệ thống giúp chúng ta xác định yêu cầu phần mềm Xác định “môi trường kỹ thuật - technical environment” Xác định các “ràng buộc lĩnh vực domain constraints” Thu hút sự tham gia của nhiều chuyên gia, khách hàng để chúng ta có được các quan điểm xem xét phần mềm khác nhau từ phía khách hàng Thiết kế các kịch bản sử dụng của phần mềm

Sản phẩm (output) của “phát hiện yêu cầu phần mềm” • • • • • • Bảng kê (statement) các đòi hỏi và chức năng khả thi của phần mềm Bảng kê phạm vi ứng dụng của phần mềm Mô tả môi trường kỹ thuật của phần mềm Bảng kê tập hợp các kịch bản sử dụng của phần mềm Các nguyên mẫu xây dựng, phát triển hay sử dụng trong phần mềm (nếu có) Danh sách nhân sự tham gia vào quá trình phát hiện các yêu cầu phần mềm - kể cả các nhân sự từ phía công ty- khách hàng

3.2.2. Phân tích các yêu cầu phần mềm và thương lượng với khách hàng

Kỹ nghệ phần mềm

Page 24

3f-hedspi.net

Requirements Analysis and Negotiation • • • • • • • • Phân loại các yêu cầu phần mềm và sắp xếp chúng theo các nhóm liên quan Khảo sát tỉ mỉ từng yêu cầu phần mềm trong mối quan hệ của nó với các yêu cầu phần mềm khác Thẩm định từng yêu cầu phần mềm theo các tính chất: phù hợp, đầy đủ, rõ ràng, không trùng lặp Phân tích các nhu cầu phần mềm dựa trên nhu cầu và đòi hỏi của khách hàng, người sử dụng Thẩm định cho từng yêu cầu phần mềm để xấy dựng chúng có khả năng thực hiện được trong môi trường kĩ thuật hay không, có khả năng kiểm định hay không Thẩm định các rủi ro cso thể xảy ra với từng yêu cầu phần mềm Đánh giá thô (tương đối) về giá thành và thời gian thực hiện của từng yêu cầu phần mềm trong giá thành sản phẩm phần mềm và thời gian thực hiện phần mềm Giải quyết tất cả các bất đồng vè yêu cầu phần mềm với khách hàng, người sử dụng trên cơ sở thảo luận và thương lượng các yêu cầu đề ra

3.2.3. Đặc tả yêu cầu phần mềm • Đặc tả các yêu cầu phần mềm là công việc xây dựng các tài liệu đặc tả, trong đó có thể sử dụng tới các công cụ như: mô hình hóa, mô hình toán học hình thức (a formal mathematical model), tập hợp các kịch bản sử dụng, các nguyên mẫu hoặc bất kỳ một tổ hợp các công cụ nói trên Chất lượng của hồ sơ đặc tả đánh giá qua các tiêu thức – – Tính rõ ràng, chính xác Tính phù hợp Page 25

Kỹ nghệ phần mềm

3f-hedspi.net – Tính đầy đủ, hoàn thiện

Requirements Specification • Đặc tả chức năng (Operational Specifications) Thông thường khi đặc tả các chức năng của SW người ta sử dụng các công cụ tiêu biểu sau – – – • Biểu đồ luồng dữ liệu (Dât a Flow Diagrams) Máy trạng thái hữu hạn (Finite State Machines) Mạng Petri (Petre nets)

Đặc tả mô tả (Descriptive Specifications) – – – Biểu đồ thực thể liên kết (Entity-Relationship Diagrams) Đặc tả Logic (Logic Specifications) Đặc tả đại số (Algebraic Specifications)

• •

Hệ thống (System): tập hợp các dữ liệu (data) được xử lý bằng các chức năng tương ứng (functions) Các ký pháp sử dụng: Thể hiện các chức năng (functions) Thể hiện luồng dữ liệu Kho dữ liệu

Vào ra dữ liệu và tương tác giữa hệ thống và người sử dụng

Ví dụ mô tả biểu thức toán học bằng DFD

Kỹ nghệ phần mềm

Page 26

3f-hedspi.net

Ví dụ đặc tả các chức năng của thư viện qua DFD

Kỹ nghệ phần mềm

Page 27

3f-hedspi.net Các hạn chế của DFD • ý nghĩa của các ký pháp sử dụng được xác định bởi các định danh lựa chọn của NSD

Ví dụ của chức năng tìm kiếm: If NSD nhập vào cả tên tác giả và tiêu đề sách Then tìm kiếm sách tương ứng, không có thì thông báo lỗi Elseif chỉ nhập tên tác giả Then hiển thị danh sách các sách tương ứng với tên tác giả đã nhập và yêu cầu NSD lựa chọn sách Elseif chỉ nhập tiêu đề sách Then ... Endif

Trong DFD không xác định rõ các hướng thực hiện (control aspects) A E

B

D

C •

F

Biểu đồ DFD này không chỉ rõ đầu vào là gì để thực hiện chức năng D và đầu ra là gì sau khi thựchiện chức năng D. • • • • • Chức năng D có thể cần cả A, B và C Chức năng D có thể chỉ cần một trong A, B và C để thực hiện Chức năng D có thể kết xuất kết quả cho một trong E và F Chức năng D có thể kết xuất kết quả chung cho cả E và F Chức năng D có thể kết xuất kết quả riêng cho cả E và F

Kỹ nghệ phần mềm

Page 28

3f-hedspi.net 3.3. Các nguyên lý phân tích yêu cầu sử dụng • Nguyên lý I. Mô hình hóa dữ liệu – – – • Xác định các đối tượng dữ liệu Xác định các đặc tính của các đối tượng dữ liệu Thiết lập các mối quan hệ giữa các đối tượng dữ liệu

Nguyên lý II. Mô hình hóa các chức năng – – – Xác định các chức năng chuyển đổi đối tượng dữ liệu Chỉ ra luồng dữ liệu đi qua hệ thống như thế nào Biểu diễn bộ phận sản sinh dữ liệu và bộ phận tiêu thụ dữ liệu

Nguyên lý III. Mô hình hóa hành vi – – Chỉ ra các trạng thái (states) khác nhau của hệ thống Đặc tả các hiện tượng (events) làm hệ thống thay đổi trạng thái

Nguyên lý IV. Partition the Models Tinh lọc từng mô hình để biểu diễn các mức trừu tượng thấp hơn

• • • •

Lọc đối tượng dữ liệu Tạo ra phân cấp chức năng Biểu diễn hành vi (behavior) ở các mức chi tiết khác nhau Nguyên lý V. Bản chất (Essence) Hãy bắt đầu bằng cách tập trung vào bản chất của vấn đề chứ không xem xét những chi tiết cài đặt (begin by focusing on the essence of the problem without regard to implementation details)

Phần III

Chương 4: Kỹ thuật thiết kế chương trình 4.1 Thiết kế chương trình là gì ? Kỹ nghệ phần mềm

Page 29

3f-hedspi.net 4.2 Phương pháp thiết kế chương trình 4.3 Công cụ thiết kế 4.1 Thiết kế chương trình là gì ? • • • Là thiết kế chi tiết cấu trúc bên trong của phần mềm: thiết kế tính năng từng môđun và giao diện tương ứng Cấu trúc ngoài của phần mềm: thiết kế hệ thống Trình tự xử lý bên trong: Thuật toán (giải thuật, Algorithm); Logic

4.2 Phương pháp thiết kế chương trình • • • • Không có trạng thái mờ (fuzzy), để đảm bảo thiết kế cấu trúc trong đúng đắn Ngôn ngữ lập trình phù hợp Triển khai đúng đắn đặc tả chức năng các môđun và chương trình nhờ phương pháp luận thiết kế chi tiết Dùng quy trình thiết kế dễ chuẩn hóa từng bước

Kỹ thuật thiết kế chương trình Kỹ thuật thiết kế mô hình hệ phần mềm • • • Hướng tiển trình (process): Kỹ thuật thiết kế cấu trúc điều khiển Hướng cấu trúc dữ liệu (Data): Kỹ thuật thiết kế cấu trúc dữ liệu Hướng sự vật đối tượng (Object): Kỹ thuật thiết kế hướng đối tượng

4.2.1 Lập trình cấu trúc hóa • • Khái niệm cơ bản: tuần tự, nhánh (chọn), lặp; cấu trúc mở rộng, tiền xử lý, hậu xử lý Những điểm lợi khi thiết kế thuật toán: – Tính độc lập của mô đun : chỉ quan tâm vào ra – Làm cho chương trình dễ hiểu – Dễ theo dõi chương trình thực hiện – Hệ phức tạp sẽ dễ hiểu nhờ tiếp cận phân cấp

Loại bỏ GOTO • GOTO dùng để làm gì? – • Cho phép thực hiện các bước nhảy đến một nhãn nhất định

Tại sao cần loại bỏ GOTO ? – Phá vỡ tính cấu trúc của lập trình cấu trúc hóa Page 30

Kỹ nghệ phần mềm

3f-hedspi.net • • • Phương pháp loại bỏ GOTO Có thể loại bỏ GOTO trong mọi trường hợp? Thế nào là “kỹ năng lập trình cấu trúc”

Lưu ý khi thiết kế chương trình • • • Phụ thuộc vào kỹ năng và kinh nghiệm của người thiết kế Cần chuẩn hóa tài liệu đặc tả thiết kế chi tiết Khi thiết kế cấu trúc điều khiển của giải thuật, vì theo các quy ước cấu trúc hóa nên đôi khi tính sáng tạo của người thiết kế bị hạn chế, bó buộc theo khuôn mẫu đã có

4.2.2 Lưu đồ cấu trúc hóa • • • • Tác dụng của lưu đồ (flow chart) Quy phạm (discipline) Trừu tượng hóa thủ tục Lưu đồ cấu trúc hóa – – – • Cấu trúc điều khiển cơ bản Chi tiết hóa từng bước giải thuật Thể hiện được trình tự điều khiển thực hiện

Lưu đồ Nassi-Shneiderman (NS chart by IBM)

Kỹ nghệ phần mềm

Page 31

3f-hedspi.net • Lưu đồ Phân tích bài toán (PAD chart by Hitachi)

4.2.3 Về Phương pháp Giắc-sơn (Jackson’s method) • • JSP: Jackson Structured Programming Các ký pháp: – – – – Cơ sở (elementary) Tuần tự (sequence) Lặp Rẽ nhánh

Trình tự thiết kế chung • • • • Thiết kế cấu trúc dữ liệu (Data step) Thiết kế cấu trúc chương trình (Program step) Thiết kế thủ tục (Operation step) Thiết kế đặc tả chương trình (Text step)

4.2.4 Về Phương pháp Wa-ny (Warnier’s method) • • Khái niệm chung Trình tự thiết kế – – Thiết kế dữ liệu ra Thiết kế dữ liệu vào

Kỹ nghệ phần mềm

Page 32

3f-hedspi.net – – – – Thiết kế cấu trúc chương trình Thiết kế lưu đồ Thiết kế lệnh thủ tục Thiết kế đặc tả chi tiết

Phần IV Kiểm thử và bảo trì Chương 5: Kiểm thử

5.1 Khái niệm kiểm thử Định nghĩa kiểm thử: • • • Là mấu chốt của đảm bảo chất lượng phần mềm Là tiến trình (và là nghệ thuật) nhằm phát hiện lỗi bằng việc xem xét lại đặc tả, thiết kế và mã hoá. Kiểm thử thành công là phát hiện ra lỗi; kiểm thử không phát hiện ra lỗi là kiểm thử dở (Sue A.Conger- The New SE)

Những khó khăn khi kiểm thử • • • • Nâng cao chất lượng phần mềm nhưng không vượt quá chất lượng khi thiết kế: chỉ phát hiện các lỗi tiềm tàng và sửa chúng Phát hiện lỗi bị hạn chế do thủ công là chính Dễ bị ảnh hưởng tâm lý khi kiểm thử Khó đảm bảo tính đầy đủ của kiểm thử

6 điểm lưu ý khi kiểm thử (1) Chất lượng phần mềm do khâu thiết kế quyết định là chủ yếu, chứ không phải khâu kiểm thử (2) Tính dễ kiểm thử phụ thuộc vào cấu trúc chương trình (3) Người kiểm thử và người phát triển nên khác nhau (4) Dữ liệu thử cho kết quả bình thường thì không có ý nghĩa nhiều, cần có những dữ liệu kiểm thử mà phát hiện ra lỗi Kỹ nghệ phần mềm Page 33

3f-hedspi.net (5) Khi thiết kế trường hợp thử, không chỉ dữ liệu kiểm thử nhập vào, mà phải thiết kế trước cả dữ liệu kết quả sẽ có (6) Khi phát sinh thêm trường hợp thử thì nên thử lại những trường hợp thử trướcđó để tránh ảnh hưởng lan truyền sóng Tương ứng giữa vòng đời dự án và kiểm thử

5.2 Phương pháp thử: thử tĩnh • • • Kiểm thử trên bàn hay Kiểm thử tĩnh: giấy và bút trên bàn, kiểm tra logic, lần từng chi tiết ngay sau khi lập trình xong Đi xuyên suốt (walk through) Thanh tra (inspection)

Kiểm thử trên máy • • • • • • Gỡ lỗi bằng máy (machine debug) hay kiểm thử động: Dùng máy chạy chương trình để điều tra trạng thái từng động tác của chương trình 9 bước của trình tự kiểm thử bằng máy (1) Thiết kế trường hợp thử theo thử trên bàn (2) Trường hợp thử phải có cả kết quả kỳ vọng sẽ thu được (3) Dịch chương trình nguồn và tạo môđun tải để thực hiện (4) Khi trường hợp thử có xử lý tệp vào-ra, phải làm trước trên bàn việc xác định miền của các tệp

Kỹ nghệ phần mềm

Page 34

3f-hedspi.net • • • • • (5) Nhập dữ liệu đã thiết kế cho trường hợp kiểm thử (6) Điều chỉnh môi trường thực hiện môđun tải (tạo thủ tục đưa các tệp truy cập tệp vào chương trình) (7) Thực hiện môđun tải và ghi nhận kết quả (8) Xác nhận kết quả với kết quả kỳ vọng (9) Lặp lại thao tác (5)-(8)

5.3 Kiểm thử đơn vị Kiểm thử đơn vị được tiếng hành tại những giai đoạn sớm nhất trong pha kiểm thử. Mục tiêu là kiểm thử từng mô đun 5.3.1 Đại cương và mục đích của kiểm thử đơn vị Kiểm thử đơn vị được tiến hành cho từng mô đun, đơn vị nhỏ nhát bên trong hệ thống đang xây dựng. Múc đích là kiểm chứng lại công việc đã được làm trong pha lập trình. Trong kiểm thử đơn vị thực tế, việc kiểm chứng được thực hiện để xem liệu các chức năng mô đun có tương ứng với các đặc tả mô đun hay không. Sau khi các mô đung đã được móc nối và tích hợp vào mức hệ thống chương trình, thì một số lớn công việc cần làm là loại bỏ lỗi. Để tránh điều này, lỗi trước hết phải được lại bỏ khỏi từng mô đun trong giai đoạn kiểm thử đơn vị, trước khi các mô đun được tích hợp lại. 5.3.2 Phương pháp kiểm thử vàKỹ thuật thiết kế trường hợp thử a. Phương pháp kiểm thử Về nguyên tắc, kiểm thử hộp đen thường được tiến hành. Kiêm thử hộp trắng được tiến hành nếu cần. – – Kiểm thử hộp trắng(còn gọi là kiểm thử hộp trong): chú ý chính được dồn vào cấu trúc bên trong Kiểm thử hộp đen: chú ý chính được dồn bào giao diện (cái vào và caisra) giữa các mô đun

b.Thiết kế trường hợp kiểm thử Trước khi kiểm thử chương trình, phải chuẩn bị các trường hợp kiểm thử (dữ liệu kiểm thử). Đó là một nhân tố quan trọng cần xét tới vì nó ảnh hưởng tới kết quả của việc kiểm thử, hay thậm chí còn xác định ra chất lượng của hệ thống. Để thiết kế các trường hợp kiểm thử tối ưu, nếu có sẵn một hướng dẫn nào đó (tại liệu thiết kế trường hợp kiểm thử) thì sẽ rất có ích. Bằng cách tích lũy các dữ liệu và xem lại tài liệu thiết kế trường hợp kiểm thử, tổ chức phát triển có thể cất giữ cách làm để cải tiến chất lượng phần mềm, và dùng nó như là một phương tiện để truyền dữ liệu sang giai đoạn lập trình tiếp. Kiểm thử hộp đen Kỹ nghệ phần mềm Page 35

3f-hedspi.net • • • Phân đoạn tương đương Phân tích giá trị biên Đoán lỗi

Phương pháp phân đoạn tương đương (Equivalence Partition) • • • Mục đích: giảm số lượng test bằng cách chọn các tập dữ liệu đại diện Thực hiện: Chia dữ kiệu vào thành các đoạn, mỗi đoạn đại diện cho một số dữ liệu => việc kiểm thử chỉ thực hiện trên đại diện đó ưu điểm: Test theo mức trừu tượng hơn là trường. áp dụng: màn hình, menu hay mức quá trình

Phương pháp phân tích giá trị biên(Boundary value analysis) • • • Là 1 trường hợp riêng của phân đoạn Thí dụ: nếu miền dữ liệu là tháng thì giá trị 0 hay >12 là không hợp lệ Thường sử dụng trong kiểm thử môđun

Phương pháp đoán lỗi(Error Guessing) • • • Dựa vào trực giác và kinh nghiệm Thí dụ lỗi chia cho 0. Nếu môđun có phép chia thì phải kiểm thử lỗi này Nhược điểm: không phát hiện hết lỗi

Phương pháp đồ thị nguyên nhân - kết quả (Cause-effect Graphing)

Kỹ nghệ phần mềm

Page 36

3f-hedspi.net

Kiểm thử hộp trắng • • • • Bó các lệnh Bó các rẽ nhánh Bó các điều kiện Bó các điều kiện - rẽ nhánh

5.4 Kiểm thử tích hợp Kiểm thử tích hợp được tiến hành sau khi kiểm thử đơn vị đã được hoàn tất. Chúng được dự định để kiểm chứng lại những công việc đã được tiến hành trong các pha thiết kế chương trình và thiết kế chương trình. 5.4.1Đại cương và mục đích của kiểm thử tích hợp Kiểm thử tích hợp được tiến hành để kiểm chứng rằng có nhiều mô đung có thể vận hành đúng khi được nối với các mô đun khác có liên quan. Trong khi tiến hành việc kiểm thử này, chú ý chính được dành cho giao diện giữa các mô đung (giao diện giữa các chương trình). Cho dù không tìm thấy vấn đề gì trong kiểm thử đơn vị, lỗi vẫn thường xuất hiện khi các mô đun được nối lại. Nếu lỗi xuất hiện trong kiểm thử tích hợp thì bạn phải quay lui trở về tiến trình trước và sửa vấn đề. Hãy nhớ rằng bạn cũng phải sửa chữa tài liệu thiết kế. Trước khi tiến hành kiểm thử tích hợp, phải định nghĩa rõ ràng các mô đun được nối theo thứ tự nào và khi nào. 5.4.2Cuống và khiển trình Trong giai đoạn lập trình phát triển của hệ thống, chương trình có một cấu trúc phân cấp bao gồm nhiều mô đun. Do đó, việc mã hóa được thực hiện cho từng mô đun riêng và các mô dun cấp cao hay cấp thấp được cần tới để kiểm chứng sự vận hành bình thường của các mô đun đã xây dựng. Trong kiểm thử thực tế, các mô đun câm được gọi là cuống hay khiển trình sẽ dùng tới. Kỹ nghệ phần mềm

Page 37

3f-hedspi.net – – Cuống(stub): Một chương trình dành cho kiểm thử để cung cấp các chức năng của mô đun mức thấp Khiển trình (driver): Một chương trình dành cho kiểm thử để cung cấp các chức năng của các mô đun cấp cao Mô đun đã hoàn thành kiểm thử Cuống:

Mô đun cần kiể m thử

Mô đun cần kiểm thử

Cuống Khiển trình

Cuống

Khiển trình

Mô đun cần kiểm thử

Mô đun cần kiểm thử

Mô đun đã kiểm thử

Mô đun đã kiểm thử

Hình 5.1 Cuống và khiển trình

Kỹ nghệ phần mềm

Page 38

3f-hedspi.net

Hình 5.2 Ví dụ về cuống

Mô đun cần kiểm thử

CALL "S" USING X, Y

<S>
Cuống Cuống cho lại giá trị

5.4.3. Kiểm thử tăng dần Trong kiểm thử tăng dần, các mô đun có việc kiểm thử dã được hoàn tất sẽ được móc nối với các mô đun khác. Kiểm thử tăng dần được phân loại đại thể thành 3 kiểm thử được nêu dưới đây:    Kiểm thử trên xuống (Top down test) Kiểm thử dưới lên (Bottom up test) Kiểm thử tổ hợp (Sandwich test)

Đặc trưng     Thích hợp cho kiểm thử chương trình kích cỡ lớn Cần dùng các mô đun kiểm thử (mô đun câm) như các cuống và khiển trình thày vì các mô đun chưa hoàn thành Kết của của việc kiểm thử có thể thay đổi, tùy theo các mô đun được móc nối theo trình tự nào Dễ theo dõi dấu vết lỗi về nguyên nhân

5.4.3.1 Kiểm thử trên xuống (Top down test) Kiểm thử trên xuống được dùng để phát triển hệ thống theo thứ tự các mô đun từ mô đun cao tới mô đun thấp( được gọi là lập trình trên xuống) • • • Môđun điều khiển chính được dùng như trình điều khiển kiểm thử, gắn các nút con trực tiếp vào nó Thay các nút con bằng các môđun thực tại (theo chiều sâu / ngang) Kiểm thử từng môđun được gắn vào Page 39

Kỹ nghệ phần mềm

3f-hedspi.net • • Các 1 nút thử xong được thử tiếp nút khác Kiểm thử hồi quy

Đặc trưng  Mô đun cao nhất (mô đun lõi hay mô đun có logic) trước hết được móc nối với mô đun cao nhất tiếp đó và tất cả các mô đun khác cũng được móc nối giống như thế trheo trình tự các mô đun từ mức cao tới thấp Các mô đun quan trọng được kiểm thử thường xuyên hơn các mô đun kém quan trọng, do vậy làm tăng độ tin cậy của giao diện giữa các mô đun cấp cao Tiên điều kiện cho việc kiểm thử này là ở chỗ bản thân chương trình phải được tạo ra băng việc dùng thiết kế có cấu trúc Bởi vì mô đun cấp cao với một số nhỏ các chương trình là được phát triển trước, nên khó làm việc lập trình và tiến hành kiểm thử song song Thích hợp cho việc phát triển hệ thống mới Xem như hệ thông (chương trình kiểm thử), cần dùng tới nhiều cuống

    

5.4.3.2 Kiểm thử dưới lên (Bottom up test) Kiểm thử dưới lên dùng để phát triển hệ thống theo trình tự các mô đun từ mô đun mức thấp tới các mô đun mức cao (gọi là lập trình dưới lên) • • • • Các môđun mức thấp được tổ hợp vào các chùm thực hiện một chức năng con Viết trình điều khiển phối hợp vào/ ra và kiểm thử Kiểm thử chùm/bó Loại bỏ trình điều khiển và chuyển lên mức trên

Kỹ nghệ phần mềm

Page 40

3f-hedspi.net

Đặc trưng      Kiểm thử được tiến hành bằng việc móc nối các mô đun theo trình tự mô đun mức thấp tới cao Khi kiểm thử tích hợp đã được hoàn tất, thì chương trình cso thể dược kiểm thử theo điều kiện vận hành thực tế Bởi vì các mô đun mức thấp với một số lượng lớn chương trình là được phát triển trước hết, nên có thể làm việc lập trình và tiến hành kiểm thử song song tại giai đoạn khởi đầu Xem như hệ thống (chương trình) kiểm thử, cần có khiển trình Thích hợp cho việc phát triển một phiên bản sửa đổi của hệ thống hiện tại

5.4.3.3 Kiểm thử tổ hợp (Sandwich test) Là việc tổ hợp của các kiểm thử trên xuống và dưới lên. Các kiểm thử trên xuống và dưới lên được tiến hành đồng thời cho tới khi đạt tới lẳn ranh thỏa hiệp đã định sẵn Đặc trưng      Nhánh độc lập : trên xuống Nhánh phức tạp: dưới lên Vì các kiểm thử trên xuống và dưới lên có thể được tiến hành đồng thời, nên các kiểm thử có thể được hoàn tất trong thời gian ngắn hơn nhiều Phần khung của chương trình có thể được kiểm thử dễ dàng Xem như hệ thống (chương trình) kiểm thử, thì cả cuống và khiển trình đều được cần tới

5.4.4Kiểm thử không tăng dần Trong kiểm thử này, tất cả các mô đun có việc kiểm thử đơn vị dã được hoàn tất đều được móc nối và cho chạy. Kiểm thử không tăng đại diện là kiểm thử Big Bung (Big Bang) Đặc trưng   Thích hợp cho việc kiểm thử chương trình kích cỡ nhỏ Không cần tới cuống hay khiển trình Page 41

Kỹ nghệ phần mềm

3f-hedspi.net  Nếu lỗi xuất hiện thì khó dò dầu vết chúng ngược về nguyên nhân

Kiểm thử Big Bang Kiểm thử Big Bang dùng kĩ thuật của việc thực hiện kiểm thử đơn vị trước hết trên mọi mô đun, rồi móc nối chúng tất cả lại một lúc và thực hiện kiểm thử tích hợp toàn bộ Đặc trưng    Bởi vì kiểm thử này được tiến hành sau kiểm thử đơn vị nên kết quả có độ tin cậy cao Để thực hiện kiểm thử móc nối thì cuống hay khiển trình là không cần thiết Các mô đung có thể được kiểm thử tất cả ngay một lúc

5.5 Kiểm thử hệ thống Sau khi các mô đun đươc móc nối với nhau đã được kiểm thử thì các kiểm thử được tiến hành theo trình tự của từng chương trình, rồi kiểm thử cho từng hệ con một, và cuối cùng kiểm thử cho toàn bộ hệ thống. Các kiểm thử được tiến hành sau kiểm thử tích hợp được gọi là kiểm thử hệ thống. 5.5.1 Tổng quan về kiểm thử hệ thống Kiểm thử hệ thống được tiến hành để kiểm chứng sự thích hợp với thiết kết ngoài. Trong việc tiến hành kiểm thử này, phần lớn chú ý được dành cho giao diện giữa các hệ con. Kiểm thử hệ thống được gọi là kiểm thử toàn diện, và được tiến hành bởi một nhóm chuyên gia kiểm thử. Nó là kiểm thử cuối cùng được tiến hành bởi tổ chức phát triển hệ thống

Hệ thống

Ch.tr Ch.tr Ch.tr

Ch.tr Ch.tr Ch.tr Ch.tr

Ch.tr Ch.tr Ch.tr

H ệ c o n

Chương trình được tích hợp toàn bộ hệ thống và kiểm thử Kỹ nghệ phần mềm

Page 42

3f-hedspi.net Hình 5.4 Phạm vi của kiểm thử hệ thống 5.5.2 Các kiểu kiêm thử hệ thống Kiểm thử hệ thống được tiến hành để kiểm tra các chức năng và hiệu năng từ nhiều góc độ khác nhau được nêu dưới đây 1. Kiểm thư tích hợp chương trình / hệ con Các chương trình được móc nối với nhau, và các hệ con được móc nối với nhau, và các hệ con và giao diện giữa các chương trình được kiểm thư 2. Kiểm thử chức năng Kiểm thử này được tiến hành để kiểm chứng liệu các yêu cầu chức năng của người dùng có được đáp ứng hay không 3. Kiểm thử hiệu năng Kiểm thử này được tiến hành để kiểm chứng thời giàn đáp ừng và các khoản mục hiệu năng khác 4. Kiểm thử vận hành Giao diện con người (GUI) và các điểm khác liên quan tới vận hành được kiểm tra để kiểm chứng 5. Kiểm thử phục hồi Cách thức hệ thống phục hồi hỏng hóc và thực hiện lại các chức năng đã được kiểm thử 6. Kiểm thử tải Kiểm thử này được tiến hành để kiểm tra hiệu năn, chức năng của hệ thống khi một khối lượng lớn dữ liệu được đưa và một lúc, hay khi một tải lớn được áp vào hệ thống 7. Kiểm thử ngoại lệ Kiểm thử này được tiến hành để kiểm chứng răng hệ thống có thẻ giải quyết thích hợp cho các dữ liệu không thích hợp khi được đưa vào 8. Kiểm thử chịu đựng Kiểm thử này được tiến hành để kiểm chứng rằng một hệ thống có thể đứng vững nhiều giờ làm việc liên tục Chương 6 Phương pháp bảo trì (Maintenance Methods) 6.1 Khái niệm • Định nghĩa: Bảo trì là công việc tu sửa, thay đổi phần mềm đã được phát triển (chương trình, dữ liệu, JCL, các loại tư liệu đặc tả, . . .) theo những lý do nào đó • Các hình thái bảo trì: bảo trì để – Tu chỉnh – Thích hợp – Cải tiến – Phòng ngừa • Vì sao phải bảo trì – Mã nguồn cần thay đổi : phải thêm các mở rộng, phải tối ưu hóa ... – Điều kiện hoạt động thay đổi (phần cứng, HĐH ... ) – xuất hiện lỗi – nhu cầu người dùng thay đổi ... Kỹ nghệ phần mềm Page 43

3f-hedspi.net

a. Bảo trì để tu sửa (Corrective Mainternance) • • Là bảo trì khắc phục những khiếm khuyết có trong phần mềm Một số nguyên nhân điển hình – – – – • • Kỹ sư phần mềm và khách hiểu nhầm nhau Lỗi tiềm ẩn của phần mềm do sơ ý của lập trình hoặc khi kiểm thử chưa bao quát hết Vấn đề tính năng của phần mềm: không đáp ứng được yêu cầu về bộ nhớ, tệp, . . . Thiết kế sai, biên tập sai . . . Thiếu chuẩn hóa trong phát triển phần mềm (trước đó) dò lại thiết kế để tu sửa

Kỹ nghệ ngược (Reverse Engineering): Những lưu ý – – – – Mức trừu tượng Tính đầy đủ Tính tương tác Tính định hướng

b.Bảo trì để thích hợp (Adaptive Mainternance) • • • Là tu chỉnh phần mềm theo thay đổi của môi trường bên ngoài nhằm duy trì và quản lý phần mềm theo vòng đời của nó Thay đổi phần mềm thích nghi với môi trường: công nghệ phần cứng, môi trường phần mềm Những nguyên nhân chính: – – – Thay đổi về phần cứng (ngoại vi, máy chủ,. . .) Thay đổi về phần mềm (môi trường): đổi OS Thay đổi cấu trúc tệp hoặc mở rộng CSDL

c.Bảo trì để cải tiến (Perfective Mainternance) • • Là việc tu chỉnh hệ phần mềm theo các yêu cầu ngày càng hoàn thiện hơn, đầy đủ hơn, hợp lý hơn Những nguyên nhân chính: – – Do muốn nâng cao hiệu suất nên thường hay cải tiến phương thức truy cập tệp Mở rộng thêm chức năng mới cho hệ thống Page 44

Kỹ nghệ phần mềm

3f-hedspi.net – – • • • Cải tiến quản lý kéo theo cải tiến tư liệu vận hành và trình tự công việc Thay đổi người dùng hoặc thay đổi thao tác

Còn gọi là tái kỹ nghệ (re-engineering) Mục đích: đưa ra một thiết kế cùng chức năng nhưng có chất lượng cao hơn Các bước thực hiện: – – – – Xây dựng lưu đồ phần mềm Suy dẫn ra biểu thức Bun cho từng dãy xử lý Biên dịch bảng chân lí Tái cấu trúc phần mềm

d.Bảo tri để phòng ngừa(Preventive Mainternance) • • • • • • • Là công việc tu chỉnh chương trình có tính đến tương lai của phần mềm đó sẽ mở rộng và thay đổi như thế nào Thực ra trong khi thiết kế phần mềm đã phải tính đến tính mở rộng của nó, nên thực tế ít khi ta gặp bảo trì phòng ngừa nếu như phần mềm được thiết kế tốt Mục đích: sửa đổi để thích hợp với yêu cầu thay đổi sẽ có của người dùng Thực hiện những thay đổi trên thiết kế không tường minh Hiểu hoạt động bên trong chương trình Thiết kế / lập trình lại Sử dụng công cụ CASE

Kỹ nghệ phần mềm

Page 45

3f-hedspi.net Bổ sung Sơ đồ có cấu trúc Với các lưu đồ, có thể mô tả các thuật toán dựa trên định lý cấu trúc. Tuy nhiên, việc dùng các kí hiệu mũi tên trong lưu đồ (nói cách khác, cho phép dùng các câu lệnh GOTO) có thể dẫn tới sinh ra thuật toán phi cấu trúc. Mặt khác, trong các sơ đồ có cấu trúc, các thuật toán được mô tả mà không dùng ký hiệu mũi tên nào (hay lệnh GOTO). Do đó, các mô tả dựa trên định lý cấu trúc là có thể dùng được. Các sơ đồ có cấu trúc bào gồm các kiểu sau đây: – – – NASS PAD SPD (không xét)

1.NASS (Sơ đồ Nassi - Shneiderman) NASS sơ đồ dùng các kí hiệu đặc biệt có các cấu trúc điều khiển cho việc biểu diễn <Cấu trúc tuần tự> Cấu trúc lặp (kiểu DO WHILE) Xử lý 1 Xử lý 1 Cấu trúc lặp (kiểu Repeat Until) Xử lý 1

Cấu trúc tuyển chọn

Cấu trúc CASE

Điều kiện True Xử lí 1 False

ĐK1

Điều kiện

Xử lí 1
Xử lí 2

ĐK2
Xử lí 2

ĐK3 Xử lí 3

Kỹ nghệ phần mềm

Page 46

3f-hedspi.net PAD (Problem Analysis Diagram - Biểu đồ phân tich vấn đề PAD mô tả cho cấu trúc logic của thuật toán bằng cây Cấu trúc tuần tự Cấu trúc CASE P1 Xử lý 1 Xử lí 1 P2 Xử lý 2 Điều kiện Cấu trúc tuyển chọn Xử lý 3 P3

Xử lý 2

P4 True Điều kiện Xử lý 1 Xử lý 4

Xử lý 2
False

Cấu trúc lặp (kiểu DO WHILE)

Cấu trúc lặp (kiểu REPEAT UNTIL)

Điều kiện WHILE

Xử llí l

Xử lí 1

Điều kiện UNTILL

Kỹ nghệ phần mềm

Page 47

Sign up to vote on this title
UsefulNot useful