TCVN8708:2011

Tiêu chuẩn quốc gia TCVN 8708:2011 về 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 TIÊU CHUẨN QUỐC GIA 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 In f ormation technology - Software product evaluation - Part 4: Process for acquirers Lời nói đầu TCVN 8708:2011 được xây dựng trên cơ sở ISO/IEC 14598-4. TCVN 8700: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ộ Kh o a 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 4: QUY TRÌNH CHO NGƯỜI MUA SẢN PHẨM In f ormation technology - Software Product Evaluation - Part 4: Process for acquirers 1. Phạm vi áp dụng Tiêu chuẩn này bao gồm các yêu cầu, khuyến nghị và hướng dẫn cho việc đo có hệ thống, đánh giá chất lượng sản phẩm phần mềm trong quy trình mua sản phẩm phần mềm đóng gói, sản phẩm phần mềm đặt hàng, hoặc thay đổi sản phẩm phần mềm sẵn có. Nó sử dụng mô hình chất lượng phần mềm mô t ả trong ISO/IEC 9126-1; và sử dụng quy trình mua sản phẩm được định nghĩa trong ISO/IEC 12207. Nó có thể được dùng kết hợp với ISO/IEC 12119. TCVN 8705:2011, TCVN 8706:2011 và ISO/IEC 14598-6. Các bước của quy trình đánh giá tương tự như TCVN 8705:2011, nhưng tình huống sử dụng thì hoàn toàn khác nhau. Trong trường hợp người mua hàng tin tư ở ng vào bên th ứ hai hay thứ ba để đánh giá, TCVN 8705:2011 được yêu cầu áp dụng. Trong trường hợp người mua hàng yêu cầu bên th ứ ba kiểm tra gói phần mềm đối với các yêu cầu chất lượng cho g ó i, th ì ISO/IEC 12119 có thể được áp dụng. Quy trình đánh giá mô tả trong tiêu chuẩn này cũng giúp đáp ứng các mục tiêu ra quyết định chấp nhận một sản phẩm đơn, hay lựa chọn sản phẩm trong số các sản phẩm khác. Quy trình đánh giá sản phẩm có thể được biến đổi cho phù hợp với bản chất và mức độ toàn vẹn của ứng dụng. Nó cũng khá mềm dẻo để áp dụng cho diện rộng các dạng và cách sử dụng sản phẩm phần mềm với chi phí h ợ p lý. Tiêu chuẩn này nhằm vào, nhưng không giới hạn, người quản lý dự án, kỹ sư hệ thống, nhân viên phát triển và b ả o tr ì phần mềm và người dùng có kế hoạch mua sản phẩm phần mềm, v à nhà cung cấp các sản phẩm như vậy. Sản phẩm phần mềm là mục tiêu của quy trình đánh giá trong ti ê u chuẩn này có thể được tích hợp vào hệ thống lớn hơn như một thành phần hoặc có thể sử dụng độc lập. Chúng được phân loại như sau: (a) Các sản phẩm phần mềm đóng gói thương mại; (b) Các sản phẩm phần mềm sẵn có được phát triển hoặc yêu cầ u cho các ứ ng dụng khác, hoặc cho dải rộng các ứng dụng chung; (c) Các sản phẩm phần mềm đặt hàng hay các sửa đổi từ các sản phẩm phần mềm sẵn có. Quy trình đánh giá được xác định trong tiêu chuẩn này cũng có kh ả năng áp dụng cho công cụ CASE; tuy nhiên việc đánh giá theo công cụ CASE được đưa ra trong ISO/IEC 14102. 2. Tài liệu viện dẫn Các tài liệu viện dẫn sau đây là cần thiết đ ể áp dụng tiêu chuẩn này. Đối với các tài liệu viện dẫn ghi năm công bố thì áp dụng b ả n đư ợ c nêu. Đối với các tài liệu viện dẫn không ghi năm công bố thì áp dụng phiên bản mới nhất, bao gồm c ả các sửa đổi, bổ sung (nếu có). [1] TCVN 8702:2011 - Công nghệ thông tin - Ch ấ t lượng sản phẩm phần mềm - Phần 1: Các phép đánh giá chất lượng 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á chất lượng trong. [3] TCVN 8704:2011 - Công nghệ t hông tin - Chất lượng sản phẩm phần mềm - Phần 3: Các phép đánh giá chất lượng sử dụng. [4] TCVN 8705:2011 - Công nghệ thông tin - Đánh giá sản phẩm phần mềm - Phần 1: Tổng quan. [5] TCVN 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á. [6] 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. [7] TCVN ISO 9001:2008 - Hệ th ố ng quản lý chất lượng - Các yêu cầu. [8] ISO/IEC 12119 - In f ormation technology - Software pagkages - Qual i ty 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). [ 9] 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). [10] ISO/IEC 9126-1 - Software engineering - Product q u ality - 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). [11] ISO/IEC 14598-6 - Information technology - Software product evaluation - Part 6: Documentation of evaluation modules. (ISO/IEC 14598-6 - Công nghệ thông tin - Đánh giá sản phẩm phần mềm - Phần 6: Tài liệu c á c m ô đun đánh giá). [12] ISO/IEC 15026 - Information technology - System and software integrity l evels (ISO/IEC 15026 - Công nghệ thông tin - Các m ứ c toàn vẹn hệ thống và phần mềm). [13] ISO/IEC 14102 - Information technology - Guideline for the evaluation and selection of CASE tools (ISO/IEC 14102 - C ô ng nghệ thông tin - Hướng dẫn đánh giá và lựa chọn c á c công cụ CASE). [ 14 ] ISO/IEC 15504-8 - Information technology - Process assessment - Part 8: An exemplar process assessment model for IT Service management (ISO/IEC 15504-8 - Công nghệ th ô ng tin - Đánh giá quy trình - Phần 8 - Mô hình đánh giá quy trình mẫu cho quản lý dịch vụ IT). 3. Thuật ngữ và định nghĩa 3.1 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.2 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ư I ĩ 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 k há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 các tiêu chuẩn t ừ TCVN 8705:2011 đến TCVN 8708:2011 thực thể liên quan là sản phẩm phần mềm. 3.3 Ch ấ t l ư ợng ngoài (exte rn al 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.4 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à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ụn g tr ong ISO 9241-11. Trong các tiêu chuẩn từ TCVN 8705:2011 đ ế n TCVN 8708:2011 thuật ngữ tính khả dụng được sử dụng cho đặc tính chất l ượn g phần mềm mô t ả trong I SO/IEC 9126-1. 3.5 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ê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: Thuật ngữ “ chất lượng trong ” , được sử dụng trong các tiêu chu ẩ n t ừ TCVN 8705:2011 đến TCVN 8708:2011 trá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 8 402. 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.6 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ó t hể 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ộ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 s ả n xuất. Chúng là các hệ đo gián tiếp của các thu ộ c t í nh. 3.7 C ô ng cụ CASE (CASE tool) Sản phẩm phần mềm có thể trợ giúp các kỹ sư phần mềm bằng cách cung c ấ p hỗ trợ tự động cho các hoạt động vòng đời phần mềm như định nghĩa trong ISO/IEC 12207:1995. CHÚ T HÍCH 1 : C ô ng cụ CASE có t hể cung cấp hỗ tr ợ trong ch ỉ các l ĩ nh vực chức năng được ch ọ n hoặc trong nhiều dạng k há c nhau của các l ĩnh vực chức năng. CHÚ THÍCH 2: Cô ng cụ CASE có Thể được s ử dụng trong các một loạt chế độ: • Như các công cụ độc lập; trong trư ờ ng hợp này , ch ỉ có t í nh tương t h í ch với các phần tử môi trường ph ả i được xác định . • Trong c á c nh ó m nhỏ kết nối trực tiếp với các nhóm k hác; có thể giả thiết việc tích hợp đ ã được x á c đ ị nh trước, có thể độc quy ề n; • Khi xu ất hiện cơ c ấ u l ớ n hơn của SEE; trong tr ườ ng hợp này khả n ă ng của công cụ sử dụng các dịch v ụ li ê n quan của cơ c ấ u phải được xác định. 3.8 Đánh giá chất lư ợ ng (quality evaluat i on) Kiểm tra một c á ch hệ thống giới hạn mà thực thể có khả năng t hực hiện các yêu cầu x ác định. CHÚ T H Í 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ư kh i 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.9 Đo (measure - verb.) Thiết lập phép đo. 3.10 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.11 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 t huộ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.12 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.13 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.14 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.15 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.16 Hợp đồng (contract) Thỏa thuận ràng buộc giữa hai chủ thể, đặc biệt có thể thi hành bằng luật, hoặc thỏa thu ậ n nội bộ tương tự hoàn toàn trong tổ chức, để cung cấp dịch vụ phần mềm hoặc cho cung cấp, phát triển, sản xuất, v ậ n hành, hoặc b ả o tr ì sản phẩm phần mềm. 3.17 Ki ể m định (audit) Thiết lập bởi người có th ẩ m quy ề n cho mục đ í ch cung cấp đánh giá độc lập của các s ả n phẩm phần mềm và các quá trình đ ể đánh giá tuân thủ theo các yêu cầu. 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ỹ t huậ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 Mua sản phẩm (acquisition) Quá trình đạt được hệ thống, sản phẩm phần mềm hay dịch vụ phần mềm 3.21 Mục cấu h ì nh (configuration item) Thực thể trong cấu hình thỏa mãn chức năng sử dụng cuối và có thể được xác định duy nhất tại điểm tham chiếu cho trước. 3.22 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. C HÚ 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 nh u 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.23 Mức toàn vẹn (integrity level) Biểu hiện dải các giá trị của đặc tính của mục cần thiết để bảo trì các r ủ i ro hệ thống trong các giới hạn chấp nhận được. Đối với các mục thực hiện các chức năng giảm nhẹ, đặc t í nh là tính tin cậy m à mục được ch ọ n phải th ự c hiện ch ứ c năng giảm nhẹ. Đối với các mục mà sự cố có thể d ẫ n đến nguy hiểm, đặc tính là giới hạn trên tần suất của sự cố. 3.24 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.25 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 m u a sản phẩm có thể là: người mua , kh á ch hàng, ch ủ s ở hữu, người sử d ụng. 3.26 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.27 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.28 Ng ư ời vận hành (operator) Tổ chức vận hành hệ thống. 3.29 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.30 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.31 Phần mềm có sẵn (existing software) Phần mềm đ ã được phát tri ể n và sẵn có; có khả năng sử dụng như nguyên b ả n hay với thay đổi; và được cung cấp bởi nhà cung c ấ p, người mua sản phẩm, hay người thứ ba. 3.32 Ph ầ n mềm đóng gói th ư ơng mại (commercial-of-the shelf software COTS) Phần mềm được xác định b ằ ng nhu cầu thị trường, có khả năng thương mại, và sự phù hợp của chúng đ ể sử dụng được chứng minh bằng đại chúng người sử dụng thương mại. 3.33 Ph ầ n mềm khách hàng (custom software) Phần mềm được phát triển cho ứng dụng cụ thể từ đặc tính kỹ thuật yêu cầu người sử dụng. 3.34 Ph ầ n sụn (firmware) Tổ hợp của thiết bị phần cứng v à các lệnh máy tính hoặc d ữ liệu máy tính được nạp như phần mềm ch ỉ đọc ra trong thiết bị ph ầ n cứng. Phần mềm không thể dễ dàng sửa đổi dư ớ i sự điều khiển của chương trình. 3.35 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.36 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 t huộ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.37 Sản phẩm đóng gói (off-the-shelf product) Sản phẩm đã được phát triển và sẵn sàng; có khả năng sử dụng như nguyên b ả n hay v ớ i thay đổi. 3.38 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 t rung 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.39 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.40 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.41 Sự xác minh (veri fi cation) 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 á t r ì 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.42 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 t hô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.43 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 t hứ t ự phù hợp với mộ t bộ được sắp x ế p của các đi ể m thang đ á nh giá; thang kh o ả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ệ k hô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 t hang khoảng và thang t ỷ l ệ cung cấp dữ liệu định lượng. 3.44 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.45 Th u ộc tính (attribute) Đặc tính vật lý đo được hay đặc tính lý thuyết của thực thể. 3.46 Vạch ranh giới (baseline) Phiên b ả n nâng cấp ch í nh thức của các mục cấu h ì nh, không phụ thuộc vào phương tiện, được chính thức thiết kế và ấn định tại thời điểm cụ thể trong vòng đời mục cấu hình. 3.47 Yêu cầu đối v ớ i đề nghị - đ ấu thầu (request for proposal - tender) Tài liệu được sử dụng bởi người mua hàng như phương tiện thông báo ý định của nó tới nhà thầu tiềm năng để mua hệ thống cụ thể, s ả n phẩm phần mềm hay dịch vụ phần mềm. 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 Các hoạt động c ủ a quy trình mua sản phẩm (xác định trong ISO/IEC 12207) được tổng hợp trong phần dưới đây, và được kết hợp cùng với các hoạt động trong quy trình đánh giá chung (xác định trong TCVN 8705:2011) trong điều 4 và 5. Đi ề u 4 tập trung vào ứng dụng của đánh giá chất lượng sản phẩm c uố i khi mua các sản phẩm đóng gói COTS. Điều 5 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 đặt hàng hoặc sửa đổi phần mềm có sẵn . a) Khởi đầu - xác nhận các yêu cầu phần mềm c h o sản phẩm được mua , kế hoạch mua sản phẩm, và chiến lược cũng như tiêu chuẩn chấp nhận; b) Chuẩn bị yêu cầu đề nghị (đ ấ u thầu) - đặc t ả và lập tài liệu của các yêu cầu mua sản phẩm; c) Chuẩn bị và cập nhật hợp đồng - lựa chọn nhà cung cấp, chuẩn bị và đàm phán hợp đồng, và quản lý các thay đổi hợp đồng; d) Giám sát nhà cung cấp - các hoạt động đánh giá được tạo lập trong quá trình thực hiện hợp đồng đưa đến việc chấp thuận và giao sản phẩm phần mềm; e) Chấp thuận và hoàn thành - các hoạt động được thực hiện trong quá trình ch ấ p thuận và giao sản phẩm phần mềm cuối cùng. Lưu ý rằng quy trình đánh giá chung được xác định trong các tiêu chuẩn từ TCVN 8702:2011 đến TCVN 8704-4:2011 không được định nghĩa như một quy trình trong ISO/IEC 12207, nhưng chức năng cơ bản tương đương với phần “kiểm tra ” của chu trình kế hoạch kiểm tra (PDCA) được thực hiện trong mỗi quá trình vòng đời. Tuy nhiên, quy tr ì nh đánh giá chung có thể được thực hiện trong bất k ì quá trình n à o của ISO/ I EC 12207 (tức là phát triển, duy tr ì , mua sản phẩm, ph ê chuẩn); do đó có các mức độ khác nhau của khái niệm “quá trình ” được sử dụng trong ISO/IEC 12207. Phân biệt này là quan trọng khi thực hiện quy tr ì nh đánh giá chung. Người mua sản phẩm cần xác định cả quy trình đánh giá và quy trình mua sản phẩm mà họ sẽ tuân theo đ ể đưa ra các yêu cầu đánh giá trong quy trình mua sản phẩm. Trong bối c ả nh phát triển hệ thống lớn, các hoạt động mua sản phẩm và đánh giá tuân theo nhu cầu được t í ch hợp với các hoạt động ph á t triển và tích hợp khác, v à được x á c định trong kế hoạch đo dự án như được đưa ra trong TCVN 8705:2011; tức là các xem xét th ự c hiện mua sản phẩm c ụ thể cho đánh giá bao gồm các v ấ n đề sau: - Đặc tả yêu cầu phần mềm yêu cầu đánh giá có thể tạo lập cơ sở cho các yêu cầu mua sản phẩm cần cho yêu cầu đề ngh ị - đấu thầu; - Các hoạt động đánh giá sơ bộ riêng có thể cần thiết để chọn t rước các sản phẩm phần mềm và người cung cấp; - Các yêu cầu thông tin nhà cung cấp và sản phẩm cho đánh giá cần phải được xác định trong các yêu cầu mua sản phẩm hoặc trong quá trình chuẩn b ị hợp đ ồ ng; - Các hoạt động đánh giá c ó thể được thực hiện như một phần của đánh giá đề xuất, trong quá trình gi á m sát thực hiện hợp đồng, như một phần của quá trình phát triển sản phẩm, một phần của ch ấ p thuận sản phẩm chính thức, hay sau khi giao 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 Điểm đầu tiên để xác định các yêu cầu đánh giá cho phần mềm mục tiêu bắt đầu với các yêu cầu hệ thống t ổ ng thể. Các yêu cầu hệ thống xác định người sử dụng, mục đích người sử dụng, các nhiệm vụ và đặc tính, bao gồm cả môi trường trong đó sản phẩm được sử dụng, bổ sung vào các yêu cầu chức năng v à các yêu cầu khác cho sản phẩm hoặc hệ thống. Chúng tạo thành cơ sở cho thiết kế cấu trúc hệ thống tiếp theo, đặc t ả các yêu cầu phần mềm, và thiết kế cấu trúc phần mềm. Các yêu cầu luật pháp và quy định liên quan cần được xác định trong giai đoạn này vì chúng tác động đến tính chính xác và quy cách của quy trình mua sản phẩm và đánh giá. Trong phân tích và thiết kế các yêu cầu hệ thống, các yêu cầu hệ thống được ấn đị nh cho các mục cấu hình phần cứng và phần mềm, và cho các vận hành của người sử dụng bao gồm các thủ tục hệ thống. Các hoạt động thiết kế trong vòng đời phát triển hệ thống đưa đến các quyết định tiếp theo để mua hoặc tái sử dụng các sản phẩm phần mềm đóng gói. Một số công việc đánh giá thực sự là một phần của các hoạt động thiết kế này, vì rằng nó đóng vai trò trong quyết định thiết lập quy trình. Đánh giá các sản phẩm phần mềm được mua được thực hiện riêng rẽ. Trong quá trình tích hợp hệ thống v à kiểm tra sản phẩm cuối cùng, các mục cấu hình phần mềm được tích hợp với các phần mềm khác, và với các mục cấu hình phần cứng (xem ISO/IEC 12207). Hình 1 tr ì nh bày ngữ cảnh kỹ thuật hệ thống lớn cho đánh giá v à mua sản phẩm. Các ứng viên cho quá trình sử dụng và mua sản phẩm là sản phẩm phần mềm có thể được tích hợp vào hệ thống lớn hơn như các thành phần hoặc chúng c ó th ể được sử dụng độc lập. Ch ú ng được ph â n loại như sau: a) Các sản phẩm phần mềm đóng gói thương mại; b) Các s ả n phẩm phần mềm có sẵn được phát triển hoặc mua cho các ứng dụng khác, hoặc cho một d ả i rộng các ứng dụng chung; c) Các sản phẩm phần mềm khách h à ng đặt hoặc sửa đổi từ các sản phẩm phần mềm có sẵn. Hình 1 - Ngữ cảnh kỹ thuật hệ thống cho đánh giá và mua sản phẩm phần mềm Trong trường hợp các mục cấu hình phần mềm được tích hợp thành hệ thống lớn hơn, các yêu cầu phần mềm ph ả i được xác định cho t ừ ng mục. Trong các trường hợp khác, các mục cấu hình hệ thống và phần mềm đồng nhất, và có thể được xem xét tương đương. Các mục cấu hình phần cứng được mua có thể chứa phần mềm như hệ đi ề u h à nh nằm trong phần sụn (như ROM, PROM...). Khi phần mềm đang có s ẵ n tạo thành một ph ầ n nguyên vẹn của phần cứng th ì theo cách như vậy nó thư ờ ng cần được đánh giá với các mục cấu hình phần cứng. 4.2.2 Các mức yêu cầu tính toàn vẹn Nếu phần mềm trong tình trạng đối mặt v ớ i nguy cơ về tính an toàn, an ninh, rủi ro về tài chính, môi trường và xã hội của hệ thống trong các giới hạn cho phép thì mức độ toàn vẹn yêu cầu của n ó phải được thiết lập và được soạn thảo chính xác trước khi mua hàng và đánh giá. Hướng dẫn cho quá trình xác định mức toàn vẹn được đưa ra trong ISO/IEC 15026. Mức toàn vẹn đạt được xác định phần mềm được gắn kết với quy trình đánh giá như thế nào. 4.2.3 Đặc tả các yêu cầu phần mềm Các yêu cầu phần mềm phải được định nghĩa sử dụng mô hình chất lượng xác định thích hợp. Đ ể đạt được mục đích này phải sử dụng mô hình chất lượng và các định nghĩa trong ISO/IEC 9126-1, trừ phi có lí do đặc biệt mới sử dụng mô h ì nh khác. Mô h ì nh n à y xác định sáu loại chủ yếu các đặc tính của phần mềm sử dụ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 sẽ được chia nh ỏ thành các đặc tính nhỏ có các thuộc tính đo được hoặc đánh giá được. Các yêu cầu phải được xác định trong phạm vi các phép đánh giá ngoài (các phép đánh giá ngoài được xác định trong TCVN 8702:2011) liên hệ trực tiếp với các nhu cầu của người sử dụng và phải được soạn thảo trong đặc t ả yêu cầu. Soạn thảo nhu cầu người sử dụng có thể thay đổi từ việc tạo lập danh sách không ch í nh thức các yêu cầu chức năng và hiệu năng yêu cầu đến việc chuẩn bị đặc tả yêu cầu hoàn ch ỉ nh cho sản phẩm (hoặc hệ thống nếu sản phẩm được gắn vào). Đặc tả yêu cầu khi đó có thể tạo cơ sở cho các yêu cầu mua sản phẩm sử dụng trong giai đoạn mời thầu trong quy trình mua sản phẩm và là nền tảng cho đánh giá sản phẩm tiếp theo. 4.2.4 Các đánh giá đượ c thực hiện bởi các bên khác Phạm vi của quy trình đánh giá hiện thời có thể được giảm đ i thông qua các truy cập tới các kết quả các hoạt động đánh giá được thực hiện bởi bên thứ hai hoặc thứ ba nếu như các kế t quả đ á ng tin cậy . Các hoạt động đánh giá như vậy có thể bao g ồ m các chứng chỉ đã có trư ớ c, các đánh giá sản phẩm và/hoặc các đánh giá quy trình. Ví dụ: - Các quá trình kỹ thuật phần mềm cho quá trình phát triển sản phẩm có thể được chuẩn hóa để thỏa mãn các yêu cầu của ISO/IEC 12207, ISO 9000-3, hoặc các tiêu chuẩn khu vực khác; - Hệ thống chất lượng của n hà cung cấp từ đó phần mềm được phát tri ể n có thể được chứng nhận với các yêu cầu TCVN ISO 9001:2008 bởi bên thứ ba; - Sản phẩm phần mềm có thể được đánh giá bởi bên thứ hai hoặc thứ ba với các yêu cầu của TCVN 8706:2011 hoặc I SO/ I EC 12119; - Kh ả năng quá trình phần mềm của nhà cung cấp đối với việc phát triển sản phẩm được chấp thuận có thể được đánh giá bởi bên thứ ba với ISO/IEC 15504-8; - Phần mềm có thể được đánh giá chức năng như một phần của giai đoạn phát triển hệ thống lớn hơn; - Sản phẩm phần mềm có thể đã được đánh giá trước đó cho các ứng dụng khác với các y ê u cầu t í nh toàn vẹn khác; - Các đánh giá sản phẩm có thể đã được thực hiện bởi các bên khác trong tổ chức thông qua các hoạt động đánh giá chính thức hoặc không chính thức. Các chi phí thêm và thời gian yêu cầu đ ể đạt được và làm sáng tỏ các kết quả đánh giá ngoài cho ứng dụng mục tiêu có thể ản h hư ở ng đến tính khả thi của phương pháp này. Nó có thể v ẫ n c ò n c ầ n tư vấn với bên đánh giá hoặc người cung cấp để đạt được sự tin cậy thích đ á ng trong kết qu ả của các bên khác. CHÚ THÍCH: Kết quả đánh giá c ủ a quá trình kỹ thuật phần mềm của nh à cung cấp, hệ thống chất lượng của nhà cung cấp, hoặc khả năng của nhà cung cấp riêng rẽ là không đủ tiêu c h u ẩ n đ ể th ể hiện rằng sản phẩm phần mềm bao hàm các đặc tính chất lượng yêu cầu. Các phương pháp đánh giá chất lượng khác (như các p h ư ơn g pháp đặ c biệt đo các nhân t ố và thuộc tính của chất lượng thích hợp với các y êu cầu của ng ườ i dù ng cuối) c ầ n phải thực hiện. 4.3 Hiệu chỉnh Quy trình đánh giá có thể được áp d ụ ng cho d ả i rộng các yêu cầu quy trình mua sản phẩm, các yêu cầu tính toàn vẹn, và mục tiêu của bên đánh giá. V í d ụ: - Người mua g ó i phần mềm có thể mong muốn đánh giá g ó i phần mềm chỉ sử dụng ISO/IEC 12119; - Người mua sả n phẩm phần mềm có thể sử dụng TCVN 8706:2011 cho đánh giá độc lập; - Khách hàng nhỏ hoặc cá nhân mua sản phẩm có thể yêu cầu quy trình đánh giá chính thức với tài liệu đánh giá tối thiểu; - Đ ố i với phần mềm tiêu d ùng mục tiêu quy trình đánh giá sản phẩm có thể đơn giản là chọn, kiểm tra và mua một sản phẩm từ một số các sản phẩm tương tự. Quy trì n h mua sản phẩm chính thức khi đó được giảm xuống để rõ ràng việc mua sắm, và không bao g ồ m phần chuẩn bị hợp đồng. Quy trình đánh giá phải có tính mềm dẻ o để kết hợp tính duy nhất của ứ ng dụng, tránh các việc không cần thi ế t hoặc công việc vô giá trị, và cung cấp ý nghĩa thực tiễn trong thiết lập độ tin cậy cần thiết cho phần mềm. Mức độ toàn vẹn yêu cầu của phần mềm xác định phần lớn tính nghiêm ngặt và hợp thức của quy tr ình đánh giá. Quy trình mua sản phẩm cũng có thể được hiệu chỉnh như cho quy trình đánh giá sử dụng hướng dẫn hiệu chỉnh đưa ra trong ISO/IEC 12207 và mức độ toàn vẹn yêu cầu cho sản phẩm phần mềm cụ thể được yêu cầu. Việc m u a các hệ thống phần mềm hoàn ch ỉ nh với các yêu cầu tính toàn v ẹ n cao sẽ thường dẫn đến một bộ đầy đ ủ các hoạt động và nhiệm vụ mua sản phẩm, cùng với các công việc và nhiệm vụ của quy trình cung cấp tương ứng, như ch ú ng đư ợ c đưa ra trong ISO/IEC 12207. Nói chung, n ế u mức độ toàn vẹn tăng, tính nghiệm ngặt và s ố lượng các hoạt động và nhiệm v ụ cùng đi với quy trình mua sản phẩm cũng tăng. 5 Đánh giá trong quy trình mua sản phẩm phần mềm đóng gói Quy trình chung đánh giá sản ph ẩ m phần mềm được xác định trong Tiêu chu ẩ n TCVN 8705:2011 bao g ồ m bốn bước chính, đặc biệt chúng được thực thi và hoàn thiện tập trung vào đánh giá chất lượng sản phẩm cuối khi mua sản phẩm đóng gói trong Tiêu chuẩn này. Tuy nhiên, điều đó không cản tr ở đánh giá các sản phẩm trung gian đối với các đặc tính chất lượng x á c định. Do đó, chi tiết việc thực hiện các bước khác nhau, nhưng không mâu thuẫn, với các chi tiết mô tả trong tiêu chuẩn TCVN 8705:2011. Quy trình đánh giá được t ổ ng kết trong bảng 1 dưới dạng các bước và các nhiệm vụ chính, cũng như các đ ầu vào và đầu ra. Bảng 1 - Quy trình đánh giá khi mua sản phẩm đóng gói Đ ầ 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 n ghi ê 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 g iá Quy trình đánh giá phải t hi ế 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: • sản phẩm phần mềm sẽ được sử dụng cho ứng dụng cụ thể, cho một tập các ứng dụng cụ thể, hoặc cho một dải chung các ứng dụng hay không; • 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: - phân biệt giữa các yêu cầu bắt buộc v à t ù y chọn; - 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 à c u ng 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; k) Quy trình mua hàng, và th ô ng tin yêu cầu từ nhà cung cấp trong quá trình đấu thầu; I) Các đánh giá được thực hiện bởi bên th ứ hai hoặc thứ ba k há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 t i ết và phức tạp của các đặc t ả yêu cầu đ á nh giá t rự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 t i ế p theo t rong 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 t rư ớ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 ôn g 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 g i á 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. 5.2.1 Lựa chọn các phép đánh giá Đặ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 d anh 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; i) Trường hợp kiểm tra mẫu được sử dụng; 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 t rê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; - các danh sách thiếu sót của sản phẩm và thông tin liên quan (thông thư ờ ng đưa trên các trang Web). 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 ươn g 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ột bộ các hoạt động, toàn bộ, có cung cấp b ả o đảm ở m ứ c độ ch ấ p nhận được sao cho có mức bao hàm toàn thể cho các đặc tính chất lượng phần mềm liên quan hay không; - 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 h i ệ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; b) Báo c á o đánh giá có xác định phiên b ả n của sản phẩm phần mềm được đánh giá, giới hạn của đánh giá, tiêu chuẩn quyết định được sử dụng, và các kết luận đạt được 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 k hông; d) Bên đánh giá có đủ trình độ t hí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; b) Bất kì đi ề u kiện nào liên quan v ớ i việc cung cấp truy cập vào bất kì thông tin mật và độc quyền nào; 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 t rì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 ng u y ê 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; I) Các điểm quy ế t định trong quy trình đánh giá mà n ó xác định k hi nào và tại sao đánh giá phải được xem như hoàn thành (tức là tiêu chu ẩ n ch ấ p nhận hoặc loại bỏ) và phải được dừng lại; 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 1459 8 -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ụ t h ể . 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ụ t hu ộ c l ẫ n nhau cao giữa các ph ươ ng pháp đánh giá kh á c nhau, tức là th ô ng t in 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 ă n g l ê n Do đ ó , kế hoạch đánh giá c ó v ẻ như sẽ b ị t hay đổ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ổ s ung , một khi đ á nh gi á ti ế n triển. CHÚ THÍCH 3: Đánh gi á các sản phẩm phần mềm c ó t h ể được thực hiện trong các giai đoạn tại các đi ể m khác nhau tr ong v ò ng đời phá t triển, hoặc t ấ t c ả cùng một lúc , tại một điểm trong vòng đời. Các cá nhân hay nhóm khác nhau c ó th ể c ó t rách nhiệm t hực hiện các phần khác nhau của đánh giá. Khi đánh giá được ho à n thành trong các giai đoạn, các bước c ủ a ho ạt động đánh giá được nhắc l ạ i trên mỗi giai đoạn cho đến khi kh ô ng c ò n công việc nào y ê u c ầ u . 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 đánh giá theo các thủ tục được xác định trong kế hoạch đánh giá; - 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 q u an, 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; - yêu cầu gốc không phải là bắt buộc và thiếu sót có thể được chấp nhận; - 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 à k hả th i 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; - ảnh hư ở ng tới thiết kế ứng dụng, ngân sách, và lịch tr ì nh thời gian; - 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. Có khả năng rằng đánh giá có thể đưa đến quyết định không ch ấ p nh ậ n sản phẩm để sử dụng, hoặc quy ế t định không tuân theo các yêu cầu đánh giá , và trong khuyến ngh ị đánh giá lại các gi ả i pháp thay thế khác. Quyết định cuối cùng là mua hoặc kh ô ng mua. 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. 6.3 Bước 3 - Thiết k ế đánh giá 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 - I nformation Technology - Software Product Evaluation - Part 1: General Overview. [2 ] IS O 14598-2:1998 - In formation Technology - Software Product Evaluation - Part 2 : Planning and management. [ 3] ISO 14598-4: 1999 - Information Technology - Software Product Evaluation - Part 4: Process for acquirers. 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.2 Các mức yêu cầu tính toàn vẹn 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.2 Lựa chọn phương 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.3 Bước 3 - Thiết k ế đánh giá 6.4 Bước 4 - Thực hiện kế hoạch Thư mục tài liệu tham khả o