Tiêu chuẩn Quốc gia TCVN 10539:2014 ISO/IEC 12207:2008 Kỹ thuật hệ thống và phần mềm-Các quá trình vòng đời phần mềm

TIÊU CHUẨN QUỐC GIA

TCVN 10539:2014

ISO/IEC 12207:2008

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

Lời nói đầu

TCVN 10539:2014 tương đương, có sửa đổi so với ISO/IEC 12207:2008

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

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ững khá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êu chuẩ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ản phẩ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. Phần mềm kể cả 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ẩm phầ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ảo trì, 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ương phá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ẫn nà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 ghi năm công bố thì áp dụng bản được nêu. Đối với các tài liệu viện dẫn không ghi năm công bố thì áp dụng phiên bản mới nhất, bao gồm cả các sửa đổi, bổ sung (nếu có).

Không có tài liệu tham khảo được đưa ra trong tài liệu này.

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 thu mua (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ì.

3.5. Bên vận hành (operator)

Tổ chức vận hành hệ thống.

CHÚ THÍCH 1: Vai trò của bên vận hành và vai trò của người sử dụng 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.

CHÚ THÍCH 2: Trong ngữ cảnh của định nghĩa cụ thể này, thuật ngữ này có nghĩa là một cá nhân hoặc một tổ chức.

3.6. 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 vi thuộ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 ứng cá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ính thức.

3.15. Giám sát (monitoring)

Kiểm tra trạng thái các hoạt động của nhà cung cấp và kết quả được thực hiện bởi bên mua sản phẩm hoặc bên thứ ba.

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

3.17. Hoạt động (activity)

Tập các nhiệm vụ của một quá trình.

3.18. Hợp đồng (contract)

Thỏa thuận ràng buộc giữa hai bên hoặc thỏa thuận nội bộ tương tự trong tổ chức mà có thể thi hành bằng điều luật.

3.19. 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 đóng gó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 tiếp 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:2007.

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

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ích hợ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.

3.26. Mua sản phẩm (acquisition)

Quá trình đạt được hệ thống, sản phẩm hoặc dịch vụ phần mềm.

3.27. Mô hình vòng đời (life cycle model)

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ần mề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.

3.31. Nhiệm vụ (task)

Yêu cầu, khuyến nghị hoặc hành động được phép nhằm góp phần vào việc đạt được một hoặc nhiều kết quả của một quá trình.

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

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ềm chỉ đọ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.

3.35. Phiên bản phát hành (release)

Phiên bản cụ thể của thành phần cấu hình được làm sẵn để dùng cho một mục đích cụ thể (ví dụ: phiên bản kiểm tra).

3.36. 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ản phẩm phần mềm.

3.38. Phiên bản (version)

Bản phát hành được xác định của một sản phẩm phần mềm.

CHÚ THÍCH: Sự chỉnh sửa đối với một phiên bản của một sản phẩm phần mềm mà yêu cầu hoạt động quản lý cấu hình để tạo ra một phiên bản mới.

3.39. Quá trình (process)

Tập hợp các hoạt động có liên quan lẫn nhau hoặc tương tác để biến đổi đầu vào thành đầu ra.

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

3.42. Sản phẩm (product)

Kết quả của quá trình.

3.43. Sản phẩm phần mềm (software product)

Tập các chương trình máy tính, các thủ tục, tài liệu hướng dẫn và dữ liệu có thể đi kèm.

3.44. 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 và các phương tiện với những 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:2007.

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.

3.49. Tính an toàn (security)

Bảo vệ thông tin và dữ liệu để những hệ thống hoặc người không có thẩm quyền không thể đọc hay chỉnh sửa chúng trong khi các hệ thống và người có thẩm quyền không bị từ chối truy nhập vào chúng.

3.50. Thành phần phần mềm (software item)

Mã nguồn, mã đối tượng, mã điều khiển, dữ liệu điều khiển hoặc một bộ tập hợp các thành phần này.

CHÚ THÍCH: Thành phần phần mềm có thể được xem như một thành phần hệ thống của tiêu chuẩn ISO/IEC 15288: 2008.

3.51. 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ụ được thự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ình thành khái niệm đến lúc ngừng sử dụng.

3.53. Xác nhận (validation)

Khẳng định bằng việc cung cấp bằng chứng khách quan rằng các yêu cầu cho một ứng dụng hay một mục đích sử dụng cụ thể đã được đáp ứng.

CHÚ THÍCH: Xác nhận trong một ngữ cảnh vòng đời là một tập các hoạt động đảm bảo và đạt được sự tin cậy mà một hệ thống có khả năng hoàn thành các mục tiêu, các mục đích và lợi ích dự kiến của nó.

3.54. Xác minh (verification)

Khẳng định bằng việc cung cấp bằng chứng khách quan rằng các yêu cầu định nghĩa đã được đáp ứng.

CHÚ THÍCH: Xác minh trong một ngữ cảnh vòng đời là một tập các hoạt động so sánh một sản phẩm của vòng đời với các đặc tính yêu cầu cho sản phẩm đó. Điều này có thể bao gồm, nhưng không giới hạn, các yêu cầu cụ thể, mô tả thiết kế và hệ thống của chính nó.

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.55. 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ầu tiề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 mục 6 và 7 và Phụ lục A. Tiêu chuẩn này cung 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ột sả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ày thườ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êu cầ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ới Quá 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ác yê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át triể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ằm cung 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ột cá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ột vài trường hợp, các từ thường dùng được sử dụng theo cách đặc biệt trong tiêu chuẩn nà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ìm thấy trong tiêu chuẩn ISO/IEC TR 15271, hướng dẫn áp dụng ISO/IEC 12207 các quá trình vòng đời phần mềm.

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ều khoả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ựa trê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ện bằ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ần mề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ích yê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ấu trú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 khi việ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ục khô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ích phầ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ác quá 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 và các dịch vụ phần mềm. Một ví dụ cần lưu ý là quá trình áp dụng 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ỗi thà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êu chuẩ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êu chuẩ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 điều kiện 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ống thà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ụng thuậ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 được gọ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ột phầ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ùng một tổ chức hoặc từ các tổ chức riêng biệt. Một cá nhân sẽ như một 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úng không mang ý nghĩa chung, thay vào đó, được tham chiếu để tổ chức hoặc bên tham gia chịu trách nhiệ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ên triể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ẩn nà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ác nhau. 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ột bản hợp đồng hoặc á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ình khá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 quá 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ản thỏ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ụng bê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ểu như quy định tự đặt ra.

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ác nhau đượ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ên cho 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ày cung 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ừa nhậ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ần mề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êu chuẩn này và bổ sung thêm các thủ tục, thực hành, công cụ và chính sách thích hợp. Dự án phần mề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ẩn nà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ẩn này một cách trực tiếp tới dự án đó.

5.1.5. Sự sửa đổi

Phụ lục A, là phần quy định, định nghĩa các hoạt động cơ bản cần thiết để thực hiện việc sửa đổi trong tiêu chuẩn này.

Chú ý rằng việc sửa đổi có thể giảm bớt giá trị nhận được của một yêu cầu tuân thủ đối với tiêu chuẩn này. Lý do là khó cho các tổ chức khác để hiểu được phạm vi sửa đổi khi mà việc sửa đổi đó có thể đã xóa bỏ các điều khoản mong muốn. Tổ chức đánh giá yêu cầu tuân thủ đối với tiêu chuẩn này có thể thấy lợi để yêu cầu tuân thủ hoàn toàn đối với một danh sách nhỏ hơn của các quá trình chứ không phải tuân thủ có sửa đổi đối với một danh sách lớn các quá trình.

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 theo trì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 hoặc sử dụng tuần tự phụ thuộc thời gian 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ác hoạ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ủa cá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 cho việ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 tham gia độ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ác nhau 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át xé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ưởng hoặ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ới việ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ương quan 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: sự gắn kết và trách nhiệm.

- Sự gắn kết: Các quá trình vòng đời được gắn kết và được ghép cặp thành phạm vi tối ưu để cho thấy tính thực tế và tính khả thi;

- Trách nhiệm: Một quá trình được đặt dưới trách nhiệm của một tổ chức hoặc một bên tham gia trong vòng đời phần mềm.

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ết quả.

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ết quả đạ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ới tấ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ộc tí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ẩn nà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ủa khả năng quá trình như được định nghĩa trong tiêu chuẩn ISO/IEC 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ác hoạ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ần phâ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ập cá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ơn khô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. Trong mỗ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ưỡng mộ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ủa nhiệ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 đạt khuyế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ép trong 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 gian tồ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 đang thự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 đi lặ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ản phẩ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ệc quan 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ác giai đ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ằng mỗ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ác giai đ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át triể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ết bằ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ình bao 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ủa tiê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ần mề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. Trong tiêu chuẩn này, các điều khoản được đánh số như sau:

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

- 6.a.b và 7.a.b 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.a.b.1 và 7.a.b.1 mô tả mục đích của quá trình;

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

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

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

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

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. Thay và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ương mạ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. Mục 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ần mềm độc lập. Điều 7 bao gồm các quá trình đặc thù phần mềm cho việc sử dụng để triển khai sản phẩm phần mềm hoặc dịch vụ như 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ặc gó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êu chuẩn ISO/IEC 15288 được xem tương tự như việc triển khai quá trình đặc thù phần mềm, 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ích riêng trong mỗi quá trình đặc trưng.

5.2.2.1. Quá trình phạm vi 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ản phẩ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 trong tiêu chuẩn ISO/IEC 15288.

5.2.2.1.2. Quá trình hỗ trợ dự án của tổ chức

Quá trình hỗ trợ dự án của tổ chức quản lý khả năng của tổ chức để mua và cung cấp các sản phẩm hoặc dịch vụ thông qua sự khởi tạo, hỗ trợ và kiểm soát dự án. Chúng cung cấp các tài nguyên và cơ sở hạ tầng cần thiết để hỗ trợ dự án và bảo đảm thỏa mãn các mục tiêu tổ chức và các thỏa thuận đã 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 kinh doanh 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 ứng cá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, đánh giá 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ành tự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ực hiệ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 quy cá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ục tiê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 trong tiêu chuẩn ISO/IEC 15288, bỏ qua một số khác biệt trong việc định dạ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êu cầ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ụng sả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 ưu hó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ức nă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ởi cá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ân theo 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 an toà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ên liê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ẩn ISO/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/IEC 15288);

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ục xây dựng trong mục 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ển tiế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ình chuyể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ích phầ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 đặc thù phần mềm

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ần phầ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ác rà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 đặc thù phần mềm của quá trình triể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 đặc thù phần mềm ở mức độ thấp 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;

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

