Tiêu chuẩn Quốc gia TCVN 10607-4:2014 ISO/IEC 15026-4:2012 Kỹ thuật phần mềm và hệ thống-Đảm bảo phần mềm và hệ thống-Phần 4: Đảm bảo trong vòng đời

TIÊU CHUẨN QUỐC GIA

TCVN 10607-4:2014

ISO/IEC 15026-4:2012

KỸ THUẬT PHẦN MỀM VÀ HỆ THỐNG - ĐẢM BẢO PHẦN MỀM VÀ HỆ THỐNG - PHẦN 4: ĐẢM BẢO TRONG VÒNG ĐỜI

Systems and software engineering - Systems and software assurance - Part 4: Assurance in the life cycle

Lời nói đầu

TCVN 10607-4:2014 hoàn toàn tương đương với ISO/IEC 15026-4:2012.

TCVN 10607-4:2014 do Ban kỹ thuật tiêu chuẩn quốc gia TCVN/JTC 1 Công nghệ thông tin biên soạn, Tổng cục Tiêu chuẩn Đo lường Chất lượng đề nghị, Bộ Khoa học và Công nghệ công bố.

Bộ TCVN 10607 (ISO/IEC 15026) Kỹ thuật phần mềm và hệ thống gồm các tiêu chuẩn sau:

- TCVN 10607-1:2014 (ISO/IEC 15026-1:2013) Kỹ thuật phần mềm và hệ thống - Đảm bảo phần mềm và hệ thống - Phần 1: Khái niệm và từ vựng;

- TCVN 10607-2:2014 (ISO/IEC 15026-2:2011) Kỹ thuật phần mềm và hệ thống - Đảm bảo phần mềm và hệ thống - Phần 2: Trường hợp đảm bảo;

- TCVN 10607-3:2014 (ISO/IEC 15026-3:2011) Kỹ thuật phần mềm và hệ thống - Đảm bảo phần mềm và hệ thống - Phần 3: Mức toàn vẹn hệ thống;

- TCVN 10607-4:2014 (ISO/IEC 15026-4:2012) Kỹ thuật phần mềm và hệ thống - Đảm bảo phần mềm và hệ thống - Phần 4: Đảm bảo trong vòng đời.

KỸ THUẬT PHẦN MỀM VÀ HỆ THỐNG - ĐẢM BẢO PHẦN MỀM VÀ HỆ THỐNG - PHẦN 4: ĐẢM BẢO TRONG VÒNG ĐỜI

Systems and software engineering - Systems and software assurance - Part 4: Assurance in the life cycle

1. Phạm vi áp dụng

Tiêu chuẩn này đưa ra hướng dẫn và khuyến nghị đối với việc quản lý các quy trình, hoạt động và các tác vụ được chọn lựa đối với các hệ thống và sản phẩm phần mềm yêu cầu các đòi hỏi đảm bảo đối với sự quan tâm đặc biệt, được gọi là các đặc tính quan trọng. Tiêu chuẩn này quy định một danh sách đặc tính độc lập của các quy trình, hoạt động, tác vụ nhằm đạt được đòi hỏi và thể hiện việc đạt được đòi hỏi đó. Tiêu chuẩn này thiết lập các quy trình, hoạt động, tác vụ và khuyến nghị theo ngữ cảnh của một mô hình vòng đời và tập các quy trình vòng đời được định nghĩa đối với hệ thống và/hoặc việc quản lý vòng đời phần mềm.

CHÚ THÍCH Bên liên quan xác định điều mà các đặc tính hệ thống hay phần mềm được chọn lựa đối với sự quan tâm đặc biệt và yêu cầu các đòi hỏi đảm bảo. Tiêu chuẩn này sử dụng thuật ngữ “quan trọng” nhằm phân biệt các đặc tính đó với các yêu cầu khác.

2. Sự phù hợp

Có thể đòi hỏi sự phù hợp đối với tiêu chuẩn này với mối quan hệ giữa dạng quy trình đảm bảo các hệ thống và/hoặc dạng quy trình đảm bảo phần mềm. Do đó, sự phù hợp với tiêu chuẩn này có thể đạt được theo một hay hai cách thức sau:

a) Mô tả các kết quả được yêu cầu của dạng quy trình đảm bảo hệ thống (Điều 6.1.2) đã đạt được, nhằm phù hợp với Thỏa thuận, Dự án và Quy trình kỹ thuật của ISO/IEC 15288.

b) Mô tả các kết quả được yêu cầu của dạng quy trình đảm bảo phần mềm (Điều 6.2.2) đã đạt được, nhằm phù hợp với Thỏa thuận, Dự án, quy trình Đặc tả Phần mềm và Kỹ thuật của ISO/IEC 12207:2008.

Một đòi hỏi phù hợp chỉ tương ứng với các đòi hỏi cụ thể liên quan tới các hệ thống và phần mềm được chọn.

Sự phù hợp đối với TCVN 10607-2 có thể hỗ trợ nhằm đạt các kết quả cần thiết bởi hai dạng quy trình trong tiêu chuẩn này.

CHÚ THÍCH Các bên có một thỏa thuận có thể chọn lựa nhằm kết hợp các phần được chọn lựa của tiêu chuẩn này theo thời hạn của thỏa thuận. Tuy nhiên, việc tuân thủ thỏa thuận không biện minh một đòi hỏi phù hợp đối với tiêu chuẩn này. Một đòi hỏi phù hợp chỉ có thể được biện minh như đã giải thích bên trên.

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

Các tài liệu viện dẫn sau rất cần thiết cho việc á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 phiên 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ó).

TCVN 10607-1 (ISO/IEC 15026-1) Kỹ thuật phần mềm và hệ thống - Đảm bảo phần mềm và hệ thống - Phần 1: Khái niệm và từ vựng

ISO/IEC 15288:2008, Systems and software engineering - System life cycle processes

ISO/IEC 12207:2008, Systems and software engineering - Software life cycle processes

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

Tiêu chuẩn này áp dụng các thuật ngữ và định nghĩa được đưa ra trong TCVN 10607-1, ISO/IEC 15288:2008 và ISO/IEC 12207:2008.

5. Khái niệm quan trọng và sử dụng tiêu chuẩn

5.1. Phương pháp tiếp cận vòng đời

Giả định rằng người dùng tiêu chuẩn này đang sử dụng một mô hình vòng đời và tập các quy trình vòng đời được định nghĩa đối với hệ thống và/hoặc sự quản lý vòng đời phần mềm. Thông qua vòng đời, các hệ thống và dạng quy trình phần mềm trong Điều 6 sử dụng hướng dẫn và khuyến nghị trong Điều 7 đối với công năng của các quy trình, hoạt động và tác vụ cụ thể nhằm đạt được và thể hiện việc đạt được đòi hỏi đảm bảo. Khi tất cả quy trình của ISO/IEC 15288 và ISO/IEC 12207 được áp dụng lặp và đệ quy trong vòng đời, hướng dẫn và khuyến nghị đảm bảo cũng được áp dụng lặp và đệ quy. Theo cách đó, việc đạt được đảm bảo có thể được kiểm tra trong mỗi lần lặp hay đệ quy.

CHÚ THÍCH Xem ISO/IEC TR 24748-1 để có các thông tin về mô hình vòng đời, việc lặp và đệ quy các quy trình.

5.2. Đòi hỏi đảm bảo

Khi các đòi hỏi hệ thống và sản phẩm phần mềm kêu gọi sự đảm bảo của một hay nhiều đặc tính quan trọng của hệ thống hay sản phẩm phần mềm, các đòi hỏi đảm bảo tổng quan liên quan tới các giá trị đặc tính này được đề cập trong bộ TCVN 10607 như các đòi hỏi đảm bảo. Các đặc tính quan trọng thường theo các lĩnh vực có các rủi ro hay hệ quả quan trọng liên quan như: độ tin cậy, tính khả trì, an toàn, an ninh và yếu tố con người.

CHÚ THÍCH Tài liệu trong điều này được phù hợp với TCVN 10607-2.

Việc đạt được đòi hỏi đảm bảo thường bao gồm tất cả xem xét có liên quan trong việc đạt được đòi hỏi chính xác. Một đòi hỏi được định nghĩa trong ISO/IEC 29148 là: “mô tả các chuyển dịch hoặc thể hiện một nhu cầu, các khó khăn và điều kiện liên quan” và được định nghĩa trong TCVN 10607-1 là: “mô tả điều gì đó chính xác bao gồm các điều kiện và giới hạn liên quan”. Tiêu chuẩn này xem xét yêu cầu là các mô tả giá trị đối với các biến và đòi hỏi là các mô tả các yêu cầu là đúng.

Trong khi các đòi hỏi có thể phát sinh từ một số nguồn, chúng thường được thúc đẩy bởi các hệ quả tiêu cực thực tế tiềm ẩn liên quan tới mục đích sử dụng hệ thống và được biện minh là sự phát sinh theo các yêu cầu hệ thống và phần mềm. Mỗi đòi hỏi đảm bảo được quy định rõ ràng và đầy đủ, bao gồm:

a) “Đòi hỏi đảm bảo” - là các đòi hỏi mức cao, bao gồm:

1) Các giá trị cho các biến của đặc tính quan trọng được yêu cầu cho việc đạt được của nó.

2) Các giới hạn của độ không xác định cho phép liên quan tới việc đạt được này.

3) Các điều kiện và/hoặc thời hạn áp dụng khi nó áp dụng.

4) Tập các phiên bản hoặc trường hợp của sản phẩm phần mềm hay hệ thống được bao trùm bởi các đòi hỏi.

