SE

Chương I

PHẦN MỀM

VÀ CÁC VẤN ĐỀ LIÊN QUAN

Nội dung

1.1. Một số quan điểm về phần mềm

1.2. Hai cách nhìn về cấu trúc phần mềm?

1.3. Đặc tính chung của phần mềm

1.4. Tiêu chí của một phần mềm tốt ?

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

1.6. Một số vấn đề trong phát triển phần mềm

Trải qua một thời gian khá dài, nhận thưc về phần mềm hay nói đầy đủ hơn là phần mềm máy tính (Computer Software) đã có những thay đổi và ngày càng được thống nhất và chuẩn hoá trên phạm vi toàn cầu. Song hành với nó là ngành Công nghệ phần mềm: nghiên cứu về qui trình hay vòng đời phần mềm, các mô hình, các phương pháp và các công cụ trong phát triển phần mềm máy tính cũng được tập trung nghiên cứu một cách hệ thống và chuẩn.

Để hiểu đúng và đầy đủ về khái niệm phần mềm và các vấn đề gặp phải trong sản xuất phần mềm, chúng tôi sẽ đề cập trong chương I của tài liệu. Chương II sẽ tập trung trình bày về qui trình, phương pháp, các mô hình và các công cụ.

1.1 Một số quan điểm 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à đến nay cao hơn HW rất nhiều

HW SW

Vật "cứng" Vật "mềm"

Kim loại Kỹ thuật sử dụng

Vật chất Trừu tượng

Hữu hình Vô hình

Sản xuất công nghiệp bởi máy móc là chính Sản xuất bởi con người là chính

Định lượng là chính Định tính là chính

Hỏng hóc, hao mòn Không hao mòn

• Có khá nhiều định nghĩa vè phần mềm. Ta xét 2 định nghĩa sau:

Đị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

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. Phần mềm là:

- 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.

Kết luận

Phần mềm gồm:

- 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

Bao trùm lên tất cả là kinh nghiệm kĩ sư (know-how)

1.2 Hai cách nhìn về cấu trúc phần mềm

Phần mềm là hàng hoá vô hình, không nhìn thấy, song nó là sản phẩm mà các nhà phát triển phần mềm cần chế tác, phát triển. Do vậy, cần có cái nhìn đúng về kiến trúc của nó. Người ta thường đề cập đến 2 kiến trúc sau:

- Kiến trúc phân cấp

- Kiến trúc thủ tục

1.2.1 Phần mềm nhìn từ cấu trúc phân cấp

Trong cách nhìn này, người ta tiếp cận theo quan điểm hệ thống. Mức trên nhất, phần mềm là một hệ thống phức tạp, dưới nó là các hệ thống con. Và dưới các hệ thống con là các chương trình và dưới nữa là các mô đun và các Subroutine (Hình 2).

1.2.2 Phần mềm nhìn từ cấu trúc thủ tục

Kiến trúc thủ tục cho chúng ta xác định được mối quan hệ giữa các trình tự (các thành phần) mà phần mềm đó có. Nó được thể hiện bởi cá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). Nó cũng 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. Cần lưu ý là thiết kế cấu trúc trước rồi sang chức năng

1.3 Đặc tính chung của phần mềm

Phần mềm là một loại sản phẩm và có những đặc thù riêng. Người ta thường lưu tâm đến các đặc tính sau:

• 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 chữ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 và 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 tác giả 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

• Phần mềm có thể sao chép rất đơn giản

1.4 Tiêu chí của một phần mềm tốt

Để dánh giá chất lượng phần mềm, người ta đưa ra các tiêu chí có tính định tính như chỉ ra trên hình 3 dưới đây.

1.5 Phân loại phần mềm

- Phần mềm cơ bản: phần mềm 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, quản lý các tiến trình, các tài nguyên của hệ thống, ví dụ như các Hệ điều hành các máy PC, Hệ điều hành mạng,...Rõ ràng với loại phần mềm này thì yêu cầu quan trọng là tính chính xác, độ ổn định cao và tính dung lỗi.

- Phần mềm ứng dụng: dùng để xử lý nghiệp vụ thích hợp nào đó như quản lý, kế toán, . . ., đáp ứng yêu cầu nghiệp vụ người dùng. Người ta nói những phần mềm này là phần mềm làm ra sản phẩm thông tin.

Một cách phân loại khác:

• 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 Khoa học và Kỹ thuật (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)

1.6 Một số vấn đề trong phát triển phần mềm

1.6.1 Khủng hoảng phần mềm là gì ?

Phần mềm thì khủng hoảng hiểu theo nghĩa nào và vì sao nó lại xuất hiện? Người ta cho rằng khủng hoảng trong phần mềm được hiểu theo nghiã khác với nghĩa thông thường. Đó là vấn đề liên quan đến chất lượng, qui trình, tốc độ của các hệ thống dựa vào máy tính và các sản phẩm được phát triển chỉ đơn giản là sự chậm trễ, sự thay đổi có tính tiến hoá, sự bùng nổ của công nghệ một cách đột phát, được thay đổi liên quan đến phần mềm.

" Khủng hoảng" nói theo ngôn ngữ của các nhà sản xuất phần mềm và hàng loạt các vấn đề cần giải quyết:

• Phải làm thế nào với việc giảm chất lượng vì những lỗi tiềm tàng có trong phần mềm ?

• Phải xử lý ra sao khi bảo dưỡng phần mềm đã có ?

• Phải giải quyết thế nào khi thiếu kỹ thuật viên phần mềm?

• Phải chế tác phần mềm ra sao khi có yêu cầu phát triển theo qui cách mới xuất hiện ?

• Phải xử lý ra sao khi sự cố phần mềm gây ra những vấn đề xã hội ?

Hình 4 dưới đây đưa ra sự so sánh về chi phí sản xuất cho phần cứng và phần mềm:

1.6.2 Những khó khăn trong sản xuất phần mềm

Theo các nhà nghiên cứu, có 14 vấn đề khó khăn trong sản xuất phần mềm:

1- Không có phương pháp mô tả rõ ràng định nghĩa yêu cầu của người dùng - khách hàng, sau khi bàn giao sản phẩm dễ phát sinh những trục trặc.

2- Với những phần mềm quy mô lớn, tư liệu đặc tả đã cố định thời gian dài, do vậy khó đáp ứng nhu cầu thay đổi của người dùng một cách kịp thời trong thời gian đó.

3- Nếu không có phương pháp luận thiết kế nhất quán mà thiết kế theo cách riêng của công ty, nhóm, thì sẽ dẫn đến suy giảm chất lượng phần mềm do phụ thuộc quá nhiều vào con người.

4- Nếu không có chuẩn về làm tư liệu quy trình sản xuất phần mềm, thì những đặc tả không rõ ràng sẽ làm giảm chất lượng phần mềm.

5- Nếu không kiểm thử tính đúng đắn của phần mềm ở từng giai đoạn mà chỉ kiểm thử ở giai đoạn cuối và phát hiện ra lỗi, thì thường bàn giao sản phẩm không đúng hạn.

6- Nếu coi trọng việc lập trình hơn khâu thiết kế thì thường dẫn đến làm giảm chất lượng phần mềm.

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

8- Phần lớn trong quy trình phát triển phần mềm có nhiều thao tác do con người thực hiện, do vậy năng suất lao động thường bị giảm.

9- Không chứng minh được tính đúng đắn của phần mềm, do vậy độ tin cậy của phần mềm sẽ giảm.

10- Chuẩn về một phần mềm tốt không thể đo được một cách định lượng, do vậy không thể đánh giá được một hệ thống đúng đắn hay không?

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

12- Công việc bảo trì kéo dài làm giảm chất lượng của tư liệu và ảnh hưởng xấu đến những việc khác.

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

14- Không có tiêu chuẩn để ước lượng nhân lực và dự toán sẽ làm kéo dài thời hạn và vượt kinh phí của dự án .

Chương 2

CÔNG NGHỆ PHẦN MỀM: KHÁI NIỆM, QUI TRÌNH - MÔ HÌNH PHÁT TRIỂN

Nội dung

2.1. Công nghệ phần mềm

2.2 Các mô hình phát triển phần mềm

2.1. Công nghệ phần mềm

2.1.1 Công nghệ phần mềm là gì?

Công nghệ phần mềm là một công nghệ phân tầng. Có nhiều định nghiã khác nhau về Công nghệ phần mềm, song ở đây ta xét 2 định nghĩa tiêu biểu:

- Định nghĩa 1: Công nghệ phần mềm là sự nghiên cứu những nguyên tắc công nghệ đúng đắn nhằm tạo ra phần mềm một cách kinh tế, tin cậy và làm việc hiệu quả trên các máy thực. [BAU69]

- Định nghĩa 2: Công nghệ phần mềm là:

1) Sự áp dụng một cách tiếp cận định lượng, có qui trình và có tính hệ thống nhằm phát triển, vận hành và duy trì phần mềm

2) Nghiên cứu các phương pháp tiếp cận sự dụng trong 1) [IEEE'93]

Như vậy, "Công nghệ 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 ".

Để hiểu rõ về công nghệ phần mềm, người ta phân nó thành 4 tầng (H 2.1) : tầng chất lương, tầng qui trình, tầng phương pháp và tầng công cụ.

Nền tảng của Công nghệ phần mềm là qui trình. Qui trình định nghĩa một khung làm việc cho một tập các qui trình chủ yếu (KPA - Key Process Area). Nó tạo nên các cơ sở để quản lý các dự án phần mềm và thiết lập các ngữ cảnh để áp dụng các phương pháp kỹ thuật: mô hình, dữ liệu, báo biểu,...

Phương pháp phần mềm nhằm cung cấp các kỹ thuật để chế tác phần mềm bao gồm:

- Phân tích yêu cầu người dùng

- Thiết kế hệ thống

- Lập trình

- Kiểm thử

- Bảo trì

Công cụ phần mềm nhằm cung cấp các hỗ trợ tự động, bán tự động cho qui trình và phương pháp phần mềm. Khi các công cụ được tích hợp, thông tin tạo bởi các công cụ này có thể được sử dụng bởi các công cụ khác, thí dụ như thiết kế có sự hỗ trợ.

2.1.2 Vòng đời của phần mềm

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 Công nghệ phần mềm.

Vòng đời phần mềm là thời kỳ tính từ khi phần mềm được sinh ra cho đến khi chết đi (từ lúc hình thành đáp ứng yêu cầu, vận hành, bảo dưỡng cho đến khi loại bỏ không dùng nữa)

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 tiêu biểu là mô hình thác nước (WaterFall Model) do Boehm đề xuất.

2.2 Các mô hình phát triển phần mềm

Trong việc sản xuất phần mềm, phụ thuộc vào đặc trưng của các phần mềm cần chế tác mà nhà phát triển sử dụng các mô hình phát triển khác nhau: có mô hình thì tuyến tính, cái khác lại lặp, cái khác thì lại gia tăng, tiến hoá,.... Trong phần dưới đây chúng ta sẽ xem xét 10 mô hình phát triển tiêu biểu.

2.2.1 Mô hình tuyến tính

Mô hình tuyến tính hay còn gọi là tuần tự (Hình 2.4) khi mà các pha được thực hiện một cách kế tiếp nhau, hết pha này đến pha khác. Đây là mô hình thác nước kinh điển.

- Kỹ nghệ Hệ thống thông tin và mô hình hóa (Information System Engineering and Modeling) nhằm 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 dùng con người và cơ sở dữ liệu.

2.2.2 Mô hình chế thử (Prototyping Model)

Trong thực tế, không phải lúc nào cũng có sẵn các nhu cầu về phần mềm từ khía khách hàng. Các doanh nghiệp phần mềm cần chủ động tạo các kích thích, các nhu cầu cho khách hàng. Một mô hình khá thích hơp cho cách tiếp cận này là mô hình chế thử (Prototyping Model- Hình 2.5)

Theo mô hình này, bản mẫu được thiết kế như một "hệ sơ khai" nhằm thâu tóm yêu cầu người dùng. Vì thế, các bản mẫu cần được thiết kế nhanh, đơn giản, chưa cần tốt miễn sao thu thập được ý kiến của khách hàng về sản phẩm sẽ được sản xuất mà họ chưa hình dung ra được.

Mô hình này cũng bộc lộ một số hạn chế:

i) Cần một đội ngũ đông đảo để chia thành các nhóm

ii) Giao kèo phải chặt chẽ, nếu không dự án có thể bị đổ bể

iii) Các ứng dụng phải có tính mô đun hoá

iv) Các ứng dụng có tính mạo hiểm cao thì không nên dùng.

2.2.4 Các mô hình tiến hóa: tiến hoá, xoắn ốc, phát triển đồng thời

Cách làm này sử dụng một qui trình lặp, cho phép các kỹ sư phần mềm phát triển tăng dần, các phiên bản sau sẽ hoàn thiện hơn phiên bản trước sau mỗi một chu trình lặp. Trong phần dưới đây chúng ta sẽ xem xét 3 mô hình: Mô hình gia tăng, mô hình xoắn ốc và mô hình phát triển đồng thời.

2.2.4.1 Mô hình gia tăng (Incremental Model)

Mô hình gia tăng là sự kết hợp các yếu tố của mô hình tuyến tính với ý tưởng lặp của mô hình chế thử. Mỗi mạch tuyến tính của qui trình cung cấp một sản phẩm (Hình 2.7). Mạch đầu tiên cung cấp một số chức năng cơ bản nào đó, mạch tiếp theo sẽ gia tăng thêm một số chức năng khác,... mạch cuối cùng cung cấp một sản phẩm hoàn thiện, đáp ứng yêu cầu người dùng. Tuy rằng trong mô hình này, các kỹ sư phần mềm áp dụng tư tưởng lặp của mô hình chế thử song nó lại khác cơ bản về sản phẩm. Mỗi mạch của nó tạo ra một sản phẩm dùng được trong khi mô hình chế thử thì không quan tâm ngay đến sản phẩm.

2.2.5 Mô hình thuần thục chức năng (CMM - Capability Maturity Model)

CMM có 5 mức (level):trong mỗi mức có thể được phân ra các key process area (KPA) tổng cộng có 18 KPA.

Mức 1: Initial (Khởi đầu): Tiến trình phần mềm mang tính chất tùy tiện, lộn xộn, có ít tiến trình được xác định trước, hiệu quả của công việc mang tính riêng lẻ. Khó có được một môi trường làm việc ổn định và ngân sách, chất lượng sản phẩm và vận hành không thể dự toán trước được. Quá trình vàn hành phụ thuộc vào khả năng của từng cá nhân riêng lẻ, và thường xuyên đổi do phụ thuộc vào kỹ năng, trình độ hiểu biết và các hoạt động của từng thành viên trong dự án.

Không có KPA.

Mức 2: Repeatable (Lặp): Có sự cải tiến hơn, chiến lược quản lý dự án và thủ tục để thực thi chiến lược ấy được thiết lập. các kế hoạch và quản lý tiến trình của một dự án mới được dựa trên những kinh nghiệm của dự án cũ. Kết quả là đưa được những hiệu quả quản lý tiến trình của một dự án quy vào dự án khác. Điều này cho phép lặp lại những thành công đối với một dự án tương tự mặc dù có thể các dự án này cũng có những điểm khác biệt.

Mức này có 6 KPA:

Mức 3 Defined (Xác định): Lập được tài liệu tiến trình tiêu chuẩn đối với việc phát triển và bảo trì phần mềm có tổ chức, bao gồm cả công nghệ phần mềm, các tiến trình quản lý, và các tiến trình tích hợp với nhau (nghĩa rằng đầu ra là một tiến trình sẽ là đầu vào của tiến trình tiếp theo)

Một tiến trình được định nghĩa tốt gồm có các tính chất như có tiêu chuẩn đầu vào, tiêu chuẩn và thủ tục rõ ràng để tiến hành công việc, kiểm tra các đầu ra.

Mức này có 7 KPA.

Mức 4 Managed (Quản trị): Mục tiêu là điều khiển tiến trình. Các tiến trình phần mềm được quản lý để vận hành ổn định, an toàn. Có những đánh giá phần mềm và chất lượng, hiệu quả các hoạt động trong tiến trình. Do các tiến trình ổn định và được đánh giá nên khi có các trường hợp ngoại lệ, sẽ xác định và chỉ rõ những nguyên nhân gây ra biến đổi.

Mức này có 2 KPA

Mức 5 Optimizing (Tối ưu): Tiếp tục cải tiến tiến trình, có thể xác định được những điểm mạnh và điểm yếu của tiến trình, có khả năng phân tích các khiếm khuyết, xác định các nguyên nhân gây ra có tránh các khiếm khuyết này.

Mức này có 3KPA

2.2.10 Sản phẩm và Qui trình

Như đã mô tả ở phần trên, qui trình là tập các mô hình, phương pháp, công nghệ và công cụ được áp dụng trong phát triển phần mềm. Sản phẩm là cái đích, là kết quả thu được sau khi áp dụng qui trình. Sản phẩm là phần mềm phải đáp ứng các yêu cầu của khách hàng-người sử dụng phần mềm đó.

Sản phẩm và qui trình có mối quan hệ nhân quả với nhau. Nếu qui trình yếu thì sản phẩm làm ra sẽ không có chất lượng như mong muốn. Qui trình tốt sẽ cho sản phẩm tốt, song cũng không hoàn toàn như vậy.

Kết luận: Công nghệ phần mềm là một lĩnh vực tích hợp các qui trình, phương pháp, công nghệ và công cụ để phát triển phần mềm máy tính. Nhiều qui trình được đề xuất và mỗi qui trình đều có những mặt mạnh và những điểm hạn chế, song cũng có các điểm chung. Việc áp dụng qui trình nào phụ thuộc vào tính chất phần mềm sẽ phát triến và đặc thù của cácc doanh nghiệp phần mềm.

6

ĐẶC TẢ YÊU CẦU NGƯỜI DÙNG

Nội dung

6.1 Yêu cầu người dùng là gì ?

6.3 Nội dung và Qui trình xác định yêu cầu

6.4 Phương pháp và công cụ đặc tả

6.5 Ứng dụng các nguyên lý phân tích yêu cầu

6.1 Yêu cầu người dùng là gì ?

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

6.2 Nh÷ng vÊn ®Ò trong xác ®Þnh yªu cÇu người dùng

• Khách hàng chỉ có những ý tưởng còn 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ồ đó đế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 nắm bắt được các thay đổi đó và sửa đổi các mô tả một cách hợp lý

6.3 Nội dung và Qui trình xác định yªu cÇu

6.3.1 Nội dung

• 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)

6.3.2 Qui trình

Từ các vẫn đề đặt ra ->làm sáng tỏ các yêu cầu cụ thể -> tiến hành 2 con đường:

->Xây dựng 1 mẫu thử

-> Tạo 1 mô hình Phân tích

Sau đó Phát triển các chi tiết kĩ thuật-> review.

6.3.3 Mô hình phân tích

6.4 Phương pháp và công cụ đặc tả

• Đặ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

- Tính đầy đủ, hoàn thiện

• Có 2 kiểu đặc tả: phi hình thức và hình thức.

- Đặc tả phi hình thức (Informal specifications) được viết bằng ngôn ngữ tự nhiên

- Đặc tả hình thức (Formal specifications) được viết bằng tập các ký pháp có các quy định về cú pháp (syntax) và ý nghĩa (sematic) rất chặt chẽ, thí dụ ký pháp đồ họa dùng các lưu đồ.

• Hai khía cạnh trong phần mềm phải dadực tả đó là đặc tả vận hành chức năng/chức năng và đặc tả mô tả/phi chức năng:

- Đặc tả vận hành chức năng (Operational specifications) mô tả các hoạt động của hệ thống phần mềm sẽ xây dựng: Các dịch vụ mà hệ thống phải cung cấp, hệ thống sẽ phản ứng với đầu vào cụ thể ra sao, Hành vi của hệ thống trong các tình huống đặc biệt.

- Đặc tả mô tả hay đặc tả phi chức năng (Descriptive specifications) - đặc tả các đặc tính, đặc trưng của phần mềm: các ràng buộc về các dịch vụ hay các chức năng hệ thống cung cấp như thời gian, ràng buộc về các quá trình phát triển, các chuẩn,...

• Đặc tả chức năng (Funtional Specifications):

i) Miêu tả các chức năng của hệ thống, phụ thuộc vào kiểu PM và mong đợi của người dùng

ii) Thông thường khi đặc tả các chức năng của phần mềm người ta sử dụng các công cụ tiêu biểu sau:

- Biểu đồ luồng dữ liệu (Data Flow Diagrams)

- Máy trạng thái hữu hạn (Finite State Machines

- Mạng Petri (Petri nets),...

Tuy nhiên không bắt buộc và có thể dùng ngôn ngữ tự nhiên.

• Đặc tả phi chức năng (Non-Funtional Specifications):

i) Định nghĩa các tính chất của hệ thống, các ràng buộc, thí dụ như độ tin cậy, thời gian trả lời, dung lượng bộ nhớ,...

ii) Các yêu cầu do tổ chức qui định như qui định chuẩn về quá trình tiến hành, chuẩn tài liệu,...

iii, Các yêu cầu từ ngoài

Đặc tả mô tả thường sử dụng các công cụ:

- Biểu đồ thực thể liên kết (Entity-Relationship Diagrams)

- Đặc tả Logic (Logic Specifications)

- Đặc tả đại số (Algebraic Specifications)

Nhìn chung đặc tả phi chức năng rất khó phát biểu chính xác và rất khó kiểm tra. Trong khuôn khổ tài liệu này chúng tôi chỉ đề cập đến đặc tả dữ liệu.

