TIÊU CHUẨN QUỐC GIA TCVN 10540:2014 (ISO/IEC 25051:2006) VỀ KỸ THUẬT PHẦN MỀM – YÊU CẦU VÀ ĐÁNH GIÁ CHẤT LƯỢNG SẢN PHẨM PHẦN MỀM – YÊU CẦU CHẤT LƯỢNG VÀ HƯỚNG DẪN KIỂM TRA SẢN PHẨM PHẦN MỀM SẴN SÀNG PHỔ BIẾN VÀ THƯƠNG MẠI HÓA (COTS)

TIÊU CHUẨN QUỐC GIA

TCVN 10540:2014

ISO/IEC 25051:2006

KỸ THUẬT PHẦN MỀM – YÊU CẦU VÀ ĐÁNH GIÁ CHẤT LƯỢNG SẢN PHẨM PHẦN MỀM – YÊU CẦU CHẤT LƯỢNG VÀ HƯỚNG DẪN KIỂM TRA SẢN PHẨM PHẦN MỀM SẴN SÀNG PHỔ BIẾN VÀ THƯƠNG MẠI HÓA (COTS)

Software engineering – Software Product Quality Requirements and Evaluation – Requirements for qulity of Commercial Of-The-Shelf (COTS) software product and intructions for testing

Lời nói đầu

TCVN 10540:2014 hoàn toàn tương đương với ISO/IEC 25051:2006 Software engineering – Software Product Quality Requirements and Evaluation – Requirements for qulity of Commercial Of-The-Shelf (COTS) software product and instructions for testing (Kỹ thuật phần mềm – Yêu cầu và đánh giá chất lượng sản phẩm phần mềm – Yêu cầu chất lượng và hướng dẫn kiểm tra sản phẩm phần mềm sẵn sàng phổ biến và thương mại hóa).

TCVN 10540:2014 do Viện Khoa học Kỹ thuật Bưu điện biên soạn, Bộ Thông tin và truyền thông đề nghị, Tổng cục Tiêu chuẩn Đo lường Chất lượng thẩm định, Bộ Khoa học và Công nghệ công bố.

Giới thiệu

Sản phẩm phần mềm sẵn sàng phổ biến và thương mại hóa (COTS) được sử dụng rộng rãi cho nhiều lĩnh vực ứng dụng khác nhau và hoạt động đúng của chúng thường quan trọng đối với nghiệp vụ, tính an toàn hay cho các ứng dụng cá nhân.

Sản phẩm phần mềm COTS là các gói làm sẵn được bán cả gói cho các bên thu mua, những người không có tác động đến các đặc tính và chất lượng của sản phẩm. Thông thường phần mềm được bán cùng với tài liệu người sử dụng. Thông tin được cung cấp trong gói sản phẩm thường chỉ là các phương tiện để nhà sản xuất hoặc tổ chức thương mại có thể liên hệ với bên thâu nhận hay người sử dụng. Do đó quan trọng là cần đưa ra các thông tin thiết yếu cho phép đánh giá chất lượng sản phẩm phần mềm COTS theo các yêu cầu của họ.

Lựa chọn sản phẩm phần mềm COTS chất lượng cao là điểm quan trọng đầu tiên, vì rằng các sản phẩm phần mềm COTS có thể phải hoạt động trong các môi trường khác nhau và được lựa chọn mà không có so sánh hiệu năng giữa các sản phẩm tương tự. Các nhà cung cấp cần phương thức đảm bảo tính tin cậy vào các dịch vụ sản phẩm phần mềm COTS cung cấp cho người sử dụng. Một số nhà cung cấp có thể chọn đánh giá hoặc chứng thực từ bên thứ ba để hỗ trợ họ cung cấp tính tin cậy này.

Ngoài ra, khi người sử dụng yêu cầu đảm bảo khi các có các rủi ro trọng yếu cho nghiệp vụ hay tính an toàn, các đảm bảo này có thể cần được người sử dụng giải quyết sử dụng các kỹ thuật được chọn sau khi đã chi trả. Tiêu chuẩn này không có ý định xác định các yêu cầu chất lượng tối thiểu của tính an toàn hay nghiệp vụ cho COTS, tuy nhiên hướng dẫn tham khảo được đưa ra trong Phụ lục B.

ISO/IEC 12119:1994 đã được phát triển để hỗ trợ các nhu cầu này. Tiêu chuẩn này xem xét các tiêu chuẩn TCVN 8702, TCVN 8703, TCVN 8704 về xác định các đặc tính chất lượng. ISO/IEC 12119:1994 được các tổ chức công nhận sử dụng, và có một số khó khăn và chưa được rõ ràng.

Các thiếu sót này là các điểm chủ yếu trong lần tiêu chuẩn chỉnh sửa này. Tiêu chuẩn này cung cấp một bộ các yêu cầu cho sản phẩm phần mềm COTS và các yêu cầu kiểm tra sản phẩm phần mềm COTS đối với các yêu cầu của chúng.

Tiêu chuẩn này chỉnh sửa từ ISO/IEC 12119:1994 cụ thể:

• Thống nhất với bộ tiêu chuẩn ISO/IEC 25010;

• Xem xét kinh nghiệm rút ra từ sử dụng tiêu chuẩn, đặc biệt là từ các tổ chức công nhận;

• Xem xét ngữ cảnh chuẩn mực mới;

• Bổ sung phần về kiểm tra;

• Loại bỏ Phụ lục B để thống nhất với ISO 9127.

 

TCVN 10540:2014

KỸ THUẬT PHẦN MỀM – YÊU CẦU VÀ ĐÁNH GIÁ CHẤT LƯỢNG SẢN PHẨM PHẦN MỀM – YÊU CẦU CHẤT LƯỢNG VÀ HƯỚNG DẪN KIỂM TRA SẢN PHẨM PHẦN MỀM SẴN SÀNG PHỔ BIẾN VÀ THƯƠNG MẠI HÓA (COTS)

Software engineering – Software Product Quality Requirements and Evaluation – Requirements for qulity of Commercial Of-The-Shelf (COTS) software product and intructions for testing

1. Phạm vi áp dụng

Tiêu chuẩn này áp dụng cho các sản phẩm phần mềm sẵn sàng phổ biến và thương mại hóa (COTS).

VÍ DỤ: Ví dụ về sản phẩm phần mềm COTS: bộ xử lý văn bản, bảng tính; phần mềm điều khiển cơ sở dữ liệu, gói đồ họa; phần mềm cho các tính năng kỹ thuật, khoa học hay nhúng thời gian thực như hệ điều hành thời gian thực hay mạng cục bộ cho hàng không/truyền thông, máy rút tiền tự động, chuyển tiền; phần mềm quản lý nguồn nhân lực, quản lý bán hàng và phần mềm web như bộ tạo website/trang web.

Tiêu chuẩn này thiết lập:

a) Các yêu cầu về chất lượng cho sản phẩm phần mềm COTS;

b) Các yêu cầu về bộ tài liệu phục vụ kiểm tra cho quá trình kiểm tra sản phẩm phần mềm COTS, bao gồm yêu cầu kiểm tra, trường hợp kiểm tra và báo cáo kiểm tra;

c) Hướng dẫn đánh giá sự phù hợp của các sản phẩm phần mềm COTS.

Tiêu chuẩn này cũng bao gồm các khuyến nghị cho sản phẩm phần mềm COTS phục vụ cho an toàn hay cho các nghiệp vụ quan trọng.

Tiêu chuẩn này giúp người sử dụng tin tưởng về sản phẩm phần mềm COTS sẽ thực hiện đúng như nó được công bố. Nó không đề cập đến quá trình sản xuất (bao gồm các hoạt động và sản phẩm trung gian, như các đặc tính kỹ thuật) cũng như hệ thống chất lượng của nhà cung cấp. Đối tượng sử dụng của tiêu chuẩn bao gồm:

a) Nhà cung cấp khi:

1. Xác định các yêu cầu cho sản phẩm phần mềm COTS;

2. Công bố hiệu năng cho sản phẩm của họ (ISO 9127);

3. Đánh giá các sản phẩm phần mềm của chính họ đối với hiệu năng đã công bố;

4. Đưa ra công bố về sự phù hợp (ISO/IEC 17050);

5. Xin chứng chỉ hay công nhận về sự phù hợp (ISO/IEC Guide 23);

b) Tổ chức chứng nhận có thể mong muốn thiết lập chương trình chứng nhận cho bên thứ ba (cấp quốc tế, khu vực hay quốc gia) (ISO/IEC Guide 28);

c) Phòng thử nghiệm (phải tuân theo các hướng dẫn kiểm tra khi kiểm tra) để cấp chứng chỉ hay công nhận sự phù hợp (TCVN ISO/IEC 17025:2007);

d) Tổ chức công nhận, chứng nhận và các phòng đo kiểm;

e) Bên thâu nhận tiềm năng có thể:

1. So sánh các yêu cầu dự kiến với thông tin mô tả sản phẩm của sản phẩm phần mềm đang có;

2. Xem xét sản phẩm COTS đã được chứng nhận;

3. Kiểm tra các yêu cầu có được đáp ứng hay không.

f) Người sử dụng cuối (được lợi ích từ các sản phẩm phần mềm tốt hơn);

g) Các tổ chức:

1. Thiết lập các môi trường quản lý và môi trường kỹ thuật dựa trên các yêu cầu và phương pháp của tiêu chuẩn này;

2. Quản lý và nâng cao chất lượng quy trình xử lý và nhân sự của họ;

h) Cơ quan có thẩm quyền có thể yêu cầu hay khuyến nghị các điều kiện cần thiết của tiêu chuẩn này cho các sản phẩm phần mềm COTS được sử dụng trong lĩnh vực an toàn hoặc trong các ứng dụng nghiệp vụ quan trọng.

2. Sự phù hợp

Sản phẩm phần mềm COTS phù hợp với tiêu chuẩn này nếu:

a) Có các thuộc tính xác định trong điều 5;

b) Nó được kiểm tra bằng tài liệu kiểm tra sản phẩm đáp ứng các yêu cầu trong điều 6;

c) Các khác thường phát hiện trong quá trình kiểm tra được lập tài liệu và giải quyết trước khi sản phẩm được phát hành. Các khác thường đối lập với các công bố hiệu năng quảng bá phải được khắc phục hoặc các công bố phải được dỡ bỏ. Các khác thường đã biết có thể được xem xét chấp nhận được nếu:

1) Khác thường không phải là vi phạm công bố hiệu năng; và

2) Nhà cung cấp đã xem xét một cách hợp lệ bản chất và ảnh hưởng của khác thường đến bên thu mua và cho là nó không đáng kể, và bảo lưu tài liệu của các khác thường cho cải tiến tương lai.

Các khuyến nghị phân cấp nhỏ hơn là tùy chọn.

CHÚ THÍCH: Để trang bị đánh giá sự phù hợp, các yêu cầu của tiêu chuẩn này được soạn thảo theo cách chúng là phân cấp mức 3 (đánh số X.X.X.X). Các chú thích tham khảo hoàn thiện các mục này và có thể dùng như hướng dẫn.

3. Tài liệu viện dẫn

Các tài liệu viện dẫn sau đây là cần thiết để áp dụng tiêu chuẩn này. Đối với các tài liệu viện dẫn ghi năm công bố thì áp dụng bản được nêu. Đối với các tài liệu viện dẫn không ghi năm công bố thì áp dụng phiên bản mới nhất, bao gồm cả các sửa đổi, bổ sung (nếu có).

ISO/IEC 25000:2005 – Software engineering – Software product quality requirements and evaluation (SQuaRE) – Guide to SQuaRE (ISO/IEC 25000 – Kỹ thuật phần mềm – Các yêu cầu và đánh giá chất lượng sản phẩm phần mềm (SQuaRE) – Hướng dẫn SQuaRE).

ISO/IEC 25010:2011 – System and software engineering – System and software quality requirements and evaluation (SQuaRE) – System and software quality models (ISO/IEC 25010:2011 – Kỹ thuật hệ thống và phần mềm – Các yêu cầu đánh giá chất lượng hệ thống và phần mềm (SQuaRE) – Mô hình chất lượng hệ thống và phần mềm).

Xem các tài liệu viện dẫn tham khảo bổ sung trong Thư mục tài liệu tham khảo.

4. Thuật ngữ và định nghĩa

4.1

Báo cáo đánh giá sự phù hợp (conformity evaluation report)

Tài liệu mô tả quá trình kiểm tra và kết quả đánh giá đã thực hiện cho sản phẩm phần mềm COTS.

CHÚ THÍCH: Điều này đã được điều chỉnh từ IEEE Std 610.12-1990.

4.2

Chức năng (function)

Thực thi của một thuật toán trong phần mềm mà người dùng cuối hay phần mềm có thể hoàn thành một phần hoặc tất cả nhiệm vụ công việc.

CHÚ THÍCH: Chức năng không nhất thiết phải có khả năng gọi bởi người dùng cuối (ví dụ như dự phòng hay lưu trữ dữ liệu tự động).

4.3

Đánh giá sự phù hợp (conformity evaluation)

Kiểm tra một cách hệ thống mức độ mà sản phẩm, quá trình hay dịch vụ hoàn thành các yêu cầu xác định.

CHÚ THÍCH 1: Xem ISO/IEC Guide 2:1996.

CHÚ THÍCH 2: ISO/IEC Guide 2: 1996 đã bị hủy và thay thế bằng TCVN 6450: 2007 (ISO/IEC Guide 2: 2004).

4.4

Kế hoạch kiểm tra (test plan)

Tài liệu mô tả phạm vi, phương pháp, nguồn tài nguyên và lịch trình các hoạt động dự kiến kiểm tra.

CHÚ THÍCH: Điều này được điều chỉnh từ IEEE Std 610.12-1990.

4.5

Mô tả sản phẩm (product description)

Tài liệu mô tả các thuộc tính của phần mềm với mục đích chính là giúp người mua sản phẩm tiềm năng đánh giá khả năng phù hợp của phần mềm cho chính bản thân họ trước khi mua nó.

4.6

Môi trường kiểm tra (test enviroment)

Cấu hình cần thiết của phần cứng và phần mềm để tiến hành tình huống kiểm tra.

4.7

Mục tiêu kiểm tra (test objective)

Một bộ các đặc tính phần mềm đã xác định được đo dưới các điều kiện cụ thể bằng cách so sánh hành vi thực tế với hành vi yêu cầu.

CHÚ THÍCH: Điều này đã chỉnh sửa từ IEEE Std 610.12-1990.

4.8

Mô tả kiểm tra (testing description)

Mô tả các điều kiện thực hiện kiểm tra (tức là thủ tục kiểm tra).

4.9

Phần mềm sẵn sàng phổ biến và thương mại hóa (COTS software product: commercial-of-the shelf software product)

Phần mềm được xác định bằng nhu cầu thị trường, sẵn sàng thương mại hóa và tính phù hợp cho sử dụng của chúng được chứng minh bằng cộng đồng người sử dụng thương mại.

CHÚ THÍCH 1: Sản phẩm phần mềm thương mại COTS bao gồm:

• Mô tả sản phẩm (bao gồm tất cả thông tin bao hàm, bảng dữ liệu, thông tin website …),

• Tài liệu người sử dụng (cần thiết để cài đặt và sử dụng phần mềm),

• Phần mềm chứa trong một phương tiện máy tính cảm nhận được (đĩa, CD-ROM, có khả năng tải về từ Internet…).

CHÚ THÍCH 2: Điều này đã chỉnh sửa từ TCVN 8708:2011.

CHÚ THÍCH 3: Phần mềm chủ yếu được tạo thành từ các chương trình và dữ liệu.

CHÚ THÍCH 4: Định nghĩa này cũng áp dụng cho mô tả sản phẩm, tài liệu hướng dẫn người sử dụng và phần mềm được tạo ra và được hỗ trợ như hàng hóa được sản xuất riêng, nhưng đối với các khoản phí thương mại và các xem xét bản quyền của chúng có thể không áp dụng.

4.10

Tài liệu yêu cầu (requirement document)

Tài liệu chứa đựng bất cứ tổ hợp các yêu cầu hay quy định nào được đáp ứng bởi sản phẩm phần mềm COTS.

CHÚ THÍCH: Ví dụ, tài liệu này có thể là báo cáo kỹ thuật, tiêu chuẩn, danh sách các yêu cầu (hoặc đặc tính yêu cầu mô hình) cho một loại người sử dụng, hoặc điều lệ hay quy định áp dụng bởi cơ quan chính phủ hay luật pháp.

4.11

Tài liệu hướng dẫn kiểm tra (test documentation)

Tập hợp tài liệu gắn liền với các hoạt động kiểm tra.

Xem phụ lục A cho các định nghĩa bổ sung từ các tiêu chuẩn khác.

5. Các yêu cầu đánh giá sản phẩm phần mềm COTS

5.1. Các yêu cầu mô tả sản phẩm

CHÚ THÍCH: Mục này liên quan đến thông tin bao hàm của ISO/IEC 9127 Software engineering – User documentation and cover information for consumer software package (ISO/IEC 9127 Kỹ thuật phần mềm – Tài liệu hướng dẫn người sử dụng và thông tin bao hàm cho gói phần mềm tiêu dùng) có thể được sử dụng như đầu vào để tạo ra mô tả sản phẩm.

5.1.1. Tính sẵn sàng

5.1.1.1. Mô tả sản phẩm phải sẵn sàng cho bên thâu nhận tiềm năng và người sử dụng sản phẩm.

5.1.2. Nội dung

5.1.2.1. Mô tả sản phẩm phải chứa thông tin cần thiết cho bên thâu nhận tiềm năng để đánh giá tính thích hợp của phần mềm đối với các nhu cầu của chúng.

5.1.2.2. Mô tả sản phẩm phải không có các mâu thuẫn nội tại.

5.1.2.3. Các tuyên bố bao gồm trong mô tả sản phẩm phải có khả năng kiểm tra hay xác minh.

5.1.3. Nhận biết và chỉ dẫn

5.1.3.1. Mô tả sản phẩm phải thể hiện một định danh duy nhất.

5.1.3.2. Sản phẩm phần mềm COTS phải được đặc tả bằng tên của nó, phiên bản và ngày tháng.

5.1.3.3. Mô tả sản phẩm phải bao gồm tên và địa chỉ (bưu điện hay web) của nhà cung cấp và ít nhất một bên bán hàng, bên bán hàng thương mại điện tử hay nhà phân phối (nếu có khả năng áp dụng).

5.1.3.4. Mô tả sản phẩm phải chỉ rõ các nhiệm vụ công việc và dịch vụ có thể được thực hiện với phần mềm.

5.1.3.5. Với các yêu cầu do cơ quan quản lý hay cơ quan pháp luật xác định để áp dụng cho sản phẩm phần mềm COTS và nhà cung cấp muốn tuyên bố sự phù hợp với các tài liệu yêu cầu tương ứng, thì mô tả sản phẩm phải xác định các tài liệu yêu cầu đó.

5.1.3.6. Mô tả sản phẩm phải chỉ dẫn sản phẩm phần mềm COTS được dự định cho nhiều người sử dụng cuối đồng thời hay chỉ một người sử dụng đơn trên hệ thống đơn và phải tuyên bố số lượng lớn nhất người sử dụng cuối đồng thời khả thi tại mức hiệu năng công bố trên hệ thống yêu cầu.

5.1.3.7. Nếu mô tả sản phẩm tham chiếu đến các giao diện với phần mềm khác, mà các giao diện này có khả năng gọi tên và người sử dụng đã biết, thì các giao diện này hay phần mềm phải được định danh.

5.1.3.8. Mô tả sản phẩm phải chỉ ra nơi sản phẩm phần mềm COTS cài đặt dựa trên phần mềm và/hoặc phần cứng cụ thể với các tham chiếu thích hợp.

CHÚ THÍCH: Ví dụ tham chiếu có thể bao gồm:

• Tên của phần mềm và/hoặc phần cứng;

• Phiên bản;

• Hệ điều hành cụ thể.

5.1.3.9. Mô tả sản phẩm phải công bố việc hỗ trợ vận hành sản phẩm phần mềm COTS có được cung cấp hay không.

5.1.3.10. Mô tả sản phẩm phải công bố việc bảo trì có được đưa ra hay không. Nếu được đưa ra, mô tả sản phẩm phải mô tả dịch vụ bảo trì được đưa ra.

5.1.4. Các công bố về tính năng

5.1.4.1. Nếu ứng dụng được mô tả sản phẩm phải bao gồm các công bố về tính năng, xem xét tính thích hợp, tính chính xác, khả năng tương tác, an toàn và khả năng tuân thủ của tính năng, được biên soạn sao cho bằng chứng xác minh sự tuân thủ có thể được chứng minh, dựa trên ISO/IEC 9126-1:2001 (phiên bản mới ISO/IEC 25010:2011).

5.1.4.2. Mô tả sản phẩm phải cung cấp tổng quan các chức năng có thể gọi được của người sử dụng cuối của sản phẩm.

5.1.4.3. Mô tả sản phẩm phải mô tả tất cả các chức năng quan trọng.

CHÚ THÍCH: Xem các thông tin chi tiết hơn trong Phụ lục A và ISO/IEC 15026.

5.1.4.4. Nếu có các tùy chọn và phiên bản của thành phần phần mềm phải được chỉ ra.

5.1.4.5. Tất cả các giới hạn của tính năng người sử dụng phải được mô tả.

CHÚ THÍCH: Ví dụ, các giới hạn có thể là:

• Các giá trị tối thiểu hay tối đa;

• Độ dài từ khóa;

• Số lượng tối đa các bản ghi trong tệp;

• Số lượng tối đa các tiêu chí tìm kiếm;

• Kích cỡ mẫu nhỏ nhất.

5.1.4.6. Nếu có cung cấp ngăn chặn truy cập bất hợp pháp vào phần mềm bất kể vô tình hay cố ý, thì mô tả sản phẩm phải bao gồm thông tin này.

5.1.5. Các công bố về tính tin cậy

5.1.5.1. Nếu ứng dụng được mô tả sản phẩm phải bao gồm các công bố về tính tin cậy, xem xét mức độ trưởng thành, khả năng chịu lỗi, khả năng phục hồi và tuân thủ của tính tin cậy, được biên soạn sao cho bằng chứng xác minh sự tuân thủ có thể được chứng minh, dựa trên ISO/IEC 9126-1:2001 (phiên bản mới ISO/IEC 25010:2011).

CHÚ THÍCH: Không cần thực hiện tuyên bố nào về tính tin cậy trừ khi người phát triển có thể chứng minh tuyên bố này với dữ liệu sử dụng hay dữ liệu xác minh khác.

5.1.5.2. Mô tả sản phẩm phải chỉ ra khả năng của phần mềm tiếp vẫn tục hoạt động (tức là vẫn có khả năng sử dụng) trong trường hợp lỗi giao diện người sử dụng, lỗi trong bản thân lôgic ứng dụng, hay lỗi do tính sẵn sàng của hệ thống hay nguồn tài nguyên hệ thống.

5.1.5.3. Mô tả sản phẩm phải bao gồm thông tin thủ tục ghi và dữ liệu lưu trữ.

CHÚ THÍCH: Có thể chấp nhận việc thực hiện chỉ thị xác nhận dữ liệu được dự phòng bằng các chức năng của hệ điều hành.

5.1.6. Các công bố về tính khả dụng

5.1.6.1. Nếu ứng dụng được mô tả sản phẩm phải bao gồm các công bố về tính khả dụng, có xem xét đến tính dễ hiểu, tính dễ học hỏi, khả năng vận hành, tính thân thiện và tuân thủ của tính khả dụng, được biên soạn sao cho bằng chứng xác minh sự tuân thủ có thể chứng minh được dựa trên ISO/IEC 9126-1:2001 (phiên bản mới ISO/IEC 25010:2011).

5.1.6.2. Mô tả sản phẩm phải xác định loại của giao diện phần mềm.

CHÚ THÍCH: Ví dụ, các giao diện có thể là:

• Dòng lệnh;

• Menu;

• Cửa sổ;

• Trình duyệt web;

• Phim chức năng;

• Chức năng hỗ trợ.

5.1.6.3 Mô tả sản phẩm phải xác định các kiến thức cụ thể yêu cầu để sử dụng và vận hành phần mềm.

CHÚ THÍCH: Ví dụ, chúng có thể là:

• Kiến thức gọi cơ sở dữ liệu và giao thức sử dụng;

• Kiến thức lĩnh vực kỹ thuật;

• Kiến thức hệ điều hành;

• Kiến thức có được nhờ khóa đào tạo đặc biệt;

• Kiến thức ngôn ngữ khác với ngôn ngữ mô tả sản phẩm được biên soạn;

5.1.6.4. Nếu người sử dụng có thể sửa đổi phần mềm cho phù hợp, thì các công cụ hay thủ tục cho việc sửa đổi này và các điều kiện sử dụng chúng phải được xác định.

CHÚ THÍCH: Ví dụ, các điều kiện có thể là:

• Thay đổi các tham số;

• Thay đổi thuật toán tính toán;

• Tùy chỉnh giao diện;

• Bố trí phím chức năng.

5.1.6.5. Nếu bảo vệ kỹ thuật chống lại vi phạm bản quyền có thể cản trở tính khả dụng, thì bảo vệ này phải được công bố.

CHÚ THÍCH: Ví dụ, các bảo vệ này có thể là:

• Thời hạn sử dụng được lập trình;

• Nhắc nhở tương tác trả tiền cho bản quyền.

5.1.6.6. Mô tả sản phẩm phải bao gồm cả chỉ dẫn về khả năng truy cập đặc biệt cho người sử dụng khuyết tật và khác biệt về ngôn ngữ.

5.1.7. Các công bố về tính hiệu quả

5.1.7.1 Mô tả sản phẩm phải bao gồm các công bố về tính hiệu quả, tính đến các đáp ứng thời gian, sử dụng tài nguyên và tuân thủ của tính hiệu quả, được biên soạn sao cho bằng chứng xác minh sự tuân thủ có thể chứng minh được dựa trên ISO/IEC 9126-1:2001 (phiên bản mới ISO/IEC 25010:2011).

CHÚ THÍCH: Ví dụ, các điều kiện có thể là:

• Cấu hình hệ thống;

• Tài nguyên cần thiết để làm việc hiệu quả với sản phẩm phần mềm COTS, như dung lượng ổ cứng, RAM, card video, card internet không dây …

5.1.8. Các công bố về khả năng bảo trì

5.1.8.1. Mô tả sản phẩm phải bao gồm các công bố về tính bảo trì, có tính đến khả năng phân tích được, khả năng thay đổi, tính ổn định, khả năng kiểm tra và tuân thủ của khả năng bảo trì, được biên soạn sao cho bằng chứng xác minh của sự tuân thủ có thể được chứng minh, dựa trên ISO/IEC 9126-1:2001 (phiên bản mới ISO/IEC 25010:2011).

5.1.8.2 Mô tả sản phẩm phải bao gồm thông tin bảo trì cho người sử dụng.

CHÚ THÍCH: Ví dụ, thông tin có thể là:

• Giám sát hiệu năng động hiện tại của ứng dụng;

• Giám sát các lỗi hỏng không mong đợi và các điều kiện quan trọng;

• Giám sát bộ chỉ thị hoạt động như màn hình đăng nhập, cảnh báo;

• Giảm sát dữ liệu cục bộ được vận hành trên ứng dụng;

5.1.9. Các công bố về tính khả chuyển

5.1.9.1. Mô tả sản phẩm phải bao gồm các công bố về tính khả chuyển, có tính đến khả năng thích nghi, khả năng cài đặt, khả năng thay thế, khả năng cùng tồn tại và tuân thủ của tính khả chuyển, được biên soạn sao cho bằng chứng xác minh sự tuân thủ có thể được chứng minh được dựa trên ISO/IEC 9126-1:2001 (phiên bản mới ISO/IEC 25010:2011).

5.1.9.2. Mô tả sản phẩm phải xác định các cấu hình khác nhau hay các cấu hình hỗ trợ (phần cứng, phần mềm) để đưa phần mềm vào sử dụng.

CHÚ THÍCH 1: Các cấu hình khác nhau có thể được xác định, như cho các nhiệm vụ công việc khác nhau, các giá trị biên khác nhau hay các yêu cầu hiệu quả khác nhau.

CHÚ THÍCH 2: Ví dụ, các hệ thống này có thể là:

• Các hệ điều hành;

• Bộ xử lý bao gồm các bộ vi xử lý kết hợp;

• Kích thước bộ nhớ chính;

• Loại và kích thước lưu trữ ngoại vi;

• Card mở rộng;

• Thiết bị vào và ra;

• Môi trường mạng;

• Phần mềm hệ thống và các phần mềm khác.

5.1.9.3. Mô tả sản phẩm phải cung cấp thông tin thủ tục cài đặt.

5.1.10. Các công bố về chất lượng sử dụng

5.1.10.1. Mô tả sản phẩm phải bao gồm các công bố về chất lượng sử dụng, có tính đến tính hiệu quả, tính năng suất, tính an toàn trong một ngữ cảnh sử dụng xác định, được biên soạn sao cho bằng chứng xác minh sự tuân thủ có thể chứng minh được dựa trên ISO/IEC 9126-1:2001 (phiên bản mới ISO/IEC 25010:2011).

CHÚ THÍCH 1: Các công bố về chất lượng sử dụng phụ thuộc rất nhiều vào ngữ cảnh sử dụng. Không thể xem xét tất cả người sử dụng có thể của COTS. Phải mô tả người sử dụng mong đợi điển hình và sử dụng dự kiến của họ.

CHÚ THÍCH 2: Ví dụ các công bố chất lượng sử dụng có thể là:

• Phần trăm của sản phẩm đã được kiểm định;

• Số lượng báo cáo hay quan sát các vấn đề chưa giải quyết trong quá trình phát triển COTS;

• Các kết quả khảo sát người sử dụng đã được chỉnh sửa hay chưa được chỉnh sửa.

Xem ISO/IEC 25062 đối với thông tin kiểm tra tính năng suất, tính hiệu quả và tính thỏa mãn.

5.1.10.2. Phải có tham chiếu cho báo cáo.

CHÚ THÍCH: Khuôn dạng báo cáo xem trong TCVN 8204 (ISO/IEC 9126-4).

5.2. Các yêu cầu cho tài liệu hướng dẫn người sử dụng

CHÚ THÍCH: ISO/IEC 9127 Software engineering – User documentation and cover information for consumer software package có thể được sử dụng để xây dựng tài liệu người sử dụng.

5.2.1. Tính hoàn thiện

5.2.1.1. Tài liệu hướng dẫn người sử dụng phải bao gồm thông tin cần thiết để sử dụng phần mềm.

5.2.1.2. Tài liệu hướng dẫn người sử dụng phải mô tả tất cả các chức năng công bố trong mô tả sản phẩm và tất cả chức năng người sử dụng cuối có thể gọi.

5.2.1.3. Tài liệu hướng dẫn người sử dụng phải mô tả các đặc tính tính tin cậy và vận hành chúng.

5.2.1.4. Tài liệu hướng dẫn người sử dụng phải liệt kê các lỗi và sự cố đã được xử lý và nguyên nhân gây ra sự cố hay dừng ứng dụng, đặc biệt là các điều kiện dẫn đến dừng ứng dụng làm mất dữ liệu.

5.2.1.5. Tài liệu hướng dẫn người sử dụng phải đưa ra hướng dẫn dự phòng và lưu trữ dữ liệu cần thiết.

5.2.1.6. Tài liệu hướng dẫn người sử dụng phải cung cấp thông tin hướng dẫn và tham chiếu hoàn chỉnh cho tất cả các chức năng phần mềm quan trọng (phần mềm mà sự cố có thể tác động đến tính an toàn và có thể gây ra mất mát lớn về tài chính hay xã hội).

CHÚ THÍCH: Xem thông tin chi tiết trong Phụ lục A.

5.2.1.7. Tài liệu hướng dẫn người sử dụng phải công bố tất cả các giới hạn trong phần mô tả sản phẩm.

5.2.1.8. Tài liệu hướng dẫn người sử dụng phải công bố dung lượng tối thiểu và tối đa yêu cầu cho việc cài đặt.

5.2.1.9. Tài liệu hướng dẫn người sử dụng phải bao gồm tất cả thông tin cần thiết cho các chức năng quản trị ứng dụng được người sử dụng thiết lập.

5.2.1.10. Thông tin cho phép người sử dụng xác minh việc hoàn thành các chức năng quản trị ứng dụng phải được bao hàm trong thông tin cho các chức năng quản trị ứng dụng được người sử dụng thiết lập.

5.2.1.11. Nếu tài liệu hướng dẫn người sử dụng được cung cấp trong nhiều phần, ít nhất một mục trong bộ tài liệu phải chỉ ra tất cả các phần.

5.2.2. Tính chính xác

5.2.2.1. Tất cả thông tin trong tài liệu hướng dẫn người sử dụng phải chính xác.

CHÚ THÍCH: Tất cả thông tin trong tài liệu hướng dẫn người sử dụng phải được truy xuất nguồn gốc từ các nguồn thẩm quyền cho tính chính xác.

5.2.2.2. Tài liệu hướng dẫn người sử dụng phải biểu diễn thông tin rõ ràng.

5.2.3. Tính thống nhất

5.2.3.1. Các tài liệu của tài liệu hướng dẫn người sử dụng phải không có mâu thuẫn nội bộ trong chúng, không có mâu thuẫn lẫn nhau và với mô tả sản phẩm.

CHÚ THÍCH: Tính thống nhất với phần mềm liên quan đến mục 5.3.1.5.

5.2.4. Tính dễ hiểu

5.2.4.1. Tài liệu hướng dẫn người sử dụng phải dễ hiểu đối với phần lớn người sử dụng mà sản phẩm phần mềm COTS hướng tới bằng cách sử dụng thuật ngữ và phong cách dễ hiểu.

CHÚ THÍCH: Ví dụ, sản phẩm phần mềm COTS dành cho các kiến trúc sư.

5.2.4.2. Danh sách tài liệu được sắp xếp để tạo thuận lợi cho người sử dụng tài liệu.

5.2.5. Tính dễ học

5.2.5.1. Tài liệu hướng dẫn người sử dụng phải cung cấp thông tin cần thiết để học cách sử dụng phần mềm như thế nào.

CHÚ THÍCH: Tài liệu hướng dẫn người sử dụng có thể tham chiếu thông tin bổ sung chứa trong bản thân gói phần mềm COTS, hoặc trong tài liệu phụ trợ như đào tạo.

5.2.6. Tính dễ vận hành

5.2.6.1. Nếu tài liệu hướng dẫn người sử dụng không được cung cấp dưới dạng bản in, tài liệu phải chỉ dẫn nó có thể được in ra được không, hoặc cách để nhận được bản in như thế nào.

5.2.6.2. Tài liệu hướng dẫn người sử dụng, ngoại trừ dạng thẻ và hướng dẫn tham chiếu nhanh, phải có bảng nội dung, hay danh sách các chủ đề và mục lục.

5.2.6.3. Tài liệu hướng dẫn người sử dụng phải định nghĩa các thuật ngữ sử dụng không thông dụng và các từ viết tắt.

5.3. Các yêu cầu chất lượng cho phần mềm

CHÚ THÍCH: Phần mềm mà sự cố của nó có thể tác động đến tính an toàn hay các mục tiêu quan trọng nghiệp vụ có thể xem xét hướng dẫn và khuyến nghị trong Phụ lục A.

