kỹ thuật hệ thống và phần mềm các quá trình vòng đời phần mềm

KỸ THUẬT HỆ THỐNG VÀ PHẦN MỀM – CÁC QUÁ TRÌNH VÒNG ĐỜI PHẦN MỀM Systems and software engineering - Software life cycle processes 1 Phạm vi áp dụng Tiêu chuẩn này thiết lập một khung hướ

Mục lục

1 Phạm vi áp dụng 10

2 Tài liệu viện dẫn 10

3 Thuật ngữ và định nghĩa 12

4 Sự phù hợp 21

4.1 Sử dụng dự kiến 21

4.2 Sự phù hợp hoàn toàn 21

4.3 Sự phù hợp có sửa đổi 21

5 Áp dụng Tiêu chuẩn 22

5.1 Các khái niệm chính của Tiêu chuẩn 22

5.1.1 Mối quan hệ của sản phẩm phần mềm và dịch vụ phần mềm 22

5.1.2 Mối liên hệ giữa hệ thống và phần mềm 22

5.1.3 Tổ chức và bên tham gia 23

5.1.4 Sự thừa nhận mức tổ chức và mức dự án 24

5.1.5 Sự sửa đổi 25

5.1.6 Mối quan hêê thời gian giữa các quá trình 25

5.1.7 Đánh giá, xác minh và xác nhận 25

5.1.8 Tiêu chí cho quá trình 25

5.1.9 Mô tả quá trình 26

5.1.10 Đặc tính chung của quá trình 26

5.1.11 Sự phân chia của quá trình 26

5.1.12 Các mô hình và giai đoạn vòng đời 27

5.2 Cấu trúc tiêu chuẩn 28

5.2.1 Phân loại quá trình vòng đời 28

5.2.2 Bản tóm tắt các quá trình vòng đời 30

5.2.3 Mô hình tham chiếu quá trình 34

6 Các quá trình vòng đời hệ thống 34

6.1 Quá trình thỏa thuận 34

6.1.1 Quá trình mua sản phẩm 34

6.1.2 Quá trình cung cấp 39

6.2 Các quá trình hỗ trợ dự án của tổ chức 43

6.2.1 Quá trình quản lý mô hình vòng đời 43

6.2.2 Quá trình quản lý cơ sở hạ tầng 45

6.2.3 Quá trình quản lý danh mục dự án 46

6.2.4 Quá trình quản lý nguồn nhân lực 47

6.2.5 Quá trình quản lý chất lượng 50

6.3 Quá trình dự án 51

6.3.1 Quá trình lập kế hoạch dự án 51

6.3.2 Quá trình kiểm soát và đánh giá dự án 53

6.3.3 Quá trình quản lý quyết định 54

6.3.4 Quá trình quản lý rủi ro 55

6.3.5 Quá trình quản lý cấu hình 58

6.3.6 Quá trình quản lý thông tin 60

6.3.7 Quá trình đo 62

6.4 Các quá trình kỹ thuật 63

6.4.1 Quá trình định nghĩa các yêu cầu của bên liên quan 63

6.4.2 Quá trình phân tích các yêu cầu hệ thống 66

6.4.3 Quá trình thiết kế kiến trúc hệ thống 68

6.4.4 Quá trình triển khai 69

6.4.5 Quá trình tích hợp hệ thống 70

6.4.6 Quá trình kiểm tra chất lượng hệ thống 71

6.4.7 Quá trình cài đặt phần mềm 72

6.4.8 Quá trình hỗ trợ tiếp nhận phần mềm 73

6.4.9 Quá trình vận hành phần mềm 74

6.4.10 Quá trình bảo trì phần mềm 77

6.4.11 Quá trình hủy bỏ phần mềm 80

7 Các quá trình phần mềm đặc thù 82

7.1 Các quá trình triển khai phần mềm 82

7.1.1 Quá trình triển khai phần mềm 82

7.1.2 Quá trình phân tích các yêu cầu phần mềm 84

7.1.3 Quá trình thiết kế kiến trúc phần mềm 86

7.1.4 Quá trình thiết kế chi tiết phần mềm 87

7.1.5 Quá trình xây dựng phần mềm 88

7.1.6 Quá trình tích hợp phần mềm 90

7.1.7 Quá trình kiểm tra chất lượng phần mềm 91

7.2 Các quá trình hỗ trợ phần mềm 93

7.2.1 Quá trình quản lý tài liệu hướng dẫn phần mềm 93

7.2.2 Quá trình quản lý cấu hình phần mềm 94

7.2.3 Quá trình đảm bảo chất lượng phần mềm 96

7.2.4 Quá trình xác minh phần mềm 99

7.2.5 Quá trình xác nhận phần mềm 101

7.2.6 Quá trình soát xét phần mềm 103

7.2.7 Quá trình kiểm tra phần mềm 105

7.2.8 Quá trình giải quyết vấn đề phần mềm 106

7.3 Các quá trình tái sử dụng phần mềm 108

7.3.1 Quá trình kỹ thuật miền 108

7.3.2 Quá trình quản lý tài sản tái sử dụng 110

7.3.3 Quá trình quản lý chương trình tái sử dụng 112

Phụ lục A 116

(Quy định) 116

Quá trình sửa đổi 116

A.1 Giới thiệu 116

A.2 Quá trình sửa đổi 116

A.2.1 Mục đích của quá trình sửa đổi 116

A.2.2 Kết quả quá trình sửa đổi 116

A.2.3 Các hoạt động của quá trình sửa đổi 116

Phụ lục B 118

(Quy định) 118

Mô hình tham chiếu quá trình cho các mục đích đánh giá 118

B.1 Giới thiệu 118

B.2 Sự phù hợp với tiêu chuẩn ISO/IEC 15504-2 118

B.2.1 Tổng quan 118

B.2.2 Các yêu cầu đối với các mô hình tham chiếu quá trình 118

B.2.3 Các mô tả quá trình 119

B.2.4 Các thuộc tính quá trình chung đối với việc xác định khả năng 120

B.3 Mô hình tham chiếu quá trình 121

B.3.1 Các quá trình mức độ thấp hơn quá trình mua sản phẩm 123

B.3.2 Các quá trình mức độ thấp hơn quá trình cung cấp 125

B.3.3 Các quá trình mức độ thấp hơn quá trình quản lý mô hình vòng đời 127

B.3.4 Các quá trình mức độ thấp hơn quá trình quản lý nguồn nhân lực 128

B.3.5 Các quá trình mức độ thấp hơn quá trình vận hành phần mềm 130

Phụ lục C 131

(Tham khảo) 131

Tổng quan quá trình 131

C.1 Giới thiệu 131

C.2 Định nghĩa 132

C.3 Khái niệm tổng quan quá trình 132

C.4 Tổng quan quá trình khả dụng 133

Phụ lục D 135

(Tham khảo) 135

Một số ví dụ mô tả quá trình 135

D.1 Quá trình sắp xếp trình tự tổ chức 135

D.2 Quá trình quản lý tổ chức 136

D.3 Quá trình quản lý thay đổi hợp đồng 136

Tài liệu tham khảo 139

Lời nói đầu

TCVN xxx:2013 được xây dựng trên cơ sở chấp nhâên ISO/IEC 12207:2008.TCVN xxx:2013 do Viêên Khoa học Kỹ thuâêt Bưu điêên biên soạn, Bộ Thông tin

và Truyền thông đề nghị, Tổng cục Tiêu chuẩn Đo lường Chất lượng thẩm định,

Bộ Khoa học và Công nghệ công bố

KỸ THUẬT HỆ THỐNG VÀ PHẦN MỀM – CÁC QUÁ TRÌNH VÒNG ĐỜI PHẦN MỀM

Systems and software engineering - Software life cycle processes

1 Phạm vi áp dụng

Tiêu chuẩn này thiết lập một khung hướng dẫn chung về các quá trình vòng đời phần mềm với nhữngkhái niệm được định nghĩa rõ ràng và có thể được tham chiếu trong lĩnh vực công nghệ phần mềm Tiêuchuẩn bao gồm các quá trình, các hoạt động và các nhiệm vụ được áp dụng trong suốt quá trình mua sảnphẩm phần mềm hoặc dịch vụ và trong suốt quá trình cung cấp, phát triển, vận hành, bảo trì và hủy bỏcủa các sản phẩm phần mềm Trong đó, phần mềm bao gồm cả phần phần mềm của phần sụn

Tiêu chuẩn này được áp dụng cho các đối tượng bao gồm bên mua sản phẩm hệ thống, các sản phẩmphần mềm và các dịch vụ, nhà cung cấp và các bên liên quan như: bên phát triển, bên khai thác, bên bảotrì, bên quản lý, bên quản lý đảm bảo chất lượng và người sử dụng các sản phẩm phần mềm

Các giới hạn của tiêu chuẩn này bao gồm:

• Không trình bày chi tiết các quá trình vòng đời trong giới hạn về các phương pháp hoặc các thủtục cần thiết để đáp ứng các yêu cầu và kết quả của quá trình

• Không trình bày chi tiết tài liệu hướng dẫn trong giới hạn về tên, định dạng, nội dung tường minh

và phương tiện ghi báo cáo

• Không qui định mô hình vòng đời phần mềm hoặc hệ thống, phương pháp luận triển khai, phươngpháp, mô hình hoặc kỹ thuật đặc trưng

• Không dự định gây mâu thuẫn với các chính sách, các thủ tục và các tiêu chuẩn của bất kỳ tổchức nào hoặc với các điều luật và pháp luật của bất kỳ quốc gia nào Nếu có bất kỳ mâu thuẫnnào như vậy nên được giải quyết trước khi áp dụng tiêu chuẩn này

2 Tài liệu viện dẫn

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

[1] IEEE Std 1517-1999 - IEEE Standard for Information Technology - Software Life Cycle

Processes - Reuse Processes (IEEE Std 1517-1999 – Tiêu chuẩn IEEE đối với Công nghệ

thông tin – Các quá trình quản lý vòng đời phần mềm – Các quá trình tái sử dụng).

[2] ISO/IEC 9126-1 - Software engineering - Product quality - Part 1: Quality model (ISO/IEC

9126-1– Kỹ thuật phần mềm – Chất lượng sản phẩm – Phần 1: Mô hình chất lượng)

[3] ISO 9000:2005 Quality management systems Concepts and vocabulary (ISO 9000: 2005

-Các hệ thống quản lý chất lượng – -Các khái niệm và từ vựng).

[4] ISO 9001:2000 - Quality management systems - Requirements (ISO 9001: 2000 – Các hệ

thống quản lý chất lượng – Các yêu cầu).

[5] ISO 9004:2000 - Quality management systems - Guidance for performance improvement (ISO

9004: 2000 – Các hệ thống quản lý chất lượng – Hướng dẫn cải tiến chất lượng).

[6] ISO 10007 - Quality management systems - Guidelines for configuration management (ISO

10007 – Các hệ thống quản lý chất lượng – Các hướng dẫn quản lý cấu hình).

[7] ISO 9241-11:1998 – Ergonomic requirements for office work with visual display terminals (VDTs)

– Part 11: Guidance on usability (ISO 9241-11:1998 – Các yêu cầu tối ưu yếu tố con người đối

với công viê êc văn phòng với thiết bị đầu cuối hiển thị hình ảnh (VDT) – Phần 11: Hướng dẫn khả năng sử dụng).

[8] ISO 13407:1999 - Ergonomics - Ergonomics of human-system interaction - Human-centred

design process for interactive systems (ISO 13407:1999 – Tối ưu yếu tố con người – Tối ưu

yếu tố con người trong việc tương tác giữa người và hệ thống – Quá trình thiết kế lấy con người

là trung tâm cho các hệ thống tương tác).

