Tiêu chuẩn TCVN 8706:2011 Quy trình cho bên đánh giá sản phẩm phần mềm

TIÊU CHUẨN QUỐC GIA

TCVN 8706:2011

CÔNG NGHỆ THÔNG TIN - ĐÁNH GIÁ SẢN PHẨM PHẦN MỀM - PHẦN 2: QUY TRÌNH CHO BÊN ĐÁNH GIÁ

Information technology - Software product evaluation - Part 2: Process for evaluators

Lời nói đầu

TCVN 8706:2011 được xây dựng trên cơ sở ISO/IEC 14598-5.

TCVN 8706:2011 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ố.

CÔNG NGHỆ THÔNG TIN - ĐÁNH GIÁ SẢN PHẨM PHẦN MỀM - PHẦN 2: QUY TRÌNH CHO BÊN ĐÁNH GIÁ

Information technology - Software product evaluation - Part 2: Process for evaluators

1  Phạm vi áp dụng

Tiêu chuẩn này cung cấp các yêu cầu và các khuyến nghị cho triển khai thực tiễn đánh giá sản phẩm phần mềm khi nhiều bên tham gia cần hiểu, chấp nhận và tin tưởng các kết quả đánh giá.

Quy trình mô tả trong Tiêu chuẩn này xác định các hoạt động cần thiết để phân tích các yêu cầu đánh giá, để xác định, thiết kế, và thực hiện các hoạt động đánh giá và để kết luận đánh giá bất kì loại sản phẩm phần mềm nào.

Quy trình đánh giá này có thể được sử dụng để đánh giá các sản phẩm đang tồn tại sẵn, với điều kiện là các thành phần cần thiết của sản phẩm đã có sẵn, hoặc để đánh giá các sản phẩm đang phát triển.

CHÚ THÍCH: Đối với đánh giá sản phẩm đang phát triển, quy trình đánh giá cần được đồng bộ với quy trình phát triển sản phẩm phần mềm và các thành phần của sản phẩm sẽ được đánh giá như khi chúng được phân phối.

Tiêu chuẩn này có thể được sử dụng bởi:

• Bên đánh giá của phòng thử nghiệm, khi cung cấp các dịch vụ đánh giá sản phẩm phần mềm,

• Người cung cấp phần mềm, khi lập kế hoạch đánh giá các sản phẩm của họ, bao gồm đánh giá được thực hiện bằng các dịch vụ kiểm tra độc lập,

• Người mua sản phẩm, khi yêu cầu thông tin đánh giá từ người cung cấp hoặc dịch vụ kiểm tra,

• Người sử dụng phần mềm khi đánh giá các sản phẩm hoặc khi sử dụng các báo cáo đánh giá cung cấp bởi các phòng thử nghiệm,

• Các đơn vị chứng nhận khi xác định phương án chứng nhận mới cho sản phẩm phần mềm.

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

[1] TCVN 8702:2011 - Công nghệ thông tin - Chất lượng sản phẩm phần mềm - Phần 1: Các phép đánh giá ngoài.

[2] TCVN 8703:2011 - Công nghệ thông tin - Chất lượng sản phẩm phần mềm - Phần 2: Các phép đánh giá trong.

[3] TCVN 8704:2011 - Công nghệ thông tin - Chất lượng sản phẩm phần mềm - Phần 3: Các phép đánh giá chất lượng sử dụng.

[4] TCVN 8705:2011 - Công nghệ thông tin - Đánh giá sản phẩm phần mềm - Phần 1: Tổng quan.

[5] TCVN 8707:2011 - Công nghệ thông tin - Đánh giá sản phẩm phần mềm - Phần 3: Quy trình cho người phát triển.

[6] TCVN 8708:2011 - Công nghệ thông tin - Đánh giá sản phẩm phần mềm - Phần 4: Quy trình cho người mua sản phẩm.

[7] ISO/IEC 12119 - Information technology - Software pagkages - Quality requirements and testing (ISO/IEC 12119 - Công nghệ thông tin - Gói phần mềm - Các yêu cầu chất lượng và kiểm tra).

[8] ISO/IEC 12207 - Systems and software engineering - Software life cycle processes (ISO/IEC 12207 - Kỹ thuật hệ thống và phần mềm - Các quá trình vòng đời phần mềm).

[9] ISO/IEC 9126-1 - Software engineering - Product quality - Part 1: Quality model. (ISO/IEC 9126-1- Kỹ thuật phần mềm - Chất lượng sản phẩm - Phần 1: Mô hình chất lượng).

[10] ISO/IEC 14598-6 - Information technology - Software product evaluation - Part 6: Documentation of evaluation modules. (ISO/IEC 14598-6 - Công nghệ thông tin - Đánh giá sản phẩm phần mềm - Phần 6: Tài liệu các mô đun đánh giá).

[11] ISO/IEC Guide 25 - General requirements for the competence of calibration and testing laboratories (ISO/IEC Hướng dẫn 25 - Các yêu cầu chung đối với năng lực của các phòng thử nghiệm và hiệu chuẩn).

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

3.1

Bản ghi đánh giá (evaluation records)

Bằng chứng khách quan được soạn thảo của tất cả các hoạt động thực hiện và của tất cả các kết quả đạt được trong quy trình đánh giá.

3.2

Báo cáo đánh giá (evaluation report)

Tài liệu trình bày các kết quả đánh giá và thông tin liên quan với đánh giá.

3.3

Công cụ đánh giá (evaluation tool)

Dụng cụ có thể được sử dụng trong quy trình đánh giá để thu thập dữ liệu, thực hiện biên dịch dữ liệu hoặc tự động hóa một phần của đánh giá.

CHÚ THÍCH: Ví dụ của các công cụ như vậy là bộ phân tích mã nguồn để tính toán các phép đánh giá mã, các công cụ CASE để tạo ra các mô hình chính thức, môi trường kiểm tra chạy các chương trình thực hiện được, danh sách để thu thập dữ liệu thẩm tra hoặc bảng tính để tạo ra tổng hợp các phép đo.

3.4

Đánh giá sản phẩm phần mềm (software product evaluation)

Hoạt động kỹ thuật bao gồm tạo ra đánh giá một hay nhiều đặc tính của sản phẩm phần mềm tương thích với thủ tục xác định.

CHÚ THÍCH 1: Trong tiêu chuẩn này, thuật ngữ đánh giá được dùng để tránh nhầm lẫn với khái niệm kiểm tra được chấp thuận rộng rãi trong lĩnh vực kỹ thuật phần mềm.

CHÚ THÍCH 2: Đánh giá sản phẩm phần mềm không cần thiết là kiểm tra tuân thủ trong ngữ cảnh của phương án chứng nhận. Tuy nhiên, kiểm tra tuân thủ có thể là một phần của đánh giá.

3.5

Bên đánh giá (evaluator)

Tổ chức thực hiện đánh giá.

CHÚ THÍCH: Bên đánh giá có thể, ví dụ, là phòng Lab. Kiểm tra, bộ phận chất lượng của tổ chức phát triển phần mềm, tổ chức chính phủ hay người sử dụng.

3.6

Người phát triển sản phẩm phần mềm (software product developer)

Cá nhân hoặc tổ chức sản xuất sản phẩm phần mềm.

3.7

Người yêu cầu đánh giá (evaluation requester)

Cá nhân hoặc tổ chức yêu cầu đánh giá.

3.8

Phương pháp đánh giá (evaluation method)