5.3.1. Tính chức năng

5.3.1.1. Trong quá trình cài đặt, phải có khả năng nhận biết phần mềm có thể hoạt động không.

CHÚ THÍCH: Ví dụ, xác minh chức năng hoạt động tốt hay không có thể thực hiện bằng cách sử dụng trường hợp kiểm tra được cung cấp hay bằng cách tự kiểm tra các bản tin tương ứng, hay bằng các bài kiểm tra khác được thực hiện bởi người sử dụng.

5.3.1.2. Tất cả các chức năng đề cập đến trong tài liệu hướng dẫn người sử dụng phải có khả năng thực hiện cùng với các phương tiện, đặc tính, dữ liệu tương ứng và trong phạm vi đưa ra trong đó.

5.3.1.3. Chức năng của phần mềm phải có khả năng thực hiện theo tất cả các công bố trong tài liệu hướng dẫn người sử dụng.

5.3.1.4. Phần mềm phải tuân thủ tất cả các yêu cầu trong các tài liệu được tham chiếu trong mô tả sản phẩm.

5.3.1.5. Phần mềm phải không có các mâu thuẫn trong nội bộ bản thân và mâu thuẫn với mô tả sản phẩm hay tài liệu hướng dẫn người sử dụng.

CHÚ THÍCH: Hai hoạt động giống nhau phải đưa ra cùng kết quả.

5.3.1.6. Người sử dụng cuối kiểm soát vận hành phần mềm theo tài liệu hướng dẫn người sử dụng phải đồng nhất với phần mềm.

5.3.2. Tính tin cậy

5.3.2.1. Phần mềm phải thực thi theo các đặc tính tính tin cậy được xác định trong tài liệu hướng dẫn người sử dụng.

5.3.2.2. Chức năng liên quan đến xử lý lỗi phải thống nhất với các công bố tương ứng trong mô tả sản phẩm và tài liệu hướng dẫn người sử dụng.

CHÚ THÍCH: Phần mềm không thể chịu trách nhiệm cho các loại sự cố xuất phát trong hệ điều hành hay mạng.

5.3.2.3. Phần mềm không thể để mất dữ liệu khi được sử dụng trong phạm vi giới hạn công bố trong tài liệu hướng dẫn người sử dụng.

CHÚ THÍCH: Yêu cầu này có thể được đáp ứng trong các trường hợp

• Khả năng được khai thác đến các giới hạn xác định;

• Thực hiện thử nghiệm khai thác khả năng vượt quá các giới hạn xác định;

• Thực hiện đầu vào không đúng từ người sử dụng cuối hay từ phần mềm khác được liệt kê trong mô tả sản phẩm;

• Các chỉ dẫn tường minh trong tài liệu hướng dẫn người sử dụng bị vi phạm.

5.3.2.4. Phần mềm phải nhận biết được các vi phạm điều kiện cú pháp đầu vào và nó không được xử lý như đầu vào cho phép.

5.3.3. Tính khả dụng

5.3.3.1. Các câu hỏi, thông điệp và kết quả thực hiện phần mềm phải có khả năng hiểu được.

CHÚ THÍCH 1: Ví dụ, tính dễ hiểu có thể đạt được

• Bằng lựa chọn đầy đủ các điều khoản;

• Bằng biểu diễn đồ họa;

• Bằng cung cấp thông tin kiến thức cơ bản;

• Bằng diễn giải của chức năng trợ giúp.

CHÚ THÍCH 2: Đối với khía cạnh tính khả dụng, các bên tham gia thỏa thuận dựa trên tiêu chuẩn này khuyến khích phát hiện khả năng ứng dụng phiên bản mới nhất trong bộ ISO 9241. Đặc biệt phần 1,2, các phần từ 10 đến 17 của bộ ISO 9241 và ISO/IEC 25062 phải được xem xét.

5.3.3.2. Thông điệp bảo lỗi phần mềm phải chỉ dẫn sửa lỗi như thế nào hay liên hệ với ai để báo cáo lỗi.

CHÚ THÍCH: Thông tin này có thể được tham chiếu tới mục nhỏ trong tài liệu hướng dẫn người sử dụng.

5.3.3.3. Phần mềm phải cung cấp thông tin dưới dạng dễ hiểu cho người sử dụng cuối, tức là đầu ra dạng văn bản hay đồ họa phải dễ nhìn và dễ đọc, đầu ra dạng âm thanh phải dễ nghe.

5.3.3.4 Thông điệp từ phần mềm phải được thiết kế sao cho người sử dụng cuối có thể dễ dàng hiểu loại của bản tin.

CHÚ THÍCH: Các thông điệp này có thể là

• Kiến thức;

• Yêu cầu từ phần mềm;

• Cảnh báo;

• Các thông điệp báo lỗi.

5.3.3.5. Các khuôn dạng đầu vào màn hình, báo cáo và các đầu ra phải rõ ràng và dễ hiểu đối với người sử dụng.

5.3.3.6. Thực hiện chức năng có hậu quả nghiêm trọng phải có khả năng quay lại, hay phần mềm phải đưa ra cảnh báo rõ ràng về các hậu quả và yêu cầu khẳng định trước khi thực hiện câu lệnh.

CHÚ THÍCH: Xóa hay ghi đè dữ liệu, cũng như làm gián đoạn hoạt động của quá trình xử lý dài có các hậu quả nghiêm trọng.

5.3.3.7. Người sử dụng cuối phải có khả năng học sử dụng chức năng thông qua các phương tiện cung cấp bằng giao diện người sử dụng, chức năng trợ giúp hay tài liệu hướng dẫn người sử dụng.

5.3.3.8. Người sử dụng cuối phải được tư vấn khi thực hiện chức năng với thời gian đáp ứng vượt quá giới hạn dự tính thông thường.

5.3.3.9. Mỗi thành phần (phương tiện dữ liệu, tệp, …) phải mang định danh sản phẩm và nếu có nhiều hơn một định danh thì phải mang cả số lượng định danh hay văn bản.

5.3.4. Tính hiệu quả

5.3.4.1. Các công bố về tính hiệu quả trong mô tả sản phẩm phải được tuân thủ.

CHÚ THÍCH: Thông báo tới người sử dụng cuối khi thời gian đợi phản hồi là không hợp lý.

5.3.5. Khả năng bảo trì

5.3.5.1. Các công bố về khả năng bảo trì trong mô tả sản phẩm phải được tuân thủ.

CHÚ THÍCH: Ví dụ, khả năng chẩn đoán các khiếm khuyết, khả năng cho phép thay đổi.

5.3.6. Tính khả chuyển

5.3.6.1. Nếu người sử dụng có thể thực hiện cài đặt, phần mềm phải được cài đặt thành công bằng cách tuân theo thông tin trong tài liệu cài đặt.

5.3.6.2. Cài đặt thành công và hoạt động đúng của ứng dụng phần mềm phải được kiểm tra đối với tất cả nền tảng và hệ thống hỗ trợ được liệt kê trong mô tả sản phẩm.

5.3.6.3. Nếu người sử dụng có thể thực hiện cài đặt và phần mềm có bất cứ ràng buộc cùng tồn tại nào với một thành phần đã cài đặt, thì điều này phải được công bố trước khi cài đặt xảy ra.

5.3.6.4. Phần mềm phải cung cấp phương tiện cho người sử dụng loại bỏ hay gỡ cài đặt tất cả các thành phần được cài đặt.

5.3.7. Chất lượng sử dụng

5.3.7.1. Các công bố về chất lượng sử dụng trong mô tả sản phẩm phải được tuân thủ.

6. Yêu cầu cho tài liệu hướng dẫn kiểm tra

6.1. Các yêu cầu chung

6.1.1. Mục tiêu

6.1.1.1. Mục tiêu tài liệu hướng dẫn kiểm tra là chứng minh sự phù hợp của phần mềm đối với các yêu cầu xác định trong mục 5.3. Nó bao gồm tất cả các thành phần cho phép chứng minh này.

6.1.2. Tính thống nhất

6.1.2.1. Thông tin chứa trong mỗi tài liệu của tài liệu hướng dẫn kiểm tra phải có khả năng xác minh và đúng.

6.1.2.2. Mỗi tài liệu của tài liệu hướng dẫn kiểm tra không được mâu thuẫn nội bộ và mâu thuẫn với mô tả sản phẩm và tài liệu người sử dụng.

6.1.3. Các yêu cầu cho nội dung

6.1.3.1. Tài liệu hướng dẫn kiểm tra phải bao gồm

a) Kế hoạch kiểm tra;

b) Mô tả kiểm tra;

c) Kết quả kiểm tra.

6.1.3.2. Tài liệu hướng dẫn kiểm tra phải bao gồm danh sách tất cả tài liệu thành phần của nó, với tiêu đề và định danh của chúng.

6.1.3.3. Mỗi tài liệu của tài liệu kiểm tra phải bao gồm:

• Tiêu đề;

• Định danh đơn (tham chiếu, số phiên bản, ngày phát hành);

• Lược sử các thay đổi hay bất cứ thành phần nào khác mô tả phát triển tài liệu;

• Nội dung và mô tả nội dung;

• Định danh của tài liệu tham chiếu đến nội dung bên trong của tài liệu;

• Thông tin liên quan đến các tác giả và người thanh tra;

• Bảng chú giải thuật ngữ.

6.1.3.4. Tài liệu hướng dẫn kiểm tra có thể được tạo thành từ một hay nhiều tài liệu.

6.2. Các yêu cầu cho kế hoạch kiểm tra

6.2.1. Phương pháp tiếp cận

CHÚ THÍCH: Không khuyến nghị kỹ thuật hay phương pháp cụ thể nào.

6.2.1.1. Tất cả các tính chất đưa ra trong mô tả sản phẩm và trong mục 5.3 phải là chủ thể cho các trường hợp kiểm tra.

6.2.1.2. Tất cả các tính chất đưa ra trong mô tả sản phẩm và trong mục 5.3 phải là đối tượng của ít nhất một trường hợp kiểm tra.

CHÚ THÍCH: Kế hoạch kiểm tra có thể đề cập đến bất cứ tài liệu nào, cung cấp mối quan hệ giữa tài liệu này và tài liệu kiểm tra.

6.2.1.3. Tất cả các chức năng mô tả trong tài liệu hướng dẫn người sử dụng, cũng như tổ hợp các chức năng biểu diễn nhiệm vụ được thực hiện, phải là chủ thể đối với các trường hợp kiểm tra.

6.2.1.4. Mỗi chức năng mô tả trong tài liệu hướng dẫn người sử dụng phải là đối tượng của ít nhất một trường hợp kiểm tra.

6.2.1.5. Các trường hợp kiểm tra phải chứng minh sự phù hợp của phần mềm đối với các công bố trong tài liệu hướng dẫn người sử dụng.

6.2.1.6. Khi các yêu cầu được đưa ra trong mô tả sản phẩm, chúng phải là chủ thể đối với các trường hợp kiểm tra.

6.2.1.7. Mức phân tích chức năng được lựa chọn là cơ sở cho thiết kế trường hợp kiểm tra phải được chỉ ra.

CHÚ THÍCH: Ví dụ, chức năng có thể là

• Một đoạn của tài liệu hướng dẫn người sử dụng;

• Lệnh của trình tiện ích;

• Phím của giao diện người sử dụng;

• Lệnh ngôn ngữ.

6.2.1.8. Phương pháp thiết kế của trường hợp kiểm tra phải được chỉ dẫn.

CHÚ THÍCH: Ví dụ, các phương pháp thiết kế có khả năng là

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

• Danh mục kiểm tra;

• Phân tích luồng dữ liệu;

• Chèn lỗi;

• Kiểm tra dung lượng.

6.2.1.9. Tất cả các thủ tục cài đặt phải là chủ thể đối với các trường hợp kiểm tra.

6.2.1.10. Tất cả các giới hạn vận hành được chỉ dẫn trong mô tả sản phẩm và tài liệu hướng dẫn người sử dụng phải là chủ thể đối với các trường hợp kiểm tra.