b) “Biện minh cho các đòi hỏi đảm bảo” - sự biện minh đối với việc chọn lựa và quy định các đòi hỏi đảm bảo đặc biệt.

c) “Nội dung thông tin thể hiện việc đạt được đòi hỏi đảm bảo” hoặc ngắn gọn hơn là: “thông tin thể hiện [hoặc đảm bảo] việc đạt được đòi hỏi đảm bảo”.

Điều cuối cùng bao gồm bằng chứng, lý do hay lập luận thể hiện cách thức bằng chứng hỗ trợ các đòi hỏi và bất kỳ giả định nào làm cơ sở cho lý do đó. Lý do này thường có nhiều mức đòi hỏi được phát sinh từ bên trong nó, ví dụ: các đòi hỏi về phần tử hệ thống ở mỗi mức phân tách cần đúng để các đòi hỏi đảm bảo về hệ thống hay sản phẩm phần mềm là đúng. Nội dung thông tin cũng bao gồm thông tin về: tính hiệu lực, toàn vẹn, tương quan và ý nghĩa của bằng chứng.

Lý do thường bao gồm một vài loại lập luận khác nhau, ví dụ: các lập luận dựa trên lý do thiết kế, việc sử dụng các kỹ thuật thiết kế phòng thủ, việc xác minh và xác thực kết quả, công năng của các hệ thống hay sản phẩm tương tự, sự phù hợp với các tiêu chuẩn hay dữ liệu miền. Chúng được kết hợp nhằm đạt một kết luận chung và một đánh giá độ không xác định còn tồn tại liên quan tới việc đạt được đòi hỏi đảm bảo.

Nội dung thông tin kết hợp và tổ chức thành ba mục này là: một (hay nhiều) phần tử hệ thống hay sản phẩm phần mềm, được duy trì và cập nhật trong suốt vòng đời hệ thống nhằm bao trùm việc phát triển hay duy trì. Như một phần tử hệ thống, tất cả quy trình, hoạt động và các tác vụ liên quan tới một phần tử hệ thống áp dụng cho nó, ví dụ: quản lý cấu hình, xác minh và xác thực.

5.3. Sử dụng tiêu chuẩn

Tiêu chuẩn này có thể sử dụng đối với một thỏa thuận giữa một nhà thâu nhận và nhà cung cấp, đối với các mục đích pháp lý, hoặc đánh giá các quy trình phát triển nội bộ nhằm tăng cường việc đạt được và thể hiện việc đạt được đòi hỏi đảm bảo đối với hệ thống hay sản phẩm phần mềm. Tuy nhiên, việc sử dụng tiêu chuẩn này không bị giới hạn theo ba mục đích này.

5.3.1. Sử dụng một thỏa thuận

Tiêu chuẩn này có thể sử dụng đối với một thỏa thuận giữa nhà thâu nhận và nhà cung cấp liên quan tới việc đạt được và thể hiện việc đạt được một đòi hỏi đảm bảo theo giá trị của các biến đối với một đặc tính quan trọng của hệ thống hay sản phẩm phần mềm đã được thừa nhận. Mối quan hệ giữa nhà thâu nhận và nhà cung cấp có thể xảy ra ở nhiều mức khác nhau của chuỗi cung ứng (nhà cung cấp chính, bên trong một tổ chức,.v..v.)

CHÚ THÍCH Một thỏa thuận có thể tồn tại nhiều dạng: từ một bản hợp đồng viết tay cho tới một thỏa thuận bằng lời.

5.3.2. Sử dụng cho quy định

Một đơn vị có thẩm quyền có thể sử dụng tiêu chuẩn này để quy định nhằm đảm bảo một vài đặc tính quan trọng của một hệ thống hay sản phẩm phần mềm. Sự cần thiết đối với quy định đó có thể phát sinh nhằm đảm bảo hay chứng thực một đặc tính quan trọng của một hệ thống hay sản phẩm phần mềm, nhằm làm rõ việc đảm bảo chúng theo điều kiện thương mại hay nhằm thực hiện một vài hoạt động khác.

5.3.3. Sử dụng cho phát triển

Tiêu chuẩn này có thể được sử dụng đối với một đánh giá nội bộ bởi nhà phát triển nhằm cải thiện các quy trình của nó đối với việc đạt được và thể hiện việc đạt được đòi hỏi đảm bảo của các đặc tính hệ thống hay sản phẩm phần mềm quan trọng mà nó phát triển.

6. Mục đích dạng quy trình và kết quả được yêu cầu

6.1. Dạng quy trình đảm bảo hệ thống

Các điều sau định nghĩa mục đích và kết quả được yêu cầu đối với dạng quy trình đảm bảo hệ thống.

6.1.1. Mục đích

Mục đích của dạng quy trình đảm bảo hệ thống là đạt được đòi hỏi đảm bảo liên quan tới các đặc tính hệ thống được chọn lựa đối với sự quan tâm đặc biệt và cung cấp một nội dung thông tin thể hiện việc đạt được đòi hỏi đó. Dạng quy trình đảm bảo hệ thống bao trùm hệ thống đáng quan tâm bao gồm bất kỳ phần mềm thành phần nào.

6.1.2. Kết quả được yêu cầu

Các kết quả sau phải thu được từ việc xây dựng thành công Dạng quy trình đảm bảo hệ thống:

a) Một tập con các yêu cầu cho việc đạt được đặc tính quan trọng được định nghĩa.

b) Các đòi hỏi đảm bảo, biện minh của chúng và nội dung thông tin thể hiện việc đạt được đòi hỏi đảm bảo đối với các đặc tính quan trọng được xây dựng như một phần tử hệ thống.

c) Một chiến lược nhằm đạt được đòi hỏi đảm bảo này và thể hiện việc đạt được đã được định nghĩa.

d) Sự mở rộng việc đạt được đòi hỏi đảm bảo được kết nối với bên liên quan bị ảnh hưởng.

6.2. Dạng quy trình đảm bảo phần mềm

Các điều sau định nghĩa mục đích và kết quả được yêu cầu của dạng quy trình đảm bảo phần mềm.

6.2.1. Mục đích

Mục đích của dạng quy trình đảm bảo phần mềm là nhằm đạt được đòi hỏi đảm bảo liên quan tới các đặc tính phần mềm được chọn lựa đối với mối quan tâm đặc biệt và cung cấp một nội dung thông tin thể hiện việc đạt được đòi hỏi đó.

6.2.2. Kết quả được yêu cầu

Các kết quả sau phải thu được từ việc xây dựng thành công Dạng quy trình đảm bảo phần mềm:

a) Một tập con các yêu cầu đối với việc đạt được các đặc tính quan trọng đối với việc ứng dụng dạng quy trình này được định nghĩa.

b) Các đòi hỏi đảm bảo, biện minh của chúng và nội dung thông tin thể hiện việc đạt được đòi hỏi đảm bảo đối với các đặc tính quan trọng được thiết lập như một phần tử hệ thống.

c) Một chiến lược nhằm đạt được đòi hỏi đảm bảo này và thể hiện việc đạt được được định nghĩa.

d) Sự mở rộng việc đạt được đòi hỏi được kết nối với bên liên quan bị ảnh hưởng.

7. Hướng dẫn và khuyến nghị đảm bảo đối với quy trình được chọn lựa

7.1. Giới thiệu

Điều 7 dẫn chứng các hoạt động và tác vụ của Thỏa thuận, Dự án và các loại quy trình kỹ thuật trong các tiêu chuẩn: ISO/IEC 15288:2008 và ISO/IEC 12207:2008, yêu cầu việc mở rộng hay diễn giải đặc biệt khi một mức đảm bảo được định nghĩa được mô tả. Số lượng các hoạt động và tác vụ đó tương ứng với số lượng trong các tiêu chuẩn gốc (ISO/IEC 15288 và ISO/IEC 12207). Hướng dẫn và khuyến nghị liên quan tới đòi hỏi đảm bảo được nêu ra đối với việc thực hiện các hoạt động và tác vụ này nhằm đạt được kết quả của các dạng quy trình. Hướng dẫn và các khuyến nghị này thừa nhận và dựa trên toàn bộ ứng dụng của các tiêu chuẩn: ISO/IEC 15288 và ISO/IEC 12207 được đề cập trong Điều 3. Các quy trình và hoạt động không được dẫn chứng trong điều này được xem xét đầy đủ như được định nghĩa trong các tiêu chuẩn: ISO/IEC 15288 và ISO/IEC 12207 nhằm đạt được đòi hỏi đối với các đặc tính quan trọng.

7.2. Quy trình thâu nhận

Quy trình thâu nhận (Điều 6.1.1, ISO/IEC 15288 và Điều 6.1.1, ISO/IEC 12207) thu được một sản phẩm hay dịch vụ tương ứng với các yêu cầu của nhà thâu nhận. Khi thâu nhận một phần tử hệ thống, quy trình này phải đảm bảo rằng tất cả yêu cầu đối với việc đạt được hay thể hiện việc đạt được bất kỳ đòi hỏi đảm bảo nào tương ứng với phần tử hệ thống được chuyển đến cho nhà cung cấp thông qua thỏa thuận.

7.2.1. Hoạt động và tác vụ liên quan

7.2.2. Hướng dẫn và khuyến nghị đảm bảo

Dự án phải đảm bảo rằng thỏa thuận xem xét tới các biến và giá trị của các đặc tính quan trọng của chúng đối với phần tử hệ thống được thu thập. Thỏa thuận phải bao gồm các yêu cầu toàn vẹn (ví dụ: việc bảo vệ chống lại các phần ngụy tạo, sự giả mạo, phần tử hệ thống với các lỗ hổng và sự tiết lộ thông tin tuyệt mật, bao trùm thông tin về các lỗ hổng để đảm bảo rằng kết quả thu được là đáng mong đợi. Dự án phải bắt nguồn từ các đòi hỏi đối với phần tử hệ thống được thâu nhận từ các đòi hỏi đảm bảo hệ thống và kết hợp chúng thành đề nghị hỗ trợ phần tử hệ thống. Ngoài ra, dự án phải kết hợp với các xem xét sau thành các đàm phán và thỏa thuận với nhà cung cấp:

a) Tin tưởng rằng các kiểm soát thích hợp liên quan tới tính khả tín (ví dụ: sự tin cậy) của nhân viên và tổ chức liên quan được thiết lập hiệu quả.

b) Tin tưởng rằng nhà cung cấp phòng giữ khỏi các phần ngụy tạo, sự giả mạo và các đe dọa khác đối với hệ thống hoặc sự toàn vẹn sản phẩm cũng như chống lại việc tiết lộ thông tin tuyệt mật.

c) Tin tưởng rằng phần tử hệ thống được truyền, nhận và có khả năng mở rộng, được cài đặt và vận hành và là một trong nhiều mục đích.

d) Tin tưởng rằng môi trường phát triển sản phẩm có các tài nguyên thích hợp tại chỗ nhằm bảo vệ sự toàn vẹn sản phẩm và các đặc tính quan trọng của nó trong suốt quá trình phát triển.

e) Tin tưởng rằng mô hình vòng đời phát triển phần mềm hay hệ thống được chọn lựa bởi nhà cung cấp là thích hợp với bản chất của bất kỳ các đòi hỏi nào đạt được.

f) Tin tưởng rằng các kiểm soát thích hợp liên quan tới việc triển khai của khả tín, yêu cầu an toàn, việc đạt được khả tín hệ thống và các yêu cầu toàn vẹn an toàn được triển khai hiệu quả.

g) Tin tưởng rằng vòng đời phát triển được quản lý sử dụng các quy trình lặp lại, được ghi chép cẩn thận, được giám sát dựa trên một kế hoạch quản lý chất lượng thích hợp với bản chất của các đòi hỏi đạt được.

Dự án phải xem lại các cách tiếp cận nhằm thể hiện việc đạt được đòi hỏi khi xem xét một thâu nhận từ nhà cung cấp khi các mối quan hệ giữa nhà cung cấp thay đổi (ví dụ: được thâu nhận, tạo mới, hòa trộn với thực thể khác) hoặc nếu yêu cầu của nhà thâu nhận thay đổi để đảm bảo rằng nhà cung cấp không trì hoãn thông tin được yêu cầu, cho phép một đe dọa mới hoặc phá hoại các bảo vệ tại chỗ sẵn sàng bảo vệ hệ thống.

Dự án phải trình một yêu cầu đề xuất (RFP) mà có thể được hiểu chính xác bởi nhà cung cấp và bên liên quan khác và thiết lập một thủ tục đối với việc giải quyết các vấn đề, có thể được mở rộng đối với một thay đổi thỏa thuận trong trường hợp giải quyết vấn đề bao quát. Dựa trên một thay đổi thỏa thuận, dự án cần đảm bảo rằng các yêu cầu bên liên quan được định nghĩa trong quy trình Định nghĩa yêu cầu bên liên quan là điểm thay đổi khởi đầu. Dự án cần xem xét một thỏa thuận nhiều giai đoạn khi thích hợp.

CHÚ THÍCH Tham khảo Phụ lục F.3, ISO/IEC 12207:2008 đối với một mô tả của Quy trình quản lý thay đổi hợp đồng.

7.3. Quy trình cung ứng

Quy trình cung ứng (Điều 6.1.2, ISO/IEC 15288:2008, và Điều 6.1.2, ISO/IEC 12207:2008) chỉ ra một nhà thâu nhận với một sản phẩm hay dịch vụ nhằm đáp ứng các yêu cầu được thỏa thuận. Khi một phần tử hệ thống được cung cấp, quy trình này cần đảm bảo rằng tất cả yêu cầu đối với việc đạt được hoặc thể hiện bất kỳ việc đạt được đòi hỏi nào là tương ứng với phần tử hệ thống được chuyển đến nhà thâu nhận.

7.3.1. Hoạt động và tác vụ liên quan

7.3.2. Hướng dẫn và khuyến nghị đảm bảo

Dự án phải đảm bảo rằng thỏa thuận xem xét tính khả thi của các biến và giá trị của các đặc tính quan trọng đối với phần tử hệ thống được cung cấp, từ các yếu tố kỹ thuật và tài nguyên. Thỏa thuận phải bao gồm các yêu cầu toàn vẹn nhằm đảm bảo rằng cái được đưa ra là cái đáng mong đợi. Dự án phải chỉ ra bằng chứng và lập luận đối với các đòi hỏi của phần tử hệ thống được bắt nguồn từ các đòi hỏi đảm bảo hệ thống. Ngoài ra, dự án cần kết hợp với các cân nhắc sau thành các đàm phán và thỏa thuận với nhà thâu nhận, nhằm đạt được sự đảm bảo sự bù đắp tài nguyên sẵn có cho dự án:

a) Tin tưởng rằng có một cách thức nhằm đáp ứng các yêu cầu chính yếu một cách thiết thực theo các yếu tố kỹ thuật và các yếu tố khác.

b) Xem xét một thỏa thuận nhiều giai đoạn, trong thường hợp mà việc đánh giá chi phí chính xác là khó khăn.

c) Xem xét sự bắt đầu từng bước của các vận hành hệ thống, phải là một khả năng của việc thiếu thời hạn tùy theo lý do không mong muốn.

7.4. Quy trình lập kế hoạch dự án

Quy trình lập kế hoạch dự án (Điều 6.3.1, ISO/IEC 15288:2008 và Điều 6.3.1, ISO/IEC 12207:2008) cung cấp và kết nối các kế hoạch dự án khả thi và hiệu quả. Nhằm đảm bảo, các kế hoạch dự án bao gồm các tài nguyên tương xứng nhằm đạt được đòi hỏi đảm bảo và thể hiện việc đạt được đòi hỏi đó.

CHÚ THÍCH Các đòi hỏi đảm bảo và việc thể hiện kết quả của các đòi hỏi đó có thể được thu được trong một trường hợp đảm bảo theo cấu trúc và định dạng của TCVN 10607-2.

7.4.1. Hoạt động và tác vụ liên quan

7.4.2. Hướng dẫn và khuyến nghị đảm bảo

Dự án phải bao gồm mục tiêu đảm bảo đối với các đặc tính quan trọng trong mục tiêu dự án. Các mục tiêu đảm bảo này phải bao gồm các hạn chế và phản ánh các luật, quy định và các tiêu chuẩn đối với việc tuân thủ dự án nhằm đạt được các mục tiêu đó, đảm bảo rằng các hoạt động và tác vụ đối với việc thu thập các giấy phép hay chứng nhận cần thiết được bao quát trong việc lập kế hoạch. Ví dụ: một đặc tính quan trọng như: an toàn, bao gồm các chứng nhận an toàn được yêu cầu phải được phản ánh trong kế hoạch dự án.

CHÚ THÍCH Các mục tiêu đảm bảo dựa trên các đặc tính quan trọng được định nghĩa bởi việc xác định các nguy hiểm và hậu quả bao gồm: các tổn hại, đe dọa và các mối nguy được quản lý hay bị ảnh hưởng bởi hệ thống và bằng cách xem xét các giá trị có thể chấp nhận được của các biến đối với các đặc tính quan trọng đó và độ không xác định có thể chấp thuận tối đa.

Các mục tiêu này cần được kết nối với nhiều bên liên quan trong dự án nhiều nhất có thể, bao gồm: quản lý mức cao, các khách hàng và nhà cung cấp.

Phương thức phát triển, môi trường và các công cụ phải được xác định dựa trên các yêu cầu hệ thống.

CHÚ THÍCH Mỗi phương thức phát triển, ví dụ: các phương pháp hướng quy trình, hướng dữ liệu và hướng đối tượng có sự phù hợp riêng đối với các ứng dụng khác nhau. Phương pháp phát triển phải được chọn lựa dựa trên một phân tích của luồng công việc và thông tin được xử lý bởi hệ thống.

Dự án cần đảm bảo rằng cá nhân đó có các kỹ năng và thẩm quyền phù hợp nhằm bao trùm đầy đủ tất cả yêu cầu liên quan tới các đặc tính quan trọng và chỉ ra việc đạt được và thể hiện việc đạt được các đòi hỏi đối với các đặc tính quan trọng đó.

Kế hoạch dự án phải bao gồm việc lập kế hoạch nhằm đạt được các đòi hỏi đảm bảo và thể hiện rằng tiến trình dự án là phù hợp với các đòi hỏi được đáp ứng theo một thời gian, bao gồm: việc lập kế hoạch nhằm giải quyết các tác động tiềm ẩn từ các lỗ hổng và điểm yếu mà có thể ảnh hưởng tới các đòi hỏi. Dự án phải làm rõ các tác vụ và trách nhiệm liên quan tới các đòi hỏi.

Dự án phải lên kế hoạch đối với việc báo cáo độc lập liên quan tới các đòi hỏi đảm bảo bao gồm trách nhiệm đối với việc báo cáo liên quan tới các đòi hỏi và việc quản lý các mục; ghi chép các mục, báo cáo, xác định cách thức báo cáo và việc phổ biến thông tin sẽ được phối hợp trong toàn tổ chức (bao gồm các khách hàng và các nhà cung cấp khi cần thiết)

