20 câu tự luận

1. ĐN Phần mềm và kỹ nghệ phần mềm. (1.2 và 1.3 - Tr5  Tr17)

1.1. Phần mềm

1.1.1. Mô tả về phần mềm

-Các lệnh (chương trình máy tính) khi được thực hiện thì đưa ra hoạt độ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ài liệu mô tả thao tác và cách dùng chương trình

1.1.2. Các đặc trưng phần mềm

Phần mềm là phần tử hệ thống logic chưa không phải là hệ thống vật lý. Do đó phần mềm có đặc trưng khác biệt đáng kể với các đậc trưng của phần cứng

1.Phần mềm được phát triển hay được kỹ nghệ hoá, nó không được chế tạo theo nghĩa cổ điển:

2.Phần mềm không "hỏng đi"

Phần mềm không cảm ứng đối với những khiếm khuyết môi trường vốn gây cho phần cứng bị mòn cũ đi

Phần cứng hỏng có "vật tư thay thế", nhưng không có phần mềm thay thế cho phần mềm . Mọi hỏng hóc phần mềm đều chỉ ra lỗi trong thiết kế hay trong tiến trình chuyển thiết kế thành mã máy thực hiện được. Do đó, việc bảo trì phần mềm bao gồm độ phức tạp phụ thêm đáng kể so với bảo trì phần cứng.

3.Phần lớn phần mềm đều được xây dựng theo đơn đặt hàng, chứ ít khi được lắp ráp từ các thành phần có sẵn

1.1.3. Các thành phần của phần mềm

Phần mềm máy tính (gọi tắt là phần mềm ) là thông tin tồn tại dưới 2 dạng cơ sở: thành phần máy không thực hiện được và các thành phần máy thực hiện được.

Các thành phần phần mềm được xây dựng bằng các ngôn ngữ như: các ngôn ngữ mức máy, ngôn ngữ cấp cao và ngôn ngữ phi thủ tục.

+Ngôn ngữ mức máy: là một biểu diễn ký hiệu cho tập lệnh của đơn vị xử lý trung tâm

+Ngôn ngữ cấp cao: Cho phép người phát triển phần mềm và chương trình được độc lập với máy song từ vựng, văn phạm, cú pháp, ngữ nghĩa phức tạp hơn nhiều so với ngôn ngữ máy.

+Ngôn ngữ phi thủ tục: Có trên một thập kỷ qua, thay vì phải yêu cầu người phát triển phần mềm cần xác định chi tiết thủ tục thì các ngôn ngữ phi thủ tục đưa đến một chương trình bằng cách "xác định kết quả mong muốn thay vì xác định hành động cần để đạt được kết quả đó". Phần mềm hỗ trợ sẽ dịch đặc tả thành chương trình máy thực hiện được.

1.1.4. Phân loại phần mềm ứng dụng (7 loại):

1. Phần mềm hệ thống:

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

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

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

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

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

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

Phần mềm điều phối hoặc phân tích hoặc kiểm soát các sự kiện thế giới thực ngay khi chúng xuất hiện được gọi là phần mềm thời gian thực.

Phần mềm thời gian thực bao gồm các yếu tố:

-Một thành phần thu thập dữ liệu để thu và định dạng thông tin từ ngoài

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

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

-Một thành phần điều phối để điều hoà các thành phần khác sao cho có thể duy trì việc đáp ứng thời gian thực.

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

Xử lý thông tin nghiệp vụ là lĩnh vực ứng dụng phần mềm lớn nhất

Các hệ thống rời rạc: hệ thông tin quản lý

Các ứng dụng phần mềm nghiệp vụ còn bao gồm cả tính toán tương tác (như xử lý giao tác cho các điểm bán hàng) ngoài ứng dụng xử lý dữ liệu

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

-Được đặc trưng bởi các thuật toán

-Trong ứng dụng mới, thiết kế có máy tính trợ giúp (CAD), có chú ý đến các đặc trưng thời gian thực và cả phần mềm hệ thống.

5. Phần mềm nhúng

-Nằm trong bộ nhớ chỉ đọc và được dùng để điều khiển các sản phẩm và hệ thống cho người dùng và thị trường công nghiệp

-Có thể thực hiện các chức năng rất giới hạn và huyền bí (điều khiển bàn phím cho lò vi sóng) hay đưa ra các khả năng điều khiển và vận hành (chức năng số hoá ở ô tô, kiểm soát xăng, biểu thị bảng đồng hồ, hệ thống phanh)

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

-Bùng nổ trong hơn thập kỷ qua (xử lý văn bản, trang tính, đồ hoạ, quản trị CSDL)

-Tiếp tục biểu thị thiết kế giao diện người-máy: được cải tiến nhiều nhất.

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

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

-Hoạt động mạnh nhất là hệ chuyên gia (hệ cơ sở tri thức)

-Lĩnh vực nhận dạng (hình ảnh và tiếng nói)

-Chứng minh định lý và chơi trò chơi

-Phát triển mạng nơ ron nhân tạo: mô phỏng cấu trúc của việc xử lý trong bộ óc.

1.2. Kỹ nghệ phần mềm

Định nghĩa

Fritz Bauer nêu ra định nghĩa ban đầu về kỹ nghệ phần mềm :

Kỹ nghệ phần mềm là việc thiết lập và sử dụng các nguyên lý công nghệ đúng đắn để thu được phần mềm một cách kinh tế vừa tin cậy vừa làm việc hiệu quả trên các máy thực

Các định nghĩa về sau đều nhấn mạnh vào yêu cầu về một kỷ luật công nghệ trong việc phát triển phần mềm

Kỹ nghệ phần mềm - sự phát triển của kỹ nghệ phần cứng và hệ thống. Nó bao gồm một tập các bước chứa đựng 3 yếu tố chủ chốt:

- Phương pháp

- Công cụ

- Thủ tục

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

1.Các phương pháp (đưa ra các "cách làm" về mặt kỹ thuật để xây dựng phần mềm ):

Các phương pháp bao hàm trong nhiều nhiệm vụ: lập kế hoạch, ước lượng dự án, phân tích yêu cầu hệ thống và phần mềm , thiết kế cấu trúc dữ liệu, kiến trúc chương trình và thủ tục thuật toán, mã hoá kiểm thử và bảo trì

