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
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ị, 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 1: TỔNG QUAN
Information technology - Software product evaluation - Part 1: General overview
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 chuẩn 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 sản 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 phẩm 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 phẩm phần mềm. Các kết quả đánh giá qua áp dụng các tiêu chuẩn từ TCVN 8705:2011 đến TCVN 8708:2011 có thể được sử dụng bởi người quản lí và người phát triển/ người bảo trì để đo tuân thủ các yêu cầu và thực 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 sản phẩm của dự án.
CHÚ THÍCH: Phần lớn các hướng dẫn 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 sản phẩm phức tạp khác.
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 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á.
[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 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).
[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 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ý chất lượng và đảm bảo chất lượng - Từ vựng chất lượng).
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 cầu á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 cầu thực tế có thể chưa được đưa trong tài liệu.
3.3. Chất 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 cầu đượ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 phẩm 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. Chất 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ànvà 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. Chất lượng trong (internal quality)
Tổng hợp các thuộc tính của sản phẩm xác định khả năng của nó để thỏa mãn các yêucầuđãđượccông bố và ám chỉ khi sử dụng dưới các điều kiện xác định.
CHÚ THÍCH 1: Thuật ngữ “chất lượng trong”, được sử dụng trong các tiêu chuẩn từ TCVN 8705:2011đếnTCVN8708:2011trái ngược với“chất lượng ngoài”, về cơ bản có cùng ý nghĩa với như “chất 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 chuẩn 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 chất 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ộctính chất lượng phần mềm và ước lượng các thuộc tính của quá trình sản 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 cầu 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 phẩm được phát triển cho người sử dụng không cụ thể, như phần 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 sản phẩm 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 mềm
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à sản phẩm là một phần của nó.
CHÚ THÍCH 1: Hệ thống bao gồm bất kì phần cứng, phần mềm liên kết nào (kể cả phần mềm của khách hàng hoăc phần mềm đó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 chất lượng gần với các mục tiêu cơ bản của thiết kế.
3.15. Hệ đo trong(internal measure)
Hệ đo nhận đượ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ờ tất cả đều làđo lường trong được tạo trong bản 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)
Tổng 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ỹ thuật đá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)
Điểm 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 phần mềm 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ợp có thể 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 triển”.
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 phẩm để 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 phẩm 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 phẩm 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ụng có thể bao gồm người vận hành, người nhận kết quả của phần mềm, hoặc người phát triển, hoặc người bảo trì phần mềm.
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. Phần 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 mềm 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 phẩm 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 phần 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 sản phẩm trung gian, và các sản phẩm 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 phẩm phần mềm 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 sản 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 kiểm tra kết quả của hoạt động cho trước để xác định việc tuân theo các yêu cầu 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 triển, xác nhận liên quan đến quá trình kiểm tra sản phẩm để xác định việc tuân theo các nhu cầu người sử dụng.
CHÚ THÍCH 2: Xác nhận thông thường được thực hiện trên sản phẩm cuối dưới các điều kiện vận 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: Nhiều 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 điểm thang đánh giá; thang khoảng phù hợp với thang đánh giá được sắp xếp với các điểm 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 cấp dữ liệu định lượng.
3.36. Thất bại (failure)
Kết thúc khả năng của sản 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ể.
Để đá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 phần mềm
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 sản 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à bảo đảm rằng sản phẩm 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 bảo trì phần mềm).
Mục đích của việc đánh giá các sản phẩm trung gian có thể là:
·Quyết định chấp nhận một sản 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 sản phẩm này sang quá trình tiếp theo;
·Dự báo hay ước lượng chất lượng sản phẩm cuối cùng;
·Thu thập thông tin về các sản phẩm trung gian để điều khiển và quản 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 phẩm;
·Quyết định thời điểm phân phối sản phẩm;
·So sánh sản phẩm với các sản phẩm 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 phẩm;
·Quyết định thời điểm nâng cấp và thay thế sản phẩm.
Chấtlượng sản phẩm phần mềm có thể được đánh giá trong cấu trúc chất lượng xác định trong suốtcá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 sản 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 phẩm bắt đầu được phát triển, mục tiêu của các yêu cầu chất lượng xác định là bảo đảm sản phẩm phù hợp với các nhu cầu công bố và mặc nhiên của người sử dụng.
Khi mua sản phẩm phần mềm, đánh giá có thể được sử dụng để so sánh các sản 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á sản phẩm phần mềm để đảm bảo các sản phẩm 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 sản phẩm, hoặc bằng cách so sánh với các sản phẩm 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 phẩm toàn bộ có thể khác với các thành phần khác nhau, và có thể yêu cầu 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ầukhông cần thiết được loại bỏ. Người phát triển cần đánh giá sản phẩm 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 chất lượng trong cho các sản 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 bảo 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 sản 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 sản 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.
Chất lượng sử dụng làảnh hưởng kết hợp của các đặc tính chất 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 chất 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ể xuất 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 cải tiến chất lượng ngoài, do đó trợ giúp một quá trình cải 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 sản phẩm 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ả của phần 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 sản phẩm trong phát triển, độ dài đường dẫn có thể được đo dựa vào các sản phẩm 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à rất 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 chất 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 phẩm 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ư chất 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 phẩm phần mềm ảnh hưởng tới khả năng đáp ứng những nhu cầu 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 sản phẩm 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 chất 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.1. Lựa chọn các phép đánh giá
Điều quan trọng là các phép đo sản phẩm 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.Cần thiết lập các phép đánh giá liên kết đến các đặc tính của sản phẩm 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 sản 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 cải 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 sản phẩm 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 cậy 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 cầu 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ó chất 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 bằng 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 phẩm đang tồn tại hoặc sản 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 xấu là mốc cho sự chấp nhận của người sử dụng, trong trường hợp sản phẩm 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 chuẩn bị thủ tục cho việc này, với tiêu chí riêng cho các đặc tính chất 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 sản phẩm phần mềm trong một môi trường cụ thể.
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 chuẩn 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 triển 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 chất 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 triển 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 tốt nhất 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ẽ quản 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ó phải được tạo lập và triển khai. Kế hoạch phải bao gồm:
a) Chuẩn 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, bảo 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à cải 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 cải 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ôngnghệ đánhgiá theokếtquả 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 lấy 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 chuẩn 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ảixem 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 với 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:
·Chuẩn 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ợ.
·Chuẩn 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) Triển 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 thập 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ácnhận 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ínhhiệu quả của đánh giá phần mềm tổng 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 chuẩn hóa
Sử dụng công nghệ đánh giá phải được tiêu chuẩn 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 quản 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 để cải tiến chất lượng và sử dụng công nghệ đánh giá.
Những cải 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 chuẩn đó,
·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ỉ dẫn chất lượng của tổ chức.
·Duy trì các bản 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.
Để quản lý một dự án đánh giá, phải 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 cần 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ụ, chuẩn 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 bắt đầ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 chất 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 đề xuất, 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 quản lý liên quan gián tiếp tham gia dự án hay quy trình đánh giá.
b) Cải 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 cầu đá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à đonhư 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ầnmề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 thuthập dữliệu, phân tích và phản hồi tới nhân viên dự án và quản 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 phẩm phần mềm.
Các mục tiêu được chấp nhận trong kế hoạch phải được hỗ trợ bởi đặc tính chất lượng sản phẩm 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à quản 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ụ, tần 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 vấn đề đượ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ảđánhgiátạicuốimỗidự án đánh giá. Chúng phảiđược lưu giữ cho mục đích tham chiếu và sử dụngcho các dựántương lai.
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 phẩm 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 phẩm 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 quản 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 phẩm 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ó cần 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?
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 sản phẩm
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. Quản 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
Ý kiến bạn đọc