[9] ISO/IEC TR 9294:2005 - Information technology - Guidelines for the Management of Software

Documentation (ISO/IEC TR 9294:2005 – Công nghệ thông tin – Các hướng dẫn quản lý tài

liệu hướng dẫn phần mềm).

[10] ISO/IEC 14764:2006 - Software Engineering - Software life cycle processes - Maintenance

(ISO/IEC 14764:2006 – Kỹ thuật phần mềm – Các quá trình vòng đời phần mềm – Bảo trì).

[11] ISO/IEC TR 15271:1998 - Software Engineering - Software life cycle processes - Guide for

ISO/IEC 12207 (Software Life Cycle Processes) (ISO/IEC TR 15271:1998 – Kỹ thuật phần

mềm – Các quá trình vòng đời phần mềm – Hướng dẫn tiêu chuẩn ISO/IEC 12207 (Các quá trình vòng đời phần mềm)).

[12] ISO/IEC 15288 - Systems Engineering - System life cycle processes (ISO/IEC 15288 – Kỹ

thuật phần mềm – Các quá trình vòng đời hệ thống).

[13] ISO/IEC 15289:2006 - Systems and Software Engineering - Content of systems and software

life cycle process information products (Documentation) (ISO/IEC 15289:2006 – Kỹ thuật hệ

thống và phần mềm – Nội dung tài liệu quá trình vòng đời phần mềm và hệ thống (Tài liệu hướng dẫn)).

[14] ISO/IEC 15504: (all parts) - Information Technology - Process Assessment (ISO/IEC 15504: (tất

cả các phần) – Công nghệ thông tin – Đánh giá quá trình).

[15] ISO/IEC 15939:2007 - Software and System Engineering - Measurement (ISO/IEC 15939:2007

– Kỹ thuật hệ thống và phần mềm – Phép đo).

[16] ISO/IEC 16085:2006 - System and Software Engineering - Life Cycle Management - Risk

management (ISO/IEC 16085:2006 – Kỹ thuật hệ thống và phần mềm – Quản lý vòng đời –

Quản lý rủi ro).

[17] ISO PAS 18152:2003 - A specification for the process assessment of human-system issues

(ISO PAS 18152:2003 – Đặc tả kỹ thuâ êt đối với việc đánh giá quá trình về các vấn đề giữa người và hệ thống).

[18] ISO/TR 18529:2000 - Ergonomics - Ergonomics of human-system interaction - Human-centred

lifecycle process descriptions (ISO/TR 18529:2000 - Tối ưu yếu tố con người – Tối ưu yếu tố

con người trong việc tương tác giữa người và hệ thống – Các mô tả quá trình vòng đời lấy con người là trung tâm).

[19] ISO/IEC TR 20000:2005 (multi-part) - Information technology - Service Management (ISO/IEC

TR 20000:2005 (nhiều phần) – Công nghệ thông tin – Quản lý dịch vụ)

[20] ISO/IEC 24774:2007 - System and Software Engineering - Life Cycle Management - Guidelines

for process definition (ISO/IEC 24774:2007 – Kỹ thuật hệ thống và phần mềm – Quản lý vòng

đời – Các hướng dẫn định nghĩa quá trình).

[21] ISO/IEC 25030:2007, Software Engineering — Software product Quality Requirements and

Evaluation (SQuaRE) — Quality Requirements (ISO/IEC 25030:2007 – Kỹ thuật phần mềm –

Đánh giá và các yêu cầu chất lượng sản phẩm phần mềm – Các yêu cầu chất lượng).

[22] ISO/IEC 25062 - Software Engineering - Software product Quality Requirements and Evaluation

(SQuaRE) - Common Industry Format (CIF) for usability test reports (ISO/IEC 25062 – Kỹ thuật

phần mềm – Các yêu cầu và đánh giá chất lượng sản phẩm phần mềm – Định dạng chung cho các báo cáo kiểm tra tính khả dụng).

[23] ISO/IEC 90003:2004 - Software Engineering - Guidelines for the application of ISO 9001:2000

to computer software (ISO/IEC 90003:2004 – Kỹ thuật phần mềm – Các hướng dẫn áp dụng

tiêu chuẩn ISO 9001:2000 vào phần mềm máy tính).

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

Tiêu chuẩn này sử dụng các thuật ngữ và định nghĩa sau:

3.1

Bên mua sản phẩm (acquirer)

Tổ chức mua, nhận sản phẩm hay dịch vụ phần mềm từ nhà cung cấp

CHÚ THÍCH: Bên mua sản phẩm có thể là: người mua, khách hàng, chủ sở hữu, người sử dụng.

3.2

Bên phát triển (developer)

Tổ chức thực hiêên các hoạt động phát triển (bao gồm cả phân tích yêu cầu, thiết kế và kiểm chuẩn)trong quá trình vòng đời phần mềm

CHÚ THÍCH: Trong tiêu chuẩn này, thuật ngữ bên phát triển và bên triển khai là đồng nghĩa.

3.3

Bên triển khai (implementer)

Tổ chức thực hiện các nhiệm vụ thực thi

CHÚ THÍCH: Trong tiêu chuẩn này, thuật ngữ bên phát triển và bên triển khai là đồng nghĩa.

3.4

Bên bảo trì (maintainer)

Tổ chức thực hiện các hoạt động bảo trì

Bên tham gia (party)

Tổ chức tham gia trong một hợp đồng

CHÚ THÍCH: Trong tiêu chuẩn này, bên tham gia thỏa thuận được gọi là bên mua sản phẩm và nhà cung cấp sản phẩm.

3.7

Bên liên quan (stakeholder)

Cá nhân hoặc tổ chức có quyền, cổ phần, yêu cầu hoặc lợi ích trong một hệ thống hoặc trong phạm vithuộc các đặc tính của hệ thống đó đáp ứng mong muốn và nhu cầu của cá nhân hoặc tổ chức đó

3.8

Chất lượng (qualification)

Quá trình minh chứng một thực thể có khả năng đáp ứng các yêu cầu cụ thể hay không

3.9

Dự án (project)

Sự nỗ lực với tiêu chí đầu vào và đầu ra xác định được đảm bảo để tạo ra một sản phẩm hoặc dịch vụphù hợp với các yêu cầu và tài nguyên xác định

CHÚ THÍCH 1: Theo tiêu chuẩn ISO 9000:2005.

CHÚ THÍCH 2: Một dự án có thể được xem xét như một quá trình đơn nhất bao gồm các hoạt động kiểm soát và phối hợp; có thể bao gồm các hoạt động từ các quá trình dự án và các quá trình kỹ thuật được định nghĩa trong tiêu chuẩn này.

3.10

Danh mục dự án (project portfolio)

Tập hợp các dự án giải quyết các mục tiêu chiến lược của môêt tổ chức

3.11

Dịch vụ (service)

Thực thi các hoạt động, công việc hoặc các nhiệm vụ liên quan đến môêt sản phẩm

3.12

Đảm bảo chất lượng (quality assurance)

Tất cả các hoạt động có hệ thống và có kế hoạch được triển khai trong hệ thống chất lượng đồng thờiđược kiểm chứng khi cần thiết để cung cấp sự tin cậy tương xứng sao cho một thực thể sẽ đáp ứngcác yêu cầu về chất lượng

CHÚ THÍCH 1: Có cả các mục đích trong và ngoài để đảm bảo chất lượng:

Đảm bảo chất lượng trong: trong một cơ cấu tổ chức, đảm bảo chất lượng cung cấp sự tin cậy để quản lý;

Đảm bảo chất lượng ngoài: trong các tình huống hợp đồng, đảm bảo chất lượng cung cấp sự tin cậy cho khách hàng hoặc các đối tượng khác.

CHÚ THÍCH 2: Một số hoạt động kiểm soát chất lượng và đảm bảo chất lượng được tương quan với nhau.

CHÚ THÍCH 3: Trừ khi các yêu cầu về chất lượng phản ánh hoàn toàn nhu cầu của người sử dụng, đảm bảo chất lượng có thể không cung cấp sự tin cậy tương xứng.

3.13

Đơn vị phần mềm (software unit)

Một đoạn mã được biên dịch riêng biệt

3.14

Giới hạn cơ bản (baseline)

Đặc tính kỹ thuật hoặc sản phẩm đã được chính thức xem xét và đồng ý mà sau đó được xem như cơ

sở cho phát triển sau này và có thể chỉ được thay đổi thông qua các thủ tục điều khiển thay đổi chínhthức

Giai đoạn (stage)

Chu kỳ vòng đời của một thực thể liên quan đến trạng thái thực tế hay mô tả của thực thể đó

CHÚ THÍCH 1: Khi được sử dụng trong tiêu chuẩn này, các giai đoạn liên quan đến các cột mốc đạt được và các tiến trình chính trong suốt vòng đời của thực thể.

CHÚ THÍCH 2: Các giai đoạn có thể được chồng lấn lên nhau.

Hêê thống phụ trợ (enabling system)

Hệ thống hỗ trợ hệ thống chính trong suốt các giai đoạn vòng đời, nhưng không nhất thiết phải đónggóp trực tiếp đến chức năng của hệ thống đó trong quá trình hoạt động

CHÚ THÍCH 1: Ví dụ, khi hệ thống chính tham gia vào giai đoạn sản xuất, một hệ thống cho phép sản xuất được yêu cầu CHÚ THÍCH 2: Mỗi hệ thống cho phép có vòng đời riêng Tiêu chuẩn này có thể áp dụng cho mỗi hệ thống cho phép khi hệ thống đó có khả năng được coi là một hệ thống chính

3.20

Hệ thống (system)

Tổng hợp các phần tử tương tác được tổ chức để đạt được một hoặc nhiều mục tiêu xác định

CHÚ THÍCH 1: Một hệ thống có thể được xem xét như một sản phẩm hoặc như các dịch vụ cung cấp.

CHÚ THÍCH 2: Trong thực tế, việc giải thích ý nghĩa một hệ thống thường được làm rõ bằng cách sử dụng một danh từ kết hợp, ví dụ: hệ thống máy bay Ngoài ra, từ “hệ thống” có thể được thay thế đơn giản bằng một từ đồng nghĩa phụ thuộc vào ngữ cảnh, ví dụ: máy bay, mặc dù điều này sau đó làm khó hiểu phối cảnh nguồn gốc hệ thống.

3.21

Kiểm tra (audit)

Sự đánh giá đôêc lâêp các quá trình và sản phẩm phần mềm được người có thẩm quyền thực hiêên đểđánh giá tuân thủ theo các yêu cầu

3.22

Khách hàng (customer)

Tổ chức hay cá nhân thu nhận sản phẩm hoặc dịch vụ phần mềm

CHÚ THÍCH 1: Khách hàng có thể nằm trong hoặc ngoài một tổ chức.

CHÚ THÍCH 2: Được điều chỉnh từ tiêu chuẩn ISO 9000:2005.

CHÚ THÍCH 3: Một số thuật ngữ khác thường sử dụng cho khách hàng như bên mua sản phẩm, người mua và người tiêu dùng.

3.23

Kết quả quá trình (process outcome)

Kết quả quan sát từ viêêc đạt được thành công của mục đích quá trình

CHÚ THÍCH: Báo cáo kết quả mô tả một trong những điều sau đây:

Đưa ra một giả thiết;

Một thay đổi quan trọng về trạng thái;

Đáp ứng các ràng buộc cụ thể, như các yêu cầu, các mục đích…

3.24

Kiểm tra chất lượng (qualification testing)

Viêêc kiểm tra được bên phát triển tiến hành và được bên mua sản phẩm chứng kiến (khi thấy thíchhợp) để chứng minh một sản phẩm phần mềm đáp ứng được các đặc điểm kỹ thuật và sẵn sàng sửdụng trong môi trường mục tiêu hoăêc tích hợp với hệ thống chứa sản phẩm phần mềm đó

3.25

Khả năng kiểm tra (test ability)

Phạm vi một bài kiểm tra khả thi và khách quan có thể được thiết kế để định nghĩa xem một yêu cầu cóđược đáp ứng hay không

Khung các quá trình và các hoạt động liên quan tới vòng đời có thể được tổ chức dưới dạng các giaiđoạn, cũng như đóng vai trò như một sự tham chiếu chung cho viêêc hiểu và trao đổi thông tin.

3.28

Mục đích quá trình (process purpose)

Mục tiêu mức cao của viêêc thực hiêên quá trình và kết quả có thể đạt được của viêêc thực thi hiêêu quảmôêt quá trình

CHÚ THÍCH: Viêêc thực thi môêt quá trình nên cung cấp các lợi ích rõ ràng cho các bên liên quan.

3.29

Ngừng sử dụng (retirement)

Hủy bỏ việc hỗ trợ chủ động bởi tổ chức bảo trì và vận hành, thay thế một phần hoặc toàn bộ bằng một

hệ thống mới hoặc cài đặt nâng cấp hệ thống

3.30

Nhà cung cấp (supplier)

Tổ chức hoặc cá nhân tham gia vào hợp đồng với bên mua sản phẩm để cung cấp sản phẩm phầnmềm hoặc dịch vụ phần mềm

CHÚ THÍCH 1: Nhà cung cấp có thể là nhà thầu, nhà sản xuất, người bán hoặc người phân phối.

CHÚ THÍCH 2: Đôi khi bên mua sản phẩm và nhà cung cấp là bộ phận của cùng một tổ chức.

Cá nhân hoặc nhóm người sử dụng hêê thống trong suốt thời gian sử dụng một hệ thống

CHÚ THÍCH: Vai trò của người sử dụng và vai trò của bên vận hành có thể được trao một cách đồng thời hoặc tuần tự trong cùng một cá nhân hoặc tổ chức.

3.33

Phương tiêên (facility)

Các phương tiện vật lý hoặc thiết bị để tạo điều kiêên thuâên lợi cho viêêc thực hiện một hoạt động, ví dụnhư các tòa nhà, các dụng cụ và các công cụ

3.34

Phần sụn (firmware)

Tổ hợp của thiết bị phần cứng và các lệnh máy tính hoặc dữ liệu máy tính được nạp như phần mềmchỉ đọc trong thiết bị phần cứng.

CHÚ THÍCH: Phần mềm không dễ dàng được sửa đổi dưới sự điều khiển của chương trình

Phần tử hêê thống (system element)

Phần tử của một tâêp các thành phần cấu thành nên một hệ thống

CHÚ THÍCH: Thành phần hệ thống là một phần rời rạc của một hệ thống có thể được triển khai để đáp ứng các yêu cầu cụ thể Một thành phần hệ thống có thể là phần cứng, phần mềm, dữ liệu, con người, quá trình (ví dụ: các quá trình để cung cấp dịch vụ tới người sử dụng), các thủ tục (ví dụ: các tài liệu hướng dẫn bên vận hành), các cơ sở, các tài liệu và các thực thể tự nhiên (ví dụ: nước, sinh vật, khoáng chất) hoặc bất kỳ sự kết hợp nào.

3.37

Phạm vi kiểm tra (test coverage)

Phạm vi các trường hợp kiểm tra thực hiêên kiểm tra các yêu cầu cho hệ thống phần mềm hoặc sảnphẩm phần mềm

Sự thỏa thuận (agreement)

Sự thừa nhận lẫn nhau giữa các điều khoản và các điều kiện mà theo đó một mối quan hệ công việcđược tiến hành

3.41

Sự đánh giá (evaluation)

Sự xác định có hệ thống môêt phạm vi mà trong đó một thực thể đáp ứng các tiêu chí xác định.

Sẵn sàng phổ biến và thương mại hóa (off-the-shelf)

Sản phẩm đã được phát triển và sẵn sàng thương mại hóa

3.45

Thành phần không thể chuyển giao (non-deliverable item)

Sản phẩm phần mềm hay phần cứng không được yêu cầu để chuyển giao theo hợp đồng nhưng cóthể được sử dụng trong sự phát triển của sản phẩm phần mềm

3.46

Thành phần cấu hình (configuration item)

Thực thể trong cấu hình thỏa mãn chức năng sử dụng cuối và có thể được định nghĩa duy nhất tạiđiểm tham chiếu cho trước

3.47

Tổ chức (organization)

Cá nhân hoặc một nhóm cá nhân và các phương tiêên với sự sắp xếp về trách nhiệm, thẩm quyền vàmối quan hệ

CHÚ THÍCH 1: Được điều chỉnh từ tiêu chuẩn ISO 9000:2005.

CHÚ THÍCH 2: Cá nhân được tổ chức hóa cho một số mục đích cụ thể, ví dụ: một hiệp hội, công đoàn, tập đoàn hoặc một xã hội là một tổ chức.

CHÚ THÍCH 3: Một phần định nghĩa của một tổ chức (ngay cả khi tối thiểu như một cá nhân duy nhất) hoặc một nhóm định nghĩa của các tổ chức có thể được coi như một tổ chức nếu tổ chức đó có trách nhiệm, thẩm quyền và mối quan hệ.

CHÚ THÍCH 4: Môêt dạng của thực thể có tổ chức thường được gọi là một doanh nghiệp, nên các khía cạnh có tổ chức trong tiêu chuẩn này phải áp dụng tốt đối với một doanh nghiệp.

3.48

Tài nguyên (resource)

Tài sản được sử dụng hoặc tiêu thụ trong thời gian thực hiện của một quá trình

Tường trình công việc (statement of work)

Tài liệu được bên mua sản phẩm sử dụng như các phương tiện để mô tả và chỉ rõ các nhiệm vụ đượcthực hiêên theo hợp đồng

3.52

Vòng đời (life cycle)

Quá trình phát triển của hệ thống, sản phẩm, dịch vụ, dự án hoặc thực thể nhân tạo nào đó từ lúc hìnhthành khái niêêm đến lúc ngừng sử dụng

3.55

Yêu cầu chất lượng (qualification requirement)

Tâêp các tiêu chí hoặc các điều kiện phải được đáp ứng để nói rõ môêt sản phẩm phần mềm là tuân thủcác đặc tính kỹ thuật của nó và sẵn sàng để sử dụng trong môi trường mục tiêu hoăêc tích hợp với hệthống chứa nó

3.56

Yêu cầu đề xuất (request for proposal)

Hồ sơ mời thầu (tender)

Tài liệu được bên mua sản phẩm sử dụng như một phương tiện thông báo dự kiến tới các nhà thầutiềm năng để mua một sản phẩm phần mềm, dịch vụ phần mềm hoặc hệ thống cụ thể

4 Sự phù hợp

4.1 Sử dụng dự kiến

Các yêu cầu trong tiêu chuẩn này được bao gồm trong các điều 6 và 7 và phụ lục A Tiêu chuẩn nàycung cấp các yêu cầu đối với một số quá trình phù hợp cho việc sử dụng trong suốt vòng đời của mộtsản phẩm hoặc dịch vụ phần mềm Các tổ chức hoặc các dự án cụ thể có thể không cần thiết phải sửdụng tất cả các quá trình được cung cấp trong tiêu chuẩn này Do đó, viêêc triển khai tiêu chuẩn nàythường liên quan đến viêêc lựa chọn một tâêp hợp các quá trình phù hợp với dự án hoặc tổ chức đó Cóhai cách triển khai có thể được yêu cầu để phù hợp với các điều khoản của tiêu chuẩn này Bất kỳ yêucầu sự phù hợp nào được trích dẫn theo một trong hai hình thức dưới đây

4.2 Sự phù hợp hoàn toàn

Một yêu cầu phù hợp hoàn toàn kê khai môêt tâêp các quá trình mà sự phù hợp được yêu cầu Sự phùhợp hoàn toàn đạt được bằng cách chứng minh rằng tất cả các yêu cầu của tâêp các quá trình kê khai

đã được đáp ứng khi sử dụng kết quả làm bằng chứng

4.3 Sự phù hợp có sửa đổi

Khi tiêu chuẩn này được sử dụng làm cơ sở để thiết lập một tâêp các quá trình không đánh giá cho sựphù hợp hoàn toàn thì các điều khoản của tiêu chuẩn này được lựa chọn hoặc chỉnh sửa phù hợp vớiquá trình sửa đổi bắt buộc trong phụ lục A Khi sự phù hợp có sửa đổi được yêu cầu, văn bản sửa đổiđược công bố Sự phù hợp có sửa đổi đạt được bằng cách chứng minh rằng khi được sửa đổi, cácyêu cầu đối với quá trình đó được đáp ứng

CHÚ THÍCH 1: Khi tiêu chuẩn này được sử dụng để giúp triển khai thỏa thuận giữa bên mua sản phẩm và nhà cung cấp, các điều của tiêu chuẩn này có thể được lựa chọn để tích hợp vào trong thỏa thuận có hoặc không có sửa đổi Trong trường hợp này, bên mua sản phẩm và nhà cung cấp nên yêu cầu sự tuân thủ thỏa thuận hơn là yêu cầu phù hợp với tiêu chuẩn này CHÚ THÍCH 2: Bất kỳ tổ chức nào (như nhà nước, hiệp hội công nghiệp, công ty) áp dụng tiêu chuẩn này như một điều kiện thương mại nên chỉ rõ, phổ biến một tâêp tối thiểu các quá trình, các hoạt động và các nhiệm vụ được yêu cầu mà tạo nên sự phù hợp của nhà cung cấp với tiêu chuẩn này.

5 Áp dụng Tiêu chuẩn

Điều này giới thiệu tổng quan quá trình vòng đời phần mềm có thể được dùng để mua, cung cấp, pháttriển, vận hành, bảo trì, hủy bỏ các sản phẩm phần mềm và các dịch vụ phần mềm Mục tiêu nhằmcung cấp một lộ trình cho người sử dụng tiêu chuẩn này để họ có thể tự định hướng và áp dụng mộtcách đúng đắn

5.1 Các khái niệm chính của Tiêu chuẩn

Mục này giới thiệu các khái niệm chính hữu ích trong việc đọc hiểu và áp dụng Tiêu chuẩn Trong mộtvài trường hợp, các từ thường dùng được sử dụng theo một phương thức đặc biệt trong tiêu chuẩnnày Mục này cũng sẽ mô tả các cách sử dụng đặc biệt đó Chi tiết hơn về các khái niệm này có thể tìmthấy trong tiêu chuẩn ISO/IEC TR 15271

CHÚ THÍCH: Bản báo cáo kỹ thuật được cập nhật tiếp theo (tiêu chuẩn ISO/IEC TR 24748) cũng sẽ được cung cấp chi tiết hơn.

5.1.1 Mối quan hệ của sản phẩm phần mềm và dịch vụ phần mềm

Nhìn chung, tiêu chuẩn này áp dụng cho cả sản phẩm phần mềm và dịch vụ phần mềm Các điềukhoản của các quá trình cụ thể đưa ra khả năng áp dụng của chúng

CHÚ THÍCH: Tiêu chuẩn ISO/IEC 20000 cung cấp các quá trình, các yêu cầu và hướng dẫn tới các nhà cung cấp dịch vụ đối với việc phân phối các dịch vụ được quản lý.