Các phương pháp cho kỹ nghệ phần mềm thường đưa ra các ký pháp đồ hoạ hay hướng ngôn ngữ đặc biệt, đưa ra một tập các tiêu chuẩn về chất lượng sản phẩm phần mềm.

2.Các công cụ (cung cấp sự hỗ trợ tự động hay bán tự động cho từng phương pháp):

Khi các công cụ được tích hợp đến mức các thông tin do chúng tạo ra có thể được dùng cho các công cụ khác thì hệ thống hỗ trợ cho việc phát triển phần mềm đã được thiết lập và còn được gọi là kỹ nghệ phần mềm có máy tính hỗ trợ (CASE)

3.Các thủ tục (chất keo dán các phương pháp và công cụ lại với nhau và làm cho chúng được sử dụng hợp lý và đúng hạn trong quá trình phát triển phần mềm):

-Xác định ra trình tự các phương pháp sẽ được áp dụng,

-Tạo sản phẩm cần bàn giao (tài liệu báo cáo, bản mẫu,...) cần cho việc kiểm soát để đảm bảo chất lượng và điều hoà thay đổi,

-Xác định những cột mốc để cho người quản lý phần mềm nắm được tiến độ.

Như vậy, kỹ nghệ phần mềm bao gồm một tập các bước bao hàm cả phương pháp, công cụ và thủ tục đã được xác định ở trên. Các bước này thường được gọi là các khuôn cảnh (paradigm) kỹ nghệ phần mềm .

Mỗi bước trong kỹ nghệ phần mềm được lựa chọn dựa trên bản chất của dự án, dựa vào phương pháp và công cụ sử dụng, vào cách kiểm soát, cách bàn giao.

2. Phân tích các thuộc tính chủ chốt. (Tr 23)

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

• Có thể bảo trì được: phần mềm tuổi thọ dài phải được viết và được lập tư liệu sao cho việc thay đổi có thể tiến hành được mà không quá tốn kém.

• Đáng tin cậy: phần mềm phải thực hiện được điều mà người tiêu dùng mong mỏi và không thất bại nhiều hơn những điều đã được đặc tả.

• Có hiệu quả: hệ thống phải không lãng phí nguồn lực bộ nhớ, bộ xử lý. Không đòi hỏi phải cực đại hoá độ hiệu quả vì rằng việc đó có thể làm cho phần mềm rất khó thay đổi.

• Có giao diện người sử dụng thích hợp: giao diện người sử dụng phải phù hợp với khả năng và kiến thức của người dùng hệ thống.

3. Nội dung phân tích hệ thống bao gồm những công việc nào? (Câu 17 Trắc nghiệm - Tr 32)

• Phân tích mục tiêu: xác định một cách chính xác và đầy đủ mục tiêu mà hệ thống và cũng là mục tiêu mà chủ thể mong muốn. Trong thực tế, mục tiêu của hệ thống không phải luôn rõ ràng.

• Phân tích phạm vi và môi trường của hệ thống: xác định phạm vi hệ thống cần nghiên cứu liên quan đến việc đạt được mục tiêu ở trên.

• Phân tích cấu trúc: xác định các phần từ, các mối quan hệ của hệ thống. Đó là những đặc trưng quan trọng của hệ thống.

• Phân tích các nguồn lực và tác động của nó: cần có các nguồn lực cần để đạt mục tiêu.

• Phân tích tổng hợp toàn hệ thống: để thấy những đặc tính trồi có thể của hệ thống khi nó vận hành.

4. Yêu cầu phi chức năng (Tr 42, 43)

Các yêu cầu phi chức năng:

Một yêu cầu phi chức năng của hệ thống là một hạn chế hoặc ràng buộc về các dịch vụ của hệ thống. Các yêu cầu đó có thể được đưa ra:

- vì nhu cầu của người dùng,

- vì hạn chế của kinh phí,

- vì chính sách của tổ chức,

- vì sự cần thiết tương tác giữa các phần cứng và phần mềm hoặc

- vì các nhân tố bên ngoài như các quy tắc an toàn, luật lệ bí mật riêng tư,...

Có 3 kiểu yêu cầu phi chức năng chính:

1. Các yêu cầu sản phẩm : đây là các yêu cầu về hệ thống được phát triển , chẳng hạn yêu cầu về tốc độ, về bộ nhớ, về độ tin cậy, về tính di chuyển được và về tính dùng lại được

2. Các yêu cầu về quá trình: đây là các yêu cầu về quá trình phát triển, chẳng hạn như các chuẩn cần phải theo, các yêu cầu về sự thực hiện như là các ngôn ngữ lập trình, phương pháp thiết kế , yêu cầu về phân phát

3. Các yêu cầu ngoại lai: tức là các yêu cầu không phải về sản phẩm cũng không phải về quá trình phát triển: chẳng hạn như về giao tiếp với các hệ thống khác, về pháp lý, về chi phí, về nhóm những người phát triển và ....

5. Các hoạt động cốt yếu nhất trong thiết kế phần mềm. (Tr 59, 60)

a. Thiết kế kiến trúc: các hệ con tạo nên hệ tổng thể và các quan hệ của chúng là được minh định và ghi thành tài liệu

b. Đặc tả trừu tượng: đối với mỗi hệ con, một đặc tả trừu tượng các dịch vụ mà nó cung cấp và các ràng buộc phải tuân theo được cung cấp

c. Thiết kế giao diện: giao diện của từng hệ con với các hệ con khác là được thiết kế và ghi thành tài liệu. đặc tả giao diện không được mơ hồ và cho phép sử dụng hệ con đó mà không cần biết về phép toán hệ con.

d. Thiết kế các thành phần: các dịch vụ cung cấp bởi một hệ con là được phân chia qua các thành phần hợp thành của hệ con đó

e. Thiết kế cấu trúc dữ liệu: các cấu trúc dữ liệu được dùng trong việc thực hiện hệ thống là được thiết kế chi tiết và được đặc tả

f. Thiết kế thuật toán: các thuật toán được dùng để cung cấp cho các dịch vụlà được thiết kế chi tiết và được đặc tả

6. Kiến trúc phần mềm bao gồm những đặc trưng quan trọng gì? (Tr 64, 65, 66)

Kiến trúc phần mềm ám chỉ hai đặc trưng quan trọng của chương trình máy tính:

1. Cấu trúc cấp bậc điều khiển của các thành phần thủ tục (modul) (hoặc cấu trúc chương trình)

Cấp bậc điều khiển, còn gọi là cấu trúc chương trình, biểu thị cho cách tổ chức của các thành phần chương trình (mô đun). Nó không biểu thị các khía cạnh thủ tục của phần mềm như dãy các xử lý, sự xuất hiện/ thứ tự các quyết định hay việc lặp lại các thao tác.

Người ta dùng các kí pháp khác nhau để biểu diễn cho cấp bậc điều khiển. Thông dụng nhất là biểu đồ kiểu cây. Trong đó độ sâu và chiều rộng đưa ra một chỉ báo về số mức điều khiển và độ trải rộng toàn bộ của điều khiển tương ứng. Số mô đun ra là một độ đo đo số các mô đun trực tiếp bị điều khiển bởi các mô đun khác. Số mô đun vào chỉ ra cách thức mô đun trực tiếp điều khiển một mô đun đã cho.

2. Cấu trúc dữ liệu

Biểu diễn mối quan hệ logic giữa các phần tử dữ liệu riêng lẻ. Vì cấu trúc thông tin sẽ luôn luôn ảnh hưởng tới thiết kế thủ tục cuối cùng nên cấu trúc dữ liệu cũng quan trọng như cấu trúc chương trình để biểu thị kiến trúc phần mềm.

Ý nghĩa: Cấu trúc dữ liệu khống chế cách tổ chức, các phương pháp thâm nhập, mức độ kết hợp và các phương án xử lý thông tin .

Tổ chức và độ phức tạp của các cấu trúc dữ liệu chỉ bị giới hạn bởi tài khéo léo của người thiết kế. Tuy nhiên cũng có một số hạn chế, các cấu trúc dữ liệu cổ điển vốn tạo nên các khối xây dựng cho nhiều cấu trúc dữ liệu phức tạp.

7. Phân biệt cấu trúc chương trình và thủ tục phần mềm? Nêu quan hệ giữa chúng? (Tr 68)

Thủ tục phần mềm

Cấu trúc chương trình xác định ra cấp bậc điều khiển không để ý đến dãy các xử lý và quyết định. Thủ tục phần mềm tập trung vào các chi tiết xử lý cho từng mô đun riêng biệt. Thủ tục phải cung cấp một đặc tả chính xác về xử lý, kể cả trình tự các sự kiện, các điểm quyết định chính xác, các thao tác lặp lại, và ngay cả cấu trúc/tổ chức dữ liệu.

Giữa cấu trúc và thủ tục có một mối quan hệ chặt chẽ. Việc xử lý được chỉ ra trong từng mô đun bao gồm một tham khảo tới mọi mô đun cấp dưới của mô đun đang được mô tả.

8. Phân biệt thiết kế hướng đối tượng với lập trình hướng đối tượng. (Tr 74)

• Dễ nhầm lẫn 2 khái niệm này. Ngôn ngữ lập trình hướng đối tượng là một ngôn ngữ lập trình cho phép thực hiện trực tiếp các đối tượng và cung cấp các lớp đối tượng và sự thừa kế .

• Thiết kế hướng đối tượng là một chiến lược thiết kế, không phụ thuộc vào ngôn ngữ thực hiện cụ thể nào. Các ngôn ngữ lập trình hướng đối tượng và các khả năng bao gói đối tượng làm cho thiết kế hướng đối tượng được thực hiện một cách đơn giản hơn. Tuy nhiên một thiết kế hướng đối tượng cũng có thể được thực hiện trong một ngôn ngữ kiểu như PASCAL hoặc C (không có các đặc điểm bao gói như vậy).

Việc chấp nhận thiết kế hướng đối tượng như là một chiến lược hữu hiệu dẫn đến sự phát triển phương pháp thiết kế hướng đối tượng .

Ada không phải là ngôn ngữ lập trình hướng đối tượng vì nó không trợ giúp sự thừa kế của các lớp, nhưng lại có thể thực hiện các đối tượng trong Ada bằng cách sử dụng các gói hoặc các nhiệm vụ (tasks), do đó Ada được dùng để mô tả các thiết kế hướng đối tượng

• Phương pháp thiết kế hướng đối tượng vẫn còn là tương đối chưa chín muồi và đang thay đổi nhanh chóng. Phương pháp hiện đang được sử dụng rộng rãi nhất là phương pháp dựa trên sự phân rã chức năng.

9. Trong thiết kế hướng chức năng, người ta dùng mô hình nào phân tích xử lý, phân tích dữ liệu? (Tr 74, 75, 76)

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

• Thiết kế hướng chức năng là một cách tiếp cận thiết kế phần mềm trong đó bản thiết kế được phân giải thành một bộ các đơn thể tác động lẫn nhau, mà mỗi đơn thể có một chức năng được xác định rõ ràng. Các chức năng có các trạng thái cục bộ nhưng chúng chia sẻ với nhau trạng thái hệ thống, trạng thái này là tập trung và mọi chức năng đều có thể truy cập được

Có người nghĩ rằng thiết kế hướng chức năng đ• lỗi thời và nên được thay thế bởi cách tiếp cận hướng đối tượng. Thế nhưng, nhiều tổ chức đ• phát triển các chuẩn và các phương pháp dựa trên sự phân giải chức năng. Nhiều phương pháp thiết kế kết hợp với công cụ CASE đều là hướng chức năng. Vô khối các hệ thống đ• được phát triển bằng cách sử dụng phương pháp tiếp cận hướng chức năng. Các hệ thống đó sẽ được bảo trì cho một tương lai xa xôi. Bởi vậy thiết kế hướng chức năng vẫn sẽ còn được tiếp tục sử dụng rộng r•i.

• Trong thiết kế hướng chức năng, người ta dùng các biểu đồ dòng dữ liệu (mà nó mô tả việc xử lý dữ liệu logic), các lược đồ cấu trúc ( nó chỉ ra cấu trúc của phần mềm ) và các mô tả PDL (mô tả thiết kế chi tiết). Khái niệm dòng dữ liệu đang hướng tới thích hợp hơn cho việc sử dụng một hệ thống vẽ biểu đồ tự động và sử dụng một dạng lược đồ cấu trúc có kèm thêm các thông tin điều khiển

Chiến lược thiết kế hướng chức năng dựa trên việc phân giải hệ thống thành một bộ các chức năng có tương tác nhau với trạng thái hệ thống tập trung dùng chung cho các chức năng đó. Các chức năng này có thể có các thông tin trạng thái cục bộ nhưng chỉ dùng cho quá trình thực hiện chức năng đó mà thôi.

• Thiết kế hướng chức năng gắn với các chi tiết của một thuật toán của chức năng đó nhưng các thông tin trạng thái hệ thống là không bị che dấu. Điều này có thể gây ra một vấn đề vì rằng một chức năng có thể thay đổi trạng thái theo một cách mà các chức năng khác không ngờ tới. Việc thay đổi một chức năng và cách nó sử dụng trạng thái của hệ thống có thể gây ra những tương tác bất ngờ đối với các chức năng khác

• Cách tiếp cận chức năng để thiết kế là tốt nhất khi mà khối lượng thông tin trạng thái hệ thống được làm nhỏ nhất và thông tin dùng chung nhau là rõ ràng

Biểu đồ dòng dữ liệu

Biểu đồ dòng dữ liệu chỉ ra cách thức biến đổi dữ liệu vào thành dữ liệu ra thông qua một dãy các phép biến đổi. Đó là một cách ngây thơ và hữu ích để mô tả một hệ thống và nó cũng là dễ hiểu không cần một sự huấn luyện đặc biệt nào. Bước thứ nhất của thiết kế hướng chức năng là phát triển một biểu đồ dòng dữ liệu hệ thống. Biểu đồ này không nhất thiết bao gồm các thông tin điều khiển nhưng nên lập tư liệu các phép biến đổi dữ liệu .

Biểu đồ dòng dữ liệu là một phần hợp nhất của một số các phương pháp thiết kế và các công cụ CASE thường trợ giúp cho việc tạo ra biểu đồ dòng dữ liệu . Thường dùng các ký pháp sau:

1. Các hình chữ nhật góc tầy: biểu diễn một phép biến đổi dòng dữ liệu vào thành dòng dữ liệu ra, sự biến đổi đó được chỉ ra bởi chính tên của hình đó:

2. Các hình chữ nhật: biểu diễn một kho dữ liệu , dữ liệu được nói rõ trong tên của hình đó

3. Các hình tròn: biểu diễn giao tác người dùng với hệ thống (cung cấp thông tin vào hoặc thu nhận thông tin ra)

4. Các mũi tên: chỉ hướng dòng dữ liệu

5. Các từ khoá and và or

6. Một khuyên tròn nối các dòng dữ liệu

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

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

Mỗi thành phần chức năng được biểu diễn trên đồ thị cấu trúc như là một hình chữ nhật. Thứ bậc này trình bày bằng cách nối các hình chữ nhật với các đường. Thông tin vào và thông tin ra cho một thành phần được chỉ bởi việc dùng các mũi tên có gán tên. Một mũi tên vào một hộp ngầm chỉ thông tin vào còn mũi tên ra từ một hộp ngầm chỉ thông tin ra. Các kho dữ liệu được chỉ bởi các hình chữ nhật góc tầy và các thông tin vào từ người dùng được chỉ bởi các khuyên tròn. Sau này, để tránh nhầm với kí pháp đã dùng trong biểu đồ dòng dữ liệu , người ta dùng khối trụ biểu diễn kho dữ liệu và hình bình hành biểu diễn thông tin vào.

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

Từ điển dữ liệu vừa có ích cho việc bảo trì hệ thống vừa có ích trong quá trình thiết kế. Với mỗi lối vào đã được minh định trong biểu đồ phải có một lối vào từ điển dữ liệu cung cấp thông tin về kiểu, chức năng của dữ liệu và một lý do cơ bản cho việc nó vào. Đôi khi người ta gọi cái này là một mô tả ngắn của chức năng thành phần.

Lối vào từ điển thành phần phải là một mô tả kiểu văn bản cho thành phần và phải được mô tả chi tiết.

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

10. Trình bày các vấn đề thiết kế giao diện. (Tr 78, 79, 80)

Bốn vấn đề thiết kế thông thường gần như bao giờ cũng nổi lên:

1. Thời gian hệ thống đáp ứng (độ dài, độ biến thiên)

Thời gian hệ thống đáp ứng là nan giải chính cho nhiều hệ thống tương tác (đặc biệt là những ứng dụng có dùng máy tính lớn tập trung). Nói chung, thời gian hệ thống đáp ứng được đo từ điểm tại đó người dùng thực hiện hành động điều khiển nào đó (như gõ phím hay nháy chuột) cho tới khi phần mềm đáp ứng với cái ra hay hành động mong muốn.

Thời gian hệ thống đáp ứng có hai đặc trưng quan trọng: độ dài và độ biến thiên. Nếu độ dài thời gian đáp ứng quá lâu thì người dùng không tránh khỏi chán nản và căng thẳng. Tuy nhiên thời gian đáp ứng quá ngắn cũng có thể bất lợi nếu người dùng bị giao diện giữ nhịp. Sự đáp ứng nhanh chóng có thể buộc người dùng phải vội vã do đó phạm sai lầm.

"Độ biến thiên " nói tới độ lệch khỏi thời gian đáp ứng trung bình, và theo nhiều cách thức thì nó còn quan trọng hơn đặc trưng thời gian đáp ứng. Độ biến thiên thấp làm cho người dùng thiết lập được nhịp điệu, cho dù thời gian đáp ứng tương đối lâu. Chẳng hạn đáp ứng1giây đối với một lệnh thì được ưa chuộng hơn cho một đáp ứng biến thiên từ 0,1 đến 2,5 giây. Trong trường hợp sau, người dùng bao giờ cũng bị mất cân bằng, bao giờ cũng phải tự hỏi liệu có cái gì đó "khác" sẽ xuất hiện bên ngoài khung cảnh này hay không.