6.2.1.11. Các vi phạm điều kiện cú pháp đầu vào đã xác định phải là chủ thể đối với các trường hợp kiểm tra.

6.2.1.12. Nếu ví dụ được chỉ dẫn trong tài liệu hướng dẫn người sử dụng, chúng phải được sử dụng như các trường hợp kiểm tra. Tuy nhiên toàn bộ kiểm tra không được chỉ giới hạn đối trong các ví dụ này.

6.2.1.13. Nếu có bất cứ yêu cầu nào trong mục 5.3 không thể áp dụng, nguyên nhân phải được công bố.

6.2.2. Tiêu chí đạt/không đạt

6.2.2.1. Tiêu chí sử dụng để quyết định kết quả kiểm tra chứng minh sự phù hợp của phần mềm đối với mô tả sản phẩm và tài liệu hướng dẫn người sử dụng phải được chỉ dẫn.

6.2.3. Môi trường kiểm tra

6.2.3.1 Kế hoạch kiểm tra phải xác định cấu hình phần cứng và phần mềm trên đó các kiểm tra được thực hiện.

6.2.3.2. Phần mềm phải được kiểm tra trên tất cả các ứng dụng được đưa ra trong mô tả sản phẩm.

CHÚ THÍCH: Chứng minh của cấu hình tương đương cũng có thể được sử dụng.

6.2.3.3. Kế hoạch kiểm tra phải xác định các công cụ cần thiết để thực hiện các trường hợp kiểm tra.

6.2.4. Lịch trình

6.2.4.1. Kế hoạch kiểm tra phải xác định lịch trình cho hoạt động kiểm tra và các mốc quan trọng của kiểm tra.

6.3. Các yêu cầu cho mô tả kiểm tra

6.3.1. Mô tả trường hợp kiểm tra

6.3.1.1 Mô tả mỗi trường hợp kiểm tra phải bao gồm

a) Đối tượng kiểm tra của nó;

b) Định danh duy nhất;

c) Dữ liệu đầu vào và các giới hạn kiểm tra cho kiểm tra;

d) Các bước chi tiết để tiến hành;

e) Xử lý mong đợi của hệ thống;

f) Đầu ra mong đợi từ trường hợp kiểm tra;

g) Tiêu chí chuyển đổi kết quả;

h) Tiêu chí sử dụng để quyết định kết quả tích cực hay tiêu cực của trường hợp kiểm tra.

6.3.1.2. Phải công bố môi trường và các điều kiện kiểm tra khác (cấu hình chi tiết và các công việc sơ bộ) đối với các thông tin bổ sung cần thiết khác khi so với các thông tin đã cung cấp trong kế hoạch kiểm tra.

6.3.2. Thủ tục kiểm tra

6.3.2.1. Thủ tục kiểm tra phải bao gồm

a) Chuẩn bị kiểm tra;

b) Các hành động cần thiết để bắt đầu và thực hiện kiểm tra;

c) Các hành động cần thiết để ghi lại kết quả kiểm tra;

d) Các điều kiện và hành động để dừng và cuối cùng là khởi tạo lại kiểm tra.

6.3.2.2. Thủ tục kiểm tra phải đủ chi tiết để có khả năng lặp lại và tái kiểm tra.

6.3.2.3. Để thực hiện điều chỉnh, phải có thủ tục kiểm tra lại chức năng được điều chỉnh và các chức năng liên quan khác.

CHÚ THÍCH: Ngôn ngữ giả hay ngôn ngữ lệnh có thể được sử dụng để mô tả các thủ tục kiểm tra.

6.4. Các yêu cầu cho kết quả kiểm tra

6.4.1. Báo cáo thực hiện

6.4.1.1. Báo cáo thực hiện phải bao gồm tổng kết toàn bộ kết quả của các trường hợp kiểm tra.

6.4.1.2. Báo cáo thực hiện phải chứng minh rằng tất cả các trường hợp kiểm tra đã được thực hiện tương ứng với kế hoạch kiểm tra.

6.4.1.3. Đối với mỗi trường hợp kiểm tra, báo cáo thực hiện phải bao gồm:

a) Định danh của trường hợp kiểm tra;

b) Ngày thực hiện kiểm tra;

c) Tên và chức năng của cá nhân thực thi kiểm tra;

d) Danh sách các khác thường;

e) Đối với mỗi khác thường, tham chiếu đến báo cáo khác thường tương ứng.

6.4.2. Báo cáo khác thường

6.4.2.1. Báo cáo khác thường phải bao gồm tổng kết toàn bộ các khác thường tìm thấy và nếu có, các điều chỉnh và xác minh bằng kiểm tra lại.

6.4.2.2. Mỗi khác thường phải có phần mô tả riêng, bao gồm:

a) Định danh của khác thường;

b) Định danh của phần mềm;

c) Mô tả khác thường;

d) Điểm xuất hiện khác thường trong trường hợp kiểm tra;

e) Bản chất của khác thường.

CHÚ THÍCH: Bản chất có thể là “bị cô lập”, “phần lớn” hay “số ít”.

6.4.2.3. Phần chỉnh sửa của báo cáo khác thường phải chứng minh rằng tất cả các khác thường tìm thấy đã được chỉnh sửa.

6.4.2.4. Đối với mỗi điều chỉnh trong phần chỉnh sửa của báo cáo khác thường phải bao gồm:

a) Định danh của điều chỉnh;

b) Ngày điều chỉnh;

c) Tên của người điều chỉnh;

d) Định danh của thay đổi tương ứng với điều chỉnh;

e) Tác động có khả năng của điều chỉnh;

f) Khuyến nghị có thể có của người điều chỉnh.

6.4.2.5. Phần xác minh bằng kiểm tra lại của báo cáo khác thường phải chứng minh rằng tất cả các chức năng được điều chỉnh đã đạt được các tính năng như xác định trong tài liệu hướng dẫn người sử dụng.

6.4.2.6. Phần xác minh bằng kiểm tra lại của báo cáo khác thường phải bao gồm cho mỗi xác minh:

a) Định danh của xác minh;

b) Ngày xác minh;

c) Tên của người xác minh;

d) Trường hợp kiểm tra sử dụng cho xác minh;

e) Các kết quả của xác minh.

6.4.3. Đánh giá kết quả kiểm tra

6.4.3.1. Đánh giá của báo cáo thực hiện và báo cáo khác thường phải chứng minh rằng đã đạt được tất cả các xử lý mong muốn trong giới hạn của tiêu chí được sử dụng để quyết định nếu kết quả kiểm tra thể hiện sự phù hợp của phần mềm.

7. Hướng dẫn đánh giá sự phù hợp

7.1. Các quy tắc chung

Mô tả sản phẩm, tài liệu hướng dẫn người sử dụng và phần mềm được chuyển giao, như các phần của sản phẩm phần mềm COTS, phải được đánh giá sự phù hợp đối với các các yêu cầu trong điều 5.

CHÚ THÍCH: Thuật ngữ “đánh giá sự phù hợp” không hàm ý cho bất cứ kỹ thuật hay công cụ nào: kiểm tra, thẩm định, xác minh, soát xét, phân tích, …

Các hướng dẫn này chủ yếu nhằm mục đích cho đánh giá của bên thứ ba. Bên thứ ba có thể là phòng thử nghiệm kiểm tra làm việc theo quy định với một hệ thống chứng chỉ nào đó hay phòng thử nghiệm kiểm tra độc lập với nhà cung cấp sản phẩm phần mềm COTS.

7.2. Các yêu cầu sơ bộ đánh giá sự phù hợp

7.2.1. Sự hiện diện của các mục sản phẩm phần mềm COTS

Để đánh giá sản phẩm COTS, tất cả các mục phải được cung cấp (xem mục 5.2.1.11) cũng như các tài liệu yêu cầu xác định trong mô tả sản phẩm (xem mục 5.1.3.5).

7.2.2. Sự hiện diện của các thành phần hệ thống

Phải có tất cả các thành phần của tất cả các hệ thống máy tính như mô tả trong mô tả sản phẩm và sẵn sàng cho đánh giá sự phù hợp.

7.3. Hoạt động đánh giá sự phù hợp

7.3.1. Đánh giá sự phù hợp của mô tả sản phẩm

Đánh giá sự phù hợp được thực hiện để xác định sự phù hợp của mô tả sản phẩm đối với các yêu cầu trong mục 5.1.

CHÚ THÍCH: Không khuyến nghị bất cứ kỹ thuật hay công cụ cụ thể nào.

7.3.2. Đánh giá sự phù hợp của tài liệu hướng dẫn người sử dụng

Đánh giá sự phù hợp được thi hành để xác định sự phù hợp của tài liệu hướng dẫn người sử dụng đối với các yêu cầu trong mục 5.2.

CHÚ THÍCH: Không khuyến nghị bất cứ kỹ thuật hay công cụ cụ thể nào.

7.3.3. Đánh giá sự phù hợp của phần mềm

Đánh giá sự phù hợp được thực hiện để xác định sự phù hợp của phần mềm đối với các yêu cầu trong mục 5.3 bằng cách tạo lập tài liệu hướng dẫn kiểm tra phù hợp với các yêu cầu trong điều 6, nhưng không bao gồm phần liên quan đến điều chỉnh khác thường và xác minh kiểm tra lại (mục 6.4.2.3 và 6.4.2.6).

CHÚ THÍCH: Tài liệu hướng dẫn kiểm tra bao gồm phần mô tả phát hiện các khác thường, tuy nhiên việc điều chỉnh các khác thường tìm được vượt ra khỏi phạm vi đánh giá sự phù hợp của bên thứ ba.

7.4. Quá trình đánh giá sự phù hợp của bên thứ ba

Nhà cung cấp cung cấp sản phẩm phần mềm COTS cho bên thứ ba. Nhà cung cấp cũng có thể cung cấp tài liệu hướng dẫn kiểm tra.

Nếu nhà cung cấp chỉ cung cấp sản phẩm phần mềm COTS, không có tài liệu hướng dẫn kiểm tra thì bên thứ ba phải:

a) Thực hiện đánh giá sự phù hợp của mô tả sản phẩm, tài liệu hướng dẫn người sử dụng và phần mềm theo mục 7.3;

b) Ghi lại kết quả vào báo cáo đánh giá sự phù hợp, theo mục 7.5.

Nếu nhà cung cấp cung cấp sản phẩm phần mềm COTS và tài liệu hướng dẫn kiểm tra thì bên thứ ba phải:

a) Thực hiện đánh giá sự phù hợp của mô tả sản phẩm và tài liệu hướng dẫn người sử dụng theo mục 7.3.1 và 7.3.2;

b) Thực hiện đánh giá sự phù hợp để xác định sự phù hợp của tài liệu hướng dẫn kiểm tra đối với các yêu cầu trong điều 6;

c) Ghi lại kết quả vào báo cáo đánh giá sự phù hợp, theo mục 7.5.

CHÚ THÍCH: Sự phù hợp của tài liệu hướng dẫn người sử dụng đối với các yêu cầu trong điều 6 thiết lập sự phù hợp của phần mềm đối với các yêu cầu trong mục 5.3.

7.5. Báo cáo đánh giá sự phù hợp

Bên thứ ba phải chuẩn bị báo cáo đánh giá sự phù hợp.

Báo cáo đánh giá sự phù hợp phải thiết lập sự phù hợp của sản phẩm phần mềm đối với các yêu cầu của điều 5.

Báo cáo đánh giá sự phù hợp phải bao gồm các mục sau:

a) Xác định sản phẩm phần mềm COTS;

b) Ngày hoàn thành đánh giá và ngày hoàn thành kiểm tra (nếu có);

c) Các hệ thống máy tính được sử dụng cho quá trình kiểm tra (phần cứng, phần mềm và cấu hình của chúng) (nếu có);

d) Tài liệu được sử dụng, cùng với định danh của chúng;

e) Tổng kết các hoạt động đánh giá sự phù hợp và các hoạt động kiểm tra (nếu có);

f) Tổng kết các kết quả đánh giá sự phù hợp và các kết quả kiểm tra (nếu có);

g) Kết quả cụ thể của đánh giá sự phù hợp và quá trình kiểm tra (nếu có);

h) Danh sách các điểm không tuân thủ các yêu cầu (nếu có),

Phần kết quả của báo cáo đánh giá sự phù hợp (mục f đến h trong đoạn trước) phải bao gồm các kết quả đánh giá sự phù hợp của mô tả sản phẩm và tài liệu hướng dẫn người sử dụng. Theo các thành phần cung cấp, nó cũng phải bao gồm một trong hai thành phần sau:

a) Kết quả kiểm tra của phần mềm đối với các yêu cầu trong mục 5.3, tức là phần mô tả của báo cáo khác thường (mục 6.4.2.2), trong trường hợp nhà cung cấp chỉ cung cấp sản phẩm phần mềm COTS, không có tài liệu hướng dẫn kiểm tra;

b) Kết quả đánh giá sự phù hợp của tài liệu hướng dẫn kiểm tra đối với các yêu cầu trong điều 6, trong trường hợp nhà cung cấp cung cấp sản phẩm phần mềm COTS và tài liệu hướng dẫn kiểm tra.

CHÚ THÍCH: Báo cáo đánh giá sự phù hợp chỉ bao gồm phần mô tả báo cáo khác thường vì nhiệm vụ của bên thứ ba không phải là sửa đổi sản phẩm.

Đối với báo cáo đánh giá sự phù hợp dưới dạng in, định danh của báo cáo đánh giá sự phù hợp (phòng thử nghiệm kiểm tra, định danh sản phẩm phần mềm COTS, ngày báo cáo đánh giá sự phù hợp) và tổng số trang của nó phải hiện diện trên từng trang của báo cáo đánh giá sự phù hợp.

Báo cáo đánh giá sự phù hợp phải bao gồm:

a) Công bố tác động của đánh giá này và các kết quả kiểm tra chỉ liên quan đến các mục đã được đánh giá và kiểm tra (nếu có);

b) Công bố là báo cáo đánh giá sự phù hợp không được sao chép lại khi không có chứng thực của phòng thử nghiệm kiểm tra, trừ phi được để nguyên toàn bộ.

7.6. Theo dõi đánh giá sự phù hợp

Khi sản phẩm phần mềm COTS, đã được đánh giá sự phù hợp, được đánh giá lại, xem xét đánh giá sự phù hợp trước đó, thì:

a) Tất cả các phần thay đổi trong tài liệu và phần mềm cần được đánh giá như nó là sản phẩm phần mềm COTS mới;

b) Tất cả các phần không thay đổi phải dự tính được sự ảnh hưởng bởi các phần thay đổi hay các thay đổi trong hệ thống yêu cầu phải được đánh giá như nó là phần mềm mới;

c) Tất cả các phần còn lại ít nhất phải được đánh giá lấy mẫu.

Phụ lục A

(Tham khảo)

Định nghĩa từ các tiêu chuẩn khác

A.1

Bảo trì (maitenance)

Quá trình thay đổi hệ thống phần mềm hay thành phần sau khi sửa lỗi, nâng cao hiệu năng hoặc các thuộc tính khác, hay tương thích với môi trường bị thay đổi.

CHÚ THÍCH: Xem IEEE Std 610.12-1990.

A.2

Bên thâu nhận (acqurier)

Tổ chức nhận được/mua hệ thống, sản phẩm phần mềm hoặc dịch vụ phần mềm từ nhà cung cấp.

CHÚ THÍCH 1: Bên thâu nhận có thể là người mua, khách hàng, chủ sở hữu hay người sử dụng.

CHÚ THÍCH 2: Xem ISO/IEC 12207:1995.

A.3

Bên thứ ba (third-party)

Cá nhân hay cơ quan được công nhận như bên độc lập với các bên tham gia, liên quan đến vấn đề xem xét.

CHÚ THÍCH: Xem ISO/IEC Guide 2:1996.

A.4

Đánh giá tính phù hợp (conformity evaluation)

Kiểm tra một cách hệ thống mức độ mà sản phẩm, quá trình hay dịch vụ hoàn thành các yêu cầu xác định.

CHÚ THÍCH: Xem ISO/IEC Guide 2:1996.

A.5

Khác thường (anomaly)

Bất cứ điều kiện nào sai lệch khỏi giá trị mong đợi (đã dựa trên các đặc tính yêu cầu, tài liệu thiết kế, tiêu chuẩn … hay từ nhận thức và kinh nghiệm của người nào đó).

CHÚ THÍCH: Xem IEEE Std 1044-1993.

A.6

Kiểm tra (test)

Hoạt động mà trong đó hệ thống hay thành phần được vận hành dưới điều kiện xác định; Các kết quả được quan sát hay ghi lại; Đánh giá được thiết lập cho một số khía cạnh của hệ thống hay thành phần.

CHÚ THÍCH: Xem IEEE Std 610.12:1990.

A.7

Lỗi (fault)

Bước, quá trình hay xác định dữ liệu không đúng trong chương trình máy tính.

CHÚ THÍCH: Xem IEEE Std 610.12-1990.

A.8

Người sử dụng cuối (end user)

Cá nhân cuối cùng nhận lợi ích từ kết quả của hệ thống.

CHÚ THÍCH 1: Người sử dụng cuối có thể là người vận hành thường xuyên sản phẩm phần mềm hay người sử dụng bình thường như thành viên cộng đồng.

CHÚ THÍCH 2: Xem ISO/IEC 25000:2005.

A.9

Nhà cung cấp (supplier)

Tổ chức tham gia vào hợp đồng với người mua sản phẩm để cung cấp hệ thống, sản phẩm phần mềm hoặc dịch vụ phần mềm theo các điều khoản của hợp đồng.

CHÚ THÍCH 1: Thuật ngữ “nhà cung cấp” đồng nghĩa với nhà thầu, nhà sản xuất, người bán hàng hay hãng cung cấp.

CHÚ THÍCH 2: Bên thâu nhận có thể chỉ định một phần tổ chức của họ như nhà cung cấp.

CHÚ THÍCH 3: Xem ISO/IEC 12207:1995.

A.10

Người sử dụng (user)

Cá nhân hay tổ chức sử dụng hệ thống để thực hiện chức năng cụ thể. Người sử dụng có thể bao gồm người vận hành, người nhận kết quả phần mềm, người phát triển hay bảo trì phần mềm.

CHÚ THÍCH 1: Xem ISO/IEC 15939:2002.

Cá nhân hay tổ chức kinh doanh sử dụng sản phẩm phần để thực hiện chức năng cụ thể.

CHÚ THÍCH 2: Xem ISO/IEC 18019:2004.

A.11

Phần mềm (software)

Tất cả hoặc một phần của các chương trình, thủ tục, quy tắc và tài liệu đi kèm của một hệ thống xử lý thông tin.

CHÚ THÍCH 1: Phần mềm là sáng tạo trí tuệ không phụ thuộc vào phương tiện nó được ghi lại.

CHÚ THÍCH 2: Xem ISO/IEC 2382.1:1993.

CHÚ THÍCH 3: Trong tiêu chuẩn này, tài liệu hướng dẫn không được xem như một phần của phần mềm mà như là một hạng mục riêng.

A.12

Quá trình kiểm tra (testing)

Quá trình vận hành hệ thống hay các thành phần dưới điều kiện xác định, quan sát và ghi lại kết quả, đồng thời đánh giá một số khía cạnh của hệ thống hay thành phần.

CHÚ THÍCH: Xem IEEE Std 610.12:1990.

A.13

Tiêu chí đạt/không đạt (pass/fail criteria)

Các quy tắc quyết định để xác định hạng mục phần mềm hay đặc tính phần mềm vượt qua hay không vượt qua bài kiểm tra.

CHÚ THÍCH: Xem IEEE Std 829.12-1998.

A.14

Trường hợp kiểm tra (test case)

Một bộ các đầu vào, điều kiện kiểm tra và các kết quả mong muốn được phát triển cho đối tượng đặc thù, như thực hành đường dẫn chương trình đặc thù hay xác minh sự phù hợp với yêu cầu cụ thể.

CHÚ THÍCH: Xem IEEE Std 610.12:1990.

A.15

Thủ tục kiểm tra (test procedure)

Hướng dẫn chi tiết cho việc thiết lập, thực hiện và đánh giá kết quả cho trường hợp kiểm tra cho trước.

CHÚ THÍCH: Xem IEEE Std 610.12:1990.

A.16

Tài liệu hướng dẫn người sử dụng (user documentation)

Thông tin được cung cấp cùng với phần mềm để trợ giúp người sử dụng trong quá trình sử dụng phần mềm.

CHÚ THÍCH: Xem ISO/IEC 18019:2004.

Phụ lục B

(Tham khảo)

Hướng dẫn áp dụng sản phẩm phần mềm COTS trong các ứng dụng nghiệp vụ quan trọng hay yêu cầu phải an toàn

Tổng quan: Các sản phẩm phần mềm COTS điển hình được sử dụng trong các ứng dụng rủi ro thấp và khá nhiều trong số chúng được phát triển mà không quan tâm rủi ro đối với an toàn, nghiệp vụ, pháp luật, hay mục tiêu của tổ chức. Trong các ứng dụng không quan trọng, các đặc tính sản phẩm phần mềm COTS, nếu không hoạt động hay hoạt động sai, trong trường hợp xấu nhất sẽ dẫn đến sự không hài lòng của người sử dụng. Trong trường hợp xấu nhất, khi đó người phát triển phải phục hồi thông qua sửa chữa lỗi, thêm/xóa các đặc tính để thỏa mãn phản hồi của người sử dụng. Trong nhiều trường hợp như vậy thị trường không yêu cầu kiểm tra nghiêm ngặt và có thể chấp nhận sản phẩm phần mềm COTS với một mức nhất định các khiếm khuyết.

Tuy nhiên, trong trường hợp sử dụng sản phẩm phần mềm COTS được minh chứng có ảnh hưởng đến rủi ro an toàn hay nghiệp vụ, hậu quả của việc sản phẩm phần mềm COTS được áp dụng hay kiểm tra không đầy đủ có thể nghiêm trọng. Các ứng dụng sản phẩm phần mềm COTS trong môi trường này bao gồm hàng không, thiết bị y tế, thuốc và dược phẩm, vũ trụ và thăm dò, viễn thông, xây dựng, kiểm toán, thang máy, đường sắt, hệ thống quân sự … Các chức năng như quản lý lưu lượng hàng không và đường sắt, sản xuất đồng vị phóng xạ cho người bệnh ung thư, tính chính xác của báo cáo thuế và kiểm toán, … là các ví dụ của hệ thống mà thậm chí một lỗi đơn có thể dẫn đến hậu quả tai hại. Các yêu cầu chức năng cho các hệ thống này được cung cấp bằng các kiến trúc phần cứng và phần mềm khác nhau, được thiết kế thích hợp cho phạm vi rộng các đối tượng thiết kế. Một số đối tượng thiết kế có thể được thực hiện trên phần cứng, như mạch tích hợp đặc tính ứng dụng và thiết bị logic có khả năng lập trình và một số trên sản phẩm phần mềm COTS.

Trong quá trình đánh giá ứng dụng của sản phẩm phần mềm COTS trong các ứng dụng yêu cầu phải an toàn hay nghiệp vụ quan trọng, người sử dụng sản phẩm phần mềm COTS phải xem xét cả các thuộc tính sản phẩm, các thuộc tính xử lý và các đặc tính của ứng dụng.

Các đặc tính thiết kế phần mềm, có thể được hỗ trợ bằng sản phẩm phần mềm COTS, bao gồm:

B.1. Phát hiện và hóa giải lỗi bao gồm dự phòng phần mềm

