T I ê uchu ẩ n q u ố c g I a

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

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:

1. 
   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õ;
   
2. 
   Các ràng buộc vào giải pháp hệ thống được định nghĩa;
   
3. 
   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;
   
4. 
   Cơ sở để định nghĩa các yêu cầu hệ thống được mô tả;
   
5. 
   Cở sở để xác nhận sự tuân thủ dịch vụ được định nghĩa;
   
6. 
   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.
   

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.

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

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.

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

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.

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.

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 khả dụng, nhiệt độ) 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.

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:

1. 
   Các khả năng học hỏi, nhận thức và thể chất;
   
2. 
   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;
   
3. 
   Các điều kiện khẩn cấp, đặc biệt và bình thường;
   
4. 
   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: 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.

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

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.

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

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.

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.

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.

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

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.

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:

1. 
   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;
   
2. 
   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;
   
3. 
   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;
   
4. 
   Ả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õ;
   
5. 
   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;
   
6. 
   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;
   
7. 
   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í;
   
8. 
   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.

1. 
   Khả năng theo dõi các nhu cầu mua sản phẩm;
   
2. 
   Tính kiên định với các nhu cầu mua sản phẩm;
   
3. 
   Khả năng kiểm tra;
   
4. 
   Tính khả thi thiết kế kiến trúc hệ thống;
   
5. 
   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:

1. 
   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;
   
2. 
   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;
   
3. 
   Các yêu cầu được phân phối tới các thành phần hệ thống;
   
4. 
   Các giao diện ngoài và trong của mỗi thành phần hệ thống được định nghĩa;
   
5. 
   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;
   
6. 
   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;
   
7. 
   Tính kiên định và khả năng theo dõ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ì;
   
8. 
   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;
   
9. 
   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;
   
10. 
    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.

1. 
   Khả năng theo dõi các yêu cầu hệ thống;
   
2. 
   Tính kiên định với các yêu cầu hệ thống;
   
3. 
   Sự phù hợp của các phương pháp và tiêu chuẩn thiết kế được sử dụng;
   
4. 
   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;
   
5. 
   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 qúa 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:

1. 
   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;
   
2. 
   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;
   
3. 
   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;
   
4. 
   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;
   
5. 
   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;
   
6. 
   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;
   
7. 
   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ảii 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.

1. 
   Phạm vi kiểm tra của các yêu cầu hệ thống;
   
2. 
   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;
   
3. 
   Tuân thủ kết quả dự kiến;
   
4. 
   Tính khả thi của việc kiểm tra chất lượng hệ thống;
   
5. 
   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:

1. 
   Tiêu chí đánh giá tuân thủ theo các yêu cầu hệ thống được phát triển;
   
2. 
   Hệ thống tích hợp được kiểm tra bằng cách sử dụng tiêu chí xác định;
   
3. 
   Kết quả kiểm tra được ghi lại;
   
4. 
   Tính sẵn sàng của thệ 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.

1. 
   Phạm vi kiểm tra của các yêu cầu hệ thống;
   
2. 
   Tuân thủ kết quả dự kiến;
   
3. 
   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 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:

1. 
   Chiến lược cài đặt phần mềm được phát triển;
   
2. 
   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;
   
3. 
   Sản phẩm phần mềm được cài đặt trong môi trường mục tiêu;
   
4. 
   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:

1. 
   Sản phẩm được hoàn thiện và chuyền giao đến bên mua sản phẩm;
   
2. 
   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ợ;
   
3. 
   Sản phẩm được đưa vào hoạt động trong môi trường của khách hàng;
   
4. 
   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:

1. 
   Chiến lược vận hành được định nghĩa;
   
2. 
   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á;
   
3. 
   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ó;
   
4. 
   Sản phẩm phần mềm được vận hành trong môi trường dự kiến của nó;
   
5. 
   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:

1. 
   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;
   
2. 
   Ả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;
   
3. 
   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;
   
4. 
   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;
   
5. 
   Các cập nhật sản phẩm được chuyển tới môi trường khách hàng;
   
6. 
   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:

1. 
   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;
   
2. 
   Phạm vi, ví dụ: kích cỡ sửa đổi, chi phí liên quan, thời điểm sửa đổi;
   
3. 
   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:

1. 
   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;
   
2. 
   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:

1. 
   Phân tích các yêu cầu và định nghĩa sự chuyển đổi;
   
2. 
   Phát triển các công cụ chuyển đổi;
   
3. 
   Chuyển đổi sản phẩm phần mềm và dữ liệu;
   
4. 
   Thực thi chuyển đổi;
   
5. 
   Xác minh chuyển đổi;
   
6. 
   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:

1. 
   Trình bày tại sao môi trường cũ không được hỗ trợ nữa;
   
2. 
   Mô tả môi trường mới tại thời điểm khả dụng của nó;
   
3. 
   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:

1. 
   Chiến lược hủy bỏ phần mềm được định nghĩa;
   
2. 
   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;
   
3. 
   Các thành phần phần mềm của hệ thống được hủy bỏ hoặc lưu trữ;
   
4. 
   Môi trường được giữ lại theo điều kiện thỏa thuận;
   
5. 
   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:

1. 
   Ngừng hỗ trợ một phần hoặc toàn bộ sau một khoảng thời gian nhất định;
   
2. 
   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ó;
   
3. 
   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;
   
4. 
   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;
   
5. 
   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:

1. 
   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ó;
   
2. 
   Trình bày tại sao sản phẩm phần mềm không được hỗ trợ lâu hơn;
   
3. 
   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.

Каталог: Upload -> Store -> tintuc -> vietnam
vietnam -> BỘ thông tin truyềN thông thuyết minh đỀ TÀi xây dựng quy chuẩn kỹ thuật thiết bị giải mã truyền hình số MẶT ĐẤt set – top box (stb)
vietnam -> Kết luận số 57-kl/tw ngày 8/3/2013 của Ban Bí thư về tiếp tục đẩy mạnh công tác đào tạo, bồi dưỡng lý luận chính trị cho cán bộ lãnh đạo, quản lý các cấp
vietnam -> BỘ thông tin và truyềN thôNG
vietnam -> Quyết định số 46-QĐ/tw ngày 1/11/2011 của Ban Chấp hành Trung ương do đồng chí Nguyễn Phú Trọng ký về Hướng dẫn thực hiện các quy định về công tác kiểm tra, giám sát và kỷ luật của Đảng trong Chương VII và Chương VIII điều lệ Đảng khoá XI
vietnam -> Lời nói đầu 6 quy đỊnh chung 7
vietnam -> Mẫu số: 31 (Ban hành kèm theo Quyết định số 1131/2008/QĐ ttcp ngày 18 tháng 6 năm 2008 của Tổng thanh tra)
vietnam -> BỘ thông tin và truyềN thông học viện công nghệ BƯu chính viễN thông việt nam viện khoa học kỹ thuật bưU ĐIỆN
vietnam -> Quy định số 173- qđ/TW, ngày 11/3/2013 của Ban Bí thư về kết nạp lại đối với đảng viên bị đưa ra khỏi Đảng, kết nạp quần chúng VI phạm chính sách dân số và kế hoạch hóa gia đình vào Đảng
vietnam -> RÀ soáT, chuyểN ĐỔi nhóm các tiêu chuẩn ngành phao vô tuyến chỉ VỊ trí khẩn cấp hàng hảI (epirb) sang qui chuẩn kỹ thuậT
vietnam -> HÀ NỘI 2012 MỤc lục mở ĐẦU 2 chưƠng tổng quan về DỊch vụ truy nhập internet cố ĐỊnh băng rộng tại việt nam 3

tải về 1.07 Mb.

Chia sẻ với bạn bè của bạn: