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

• Số hiệu: TCVN10607-4:2014
• Loại văn bản: Tiêu chuẩn Việt Nam
• Nơi ban hành: ***
• Người ký: ***
• Ngày ban hành: Năm 2014

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ận 6.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 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.

...

...

...

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.

...

...

...

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.

...

...

...

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 dự án, bao gồm các đánh giá.

6.3.1.3.1 Xác định dự án.

...

...

...

6.3.1.3.2 Lập kế hoạch dự án.

6.3.1.3.2.1 Nhà quản lý phải chuẩn bị các kế hoạch cho việc thực hiện dự án. Các kế hoạch liên quan tới việc thực hiện dự án phải bao gồm các mô tả của các hoạt động và tác vụ tương ứng và việc xác định các sản phẩm phần mềm sẽ được cung cấp. Các kế hoạch này sẽ bao gồm, nhưng không bị giới hạn bởi:

a) Lịch biểu cho việc hoàn thiện các tác vụ.

b) Đánh giá tác động.

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

d) Định danh các tác vụ.

e) Phân bổ trách nhiệm.

f) Định lượng của các rủi ro tương ứng với các tác vụ hoặc của chính quy trình.

g) Các đơn vị đảm bảo chất lượng được thực hiện trong suốt dự án.

...

...

...

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

...

...

...

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

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

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

...

...

...

1) Định nghĩa một chiến lược quản lý quyết định.

2) Xác định các trường hợp và sự cần thiết đố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.

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.1 Lập kế hoạch quyết định

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

...

...

...

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

...

...

...

7.7.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.5.3 a) Lập kế hoạch quản lý cấu hình.

1) Định nghĩa một chiến lược quản lý cấu hình.

b) Thực hiện quản lý cấu hình.

1) Duy trì thông tin về các cấu hình với một mức thích hợp của tính toàn vẹn và an ninh.

6.3.5.3.1 Lập kế hoạch quản lý cấu hình.

6.3.5.3.1.1 Dự án phải định nghĩa một chiến lược quản lý cấu hình.

...

...

...

6.3.5.3.2.1 Dự án phải duy trì thông tin về các cấu hình với một mức thích hợp của tình toàn vẹn và an ninh.

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ợ:

...

...

...

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.

...

...

...

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

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

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

6.3.6.3 a) Lập kế hoạch quản lý thông tin

1) Định nghĩa các mục thông tin được quản lý trong suốt vòng đời hệ thống dựa trên chính sách, các thỏa thuận hay quy định của tổ chức được duy trì cho một giai đoạn được định nghĩa sau này.

2) Chỉ định các thẩm quyền và trách nhiệm liên quan tới việc khởi tạo, tạo ra, thu giữ, đạt được và giảm thiểu các mục thông tin.

3) Định nghĩa quyền, nghĩa vụ và cam kết liên quan tới việc giữ, việc truyền tải và truy cập của các mục thông tin.

4) Định nghĩa nội dung, ngữ nghĩa, định dạng và phương tiện cho việc thể hiện, giữ, truyền và nhận thông tin

...

...

...

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

3) Nhận và phân phối thông tin cho các bên được chỉ định như đã yêu cầu bởi lịch biểu thỏa thuận hay các trường hợp được định nghĩa

6.3.6.3.1 Lập kế hoạch quản lý thông tin

6.3.6.3.1.1 Dự án phải định nghĩa các mục của thông tin mà được quản lý trong suốt vòng đời hệ thống, dựa trên chính sách hay quy định được tổ chức, duy trì cho một giai đoạn được định nghĩa sau này.

6.3.6.3.1.2 Dự án phải có các thẩm quyền và trách nhiệm chỉ định liên quan tới việc khởi tạo, tạo ra, thu thập, đạt được và giảm thiểu các mục thông tin.

6.3.6.3.1.3 Dự án phải định nghĩa các quyền, nghĩa vụ và cam kết liên quan tới việc giữ, truyền và truy cập các mục thông tin.

6.3.6.3.1.4 Dự án phải định nghĩa nội dung, ngữ cảnh, định dạng và phương tiện cho việc trình bày, giữ, truyền và nhận thông tin.

6.3.6.3.3.5 Dự án phải định nghĩa các hành động duy trình thông tin

6.3.6.3.2 Thực hiện quản lý thông tin

...

...

...

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.

...

...

...

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

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

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

6.4.1.3 c) Phân tích và duy trì các yêu cầu bên liên quan

1) Phân tích tập hoàn thiện của các yêu cầu được nêu ra

...

...

...

6.4.1.3.3 Đánh giá các yêu cầu. Hoạt động bao gồm tác vụ sau:

6.4.1.3.3.1 Dự án phải phân tích tập hoàn thiện của các yêu cầu được nêu ra.

6.4.1.3.4 Thỏa thuận các yêu cầu. Hoạt động này bao gồm các tác vụ sau:

6.4.1.3.4.2 Dự án phải phản hồi các yêu cầu được phân tích để các bên liên quan có thể áp dụng nhằm đảm bảo rằng các nhu cầu và các mong đợi đã được thu nhận đầy đủ và nhấn mạnh.

6.4.1.3.4.3 Dự án phải triển khai với các bên liên quan mà các yêu cầu của chúng được nhấn mạnh chính xác.

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.

...

...

...

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.

...

...

...

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

...

...

...

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

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

Phân tích yêu cầu

Phân tích yêu cầu hệ thống

Phân tích yêu cầu phần mềm

6.4.2.3 a) Định nghĩa yêu cầu hệ thống.

1) Định nghĩa ranh giới chức năng của hệ thống theo các thuật ngữ hành vi và đặc tính được cung cấp.