6.4.1 Đặc tả chức năng bằng sơ đồ luồng dữ liệu DFD

• Biểu đồ luồng dữ liệu: là một công cụ cho phép diễn tả một quá trình xử lý thông tin (một chức năng) với các yêu cầu sau:

- Có thể áp dụng ở 2 mức độ: lôgic và vật lý.

- Chỉ rõ các chức năng con phải thực hiện để hoàn tất quá trình xử lý thông tin

- Chỉ rõ các thông tin được chuyển giao giữa các chức năng và cho phép hình dung trình tự thực hiện của chúng.

• Trong kiểu đặc tả này, phần mềm được coi là một Hệ thống (System) gồm 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:

- Chức năng (functions): biểu diễn bởi vòng tròn

Trong chứa tên chức năng và thường là động từ

- Luồng dữ liệu: biểu diễn bằng mũi tên một/hai chiều.

Chiều mũi tên chỉ chiều vận động của lưồng thông tin

- Kho dữ liệu: Nơi lưu trữ dữ liệu tạm thời hay lâu dài

cho xử lý và được biểu diễn bởi 2 gạch song song bên

trong có tên. Tên kho là danh từ + tính từ

- Bộ phận vào ra dữ liệu: biểu diễn sự tương tác giữa

hệ thống và người sử dụng. Cách biểu diễn là khá khác

nhau theo qui ước.

Biểu đồ lường dữ liệu có thể phân mức. Nguyên tắc phân mức được chỉ ra trong phần nguyên lý phân tích dưới đây.

 Các hạn chế của DFD

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

- DFD không xác định sự đồng bộ giữa các chức năng / mô-đun

6.5 Ứng dụng các nguyên lý phân tích yêu cầu

Trong quá trình phân tích, đặc tả yêu cầu phần mềm, người ta thường áp dụng 5 nguyên lý được trình bày dưới đây.

6.5.1 Nguyên lý mô hình hoá dữ liệu

- Xác định các đối tượng dữ liệu: các đối tượng thoả định nghĩa ở trên và thường ở các nguồn sau: con người, tài nguyên, sổ sách có cấu trúc và các giao dịch

- Xác định các đặc tính của các đối tượng dữ liệu: Phụ thuộc vào bản chất bài toán

- Thiết lập các mối quan hệ giữa các đối tượng dữ liệu: các mối quan hệ tự nhiên và do nhu cầu quản lý

6.5.2 Nguyên lý mô hình hoá chức năng

- Xác định các chức năng chuyển đổi đối tượng dữ liệu: xuất phát từ nhu cầu xử lý

- Chỉ ra luồng dữ liệu đi qua hệ thống như thế nào: Qui trình xử lý

- Biểu diễn bộ phận sản sinh dữ liệu và bộ phận tiêu thụ dữ liệu: Các nguồn cung cấp thông tin và thu nhận thông tin (các tác nhân ngoài)

6.5.3 Nguyên lý mô hình hoá 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ý này thường sử dụng cho các hệ thống mà chúng ta mô tả qua tập các trạng thái.

6.5.4 Nguyên lý mô hình phân rã

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

Đây là nguyên lý rất quan trọng cho phép phân rã để hiểu hệ thống hơn theo kiểu Top-Down

6.5.5 Nguyên lý dựa vào bản chất

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.

Chương 7 THIẾT KẾ CHƯƠNG TRÌNH

7.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. Thực tế bao gồm 2 nhiệm vụ cơ bản:

- Thiết kế giải thuật nhằm thực hiện chức năng mà mô đun đảm nhận

- Thiết kế cấu trúc dữ liệu: các dữ liệu dùng cho mô đun, đáp ứng yêu cầu xử lý

• Đầu vào là các đặc tả của giai đoạn phân tích và thiết kế hệ thống.

• Đầu ra là các mô tả giải thuật. Thường người ta hay dùng ký pháp đồ hoạ. Tuy nhiên không bắt buộc có thể dùng ngôn ngữ diễn tả giải thuật: giả mã, sơ đồ khối hay PDL (ngôn ngữ mô tả chương trình)

7.2 Các phương pháp thiết kế chương trình

Có nhiều kỹ thuật thiết kế chương trình:

- 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.

Ở đây chúng ta tập trung vào phương pháp thiết kế cấu trúc hoá và sử dụng kỹ thuật thiết kế hướng tiến trình - dựa vào các cấu trúc điều khiển.

7.2.1 Thiết kế cấu trúc hóa

Nguyên tắc thiết kế cấu trúc hoá có nguồn gốc từ kỹ thuật lập trình cấu trúc mà bản chất là dựa vào các cấu trúc điều khiển cơ bản: tuần tự, rẽ nhánh và lặp. Lý thuyết đã chứng minh rằng mọi chương trình đều có thể xây dựng được chỉ dựa vào 3 cấu trúc cơ bản trên.

Thiết kế cấu trúc hoá tỏ rõ những ưu điểm:

- 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

Một vấn đề quan trọng trong thiết kế cấu trúc là không được sử dụng cấu trúc nào khác ngoài 3 cấu trúc trên. Thí dụ, một số người có thói quen sử dụng GOTO. Vậy GOTO là gì và loại bỏ GOTO ra sao?

Người ta cho rằng:

- GOTO dùng để chuyển điều khiển (nhảy) đến một nhãn nhất định

- GOTO phá vỡ tính cấu trúc của lập trình cấu trúc hóa và không thể quản lý được

- GOTO có thể loại bỏ được