5.1.2 Mối liên hệ giữa hệ thống và phần mềm

Tiêu chuẩn này thiết lập một liên kết bền vững giữa hệ thống và phần mềm của hệ thống Liên kết dựatrên các nguyên tắc chung của các hệ thống kỹ thuật Phần mềm được coi như một phần tích hợp của

hệ thống tổng thể và thực hiện các chức năng nhất định trong hệ thống đó Điều này được thực hiêênbằng cách tách yêu cầu phần mềm khỏi yêu cầu thiết kế và yêu cầu hệ thống, từ đó tạo ra phần mềm

và tích hợp phần mềm đó vào trong hệ thống Đó là tiền đề cơ bản của tiêu chuẩn này khi mà phầnmềm luôn luôn tồn tại trong ngữ cảnh của một hệ thống, ngay cả khi hệ thống bao gồm duy nhất bộ xử

lý có phần mềm được thực thi Do đó, một sản phẩm phần mềm hoặc một dịch vụ phần mềm luônđược coi như một thành phần trong một hệ thống Ví dụ, tiêu chuẩn làm rõ sự khác biệt giữa phân tíchyêu cầu hệ thống và phân tích yêu cầu phần mềm, bởi vì trong trường hợp tổng quát, việc thiết kế cấutrúc hệ thống sẽ sắp xếp các yêu cầu hệ thống vào các hạng mục khác nhau của hệ thống, trong khiviệc phân tích yêu cầu phần mềm sẽ nhận được các yêu cầu phần mềm từ các yêu cầu hệ thống đểsắp xếp vào từng hạng mục thành phần phần mềm Tất nhiên, trong một số trường hợp, hạng mụckhông phải phần mềm của hệ thống có thể coi là số ít nên có thể không cần thiết thực hiện phân tíchphần mềm và hệ thống nhất định

Tiêu chuẩn này có mối liên hệ mật thiết với tiêu chuẩn ISO/IEC 15288:2008 và có thể được sử dụng

kết hợp chung Trong nhiều trường hợp, các quá trình của tiêu chuẩn này tương ứng trực tiếp với cácquá trình của tiêu chuẩn ISO/IEC 15288 nhưng với một số cụ thể hóa đối với các sản phẩm phần mềm

và các dịch vụ Một ví dụ cần lưu ý là quá trình thực hiện phần mềm của tiêu chuẩn này là một cụ thểhóa (một cụ thể hóa chi tiết) của quá trình triển khai trong tiêu chuẩn ISO/IEC 15288.

Trong trường hợp hệ thống có thành phần không phải phần mềm có tính chất quan trọng, tổ chức cóthể áp dụng tiêu chuẩn ISO/IEC 15288 để cung cấp các quá trình vòng đời thích hợp Đối với mỗithành phần phần mềm của hệ thống, tổ chức phải áp dụng quá trình triển khai phần mềm của tiêuchuẩn này để tạo ra phần tử phần mềm

Trong trường hợp rất nhỏ là các phần không phải phần mềm của hệ thống, tổ chức có thể áp dụng tiêuchuẩn này mà không cần tham chiếu với tiêu chuẩn ISO/IEC 15288 Tiêu chuẩn này bao gồm quá trình

bổ sung ở mức hệ thống (dù đã cụ thể hóa đối với các nhu cầu phần mềm) để cung cấp ngữ cảnh hệthống thích hợp đối với phần mềm

Khi áp dụng tiêu chuẩn này kết hợp với tiêu chuẩn ISO/IEC 15288, một phần nhỏ của sự không phùhợp trong thuật ngữ cũng phải được xem xét Tiêu chuẩn ISO/IEC 15288 phân tách một hệ thốngthành một tâêp các “thành phần” hệ thống Một số trong các thành phần đó có thể được định nghĩa làcác sản phẩm phần mềm thì phải được triển khai bằng cách sử dụng tiêu chuẩn này Tiêu chuẩn này

sử dụng thuật ngữ “thành phần” để tham chiếu tới thành phần chính của hệ thống Một cách ngắn gọn,tiêu chuẩn này sử dụng thuật ngữ “thành phần”, trong khi tiêu chuẩn ISO/IEC 15288 phải sử dụngthuật ngữ “thành phần phần mềm”

Một số thành phần có thể được ấn định như đối tượng phụ thuôêc vào quản lý cấu hình; chúng đượcgọi là “thành phần cấu hình” Quá trình thiết kế kiến trúc phần mềm chuyển đổi các thành phần thành

“các phần tử” và quá trình thiết kế phần mềm chi tiết tinh chỉnh các phần tử thành “các đơn vị”

5.1.3 Tổ chức và bên tham gia

Trong tiêu chuẩn này, thuật ngữ “tổ chức” và “bên tham gia” được liên hệ chặt chẽ với nhau Một tổchức là môêt tâêp các thành viên có thẩm quyền và trách nhiệm xác định, được tổ chức cho một số mụcđích cụ thể, ví dụ: một hiệp hội, công đoàn, tập đoàn hoặc xã hội Khi một tổ chức, tổng thể hoặc mộtphần, tham gia vào một hợp đồng, thì tổ chức đó là một bên tham gia Bên tham gia có thể là từ cùngmột tổ chức hoặc từ các tổ chức riêng biệt Một cá nhân là một ví dụ của tổ chức, nếu cá nhân đóđược giao các trách nhiệm và thẩm quyền

Tên của tổ chức hoặc bên tham gia thường xuất phát từ quá trình mà tổ chức hoặc bên tham gia đóchịu trách nhiệm Ví dụ, tổ chức hoặc bên tham gia được gọi là bên mua sản phẩm khi thực hiện quátrình mua sản phẩm Do đó, khi các thuật ngữ sau đây được sử dụng trong tiêu chuẩn này, chúngkhông mang ý nghĩa chung, thay vào đó, được tham chiếu để tổ chức hoặc bên tham gia chịu tráchnhiệm cho việc thực hiện quá trình với một tên tương tự, ví dụ: bên mua sản phẩm, nhà cung cấp, bêntriển khai, bên bảo trì hoặc bên vận hành

Một vài thuật ngữ khác được áp dụng đối với các tổ chức trong tiêu chuẩn này: “người sử dụng” là tổchức hưởng lợi từ việc sử dụng sản phẩm phần mềm hoặc dịch vụ; “khách hàng” đề câêp đến người sửdụng hay bên mua sản phẩm; “bên liên quan” đề câêp tới tổ chức có lợi ích trong thành công của dự án

Quá trình và tổ chức (hoặc bên tham gia) chỉ được liên quan duy nhất về mặt chức năng Tiêu chuẩnnày không bắt buộc hoặc mặc định một cấu trúc dành cho một tổ chức (hoặc một bên tham gia).

Các quá trình trong tiêu chuẩn này tạo thành một tâêp bao hàm toàn diện để phục vụ các tổ chức khácnhau Tùy thuộc vào mục đích kinh doanh hay chiến lược mua sản phẩm, một tổ chức, dù lớn hay nhỏ,

có thể lựa chọn một tâêp thích hợp các quá trình (có các hoạt động và các nhiệm vụ kết hợp) để đápứng mục đích đó Một tổ chức có thể thực hiêên một hoặc nhiều hơn một quá trình Dưới hình thức mộtbản hợp đồng hoặc dưới sự áp dụng tiêu chuẩn này, một bên tham gia xác định không nên thực hiêên

cả quá trình mua sản phẩm và quá trình cung cấp sản phẩm, nhưng có thể thực hiêên các quá trìnhkhác Một quá trình có thể được một tổ chức hoặc nhiều hơn một tổ chức thực hiêên Một ví dụ của mộtquá trình được thực hiêên bởi nhiều hơn một tổ chức là quá trình soát xét phần mềm

Tiêu chuẩn này dự định được hai hoặc nhiều tổ chức áp dụng bên trong hoăêc bên ngoài một tổ chức.Khi áp dụng bên trong một tổ chức, hai bên tham gia thỏa thuận thường thực hiêên theo các điều khoảnthỏa thuận, các điều khoản thỏa thuâên này có thể thay đổi dưới các điều kiêên khác nhau Khi áp dụngbên ngoài một tổ chức, hai bên tham gia thỏa thuận thường thực hiêên theo các điều khoản trong hợpđồng Để thuận tiện cho việc áp dụng tiêu chuẩn này hoặc bên trong hoặc bằng hợp đồng, các nhiệm

vụ được mô tả theo ngôn ngữ hợp đồng Khi áp dụng bên trong, ngôn ngữ hợp đồng phải được hiểunhư một quy tắc tự áp đặt

Với mục đích của tiêu chuẩn này, bất kỳ dự án nào cũng được giả thiết là được tiến hành trong ngữcảnh của một tổ chức Điều này là quan trọng bởi vì một dự án phần mềm phụ thuộc trên kết quả khácnhau được đưa ra bởi các quá trình thương mại của tổ chức, ví dụ, người lao động để bố trí nhân viêncho dự án và cơ sở vâêt chất để cung cấp địa điểm cho dự án Với mục đích như vậy, tiêu chuẩn nàycung cấp một tâêp các quá trình “hỗ trợ dự án của tổ chức” Các quá trình này không được thừa nhận làđầy đủ để vận hành một công việc, cũng không phải là quá trình dự án riêng biêêt bất kỳ được thừanhận để được xác định hoàn toàn Thay vì được xem xét như một tập hợp, các quá trình này được dựđịnh để xác định một tâêp tối thiểu của các phần phụ thuộc mà trong đó dự án thuôêc vào một tổ chức

5.1.4 Sự thừa nhận mức tổ chức và mức dự án

Các doanh nghiệp phần mềm hiện đại đang cố gắng phát triển một tâêp thô các quá trình vòng đời phầnmềm được áp dụng nhiều lần vào các dự án phần mềm của doanh nghiệp đó Do đó, tiêu chuẩn nàyđược dự định giúp ích cho sự thừa nhận ở mức tổ chức hoặc mức dự án Tổ chức phải thừa nhận tiêuchuẩn này và bổ sung thêm các thủ tục, bài thực hành, công cụ và chính sách thích hợp Dự án phầnmềm của tổ chức phải tuân thủ các quá trình của tổ chức chứ không phải tuân thủ trực tiếp tiêu chuẩnnày

Trong một số trường hợp, dự án có thể được tổ chức thực thi mà không có một tâêp các quá trình phùhợp được thừa nhận ở mức tổ chức Dự án như vậy có thể áp dụng các điều khoản của tiêu chuẩnnày một cách trực tiếp tới dự án đó

5.1.6 Mối quan hêê thời gian giữa các quá trình

Trong tiêu chuẩn này, quá trình với các hoạt động và nhiệm vụ của quá trình đó được sắp xếp theotrình tự phù hợp cho viêêc mô tả Tuần tự vị trí này không quy định hay bắt buộc theo bất kỳ trình tự phụthuộc thời gian nào Trong trường hợp thiếu sự thống nhất về hoăêc sử dụng tuần tự phụ thuôêc thờigian toàn cầu, người sử dụng tiêu chuẩn này có thể lựa chọn và sắp đặt các quá trình, hoạt động vànhiệm vụ theo cách thích hợp và hiệu quả Tiêu chuẩn này khuyến khích viêêc lặp đi lặp lại giữa cáchoạt động và đệ quy bên trong một hoạt động để bù lại các tác động từ bất kỳ trình tự mặc định củacác hoạt động và các nhiệm vụ Các bên tham gia của tiêu chuẩn này chịu trách nhiệm lựa chọn một

mô hình vòng đời cho dự án và ánh xạ các quá trình, hoạt động và nhiệm vụ vào mô hình đó