Thủ tục mô tả hành động được thực hiện bởi bên đánh giá nhằm mục đích đạt được kết quả cho quá trình đo xác định hoặc xác minh áp dụng trên các thành phần sản phẩm hoặc trên toàn bộ sản phẩm.

4  Các khái niệm đánh giá

4.1  Các khía cạnh chung

Chất lượng của các sản phẩm phần mềm có thể được mô tả trên phạm vi của các đặc tính chất lượng như xác định trong ISO/IEC 9126-1. Tuy nhiên, đối với phép đo phần mềm, nói chung, phép đo trực tiếp các đặc tính là không thực tế. Chỉ có thể đánh giá các đặc tính này dựa trên phép đo của các thuộc tính rút ra thấp hơn của sản phẩm.

Trên ngữ cảnh đó, bên đánh giá có thể sử dụng kinh nghiệm của họ trong kỹ thuật phần mềm để đánh giá. Điều này có thể làm giảm tính khách quan của đánh giá. Mặt khác cần xem xét là khả năng sử dụng các phương pháp đánh giá không tiền định; mặc dù được xác định chính xác, như phương pháp có thể yêu cầu bên đánh giá lựa chọn cái nào không thể xác định.

CHÚ THÍCH: Ví dụ của phương pháp đánh giá không tiền định là phương pháp cấu thành từ chuyển thành phần đặc tả của sản phẩm tới mô hình chính thức và thực hiện hiệu năng hoặc đánh giá tính tin cậy của mô hình này; giai đoạn chuyển đổi kéo theo nhiều lựa chọn được thực hiện bởi bên đánh giá.

Do đó, tiêu chuẩn này cung cấp duy trì mức khách quan của đánh giá càng cao càng tốt trong tất cả các trường hợp. Chúng cung cấp phương hướng trong tổ chức trên quan điểm của các kết quả đánh giá trung gian và cuối cùng và giữ các bản ghi của quy trình đánh giá.

4.2  Điểm bắt đầu đánh giá

4.2.1  Thỏa thuận khởi đầu

Đánh giá của sản phẩm phần mềm xuất hiện khi người yêu cầu của đánh giá yêu cầu bên đánh giá thực thi đánh giá của sản phẩm phần mềm.

CHÚ THÍCH: Khi yêu cầu đánh giá, người yêu cầu trình bày các yêu cầu đánh giá được phân tích bởi bên đánh giá. Người yêu cầu và bên đánh giá tiếp theo sẽ thỏa thuận đặc tả đánh giá.

4.2.2  Các bên tham gia đánh giá

• Các người yêu cầu tiềm năng của đánh giá là, ví dụ,

• Người phát triển phần mềm,

• Người cung cấp phần mềm,

• Người mua sản phẩm phần mềm,

• Người sử dụng phần mềm,

• Người tích hợp hệ thống trong vai trò người khai thác sản phẩm phần mềm

Bên đánh giá tiềm năng là, ví dụ,

• Phòng Lab kiểm tra bên thứ ba,

• Các thực thể trong các tổ chức sản xuất hay phân phối phần mềm,

• Các thực thể trong các tổ chức mua hay sử dụng phần mềm,

• Các thực thể trong các tổ chức tích hợp hệ thống,

• Các tổ chức tạo lập so sánh giữa các sản phẩm.

Trong một số trường hợp, người phát triển của sản phẩm phần mềm tham gia vào đánh giá thậm chí nếu người phát triển không phải là người yêu cầu đánh giá.

4.3  Các đặc tính của quy trình đánh giá

Mục tiêu cơ bản của quy trình đánh giá được mô tả trong Tiêu chuẩn này là xúc tiến các đặc tính quy trình đánh giá của mong muốn như sau:

• Khả năng lặp lại: đánh giá lặp lại của cùng sản phẩm với cùng đặc tả đánh giá bởi cùng bên đánh giá phải cho các kết quả có thể chấp nhận giống hệt nhau,

• Khả năng tái diễn: đánh giá của cùng sản phẩm với cùng đặc tả đánh giá bởi các bên đánh giá khác nhau phải cho các kết quả có thể chấp nhận giống hệt nhau,

• Tính công bằng: đánh giá phải không lệch về bất cứ kết quả đặc thù nào,

• Tính khách quan: các kết quả đánh giá phải thực tế, tức là không mang ảnh hưởng của cảm giác hay ý kiến của bên đánh giá.

CHÚ THÍCH: Đánh giá của cùng sản phẩm có thể được dẫn dắt bởi các đặc tả đánh giá khác nhau. Chúng do đó không thể so sánh được và có thể dẫn đến các kết quả khác nhau.

4.4  Quy trình đánh giá

Quy trình đánh giá gồm có một bộ các hoạt động được quản lý trong mối hợp tác với người yêu cầu và bên đánh giá. Các hoạt động này được thực thi trên cơ sở dữ liệu cung cấp bởi người yêu cầu và bên đánh giá hoặc được tạo ra bởi các hoạt động khác. Chúng đưa ra dữ liệu được sử dụng bởi các hoạt động khác hoặc là kết quả của quy trình đánh giá

Các hoạt động được thiết kế để xem xét các vấn đề sau:

• Các mục tiêu thay đổi từ một trường hợp đánh giá sang trường hợp khác vì rằng các sản phẩm phần mềm được phát triển để thực hiện các yêu cầu khác nhau và người yêu cầu đánh giá có thể đồng ý các yêu cầu đánh giá đặc thù.

• Các sản phẩm phần mềm được cấu thành từ các bộ phận, khuôn dạng và bản chất của nó phụ thuộc vào các phương pháp phát triển mà chúng rất khác nhau.

• Các kỹ thuật đánh giá có thể rất nhiều và cần được lựa chọn để đưa vào các mục tiêu của đánh giá và kết cấu của sản phẩm.

Tất cả các xem xét này áp đặt tính mềm dẻo cao của quy trình.

4.4.1  Các hoạt động đánh giá

Quy trình đánh giá gồm có năm hoạt động đưa ra dưới đây:

• Thiết lập các yêu cầu đánh giá;

• Đặc tả đánh giá dựa trên các yêu cầu đánh giá và mô tả của sản phẩm cung cấp bởi người yêu cầu;

• Thiết kế đánh giá tạo tập kế hoạch đánh giá trên cơ sở của đặc tả đánh giá; hoạt động này xem xét các thành phần của sản phẩm phần mềm được đánh giá và các phương pháp đánh giá đề xuất bởi bên đánh giá;

• Thực hiện kế hoạch đánh giá bao gồm kiểm tra, mô hình hóa, đo và kiểm thử các sản phẩm và thành phần của nó tương ứng với kế hoạch đánh giá; các hành động này có thể được thực thi sử dụng các công cụ phần mềm (thường được cung cấp bởi bên đánh giá); các hành động được thực thi bởi bên đánh giá được ghi lại và các kết quả nhận được được đưa vào bản thảo báo cáo đánh giá;

• Kết luận của đánh giá, bao gồm đưa ra báo cáo đánh giá và tùy ý sử dụng bởi bên đánh giá sản phẩm được đánh giá cũng như các thành phần của nó khi chúng được phát đi độc lập.

4.4.2  Đầu vào quy trình đánh giá

Người yêu cầu cung cấp các yêu cầu là phiên bản đầu tiên của các yêu cầu đánh giá.

Người yêu cầu cung cấp, trong quá trình đánh giá, các đầu vào sau tới quy trình đánh giá:

• Mô tả sản phẩm,

• Các thành phần sản phẩm.

Mô tả sản phẩm định rõ sản phẩm phần mềm cũng như các thành phần của nó đưa ra để đánh giá.

CHÚ THÍCH.

1. Sản phẩm có thể gồm các tài liệu liên quan đến lập kế hoạch, quá trình hay các phương pháp phát triển sử dụng sản xuất nó. Tài liệu lập kế hoạch có thể gồm lịch trình, cấu trúc tổ chức hay chi phí ước lượng.

2. Nếu người yêu cầu là người sử dụng, họ phải đồng ý với người phát triển để hỗ trợ bên đánh giá và có thể yêu cầu người phát triển đưa ra cho bên đánh giá mô tả của các thành phần phần mềm và sản phẩm phần mềm được đánh giá.

Bên đánh giá cung cấp đầu vào sau cho quy trình đánh giá:

• Các đặc tả đánh giá xác định trước,

• Các phương pháp đánh giá và

• Các công cụ đánh giá.

4.4.3  Đầu ra quy trình đánh giá

Trong quy trình đánh giá, bên đánh giá cung cấp các sản phẩm đầu ra sau:

• Các bản ghi đánh giá, bao gồm kế hoạch đánh giá và các bản ghi hành động đánh giá,

• Bản thảo báo cáo đánh giá, bao gồm các yêu cầu đánh giá, đặc tả đánh giá và các kết quả đánh giá tổng hợp,

• Báo cáo đánh giá được soát xét.

Các yêu cầu đánh giá, đặc tả và kế hoạch là các sản phẩm trung gian của quy trình đánh giá. Các bản ghi đánh giá và báo cáo đánh giá là các sản phẩm cuối cùng của quy trình đánh giá.

Các yêu cầu đánh giá mô tả các mục tiêu của đánh giá; đặc biệt, các yêu cầu chất lượng cho sản phẩm được mô tả.

Đặc tả đánh giá xác định tất cả các phân tích và phép đo được thực hiện trên sản phẩm và trên các thành phần của nó. Các thành phần của sản phẩm sẽ được phân tích và đo được xác định.

Kế hoạch đánh giá mô tả các thủ tục vận hành cần thiết để thực hiện đặc tả đánh giá; đặc biệt, tất cả các phương pháp và công cụ được sử dụng trong đánh giá sẽ được mô tả.

Các bản ghi đánh giá gồm kế hoạch đánh giá và tài khoản chi tiết các hành động được thực hiện bởi bên đánh giá khi thực hiện kế hoạch đánh giá; các bản ghi được lưu giữ bởi bên đánh giá.

CHÚ THÍCH:

1. Các bản ghi đánh giá được lưu giữ để cho phép xử lý lại các kết quả đánh giá.

2. Hình sau đưa ra tổng quan quy trình được mô tả trên. Dòng thông tin giữa các hoạt động được xác định.

Báo cáo đánh giá chứa các yêu cầu đánh giá, đặc tả đánh giá, các kết quả từ các phép đo và các phân tích được thực hiện và bất cứ thông tin nào khác cần thiết cho phép lặp lại hoặc tái diễn đánh giá. Báo cáo đánh giá là bản thảo đầu tiên cho soát xét. Khi trên khuôn dạng cuối cùng, nó được gửi đến người yêu cầu.

Hình 1 - Quy trình đánh giá

4.5  Các quan hệ giữa đánh giá và vòng đời

Đánh giá sản phẩm phần mềm có thể được thực hiện trong ngữ cảnh của bất kì quá trình vòng đời nào như trong ISO/IEC 12207. Đặc biệt, đánh giá có thể xuất hiện trong một trong các quá trình mua sản phẩm, cung cấp, phát triển, vận hành hay bảo trì.

Quyết định dạng như đánh giá sản phẩm phần mềm có được thực hiện không có thể được đưa ra càng sớm càng tốt trong quá trình phát triển sản phẩm. Nếu điều này được làm đúng tại thời điểm bắt đầu của quá trình phát triển, thì có khả năng xây dựng trong quá trình phát triển phần mềm các phép đo và kiểm tra được thực hiện cho đánh giá. Điều này có thể đảm bảo khả năng tối đa cho sản phẩm thỏa mãn tất cả các yêu cầu liên quan các kết quả đánh giá, cũng như giảm thiểu rủi ro của các chi phí thêm, không mong đợi xảy ra.

Khi người yêu cầu là người phát triển sản phẩm, thỏa thuận trước đó với bên đánh giá thảo luận ý định đưa sản phẩm ra đánh giá cũng có thể giúp người phát triển lường trước bất cứ nhu cầu đặc biệt nào (như các tài liệu hay bằng chứng đặc thù có thể được yêu cầu) mà bên đánh giá có thể có.

Có khả năng rằng một số (hoặc thậm chí tất cả) các hành động đánh giá sẽ được thực hiện tại hiện trường hơn là tại chỗ của bên đánh giá. Trong trường hợp này, các hành động sẽ được kiểm soát bởi bên đánh giá để đảm bảo các kết quả công bằng.

Đối với các dự án phần mềm rất lớn, phức tạp có thể sẽ có lợi cho người phát triển có được hợp tác liên tục, chi tiết với bên đánh giá trong suốt quá trình phát triển sản phẩm để giảm thời gian và chi phí của quy trình đánh giá. Hợp tác này phải sao cho không giảm tính công bằng của bên đánh giá.

5  Các yêu cầu quy trình đánh giá

5.1  Các yêu cầu chung

5.1.1  Tổ chức và hệ thống chất lượng

Để thỏa mãn các đặc tính trình bày tại 4.3, khả năng lặp lại, khả năng tái diễn, tính công bằng và tính khách quan của các kết quả đánh giá bên đánh giá phải hành động trong ngữ cảnh tổ chức cung cấp tất cả các đảm bảo cần thiết để đạt được chất lượng đủ tốt cho các hoạt động của nó. Để thỏa mãn các yêu cầu này tổ chức bên đánh giá có thể kết hợp với các yêu cầu mô tả trong ISO/IEC Guide 25.

5.1.2  Các trách nhiệm người yêu cầu

Các trách nhiệm của người yêu cầu đánh giá phải là

• Thiết lập các quyền dựa trên luật pháp cần thiết trên sản phẩm phần mềm cho mục đích đánh giá.

• Cung cấp các thông tin cần thiết để xác định và mô tả sản phẩm,

• Công bố các yêu cầu đánh giá ban đầu và thỏa thuận với bên đánh giá xác định các yêu cầu đánh giá thực tế; các yêu cầu này cho đánh giá phải tuân thủ các quy định và tiêu chuẩn liên quan,

• Công bố các yêu cầu bí mật liên quan đến thông tin đưa ra cho đánh giá,

• Hành động, khi cần thiết, như người trung gian giữa người phát triển và bên đánh giá,

• Cung cấp cho bên đánh giá, khi cần, truy cập phù hợp tới máy tính và các thiết bị sử dụng cho phát triển và cho sử dụng vận hành của sản phẩm phần mềm,

• Cung cấp, khi cần, hỗ trợ cho bên đánh giá, bao gồm đào tạo và truy cập tới các nhân viên thích hợp,

• Đảm bảo cung cấp đúng hạn, khi cần, sản phẩm phần mềm, mô tả của nó và các thành phần, bao gồm tài liệu và các vật liệu khác,

• Thông báo, khi cần, cho bên đánh giá bất kì nhân tố nào có thể làm mất hiệu lực các kết quả đánh giá.

5.1.3  Các trách nhiệm bên đánh giá

Các trách nhiệm của bên đánh giá phải là

• Kiểm tra xem người yêu cầu có đủ các quyền dựa trên luật pháp trên sản phẩm phần mềm cho đánh giá được thực hiện; để làm việc đó, bên đánh giá có thể yêu cầu chứng thực từ người yêu cầu,

• Tuân thủ tính bí mật yêu cầu cho tất cả các thông tin được cung cấp bởi người yêu cầu, ví dụ, sản phẩm được đánh giá, các bản ghi đánh giá và báo cáo đánh giá,

• Cung cấp nhóm nhân viên chất lượng và được đào tạo thực thi đánh giá,

• Cung cấp các công cụ và công nghệ đánh giá,

• Thực thi đánh giá tương ứng với các yêu cầu đánh giá,

• Xử lí bất cứ công việc thực hiện nào trong đánh giá mà có ảnh hưởng tới kết quả đánh giá,

• Đảm bảo đưa ra đúng hạn báo cáo đánh giá cho người yêu cầu,

• Cung cấp tính minh bạch thực thi đánh giá cho các phạm vi được yêu cầu bởi người yêu cầu.

5.2  Thiết lập các yêu cầu đánh giá

5.2.1  Mục đích của thiết lập các yêu cầu đánh giá

Mục đích của thiết lập các yêu cầu đánh giá là mô tả các mục tiêu của đánh giá. Các mục tiêu liên quan đến sử dụng dự kiến của sản phẩm và các nguy cơ đi kèm của nó. Một loạt các quan điểm có thể được xem xét: của các người sử dụng sản phẩm khác nhau như người mua sản phẩm, người cung cấp, người phát triển, người vận hành hay người bảo trì.

5.2.2  Soạn thảo các yêu cầu đánh giá

Hoạt động phân tích các yêu cầu đánh giá được tổng hợp từ các hoạt động nhỏ hơn như sau:

• Đề xuất các yêu cầu người yêu cầu bởi người yêu cầu;

• Biểu diễn phạm vi bao phủ của đánh giá bởi người yêu cầu;

• Hỗ trợ người yêu cầu phân tích lí do đánh giá và mô tả các yêu cầu đánh giá bởi bên đánh giá;

• Giải thích phạm vi của tin cẩn và tính nghiêm ngặt bởi bên đánh giá;

• Thỏa thuận các yêu cầu đánh giá.

Người yêu cầu đánh giá phải cung cấp các yêu cầu của người yêu cầu là phiên bản ban đầu của các yêu cầu đánh giá. Bên đánh giá phải hỗ trợ người yêu cầu phân tích lí do đánh giá sản phẩm và mô tả các yêu cầu đánh giá.

Miền ứng dụng cho sản phẩm đưa ra đánh giá phải được xem xét, cũng như mô tả chung mục đích của nó. Các vấn đề chủ yếu như tính an toàn, bảo mật, các khía cạnh kinh tế hay môi trường có thể được xem xét. Các quy định và luật áp dụng phải được xem xét.

Trong các yêu cầu của người yêu cầu người yêu cầu phải biểu diễn các yêu cầu thể hiện mức bao hàm của đánh giá phải rộng như thế nào. Đồng thời bên đánh giá phải đảm bảo rằng đánh giá là đủ nghiêm ngặt để cung cấp tin cẩn thực trên chất lượng phần mềm. Do đó, bên đánh giá và người yêu cầu phải đồng thuận trên các yêu cầu đánh giá như điều kiện tiên quyết để tiếp tục quy trình đánh giá.

CHÚ THÍCH: Để chứng nhận sản phẩm phần mềm hoặc các thành phần của nó người yêu cầu đánh giá xác định tài liệu quy chuẩn chứa các yêu cầu cho sản phẩm.

5.2.3  Các nội dung của yêu cầu đánh giá

Các yêu cầu đánh giá phải chứa mô tả chung của miền ứng dụng cho sản phẩm đưa ra đánh giá. Mô tả chung của mục đích phần mềm phải được cung cấp.

Các yêu cầu đánh giá cũng phải gồm danh sách các yêu cầu chất lượng tham chiếu đến, ví dụ, tới các đặc tính chất lượng xác định trong ISO/IEC 9126. Trên ngữ cảnh đó, các đặc tính nhỏ có thể cũng được sử dụng, khi yêu cầu tham chiếu đến đặc tính không được xác định trong ISO/IEC 9126 phải viện dẫn tài liệu uy tín xác định nó và người yêu cầu và bên đánh giá phải công bố rõ ràng hiểu biết chung của họ về đặc tính này.

Mức độ quan trọng tương đối của đặc tính trong các yêu cầu đánh giá phải được đưa ra. Nó áp dụng khi một số phần của sản phẩm cần đánh giá có các yêu cầu đánh giá khác nhau. Để biểu diễn mức quan trọng này, chú thích mức đánh giá có thể được sử dụng.

Đối với từng yêu cầu trong các yêu cầu đánh giá, đặc tả thông tin được chứa trong sản phẩm phần mềm đánh giá và các thành phần của nó phải được cung cấp. Đặc tả này phải, càng nhiều càng tốt, tham chiếu đến tiêu chuẩn kỹ thuật phần mềm. Hơn nữa, loại của khuôn dạng sử dụng trong các thành phần hay loại của các phương pháp phát triển phần mềm sử dụng sản xuất chúng có thể được xác định.

CHÚ THÍCH: Phạm vi của khuôn dạng thông tin yêu cầu cho đánh giá có thể liên quan đến chi phí đánh giá, trên một mặt, và đến mức độ quan trọng của yêu cầu chất lượng cụ thể của sản phẩm, trên mặt khác.

5.2.4  Phê chuẩn và báo cáo

Các yêu cầu đánh giá phải được phê chuẩn như là kết quả của soát xét chung giữa người yêu cầu và bên đánh giá.

Các yêu cầu đánh giá phải được trình bày trong báo cáo đánh giá và các bản ghi đánh giá.

5.3  Đặc tả của đánh giá

5.3.1  Mục đích của đặc tả đánh giá

Mục đích đặc tả đánh giá phải được xác định trong phạm vi của đánh giá và các phép đo được thực hiện trên sản phẩm được đánh giá và trên các thành phần khác nhau của nó. Mức độ chi tiết trong đặc tả đánh giá phải sao cho, trên cơ sở của nó, khả năng lặp lại và khả năng tái diễn của đánh giá được đảm bảo.

CHÚ THÍCH 1: Đánh giá đặc tả có thể là không tiền định. Trong trường hợp đó, nó phải sao cho các kết quả đạt được từ đánh giá lặp lại và tái diễn là nhất quán.

Tuy nhiên, đặc tả đánh giá phải không chứa thông tin độc quyền của đánh giá.

CHÚ THÍCH 2: Báo cáo đánh giá, bao gồm đặc tả đánh giá được đưa đến người yêu cầu đánh giá có thể làm lộ cho các bên khác. Do đó có thể là không thích hợp cho bên đánh giá cố gắng bảo vệ một số thông tin độc quyền.

5.3.2  Soạn thảo đặc tả đánh giá

Hoạt động xác định đánh giá được cấu thành từ ba hoạt động nhỏ:

• Phân tích mô tả sản phẩm,

• Xác định các phép đo được thực hiện trong sản phẩm và các thành phần của nó,

• Thẩm tra đặc tả tạo ra theo các yêu cầu đánh giá.

CHÚ THÍCH: Thẩm tra các hoạt động nhỏ có thể được thực hiện song song với các hoạt động khác để nhận biết các vấn đề càng sớm càng tốt.

5.3.2.1  Phân tích mô tả sản phẩm

Người yêu cầu phải cung cấp mô tả sản phẩm đưa ra đánh giá. Mục tiêu của mô tả này là:

• Cho phép xác định phạm vi của đánh giá, tức là định rõ các thành phần sản phẩm phần mềm được xem xét như một phần của sản phẩm và định rõ các thành phần không được xem xét như một phần của sản phẩm và chỉ được tham chiếu tới để dễ dàng hiểu sản phẩm hơn.

CHÚ THÍCH:

1. Các xác định như vậy có thể dựa trên chi tiết các phần nào của tài liệu thuộc về sản phẩm, chức năng nào được thực hiện bởi sản phẩm hoặc không.

2. Xác định phạm vi của đánh giá quan trọng khi sản phẩm phần mềm được đưa ra đánh giá gắn liền với hệ thống bao gồm phần cứng, các sản phẩm phần mềm khác, các mạng và các tổ chức vì rằng phân biệt giữa các sản phẩm không phải bao giờ cũng rõ ràng.

• Đưa ra cho bên đánh giá nhận biết các thành phần sản phẩm được đánh giá, để hiểu cấu trúc của chúng và xác định thông tin được cung cấp cũng như truy cập nó như thế nào.

Mô tả này phải gồm danh sách các thành phần sản phẩm thực tế được đưa ra đánh giá, cơ sở lý lẽ về cấu trúc của sản phẩm và danh sách các tài liệu liên quan sản phẩm. Các thành phần liệt kê có thể bao gồm các thành phần nhỏ hơn không cần liệt kê. Đối với từng tài liệu liên quan thành phần và sản phẩm trong danh sách, các thông tin sau phải được cung cấp:

• Mô tả bản chất thành phần,

• Thông tin về khuôn dạng sử dụng trong thành phần,

• Thông tin về kích cỡ của thành phần,

• Quan hệ với các thành phần khác,

• Thông tin về tính hiệu dụng của thành phần sản phẩm cho bên đánh giá.

Trong bất kì trường hợp nào, tham chiếu đến các tiêu chuẩn kỹ thuật phần mềm tương ứng phải được thực hiện.

Bên đánh giá phải kiểm tra mô tả sản phẩm có tuân thủ các yêu cầu đề cập ở trên không.

Bên đánh giá phải phân tích cơ sở lý lẽ được cung cấp cũng như mô tả thành phần để xác định mối quan hệ với các thành phần được định rõ trong các yêu cầu đánh giá.

CHÚ THÍCH:

3. Trong các yêu cầu đánh giá, các thành phần có thể được xác định từ quan điểm lý thuyết, tương ứng với các đặc tính chất lượng được đánh giá. Trong mô tả sản phẩm các thành phần thực tế được liệt kê. Có thể xảy ra trường hợp một số thành phần thực tế của sản phẩm chứa thông tin mà các yêu cầu đánh giá xác định có trong một loạt thành phần.

4. Thông tin này cần thiết để nhận biết đánh giá nào có thể được thực hiện. Điều này sẽ được sử dụng, cùng với các yêu cầu đánh giá khác, để xây dựng đặc tả đánh giá.

5. Phân tích mô tả sản phẩm có thể được cải tiến nhờ tư vấn với người phát triển sản phẩm. Điều này có thể cung cấp cơ hội cho bên đánh giá thiết lập đánh giá sâu theo yêu cầu sẽ có khả năng hay không, bằng cách thực hiện kiểm toán ngắn gọn.

5.3.2.2  Xác định các phép đo

Bên đánh giá phải tự xác định các phép đo đánh giá trên sản phẩm và các thành phần khác nhau được định rõ trong mô tả sản phẩm. Điều này phải đưa đến phân tích các yêu cầu đánh giá thành các đặc tính nhỏ. Kết quả của phân tích này có thể khác nhau cho các thành phần đánh giá khác nhau. Trong giai đoạn này, một số thành phần liệt kê trong mô tả sản phẩm có thể không được xem xét trong tương lai.

Bên đánh giá phải đặc tả các phép đo dự kiến sử dụng để đánh giá các đặc tính, đặc tính nhỏ và thuộc tính của sản phẩm và các thành phần được chọn. Các đặc tả này phải được tạo lập như một tổng hợp của các loại báo cáo sau:

• Đặc tả chính thức của phép đánh giá được áp dụng hoặc một bộ xác định các thành phần, cùng hướng dẫn trình bày các hệ đo kết quả trong báo cáo đánh giá,

• Tham chiếu tới báo cáo trên thành phần sản phẩm xác định các yêu cầu phần mềm được thẩm tra và đặc tả của thủ tục được sử dụng thẩm tra các yêu cầu này,

• Đặc tả của yêu cầu cho sản phẩm phần mềm hoặc thiếu trong trong tài liệu yêu cầu phần mềm hoặc cần được giải thích chi tiết hơn cho đánh giá và đặc tả của thủ tục sử dụng thẩm tra yêu cầu này,

• Tham chiếu tới báo cáo trong các tiêu chuẩn hoặc quy định xác định mà các yêu cầu phần mềm bổ sung được cung cấp và đặc tả được sử dụng để thẩm tra các yêu cầu này.

Đối với mỗi báo cáo này tham chiếu phải được tạo lập tới bản chất và khuôn dạng sử dụng trong các thành phần được đo hay thẩm tra.

Đối với nhiệm vụ này, bên đánh giá có thể sử dụng các đặc tả đánh giá xác định trước. Các đặc tả cơ bản này phải có dạng đặc tả mô đun đánh giá như khuyến nghị trong ISO/IEC 14598-6.

5.3.2.3  Thẩm tra đặc tả đánh giá

Bên đánh giá phải thực thi thẩm tra đặc tả đánh giá theo các yêu cầu đánh giá.

Bên đánh giá phải kiểm tra các thành phần liệt kê trong mô tả đánh giá có cung cấp tất cả các thông tin cần thiết để thực hiện đánh giá tương ứng với các yêu cầu đánh giá không. Bên đánh giá cũng phải thẩm tra các phép đánh giá và các bằng chứng xác định có đầy đủ để đáp ứng các mục tiêu của đánh giá như trình bày trong các yêu cầu đánh giá không.

Kiểm tra ban đầu có thể đưa tới xác định các thông tin thiếu trong các thành phần liệt kê trong mô tả sản phẩm. Điều này có thể được giải quyết bằng một trong các cách sau:

• Tham chiếu tới thành phần sản phẩm bao hàm thông tin bị thiếu phải được bổ sung trong mô tả sản phẩm; điều đó có nghĩa là người yêu cầu sẽ cung cấp thành phần này cùng các thành phần khác để thực hiện đánh giá;

• Các mục tiêu của đánh giá phải được giảm, có nghĩa là các yêu cầu đánh giá được sửa đổi.

Kiểm tra tiếp theo nhắm đến khẳng định rằng các phép đo và báo cáo đề xuất trong đặc tả đánh giá là nhất quán với tình trạng kỹ thuật. Điều này có thể được thực hiện bằng một trong các cách sau:

• Xác định các tiêu chuẩn đo liên quan,

CHÚ THÍCH: Các tiêu chuẩn như vậy có thể là các mô đun đánh giá như được mô tả trong ISO/IEC 14598-6.

• Cung cấp hiệu chỉnh chi tiết, tài liệu tham chiếu có uy tín thích hợp trong lĩnh vực; hiệu chỉnh này phải được bao gồm trong đặc tả đánh giá.

5.3.3  Các nội dung đặc tả đánh giá

Đặc tả đánh giá phải gồm:

• Phạm vi của đánh giá cho các thành phần sản phẩm như được định rõ trong mô tả sản phẩm,

• Tham chiếu lẫn nhau giữa thông tin cần thiết để thực hiện đánh giá và các thành phần sản phẩm và các tài liệu liên quan khác liệt kê trong mô tả sản phẩm,

• Đặc tả các phép đo và các thẩm tra được thực thi và các tham chiếu tới các thành phần sản phẩm được thực hiện,

• Ánh xạ giữa đặc tả các phép đo và các thẩm tra và các yêu cầu đánh giá cùng tham chiếu tới các tiêu chuẩn hay hiệu chỉnh cho từng phép đo hay thẩm tra liệt kê.

5.3.4  Phê chuẩn và báo cáo

Đặc tả đánh giá phải được phê chuẩn như là kết quả của soát xét chung giữa người yêu cầu và bên đánh giá.

Đặc tả đánh giá phải được bao gồm trong báo cáo đánh giá và trong các bản ghi đánh giá. Hơn nữa, bất cứ thay đổi nào các yêu cầu đánh giá phải được báo cáo trong các bản ghi đánh giá.

5.4  Thiết kế đánh giá

5.4.1  Mục đích của thiết kế đánh giá

Thiết kế đánh giá phải soạn các thủ tục được sử dụng bởi bên đánh giá để thực hiện các phép đo xác định trong đặc tả đánh giá. Bên đánh giá phải tạo lập kế hoạch đánh giá mô tả các tài nguyên cần thiết để thực hiện đánh giá đặc tả cũng như phân bổ các tài nguyên này trên các hành động khác nhau được thực hiện.

CHÚ THÍCH 1: Các tài nguyên xem xét ở đây có thể là, ví dụ, nguồn lực con người thực hiện các hành động đánh giá, các tài nguyên tính toán hay không gian làm việc.

Mức độ chi tiết trong kế hoạch đánh giá phải sao cho đảm bảo các hành động được thực hiện thành thạo.

CHÚ THÍCH 2: Kế hoạch đánh giá thường bao gồm một số kiến thức bản quyền của bên đánh giá.

5.4.2  Soạn thảo kế hoạch đánh giá

Các hoạt động tạo lập kế hoạch đánh giá được cấu thành từ ba hoạt động nhỏ:

• Soạn thảo các phương pháp đánh giá và tạo lập bản thảo kế hoạch,

• Tối ưu kế hoạch đánh giá,

• Lập lịch các hành động đánh giá theo các tài nguyên sẵn có.

5.4.2.1  Soạn thảo các phương pháp đánh giá và tạo lập bản thảo kế hoạch

Mục tiêu của hoạt động này là kết hợp các phép đo hay các thẩm tra xác định với khuôn dạng của các thành phần sản phẩm khác nhau được đánh giá để soạn thảo các phương pháp chi tiết được áp dụng thực hiện các phép đo hay các thẩm tra xác định trên các thành phần này.

Bên đánh giá phải phân tích các ràng buộc các phép đo hay các thẩm tra xác định trên đặc tả đánh giá. Các ràng buộc kỹ thuật có thể bao gồm, nhưng không chỉ giới hạn:

• Khuôn dạng sử dụng cho các thành phần sản phẩm,

• Sự kiện mà các thành phần sản phẩm được trình bày điện tử hay trên tài liệu,

• Sự tồn tại của các phương pháp đánh giá xác định trước.

CHÚ THÍCH: Các phương pháp đánh giá định trước có thể được đưa ra trên dạng triển khai mô đun đánh giá như khuyến nghị trong ISO/IEC 14598-6. Các triển khai mô đun đánh giá như vậy phải được liên hệ tới đặc tả mô đun đánh giá sử dụng trong đặc tả đánh giá.

• Tính hiệu dụng của các công cụ hỗ trợ kỹ thuật đánh giá,

• Kích cỡ của các thành phần sản phẩm.

Đối với từng phép đo hoặc thẩm tra xác định trong đặc tả đánh giá bên đánh giá phải soạn thảo phương pháp đánh giá thích hợp.

Khi phương pháp đánh giá mô tả được dựa trên sử dụng công cụ phần mềm, công cụ này phải được xác định trong kế hoạch đánh giá. Một xác định như vậy phải gồm ít nhất là tên của công cụ, xác nhận phiên bản của nó và nguồn gốc của nó (ví dụ, người cung cấp).

Mô tả các phương pháp đánh giá phải được hoàn thiện bởi xác nhận của các thành phần sản phẩm mà phương pháp áp dụng.

Khi trong đặc tả đánh giá phân tích chuyên gia các phép đo được yêu cầu để chuyển đổi các kết quả trước khi chúng có thể được đưa vào báo cáo đánh giá, thủ tục chuyển phải được xác định trong kế hoạch đánh giá. Đặc tả này phải chứa các hướng dẫn để bao gồm xem xét thực hiện thủ tục trong các bản ghi đánh giá.

Khi lập kế hoạch thực hiện chương trình cho sản phẩm được đánh giá, môi trường cần thiết cho thực hiện cũng như dữ liệu cho tính hiệu dụng của nó phải được mô tả.

5.4.2.2  Tối ưu các phép đo

Tại giai đoạn này, các phương pháp đánh giá liên quan đến các yếu tố trong đặc tả đánh giá tự liên quan đến các yêu cầu đánh giá. Mỗi phương pháp đánh giá cơ bản được lập kế hoạch áp dụng trên các thành phần sản phẩm được đánh giá khác nhau. Có thể xảy ra một loạt các phương pháp đánh giá cơ bản được áp dụng cho cùng thành phần sản phẩm hoặc có các phần chung.

Bản thảo kế hoạch đánh giá phải được soát xét để tránh các hành động bên đánh giá trùng lặp. Điều này cần thiết để giảm nguy cơ lỗi và giảm nguồn lực bên đánh giá dự định.

5.4.2.3  Lập lịch các hành động đánh giá

Một khi các trùng lặp các hành động đánh giá đã được loại bỏ, bên đánh giá phải lập lịch các hành động đánh giá theo kế hoạch.

Bên đánh giá phải xem xét tính hiệu dụng của các tài nguyên như nhân viên, các công cụ phần mềm và máy tính.

Bên đánh giá phải thỏa thuận với người yêu cầu đưa ra lịch trình cho sản phẩm và các thành phần của nó. Phương tiện và khuôn dạng cung cấp các thành phần sản phẩm cũng như số lượng bản sao phải được xác định.

Các yêu cầu đáp ứng trong quá trình đánh giá phải được xác định. Khi người yêu cầu không phải là người phát triển sản phẩm phần mềm, quan hệ giữa bên đánh giá và người phát triển phải được xác định. Đặc biệt, hỗ trợ cần thiết cho người phát triển phải được đặc tả. Hỗ trợ như vậy có thể bao gồm, ví dụ, đào tạo, thảo luận không chính thức hay tiện nghi làm việc.

Truy cập tới vị trí phát triển và vận hành, khi cần, phải được xác định cùng các tài nguyên cần thiết.

5.4.3  Các nội dung của kế hoạch đánh giá

Kế hoạch đánh giá phải gồm hai phần, tài liệu các phương pháp đánh giá và lịch trình các hành động bên đánh giá.

Tài liệu của một số phương pháp đánh giá trong kế hoạch đánh giá có thể gồm tham chiếu tới tài liệu bên đánh giá riêng. Trong trường hợp này, bên đánh giá phải có khả năng hiệu chỉnh thích hợp phương pháp theo yếu tố tương ứng của đặc tả đánh giá và năng lực bản thân của nó khi áp dụng phương pháp.

5.4.4  Phê chuẩn và báo cáo

Kế hoạch đánh giá phải được phê chuẩn như là kết quả soát xét chung giữa người yêu cầu và bên đánh giá.

Kế hoạch đánh giá phải được bao gồm trong các bản ghi đánh giá. Tài liệu các phương pháp đánh giá hoặc các tham chiếu tới chúng cũng như xác nhận các thành phần sản phẩm được áp dụng phải được trình bày trong báo cáo đánh giá.

5.5  Thực hiện đánh giá

5.5.1  Mục đích của thực hiện đánh giá

Mục đích của thực hiện đánh giá là thu được các kết quả từ các hành động thực thi để đo và kiểm tra sản phẩm phần mềm theo các yêu cầu đánh giá, như đã xác định trong đặc tả đánh giá và được lập kế hoạch trong kế hoạch đánh giá.

Thực hiện các hành động này đưa đến hoàn thành bản thảo báo cáo đánh giá và các bản ghi đánh giá.

5.5.2  Thực hiện các hành động đánh giá

Để thực hiện các hành động dự định, bên đánh giá phải

• Quản lý các thành phần sản phẩm cung cấp bởi người yêu cầu,

• Quản lý dữ liệu tạo ra bởi các hành động đánh giá (bao gồm báo cáo và bản ghi),

• Quản lý các công cụ được sử dụng để thực hiện các hành động đánh giá.

Thêm nữa, khi các dữ liệu cụ thể được cung cấp, bên đánh giá có thể

• Quản lý các hành động đánh giá thực hiện bên ngoài văn phòng bên đánh giá,

• Quản lý các yêu cầu được đưa đến bởi sử dụng các kỹ thuật đánh giá cụ thể.

5.5.2.1  Quản lý các thành phần sản phẩm

Người yêu cầu phải cung cấp các thành phần sản phẩm và các tài liệu liên quan sản phẩm cho bên đánh giá theo lịch trình trong kế hoạch đánh giá.

Bên đánh giá phải ghi nhận tất cả các thành phần sản phẩm và các tài liệu liên quan sản phẩm. Khi kích cỡ và độ phức tạp đồng đều, quản lý cấu hình chính thức phải được sử dụng.

Thông tin ghi nhận phải có ít nhất là

• Thành phần hoặc tài liệu nhận dạng duy nhất,

• Tên thành phần hoặc đầu đề tài liệu,

• Điều kiện của tài liệu (bao gồm các điểm không bình thường hoặc các điều kiện vật lý),

• Thông tin phiên bản, cấu hình và ngày tháng như được cung cấp bởi người yêu cầu,

• Ngày nhận.

Tính bí mật của tất cả các thành phần sản phẩm và tài liệu liên quan sản phẩm phải được bảo vệ bởi bên đánh giá trừ khi có được thỏa thuận với người yêu cầu.

CHÚ THÍCH: Các yêu cầu tính bí mật ảnh hưởng đến nhiều khía cạnh của công việc đánh giá, bao gồm nhận, xử lí, lưu trữ và tùy ý sử dụng tất cả các thông tin liên quan sản phẩm.

5.5.2.2  Quản lý dữ liệu đánh giá

Thực hiện các hành động đánh giá thông thường gồm đo sản phẩm và các thành phần của nó để thu được dữ liệu trung gian và làm sáng tỏ các dữ liệu này để tạo lập kết quả bao gồm trong báo cáo đánh giá. Dữ liệu trung gian có thể có bản chất thay đổi, ví dụ, số lượng, hình vẽ, sơ đồ, trích dẫn từ các thành phần hay các mô hình chính thức hóa được tạo ra cho đánh giá.

Tính bí mật của dữ liệu trung gian phải được bảo vệ cùng một cách như các thành phần và tài liệu gốc. Hơn nữa, bên đánh giá phải làm tất cả nỗ lực cần thiết để ngăn chặn bất cứ thay đổi ngẫu nhiên hay ác ý nào của dữ liệu này. Đặc biệt, khi khối lượng và độ phức tạp của dữ liệu trung gian lớn, quản lý cấu hình chính thức phải được sử dụng để giữ sự đồng nhất giữa các kết quả đánh giá trung gian và sản phẩm đánh giá.

Bên đánh giá phải đưa vào trong các bản ghi đánh giá bất cứ dữ liệu trung gian mà có bất kì sự diễn giải nào dựa vào. Các quyết định đưa ra trong quá trình diễn giải cũng phải trình bày trong các báo cáo đánh giá như xác định trong kế hoạch đánh giá.

5.5.2.3  Quản lý sử dụng công cụ

Các hành động đánh giá có thể đòi hỏi sử dụng các công cụ phần mềm để thu thập dữ liệu thô hoặc thực hiện diễn giải các dữ liệu trung gian.

CHÚ THÍCH 1: Các ví dụ công cụ như vậy là bộ phân tích mã nguồn để tính các phép đánh giá mã. Công cụ CASE tạo ra các mô hình chính thức, các môi trường kiểm tra chạy các chương trình hoặc các bảng tính để tổng hợp các hệ đo.

Khi công cụ được sử dụng thực hiện hành động đánh giá, tham chiếu đến công cụ phải được trình bày trong báo cáo đánh giá. Tham chiếu phải gồm các nhận biết công cụ và người cung cấp nó và phiên bản công cụ.

Tham chiếu chi tiết hơn của công cụ sử dụng phải được trình bày trong các bản ghi đánh giá. Nó phải gồm cấu hình chi tiết của công cụ và bất cứ thông tin thích hợp cần thiết nào có khả năng lặp lại hành động đánh giá để thu được cùng một kết quả trung gian.

CHÚ THÍCH 2: Khả năng lặp lại yêu cầu này xem xét đến các kết quả không nằm trong báo cáo đánh giá

CHÚ THÍCH 3: Trong một số trường hợp có thể thích hợp bao gồm cả bản sao của công cụ thực hiện trong các bản ghi đánh giá

Bên đánh giá phải tạo tất cả nỗ lực cần thiết để đảm bảo rằng các công cụ sử dụng làm việc thực sự như chúng được đòi hỏi thực hiện. Bên đánh giá phải duy trì các bản ghi của các hành động thực hiện để xác nhận các công cụ sử dụng trong quy trình đánh giá.

CHÚ THÍCH 4: Các bản ghi có thể được dựa trên, ví dụ, số lượng các cài đặt đang có của phần mềm hay thời lượng sử dụng công cụ.

Các nhân viên đánh giá phải được đào tạo sử dụng các công cụ thích hợp.

5.5.2.4  Đánh giá tại hiện trường

Trong một số trường hợp, các hành động đánh giá không thể thực hiện tại văn phòng bên đánh giá. Chúng có thể được thực hiện, ví dụ, tại chỗ người phát triển hoặc tại hiện trường nơi sản phẩm phần mềm vận hành.

Khi điều này xảy ra, bên đánh giá phải điều khiển tất cả các hành động đánh giá thực hiện. Đặc biệt, bên đánh giá phải tránh bất cứ tình huống nào có thể làm sai các kết quả đánh giá.

Bên đánh giá phải tạo tất cả nỗ lực cần thiết để đảm bảo rằng tính bí mật của kết quả đánh giá và các kết quả đánh giá trung gian phải được giữ gìn.

5.5.2.5  Các yêu cầu kỹ thuật đánh giá cụ thể

Khi kế hoạch đánh giá yêu cầu chương trình khả thi của sản phẩm được kiểm tra, cấu hình kiểm tra và môi trường kiểm tra phải được ghi lại chính xác.

Khi hành động đánh giá yêu cầu tài liệu được thẩm tra, sử dụng bảng kiểm tra được khuyến nghị.

5.5.3  Soát xét và báo cáo

Trong quá trình thực hiện đánh giá, các kết quả đánh giá trung gian và các kết quả đánh giá cuối cùng được tạo lập. Để thực đạt được tính khách quan tối đa, các hành động đánh giá phải được kiểm tra bởi các nhân viên đánh giá khác với người thực hiện hành động.

Tất cả các kết quả đánh giá phải được soát xét. Mục tiêu của soát xét phụ thuộc vào bản chất của hành động đánh giá được xem xét. Soát xét phải được quan tâm bởi ít nhất một người không trực tiếp tham gia vào thực hiện hành động đánh giá liên quan. Báo cáo soát xét phải được trình bày trong các bản ghi đánh giá.

Một khi đã soát xét, các kết quả đánh giá phải được đưa vào, như đã xác định trong đặc tả đánh giá, báo cáo đánh giá. Hơn nữa, khi kế hoạch đánh giá cũng xác định như vậy, một số kết quả đánh giá trung gian hoặc các quyết định diễn giải phải được đưa vào trong báo cáo đánh giá.

5.6  Kết luận đánh giá

5.6.1  Mục đích của kết luận đánh giá

Mục đích của kết luận gồm soát xét báo cáo đánh giá và tùy ý sử dụng dữ liệu đánh giá.

5.6.2  Soát xét chung báo cáo đánh giá

Bản thảo báo cáo đánh giá phải được phân phát cho người yêu cầu và bên đánh giá. Soát xét chung giữa người yêu cầu và bên đánh giá phải được tổ chức. Người yêu cầu phải được cho cơ hội bình luận báo cáo đánh giá. Nếu có các bình luận thì chúng phải được đưa vào chương riêng của báo cáo đánh giá. Báo cáo đánh giá phải được đưa đến cho người yêu cầu.

5.6.3  Sắp đặt dữ liệu và tài liệu đánh giá

Một khi báo cáo đánh giá đã được đưa đến chính thức cho người yêu cầu, bên đánh giá phải sắp đặt dữ liệu thuộc về đánh giá. Điều này có thể thực hiện bằng một trong các cách sau, phụ thuộc vào loại dữ liệu:

Các tài liệu đưa vào đánh giá phải hoặc trả lại cho người yêu cầu hoặc được lưu trữ trong khoảng thời gian xác định hoặc được hủy bỏ an toàn.

Báo cáo đánh giá và các bản ghi đánh giá phải được lưu trữ trong một khoảng thời gian xác định.

Tất cả dữ liệu khác phải được hoặc lưu trữ trong khoảng thời gian xác định hoặc được hủy bỏ an toàn.

Khi khoảng thời gian lưu trữ đã hết đối với một số dữ liệu, nó phải được hoặc lưu trữ lại trong khoảng thời gian xác định hoặc được hủy bỏ an toàn.

Giả thiết người yêu cầu đồng ý rõ ràng, các kết quả đánh giá trung gian có thể được sử dụng bởi bên đánh giá để nghiên cứu các kỹ thuật đánh giá và các phép đánh giá phần mềm.

THƯ MỤC TÀI LIỆU THAM KHẢO

[1] ISO 14598-1:1998 - Information Technology - Software Product Evaluation - Part 1: General Overview.

[2] ISO 14598-2:1998 - Information Technology - Software Product Evaluation - Part 2: Planning and management.

[3] ISO 14598-5:1998 - Information Technology - Software Product Evaluation - Part 5: Process for evaluators.

MỤC LỤC

1  Phạm vi áp dụng

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

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

4  Các khái niệm đánh giá

4.1  Các khía cạnh chung

4.2  Điểm bắt đầu đánh giá

4.2.1  Thỏa thuận khởi đầu

4.2.2  Các bên tham gia đánh giá

4.3  Các đặc tính của quy trình đánh giá

4.4  Quy trình đánh giá

4.4.1  Các hoạt động đánh giá

4.4.2  Đầu vào quy trình đánh giá

4.4.3  Đầu ra quy trình đánh giá

4.5  Các quan hệ giữa đánh giá và vòng đời

5  Các yêu cầu quy trình đánh giá

5.1  Các yêu cầu chung

5.1.1  Tổ chức và hệ thống chất lượng

5.1.2  Các trách nhiệm người yêu cầu

5.1.3  Các trách nhiệm bên đánh giá

5.2  Thiết lập các yêu cầu đánh giá

5.2.1  Mục đích của thiết lập các yêu cầu đánh giá

5.2.2  Soạn thảo các yêu cầu đánh giá

5.2.3  Các nội dung của yêu cầu đánh giá

5.2.4  Phê chuẩn và báo cáo

5.3  Đặc tả của đánh giá

5.3.1  Mục đích của đặc tả đánh giá

5.3.2  Soạn thảo đặc tả đánh giá

5.3.2.1  Phân tích mô tả sản phẩm

5.3.2.2  Xác định các phép đo

5.3.2.3  Thẩm tra đặc tả đánh giá

5.3.3  Các nội dung đặc tả đánh giá

5 3.4  Phê chuẩn và báo cáo

5.4  Thiết kế đánh giá

5 4.1  Mục đích của thiết kế đánh giá

5.4.2  Soạn thảo kế hoạch đánh giá

5.4.2.1  Soạn thảo các phương pháp đánh giá và tạo lập bản thảo kế hoạch

5.4.2.2  Tối ưu các phép đo

5.4.2.3  Lập lịch các hành động đánh giá

5.4.3  Các nội dung của kế hoạch đánh giá

5.4.4  Phê chuẩn và báo cáo

5.5  Thực hiện đánh giá

5.5.1  Mục đích của thực hiện đánh giá

5.5.2  Thực hiện các hành động đánh giá

5.5.2.1  Quản lý các thành phần sản phẩm

5.5.2.2  Quản lý dữ liệu đánh giá

5.5.2.3  Quản lý sử dụng công cụ

5.5.2.4  Đánh giá tại hiện trường

5.5.2.5  Các yêu cầu kỹ thuật đánh giá cụ thể

5.5.3  Soát xét và báo cáo

5.6  Kết luận đánh giá

5.6.1  Mục đích của kết luận đánh giá

5.6.2  Soát xét chung báo cáo đánh giá

5.6.3  Sắp đặt dữ liệu và tài liệu đánh giá

Thư mục tài liệu tham khảo