e) Quá trình tích hợp phần mềm;

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

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

Quá trình hỗ trợ phần mềm cung cấp một tập các hoạt động trọng tâm xác định cho việc thực hiện quá trình phần mềm cụ thể hóa. Quá trình hỗ trợ giúp quá trình triển khai phần mềm như một phần tích hợp với một mục đích nhất định, góp phần vào thành công và chất lượng của dự án phần mềm. Có tám quá trình

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ụng cá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ình tham 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ình tham 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 nhau hơ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ết trong 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

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

6.1.1.1. Mục đích

Mục đích của quá trình mua sản phẩm là để thu được sản phẩm và/hoặc dịch vụ mà đáp ứng nhu cầu được bên mua sản phẩm đưa ra. Quá trình này bắt đầu với việc nhận biết các nhu cầu của khách hàng và kết thúc bằng việc tiếp nhận sản phẩm và/hoặc dịch vụ được yêu cầu bởi bên mua sản phẩm.

6.1.1.2. Kết quả

Các kết quả triển khai thành công của quá trình mua sản phẩm gồm:

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ến lượ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ản phẩ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ận bở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ên quan.

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ủa bê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 án gồ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.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ục 6.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ên tham 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 cho việ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 (xem mụ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 ra quyế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ần mề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ổ sung thê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ục 7.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ục tiế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 xem xét được chấp thuận khác có thể được thực hiện với sự tăng thêm tương ứng.

6.1.2. Quá trình cung cấp

6.1.2.1. Mục đích

Mục đích của quá trình cung cấp là để cung cấp sản phẩm hoặc dịch vụ đến bên mua sản phẩm, đáp ứng được các yêu cầu đã thỏa thuận.

6.1.2.2. Kết quả

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át triể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 đã thỏa thuận;

f) Sản phẩm được cài đặt phù hợp với các yêu cầu đã thỏa thuận.

6.1.2.3. Hoạt động và nhiệm vụ

Nhà cung cấp 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ó tổ chức có khả năng áp dụng đối với quá trình cung cấp.

6.1.2.3.1. Nhận dạng cơ hội

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ác hoạ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 tốt nhất, đ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 xác định 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êu cầ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ên quan tới mỗi phương án. Các phương án này gồm có:

a) Phát triển sản phẩm phần mềm hoặc cung cấp dịch vụ phần mềm sử dụng các tài nguyên bên trong;

b) Phát triển sản phẩm phần mềm hoặc cung cấp dịch vụ phần mềm bằng hợp đồng phụ;

c) Thu được các sản phẩm phần mềm có sẵn phổ biến và thương mại hóa từ các nguồn trong hoặc nguồn ngoài;

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

6.1.2.3.4.5. Nhà cung cấp sẽ xây dựng và tài liệu hóa kế hoạch quản lý dự án dựa trên các yêu cầu lập kế hoạch và các phương án đã lựa chọn trong mục 6.1.2.3.4.4.

CHÚ THÍCH: Các thành phần cần được xem xét trong kế hoạch bao gồm, nhưng không giới hạn, những điều sau đây:

a) Cấu trúc tổ chức dự án cũng như thẩm quyền vá trách nhiệm của mỗi đơn vị tổ chức, bao gồm cả các tổ chức ngoài;

b) Môi trường kỹ thuật (cho sự xây dựng, vận hành hoặc bảo trì, khi có khả năng áp dụng) gồm có môi trường kiểm tra, thư viện, thiết bị, các phương tiện, các tiêu chuẩn, các thủ tục và các công cụ;

c) Cấu trúc phân chia công việc (bảng công việc) của các quá trình vòng đời và các hoạt động, bao gồm cả các sản phẩm phần mềm, dịch vụ phần mềm và các thành phần không thể chuyển giao, được thực hiện cùng với ngân sách, biên chế, các tài nguyên vật lý, quy mô phần mềm và các lịch trình được liên kết với các nhiệm vụ;

d) Quản lý các đặc tính chất lượng của các sản phẩm phần mềm hoặc dịch vụ phần mềm. Các kế hoạch riêng cho chất lượng có thể được phát triển;

e) Quản lý độ tin cậy, tính an toàn và các yêu cầu tiêu chí khác của các sản phẩm phần mềm hoặc dịch vụ phần mềm. Các kế hoạch riêng biệt cho độ tin cậy và tính an toàn có thể được phát triển;

f) Quản lý nhà thầu phụ, bao gồm cả việc lựa chọn nhà thầu phụ và sự gắn kết giữa nhà thầu phụ và bên mua sản phẩm nếu có;

g) Đảm bảo chất lượng (xem mục 7.2.3);

h) Xác minh (xem mục 7.2.4) và xác nhận (xem mục 7.2.5), bao gồm cả sự tiếp cận với bên xác nhận và xác minh, nếu được chỉ định;

i) Sự tham gia của bên mua sản phẩm, bằng các cách thức như soát xét (xem mục 7.2.6), kiểm tra (xem mục 7.2.7), các buổi họp không chính thức, báo cáo, chỉnh sửa và thay đổi, triển khai, chấp thuận, tiếp nhận và tiếp cận tới các phương tiện;

j) Sự tham gia của người sử dụng, bằng các cách thức như thực hiện thiết lập các yêu cầu, các đánh giá và các thuyết minh mẫu kiểm tra;

k) Quản lý rủi ro, có nghĩa là, quản lý các phạm vi của dự án liên quan đến kỹ thuật tiềm năng, chi phí hoặc các rủi ro tiến độ;

I) Chính sách an toàn, có nghĩa là, các quy tắc đối với “cần biết" và “truy cập thông tin” ở mỗi mức tổ chức dự án;

m) Chấp thuận được yêu cầu bằng các cách thức như các quy định, chứng chỉ được yêu cầu, 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;

n) Các phương tiện lập kế hoạch, tự hiệu chỉnh và báo cáo;

o) Đào tạo nhân lực (xem mục 6.2.4).

6.1.2.3.4.6. Nhà cung cấp sẽ triển khai và thực thi kế hoạch quản lý dự án đã được phát triển trong mục 6.1.2.3.4.5.

6.1.2.3.4.7. Nhà cung cấp sẽ:

a) Phát triển sản phẩm phần mềm phù hợp với các quá trình kỹ thuật (mục 6.4);

b) Vận hành sản phẩm phần mềm phù hợp với quá trình vận hành phần mềm (mục 6.4.9);

c) Bảo trì sản phẩm phần mềm phù hợp với quá trình bảo trì phần mềm (mục 6.4.10).

6.1.2.3.4.8. Nhà cung cấp sẽ giám sát và kiểm soát tiến độ và chất lượng của các sản phẩm phần mềm hoặc dịch vụ phần mềm trong dự án trong suốt vòng đời đã ký kết. Điều này sẽ là nhiệm vụ diễn ra lặp đi lặp lại, nhằm cung cấp cho:

a) Tiến trình giám sát trong việc thực hiện kỹ thuật, chi phí và tiến độ cùng với báo cáo tình trạng của dự án;

b) Xác định vấn đề, phân tích, ghi hồ sơ dữ liệu và cách giải quyết.

6.1.2.3.4.9. Nhà cung cấp sẽ quản lý và kiểm soát các nhà thầu phụ phù hợp với quá trình mua sản phẩm (mục 6.1.1). Nhà cung cấp sẽ chấp thuận tất cả yêu cầu hợp đồng cần thiết để bảo đảm rằng sản phần phần mềm hoặc dịch vụ phần mềm đã chuyển giao đến bên mua sản phẩm được triển khai hoặc thực hiện phù hợp với các yêu cầu trong hợp đồng gốc.

6.1.2.3.4.10. Nhà cung cấp sẽ giao tiếp với đại lý kiểm tra, xác nhận hoặc xác minh độc lập như được chỉ rõ trong hợp đồng và các kế hoạch dự án.

6.1.2.3.4.11. Nhà cung cấp sẽ giao tiếp với các bên tham gia khác như được chỉ rõ trong hợp đồng và các kế hoạch dự án.

6.1.2.3.4.12. Nhà cung cấp nên sắp xếp các hoạt động soát xét hợp đồng, các giao tiếp và thông báo đến tổ chức mua sản phẩm.

6.1.2.3.4.13. Nhà cung cấp sẽ tiến hành hoặc hỗ trợ các cuộc họp không chính thức, soát xét chấp thuận, kiểm tra chấp thuận, các đánh giá chung và kiểm tra đối với bên mua sản phẩm như đã chỉ rõ trong hợp đồng và các kế hoạch dự án. Các đánh giá chung sẽ được tiến hành phù hợp với mục 7.2.6, các kiểm tra phù hợp với mục 7.2.7.

6.1.2.3.4.14. Nhà cung cấp nên thực hiện xác minh và xác nhận phù hợp với mục 7.2.4 và 7.2.5 tương ứng để chứng minh rằng các sản phẩm phần mềm hoặc các dịch vụ phần mềm và các quá trình đáp ứng hoàn toàn từng yêu cầu mong đợi của họ.

6.1.2.3.4.15. Nhà cung cấp sẽ cung cấp cho bên mua sản phẩm các báo cáo đánh giá, soát xét, kiểm tra, thử nghiệm và các phương thức giải quyết vấn đề như đã chỉ rõ trong hợp đồng.

6.1.2.3.4.16. Nhà cung cấp sẽ cung cấp cho bên mua sản phẩm tiếp cận tới phương tiện của nhà cung cấp và nhà thầu phụ để soát xét các sản phẩm phần mềm hoặc các dịch vụ phần mềm như đã chỉ rõ trong hợp đồng và các kế hoạch dự án.

6.1.2.3.4.17. Nhà cung cấp sẽ thực hiện các hoạt động đảm bảo chất lượng phù hợp với mục 7.2.3.

6.1.2.3.5. Hỗ trợ và chuyển giao sản phẩm/dịch vụ

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

6.1.2.3.5.1. Nhà cung cấp sẽ chuyển giao sản phẩm phần mềm hoặc dịch vụ phần mềm như đã chỉ rõ trong hợp đồng.

CHÚ THÍCH: Khi được yêu cầu trong thỏa thuận, nhà cung cấp nên cài đặt sản phẩm phù hợp với các yêu cầu đã được thiết lập.

6.1.2.3.5.2. Nhà cung cấp sẽ cung cấp sự hỗ trợ đến bên mua sản phẩm giúp chuyển giao sản phẩm phần mềm hoặc dịch vụ phần mềm như đã chỉ rõ trong hợp đồng.

6.1.2.3.6. Đóng hợp đồng

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

6.1.2.3.6.1. Nhà cung cấp sẽ chấp thuận và nhận thanh toán hoặc lý do được chấp thuận khác.

6.1.2.3.6.2. Nhà cung cấp sẽ chuyển trách nhiệm với sản phẩm hoặc dịch vụ tới bên mua sản phẩm hoặc bên tham gia khác, như hướng dẫn trong hợp đồng.

CHÚ THÍCH: Thỏa thuận nên đưa ra các điều khoản và thẩm quyền để tiến hành đóng dự án.

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

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

6.2.1.1. Mục đích

Mục đích của quá trình quản lý mô hình vòng đời là để định nghĩa, duy trì và đảm bảo tính khả dụng của các chính sách, các quá trình vòng đời, mô hình vòng đời và các thủ tục cho việc sử dụng bởi tổ chức có liên quan tới phạm vi của tiêu chuẩn này.

Quá trình này cung cấp các thủ tục, quá trình và chính sách vòng đời phù hợp với mục tiêu của của tổ chức, cũng như được định nghĩa, thích ứng, cải thiện và duy trì để hỗ trợ các nhu cầu dự án riêng biệt trong ngữ cảnh một tổ chức và có khả năng được áp dụng sử dụng các công cụ và phương pháp hiệu quả, đã được minh chứng.

6.2.1.2. Kết quả

Kết quả triển khai thành công của quá trình quản lý mô hình vòng đời gồm:

a) Các chính sách và thủ tục cho việc quản lý và phát triển các quá trình và các mô hình vòng đời được cung cấp;

b) Trách nhiệm, trách nhiệm giải trình và thẩm quyền đối với quản lý vòng đời được định nghĩa;

c) Các thủ tục, mô hình và quá trình vòng đời được tổ chức sử dụng, được định nghĩa, duy trì và hoàn thiện;

d) Các cải tiến cho quá trình ưu tiên được triển khai.

6.2.1.3. Hoạt động và nhiệm vụ

Tổ chức 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ó tổ chức có khả năng áp dụng có liên quan tới quá trình quản lý mô hình vòng đời.

6.2.1.3.1. Thiết lập quá trình

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

6.2.1.3.1.1. Tổ chức sẽ thiết lập một tập các quá trình thuộc tổ chức cho tất cả các quá trình vòng đời phần mềm và mô hình vòng đời như đã áp dụng với các hoạt động kinh doanh của họ. Quá trình và ứng dụng của chúng theo các trường hợp cụ thể sẽ được tài liệu hóa trong sách báo xuất bản của tổ chức. Khi thích hợp, cơ chế kiểm soát quá trình nên được thiết lập để phát triển, giám sát, kiểm soát và cải tiến quá trình.

CHÚ THÍCH: Thiết lập cơ chế kiểm soát quá trình bao gồm định nghĩa trách nhiệm, trách nhiệm giải trình và thẩm quyền đối với quản lý vòng đời.

6.2.1.3.2. Đánh giá quá trình

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

6.2.1.3.2.1. Tổ chức nên phát triển, tài liệu hóa và áp dụng thủ tục đánh giá quá trình. Các hồ sơ ghi đánh giá nên được đưa ra và duy trì.

6.2.1.3.2.2. Tổ chức sẽ lập kế hoạch và tiến hành soát xét các quá trình với các khoảng thời gian thích hợp để bảo đảm duy trì tính phù hợp và hiệu quả của chúng dưới sự chân thực của kết quả đánh giá.

6.2.1.3.3. Cải tiến quá trình

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

6.2.1.3.3.1. Tổ chức sẽ thực hiện các cải tiến đối với các quá trình bởi vì tổ chức đó xác định là cần thiết như kết quả của sự soát xét và đánh giá quá trình. Tài liệu hướng dẫn quá trình nên được cập nhật để tham chiếu sự cải tiến trong các quá trình tổ chức.

6.2.1.3.3.2. Dữ liệu đánh giá, kỹ thuật và lịch sử nên được tập hợp và phân tích để đạt được sự hiểu biết về các ưu điểm và nhược điểm của các quá trình được sử dụng. Các phân tích này nên được sử dụng như sự phản hồi để cải tiến các quá trình đó, để khuyến nghị thay đổi trong chỉ dẫn của dự án (hoặc các dự án phát sinh) và để xác định các nhu cầu thúc đẩy công nghệ.

6.2.1.3.3.3. Dữ liệu chi phí chất lượng nên được tập hợp, duy trì và sử dụng để cải tiến các quá trình của tổ chức đó như một hoạt động quản lý. Các dữ liệu đó sẽ đáp ứng được mục đích thiết lập chi phí cho cả việc phòng ngừa và giải quyết các vấn đề và sự không phù hợp trong các sản phẩm phần mềm và dịch vụ phần mềm.

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

6.2.2.1. Mục đích

Mục đích của quá trình quản lý cơ sở hạ tầng là để cung cấp các dịch vụ và cơ sở hạ tầng hỗ trợ cho dự án nhằm hỗ trợ mục tiêu của dự án và tổ chức từ đầu tới cuối vòng đời.

Quá trình này định nghĩa, cung cấp và duy trì các phương tiện, các công cụ, và tài sản công nghệ thông tin và truyền thông cần thiết cho việc kinh doanh của tổ chức trong phạm vi của tiêu chuẩn này.

6.2.2.2. Kết quả

Kết quả triển khai thành công của quá trình quản lý cơ sở hạ tầng gồm:

a) Các yêu cầu cho cơ sở hạ tầng để hỗ trợ các quá trình được định nghĩa;

b) Các thành phần cơ sở hạ tầng được nhận biết và chỉ rõ;

c) Các thành phần cơ sở hạ tầng được mua;

d) Các thành phần cơ sở hạ tầng được triển khai;

e) Cơ sở hạ tầng đáng tin cậy, ổn định được duy trì và cải tiến.

CHÚ THÍCH: Các thành phần cơ sở hạ tầng có thể bao gồm phần cứng, phần mềm, các phương pháp, công cụ, kỹ thuật, tiêu chuẩn và các phương tiện cho sự phát triển, vận hành hoặc duy trì.

6.2.2.3. Hoạt động và nhiệm vụ

Tổ chức 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ó tổ chức có khả năng áp dụng trong quá trình quản lý cơ sở hạ tầng.

6.2.2.3.1. Triển khai quá trình

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

6.2.2.3.1.1. Cơ sở hạ tầng nên được định nghĩa và tài liệu hóa để đáp ứng các yêu cầu của quá trình sử dụng quá trình này, xem xét các kỹ thuật, công cụ, tiêu chuẩn và thủ tục có khả năng áp dụng.

6.2.2.3.1.2. Việc thiết lập cơ sở hạ tầng nên được lập kế hoạch và tài liệu hóa.

6.2.2.3.2. Thiết lập cơ sở hạ tầng

Hoạt động này bao gồm các hoạt động sau:

6.2.2.3.2.1. Việc cấu hình cơ sở hạ tầng nên được lập kế hoạch và tài liệu hóa. Chức năng, khả năng thực hiện, độ tin cậy, tính an toàn, tính khả dụng, các yêu cầu không gian, thiết bị, các chi phí và các ràng buộc thời gian nên được xem xét.

6.2.2.3.2.2. Cơ sở hạ tầng sẽ được thiết lập trong thời gian thực thi của quá trình liên quan.

6.2.2.3.3. Bảo trì cơ sở hạ tầng

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

6.2.2.3.3.1. Cơ sở hạ tầng sẽ được bảo trì, giám sát và chỉnh sửa khi cần để đảm bảo rằng cơ sở hạ tầng tiếp tục đáp ứng các yêu cầu của quá trình sử dụng quá trình này. Như một phần của việc bảo trì cơ sở hạ tầng, phạm vi mà cơ sở hạ tầng thuộc sự quản lý cấu hình sẽ được định nghĩa.

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

6.2.3.1. Mục đích

Mục đích của quá trình quản lý danh mục dự án là để khởi tạo và duy trì các dự án cần thiết, hiệu quả và phù hợp để đáp ứng các mục tiêu chiến lược của tổ chức.

Quá trình này cam kết đầu tư các tài nguyên và kinh phí tổ chức phù hợp và ban hành các thẩm quyền cần thiết để thiết lập các dự án được lựa chọn. Quá trình này thực hiện khả năng duy trì chất lượng các dự án để xác nhận rằng chúng bảo đảm hoặc có thể được thực hiện lại để bảo đảm, sự đầu tư được duy trì.

6.2.3.2. Kết quả

Kết quả triển khai thành công của quá trình quản lý danh mục dự án gồm:

a) Các cơ hội kinh doanh, các đầu tư hoặc những thứ cần thiết được xác định rõ, được ưu tiên và được lựa chọn;

b) Các tài nguyên và ngân sách cho mỗi dự án được xác định và cấp phát;

c) Các thẩm quyền và trách nhiệm giải trình quản lý dự án được định nghĩa;

d) Các dự án đáp ứng các yêu cầu của bên liên quan và bản thỏa thuận được chấp nhận;

e) Các dự án không đáp ứng các yêu cầu của bên liên quan hoặc bản thỏa thuận được thực hiện lại hoặc chấm dứt.

6.2.3.3. Hoạt động và nhiệm vụ

Tổ chức sẽ triển khai các hoạt động và nhiệm vụ sau phù hợp với các thủ tục và chính sách có tổ chức có khả năng áp dụng trong quá trình quản lý danh mục dự án.

6.2.3.3.1. Khởi tạo dự án

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

6.2.3.3.1.1. Tổ chức sẽ xác định, ưu tiên, lựa chọn và thiết lập các cơ hội kinh doanh mới, các liên doanh hoặc doanh nghiệp theo một cách phù hợp với chiến lược kinh doanh và kế hoạch hoạt động của tổ chức đó.

CHÚ THÍCH: Ưu tiên dự án được khởi tạo và thiết lập các ngưỡng giới hạn để xác định dự án nào sẽ được thực thi.

6.2.3.3.1.2. Tổ chức sẽ định nghĩa các trách nhiệm giải trình và thẩm quyền cho mỗi dự án.

6.2.3.3.1.3. Tổ chức sẽ xác định kết quả được kỳ vọng của các dự án.

6.2.3.3.1.4. Tổ chức sẽ phân phối các tài nguyên để đạt được mục tiêu dự án.

6.2.3.3.1.5. Tổ chức sẽ xác định bất kỳ giao diện đa dự án nào phải được dự án quản lý và hỗ trợ.

CHÚ THÍCH: Điều này bao gồm cách sử dụng các hệ thống phụ trợ và các thành phần hệ thống chung được sử dụng nhiều hơn trong một dự án.

6.2.3.3.1.6. Tổ chức sẽ chỉ rõ các mốc soát xét và các yêu cầu báo cáo của dự án sẽ gây ảnh hưởng tới sự thực thi của dự án.

6.2.3.3.1.7. Tổ chức sẽ cấp phép cho dự án để bắt đầu thực thi các kế hoạch dự án được phê chuẩn, bao gồm cả các kế hoạch kỹ thuật.

6.2.3.3.2. Đánh giá danh mục đầu tư

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

6.2.3.3.2.1. Tổ chức sẽ đánh giá các dự án đang diễn ra để khẳng định rằng:

a) Các dự án đang thực hiện tiến độ để đạt được mục đích đã thiết lập;

b) Các dự án đang thực hiện tuân theo chỉ dẫn dự án;

c) Các dự án đang được tiến hành theo các thủ tục và kế hoạch vòng đời hệ thống;

d) Các dự án vẫn còn tồn tại, theo như chỉ định bởi nhu cầu duy trì dịch vụ, việc triển khai sản phẩm thực tế hoặc các lợi ích đầu tư có thể chấp nhận được.

6.2.3.3.2.2. Tổ chức sẽ tác động để duy trì hoặc thực hiện lại dự án đang thực hiện tốt hoặc dự án có thể được mong đợi là thực hiện tốt bằng việc thực hiện lại thích hợp.

6.2.3.3.3. Đóng dự án

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

6.2.3.3.3.1. Tổ chức phải tác động để chấm dứt hoặc đình chỉ dự án khi mức khó khăn hay rủi ro ảnh hưởng đến tổ chức đó lớn hơn lợi ích đầu tư tiếp tục, nếu thỏa thuận cho phép điều đó.

6.2.3.3.3.2. Sau khi hoàn thành thỏa thuận đối với các sản phẩm và dịch vụ, tổ chức phải thực hiện đóng dự án dựa vào bản thỏa thuận và các thủ tục, chính sách của tổ chức.

CHÚ THÍCH 1: Tổ chức đảm bảo rằng việc tổ chức vẫn ghi chép việc lưu giữ tài liệu hướng dẫn sau khi dự án được đóng.

CHÚ THÍCH 2: Sau khi đóng dự án, tổ chức có thể cho phép loại bỏ dự án đó khỏi danh mục dự án.

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

6.2.4.1. Mục đích

Mục đích của quá trình quản lý nguồn nhân lực là để cung cấp cho tổ chức nguồn nhân lực cần thiết và để duy trì năng lực của họ, phù hợp với nhu cầu kinh doanh.

Quá trình đảm bảo việc cung cấp nguồn cung ứng nhân lực có kinh nghiệm và kỹ năng đủ khả năng thực hiện các quá trình vòng đời để đạt được các mục tiêu của khách hàng, của dự án và của tổ chức.

6.2.4.2. Kết quả

Kết quả triển khai thành công của quá trình quản lý nguồn nhân lực gồm:

a) Các kỹ năng được các dự án yêu cầu được xác định;

b) Nguồn nhân lực cần thiết được cung cấp tới các dự án;

c) Các kỹ năng của nhân viên được phát triển, duy trì hoặc nâng cấp;

d) Các xung đột trong các nhu cầu nguồn lực đa dự án được giải quyết;

e) Các kỹ năng, thông tin và tri thức cá nhân được tổng hợp, chia sẻ, tái sử dụng và cải tiến xuyên suốt tổ chức.

6.2.4.3. Hoạt động và nhiệm vụ

Tổ chức phải 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ó tổ chức có khả năng áp dụng trong quá trình quản lý nguồn nhân lực:

6.2.4.3.1. Nhận dạng kỹ năng

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

6.2.4.3.1.1. Việc xem xét các yêu cầu dự án và tổ chức phải được tiến hành để thiết lập và thực hiện cung cấp kịp thời cho việc mua hoặc phát triển các nguồn lực và kỹ năng được yêu cầu bởi nhân viên kỹ thuật và quản lý. Các nhu cầu này có thể được đáp ứng thông qua đào tạo, tuyển dụng hoặc cơ chế phát triển nhân sự khác.

6.2.4.3.1.2. Các loại hình và mức độ của đào tạo và tri thức cần thiết để đáp ứng các yêu cầu dự án và tổ chức sẽ được xác định.

6.2.4.3.2. Phát triển kỹ năng

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

6.2.4.3.2.1. Kế hoạch đào tạo, tiến độ triển khai, yêu cầu nguồn lực và nhu cầu đào tạo, nên được trình bày và tài liệu hóa.

6.2.4.3.2.2. Sách hướng dẫn đào tạo, bao gồm cả tài liệu trình bày được sử dụng trong việc cung cấp quá trình đào tạo nên được phát triển hoặc mua lại.

6.2.4.3.2.3. Kế hoạch đào tạo sẽ được triển khai để cung cấp quá trình đào tạo tới nhân viên. Các hồ sơ lưu trữ quá trình đào tạo nên được duy trì.

6.2.4.3.3. Sự chuẩn bị và thu nhận kỹ năng

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

6.2.4.3.3.1. Thiết lập chương trình có hệ thống cho việc tuyển dụng nhân sự có đủ khả năng đáp ứng các nhu cầu của tổ chức và các dự án. Tạo cơ hội cho sự phát triển sự nghiệp của nhân viên hiện thời.

6.2.4.3.3.2. Định nghĩa tiêu chí khách quan có thể được sử dụng để đánh giá thành tích của nhân viên.

6.2.4.3.3.3. Đánh giá thành tích của nhân viên trên phương diện những đóng góp của họ cho các mục đích của tổ chức hoặc dự án.

6.2.4.3.3.4. Đảm bảo rằng thông tin phản hồi được cung cấp tới nhân viên dựa trên kết quả của bất kỳ đánh giá nào được thực hiện.

6.2.4.3.3.5. Duy trì các hồ sơ lưu trữ đầy đủ thành tích của nhân viên bao gồm cả thông tin về các kỹ năng, quá trình đào tạo hoàn thành và đánh giá thành tích.

6.2.4.3.3.6. Định nghĩa nhu cầu của dự án và của tổ chức cho các nhóm dự án. Định nghĩa các quy tắc hoạt động và cấu trúc nhóm dự án đó.

CHÚ THÍCH: Các xung đột trong nhu cầu nguồn lực đa dự án nên được giải quyết.

6.2.4.3.3.7. Trao quyền cho các nhóm để thực hiện vai trò của họ bằng cách đảm bảo các nhóm có:

a) Sự hiểu biết về vai trò của họ trong dự án đó;

b) Cách nhìn chung hoặc ý thức mối quan tâm chung về sự thành công của dự án;

c) Các phương tiện hoặc cơ chế phù hợp cho việc thông tin và tương tác giữa các nhóm;

d) Sự hỗ trợ từ việc quản lý phù hợp để hoàn thành các yêu cầu dự án.

6.2.4.3.3.8. Nên được đảm bảo rằng quyền lợi tham gia và các loại hình của nhân viên được đào tạo một cách thích hợp là có sẵn cho các nhiệm vụ và hoạt động đã được lập kế hoạch một cách kịp thời.

6.2.4.3.4. Quản lý tri thức

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

6.2.4.3.4.1. Tổ chức phải lập các yêu cầu cho việc quản lý tài sản tri thức của tổ chức. Việc lập kế hoạch này sẽ bao gồm định nghĩa cơ sở hạ tầng và quá trình đào tạo để hỗ trợ người cộng tác và người sử dụng tài sản tri thức của tổ chức đó, gồm sơ đồ phân loại cho việc đánh giá đó và các tiêu chí đánh giá.

6.2.4.3.4.2. Tổ chức phải thiết lập một mạng lưới chuyên gia bên trong tổ chức. Mạng lưới này sẽ bao gồm việc nhận biết các chuyên gia của tổ chức, danh sách lĩnh vực của họ và nhận biết thông tin có sẵn bên trong sơ đồ phân loại, ví dụ: lĩnh vực tri thức. Tổ chức phải đảm bảo rằng mạng lưới được duy trì thừa nhận.

6.2.4.3.4.3. Tổ chức phải thiết lập cơ chế để hỗ trợ trao đổi thông tin giữa các chuyên gia và luồng thông tin giám định từ các dự án của tổ chức. Cơ chế này sẽ hỗ trợ các yêu cầu sửa đổi, lưu trữ và truy cập của tổ chức.

6.2.4.3.4.4. Tổ chức phải tiến hành quản lý cấu hình, tài sản phù hợp với quá trình quản lý cấu hình được chỉ định trong mục 6.4.2.

6.2.4.3.4.5. Tổ chức phải nắm bắt và duy trì thông tin để truy cập đối với mỗi kế hoạch.

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

6.2.5.1. Mục đích

Mục đích của quá trình quản lý chất lượng là để đảm bảo rằng các sản phẩm, dịch vụ và việc triển khai các quá trình vòng đời đáp ứng các mục tiêu chất lượng của tổ chức và đạt được sự hài lòng của khách hàng.

6.2.5.2. Kết quả

Kết quả triển khai thành công của quá trình quản lý chất lượng gồm:

a) Các thủ tục và các chính sách quản lý chất lượng của tổ chức được định nghĩa;

b) Các mục tiêu chất lượng của tổ chức được định nghĩa;

c) Trách nhiệm giải trình và thẩm quyền cho việc quản lý chất lượng được định nghĩa;

d) Trạng thái hài lòng của khách hàng được giám sát;

e) Hoạt động thích hợp được thực hiện khi các mục tiêu chất lượng không đạt được.

6.2.5.3. Hoạt động và nhiệm vụ

Tổ chức phải triển khai các hoạt động và nhiệm vụ phù hợp với các thủ tục và chính sách có tổ chức có khả năng áp dụng trong quá trình quản lý chất lượng.

6.2.5.3.1. Quản lý chất lượng

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

6.2.5.3.1.1. Tổ chức phải thiết lập các thủ tục, tiêu chuẩn và chính sách quản lý chất lượng.

CHÚ THÍCH 1: Mô hình quá trình cho hệ thống quản lý chất lượng có thể được tìm thấy trong tiêu chuẩn TCVN ISO 9001:2000. Đối với tổ chức có mong muốn để làm cho tiêu chuẩn TCVN ISO 9001:2000 tiến xa hơn, trong mục đích cải tiến liên tục về hiệu suất, hướng dẫn được cung cấp trong tiêu chuẩn TCVN ISO 9004:2000.

CHÚ THÍCH 2: Hướng dẫn cho việc áp dụng tiêu chuẩn TCVN ISO 9001:2000 đối với phần mềm có thể được tìm thấy trong tiêu chuẩn ISO/IEC 90003:2004.

6.2.5.3.1.2. Tổ chức phải thiết lập các mục tiêu và mục đích quản lý chất lượng của tổ chức dựa trên chiến lược kinh doanh với mục đích là sự hài lòng của khách hàng.

6.2.5.3.1.3. Tổ chức phải định nghĩa các trách nhiệm và thẩm quyền đối với việc triển khai quá trình quản lý chất lượng.

6.2.5.3.1.4. Tổ chức phải đánh giá và báo cáo mức độ hài lòng của khách hàng.

CHÚ THÍCH: Việc triển khai tiêu chuẩn này cung cấp cho tổ chức một cách tiếp cận để đạt được sự hài lòng của khách hàng.

6.2.5.3.1.5. Tổ chức phải tiến hành soát xét định kỳ đối với các kế hoạch chất lượng của dự án.

CHÚ THÍCH: Đảm bảo rằng các mục tiêu chất lượng dựa trên các yêu cầu của bên liên quan được thiết lập cho mỗi dự án.

6.2.5.3.1.6. Tổ chức phải giám sát tình trạng cải tiến chất lượng trên các sản phẩm và dịch vụ.

6.2.5.3.2. Hoạt động hiệu chỉnh quản lý chất lượng

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

6.2.5.3.2.1. Tổ chức phải đưa ra các hoạt động hiệu chỉnh khi các mục đích quản lý chất lượng không đạt được.

6.2.5.3.2.2.Tổ chức phải triển khai các hoạt động hiệu chỉnh và truyền đạt kết quả thông qua tổ chức.

6.3. Quá trình dự án

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

6.3.1.1. Mục đích

Mục đích của quá trình lập kế hoạch dự án là để đưa ra và truyền đạt các kế hoạch dự án có khả năng thực hiện và có hiệu quả.

Quá trình này xác định phạm vi quản lý dự án và các hoạt động kỹ thuật, nhận biết kết quả quá trình, nhiệm vụ dự án và hạng mục chuyển giao, thiết lập lịch trình cho việc tiến hành nhiệm vụ dự án, bao gồm cả tiêu chí đạt được và tài nguyên được yêu cầu để hoàn thành nhiệm vụ dự án.

6.3.1.2. Kết quả

Kết quả triển khai của quá trình lập kế hoạch dự án gồm:

a) Phạm vi công việc cho dự án được định nghĩa;

b) Tính khả thi để đạt được các mục đích của dự án với các ràng buộc và tài nguyên có sẵn được đánh giá;

c) Các nhiệm vụ và tài nguyên cần thiết để hoàn thành công việc được định cỡ và được đánh giá;

d) Các giao diện giữa các thành phần trong dự án và với các đơn vị tổ chức và dự án khác, được định nghĩa;

e) Kế hoạch cho việc thực thi dự án được phát triển;

f) Kế hoạch cho việc thực thi dự án được khởi động.

6.3.1.3. Hoạt động và nhiệm vụ

Bên quản lý 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ó tổ chức có khả năng áp dụng trong quá trình lập kế hoạch dự án:

6.3.1.3.1. Khởi tạo dự án

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

6.3.1.3.1.1. Bên quản lý sẽ thiết lập các yêu cầu của dự án được đảm nhận.

CHÚ THÍCH: Thiết lập các yêu cầu bao gồm nhận biết các giới hạn, các động cơ thúc đẩy và các mục tiêu của dự án đó.

6.3.1.3.1.2. Một khi các yêu cầu dự án được thiết lập, bên Quản lý phải thiết lập tính khả thi của dự án bằng cách kiểm tra rằng các tài nguyên (nhân lực, các tài liệu, công nghệ và môi trường) được yêu cầu để thực thi và quản lý dự án là có sẵn, đầy đủ và thích hợp và rằng các giai đoạn kế tiếp nhau tới khi hoàn thành là có thể thực hiện được.

6.3.1.3.1.3. Khi cần thiết và theo thỏa thuận của tất cả bên tham gia có liên quan, các yêu cầu của dự án có thể được chỉnh sửa tại thời điểm này để đạt được các tiêu chí hoàn thành.

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

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

6.3.1.3.2.1. Bên quản lý phải chuẩn bị các kế hoạch cho việc thực thi dự án. Các kế hoạch kết hợp với thực thi dự án sẽ bao gồm mô tả các nhiệm vụ, hoạt động liên kết và nhận biết các sản phẩm phần mềm mà sẽ được cung cấp. Các kế hoạch này phải bao gồm, nhưng không giới hạn, các điều sau:

a) Các lịch trình cho việc hoàn thành kịp thời các nhiệm vụ;

b) Đánh giá kết quả đạt được;

c) Các tài nguyên đầy đủ cần thiết để thực thi các nhiệm vụ;

d) Phân phối các nhiệm vụ;

e) Phân công trách nhiệm;

f) Số lượng của các rủi ro liên quan tới các nhiệm vụ hoặc chính quá trình đó;

g) Các biện pháp đảm bảo chất lượng phải được thực hiện xuyên suốt dự án;

h) Các chi phí liên quan tới thực thi quá trình;

i) Sự cung ứng về môi trường và cơ sở hạ tầng;

j) Định nghĩa và duy trì một mô hình vòng đời bao gồm các giai đoạn bằng cách sử dụng các mô hình vòng đời xác định cho các dự án của tổ chức.

CHÚ THÍCH: Các mô hình tổ chức hữu ích cho dự án phải được cung cấp thông qua quá trình quản lý mô hình vòng đời.

6.3.1.3.3. Khởi động dự án

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

6.3.1.3.3.1. Bên quản lý phải đạt được quyền cấp phép cho dự án.

6.3.1.3.3.2. Bên quản lý phải đệ trình các yêu cầu đối với các tài nguyên cần thiết để thực hiện dự án.

6.3.1.3.3.3. Bên quản lý phải bắt đầu việc triển khai kế hoạch dự án để đáp ứng các mục tiêu và bộ tiêu chí, để thực hiện kiểm soát toàn bộ dự án.

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

6.3.2.1. Mục đích

Mục đích của quá trình kiểm soát và đánh giá dự án là để xác định tình trạng dự án và đảm bảo rằng dự án thực hiện theo các kế hoạch, lịch trình và nằm trong ngân sách dự kiến, cũng như đáp ứng các mục tiêu kỹ thuật.

Quá trình này bao gồm việc thực hiện lại các hoạt động dự án, khi thấy thích hợp, để hiệu chỉnh các thay đổi và sai lệch được định nghĩa từ các quá trình kỹ thuật hoặc quản lý dự án. Sự thực hiện lại có thể bao gồm việc lặp lại kế hoạch khi thấy thích hợp.

6.3.2.2. Kết quả

Kết quả triển khai thành công của quá trình kiểm soát và đánh giá dự án gồm:

a) Tiến độ của dự án được giám sát và báo cáo;

b) Các giao diện giữa các thành phần trong dự án và với các đơn vị tổ chức và dự án khác, được giám sát;

c) Các hoạt động để hiệu chỉnh sai lệch so với kế hoạch và để ngăn chặn sự tái diễn các vấn đề được định nghĩa trong dự án được đưa ra khi các mục tiêu dự án không đạt được;

d) Các mục tiêu dự án đạt được và được ghi lại.

6.3.2.3. Hoạt động và nhiệm vụ

Bên quản lý phải 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ó tổ chức có khả năng áp dụng trong quá trình kiểm soát và đánh giá dự án.

6.3.2.3.1. Giám sát dự án

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

6.3.2.3.1.1. Bên quản lý phải giám sát toàn bộ việc thực thi dự án, để cung cấp cả bản báo cáo trong của tiến độ dự án và bản báo cáo ngoài tới bên mua sản phẩm như đã chỉ định trong hợp đồng.

CHÚ THÍCH: Bên quản lý đảm bảo rằng các giao diện thành phần dự án trong, cũng như các giao diện đối với các đơn vị tổ chức và các dự án liên quan khác, được giám sát trong suốt hoạt động này.

6.3.2.3.2. Kiểm soát dự án

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

6.3.2.3.2.1. Bên quản lý phải khảo sát, phân tích và giải quyết các vấn đề được phát hiện ra trong suốt quá trình thực thi dự án. Cách giải quyết vấn đề có thể dẫn đến thay đổi trong các kế hoạch. Đó là trách nhiệm của bên quản lý để đảm bảo ảnh hưởng của bất kỳ sự thay đổi nào được xác định, được kiểm soát và được giám sát. Các vấn đề và cách giải quyết phải được tài liệu hóa.

6.3.2.3.2.2. Bên quản lý phải báo cáo, theo thỏa thuận, tiến độ của dự án, trình sự tuân thủ theo các kế hoạch và giải quyết các trường hợp cá biệt không đạt tiến độ. Báo cáo bao gồm báo cáo trong và báo cáo ngoài theo yêu cầu do hợp đồng và các thủ tục của tổ chức.

6.3.2.3.3. Đánh giá dự án. Hoạt động này bao gồm các nhiệm vụ sau:

6.3.2.3.3.1. Bên quản lý phải đảm bảo rằng các kế hoạch và sản phẩm phần mềm được đánh giá để thỏa mãn các yêu cầu.

6.3.2.3.3.2. Bên quản lý phải đánh giá kết quả đánh giá của các sản phẩm phần mềm, các hoạt động và nhiệm vụ hoàn thành trong suốt quá trình thực thi dự án để đạt được các mục tiêu và hoàn thành các kế hoạch đó.

CHÚ THÍCH: Bên quản lý sử dụng kết quả đánh giá để ngăn chặn sự tái diễn trong tương lai của các vấn đề được xác định trong dự án.

6.3.2.3.4. Đóng dự án

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

6.3.2.3.4.1. Khi tất cả sản phẩm phần mềm, các hoạt động và nhiệm vụ được hoàn thành, bên quản lý phải xác định dự án đã hoàn thành hay chưa, có tính đến các tiêu chí như đã chỉ rõ trong hợp đồng hoặc như một phần thủ tục của tổ chức.

6.3.2.3.4.2. Các hồ sơ lưu trữ và kết quả này phải đạt được trong môi trường thích hợp như đã chỉ rõ trong hợp đồng.

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

6.3.3.1. Mục đích

Mục đích của quá trình quản lý quyết định là để lựa chọn đường lối có lợi nhất cho hoạt động dự án khi mà có các lựa chọn thay thế tồn tại.

Quá trình này đáp ứng yêu cầu cho một quyết định gặp phải trong vòng đời hệ thống, bất kể nguồn gốc hoặc đặc tính của quyết định đó, để đạt được kết quả tối ưu, mong muốn hoặc xác định. Các hoạt động thay thế được phân tích và tiến trình/quá trình được lựa chọn và ra lệnh. Các quyết định và lý do được ghi lại để hỗ trợ việc đưa ra quyết định trong tương lai.

6.3.3.2. Kết quả

Kết quả triển khai thành công của quá trình quản lý quyết định gồm:

a) Chiến lược đưa ra quyết định được định nghĩa;

b) Các đường lối hoạt động thay thế được định nghĩa;

c) Đường lối hoạt động ưu tiên được định nghĩa;

d) Cách giải quyết, lý do quyết định và các giả định được nắm bắt và báo cáo.

6.3.3.3. Hoạt động và nhiệm vụ

Dự án sẽ triển khai các hoạt động và nhiệm vụ sau phù hợp với các thủ tục và chính sách có tổ chức có khả năng được áp dụng trong quá trình quản lý quyết định.

6.3.3.3.1. Lập kế hoạch quyết định

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

6.3.3.3.1.1. Dự án sẽ định nghĩa chiến lược đưa ra quyết định.

CHÚ THÍCH: Điều này bao gồm việc nhận biết các loại hình quyết định và sơ đồ sắp xếp dựa trên sự ưu tiên và nhận biết các bên tham gia chịu trách nhiệm. Người đưa ra quyết định được nhận biết và được trao trách nhiệm và thẩm quyền để đưa ra các quyết định. Các quyết định có thể nảy sinh như kết quả của sự đánh giá tính hiệu quả, một thỏa hiệp kỹ thuật, một vấn đề cần được giải quyết, hành động cần thiết như sự phản ứng lại với rủi ro vượt quá mức ngưỡng có thể chấp nhận, một cơ hội mới hoặc chấp thuận tiến độ dự án đạt tới giai đoạn vòng đời tiếp theo. Chiến lược đưa ra quyết định bao gồm định nghĩa và phân phối trách nhiệm và thẩm quyền để đưa ra, đối với các quyết định.

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

6.3.3.3.1.3. Dự án phải nhận biết các tình huống và sự cần thiết đối với một quyết định.

CHÚ THÍCH: Lưu trữ, phân loại và báo cáo một cách kịp thời các vấn đề hay các cơ hội và tiến trình/quá trình hoạt động thay thế mà sẽ quyết định kết quả của chúng.

6.3.3.3.2. Phân tích quyết định

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

6.3.3.3.2.1. Dự án phải lựa chọn và công bố chiến lược đưa ra quyết định cho mỗi tình huống quyết định. Dự án phải nhận biết kết quả mong muốn và tiêu chí thành công của phép đo.

6.3.3.3.2.2. Dự án phải đánh giá việc cân bằng các hệ quả của các hoạt động thay thế, bằng cách sử dụng chiến lược đưa ra quyết định được định nghĩa, để đạt được tối ưu hóa hoặc cải tiến, của một tình huống quyết định được xác định.

6.3.3.3.3. Theo dõi quyết định

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

6.3.3.3.3.1. Dự án phải ghi lại, theo dõi, đánh giá và báo cáo kết quả quyết định để xác nhận rằng các vấn đề đã được giải quyết một cách hiệu quả, các xu hướng bất lợi đã được loại bỏ và sự thuận lợi đã đạt được từ các cơ hội.

6.3.3.3.3.2. Dự án phải duy trì các hồ sơ lưu trữ các vấn đề và cơ hội và cách xử lý của chúng, theo quy định trong các thỏa thuận hoặc các thủ tục của tổ chức và theo cách mà cho phép việc kiểm tra và học hỏi từ kinh nghiệm.

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

6.3.4.1. Mục đích

Mục đích của quá trình quản lý rủi ro là để nhận dạng, phân tích, xử lý và giám sát liên tục các rủi ro.

Quá trình quản lý rủi ro là quá trình liên tục để giải quyết rủi ro một cách có hệ thống từ đầu tới cuối vòng đời của một hệ thống hoặc sản phẩm hoặc dịch vụ phần mềm. Quá trình này có thể được áp dụng đối với các rủi ro liên quan tới việc mua sản phẩm, phát triển, bảo trì hoặc vận hành của một hệ thống.

6.3.4.2. Kết quả

Kết quả triển khai thành công của quá trình quản lý rủi ro gồm:

a) Phạm vi của việc quản lý rủi ro được định nghĩa;

b) Các chiến lược quản lý rủi ro thích hợp được định nghĩa và được triển khai;

c) Các rủi ro được xuất hiện khi chúng xuất hiện và trong suốt quá trình thực hiện dự án;

d) Các rủi ro được phân tích và thứ tự ưu tiên áp dụng đối với các tài nguyên để xử lý của các rủi ro này được định nghĩa;

e) Các phép đánh giá rủi ro được định nghĩa, áp dụng và đánh giá để xác định các thay đổi trong điều kiện rủi ro và trong quá trình hoạt động xử lý;

f) Việc xử lý thích hợp được đưa ra để hiệu chỉnh hoặc tránh ảnh hưởng của rủi ro dựa trên hệ quả, xác suất và sự ưu tiên hoặc dựa trên mức ngưỡng rủi ro được định nghĩa khác.

6.3.4.3. Hoạt động và nhiệm vụ

Dự án phải triển khai các hoạt động và nhiệm vụ sau phù hợp với các thủ tục và chính sách có tổ chức có khả năng áp dụng trong quá trình quản lý rủi ro.

CHÚ THÍCH: Tiêu chuẩn ISO/IEC 16085:2006, Quá trình quản lý rủi ro, cung cấp một tập chi tiết hơn các hoạt động và nhiệm vụ được sắp xếp tương ứng với các hoạt động và nhiệm vụ được trình bày sau đây.

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

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

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

6.3.4.3.1.2. Mô tả quá trình quản lý rủi ro để triển khai phải được tài liệu hóa.

6.3.4.3.1.3. Trách nhiệm, vai trò và các bên tham gia chịu trách nhiệm thực hiện quản lý rủi ro sẽ được định nghĩa.

6.3.4.3.1.4. Các bên tham gia có trách nhiệm sẽ được cung cấp các tài nguyên đầy đủ để thực hiện quá trình quản lý rủi ro.

6.3.4.3.1.5. Cung cấp mô tả quá trình đánh giá và cải tiến quá trình quản lý rủi ro.

CHÚ THÍCH: Điều này bao gồm sự nắm bắt các bài học kinh nghiệm.

6.3.4.3.2. Quản lý thông tin hiện trạng rủi ro

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

6.3.4.3.2.1. Ngữ cảnh của quá trình quản lý rủi ro phải được định nghĩa và tài liệu hóa.

CHÚ THÍCH: Điều này bao gồm việc mô tả các quan điểm của các bên liên quan, các hạng mục rủi ro và mô tả (có thể bằng tham chiếu) các mục tiêu về quản lý và kỹ thuật, các giả thiết và ràng buộc.

6.3.4.3.2.2. Mức ngưỡng rủi ro, định nghĩa các điều kiện theo đó mức độ rủi ro có thể được chấp nhận, sẽ được tài liệu hóa.

6.3.4.3.2.3. Thông tin hiện trạng rủi ro phải được thiết lập và duy trì.

CHÚ THÍCH: Các hồ sơ lưu trữ thông tin hiện trạng rủi ro: ngữ cảnh quản lý rủi ro; hồ sơ lưu trữ mỗi trạng thái của rủi ro bao gồm cả xác suất, hệ quả và mức ngưỡng rủi ro; sự ưu tiên của mỗi rủi ro dựa trên tiêu chuẩn rủi ro được các bên liên quan cung cấp; các yêu cầu hoạt động rủi ro cùng với trạng thái trong cách xử lý của chúng. Thông tin hiện trạng rủi ro được cập nhật khi có các thay đổi trong trạng thái của mỗi rủi ro riêng. Sự ưu tiên trong thông tin hiện trạng rủi ro được sử dụng để xác định việc sử dụng của các tài nguyên cho việc xử lý.

6.3.4.3.2.4. Các thông tin hiện trạng rủi ro có liên quan phải được thông tin định kỳ tới các bên liên quan dựa trên các nhu cầu của họ.

6.3.4.3.3. Phân tích rủi ro

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

6.3.4.3.3.1. Các rủi ro sẽ được xác định theo sự phân loại được mô tả trong ngữ cảnh quản lý rủi ro.

6.3.4.3.3.2. Xác suất xảy ra và các hệ quả của mỗi rủi ro xác định sẽ được đánh giá.

6.3.4.3.3.3. Mỗi rủi ro sẽ được đánh giá dựa theo các mức ngưỡng rủi ro của chúng.

6.3.4.3.3.4. Đối với mỗi rủi ro trên mức ngưỡng rủi ro, các chiến lược xử lý khuyến nghị sẽ được định nghĩa và tài liệu hóa. Các biện pháp đo cho thấy tính hiệu quả của các lựa chọn cho việc xử lý cũng sẽ được định nghĩa và tài liệu hóa.

CHÚ THÍCH: Các chiến lược xử lý rủi ro bao gồm, nhưng không giới hạn, việc loại bỏ rủi ro đó, giảm thiểu xác suất xảy ra các rủi ro hoặc tính nghiêm trọng của hệ quả hoặc chấp nhận rủi ro.

6.3.4.3.4. Xử lý rủi ro

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

6.3.4.3.4.1. Các bên liên quan sẽ được cung cấp các lựa chọn xử lý rủi ro cho các yêu cầu hoạt động rủi ro.

6.3.4.3.4.2. Nếu các bên liên quan xác định rằng các hoạt động nên được đưa ra để khiến cho rủi ro có thể chấp nhận được, thì sau đó việc lựa chọn xử lý rủi ro sẽ được triển khai.

6.3.4.3.4.3. Nếu các bên liên quan chấp nhận một rủi ro vượt quá mức ngưỡng cho phép, thì rủi ro đó sẽ được coi là có ưu tiên cao hơn và cần được giám sát một cách liên tục để xác định xem hoạt động xử lý rủi ro trong tương lai nào là cần thiết.

6.3.4.3.4.4. Một khi việc xử lý rủi ro được lựa chọn, nó sẽ tiếp nhận các hoạt động quản lý giống như các vấn đề đã làm, phù hợp với các hoạt động kiểm soát và đánh giá trong mục 6.3.2 của tiêu chuẩn này hoặc tiêu chuẩn ISO/IEC 15288:2008.

6.3.4.3.5. Giám sát rủi ro

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

6.3.4.3.5.1. Tất cả ngữ cảnh quản lý rủi ro và các rủi ro sẽ được giám sát một cách liên tục khi có các thay đổi. Các rủi ro phải trải qua việc đánh giá rủi ro khi các trạng thái của chúng có sự thay đổi.

6.3.4.3.5.2. Các phép đo sẽ được triển khai và giám sát để đánh giá tính hiệu quả của các hoạt động xử lý rủi ro.

6.3.4.3.5.3. Dự án phải giám sát một cách liên tục đối với các nguồn phát sinh rủi ro và các rủi ro mới từ đầu tới cuối vòng đời của chúng.

6.3.4.3.6. Đánh giá quá trình quản lý rủi ro

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

6.3.4.3.6.1. Thông tin sẽ được thu thập từ đầu tới cuối vòng đời của dự án cho các mục đích cải tiến quá trình quản lý rủi ro và đưa ra các bài học kinh nghiệm.

CHÚ THÍCH: Thông tin rủi ro bao gồm các rủi ro được định nghĩa, các nguồn phát sinh, nguyên nhân, hoạt động xử lý chúng và sự thành công của các hoạt động xử lý được lựa chọn.

6.3.4.3.6.2. Quá trình quản lý rủi ro sẽ được soát xét định kỳ để đạt được hiệu suất và tính hiệu quả của quá trình đó.

6.3.4.3.6.3. Thông tin về các rủi ro được xác định, hoạt động xử lý và sự thành công của các hoạt động xử lý sẽ được soát xét định kỳ cho mục đích nhận biết các rủi ro của tổ chức và dự án hệ thống.

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

6.3.5.1. Mục đích

Mục đích của quá trình quản lý cấu hình là để thiết lập và duy trì tính toàn vẹn của tất cả kết quả xác định của một dự án hoặc một quá trình và để làm cho chúng khả dụng đối với các bên tham gia quan tâm.

6.3.5.2. Kết quả

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

a) Chiến lược quản lý cấu hình được định nghĩa;

b) Các thành phần yêu cầu quản lý cấu hình được định nghĩa;

c) Các giới hạn cơ bản cấu hình được thiết lập;

d) Các sự thay đổi tới các thành phần dưới sự quản lý cấu hình được kiểm soát;

e) Cấu hình của các thành phần phát hành được kiểm soát;

f) Trạng thái của các thành phần dưới sự quản lý cấu hình là khả dụng từ đầu tới cuối vòng đời.

CHÚ THÍCH: Quá trình quản lý cấu hình vòng đời phần mềm là một cụ thể hóa của quá trình quản lý cấu hình và được bao gồm trong nhóm quá trình hỗ trợ phần mềm.

6.3.5.3. Hoạt động và nhiệm vụ

Dự án phải triển khai các hoạt động và nhiệm vụ sau phù hợp với các thủ tục và chính sách tổ chức có khả năng áp dụng trong quá trình quản lý cấu hình.

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

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

6.3.5.3.1.1. Dự án phải xác định chiến lược quản lý cấu hình.

CHÚ THÍCH: Điều này bao gồm việc định nghĩa các thẩm quyền cho việc loại bỏ, tiếp cận, phát hành, kiểm soát các thay đổi đến các thành phần cấu hình; định nghĩa các vị trí và điều kiện lưu trữ, môi trường của chúng và, trong trường hợp thông tin, phương tiện lưu trữ, phù hợp với các mức chỉ định của tính toàn vẹn, tính an toàn và độ tin cậy; định nghĩa các tiêu chí hoặc các sự kiện để bắt đầu kiểm soát cấu hình và duy trì các giới hạn cơ bản của các cấu hình triển khai và định nghĩa chiến lược kiểm tra và các trách nhiệm để đảm bảo tính an toàn và tính toàn vẹn liên tục của thông tin định nghĩa cấu hình. Các hoạt động quản lý cấu hình nên tương thích với sự hướng dẫn được cung cấp trong tiêu chuẩn TCVN ISO 10007.

6.3.5.3.1.2. Dự án phải chỉ rõ các thành phần phụ thuộc vào việc kiểm soát cấu hình.

CHÚ THÍCH: Các thành phần được các nhãn hoặc ký hiệu nhận dạng lâu dài và duy nhất phân biệt, nếu thích hợp. Các ký hiệu nhận dạng phù hợp với các ký hiệu quy ước trong lĩnh vực sản phẩm và các tiêu chuẩn có liên quan, như các thành phần dưới sự kiểm soát cấu hình có thể chỉ ra một cách rõ ràng các đặc điểm kỹ thuật của chúng hoặc mô tả được dẫn ra bằng tài liệu tương đương.

6.3.5.3.2. Thực thi quản lý cấu hình

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

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

CHÚ THÍCH: Điều này bao gồm việc tính đến bản chất của các thành phần dưới sự kiểm soát cấu hình. Các mô tả cấu hình phù hợp, nếu khả thi, với các tiêu chuẩn công nghệ hoặc sản phẩm. Có thể đảm bảo rằng thông tin cấu hình cho phép khả năng theo dõi trước và sau đối với các trạng thái cấu hình giới hạn cơ bản khác. Củng cố các trạng thái cấu hình triển khai của các thành phần cấu hình để tạo thành các giới hạn cơ bản được tài liệu hóa tại các thời điểm được chỉ định hoặc dưới các trường hợp cụ thể. Ghi lại việc phân tích nguồn gốc đối với giới hạn cơ bản và các thẩm quyền liên quan trong dữ liệu giới hạn cơ bản cấu hình. Duy trì các hồ sơ lưu trữ cấu hình thông qua vòng đời hệ thống và lưu trữ chúng theo các thỏa thuận, điều luật có liên quan hoặc theo công nghệ kỹ thuật tốt nhất.

6.3.5.3.2.2. Dự án phải đảm bảo rằng các thay đổi tới các giới hạn cơ bản cấu hình được xác minh, bổ sung, chấp thuận, đánh giá, ghi lại và định nghĩa một cách đúng đắn.

CHÚ THÍCH: Củng cố các trạng thái cấu hình triển khai của các thành phần cấu hình để tạo thành các giới hạn cơ bản được tài liệu hóa tại các thời điểm được chỉ định hoặc dưới các trường hợp cụ thể. Ghi lại các bước cấu hình, cách phân tích nguồn gốc đối với giới hạn cơ bản và các thẩm quyền liên quan trong dữ liệu giới hạn cơ bản cấu hình. Duy trì các hồ sơ lưu trữ cấu hình thông qua vòng đời hệ thống và lưu trữ chúng theo các thỏa thuận, điều luật có liên quan hoặc quá trình công nghệ kỹ thuật tốt nhất. Quản lý việc ghi lại, sửa đổi và củng cố trạng thái cấu hình đang thực hiện và trạng thái của tất cả các cấu hình có trước đó để xác nhận tính an toàn, tính toàn vẹn, tính kịp thời và tính đúng đắn của thông tin. Thực hiện các quá trình kiểm tra để xác minh sự phù hợp của một giới hạn cơ bản đối với các bản vẽ, các tài liệu kiểm soát giao diện và các yêu cầu thỏa thuận khác.

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

6.3.6.1. Mục đích

Mục đích của quá trình quản lý thông tin là để cung cấp thông tin mật, hợp lệ, đầy đủ, kịp thời và thích hợp, nếu cần thiết, tới các bên tham gia được chỉ định trong và sau quá trình vòng đời, khi thấy thích hợp.

Quá trình này tạo ra, thu thập, chuyển đổi, ghi nhớ, sửa đổi, phổ biến và hủy bỏ thông tin. Đồng thời quản lý thông tin được chỉ định, bao gồm cả thông tin người sử dụng, thông tin thỏa thuận, thông tin tổ chức, thông tin dự án và thông tin kỹ thuật.

6.3.6.2. Kết quả

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

a) Thông tin được quản lý được xác định;

b) Các hình thức của các miêu tả thông tin được định nghĩa;

c) Thông tin được chuyển đổi và được hủy bỏ theo yêu cầu;

d) Tình trạng của thông tin được ghi lại;

e) Thông tin phải đang lưu hành, đầy đủ và hợp lệ;

f) Thông tin là khả dụng cho các bên tham gia được ấn định.

CHÚ THÍCH: Quá trình quản lý tài liệu hướng dẫn phần mềm là một cụ thể hóa của quá trình quản lý thông tin và được bao gồm trong nhóm quá trình hỗ trợ phần mềm.

6.3.6.3. Hoạt động và nhiệm vụ

Dự án phải triển khai các hoạt động và nhiệm vụ sau phù hợp với các thủ tục và chính sách có tổ chức có khả năng áp dụng trong quá trình quản lý thông tin.

CHÚ THÍCH: Tiêu chuẩn ISO/IEC 15289 tóm tắt các yêu cầu đối với các thành phần thông tin (tài liệu hướng dẫn) và cung cấp hướng dẫn về sự phát triển của chúng.

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

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

6.3.6.3.1.1. Dự án phải định nghĩa các thành phần thông tin mà sẽ được quản lý trong vòng đời hệ thống, theo điều luật hoặc chính sách tổ chức và được duy trì cho một thời hạn kéo dài hơn nữa được định nghĩa.

6.3.6.3.1.2. Dự án phải định rõ các thẩm quyền và các trách nhiệm có liên quan tới nguồn gốc, sự hình thành, thu thập, lưu trữ và hủy bỏ các thành phần thông tin.

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

CHÚ THÍCH: Sự quan tâm chú ý tới tính riêng tư, tính an toàn và pháp luật về dữ liệu và thông tin, ví dụ: đồng sở hữu, các hạn chế của thỏa thuận, các quyền truy cập, sở hữu trí tuệ và các bằng sáng chế. Trong trường hợp các hạn chế hoặc các ràng buộc áp dụng, thông tin được định nghĩa một cách thích hợp. Nhân viên có kiến thức về các thành phần thông tin được thông báo về các trách nhiệm và các nghĩa vụ của họ.

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

CHÚ THÍCH: Thông tin có thể khởi đầu và có thể kết thúc dưới bất kỳ hình thức nào (ví dụ: bằng lời nói, bằng văn bản, bằng đồ họa hoặc bằng số) và có thể được lưu trữ, xử lý, sao chép và truyền đạt bằng cách sử dụng bất kỳ phương tiện nào (ví dụ: điện tử, in, từ, quang), cần chú ý đến các điều kiện của tổ chức, ví dụ: cơ sở hạ tầng, các truyền thông liên tổ chức, các hoạt động dự án được phân phối. Các thỏa thuận và các tiêu chuẩn trình bày, truyền đạt, chuyển đổi và lưu trữ thông tin liên quan được sử dụng phù hợp với chính sách, các yêu cầu và các ràng buộc về luật.

6.3.6.3.1.5. Dự án phải định nghĩa các hoạt động duy trì thông tin.

CHÚ THÍCH: Điều này bao gồm soát xét trạng thái của thông tin lưu trữ về tính nguyên vẹn, tính hợp lệ và tính khả thi và các nhu cầu bất kỳ cho việc sao chép hoặc chuyển đổi theo một phương tiện lựa chọn. Xem xét nhu cầu giữ lại cơ sở hạ tầng khi công nghệ thay đổi để phương tiện lưu trữ có thể được đọc hoặc nhu cầu ghi lại phương tiện ghi lưu trữ sử dụng công nghệ mới.

6.3.6.3.2. Thực thi quản lý thông tin