Dự án phải kết hợp các điểm quyết định và mốc quan trọng nhằm quản lý chi phí, lịch biểu và công năng rủi ro liên quan tới độ không xác định, không rõ ràng và các yêu cầu phát sinh mà góp phần nhằm đạt được đòi hỏi. Các điểm quyết định này phải là các điểm liên quan trong dự án mà các quyết định và yêu cầu quan trọng từ các bên liên quan không bị trì hoãn, bất kể độ phức tạp của chúng.

Dự án phải xác định các hành động phụ trợ được yêu cầu đối với việc thể hiện việc đạt được các đòi hỏi đối với các đặc tính quan trọng, bên cạnh việc phát triển hệ thống và phần mềm và tính toán chi phí, tỷ lệ thời gian và các tài nguyên cần thiết cho việc hoàn thiện chúng. Mục đích của các hoạt động phụ trợ này phải được đưa ra một cách định lượng bất kỳ khi nào có thể. Đánh giá định lượng là cần thiết đối với việc đánh giá kết quả trong Quy trình vận hành. Sự đánh giá việc đạt được phải được tiếp diễn trong suốt giai đoạn áp dụng đòi hỏi đảm bảo liên quan (ví dụ: thiết bị giám sát an toàn trong công nghiệp nguyên tử)

Dự án phải đánh giá việc sử dụng các sản phẩm thương mại và được đặt trước như các phần tử hệ thống dựa trên các sự cần thiết của dự án. Theo đánh giá này, dự án phải xem xét cách thức sử dụng các phần tử hệ thống thương mại có thể ảnh hưởng tới việc đạt được các đòi hỏi và thể hiện việc đạt được các đòi hỏi cho các đặc tính quan trọng bởi rủi ro có thể được gây ra bởi việc thực hiện điều khiển tính năng bởi các phần tử hệ thống đó. Khi việc tùy biến được yêu cầu, sự quan tâm đặc biệt phải được đưa ra nhăm đảm bảo rằng các đòi hỏi đảm bảo không bị vô hiệu.

7.5. Quy trình quản lý quyết định

Quy trình quản lý quyết định (Điều 6.3.3, ISO/IEC 15288:2008 và Điều 6.3.3, ISO/IEC 12208:2008) chọn lựa các cách giải quyết có lợi nhất của hành động dự án bất kỳ ở đâu các thay đổi tồn tại. Để đảm bảo cho các hoạt động của quy trình quản lý quyết định cần thiết nhằm đảm bảo rằng các hệ quả của việc đạt được và thể hiện việc đạt được đòi hỏi đối với đặc tính quan trọng được xem xét bất kỳ khi nào một quyết định được tạo ra.

7.5.1. Hoạt động và tác vụ liên quan

7.5.2. Hướng dẫn và khuyến nghị đảm bảo

Dự án phải bao gồm các quyết định liên quan tới các đòi hỏi đảm bảo như một hạng mục các loại quyết định trong chiến lược quản lý quyết định. Chiến lược quản lý quyết định phải đảm bảo rằng bất kỳ ảnh hưởng nào về việc đạt được và thể hiện việc đạt được các đòi hỏi được bao quát trong việc đánh giá các hệ quả và rủi ro tương ứng của các hoạt động thay đổi trong bất kỳ quyết định nào ảnh hưởng tới các chính sách, thủ tục, kế hoạch, cá nhân, môi trường, sản phẩm, dịch vụ và hạ tầng hỗ trợ quan trọng. Một khi một quyết định liên quan tới các đòi hỏi đã được tạo ra, ảnh hưởng của nó phải được phản ánh trong các cách tiếp cận nhằm thể hiện việc đạt được của chúng. Tiêu chí quyết định đối với các trao đổi và quyết định khác phải bảo vệ việc đảm bảo của đặc tính quan trọng và phải bao gồm các bên liên quan của đặc tính quan trọng đó.

7.6. Quy trình quản lý rủi ro

Quy trình quản lý rủi ro (Điều 6.3.4, ISO/IEC 15288:2008 và Điều 6.3.4, ISO/IEC 12207:2008) xác định, phân tích, xử lý và giám sát các rủi ro liên tục và có thể được áp dụng đối với các rủi ro liên quan tới việc thu thập, cung cấp, phát triển, duy trì, vận hành hay xử lý của một hệ thống. Các hoạt động và tác vụ của quy trình quản lý rủi ro là một phần quan trọng của việc tiếp cận nhằm thể hiện việc đạt được các đòi hỏi.

CHÚ THÍCH Mặc dù câu đầu nêu trên được nêu ra trong ISO/IEC 15288, một phần của bộ tiêu chuẩn này được bổ sung “hỗ trợ” dựa trên việc kế thừa các rủi ro đảm bảo trong việc hỗ trợ của một hệ thống.

7.6.2. Hướng dẫn và khuyến nghị đảm bảo

Việc quản lý các rủi ro phải được tương tác thông suốt trong suốt quy trình quản lý rủi ro theo việc thiết lập ưu tiên, đưa ra quyết định, triển khai và duy trì hồ sơ rủi ro và xử lý rủi ro. Thông tin biện minh đối với việc chọn lựa và đặc tả của các đòi hỏi đảm bảo, Nội dung thông tin thể hiện việc đạt được các đòi hỏi và các hạn chế được đòi hỏi đối với độ không xác định có thể được dùng như một khung đối với việc tổ chức và chỉ ra các rủi ro đảm bảo của các hệ thống. Thông tin này phải bao gồm các giả định, dữ liệu, xử lý và tính toán liên quan cần thiết để củng cố phân tích rủi ro và cho phép các đánh giá rủi ro được đánh giá, tái xây dựng và được kiểm tra.

Trong suốt vòng đời hệ thống, việc nhấn mạnh phải được đưa ra cho các yếu tố và điều kiện nhân quả đối với việc xuất hiện, các dấu hiệu cảnh báo và các chỉ báo của chúng của việc phát sinh rủi ro và hệ quả của chúng. Ngoài ra, việc quan tâm cẩn thận phải được đưa ra đối với các khó khăn trong việc đạt được bằng chứng cần thiết, nhằm đảm bảo việc báo cáo nhanh, đánh giá các báo cáo và duy trì các báo cáo toàn diện. Các thực hành phân tích và giảm thiểu các hậu quả của việc đảm bảo phải được phát triển và được dùng khi các nhà cung cấp các sản phẩm thương mại hay đặt trước tạo ra các thay đổi cho các sản phẩm này mà không cung cấp các thông tin chi tiết về các thay đổi đó.

Các rủi ro và các nguồn nguy cơ liên quan đối với các lỗ hổng và điểm yếu, đe dọa, mối nguy, lỗi, lỗi con người và các thay đổi an ninh đối với hệ thống hay môi trường của nó phải được xác định trong suốt vòng đời hệ thống. Dự án phải giả định việc tồn tại của trí thông minh và các đối tượng nguy hại trong việc triển khai và duy trì hồ sơ rủi ro của chính nó bởi bản chất quan trọng của các rủi ro liên quan. Khi đánh giá khả năng xuất hiện và các hệ quả của mỗi rủi ro được xác định, dự án phải xem xét chuỗi tác động hoàn thiện mà một đối tượng thông minh có thể gây ra. Một rủi ro của việc phá hoại tồn tại trong bất kỳ quy trình vòng đời nào bao gồm chính quy trình quản lý rủi ro.

Các khả năng sai sót để đạt được các đòi hỏi đảm bảo và sai sót nhằm chấp nhận thể hiện việc đạt được phải được xem xét thực tế, bao gồm các rủi ro của việc phải lặp lại các phần của hệ thống. Dự án phải đánh giá tiềm năng đối với việc không thể đạt được việc đảm bảo các hệ thống cần thiết theo một cách thức thời gian, dẫn đến một rủi ro đối với việc chứng nhận hay năng suất hệ thống hoặc dẫn đến hệ thống không được sử dụng như đã định. Hành động dự phòng theo sự kiện mà các đòi hỏi đảm bảo không thể được đạt theo phương thức thời gian phải được xác định, lên kế hoạch và được thừa nhận bởi các bên liên quan tương ứng.

7.7. Quy trình quản lý cấu hình

Quy trình quản lý cấu hình (Điều 6.3.5, ISO/IEC 15288:2008 và Điều 6.3.5, ISO/IEC 12207:2008) thiết lập và duy trì tính toàn vẹn của tất cả các tạo tác được xác định của một dự án hay quy trình và tạo ra cho chúng tính sẵn có đối với các bên liên quan. Nhằm đảm bảo, hai mối quan hệ tồn tại: (1) Quản lý cấu hình hiệu quả các phần tử hệ thống là bằng chứng của thông tin thể hiện việc đạt được của chính các đòi hỏi đảm bảo; (2) thông tin thể hiện việc đạt được của chính các đòi hỏi đảm bảo theo quản lý cấu hình.

7.7.1. Hoạt động và tác vụ liên quan

7.7.2. Hướng dẫn và khuyến nghị đảm bảo

Chiến lược quản lý cấu hình phải được phát triển nhằm xác định cách thức lấy thông tin liên quan từ quy trình quản lý cấu hình thành thông tin đảm bảo các đòi hỏi, bao quát trong suốt quá trình duy trì và để cung cấp sự bảo vệ của dữ liệu mục cấu hình và siêu dữ liệu, cho cả các kho và theo thay đổi.