2. Tiện nghi giúp đỡ người dùng(tích hợp, phụ thêm)

Ta thường gặp phải hai kiểu tiện nghi trợ giúp khác nhau: tích hợp và phụ thêm. Tiện nghi trợ giúp tích hợp được thiết kế trong phần mềm ngay từ đầu. Nó thường cảm ngữ cảnh, làm cho người dùng lựa được từ các chủ đề có liên quan tới hành động hiện đang được thực hiện. Hiển nhiên, điều này rút gọn thời gian cần để người dùng thu được sự trợ giúp và tạo ra "sự thân thiện" của giao diện. Tiện nghi trợ giúp phụ thêm được thêm vào cho phần mềm sau khi hệ thống đã được xây dựng. Theo nhiều cách, nó thực sự là một tài liệu người dùng trực tuyến với một khả năng hỏi hạn chế. Người dùng có thể phải tìm kiếm trong một danh sách hàng trăm chủ đề để tìm hướng dẫn thích hợp, thường nhiều lần bắt đầu sai và nhận được những thông tin không liên quan. Chắc chắn là tiện nghi trợ giúp tích hợp được ưa thích hơn cách tiếp cận phụ thêm.

3. Giải quyết thông tin lỗi (thông báo, cảnh báo)

Thông báo lỗi và cảnh báo là tin dữ trao cho người dùng hệ thống tương tác khi một điều gì đó chạy không đúng. Tồi nhất thì thông báo lỗi và lời cảnh báo truyền đạt thông tin vô dụng hay hiểu sai và chỉ làm tăng thêm lỗi chán nản của người dùng.

Nói chung, mọi thông báo lỗi hay cảnh báo do hệ thông tương tác tạo ra nên có các đặc trưng sau:

• Thông báo nên mô tả vấn đề theo lối nói mà người dùng có thể hiểu được.

• Thông báo nên đưa ra những lời khuyên có tính xây dựng để khôi phục từ lỗi.

• Thông báo nên chỉ ra bất kỳ hậu quả lỗi tiêu cực nào (như tệp dữ liệu có thể hỏng) để cho người dùng có thể kiểm tra đảm bảo rằng chúng không xuất hiện (hay sửa ngay chúng nếu có xuất hiện).

• Thông báo nên đi kèm với tín hiệu nghe được hay thấy được. Tức là một tiếng bíp có thể được sinh ra đi kèm với việc hiển thị thông báo, hay thông báo có thể nhấp nháy chốc lát hay được hiển thị theo mầu dễ nhận ra như "mầu lỗi".

• Thông báo nên có tính chất "phi đánh giá". Tức là lời đưa ra đừng hàm ý trách móc người dùng

4. Gắn nhãn chỉ lệnh (tiện nghi tạo macro)

Ngày nay, việc dùng giao diện hướng cửa sổ, chỉ và chọn, đã làm giảm bớt việc dựa vào chỉ lệnh gõ vào, nhưng nhiều siêu người dùng vẫn tiếp tục ưa thích mốt tương tác theo chỉ lệnh. Trong nhiều tình huống, người dùng có thể được cung cấp một tuỳ chọn - các năng phần mềm có thể được lựa ra từ một đơn tĩnh hay đơn kéo xuống thông qua một dãy chỉ lệnh bàn phím nào đó.

Một số vấn đề thiết kế nảy sinh khi chỉ lệnh được đưa ra như một mốt tương tác:

• Liệu mọi tuỳ chọn đơn có tương ứng với một chỉ lệnh không?

• Chỉ lệnh sẽ có dạng nào? Các tuỳ chọn bao gồm: dãy điều khiển (như ^P); phím chức năng; từ gõ vào.

• Việc học và nhớ chỉ lệnh sẽ khó đến mức nào? Có thể làm được gì nếu quên mất chỉ lệnh (xem thảo luận về trợ giúp được trình bày trong mục này)?

• Liệu chỉ lệnh có được người dùng làm cho phù hợp hay viết tắt không?

• Trong số ứng dụng ngày càng tăng, người thiết kế giao diện đưa ra một tiện nghi tạo macro chỉ lệnh để cho phép người dùng ghi lại một dãy các chỉ lệnh hay dùng hay theo tên do người dùng xác định. Thay vì phải gõ từng lệnh một thì chỉ cần gõ macro chỉ lệnh và mọi chỉ lệnh trong đó sẽ được thực hiện tuần tự.

11. Khái niệm chương trình con và đặc trưng tổng quát của chúng?

Chương trình con là một thành phần của chương trình dịch được tách biệt có chứa dữ liệu và cấu trúc điều khiển. Mô đun là cách biểu hiện tổng quát của chương trình con. Tuỳ theo ngôn ngữ lập trình mà một chương trình con có thể được gọi là trình con, thủ tục, hàm hay bất kì tên gọi đặc biệt nào. Bất kể đến tên của nó, chương trình con vẫn bộc lộ ra một tập các đặc trưng tổng quát:

(1) Phần mô tả có chứa tên của nó và mô tả giao điện ;

(2) Phần cài đặt có chứa dữ liệu và cấu trúc điều khiển;

(3) Một cơ chế kích hoạt làm cho chương trình con được gọi tới từ một nơi nào đó khác trong chương trình.

Trong các ngôn ngữ lập trình qui ước ,mỗi chương trình con bản thân nó đều là một thực thể, vận hành trên dữ liệu theo một cách được chỉ đạo bởi cấu trúc điều khiển của chương trình lớn hơn. Trong các ngôn ngữ lập trình hướng đối tượng, cách nhìn lớp chương trình con được thay thế bởi đối tượng.

12. Nêu 4 yếu tố của phong cách lập trình. (Tr 96, 97, 98)

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

Tài liệu bên trong của chương trình gốc bắt đầu với việc chọn lựa các tên gọi định danh (biến và nhãn), tiếp tục với vị trí và thành phần của việc chú thích, và kết luận với cách tổ chức trực quan của chương trình.

