Tiêu chuẩn quốc gia TCVN 8708:2011 về Công nghệ thông tin - Quy trình Đánh giá phần mềm cho người mua

• Số hiệu: TCVN8708:2011
• Loại văn bản: Tiêu chuẩn Việt Nam
• Nơi ban hành: ***
• Người ký: ***
• Ngày ban hành: Năm 2011

Đầu vào	Bước đánh giá	Công việc chính	Đầu ra
Các yêu cầu hệ thống/ phần mềm	Thiết lập các yêu cầu đánh giá	Xác định mục tiêu, mục đích, và phạm vi. Xác định tính nghiêm ngặt của đánh giá. Xác định đầu vào đánh giá. Xác định đánh giá được tạo lập, hoặc được tạo lập bởi người khác. Xác định quy trình mua hàng tuân thủ theo và các yêu cầu đầu vào đánh giá được trao đổi với nhà cung cấp như thế nào.	Đặc tả các yêu cầu đánh giá
Các yêu cầu đánh giá	Xác định đánh giá	Lựa chọn các phép đánh giá tương quan với các đặc tính của sản phẩm phần mềm. Thiết lập các mức phân hạng. Lựa chọn một bộ các phương pháp đánh giá hiệu quả nhất. Thiết lập các thủ tục để tổng hợp kết quả đánh giá của các đặc tính chất lượng khác nhau và các khía cạnh khác góp phần đánh giá chất lượng sản phẩm phần mềm trong môi trường đặc thù.	Đặc tả đánh giá
Đặc tả đánh giá	Thiết kế đánh giá	Chuẩn bị kế hoạch đánh giá mô tả các phương pháp đánh giá, và lịch trình đánh giá. Xác định các điểm nối giữa các hoạt động đánh giá và các hoạt động mua hàng	Kế hoạch đánh giá
Kế hoạch đánh giá	Thực hiện đánh giá	Hướng dẫn các hoạt động đánh giá được chọn, và phân tích và ghi nhận các kết quả để xác định tính thích hợp của sản phẩm phần mềm. Phân tích ảnh hưởng của các thiếu sót xác định và các tùy chọn để điều chỉnh sử dụng sản phẩm. Đưa ra kết luận trên các khía cạnh chấp nhận sản phẩm và quyết định cuối cùng mua hay không mua.	Các bản ghi và kết quả đánh giá

5.1  Bước 1 - Thiết lập các yêu cầu đánh giá

5.1.1  Thiết lập mục đích và phạm vi đánh giá

Quy trình đánh giá phải thiết lập:

a) Một bộ các yêu cầu chất lượng phần mềm sử dụng mô hình chất lượng và định nghĩa trong ISO/IEC 9126-1, dựa vào chúng sản phẩm phần mềm có thể được đánh giá khách quan phù hợp cho sử dụng;

b) Độ ưu tiên hợp lí phải được đưa ra cho các đặc tính chất lượng phần mềm;

c) Cơ sở hệ thống cho đánh giá thích hợp với mức độ toàn vẹn của ứng dụng, chúng bao hàm các yêu cầu thiết lập như mức độ nghiêm ngặt hoặc chi tiết yêu cầu trong các hoạt động đánh giá, cũng như các đầu vào, đầu ra quy trình đánh giá;

CHÚ THÍCH: Hình 2 cung cấp lược tả quy trình đánh giá sản phẩm phần mềm. Nó chỉ ra các quan niệm khác nhau của các đầu vào quy trình đánh giá và các kết quả đầu ra từ quy trình đánh giá, từ quan điểm của người mua sản phẩm.

d) Quá trình mua hàng được thực hiện tiếp theo và các yêu cầu đầu vào đánh giá được liên kết với người cung cấp như thế nào;

e) Phạm vi, mục đích và mục tiêu của đánh giá bằng các xem xét:

...

...

...

• có hay không bất cứ đánh giá nào thực hiện bởi người thứ hai hoặc thứ ba, hoặc có hay không bất cứ hoạt động đánh giá nào được lập kế hoạch thực hiện sau này.

5.1.2  Xác định các yêu cầu đánh giá

Đặc tả các yêu cầu đánh giá phải xác định:

a) Người sử dụng và mục tiêu, nhiệm vụ, và các đặc tính của họ và môi trường sử dụng cho sản phẩm;

b) Mức độ toàn vẹn của ứng dụng phần mềm (rủi ro xuất hiện trong trường hợp phần mềm lỗi) và do đó mức độ nghiêm ngặt yêu cầu cho quy trình đánh giá;

c) Các yêu cầu điều chỉnh (tài liệu nào cần để cung cấp điều chỉnh (nếu có) với đảm bảo chất lượng sản phẩm);

d) Các giới hạn và giao diện của sản phẩm, bao gồm các yêu cầu giao diện (như loại dữ liệu đi qua giao diện, định dạng dữ liệu, cơ cấu truy nhập giao diện, xử lí sự cố/ lỗi, các vấn đề đồng bộ, các vấn đề hoạt động giao tiếp, các phụ thuộc và chuyển đổi trạng thái giao diện) của sản phẩm phần mềm (xem ISO/IEC 9126-1);

e) Các yêu cầu tích hợp nếu sản phẩm là một phần của hệ thống lớn yêu cầu tích hợp với các thành phần hoặc sản phẩm khác;

f) Các yêu cầu chất lượng phần mềm bao gồm:

...

...

...

- tất cả các giả thiết, ngoại lệ, giới hạn, loại trừ, hoặc các vấn đề chưa được giải quyết cần thiết làm sáng tỏ hoặc hiểu các yêu cầu;

- các yêu cầu của người sử dụng cho tất cả các đặc tính chất lượng quan trọng và độ ưu tiên của chúng (ví dụ như nếu khả năng bảo trì được xem xét là quan trọng thì xác định các yêu cầu khả năng bảo trì cụ thể);

- tất cả các ràng buộc thiết kế và môi trường; ví dụ như các giới hạn chức năng hoặc hiệu năng áp đặt bởi người sử dụng sản phẩm phần mềm, mức độ và tính phức tạp của tích hợp sản phẩm phần mềm với các phần mềm đang tồn tại khác, phần mềm khách hàng, và phần cứng trong ứng dụng của người sử dụng;

- tất cả các ràng buộc quản lý dự án; ví dụ như tính hiệu dụng của tài nguyên và tính thành thạo chuyên môn tạo lập các hoạt động đánh giá, hạn định cho phép của lịch trình và ngân sách, các phụ thuộc có khả năng hoặc các rủi ro, các giả thiết chính, hoặc các giả thiết về nỗ lực đánh giá;

- cơ sở pháp lí của việc sử dụng mô hình chất lượng khác ngoài các quy trình trong tiêu chuẩn ISO/IEC 9126-1.

g) Các dịch vụ nhà cung cấp được đánh giá; ví dụ như khả năng hỗ trợ, khả năng phát triển ứng dụng, và khả năng đào tạo;

h) Các yêu cầu đặc biệt được đánh giá; ví dụ như các vấn đề tính khả thi kỹ thuật cụ thể hoặc các vấn đề thực hiện thiết kế;

i) Các yêu cầu đánh giá nhất quán với nhau (ví dụ như không có các yêu cầu mâu thuẫn nhau) và đồng nhất với mức độ toàn vẹn của ứng dụng;

j) Sản phẩm sẽ được sử dụng lại trong các ứng dụng tương lai hay không và tài liệu cần thiết để hỗ trợ bất cứ đánh giá tương lai nào của sản phẩm;

...

...

...

I) Các đánh giá được thực hiện bởi bên thứ hai hoặc thứ ba khác mà nó có thể được sử dụng để giảm nguồn lực đánh giá cho sản phẩm.

CHÚ THÍCH: Mức độ chi tiết và phức tạp của các đặc tả yêu cầu đánh giá trực tiếp ảnh hưởng tới mức độ phức tạp của đánh giá, ví dụ, đánh giá chỉ dựa trên các yêu cầu cơ bản không thể được xem xét như đánh giá đầy đủ, mặc dù các kết quả được sử dụng trực tiếp cho các công việc tiếp theo trong các giai đoạn khác, ngăn chặn trước các vấn đề, hoặc loại bỏ sản phẩm hoặc nhà cung cấp phần mềm nào đó. Chúng thường được thực hiện trước các hoạt động đánh giá chính như một phần của thiết kế thích hợp hoặc hoạt động lập kế hoạch. Một số công việc đánh giá cũng có thể được yêu cầu trước khi các yêu cầu được kết thúc.

Tổng quan đầu vào đánh giá

Tổng quan sản phẩm

Tổng quan các kết quả đánh giá

Hình 2 - Khái quát quy trình đánh giá sản phẩm phần mềm từ cách nhìn của người mua sản phẩm

5.2  Bước 2 - Xác định đánh giá

Đặc tả đánh giá phải được soạn thảo sao cho quy trình đánh giá có thể được lặp lại bởi nhân viên chất lượng thích hợp với các kết quả có thể lặp lại.

...

...

...

Đặc tả đánh giá phải xác định:

a) Các đặc tính của sản phẩm được đánh giá;

b) Các phép đánh giá ngoài liên quan đến các khía cạnh đo chất lượng khi phần mềm được sử dụng;

c) Các phép đánh giá chất lượng sử dụng liên quan đến quan điểm của người sử dụng về chất lượng của hệ thống chứa phần mềm;

d) Các tiêu chuẩn đầy đủ cho các phép đánh giá để mô tả dải chấp nhận của chúng (tức là cần bao nhiêu công việc vận hành để cung cấp mức độ bảo đảm hợp lí cho đặc tính chất lượng cho trước và mức toàn vẹn cho trước),

e) Bất cứ mô đun đánh giá đóng gói nào;

f) Mức độ bao hàm tương quan đến các yêu cầu đánh giá cần thiết sau khi soát xét bất kì một đánh giá trước đó nào được tạo lập bởi người khác;

g) Bản danh sách kiểm tra được trả lời từ đánh giá;

h) Danh sách các ví dụ có thể giúp trả lời các câu hỏi;

...

...

...

j) Dữ liệu được thu thập và phân tích, và khuôn dạng của chúng;

k) Các phương pháp đánh giá cụ thể được sử dụng, chúng bao gồm soát xét hoặc đánh giá một hoặc một số các khoản mục sau:

- người sử dụng sản phẩm phần mềm và tài liệu kỹ thuật (bao gồm cả tài liệu on-line);

- đánh giá sản phẩm phần mềm dựa trên các khóa học và đào tạo của nhà cung cấp;

- quá trình kỹ thuật phần mềm, bao gồm cả các sản phẩm phần mềm trung gian;

- lịch sử vận hành sản phẩm với nhà cung cấp;

- lịch sử vận hành sản phẩm với khách hàng;

- hệ thống năng lực, hỗ trợ, và chất lượng của nhà cung cấp;

- các phương pháp đánh giá nguyên mẫu hoặc các phương pháp khác;

...

...

...

l) Các phương pháp để đánh giá kết quả đánh giá;

m) Các phương pháp phù hợp của xếp hạng đánh giá để cho phép lựa chọn, khi lựa chọn sản phẩm từ nhiều sản phẩm tương tự;

n) Bất cứ một hệ thống phân hạng nào tiện lợi cho việc so sánh nhiều sản phẩm phần mềm. Hệ thống phân hạng có thể được đánh trọng số tương ứng với mức ưu tiên của đặc tính chất lượng.

5.2.2  Lựa chọn phương pháp đánh giá

Tổ hợp các phương pháp đánh giá phải được xác định để cho phép lựa chọn sản phẩm hoặc thiết lập tính thích hợp của sản phẩm khi sử dụng. Các lĩnh vực được đánh giá bao gồm:

a) Có hay không một số các nhận định có thể mâu thuẫn lẫn nhau (ví dụ như “Chi phí của các phương pháp được chọn có nằm trong ngân sách cho phép?” có thể không nhất quán với “Các phương pháp có bao hàm hết tất cả các yêu cầu đánh giá hay không?”). Trong trường hợp này tùy thuộc vào bên đánh giá quyết định các yếu tố thỏa hiệp cần thiết dựa trên mức ưu tiên của các yêu cầu đánh giá;

b) Đánh giá có cung cấp bao hàm đầy đủ hoặc phạm vi khi kết hợp các phương pháp được chọn hay không khi xem xét:

- làm thế nào để thể hiện rằng phần mềm đáp ứng các đặc tả của nó;

- chồng chéo bao hàm của các phương pháp để cung cấp thêm độ tin cẩn;

...

...

...

- mức độ các phương pháp bổ sung lẫn nhau;

- tính hiệu quả và tính khách quan của mỗi phương pháp khi nhằm đến sự đa dạng của các đặc tính;

- sự đa dạng của các giải pháp phân biệt trong các phương pháp đánh giá (ví dụ như một số phương pháp dựa trên soát xét, phân tích, và kiểm tra);

- thiết lập lòng tin cho bất cứ hoạt động đánh giá nào trong ứng dụng mà về cơ bản sẽ được thực hiện như một phần của toàn bộ vòng đời phát triển hệ thống;

- tin cậy đánh giá tạo lập bởi người khác;

c) Sử dụng các hoạt động đánh giá sơ bộ “không chính thức” như soát xét hoặc khảo sát hoặc kinh nghiệm giai thoại của người sử dụng, các soát xét sản phẩm trên tạp chí thương mại, tài liệu sử dụng sản phẩm truy cập được, hoặc kho lưu trữ dữ liệu các soát xét của sản phẩm, để thu hẹp phạm vi lựa chọn sản phẩm được xem xét chức năng phù hợp cho đánh giá sau này.

6.2.3  Đánh giá thực hiện bởi các bên khác

Trước khi tin cậy các đánh giá thực hiện bởi các bên khác, cần phải xem xét các vấn đề sau:

a) Đánh giá có nhằm tới các yêu cầu đánh giá ở một mức độ nghiêm ngặt nhất quán với mức toàn vẹn của ứng dụng hay không;

...

...

...

c) Báo cáo đánh giá có xác định bất kì thiếu sót nào trong sản phẩm phần mềm hoặc quá trình kỹ thuật phần mềm, có khuyến nghị bất kì hành động sửa chữa cho các thiếu sót này, và hành động sửa chữa có được thực hiện hay không;

d) Bên đánh giá có đủ trình độ thích hợp hay không, bao gồm:

- kinh nghiệm trong việc thực hiện đánh giá và phân tích;

- kinh nghiệm trong chất lượng phần mềm liên quan đến các tiêu chuẩn quốc tế được chấp thuận;

- trình độ trong các vấn đề kỹ thuật phần mềm;

- hoàn toàn độc lập với nhà cung cấp.

5.3  Bước 3 - Thiết kế đánh giá

Kế hoạch đánh giá sản phẩm phải xác định:

a) Nhà cung cấp hoặc bên thứ ba có mong muốn và sẵn sàng cung cấp truy cập vào các tài liệu, thiết bị, công cụ, phần mềm, khóa học và/hoặc đào tạo, và chi phí đi kèm được yêu cầu hay không;

...

...

...

c) Nhà cung cấp hoặc bên thứ ba có mong muốn và sẵn sàng cung cấp truy cập tới các cá nhân có trình độ chuyên môn đúng đắn để trả lời các câu hỏi không, và chi phí cho các việc đó thế nào, kể cả chi phí đi lại;

d) Trình độ chuyên môn đòi hỏi từ bên đánh giá để thiết lập đánh giá dựa trên các yêu cầu đánh giá, và bất kì các chi phí nào liên quan đến việc đạt được trình độ chuyên môn cụ thể này;

e) Bất kì kiểm tra sơ bộ nào yêu cầu để thiết lập cơ sở sản phẩm phù hợp với việc kiểm tra trong mọi cấp độ;

f) Bất kì chi phí nào liên quan đến việc cung cấp môi trường kiểm tra (ví dụ như phần cứng kiểm tra, thiết bị và các công cụ hỗ trợ, nhân vật đặc biệt) để tạo lập đánh giá;

g) Trách nhiệm đánh giá và lịch trình thời gian yêu cầu;

h) Bất kì một hạn chế hay thiếu sót nào trong phương pháp đánh giá để cung cấp đảm bảo chất lượng, và hạn chế hoặc thiếu sót này có được đưa vào trong kế hoạch hay không; ví dụ như phương pháp đánh giá không có khả năng bao phủ toàn bộ các đặc tính nhỏ cho một đặc tính chất lượng xác định;

i) Bất kì sự phụ thuộc lẫn nhau nào giữa các các phương pháp đánh giá khác nhau được sử dụng; tức là các phụ thuộc thứ tự (thông tin thu được trong một kiểm tra có thể hữu dụng trong các lần khác), thiết lập trình tự tối ưu cho các phương pháp đánh giá;

j) Nguồn tài nguyên yêu cầu, chi phí cho toàn bộ đánh giá, và chi phí cho mỗi phương pháp đánh giá;

k) Các điểm nối giữa các hoạt động đánh giá và hoạt động mua sản phẩm;

...

...

...

m) Các vấn đề sau cho mỗi hoạt động đánh giá được lập kế hoạch;

- các thủ tục và kỹ thuật phải tuân theo;

- các đầu vào và đầu ra thông tin và tài liệu yêu cầu;

- bất kì yêu cầu khuôn dạng và nội dung nào trong bất kì tài liệu đưa ra nào;

n) Lí do căn bản, biện minh, và các giả thiết đằng sau bất kì một quyết định không bình thường hoặc ngoại lệ nào được đưa ra trong quá trình lập kế hoạch đánh giá được ghi lại;

o) Các công cụ đánh giá;

p) Các thủ tục để phát triển và xác nhận các phép đánh giá, và để chuẩn hóa quy trình đánh giá, các phép đánh giá và hệ đo;

CHÚ THÍCH 1: ISO/IEC 14598-6 định nghĩa khái niệm của mô đun đánh giá thu thập một cách có hệ thống tất cả các thông tin cần thiết đi thực hiện đánh giá của các khía cạnh cụ thể của các đặc tính chất lượng áp dụng kỹ thuật hoặc phương pháp đánh giá cụ thể.

CHÚ THÍCH 2: Trong quá trình lập lịch các phương pháp đánh giá, điều quan trọng là phải xác nhận mức độ phụ thuộc lẫn nhau cao giữa các phương pháp đánh giá khác nhau, tức là thông tin thu được bởi một phương pháp có thể ảnh hưởng tâm điểm của các phương pháp khác. Bởi vì bản chất của đánh giá là lặp lại, các vấn đề có thể xuất hiện lại khi thông tin tăng lên Do đó, kế hoạch đánh giá có vẻ như sẽ bị thay đổi khi đánh giá được tạo lập. Ví dụ, nó có thể chung trong các mức độ chi tiết hơn của đánh giá được xem xét như không cần thiết, hoặc như một yêu cầu bổ sung, một khi đánh giá tiến triển.

...

...

...

5.4  Bước 4 - Thực hiện đánh giá

5.4.1  Thực hiện phương pháp đánh giá

a) Đánh giá phải được thực hiện, ghi chép và phân tích cho:

- thiết lập cấp độ tin cẩn thích hợp sao cho sản phẩm phần mềm có khả năng đáp ứng các yêu cầu đánh giá;

- xác minh bất kì thiếu sót cụ thể nào tương ứng với các yêu cầu đánh giá và bất kì đánh giá bổ sung nào cần thiết để xác định phạm vi của các thiếu sót này;

- xác định bất kì một hạn chế hay điều kiện đặc biệt nào trong khi sử dụng sản phẩm phần mềm;

- xác định các điểm yếu hoặc điểm bỏ sót nào trong bản thân đánh giá và bất kì đánh giá bổ sung nào cần thiết;

- xác định bất kì tùy chọn nào cho việc sử dụng sản phẩm phần mềm không được bao hàm bởi đánh giá;

b) Các bản ghi thực hiện đánh giá phải xác định.

...

...

...

- thực hiện từng bước thủ tục đánh giá (bao gồm dữ liệu sử dụng, quá trình cài đặt, và bất kì thông tin trạng thái nào), các kết quả đánh giá (trả lời tất cả các câu hỏi và các tham chiếu tới nguồn các câu trả lời), và số phiên bản của sản phẩm phần mềm;

- bất kì hạn chế, ràng buộc, thiếu sót, hoặc ngoại trừ trong hoạt động đánh giá, bao gồm tác động của chúng trong sử dụng, cấu hình, sửa đổi, hoặc bảo trì tổng thể sản phẩm phần mềm trong suốt quá trình thời gian; bên đánh giá và năng lực của họ;

- bất kì sự khác nhau nào giữa phiên bản sản phẩm được đánh giá và các đầu vào đánh giá tương ứng; tức là tài liệu hoặc các khóa học;

- giải pháp hoặc vòng tránh trong các sự kiện lỗi;

5.4.2  Phân tích kết quả đánh giá

Các bản ghi để phân tích các hoạt động đánh giá phải xác định:

a) Mỗi thiếu sót, bất kì phân tích liên quan, và mỗi thiếu sót đã được giải quyết như thế nào. Cách giải quyết của mỗi thiếu sót có thể bao gồm các yếu tố sau:

- một trong những phương pháp đánh giá khác đã cung cấp đảm bảo rằng thiếu sót là không lớn; ví dụ như lịch sử khai thác rộng có thể hoàn chỉnh cho quá trình kỹ thuật phần mềm thiếu sót;

- việc vòng tránh thỏa đáng có thể được dùng làm giảm nhẹ ảnh hưởng của thiếu sót; ví dụ như sửa đổi sản phẩm, cô lập hoặc loại bỏ chức năng không cần thiết, tạo lại các yêu cầu thiết kế bị bỏ qua sử dụng cơ cấu ngược;

...

...

...

- thiếu sót là chấp nhận được với điều kiện việc sử dụng sản phẩm phần mềm sẽ được kiểm soát bởi các điều kiện hoặc hạn chế cụ thể;

- công việc đánh giá bổ sung được yêu cầu để giải quyết thiếu sót hoặc các chênh lệch trong đánh giá;

b) Bất kì đánh giá bổ sung nào được thực hiện để giải quyết bất kì một thiếu sót xác định nào:

- xác định phạm vi hoặc ảnh hưởng của thiếu sót;

- thiết lập độ tin cậy rằng không có thiếu sót;

- xác minh rằng việc vòng tránh là khả thi và/hoặc phù hợp và chấp nhận được;

- xác minh rằng việc hoạt động đúng và chấp nhận được của phần mềm một khi thay đổi thiết kế hoặc thay đổi đã được thực hiện để sửa lỗi;

c) Trong trường hợp cần hạn chế hoặc kiểm soát sử dụng sản phẩm phần mềm, nếu hạn chế là:

- cản trở sản phẩm phần mềm đáp ứng các yêu cầu bắt buộc của ứng dụng;

...

...

...

- yêu cầu công việc đánh giá thêm;

- đưa ra bất kì khả năng hỏng hóc nào trong ứng dụng;

d) Bất cứ ngoại lệ nào từ phạm vi của đánh giá và/hoặc hạn chế trong kết quả cho từng đánh giá, chẳng hạn như:

- “Đánh giá này không bao hàm soát xét chi tiết chức năng của sản phẩm” hoặc

- “Sản phẩm phần mềm này được cho rằng đạt chất lượng đối với mức toàn vẹn yêu cầu trong điều kiện đánh giá toàn bộ các chức năng yêu cầu cho sản phẩm được thực hiện thành công.”

e) Các kết quả tích hợp của tất cả các hoạt động đánh giá cho phép kết luận toàn diện cho đánh giá sản phẩm phần mềm được sản xuất.

5.4.3  Rút ra kết luận

Kết luận phải phát biểu rõ sản phẩm phần mềm có xứng đáng và thích hợp để sử dụng trong ứng dụng dự định hay không, trong khi xem xét mức độ toàn vẹn của ứng dụng và các yêu cầu đánh giá thực tế. Nếu không thể sử dụng sản phẩm phần mềm như nó đang sẵn có, do các thiếu sót được phát hiện hoặc do thiếu thông tin đánh giá, thì cần phải đưa ra các khuyến nghị để thực hiện đánh giá tiếp theo hoặc để kiểm soát hoặc giới hạn sử dụng sản phẩm phần mềm trong ứng dụng mục tiêu của nó.

Các kết luận có thể được chính thức hóa sử dụng “báo cáo tuân thủ yêu cầu” có thể mô tả cho mỗi yêu cầu cụ thể các đặc điểm, chức năng, dịch vụ, của sản phẩm phần mềm sử dụng để đáp ứng yêu cầu đó, và các phương pháp đánh giá cung cấp sự tin cẩn thích đáng sao cho đáp ứng được yêu cầu. Các chiến lược thiết kế tiềm năng như áp dụng tính đa dạng thiết kế, dự phòng trong cấu hình, kiểm tra tính toàn vẹn của giao tiếp và các kỹ thuật phục hồi có thể bù vào cho các thiếu sót hoặc các lỗi tiềm năng của sản phẩm phần mềm.

...

...

...

Quyết định mua khi đó có thể dẫn đến hợp đồng mua sản phẩm phần mềm với khả năng có đánh giá bổ sung dưới dạng kiểm tra chấp thuận sản phẩm.

Quyết định không mua sản phẩm có thể đưa đến các khả năng khác bao gồm sửa đổi sản phẩm phần mềm, phát triển sản phẩm phần mềm khách hàng, hoặc thay đổi các yêu cầu.

6  Đánh giá khi mua phần mềm khách hàng và sửa đổi phần mềm sẵn có

Mục này tập trung vào ứng dụng của quy trình đánh giá khi mua sản phẩm phần mềm khách hàng hoặc sửa đổi phần mềm đang có.

6.1  Bước 1 - Thiết lập các yêu cầu đánh giá

Quá trình thiết lập yêu cầu đánh giá được định nghĩa trong phần bước 1 của mục 5.1 cũng áp dụng trong trường hợp này. Các yêu cầu đánh giá tạo ra cơ sở cho các yêu cầu mua sản phẩm mà nó được đưa ra như một phần của yêu cầu đề nghị tới các nhà cung cấp được lựa chọn sơ bộ. Đối với việc sửa đổi phần mềm sẵn có, đánh giá phải tập trung đầu tiên đến các phần thay đổi của sản phẩm phần mềm và các giao diện của chúng.

Đánh giá sơ bộ phải được thực hiện cho các nhà cung cấp được lựa chọn sơ bộ dựa trên cơ sở khả năng của họ, chương trình chất lượng và quá trình kỹ thuật phần mềm ưu tiên hướng tới yêu cầu đề nghị.

6.2  Bước 2 - Xác định đánh giá

Mục 5.2 đã xác định đánh giá cho phần mềm đóng gói, và cũng áp dụng cho đánh giá phần mềm khách hàng và sửa đổi phần mềm đang có sẵn. Tuy nhiên, phép đo bổ sung được yêu cầu như một phần của quá trình phát triển của nhà cung cấp để dự báo chất lượng sản phẩm cuối dựa trên đo chất lượng các sản phẩm trung gian. TCVN 8707:2011 cung cấp các yêu cầu và hướng dẫn cho việc đo chất lượng sản phẩm trung gian trong quá trình phát triển.

...

...

...

Mục 5.3 áp dụng cho quy trình mua sản phẩm phần mềm khách hàng và sửa đổi phần mềm có sẵn với các xem xét bổ sung sau.

Lựa chọn nhà cung cấp trong quá trình đấu thầu có thể yêu cầu nhà cung cấp nâng cấp kỹ thuật phần mềm hoặc quá trình bảo trì cho các yêu cầu để đạt được các yêu cầu tính toàn vẹn mục tiêu ưu tiên hướng tới quá trình phát triển phần mềm hay sửa đổi.

Các hoạt động đánh giá được yêu cầu khi đó sẽ trở thành một phần của quá trình hoạt động của nhà cung cấp, tức là trong quá trình kiểm soát các hoạt động phát triển, xác minh, soát xét chung và kiểm định, kiểm tra và xác nhận của nhà cung cấp. Các yêu cầu này được xác định trong kế hoạch chất lượng hay phát triển mà nhà cung cấp được yêu cầu tuân theo. Người mua sản phẩm giám sát việc thực hiện kế hoạch của nhà cung cấp và thiết lập các yêu cầu cho kế hoạch trên thỏa thuận hợp đồng giữa nhà cung cấp và người mua sản phẩm.

6.4  Bước 4 - Thực hiện kế hoạch

Các yêu cầu cho việc thực hiện đánh giá trong mục 5 4 cũng được áp dụng ở đây, ngoài việc đánh giá thực tế được thực hiện thông qua các hoạt động của nhà cung cấp và giám sát của người mua sản phẩm theo với kế hoạch chất lượng. Kiểm chấp nhận sản phẩm phần mềm thành công là tiêu chuẩn cần trước khi sản phẩm giao cho người mua sản phẩm. Người mua sản phẩm có thể quyết định thực thi các sửa đổi bổ sung cho sản phẩm phần mềm hoặc chỉ ra các thiếu sót tìm thấy trong đánh giá, trước khi sử dụng sản phẩ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.

...

...

...

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  Đánh giá sản phẩm phần mềm - Các xem xét tổng quan

4.1  Liên hệ giữa các quy trình đánh giá và mua sản phẩm

4.2  Các đầu vào quy trình đánh giá

4.2.1  Các yêu cầu hệ thống

...

...

...

4.2.3  Đặc tả các yêu cầu phần mềm

4.2.4  Các đánh giá được thực hiện bởi các bên khác

4.3  Hiệu chỉnh

5  Đánh giá trong quy trình mua sản phẩm phần mềm đóng gói

5.1  Bước 1 - Thiết lập các yêu cầu đánh giá

5.1.1  Thiết lập mục đích và phạm vi đánh giá

5.1.2  Xác định các yêu cầu đánh giá

5.2  Bước 2 - Xác định đánh giá

5.2.1  Lựa chọn các phép đánh giá

...

...

...

5.2.3  Đánh giá thực hiện bởi các bên khác

5.3  Bước 3 - Thiết kế đánh giá

5.4  Bước 4 - Thực hiện đánh giá

5.4.1  Thực hiện phương pháp đánh giá

5.4.2  Phân tích kết quả đánh giá

5.4.3  Rút ra kết luận

6  Đánh giá khi mua phần mềm khách hàng và sửa đổi phần mềm sẵn có

6.1  Bước 1 - Thiết lập các yêu cầu đánh giá

6.2  Bước 2 - Xác định đánh giá

...

...

...

6.4  Bước 4 - Thực hiện kế hoạch

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