Phát hiện lỗi là quá trình kiểm tra hệ thống đối với trạng thái lỗi. Các kỹ thuật hóa giải lỗi có thể xác định “trạng thái an toàn” mà hệ thống hoạt động tốt. Thông qua sử dụng chương trình chẩn đoán, phần mềm kiểm tra bản thân nó và phần cứng đối với các kết quả không chính xác. Chương trình kiểm tra có thể chạy định kì hay liên tục như quá trình nền tảng. Chương trình chẩn đoán có thể bao gồm việc lặp lại một phép tính hai hay nhiều lần, kiểm tra chẵn lẻ, kiểm tra dự phòng theo chu kì. Đối với các chức năng quan trọng được thiết kế với dự phòng, biểu quyết giữa các thành phần dự phòng được sử dụng để quyết định tính chính xác của các thành phần này. [IEC 61508-7]

B.2. Hồi phục lỗi bằng cách thực hiện lại

Hồi phục lỗi thông qua việc thực hiện lại thường được sử dụng cho các hệ thống liên quan truyền thông và không phải là kỹ thuật phổ biến cho các hệ thống thời gian thực nhanh. Hệ thống tự giám sát lỗi của bản thân nó và tự thiết lập lại cho nó trạng thái an toàn trước đó và tiếp tục hoạt động. Nếu sử dụng trong hệ thống liên quan thời gian thực, cần thực hiện đảm bảo rằng hồi phục có khả năng hoàn thành trước khi lỗi có thể biểu hiện ra ngoài tại mức hệ thống. [IEC 61508-7]

B.3. Lập trình n-Version

Trong lập trình n-version, các nhóm độc lập tạo ra số cụ thể n sản phẩm phần mềm gọi là phiên bản. Thường là ba phiên bản, tuy nhiên, đối với các hệ thống có trạng thái an toàn, hai phiên bản có thể sử dụng với sai lệch đối với trạng thái an toàn, Tất cả n phiên bản của sản phẩm phần mềm là một phần của hệ thống phần mềm. Các ngôn ngữ lập trình và thuật toán khác nhau thường được sử dụng để giảm việc xuất hiện cùng một kiểu lỗi chung. Tuy nhiên, các lỗi kiểu chung có thể có khả năng xảy ra do đặc tính mức cao nhất không đầy đủ. Xu hướng sử dụng các biểu quyết khác nhau có thể được sử dụng giữa các phiên bản để chọn đầu ra với phả hệ cao nhất.

B.4. Hồi phục khối lập trình

Hồi phục khối lập trình là kỹ thuật trong đó các môđun được viết độc lập tự kiểm tra tính chính xác cho bản thân chúng. Kỹ thuật áp dụng cho sản phẩm phần mềm COTS có thể tách biệt thành phần sản phẩm phần mềm COTS trong môđun và sớm thoát khỏi đánh giá kết quả cho bất kì lỗi nào. Nếu môđun phát hiện lỗi, môđun khác được khởi tạo, nó loại bỏ bất cứ tác động nào từ môđun được đóng gói của sản phẩm phần mềm COTS và tiếp tục hoạt động không có lỗi.

B.5. Tuân theo mô hình

Tuân theo mô hình là kỹ thuật mà mô hình sơ khai của thành phần sản phẩm phần mềm hiện diện trong hệ thống và được sử dụng tự xác minh hoạt động chính xác của thành phần sản phẩm hệ thống phần mềm COTS cho chính nó. Mô hình có thể được biểu diễn bằng một số kỹ thuật, từ biểu diễn mô hình xem dạng bảng đơn giản đến mô hình toàn diện, phụ thuộc vào độ phức tạp và các yêu cầu của chức năng sản phẩm phần mềm được mô hình hóa.

B.6. Trình bao bọc

Trình bao bọc là các lớp phần mềm được sử dụng để bảo vệ, tách biệt, hay giao tiếp tới các thành phần khác. Trình bao bọc là ứng viên khả thi để bảo vệ hệ thống từ các thành phần sản phẩm phần mềm COTS, mà không cần thay đổi thành phần sản phẩn phần mềm COTS. Bao bọc có thể được sử dụng để cải tiến tính chức năng thành phần sản phẩm phần mềm, do đó cho phép nó đáp ứng tất cả các yêu cầu hệ thống mục tiêu. Thêm nữa, bao bọc có thể sử dụng để che đậy tính năng sản phẩm phần mềm COTS không được sử dụng trong triển khai hệ thống mới.

B.7. Các kỹ thuật được xem xét để thiết lập tính toàn vẹn sản phẩm phần mềm COTS

Bảng A.1 cung cấp danh sách các xác minh có thể được sử dụng để đánh giá tính toàn vẹn của sản phẩm phần mềm COTS trong ứng dụng rủi ro cao.

Bảng A.1 – Hướng dẫn cho sản phẩm phần mềm COTS trong các ứng dụng rủi ro cao