- Định danh: Việc lựa chọn các tên gọi định danh có nghĩa chính là điều chủ chốt cho việc hiểu chương trình. Những ngôn ngữ giới hạn tên biến hay nhãn chỉ trong vài kí tự tự nó đã mang nghĩa mơ hồ. Cho dù một chương trình nhỏ thì một tên gọi có nghĩa cũng làm tăng tính dễ hiểu. Theo ngôn từ của mô hình cú pháp/ngữ nghĩa tên có ý nghĩa làm "đơn giản hoá việc chuyển đổi từ cú pháp chương trình sang cấu trúc ngữ nghĩa bên trong".

- Chú thích: Một điều rõ ràng là: phần mềm phải chứa tài liệu bên trong. Lời chú thích cung cấp cho người phát triển một ý nghĩa truyền thông với các độc giả khác về chương trình gốc. Lời chú thích có thể cung cấp một hướng dẫn rõ rệt để hiểu trong pha cuối cùng của kĩ nghệ phần mềm-bảo trì.

Có nhiều hướng dẫn đã được đề nghị cho việc viết lời chú thích. Các chú thích mở đầu và chú thích chức năng là hai phạm trù đòi hỏi cách tiếp cận có hơi khác.

Khi một thiết kế thủ tục chi tiết được biểu diễn bằng cách dùng một ngôn ngữ thiết kế chương trình thì tài liệu thiết kế có thể được nhúng trực tiếp vào trong văn bản chương trình gốc như những câu chú thích. Kĩ thuật này đặc biệt có ích khi việc làm tài liệu được thực hiện trong hợp ngữ và giúp đảm bảo rằng cả chương trình và thiết kế sẽ được bảo trì khi những thay đổi được thực hiện cho cả hai.

- Cách tổ chức trực quan: Dạng chương trình gốc như nó xuất hiện trong bản in là một đóng góp quan trọng cho tính dễ đọc. Việc tụt lề chương trình gốc chỉ ra kết cấu và khối logic của chương trình sao cho những thuộc tính này là thấy được so với lề bên trái. Giống như việc chú thích, cách tiếp cận tốt nhất tới việc tụt lề là nên để mở cho tranh luận. Việc tụt lề thủ công có thể trở nên phức tạp khi có sự sửa đổi chương trình và kinh nghiệm chỉ ra rằng khi đã tích luỹ đủ hiểu biết thì sẽ tăng cường được việc để lề cho khớp. Có lẽ cách tiếp cận tốt nhất là dùng bộ định dạng chương trình tự động (như công cụ CASE) sẽ đặt đúng việc tụt lề cho chương trình gốc. Bằng cách xoá bỏ đi gánh nặng của việc làm tụt lề cho người lập trình, có thể cải thiện khuôn dạng chương trình với tương đối ít công sức.

2. Khai báo dữ liệu

Độ phức tạp và việc tổ chức cấu trúc dữ liệu được xác định trong bước thiết kế. Phong cách khai báo dữ liệu được thiết lập khi chương trình được sinh ra. Một số hướng dẫn tương đối đơn giản có thể được lập ra để làm cho dữ liệu được dễ hiểu hơn và đơn giản hơn khi bảo trì.

Thứ tự khai báo dữ liệu nên được chuẩn hoá cho dù ngôn ngữ lập trình không có yêu cầu bắt buộc nào về điều đó.

Thứ tự tạo ra các thuộc tính để dễ tìm, cho phép xúc tiến kiểm thử ,gỡ lỗi và bảo trì.

Khi có nhiều tên biến được khai báo trong một câu lệnh thì việc sắp xếp theo trật tự chữ cái cho các tên gọi đó cũng có giá trị. Tương tự, dữ liệu toàn cục có nhãn cũng nên được lập thứ tự theo bảng chữ.

Nếu thiết kế có mô tả trước cấu trúc dữ liệu phức tạp thì nên dùng việc chú thích những điểm đặc thù cố hữu trong việc cài đặt ngôn ngữ lập trình. Chẳng hạn, cấu trúc dữ liệu danh sách móc nối trong C hay kiểu dữ liệu người dùng xác định trong PASCAL có thể yêu cầu tài liệu bổ sung có chứa trong lời chú thích của nó.

3. Xây dựng câu lệnh

Việc xây dựng luồng logic phần mềm được thiết lập trong khi thiết kế. Việc xây dựng từng câu lệnh tuy nhiên lại là một phần của bước lập trình. Việc xây dựng câu lệnh nên tuân theo một qui tắc quan trọng hơn cả: mỗi câu lệnh nên đơn giản và trực tiếp; chương trình không nên bị xoắn xít để đạt tính hiệu quả.

Nhiều ngôn ngữ lập trình cho phép nhiều câu lệnh trên một dòng.Khía cạnh tiết kiệm không gian của tình năng này khó mà biện minh bởi tính khó đọc nảy sinh.

Cấu trúc chu trình và các phép toán điều kiện được chứa trong đoạn trên đều bị che lấp bởi cách xây dựng nhiều câu lệnh trên một dòng.

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

• Việc tránh dùng các phép kiểm tra điều kiện phức tạp

• Khử bỏ các phép kiểm tra điều kiện phủ định

• Tránh lồng nhau nhiều giữa các điều kiện hay chu trình

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

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

• Chỉ dùng các tính năng chuẩn ANSI

• Suy nghĩ: Liệu ta có thể hiểu được điều này nếu ta không là người lập trình cho nó không ?

Từng hướng dẫn trên đều cố gắng "giữ cho đơn giản "

4. Vào/ra

Phong cách vào và ra được thiết lập trong khi phân tích thiết kế yêu cầu phần mềm, không phải khi lập trình. Tuy nhiên, cách thức mà vào/ ra được cài đặt có thể là đặc trưng xác định việc cộng đồng người sử dụng chấp nhận hệ thống. Phong cách vào và ra sẽ thay đổi theo mức độ tương tác con người. Với vào/ra theo lô thì cách tổ chức cái vào lôgic, kiểm tra lỗi vào/ra có nghĩa, phục hồi lỗi vào/ra tốt và định dạng báo cáo ra hợp lý là những đặc trưng mong muốn.Với vào/ra tương tác, một sơ đồ đưa vào có hướng dẫn, đơn giản, việc kiểm tra lỗi kỹ lưỡng và phục hồi, cái ra cho con người và sự nhất quán của định dạng vào ra trở thành mối quan tâm chủ yếu.

Bất kể tới bản chất theo lô hay tương tác của phần mềm, một số hướng dẫn phong cách vào /ra nên được xét tới trongthiết kế và lập trình:

• Làm hợp lệ mọi cái vào

• Kiểm tra sự tin cậy của các tổ hợp khoản mục vào quan trọng.

• Giữ cho định dạng cái vào đơn giản.

• Dùng các chỉ báo cuối dữ liệu thay vì yêu cầu người dùng xác định "số các khoản mục".

• Đặt nhãn cho yêu cầu cái vào tương tác, xác định chọn lựa có sẵn hay gắn các giá trị

• Giữ cho định dạng cái vào thống nhất khi một ngôn ngữ lập trình có các yêu cầu định dạng nghiêm ngặt.

Phong cách của vào/ra bị ảnh hưởng bởi nhiều đặc trưng khác như thiết bị vào/ra (như kiểu thiết bị cuối hay trạm làm việc, thiết bị đồ hoạ máy tính, chuột v.v...), độ phức tạp của người dùng, và môi trường truyền thống.

13. 2 kĩ thuật viết chương trình đáng tin là gì? Nêu rõ các nguyên tắc hỗ trợ tránh lỗi. (Tr 99, 100)

Nhu cầu các hệ thống đáng tin là đang tăng lên hiển nhiên là vì các hệ thống máy tính đã lan khắp nơi. Hiện thời có hai kĩ thuật để viết các chương trình đáng tin: tránh lỗi và thứ lỗi.

1. Tránh lỗi:

Tất cả các kĩ sư phần mềm hẳn đều muốn làm ra các phần mềm không có lỗi. Một quá trình phát triển chỉ dựa vào việc phát hiện lỗi và khử lỗi chứ không để ý đến tránh lỗi là một qúa trình chưa thật tốt.

Phần mềm không có lỗi nói ở đây là phần mềm tuân theo đúng đặc tả. Nói chung, nó có thể có lỗi trong đặc tả hoặc có thể không phản ánh đúng các nhu cầu của người sử dụng. Vậy là phần mềm không có lỗi không nhất thiết là các phần mềm luôn luôn hành xử như người dùng dự đoán.

Việc phát triển phần mềm không có lỗi đòi hỏi chi phí nhiều. Khi mà một số lỗi đã được tháo khỏi chương trình thì giá cả cho việc tìm và tháo các lỗi còn lại có xu hướng tăng theo hàm số mũ. Do đó một tổ chức có thể quyết định chấp nhận một vài lỗi còn lưu lại. Tính về mặt giá cả thì thà rằng chịu tiền chi trả cho các phí tổn của hệ thống do các lỗi đó gây ra còn hơn là đi phát hiện và tháo gỡ các lỗi đó trước khi phân phối.

Tránh lỗi và phát triển phần mềm vô lỗi dựa trên:

i) Sản phẩm của một đặc tả hệ thống chính xác.

ii) Chấp nhận một cách tiếp cận thiết kế phần mềm dựa trên việc che dấu thông tin và bao gói thông tin.

iii) Tăng cường duyệt lại trong quá trình phát triển và thẩm định hệ thống phần mềm.

iv) Chấp nhận triết lý chất lượng tổ chức: chất lượng là bánh lái của quá trình phần mềm.

v) Việc lập kế hoạch cẩn thận cho việc thử nghiệm hệ thống để trưng ra các lỗi mà các lỗi này chưa được phát hiện trong quá trình duyệt lại và để định lượng độ tin cậy của hệ thống.

Có hai quan tâm lớn hỗ trợ tránh lỗi, đó là:

• Lập trình có cấu trúc

• Phân quyền truy cập dữ liệu

2. Thứ lỗi

Ngay với một hệ vô lỗi thì vẫn cần một tiện ích thứ lỗi: đó là vì có thể có các lỗi đặc tả. Một tiện ích thứ lỗi là cần thiết cho một hệ thống đáng tin.

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

i) Phát hiện lỗi.

ii) Định ra mức độ thiệt hại.

iii) Hồi phục sau khi gặp lỗi. Hệ thống phải hồi phục về trạng thái mà nó biết là an toàn. Cũng có thể là chỉnh lý trạng thái bị huỷ hoại (hồi phục tiến), cũng có thể là lui về một trạng thái trước mà an toàn (hồi phục lùi).

iv) Chữa lỗi: Cải tiến hệ thống để cho lỗi đó không xuất hiện nữa. trong nhiều trường hợp sự thất bại của phần mềm là tàng hình và gây ra bởi một tổ hợp của thông tin vào.

14. Nêu 1 vài hướng dẫn lập trình hướng hiệu quả (Tr 104, 105)

• Tính hiệu quả chương trình.

Tính hiệu quả của chương trình gốc có liên hệ trực tiếp với tính hiệu quả của thuật toán được xác định trong thiết kế chi tiết. Tuy nhiên, phong cách lập trình có thể có một tác động đến tốc độ thực hiện và yêu cầu bộ nhớ. Tập hợp các hướng dẫn sau đây bao giờ cũng có thể áp dụng được khi thiết kế chi tiết được dịch thành chương trình:

 Đơn giản hoá các biểu thức số học và lôgic trước khi đi vào lập trình.

 Tính cẩn thận từng chu kì lồng nhau để xác định liệu các câu lệnh hay biểu thức có thể được chuyển ra ngoài hay không.

 Khi có thể, hãy tránh dùng mảng nhiều chiều

 Khi có thể hãy tránh việc dùng con trỏ và danh sách phức tạp.

 Dùng các phép toán số học "nhanh".

 Không trộn lẫn các kiểu dữ liệu, cho dù ngôn ngữ có cho phép điều đó.

 Dùng các biểu thức số học và logic bất kì khi nào có thể được.