5.1.7 Đánh giá, xác minh và xác nhận

Các tổ chức tham gia vào bất kỳ quá trình vòng đời sản phẩm phần mềm nào, phải tiến hành đánh giáđối với các sản phẩm đó Quá trình xác minh phần mềm và xác nhận phần mềm cung cấp cơ hội choviêêc đánh giá bổ sung Các quá trình này được bên mua sản phẩm, nhà cung cấp hoặc một bên thamgia độc lập tiến hành thực hiện để xác minh và xác nhận tính hợp lệ của các sản phẩm ở mức độ khácnhau tùy thuộc dự án Các đánh giá này không sao chép hay thay thế các đánh giá khác, nhưng là sự

bổ sung cho các đánh giá khác Cơ hội bổ sung cho viêêc đánh giá được cung cấp bởi quá trình soátxét phần mềm, kiểm chứng phần mềm, đánh giá chất lượng phần mềm và quản lý mô hình vòng đời

5.1.8 Tiêu chí cho quá trình

Tiêu chuẩn này thiết lập một khuôn dạng cho vòng đời phần mềm Vòng đời bắt đầu từ một ý tưởnghoặc nhu cầu cần thiết có thể được đáp ứng hoàn toàn hoặc một phần bởi phần mềm và kết thúc vớiviệc ngừng sử dụng phần mềm Kiến trúc này được xây dựng bằng một tâêp các quá trình và mối tươngquan giữa các quá trình đó Viêêc xác định các quá trình vòng đời được dựa trên hai nguyên tắc cơ bản:

5.1.9 Mô tả quá trình

Các quá trình của tiêu chuẩn này được mô tả theo một cách tương tự với tiêu chuẩn ISO/IEC 15288 đểthuận tiện cho việc sử dụng cả hai tiêu chuẩn trong cùng một tổ chức hay một dự án

Mỗi quá trình của tiêu chuẩn này được mô tả theo các thuộc tính sau:

- Tiêu đề truyền đạt phạm vi của quá trình là nguyên vẹn;

- Mục đích mô tả các mục đích của viêêc thực hiêên quá trình;

- Kết quả thể hiện kết quả quan sát được mong đợi từ việc thực hiện thành công của quá trình;

- Hoạt động là một danh sách các hoạt động được sử dụng để đạt được kết quả;

- Nhiệm vụ là các yêu cầu, khuyến nghị hoặc các hoạt động cho phép để hỗ trợ việc đạt được kếtquả

Chi tiết bổ sung đối với hình thức mô tả này có thể được tìm thấy trong tiêu chuẩn ISO/IEC 24774

5.1.10 Đặc tính chung của quá trình

Các thuộc tính được mô tả trong mục 5.1.9 mô tả đặc điểm đặc trưng của mỗi quá trình Khi một quátrình triển khai tuân thủ các thuộc tính này, quá trình đó định nghĩa một cách rõ ràng mục đích và kếtquả đạt được thông qua viêêc triển khai các hoạt động xác định của nó

Ngoài các thuộc tính cơ bản này, quá trình có thể được mô tả bằng các thuộc tính khác thông dụng vớitất cả các quá trình Tiêu chuẩn ISO/IEC 15504-2 xác định các thuộc tính quá trình chung, các thuôêctính chung này mô tả 6 mức độ đạt được trong khung đo khả năng quá trình Phụ lục B của tiêu chuầnnày bao gồm danh sách các thuộc tính quá trình góp phần vào việc đạt được các mức độ cao hơn củakhả năng quá trình như được định nghĩa trong tiêu chuẩn 15504-2

5.1.11 Sự phân chia của quá trình

Mỗi quá trình của tiêu chuẩn này thỏa mãn các tiêu chí được mô tả ở trên Với mục đích mô tả rõ ràng,quá trình đôi khi được phân chia thành các phần nhỏ hơn Một số quá trình được phân chia thành cáchoạt động và/hoặc các quá trình mức thấp hơn Một quá trình mức thấp hơn được mô tả khi một phầnphân chia của quá trình đáp ứng được các tiêu chí của một quá trình Môêt hoạt động được sử dụng khiđơn vị phân chia không thỏa mãn như một quá trình Hoạt động đó có thể được xem xét như một tậpcác nhiệm vụ đơn giản

Đôi khi là hữu ích khi phân chia quá trình thành các quá trình mức thấp hơn tại mức chi tiết tốt hơn.Một số quá trình mức thấp hơn chỉ được phân chia cho mục đích đánh giá Quá trình mức thấp hơnkhông được mô tả trong phần nội dung của tiêu chuẩn, nhưng được cung cấp ở phần phụ lục Trongmỗi trường hợp, quá trình đánh giá mức thấp hơn được mô tả trong phụ lục là sự trình bày kỹ lưỡngmột hoạt động của quá trình liên kết trong phần nội dung của tiêu chuẩn

Một nhiệm vụ được diễn đạt theo hình thức của một yêu cầu, khuyến nghị hoặc hành động được phép,nhằm để hỗ trợ việc đạt được kết quả của một quá trình Đối với mục đích này, tiêu chuẩn này sử dụng

môêt cách cẩn thận các trợ động từ (phải, nên và có thể) để phân biệt giữa các hình thức riêng biệt củanhiệm vụ “Phải” được sử dụng để diễn đạt một điều khoản được yêu cầu tuân thủ, “nên” để diễn đạtkhuyến nghị giữa các khả năng và “có thể” để chỉ thị một quá trình diễn biến của hành động được phéptrong các giới hạn của tiêu chuẩn này.

Thông tin bổ sung được cung cấp theo hình thức các chú thích hoặc phụ lục không phải là quy định

5.1.12 Các mô hình và giai đoạn vòng đời

Thời gian tồn tại của một hệ thống hoặc một sản phẩm phần mềm có thể được mô hình hóa bằng một

mô hình vòng đời gồm có nhiều giai đoạn Mô hình có thể được sử dụng để diễn tả toàn bôê thời giantồn tại từ khái niêêm cho tới lúc hủy bỏ hoặc để diễn tả phần thời gian tồn tại tương ứng với dự án đangthực hiện Mô hình vòng đời bao gồm một chuỗi các giai đoạn liên tục có thể xếp chồng và/hoặc lặp đilặp lại, theo cách thích hợp đối với các cơ hội, các nhu cầu thay đổi, độ phức tạp, tầm quan trọng vàphạm vi của một dự án Mỗi giai đoạn được mô tả bằng mục đích và kết quả Các hoạt động và quátrình vòng đời được lựa chọn và sử dụng trong một giai đoạn để đáp ứng mục đích và kết quả của giaiđoạn đó Các tổ chức khác nhau có thể đảm nhận các giai đoạn khác nhau trong một vòng đời sảnphẩm Tuy nhiên, mỗi giai đoạn được tổ chức chịu trách nhiệm tiến hành đối với giai đoạn đó với việcquan tâm đến thông tin khả thi trong các kế hoạch vòng đời và các quyết định được thực hiện từ cácgiai đoạn trước đó Tương tự như vậy, tổ chức chịu trách nhiệm đối với giai đoạn đó ghi lại các quyếtđịnh thực hiện và giả thiết liên quan đến các giai đoạn kế tiếp trong vòng đời

Tiêu chuẩn này không yêu cầu sử dụng bất kỳ mô hình vòng đời đặc biệt nào Tuy nhiên, yêu cầu rằngmỗi dự án định nghĩa một mô hình vòng đời phù hợp, tốt nhất là một mô hình đã được tổ chức xácđịnh để sử dụng cho các dự án khác nhau Việc áp dụng một mô hình vòng đời cung cấp phương pháp

để thiết lập trình tự phụ thuôêc thời gian cần thiết cho việc quản lý dự án

Hơn nữa, tiêu chuẩn này không yêu cầu sử dụng bất kỳ tập các giai đoạn đặc biệt nào Ví dụ, tập cácgiai đoạn cho vòng đời của một hệ thống bao gồm: ý tưởng, phát triển, sản xuất, khai thác, hỗ trợ vàngừng sử dụng Trong khi, tập các giai đoạn cho vòng đời của sản phẩm phần mềm lại bao gồm pháttriển, vận hành và duy trì

Rất nhiều kiểu hoăêc lớp của mô hình vòng đời đã được mô tả Ví dụ của các loại hình này được biếtbằng các tên gọi như mô hình thác nước, phát triển gia tăng, phát triển tiến hóa và xoắn ốc Lưu ýrằng, việc lựa chọn đơn giản tên gọi của loại mô hình không đáp ứng yêu cầu định nghĩa một mô hìnhbao gồm các giai đoạn với kết quả và mục đích xác định được thực hiện thông qua các quá trình củatiêu chuẩn này

CHÚ THÍCH: Bản báo cáo kỹ thuật cập nhật tiếp theo (ISO/IEC TR 24748) phải cung cấp phần bổ sung chi tiết phù hợp với các giai đoạn và các mô hình vòng đời

5.2 Cấu trúc tiêu chuẩn

5.2.1 Phân loại quá trình vòng đời

Tiêu chuẩn này nhóm các hoạt động có thể được thực hiêên trong suốt vòng đời của hệ thống phầnmềm thành bảy nhóm quá trình Mỗi quá trình vòng đời trong các nhóm đó được mô tả về mục đích vàkết quả mong muốn của các quá trình và liệt kê các hoạt động và nhiệm vụ cần thiết được thực hiêên đểđạt được kết quả đó

a) Quá trình thỏa thuận – hai quá trình (mục 5.2.2.1.1 và 6.1);

b) Quá trình hỗ trợ dự án của tổ chức– năm quá trình (mục 5.2.2.1.2 và 6.2);

c) Quá trình dự án – bảy quá trình (mục 5.2.2.1.3 và 6.3);

d) Quá trình kỹ thuật – mười một quá trình (mục 5.2.2.1.4 và 6.4);

e) Quá trình triển khai phần mềm – mười một quá trình (mục 5.2.2.2.1 và 7.1);

f) Quá trình hỗ trợ phần mềm – tám quá trình (mục 5.2.2.2.2 và 7.2);

g) Quá trình tái sử dụng phần mềm – ba quá trình (mục 5.2.2.2.3 và 7.3)

Các mục đích và kết quả của quá trình vòng đời cấu thành một mô hình tham chiếu quá trình Trongtiêu chuẩn này, các điều khoản được đánh số như sau:

- 6.x và 7.x biểu thị một nhóm quá trình;

- 6.x.x và 7.x.x biểu thị một quá trình (hoặc quá trình mức độ thấp hơn) trong phạm vi nhóm đó;

- 6.x.x.1 và 7.x.x.1 mô tả mục đích của quá trình;

- 6 x.x.2 và 7.x.x.2 mô tả kết quả của quá trình;

- 6.x.x.3.y và 7.x.x.3.y liệt kê các hoạt động của quá trình;

- 6.x.x.3.y.x và 7.x.x.3.y.x liệt kê các nhiệm vụ của hoạt động ‘y’

Các nhóm quá trình vòng đời này được giới thiệu dưới đây và được miêu tả trong Hình 1

Hình 1 - Các nhóm quá trình vòng đời

khai phần mềm

Quá trình hỗ trợ phần mềm

Quá trình thực thi phần mềm (Mục 7.1.1)

Quá trình xác định các yêu cầu giữa các bên liên quan (Mục 6.4.1)

Quá trình

mua sản phẩm

(Mục 6.1.1)

Quá trình tích hợp phần mềm (Mục 7.1.6)

Quá trình phân tích các yêu cầu phần mềm (Mục 7.1.2)

Quá trình quản lý rủi ro (Mục 6.3.4)

Quá trình quản lý quyết định (Mục 6.3.3)

Quá trình kiểm soát và đánh giá

dự án (Mục 6.3.2)

Quá trình

hỗ trợ tiếp nhận phần mềm (Mục 6.4.8)

Quá trình phân tích các yêu cầu

hệ thống (Mục 6.4.2)

Quá trình đo (Mục 6.3.7)

Quá trình quản lý quản lý thông tin (Mục 6.3.6)

Quá trình quản lý cấu hình (Mục 6.3.5)

Quá trình cài đặt phần mềm (Mục 6.4.7)

Quá trình kiểm tra chất lượng hệ thống (Mục 6.4.6)

Quá trình tích hợp hệ thống (Mục 6.4.5)

Quá trình triển khai (Mục 6.4.4)

Quá trình thiết kế kiến trúc hệ thống (Mục 6.4.3)

Quá trình hủy bỏ phần mềm (Mục 6.4.11)

Quá trình bảo trì phần mềm (Mục 6.4.10)

Quá trình vận hành phần mềm (Mục 6.4.9)

Quá trình xây dựng phần mềm (Mục 7.1.5)

Quá trình thiết kế kiến trúc phần mềm (Mục 7.1.3)

Quá trình thiết kế phần mềm chi tiết (Mục 7.1.4)

Quá trình quản lý cấu hình phần mềm (Mục 7.2.2)

Quá trình quản lý

chất lượng

(Mục 6.2.5)

Quá trình kiểm tra chất lượng phần mềm (Mục 7.1.7)

Quá trình kiểm tra phần mềm (Mục 7.2.7)

Quá trình soát xét phần mềm (Mục 7.2.6)

Quá trình xác nhận phần mềm (Điều 7.2.5)

Quá trình xác minh phần mềm (Mục 7.2.4)

Quá trình đảm bảo chất lượng phần mềm (Mục 7.2.3)

Quá trình giải quyết vấn đề phần mềm (Mục 7.2.8)

Quá trình tái sử dụng phần mềm

Quá trình quản lý chương trình tái

sử dụng (Mục 7.3.3)

Quá trình

kỹ thuật miền (Mục 7.3.1)

Quá trình quản lý tài sản tái sử dụng (Mục 7.3.2)

Mô hình tham chiếu quá trình không trình bày một phương pháp tiếp cận triển khai quá trình cụ thể vàcũng không quy định một kỹ thuâêt, phương pháp luâên hay mô hình vòng đời hệ thống/phần mềm Thayvào đó, mô hình tham chiếu được nhằm để được một tổ chức thừa nhận dựa trên các nhu cầu thươngmại và miền áp dụng Quá trình đã được định nghĩa được các dự án của tổ chức thừa nhận trong ngữcảnh các yêu cầu của khách hàng.

Kết quả quá trình được sử dụng để chứng minh việc đạt được thành công mục đích của quá trình.Điều này giúp người đánh giá quá trình xác định khả năng của quá trình đã được triển khai trong tổchức đó và cung cấp nguồn tài liệu để lập kế hoạch cải tiến quá trình đó

5.2.2 Bản tóm tắt các quá trình vòng đời

Có hai sự phân chia nhỏ cơ bản của quá trình trong tiêu chuẩn này Điều 6 cung cấp một ngữ cảnh hệthống để giải quyết các vấn đề liên quan đến hệ thống phần mềm hoặc dịch vụ hoặc sản phẩm phầnmềm độc lập Điều 7 bao gồm các quá trình phần mềm chuyên dụng cho việc sử dụng để triển khaisản phẩm phần mềm hoặc dịch vụ mà là một phần của một hệ thống lớn

Để hỗ trợ việc sử dụng đồng thời tiêu chuẩn ISO/IEC 15288 và ISO/IEC 12207, các quá trình tươngứng trong điều 6 có cùng cách đánh số với mục nhỏ hơn (ở mức 6.x.x)

Nhìn chung, tập hợp các quá trình trong tiêu chuẩn này là các chuyên ngành phần mềm phù hợp hoặcgóp phần vào kết quả của các quá trình trong tiêu chuẩn ISO/IEC 15288 Nhiều quá trình trong tiêuchuẩn ISO/IEC 15288 được xem tương tự như viêêc triển khai quá trình phần mềm chuyên dụng,nhưng chúng duy trì các đặc tính riêng quan trọng dựa trên mục đích, kết quả và đối tượng đọc Người

sử dụng cả hai tiêu chuẩn ISO/IEC 15288 và ISO/IEC 12207 nên xem xét các chú thích và giải thíchriêng trong mỗi quá trình đặc trưng

5.2.2.1 Quá trình ngữ cảnh hệ thống

5.2.2.1.1 Quá trình thỏa thuận

Quá trình này định nghĩa các hoạt động cần thiết để thiết lập thỏa thuận giữa hai tổ chức Nếu quátrình mua sản phẩm được yêu cầu, nó cung cấp cách thức tiến hành kinh doanh cho nhà cung cấp sảnphẩm, cách thức hỗ trợ một hệ thống vận hành cho nhà cung cấp dịch vụ hoặc cách thức cho nhàcung cấp các thành phần của một hệ thống đã được một dự án phát triển Nếu quá trình cung cấpđược yêu cầu, nó cung cấp cách thức tiến hành dự án, trong đó kết quả là một sản phẩm hoặc dịch vụđược chuyển giao đến bên mua sản phẩm

Nhìn chung, các quá trình thỏa thuận trong tiêu chuẩn này là cụ thể hóa của quá trình thỏa thuận trongtiêu chuẩn ISO/IEC 15288

thiết lập Chúng không phải là một tâêp đầy đủ các quá trình kinh doanh mà cho phép quản lý viêêc kinhdoanh của tổ chức đó.

Quá trình hỗ trợ dự án của tổ chức bao gồm các thành phần sau:

a) Quá trình quản lý mô hình vòng đời;

b) Quá trình quản lý cơ sở hạ tầng;

c) Quá trình quản lý danh mục dự án;

d) Quá trình quản lý nguồn nhân lực;

e) Quá trình quản lý chất lượng

Nhìn chung, quá trình hỗ trợ dự án của tổ chức trong tiêu chuẩn này là cụ thể hóa của tâêp tương ứngcác quá trình trong tiêu chuẩn ISO/IEC 15288

5.2.2.1.3 Quá trình dự án

Trong tiêu chuẩn này, dự án được lựa chọn như là ngữ cảnh cho viêêc mô tả các quá trình có liên quanđến việc lập kế hoạch, đánh giá và kiểm soát Các nguyên tắc liên quan đến các quá trình này có thểđược áp dụng trong bất kỳ phạm vi quản lý nào của một tổ chức

Có hai loại hình quá trình dự án Quá trình quản lý dự án được sử dụng để lập kế hoạch, thực thi, đánhgiá và điều khiển các quá trình của dự án Quá trình hỗ trợ dự án để hỗ trợ các mục tiêu quản lýchuyên dụng Cả hai được mô tả dưới đây

Quá trình quản lý dự án được sử dụng để thiết lập và phát triển các kế hoạch dự án, để đánh giá thànhtựu thực tế và tiến độ so với kế hoạch và để kiểm soát việc thực thi của dự án thông qua việc thựchiện Quá trình quản lý dự án riêng biệt có thể được đưa ra ở bất kỳ thời điểm nào trong vòng đời và ởbất kỳ mức độ nào trong hệ thống phân cấp của dự án, như yêu cầu từ kế hoạch dự án hoặc từ các sựkiêên không lường trước Quá trình quản lý dự án được áp dụng với một mức độ chặt chẽ và đúng quycách tùy thuộc vào độ rủi ro và tính phức tạp của dự án

a) Quá trình lập kế hoạch dự án;

b) Quá trình kiểm soát và đánh giá dự án

Quá trình hỗ trợ dự án cung cấp môêt tâêp trọng tâm chuyên dụng các nhiệm vụ cho viêêc thực hiện mụctiêu quản lý chuyên dụng Quá trình đó là hoàn toàn rõ ràng trong việc quản lý sự cam kết bất kỳ,xuyên suốt từ một tổ chức hoàn chỉnh tới một quá trình vòng đời đơn và tới các nhiệm vụ của quá trìnhđó

a) Quá trình quản lý quyết định;

b) Quá trình quản lý rủi ro;

c) Quá trình quản lý cấu hình;

d) Quá trình quản lý thông tin;

e) Quá trình đo.

Nhìn chung, quá trình hỗ trợ dự án trong tiêu chuẩn này là đồng nhất với quá trình hỗ trợ dự án trongtiêu chuẩn ISO/IEC 15288, bỏ qua một số khác biệt trong việc định đạng Trong một vài trường hợp,quá trình hỗ trợ phần mềm có thể có mối liên hệ với quá trình hỗ trợ dự án

5.2.2.1.4 Quá trình kỹ thuật

Quá trình kỹ thuật được sử dụng để định nghĩa các yêu cầu cho một hệ thống, để chuyển đổi các yêucầu đó thành một sản phẩm hiệu quả, để cho phép việc sản xuất lại sản phẩm khi cần thiết, để sử dụngsản phẩm, để cung cấp các dịch vụ theo yêu cầu, để chấp nhận các điều khoản của các dịch vụ đó và

để ngừng sử dụng sản phẩm khi ngừng sử dụng dịch vụ

Quá trình kỹ thuâêt định nghĩa các hoạt động hỗ trợ các chức năng thuôêc tổ chức và dự án để tối ưuhóa các lợi ích và giảm thiểu các rủi ro phát sinh từ các quyết định và các hoạt động kỹ thuật Các hoạtđộng này cho phép sản phẩm và dịch vụ có tính kịp thời và tính khả thi, chi phí hiệu quả và tính chứcnăng, tính tin cậy, khả năng bảo trì, khả năng sản xuất, tính khả dụng và các tính chất khác yêu cầu bởicác tổ chức mua và cung cấp sản phẩm Các hoạt động này cũng cho phép sản phẩm và dịch vụ tuântheo những mong đợi hoặc yêu cầu hợp pháp của xã hội, bao gồm cả sức khỏe, độ tin cậy, tính antoàn và các yếu tố môi trường

Quá trình kỹ thuật gồm có các quá trình sau:

a) Định nghĩa các yêu cầu của bên liên quan (cụ thể hóa quá trình định nghĩa các yêu cầu của bênliên quan trong tiêu chuẩn ISO/IEC 15288);

b) Phân tích các yêu cầu hệ thống (cụ thể hóa quá trình phân tích các yêu cầu của tiêu chuẩnISO/IEC 15288);

c) Thiết kế kiến trúc hệ thống (cụ thể hóa quá trình thiết kế kiến trúc của tiêu chuẩn ISO/IEC15288);

d) Quá trình triển khai (cụ thể hóa quá trình triển khai của tiêu chuẩn ISO/IEC 15288 và tiếp tụcxây dựng trong điều 7 của tiêu chuẩn này như quá trình triển khai phần mềm);

e) Quá trình tích hợp hệ thống (cụ thể hóa quá trình tích hợp của tiêu chuẩn ISO/IEC 15288);f) Quá trình kiểm tra chất lượng hệ thống (quá trình này góp phần để đạt được kết quả của quátrình xác minh của tiêu chuẩn ISO/IEC 15288);

g) Quá trình cài đặt phần mềm (quá trình này góp phần để đạt được kết quả của quá trình chuyểntiếp của tiêu chuẩn ISO/IEC 15288);

h) Quá trình hỗ trợ tiếp nhận phần mềm (quá trình này góp phần để đạt được kết quả quá trìnhchuyển tiếp của tiêu chuẩn ISO/IEC 15288);