2) Định nghĩa mỗi chức năng mà hệ thống được yêu cầu để thực hiện.

3) Định nghĩa các hạn chế thiết lập cần thiết được cung cấp bởi các yêu cầu bên liên quan hoặc là các hạn chế giải pháp không thể tránh được.

...

...

...

5) Các yêu cầu hệ thống và chức năng đặc trưng, được biện minh bằng việc xác định các rủi ro hoặc sự nghiêm trọng của hệ thống, liên quan tới các chất lượng quan trọng, ví dụ: sức khỏe, an toàn, an ninh, sự tin cậy, tính sẵn có và khả năng hỗ trợ.

6.4.2.3.1 Quy định các yêu cầu.

6.4.2.3.1.1 Việc sử dụng cụ thể được hướng tới của hệ thống được phát triển phải được phân tích để quy định các yêu cầu hệ thống. Việc quy định các yêu cầu hệ thống phải mô tả: các chức năng và khả năng của hệ thống; các yêu cầu người dùng, tổ chức và doanh nghiệp; an toàn, an ninh, kiến trúc có yếu tố con người (công thái học), giao diện, các vận hành và các yêu cầu duy trì; các yêu cầu hạn chế thiết kế và các trình độ. Quy định các yêu cầu hệ thống phải được ghi chép lại.

7.1.2.3.1 Phân tích yêu cầu phần mềm.

7.1.2.3.1.1 Nhà triển khai phải thiết lập và ghi chép các yêu cầu phần mềm (bao gồm các quy định đặc tính chất lượng) được mô tả bên dưới:

a) Các quy định khả năng và chức năng, bao gồm: công năng, đặc tính vật lý và các điều kiện môi trường theo mục phần mềm được thực hiện.

b) Các giao diện bên ngoài đối với mục phần mềm.

c) Các yêu cầu trình độ.

d) Các quy định an toàn, liên quan tới các phương pháp vận hành và duy trì, các ảnh hưởng môi trường và tổn hại cá nhân.

...

...

...

f) Các quy định tác động con người (công thái học), liên quan tới các vận hành thủ công, các tương tác người-thiết bị, các hạn chế cá nhân và các lĩnh vực cần sự tập trung của con người, mà nhạy cảm với các sai sót cá nhân hoặc việc đào tạo.

g) Định nghĩa dữ liệu và các yêu cầu cơ sở dữ liệu.

h) Việc cài đặt và chấp nhận các yêu cầu của sản phẩm phần mềm được chuyển giao trong (các) khu vực vận hành và duy trì.

i) Các yêu cầu tài liệu người dùng.

j) Các yêu cầu vận hành và thực hiện của người dùng.

k) Các yêu cầu bảo trì của người dùng.

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.

...

...

...

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.

...

...

...

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

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

6.4.6.3 a) Lập kế hoạch xác minh

1) Định nghĩa chiến lược đối với việc xác minh các thực thể hệ thống trong suốt vòng đời.

2) Định nghĩa một kế hoạch xác minh dựa trên các yêu cầu hệ thống.

3) Các hạn chế tiềm ẩn theo các quyết định thiết kế được xác định và được kết nối.

CHÚ THÍCH Điều này bao gồm các giới hạn thực tế của tính chính xác, tính bất định, khả năng lặp được áp đặt bởi việc xác minh các hệ thống được phép, các phương thức tính toán tương ứng, nhu cầu của việc tương tác hệ thống và tính sẵn có, khả năng truy cập và liên kết nối với các hệ thống được phép.

7.2.4.3.1 Triển khai quy trình

7.2.4.3.1.1 Một định danh phải được tạo ra nếu dự án đảm bảo rằng một nỗ lực xác minh và mức độ độc lập tổ chức của nỗ lực đó là cần thiết. Các yêu cầu dự án phải được phân tích kỹ càng đối với mức rủi ro. Mức rủi ro có thể được tính toán theo cách thức sau:

...

...

...

b) Sự hết hạn và các rủi ro liên quan tới công nghệ phần mềm được sử dụng;

7.2.4.3.1.5 Dựa trên việc xác minh các tác vụ được xác định, một kế hoạch xác minh phải được phát triển và ghi chép. Kế hoạch phải chỉ ra các hoạt động vòng đời và đối tượng các sản phẩm phần mềm được xác minh, các tác vụ xác minh được yêu cầu đối với mỗi hoạt động vòng đời và sản phẩm phần mềm và các tài nguyên, trách nhiệm và lịch biểu liên quan. Kế hoạch phải chỉ ra các thủ tục cho việc xác minh chuyển tiếp các báo cáo đối với các nhà thâu nhận và các tổ chức liên quan khác.

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

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

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

...

...

...

Vận hành phần mềm

6.4.9.3 a) Chuẩn bị vận hành

1) Chuẩn bị một chiến lược vận hành

6.4.9.3.1 Chuẩn bị vận hành. Hoạt động này bao gồm những tác vụ sau:

6.4.9.3.1.1 Người vận hành phải phát triển một kế hoạch và tập các tiêu chuẩn vận hành đối với việc thực hiện các hoạt động và tác vụ của quy trình này. Kế hoạch phải được ghi chép và thực thi.

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.

...

...

...

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

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

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

Bảo trì

Bảo trì phần mềm

6.4.10 a) Lập kế hoạch bảo trì.

1) Chuẩn bị một chiến lược bảo trì.

6.4.10.3.1 Thiết lập quy trình.

...

...

...

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

...

...

...

[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

...

...

...

[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

...

...

...

[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

...

...

...

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