Nhiều trình biên dịch có tính năng tối ưu tự động sinh ra chương trình hiệu quả bằng cách dồn nén các biểu thức lặp,thực hiện tính chu trình,dùng số học nhanh và áp dụng các thuật toán có hiệu quả liên quan khác. Với những ứng dụng trong đó tính hiệu quả có ý nghĩa quan trọng, những trình biên dịch như thế là công cụ lập trình không thể thiếu được.

• Hiệu quả bộ nhớ

Tính hiệu quả bộ nhớ phải được tính vào đặc trưng "phân trang" của hệ điều hành.Nói chung, tính cục bộ của chương trình hay việc bảo trì lĩnh vực chức năng qua các kết cấu có cấu trúc là một phương pháp tuyệt vời làm giảm việc phân trang và do đó làm tăng tính hiệu quả.

Hạn chế bộ nhớ trong thế giới bộ vi xử lí nhúng là mối quan tâm rất thực tế,mặc dầu bộ nhớ giá thấp, mật độ cao vẫn đang tiến hoá nhanh chóng. Nếu yêu cầu hệ thống cần tới bộ nhớ tối thiểu (như sản phẩm giá thấp, khối lượng lớn) thì trình biên dịch ngôn ngữ cấp cao phải được trù tính cẩn thận với tính năng nén bộ nhớ, hay như một phương kế cuối cùng, có thể phải dùng tới hợp ngữ.

Không giống như nhiều đặc trưng hệ thống khác phải trả giá lẫn nhau, các kĩ thuật cho hiệu quả về thời gian thực hiện đôi khi có thể dẫn tới hiệu quả bộ nhớ. Chẳng hạn, giới hạn việc dùng các mảng ba hay bốn chiều làm nảy sinh thuật toán thâm nhập phần tử đơn, thuật toán nhanh và ngắn nhất. Lần nữa, chìa khoá cho tính hiệu quả bộ nhớ là "giữ cho đơn giản".

• Hiệu quả vào / ra.

Cái vào do người dùng cung cấp và cái ra được tạo ra cho người dùng là hiệu quả khi thông tin có thể được cung cấp hay được hiêủ với một mức độ tiết kiệm nỗ lực trí tuệ.

Một số hướng dẫn đơn giản để tăng cường hiệu quả vào/ra:

 Số các yêu cầu vào/ra nên giữ mức tối thiểu

 Mọi việc vào /ra nên qua bộ đệm để làm giảm phí tổn liên lạc.

 Với bộ nhớ phụ (như đĩa) nên lựa chọn và dùng phương pháp thâm nhập đơn giản nhất chấp nhận được.

 Nên xếp khối vào/ra với các thiết bị bộ nhớ phụ.

 Việc vào/ ra với thiết bị cuối hay máy in nên nhận diện các tính năng của thiết bị có thể cải tiến chất lượng hay tốc độ.

 Hãy nhớ rằng "siêu hiệu quả" của vào/ra là vô nghĩa nếu nó không được hiểu rõ.

Thiết kế vào/ra lập nên phong cách và cuối cùng chi phối tính hiệu quả. Những hướng dẫn trình bày trên đây là áp dụng được cho cả các bước thiết kế và lập trình cho tiến trình kĩ nghệ phần mềm.

15. Mỗi quan hệ biện chứng giữa thẩm định và xác minh (Tr 105)

Xác minh và thẩm định một hệ phần mềm là quá trình liên tục xuyên suốt mọi giai đoạn của quá trình phần mềm. Xác minh và thẩm định mang tính quá trình nhằm đảm bảo phần mềm thoả mãn các yêu cầu của khách hàng.

Xác minh và thẩm định là một quá trình kéo dài suốt vòng đời. Nó bắt đầu khi duyệt xét yêu cầu. Xác minh và thẩm định có hai mục tiêu:

- Phát hiện các khuyết tật trong hệ thống.

- Đánh giá xem hệ thống có dùng được hay không ?.

Sự khác nhau giữa xác minh và thẩm định là:

- Thẩm định: xét xem cái được xây dựng có là sản phẩm đúng không ?

- Xác minh: Xét xem cái được xây dựng có đúng là sản phẩm không ?

Như vậy xác minh là kiểm tra xem chương trình có phù hợp với đặc tả hay không. Còn thẩm định là kiểm tra xem chương trình có được như mong đợi của người dùng hay không .

Có hai loại phép thử:

- Phép thử thống kê: để phản ánh tần suất các input của người dùng thực và sau khi vận hành máy có thể cho ra một đánh giá độ tin cậy thao tác của hệ thống.

- Phép thử khuyết tật: để bộc lộ các khuyết tật trong hệ thống.

16. 5 giai đoạn của quá trình thử nghiệm là gì? Nêu tên các chiến lược thường dùng.

(Tr 106)

Trừ các hệ nhỏ, nói chung không nên thử hệ thống nguyên cả khối. Quá trình thử có thể chia làm 5 giai đoạn:

1) Thử đơn vị.

2) Thử modul ( chức năng ).

3) Thử hệ con.

4) Thử hệ thống.

5) Thử sau lưng (alpha) và thử điều tra (beta).

*Kế hoạch thử nghiệm.

Thử hệ thống là rất đắt, đối với một vài hệ thời gian thực có các ràng buộc thời gian phức tạp thì việc thử có thể ngốn hết khoảng nửa tổng chi phí phát triển. Vì thế mà phải lập kế hoạch thử và khống chế chi phí thử.

Việc thử liên quan nhiều đến việc thiết lập ra các mẫu cho quá trình thử nhiều hơn là mô tả các phép thử.

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

Có các chiến lược thử như sau:

1) Thử từ - trên - xuống: nên dùng cho các phát triển từ - trên - xuống.

2) Thử từ dưới lên: việc thử từ dưới lên luôn luôn là cần thiết cho các thành phần hệ thống mức thấp.

3) Thử luồn sợi: dùng cho các hệ thời gian thực.

4) Thử gay cấn (áp lực): cho những hệ thống có giới hạn tải, và phép thử tăng dần tải cho tới khi hệ thống sập đổ để xác định độ chịu tải thực sự.