i) Quá trình vận hành phần mềm (cụ thể hóa quá trình vận hành của tiêu chuẩn ISO/IEC 15288);j) Quá trình bảo trì phần mềm (cụ thể hóa quá trình bảo trì của tiêu chuẩn ISO/IEC 15288);

k) Quá trình hủy bỏ phần mềm (cụ thể hóa quá trình hủy bỏ của tiêu chuẩn ISO/IEC 15288).

Nhìn chung, quá trình kỹ thuật trong tiêu chuẩn này là sự đóng góp hoặc các cụ thể hóa tương thíchphần mềm vào kết quả của các quá trình kỹ thuật được cung cấp trong tiêu chuẩn ISO/IEC 15288.Nhiều quá trình được xem tương tự như các quá trình triển khai phần mềm, nhưng vẫn bảo toàn cácđặc tính riêng chủ yếu, như phân tích các yêu cầu hệ thống và phân tích các yêu cầu phần mềm bắtđầu từ các điểm khác biệt và có đối tượng đọc khác nhau

5.2.2.2 Các quá trình phần mềm đặc thù

5.2.2.2.1 Quá trình triển khai phần mềm

Quá trình triển khai phần mềm được sử dụng để đưa ra một thành phần hệ thống đặc thù (thành phầnphần mềm) được triển khai trong phần mềm Quá trình đó chuyển đổi cách xử lý, các giao diện và cácràng buộc triển khai cụ thể thành các hoạt động triển khai tạo ra trong một thành phần hệ thống để đápứng được các yêu cầu xuất phát từ các yêu cầu hệ thống

Quá trình bảo vệ là quá trình triển khai phần mềm, là một cụ thể hóa phần mềm đặc thù của quá trìnhtriển khai trong tiêu chuẩn ISO/IEC 15288

Quá trình triển khai phần mềm có các quá trình mức độ thấp phần mềm đặc thù sau:

a) Quá trình phân tích các yêu cầu phần mềm;

b) Quá trình thiết kế kiến trúc phần mềm;

c) Quá trình thiết kế phần mềm chi tiết;

a) Quá trình quản lý tài liệu hướng dẫn phần mềm;

b) Quá trình quản lý cấu hình phần mềm;

c) Quá trình đảm bảo chất lượng phần mềm;

d) Quá trình xác minh phần mềm;

e) Quá trình xác nhận phần mềm;

f) Quá trình soát xét phần mềm;

g) Quá trình kiểm tra phần mềm;

h) Quá trình giải quyết vấn đề phần mềm

5.2.2.2.3 Quá trình tái sử dụng phần mềm

Nhóm quá trình tái sử dụng phần mềm gồm có ba quá trình hỗ trợ khả năng của tổ chức để tái sử dụngcác thành phần phần mềm qua các giới hạn của dự án Các quá trình là duy nhất bởi vì chúng hoạtđôêng ngoài giới hạn của bất kỳ dự án cụ thể nào

Các quá trình tái sử dụng phần mềm:

a) Quá trình kỹ thuật miền;

b) Quá trình quản lý tài sản tái sử dụng;

c) Quá trình quản lý chương trình tái sử dụng

5.2.3 Mô hình tham chiếu quá trình

Phụ lục B định nghĩa một mô hình tham chiếu quá trình ở mức độ trừu tượng cao hơn so với mô hìnhtham chiếu của các yêu cầu chi tiết được bao gồm trong nội dung chính của tiêu chuẩn này Mô hìnhtham chiếu quá trình có khả năng áp dụng đối với tổ chức đang đánh giá các quá trình để xác định khảnăng của các quá trình này Mục đích và kết quả là bản kê các mục tiêu thực hiện của mỗi quá trình.Bảng kê các mục tiêu này cho phép đánh giá tính hiệu quả của quá trình theo những cách khác nhauhơn là theo sự đánh giá tuân thủ đơn giản Ví dụ, các định nghĩa quá trình mới có thể được đánh giádựa vào các bản kê mục đích và kết quả trong phụ lục B chứ không dựa vào các điều khoản chi tiếttrong nội dung chính của tiêu chuẩn này

CHÚ THÍCH 1: Trong tiêu chuẩn này, thuật ngữ “mô hình tham chiếu quá trình” được sử dụng với cùng nghĩa như tiêu chuẩn ISO/IEC 15504-2.

CHÚ THÍCH 2: Mô hình tham chiếu quá trình được nhằm mục đích để sử dụng cho việc phát triển mô hình đánh giá để đánh giá các quá trình sử dụng tiêu chuẩn ISO/IEC 15504-2.

6 Các quá trình vòng đời hệ thống

6.1 Quá trình thỏa thuận

a) Các nhu cầu mua sản phẩm, mục tiêu, tiêu chí chấp nhận sản phẩm và/hoặc dịch vụ và chiếnlược mua sản phẩm được định nghĩa;

b) Thỏa thuận được phát triển thể hiện rõ ràng mong muốn, các trách nhiệm và tính pháp lý của

cả bên mua sản phẩm và nhà cung cấp;

c) Một hoặc nhiều nhà cung cấp được lựa chọn;

d) Sản phẩm và/hoặc dịch vụ được mua phải thỏa mãn nhu cầu đã xác định của bên mua sảnphẩm;

e) Việc mua sản phẩm được giám sát để các ràng buộc cụ thể như: chi phí, tiến độ kế hoạch vàchất lượng được đáp ứng;

f) Các hạng mục chuyển giao của nhà cung cấp được chấp nhận;

g) Bất kì thành phần mở rộng nào đã xác định đều có sự giải quyết thỏa đáng như đã thỏa thuậnbởi bên mua sản phẩm và nhà cung cấp

6.1.1.3 Các hoạt động và nhiệm vụ

Bên mua sản phẩm sẽ triển khai các hoạt động sau phù hợp với các thủ tục và chính sách của tổ chức

có khả năng áp dụng liên quan tới quá trình mua sản phẩm

CHÚ THÍCH: Các hoạt động và nhiệm vụ trong quá trình này có thể áp dụng đối với một hoặc nhiều nhà cung cấp.

6.1.1.3.1 Chuẩn bị mua sản phẩm

Hoạt động này bao gồm các nhiệm vụ sau:

6.1.1.3.1.1 Bên mua sản phẩm bắt đầu quá trình mua sản phẩm bằng việc mô tả ý tưởng hoặc nhu cầu

để mua, phát triển hoặc nâng cấp một hệ thống, sản phẩm phần mềm hoặc dịch vụ phần mềm

6.1.1.3.1.2 Bên mua sản phẩm sẽ định nghĩa và phân tích các yêu cầu hệ thống Các yêu cầu hệ thống

nên bao gồm yêu cầu của doanh nghiệp, tổ chức và người sử dụng cũng như các yêu cầu bảo đảm độtin cậy, tính an toàn và mức độ rủi ro khác theo các thủ tục, tiêu chuẩn tuân thủ, kiểm tra và thiết kế liênquan

6.1.1.3.1.3 Bên mua sản phẩm có thể tự thực hiện định nghĩa và phân tích các yêu cầu phần mềm

hoặc có thể thuê nhà cung cấp để thực hiện nhiệm vụ đó

6.1.1.3.1.4 Nếu bên mua sản phẩm thuê nhà cung cấp để thực hiện phân tích các yêu cầu hệ thống

hoăêc phần mềm, thì bên mua sản phẩm sẽ thuê chuyên gia phê chuẩn các yêu cầu đã phân tích

6.1.1.3.1.5 Các quá trình kỹ thuật (mục 6.4) nên được sử dụng để thực hiện các nhiệm vụ trong mục

6.1.1.3.1.2 và 6.1.1.3.1.4 Bên mua sản phẩm có thể sử dụng quá trình định nghĩa các yêu cầu củabên liên quan để thiết lập các yêu cầu của khách hàng

6.1.1.3.1.6 Bên mua sản phẩm sẽ xem xét các phương án cho việc mua sản phẩm dựa vào viêêc phân

tích các tiêu chí phù hợp bao gồm độ rủi ro, chi phí và các lợi ích cho mỗi phương án Các phương ángồm có:

a) Mua sản phẩm phần mềm sẵn sàng phổ biến và thương mại hóa đáp ứng được các yêu cầu;

b) Phát triển sản phẩm phần mềm hoặc thu được dịch vụ phần mềm môêt cách nôêi bôê;

c) Phát triển sản phẩm phần mềm hoặc thu được dịch vụ phần mềm thông qua hợp đồng;

d) Kết hợp cả phương án a, b và c nêu trên;

e) Nâng cấp sản phẩm phần mềm hoặc dịch vụ có sẵn

6.1.1.3.1.7 Khi mua sản phẩm phần mềm sẵn sàng phổ biến và thương mại hóa, bên mua sản phẩm

sẽ phải đảm bảo các điều kiện sau được đáp ứng:

a) Các yêu cầu cho sản phẩm phần mềm phải được đáp ứng;

b) Tài liệu hướng dẫn được yêu cầu là phải có sẵn;

c) Sở hữu độc quyền, khả năng sử dụng, đồng sở hữu, giấy bảo hành và bản quyền phải đượcđáp ứng;

d) Có kế hoạch cho viêêc bảo hành sản phẩm phần mềm

6.1.1.3.1.8 Bên mua sản phẩm nên chuẩn bị, tài liệu hóa và thực thi kế hoạch mua sản phẩm Kế

hoạch nên bao gồm như sau:

a) Các yêu cầu cho hệ thống;

b) Công việc xác định của hệ thống;

c) Loại hình hợp đồng được sử dụng;

d) Các trách nhiệm của các tổ chức có liên quan;

e) Khái niêêm hỗ trợ được sử dụng;

f) Các rủi ro được xem như các phương pháp để quản lý các rủi ro

6.1.1.3.1.9 Bên mua sản phẩm sẽ định nghĩa và tài liệu hóa các điều kiện và chiến lược được chấp

nhận

6.1.1.3.1.10 Bên mua sản phẩm nên tài liệu hóa các yêu cầu mua sản phẩm (ví dụ: yêu cầu đối với đề

xuất), nội dung trong đó phụ thuộc vào phương án mua sản phẩm được lựa chọn trong mục6.1.1.3.1.6 Tài liệu hướng dẫn mua sản phẩm nên tính đến khi thấy thích hợp:

a) Các yêu cầu hệ thống;

b) Phạm vi;

c) Bản hướng dẫn cho các nhà đấu thầu;

d) Danh sách các sản phẩm phần mềm;

e) Các điều khoản và các điều kiện;

f) Kiểm soát các hợp đồng phụ;

g) Các ràng buộc kỹ thuật (ví dụ: môi trường mục tiêu)

6.1.1.3.1.11 Bên mua sản phẩm nên xác định quá trình nào của tiêu chuẩn này là thích hợp cho việc

mua sản phẩm và chỉ rõ bất kỳ các yêu cầu của bên mua sản phẩm nào đối với viêêc sửa đổi các quátrình đó Bên mua sản phẩm nên chỉ rõ nếu bất kỳ một quá trình nào trong các quá trình được các bêntham gia khác với nhà cung cấp thực hiện, để những nhà cung cấp có thể xác định cách tiếp cận choviệc hỗ trợ công việc của các bên tham gia khác theo các đề xuất của họ Bên mua sản phẩm sẽ chỉ rõphạm vi của các nhiệm vụ trong hợp đồng

6.1.1.3.1.12 Tài liệu hướng dẫn mua sản phẩm cũng sẽ định nghĩa các cột mốc hợp đồng mà tiến độ

của nhà cung cấp được xem xét và kiểm tra như một phần trong việc giám sát mua sản phẩm (xemmục 7.2.6 và 7.2.7)

