Tiêu chuẩn Quốc gia TCVN 10607-4:2014

Tiêu chuẩn Quốc gia TCVN 10607-4:2014 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.

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

Hoạt động của ISO/IEC 15288 Hoạt động của ISO/IEC 12207

6.1.1.3 c) Bắt đầu một thỏa thuận

1) Đàm phán một thỏa thuận với nhà cung

cấp

d) Giám sát thỏa thuận

1) Đánh giá việc thực hiện thỏa thuận

2) Cung cấp dữ liệu cần thiết bởi nhà cung

cấp và giải quyết các mục theo thời gian

6.1.1.3.4 Thỏa thuận hợp đồng

6.1.1.3.4.2 Nhà thâu nhận phải chuẩn bị và đàm phán một thỏa thuận với nhà cung cấp nhằm nêu lên các yêu cầu thu thập, bao gồm: chi phí và lịch biểu của sản phẩm hay dịch vụ phần mềm được chuyển giao Hợp đồng phải nêu lên quyền sở hữu, sử dụng, làm chủ, bảo hành và quyền sở hữu tương ứng với các sản phẩm phần mềm sẵn có có khả năng tái sử dụng

6.1.1.3.5 Giám sát thỏa thuận6.1.1.3.5.1 Nhà thâu nhận phải giám sát các hoạt động của nhà cung cấp theo Quy trình kiểm tra phần mềm và Quy trình đánh giá phần mềm Nhà thâu nhận phải hỗ trợ việc giám sát với Quy trình xác minh phần mềm và Quy trình xác nhận phần mềm khi cần thiết

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

Dạng quy trình đảm bảo hệ thống Dạng quy trình đảm bảo phần mềm

6.1.2.3 c) Bắt đầu một thỏa thuận

1) Đàm phán một thỏa thuận với nhà thâu

nhận d) Thực hiện thỏa thuận

1) Thực hiện thỏa thuận dựa trên các kế

hoạch dự án được thiết lập của nhà cung cấp

và dựa trên thỏa thuận

2) Đánh giá việc thực hiện thỏa thuận

6.1.2.3.4 Thực hiện hợp đồng

6.1.2.3.4.8 Nhà cung cấp phải giám sát và kiểm soát tiến trình và chất lượng của sản phẩm hay dịch vụ của dự án trong suốt vòng đời đã được

ký kết Nó phải là một tác vụ liên tục, lặp lại mà phải cung cấp cho:

a) Việc giám sát tiến trình của công năng kỹ thuật, chi phí và lịch biểu và việc báo cáo tình trạng dự án

b) Xác định vấn đề, ghi chép, phân tích và xử lý

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

Hoạt động của ISO/IEC 15288 Hoạt động của ISO/IEC 12207

6.3.1.3 a) Định nghĩa dự án

1) Xác định mục tiêu và hạn chế của dự án

2) Định nghĩa và duy trì một mô hình vòng đời

bao gồm các giai đoạn sử dụng các mô hình

vòng đời được định nghĩa của tổ chức

b) Lập kế hoạch các tài nguyên dự án

1) Định nghĩa và duy trì một lịch biểu dự án

dựa trên mục tiêu dự án và đánh giá công

việc

2) Định nghĩa lĩnh vực đạt được của dự án

đối với các cổng quyết định giai đoạn vòng

đời, thời gian chuyển giao và các khả tín

chính yếu theo các đầu vào hay đầu ra bên

ngoài

3) Định nghĩa chi phí dự án và lập kế hoạch

dự toán

4) Xây dựng cấu trúc của các thẩm quyền và

trách nhiệm của công việc dự án

5) Định nghĩa hạ tầng và các dịch vụ được

đòi hỏi bởi dự án

6) Lập kế hoạch thu thập tài liệu, hàng hóa và

cho phép các dịch vụ hệ thống được cung

cấp từ bên ngoài dự án

c) Lập kế hoạch quản lý chất lượng và kỹ

thuật dự án

1) Tạo ra và kết nối một dự án một kế hoạch

đối với việc quản lý kỹ thuật và thực hiện của

c) Các tài nguyên tương ứng cần thiết để thực hiện các tác vụ

i) Điều khoản về môi trường và hạ tầng

j) Định nghĩa và duy trì của một mô hình vòng đời mà bao gồm thành nhiều giai đoạn sử dụng các mô hình vòng đời được định nghĩa cho các

dự án của tổ chức

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ể

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

Hoạt động của ISO/IEC 15288 Hoạt động của ISO/IEC 12207

đối với một quyết định

3) Bao gồm các bên liên quan trong việc đưa

ra quyết định để rút ra kinh nghiệm và kiến

thức

6.3.3.3.1 Lập kế hoạch quyết định6.3.3.3.1.1 Dự án phải định nghĩa một chiến lược đưa ra quyết định

6.3.3.3.1.2 Dự án phải bao gồm các bên liên quan trong việc đưa ra quyết định để rút ra các kinh nghiệm và kiến thức

6.3.3.3.1.3 Dự án phải xác định các trường hợp và sự cần thiết đối với một quyết định.6.3.3.3.2 Phân tích quyết định

b) Phân tích thông tin quyết định.

2) Xác định các kết quả được mong đợi và

lĩnh vực thành công có thể tính toán trước

6.3.3.3.2.1 Dự án phải chọn lựa và khai báo chiến lược đưa ra quyết định đối với mỗi tình huống quyết định Dự án phải xác định các kết quả được mong đợi và lĩnh vực thành công có thể tính toán trước

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

Hoạt động của ISO/IEC 15288 Hoạt động của ISO/IEC 12207

6.3.4.3 a) Lập kế hoạch quản lý rủi ro

1) Định nghĩa các chính sách quản lý rủi ro

b) Quản lý hồ sơ rủi ro

3) Triển khai và duy trì một hồ sơ rủi ro

c) Phân tích các rủi ro

d) Xử lý các rủi ro

2) Triển khai các thay đổi xử lý rủi ro mà các

bên liên quan xác định rằng các hành động

phải được chọn để tạo ra một chấp nhận rủi

ro

e) Giám sát các rủi ro

2) Triển khai và giám sát các đơn vị đo để

đánh giá công năng của các xử lý rủi ro

6.3.4.3.1 Lập kế hoạch quản lý rủi ro

6.3.4.3.1.1 Các chính sách quản lý rủi ro mô tả các hướng dẫn mà việc quản lý rủi ro được thực hiện phải được định nghĩa

6.3.4.3.1.2 Một mô tả của Quy trình quản lý rủi ro được thiết lập phải được ghi chép

6.3.4.3.1.3 Các bên chịu trách nhiệm cho việc thực hiện quản lý rủi ro, vai trò và trách nhiệm phải được xác định

6.3.4.3.1.4 Các bên chịu trách nhiệm phải được cung cấp các tài nguyên tương ứng để thực hiện các Quy trình quản lý rủi ro

6.3.4.3.1.5 Một mô tả của quy trình của việc đánh giá và tăng cường của Quy trình quản lý rủi

ro phải được cung cấp

6.3.4.3.2 Quản lý hồ sơ rủi ro

6.3.4.3.2.1 Ngữ cảnh của Quy trình quản lý rủi ro phải được định nghĩa và ghi chép

6.3.4.3.2.2 Các ngưỡng rủi ro định nghĩa các điều kiện theo một mức rủi ro có thể được chấp nhận, phải được ghi chép

6.3.4.3.2.3 Một hồ sơ rủi ro phải được triển khai

và duy trì

6.3.4.3.2.4 Hồ sơ rủi ro liên quan phải được kết nối trực tiếp với các bên liên quan dựa trên các

nhu cầu.

6.3.4.3.3 Phân tích rủi ro6.3.4.3.3.1 Các rủi ro phải được xác định theo hạng mục được mô tả trong ngữ cảnh quản lý rủi ro

6.3.4.3.3.2 Khả năng xuất hiện và các hệ quả của mỗi rủi ro được xác định phải được đánh giá

6.3.4.3.3.3 Mỗi rủi ro phải được đánh giá chống lại các ngưỡng rủi ro của chính nó

6.3.4.3.3.4 Với mỗi rủi ro của các ngưỡng rủi ro nêu trên, các chiến lược xử lý được khuyến nghị phải được định nghĩa và ghi chép lại Các đơn vị tính chỉ ra tính hiệu quả của việc xử lý các thay đổi phải được định nghĩa và ghi chép lại

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