Đặc tính	Mục đích	Hành động có khả năng
Bảo vệ bộ nhớ	Kiểm tra các ứng dụng có được ngăn chặn truy cập không gian địa chỉ bất hợp pháp không.	Chạy kiểm tra, thử thực hiện, đọc và viết các hoạt động ngoài dải địa chỉ được ấn định của chúng.
Bảo vệ tràn ngăn xếp	Kiểm tra sản phẩm phần mềm COTS có cung cấp phương tiện bảo vệ chống tràn ngăn xếp không.	Kiểm tra bằng cách gọi một vài chức năng làm tràn ngăn xếp. Xác minh rằng nhân chương trình sẽ tạm ngừng nhiệm vụ, hoặc nếu nhiệm vụ làm dừng toàn bộ hệ thống.
Hạn mức phân bổ bộ nhớ động	Kiểm tra sản phẩm phần mềm COTS có cơ chế bảo vệ tài nguyên để ngăn chặn nhiệm vụ độc hại tiêu tốn tài nguyên không giới hạn không.	Tạo ra nhiệm vụ yêu cầu bộ nhớ trong vòng lặp vô hạn trong khi nhiệm vụ khác yêu cầu rất ít bộ nhớ. Xác minh rằng nhiệm vụ quan trọng không bị dừng bởi sản phẩm phần mềm COTS.
Khả năng chịu lỗi	Xác minh rằng phần lõi có thể hồi phục và ghi lại sự kiện diễn ra sự cố.	Kiểm tra sản phẩm phần mềm COTS phải được thiết kế để chỉ ra các đặc tính cơ bản của sản phẩm phần mềm COTS có thể cho phép người thiết kế hệ thống xây dựng khả năng chịu lỗi.
Ngắt đồng thời và ngắt lồng nhau	Xác định hệ thống cần phản ứng với hai ngắt xảy ra đồng thời mất bao lâu.	Đo lường trễ dịch vụ cả hai ngắt ưu tiên cao và thấp. Bài kiểm tra phải đo thời gian hệ thống phản ứng hai ngắt xảy ra đồng thời. Xác minh xử lý ngắt được phân mức.
Đưa vào tùy chọn hay mã ngừng hoạt động	Xác minh việc thực hiện vô ý tùy chọn hay mã ngừng hoạt động.	Kiểm tra bất cứ điều kiện nào có thể gây ra mã “rỗi” bị kích hoạt và kiểm tra điều kiện như vậy.
Sử dụng trình bao bọc	Các trình bao bọc có được sử dụng để bảo vệ thành phần sản phẩm phần mềm COTS bên trong hệ thống hay che đậy tính năng không mong muốn?	Phát hiện các thành phần sản phẩm phần mềm COTS được sử dụng trong các ngữ cảnh khác nhau của thiết kế gốc.
Đánh giá sản phẩm phần mềm COTS	Xác định tính thích hợp của các đặc tính sản phẩm phần mềm COTS và tác động của chúng lên thiết kế hệ thống.	Đánh giá và/hoặc thử mẫu nhanh tại chỗ.
Kế hoạch mua sản phẩm phần mềm COTS	Xác định giấy phép, giao kèo, hợp đồng bảo trì, truy cập vào báo cáo vấn đề và nhu cầu tiềm năng truy cập vào mã nguồn.	Quản lý và kế hoạch được ký của nhà cung cấp sản phẩm phần mềm COTS.
Kế hoạch quản lý cấu hình/đảm bảo chất lượng phần mềm (CM/SQA) cho sản phẩm phần mềm COTS	Xác định phả hệ của quản lý cấu hình CM và đảm bảo chất lượng phần mềm SQA tại chỗ và tại địa điểm của nhà cung cấp sản phẩm phần mềm COTS.	Các kế hoạch quản lý cấu hình/đảm bảo chất lượng phần mềm CM/SQA được ký bởi quản lý và nhà cung cấp sản phẩm phần mềm COTS. Soát xét các báo cáo vấn đề, đảm bảo kiểm soát phiên bản xác thực của mã nguồn và đối tượng.
Kế hoạch kiểm tra cho sản phẩm phần mềm COTS	Kiểm tra trong hệ thống và ngoài hệ thống với sản phẩm phần mềm COTS.	Xác minh các yêu cầu cho từng hệ thống.
Kế hoạch tích hợp sản phẩm phần mềm COTS	Kế hoạch cho sản phẩm phần mềm COTS được cấu hình trên hệ thống như thế nào.	Phần mềm tích hợp đặc biệt. Nền tảng phần cứng đặc biệt để vận hành sản phẩm phần mềm COTS đúng đắn, (định thời gian, phân vùng, tính năng không mong muốn, tác động của mã chết hay mã dừng hoạt động.
Hỗ trợ sản phẩm	Xác định tính sẵn sàng của hỗ trợ sản phẩm.	Đánh giá tính đầy đủ của hệ thống hỗ trợ, (bảng trợ giúp, hướng dẫn sử dụng, mô tả sản phẩm, bàn hỗ trợ).
Đã được cấp chứng nhận/văn bằng	Lịch sử dịch vụ của sản phẩm phần mềm COTS bao gồm bất kì thẩm quyền quy định kiểm soát sản phẩm nào.	Xác định lịch sử dịch vụ của sản phẩm phần mềm COTS bao gồm bất cứ ứng dụng quan trọng cao nào và điều tra hiệu năng trên môi trường này.
Chất lượng sử dụng	Mục đích là cung cấp bằng chứng khách quan (trên cơ sở dữ liệu các kiểm tra và thử nghiệm, mô hình toán học và mô phỏng) mà sản phẩm phần mềm COTS sử dụng phù hợp với các yêu cầu đã cho của khách hàng và người sử dụng.	Xác minh và xác nhận để chứng minh (thông qua mô hình toán học và mô phỏng) sản phẩm phần mềm COTS thích hợp cho mục đích và thỏa mãn các yêu cầu khách hàng và người sử dụng.

 

Phụ lục C

(Tham khảo)

Sử dụng tiêu chuẩn

Tiêu chuẩn này có thể được sử dụng như sau:

• Các yêu cầu mức cao cho đặc tính sản phẩm phần mềm COTS: sử dụng điều 5, “Các yêu cầu chất lượng” như đầu vào để xây dựng các đặc tính cho sản phẩm phần mềm COTS;

• Các yêu cầu kiểm tra phần mềm như một phần của sản phẩm phần mềm COTS: Xây dựng tài liệu hướng dẫn kiểm tra dựa trên các yêu cầu xác định trong điều 6, “Các yêu cầu cho tài liệu hướng dẫn kiểm tra”;

• Chứng minh chất lượng của sản phẩm phần mềm COTS, tức là chứng minh sự phù hợp với tiêu chuẩn này: tiến hành đánh giá sự phù hợp theo điều 7, chứng nhận hay công bố của nhà cung cấp khi đó dựa trên báo cáo đánh giá sự phù hợp.

CHÚ THÍCH: Ba khả năng trên là lũy tiến, tức là một trường hợp chỉ được thực hiện nếu các trường hợp trước đó đã được hoàn thành.

Thêm nữa, Phụ lục B có thể được sử dụng cho phần mềm nghiệp vụ quan trọng hay yêu cầu phải an toàn.

Thư mục tài liệu tham khảo

[1] TCVN 8702 Kỹ thuật phần mềm – Chất lượng sản phẩm – Các phép đánh giá ngoài (TCVN 8702 Software engineering – Product quality – External metrics).

[2] TCVN 8703 Kỹ thuật phần mềm – Chất lượng sản phẩm – Các phép đánh giá trong (TCVN 8703 Software engineering – Product quality – Internal metrics).

[3] TCVN 8704 Kỹ thuật phần mềm – Chất lượng sản phẩm – Các phép đánh giá chất lượng sử dụng (TCVN 8704 Software engineering – Product quality- Quality in use metrics).

[4] TCVN 8705 Công nghệ thông tin – Chất lượng sản phẩm phần mềm – Phần 1: Tổng quan. (TCVN 8705 Software engineering – Software product quality- General overview).

[5] TCVN 8706 Công nghệ thông tin – Chất lượng sản phẩm phần mềm – Phần 2: Quy trình cho bên đánh giá. (TCVN 8706 Software engineering – Software product quality – Process for evaluator).

[6] TCVN 8707 Công nghệ thông tin – Chất lượng sản phẩm phần mềm – Phần 3: Quy trình cho người phát triển. (TCVN 8707 Software engineering – Software product quality – Process for developer).

[7] TCVN 8708 Công nghệ thông tin – Chất lượng sản phẩm phần mềm – Phần 4: Quy trình cho người mua sản phẩm. (TCVN 8708 Software engineering – Software product quality – Process for acquirer).

[8] ISO/IEC Guide 2:1996 – Standardization and related activities – General vocabulary. (ISO/IEC Hướng dẫn 2:1996 – Tiêu chuẩn hóa và các hoạt động liên quan – Từ vựng chung).

[9] ISO/IEC 17050-2:2004 – Conformity assessment – Suplier’s declaration of conformity – Part 2: Supporitng documentation. (ISO/IEC 17050-2:2004 – Đánh giá sự phù hợp – Công bố sự phù hợp của nhà sản xuất – Phần 2: Tài liệu hỗ trợ).

[10] ISO/IEC Guide 23:1982 – Methods of indicating conformity with standards for third-party certification systems. (ISO/IEC Hướng dẫn 23:1982 – Các phương pháp chỉ dẫn tuân thủ tiêu chuẩn cho hệ thống chứng nhận bên thứ ba).

[11] ISO/IEC Guide 28:2004 – Conformity assessment – Guidance on a third-party certitication systems for products. (ISO/IEC Hướng dẫn 28:2004 – Đánh giá sự phù hợp – Hướng dẫn hệ thống chứng nhận bên thứ ba cho các sản phẩm).

[12] ISO/IEC 12207:2008 – Systems and software engineering – Software life cycle process. (ISO/IEC 12207:2008 – Kỹ thuật hệ thống và phần mềm – Quá trình vòng đời phần mềm).

[13] ISO/IEC 15939:2002 – Systems and software engineering – Measurement process. (ISO/IEC 15939:2002 – Kỹ thuật hệ thống và phần mềm – Quá trình đo).

[14] ISO/IEC 9127 – Software engineering – User documentation and cover information for consumer software package. (ISO/IEC 9127 – Kỹ thuật phần mềm – Tài liệu người sử dụng và thông tin bao hàm cho gói phần mềm tiêu dùng).

[15] ISO/IEC 15026:1998 – Information technology – System and software integrity levels. (ISO/IEC 15026:1998 – Công nghệ thông tin – Các mức toàn vẹn của hệ thống và phần mềm).

[16] ISO/IEC 18019:2004 – System and software engineering – Guidelines for the design and preparation of user documentation for application software. (ISO/IEC 18019:2004 – Kỹ thuật hệ thống và phần mềm – Hướng dẫn thiết kế và chuẩn bị tài liệu người sử dụng cho phần mềm ứng dụng).

[17] ISO/IEC 17025:2007 – General requirements for the completence of testing and calibration laboratories. (ISO/IEC 17025:1999 – Các yêu cầu chung cho hoàn thiện phòng thử nghiệm và hiệu chuẩn).

[18] ISO/IEC 9241-1:1997 – Ergonomic requirements for office work with visual display terminals (VDTs) – Part 1: General introduction. (ISO/IEC 9241-1:1997 – Các yêu cầu tiện dụng cho công việc văn phòng với màn hình hiển thị – Phần 1: Giới thiệu chung).

[19] ISO/IEC 9241-2:1992 – Ergonomic requirements for office work with visual display terminals (VDTs) – Part 2: Guidance on the task requirements. (ISO/IEC 9241-2:1992 – Các yêu cầu tiện dụng cho công việc văn phòng với màn hình hiển thị – Phần 2: Hướng dẫn về các yêu cầu nhiệm vụ).

[20] ISO/IEC 9241-10:1996 – Ergonomic requirements for office work with visual display terminals (VDTs) – Part 10: Dialogue principles. (ISO/IEC 9241-10:1996 – Các yêu cầu tiện dụng cho công việc văn phòng với màn hình hiển thị – Phần 10: Các nguyên tắc đối thoại).

[21] ISO/IEC 9241-11:1998 – Ergonomic requirements for office work with visual display terminals (VDTs) – Part 11: Guidance on usability. (ISO/IEC 9241-11:1998 – Các yêu cầu tiện dụng cho công việc văn phòng với màn hình hiển thị – Phần 11: Hướng dẫn về tính khả dụng).

[22] ISO/IEC 9241-12:1998 – Ergonomic requirements for office work with visual display terminals (VDTs) – Par 12: Presentation of information. (ISO/IEC 9241-12:1998 – Các yêu cầu tiện dụng cho công việc văn phòng với màn hình hiển thị- Phần 12: Biểu diễn thông tin).

[23] ISO/IEC 9241-13:1998 – Ergonomic requirements for office work with visual display terminals (VDTs) – Part 13: User guidance. (ISO/IEC 9241-13:1998 – Các yêu cầu tiện dụng cho công việc văn phòng với màn hình hiển thị – Phần 13: Hướng dẫn người sử dụng).

[24] ISO/IEC 9241-14:1997 – Ergonomic requirements for office work with visual display terminals (VDTs) – Part 14: Menu dialogues. (ISO/IEC 9241-14:1997 – Các yêu cầu tiện dụng cho công việc văn phòng với màn hình hiển thị – Phần 14: Đối thoại bảng menu).

[25] ISO/IEC 9241-15:1997 – Ergonomic requirements for office work with visual display terminals (VDTs) – Part 15: Command dialogues. (ISO/IEC 9241-15:1997 – Các yêu cầu tiện dụng cho công việc văn phòng với màn hình hiển thị – Phần 15: Đối thoại câu lệnh).

[26] ISO/IEC 9241-16:1999 – Ergonomic requirements for office work with visual display terminals (VDTs) – Part 16: Direct manipulation dialogues. (ISO/IEC 9241-16:1999 – Các yêu cầu tiện dụng cho công việc văn phòng với màn hình hiển thị – Phần 16: Đối thoại thao tác trực tiếp).

[27] ISO/IEC 9241-17:1999 – Ergonomic requirements for office work with visual display terminals (VDTs) – Part 17: Form filling dialogues. (ISO/IEC 9241-17:1999 – Các yêu cầu tiện dụng cho công việc văn phòng với màn hình hiển thị – Phần 17: Đối thoại điền vào mẫu).

[28] IEEE Std 610.12-1990 – IEEE Standard glossary of software engineering terminology. (IEEE Std 610.12-1990- Tiêu chuẩn IEEE: Bảng chú giải thuật ngữ kỹ thuật phần mềm).

[29] IEEE Std 829-1998 – IEEE Standard for software test documetation. (IEEE Std 829-1998 – Tiêu chuẩn IEEE cho tài liệu kiểm tra phần mềm).

[30] IEEE Std 1044-1993 – IEEE Standard classification for anomalies. (IEEE Std 1044-1993 – Tiêu chuẩn IEEE: Phân loại các khác thường).

[31] ISO/IEC 25062 – Software engineering – Software product quality requirements and evaluation (SQuaRE) – Common industry format (CIF) for usability test reports. (ISO/IEC 25062 – Kỹ thuật phần mềm – Các yêu cầu và đánh giá chất lượng sản phẩm phần mềm (SQuaRE) – Khuôn dạng công nghiệp chung cho các báo cáo kiểm tra tính khả dụng).

[32] ISO/IEC 2382.1:1993 – Information technology – Vocabulary – Part 1: Fundamental terms. (ISO/IEC 2382.1:1993 – Công nghệ thông tin – Từ vựng – Phần 1: Các thuật ngữ cơ bản).

 

Mục lục

1. Phạm vi áp dụng

2. Sự phù hợp

3. Tài liệu viện dẫn

4. Thuật ngữ và định nghĩa

5. Các yêu cầu đánh giá sản phẩm phần mềm COTS

5.1. Các yêu cầu mô tả sản phẩm

5.1.1. Tính sẵn sàng

5.1.2. Nội dung

5.1.3. Nhận biết và chỉ dẫn

5.1.4. Các công bố về tính năng

5.1.5. Các công bố về tính tin cậy

5.1.6. Các công bố về tính khả dụng

5.1.7. Các công bố về tính hiệu quả

5.1.8. Các công bố về khả năng bảo trì

5.1.9. Các công bố về tính khả chuyển

5.1.10. Các công bố về chất lượng sử dụng

5.2. Các yêu cầu cho tài liệu hướng dẫn người sử dụng

5.2.1. Tính hoàn thiện

5.2.2. Tính chính xác

5.2.3. Tính thống nhất

5.2.4. Tính dễ hiểu

5.2.5. Tính dễ học

5.2.6. Tính dễ vận hành

5.3. Các yêu cầu chất lượng cho phần mềm

5.3.1. Tính chức năng

5.3.2. Tính tin cậy

5.3.3. Tính khả dụng

5.3.4. Tính hiệu quả

5.3.5. Khả năng bảo trì

5.3.6. Tính khả chuyển

5.3.7. Chất lượng sử dụng

6. Yêu cầu cho tài liệu hướng dẫn kiểm tra

6.1. Các yêu cầu chung

6.1.1. Mục tiêu

6.1.2. Tính thống nhất

6.1.3. Các yêu cầu cho nội dung

6.2. Các yêu cầu cho kế hoạch kiểm tra

6.2.1. Phương pháp tiếp cận

6.2.2. Tiêu chí đạt/không đạt

6.2.3. Môi trường kiểm tra

6.2.4. Lịch trình

6.3. Các yêu cầu cho mô tả kiểm tra

6.3.1. Mô tả trường hợp kiểm tra

6.3.2. Thủ tục kiểm tra

6.4. Các yêu cầu cho kết quả kiểm tra

6.4.1. Báo cáo thực hiện

6.4.2. Báo cáo khác thường

7. Hướng dẫn đánh giá sự phù hợp

7.1. Các quy tắc chung

7.2. Các yêu cầu sơ bộ đánh giá sự phù hợp

7.3. Hoạt động đánh giá sự phù hợp

7.4. Quá trình đánh giá sự phù hợp của bên thứ ba

7.6. Theo dõi đánh giá sự phù hợp

Phụ lục A. (Tham khảo) Định nghĩa từ các tiêu chuẩn khác

Phụ lục B. (Tham khảo) Hướng dẫn áp dụng sản phẩm phần mềm COTS trong các ứng dụng nghiệp vụ quan trọng hay yêu cầu phải an toàn

B.1. Phát hiện và hóa giải lỗi bao gồm dự phòng phần mềm

B.2. Hồi phục lỗi bằng cách thực hiện lại

B.3. Lập trình n-Version

B.5. Tuân theo mô hình

B.6. Trình bao bọc

B.7. Các kỹ thuật được xem xét để thiết lập tính toàn vẹn sản phẩm phần mềm COTS

Phụ lục C. (Tham khảo) Sử dụng tiêu chuẩn

Thư mục tài liệu tham khảo