Tuy nhiên, để tạo điều kiện cho người lập trình không bị quá gò bó vào tính có cấu trúc, người ta vẫn cho phép dung GOTO song rất hạn chế.

Thí dụ dưới đây minh hoạ 1 chương trình Spagetti và chương trình sau sau loại bỏ GOTO.

7.2.2 Sơ đồ cấu trúc hóa Nassi, PAD,...

Lưu đồ Nassi do hãng IBM đề xuất để mô tả giải thuật theo hướng thiết kế cấu trúc. Lưu đồ này dùng 4 ký pháp cơ bản: tuần tự (nối), rẽ nhánh (if .. then ..elsse), rẽ nhiều nhánh và lặp.

Lưu đồ PAD do hãng Hitachi đề xuất. Nó cũng sử dụng 4 thành phần tương tự như trong lưu đồ Nassi, song có thêm 1 trục chính theo chiều thẳng đứng.

Các lưu đồ này được minh hoạ trong trang bên dưới.

Chương 9

KIỂM THỬ PHẦN MỀM

Nội dung

9.1 Khái niệm kiểm thử

9.2 Phương pháp thử

9.3 Các kỹ thuật thiết kế trường hợp thử

9.4 Kiểm thử mô đun

9.5 Kiểm thử hệ thống

9.6 Kiểm thử chấp nhận

9.1 Khái niệm kiểm thử

Kiểm thử là giai đoạn cuối cùng trước khi bàn giai sản phẩm cho khách hàng - người dùng.

9.1.1 Khái niệm kiểm thử

• Vai trò: Là khâu mấu chốt đảm bảo chất lượng phần mềm

• Khái niệ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á.

• Chú ý: 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)

9.1.2 Những khó khăn trong 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ử

9.1.3 Những điểm lưu ý khi thực hiện

(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

(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

9.1.4 Tương ứng giữa vòng đời phần mềm và qui trình kiểm thử

9.2 Phương pháp thử

Người ta phân biệt 2 phương pháp kiểm thử: Kiểm thử trên bàn hay kiểm thử tĩnh và Kiểm thử trên máy hay kiểm thử động. Kiểm thử tĩnh thường được tiến hành trước nhằm tạo ra kịch bản cho kiểm thử động.

9.2.1 Thử trên bàn (thử tĩnh)

Kiểm thử trên bàn hay Kiểm thử tĩnh: với công cụ là giấy, bút và các tài liệu cần thiết: đặc tả yêu cầu, thiết kế và listing và thực hiện trên bàn nhằm kiểm tra logic, lần từng chi tiết ngay sau khi lập trình xong. Có 2 kỹ thuật được sử dụng:

• Đi xuyên suốt (walk through)

• Thanh tra (inspection)

9.2.2 Thử trên máy

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

(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)

9.3 Các kỹ thuật thiết kế trường hợp thử

Người ta thường sử dụng 2 kỹ thuật kiểm thử: Kiểm thử hộp trắng và kiểm thử hộp đen. Hai kỹ thuật kiểm thử này dành cho kiểm thử mô đun. Ngoài ra còn dùng các kỹ thuật khác như Trên xuống (Top Down) và Dưới lên (Bottom Up) cho kiểm thử tích hợp.

9.3.1 Thử hộp đen (What?)

Kiểm thử hộp đen (Black Box testing) là kỹ thuật thiết kế trường hợp thử dựa trên đặc tả bề ngoài của chương trình. Người kiểm thử chỉ quan tâm đến nhiệm vụ mà mô đun phải đảm nhận, đầu vào cho mô đun và kết quả xử lý - đầu ra.

Kiểm thử hộp đen lại chia nhỏ ra nhiều kỹ thuật:

- Phân đoạn tương đương

- Phân tích giá trị biên

- Đoán lỗi

và một số kỹ thuật khác

Black Box Testing

Trong tài liệu này chúng ta quan tâm đến 3 kỹ thuật trên cùng.

1- Kỹ thuật phân đoạn tương đương (Equivalence Partition)

Kỹ thuật dựa vào khái niệm đoạn tương đương. Người ta chia miền dữ liêụ của bài toán thành những đoạn tương đương: có nghĩa là khi dữ liệu thuộc tập này được cung cấp thi mô đun xử lý và cho kết quả có cùng trạng thái. Ví dụ khi phải giải 1 phương trình bậc 2 : ax2 + bx + c = 0 thì tập các hệ số (a, b, c) cho 2 nghiệm tạo thành 1 tập; tập các hệ số (a, b, c) làm cho phương trình vô nghiệm sẽ tạo nên 1 tập tương đương khác,....

- Thực hiện: Chia dữ liệ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 đó.

- 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.

2- Phân tích giá trị biên (Boundary value analysis)

Là một trường hợp riêng của phân đoạn tương đương. Người ta tiến hành thử trên các giá trị biên: cận dưới và cận dưới cộng 1, cận trên và cận trên trừ 1. Thí dụ với dữ liệu ngày tháng, các chỉ số của mảng, các tệp rỗng,...

3- Đoán nhận lỗi (Error Guessing)

- Thường 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. Ngoài ra các lỗi đường dẫn hay môi trường cũng thuộc loại này.

- Nhược điểm: không phát hiện hết lỗi. Tuy nhiên, nó cho phép phát hiện các lỗi sơ ý trong lập trình.

9.3.2 Thử hộp trắng (White Box Testing)

Là kỹ thuật thiết kế trường hợp thử dựa trên đặc tả bên trong của chương trình: Cấu trúc điều khiển, cấu trúc dữ liệu.

• Người kỹ sư phần mềm có thể đảm bảo:

- Kiểm tra tất cả các lộ trình độc lập bên trong một mô đun ít nhất 1 lần

- Kiểm tra tất cả các nhánh đúng/sai của lựa chọn

- Kiểm tra việc thực hiện của vòng lặp tại các biên và bên trong vòng lặp

- Kiểm tra các cấu trúc dữ liệu để đảm bảo tính hợp thức.

• Các kỹ thuật:

- Kiểm thử theo lộ trình (Basis path testing)

- Kiểm thử theo cấu trúc điều khiển.

Ở đây chỉ giới thiệu kỹ thuật kiểm thử theo lộ trình độc lập.

Kiểm thử theo lộ trình là kỹ thuật do Tom McCabe đề xuất cho phép nhà kiểm thử tiến hành một số đo về độ phức tạp lô gic của các thủ tục và số đo này được sử dụng để giúp cho việc định nghĩa các lộ trình cơ bản sao cho các lệnh trong chương trình được thực hiện ít nhất một lần trong quá trình kiểm thử. Kỹ thuật này sử dụng Ký pháp đồ hoạ luồng/ đồ thị chương trình. Một đồ thị luồng chương trình là một đồ thị mà:

- Mỗi nút đồ thị biểu diễn 1 lệnh/ 1 dãy lệnh liên tiếp

- Cung của đồ thị biểu diễn luồng điều khiển (trình tự thực hiện).

Thí dụ, sơ đồ khối quá trình thực hiện 1 mô đun được mô tả như hình vẽ:

Thì đồ thị luồng chương trình có dạng:

Chú ý

- Một cung bao giờ cũng phải kết thúc tại 1 nút (có thể nút này không tương ứng với bất kỳ lệnh nào trong thủ tục - nút predicat).

- Vùng bao bởi các cung và nút gọi là Region (khi tính, ta phải tính cả vùng bao ngoài).

Thí dụ đồ thị chương trình trên gồm 4 vùng (các số màu đỏ).

- Với điều kiện phức tạp (nhiều hơn 1 phép so sánh) thì mỗi so sánh lại tách thành 1 nút riêng.

Thí dụ: If a OR b then X else Y Endif

Độ phức tạp lặp (Cyclomatic Complexity)

Độ phức tạp lặp là 1 số đo phần mềm, cung cấp 1 đơn vị đo định lượng về độ phức tạp lô gic của CT. Trong ngữ cảnh áp dụng kiểm thử theo lộ trình, giá trị này sẽ cung cấp số lượng các lộ trình (path) độc lập trong 1 chương trình và đó được coi như là cận trên của số lượng test phải tiến hành để đảm bảo mọi lệnh đều được thực hiện ít nhất 1 lần.

- Lộ trình độc lập? là 1 phần của chương trình bao gồm ít nhất một tập lệnh hay 1 điều khiển mới.

Đồ thị chương trình trên có 4 lộ trình độc lập: 1-11; 1-2-3-4-5-10-1-11; 1-2-3-6-8-9-10-1-11; 1-2-3-6-7-9-10-1-11

• Có 3 cách tính độ phức tạp lặp ký hiệu V(G):

1) V(G) = E - N +2, với E là số cung, N là số nút của G

2) V(G) = số vùng (region)

3) V(G) = P +1, với P là số lượng nút Predicat (nút giả định, không có thật

Xét thí dụ:

1- Số lộ trình độc lập (độ phức tạp lặp) = 6

1-2-10-11-13; 1-2-10-12-13

1-2-3-10-11-13; 1-2-3-4-5-8-9-2 ...

1-2-3-4-5-6-8-9-2...; 1-2-3-4-5-6-7-8-9-2...

...: có nghĩa là phần tiếp theo còn lại đồ thị là chấp nhận được.

2- Đồ thị chương trình : Sinh viên tự vẽ coi như bài tập

3- Số test phải thực hiện: 6

9.4 Phương pháp thử các môđun

Để kiểm thử một phần mềm, người ta tiến hành kiểm thử theo trình tự sau:

• Kiểm thử môđun

• Kiểm thử tích hợp

• Kiểm thử hệ thống

• Kiểm thử chấp nhận ( Testing)

9.4.1 Kiểm thử mô đun

Được tiến hành một cách độc lập từng mô đun theo các kỹ thuật trên. Khi các mô đun được kiểm thử xong, kiểm thử tích hợp được tiến hành.

9.4.2 Kiểm thử tích hợp

Kiểm thử tích hợp với mục đích là kiểm tra giao diện và sự liên tác giữa các mô đun. Do vậy, các mô đun đã được kiểm thử xong coi như không có lỗi ở mức mô đun. Việc truy nhập ở đây là ở mức mô đun và nhằm phát hiện lỗi giao diện khi các mô đun truy nhập (gọi) tới nhau.

Hình trên cho ta một hình ảnh về việc tích hợp theo điều khiển các mô đun như một đồ thị luồng với điểm bắt đầu m1 <Main calls C> c1 <C calls F> f1 <F

Trong kiểm thử tích hợp, các kỹ thuật sau đây thường được sử dụng:

- Kiểm thử dưới lên (Bottom-up Test)

- Kiểm thử trên xuống (Top-down Test)

- Kiểm thử cột trụ (Big bung Test)

- Kiểm thử kẹp (Sandwich Test)

9.4.2.1 Thử dưới lên

Qui trình

- 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

Hình ảnh các mô đun được ghép dần từ mức thấp nhất, qau các mức trên và dần lên mức cao nhất

Một số điểm lưu ý của kỹ thuật này:

- Khó lập trình

- Dễ cô lập lỗi

- Mỗi test cho một session

9.4.2.2 Thử trên xuống

Qui trình

- 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

- Các 1 nút thử xong được thử tiếp nút khác

- Kiểm thử hồi quy

Hình ảnh về thứ tự kiểm thử được minh hoạ như hình trên. Các mô đun ở mức dưới có thể được tổ hợp theo chiều sâu hay theo chiều rộng.

Một số điểm lưu ý của kỹ thuật này:

- Dễ dàng lập trình

- Dễ cô lập lỗi

- 1 test cho 1 session

9.4.2.3 KIểm thử trụ cột Big-bang Test

Qui trình:

- Tích hợp không tăng dần

- Tất các các môđun đều được tổ hợp trước

- Toàn bộ chương trình được kiểm thử tổng thể

- Khó khăn: khó cô lập lỗi, khi chữa xong

lỗi này có thể lỗi mới lại phát sinh

9.4.2.4 Kiểm thử Sandwich

Kết hợp 2 kỹ thuật kiểm thử:

Trên -Xuống cho các mức trên của chương trình;

Dưới - Lên cho các mức phụ thuộc.

Hạn chế:

Khó cô lập lỗi.

9.5 Kiểm thử hệ thống

Kiểm thử hệ thống được tiến hành sau khi việc tích hợp các mô đun đã được thực hiện. Kiểm thử hệ thống nhằm:

• Kiểm thử phục hồi: bắt buộc phần mềm hỏng nhiều cách để kiểm chứng phục hồi

• Kiểm thử an toàn: kiểm chứng cơ chế bảo vệ

• Kiểm thử gay cấn

• Kiểm thử hiệu năng

9.6 Kiểm thử chấp nhận (Acceptance Test)

Nếu các kiểm thử trước được tiến hành bởi nhóm kiểm thử không cần sự hiện diện của người dùng thì kiểm thử này ngược lại cần sự hiện diện của người dùng. Người dùng căn cứ vào yêu cầu đã thống nhất với nhóm phát triển nhằm kiểm tra các yêu cầu về chức năng, về giao tiếp và các ràng buộc khác như hiệu năng, môi trường kỹ thuật. Sau kiểm thử này nếu kết quả tốt phần mềm sẽ được bàn giao cho khách hàng.

Chương 10

BẢO TRÌ PHẦN MỀM

Nội dung

10.1. Bảo trì là gì?

10.2 Trình tự nghi ệp vụ bảo trì

10.3 Những khó khăn trong bảo trì

10.4 Những vấn đề trong bảo trì hiện nay

10.5 Mô hình thuần thục bảo trì

10.1 Bảo trì là gì ?

10.1.1 Khái niệm

Theo IEEE (1993), thì bảo trì phần mềm được định nghĩa là việc sửa đổi một phần mềm sau khi đã bàn giao để chỉnh lại các lỗi phát sinh, cải thiện hiệu năng của phần mềm hoặc các thuộc tính khác, hoặc làm cho phần mềm thích ứng trong một môi trường đã bị thay đổi.

Năm 1995, tiêu chuẩn ISO/IEC 12207 định nghĩa: Bảo trì phần mềm là sự thay đổi mã nguồn và các tài liệu liên quan vì một vấn đề hoặc vì sự cần thiết phải phát triển. Mục đích là biến đổi phần mềm hiện có trong khi vẫn giữ nguyên tính toàn vẹn của nó.

10.1.2 Các hình thái bảo trì

IEEE (1993) chia bảo trì phần mềm thành 4 loại:

1- Bảo trì để Tu chỉnh:

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 đó.

Qui trình: sử dụng kỹ nghệ ngược nhằm dò lại thiết kế để tu sửa

2- Bảo trì để Thích hợp:

Là tu chỉnh phần mềm theo thay đổi của môi trường bên ngoài nhằm duy trì và quản lý phần mềm theo vòng đời của nó. Thay đổi phần mềm thích nghi với môi trường: công nghệ phần cứng, môi trường phần mềm. 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): thí dụ như Hệ điều hành

- Thay đổi cấu trúc tệp hoặc mở rộng cơ sở dữ liệu .

3- Bảo trì để Cải tiến:

Là việc tu chỉnh hệ phần mềm theo các yêu cầu ngày càng hoàn thiện hơn, đầy đủ hơn, hợp lý hơn. Những nguyên nhân chính:

- Do muốn nâng cao hiệu suất nên thường hay cải tiến phương thức truy cập tệp.

- Mở rộng thêm chức năng mới cho hệ thống.

- Cải tiến quản lý kéo theo cải tiến tư liệu vận hành và trình tự công việc.

- Thay đổi người dùng hoặc thay đổi thao tác.

Qui trình: sử dụng kỹ thuật tái kỹ nghệ (re-engineering) với 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. Thường tiến hành với hai mảng: tái cấu trúc phần mềm, tái xây dựng cấu trúc dữ liệu cho phù hợp

4- Bảo trì để Phòng ngừa:

Là công việc tu chỉnh chương trình có tính đến tương lai của phần mềm đó sẽ mở rộng và thay đổi như thế nào. Thực ra trong khi thiết kế phần mềm đã phải tính đến tính mở rộng của nó, nên thực tế ít khi ta gặp bảo trì phòng ngừa nếu như phần mềm được thiết kế tốt.

Qui trình:

- Hiểu hoạt động bên trong chương trình

- Thực hiện những thay đổi trên thiết kế không tường minh.

- Thiết kế / lập trình lại.

- Sử dụng công cụ CASE