Tải về định dạng Word (603.5KB) Tải về định dạng PDF (4.7MB)

Tiêu chuẩn quốc gia TCVN 8705:2011 về Công nghệ thông tin - Đánh giá sản phẩm phần mềm - Phần 1: Tổng quan

TIÊU CHUẨN QUỐC GIA

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

Information technology - Software product evaluation - Part 1: General overview.

Lời nói đầu

TCVN 8705:2011 được xây dựng trên cơ s ISO/IEC 14598-1 và ISO/IEC 14598-2.

TCVN 8705: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ị, Tng cục Tiêu chuẩn Đo lường Chất lượng thm đnh, Bộ Khoa học và Công nghệ công bố.

 

CÔNG NGHỆ THÔNG TIN - ĐÁNH GIÁ SẢN PHM PHN MM - PHN 1: TNG QUAN

Information technology - Software product evaluation - Part 1: General overview

1. Phạm vi áp dụng

Tiêu chuẩn này cung cấp tổng quan của các phần khác và giải thích mối quan hệ giữa các tiêu chun từ TCVN 8705:2011 đến TCVN 8708:2011 (ISO/IEC 14598) và mô hình chất lượng trong các tiêu chuẩn từ TCVN 8702: 2011 đến TCVN 8704:2011 (ISO/IEC 9126). Phần này cũng định nghĩa các thuật ngữ kỹ thuật sử dụng trong các phần khác, xác định các yêu cầu chung cho đặc tả và đánh giá chất lượng phần mềm và làm sáng tỏ các khái niệm chung. Thêm vào đó, phần này cung cấp khung cho đánh giá chất lượng của tất c các loại sn phẩm phần mềm và đề cập các yêu cầu cho các phương pháp đo và đánh giá sản phm phần mềm.

Các tiêu chuẩn từ TCVN 8705:2011 đến TCVN 8708:2011 được sử dụng cho người phát triển, người mua sản phẩm và bên đánh giá độc lập, đặc biệt cho những người chịu trách nhiệm đánh giá sản phm phn mềm. Các kết qu đánh giá qua áp dụng các tiêu chun từ TCVN 8705:2011 đến TCVN 8708:2011 có th được sử dụng bởi người qun lí và người phát triển/ người bảo trì để đo tuân thủ các yêu cầu và thc hiện cải tiến khi cần. Các kết qu đánh giá cũng có thể sử dụng cho các nhà phân tích để thiết lập mối quan hệ giữa các phép đánh giá trong và ngoài. Nhân viên cải tiến quá trình có thể sử dụng các kết quả đánh giá để quyết định việc cải tiến các quá trình thông qua nghiên cứu và kiểm tra thông tin chất lượng sn phẩm của dự án.

CHÚ THÍCH: Phần lớn các hướng dn trong tiêu chuẩn từ TCVN 8705:2011 đến TCVN 8708:2011 (ISO/IEC 14598) không chỉ đặc trưng riêng cho phần mềm, mà cũng có th ứng dụng cho các sn phm phức tạp khác.

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 chun 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 bn 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 sn 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 phm 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 8706:2011 - Công nghệ thông tin - Đánh giá sn phm phần mềm - Phn 2: Quy trình cho bên đánh giá.

[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á sn phẩm phần mềm - Phần 4: Quy trình cho người mua sn phẩm.

[7] 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 sn phẩm - Phần 1: Mô hình chất lượng).

[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 mm).

[9] 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).

[10] ISO/IEC 2382-1:1993 - Information technology - Vocabulary - Part 1: Fundamental terms (ISO/IEC 2382-1: 1993 - Công nghệ thông tin - Từ vựng - Các thuật ngữ cơ bản)

[11] ISO 8402:1994 - Quality management and quality assurance - Quality vocabulary (ISO 8402:1994 - Quản lý cht lượng và đảm bảo chất lượng - Từ vựng chất lượng).

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

3.1. Các kỹ thuật (techniques)

Các phương pháp và kỹ năng yêu cầu để thực hiện nhiệm vụ cụ thể.

3.2. Các nhu cu ám ch (implied needs)

Các nhu cầu có thể chưa được công bố nhưng là các nhu cầu thực sự khi thực thể được sử dụng trong các điều kiện đặc thù

CHÚ THÍCH: Các nhu cầu ám ch là các nhu cu thực tế có thể chưa được đưa trong tài liệu.

3.3. Cht lượng (quality)

Tổng hợp các đặc tính của thực thể liên quan tới khả năng của nó thỏa mãn các yêu cầu đã được công bố và ám ch.

CHÚ THÍCH: Trong môi trường hợp đồng, hoặc trong môi trường quy định, như lĩnh vực an toàn nguyên tử, các yêu cu được xác định, trong khi đó trong các môi trường khác, các yêu cầu ám ch phải được nhận biết và định nghĩa.

CHÚ THÍCH 2: Trong TCVN 8705-8708:2011 thực th liên quan là sản phẩm phần mềm.

3.4. Chất lượng ngoài (external quality)

Khả năng của sản phm thỏa mãn các yêu cầu đã được công bố và ám ch khi sử dụng dưới các điều kiện xác định.

3.5. Cht lượng sử dụng (quality in use)

Khả năng của sản phẩm phần mềm cho phép người sử dụng xác định đạt tới các mục tiêu xác định với tính hiệu quả, năng suất, tính an toàn và sự thỏa mãn trong ngữ cảnh cụ thể khi sử dụng.

CHÚ THÍCH: Định nghĩa này của chất lượng s dụng tương tự như định nghĩa tính kh dụng trong ISO 9241-11. Trong TCVN 8705-8708:2011 thuật ngữ tính khả dụng được s dụng cho đặc tính chất lượng phần mềm mô tả trong ISO/IEC 9126-1.

3.6. Cht lượng trong (internal quality)

Tổng hợp các thuộc tính của sản phm xác định khả năng của nó để thỏa mãn các yêu cầu đã được công bố và ám ch khi sử dụng dưới các điều kiện xác định.

CHÚ THÍCH 1: Thut ngữ chất lượng trong, được sử dụng trong các tiêu chun từ TCVN 8705:2011 đến TCVN 8708:2011 trái ngược với chất lượng ngoài, v cơ bn có cùng ý nghĩa với như cht lượng trong ISO 8402.

CHÚ THÍCH 2: Thuật ngữ thuộc tính được s dụng với cùng ý nghĩa như thuật ngữ đặc tính” sử dụng trong 3.21, như thuật ngữ đặc tính được sử dụng trong ý nghĩa đặc trưng hơn trong các tiêu chun từ TCVN 8702:2011 đến TCVN 8704:2011.

3.7. Ch báo (indicator)

Hệ đo có thể được sử dụng để ước lượng hoặc dự báo hệ đo khác.

CHÚ THÍCH 1: Hệ đo có thể như nhau hoặc tính cht khác nhau.

CHÚ THÍCH 2: Các ch báo có th được sử dụng cho c ước lượng các thuộc tính chất lượng phần mềm và ước lượng các thuộc tính của quá trình sn xuất. Chúng là các hệ đo gián tiếp của các thuộc tính.

3.8. Chức năng hỗ trợ (suppoting function)

Tổ chức có trách nhiệm trợ giúp các hoạt động đánh giá phần mềm thông qua cung cấp công nghệ, công cụ, kinh nghiệm, và kỹ năng quản lý.

3.9. Công ngh đánh giá (evaluation technology)

Các kỹ thuật, công cụ, phép đánh giá, phép đo và thông tin kỹ thuật khác s dụng cho đánh giá

3.10. Đánh giá chất lượng (quality evaluation)

Kiểm tra một cách hệ thống giới hạn mà thực thể có khả năng thực hiện các yêu cầu xác định.

CHÚ THÍCH: Các yêu cu có thể xác định chính thức, như khi sản phẩm được phát triển cho người sử dụng cụ th bằng hợp đồng, hay được xác định bằng tổ chức phát triển, như khi sản phm được phát triển cho người sử dụng không cụ thể, như phn mềm thương mại, hoặc các yêu cầu có th chung hơn, như khi người sử dụng đánh giá các sn phm cho mục đích so sánh và lựa chọn.

3.11. Đo (measure - verb.)

Thiết lập phép đo.

3.12. Hệ đo (measure - noun.)

Số lượng hoặc phạm trù gắn với các thuộc tính của thực thể bằng cách thiết lập phép đo.

3.13. Hệ đo gián tiếp (indirect measure)

Hệ đo thuộc tính nhận được từ các hệ đo một hoặc nhiều các thuộc tính khác.

CHÚ THÍCH: Hệ đo ngoài của thuộc tính của hệ thống máy tính (như thời gian đáp ứng đầu vào người sử dụng) là hệ đo gián tiếp các thuộc tính của phần mềm vì rằng hệ đo s bị ảnh hưởng bởi các thuộc tính của môi trường tính toán cũng như các thuộc tính của phần mm

3.14. Hệ đo ngoài (external measure)

Hệ đo gián tiếp của sản phẩm nhận được từ các hệ đo các hoạt động của hệ thống mà sn phm là một phần của.

CHÚ THÍCH 1: H thống bao gồm bt kì phần cứng, phần mm liên kết nào (k c phn mềm của khách hàng hoăc phần mm đóng gói) và người sử dụng.

CHÚ THÍCH 2: S sự cố phát hiện được trong quá trình kiểm tra là các h đo ngoài của số sự cố trong chương trình vì số sự cố được đếm trong quá trình vận hành của hệ thống máy tính đang thực hiện chương trình để nhận biết lỗi trong mã.

CHÚ THÍCH 3: Các hệ đo ngoài có th được s dụng để đánh giá các thuộc tính cht lượng gn với các mục tiêu cơ bn của thiết kế.

3.15. Hệ đo trong (internal measure)

H đo nhn được từ chính bản thân phần mềm, bất kể là trực tiếp hay gián tiếp, nó không xuất phát từ các h đo các hoạt động của hệ thống mà nó là một phần.

CHÚ THÍCH: Các dòng mã, độ phức tạp, số sự cố phát hiện được trong các bước và Ch số mờ tt c đu là đo lường trong được tạo trong bn thân phần mềm.

3.16. Hệ đo trực tiếp (direct measure)

Hệ đo thuộc tính không phụ thuộc vào hệ đo các thuộc tính khác.

3.17. Hệ thống (system)

Tng hợp tích hợp bao gồm một hoặc nhiều quá trình, phần cứng, phần mềm, phương tiện và người, cung cấp kh năng thỏa mãn nhu cầu hoặc mục tiêu công bố.

3.18. Mô hình chất lượng (quality model)

Một bộ các đặc tính và quan hệ giữa chúng, cung cấp cơ s cho các yêu cầu chất lượng xác định và đánh giá chất lượng.

3.19. Môđun đánh giá (evaluation module)

Gói công nghệ đánh giá cho đặc tính hay đặc tính nh chất lượng phần mềm xác định.

CHÚ THÍCH: Gói bao gồm các phương pháp và các kỹ thut đánh giá, các đầu vào được đánh giá, dữ liệu được đo và thu thập, và các th tục và công cụ hỗ trợ.

3.20. Mức phân hạng (rating level)

Đim thang đánh giá trên thang đánh giá thứ tự được sử dụng để phân loại thang đánh giá phép đo.

CHÚ THÍCH 1: Mức phân hạng cho phép phn mm phân lớp (phân hạng) tương ứng với các nhu cầu công bố hay mặc nhiên.

CHÚ THÍCH 2: Các mức phân hạng thích hợpthể liên quan với các quan điểm của chất lượng, tức là, Người sử dụng, Người quản lý hay “Người phát trin.

3.21. Người bảo trì (maintainer)

Tổ chức thực hiện các hoạt động bảo trì.

3.22. Người cung cấp (supplier)

T chức tham gia vào hợp đồng với người mua sản phm để cung cấp hệ thống, sản phẩm phần mềm hoặc dịch vụ phần mềm theo các điều khoản của hợp đồng.

3.23. Người mua sản phẩm (acquirer)

T chức mua hay nhận hệ thống, sản phm phần mềm hoặc dịch vụ phần mềm từ nhà cung cấp.

CHÚ THÍCH: Người mua sản phm có thể là: người mua, khách hàng, ch s hữu, người s dụng.

3.24. Người phát triển (developer)

Tổ chức tạo lập các hoạt động phát triển (bao gồm phân tích yêu cầu, thiết kế, kiểm tra thông qua chấp thuận) trong quá trình vòng đời phần mềm.

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

Cá nhân sử dụng sản phẩm phần mềm để thực hiện chức năng xác định.

CHÚ THÍCH: Người s dụngthể bao gồm người vận hành, người nhn kết quả của phần mm, hoặc người phát triển, hoặc người bo trì phần mm.

3.26. Phân hạng (rating)

Hành động ánh xạ giá tr đo được tới mức phân hạng thích hợp. Thường dùng để xác định mức phân hạng liên quan với phần mềm cho các đặc tính chất lượng cụ th.

3.27. Phn mềm (software)

Tất cả hoặc một phần của các chương trình, thủ tục, qui tắc, và tài liệu đi kèm của một hệ thống xử lí thông tin.

CHÚ THÍCH: Phần mm là sáng tạo trí tuệ không phụ thuộc vào phương tiện nó được lưu trữ.

3.28. Phép đánh giá (metric)

Thang đo và phương pháp sử dụng đo.

CHÚ THÍCH 1: Phép đánh giá có thể là trong hoặc ngoài.

CHÚ THÍCH 2: Các phép đánh giá bao gồm các phương pháp cho phân loại dữ liệu định tính.

3.29. Phép đo (measurement)

Quá trình gắn số lượng hoặc phạm trù với thực th mô tả thuộc tính của thực th.

CHÚ THÍCH: Phạm trù được s dụng đ biểu thị các phép đo định tính của các thuộc tính. Ví dụ, một số các thuộc tính quan trọng của sản phm phần mềm, như ngôn ngữ của chương trình nguồn (ADA, C, COBOL, ...) là định tính.

3.30. Sản phẩm phn mềm (software product)

Một bộ các chương trình máy tính, thủ tục, và có thể các tài liệu đi kèm và dữ liệu thiết kế đ phân phối cho người sử dụng.

CHÚ THÍCH: Sản phẩm bao gồm các sn phm trung gian, và các sn phm dự định cho người s dụng như người phát triển và người bảo trì.

3.31. Sản phm phn mm trung gian (intermediate software product)

Sản phẩm của quá trình phát triển phần mềm được sử dụng như đầu vào các giai đoạn khác của quá trình phát triển phần mềm.

CHÚ THÍCH: Trong một số trường hợp sn phẩm trung gian cũng có thể là sản phẩm cuối cùng.

3.32. Sự hỏng (fault)

Một bước, một quá trình hay xác định dữ liệu không đúng trong chương trình máy tính.

3.33. Sự xác minh (verification)

Khẳng định bằng kiểm tra và cung cấp bằng chứng khách quan rằng các yêu cầu xác định đã được thực hiện.

CHÚ THÍCH 1: Trong thiết kế và phát triển, xác minh liên quan đến quá trình kim tra kết qu của hoạt động cho trước đ xác định việc tuân theo các yêu cu công bố cho hoạt động này.

CHÚ THÍCH 2: Xác minh được sử dụng để ch định trạng thái tương ứng.

3.34. Sự xác nhận (validation)

Khẳng định bằng kiểm tra và cung cấp bằng chứng khách quan rằng các yêu cầu đặc thù cho sử dụng dự kiến cụ thể đã được thực hiện.

CHÚ THÍCH 1: Trong thiết kế và phát trin, xác nhận liên quan đến quá trình kiểm tra sản phm để xác định việc tuân theo các nhu cầu người sử dụng.

CHÚ THÍCH 2: Xác nhn thông thường được thực hiện trên sản phm cuối dưới các điều kiện vn hành xác định. Nó cũng có thể cần thiết trong các giai đoạn sớm hơn.

CHÚ THÍCH 3: Xác nhận được sử dụng để chỉ định trạng thái tương ứng.

CHÚ THÍCH 4: Nhiu xác nhận có thể được thực hiện nếu có các sử dụng dự kiến khác nhau.

3.35. Thang đánh giá (scale)

Bộ các giá trị với các đặc tính xác định.

CHÚ THÍCH: Các ví dụ các loại thang đánh giá là: thang danh nghĩa phù hợp với một bộ các phạm trù; thang thứ tự phù hợp với một bộ được sắp xếp của các đim thang đánh giá; thang khoảng phù hợp với thang đánh giá được sp xếp với các đim thang cách đu nhau; và thang đánh giá tỷ lệ không ch có điểm thang đánh giá cách đu nhau mà còn có điểm không tuyệt đối. Các phép đánh giá sử dụng thang danh nghĩa và thang thứ tự cung cấp các dữ liệu định tính, và các phép đánh giá s dụng thang khoảng và thang tỷ lệ cung cp dữ liệu định lượng.

3.36. Thất bại (failure)

Kết thúc khả năng của sn phẩm thực hiện chức năng yêu cầu hay sự bất lực của nó khi thực hiện trong các giới hạn được xác định trước.

3.37. Thuộc tính (attribute)

Đặc tính vật lý đo được hay đặc tính lý thuyết của thực thể.

4. Quy trình đánh giá

Để đánh giá chất lượng sản phẩm phần mềm, đầu tiên thiết lập các yêu cầu đánh giá, sau đó xác định, thiết kế và thực hiện đánh giá (Hình 1) Mỗi bước được mô tả chi tiết hơn trong các mục dưới.

Hình 1 - Quy trình đánh giá sản phẩm phn mm

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

5.1. Thiết lập mục đích đánh giá

5.1.1. Tổng quan

Mục đích đánh giá chất lượng sn phẩm phần mềm nhằm hỗ trợ trực tiếp cả quá trình phát triển và khai thác phần mềm sao cho đáp ng yêu cầu của người s dụng và khách hàng. Mục tiêu cuối cùng là bo đm rằng sản phm cung cấp đúng chất lượng yêu cầu - nó phù hợp các yêu cầu công bố và mặc nhiên của người sử dụng (bao gồm c người vận hành, người nhận kết qu của phần mềm, hoặc người bo trì phần mềm).

Mục đích của việc đánh giá các sn phẩm trung gian có thể là:

· Quyết định chấp nhận một sn phẩm trung gian từ một nhà phát triển phần mềm phụ;

· Quyết định sự hoàn thành của một quá trình và chuyển các sn phm này sang quá trình tiếp theo;

· Dự báo hay ước lượng cht lượng sản phm cuối cùng;

· Thu thập thông tin về các sản phm trung gian để điều khiển và qun lý quá trình.

Mục đích của việc đánh giá chất lượng sản phẩm cuối cùng có thể là:

· Quyết định chấp nhận sản phm;

· Quyết định thời đim phân phối sản phẩm;

· So sánh sn phẩm với các sản phm cạnh tranh;

· Chọn một sản phẩm trong các sản phẩm thay thế;

· Đánh giá tác động tốt và xấu khi sử dụng sản phm;

· Quyết định thời điểm nâng cấp và thay thế sản phm.

Chất lượng sn phm phần mềm có th được đánh giá trong cấu trúc chất lượng xác định trong suốt các quá trình vòng đời phát triển và khai thác sản phẩm.

5.1.2. Mua sản phẩm

Khi thu được sản phẩm phần mềm sn xuất đặt hàng, người mua sản phẩm phải thiết lập các yêu cầu chất lượng ngoài, xác định các yêu cầu cho người cung cấp, và đánh giá lợi nhuận tiềm năng đối với các yêu cầu này trước khi mua sản phẩm.

Khi sản phm bắt đầu được phát triển, mục tiêu của các yêu cu cht lượng xác định là bo đm sn phẩm phù hợp với các nhu cu công bố và mặc nhiên của người sử dụng.

Khi mua sn phm phần mềm, đánh giá có thể được s dụng để so sánh các sn phẩm thay thế khác và đảm bảo sản phẩm được chọn phù hợp yêu cầu chất lượng.

5.1.3. Cung cấp

Người cung cấp có th sử dụng các kết qu của đánh giá sn phẩm phần mềm để đảm bảo các sản phm phù hợp với tiêu chí chất lượng yêu cầu có thể được thiết lập bởi người mua sn phẩm, hoặc bằng cách so sánh với các sản phm khác.

5.1.4. Phát triển

Các yêu cầu diễn tả các nhu cầu người sử dụng cho sản phẩm phần mềm được xem xét, và được xác định ưu tiên cho việc phát triển. Do sản phẩm phần mềm được phân tích thành các thành phần chính, các yêu cầu xuất phát từ sản phm toàn bộ có thể khác với các thành phần khác nhau, và có thể yêu cu tiêu chí đánh giá khác nhau. Ưu tiên cho đánh giá chất lượng, các yêu cầu chất lượng phải được xác định trên phạm vi của các đặc tính và các đặc tính nhỏ.

Trong giai đoạn đầu của đánh giá, các yêu cầu chất lượng này phải được nghiên cứu và nhận biết, cho lập việc kế hoạch và triển khai đánh giá. Người phát triển phải thiết lập các yêu cầu đánh giá ngoài cho từng đặc tính chất lượng liên quan. Tính hoàn thiện và tính đúng đắn của đặc tính yêu cầu chất lượng phải được đánh giá để bảo đm rằng tất cả các yêu cầu cần thiết đã được xác định và các yêu cầu không cần thiết được loại b. Người phát triển cần đánh giá sn phm theo các yêu cầu này trước khi phát hành.

Để đạt được c nhu cầu công bố lẫn mặc nhiên điều quan trọng là kiểm tra các nhu cầu ám chỉ được xác định đủ chi tiết cho tất c các đặc tính chất lượng liên quan. Nếu có thể, các yêu cầu phải được đánh giá bởi môi giới hoặc người mua hàng, và bởi người sử dụng cuối để đánh giá các nhu cầu ám chỉ. Kinh nghiệm của người sử dụng với các nguyên mẫu thường xuyên đưa đến các trình bày các yêu cầu chính xác hơn cho chất lượng sử dụng.

Người phát triển phải định rõ các yêu cầu chất lượng trong. Khi các yêu cầu chất lượng trong được sử dụng, người phát triển phải định rõ chúng sử dụng mô hình chất lượng mà nó liên hệ các yêu cầu trong với các yêu cầu chất lượng ngoài, và sử dụng các yêu cầu chất lượng trong để xác minh các sản phẩm trung gian trong quá trình phát triển.

Đánh giá phần mềm phải được sử dụng để dự báo và xác minh chất lượng trong phát triển, bằng cách xác định các yêu cầu cht lượng trong cho các sn phẩm trung gian trong quá trình phát triển. Chất lượng ngoài của sản phẩm hoàn chỉnh cho các sử dụng dự kiến cụ thể có th tiếp tục được đánh giá theo các yêu cầu ban đầu.

Các kết qu của đánh giá chất lượng phần mềm có thể được sử dụng để thu được phản hồi trên các phạm vi mà các quá trình phát triển, các phương pháp hoặc công cụ CASE khác nhau có thể được sử dụng để thỏa mãn các yêu cầu chất lượng.

5.1.5. Vận hành

Tổ chức vận hành hệ thống phần mềm có thể sử dụng đánh giá chất lượng phần mềm để xác nhận rằng các yêu cầu chất lượng đã được thỏa mãn trong các điều kiện khác nhau, và cung cấp phản hồi khi cần cho các thay đổi tới những người chịu trách nhiệm bảo trì.

5.1.6. Bảo trì

Tổ chức bo trì phần mềm có th sử dụng đánh giá phần mềm để xác nhận rằng các yêu cầu chất lượng hãy còn phù hợp, và các yêu cầu cho khả năng bảo trì và tính kh chuyển được hoàn thành.

5.2. Xác định loại sản phẩm được đánh giá

Loại sản phẩm phần mềm trung gian hay sn phẩm phần mềm cuối cùng được đánh giá sẽ phụ thuộc vào giai đoạn trong vòng đời và mục đích của đánh giá (xem Hình 2).

Hình 2 - Chất lượng trong vòng đời phần mềm

Mục đích là khi sn phẩm phần mềm được sử dụng thực sự bởi người sử dụng nó đáp ứng những nhu mặc nhiên. Chất lượng ngoài ch có thể được đánh giá cho một hệ thống phần cứng/phần mềm hoàn chỉnh mà phần mềm là một phần của hệ thống đó. Các phép đánh giá ngoài được áp dụng phần mềm khi thực hiện phần mềm. Các giá trị hệ đo ngoài cần phụ thuộc vào không ch phần mềm, do đó phần mềm phải được đánh giá như một phần của hệ thống hoạt động.

Cht lượng sử dụng là ảnh hưởng kết hợp của các đặc tính cht lượng liên quan đối với người sử dụng đặc thù (có thể là người sử dụng cuối, người vận hành hay người bảo trì). Đối với phần mềm để đạt cht lượng sử dụng cần phải đáp ứng các nhu cầu của người sử dụng, khi thực hiện các nhiệm vụ cụ thể trong môi trường phần cứng, phần mềm cụ thể. Phần mềm hoạt động đạt yêu cầu trong một môi trường có thể xut hiện lỗi trong một môi trường khác. Đánh giá ngoài các đặc tính chất lượng phải được thực hiện dưới các điều kiện mô phỏng gần tới mức có thể với các điều kiện sử dụng mong đợi. Các phép đo ngoài của các đặc tính được thực hiện khi mã đã hoàn thành, mặc dù có thể không có khả năng mô phỏng chính xác điều kiện sử dụng (ví dụ, môi trường mạng và các đặc tính người sử dụng), các hệ đo ngoài thường ch là ch báo của chất lượng sử dụng thực tế.

Nếu những yêu cầu chất lượng ngoài không đạt được, kết quả của đánh giá có th được sử dụng như phản hồi để chỉnh sửa các đặc tính phần mềm với mục đích ci tiến chất lượng ngoài, do đó trợ giúp một quá trình ci tiến lặp lại nữa.

Đối với mục đích phát triển, những yêu cầu chất lượng trong được xác định cho phép chất lượng các sn phm trung gian được kiểm tra. Những đặc tính trong (như đặc t hoặc mã nguồn) của phần mềm có thể được đo bằng các phép đánh giá trong. Các phép đánh giá trong được quan tâm nhiều nhất trong quá trình phát triển. Các hệ đo trong có thể được s dụng như ch báo cho các thuộc tính ngoài. Điều chỉnh và khả năng truy vết là các ví dụ của các thuộc tính trong được đo. Đạt được chất lượng trong yêu cầu sẽ góp phần thỏa mãn các yêu cầu ngoài của phần mềm khi sử dụng. Do vậy, các hệ đo chất lượng phần mềm trong có thể được sử dụng để ước lượng chất lượng sử dụng (xem Hình 3).

Ví dụ, thời gian đáp ứng là một hệ đo quan trọng để đánh giá tính khả dụng và tính hiệu qu ca phn mềm, nhưng thời gian đáp ứng không thể đo được trong quá trình phát triển. Để đánh giá tính hiệu qu của sn phẩm trong phát triển, độ dài đường dẫn có thể được đo dựa vào các sản phm trung gian hoặc các đặc tả. Phương pháp này cũng được sử dụng như ch báo cung cấp các ước lượng thô của thời gian đáp ứng trong những điều kiện cho trước.

Các thuộc tính chất lượng trong của phần mềm liên quan đến các yêu cầu chất lượng ngoài là rt quan trọng, để cho các đặc tính chất lượng của sản phẩm phần mềm trong giai đoạn phát triển (gồm cả sản phẩm trung gian và sản phẩm cuối cùng) có thể được đánh giá trên những nhu cầu chất lượng s dụng của hệ thống cuối. Các hệ đo trong thường ít giá trị trừ khi có bằng chứng chúng liên quan đến cht lượng ngoài.

Các thuộc tính cụ thể liên quan đến chất lượng cuối cùng s phụ thuộc vào điều kiện dự kiến sử dụng - đối với các sản phẩm tương tác nó sẽ phụ thuộc vào nhu cầu của người sử dụng và nhiệm vụ cuối cùng. Các yếu tố khác sẽ ảnh hưởng đến nhu cầu chất lượng sản phẩm phần mềm bao gồm sản phẩm được bán hay phát triển không, giai đoạn phát triển, và phần cứng, phần mềm và môi trường mạng sản phm sẽ được sử dụng.

Hình 3 - Mối quan h giữa các hệ đo

Các hệ đo ngoài của một hệ thống máy tính cũng có thể được sử dụng như hệ đo gián tiếp của chất lượng phần mềm trong. Vì thế, thời gian đáp ứng của một hệ thống máy tính có thể được sử dụng để đo tính hiệu qu của phần mềm trong một môi trường tính toán cụ thể.

5.3. Xác định mô hình chất lượng

Bước đầu tiên trong đánh giá phần mềm là lựa chọn đặc tính chất lượng liên quan, sử dụng mô hình chất lượng phân tách chất lượng phần mềm thành nhiều đặc tính khác nhau. Các mô hình đánh giá phần mềm nhìn chung thường biểu diễn toàn bộ các thuộc tính chất lượng phần mềm đã được phân lớp trong cấu trúc cây phân cấp của các đặc tính và các đặc tính con. Mức cao nhất trong cây này bao gồm các đặc tính chất lượng và mức thấp nhất bao gồm các thuộc tính chất lượng. ISO/IEC 9126-1 cung cấp mô hình mục tiêu tổng quát xác định sáu loại đặc tính chất lượng: tính chức năng, tính tin cậy, tính khả dụng, tính hiệu quả, khả năng bảo trì và tính kh chuyển. Chúng sau đó có thể được chia thành các đặc tính nhỏ có các thuộc tính đo được. Hiệu quả kết hợp của các đặc tính chất lượng trong tình huống sử dụng đặc thù được xác định như cht lượng sử dụng.

Các thuộc tính chất lượng sản phẩm phần mềm trong là các đặc điểm có thể đo được của sản phm phần mềm ảnh hưởng tới khả năng đáp ứng những nhu cu công bố và mặc nhiên. Một vài thuộc tính có thể được sử dụng để đánh giá đặc tính và đặc tính nh của chất lượng một sn phm phần mềm cụ thể (Hình 4).

Hình 4 - Các đặc tính, đặc tính nhỏ và thuộc tính cht lượng

Các thuộc tính trong và ngoài đủ phải được xác định cho mỗi đặc tính nh yêu cầu.

Các đặc tính và đặc tính con thực tế có liên quan đến nhau trong bất kỳ tình huống cụ thể nào sẽ phụ thuộc vào mục đích đánh giá, và sẽ phải được xác định bởi nghiên cứu yêu cầu chất lượng. Các đặc tính và đặc tính nh của ISO/IEC 9126-1 cung cấp bản danh sách các vấn đề liên quan đến chất lượng, nhưng các cách khác phân loại chất lượng có thể thích hợp hơn trong các trường hợp cụ thể.

CHÚ THÍCH: Ví dụ, IEC 50(191) xác định tính tin cậy như là giới hạn người sử dụng có thể phụ thuộc chính đáng vào dịch vụ nhận được từ hệ thống. Nó được chia ra thành các đặc tính tính tin cậy, tính hiệu dụng và khả năng bảo trì. Nó cũng có th bao gồm tính khả dụng, khả năng phục hồi, an toàn, khả năng m rộng và anh ninh.

6. Xác định đánh giá

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

Điều quan trọng là các phép đo sản phm phần mềm có thể được thực hiện dễ dàng và kinh tế và các hệ đo kết qu dễ sử dụng. Nhiều phép đo phần mềm được làm ra một cách tiện lợi với công cụ dạng nào đó, và có thể được đóng gói như một mô đun đánh giá (ISO/IEC 14598-6).

Cách thức các đặc tính chất lượng được xác định không cho phép đo trực tiếp. Cn thiết lập các phép đánh giá liên kết đến các đặc tính của sản phm phần mềm. Mỗi thuộc tính trong định lượng được của phần mềm và mỗi thuộc tính ngoài định lượng được của phần mềm tương tác với môi trường của nó tương quan với đặc tính có thể được thiết lập như phép đánh giá.

Các phép đánh giá có thể khác nhau tùy theo môi trường và giai đoạn của quá trình phát triển chúng được sử dụng. Các phép đánh giá trong quá trình phát triển phải được tương quan đến các phép đánh giá theo quan điểm của người sử dụng, vì các phép đánh giá từ quan điểm của người sử dụng là cốt yếu.

6.1.1. Các loại phép đo

Có hai mục tiêu chính của đánh giá:

· Xác định các vấn đề sao cho chúng có thể được sửa, và

· So sánh chất lượng của một sn phẩm với các sản phẩm thay thế hoặc để đối chiếu với các yêu cầu (có thể bao gồm chứng nhận).

Loại phép đo yêu cầu sẽ phụ thuộc vào mục đích của đánh giá. Nếu mục đích chính là để hiểu và sửa những sai sót, một loạt các phép đo có thể sử dụng trong phần mềm đ giám sát và điều khiển quá trình ci tiến. Có rất nhiều hệ đo có thể hữu ích cho các mục đích này, bao gồm cả danh sách kiểm tra và ý kiến chuyên gia. Yêu cầu chính là các phép đo xác định chính xác tác động của bất cứ thay đổi trong phần mềm đến chất lượng.

Các phép đánh giá nghiêm ngặt hơn yêu cầu tạo ra các so sánh tin cậy, giữa những sn phm hoặc với những giá trị tiêu chí. Các thủ tục đo phải đo đặc tính chất lượng phần mềm (hoặc đặc tính nh) đòi hỏi tính chính xác đủ để cho phép thiết lập tiêu chí và thực hiện các so sánh. Quan trọng là đặc tả đánh giá xác định mô hình chất lượng chính xác, và các phương pháp đo, thang đo và các mức phân hạng cho mỗi phép đánh giá. Dữ liệu từ các danh sách kiểm tra và ý kiến chuyên gia có th không tin cy khi so sánh các sản phẩm với các thuộc tính khác nhau. Phải lập hạn định cho phép cho các lỗi đo có thể gây ra bởi các công cụ đo hay lỗi do con người.

6.1.2. Các yêu cu cho các phép đo

Phép đo trong phải có tính xác nhận dự báo, nghĩa là chúng phải tương quan với một số tiêu chí ngoài mong đợi. Ví dụ, một hệ đo trong của thuộc tính phần mềm cụ thể có thể phải tương quan với một số khía cạnh đo được của chất lượng khi phần mềm được sử dụng. Việc các phép đo gán những giá trị khớp với những kết qu mong đợi là quan trọng; ví dụ nếu các phép đo khuyến cáo rằng sản phẩm có cht lượng cao thì nó phải đồng nhất với sản phẩm thỏa mãn các nhu cầu người sử dụng cụ thể.

6.2. Thiết lập mức phân hạng cho các phép đánh giá

Các đặc tính có thể đo một cách định lượng bng cách dùng các phép đo chất lượng. Kết quả, tức là giá trị đo, được ánh xạ vào một thang đánh giá. Giá trị này tự nó không cho thấy mức độ thỏa mãn. Với mục đích đó, thang đánh giá được chia thành các dải tương ứng theo các bậc thỏa mãn khác nhau đối với các yêu cầu, ví dụ như:

- Chia thang đánh giá thành hai loại: thỏa mãn và không thỏa mãn;

- Chia thang đánh giá thành bốn loại, giới hạn bởi mức hiện thời cho sản phm đang tồn tại hoặc sn phẩm thay thế, trường hợp xấu và mức hoạch định. Mức hiện thời được công bố để quản lý hệ thống mới không tồi hơn tình huống hiện tại. Mức hoạch định được coi là sẽ đạt được với những tài nguyên có sẵn. Mức trường hợp xu là mốc cho sự chấp nhận của người sử dụng, trong trường hợp sn phm không đạt được mức hoạch định (xem Hình 5).

Hình 5 - Các mức phân hạng cho phép đánh giá

6.3. Thiết lập tiêu chí đánh giá

Những đặc tả yêu cầu chất lượng phần mềm s được xác định s dụng mô hình chất lượng rõ ràng và thích hợp. Với mục đích đó mô hình chất lượng và các định nghĩa trong ISO/IEC 9126-1 phải được sử dụng, trừ phi có lí do đặc biệt sử dụng mô hình khác.

Để đánh giá chất lượng của sản phẩm, các kết qu đánh giá về các đặc tính khác nhau cần được tổng hợp lại. Bên đánh giá cần phải chun b thủ tục cho việc này, với tiêu chí riêng cho các đặc tính cht lượng khác nhau, mỗi đặc tính có thể là những đặc tính nhỏ riêng, hay kết hợp có trọng số của nhiều đặc tính nhỏ. Thủ tục thường bao trùm nhiều khía cạnh như thời gian và chi phí, đóng góp cho đánh giá chất lượng sn phẩm phần mềm trong một môi trường cụ thể.

7. Thiết kế đánh giá

7.1. Tạo lập kế hoạch đánh giá

Kế hoạch đánh giá mô t các phương pháp đánh giá và lịch trình đánh giá của các hành động của người đánh giá (xem tiêu chuẩn từ TCVN 8706:2011 đến TCVN 8708:2011). Nó cũng phải đồng nhất với kế hoạch đo được trình bày dưới.

7.2. Các yêu cầu và khuyến nghị hỗ trợ đánh giá phần mềm

7.2.1. Tổng quan

T chức phải xây dựng chính sách và các kế hoạch cho tất cả các hoạt động đánh giá. Trách nhiệm của các chức năng hỗ trợ cũng sẽ được xác định cho tất cả các hoạt động đánh giá.

a) Các bước sau phải thực hiện khi lập kế hoạch và thực thi đánh giá phần mềm:

1) Xác định mục đích đánh giá phần mềm.

2) Đm bảo kế hoạch đánh giá định lượng cho tất cả các dự án đánh giá được phát triển. Kế hoạch này có thể phân chia thành các kế hoạch mức thấp hơn, tùy thuộc vào sự phức tạp của đánh giá cụ thể.

3) Đưa các kinh nghiệm đánh giá dự án và/hoặc sản phẩm vào cơ s dữ liệu của tổ chức, nhằm nâng cao giải pháp của t chức cho đánh giá phần mềm.

b) Tổ chức phải thực hiện tất c các hoạt động đánh giá phần mềm tương ứng với các điều sau:

1) Đánh giá xem phần mềm có phù hợp với các chun quốc tế, quốc gia hay nội bộ không (nếu nó có khả năng áp dụng).

2) Đm bảo rằng các kết qu đánh giá có thể định lượng, được trình bày rõ ràng và có thể theo dõi được.

3) Đảm bảo s dụng công nghệ phù hợp và hiệu quả và các sử dụng các thực nghiệm tốt nhất.

4) Đm bảo công việc đánh giá được trin khai hiệu qu.

5) Đm bảo các kế hoạch và khuyến nghị hỗ trợ tất cả các hoạt động đánh giá tương lai là kh thi.

7.2.2. Quản lý mức t chức

Các tổ chức phát triển, khai thác hoặc đánh giá phần mềm phải có trách nhiệm đánh giá tổng thể và các hoạt động đảm bảo cht lượng được xác định rõ ràng và kết hợp chặt chẽ với kế hoạch.

CHÚ THÍCH: Khi trin khai, kế hoạch này s giúp cải tiến chất lượng đánh giá và đm bảo sử dụng tt nht công nghệ sẵn có và liên quan.

Một số t chức có thể chọn cách giao phó các hoạt động đánh giá cho một bên thứ ba. Bên thứ ba này cũng sẽ qun lý công nghệ đánh giá sao cho phù hợp với các yêu cầu và các khuyến nghị dưới đây.

7.2.2.1. Lập kế hoạch sử dụng và cải tiến công nghệ đánh giá

Một kế hoạch tổng thể để cải tiến đánh giá phần mềm và các kỹ thuật hỗ trợ của nó phi được tạo lập và triển khai. Kế hoạch phải bao gồm:

a) Chun bị chính sách

Cần có một chính sách công bố tiếp cận của tổ chức giới thiệu, bo trì và cải tiến đánh giá chất lượng phần mềm.

b) Xác định các mục đích của tổ chức

Các mục đích này đạt được bằng cách giới thiệu, bảo trì và ci tiến công nghệ đánh giá chất lượng phần mềm phải được xác định.

c) Xác định công nghệ sử dụng

Các phương pháp và kỹ thuật đánh giá phần mềm được s dụng sẽ được đánh giá và xác định trong kế hoạch. Mọi sai lệch trong mục đích đề ra sẽ được sửa chữa.

d) Gán trách nhiệm cho quản lý đánh giá

Trách nhiệm công bố rõ ràng sẽ được gán cho giới thiệu, bảo trì, liên tục ci tiến quy trình đánh giá.

e) Xác định những cải tiến tương lai

Quá trình và các hoạt động để nghiên cứu về tính hiệu dụng và tính áp dụng của công nghệ mới phải được xác định. Công việc này bao gồm các thử nghiệm và đánh giá thử, giới thiệu và bảo trì các kỹ thuật mới.

7.2.2.2. Triển khai công nghệ đánh giá

Tổ chức sẽ phải:

a) Tự đánh giá và đánh giá từ bên ngoài các công nghệ đánh giá chất lượng có sẵn và phải xác định những nhu cầu của mình, nếu cần, xác định xem công nghệ mới có thể giành được như thế nào.

b) Gạn lọc và xác định những yêu cầu chi tiết để thu được hay phát triển công nghệ đánh giá theo kết quả của công việc a) trên. Những kế hoạch này sau đó s được triển khai.

c) Xác định quá trình chấp nhận và vận hành công nghệ đánh giá đã nhận được.

Bất cứ mô đun đánh giá được xác nhận nào cũng phải được bảo trì bằng quản lý cấu hình, và được ghi nhận như Mô đun đánh giá (ISO/IEC 14598-6). Nếu không, nó phải được sử dụng thử nghiệm để đánh giá.

Quy trình đánh giá phần mềm của tổ chức phải được xác định. Nếu không có sẵn, nó sẽ được ly từ bên ngoài. Trong trường hợp đó:

a) Đầu tiên, nếu có sẵn các tiêu chuẩn quốc tế, quốc gia, tổ chức phải giới thiệu các tiêu chun này.

b) Tiếp theo, nếu có sẵn các công nghệ đánh giá có tiếng trong các viện hay công nghiệp, tổ chức phải xem xét để giới thiệu những công nghệ này.

c) Cuối cùng, tổ chức phải xem xét việc phát triển một công nghệ thích hợp hoặc ký hợp đồng với một công ty chuyên trách bên ngoài để đáp ứng các yêu cầu này.

7.2.2.3. Chuyển giao công nghệ sử dụng đánh giá

Đ chuyển giao công nghệ đã phát triển hay nhận được trong tổ chức, tổ chức phải chuẩn bị các chương trình đào tạo, công cụ và môi trường thích hợp để giới thiệu và chấp thuận công nghệ mới. Các chương trình, công cụ và môi trường này không nhất thiết phải giữ nguyên, nhưng phải phù hợp vi mức độ công nghệ của dự án.

a) Chuẩn bị cho chuyển giao công nghệ:

T chức phải xem xét cho mục đích chuyển giao công nghệ như sau:

· Chun bị kế hoạch đánh giá định lượng bao trùm các mục tiêu, hành động, lịch trình, mục đích dự án và trách nhiệm cho các hoạt động chuyển giao công nghệ.

· Chuẩn bị các chương trình đào tạo hỗ trợ.

· Chun bị các công cụ và môi trường.

· Xác định phương thức thu thập số liệu vá đánh giá công việc chuyển giao công nghệ.

· Xác định phương thức tích lũy kinh nghiệm về chuyển giao công nghệ.

b) Trin khai chuyển giao công nghệ

Tổ chức phải triển khai chuyển giao công nghệ và thu thập số liệu dựa theo kế hoạch đã định.

c) Đánh giá việc chuyển giao công nghệ

Tổ chức phải đánh giá việc chuyển giao công nghệ như sau:

· Đánh giá tác động của công nghệ được giới thiệu cho tất c các dự án.

· Đánh giá những giới hạn sử dụng công nghệ trong phạm vi t chức.

Nếu cần, tổ chức phải sửa đổi hay chuẩn bị kế hoạch mới dựa trên kết quả của đánh giá.

7.2.2.4. Đánh giá công nghệ sử dụng cho đánh giá

Để thu được những kết qu tốt trong việc đánh giá, công nghệ sử dụng phải được đánh giá.

Các kết qu đánh giá nhận được từ một dự án được thu thập và đánh giá như sau:

a) Thu thập và bảo trì thông tin

Phải thu thp những thông tin công nghệ cần thiết cho việc đánh giá (ví dụ, nỗ lực dành cho các phép đo và đánh giá). Những thông tin này phải được kiểm tra, lựa chọn, chỉnh sửa và duy trì để sử dụng sau này trong các dự án khác và cho mục đích kiểm tra tính hữu dụng của công nghệ mới.

b) Phân tích và đánh giá kết quả đánh giá cùng với công nghệ sử dụng

Các kết qu đánh giá phần mềm sẽ được phân tích và đánh giá. Công việc này có thể bao gồm xác nhn của:

· Các phép đo

· Tiêu chí đánh giá

· Các phép đánh giá

· Các kỹ thuật

Và tính hiệu quả của đánh giá phần mềm tng thể. Những phân tích và đánh giá này có thể được tiến hành dựa theo kế hoạch đánh giá định lượng.

c) Tiêu chun hóa

S dụng công nghệ đánh giá phải được tiêu chun hóa trong phạm vi tổ chức, nếu nó kh thi.

7.2.2.5. Quản lý kinh nghiệm

Người qun lý phải chịu trách nhiệm đối với việc sử dụng hiệu quả công nghệ đánh giá trong tổ chức và đảm bảo rằng kết quả và kinh nghiệm đánh giá sẽ được lưu giữ lại trong tổ chức. Việc này sẽ được sử dụng để ci tiến chất lượng và sử dụng công nghệ đánh giá.

Những ci tiến có thể đạt được thông qua việc chỉnh sửa các tiêu chuẩn đánh giá của chính t chức, có thể bao gồm các mục như xác định yêu cầu chất lượng, lựa chọn phép đánh giá, xác định mức phân hạng và tiêu chí đánh giá.

Một số tiếp cận sau được khuyến nghị:

· Thực hiện soát xét đánh giá chất lượng định kỳ,

· Kết hợp các tiêu chuẩn có sẵn với các tiêu chuẩn mới và với việc s dụng các phép đánh giá mới,

· Cung cấp phản hồi của kết quả đánh giá cho những tiêu chun đó,

· Cung cấp phản hồi của kết qu đánh giá cho kế hoạch chất lượng hoặc ch dn chất lượng của tổ chức.

· Duy trì các bn ghi của những cải tiến và đảm bảo sử dụng thực tiễn tốt nhất trong tổ chức

7.2.3. H trợ việc quản lý dự án

Việc quản lý dự án của các dự án đánh giá cụ thể được trợ giúp bởi chức năng hỗ trợ. Chức năng này chịu trách nhiệm tổng thể đối với tất c các hoạt động đánh giá và công nghệ sử dụng trong t chức. Nó bao gồm lập kế hoạch đánh giá, xúc tiến kế hoạch và chuyển giao công nghệ giữa dự án và tổ chức.

Để qun lý một dự án đánh giá, phi có một kế hoạch đánh giá định lượng thống nhất.

Việc đánh giá phải được quản lý bởi một người quản lý dự án có kinh nghiệm và công việc này cn phải có:

· Một quỹ đã được phê chuẩn,

· Nguồn lực con người và máy móc phù hợp,

· Các công cụ, chun và thủ tục hỗ trợ,

· Kế hoạch đánh giá định lượng được xác định rõ ràng, được ghi chép và được thông qua. Kế hoạch này phải xác định các mục đích công bố đạt được như thế nào, và như thế nào và bao giờ thì những phép đo này được sử dụng để hỗ trợ quy trình đánh giá.

Người quản lý hỗ trợ chức năng chịu trách nhiệm về chiến lược đánh giá tổng thể và công nghệ trong một tổ chức phải hỗ trợ người quản lý dự án trong việc triển khai kế hoạch này.

7.2.3.1. Hỗ trợ việc lập kế hoạch đánh giá

Để thực hiện thành công việc đánh giá sản phẩm phần mềm, một kế hoạch đánh giá định lượng phải được phát triển từ lúc bt đầu dự án hoặc bắt đu đánh giá. Mục tiêu của kế hoạch là giúp người quản lý dự án xác định và giám sát các mục tiêu cht lượng định lượng. Nó cũng phải giúp tất cả các nhân viên dự án xác định mục tiêu chất lượng của chính h và liên tục giám sát quá trình của họ theo các mục tiêu đó.

Khi chuẩn bị một kế hoạch như vậy cần quan tâm một số vấn đề sau:

a) Mục đích và công dụng của kế hoạch

Tất c các thành viên dự án phải hiểu tính quan trọng của kế hoạch đề xut, các chi tiết triển khai nó và các liên quan của nó tới mỗi thành viên dự án. Tất cả những điều này phải được chọn lọc trước khi bắt đu bất kỳ một hoạt động đánh giá nào.

Tính hữu dụng của kế hoạch này phải được chấp nhận và được hỗ trợ bởi tất cả các nhân viên dự án cũng như bởi các qun lý liên quan gián tiếp tham gia dự án hay quy trình đánh giá.

b) Ci tiến kế hoạch

Dự thảo kế hoạch phải được kiểm tra và cải tiến bởi người quản lý chịu trách nhiệm chung về đánh giá trong tổ chức. Nó phải được soát xét để chắc chắn rằng nó bao trùm chính xác các yêu cu đánh giá khác nhau, bao gồm:

· Đặc tả những mục tiêu đề ra đạt được như thế nào, và chúng được định lượng và đo như thế nào. Nó cũng nêu các phép đo này sẽ hỗ trợ quy trình đánh giá như thế nào,

· Đặc t các quản lý định lượng sẽ được thực thi như thế nào trong đánh giá sản phẩm phần mềm,

· Những mục tiêu chất lượng cụ thể,

CHÚ THÍCH: Chúng có thể là sản phẩm, quá trình hay thậm chí kích c liên quan.

· Phân loại các nhiệm vụ, gán trách nhiệm tương ứng (ví dụ, người chịu trách nhiệm thu thập dữ liệu, phân tích và phn hồi tới nhân viên dự án và qun lý),

· Xác định dữ liệu được thu thập, điều khiển và sử dụng như thế nào.

c) Nội dung kế hoạch

Nội dung của kế hoạch này phải bao trùm tất cả các hệ đo áp dụng cho các đặc tính của sản phm phần mềm.

Các mục tiêu được chp nhận trong kế hoạch phải được hỗ trợ bởi đặc tính chất lượng sản phm tương ứng, và cũng bởi sự lựa chọn tiêu chí chất lượng quy trình, các chuẩn được chọn, các phương pháp, kỹ năng của nhân viên, hỗ trợ của công cụ và qun lý dự án.

d) H trợ lập kế hoạch chi tiết

Để hỗ trợ lập kế hoạch cho dự án đánh giá, tất c các thông tin cụ thể hữu ích phải được đưa vào dự án. Các thông tin này bao gồm cả các mẫu kế hoạch và công nghệ đánh giá liên quan, chứa những thông tin cụ thể về:

· Kinh nghiệm lập kế hoạch dự án tương tự,

· Sử dụng cùng một công nghệ,

· Tiêu chuẩn của t chức và mô hình chất lượng,

· Sử dụng các phép đánh giá được khuyến nghị hay bắt buộc,

· Phép đo kiến thức, như thành phần dữ liệu, phương pháp đo, các công cụ, tn suất đo và điều kiện,

· Thiết lập mức phân hạng cụ thể.

7.2.3.2. Xúc tiến kế hoạch đánh giá định lượng

Để có được sự tin tưởng của các thành viên dự án về tính hữu dụng của kế hoạch và để khuyến khích họ tham gia tích cực vào việc triển khai, cần thực hiện một số việc sau nếu thích hợp:

· T chức một cuộc gặp mặt để giải thích về các vấn đề kỹ thuật của kế hoạch.

· Tổ chức các bài giảng về đánh giá chất lượng phần mềm.

7.2.3.3. Hỗ trợ các dự án đánh giá

Các chức năng hỗ trợ phải giám sát trạng thái triển khai của dự án đánh giá theo đúng tiến độ lịch trình.

Nếu có các vn đề được phát hiện, các hỗ trợ cần thiết phải được cung cấp đ giải quyết các vấn đề này với mục đích tích lũy kinh nghiệm cho sử dụng tương lai.

7.2.3.4. Thu thập các kết quả đánh giá

Các chức năng hỗ trợ phải thu thập các kết quả đánh giá tại cuối mỗi dự án đánh giá. Chúng phải được lưu giữ cho mục đích tham chiếu và sử dụng cho các dự án tương lai.

8. Thực hiện đánh giá

8.1. Tiến hành đo

Đối với phép đo, các phép đánh giá lựa chọn được áp dụng cho sản phm phần mềm. Kết quả là các giá tr nằm trong thang đánh giá của phép đánh giá.

8.2. So sánh với tiêu chí

Trong bước phân hạng, kết quả đo được so sánh với tiêu chí xác định trước (như trình bày trên Hình 5).

8.3. Đánh giá kết qu

Đây là bước cuối cùng của quy trình đánh giá phần mềm, một bộ các mức phân hạng s được tổng hợp. Kết qu là một công bố các giới hạn sản phm phần mềm đáp ứng các yêu cầu chất lượng. Sau đó, chất lượng tổng hợp được so sánh với các khía cạnh khác như thời gian và chi phí. Cuối cùng, quyết định qun lý bỏ sẽ được đưa ra dựa trên các tiêu chí quản lý. Kết qu là quyết định của ban quản trị chấp thuận hay loại b, đưa vào lưu hành hay không đối với sản phm phần mềm.

Các kết qu của đánh giá là quan trọng đối với các quyết định về các bước tiếp theo trong vòng đời phát triển phần mềm. Ví dụ, liệu có cn thay đổi những yêu cầu chất lượng, hay có cần thêm tài nguyên cho quá trình phát triển tiếp theo?

9. Các quá trình hỗ trợ

Các hoạt động này trợ giúp đánh giá bằng cách thu thập thông tin trong các công cụ và phương pháp đánh giá, 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à các hệ đo.

 

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. Quy trình đánh giá

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

5.1. Thiết lập mục đích đánh giá

5.1.1. Tổng quan

5.1.2. Mua sn phm

5.1.3. Cung cấp

5.1.4. Phát triển

5.1.5. Vận hành

5.1.6. Bảo trì

5.2. Xác định loại sản phẩm được đánh giá

5.3. Xác định mô hình chất lượng

6. Xác định đánh giá

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

6.1.1. Các loại phép đo

6.1.2. Các yêu cầu cho các phép đo

6.2. Thiết lập mức phân hạng cho các phép đánh giá

6.3. Thiết lập tiêu chí đánh giá

7. Thiết kế đánh giá

7.1. Tạo lập kế hoạch đánh giá

7.2. Các yêu cầu và khuyến nghị hỗ trợ đánh giá phần mềm

7.2.1. Tổng quan

7.2.2. Qun lý mức tổ chức

7.2.2.1. Lập kế hoạch sử dụng và cải tiến công nghệ đánh giá

7.2.2.2. Triển khai công nghệ đánh giá

7.2.2.3. Chuyển giao công nghệ sử dụng đánh giá

7.2.2.4. Đánh giá công nghệ sử dụng cho đánh giá

7.2.2.5. Quản lý kinh nghiệm

7.2.3. Hỗ trợ việc quản lý dự án

7.2.3.1. H trợ việc lập kế hoạch đánh giá

7.2.3.2. Xúc tiến kế hoạch đánh giá định lượng

7.2.3.3. Hỗ trợ các dự án đánh giá

7.2.3.4. Thu thập các kết quả đánh giá

8. Thực hiện đánh giá

8.1. Tiến hành đo

8.2. So sánh với tiêu chí

8.3. Đánh giá kết quả

9. Các quá trình hỗ trợ

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

Tìm kiếm

Thông tin Tiêu chuẩn Việt Nam TCVN8705:2011
Loại văn bảnTiêu chuẩn Việt Nam
Số hiệuTCVN8705:2011
Cơ quan ban hành
Người ký***
Lĩnh vựcLĩnh vực khác
Ngày ban hành...
Ngày hiệu lực...
Tình trạng hiệu lựcKhông xác định
Cập nhật4 năm trước