Dự án phải xác định thông tin liên quan tới đòi hỏi đảm bảo được lên kế hoạch và được kết hợp liên tục thành một cấu hình định danh nhằm tạo thành một phiên bản được tổ chức của thông tin đảm bảo đòi hỏi. Việc đánh giá và kiểm tra các thủ tục và hoạt động quản lý cấu hình phải được hoàn thiện để ngăn ngừa các thay đổi cố ý hoặc bất hợp pháp của các sản phẩm được kiểm soát và để khuyến nghị hiệu chuẩn và các hành động ngăn ngừa liên quan tới các đòi hỏi đảm bảo.

Dự án phải đảm bảo sự phù hợp của tính toàn vẹn và an ninh của cấu trúc và thông tin được bao quát theo thông tin đảm bảo đòi hỏi với cách tiếp cận nhằm thể hiện việc đạt được đòi hỏi. Thông tin đảm bảo được yêu cầu phải được xác định và kết hợp liên tục trong một cấu hình định danh để tạo thành một phiên bản được tổ chức của thông tin đảm bảo đòi hỏi. Việc truy cập và phân phối kiểm soát, lưu trữ và bảo vệ phải được duy trì trong suốt vòng đời sản phẩm hay dịch vụ.

Dự án phải chỉ dẫn việc quản lý cấu hình nhằm tạo điều kiện cho việc đạt được và đảm bảo các đòi hỏi. Ở một mức tối thiểu sau:

a) Thực hiện các biện pháp chặt chẽ và bảo vệ mức rủi ro hệ thống, dữ liệu, nhiệm vụ và đảm bảo của đòi hỏi là linh hoạt đủ để cho phép chỉ ra một khối đe dọa lớn.

b) Điều chỉnh độ chi tiết trong quy trình quản lý cấu hình nhằm hỗ trợ cách tiếp cận để thể hiện việc đạt được các đòi hỏi.

Dự án phải triển khai và duy trì độ tin cậy, tính toàn vẹn, sẵn có, xác thực, trách nhiệm giải trình (bao gồm: không thoái thác) và khả năng kiểm tra được yêu cầu của thông tin đảm bảo đòi hỏi, bao gồm: sự kết hợp của các chiến lược và công nghệ sau đối với các quy trình quản lý cấu hình và công cụ hỗ trợ:

a) Từng thẩm quyền người dùng mạnh mẽ. Nếu các mật khẩu được dùng đối với việc xác thực, chúng phải luôn được mã hóa nhằm truyền thông qua một mạng và không bao giờ được lưu trữ ở dạng thông thường ở bất kỳ đâu.

b) Các kho khó chống lại sự tấn công. Ví dụ: trên nền tảng hỗ trợ kho tập trung, hạn chế số lượng các dịch vụ đang chạy khác nhằm giảm thiểu rủi ro mà các dịch vụ này có thể để lộ các kho để bị tấn công. Hạn chế và giám sát truy cập mạng cho hệ thống CM.

c) Tiêu chí chấp nhận chất lượng để tránh giới thiệu các phần tử hay tài liệu không thể chấp nhận.

d) Các kiểm tra của các kho quản lý cấu hình và quản trị.

e) Các bản ghi và các tính toán liên quan tới việc truy cập và các cập nhật dữ liệu, nhằm xác định nếu chúng là hoạt động không mong đợi hay bất thường (ví dụ: hoạt động theo thời gian, các khu vực, hệ thống hay cá nhân không bình thường, các cá nhân cập nhật một lượng lớn thông tin không theo thông lệ của các mục cấu hình,.v..v.)

f) Việc bảo vệ các hệ thống quản lý cấu hình (ví dụ: bằng cách khóa chúng lại) và truy cập được kiểm soát của hệ thống.

g) Các quy trình nhằm hỗ trợ bộ đếm dữ liệu thất thoát hoặc sự phá hoại kho quản lý cấu hình.

h) Các điểm mục vào được kiểm soát với sự truy cập cần thiết của chúng đối với dữ liệu quản lý cấu hình.

Dự án phải đánh giá các rủi ro phát sinh từ việc sử dụng quy trình quản lý cấu hình, bao quát các rủi ro do sai sót cá nhân, bao gồm: sự nguy hại, trừ phi việc biện minh được ghi chép được cung cấp để làm điều khác.

CHÚ THÍCH Hướng dẫn bổ sung cho các thực hành quản lý cấu hình này sẵn có trong TCVN ISO/IEC 27002 Công nghệ thông tin - Kỹ thuật an ninh - Mã thực thi cho quản lý an ninh thông tin và ISO 10007:2003 Quality management systems - Guidelines for configuration managemet.

7.8. Quy trình quản lý thông tin

Quy trình quản lý thông tin (Điều 6.3.6, ISO/IEC 15288 và Điều 6.3.6, ISO/IEC 12207) cung cấp thông tin liên quan theo thời gian, có hiệu lực và nếu được yêu cầu, thông tin tuyệt mật cho các bên được chỉ định trong suốt và sau vòng đời hệ thống nếu tương ứng. Để đảm bảo, quy trình này cung cấp thông tin về đạt được đảm bảo đòi hỏi đối với các bên liên quan tương ứng và cung cấp đối với việc phân phối nội dung thông tin thể hiện việc đạt được đảm bảo đòi hỏi đối với các bên liên quan tương ứng, bao gồm các nhà quy định và nhà phê duyệt.

7.8.1. Hoạt động và tác vụ liên quan

7.8.2. Hướng dẫn và khuyến nghị đảm bảo

Dự án cần lên kế hoạch và thiết lập một nội dung thông tin được ghi chép nhằm cung cấp các cơ sở cho sự tin tưởng các đòi hỏi đảm bảo, bao gồm: các giả định, lập luận, bằng chứng có cấu trúc và các mối quan hệ giữa chúng nhằm thể hiện cách thức các đòi hỏi sẽ hoặc đã được thỏa mãn.

CHÚ THÍCH TCVN 10607-2 cung cấp một cấu trúc của thông tin này dưới dạng một trường hợp đảm bảo nếu một trường hợp đảm bảo được yêu cầu bởi các bên liên quan quan tâm tới việc đảm bảo của một đặc tính quan trọng đặc biệt.

Ví dụ Khi các đòi hỏi này được tạo ra cho các đặc tính quan trọng “an toàn” hay “an ninh” của hệ thống, Nội dung thông tin phải cung cấp một lập luận bao trùm toàn bộ phạm vi được yêu cầu đối với an toàn hay an ninh. Các lập luận và bằng chứng hỗ trợ phải được tạo ra, thu thập và duy trì trong suốt vòng đời và thường bắt nguồn từ nhiều nguồn.

Dự án cũng phải thu thập, tổ chức và phân tích thông tin liên quan bổ sung liên quan tới việc đảm bảo các đòi hỏi sau:

a) Thông tin và bằng chứng hiện thời bao gồm thông tin liên quan từ các phiên bản trước đó, các hệ thống tương tự và các tập thông tin giống nhau bao gồm bất kỳ các lập luận và biện minh nào đối với việc sử dụng nó nhằm giảm thiểu các rủi ro và tạo cho cả sự thành công và thất bại.

b) Thông tin liên quan tới tính hiệu lực và toàn vẹn của thông tin đảm bảo đòi hỏi.

c) Thông tin và các báo cáo liên quan tới lỗi, sai sót do con người, khiếm khuyết, điểm yếu và các tai nạn liên quan tới việc đảm bảo đòi hỏi.

Dự án nên quản lý và kiểm soát thông tin liên quan tới việc đảm bảo đòi hỏi nhằm bảo đảm tính toàn vẹn và hiệu lực của nó. Dự án bao quát việc bảo vệ thông tin liên quan tới việc đảm bảo đòi hỏi, bao gồm: việc bảo vệ khỏi các hành động nguy hại; hạn chế truy cập thông tin nhạy cảm, bao gồm: đe dọa và thông tin độc hại và việc duy trì độ tin cậy được yêu cầu; và phản hồi các tai nạn liên quan tới thông tin đảm bảo đòi hỏi.

Bất kỳ khi nào một thay đổi được tạo ra trong thông tin liên quan tới việc đảm bảo đòi hỏi, phần thỏa thuận liên quan tới thay đổi và mối quan hệ giữa thay đổi và phần liên quan của việc thỏa thuận phải được làm rõ.

Dự án phải cung cấp các báo cáo tổng hợp tập thông tin này, các thay đổi đối với nó, chất lượng và tình trạng hoàn thiện của chính nó ở một khoảng dự kiến và cần thiết nhằm giám sát và quản lý hiệu quả. Dự án bao gồm việc thiết lập báo cáo các kênh cung cấp khả năng hiển thị thông tin liên quan cần thiết cho các bên liên quan trong việc đưa ra quyết định. Thông tin này bao quát nội dung để làm trong các trường hợp sử dụng thông thường mà hệ thống mong muốn để người dùng xác định khi hệ thống làm điều gì không mong đợi bởi nó có thể chỉ ra một nhánh tiềm năng của việc tuân thủ các hạn chế. Người dùng phải biết cách báo cáo hay hành động không theo lịch trình hay các điều kiện bất ngờ và bất kỳ nhánh nào của việc tuân thủ các hạn chế mà người dùng không tuân thủ thỏa hiệp với các hạn chế đó.

Các tài liệu viết tay ảnh hưởng tới các thỏa thuận bên liên quan phải được quản lý để bất kỳ sự khác biệt nào với việc một biên dịch của các bên liên quan được tối giản. Các tài liệu đó bao quát nhưng không bị giới hạn các yêu cầu đề xuất (RFP) bởi nhà thâu nhận và bên đề xuất theo dự án.

7.9. Quy trình định nghĩa yêu cầu bên liên quan

Quy trình định nghĩa yêu cầu bên liên quan (Điều 6.4.1, ISO/IEC 15288:2008 và Điều 6.4.1, ISO/IEC 12207:2008) định nghĩa các yêu cầu đối với một hệ thống mà có thể cung cấp các dịch vụ cần thiết cho người dùng và các bên liên quan khác trong một môi trường được định nghĩa. Quy trình này định danh các bên hay các nhóm của bên liên quan, tham gia hệ thống trong suốt vòng đời của chính nó và các nhu cầu, mong đợi hay mong muốn của chúng. Quy trình này phân tích và biến đổi các yêu cầu này thành một tập chung các yêu cầu bên liên quan. Như một tập con của các yêu cầu này, các đặc tính quan trọng cho một mức tin cậy cao được yêu cầu đối với việc đạt được được xác định và ghi chép lại.

7.9.1. Hoạt động và tác vụ liên quan

7.9.2. Hướng dẫn và khuyến nghị đảm bảo

Một tập các đặc tính quan trọng phải được xác định bằng việc phân tích tập hoàn chỉnh các yêu cầu được thu thập từ các bên liên quan. Các bên liên quan định nghĩa các yêu cầu của họ: một vài yêu cầu sẽ phát sinh như việc yêu cầu độ tin cậy cao trong việc đạt được của chúng bởi chúng được liên quan tới các hệ quả, rủi ro, luật pháp hay nhiệm vụ quan trọng khác (ví dụ: chống giả mạo, an ninh) liên quan tới các đặc tính hệ thống. Các yêu cầu đòi hỏi độ tin cậy cao có thể được dùng để xác định các đặc tính quan trọng của hệ thống hay sản phẩm phần mềm. Dự án cần hỗ trợ việc chọn lựa từ các quan điểm kỹ thuật, ví dụ: việc xác định các rủi ro, hệ quả bổ sung và tính bất định liên quan và sự tuân thủ các yêu cầu.

Là một phần của việc chọn lựa các đặc tính quan trọng, dự án cần định nghĩa các yêu cầu sơ bộ đối với việc thể hiện việc đạt được các đặc tính này, đặc biệt quan tâm tới các giao dịch liên quan tới sức chống chịu các rủi ro của bên liên quan. Bên liên quan cần xác định sức chống chịu lỗi, sự suy thoái và thỏa hiệp hay tổn thất của họ, ví dụ: các chế độ vận hành suy thoái. Dự án cũng phải xác định bất kỳ ngữ cảnh văn hóa, xã hội và tổ chức nào của một hệ thống có thể ảnh hưởng tới việc đạt được hay thể hiện việc đạt được một đặc tính đặc biệt. Hoạt động này được hỗ trợ bằng việc sử dụng kinh nghiệm và các bản ghi liên quan tới các phiên bản trước đó hoặc các hệ thống và các môi trường vận hành tương tự cũng như ý định được biết đến hay các dự đoán liên quan tới việc sử dụng hệ thống trong chính môi trường của nó.

Dự án phải ưu tiên các đặc tính để chọn lựa ra điều gì là quan trọng nhất cho việc cung cấp các đòi hỏi đảm bảo. Các đặc tính quan trọng được chọn lựa với việc biện minh và lý do cho việc lựa chọn của chúng phải được ghi chép và trở thành một phần của khả năng truy xuất cho nhu cầu bên liên quan cụ thể và được duy trì cho việc điều tra sau này khi cần thiết. Tài liệu và việc duy trì của lý do này được hoàn thiện như là một phần của việc duy trì khả năng truy xuất các yêu cầu bên liên quan đối với các nguồn của bên liên quan cần thiết. Các đặc tính quan trọng được chọn lựa được dùng cho các đòi hỏi đảm bảo mức cao.

Trong quá trình phân tích các yêu cầu của bên liên quan, thực tế rằng mỗi bên liên quan có trường hợp riêng của họ và tập các giá trị phải được phân chia.

CHÚ THÍCH Dự án phải làm việc xuyên suốt tập các bên liên quan có kiến thức về công nghệ nhằm xác định tính khả thi các yêu cầu trong suốt vòng đời. Vòng đời hoàn thiện phải xem xét tới việc xác định các yêu cầu tính khả thi và tránh các thay đổi mà dẫn đến các thay đổi chi phí, lịch trình và/hoặc hiệu năng không mong đợi sau này trong vòng đời khi nhiều chi tiết kỹ thuật về hệ thống được biết tới.

Dự án phải cố gắng loại bỏ các mục không được xác định trong tập các yêu cầu của bên liên quan. Các yêu cầu chức năng và phi chức năng phải được kiểm tra và định nghĩa, phản ánh thông tin về lượng tối đa công việc, các thời hạn kế toán hàng tháng và kinh nghiệm phát triển và vận hành thực tiễn. Việc thực hiện phải tối giản hóa các rủi ro hướng kỹ thuật nhằm cho phép nhiều đánh giá chính xác các tài nguyên con người, thời hạn và chi phí đối với vòng đời hệ thống. Các mục không xác định hay các rủi ro hướng kỹ thuật vẫn không thể tránh khỏi, dự án phải làm cho chúng rõ ràng và quản lý chúng trong quy trình quản lý rủi ro như một giai đoạn trong vòng đời khi có thể.

CHÚ THÍCH 1 Tham khảo ISO/IEC 29148:2011 Requirements Engineering để hiểu thêm và bao quát tất cả các loại yêu cầu và khái niệm vận hành.

CHÚ THÍCH 2 Nhà thâu nhận phải định nghĩa và quản lý các yêu cầu dựa trên loại vòng đời đối với dự án, cho phép dự án ước tính kinh phí và bắt đầu phát triển; dự án phải đánh giá chi phí dựa trên các yêu cầu cuối cùng để cho phép nhà thâu nhận đánh giá việc đầu tư. Các hành động này có thể không phải là khuynh hướng đầu tiên bởi sự dự đoán các rủi ro tiềm ẩn.

Các yêu cầu bên liên quan phải được giữ càng đơn giản càng tốt do các yêu cầu phức tạp thường dẫn tới một hệ thống phức tạp với kinh phí cao đối với việc phát triển và vận hành và có thể tạo ra đặc tính quan trọng khó khăn hơn để đảm bảo.

Dự án phải đảm bảo rằng các quyết định thiết yếu trong các giai đoạn sau của vòng đời được dựa trên các yêu cầu bên liên quan được định nghĩa trong quy trình này.

Dự án phải đảm bảo sự tham gia của tất cả các bên liên quan tương ứng (ví dụ: nhu cầu của các bên liên quan đó tương tự với nhu cầu kinh doanh đối với đặc tính quan trọng và kiến thức của đặc tính quan trọng) theo định nghĩa các yêu cầu để giữ trong các yêu cầu của bên liên quan bổ sung đối với các giai đoạn sau này của vòng đời.

CHÚ THÍCH Sự hợp tác là thiết yếu trong việc định nghĩa mục đích của hệ thống hay sản phẩm phần mềm (ví dụ: doanh nghiệp mới được cho phép bởi hệ thống hay phần mềm mới). Cá nhân dự án có kiến thức kỹ thuật phát triển phần mềm hay hệ thống nhưng không có hình ảnh chi tiết của việc sử dụng hệ thống hay phần mềm, trong khi các nhà thâu nhận, khách hàng hay người sử dụng biết sử dụng hệ thống và phần mềm không cần kỹ năng, kỹ thuật để xây dựng nó.

Dự án phải cố gắng để tối giản hóa số lượng các mục công việc cần thiết nhưng không được liệt kê trong các yêu cầu bên liên quan và bất kỳ việc sao chép các mục công việc nào trong các yêu cầu bên liên quan. Các hành động này giúp tối giản hóa rủi ro của việc hiểu lầm giữa các bên liên quan.

Dự án phải cung cấp hỗ trợ cho các bên liên quan khi được yêu cầu. Một vài bên liên quan có thể không có một nền tảng kỹ thuật và có thể cần hỗ trợ kỹ thuật trong việc định nghĩa các yêu cầu bên liên quan hoặc trong đàm phán để giải quyết xung đột của các yêu cầu bên liên quan. Việc biên dịch rõ ràng của các yêu cầu bên liên quan và ứng dụng kỹ thuật của các yêu cầu đó có thể cần thiết để đảm bảo một hiểu biết chung giữa các bên liên quan công nghệ và phi công nghệ.

Bên liên quan phải đồng ý rằng tất cả các chia sẻ nhiệm vụ của việc định nghĩa các yêu cầu theo cách thức cần thiết nhằm cung cấp các yêu cầu của họ tuân theo cách thức thông thường. Nhà phân tích hệ thống có thể có trách nhiệm đối với việc nêu ra các yêu cầu, nhưng các bên liên quan khác có nhiệm vụ hoạt động phối hợp với nhà phân tích.

Dự án phải đảm bảo rằng việc tiếp cận nhằm đạt được và thể hiện việc đạt được các đòi hỏi đảm bảo của việc chọn lựa các đặc tính quan trọng của hệ thống hay sản phẩm phần mềm được dàn xếp theo ngữ cảnh kinh doanh hoặc khái niệm các vận hành được thực hiện với hệ thống hay sản phẩm phần mềm.

Trong trường hợp cập nhật một hệ thống hiện thời, nhà phân tích thực hiện quy trình định nghĩa các yêu cầu bên liên quan phải thận trọng đối với cụm từ: “tương tự như hệ thống hiện thời” theo các yêu cầu bên liên quan. Khi các yêu cầu tăng cường, nhà phân tích phải kiểm tra thông suốt bất kỳ khi nào việc sử dụng hiện thời của hệ thống hoặc các giá trị hiện thời của các biến hệ thống trong thực tế được giữ không đổi trong hệ thống được cập nhật. Mối quan tâm đặc biệt phải được đưa ra đối với các đặc tính quan trọng và đòi hỏi đối với các đặc tính đó trong hệ thống hiện thời khi một hệ thống được cập nhật.

Mặc dù các yêu cầu thiết yếu được định nghĩa và xác định theo quy trình này, Định nghĩa Yêu cầu Bên liên quan có thể thay đổi như một hệ quả của việc giải quyết các xung đột giữa các yêu cầu của các bên liên quan khác nhau và các giới hạn từ việc xem xét hệ thống khi thực hiện các hoạt động của các quy trình sau đó là Phân tích Yêu cầu. Các hoạt động và tác vụ của hai quy trình này là được thực hiện lặp lại. Tùy thuộc kinh phí, lịch biểu và các hạn chế khác hay các thay đổi theo nhu cầu bên liên quan, các yêu cầu sẽ phát triển. Các thỏa thuận về các thay đổi yêu cầu được tạo ra, các tác động đối với khả năng đạt được các thỏa thuận liên quan tới đặc tính quan trọng phải được chỉ ra, mặc dù một thỏa thuận phải liên quan và không được thay đổi quá dễ dàng, ngay cả khi không có hành động tài chính hay hợp pháp nào đem lại kết quả.

CHÚ THÍCH 1 Tham khảo Điều 5, ISO/IEC 29148:2011 Requirements engineering để thảo luận nhiều hơn về bản chất lặp của các hoạt động và tác vụ này.

CHÚ THÍCH 2 Một quy trình đối với việc thực hiện một thay đổi thỏa thuận được bao quát trong Phụ lục F.3, ISO/IEC 12207:2008 Contract Change Management Process.

7.10. Quy trình phân tích yêu cầu

Quy trình phân tích yêu cầu (Điều 6.4.2, ISO/IEC 15288:2008) và quy trình phân tích yêu cầu hệ thống (Điều 6.4.2, ISO/IEC 12207:2008) biến đổi bên liên quan, dạng định hướng yêu cầu của các dịch vụ được mong đợi thành một dạng kỹ thuật của một sản phẩm được yêu cầu mà có thể chuyển giao các dịch vụ đó. Quy trình phân tích yêu cầu hệ thống (Điều 7.1.2, ISO/IEC 12207) thiết lập các yêu cầu của các thành phần phần mềm của hệ thống. Mục đích chính liên quan tới đòi hỏi đảm bảo của việc phân tích yêu cầu được bắt nguồn từ một tập đòi hỏi đảm bảo từ các đặc tính quan trọng. Phân tích yêu cầu lấy các đặc tính quan trọng được chọn lựa từ quy trình định nghĩa yêu cầu bên liên quan và gắn các biến đối với việc đánh giá đặc tính và các giá trị đối với các biến đó đối với việc tính toán đặc tính. Đòi hỏi đảm bảo là một bày tỏ về giá trị của các biến đối với đặc tính đó.

CHÚ THÍCH Trong TCVN 10607-1, một đòi hỏi được định nghĩa là một “bày tỏ của điều gì đúng bao gồm các điều kiện và giới hạn liên quan”. Ở đây, “điều gì” là “giá trị của các biến đối với đặc tính”.

7.10.1. Hoạt động và tác vụ liên quan

7.10.2. Hướng dẫn và khuyến nghị đảm bảo

Việc định nghĩa các yêu cầu hệ thống được thực hiện nhằm định nghĩa các giá trị cho các biến đối với các đặc tính quan trọng được chọn lựa bên ngoài của các yêu cầu bên liên quan được thu thập trong quy trình định nghĩa yêu cầu bên liên quan. Ranh giới chức năng của hệ thống liên quan tới các đặc tính quan trọng, các chức năng liên quan tới các đặc tính quan trọng và việc triển khai các hạn chế liên quan tới các đặc tính quan trọng phải được quy định rõ ràng. Giữa các tính toán được định nghĩa, các tính toán liên quan tới các giá trị của các biến của các đặc tả quan trọng đó phải được quy định rõ ràng và các yêu cầu hệ thống liên quan tới các đặc tả quan trọng phải được quy định rõ ràng theo các giá trị của các biến liên quan tới các đặc tính quan trọng đó. Hơn nữa, việc ưu tiên giữa các yêu cầu hệ thống liên quan tới các đặc tính quan trọng phải được định nghĩa và khả năng truy xuất được duy trì đối với các yêu cầu bên liên quan.

Ví dụ Nếu an toàn chức năng được chọn là đặc tính quan trọng, một phần của các yêu cầu hệ thống được yêu cầu được quy định cụ thể theo dạng quy trình nên là “các yêu cầu vòng đời an toàn” được mô tả trong IEC 61508-1.

Các giới hạn của môi trường hệ thống được yêu cầu nhằm đạt được và thể hiện việc đạt được các đòi hỏi được xác định bằng việc thực hiện phân tích các rủi ro hay hệ quả. Phân tích này được tạo điều kiện bằng cách thu thập thông tin đối với mỗi đòi hỏi sau:

a) Các rủi ro được phép tương ứng với hệ thống mà không đạt được đòi hỏi này.

b) Các giá trị được phép của các biến liên quan tới các đòi hỏi quan trọng.

c) Mức độ được phép của tính bất định liên quan tới đòi hỏi và thành quả của nó.

d) Các điều kiện có thể áp dụng liên quan tới đòi hỏi.

Trước khi hoàn tất việc phân tích các yêu cầu, dự án phải đánh giá các yêu cầu hệ thống liên quan tới các đặc tính quan trọng nhằm xác địch liệu chúng phù hợp với các yêu cầu bên liên quan và liệu chúng được thu thập đầy đủ các đặc tính quan trọng đó mà sự vi phạm có nhiều hệ quả và việc đạt được các bên liên quan yêu cầu mức tin tưởng cao. Tập tối thượng của các yêu cầu đạt được và được thể hiện đạt được có thể được chọn lựa và xác thực sau này. Dự án phải ghi chép tập được chọn lựa các đòi hỏi đảm bảo và các mối quan hệ giữa chúng với bên liên quan và các yêu cầu hệ thống mà biện minh cho chúng.

Dự án phải cung cấp một khung để xác thực các yêu cầu định nghĩa một hệ thống nhằm thực hiện điều được hướng tới để thực hiện mà không điều gì khác có thể trong việc chuyển đổi, vận hành và giảm thiểu các môi trường của chính nó.

Các yêu cầu hệ thống phải rõ ràng và được minh họa cụ thể; một tập không rõ ràng chưa được kiểm tra của các yêu cầu dẫn đến việc tăng chi phí, sai lịch biểu và giảm chất lượng hệ thống.

7.11. Quy trình xác minh

Đối với dạng quy trình đảm bảo các hệ thống, quy trình xác minh (Điều 6.4.6, ISO/IEC 15288:2008) xác nhận rằng các yêu cầu thiết kế được quy định được đáp ứng đầy đủ bởi hệ thống. Quy trình này cung cấp thông tin được yêu cầu nhằm tác động tới các hành động khắc phục hậu quả mà không phù hợp trong hệ thống hay các quy trình nhận dạng mà hoạt động trên nó. Quy trình xác minh phần mềm (Điều 7.2.4, ISO/IEC 12207:2008) xác thực rằng mỗi sản phẩm công việc phần mềm và/hoặc dịch vụ của một quy trình hay dự án phản ánh chính xác các yêu cầu được quy định. Để đảm bảo, dự án cần tạo ra một kế hoạch xác minh phù hợp với chiến lược đạt được và thể hiện việc đạt được các đòi hỏi đảm bảo.

7.11.1. Hoạt động và tác vụ liên quan

7.11.2. Hướng dẫn và khuyến nghị đảm bảo

Dự án phải thực hiện việc lập kế hoạch xác minh phù hợp với các kế hoạch liên quan tới đòi hỏi đảm bảo bao gồm: cách tiếp cận được lập kế hoạch nhằm thể hiện việc đạt được các đòi hỏi cho các đặc tính quan trọng. Cách tiếp cận này bao gồm: tiêu chí định danh xác minh và tính toán được dùng trong việc tiếp cận nhằm thể hiện việc đạt được các đòi hỏi và tiêu chí triển khai đối với cách thức các vấn đề liên quan tới đòi hỏi đảm bảo được giải quyết và phản ánh trong Nội dung thông tin đảm bảo đòi hỏi. Một khi các giá trị của độ không xác định liên quan tới việc đảm bảo được thiết lập, các kế hoạch xác minh, hoạt động và quyết định phải đảm bảo đáp ứng các yêu cầu của độ không xác định này. Ví dụ: dự án phải xem xét tới việc tham gia của độ tin cậy công cụ đối với độ không xác định của việc đạt được kết quả.

7.12. Quy trình vận hành

Quy trình vận hành (Điều 6.4.9, ISO/IEC 15288) sử dụng hệ thống để phân chia các dịch vụ của nó. Quy trình vận hành phần mềm (Điều 6.4.9, ISO/IEC 12207) vận hành sản phẩm phần mềm trong môi trường dự kiến của nó và cung cấp hỗ trợ đối với các khách hàng của sản phẩm phần mềm. Để đảm bảo, các kế hoạch cho quy trình này phải xem xét việc đạt được các đặc tính quan trọng trong suốt vòng đời hệ thống.

7.12.1. Hoạt động và tác vụ liên quan

7.12.2. Hướng dẫn và khuyến nghị đảm bảo

Dự án phải lập kế hoạch cho việc vận hành hệ thống phù hợp với các hạn chế vận hành, giả định theo cách tiếp cận nhằm thể hiện việc đạt được các đòi hỏi đảm bảo. Kế hoạch phải đảm bảo rằng các vi phạm hạn chế này được báo cáo, ghi chép, được giải quyết và bao quát việc đào tạo thông tin theo cách thức triển khai và duy trì sự tuân thủ với các hạn chế liên quan tới đòi hỏi đảm bảo. Kế hoạch phải bao gồm cách thức thay đổi cách tiếp cận nhằm thể hiện việc đạt được của các đòi hỏi và Nội dung thông tin liên quan nhằm phản ánh các thay đổi trong các điều kiện vận hành mà không được bao trùm trong các đòi hỏi.

Kế hoạch phải cung cấp cho việc đánh giá các tác động của các thay đổi trong hệ thống hay môi trường vận hành trong khả năng sử dụng liên quan tới đòi hỏi đảm bảo của hệ thống và theo tính hiệu lực của các giả định cần thiết cho việc thể hiện việc đạt được của các đòi hỏi. Kế hoạch phải cung cấp cho các kiểm tra thông thường của các bản ghi vận hành nhằm xác thực rằng không có bằng chứng mà hệ thống hoặc việc đạt được và thể hiện việc đạt được của các đòi hỏi là bị phá vỡ một cách không biết. Kế hoạch phải đảm bảo rằng các biện pháp thích hợp tồn tại để ngăn chặn các tổn thất thông tin nhạy cảm hoặc làm nguy hại nếu việc kiểm soát hệ thống bị mất hoặc được chuyển đổi.

Dự án phải triển khai các hệ thống và thủ tục báo cáo cho việc điều tra và chỉnh đốn các tai nạn liên quan tới đòi hỏi đảm bảo, ví dụ: các nỗ lực vi phạm và các vi phạm các đòi hỏi, lỗ hổng sản phẩm hoặc điểm yếu mà có thể góp phần dẫn tới các vi phạm; và các nguồn hay nguy hiểm mới tiềm ẩn dẫn tới sự vi phạm đòi hỏi/thông qua cuộc đời của hệ thống. Các bảo vệ tương ứng phải được đặt trong vị trí đối với sự tin tưởng được yêu cầu khi kết nối kế hoạch và báo cáo tai nạn.

7.13. Quy trình bảo trì

Quy trình bảo trì (Điều 6.4.10, ISO/IEC 15288) duy trì khả năng của hệ thống nhằm cung cấp một dịch vụ. Quy trình bảo trì hệ thống (Điều 6.4.10, ISO/IEC 12207) chỉ ra hỗ trợ hiệu quả kinh phí với một sản phẩm phần mềm được phân phối. Để đảm bảo, các kế hoạch của quy trình này đề cập tới việc đạt được các đặc tả quan trọng thông qua cuộc đời của hệ thống.

7.13.1. Hoạt động và tác vụ liên quan

7.13.2. Hướng dẫn và khuyến nghị đảm bảo

Dự án phải đảm bảo rằng kế hoạch bảo trì cung cấp đối với việc đánh giá tác động thông tin liên quan tới đòi hỏi đảm bảo các thay đổi được tạo ra cho hệ thống hay các phần tử hệ thống trong việc bảo trì hệ thống. Kế hoạch phải bao gồm các tài nguyên đối với việc cập nhật cách tiếp cận nhằm thể hiện việc đạt được và Nội dung thông tin liên quan được yêu cầu, bao gồm: bằng chứng mới. Kế hoạch phải bao gồm điều khoản đối với việc cập nhật được kiểm soát và ban hành của các tạo tác liên quan tới đòi hỏi đảm bảo. Kế hoạch phải bao gồm việc đánh giá của các tác động của các thay đổi của hệ thống hay môi trường vận hành trong khả năng sử dụng liên quan tới đòi hỏi đảm bảo của hệ thống. Việc đánh giá phải bao gồm việc tính toán liên tục các đặc tính quan trọng khi các thay đổi bảo trì được tạo ra.

CHÚ THÍCH 1 Tất cả các thay đổi được đề xuất phải trải qua các phân tích các tác động liên quan tới đòi hỏi. Các thay đổi được thừa nhận có một tác động về việc đạt được và thể hiện việc đạt được các đòi hỏi phải được hoàn trả đối với giai đoạn phù hợp của vòng đời và tất cả các giai đoạn tiếp sau được lặp lại đối với các thay đổi. Thông tin với các ý nghĩa liên quan tới đòi hỏi phải được phổ biến rộng rãi, rõ ràng, ngắn gọn và dễ đọc. Thông tin có thể được phổ biến theo các báo cáo hình thức đối với việc quản lý và bởi các bản tin an toàn, thông báo và việc đào tạo cho tất cả nhân viên.

CHÚ THÍCH 2 Kế hoạch bảo trì phải bao gồm các điều khoản nhằm đảm bảo các đặc tính quan trọng của các hệ thống không bị ảnh hưởng trong suốt vòng đời như một kết quả của việc thay thế, loại bỏ hoặc giảm thiếu các phần hay thành phần của hệ thống.

Kế hoạch phải có các điều khoản đối với việc thông báo chiến lược quản lý rủi ro của thông tin rủi ro liên quan tới đòi hỏi và hướng dẫn liên quan tới các thay đổi, việc giải quyết và các rủi ro liên quan tới bảo trì khác. Một đánh giá rủi ro hay phân tích các tác động liên quan tới đòi hỏi của những thay đổi này phải được thực hiện nhằm đảm bảo rằng việc đạt được các đòi hỏi, việc tiếp cận để việc đạt được các đòi hỏi và Nội dung thông tin liên quan có thể được duy trì.

CHÚ THÍCH Tất cả thay đổi sản phẩm được đề xuất, bao gồm các thay đổi theo yêu cầu, thiết kế và các thành phần liên quan tới đòi hỏi phi đảm bảo phải trải qua các phân tích tác động liên quan tới đòi hỏi đảm bảo.

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

[1] ISO/IEC 90003:2004, Software engineering - Guidelines for the application of ISO 9001:2000 to computer software

[2] ISO/IEC 15026-2:2011, System and software engineering - System and software assurance - Part 2: Assurance case

[3] Software and Systems Engineering Vocabulary (sevocab). Có sẵn tại: www.computer.org/sevocab/

[4] ISO/IEC 15289:2011, System and software engineering - Content of life cycle information products (Tài liệu)

[5] ISO/IEC 15504-1:2004, Information Technology - Process Assessment- Par 1: Concepts and vocabulary

[6] ISO/IEC 15504-2:2003, Information Technology - Process Assessment - Part 2: Performing an Assessment

[7] ISO/IEC 15504-3:2004, Information Technology - Process Assessment - Part 3: Guidance on performing a process improvement and process capability determination

[8] ISO/IEC 15504-5:2012, Information Technology - Process Assessment - Part 5: An exemplar software process assessment model

[9] ISO/IEC TR 15504-6:2008, Information Technology - Process Assessment - Part 6: An exemplar system life cycle process assessment model

[10] ISO/IEC 15504-7:2008, Information Technology - Process Assessment - Part 7: Assessment of organizational maturity

[11] ISO/IEC 15939:2007, Systems and software engineering - Measurement process

[12] ISO/IEC 16085:2006, Systems and software engineering - Life cycle processes - Risk management [13] ISO/IEC 16326:2009, System and Software engineering - Life cycle Processes - Project management [14] ISO/IEC 21827:2008, Information technology - Systems Security Engineering - Capability Maturity Model (SSE-CMM)

[15] ISO/IEC TR 24748-1:2010, Systems and software engineering - Life cycle management - Part 1: Guide for life cycle management

[16] ISO/IEC TR 24748-2:2011, Systems and software engineering - Life cycle management - Part 2: Guide for the application of ISO/IEC 15288 (System life cycle processes)

[17] ISO/IEC TR 24748-3:2011, Systems and software engineering - Life cycle management - Part 3: Guide for the application of ISO/IEC 12207 (Software life cycle processes)

[18] ISO/IEC 25000:2005, Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Guide to SquaRE

[19] ISO/IEC 25010:2011, Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models

[20] ISO/IEC 25012:2008, Software Engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Data Quality Model

[21] ISO/IEC 25020:2007, Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Measurement reference model and guide

[22] ISO/IEC 25030:2007, Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Quality requirements

[23] ISO/IEC 25040:2011, Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Evaluation process

[24] ISO/IEC 25051:200, Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Requirements for quality of Commercial Off-The-Shelf (COTS) software product and instructions for testing

[25] ISO/IEC 27001:2005, Information technology - Security techniques - Information security management systems - Requirement

[26] ISO/IEC 27002:2005, Information technology - Security techniques - Code of practice for information security management

[27] ISO/IEC 29148:2011, Systems and software engineering - Requirements engineering

MỤC LỤC

Lời nói đầu

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. Khái niệm quan trọng và sử dụng tiêu chuẩn

6. Mục đích dạng quy trình và kết quả được yêu cầu

7. Hướng dẫn và khuyến nghị đảm bảo đối với quy trình được chọn lựa

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