6.1.1.3.1.13 Các yêu cầu mua sản phẩm nên được chuyển đến tổ chức được lựa chọn cho việc thực

hiện hoạt động mua sản phẩm

6.1.1.3.2 Thông báo mua sản phẩm

Hoạt động này bao gồm nhiệm vụ sau:

6.1.1.3.2.1 Bên mua sản phẩm sẽ gửi thông tin yêu cầu cung cấp sản phẩm hoặc dịch vụ đến những

nhà cung cấp đã được xác định

CHÚ THÍCH: Điều này có thể bao gồm việc hợp tác quản lý chuỗi cung ứng thực hiện trao đổi thông tin với bên mua sản phẩm và những nhà cung cấp có liên quan để đạt được cách tiếp cận chung hoặc hợp lý đối với các vấn đề thương mại và kỹ thuật chung.

6.1.1.3.3 Lựa chọn nhà cung cấp

Hoạt động này bao gồm các nhiệm vụ sau:

6.1.1.3.3.1 Bên mua sản phẩm nên thiết lập một thủ tục cho viêêc lựa chọn nhà cung cấp bao gồm cả

việc hiệu chỉnh bổ sung phù hợp với các yêu cầu và tiêu chí đánh giá đề xuất

6.1.1.3.3.2 Bên mua sản phẩm nên lựa chọn nhà cung cấp dựa trên việc đánh giá các khả năng, đề

xuất của những nhà cung cấp theo các điều kiện và chiến lược của bên mua sản phẩm

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

Hoạt động này bao gồm các nhiệm vụ sau:

6.1.1.3.4.1 Trước khi quyết định hợp đồng, bên mua sản phẩm có thể bao gồm các bên tham gia khác,

gồm cả nhà cung cấp tiềm năng hoặc bất kỳ bên thứ ba cần thiết nào (như bên quản lý), trong viêêc xác

định các yêu cầu của bên mua sản phẩm để sửa đổi tiêu chuẩn này cho dự án Trong việc đưa raquyết định này, bên mua sản phẩm phải xem xét ảnh hưởng của các yêu cầu sửa đổi theo các quátrình tổ chức được thừa nhận của nhà cung cấp Bên mua sản phẩm phải tính đến hoặc tham chiếuđến các yêu cầu sửa đổi trong hợp đồng.

6.1.1.3.4.2 Bên mua sản phẩm sau đó phải chuẩn bị và đàm phán hợp đồng với nhà cung cấp để giải

quyết các yêu cầu mua sản phẩm (bao gồm cả chi phí và tiến độ) của dịch vụ hoăêc sản phẩm phầnmềm được chuyển giao Bản hợp đồng phải chỉ ra sở hữu độc quyền, khả năng sử dụng, đồng sởhữu, giấy bảo hành và bản quyền liên quan đến các sản phẩm phần mềm sẵn sàng phổ biến vàthương mại hóa có khả năng tái sử dụng

6.1.1.3.4.3 Một khi hợp đồng đang thực hiện, bên mua sản phẩm phải kiểm soát sự thay đổi hợp đồng

thông qua việc đàm phán với nhà cung cấp như một phần của cơ chế kiểm soát sự thay đổi Các thayđổi của hợp đồng phải được khảo sát sự tác động của nó đến tiến độ, chất lượng, các lợi ích, chi phí

và kế hoạch dự án

CHÚ THÍCH 1: Bên mua sản phẩm xác định một trong hai thuật ngữ “hợp đồng” hoặc “thỏa thuận” được sử dụng trong việc

áp dụng tiêu chuẩn này.

CHÚ THÍCH 2: Sự thỏa thuận giữa bên mua sản phẩm và nhà cung cấp nên mô tả môêt cách rõ ràng mong muốn, trách nhiệm

và tính pháp lý của cả hai bên.

CHÚ THÍCH 3: Cơ chế kiểm soát thay đổi hợp đồng nên chỉ ra trách nhiệm và vai trò quản lý sự thay đổi; mức độ theo đúng thủ tục với việc đàm phán hợp đồng, các yêu cầu thay đổi được đề xuất và thông tin đến các bên liên quan bị ảnh hưởng

6.1.1.3.5 Giám sát thỏa thuận

Hoạt động này bao gồm các nhiệm vụ sau:

6.1.1.3.5.1 Bên mua sản phẩm phải giám sát các hoạt động của nhà cung cấp theo quá trình soát xét

phần mềm (mục 7.2.6) và quá trình kiểm tra phần mềm (mục 7.2.7) Bên mua sản phẩm nên bổ sungthêm việc giám sát quá trình xác minh phần mềm (mục 7.2.4) và quá trình xác nhận phần mềm (mục7.2.5) khi cần thiết

6.1.1.3.5.2 Bên mua sản phẩm phải hợp tác với nhà cung cấp để đưa ra tất cả thông tin cần thiết một

cách kịp thời và giải quyết tất cả các vấn đề còn tồn tại

6.1.1.3.6 Sự tiếp nhận của bên mua sản phẩm

Hoạt động này bao gồm các nhiệm vụ sau:

6.1.1.3.6.1 Bên mua sản phẩm nên chuẩn bị việc tiếp nhận dựa trên tiêu chí và chiến lược đã xác định.

Bên mua cũng nên chuẩn bị trước các trường hợp kiểm tra, dữ liệu kiểm tra, phương pháp kiểm tra vàmôi trường kiểm tra Ngoài ra, cũng nên xác định phạm vi tham gia của nhà cung cấp

6.1.1.3.6.2 Bên mua sản phẩm phải tiến hành kiểm tra, xem xét tiếp nhận dịch vụ hoăêc sản phẩm phần

mềm và phải chấp nhận nó từ nhà cung cấp khi tất cả các điều kiện tiếp nhận được đáp ứng Thủ tụctiếp nhận nên tuân theo các quy định của mục 6.1.1.3.1.9

6.1.1.3.6.3 Sau khi tiếp nhận, bên mua sản phẩm nên thực hiện trách nhiệm quản lý cấu hình của sản

phẩm phần mềm đó (xem mục 7.2.2)

CHÚ THÍCH: Bên mua sản phẩm có thể cài đặt sản phẩm phần mềm hoặc thực hiện dịch vụ phần mềm theo các hướng dẫn được nhà cung cấp đưa ra.

6.1.1.3.7 Đóng thỏa thuận

Hoạt động này bao gồm các nhiệm vụ sau:

6.1.1.3.7.1 Bên mua sản phẩm phải thực hiện thanh toán hoặc đưa ra lý do được chấp thuận khác tới

nhà cung cấp đối với sản phẩm và dịch vụ đã được giao

CHÚ THÍCH 1: Khi sản phẩm hoặc dịch vụ được cung cấp đã đáp ứng được các điều kiện trong thỏa thuận và các điều khoản

mở xác định đã được hoàn thành môêt cách thỏa đáng, thì bên mua sản phẩm giải quyết thỏa thuận bằng cách thực hiêên thanh toán hoăêc đưa ra lý do được chấp thuận khác và thông báo đóng thỏa thuận.

CHÚ THÍCH 2: Sản phẩm hoặc dịch vụ có thể được cung cấp thêm và thanh toán hoặc đưa ra lý do được chấp thuận khác có thể được thực hiện với sự tăng thêm tương ứng

Kết quả triển khai thành công của quá trình cung cấp gồm:

a) Bên mua sản phẩm hoặc dịch vụ được định nghĩa;

b) Sự đáp ứng đối với yêu cầu của bên mua sản phẩm được đưa ra;

c) Thỏa thuận được thiết lập giữa bên mua sản phẩm và nhà cung cấp cho viêêc phát triển, bảo trì,vận hành, đóng gói, chuyển giao và cài đặt sản phẩm và/hoặc dịch vụ;

d) Sản phẩm và/hoặc dịch vụ đáp ứng được các yêu cầu đã thỏa thuận được nhà cung cấp pháttriển;

e) Sản phẩm và/hoặc dịch vụ được chuyển giao tới bên mua sản phẩm phù hợp với các yêu cầu

6.1.2.3.1 Định nghĩa thời cơ

Hoạt động này bao gồm nhiệm vụ sau:

6.1.2.3.1.1 Nhà cung cấp nên xác định sự tồn tại và nhâên dạng bên mua sản phẩm hoặc đại diện cho

một tổ chức hoặc nhiều tổ chức, có nhu cầu về sản phẩm hoặc dịch vụ

CHÚ THÍCH: Đối với sản phẩm hoặc dịch vụ được phát triển cho khách hàng, đại lý, ví dụ chức năng tiếp thị bên trong tổ chức nhà cung cấp, có thể đại diện cho bên mua sản phẩm.

6.1.2.3.2 Đấu thầu nhà cung cấp

Hoạt động này bao gồm các nhiệm vụ sau:

6.1.2.3.2.1 Nhà cung cấp nên tiến hành cân nhắc các yêu cầu trong đề nghị mua sản phẩm có tính đến

các chính sách tổ chức và các quy định khác

6.1.2.3.2.2 Nhà cung cấp nên ra quyết định để đấu thầu hoặc tiếp nhận hợp đồng.

6.1.2.3.2.3 Nhà cung cấp sẽ chuẩn bị đề xuất cho việc đáp ứng yêu cầu đề xuất.

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

Hoạt động này bao gồm các nhiệm vụ sau:

6.1.2.3.3.1 Nhà cung cấp sẽ đàm phán và tham gia vào hợp đồng với bên mua sản phẩm để cung cấp

sản phẩm phần mềm hoặc dịch vụ phần mềm

6.1.2.3.3.2 Nhà cung cấp có thể yêu cầu chỉnh sửa hợp đồng như một phần của cơ chế kiểm soát thay

đổi

6.1.2.3.4 Thực thi hợp đồng

Hoạt động này bao gồm các nhiệm vụ sau:

6.1.2.3.4.1 Nhà cung cấp sẽ tiến hành xem xét các yêu cầu mua sản phẩm để định nghĩa khung làm

viêêc cho việc quản lý và đảm bảo dự án và để đảm bảo chất lượng của sản phẩm phần mềm hoặc dịch

vụ phần mềm được chuyển giao

6.1.2.3.4.2 Nếu như không được quy định trong hợp đồng, nhà cung cấp sẽ định nghĩa hoặc lựa chọn

một mô hình vòng đời thích hợp với phạm vi, tầm quan trọng và tính phức tạp của dự án Mô hình vòngđời sẽ bao gồm các giai đoạn cùng với mục đích và kết quả của mỗi giai đoạn đó Các quá trình, cáchoạt động và các nhiệm vụ của tiêu chuẩn này phải được lựa chọn và ánh xạ lên trên mô hình vòngđời đó

CHÚ THÍCH: Môêt cách lý tưởng, điều này được thực hiện bằng cách sử dụng một mô hình vòng đời được định nghĩa môêt cách có tổ chức.

6.1.2.3.4.3 Nhà cung cấp phải thiết lập các yêu cầu cho các kế hoạch quản lý và đảm bảo dự án và để

đảm bảo chất lượng của sản phẩm phần mềm hoặc dịch vụ phần mềm được chuyển giao Các yêucầu cho các kế hoạch nên bao gồm các nhu cầu tài nguyên và sự tham gia của bên mua sản phẩm

6.1.2.3.4.4 Khi các yêu cầu lập kế hoạch được thiết lập, nhà cung cấp sẽ xem xét các phương án để

phát triển sản phẩm phần mềm hoặc cung cấp dịch vụ phần mềm dựa vào sự phân tích các rủi ro liênquan tới mỗi phương án Các phương án này gồm có: