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

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

6.3.6.3.2.1. Dự án phải thu được các thành phần thông tin xác định.

CHÚ THÍCH: Điều này có thể bao gồm việc tạo ra thông tin hoặc thu thập thông tin từ các nguồn thích hợp.

6.3.6.3.2.2. Dự án phải duy trì các thành phần thông tin và các hồ sơ lưu trữ của chúng theo các yêu cầu riêng tư, an toàn và toàn vẹn.

CHÚ THÍCH: Lưu trữ trạng thái của các thành phần thông tin, ví dụ: mô tả phiên bản, hồ sơ lưu trữ phân phối, phân loại an toàn. Thông tin nên rõ ràng và được lưu trữ và giữ theo một cách có thể lấy ra dễ dàng tại các phương tiện mà cung cấp một môi trường phù hợp và ngăn chặn thiệt hại, hư hỏng và mất mát.

6.3.6.3.2.3. Dự án phải lấy và phân phối thông tin tới các bên tham gia được định rõ khi được yêu cầu bởi các lịch trình đã thỏa thuận hay các trường hợp cụ thể.

CHÚ THÍCH: Thông tin được cung cấp tới các bên tham gia xác định theo một hình thức phù hợp.

6.3.6.3.2.4. Dự án phải cung cấp tài liệu hướng dẫn chính thức theo yêu cầu.

CHÚ THÍCH: Các ví dụ về tài liệu hướng dẫn chính thức như chứng thư, chứng chỉ cấp phép, giấy phép hướng dẫn và các bảng xếp hạng đánh giá.

6.3.6.3.2.5. Dự án phải lưu trữ thông tin được chỉ định, phù hợp với sự kiểm tra, lưu giữ tri thức và các mục đích đóng dự án.

CHÚ THÍCH: cần lựa chọn phương tiện ghi, vị trí và cách bảo vệ thông tin phù hợp với bộ nhớ cụ thể và các chu kỳ sửa đổi và phù hợp với điều luật, các yêu cầu và chính sách của tổ chức. Đảm bảo các cách sắp xếp tại nơi thích hợp để lưu giữ các tài liệu hướng dẫn cần thiết sau khi đóng dự án.

6.3.6.3.2.6. Dự án phải hủy bỏ thông tin chưa được xác minh, không có hiệu lực hoặc không có giá trị theo chính sách tổ chức và các yêu cầu về tính riêng tư và tính an toàn.

6.3.7. Quá trình đo

6.3.7.1. Mục đích

Mục đích của quá trình đo là để thu thập, phân tích và báo cáo dữ liệu có liên quan đến các sản phẩm được phát triển và các quá trình được triển khai trong đơn vị tổ chức, để hỗ trợ quản lý hiệu quả các quá trình và để chứng minh một cách khách quan chất lượng của các sản phẩm.

6.3.7.2. Kết quả

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

a) Các nhu cầu thông tin kỹ thuật và các quá trình quản lý được xác định;

b) Một tập các phép đo thích hợp, thúc đẩy bởi các nhu cầu thông tin được định nghĩa và/hoặc phát triển;

c) Các hoạt động đo được định nghĩa và lập kế hoạch:

d) Dữ liệu cần thiết được thu thập, lưu trữ, phân tích và kết quả được làm rõ;

e) Các sản phẩm thông tin được sử dụng để hỗ trợ các quyết định và cung cấp mục tiêu cơ bản cho truyền thông;

f) Quá trình đo và các phép đo được đánh giá;

g) Các cải tiến được truyền tới bên sở hữu quá trình đo.

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

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

CHÚ THÍCH 1: Tiêu chuẩn ISO/IEC 15939 cung cấp một tập các hoạt động và nhiệm vụ chi tiết hơn được đượ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.

CHÚ THÍCH 2: Điều 8 của tiêu chuẩn TCVN ISO 9001:2000 chỉ rõ các yêu cầu hệ thống quản lý chất lượng đối với việc đo và giám sát các quá trình và các sản phẩm.

6.3.7.3.1. Lập kế hoạch đo

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

6.3.7.3.1.1. Dự án phải mô tả các đặc tính của tổ chức liên quan tới việc đo.

6.3.7.3.1.2. Dự án phải nhận biết và ưu tiên các nhu cầu thông tin.

6.3.7.3.1.3. Dự án phải lựa chọn và tài liệu hóa các phép đo đáp ứng các nhu cầu thông tin.

6.3.7.3.1.4. Dự án phải định nghĩa các thủ tục báo cáo, phân tích, thu thập dữ liệu.

6.3.7.3.1.5. Dự án phải định nghĩa tiêu chí để đánh giá các sản phẩm thông tin và quá trình đo.

6.3.7.3.1.6. Dự án phải soát xét, chấp thuận và cung cấp các tài nguyên cho các nhiệm vụ do.

6.3.7.3.1.7. Dự án phải mua và triển khai các công nghệ hỗ trợ.

6.3.7.3.2. Thực hiện đo

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

6.3.7.3.2.1. Dự án phải bổ sung các thủ tục báo cáo, phân tích, thu thập và tạo dữ liệu vào các quá trình liên quan.

6.3.7.3.2.2. Dự án phải thu thập, lưu trữ và xác minh dữ liệu.

6.3.7.3.2.3. Dự án phải phân tích dữ liệu và phát triển các sản phẩm thông tin.

6.3.7.3.2.4. Dự án phải tài liệu hóa và truyền thông kết quả tới người sử dụng quá trình đo. 6.3.7.3.3. Đánh giá quá trình đo

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

6.3.7.3.3.1. Dự án phải đánh giá các sản phẩm thông tin và quá trình đo.

6.3.7.3.3.2. Dự án phải nhận biết và truyền đạt các cải tiến tiềm năng.

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

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

CHÚ THÍCH: Quá trình định nghĩa các yêu cầu của bên liên quan trong tiêu chuẩn này là một cụ thể hóa củ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. Người sử dụng có thể xem xét xác nhận tuân thủ với quá trình 15288 hơn là quá trình trong tiêu chuẩn này.

6.4.1.1. Mục đích

Mục đích của quá trình định nghĩa các yêu cầu của bên liên quan là để định nghĩa các yêu cầu đối với một hệ thống có thể cung cấp các dịch vụ được người sử dụng và các bên liên quan khác yêu cầu trong một môi trường xác định.

Quá trình này xác định các bên liên quan hoặc các loại hình bên liên quan tham gia từ đầu tới cuối vòng đời của một hệ thống và các mong muốn, nhu cầu của các bên liên quan. Nó phân tích và chuyển đổi các thông tin đó thành một tập các yêu cầu chung của bên liên quan, các yêu cầu này thể hiện sự tương tác dự định đối với hệ thống cùng với môi trường vận hành của hệ thống và là một bộ tham chiếu dựa vào mỗi kết quả của dịch vụ vận hành được công nhận để xác nhận rằng hệ thống đáp ứng đầy đủ các nhu cầu.

6.4.1.2. Kết quả

Kết quả triển khai thành công của quá trình định nghĩa các yêu cầu của bên liên quan gồm:

a) Các đặc tính yêu cầu và ngữ cảnh sử dụng của các dịch vụ được chỉ rõ;

b) Các ràng buộc vào giải pháp hệ thống được định nghĩa;

c) Khả năng kiểm soát các yêu cầu bên liên quan đối với các bên liên quan và các nhu cầu của họ được thực hiện;

d) Cơ sở để định nghĩa các yêu cầu hệ thống được mô tả;

e) Cơ sở để xác nhận sự tuân thủ dịch vụ được định nghĩa;

f) Cơ sở cho việc đàm phán và thỏa thuận để cung cấp dịch vụ hoặc sản phẩm được cung cấp.

6.4.1.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 định nghĩa các yêu cầu của bên liên quan.

6.4.1.3.1. Nhận biết bên liên quan

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

6.4.1.3.1.1. Dự án phải xác định các bên liên quan riêng biệt hoặc các loại hình bên liên quan hợp pháp tham gia từ đầu tới cuối vòng đời của một hệ thống.

CHÚ THÍCH: Điều này bao gồm, nhưng không giới hạn, người sử dụng, bên vận hành, bên hỗ trợ, bên phát triển, nhà sản xuất, bên đào tạo, bên bảo trì, bên xử lý, các tổ chức cung cấp và mua sản phẩm, các bên tham gia chịu trách nhiệm đối với các thực thể giao diện ngoài, các thành viên và các cơ quan quản lý xã hội. Trong trường hợp truyền thông trực tiếp không thực hiện được, ví dụ: đối với các dịch vụ và các sản phẩm tiêu dùng, thì các bên liên quan ủy nhiệm được chỉ định hoặc đại diện được lựa chọn.

6.4.1.3.2. Nhận biết các yêu cầu

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

6.4.1.3.2.1. Dự án sẽ gợi ý các yêu cầu của bên liên quan

CHÚ THÍCH: Các yêu cầu của bên liên quan mô tả các nhu cầu, sự cần thiết, mong muốn, kỳ vọng và các ràng buộc lĩnh hội được của các bên liên quan xác định. Chúng được mô tả bằng mô hình nguyên bản hoặc chính thức, tập trung vào cách hoạt động và mục đích của hệ thống và được mô tả trong ngữ cảnh các điều kiện và môi trường hoạt động. Một mô hình chất lượng sản phẩm và các yêu cầu chất lượng, như trong tiêu chuẩn ISO/IEC 9126-1 và ISO/IEC 25030, có thể hữu ích đối với việc trợ giúp hoạt động này. Các yêu cầu của bên liên quan bao gồm các nhu cầu và các yêu cầu bắt buộc phù hợp với xã hội, các ràng buộc bắt buộc phù hợp với một tổ chức mua sản phẩm, các đặc tính vận hành và năng lực của người sử dụng và nhân viên vận hành. Nó hữu ích để trích dẫn các nguồn, bao gồm cả các thỏa thuận và các tài liệu cần thiết, lý do cơ bản và lý lẽ biện hộ của họ, các giả định của các bên liên quan và tiêu chuẩn mà họ kỳ vọng vào sự đáp ứng các yêu cầu của họ. Đối với các nhu cầu của bên liên quan quan trọng, các phép đo tính hiệu quả được định nghĩa để việc thực hiện hoạt động có thể được đo và đánh giá. Nếu các rủi ro quan trọng có thể phát sinh từ các vấn đề (ví dụ: các nhu cầu, sự cần thiết, các ràng buộc, giới hạn, các thành phần liên quan, các màng chắn, các chỉ số hoặc các nghiên cứu) liên quan tới người sử dụng và các bên liên quan khác và sự tương tác hoặc sự tham gia của họ trong một hệ thống ở bất kỳ thời điểm nào trong vòng đời hệ thống đó, các khuyến nghị đối với các vấn đề tương tác người hệ thống nhận biết và xử lý có thể được tìm thấy trong tiêu chuẩn ISO PAS 18152, đặc tả đối với việc đánh giá quá trình của các vấn đề tương tác người hệ thống.

6.4.1.3.2.2. Dự án phải định nghĩa các ràng buộc vào giải pháp hệ thống mà không thể tránh khỏi kết quả của thỏa thuận hiện có, các quyết định quản lý và các quyết định kỹ thuật.

CHÚ THÍCH: Đây có thể là kết quả từ 1) các trường hợp và các phạm vi của giải pháp được bên liên quan định nghĩa; 2) các quyết định triển khai được thực hiện ở các mức độ cao hơn của cấu trúc phân cấp hệ thống; 3) cách sử dụng được yêu cầu của các hệ thống phụ trợ xác định, tài nguyên và nhân viên.

6.4.1.3.2.3. Dự án phải định nghĩa một tập điển hình các chuỗi hoạt động để nhận biết tất cả các dịch vụ được yêu cầu phù hợp với các môi trường và kịch bản hỗ trợ, vận hành đã biết trước.

CHÚ THÍCH: Các kịch bản được sử dụng để phân tích việc vận hành của hệ thống theo trình tự trong môi trường dự kiến của nó và để nhận biết các yêu cầu có thể không được bên liên quan bất kỳ định nghĩa một cách chính thức, ví dụ: pháp luật, bên quản lý và các trách nhiệm xã hội. Ngữ cảnh sử dụng hệ thống được định nghĩa và phân tích. Bao gồm trong việc phân tích ngữ cảnh các hoạt động mà người sử dụng thực hiện để đạt được các mục đích hệ thống, các đặc tính liên quan của người sử dụng đầu cuối của hệ thống (ví dụ: đào tạo dự kiến, mức độ chịu đựng), môi trường vật lý (ví dụ: ánh sáng, nhiệt độ thích hợp) và bất kỳ thiết bị nào được sử dụng (ví dụ: thiết bị truyền thông hoặc thiết bị bảo vệ). Các ảnh hưởng của tổ chức và xã hội với người sử dụng có thể tác động lên việc sử dụng hệ thống hoặc ràng buộc thiết kế của nó được phân tích khi có khả năng áp dụng.

Dự án phải nhận biết sự tương tác giữa người sử dụng và hệ thống, có tính đến các khả năng của con người và các hạn chế về kỹ năng.

CHÚ THÍCH 1: Các yêu cầu tính khả dụng được xác định, thiết lập, một cách tối thiểu, sự tương tác người hệ thống và hiệu năng của con người một cách tin cậy và hiệu quả nhất. Nếu có thể, các tiêu chuẩn có khả năng áp dụng, ví dụ ISO 9241 và các bài thực hành chuyên nghiệp được phép sử dụng để định nghĩa:

a) Các khả năng học hỏi, nhận thức và thể chất;

b) Nơi làm việc, môi trường và các phương tiện, bao gồm cả thiết bị khác trong ngữ cảnh sử dụng;

c) Các điều kiện khẩn cấp, đặc biệt và bình thường;

d) Tu dưỡng, đào tạo và tuyển dụng người sử dụng và bên vận hành.

CHÚ THÍCH 2: Nếu tính khả dụng quan trọng, các yêu cầu tính khả dụng nên được lập kế hoạch, xác định và triển khai trong suốt quá trình vòng đời và các báo cáo kỹ thuật hoặc các tiêu chuẩn sau có khả năng áp dụng để thu được mức độ mong muốn về tính khả dụng: 180 9241-11:1998, ISO 13407:1999, ISO/TR 18529. Phụ lục E bao gồm tổng quan quá trình tập trung vào tính khả dụng.

6.4.1.3.2.5. Dự án phải xác định rõ sức khỏe, độ tin cậy, tính an toàn, môi trường, và các chức năng và các yêu cầu của bên liên quan khác, liên quan tới các phẩm chất quan trọng và sẽ có trách nhiệm giải quyết các ảnh hưởng bất lợi trong cách sử dụng hệ thống đến sự an toàn và sức khỏe con người.

CHÚ THÍCH: Nhận biết rủi ro đáng tin cậy, nếu được đảm bảo, xác định các yêu cầu và các chức năng để cung cấp độ tin cậy. Điều này bao gồm các rủi ro liên quan với các phương pháp hoạt động và hỗ trợ, sức khỏe và độ tin cậy, đe dọa tới đặc tính và các tác động môi trường. Sử dụng các tiêu chuẩn có thể có khả năng áp dụng, ví dụ: IEC 61508 và các bài kiểm tra chuyên môn đã được công nhận. Nhận biết rủi ro an toàn, nếu được đảm bảo, định nghĩa tất cả phạm vi an toàn hệ thống có thể có khả năng áp dụng, bao gồm vùng vật lý, thủ tục, các truyền thông, máy tính, chương trình, dữ liệu và các môi trường truyền. Nhận biết các chức năng có thể tác động tới tính an toàn của hệ thống, bao gồm việc truy nhập và làm tổn hại tới thông tin, các đặc tính và người được bảo vệ, gây tổn hại thông tin nhạy cảm và phủ nhận sự truy nhập hợp pháp tới đặc tính và thông tin. Nhận biết các chức năng an toàn cần thiết, bao gồm sự giảm thiểu và ngăn chặn, bằng cách tham chiếu các tiêu chuẩn có khả năng áp dụng và các bài kiểm tra chuyên môn đã được công nhận bắt buộc hoặc có liên quan.

6.4.1.3.3. Đánh giá các yêu cầu

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

6.4.1.3.3.1. Dự án phải phân tích một tập hoàn chỉnh các yêu cầu đã được luận ra.

CHÚ THÍCH: Việc phân tích bao gồm việc nhận biết và ưu tiên các yêu cầu không thể xác minh, không phù hợp, không nhất quán, không rõ ràng, không đầy đủ, thiếu sót hoặc mâu thuẫn.

6.4.1.3.4. Thỏa thuận các yêu cầu

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

6.4.1.3.4.1. Dự án phải giải quyết các vấn đề của các yêu cầu.

CHÚ THÍCH: Điều này bao gồm các yêu cầu không thể được xác nhận rõ hoặc không thực tế để thực hiện.

6.4.1.3.4.2. Dự án phải phản hồi các yêu cầu được phân tích đến các bên liên quan có khả năng áp dụng nhằm đảm bảo rằng các nhu cầu và các kỳ vọng đã được nắm bắt và mô tả tương xứng.

CHÚ THÍCH: Giải thích và đạt được thỏa thuận đối với các đề xuất này để giải quyết các yêu cầu không thể thực hiện được, không thực tế và mâu thuẫn của bên liên quan.

6.4.1.3.4.3. Dự án phải xác minh với các bên liên quan rằng các yêu cầu của họ được mô tả một cách đúng đắn

CHÚ THÍCH: Điều này bao gồm việc khẳng định rằng các yêu cầu của bên liên quan có thể hiểu theo bên khởi tạo và khẳng định rằng việc giải quyết các mâu thuẫn trong các yêu cầu không làm thay đổi hoặc làm tổn hại các dự định của bên liên quan.

6.4.1.3.5. Ghi lại yêu cầu

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

6.4.1.3.5.1. Dự án phải ghi lại các yêu cầu của bên liên quan theo một hình thức phù hợp đối với việc quản lý các yêu cầu trong suốt vòng đời.

CHÚ THÍCH: Các bản ghi hồ sơ này thiết lập giới hạn cơ bản các yêu cầu của bên liên quan, và giữ lại các thay đổi cần thiết và nguyên gốc của chúng từ đầu tới cuối vòng đời hệ thống. Chúng là cơ sở cho khả năng theo dõi các yêu cầu hệ thống và tạo thành một nguồn kiến thức đối với các yêu cầu của các hệ thống tiếp sau và thông tin tới các bên liên quan tình trạng của các yêu cầu.

6.4.1.3.5.2. Dự án phải duy trì khả năng theo dõi các yêu cầu của bên liên quan theo các nguồn cần thiết của bên liên quan.

CHÚ THÍCH: Các yêu cầu của bên liên quan được xem xét tại các thời điểm quyết định quan trọng trong vòng đời để đảm bảo rằng hồ sơ ghi lại được bất kỳ thay đổi cần thiết nào.

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

CHÚ THÍCH: Quá trình phân tích các yêu cầu hệ thống trong tiêu chuẩn này là một cụ thể hóa của quá trình phân tích các yêu cầu trong tiêu chuẩn ISO/IEC 15288. Người sử dụng có thể xem xét yêu cầu tuân thủ với quá trình 15288 hơn quá trình trong tiêu chuẩn này.

6.4.2.1. Mục đích

Mục đích của việc phân tích các yêu cầu hệ thống là để chuyển đổi các yêu cầu của bên liên quan xác định thành một tập các yêu cầu kỹ thuật hệ thống mong muốn mà tập các yêu cầu đó sẽ là bản hướng dẫn cho việc thiết kế hệ thống.

6.4.2.2 Kết quả

Kết quả triển khai thành công của quá trình phân tích các yêu cầu hệ thống gồm:

a) Một tập xác định các yêu cầu thuộc chức năng hệ thống và không thuộc chức năng hệ thống mô tả vấn đề cần được giải quyết được thiết lập;

b) Các kỹ thuật phù hợp được thực hiện để tối ưu hóa giải pháp dự án được đưa ra;

c) Các yêu cầu hệ thống được phân tích về tính đúng đắn và khả năng kiểm tra;

d) Ảnh hưởng của các yêu cầu hệ thống vào môi trường vận hành được hiểu rõ;

e) Các yêu cầu được ưu tiên, chấp thuận và được cập nhật khi cần thiết;

f) Tính kiên định và khả năng theo dõi được thiết lập giữa giới hạn cơ bản các yêu cầu của khách hàng và các yêu cầu của hệ thống;

g) Các thay đổi tới giới hạn cơ bản được đánh giá về ảnh hưởng kỹ thuật, thời hạn và chi phí;

h) Các yêu cầu hệ thống được giới hạn cơ bản và thông báo tới tất cả các bên tham gia chịu ảnh hưởng.

6.4.2.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 phân tích các yêu cầu hệ thống.

6.4.2.3.1. Đặc tả các yêu cầu

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

6.4.2.3.1.1. Cách sử dụng dự kiến cụ thể của hệ thống được phát triển phải được phân tích chỉ rõ các yêu cầu của hệ thống. Các đặc tính của các yêu cầu hệ thống phải mô tả: các chức năng và các khả năng của hệ thống; các yêu cầu của người sử dụng, tổ chức, doanh nghiệp; các yêu cầu bảo trì, vận hành, giao diện, kỹ thuật có tính đến nhân tố con người (tối ưu yếu tố con người), độ tin cậy, tính an toàn; các yêu cầu chất lượng và các ràng buộc thiết kế. Việc đặc tả các yêu cầu hệ thống phải được tài liệu hóa.

CHÚ THÍCH 1: Các kỹ thuật phù hợp phải được thực hiện để tối ưu hóa giải pháp đưa ra.

CHÚ THÍCH 2: Ảnh hưởng của các yêu cầu hệ thống vào môi trường vận hành nên được hiểu rõ.

CHÚ THÍCH 3: Các yêu cầu hệ thống nên được ưu tiên, được chấp thuận, được giới hạn cơ bản và được truyền thông tới tất cả các bên tham gia chịu ảnh hưởng. Các cập nhật giới hạn cơ bản các yêu cầu nên được đánh giá đối với tác động kỹ thuật, thủ tục và chi phí.

6.4.2.3.2. Đánh giá các yêu cầu

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

6.4.2.3.2.1. Các yêu cầu hệ thống phải được đánh giá xem xét theo tiêu chí được liệt kê dưới đây. Kết quả của các đánh giá phải được tài liệu hóa.

a) Khả năng theo dõi các nhu cầu mua sản phẩm;

b) Tính kiên định với các nhu cầu mua sản phẩm;

c) Khả năng kiểm tra;

d) Tính khả thi thiết kế kiến trúc hệ thống;

e) Tính khả thi về vận hành và bảo trì.

CHÚ THÍCH: Các nhu cầu mua sản phẩm bao gồm giới hạn cơ bản các yêu cầu của bên liên quan.

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

CHÚ THÍCH: Quá trình thiết kế kiến trúc hệ thống trong tiêu chuẩn này là một cụ thể hóa của quá trình thiết kế kiến trúc hệ thống trong tiêu chuẩn ISO/IEC 15288. Người sử dụng có thể xem xét yêu cầu tuân thủ với quá trình 15288 hơn quá trình trong tiêu chuẩn này.

6.4.3.1. Mục đích

Mục đích của quá trình thiết kế kiến trúc hệ thống là để nhận biết các yêu cầu hệ thống nào nên được phân phối tới thành phần nào của hệ thống.

6.4.3.2. Kết quả

Kết quả triển khai thành công của quá trình thiết kế hệ thống gồm:

a) Bản thiết kế kiến trúc hệ thống được định nghĩa phải nhận biết các thành phần của hệ thống và đáp ứng các yêu cầu được định nghĩa;

b) Các yêu cầu thuộc chức năng hệ thống và không thuộc chức năng hệ thống được chỉ định;

c) Các yêu cầu được phân phối tới các thành phần hệ thống;

d) Các giao diện ngoài và trong của mỗi thành phần hệ thống được định nghĩa;

e) Việc xác minh giữa các yêu cầu hệ thống và kiến trúc hệ thống được thực hiện;

f) Các yêu cầu được phân phối tới các thành phần hệ thống và các giao diện của nó là có thể theo dõi được tới giới hạn cơ bản các yêu cầu của khách hàng;

g) Tính nhất quán và khả năng truy hồi giữa các yêu cầu hệ thống và thiết kế kiến trúc hệ thống được duy trì;

h) Các yêu cầu hệ thống, thiết kế kiến trúc hệ thống và các mối quan hệ của chúng được giới hạn cơ bản và thông báo tới tất cả các bên tham gia chịu ảnh hưởng;

i) Các nhân tố con người, các kỹ thuật và kiến thức tối ưu yếu tố con người được bổ sung vào thiết kế hệ thống;

j) Các hoạt động thiết kế lấy con người là trung tâm được xác định và thực hiện.

6.4.3.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 thiết kế kiến trúc hệ thống.

6.4.3.3.1. Thiết lập kiến trúc

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

6.4.3.3.1.1. Kiến trúc hoàn chỉnh của hệ thống phải được thiết lập. Kiến trúc này phải định nghĩa các thành phần phần cứng, phần mềm và các thao tác thủ công. Phải được đảm bảo rằng tất cả các yêu cầu hệ thống được phân phối đến các thành phần đó. Các thành phần cấu hình phần cứng, các thành phần cấu hình phần mềm và các thao tác thủ công phải được định nghĩa sau đó từ các thành phần này. Kiến trúc hệ thống và các yêu cầu hệ thống được phân phối tới các thành phần phải được tài liệu hóa.

CHÚ THÍCH 1: Các giao diện ngoài và trong của mỗi thành phần hệ thống nên được định nghĩa trong kiến trúc hệ thống.

CHÚ THÍCH 2: Các hoạt động thiết kế lấy con người làm trung tâm nên được xác định và thực hiện; các nhân tố con người, các kỹ thuật và kiến thức tối ưu yếu tố con người nên được bổ sung vào thiết kế hệ thống.

CHÚ THÍCH 3: Thiết kế kiến trúc hệ thống và mối liên hệ với các yêu cầu hệ thống nên được giới hạn cơ bản và thông báo tới tất cả các bên tham gia chịu ảnh hưởng.

6.4.3.3.2. Đánh giá kiến trúc

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

6.4.3.3.2.1. Kiến trúc hệ thống và các yêu cầu đối với các thành phần phải được đánh giá xem xét theo tiêu chí được kê dưới đây. Kết quả của các đánh giá phải được tài liệu hóa.

a) Khả năng theo dõi các yêu cầu hệ thống;

b) Tính kiên định với các yêu cầu hệ thống;

c) Sự phù hợp của các phương pháp và tiêu chuẩn thiết kế được sử dụng;

d) Tính khả thi của các thành phần phần mềm đáp ứng được các yêu cầu được phân phối của chúng;

e) Tính khả thi về vận hành và bảo trì.

CHÚ THÍCH 1: Khả năng theo dõi của kiến trúc hệ thống tới các yêu cầu hệ thống cũng nên cung cấp đối với việc khả năng theo dõi tới giới hạn cơ bản các yêu cầu của bên liên quan.

6.4.4. Quá trình triển khai

6.4.4.1. Mục đích

Mục đích của quá trình triển khai là để hiện thực hóa một thành phần hệ thống cụ thể.

CHÚ THÍCH: Người sử dụng tiêu chuẩn này có mục đích khảo sát sản phẩm phần mềm hoặc một thành phần phần mềm của một hệ thống lớn. Quá trình triển khai phần mềm (mục 7.1.1) là một trường hợp tuân theo quá trình triển khai trong tiêu chuẩn ISO/IEC 15288, cụ thể hóa các nhu cầu cụ thể trong việc triển khai một sản phẩm phần mềm hoặc dịch vụ phần mềm. Quá trình triển khai phần mềm thay thế quá trình triển khai trong tiêu chuẩn này.

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

CHÚ THÍCH: Quá trình tích hợp hệ thống trong tiêu chuẩn này là một cụ thể hóa của quá trình tích hợp trong tiêu chuẩn ISO/IEC 15288. Người sử dụng có thể xem xét yêu cầu tuân thủ với quá trình trong tiêu chuẩn 15288 hơn quá trình trong tiêu chuẩn này.

6.4.5.1. Mục đích

Mục đích của quá trình tích hợp hệ thống là để tích hợp các thành phần hệ thống (bao gồm các thành phần phần mềm, các thành phần phần cứng, các thao tác thủ công và các hệ thống khác, nếu cần thiết) để tạo ra một hệ thống hoàn chỉnh đáp ứng thiết kế của hệ thống và các kỳ vọng của các khách hàng đưa ra trong các yêu cầu hệ thống.

6.4.5.2. Kết quả

Kết quả triển khai thành công của quá trình tích hợp hệ thống gồm:

a) Chiến lược được phát triển để tích hợp hệ thống phù hợp với các ưu tiên của các yêu cầu hệ thống;

b) Các tiêu chí được phát triển để xác minh tuân thủ đúng theo các yêu cầu hệ thống được phân phối vào các thành phần hệ thống, bao gồm các giao diện giữa các thành phần hệ thống;

c) Tích hợp hệ thống được xác minh bằng cách sử dụng các tiêu chí xác định;

d) Chiến lược hồi quy được phát triển và áp dụng để kiểm tra lại hệ thống khi các thay đổi được thực hiện;

e) Tính kiên định và khả năng theo dõi được thiết lập giữa thiết kế hệ thống và các thành phần hệ thống được tích hợp;

f) Hệ thống tích hợp được xây dựng để chứng minh tuân thủ đúng theo thiết kế hệ thống;

g) Hệ thống tích hợp được xây dựng để chứng minh rằng một bộ hoàn chỉnh các thành phần hệ thống có khả năng chuyển giao và sử dụng tồn tại.

6.4.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 có tổ chức có khả năng áp dụng trong quá trình tích hợp hệ thống.

6.4.5.3.1. Tích hợp

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

6.4.5.3.1.1. Các thành phần cấu hình phần mềm phải tích hợp, với các thành phần cấu hình phần cứng, các thao tác thủ công và các hệ thống khác nếu cần thiết vào trong hệ thống. Tổng thể hệ thống phải được kiểm tra, như khi chúng được phát triển, dựa vào các yêu cầu của chúng. Kết quả kiểm tra và tích hợp phải được tài liệu hóa.

CHÚ THÍCH 1: Hoạt động tích hợp hệ thống phải được thực hiện theo chiến lược tích hợp được định nghĩa từ trước có tính đến các ưu tiên của các yêu cầu hệ thống.

CHÚ THÍCH 2: Chiến lược tích hợp phải chỉ ra tính kiên định và khả năng theo dõi giữa thiết kế hệ thống và các thành phần hệ thống được tích hợp.

6.4.5.3.2. Sẵn sàng kiểm tra

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

6.4.5.3.2.1. Đối với mỗi yêu cầu chất lượng của hệ thống, một tập các bài đo, các trường hợp đo (các đầu vào, đầu ra, tiêu chí đo) và các thủ tục đo để tiến hành đo kiểm chất lượng hệ thống phải được phát triển và tài liệu hóa. Bên phát triển phải đảm bảo rằng hệ thống tích hợp luôn sẵn sàng đối với quá trình kiểm tra chất lượng hệ thống.

CHÚ THÍCH: Chiến lược hồi quy, được áp dụng để kiểm tra lại hệ thống khi có các thay đổi, nên được phát triển.

6.4.5.3.2.2. Hệ thống tích hợp sẽ được đánh giá xem xét theo tiêu chí dưới đây. Kết quả của các đánh giá phải được tài liệu hóa.

a) Phạm vi kiểm tra của các yêu cầu hệ thống;

b) Sự phù hợp của các tiêu chuẩn và các phương pháp kiểm tra được sử dụng;

c) Tuân thủ kết quả dự kiến;

d) Tính khả thi của việc kiểm tra chất lượng hệ thống;

e) Tính khả thi của việc vận hành và bảo trì.

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

CHÚ THÍCH: Quá trình kiểm tra chất lượng hệ thống trong tiêu chuẩn này góp phần vào kết quả của quá trình xác minh trong tiêu chuẩn ISO/IEC 15288. Người sử dụng có thể xem xét yêu cầu tuân thủ với quá trình trong tiêu chuẩn 15288 hơn Quá trình trong tiêu chuẩn này.

6.4.6.1. Mục đích

Mục đích của quá trình kiểm tra chất lượng các hệ thống là để đảm bảo rằng việc triển khai của mỗi yêu cầu hệ thống được kiểm tra tuân thủ và đảm bảo rằng hệ thống sẵn sàng để chuyển giao.

6.4.6.2. Kết quả

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

a) Tiêu chí đánh giá tuân thủ theo các yêu cầu hệ thống được phát triển;

b) Hệ thống tích hợp được kiểm tra bằng cách sử dụng tiêu chí xác định;

c) Kết quả kiểm tra được ghi lại;

d) Tính sẵn sàng của hệ thống đối với việc chuyển giao được đảm bảo.

6.4.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 chất lượng hệ thống.

6.4.6.3.1. Kiểm tra chất lượng

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

6.4.6.3.1.1. Kiểm tra chất lượng hệ thống phải được tiến hành phù hợp với các yêu cầu chất lượng được chỉ rõ cho hệ thống đó. Sẽ được đảm bảo rằng việc triển khai mỗi yêu cầu hệ thống được kiểm tra tuân thủ và hệ thống đó đã sẵn sàng để chuyển giao. Kết quả kiểm tra chất lượng phải được tài liệu hóa.

CHÚ THÍCH: Các yêu cầu chất lượng đối với hệ thống nên bao gồm tiêu chí đánh giá tuân thủ theo các yêu cầu hệ thống.

6.4.6.3.1.2. Hệ thống phải đánh giá xem xét theo các tiêu chí dưới đây. Kết quả của các đánh giá phải được tài liệu hóa.

a) Phạm vi kiểm tra của các yêu cầu hệ thống;

b) Tuân thủ kết quả dự kiến;

c) Tính khả thi về vận hành và bảo trì.

CHÚ THÍCH: Tiêu chí đánh giá nên giải quyết tính sẵn sàng của hệ thống chuyển giao.

6.4.6.3.1.3. Bên triển khai phải hỗ trợ kiểm tra phù hợp với mục 7.2.7. Kết quả kiểm tra phải được tài liệu hóa.

CHÚ THÍCH: Mục này không thể áp dụng tới các thành phần cấu hình phần mềm mà các kiểm tra được tiến hành trước đó.

6.4.6.3.1.4. Sau khi hoàn thành thành công kiểm tra, nếu được tiến hành. Bên triển khai phải cập nhật và chuẩn bị sản phẩm phần mềm chuyển giao trong quá trình hỗ trợ tiếp nhận phần mềm và cài đặt phần mềm.

CHÚ THÍCH: Quá trình kiểm tra chất lượng hệ thống có thể được sử dụng trong Quá trình xác minh phần mềm (mục 7.2.4) hoặc quá trình xác nhận phần mềm (mục 7.2.5).

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

CHÚ THÍCH: Quá trình cài đặt phần mềm trong tiêu chuẩn này góp phần vào kết quả của quá trình chuyển tiếp trong tiêu chuẩn ISO/IEC 15288. Người sử dụng có thể xem xét yêu cầu tuân thủ với quá trình trong tiêu chuẩn ISO/IEC 15288 hơn quá trình trong tiêu chuẩn này.

6.4.7.1. Mục đích

Mục đích của quá trình cài đặt phần mềm là để cài đặt sản phẩm phần mềm đáp ứng các yêu cầu thỏa thuận trong môi trường mục tiêu.

6.4.7.2. Kết quả

Kết quả triển khai thành công của quá trình cài đặt phần mềm gồm:

a) Chiến lược cài đặt phần mềm được phát triển;

b) Tiêu chí đối với cài đặt phần mềm được phát triển để chứng minh sự tuân thủ theo các yêu cầu cài đặt phần mềm;

c) Sản phẩm phần mềm được cài đặt trong môi trường mục tiêu;

d) Tính sẵn sàng của sản phẩm phần mềm cho việc sử dụng trong môi trường dự kiến của nó được đảm bảo.

6.4.7.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 cài đặt phần mềm.

6.4.7.3.1.1. Bên triển khai phải phát triển kế hoạch để cài đặt sản phẩm phần mềm trong môi trường mục tiêu như đã chỉ rõ trong hợp đồng. Các tài nguyên và thông tin cần thiết để cài đặt sản phẩm phần mềm sẽ được xác định và khả dụng. Như đã chỉ rõ trong hợp đồng, bên triển khai phải trợ giúp bên mua sản phẩm bằng các hoạt động cài đặt. Khi sản phẩm phần mềm được thay thế một hệ thống đã tồn tại, bên triển khai phải hỗ trợ bất kỳ các hoạt động chạy song song nào được yêu cầu trong hợp đồng. Kế hoạch cài đặt phải được tài liệu hóa.

CHÚ THÍCH 1: Chiến lược cài đặt phần mềm nên được phát triển trong việc thỏa thuận với khách hàng và tổ chức điều hành.

CHÚ THÍCH 2: Phần quan trọng của việc phát triển chiến lược cài đặt là để triển khai chiến lược phục hồi phiên bản hệ thống làm việc mới nhất. Để có thể cài đặt lại phiên bản làm việc mới nhất, một bản dự phòng đầy đủ của hệ thống nên được tạo ra trước khi bắt đầu cài đặt.

CHÚ THÍCH 3: Dựa trên các yêu cầu cài đặt, bộ cài đặt nên phát triển theo tiêu chuẩn đối với môi trường phần mềm sẽ được cài đặt.

CHÚ THÍCH 4: Bộ cài đặt nên định nghĩa các yêu cầu đối với việc tương thích của hệ thống theo môi trường dự kiến của nó.

CHÚ THÍCH 5: Bộ cài đặt nên tương thích với hệ thống để đáp ứng các yêu cầu đối với việc vận hành.

6.4.7.3.1.2. Bên phát triển phải cài đặt sản phẩm phần mềm phù hợp với kế hoạch cài đặt. Nó phải được đảm bảo rằng các cơ sở dữ liệu và mã phần mềm khởi động, thực thi và hoàn thành theo chỉ định trong hợp đồng. Các sự kiện cài đặt và kết quả phải được tài liệu hóa.

CHÚ THÍCH: Bộ cài đặt phải đảm bảo rằng sản phẩm phần mềm phải sẵn sàng đối với việc sử dụng trong môi trường dự kiến của nó.

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

CHÚ THÍCH: Quá trình hỗ trợ tiếp nhận phần mềm trong tiêu chuẩn này đóng góp vào kết quả của quá trình chuyển tiếp trong tiêu chuẩn ISO/IEC 15288. Quá trình hỗ trợ tiếp nhận phần mềm trong tiêu chuẩn này cũng có thể đóng góp vào kết quả của quá trình công nhận hiệu lực trong tiêu chuẩn ISO/IEC 15288. Người sử dụng có thể xem xét yêu cầu tuân thủ với các quá trình trong tiêu chuẩn 15288 hơn quá trình trong tiêu chuẩn này.

6.4.8.1. Mục đích

Mục đích của quá trình hỗ trợ tiếp nhận phần mềm là để trợ giúp bên mua sản phẩm đạt được sự tin tưởng về sản phẩm đáp ứng các yêu cầu.

6.4.8.2. Kết quả

Kết quả triển khai thành công của quá trình hỗ trợ tiếp nhận phần mềm gồm:

a) Sản phẩm được hoàn thiện và chuyển giao đến bên mua sản phẩm;

b) Các quá trình soát xét và kiểm tra khi tiếp nhận của bên mua sản phẩm được hỗ trợ;

c) Sản phẩm được đưa vào hoạt động trong môi trường của khách hàng;

d) Các vấn đề phát hiện trong việc tiếp nhận được định nghĩa và thông báo tới người có trách nhiệm giải quyết.

CHÚ THÍCH: Chuyển giao gia tăng phải được hoàn thiện dần.

6.4.8.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 hỗ trợ tiếp nhận phần mềm.

6.4.8.3.1. Hỗ trợ tiếp nhận phần mềm

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

6.4.8.3.1.1. Bên phát triển phải hỗ trợ việc kiểm tra và soát xét khi tiếp nhận sản phẩm của bên mua sản phẩm. Việc kiểm tra và soát xét khi tiếp nhận phải lưu ý đến kết quả của các Quá trình soát xét phần mềm (mục 7.2.6), kiểm tra phần mềm (mục 7.2.7), kiểm tra chất lượng phần mềm và kiểm tra chất lượng hệ thống (nếu được thực hiện). Kết quả của việc kiểm tra và soát xét khi tiếp nhận phải được tài liệu hóa.

CHÚ THÍCH: Điều này bao gồm tài liệu hướng dẫn và sự truyền thông các vấn đề phát hiện trong kiểm tra khi tiếp nhận tới người có trách nhiệm giải quyết.

6.4.8.3.1.2. Bên phát triển phải hoàn thiện và chuyển giao sản phẩm phần mềm như đã định nghĩa trong hợp đồng.

CHÚ THÍCH: Hợp đồng có thể yêu cầu bên phát triển đưa sản phẩm vào hoạt động trong môi trường của khách hàng.

6.4.8.3.1.3. Bên phát triển phải cung cấp đào tạo ban đầu và duy trì hỗ trợ tới bên mua sản phẩm như đã định nghĩa trong hợp đồng.

CHÚ THÍCH: Hỗ trợ ban đầu bao gồm nhận biết và thông báo các vấn đề phát hiện trong khi chuyển giao tới người có trách nhiệm giải quyết.

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

Quá trình vận hành phần mềm trong tiêu chuẩn này một cụ thể hóa của quá trình vận hành trong tiêu chuẩn ISO/IEC 15288. Người sử dụng có thể xem xét yêu cầu tuân thủ với quá trình trong tiêu chuẩn 15288 hơn quá trình trong tiêu chuẩn này.

6.4.9.1. Mục đích

Mục đích của quá trình vận hành phần mềm là để vận hành sản phẩm phần mềm trong môi trường dự kiến của nó và để cung cấp hỗ trợ các khách hàng về sản phẩm phần mềm.

6.4.9.2. Kết quả

Kết quả triển khai thành công của quá trình vận hành phần mềm gồm:

a) Chiến lược vận hành được định nghĩa;

b) Các điều kiện đối với việc vận hành chính xác sản phẩm trong môi trường dự kiến của nó được nhận biết và đánh giá;

c) Sản phẩm phần mềm được kiểm tra và xác định để vận hành trong môi trường dự kiến của nó;

d) Sản phẩm phần mềm được vận hành trong môi trường dự kiến của nó;

e) Sự hỗ trợ và tư vấn được cung cấp tới các khách hàng về sản phẩm phần mềm phù hợp với thỏa thuận.

6.4.9.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 vận hành phần mềm.

6.4.9.3.1. Chuẩn bị vận hành

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

6.4.9.3.1.1. Bên vận hành phải phát triển kế hoạch và một tập các tiêu chuẩn vận hành để thực hiện các hoạt động và nhiệm vụ của quá trình này. Việc lập kế hoạch phải được tài liệu hóa và được thực thi.

6.4.9.3.1.2. Bên vận hành phải thiết lập các thủ tục để tiếp nhận, ghi lại, giải quyết, theo dõi các vấn đề và cung cấp sự phản hồi. Bất cứ khi nào các vấn đề gặp phải, chúng sẽ được ghi lại và tiến hành quá trình giải quyết vấn đề phần mềm (mục 7.2.8).

6.4.9.3.1.3. Bên vận hành phải thiết lập các thủ tục để kiểm tra sản phẩm phần mềm trong môi trường vận hành của nó, để đưa các báo cáo vấn đề phát sinh và các yêu cầu sửa đổi vào quá trình bảo trì phần mềm (mục 6.4.10) và để phát hành sản phẩm phần mềm cho việc sử dụng vận hành.

6.4.9.3.2. Hiệu chỉnh và kích hoạt vận hành

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

6.4.9.3.2.1. Đối với mỗi phát hành sản phẩm phần mềm, bên vận hành phải thực hiện kiểm tra hoạt động và, hoạt động đó đáp ứng được các tiêu chí xác định, phát hành sản phẩm phần mềm cho việc sử dụng vận hành.

6.4.9.3.2.2. Bên vận hành phải đảm bảo rằng các cơ sở dữ liệu và mã phần mềm khởi tạo, thực thi và hoàn thành như đã mô tả trong kế hoạch.

6.4.9.3.2.3. Bên vận hành phải khởi động hệ thống trong tình trạng hoạt động dự kiến của nó để phân phối các đối tượng của dịch vụ hoặc dịch vụ thường xuyên theo mục đích dự kiến của nó.

CHÚ THÍCH: Trong trường hợp thỏa thuận, duy trì chất lượng và năng lực dịch vụ thường xuyên khi hệ thống thay thế một hệ thống tồn tại bị ngừng sử dụng. Trong khoảng thời gian quy định việc điều chỉnh hoặc vận hành đồng thời, quản lý chuyển đổi các dịch vụ để duy trì tuân thủ với các nhu cầu bên liên quan đạt được một cách ổn định.

6.4.9.3.3. Vận hành

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

6.4.9.3.3.1. Hệ thống phải được vận hành trong môi trường dự kiến của nó theo tài liệu hướng dẫn người sử dụng.

CHÚ THÍCH 1: Vận hành trong môi trường dự kiến bao gồm việc phát triển các tiêu chí đối với việc sử dụng vận hành để việc tuân thủ các yêu cầu thỏa thuận có thể được chứng minh và việc thực hiện kiểm tra hoạt động đối với mỗi phát hành sản phẩm, đánh giá sự thỏa mãn dựa vào tiêu chí quy định.

CHÚ THÍCH 2: Các rủi ro tới việc vận hành sản phẩm được nhận biết và giám sát.

CHÚ THÍCH 3: Bên vận hành giám sát dịch vụ hoạt động một cách thường xuyên, khi thích hợp, dựa vào các tiêu chí đã định nghĩa.

6.4.9.3.4. Hỗ trợ khách hàng

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

6.4.9.3.4.1. Bên vận hành phải cung cấp sự hỗ trợ và tư vấn tới người sử dụng khi được yêu cầu. Các yêu cầu và các hoạt động tiếp sau đó sẽ được ghi lại và giám sát.

CHÚ THÍCH: Sự hỗ trợ và tư vấn bao gồm cung cấp việc đào tạo, tài liệu hướng dẫn và các dịch vụ hỗ trợ khác để hỗ trợ sử dụng hiệu quả sản phẩm.

6.4.9.3.4.2. Bên vận hành phải chuyển tiếp các yêu cầu của người sử dụng, nếu cần thiết, tới quá trình bảo trì phần mềm (mục 6.4.10) để giải quyết. Các yêu cầu này phải được giải quyết và các hoạt động được lập kế hoạch và thực hiện sẽ được báo cáo tới bên yêu cầu. Tất cả việc giải quyết sẽ được giám sát để kết luận.

6.4.9.3.5. Giải quyết vấn đề vận hành

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

6.4.9.3.5.1. Bên vận hành phải chuyển tiếp các vấn đề được nhận biết tới quá trình giải quyết vấn đề phần mềm để giải quyết.

6.4.9.3.5.2. Nếu một vấn đề được báo cáo có cách giải quyết tạm thời trước khi cách giải quyết lâu dài có thể được ban hành, người khai báo báo cáo vấn đề phát sinh sẽ được cung cấp phương án đó để sử dụng. Các bản ban hành, các hiệu chỉnh lâu dài bao gồm các đặc điểm đặc trưng hoặc chức năng thiết sót trước đó và các cải tiến hệ thống phải được áp dụng vào hoạt động của sản phẩm phần mềm sử dụng quá trình bảo trì phần mềm (mục 6.4.10).

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

CHÚ THÍCH 1: Quá trình bảo trì phần mềm trong tiêu chuẩn này là một cụ thể hóa của quá trình bảo trì trong tiêu chuẩn ISO/IEC 15288. Người sử dụng có thể xem xét yêu cầu tuân thủ với quá trình trong tiêu chuẩn 15288 hơn quá trình trong tiêu chuẩn này.

CHÚ THÍCH 2: Quá trình bảo trì phần mềm của tiêu chuẩn này là tương thích với tiêu chuẩn ISO/IEC 14764:2006.

6.4.10.1. Mục đích

Mục đích của quá trình bảo trì phần mềm là để cung cấp hỗ trợ chi phí hiệu quả tới sản phẩm phần mềm được chuyển giao.

CHÚ THÍCH: Các hoạt động bảo trì phần mềm trước khi chuyển giao bao gồm lập kế hoạch đối với các hoạt động chuyển giao, khả năng hỗ trợ và giải quyết sau chuyển giao. Các hoạt động chuyển giao bao gồm hỗ trợ vận hành và sửa đổi phần mềm, ví dụ đào tạo hoặc nhân viên hỗ trợ.

6.4.10.2. Kết quả

Kết quả triển khai thành công của quá trình bảo trì phần mềm gồm:

a) Chiến lược bảo trì được phát triển để quản lý việc sửa đổi và chuyển giao các sản phẩm theo chiến lược ban hành;

b) Ảnh hưởng của các thay đổi tới hệ thống hiện có lên tổ chức, các vận hành hoặc các giao diện được xác định;

c) Tài liệu hướng dẫn phần mềm và hệ thống bị ảnh hưởng được cập nhật khi cần thiết;

d) Các sản phẩm bị sửa đổi được phát triển cùng với các bài kiểm tra liên quan nhằm chứng tỏ rằng các yêu cầu không bị làm thay đổi;

e) Các cập nhật sản phẩm được chuyển tới môi trường khách hàng;

f) Việc sửa đổi phần mềm hệ thống được thông báo tới tất cả bên tham gia chịu ảnh hưởng.

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

Bên bảo trì 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 bảo trì phần mềm.

6.4.10.3.1. Triển khai quá trình

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

6.4.10.3.1.1. Bên bảo trì phải phát triển, tài liệu hóa, thực thi các kế hoạch và các thủ tục để tiến hành các hoạt động và nhiệm vụ của quá trình bảo trì phần mềm.

6.4.10.3.1.2. Bên bảo trì phải thiết lập các thủ tục cho việc tiếp nhận, ghi lại và theo dõi các báo cáo về vấn đề phát sinh và các yêu cầu sửa đổi từ người sử dụng và cung cấp sự phản hồi đến người sử dụng. Bất cứ khi nào các vấn đề gặp phải, chúng sẽ được ghi lại và đưa vào quá trình giải quyết vấn đề phần mềm (mục 7.2.8).

6.4.10.3.1.3. Bên bảo trì phải triển khai (hoặc thiết lập giao diện tổ chức với) quá trình quản lý cấu hình (mục 7.2.2) để quản lý các sửa đổi tới hệ thống hiện có.

6.4.10.3.2. Phân tích sửa đổi và vấn đề phát sinh

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

6.4.10.3.2.1. Bên bảo trì phải phân tích báo cáo vấn đề phát sinh hoặc yêu cầu sửa đổi đối với sự ảnh hưởng của nó lên tổ chức, hệ thống hiện có và các hệ thống giao diện theo các điều sau:

a) Kiểu, ví dụ: sự hiệu chỉnh, sự cải tiến, ngăn ngừa hoặc sự tương thích với môi trường mới;

b) Phạm vi, ví dụ: kích cỡ sửa đổi, chi phí liên quan, thời điểm sửa đổi;

c) Mức độ rủi ro, ví dụ: ảnh hưởng đến hiệu năng, độ tin cậy hoặc tính an toàn

6.4.10.3.2.2. Bên bảo trì phải sao lưu hoặc xác minh vấn đề phát sinh.

6.4.10.3.2.3. Dựa trên sự phân tích, Bên bảo trì phải phát triển các phương án để triển khai việc sửa đổi đó.

6.4.10.3.2.4. Bên bảo trì phải tài liệu hóa yêu cầu sửa đổi/vấn đề phát sinh, kết quả phân tích và các lựa chọn thực thi.

6.4.10.3.2.5. Bên bảo trì phải đạt được sự chấp thuận đối với phương án sửa đổi được lựa chọn như được chỉ rõ trong hợp đồng.

6.4.10.3.3. Triển khai sửa đổi

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

6.4.10.3.3.1. Bên bảo trì phải tiến hành phân tích và xác định tài liệu hướng dẫn, các đơn vị phần mềm và các phiên bản nào cần phải được sửa đổi. Các việc này phải được tài liệu hóa.

6.4.10.3.3.2. Bên bảo trì phải tiến hành quá trình kỹ thuật (mục 6.4) để triển khai các sửa đổi. Các yêu cầu của các quá trình kỹ thuật sẽ được bổ sung như sau:

a) Tiêu chí đánh giá và kiểm tra cho việc kiểm tra tra và đánh giá các phần không sửa đổi và các phần sửa đổi (các đơn vị phần mềm, các thành phần và các thành phần cấu hình) của hệ thống phải được định nghĩa và tài liệu hóa;

b) Triển khai đúng và hoàn chỉnh các yêu cầu sửa đổi và yêu cầu mới sẽ được đảm bảo. Cũng sẽ được đảm bảo rằng các yêu cầu không sửa đổi, nguyên gốc không bị ảnh hưởng. Kết quả kiểm tra phải được tài liệu hóa.

6.4.10.3.4. Tiếp nhận/soát xét sau bảo trì

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

6.4.10.3.4.1. Bên bảo trì phải tiến hành soát xét với tổ chức về việc cho phép sửa đổi để xác định sự toàn vẹn của hệ thống được sửa đổi.

6.4.10.3.4.2. Bên bảo trì phải đạt được sự chấp thuận sự hoàn thành thỏa đáng việc sửa đổi như đã định rõ trong hợp đồng.

6.4.10.3.5. Sự chuyển đổi

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

6.4.10.3.5.1. Nếu một hệ thống hoặc sản phẩm phần mềm (bao gồm cả dữ liệu) được chuyển đổi từ một môi trường hoạt động cũ sang môi trường hoạt động mới, nó sẽ được đảm bảo rằng bất kỳ dữ liệu hoặc sản phẩm phần mềm nào được tạo ra hoặc được sửa đổi trong suốt quá trình chuyển đổi đó là phù hợp với tiêu chuẩn này.

6.4.10.3.5.2. Kế hoạch chuyển đổi sẽ được phát triển, tài liệu hóa và thực thi. Các hoạt động lập kế hoạch sẽ bao gồm cả người sử dụng. Các thành phần trong kế hoạch sẽ gồm:

a) Phân tích các yêu cầu và định nghĩa sự chuyển đổi;

b) Phát triển các công cụ chuyển đổi;

c) Chuyển đổi sản phẩm phần mềm và dữ liệu;

d) Thực thi chuyển đổi;

e) Xác minh chuyển đổi;

f) Hỗ trợ cho môi trường cũ trong tương lai.

6.4.10.3.5.3. Người sử dụng sẽ được cung cấp thông báo về các hoạt động và các kế hoạch chuyển đổi. Các thông báo phải bao gồm các điều sau:

a) Trình bày tại sao môi trường cũ không được hỗ trợ nữa;

b) Mô tả môi trường mới tại thời điểm khả dụng của nó;

c) Mô tả các phương án hỗ trợ khả thi khác, nếu có, khi việc hỗ trợ đối với môi trường cũ đã bị loại bỏ.

6.4.10.3.5.4. Các hoạt động song song của các môi trường mới và cũ có thể tiến hành chuyển tiếp sang môi trường mới. Trong thời gian này, việc đào tạo cần thiết phải được tiến hành như đã chỉ rõ trong hợp đồng.

6.4.10.3.5.5. Khi việc chuyển đổi thực hiện theo lịch trình, thông báo sẽ được gửi tới tất cả các bên liên quan. Mã, các log và tài liệu hướng dẫn trong môi trường cũ liên quan nên được giữ trong các kho lưu trữ.

6.4.10.3.5.6. Soát xét sau hoạt động chuyển giao sẽ được thực hiện để đánh giá ảnh hưởng của sự thay đổi tới môi trường mới đó. Kết quả soát xét phải được gửi đến những bên có thẩm quyền thích hợp để được hướng dẫn, thông tin và hành động.

6.4.10.3.5.7. Dữ liệu được môi trường cũ sử dụng hoặc có liên quan tới môi trường cũ phải được tiếp cận theo các yêu cầu hợp đồng về việc kiểm tra và bảo vệ dữ liệu.

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

CHÚ THÍCH: Quá trình hủy bỏ phần mềm trong tiêu chuẩn này là một cụ thể hóa của quá trình hủy bỏ trong tiêu chuẩn ISO/IEC 15288. Người sử dụng có thể xem xét yêu cầu tuân thủ với quá trình trong tiêu chuẩn 15288 hơn quá trình trong tiêu chuẩn này.

6.4.11.1. Mục đích

Mục đích của quá trình hủy bỏ phần mềm là để kết thúc sự tồn tại thực thể phần mềm của hệ thống.

Quá trình này kết thúc hỗ trợ hoạt động hoặc vô hiệu hóa, tháo rời và loại bỏ các sản phẩm phần mềm bị hư hỏng bởi tổ chức bảo trì và vận hành thực hiện, bằng cách phó thác chúng ở trạng thái cuối và để lại môi trường đó theo một điều kiện chấp nhận được. Quá trình này hủy bỏ hoặc lưu trữ các thành phần phần mềm hệ thống và các sản phẩm liên quan theo một cách hợp lý, đúng với pháp luật, với các thỏa thuận, các ràng buộc của tổ chức và các yêu cầu của bên liên quan. Trong trường hợp cần thiết, các bản ghi hồ sơ được duy trì và giám sát.

CHÚ THÍCH: Mục đích là để dừng các dịch vụ hoặc sản phẩm phần mềm hiện có của hệ thống trong khi vẫn bảo toàn tính toàn vẹn các hoạt động của tổ chức.

6.4.11.2. Kết quả

Kết quả triển khai thành công của quá trình hủy bỏ phần mềm gồm:

a) Chiến lược hủy bỏ phần mềm được định nghĩa;

b) Các ràng buộc hủy bỏ được cung cấp như các đầu vào của các yêu cầu;

c) Các thành phần phần mềm của hệ thống được hủy bỏ hoặc lưu trữ;

d) Môi trường được giữ lại theo điều kiện thỏa thuận;

e) Các hồ sơ cho phép lưu giữ kiến thức về các hoạt động hủy bỏ và bất kỳ phân tích nào về ảnh hưởng lâu dài là khả dụng.

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

Dự án 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 hủy bỏ phần mềm .

6.4.11.3.1. Lập kế hoạch hủy bỏ phần mềm

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

6.4.11.3.1.1. Chiến lược hủy bỏ phần mềm được định nghĩa và tài liệu hóa. Kế hoạch để kết thúc hỗ trợ hoạt động phải được các tổ chức bảo trì và tổ chức vận hành phát triển và tài liệu hóa. Các hoạt động lập kế hoạch phải bao gồm người sử dụng. Kế hoạch hủy bỏ phần mềm phải giải quyết các mục được liệt kê dưới đây:

a) Ngừng hỗ trợ một phần hoặc toàn bộ sau một khoảng thời gian nhất định;

b) Lưu trữ sản phẩm phần mềm và tài liệu hướng dẫn phù hợp của nó;

c) Có trách nhiệm đối với bất kỳ vấn đề hỗ trợ còn lại nào trong tương lai;

d) Chuyển sang bất kỳ sản phẩm phần mềm nào, nếu có thể có khả năng áp dụng;

e) Khả năng truy cập các bản sao lưu trữ dữ liệu.

CHÚ THÍCH 1: Mục này định nghĩa các lịch trình, các hoạt động và các tài nguyên để: 1) kết thúc việc chuyển giao các dịch vụ phần mềm; 2) chuyển đổi hệ thống sang hoặc giữ lại nó trong, một trạng thái có thể chấp nhận được một cách tự nhiên và gần gũi, do đó tránh các ảnh hưởng bất lợi tiếp sau đó tới các bên liên quan, xã hội và môi trường; 3) lưu ý đến sức khỏe, độ tin cậy, tính an toàn và tính riêng tư có khả năng áp dụng đối với các hoạt động hủy bỏ và điều kiện lâu dài của việc tạo ra thông tin và tài liệu vật lý.

CHÚ THÍCH 2: Các ràng buộc hủy bỏ nên được cung cấp như các đầu vào của các yêu cầu đối với các hoạt động hủy bỏ được lập kế hoạch.

6.4.11.3.2. Thực thi hủy bỏ phần mềm

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

6.4.11.3.2.1. Kế hoạch hủy bỏ phần mềm phải được thực thi.

6.4.11.3.2.2. Bên sử dụng phải được thông báo về các kế hoạch và các hoạt động đối với việc ngừng sử dụng các dịch vụ và các sản phẩm phần mềm. Các thông báo phải bao gồm các điều sau:

a) Mô tả cập nhật hoặc sự thay thế bất kỳ từ thời điểm khả dụng của nó;

b) Trình bày tại sao sản phẩm phần mềm không được hỗ trợ lâu hơn;

c) Mô tả các phương án hỗ trợ khả thi khác, khi việc hỗ trợ đó đã bị loại bỏ.

6.4.11.3.2.3. Các hoạt động song song của việc ngừng sử dụng này và sản phẩm phần mềm mới nên được tiến hành chuyển tiếp sang hệ thống mới. Trong thời gian này, việc hướng dẫn người sử dụng phải được tiến hành như đã chỉ định trong hợp đồng.

6.4.11.3.2.4. Khi việc ngừng sử dụng theo lịch trình tới, thông báo phải được gửi đến tất cả các bên có liên quan. Tất cả mã, các log và tài liệu hướng dẫn phát triển liên quan nên được giữ trong các kho lưu trữ, khi thích hợp.

6.4.11.3.2.5. Dữ liệu được sử dụng bởi hoặc có liên quan tới sản phẩm phần mềm ngừng sử dụng phải được tiếp cận theo các yêu cầu hợp đồng về việc kiểm tra và bảo vệ dữ liệu.

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

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

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

CHÚ THÍCH: Quá trình triển khai phần mềm là một trường hợp tuân thủ quá trình triển khai trong tiêu chuẩn ISO/IEC 15288, cụ thể hóa các nhu cầu cụ thể từ việc triển khai một sản phẩm phần mềm hoặc dịch vụ.

7.1.1.1. Mục đích

Mục đích của quá trình triển khai phần mềm là để tạo ra một thành phần hệ thống xác định được triển khai như một sản phẩm phần mềm hoặc dịch vụ phần mềm.

Quá trình này chuyển đổi các giao diện, tính năng xác định và các ràng buộc triển khai thành các hoạt động tạo ra một thành phần hệ thống triển khai như một sản phẩm hoặc dịch vụ phần mềm, còn được biết đến như là “thành phần phần mềm”. Quá trình này tạo ra một thành phần phần mềm mà thỏa mãn các yêu cầu thiết kế kiến trúc thông qua việc xác minh và các yêu cầu của bên liên quan thông qua việc xác nhận.

7.1.1.2. Kết quả

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

a) Chiến lược triển khai được định nghĩa:

b) Các ràng buộc công nghệ triển khai đối với thiết kế được nhận biết;

c) Thành phần phần mềm được thực hiện;

d) Thành phần phần mềm được đóng gói và lưu trữ theo sự thỏa thuận về việc cung cấp của nó.

Ngoài các hoạt động của nó, quá trình triển khai phần mềm có các quá trình mức độ thấp hơn như sau:

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

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

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

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

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

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

CHÚ THÍCH: Người sử dụng tiêu chuẩn ISO/IEC 15288 có thể quyết định rằng các quá trình đánh dấu bằng dấu sao (*) trong danh sách liệt kê trên được cung cấp bởi việc áp dụng đệ quy của tiêu chuẩn ISO/IEC 15288 ngay cả đối với các thành phần phần mềm của hệ thống.

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

Dự án 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 triển khai phần mềm.

7.1.1.3.1. Chiến lược triển khai phần mềm

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

7.1.1.3.1.1. Nếu không được quy định trong hợp đồng, bên phát triển phải định nghĩa hoặc lựa chọn một mô hình vòng đời phù hợp với phạm vi, tầm quan trọng và độ phức tạp của dự án. Mô hình vòng đời phải bao gồm các giai đoạn, mục đích và kết quả của mỗi giai đoạn. Các hoạt động và nhiệm vụ của quá trình triển khai phải được lựa chọn và ánh xạ lên trên mô hình vòng đời.

CHÚ THÍCH: Các hoạt động và nhiệm vụ này có thể chồng lên nhau hoặc tác động lẫn nhau và có thể được thực hiện một cách lặp đi lặp lại hoặc một cách đệ quy.

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 xác định một cách có tổ chức.

7.1.1.3.1.2. Bên triển khai phải:

a) Tài liệu hóa kết quả phù hợp với quá trình quản lý tài liệu hướng dẫn phần mềm (mục 7.2.1);

b) Đặt kết quả dưới quá trình quản lý cấu hình phần mềm (mục 7.2.2) và thực hiện kiểm soát thay đổi phù hợp với nó;

c) Tài liệu hóa và giải quyết các vấn đề và các điều không phù hợp được phát hiện trong các các nhiệm vụ và sản phẩm phần mềm phù hợp với quá trình giải quyết vấn đề phần mềm (mục 7.2.8);

d) Thực hiện việc hỗ trợ các quá trình như chỉ định trong hợp đồng;

e) Thiết lập các giới hạn cơ bản và bổ sung thêm các thành phần cấu hình tại các thời điểm thích hợp, như đã định nghĩa bởi bên mua sản phẩm và nhà cung cấp.

7.1.1.3.1.3. Bên triển khai phải lựa chọn, sửa đổi và sử dụng các tiêu chuẩn, các công cụ, các phương pháp và ngôn ngữ lập trình máy tính này (nếu không được quy định trong hợp đồng) mà đã được tài liệu hóa, phù hợp và được tổ chức thiết lập cho việc thực hiện các hoạt động của quá trình triển khai phần mềm và hỗ trợ các quá trình.

CHÚ THÍCH: Các điều kiện triển khai công nghệ trong bản thiết kế nên được nhận biết như một phần của chiến lược triển khai phần mềm.

7.1.1.3.1.4. Bên triển khai phải phát triển các kế hoạch cho việc tiến hành các hoạt động của quá trình triển khai phần mềm. Các kế hoạch nên bao gồm trách nhiệm, các hoạt động, các công cụ, các phương pháp và các tiêu chuẩn cụ thể có liên quan tới việc phát triển và chất lượng của tất cả các yêu cầu bao gồm cả độ tin cậy và tính an toàn. Nếu cần thiết, các kế hoạch riêng rẽ có thể được phát triển. Các kế hoạch này phải được tài liệu hóa và thực thi.

7.1.1.3.1.5. Các thành phần không thể chuyển giao có thể được sử dụng trong việc phát triển hoặc bảo trì sản phẩm phần mềm. Tuy nhiên, phải được đảm bảo rằng việc vận hành và bảo trì sản phẩm phần mềm có thể chuyển giao sau khi chuyển giao tới bên mua sản phẩm là độc lập với các thành phần đó; nếu không thì, các thành phần đó nên được xem như là có thể chuyển giao.

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

CHÚ THÍCH: Quá trình phân tích các yêu cầu phần mềm trong tiêu chuẩn này là một quá trình mức độ thấp hơn quá trình triển khai phần mềm. Người sử dụng tiêu chuẩn ISO/IEC 15288 có thể quyết định rằng quá trình này được cung cấp bởi quá trình phân tích các yêu cầu của tiêu chuẩn ISO/IEC 15288 trong việc áp dụng đệ quy tiêu chuẩn đó.

7.1.2.1. Mục đích

Mục đích của quá trình phân tích các yêu cầu phần mềm là để thiết lập các yêu cầu của các thành phần phần mềm hệ thống.

7.1.2.2. Kết quả

Kết quả triển khai thành công của quá trình phân tích các yêu cầu phần mềm gồm:

a) Các yêu cầu được phân phối tới các thành phần phần mềm của hệ thống và các giao diện của nó được định nghĩa;

b) Các yêu cầu phần mềm được phân tích về tính đúng đắn và khả năng kiểm tra;

c) Ảnh hưởng của các yêu cầu phần mềm vào môi trường vận hành được hiểu rõ;

d) Tính kiên định và khả năng theo dõi được thiết lập giữa các yêu cầu phần mềm và các yêu cầu hệ thống;

e) Sự ưu tiên trong việc thực thi các yêu cầu phần mềm được định nghĩa;

f) Các yêu cầu phần mềm được chấp thuận và cập nhật khi cần thiết;

g) Các thay đổi tới các yêu cầu phần mềm được đánh giá về tác động kỹ thuật, thời hạn và chi phí;

h) Các yêu cầu phần mềm được giới hạn cơ bản và thông báo tới tất cả các bên tham gia chịu ảnh hưởng.

7.1.2.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 với sự liên quan tới quá trình phân tích các yêu cầu phần mềm.

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

Đối với mỗi thành phần phần mềm (hoặc thành phần cấu hình, nếu được định nghĩa) hoạt động này bao gồm các nhiệm vụ sau:

7.1.2.3.1.1. Bên triển khai phải thiết lập và tài liệu hóa các yêu cầu phần mềm (bao gồm các đặc tả các đặc tính chất lượng) được mô tả dưới đây:

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

b) Các giao diện ngoài thành phần phần mềm;

c) Các yêu cầu chất lượng;

d) Các đặc tả độ tin cậy, bao gồm những việc liên quan tới các phương pháp vận hành và bảo trì, các tác động của môi trường và tổn hại tới con người;

e) Các đặc tả tính an toàn, bao gồm những việc liên quan tới sự thỏa hiệp thông tin nhạy cảm;

f) Các đặc tả kỹ thuật có tính đến nhân tố con người (tối ưu yếu tố con người), bao gồm những việc liên quan đến các vận hành thủ công, các sự tương tác giữa người-thiết bị, các ràng buộc về nhân sự và các phạm vi cần tập trung chú ý nhân lực, chịu ảnh hưởng bởi việc đào tạo và các sai sót do nhân sự;

g) Các yêu cầu cơ sở dữ liệu và việc định nghĩa dữ liệu;

h) Các yêu cầu tiếp nhận và cài đặt sản phẩm phần mềm được chuyển giao tại bên vận hành và bảo trì;

i) Các yêu cầu tài liệu hướng dẫn người sử dụng;

j) Các yêu cầu thực thi và vận hành từ người sử dụng;

k) Các yêu cầu bảo trì từ người sử dụng.

CHÚ THÍCH 1: Sự hướng dẫn về việc xác định các đặc tính chất lượng có thể được tìm trong tiêu chuẩn ISO/IEC 9126-1.

CHÚ THÍCH 2: Việc ưu thực thi các yêu cầu phần mềm nên được xác định.

CHÚ THÍCH 3: Nếu tính khả dụng là một yêu cầu quan trọng, các khuyến nghị để đạt được mức mong muốn về tính khả dụng có thể tìm trong tiêu chuẩn ISO TR 18529. Phụ lục E bao gồm một quá trình tổng quan tập trung vào tính khả dụng.

7.1.2.3.1.2. Bên triển khai phải đánh giá các yêu cầu phần mềm bằng cách xem xét tiêu chí được liệt kê dưới đây. Kết quả của các đánh giá phải được tài liệu hóa.

a) Khả năng theo dõi các yêu cầu của hệ thống và thiết kế của hệ thống;

b) Tính nhất quán ngoài với các yêu cầu của hệ thống;

c) Tính nhất quán trong;

d) Khả năng kiểm tra;

e) Tính khả thi của thiết kế phần mềm;

f) Tính khả thi của việc vận hành và bảo trì.

7.1.2.3.1.3. Bên triển khai phải tiến hành soát xét phù hợp với mục 7.2.6.

CHÚ THÍCH: Tiếp sau quá trình soát xét và đánh giá thành công, các yêu cầu phần mềm nên được chấp thuận, giới hạn cơ bản và thông báo tới tất cả bên tham gia chịu ảnh hưởng. Các thay đổi sau đó tới giới hạn cơ bản các yêu cầu phần mềm nên được đánh giá về ảnh hưởng kỹ thuật, thời hạn và chi phí.

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

CHÚ THÍCH: Quá trình thiết kế kiến trúc phần mềm trong tiêu chuẩn này là quá trình mức độ thấp hơn của quá trình triển khai phần mềm. Người sử dụng tiêu chuẩn ISO/IEC 15288 có thể quyết định rằng quá trình này được thực hiện bởi quá trình thiết kế kiến trúc của tiêu chuẩn ISO/IEC 15288 trong việc áp dụng đệ quy của tiêu chuẩn đó.

7.1.3.1. Mục đích

Mục đích của quá trình thiết kế kiến trúc phần mềm là để cung cấp bản thiết kế phần mềm mà triển khai và có thể được xác minh dựa vào các yêu cầu.

7.1.3.2. Kết quả

Kết quả triển khai thành công của quá trình thiết kế kiến trúc phần mềm gồm:

a) Bản thiết kế kiến trúc phần mềm được phát triển và được giới hạn cơ bản để mô tả các thành phần phần mềm thực thi các yêu cầu phần mềm;

b) Các giao diện ngoài và trong mỗi thành phần phần mềm được định nghĩa;

c) Tính kiên định và khả năng theo dõi được thiết lập giữa các yêu cầu phần mềm và thiết kế phần mềm.

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

Dự án phải triển khai các hoạt động sau đây 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 thiết kế kiến trúc phần mềm.

CHÚ THÍCH: Hoạt động này được triển khai đối với mỗi thành phần phần mềm, thống nhất với thiết kế kiến trúc hệ thống.

7.1.3.3.1. Thiết kế kiến trúc phần mềm

Đối với mỗi thành phần phần mềm (hoặc thành phần cấu hình, nếu được định nghĩa) hoạt động này bao gồm các nhiệm vụ sau:

7.1.3.3.1.1. Bên triển khai phải chuyển đổi các yêu cầu đối với thành phần phần mềm thành kiến trúc mô tả cơ cấu hoàn chỉnh của nó và nhận biết các thành phần phần mềm. Nó phải được đảm bảo rằng tất cả các yêu cầu đối với thành phần phần mềm được phân phối tới các thành phần phần mềm của nó và tinh giản hơn nữa để thuận tiện thiết kế chi tiết. Kiến trúc thành phần phần mềm phải được tài liệu hóa.

CHÚ THÍCH: Thiết kế kiến trúc phần mềm cũng cung cấp cơ sở cho việc xác minh các thành phần phần mềm, tích hợp các thành phần phần mềm với mỗi thành phần khác và tích hợp các thành phần phần mềm với phần còn lại của các thành phần hệ thống.

7.1.3.3.1.2. Bên triển khai phải phát triển và tài liệu hóa thiết kế chỉnh về các giao diện ngoài đối với thành phần phần mềm và giữa các phần tử phần mềm của thành phần phần mềm đó.

7.1.3.3.1.3. Bên triển khai phải phát triển và tài liệu hóa thiết kế hoàn chỉnh về cơ sở dữ liệu.

7.1.3.3.1.4. Bên triển khai phải phát triển và tài liệu hóa các phiên bản sơ bộ của tài liệu hướng dẫn người sử dụng.

7.1.3.3.1.5. Bên triển khai phải định nghĩa và tài liệu hóa lịch trình và các yêu cầu kiểm tra sơ bộ đối với việc tích hợp phần mềm.

7.1.3.3.1.6. Bên triển khai phải đánh giá kiến trúc thành phần phần mềm, giao diện và các thiết kế cơ sở dữ liệu bằng cách xem xét các tiêu chí được liệt kê dưới đây. Kết quả của các đánh giá phải được tài liệu hóa.

a) Khả năng theo dõi các yêu cầu thành phần phần mềm;

b) Tính nhất quán ngoài với các yêu cầu của thành phần phần mềm;

c) Tính nhất quán trong giữa các thành phần phần mềm;

d) Sự phù hợp của các tiêu chuẩn và các phương pháp thiết kế được sử dụng;

e) Tính khả thi của thiết kế chi tiết;

f) Tính khả thi của việc vận hành và bảo trì.

7.1.3.3.1.7. Bên triển khai phải tiến hành soát xét phù hợp với mục 7.2.6

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

CHÚ THÍCH: Quá trình thiết kế chi tiết phần mềm trong tiêu chuẩn này là một quá trình mức độ thấp hơn của quá trình triển khai phần mềm.

7.1.4.1. Mục đích

Mục đích của quá trình thiết kế chi tiết phần mềm là để cung cấp bản thiết kế phần mềm mà phải triển khai và có thể được xác minh dựa vào các yêu cầu và kiến trúc phần mềm và được trình bày chi tiết một cách đầy đủ để cho phép mã hóa và kiểm tra.

7.1.4.2. Kết quả

Kết quả triển khai thành công của quá trình thiết kế chi tiết phần mềm gồm:

a) Bản thiết kế chi tiết của mỗi phần tử phần mềm, bằng cách mô tả các đơn vị phần mềm được xây dựng lên, được phát triển;

b) Các giao diện ngoài của mỗi đơn vị phần mềm được định nghĩa;

c) Tính nhất quán và khả năng theo dõi được thiết lập giữa các yêu cầu, thiết kế chi tiết và thiết kế kiến trúc.

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

Dự án 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 thiết kế chi tiết phần mềm.

7.1.4.3.1. Thiết kế chi tiết phần mềm

Đối với mỗi thành phần phần mềm (hoặc thành phần cấu hình, nếu được định nghĩa) hoạt động này bao gồm các nhiệm vụ sau:

7.1.4.3.1.1. Bên triển khai phải phát triển thiết kế chi tiết đối với mỗi phần tử phần mềm của thành phần phần mềm. Các phần tử phần mềm phải được tinh giản thành các mức độ thấp hơn bao gồm các đơn vị phần mềm mà có thể được mã hóa, biên dịch và kiểm tra. Nó phải được đảm bảo rằng tất cả các yêu cầu phần mềm được phân phối từ các phần tử phần mềm tới các đơn vị phần mềm. Thiết kế chi tiết phần mềm phải được tài liệu hóa.

7.1.4.3.1.2. Bên triển khai phải phát triển và tài liệu hóa thiết kế chi tiết đối với các giao diện ngoài thành phần phần mềm, giữa các phần tử phần mềm và giữa các đơn vị phần mềm. Thiết kế chi tiết các giao diện phải cho phép mã hóa mà không yêu cầu thông tin bổ sung nào.

7.1.4.3.1.3. Bên triển khai phải phát triển và tài liệu hóa thiết kế chi tiết về cơ sở dữ liệu.

7.1.4.3.1.4. Bên triển khai phải cập nhật tài liệu hướng dẫn người sử dụng khi cần thiết.

7.1.4.3.1.5. Bên triển khai phải định nghĩa và tài liệu hóa lịch trình và các yêu cầu kiểm tra để kiểm tra các đơn vị phần mềm. Các yêu cầu kiểm tra nên bao gồm việc nhấn mạnh đơn vị phần mềm tại các giới hạn các yêu cầu của nó.

7.1.4.3.1.6. Bên triển khai phải cập nhật lịch trình và các yêu cầu kiểm tra đối với việc tích hợp phần mềm.

7.1.4.3.1.7. Bên triển khai phải đánh giá thiết kế chi tiết phần mềm và các yêu cầu kiểm tra bằng cách xem xét các tiêu chí được liệt kê dưới đây. Kết quả của các đánh giá phải được tài liệu hóa:

a) Khả năng theo dõi các yêu cầu thành phần phần mềm;

b) Tính nhất quán ngoài đối với thiết kế kiến trúc;

c) Tính nhất quán trong giữa các thành phần phần mềm và các đơn vị phần mềm;

d) Sự phù hợp của các tiêu chuẩn và các phương pháp thiết kế được sử dụng;

e) Tính khả thi của việc kiểm tra;

f) Tính khả thi của việc vận hành và bảo trì.

7.1.4.3.1.8. Bên triển khai phải tiến hành soát xét phù hợp với mục 7.2.6.

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

CHÚ THÍCH: Quá trình xây dựng phần mềm trong tiêu chuẩn này là một quá trình mức độ thấp hơn của quá trình triển khai phần mềm.

7.1.5.1. Mục đích

Mục đích của quá trình xây dựng phần mềm là để đưa ra các đơn vị phần mềm có thể thực thi mà phản ánh một cách chính xác bản thiết kế phần mềm đó.

7.1.5.2. Kết quả

Kết quả triển khai thành công của quá trình xây dựng phần mềm gồm:

a) Các tiêu chí xác minh được định nghĩa đối với tất cả đơn vị phần mềm dựa vào các yêu cầu của chúng;

b) Các đơn vị phần mềm được định nghĩa bằng bản thiết kế được đưa ra;

c) Tính nhất quán và khả năng theo dõi được thiết lập giữa các yêu cầu, các đơn vị phần mềm và thiết kế;

d) Việc xác minh các đơn vị phần mềm dựa vào các yêu cầu và thiết kế được hoàn thiện.

7.1.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 có tổ chức có khả năng áp dụng trong quá trình xây dựng phần mềm.

7.1.5.3.1. Xây dựng phần mềm

Đối với mỗi thành phần phần mềm (hoặc thành phần cấu hình, nếu được định nghĩa) hoạt động này bao gồm các nhiệm vụ sau:

7.1.5.3.1.1. Bên triển khai phải phát triển và tài liệu hóa các điều sau:

a) Mỗi cơ sở dữ liệu và đơn vị phần mềm;

b) Dữ liệu và các thủ tục kiểm tra để kiểm tra mỗi cơ sở dữ liệu và đơn vị phần mềm.

7.1.5.3.1.2. Bên triển khai phải kiểm tra mỗi cơ sở dữ liệu và đơn vị phần mềm để đảm bảo rằng nó đáp ứng các yêu cầu. Kết quả kiểm tra phải được tài liệu hóa.

7.1.5.3.1.3. Bên triển khai phải cập nhật tài liệu hướng dẫn người sử dụng khi cần thiết.

7.1.5.3.1.4. Bên triển khai phải cập nhật lịch trình và các yêu cầu kiểm tra đối với việc tích hợp phần mềm.

7.1.5.3.1.5. Bên triển khai phải đánh giá việc mã hóa phần mềm và kết quả kiểm tra bằng cách xem xét các tiêu chí được liệt kê dưới đây. Kết quả của các đánh giá phải được tài liệu hóa.

a) Khả năng theo dõi các yêu cầu và thiết kế thành phần phần mềm;

b) Tính kiên định ngoài đối với các yêu cầu và thiết kế thành phần phần mềm;

c) Tính kiên định trong giữa các yêu cầu đơn vị;

d) Phạm vi kiểm tra các đơn vị;

e) Sự phù hợp của các tiêu chuẩn và các phương pháp mã hóa được sử dụng;

f) Tính khả thi của việc kiểm tra và tích hợp phần mềm;

g) Tính khả thi của việc vận hành và bảo trì.

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

CHÚ THÍCH: Quá trình tích hợp phần mềm trong tiêu chuẩn này là một quá trình mức độ thấp hơn của quá trình triển khai phần mềm. Người sử dụng tiêu chuẩn ISO/IEC 15288 có thể quyết định rằng quá trình này được thực hiện bởi quá trình tích hợp của tiêu chuẩn ISO/IEC 15288 trong việc áp dụng đệ quy của tiêu chuẩn đó.

7.1.6.1. Mục đích

Mục đích của quá trình tích hợp phần mềm là để kết hợp các đơn vị phần mềm và các phần tử phần mềm, tạo ra các thành phần phần mềm tích hợp, phù hợp với thiết kế phần mềm, thỏa mãn các yêu cầu phần mềm thuộc chức năng hoặc không thuộc chức năng dựa vào nền tảng hoạt động hoàn chỉnh hoặc tương đương

7.1.6.2. Kết quả

Kết quả triển khai thành công của quá trình tích hợp phần mềm gồm:

a) Chiến lược tích hợp được phát triển đối với các đơn vị phần mềm thống nhất với bản thiết kế phần mềm và các yêu cầu phần mềm ưu tiên;

b) Các tiêu chí xác minh đối với các thành phần phần mềm được phát triển để đảm bảo phù hợp với các yêu cầu phần mềm được phân phối tới các thành phần phần mềm;

c) Các thành phần phần mềm được xác minh sử dụng các tiêu chí xác định;

d) Các thành phần phần mềm được định nghĩa bằng chiến lược tích hợp được đưa ra;

e) Kết quả của việc kiểm tra tích hợp được ghi lại;

f) Tính kiên định và khả năng theo dõi được thiết lập giữa thiết kế phần mềm và các thành phần phần mềm;

g) Chiến lược hồi quy được phát triển và áp dụng để xác minh lại các thành phần phần mềm khi xảy ra thay đổi trong các đơn vị phần mềm (bao gồm mã hóa, thiết kế và các yêu cầu liên kết).

7.1.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 tích hợp phần mềm.

7.1.6.3.1. Tích hợp phần mềm

Đối với mỗi thành phần phần mềm (hoặc thành phần cấu hình, nếu được định nghĩa) hoạt động này bao gồm các nhiệm vụ sau:

7.1.6.3.1.1. Bên triển khai phải phát triển kế hoạch tích hợp để tích hợp các đơn vị phần mềm và các phần tử phần mềm vào trong thành phần phần mềm. Kế hoạch phải bao gồm các yêu cầu kiểm tra, các thủ tục, dữ liệu, các trách nhiệm và lịch trình. Kế hoạch này phải được tài liệu hóa.

7.1.6.3.1.2. Bên triển khai phải tích hợp các đơn vị phần mềm, các phần tử phần mềm và kiểm tra khi toàn bộ các phần tử được thực hiện phù hợp với kế hoạch tích hợp. Nó phải được đảm bảo rằng mỗi tổng thể đáp ứng các yêu cầu thành phần phần mềm và thành phần phần mềm đó được tích hợp tại thời điểm cuối của hoạt động tích hợp. Kết quả kiểm tra và tích hợp phải được tài liệu hóa.

CHÚ THÍCH: Chiến lược hồi quy nên được phát triển nhằm áp dụng để xác minh lại các thành phần phần mềm khi thay đổi được thực hiện trong các thành phần phần mềm (bao gồm mã hóa, thiết kế và các yêu cầu liên kết).

7.1.6.3.1.3. Bên triển khai phải cập nhật tài liệu hướng dẫn người sử dụng khi cần thiết.

7.1.6.3.1.4. Bên triển khai phải phát triển và tài liệu hóa đối với mỗi yêu cầu chất lượng của thành phần phần mềm, một bộ các bài kiểm tra, các trường hợp kiểm tra (các đầu vào, đầu ra, tiêu chí kiểm tra) và các thủ tục kiểm tra để tiến hành kiểm tra chất lượng phần mềm. Bên phát triển phải đảm bảo rằng thành phần phần mềm tích hợp là sẵn sàng đối với việc kiểm tra chất lượng phần mềm.

7.1.6.3.1.5. Bên triển khai phải đánh giá kế hoạch tích hợp, thiết kế, mã hóa, các bài đo, kết quả kiểm tra và tài liệu hướng dẫn người sử dụng bằng cách xem xét các tiêu chí được liệt kê dưới đây. Kết quả của các đánh giá phải được tài liệu hóa.

a) Khả năng theo dõi các yêu cầu hệ thống;

b) Tính kiên định ngoài đối với các yêu cầu hệ thống;

c) Tính kiên định trong;

d) Phạm vi kiểm tra các yêu cầu thành phần phần mềm;

e) Sự phù hợp của các tiêu chuẩn và các phương pháp kiểm tra được sử dụng;

f) Sự tuân thủ theo kết quả được kỳ vọng;

g) Tính khả thi của việc kiểm tra chất lượng phần mềm;

h) Tính khả thi của việc vận hành và bảo trì.

CHÚ THÍCH: Các tiêu chí đánh giá nên bao gồm Tính kiên định và khả năng theo dõi giữa thiết kế phần mềm và các thành phần phần mềm.

7.1.6.3.1.6. Bên triển khai phải tiến hành soát xét phù hợp với mục 7.2.6.

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

CHÚ THÍCH: Quá trình kiểm tra chất lượng phần mềm trong tiêu chuẩn này là một quá trình mức độ thấp hơn của quá trình triển khai phần mềm. Người sử dụng tiêu chuẩn ISO/IEC 15288 có thể quyết định rằng quá trình này được thực hiện bởi quá trình xác minh của tiêu chuẩn ISO/IEC 15288 trong việc áp dụng đệ quy của tiêu chuẩn đó.

7.1.7.1. Mục đích

Mục đích của quá trình kiểm tra chất lượng phần mềm là để xác nhận rằng sản phẩm phần mềm được tích hợp đáp ứng các yêu cầu xác định của nó.

7.1.7.2. Kết quả

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

a) Tiêu chí đối với phần mềm tích hợp được phát triển cho thấy sự tuân thủ đúng với các yêu cầu phần mềm;

b) Phần mềm tích hợp được xác minh bằng cách sử dụng các tiêu chí xác định;

c) Kết quả kiểm tra được ghi lại;

d) Chiến lược hồi quy được phát triển và áp dụng để kiểm tra lại phần mềm tích hợp khi sự thay đổi trong các thành phần phần mềm được thực hiện.

CHÚ THÍCH: Chiến lược hồi quy nên được phát triển, nhằm áp dụng để kiểm tra lại phần mềm tích hợp khi sự thay đổi được thực hiện trong các thành phần phần mềm.

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

Dự án 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 tra chất lượng phần mềm.

7.1.7.3.1. Kiểm tra chất lượng phần mềm

Đối với mỗi thành phần phần mềm (hoặc thành phần cấu hình, nếu được định nghĩa) hoạt động này bao gồm các nhiệm vụ sau:

7.1.7.3.1.1. Bên triển khai phải tiến hành kiểm tra chất lượng phù hợp với các yêu cầu chất lượng đối với thành phần phần mềm. Nó phải được đảm bảo rằng việc triển khai mỗi yêu cầu phần mềm được kiểm tra phù hợp. Kết quả kiểm tra chất lượng phải được tài liệu hóa.

7.1.7.3.1.2. Bên triển khai phải cập nhật tài liệu hướng dẫn người sử dụng khi cần thiết.

7.1.7.3.1.3. Bên triển khai phải đánh giá thiết kế, mã hóa, các bài kiểm tra, kết quả kiểm tra và tài liệu hướng dẫn người sử dụng bằng cách xem xét các tiêu chí được liệt kê dưới đây. Kết quả của các đánh giá phải được tài liệu hóa.

a) Phạm vi kiểm tra các yêu cầu của thành phần phần mềm;

b) Sự tuân thủ theo kết quả được kỳ vọng;

c) Tính khả thi của việc kiểm tra và tích hợp phần mềm, nếu được tiến hành;

d) Tính khả thi của việc vận hành và bảo trì.

7.1.7.3.1.4. Bên triển khai phải hỗ trợ kiểm tra phù hợp với mục 7.2.7. Kết quả của việc kiểm tra phải được tài liệu hóa. Nếu cả phần cứng và phần mềm đang phát triển hoặc tích hợp, việc kiểm tra có thể được đình chỉ lại cho đến khi kiểm tra chất lượng hệ thống.

7.1.7.3.1.5. Khi hoàn thiện thành công các việc kiểm tra, nếu được tiến hành, bên triển khai phải cập nhật và chuẩn bị sản phẩm phần mềm chuyển giao đối với việc tích hợp hệ thống, kiểm tra chất lượng hệ thống, cài đặt phần mềm hoặc hỗ trợ tiếp nhận phần mềm khi có thể áp dụng.

CHÚ THÍCH: Quá trình kiểm tra chất lượng phần mềm có thể được sử dụng trong quá trình xác minh phần mềm (mục 7.2.4) hoặc quá trình xác nhận phần mềm (mục 7.2.5).

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

CHÚ THÍCH: Các quá trình hỗ trợ được liệt kê dưới mục này là dành cho phần mềm và được gán tên là các quá trình hỗ trợ phần mềm. Mặc dù chúng đóng vài trò không thể thiếu trong việc hỗ trợ quá trình triển khai phần mềm, các quá trình hỗ trợ phần mềm cũng có thể cung cấp các dịch vụ tới các quá trình khác, ví dụ: các quá trình thỏa thuận, kiểm tra chất lượng các hệ thống, hỗ trợ tiếp nhận phần mềm, vận hành phần mềm và quá trình bảo trì phần mềm.

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

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 từ nhóm quá trình dự án trong tiêu chuẩn này.

7.2.1.1. Mục đích

Mục đích của quá trình quản lý tài liệu hướng dẫn phần mềm là để phát triển và duy trì thông tin phần mềm ghi được quá trình tạo ra.

CHÚ THÍCH: Tiêu chuẩn ISO/IEC 15289 cung cấp nội dung chi tiết hơn đối với các thành phần thông tin quá trình vòng đời (tài liệu hướng dẫn).

7.2.1.2. Kết quả

Kết quả triển khai thành công của quá trình quản lý tài liệu hướng dẫn phần mềm gồm:

a) Chiến lược xác định tài liệu hướng dẫn được đưa ra trong suốt vòng đời của sản phẩm hoặc dịch vụ phần mềm được phát triển;

b) Các tiêu chuẩn được áp dụng cho việc phát triển tài liệu hướng dẫn phần mềm được nhận biết;

c) Tài liệu hướng dẫn được quá trình hoặc dự án đưa ra, được nhận biết;

d) Nội dung và mục đích của tất cả tài liệu hướng dẫn được chỉ rõ, soát xét và được chấp thuận;

e) Tài liệu hướng dẫn được phát triển và thực hiện khả thi phù hợp với các tiêu chuẩn xác định;

f) Tài liệu hướng dẫn được duy trì phù hợp với các tiêu chí xác định.

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

Dự án 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ý tài liệu hướng dẫn phần mềm.

7.2.1.3.1. Triển khai quá trình

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

7.2.1.3.1.1. Kế hoạch, định nghĩa các tài liệu hướng dẫn được đưa ra trong suốt vòng đời sản phẩm phần mềm phải được phát triển, tài liệu hóa và được triển khai. Mỗi tài liệu hướng dẫn được định nghĩa phải gồm những nội dung sau:

a) Tiêu đề hoặc tên;

b) Mục đích và nội dung;

c) Đối tượng dự kiến;

d) Các thủ tục và các trách nhiệm đối với đầu vào, sự phát triển, soát xét, sửa đổi, chấp thuận, sản xuất, lưu trữ, phân phối, bảo trì và quản lý cấu hình;

e) Lịch trình đối với các phiên bản trung gian và cuối cùng.

7.2.1.3.2. Thiết kế và phát triển

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

7.2.1.3.2.1. Mỗi tài liệu xác định phải được thiết kế phù hợp với các tiêu chuẩn tài liệu hướng dẫn có khả năng áp dụng về phương tiện, định dạng, mô tả nội dung, đánh số trang, sắp xếp hình ảnh/bảng biểu, đánh dấu an toàn/sở hữu độc quyền, đóng gói và các mục trình bày khác.

CHÚ THÍCH: Tài liệu hướng dẫn có thể khởi tạo và hoàn thành theo bất kỳ định dạng nào (ví dụ: bằng lời nói, văn bản, đồ họa, số) và có thể được lưu trữ, xử lý, sao chép và chuyển giao sử dụng bất kỳ phương pháp nào (ví dụ: điện tử, in, từ, quang).

7.2.1.3.2.2. Nguồn gốc và sự phù hợp của dữ liệu đầu vào đối với các tài liệu hướng dẫn phải được xác nhận. Các công cụ hỗ trợ tài liệu hướng dẫn tự động có thể được sử dụng.

7.2.1.3.2.3. Các tài liệu được chuẩn bị phải được soát xét và chỉnh sửa về định dạng, nội dung kỹ thuật và cách trình bày dựa vào tài liệu hướng dẫn. Tài liệu này phải được người có thẩm quyền chấp thuận là đầy đủ trước khi ban hành.

7.2.1.3.3. Sản xuất

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

7.2.1.3.3.1. Các tài liệu hướng dẫn phải được sản xuất và cung cấp phù hợp với kế hoạch. Việc sản xuất và phân phối các tài liệu này có thể sử dụng giấy, điện tử hoặc phương tiện khác. Các tài liệu gốc phải được lưu trữ phù hợp với các yêu cầu đối với việc lưu giữ hồ sơ, an toàn, bảo trì và sao lưu.

7.2.1.3.3.2. Các kiểm soát phải được thiết lập phù hợp với quá trình quản lý cấu hình phần mềm (mục 7.2.2).

7.2.1.3.4. Bảo trì

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

7.2.1.3.4.1. Các nhiệm vụ của quá trình bảo trì phần mềm, được yêu cầu khi tài liệu hướng dẫn được sửa đổi, phải được thực hiện (xem mục 6.4.10), Đối với các tài liệu về quản lý cấu hình, các sửa đổi phải được quản lý phù hợp với quá trình quản lý cấu hình phần mềm (mục 7.2.2).

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

CHÚ THÍCH: Quá trình quản lý cấu hình phần mềm là một cụ thể hóa của quá trình quản lý cấu hình từ nhóm quá trình dự án trong tiêu chuẩn này.

7.2.2.1. Mục đích

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

7.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ấu hình phần mềm gồm:

a) Chiến lược quản lý cấu hình phần mềm được phát triển;

b) Các thành phần được quá trình hoặc dự án tạo ra được nhận biết, định nghĩa và giới hạn cơ bản;

c) Các sửa đổi và phát hành các thành phần được kiểm soát;

d) Các sửa đổi và phát hành được làm cho khả dụng đối với các bên tham gia chịu ảnh hưởng;

e) Trạng thái của các thành phần và các sửa đổi được ghi lại và báo cáo;

f) Tính đầy đủ và tính kiên định của các thành phần được đảm bảo;

g) Việc lưu trữ, xử lý và chuyển giao các thành phần được kiểm soát.

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

Dự án phải triển khai các hoạt động 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ấu hình phần mềm.

7.2.2.3.1. Triển khai quá trình

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

7.2.2.3.1.1. Kế hoạch quản lý cấu hình phần mềm phải được phát triển. Kế hoạch phải mô tả: các hoạt động quản lý cấu hình; các thủ tục và lịch trình để thực hiện các hoạt động này; trách nhiệm của tổ chức về việc thực hiện các hoạt động này; mối liên hệ của chúng với các tổ chức khác, ví dụ, việc phát triển hoặc bảo trì phần mềm. Kế hoạch này phải được tài liệu hóa và được triển khai.

CHÚ THÍCH: Kế hoạch này có thể là một phần của kế hoạch quản lý cấu hình hệ thống.

7.2.2.3.2. Nhận biết cấu hình

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

7.2.2.3.2.1. Một lược đồ phải được thiết lập cho việc nhận biết các thành phần phần mềm và các phiên bản của chúng được kiểm soát đối với dự án. Đối với mỗi thành phần phần mềm và các phiên bản của nó, các điều sau đây phải được nhận biết: tài liệu hướng dẫn thiết lập giới hạn cơ bản; các tham chiếu phiên bản; các chi tiết nhận dạng khác.

7.2.2.3.3. Kiểm soát cấu hình

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

7.2.2.3.3.1. Những điều sau đây phải được thực hiện: nhận biết và ghi hồ sơ các yêu cầu thay đổi; phân tích và đánh giá các thay đổi; chấp thuận hoặc không chấp thuận yêu cầu đó; triển khai, xác minh và phát hành thành phần phần mềm được sửa đổi. Dấu vết kiểm tra phải tồn tại, nhờ đó mỗi sửa đổi, lý do sửa đổi và quyền cho phép sửa đổi có thể được theo dõi. Việc kiểm soát và kiểm tra tất cả truy cập tới các thành phần phần mềm được kiểm soát mà xử lý các chức năng quan trọng về độ an toàn hoặc độ tin cậy phải được thực hiện.

CHÚ THÍCH: Quá trình quản lý việc giải quyết vấn đề phần mềm có thể cung cấp sự hỗ trợ cho hoạt động này.

7.2.2.3.4. Báo cáo trạng thái cấu hình

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

7.2.2.3.4.1. Các hồ sơ quản lý và các báo cáo trạng thái thể hiện tình trạng và lịch sử của các thành phần phần mềm được kiểm soát, bao gồm các giới hạn cơ bản phải được chuẩn bị. Các báo cáo trạng thái nên bao gồm một số các thay đổi đối với dự án, các phiên bản thành phần phần mềm mới nhất, các nhận dạng phát hành, số lượng phát hành và các bản so sánh của các bản phát hành.

7.2.2.3.5. Đánh giá cấu hình

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

7.2.2.3.5.1. Các nội dung sau phải được xác định và đảm bảo; tính đầy đủ về mặt chức năng của các thành phần phần mềm dựa vào các yêu cầu của chúng và tính đầy đủ về mặt vật lý của các thành phần phần mềm (cho dù mã hóa và thiết kế của chúng có phản ánh sự mô tả kỹ thuật mới nhất hay không).

7.2.2.3.6. Chuyển giao và quản lý phát hành

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

7.2.2.3.6.1. Việc phát hành và chuyển giao các sản phẩm phần mềm và tài liệu hướng dẫn phải được kiểm soát một cách chính thức. Các bản sao chép gốc về mã nguồn và tài liệu hướng dẫn phải được duy trì trong suốt thời gian tồn tại của sản phẩm phần mềm. Mã nguồn và tài liệu hướng dẫn gồm các chức năng quan trọng về độ an toàn hoặc tin cậy phải được xử lý, lưu trữ, đóng gói và chuyển giao phù hợp với các chính sách của các tổ chức liên quan.

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

7.2.3.1. Mục đích

Mục đích của quá trình đảm bảo chất lượng phần mềm là để cung cấp sự đảm bảo rằng các quá trình và sản phẩm công việc tuân theo các kế hoạch và các quy định được định nghĩa trước đó.

7.2.3.2. Kết quả

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

a) Chiến lược để tiến hành đảm bảo chất lượng được phát triển;

b) Bằng chứng về việc đảm bảo chất lượng phần mềm được đưa ra và duy trì;

c) Các vấn đề và/hoặc không tuân thủ các yêu cầu được nhận dạng và ghi lại;

d) Sự tuân thủ của các sản phẩm, các quá trình và các hoạt động với các yêu cầu, các thủ tục và các tiêu chuẩn có khả năng áp dụng được xác minh.

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

Dự án 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 đảm bảo chất lượng phần mềm.

7.2.3.3.1. Triển khai quá trình

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

7.2.3.3.1.1. Quá trình đảm bảo chất lượng phù hợp với dự án phải được thiết lập. Các mục đích của quá trình đảm bảo chất lượng phải đảm bảo rằng các sản phẩm phần mềm và các quá trình sử dụng để cung cấp các sản phẩm phần mềm đó tuân theo các yêu cầu đã được thiết lập của chúng và tuân thủ các kế hoạch đã được thiết lập của chúng.

7.2.3.3.1.2. Quá trình đảm bảo chất lượng nên được phối hợp với quá trình xác minh phần mềm (mục 7.2.4), quá trình xác nhận phần mềm (mục 7.2.5), 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).

7.2.3.3.1.3. Kế hoạch để tiến hành các hoạt động và nhiệm vụ của quá trình đảm bảo chất lượng phải được phát triển, tài liệu hóa, triển khai và duy trì trong suốt thời gian tồn tại của hợp đồng. Kế hoạch phải bao gồm như sau:

a) Các tiêu chuẩn chất lượng, các phương pháp luận, các thủ tục và các công cụ để thực hiện các hoạt động đảm bảo chất lượng (hoặc các tham chiếu của chúng trong tài liệu hướng dẫn chính thức của tổ chức);

b) Các thủ tục đối với việc phối hợp và soát xét hợp đồng;

c) Các thủ tục đối với việc nhận dạng, thu thập, sắp xếp, duy trì và hủy bỏ các hồ sơ ghi chất lượng;

d) Các tài nguyên, lịch trình và các trách nhiệm đối với việc tiến hành các hoạt động đảm bảo chất lượng;

e) Các hoạt động và nhiệm vụ được lựa chọn từ việc hỗ trợ các quá trình, ví dụ: quá trình xác minh phần mềm (mục 7.2.4), quá trình xác nhận phần mềm (mục 7.2.5), 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) và quá trình giải quyết vấn đề phần mềm (mục 7.2.8).

7.2.3.3.1.4. Các hoạt động và nhiệm vụ đảm bảo chất lượng đang diễn ra và được lên lịch trình phải được thực thi. Khi các vấn đề hoặc sự không phù hợp với các yêu cầu hợp đồng được phát hiện, chúng phải được tài liệu hóa và được coi như đầu vào của quá trình giải quyết vấn đề (mục 7.2.8). Các hồ sơ ghi các hoạt động và nhiệm vụ này, việc thực thi, các vấn đề và các cách giải quyết vấn đề của chúng phải được chuẩn bị và duy trì.

7.2.3.3.1.5. Các hồ sơ ghi các hoạt động và nhiệm vụ đảm bảo chất lượng phải được làm cho khả dụng đối với bên mua sản phẩm như được chỉ định trong hợp đồng.

7.2.3.3.1.6. Phải được đảm bảo rằng những người chịu trách nhiệm cho việc đảm bảo tuân thủ các yêu cầu hợp đồng có quyền tự do tổ chức, có các tài nguyên và có thẩm quyền để cho phép đánh giá khách quan và để khởi tạo, tác động, giải quyết và xác minh các cách giải quyết vấn đề.

7.2.3.3.2. Đảm bảo sản phẩm

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

7.2.3.3.2.1. Phải được đảm bảo rằng tất cả kế hoạch được yêu cầu trong hợp đồng được tài liệu hóa, tuân thủ với hợp đồng, hai bên cùng thống nhất và được thực thi theo yêu cầu.

7.2.3.3.2.2. Phải được đảm bảo rằng các sản phẩm phần mềm và tài liệu hướng dẫn có liên quan tuân thủ hợp đồng và luôn gắn với các kế hoạch.

7.2.3.3.2.3. Trong việc chuẩn bị đối với việc chuyển giao các sản phẩm phần mềm, phải được đảm bảo rằng các sản phẩm phần mềm đã đáp ứng đầy đủ các yêu cầu hợp đồng và được bên mua sản phẩm chấp nhận.

7.2.3.3.3. Đảm bảo quá trình

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

7.2.3.3.3.1. Phải được đảm bảo rằng các quá trình vòng đời phần mềm đó (quá trình cung cấp, phát triển, vận hành, bảo trì và các quá trình hỗ trợ bao gồm cả đảm bảo chất lượng) được sử dụng cho dự án tuân thủ hợp đồng và luôn gắn với các kế hoạch.

7.2.3.3.3.2. Phải được đảm bảo rằng các bài thực hành kỹ thuật phần mềm trong, môi trường phát triển, môi trường kiểm tra và các thư viện tuân thủ theo hợp đồng.

7.2.3.3.3.3. Phải được đảm bảo rằng các yêu cầu hợp đồng chính có khả năng áp dụng được chuyển tới nhà thầu phụ và các sản phẩm phần mềm của nhà thầu phụ đáp ứng các yêu cầu hợp đồng chính.

7.2.3.3.3.4. Phải được đảm bảo rằng bên mua sản phẩm và các bên tham gia khác được cung cấp các sự hợp tác và hỗ trợ cần thiết phù hợp với hợp đồng, các đàm phán và các kế hoạch.

7.2.3.3.3.5. Nên được đảm bảo rằng các phép đo quá trình và sản phẩm phần mềm là phù hợp với các thủ tục và các tiêu chuẩn đã thiết lập.

7.2.3.3.3.6. Phải được đảm bảo rằng nhân lực được phân công có kỹ năng và kiến thức cần thiết để đáp ứng các yêu cầu của dự án và tiếp nhận bất kỳ khóa đào tạo cần thiết nào.

7.2.3.3.4. Đảm bảo các hệ thống chất lượng

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

7.2.3.3.4.1. Các hoạt động quản lý chất lượng bổ sung có thể được đảm bảo phù hợp với các điều khoản của TCVN ISO 9001.

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

7.2.4.1. Mục đích

Mục đích của quá trình xác minh phần mềm là để xác nhận rằng mỗi sản phẩm và/hoặc dịch vụ phần mềm của quá trình hoặc dự án phản ánh một cách chính xác các yêu cầu xác định.

7.2.4.2. Kết quả

Kết quả triển khai thành công của quá trình xác minh phần mềm gồm:

a) Chiến lược xác minh được phát triển và triển khai;

b) Các tiêu chí đối với việc xác minh tất cả các sản phẩm phần mềm cần thiết được xác định;

c) Các hoạt động xác minh cần thiết được thực hiện;

d) Các sai sót được xác định và ghi lại;

e) Kết quả của các hoạt động xác minh được làm cho khả dụng đối với khách hàng và các bên tham gia liên quan khác.

7.2.4.3. Hoạt động và kết quả

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 xác minh phần mềm.

7.2.4.3.1. Triển khai quá trình

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

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

a) Khả năng một lỗi không được phát hiện trong yêu cầu phần mềm hoặc hệ thống khiến gây tử vong hoặc gây thương tích cá nhân, vận hành thất bại hoặc thiệt hại hoặc mất mát về thiết bị ngẫu nhiên hoặc về tài chính;

b) Độ chín muồi của và các rủi ro liên quan tới công nghệ phần mềm được sử dụng;

c) Tính khả dụng của các nguồn vốn và các nguồn lực.

7.2.4.3.1.2. Nếu dự án đảm bảo nỗ lực xác minh, quá trình xác minh phải được thiết lập để xác minh sản phẩm phần mềm.

7.2.4.3.1.3. Nếu dự án đảm bảo nỗ lực xác minh độc lập, tổ chức đủ điều kiện chịu trách nhiệm về việc thực hiện xác minh phải được lựa chọn. Tổ chức này phải được đảm bảo về tính độc lập và thẩm quyền để thực hiện các hoạt động xác minh.

7.2.4.3.1.4. Căn cứ vào phạm vi, tầm quan trọng, độ phức tạp và mức độ rủi ro đã phân tích trên, các sản phẩm phần mềm và các hoạt động vòng đời mục tiêu yêu cầu xác minh phải được xác định. Các hoạt động và nhiệm vụ xác minh đã định nghĩa trong mục 7.2.4.3.2, bao gồm cả các công cụ, các kỹ thuật và các phương pháp liên quan để thực hiện các nhiệm vụ, phải được lựa chọn đối với các sản phẩm phần mềm và các hoạt động vòng đời mục tiêu.

7.2.4.3.1.5. Căn cứ vào các nhiệm vụ xác minh như đã xác định, kế hoạch xác minh phải được phát triển và tài liệu hóa. Kế hoạch này phải chỉ ra các sản phẩm phần mềm và các hoạt động vòng đời đưa ra để xác minh, các nhiệm vụ xác minh cần thiết đối với mỗi sản phẩm phần mềm và hoạt động vòng đời và lịch trình, các trách nhiệm, các tài nguyên liên quan. Kế hoạch này cũng phải giải quyết các thủ tục để chuyển tiếp các báo cáo xác minh tới bên mua sản phẩm và các tổ chức tham gia khác.

7.2.4.3.1.6. Kế hoạch xác minh phải được triển khai. Các vấn đề và các sự không phù hợp được phát hiện bởi nỗ lực xác minh phải được đưa vào quá trình giải quyết vấn đề phần mềm (mục 7.2.8). Tất cả các vấn đề và sự không phù hợp phải được giải quyết. Kết quả của các hoạt động xác minh phải được làm cho khả dụng đối với bên mua sản phẩm và các tổ chức tham gia khác.

7.2.4.3.2. Xác minh

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

7.2.4.3.2.1. Xác minh các yêu cầu. Các yêu cầu phải được xác minh bằng cách xem xét các tiêu chí được liệt kê dưới đây:

a) Các yêu cầu hệ thống là nhất quán, khả thi và có thể kiểm tra;

b) Các yêu cầu hệ thống đã được phân phối một cách phù hợp tới các thành phần phần cứng, các thành phần phần mềm và các hoạt động thủ công theo các tiêu chí thiết kế;

c) Các yêu cầu phần mềm là nhất quán, khả thi, có thể kiểm tra và phản ánh một cách chính xác các yêu cầu hệ thống;

d) Các yêu cầu phần mềm liên quan tới độ tin cậy, tính an toàn và mức độ rủi ro là chính xác như được thể hiện theo các phương pháp chặt chẽ phù hợp.

7.2.4.3.2.2. Xác minh thiết kế. Thiết kế phải được xác minh bằng cách xem xét các tiêu chí được kê dưới đây:

a) Thiết kế là đúng đắn và phù hợp với và có khả năng theo dõi tới các yêu cầu;

b) Thiết kế thực hiện đúng trình tự của các sự kiện, các đầu vào, đầu ra, các giao diện, luồng logic, phân bổ quỹ kích cỡ và thời gian và định nghĩa cô lập và khôi phục lỗi;

c) Thiết kế được lựa chọn có thể được xuất phát từ các yêu cầu;

d) Thiết kế triển khai các yêu cầu về độ tin cậy, an toàn và các yêu cầu quan trọng khác một cách chính xác như được thể hiện theo các phương pháp chặt chẽ phù hợp.

7.2.4.3.2.3. Xác minh mã nguồn. Mã nguồn phải được xác minh bằng cách xem xét các tiêu chí được liệt kê dưới đây:

a) Mã nguồn có thể khả năng theo dõi tới thiết kế và các yêu cầu, có thể kiểm tra, là chính xác và tuân thủ các yêu cầu và các tiêu chuẩn mã hóa;

b) Mã nguồn thực hiện đúng trình tự sự kiện, các giao diện nhất quán, luồng kiểm soát và dữ liệu đúng, tính đầy đủ, phân bổ quỹ kích thước và thời gian thích hợp và định nghĩa cô lập và khôi phục lỗi;

c) Mã nguồn được lựa chọn có thể xuất phát từ thiết kế hoặc các yêu cầu;

d) Mã nguồn triển khai các yêu cầu về độ tin cậy, an toàn và các yêu cầu quan trọng khác một cách chính xác như được thể hiện theo các phương pháp chặt chẽ phù hợp.

7.2.4.3.2.4. Xác minh việc tích hợp. Việc tích hợp phải được xác minh bằng cách xem xét các tiêu chí được liệt kê dưới đây:

a) Các đơn vị và các phần tử phần mềm của mỗi thành phần phần mềm đã được tích hợp đầy đủ và chính xác thành thành phần phần mềm;

b) Các thành phần phần cứng, các thành phần phần mềm và các hoạt động thủ công của hệ thống đã được tích hợp đầy đủ và chính xác thành hệ thống;

c) Các nhiệm vụ tích hợp đã được thực hiện phù hợp với kế hoạch tích hợp.

7.2.4.3.2.5. Xác minh tài liệu hướng dẫn. Tài liệu hướng dẫn phải được xác minh bằng cách xem xét các tiêu chí được liệt kê dưới đây:

a) Tài liệu hướng dẫn là đầy đủ, hoàn thiện và nhất quán;

b) Việc chuẩn bị tài liệu hướng dẫn là kịp thời;

c) Quản lý cấu hình các tài liệu tuân theo các thủ tục xác định,

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

7.2.5.1. Mục đích

Mục đích của quá trình xác nhận phần mềm là để xác nhận rằng các yêu cầu đối với việc sử dụng dự kiến cụ thể của sản phẩm phần mềm được đáp ứng.

7.2.5.2. Kết quả

Kết quả triển khai thành công của quá trình xác nhận phần mềm gồm:

a) Chiến lược xác nhận được phát triển và triển khai;

b) Các tiêu chí đối với việc xác nhận tất cả các sản phẩm cần thiết được xác định;

c) Các hoạt động xác nhận cần thiết được thực hiện;

d) Các vấn đề được nhận dạng và ghi lại;

e) Bằng chứng được cung cấp rằng các sản phẩm phần mềm như đã được phát triển là phù hợp đối với mục đích sử dụng của chúng;

f) Kết quả của các hoạt động xác nhận được làm cho khả dụng đối với khách hàng và các bên tham gia khác.

7.2.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 có tổ chức có khả năng áp dụng trong quá trình xác nhận phần mềm.

7.2.5.3.1. Triển khai quá trình

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

7.2.5.3.1.1. Việc xác định phải được thực hiện nếu dự án đảm bảo nỗ lực xác nhận và mức độ độc lập của tổ chức đối với nỗ lực cần thiết đó.

7.2.5.3.1.2. Nếu dự án đảm bảo nỗ lực xác nhận, quá trình xác nhận phải được thiết lập để xác nhận hệ thống hoặc sản phẩm phần mềm. Các nhiệm vụ xác nhận được định nghĩa dưới đây, bao gồm cả các công cụ, các kỹ thuật, các phương pháp liên kết cho việc thực hiện các nhiệm vụ, phải được lựa chọn.

7.2.5.3.1.3. Nếu dự án đảm bảo nỗ lực độc lập, tổ chức có khả năng chịu trách nhiệm để tiến hành xác nhận phải được lựa chọn. Bên thực hiện xác nhận phải được đảm bảo về tính độc lập và thẩm quyền để thực hiện các nhiệm vụ xác nhận.

7.2.5.3.1.4. Kế hoạch xác nhận phải được phát triển và tài liệu hóa. Kế hoạch này phải bao gồm, nhưng không giới hạn, như sau:

a) Các thành phần đưa ra để xác nhận;

b) Các nhiệm vụ xác nhận để được thực hiện;

c) Các tài nguyên, các trách nhiệm và lịch trình cho việc xác nhận;

d) Các thủ tục để chuyển tiếp các báo cáo xác nhận tới bên mua sản phẩm và các bên tham gia khác.

7.2.5.3.1.5. Kế hoạch xác nhận phải được triển khai. Các vấn đề và sự không phù hợp được phát hiện bởi việc xác nhận phải được đưa vào quá trình giải quyết vấn đề phần mềm (mục 7.2.8). Tất cả vấn đề và sự không phù hợp phải được giải quyết. Kết quả của các hoạt động xác nhận phải được làm cho khả dụng đối với bên mua sản phẩm và các tổ chức tham gia khác.

7.2.5.3.2. Xác nhận

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

CHÚ THÍCH: Các phương pháp khác bên cạnh việc kiểm tra (ví dụ: phân tích, mô hình hóa, mô phỏng, vv...) có thể được áp dụng đối với việc xác nhận.

7.2.5.3.2.1. Chuẩn bị các yêu cầu kiểm tra được lựa chọn, các trường hợp thử nghiệm và các đặc tả kiểm tra cho việc phân tích kết quả kiểm tra.

7.2.5.3.2.2. Đảm bảo rằng các yêu cầu kiểm tra, các trường hợp kiểm tra và các đặc tả kiểm tra này phản ánh các yêu cầu cụ thể đối với mục đích sử dụng.

7.2.5.3.2.3. Tiến hành các bài kiểm tra trong các mục 7.2.5.3.2.1 và 7.2.5.3.2.2, bao gồm:

a) Kiểm tra với các đầu vào suy biến, giới hạn và ứng suất;

b) Kiểm tra sản phẩm phần mềm về khả năng của nó để cô lập và giảm thiểu tác động của các lỗi; nghĩa là xuống cấp từ từ khi xảy ra lỗi, yêu cầu trợ giúp của bên vận hành khi có các trạng thái suy biến, giới hạn và ứng suất;

c) Kiểm tra rằng người sử dụng đại diện có thể đạt được một cách thành công các nhiệm vụ dự kiến của họ bằng cách sử dụng sản phẩm phần mềm đó.

7.2.5.3.2.4. Xác nhận rằng sản phẩm phần mềm đáp ứng được mục đích sử dụng của nó.

7.2.5.3.2.5. Kiểm tra sản phẩm phần mềm khi thích hợp trong các phạm vi được lựa chọn của môi trường mục tiêu.

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

7.2.6.1. Mục đích

Mục đích của quá trình soát xét phần mềm là để duy trì sự hiểu biết chung với các bên liên quan về tiến độ so với các mục tiêu thỏa thuận và những gì nên được thực hiện để đảm bảo việc phát triển sản phẩm mà thỏa mãn các bên liên quan. Soát xét phần mềm có thể được thực hiện tại mức quản lý và kỹ thuật dự án và được tiến hành từ đầu tới cuối thời gian tồn tại của dự án.

7.2.6.2. Kết quả

Kết quả triển khai thành công của quá trình soát xét phần mềm gồm:

a) Soát xét về mặt kỹ thuật và quản lý được tiến hành dựa vào các nhu cầu của dự án;

b) Trạng thái các các sản phẩm của hoạt động từ một quá trình được đánh giá thông qua các hoạt động soát xét;

c) Kết quả soát xét được thông báo tới tất cả bên tham gia chịu ảnh hưởng;

d) Các hoạt động tạo ra từ việc soát xét được theo dõi tới khi đóng dự án;

e) Các rủi ro và các vấn đề được nhận dạng và ghi lại.

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

Dự án 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 soát xét phần mềm.

7.2.6.3.1. Triển khai quá trình

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

7.2.6.3.1.1. Soát xét định kỳ sẽ được thực hiện tại các mốc được xác định trước như đã chỉ định trong kế hoạch dự án. Các bên liên quan nên xác định nhu cầu đối với bất kỳ soát xét đặc biệt nào trong đó các bên tham gia thỏa thuận có thể tham gia.

7.2.6.3.1.2. Tất cả các tài nguyên được yêu cầu để tiến hành soát xét sẽ được cung cấp. Các tài nguyên này bao gồm nhân lực, địa điểm, phương tiện, phần cứng, phần mềm và các công cụ.

7.2.6.3.1.3. Các bên tham gia tham gia trong quá trình soát xét nên thỏa thuận các nội dung sau tại mỗi quá trình soát xét: nội dung cuộc họp, các sản phẩm phần mềm (kết quả của một hoạt động) và các vấn đề được soát xét; phạm vi và các thủ tục; các điều kiện bắt đầu và kết thúc đối với việc soát xét.

7.2.6.3.1.4. Các vấn đề được phát hiện trong khi soát xét sẽ được ghi lại và đưa vào quá trình giải quyết vấn đề phần mềm (mục 7.2.8) khi cần thiết.

7.2.6.3.1.5. Kết quả soát xét phải được tài liệu hóa và được thông báo. Thông báo này bao gồm sự chấp thuận, không chấp thuận hoặc chấp thuận ngẫu nhiên về kết quả soát xét.

7.2.6.3.1.6. Các bên tham gia tham gia sẽ thỏa thuận về kết quả soát xét và bất kỳ trách nhiệm hành động và tiêu chí kết thúc nào.

7.2.6.3.2. Soát xét việc quản lý dự án

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

7.2.6.3.2.1.Tình trạng dự án phải được đánh giá liên quan tới các hướng dẫn, các tiêu chuẩn, các lịch trình và các kế hoạch dự án có khả năng áp dụng. Kết quả soát xét nên được xem xét bởi việc quản lý phù hợp và nên cung cấp các điều sau:

a) Thực hiện các hoạt động theo kế hoạch, dựa vào việc đánh giá trạng thái hoạt động hoặc sản phẩm phần mềm;

b) Duy trì việc kiểm soát toàn bộ dự án thông qua việc phân phối đầy đủ các tài nguyên;

c) Thay đổi hướng dự án hoặc xác định nhu cầu về việc lập kế hoạch thay thế;

d) Đánh giá và quản lý các vấn đề rủi ro có thể hủy hoại sự thành công của dự án.

7.2.6.3.3. Soát xét kỹ thuật

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

7.2.6.3.3.1. Soát xét kỹ thuật sẽ được thực hiện để đánh giá các sản phẩm hoặc các dịch vụ phần mềm dưới việc xem xét và cung cấp bằng chứng rằng:

a) Các sản phẩm hoặc các dịch vụ phần mềm là hoàn thiện;

b) Các sản phẩm hoặc các dịch vụ phần mềm tuân thủ các đặc tả kỹ thuật và các tiêu chuẩn;

c) Các thay đổi đến các sản phẩm hoặc các dịch vụ phần mềm được triển khai một cách phù hợp và chỉ ảnh hưởng tới các phạm vi được quá trình quản lý cấu hình định nghĩa (mục 7.2.2);

d) Các sản phẩm hoặc các dịch vụ phần mềm tuân theo các lịch trình có thể áp dụng;

e) Các sản phẩm hoặc các dịch vụ phần mềm là sẵn sàng cho hoạt động kế hoạch tiếp theo;

f) Sự phát triển, vận hành hoặc bảo trì được tiến hành theo các kế hoạch, các lịch trình, các tiêu chuẩn và các hướng dẫn của dự án.

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

7.2.7.1. Mục đích

Mục đích của quá trình kiểm tra phần mềm là để xác định một cách độc lập sự tuân thủ của các quá trình và các sản phẩm được lựa chọn với các yêu cầu, các kế hoạch và thỏa thuận, khi thích hợp.

7.2.7.2. Kết quả

Kết quả triển khai thành công của quá trình kiểm tra phần mềm gồm:

a) Chiến lược kiểm tra được phát triển và triển khai;

b) Việc tuân thủ của các quá trình và/hoặc các dịch vụ và/hoặc các sản phẩm phần mềm được lựa chọn với các yêu cầu, các kế hoạch và sự thỏa thuận được xác định theo chiến lược kiểm tra;

c) Các việc kiểm tra được bên tham gia độc lập phù hợp tiến hành;

d) Các vấn đề được phát hiện trong suốt quá trình kiểm tra được nhận dạng và thông báo tới bên chịu trách nhiệm về hoạt động khắc phục và giải quyết.

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

Dự án 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 tra phần mềm.

7.2.7.3.1. Triển khai quá trình

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

7.2.7.3.1.1. Các quá trình kiểm tra sẽ được thực hiện tại các mốc được xác định trước như đã chỉ định trong kế hoạch dự án.

7.2.7.3.1.2. Người kiểm tra sẽ không có bất kỳ trách nhiệm trực tiếp nào đối với các hoạt động và các sản phẩm phần mềm mà họ kiểm tra.

7.2.7.3.1.3. Tất cả các tài nguyên được yêu cầu để tiến hành việc kiểm tra sẽ được các bên tham gia đồng ý. Các tài nguyên này bao gồm người hỗ trợ, địa điểm, các phương tiện, phần cứng, phần mềm và các công cụ.

7.2.7.3.1.4. Các bên tham gia nên thỏa thuận các nội dung sau tại mỗi lần kiểm tra: nội dung; các sản phẩm phần mềm (và kết quả của một hoạt động) được rà soát; các thủ tục và phạm vi kiểm tra; các điều kiện bắt đầu và kết thúc việc kiểm tra.

7.2.7.3.1.5. Các vấn đề được phát hiện trong các quá trình kiểm tra sẽ được ghi lại và đưa vào quá trình giải quyết vấn đề phần mềm (mục 7.2.8) khi cần thiết.

7.2.7.3.1.6. Sau khi hoàn thành quá trình kiểm tra, kết quả kiểm tra có thể được tài liệu hóa và được cung cấp tới bên tham gia được kiểm tra. Bên tham gia được kiểm tra sẽ xác nhận tới bên tham gia kiểm tra bất kỳ vấn đề nào được tìm thấy trong quá trình kiểm tra và các cách giải quyết vấn đề liên quan đã lập kế hoạch.

7.2.7.3.1.7. Các bên tham gia sẽ thỏa thuận về kết quả kiểm tra và bất kỳ trách nhiệm hành động và tiêu chí kết thúc nào.

7.2.7.3.2. Kiểm tra phần mềm

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

7.2.7.3.2.1. Các quá trình kiểm tra phần mềm sẽ được tiến hành để đảm bảo rằng:

a) Khi được viết mã, các sản phẩm phần mềm (ví dụ: một thành phần phần mềm) phản ánh đúng tài liệu hướng dẫn thiết kế;

b) Các yêu cầu đo kiểm và rà soát tiếp nhận được quy định bởi tài liệu hướng dẫn là phù hợp đối với việc tiếp nhận các sản phẩm phần mềm;

c) Dữ liệu kiểm tra tuân thủ các đặc tả kỹ thuật;

d) Các sản phẩm phần mềm được kiểm tra thành công và đáp ứng các đặc tả kỹ thuật của chúng;

e) Các báo cáo kiểm tra là chính xác và các sự sai lệch giữa kết quả kỳ vọng và thực tế được giải quyết;

f) Tài liệu hướng dẫn người sử dụng tuân thủ các tiêu chuẩn như đã chỉ định;

g) Các hoạt động đã được tiến hành theo hợp đồng, các kế hoạch và các yêu cầu có thể áp dụng;

h) Các chi phí và lịch trình tuân thủ với các kế hoạch đã thiết lập.

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

7.2.8.1. Mục đích

Mục đích của quá trình giải quyết vấn đề phần mềm là để đảm bảo rằng tất cả vấn đề được phát hiện được nhận dạng, phân tích, quản lý và kiểm soát để giải quyết.

7.2.8.2. Kết quả

Kết quả triển khai thành công của quá trình giải quyết vấn đề phần mềm gồm:

a) Chiến lược quản lý vấn đề được phát triển;

b) Các vấn đề được ghi lại, nhận biết và phân loại;

c) Các vấn đề được phân tích và đánh giá để xác định giải pháp có khả năng áp dụng;

d) Giải quyết vấn đề được triển khai;

e) Các vấn đề được theo dõi tới khi đóng dự án;

f) Tình trạng của tất cả vấn đề đã báo cáo được nhận biết.

CHÚ THÍCH: Quá trình giải quyết vấn đề phần mềm có thể được sử dụng hoặc tương thích một cách dễ dàng để quản lý, theo dõi và kiểm soát các yêu cầu thay đổi phần mềm.

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

Dự án 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 giải quyết vấn đề phần mềm.

7.2.8.3.1. Triển khai quá trình

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

7.2.8.3.1.1. Quá trình giải quyết vấn đề sẽ được thiết lập để xử lý tất cả vấn đề (bao gồm cả sự không phù hợp) được phát hiện trong các hoạt động và các sản phẩm phần mềm. Quá trình này sẽ tuân theo các yêu cầu sau:

a) Quá trình này sẽ là một chu trình khép kín, đảm bảo rằng: tất cả vấn đề được phát hiện được báo cáo ngay lập tức và được đưa vào quá trình giải quyết vấn đề; hoạt động được khởi tạo dựa vào chúng; các bên tham gia liên quan được cho biết về sự tồn tại của vấn đề khi thích hợp; các nguyên nhân được xác định, phân tích và, khi có thể, được loại bỏ; cách giải quyết và hủy bỏ được hoàn thiện; tình trạng được theo dõi và báo cáo; các bàn ghi hồ sơ các vấn đề được duy trì như đã quy định trong hợp đồng;

b) Quá trình nên bao gồm một lược đồ để phân loại và ưu tiên các vấn đề, Mỗi vấn đề nên được phân loại bởi hạng mục và sự ưu tiên để thuận tiện phân tích xu hướng và giải quyết vấn đề;

c) Việc phân tích sẽ được thực hiện để phát hiện các xu hướng trong các vấn đề đã báo cáo;

d) Việc hủy bỏ và giải quyết vấn đề sẽ được đánh giá: để đánh giá rằng các vấn đề đã được giải quyết, các xu hướng bất lợi đã được thay đổi hoàn toàn và các thay đổi đã được triển khai một cách chính xác trong các hoạt động và các sản phẩm phần mềm phù hợp; để xác định xem liệu các vấn đề bổ sung đã được đưa ra hay chưa.

7.2.8.3.2. Giải quyết vấn đề

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

7.2.8.3.2.1. Khi các vấn đề (bao gồm cả sự không phù hợp) đã được phát hiện trong một sản phẩm phần mềm hoặc một hoạt động, một bản báo cáo vấn đề sẽ được chuẩn bị để mô tả mỗi vấn đề đã phát hiện. Bản báo cáo vấn đề sẽ được sử dụng như một phần của quá trình vòng kín đã mô tả trên: từ việc phát hiện vấn đề, thông qua sự khảo sát, phân tích, giải quyết vấn đề và nguyên nhân của nó, cho đến việc phát hiện xu hướng qua các vấn đề đó.

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

CHÚ THÍCH: Người sử dụng tiêu chuẩn này, mong muốn thông qua các thủ tục tái sử dụng phần mềm của tổ chức, có thể yêu cầu bổ sung các điều khoản của tiêu chuẩn này với các điều khoản của tiêu chuẩn IEEE, IEEE std 1517™-1999.

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

7.3.1.1. Mục đích

Mục đích của quá trình kỹ thuật miền là để phát triển và duy trì các mô hình miền, các kiến trúc miền và các tài sản đối với miền đó.

7.3.1.2. Kết quả

Kết quả triển khai thành công của quá trình kỹ thuật miền gồm:

a) Các định dạng trình bày cho các mô hình miền và các kiến trúc miền được lựa chọn;

b) Các giới hạn miền và các mối quan hệ của nó tới các miền khác được thiết lập;

c) Mô hình miền đạt được các chức năng, khái niệm, khả năng và các tính năng khác biệt và chung trong miền đó được phát triển;

d) Kiến trúc miền mô tả tập hợp các hệ thống trong miền đó, bao gồm cả các sự khác biệt và các sự tương đồng, được phát triển;

e) Các tài sản thuộc về miền được chỉ định;

f) Các tài sản thuộc về miền được mua hoặc phát triển và duy trì từ đầu tới cuối các vòng đời của chúng;

g) Các kiến trúc và mô hình miền được duy trì từ đầu tới cuối các vòng đời của chúng;

CHÚ THÍCH 1: Kỹ thuật miền là một phương pháp tiếp cận dựa trên việc tái sử dụng để định nghĩa phạm vi (ví dụ: định nghĩa miền), chỉ rõ cấu trúc (ví dụ: kiến trúc miền) và xây dựng các tài sản (ví dụ: các yêu cầu, các thiết kế, mã phần mềm, tài liệu hướng dẫn) đối với một lớp các hệ thống, các hệ thống nhỏ hoặc các ứng dụng.

CHÚ THÍCH 2: Quá trình kỹ thuật miền có thể xếp chồng với các quá trình phát triển và bảo trì sử dụng các tài sản được quá trình kỹ thuật miền tạo ra.

7.3.1.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 kỹ thuật miền.

CHÚ THÍCH: Tiêu chuẩn IEEE Std 1517™-1999, cung cấp một tập các hoạt động và nhiệm vụ chi tiết hơn được sắp xếp tương ứng với các hoạt động và nhiệm vụ được trình bày dưới đây.

7.3.1.3.1. Triển khai quá trình

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

7.3.1.3.1.1. Kỹ sư thiết kế miền phải tạo ra và thực thi kế hoạch kỹ thuật miền.

7.3.1.3.1.2. Kỹ sư thiết kế miền phải lựa chọn định dạng trình bày được sử dụng đối với các mô hình và các kiến trúc miền.

7.3.1.3.1.3. Kỹ sư thiết kế miền phải thiết lập các thủ tục để tiếp nhận, giải quyết và cung cấp phản hồi tới bên quản lý tài sản dù các vấn đề hoặc các yêu cầu thay đổi xảy ra đối với các tài sản được kỹ sư thiết kế miền phát triển.

7.3.1.3.2. Phân tích miền

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

7.3.1.3.2.1. Kỹ sư thiết kế miền phải định nghĩa các giới hạn của miền và các mối quan hệ giữa miền này với các miền khác.

7.3.1.3.2.2. Kỹ sư thiết kế miền phải nhận biết các nhu cầu trước đó và hiện hành của các bên liên quan về các sản phẩm phần mềm trong miền này.

7.3.1.3.2.3. Kỹ sư thiết kế miền phải xây dựng các mô hình miền sử dụng các định dạng trình bày đã được lựa chọn trong hoạt động triển khai quá trình trong quá trình này.

7.3.1.3.2.4. Kỹ sư thiết kế miền phải xây dựng bảng từ vựng cung cấp thuật ngữ để mô tả các khái niệm miền quan trọng và các mối quan hệ giữa các tài sản chung hoặc tương tự của miền.

7.3.1.3.2.5. Kỹ sư thiết kế miền phải phân loại và tài liệu hóa các mô hình miền.

7.3.1.3.2.6. Kỹ sư thiết kế miền phải đánh giá các mô hình miền và bảng từ vựng miền phù hợp với các quy định về kỹ thuật mô hình được lựa chọn và phù hợp với các thủ tục xác thực và tiếp nhận tài sản của tổ chức.

7.3.1.3.2.7. Kỹ sư thiết kế miền phải tiến hành soát xét việc phân tích miền. Bên phát triển phần mềm, bên quản lý tài sản, chuyên gia về miền và người sử dụng sẽ được tính đến trong quá trình soát xét.

7.3.1.3.2.8. Kỹ sư thiết kế miền phải giao nộp các mô hình miền tới bên quản lý tài sản.

7.3.1.3.3. Thiết kế miền

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

7.3.1.3.3.1. Kỹ sư thiết kế miền phải tạo ra và tài liệu hóa kiến trúc miền, phù hợp với mô hình miền và các tiêu chuẩn của tổ chức như sau:

7.3.1.3.3.2. Kiến trúc miền sẽ được đánh giá phù hợp với các quy định của kỹ thuật thiết kế kiến trúc được lựa chọn và các thủ tục xác thực và tiếp nhận tài sản của tổ chức.

7.3.1.3.3.3. Đối với mỗi thực thể được lựa chọn để được thiết kế cho việc tái sử dụng. Kỹ sư thiết kế miền phải phát triển và tài liệu hóa đặc tả kỹ thuật tài sản.

7.3.1.3.3.4. Đối với mỗi tài sản xác định, đặc tả kỹ thuật của nó sẽ được đánh giá theo các thủ tục xác thực và tiếp nhận tài sản của tổ chức.

7.3.1.3.3.5. Kỹ sư thiết kế miền phải tiến hành soát xét thiết kế miền. Bên phát triển phần mềm, chuyên gia về miền và bên quản lý tài sản sẽ được tính đến trong việc soát xét này.

7.3.1.3.3.6. Kỹ sư thiết kế miền phải giao nộp kiến trúc miền tới bên quản lý tài sản.

7.3.1.3.4. Cung cấp tài sản

Đối với mỗi tài sản được phát triển hoặc được mua, hoạt động này bao gồm các nhiệm vụ sau:

7.3.1.3.4.1. Kỹ sư thiết kế miền phải có được tài sản bằng việc mua hoặc phát triển.

7.3.1.3.4.2. Kỹ sư thiết kế miền phải tài liệu hóa và phân loại tài sản.

7.3.1.3.4.3. Kỹ sư thiết kế miền phải đánh giá tài sản phù hợp với các thủ tục xác thực và tiếp nhận tài sản của tổ chức.

7.3.1.3.4.4. Kỹ sư thiết kế miền phải tiến hành soát xét tài sản. Bên phát triển phần mềm và bên quản lý tài sản sẽ được bao gồm trong việc soát xét này.

7.3.1.3.4.5. Kỹ sư thiết kế miền phải giao nộp tài sản tới bên quản lý tài sản.

7.3.1.3.5. Bảo trì tài sản

Nhiệm vụ liên quan tới việc tái sử dụng sau đây được bổ sung vào quá trình bảo trì phần mềm khi nó được áp dụng để bảo trì tài sản.

7.3.1.3.5.1. Khi phân tích các yêu cầu cho việc chỉnh sửa tài sản và lựa chọn các phương án triển khai, kỹ sư thiết kế miền sẽ xem xét:

a) Sự phù hợp với các mô hình miền và kiến trúc miền;

b) Ảnh hưởng lên các hệ thống và các sản phẩm phần mềm sử dụng tài sản đó;

c) Ảnh hưởng đến người sử dụng tài sản trong tương lai;

d) Ảnh hưởng đến khả năng tái sử dụng tài sản.

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

7.3.2.1. Mục đích

Mục đích của quá trình quản lý tài sản tái sử dụng là để quản lý thời gian tồn tại của các tài sản có thể tái sử dụng từ khi hình thành ý tưởng đến lúc ngừng sử dụng.

7.3.2.2. Kết quả

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

a) Chiến lược quản lý tài sản được tài liệu hóa;

b) Một lược đồ phân loại tài sản được thiết lập;

c) Tiêu chí đối với việc tiếp nhận, xác thực và ngừng sử dụng tài sản được định nghĩa;

d) Cơ chế khôi phục và lưu trữ tài sản được sử dụng;

e) Việc sử dụng các tài sản được ghi lại;

f) Các thay đổi đối với các tài sản được kiểm soát;