Tiêu chuẩn Việt Nam TCVNISO/IEC90003:2016

TIÊU CHUẨN QUỐC GIA

TCVN ISO/IEC 90003:2016

ISO/IEC 90003:2014

KỸ THUẬT PHẦN MỀM – HƯỚNG DẪN ÁP DỤNG TCVN ISO 9001:2008 CHO PHẦN MỀM MÁY TÍNH

Software engineering – Guidelines for the application of ISO 9001:2008 to computer software

 

Lời nói đầu

TCVN ISO/IEC 90003:2016 hoàn toàn tương đương với ISO/IEC 90003:2014.

TCVN ISO/IEC 90003:2016 do Ban kỹ thuật tiêu chuẩn quốc gia TCVN/TC 176 Quản lý chất lượng và Đảm bảo chất lượng biên soạn, Tổng cục tiêu chuẩn Đo lường Chất lượng đề nghị, Bộ Khoa học và Công nghệ công bố.

 

Lời giới thiệu

Tiêu chuẩn này đưa ra hướng dẫn cho các tổ chức trong việc áp dụng hệ thống quản lý chất lượng cho việc mua, cung ứng, phát triển, vận hành và bảo trì phần mềm máy tính.

Tiêu chuẩn nhận biết các vấn đề cần được giải quyết và độc lập với công nghệ, mô hình vòng đời, quá trình phát triển, trình tự các hoạt động và cơ cấu tổ chức mà tổ chức sử dụng. Hướng dẫn và các vấn đề được nhận biết nhằm mang tính toàn diện chứ không phải đầy đủ. Trong trường hợp phạm vi các hoạt động của tổ chức bao gồm các lĩnh vực ngoài phát triển phần mềm máy tính, thì mối quan hệ giữa các yếu tố của hệ thống quản lý chất lượng của tổ chức cho phần mềm máy tính và các khía cạnh còn lại cần được làm rõ bằng văn bản trong tổng thể hệ thống quản lý chất lượng.

Điều 4, 5 và 6 và các phần của điều 8 của TCVN ISO 9001:2008 được áp dụng chủ yếu ở cấp “chung” trong tổ chức, mặc dù chúng có ảnh hưởng nhất định tới “cấp dự án/sản phẩm”, việc phát triển từng dự án hoặc sản phẩm có thể thích hợp với các phần liên quan của hệ thống quản lý chất lượng của tổ chức để phù hợp với các yêu cầu cụ thể của dự án/sản phẩm.

Trong toàn bộ TCVN ISO 9001:2008, từ “phải” được dùng để diễn đạt điều khoản bắt buộc giữa hai hay nhiều bên, từ “cần/nên” để diễn đạt khuyến nghị về các khả năng và từ “có thể” để chỉ chuỗi hành động được phép trong phạm vi các giới hạn của TCVN ISO 9001:2008. Tiêu chuẩn này đưa ra hướng dẫn để hỗ trợ việc hiểu cách thức các điều khoản của TCVN ISO 9001:2008 được áp dụng trong bối cảnh phần mềm.

Tổ chức có hệ thống quản lý chất lượng cho hoạt động phát triển, vận hành hoặc bảo trì phần mềm trên cơ sở tiêu chuẩn này có thể lựa chọn sử dụng các quá trình nêu trong ISO/IEC 12207 để hỗ trợ hoặc bổ sung cho mô hình quá trình theo TCVN ISO 9001:2008. Các nội dung liên quan của ISO/IEC 12207:2008 được viện dẫn trong từng điều của tiêu chuẩn này; tuy nhiên chúng không hàm ý các yêu cầu bổ sung so với các yêu cầu của TCVN ISO 9001:2008. Hướng dẫn thêm về việc sử dụng ISO/IEC 12207 có thể xem trong ISO/IEC 24748-3. Để có hướng dẫn bổ sung, xem các tài liệu viện dẫn được đưa ra đối với các tiêu chuẩn về kỹ thuật phần mềm của ban kỹ thuật ISO/IEC JTC 1/SC 7. Khi những tài liệu viện dẫn này cụ thể cho các điều của TCVN ISO 9001:2008, thì chúng sẽ được đưa vào sau phần hướng dẫn của điều đó. Khi chúng được áp dụng chung cho nhiều phần của điều, thì phần viện dẫn được nêu ở cuối của phần cuối cùng của điều đó.

Khi các nội dung được trích từ TCVN ISO 9001:2008, thì phần nội dung này sẽ được đóng khung để dễ nhận biết.

 

KỸ THUẬT PHẦN MỀM – HƯỚNG DẪN ÁP DỤNG TCVN ISO 9001:2008 CHO PHẦN MỀM MÁY TÍNH

Soft engineering – Guidelines for the application of ISO 9001:2008 to Computer software

1  Phạm vi áp dụng

1.1  Khái quát

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 1.1  Khái quát Tiêu chuẩn này quy định các yêu cầu đối với hệ thống quản lý chất lượng khi một tổ chức a) cần chứng tỏ khả năng cung cấp một cách ổn định sản phẩm đáp ứng các yêu cầu của khách hàng cũng như các yêu cầu của luật định và chế định thích hợp; và b) muốn nâng cao sự thỏa mãn của khách hàng thông qua việc áp dụng có hiệu lực hệ thống, bao gồm cả các quá trình để cải tiến liên tục hệ thống và đảm bảo sự phù hợp với các yêu cầu của khách hàng, yêu cầu luật định và chế định được áp dụng. CHÚ THÍCH 1: Trong tiêu chuẩn này, thuật ngữ “sản phẩm” chỉ áp dụng cho a) sản phẩm dự kiến cung cấp cho khách hàng hoặc khách hàng yêu cầu, b) mọi đầu ra dự kiến là kết quả của quá trình tạo sản phẩm. CHÚ THÍCH 2: Các yêu cầu luật định và chế định có thể được thể hiện như các yêu cầu pháp lý.

Tiêu chuẩn này nêu hướng dẫn cho các tổ chức trong việc áp dụng hệ thống quản lý chất lượng theo TCVN ISO 9001:2008 cho các hoạt động thu mua, cung cấp, phát triển, vận hành và duy trì phần mềm máy tính và các dịch vụ hỗ trợ có liên quan. Tiêu chuẩn này không bổ sung và cũng không thay đổi các yêu cầu của TCVN ISO 9001:2008.

Phụ lục A (tham khảo) đưa ra bảng nêu các hướng dẫn bổ sung trong việc áp dụng TCVN ISO 9001:2008 có trong các tiêu chuẩn do các ban kỹ thuật ISO/IEC/JTC1/SC7 và ISO/TC176 xây dựng.

Hướng dẫn nêu trong tiêu chuẩn này không nhằm sử dụng làm chuẩn mực đánh giá để đăng ký hay chứng nhận hệ thống quản lý chất lượng.

1.2  Áp dụng

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 1.2  Áp dụng Các yêu cầu trong tiêu chuẩn này mang tính tổng quát và nhằm áp dụng cho mọi tổ chức không phân biệt loại hình, quy mô và sản phẩm cung cấp. Khi có bất kỳ yêu cầu nào của tiêu chuẩn này không thể áp dụng được do bản chất của tổ chức và đặc thù của sản phẩm, có thể xem xét yêu cầu này như một ngoại lệ. Khi có ngoại lệ, việc công bố phù hợp với tiêu chuẩn này không được chấp nhận trừ phi các ngoại lệ này được giới hạn trong phạm vi các yêu cầu của điều 7, và các ngoại lệ này không ảnh hưởng đến khả năng hay trách nhiệm của tổ chức trong việc cung cấp sản phẩm đáp ứng các yêu cầu của khách hàng, các yêu cầu luật định và chế định thích hợp.

Việc áp dụng tiêu chuẩn này thích hợp đối với các phần mềm:

– là một phần của hợp đồng thương mại ký với một tổ chức khác;

– là sản phẩm hiện hữu đối với một lĩnh vực thị trường;

– gắn cùng một sản phẩm phần cứng hoặc;

– liên quan tới các dịch vụ phần mềm.

Một số tổ chức có thể thực hiện tất cả các hoạt động nêu trên, một số tổ chức khác có thể chỉ chuyên môn hóa trong một lĩnh vực. Trong bất kỳ trường hợp nào, hệ thống quản lý chất lượng của tổ chức đều cần bao gồm tất cả các khía cạnh của hoạt động này (có và không liên quan đến phần mềm).

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

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 2  Tài liệu viện dẫn Các tài liệu dưới đây rất cần thiết cho việc áp dụng tiêu chuẩn này. Đối với các tài liệu ghi năm công bố thì áp dụng bản được nêu. Đối với các tài liệu không ghi năm công bố thì áp dụng bản mới nhất, bao gồm cả các sửa đổi. TCVN ISO 9000:2007, Hệ thống quản lý chất lượng – Cơ sở và từ vựng

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

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 3  Thuật ngữ và định nghĩa Tiêu chuẩn này áp dụng các thuật ngữ và định nghĩa nêu trong TCVN ISO 9000. Trong tiêu chuẩn này, thuật ngữ “sản phẩm” cũng có nghĩa “dịch vụ”.

Tiêu chuẩn này áp dụng các thuật ngữ và định nghĩa nêu trong TCVN ISO 9000:2007 và cũng sử dụng một số thuật ngữ cụ thể khác được nêu trong ISO/IEC 12207 (được nhắc lại ở những nơi cần thiết).

Tuy nhiên, khi có sự khác nhau về các thuật ngữ và định nghĩa, thì sẽ sử dụng các thuật ngữ và định nghĩa nêu trong TCVN ISO 9000:2007.

CHÚ THÍCH: ISO/IEC 12207:2008 nêu các hạng mục chi tiết đối với các quá trình trong vòng đời của một phần mềm. Tiêu chuẩn này sẽ viện dẫn đến các thuật ngữ được định nghĩa trong ISO/IEC 12207:2008.

3.1

Hoạt động (activity)

Tập hợp các công việc gắn liền với nhau của một quá trình.

[NGUỒN ISO/IEC 12207:2008,4.3]

3.2

Đường cơ sở (baseline)

Quy định kỹ thuật hoặc sản phẩm đã được xem xét và thống nhất một cách chính thức và sau đó được dùng làm cơ sở cho sự phát triển tiếp và chỉ có thể được thay đổi bởi các thủ tục chính thức về kiểm soát sự thay đổi.

[NGUỒN ISO/IEC 12207:2008, 4.6]

3.3

Hạng mục cấu hình (configuration item)

Thực thể trong một cấu hình đáp ứng chức năng sử dụng cuối cùng và được xác định một cách duy nhất tại một điểm quy chiếu đã cho.

[NGUỒN ISO/IEC 12207:2008, 4.7]

3.4

Phần mềm thương mại (commercial-off-the-shelf-COTS)

<Sản phẩm phần mềm> có sẵn để mua và sử dụng mà không cần thực hiện thêm các hoạt động phát triển nào.

3.5

Áp dụng (implementation)

Quá trình vòng đời của phần mềm bao gồm các hoạt động phân tích yêu cầu, thiết kế, mã hóa, tích hợp, thử nghiệm, cài đặt và hỗ trợ để chấp nhận các sản phẩm phần mềm.

3.6

Mô hình vòng đời (life cycle model)

Khuôn khổ của các quá trình và các hoạt động liên quan đến vòng đời được tạo lập vào các giai đoạn và nó cũng đóng vai trò làm chuẩn chung cho việc trao đổi thông tin và hiểu biết.

CHÚ THÍCH 1: Các yêu cầu của TCVN ISO 9001:2008 có thể áp dụng đối với việc bảo trì, chỉ khi có yêu cầu của hợp đồng, sau khi sản phẩm đã được khách hàng chấp nhận. Tuy nhiên, các yêu cầu này thường không áp dụng cho việc bảo trì.

3.7

Đo (measure)

Tiến hành một phép đo

[NGUỒN ISO/IEC 15939: 2007, 2.15]

3.8

Đại lượng đo (measure)

Biến số theo đó một giá trị được ấn định làm kết quả đo.

[NGUỒN ISO/IEC 15939:2007, 2.15]

3.9

Phép đo (measurement)

Tập hợp các thao tác nhằm xác định giá trị của đại lượng đo.

[NGUỒN ISO/IEC 15939:2007, 2.17]

3.10

Quá trình (process)

Tập hợp các hoạt động có liên quan hoặc tương tác lẫn nhau biến đổi đầu vào thành đầu ra.

CHÚ THÍCH 1: Các đầu vào của một quá trình này thường là đầu ra của quá trình khác.

[NGUỒN TCVN ISO 9000:2007, 3.1.4]

3.11

Thử nghiệm suy thoái (regresion testing)

Phép thử cần thiết để xác định rằng một sự thay đổi đối với một cấu thành của hệ thống không gây tác động xấu về chức năng, công dụng, độ tin cậy và không làm phát sinh thêm các khuyết tật.

3.12

Phát hành (release)

Một phiên bản cụ thể về một hạng mục cấu hình đã được thực hiện xong, sẵn có cho mục đích sử dụng cụ thể.

CHÚ THÍCH 1: Thuật ngữ “release” dùng trong TCVN ISO 9001:2008 được viện dẫn trong tiêu chuẩn này theo nghĩa là “thông qua” như đã nêu trong mục 3.6.13 của TCVN ISO 9000:2007, thuật ngữ này khác với thuật ngữ “Phát hành“ trong ISO/IEC 12207 như được nêu ở trên.

VÍ DỤ: Thử nghiệm trước khi phát hành.

[NGUỒN ISO/IEC 12207:2008, 4.35]

3.13

Sao lại (replication)

Sao chép một sản phẩm phần mềm từ một phương tiện lưu trữ này sang một phương tiện khác.

3.14

Hạng mục phần mềm (software item)

Một phần có thể phân định được của một sản phẩm phần mềm.

3.15

Sản phẩm phần mềm (software product)

Tập hợp các chương trình máy tính, các thủ tục và các văn bản, dữ liệu kèm theo.

CHÚ THÍCH 1: Sản phẩm phần mềm có thể được ấn định để cung cấp, là một phần không thể thiếu của một sản phẩm khác, hoặc được sử dụng để phát triển.

CHÚ THÍCH 2: Từ “sản phẩm” nêu ở đây khác với từ “sản phẩm” nêu trong TCVN ISO 9000.

CHÚ THÍCH 3: Với mục đích của tiêu chuẩn này, từ “phần mềm” đồng nghĩa với “sản phẩm phần mềm“.

[NGUỒN ISO/IEC 12207:2008,4.42]

4  Hệ thống quản lý chất lượng

4.1  Yêu cầu chung

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 4.1  Yêu cầu chung Tổ chức phải xây dựng, lập văn bản, thực hiện, duy trì hệ thống quản lý chất lượng và cải tiến liên tục hiệu lực của hệ thống theo các yêu cầu của tiêu chuẩn này. Tổ chức phải a) xác định các quá trình cần thiết trong hệ thống quản lý chất lượng và áp dụng chúng trong toàn bộ tổ chức (xem 1.2), b) xác định trình tự và mối tương tác của các quá trình này, c) xác định các chuẩn mực và phương pháp cần thiết để đảm bảo vận hành và kiểm soát các quá trình này có hiệu lực, d) đảm bảo sẵn có các nguồn lực và thông tin cần thiết để hỗ trợ việc vận hành và theo dõi các quá trình này, e) theo dõi, đo lường khi thích hợp và phân tích các quá trình này, và f) thực hiện các hành động cần thiết để đạt được kết quả dự định và cải tiến liên tục các quá trình này. g) Tổ chức phải quản lý các quá trình theo các yêu cầu của tiêu chuẩn này. Khi tổ chức chọn nguồn bên ngoài cho bất kỳ quá trình nào ảnh hưởng đến sự phù hợp của sản phẩm với các yêu cầu, tổ chức phải đảm bảo kiểm soát được những quá trình đó. Cách thức và mức độ kiểm soát cần áp dụng cho những quá trình sử dụng nguồn bên ngoài này phải được xác định trong hệ thống quản lý chất lượng. CHÚ THÍCH 1: Các quá trình cần thiết đối với hệ thống quản lý chất lượng nêu ở trên bao gồm cả các quá trình về các hoạt động quản lý, cung cấp nguồn lực, tạo sản phẩm, đo lường, phân tích và cải tiến. CHÚ THÍCH 2: “Quá trình sử dụng nguồn bên ngoài” là quá trình tổ chức cần cho hệ thống quản lý chất lượng của mình và lựa chọn để bên ngoài thực hiện. CHÚ THÍCH 3: Việc đảm bảo kiểm soát các quá trình sử dụng nguồn bên ngoài không loại trừ được trách nhiệm của tổ chức về sự phù hợp với tất cả các yêu cầu của khách hàng, luật định và chế định. Loại và mức độ kiểm soát cần áp dụng với các quá trình sử dụng nguồn bên ngoài có thể bị ảnh hưởng bởi các yếu tố như: a) tác động tiềm ẩn của quá trình sử dụng nguồn bên ngoài đến khả năng của tổ chức trong việc cung cấp sản phẩm phù hợp với các yêu cầu, b) mức độ chia sẻ việc kiểm soát quá trình, c) khả năng đạt được kiểm soát cần thiết thông qua việc áp dụng 7.4.

Hướng dẫn được nêu cho các mục a) và b) trong mục 4.1 của TCVN ISO 9001:2008 liên quan đến các quá trình dưới đây của tổ chức (xem 5.4.2 và 7.4.1 về chỉ dẫn bổ sung về thuê ngoài).

a) Nhận biết và áp dụng quá trình

Tổ chức cần nhận biết các quá trình để phát triển, khai thác và bảo trì sản phẩm phần mềm.

b) Trình tự và mối tương tác giữa các quá trình

Tổ chức cần nhận biết trình tự và mối tương tác của các quá trình trong:

1) Các mô hình vòng đời đối với việc phát triển phần mềm, ví dụ nguyên tắc dòng chảy một chiều, tách thành các mô đun riêng, tính dễ nâng cấp, và

2) Lập kế hoạch chất lượng và phát triển dựa trên mô hình vòng đời

CHÚ THÍCH: Thông tin thêm xem:

– ISO/IEC 12207:2008^[5] (các quá trình của vòng đời sản phẩm phần mềm) tài liệu xác định tập hợp các quá trình của một vòng đời sản phẩm phần mềm và nó có thể được sử dụng để tham chiếu;

– ISO/IEC/TR 24748-1^[21] và ISO/IEC/TR24748-3 ^[22] đưa ra các chỉ dẫn cách sử dụng các quá trình nêu trong ISO/IEC 12207 trong các vòng đời khác nhau.

4.2  Yêu cầu về hệ thống tài liệu

4.2.1  Khái quát

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 4.2.1  Khái quát Tài liệu của hệ thống quản lý chất lượng phải bao gồm a) Các văn bản công bố về chính sách chất lượng và mục tiêu chất lượng, b) Sổ tay chất lượng, c) Các thủ tục dạng văn bản và hồ sơ theo yêu cầu của tiêu chuẩn này, và đ) Các tài liệu, bao gồm cả hồ sơ, được tổ chức xác định là cần thiết để đảm bảo hoạch định, vận hành và kiểm soát có hiệu lực các quá trình của tổ chức. CHÚ THÍCH 1: Khi thuật ngữ “thủ tục dạng văn bản” xuất hiện trong tiêu chuẩn này, thì thủ tục đó phải được xây dựng, lập thành văn bản, thực hiện và duy trì. Một tài liệu riêng rẽ có thể đề cập tới yêu cầu với một hay nhiều thủ tục. Yêu cầu về thủ tục dạng văn bản có thể được đề cập trong nhiều tài liệu. CHÚ THÍCH 2: Mức độ văn bản hóa hệ thống quản lý chất lượng của mỗi tổ chức có thể khác nhau tùy thuộc vào a) Quy mô của tổ chức và loại hình hoạt động, b) Sự phức tạp và sự tương tác giữa các quá trình, và c) Năng lực nhân sự. CHÚ THÍCH 3: Hệ thống tài liệu có thể ở bất kỳ dạng hoặc loại phương tiện nào.

Các tài liệu cho việc hoạch định, triển khai và kiểm soát một cách hiệu lực các quá trình đối với một sản phẩm phần mềm (TCVN ISO 9001:2008, 4.2.1d) có thể gồm:

1) Mô tả về các quá trình, chẳng hạn những quá trình đã được xác định trong việc áp dụng 4.1;

2) Mô tả về các hướng dẫn hay các mẫu mang tính chất thủ tục hiện được sử dụng;

3) Mô tả về mô hình vòng đời được sử dụng như nguyên tắc dòng chảy một chiều, tách thành các mô đun riêng, tính dễ nâng cấp;

4) Mô tả về các công cụ, kỹ thuật, công nghệ và các phương pháp như những gì đã được xác định khi áp dụng 4.1;

5) Các chủ đề mang tính kỹ thuật như các tiêu chuẩn hay các tài liệu chỉ dẫn để thiết lập mã hóa, thiết kế và phát triển và thử nghiệm.

CHÚ THÍCH: Thông tin thêm về phân định các tài liệu như là một phần của quản lý cấu hình, xem 7.5.3.

4.2.2  Sổ tay chất lượng

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 4.2.2  Sổ tay chất lượng Tổ chức phải thiết lập và duy trì sổ tay chất lượng trong đó bao gồm: a) Phạm vi của hệ thống quản lý chất lượng, bao gồm cả các nội dung chi tiết và lý giải về bất cứ ngoại lệ nào (xem 1.2), b) Các thủ tục dạng văn bản được thiết lập cho hệ thống quản lý chất lượng hoặc viện dẫn đến chúng và, c) Mô tả sự tương tác giữa các quá trình trong hệ thống quản lý chất lượng.

4.2.3  Kiểm soát tài liệu

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 4.2.3  Kiểm soát tài liệu Các tài liệu theo yêu cầu của hệ thống quản lý chất lượng phải được kiểm soát. Hồ sơ chất lượng là một loại tài liệu đặc biệt và phải được kiểm soát theo các yêu cầu nêu trong 4.2.4. Tổ chức phải lập một thủ tục dạng văn bản để xác định việc kiểm soát cần thiết nhằm: a) phê duyệt tài liệu về sự thỏa đáng trước khi ban hành, b) xem xét, cập nhật khi cần và phê duyệt lại tài liệu, c) đảm bảo nhận biết được các thay đổi và tình trạng sửa đổi hiện hành của tài liệu, d) đảm bảo các phiên bản của các tài liệu thích hợp sẵn có ở nơi sử dụng, e) đảm bảo tài liệu luôn rõ ràng và dễ nhận biết, f) đảm bảo các tài liệu có nguồn gốc bên ngoài mà tổ chức xác định là cần thiết cho việc hoạch định và vận hành hệ thống quản lý chất lượng được nhận biết và việc phân phối chúng được kiểm soát, và g) ngăn ngừa việc vô tình sử dụng các tài liệu lỗi thời và áp dụng các dấu hiệu nhận biết thích hợp nếu chúng được giữ lại vì bất kỳ mục đích nào.

CHÚ THÍCH: Thông tin thêm về kiểm soát tài liệu như một phần của quản lý cấu hình, xem 7.5.3.

4.2.4  Kiểm soát hồ sơ

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 4.2.4  Kiểm soát hồ sơ Phải kiểm soát các hồ sơ đã được thiết lập để cung cấp bằng chứng về sự phù hợp với các yêu cầu và việc vận hành có hiệu lực của hệ thống quản lý chất lượng. Tổ chức phải lập một thủ tục bằng văn bản để xác định những cách kiểm soát cần thiết đối với việc nhận biết, bảo quản, bảo vệ, sử dụng, thời gian lưu giữ và hủy bỏ hồ sơ. Hồ sơ phải luôn rõ ràng, dễ nhận biết và dễ sử dụng.

4.2.4.1  Bằng chứng về sự phù hợp với các yêu cầu

Bằng chứng về sự phù hợp với các yêu cầu có thể là:

a) các kết quả thử nghiệm bằng văn bản;

b) báo cáo về các vấn đề, kể cả những vấn đề liên quan đến công cụ;

c) các yêu cầu thay đổi;

d) các tài liệu liên quan tới góp ý;

e) các báo cáo đánh giá; và

f) các hồ sơ xem xét và kiểm tra như hồ sơ xem xét thiết kế, kiểm tra mã nguồn, hồ sơ khi kiểm tra theo toàn bộ trình tự.

4.2.4.2  Bằng chứng về việc vận hành có hiệu lực

Các ví dụ về bằng chứng của việc vận hành có hiệu lực hệ thống quản lý chất lượng có thể là, nhưng không giới hạn ở:

a) những thay đổi (và cả nguyên nhân) đối với nguồn lực (con người, phần mềm và thiết bị),

b) các ước lượng, ví dụ quy mô dự án và nỗ lực (con người, chi phí, lịch trình),

c) các công cụ, phương pháp luận và người cung ứng đã được lựa chọn, đánh giá năng lực như thế nào và tại sao,

d) những thỏa thuận về cấp phép phần mềm (cả các phần mềm để cung cấp cho khách hàng và phần mềm được mua để hỗ trợ phát triển),

e) các biên bản họp, và

f) hồ sơ phát hành phần mềm.

4.2.4.3  Việc lưu giữ và hủy bỏ hồ sơ

Khi xác định khoảng thời gian lưu giữ các hồ sơ cần xem xét các yêu cầu luật định và chế định. Khi hồ sơ được lưu giữ bằng các phương tiện điện tử, việc cân nhắc thời gian lưu trữ và việc truy cập hồ sơ cần tính đến mức độ suy giảm của phương tiện, tính sẵn có của các thiết bị và phần mềm cần thiết cho việc truy cập hồ sơ. Hồ sơ có thể bao gồm các thông tin lưu trong hệ thống thư điện tử. Cần cân nhắc việc phòng tránh vi rút cho máy tính cũng như việc truy cập bất hợp pháp hoặc truy cập mà không được chấp thuận.

Khi xác định các phương pháp xóa dữ liệu khỏi các phương tiện lưu trữ khi hết thời hạn lưu giữ, cần đánh giá nguồn gốc sở hữu thông tin được lưu giữ trong hồ sơ.

CHÚ THÍCH: Hướng dẫn thêm về 4.2, TCVN ISO 9001:2008, xem ISO/IEC 12207:2008 [5] mục 6.3.6 (Quá trình quản lý thông tin) và 7.2.1 (Quá trình quản lý tài liệu phần mềm).

5  Trách nhiệm của lãnh đạo

5.1  Cam kết của lãnh đạo

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 5.1  Cam kết của lãnh đạo Lãnh đạo cao nhất phải cung cấp bằng chứng về sự cam kết của mình đối với việc xây dựng và thực hiện hệ thống quản lý chất lượng và cải tiến liên tục hiệu lực của hệ thống đó bằng cách a) truyền đạt cho tổ chức về tầm quan trọng của việc đáp ứng các yêu cầu của khách hàng cũng như các yêu cầu của luật định và chế định, b) thiết lập chính sách chất lượng, c) đảm bảo việc thiết lập các mục tiêu chất lượng, d) tiến hành việc xem xét của lãnh đạo, và e) đảm bảo sẵn có các nguồn lực.

5.2  Hướng vào khách hàng

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 5.2  Hướng vào khách hàng Lãnh đạo cao nhất phải đảm bảo rằng các yêu cầu của khách hàng được xác định và đáp ứng nhằm nâng cao sự thỏa mãn khách hàng (xem 7.2.1 và 8.2.1).

5.3  Chính sách chất lượng

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 5.3  Chính sách chất lượng Lãnh đạo cao nhất phải đảm bảo rằng chính sách chất lượng a) phù hợp với mục đích của tổ chức, b) bao gồm việc cam kết đáp ứng các yêu cầu và cải tiến liên tục hiệu lực của hệ thống quản lý chất lượng, c) cung cấp cơ sở cho việc thiết lập và xem xét các mục tiêu chất lượng, d) được truyền đạt và thấu hiểu trong tổ chức, và e) được xem xét để luôn thích hợp.

5.4  Hoạch định

5.4.1  Mục tiêu chất lượng

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 5.4.1  Mục tiêu chất lượng Lãnh đạo cao nhất phải đảm bảo rằng các mục tiêu chất lượng, bao gồm cả những điều cần thiết để đáp ứng các yêu cầu của sản phẩm [xem 7.1 a)], được thiết lập tại các cấp và bộ phận chức năng liên quan trong tổ chức. Mục tiêu chất lượng phải đo được và nhất quán với chính sách chất lượng.

CHÚ THÍCH 1: Thông tin thích hợp về các thuộc tính của quá trình phần mềm thích hợp cho việc thiết lập các mục tiêu được nêu trong ISO/IEC15504-1^[10]. ISO/IEC15504 (tất cả các phần) và có thể được dùng để đánh giá năng lực quá trình, thiết lập các mục tiêu cho việc cải thiện năng lực quá trình.

CHÚ THÍCH 2: Thông tin về các đặc tính, đặc tính phụ, các thuộc tính về chất lượng của các sản phẩm phần mềm dùng để thiết lập các mục tiêu được nêu trong ISO/IEC 25010. Bộ tiêu chuẩn ISO/IEC 25000 được xem là hữu ích cho việc xác định các yêu cầu chất lượng và để thiết lập các mục tiêu chất lượng của một sản phẩm phần mềm.

5.4.2  Hoạch định hệ thống quản lý chất lượng

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 5.4.2  Hoạch định hệ thống quản lý chất lượng Lãnh đạo cao nhất phải đảm bảo a) tiến hành hoạch định hệ thống quản lý chất lượng để đáp ứng các yêu cầu nêu trong 4.1 cũng như các mục tiêu chất lượng, và b) tính nhất quán của hệ thống quản lý chất lượng được duy trì khi các thay đổi đối với hệ thống quản lý chất lượng được hoạch định và thực hiện.

Việc hoạch định có thể diễn ra ở các cấp tổ chức, cấp dự án/sản phẩm.

Việc hoạch định hệ thống quản lý chất lượng ở cấp tổ chức có thể bao gồm:

a) xác định các mô hình vòng đời phần mềm thích hợp được sử dụng cho các loại dự án mà tổ chức đang thực hiện, kể cả cách tổ chức thường áp dụng các quá trình vòng đời phần mềm;

b) xác định các sản phẩm dạng kết quả công việc của việc phát triển phần mềm, chẳng hạn như tài liệu về các yêu cầu của phần mềm, tài liệu về thiết kế kiến trúc, tài liệu thiết kế chi tiết, mã chương trình, tài liệu dùng cho người sử dụng phần mềm;

c) xác định nội dung của các phương án quản lý phần mềm, như các phương án quản lý dự án phần mềm, các phương án quản lý cấu hình phần mềm, các phương án kiểm tra và xác nhận giá trị sử dụng phần mềm, các phương án đảm bảo chất lượng phần mềm, các phương án đào tạo;

d) xác định cách để các phương pháp mang tính kỹ thuật phần mềm được làm phù hợp với các dự án của tổ chức trong khuôn khổ vòng đời (xem 1.2);

e) nhận biết các công cụ và môi trường để phát triển, khai thác sử dụng và duy trì phần mềm;

f) quy định các quy ước sử dụng các ngôn ngữ phần mềm, ví dụ các quy tắc về mã, các thư viện hay các cơ chế quản lý phần mềm;

g) nhận biết rõ bất kỳ sự sử dụng lại phần mềm nào (xem 7.5.4)

Đại diện lãnh đạo của tổ chức cần cân nhắc về bất kỳ sự thay đổi nào của mô hình vòng đời phần mềm có thể ảnh hưởng đến hệ thống quản lý chất lượng và cần đảm bảo rằng những thay đổi đó không làm tổn hại đến bất kỳ hoạt động kiểm soát nào của hệ thống quản lý chất lượng.

Hoạch định chất lượng phần mềm ở cấp dự án/sản phẩm được nêu ở 7.1.

5.5  Trách nhiệm, quyền hạn và trao đổi thông tin

5.5.1  Trách nhiệm và quyền hạn

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 5.5.1  Trách nhiệm và quyền hạn Lãnh đạo cao nhất phải đảm bảo các trách nhiệm và quyền hạn được xác định và thông báo trong tổ chức.

5.5.2  Đại diện của lãnh đạo

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 5.5.2  Đại diện của lãnh đạo Lãnh đạo cao nhất phải chỉ định một thành viên trong ban lãnh đạo của tổ chức, ngoài các trách nhiệm khác, phải có trách nhiệm và quyền hạn sau: a) đảm bảo các quá trình cần thiết của hệ thống quản lý chất lượng được thiết lập, thực hiện và duy trì; b) báo cáo cho lãnh đạo cao nhất về kết quả hoạt động của hệ thống quản lý chất lượng và về mọi nhu cầu cải tiến, và c) đảm bảo thúc đẩy toàn bộ tổ chức nhận thức được các yêu cầu của khách hàng. CHÚ THÍCH: Trách nhiệm của đại diện lãnh đạo về chất lượng có thể bao gồm cả quan hệ với bên ngoài về các vấn đề có liên quan đến hệ thống quản lý chất lượng.

Với tổ chức sản xuất phần mềm, sẽ thuận lợi nếu đại diện lãnh đạo là người có kinh nghiệm về phát triển phần mềm.

5.5.3  Trao đổi thông tin nội bộ

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 5.5.3  Trao đổi thông tin nội bộ Lãnh đạo cao nhất phải đảm bảo thiết lập các quá trình trao đổi thông tin thích hợp trong tổ chức và có sự trao đổi thông tin về hiệu lực của hệ thống quản lý chất lượng.

5.6  Xem xét của lãnh đạo

5.6.1  Khái quát

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 5.6.1  Khái quát Lãnh đạo cao nhất phải định kỳ xem xét hệ thống quản lý chất lượng, để đảm bảo nó luôn thích hợp, thỏa đáng và có hiệu lực. Việc xem xét này phải đánh giá được cơ hội cải tiến và nhu cầu thay đổi đối với hệ thống quản lý chất lượng, kể cả chính sách chất lượng và các mục tiêu chất lượng. Hồ sơ xem xét của lãnh đạo phải được duy trì (xem 4.2.4)

5.6.2  Đầu vào của việc xem xét

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 5.6.2  Đầu vào của việc xem xét Đầu vào của việc xem xét của lãnh đạo phải bao gồm thông tin về a) kết quả của các cuộc đánh giá, b) phản hồi của khách hàng, c) việc thực hiện các quá trình và sự phù hợp của sản phẩm, d) tình trạng của các hành động khắc phục và phòng ngừa, e) các hành động tiếp theo từ các cuộc xem xét của lãnh đạo lần trước, f) những thay đổi có thể ảnh hưởng đến hệ thống quản lý chất lượng, và g) các khuyến nghị về cải tiến.

Hướng dẫn cho 5.6.2 c) trong TCVN ISO 9001:2008 được nêu dưới đây.

Một cách để đo kết quả thực hiện quá trình là tiến hành đánh giá quá trình thực hiện phần mềm (xem 8.2.3). Các đầu ra của đánh giá quá trình phần mềm cần được coi là đầu vào của việc xem xét của lãnh đạo.

Một cách để đo sự phù hợp của sản phẩm là tiến hành đánh giá định lượng sản phẩm phần mềm (xem 8.2.4). Các đầu ra của việc đánh giá định lượng sản phẩm phần mềm được coi là đầu vào của việc xem xét của lãnh đạo.

5.6.3  Đầu ra của việc xem xét

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 5.6.3  Đầu ra của việc xem xét Đầu ra của việc xem xét của lãnh đạo phải bao gồm mọi quyết định và hành động liên quan đến a) việc cải tiến hiệu lực của hệ thống quản lý chất lượng và cải tiến các quá trình của hệ thống. b) việc cải tiến sản phẩm liên quan đến các yêu cầu của khách hàng, và c) nhu cầu về nguồn lực.

6  Quản lý nguồn lực

6.1  Cung cấp các nguồn lực

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 6.1  Cung cấp các nguồn lực Tổ chức phải xác định và cung cấp các nguồn lực cần thiết để a) thực hiện và duy trì hệ thống quản lý chất lượng, cải tiến liên tục hiệu lực của hệ thống đó, và b) nâng cao sự thỏa mãn khách hàng bằng cách đáp ứng các yêu cầu của khách hàng.

6.2  Nguồn nhân lực

6.2.1  Khái quát

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 6.2.1  Khái quát Những người thực hiện các công việc ảnh hưởng đến sự phù hợp với các yêu cầu của sản phẩm phải có năng lực trên cơ sở được giáo dục, đào tạo, có kỹ năng và kinh nghiệm thích hợp. CHÚ THÍCH: Sự phù hợp với các yêu cầu của sản phẩm có thể bị ảnh hưởng trực tiếp hoặc gián tiếp bởi những người thực hiện nhiệm vụ bất kỳ trong hệ thống quản lý chất lượng.

CHÚ THÍCH: Thông tin thêm xem ISO/IEC 12207:2008 [5], 6.2.4 Quá trình quản lý nguồn nhân lực.

6.2.2  Năng lực, nhận thức và đào tạo

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 6.2.2  Năng lực, nhận thức và đào tạo Tổ chức phải a) xác định năng lực cần thiết của những người thực hiện các công việc ảnh hưởng đến sự phù hợp với các yêu cầu của sản phẩm, b) tiến hành đào tạo hay những hành động khác để đạt được năng lực cần thiết, khi thích hợp, c) đánh giá hiệu lực của các hành động được thực hiện, d) đảm bảo rằng nhân sự của tổ chức nhận thức được mối liên quan và tầm quan trọng của các hoạt động của họ và họ đóng góp như thế nào đối với việc đạt được mục tiêu chất lượng, và e) duy trì hồ sơ thích hợp về giáo dục, đào tạo, kỹ năng và kinh nghiệm (xem 4.2.4).

Nhu cầu đào tạo cần được xác định trên cơ sở cân nhắc các yêu cầu, các phương pháp thiết kế, ngôn ngữ lập trình cụ thể, các công cụ kỹ thuật và các nguồn lực máy tính được sử dụng trong phát triển và quản lý dự án/sản phẩm phần mềm. Nó cũng được phép bao gồm việc đào tạo về kỹ năng và kiến thức thuộc lĩnh vực cụ thể trong đó phần mềm được ứng dụng và về các nội dung khác như quản lý dự án,… sẽ được áp dụng.

Các công nghệ được dùng trong phát triển, triển khai và duy trì phần mềm cần được thường xuyên theo dõi và đánh giá nhằm xác định các yêu cầu đối với việc cập nhật các kỹ năng cho nhân viên.

Hình thức đào tạo không nhất thiết là các khóa học mang tính truyền thống mà có thể là hội thảo, đào tạo trên máy tính, tự nghiên cứu, kèm cặp, đào tạo qua công việc hoặc đào tạo qua mạng.

Việc đánh giá hiệu lực của đào tạo có thể được thực hiện thông qua việc sử dụng các thước đo về sản phẩm và quá trình, nhờ xác định các khu vực cải tiến về kết quả thực hiện của nhân sự (trong số các khu vực cải tiến khác).

6.3  Cơ sở hạ tầng

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 6.3  Cơ sở hạ tầng Tổ chức phải xác định, cung cấp và duy trì cơ sở hạ tầng cần thiết để đạt được sự phù hợp với các yêu cầu của sản phẩm. Cơ sở hạ tầng bao gồm ví dụ như: a) nhà cửa, không gian làm việc và các phương tiện kèm theo, b) trang thiết bị quá trình (cả phần cứng và phần mềm), và c) dịch vụ hỗ trợ (như vận chuyển hoặc trao đổi thông tin hay hệ thống thông tin).

Cơ sở hạ tầng cần bao gồm phần cứng, phần mềm, các công cụ và thiết bị cho việc phát triển, khai thác hoặc duy trì phần mềm.

Cơ sở hạ tầng có thể bao gồm các công cụ phần mềm hỗ trợ cho quá trình thiết kế và phát triển, bao gồm:

a) công cụ, chẳng hạn để phân tích, thiết kế và phát triển, quản lý cấu hình, thử nghiệm, quản lý dự án, lập văn bản, tạo hay hình thành các hệ mã;

b) phát triển ứng dụng và các môi trường hỗ trợ;

c) quản lý tri thức, các công cụ cho mạng nội bộ và mạng bên ngoài;

d) công cụ mạng, bao gồm tính bảo mật, sao lưu, bảo vệ khỏi virut, tường lửa;

e) ứng dụng hỗ trợ và các công cụ bảo trì;

f) các biện pháp kiểm soát truy cập;

g) thư viện phần mềm;

h) công cụ kiểm soát tác nghiệp như việc giám sát mạng, quản lý hệ thống và quản lý việc lưu giữ.

Dù các công cụ hay kỹ thuật này được phát triển nội bộ hay được mua, thì tổ chức đều cần đánh giá xem chúng có phù hợp với mục đích sử dụng hay không. Các công cụ được sử dụng trong ứng dụng sản phẩm, chẳng hạn các công cụ phân tích, thiết kế và phát triển, các trình biên dịch, chương trình lập mã số đều cần được đánh giá, phê duyệt và chịu một mức độ kiểm soát quản lý cấu hình thích hợp trước khi sử dụng. Phạm vi sử dụng của các công cụ và các kỹ thuật có thể được lập thành văn bản theo những hướng dẫn thích hợp và việc sử dụng của chúng cần được xem xét khi thích hợp nhằm xác định liệu có cần cải tiến và/hoặc nâng cấp hay không.

CHÚ THÍCH: Thông tin thêm xem:

– ISO/IEC 12207:2008 [5] mục 6.2.2 Quá trình quản lý cơ sở hạ tầng;

– ISO/IEC 25001 [23] (việc thu nhận) và ISO/IEC 25004 [25] và ISO/IEC 25041 [26] (Đánh giá sản phẩm phần mềm)

– ISO/1EC 14102 [6].

6.4  Môi trường làm việc

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 6.4  Môi trường làm việc Tổ chức phải xác định và quản lý môi trường làm việc cần thiết để đạt được sự phù hợp đối với các yêu cầu của sản phẩm. CHÚ THÍCH: Thuật ngữ “môi trường làm việc” liên quan tới các điều kiện tiến hành công việc, bao gồm các yếu tố vật lý, môi trường và các yếu tố khác (như tiếng ồn, nhiệt độ, độ ẩm, chiếu sáng hoặc thời tiết).

7  Tạo sản phẩm

7.1  Hoạch định việc tạo sản phẩm

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 7.1  Hoạch định việc tạo sản phẩm Tổ chức phải lập kế hoạch và triển khai các quá trình cần thiết đối với việc tạo sản phẩm. Hoạch định việc tạo sản phẩm phải nhất quán với các yêu cầu của các quá trình khác của hệ thống quản lý chất lượng (xem 4.1). Trong quá trình hoạch định việc tạo sản phẩm, khi thích hợp, tổ chức phải xác định những điều sau đây: a) Các mục tiêu chất lượng và các yêu cầu đối với sản phẩm; b) Nhu cầu thiết lập các quá trình và tài liệu cũng như việc cung cấp các nguồn lực cụ thể đối với sản phẩm; c) Các hoạt động kiểm tra xác nhận, xác nhận giá trị sử dụng, các hoạt động theo dõi, đo lường, kiểm tra và thử nghiệm cụ thể cần thiết đối với sản phẩm và các tiêu chí chấp nhận sản phẩm; d) Các hồ sơ cần thiết để cung cấp bằng chứng rằng các quá trình thực hiện và sản phẩm tạo thành đáp ứng các yêu cầu (xem 4.2.4). Đầu ra của việc hoạch định phải được thể hiện phù hợp với phương pháp tác nghiệp của tổ chức. CHÚ THÍCH 1: Tài liệu quy định các quá trình của hệ thống quản lý chất lượng (bao gồm cả các quá trình tạo sản phẩm) và các nguồn lực được sử dụng đối với một sản phẩm, dự án hay hợp đồng cụ thể có thể được coi như một kế hoạch chất lượng. CHÚ THÍCH 2: Tổ chức cũng có thể áp dụng các yêu cầu nêu trong 7.3 để triển khai quá trình tạo sản phẩm.

7.1.1  Vòng đời sản phẩm phần mềm

Các quá trình, hoạt động và công việc cần được hoạch định và tiến hành trên cơ sở sử dụng mô hình vòng đời thích hợp với tính chất của dự án phần mềm có tính đến quy mô, mức độ phức tạp, rủi ro và tính toàn vẹn. TCVN ISO 9001:2008 áp dụng cho mọi mô hình vòng đời hiện đang được sử dụng chứ không nhằm chỉ ra một mô hình vòng đời hay một trình tự quá trình cụ thể nào.

Việc thiết kế và phát triển có thể là một quá trình và các thủ tục luôn biến đổi và vì vậy nó cần được thay đổi hay cập nhật theo các tiến triển của dự án sau khi cân nhắc các thay đổi đối với các hoạt động và các nhiệm vụ liên quan.

Việc cân nhắc cần được tiến hành thích hợp với phương pháp thiết kế và phát triển đối với loại công việc, sản phẩm hay dự án và tương thích với việc áp dụng, với các phương pháp và các công cụ được sử dụng. Đối các sản phẩm mà sai lỗi có thể dẫn đến thương tật hoặc nguy hiểm cho con người, gây hỏng hóc hay hủy hoại tài sản hay môi trường thì việc thiết kế và phát triển những sản phẩm phần mềm như vậy cần đảm bảo xác định các yêu cầu thiết kế và phát triển cụ thể này, định rõ kỳ vọng là sẽ hoàn toàn tránh được hay ứng phó được với các điều kiện sai lỗi tiềm ẩn.

Việc lập kế hoạch phát triển phần mềm cần xác định được những sản phẩm nào cần được sản xuất, ai là người tạo ra chúng và lúc nào chúng được tạo ra (xem 7.3.1). Việc lập kế hoạch chất lượng sản phẩm phần mềm tại giai đoạn sản phẩm và dự án cần mô tả cách thức các sản phẩm cụ thể sẽ được triển khai, đánh giá hoặc duy trì.

7.1.2  Hoạch định chất lượng

Hoạch định chất lượng đưa ra các biện pháp để điều tiết một cách thích ứng việc áp dụng hệ thống quản lý chất lượng theo hợp đồng, sản phẩm, dự án cụ thể. Hoạch định chất lượng có thể bao gồm hoặc viện dẫn đến các thủ tục chung và/hoặc các thủ tục cụ thể của hợp đồng/sản phẩm/dự án khi thích hợp. Hoạch định chất lượng cần được soát xét song hành với tiến triển của hoạt động thiết kế và phát triển và các hạng mục có liên quan tới từng giai đoạn cần được xác định một cách đầy đủ khi bắt đầu giai đoạn đó. Hoạch định chất lượng cần được xem xét và được sự chấp thuận của toàn bộ tổ chức liên quan tới việc triển khai, khi thích hợp.

CHÚ THÍCH 1: Tài liệu mô tả việc hoạch định chất lượng có thể là một tài liệu độc lập (có tên gọi là kế hoạch chất lượng), là một phần của tài liệu khác hoặc được kết hợp từ một số tài liệu, kể cả các kế hoạch thiết kế và phát triển.

CHÚ THÍCH 2: ISO/IEC 12207 ^[5] bao gồm việc hoạch định chất lượng và hoạch định phát triển và được xem là hoạt động hoạch định đơn lẻ để dẫn đến việc tạo lập (các) kế hoạch quản lý dự án. Phụ lục B đưa ra bảng cho thấy cách để các hạng mục nêu trong 7.1.1 và 7.3.1 được đáp ứng như thế nào so với các hạng mục liên quan 6.1.2.3.4.5; 7.1.1.3.1.4 được nêu trong ISO/IEC 12207:2008.

Kế hoạch chất lượng của sản phẩm phần mềm tại giai đoạn dự án cần đề cập các nội dung sau:

a) nêu hoặc viện dẫn đến các kế hoạch phát triển (xem 7.3.1);

b) các yêu cầu chất lượng liên quan đến sản phẩm và hoặc quá trình;

c) việc điều chỉnh và/hoặc xác định các thủ tục hoặc các hướng dẫn cụ thể cho phù hợp với phạm vi của sổ tay chất lượng và mọi điểm loại trừ nào đã được công bố (TCVN ISO 9001:2008, mục 1.2);

d) các thủ tục và các hướng dẫn mang tính riêng biệt của dự án, như các phương án chi tiết trong quy định để thử nghiệm sản phẩm phần mềm, các thiết kế, các trường hợp và các thủ tục thử nghiệm đối với từng đơn vị, tính tích hợp, tính hệ thống và cách thử nghiệm để nghiệm thu (xem 8.2.4);

e) các phương pháp, các mô hình vòng đời của sản phẩm, các công cụ, cách chuyển đổi ngôn ngữ lập trình, các thư viện phần mềm, các cơ chế và tài sản dạng có thể tái sử dụng khác sẽ được dùng trong dự án này;

f) chuẩn mực để bắt đầu và kết thúc từng giai đoạn dự án;

g) các kiểu xem xét và các hoạt động kiểm tra xác nhận khác cần được tiến hành (xem 7.3.4, 7.3.5 và 7.3.6):

h) các thủ tục quản lý cấu hình cần được tiến hành (7.5.3);

i) hoạt động theo dõi và đo lường cần được tiến hành;

j) (những) người chịu trách nhiệm thông qua các đầu ra của các quá trình để chuyển cho việc sử dụng tiếp theo;

k) nhu cầu đào tạo để sử dụng các công cụ và kỹ thuật, lịch trình đào tạo trước các kỹ năng cần thiết này;

l) hồ sơ được duy trì (xem 4.2.4)

m) quản lý sự thay đổi, chẳng hạn về nguồn lực, tiến độ và những sự thay đổi trong hợp đồng.

Kế hoạch chất lượng, nói vắn tắt, là cách hữu ích và thực tiễn nhằm làm rõ các mục tiêu có tính giới hạn về chất lượng đối với sản phẩm phần mềm hiện được thiết kế cho mục đích có tính giới hạn. Các ví dụ về sản phẩm phần mềm có mục đích có tính giới hạn bao gồm các bản chạy thử minh họa để tránh nhầm lẫn khái niệm, cách tính toán mang tính khảo sát về điện toán chỉ được sử dụng bởi người thiết kế, giải pháp tạm thời mang tính giả định khi thiếu các đặc tính như tính bảo mật, kết quả thực hiện đầy đủ về tính năng vận hành mà những điều này sẽ được áp dụng cho đầu ra dự kiến và các hồ sơ phân tích dữ liệu mang tính tức thời.

Các sản phẩm phần mềm có mục đích mang tính giới hạn cần được thử nghiệm theo những cách gắn liền với việc sử dụng đã được dự định để giảm khả năng xảy ra những việc bị bỏ sót hay sai lỗi không lường trước.

CHÚ THÍCH 3: Với các chỉ dẫn chung chi tiết hơn liên quan tới TCVN ISO 9001:2008, xem các tài liệu sau:

– ISO/IEC 12207:2008 ^[5] mục 6.3.1 (Quá trình lập kế hoạch dự án) và mục 7.2 (Các quá trình hỗ trợ phần mềm)

– ISO/IEC 25010:2011 ^[24]

– ISO/IEC 25010:2011 ^[24]

– ISO/IEC 25001:2007 ^[23]

– ISO/IEC 16326:2009 ^[12]

7.2  Các quá trình liên quan đến khách hàng

7.2.1  Xác định các yêu cầu liên quan đến sản phẩm

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 7.2.1  Xác định các yêu cầu liên quan đến sản phẩm Tổ chức phải xác định a) yêu cầu do khách hàng đưa ra, gồm cả yêu cầu về các hoạt động giao hàng và sau giao hàng; b) yêu cầu không được khách hàng công bố nhưng cần thiết cho việc sử dụng quy định hoặc sử dụng dự kiến, khi đã biết; c) yêu cầu luật định và chế định áp dụng cho sản phẩm, và d) mọi yêu cầu bổ sung được tổ chức cho là cần thiết. CHÚ THÍCH: Các hoạt động sau giao hàng bao gồm, ví dụ như, các hành động theo những điều khoản bảo hành, nghĩa vụ hợp đồng như dịch vụ bảo trì và các dịch vụ bổ trợ như tái chế hoặc loại bỏ cuối cùng.

7.2.1.1  Các yêu cầu liên quan đến khách hàng [TCVN ISO 9001:2008, 7.2.1 mục a) và b)]

Sản phẩm phần mềm có thể được phát triển như là một phần của hợp đồng, là một sản phẩm có sẵn để bán trên thị trường, là một phần mềm để cài vào trong hệ thống hay trong hệ thống hỗ trợ của các quá trình sản xuất của một tổ chức. Phải xác định các yêu cầu có thể có trong tất cả các ngữ cảnh này.

Các hoạt động cụ thể có thể là:

a) thiết lập các yêu cầu sau cho việc phát triển:

1) các phương pháp để thỏa thuận về các yêu cầu và các thay đổi liên quan đến bản quyền hay xuất xứ, đặc biệt khi hoạt động triển khai mang tính lặp lại;

2) các phương pháp để đánh giá các tính nguyên mẫu hoặc các dạng đề mô, nếu có sử dụng;

3) các phương pháp để ghi nhận và xem xét các kết quả thảo luận từ tất cả các bên tham gia;

b) khi triển khai các yêu cầu cần kết hợp chặt chẽ với khách hàng hoặc những người sử dụng và cần nỗ lực để tránh các hiểu nhầm, chẳng hạn, mục định nghĩa các thuật ngữ, giải thích nguồn gốc của các yêu cầu;

c) cách đạt được sự chấp nhận thông qua của khách hàng về các yêu cầu;

d) thiết lập phương pháp để đối chiếu lại theo các yêu cầu đối với thành phẩm (chẳng hạn nhờ ma trận đối chiếu các yêu cầu).

Các yêu cầu có thể do khách hàng nêu, do tổ chức hay do cả hai cùng thiết lập.

Khi các yêu cầu được nêu và được chấp thuận dưới dạng quy định mang tính hệ thống, cần có các phương pháp để phân định chúng vào các hạng mục phần mềm và phần cứng nhờ những quy định có tính giao thức bất kỳ thích hợp. Cần kiểm soát những thay đổi với các yêu cầu. Hợp đồng cũng cần sửa đổi khi các yêu cầu bị thay đổi.

Trong trường hợp hợp đồng, các yêu cầu có thể không được xác định một cách thật đầy đủ khi chấp nhận nó, một số các yêu cầu có thể được nêu bổ sung khi thực hiện dự án.

Các yêu cầu cần gắn với môi trường tác nghiệp. Các yêu cầu có thể bao gồm, nhưng không giới hạn đối với các đặc trưng sau: chức năng, tính tin cậy, độ khả dụng, tính hiệu quả, khả năng bảo trì và tính linh hoạt, tiện lợi. Một số đặc trưng khác cũng cần quy định, chẳng hạn, tính bảo mật, an toàn và các bổn phận tuân thủ luật pháp. Một số các đặc trưng này thuộc diện bắt buộc hoặc dạng chuẩn mực an toàn.

Nếu sản phẩm phần mềm cần giao diện với phần mềm hay các hệ thống sản phẩm khác, thì trong các quy định về giao diện giữa sản phẩm phần mềm được phát triển và phần mềm hay hệ các sản phẩm khác, cần xác định càng chi tiết càng tốt là giao diện trực tiếp hay giao diện dẫn xuất.

Các yêu cầu cần được biểu thị rõ ràng và các hạng mục dùng để thẩm định khi chấp nhận sản phẩm cần cụ thể, không mơ hồ. Các yêu cầu cần có khả năng nhận diện lại được trong suốt vòng đời phát triển (xem 7.5.2).

7.2.1.2  Các yêu cầu bổ sung do tổ chức tự xác định [TCVN ISO 9001:2008, 7.2.1 mục d)]

CHÚ THÍCH 1: Thông tin chi tiết hơn về mục 7.2.1.1, xem các tài liệu sau:

– ISO/IEC 12207:2008 ^[5] mục 6.4.2 (Quá trình phân tích các yêu cầu của hệ thống), mục 6.4.3 (Quá trình thiết kế cấu trúc hệ thống), 7.1.2 (Phân tích các yêu cầu phần mềm)

– ISO/IEC 12207:2011; ^[29]

– ISO/IEC 25010:2011; ^[24]

– ISO/IEC 25016-3:2011; ^[3]

CHÚ THÍCH 2: Thông tin chi tiết hơn về mục 7.2.1.2, xem ISO/IEC 25015:2006; ^[27]

7.2.2  Xem xét các yêu cầu liên quan đến sản phẩm

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 7.2.2  Xem xét các yêu cầu liên quan đến sản phẩm Tổ chức phải xem xét các yêu cầu liên quan đến sản phẩm. Việc xem xét này phải được tiến hành trước khi tổ chức cam kết cung cấp sản phẩm cho khách hàng (ví dụ như nộp đơn dự thầu, chấp nhận hợp đồng hay đơn đặt hàng, chấp nhận sự thay đổi trong hợp đồng hay đơn đặt hàng) và phải đảm bảo rằng a) yêu cầu về sản phẩm được định rõ; b) các yêu cầu trong hợp đồng hoặc đơn đặt hàng khác với những gì đã nêu trước đó phải được giải quyết; và c) tổ chức có khả năng đáp ứng các yêu cầu đã định. Phải duy trì hồ sơ các kết quả của việc xem xét và các hành động nảy sinh từ việc xem xét (xem 4.2.4). Khi khách hàng đưa ra các yêu cầu không bằng văn bản, các yêu cầu của khách hàng phải được tổ chức đó khẳng định trước khi chấp nhận. Khi yêu cầu về sản phẩm thay đổi, tổ chức phải đảm bảo rằng các tài liệu liên quan được sửa đổi và các cá nhân liên quan nhận thức được các yêu cầu thay đổi đó. CHÚ THÍCH: Trong một số tình huống, ví dụ như trong bán hàng qua internet, với mỗi lần đặt hàng, việc xem xét một cách chính thức là không thực tế. Thay vào đó, việc xem xét có thể được thực hiện đối với các thông tin liên quan về sản phẩm như danh mục chào hàng hay tài liệu quảng cáo.

7.2.2.1  Những vấn đề có liên quan của tổ chức

Các vấn đề có thể liên quan trong quá trình xem xét các gói thầu, hợp đồng hay đơn hàng phần mềm của tổ chức có thể bao gồm, nhưng không giới hạn ở:

a) tính khả thi trong việc đáp ứng và thỏa mãn hợp lý các yêu cầu cũng như các đặc trưng của sản phẩm, kể cả việc xác định các đặc trưng phần mềm đã đòi hỏi (ví dụ chức năng, tính khả dụng, khả năng bảo trì, tính gọn nhẹ, linh hoạt và tính hiệu quả);

b) các tiêu chuẩn và các thủ tục được sử dụng để thiết kế và phát triển phần mềm;

c) xác định cơ sở vật chất phương tiện, công cụ các hạng mục phần mềm và dữ liệu do khách hàng cung cấp, các định nghĩa và thông tin tài liệu của các phương pháp để đánh giá tính thích hợp cho việc sử dụng;

d) hệ thống vận hành hoặc phần nền hệ thống phần cứng;

e) thỏa thuận về việc kiểm soát các giao diện bên ngoài với sản phẩm phần mềm;

f) các yêu cầu liên quan đến việc sao lại các bản và phân phối;

g) các vấn đề liên quan đến khách hàng:

1) các quá trình vòng đời thuộc trách nhiệm của khách hàng;

2) khoảng thời gian bắt buộc tổ chức trong việc cung cấp các bản sao và khả năng đọc của các bản gốc.

h) các vấn đề về quản lý:

1) cần quản lý rủi ro (xem 7.2.2.2);

2) trách nhiệm của tổ chức đối với công việc dạng hợp đồng phụ;

3) lịch trình của các tiến trình, các cuộc xem xét về kỹ thuật và các đầu ra;

4) các yêu cầu cài đặt, bảo trì và hỗ trợ;

5) việc đáp ứng một cách kịp thời các nguồn lực tài chính, nhân lực, kỹ thuật;

i) những vấn đề liên quan đến tính tin cậy, bảo mật và luật pháp:

1) thông tin được quản lý trong hợp đồng có thể là đối tượng liên quan đến quyền sở hữu trí tuệ, những thỏa thuận được cấp phép, các yêu cầu mang tính luật pháp và chế định, các yêu cầu về bảo mật và bảo vệ thông tin kể cả các bằng sáng chế và các vấn đề về bản quyền;

2) tính được bảo vệ của bản gốc của sản phẩm và quyền của khách hàng được truy xuất hoặc kiểm tra xác nhận tính nguyên bản đó;

3) độ mở của thông tin đối với khách hàng mà điều đó cần được sự đồng thuận của các bên;

4) xác định các điều khoản về bảo hành;

5) trách nhiệm pháp lý/các hình phạt được nêu trong hợp đồng.

7.2.2.2  Các rủi ro

Khi xem xét các yêu cầu liên quan đến sản phẩm phần mềm. Cần cân nhắc các rủi ro sau:

a) các vấn đề an ninh, an toàn, mang tính chuẩn mực/giới hạn;

b) khả năng và kinh nghiệm của tổ chức hoặc người cung ứng của tổ chức;

c) tính tin cậy của những dự đoán về nguồn lực, thời hạn cần thiết với mỗi loại hoạt động;

d) những khác biệt quan trọng giữa các mốc thời gian đòi hỏi chuyển giao các sản phẩm hoặc dịch vụ và các mốc thời gian đã được xác định trong các kế hoạch có liên quan đến toàn bộ việc tối ưu hóa chi phí và các mục tiêu chất lượng;

e) sự phân tán đáng kể về mặt địa lý của tổ chức, khách hàng, những người sử dụng và cung cấp;

f) tính mới lạ về kỹ thuật cao, kể cả các phương pháp, công cụ, công nghệ và các phần mềm được cung cấp có tính mới lạ;

g) tình trạng kém chất lượng hoặc tính sẵn có của sản phẩm phần mềm và các công cụ được cung cấp;

h) tình trạng không đúng, thiếu chính xác, không ổn định trong việc xác định các yêu cầu của khách hàng và của các mối tương tác bên ngoài.

Cần đánh giá mối quan hệ mật thiết về bất kỳ sự thay đổi nào trong hợp đồng liên quan đến nguồn lực, tiến độ và chi phí, đặc biệt đối với những sự thay đổi về phạm vi, tính năng hay rủi ro.

7.2.2.3  Đại diện của khách hàng

Khách hàng cần có những đại diện đứng tên trong hợp đồng. Có nhiều vấn đề riêng biệt đòi hỏi có sự hợp tác của khách hàng với tổ chức để cung cấp kịp thời các thông tin cần thiết và cùng giải quyết các hạng mục công việc. Khi được chỉ định để giám sát mọi hoạt động của vòng đời, đại diện khách hàng cần đóng vai trò người sử dụng cuối cùng đối với sản phẩm cũng như vai trò của người quản lý điều hành và có quyền xử lý các vấn đề của hợp đồng, chẳng hạn, nhưng không giới hạn ở các nội dung sau:

a) xử lý các hạng mục phần mềm, dữ liệu, trang thiết bị, công cụ do chính khách hàng cung cấp nhưng bị phát hiện không thích hợp cho mục đích sử dụng;

b) tổ chức tiếp cận với những người sử dụng cuối cùng, nếu có thể;

Việc xem xét các yêu cầu có thể được tiến hành bởi các tổ chức bên trong hoặc bên ngoài. Nó có thể bao gồm việc xem xét các yêu cầu liên quan đến hợp đồng, công nghệ, việc bảo trì hay chất lượng.

CHÚ THÍCH: Thông tin chi tiết hơn về xem xét các yêu cầu, xem ISO/IEC 12207:2008, ^[5] mục 6.1.2 (quá trình cung cấp), mục 6.1.2.3.4.14 (kiểm tra xác nhận), mục 7.2.6 (quá trình xem xét). Thông tin chi tiết hơn về các yêu cầu công nghệ để tìm kiếm, phân tích, kiểm tra và thẩm định các yêu cầu của khách hàng, xem ISO/IEC 29148 ^[29]. Thông tin chi tiết hơn về quản lý rủi ro, xem ISO/IEC 12207:2008 ^[29] mục 6.3.4 (quản lý rủi ro) và ISO/IEC 16085:2006 ^[16]; Thông tin chi tiết hơn về xem xét các yêu cầu chất lượng bằng sử dụng các đặc trưng chất lượng, xem ISO/IEC 25010 ^[24].

7.2.3  Trao đổi thông tin với khách hàng

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 7.2.3  Trao đổi thông tin với khách hàng Tổ chức phải xác định và sắp xếp có hiệu quả việc trao đổi thông tin với khách hàng có liên quan tới a) thông tin về sản phẩm; b) xử lý các yêu cầu, hợp đồng hoặc đơn đặt hàng, kể cả các sửa đổi, và c) phản hồi của khách hàng, kể cả các khiếu nại.

7.2.3.1  Khái quát

Đối với phần mềm máy tính, phương pháp trao đổi thông tin có thể khác nhau lệ thuộc vào dạng thỏa thuận hợp đồng, vào phạm vi hợp đồng triển khai, các tác nghiệp hoặc việc bảo trì.

Những chỉ dẫn sau đây về trao đổi thông tin với khách hàng được tách thành chỉ dẫn cho các quá trình vòng đời liên quan đến phát triển và các quá trình vòng đời liên quan đến khai thác vận hành và bảo trì.

7.2.3.2  Trao đổi thông tin trong giai đoạn phát triển

Tổ chức và khách hàng cần cùng lập lịch trình tham gia xem xét một cách định kỳ hoặc tại những khâu/sự kiện có ý nghĩa của dự án nhằm bao quát một cách thích hợp các khía cạnh sau:

a) Thông tin sản phẩm, bao gồm:

1) các phương án phát triển,

2) sự phù hợp của các đầu ra, như các tài liệu thiết kế và phát triển tương ứng với các yêu cầu đã được chấp thuận của khách hàng,

3) những minh chứng của các đầu ra về các quá trình phát triển, chẳng hạn bản chạy thử, và

4) những kết quả thử nghiệm nghiệm thu.

b) Các đòi hỏi, hợp đồng và các sửa đổi, bao gồm:

1) tiến triển của các hoạt động liên quan những người sử dụng cuối cùng trong hệ thống đang được phát triển, chẳng hạn việc phân bổ nhân sự và đào tạo,

2) tiến triển của công việc phát triển sản phẩm phần mềm do tổ chức đảm nhận,

3) tiến triển của các hoạt động đã được thỏa thuận và do khách hàng đảm nhận,

4) xử lý các vấn đề quản lý rủi ro, các vấn đề và kiểm soát các hạng mục có thay đổi, và

5) các phương pháp mà theo đó khách hàng sẽ được chỉ dẫn về các thay đổi hiện tại hoặc những thay đổi đã xác định trong tương lai.

7.2.3.3  Trao đổi thông tin với khách hàng trong các quá trình khai thác và bảo trì phần mềm

Các nguồn thông tin cần đưa vào nội dung trao đổi với khách hàng trong quá trình khai thác và bảo trì có thể gồm:

a) Thông tin sản phẩm, bao gồm:

1) trợ giúp trực tuyến, sổ tay của người sử dụng mô tả sản phẩm và cách sử dụng nó,

2) mô tả các đặc điểm trong các lần phát hành hoặc nâng cấp mới, và

3) các trang web về sản phẩm;

b) Các đòi hỏi, hợp đồng và các sửa đổi, bao gồm:

1) tiến triển về việc chuyển giao sản phẩm hoặc dịch vụ và hoặc các hoạt động bảo trì, và

2) xử lý các rủi ro của sản phẩm hoặc dịch vụ, các vấn đề và những đòi hỏi sự thay đổi;

c) Phản hồi từ khách hàng, bao gồm:

1) cách bố trí trợ giúp và tính hữu hiệu;

2) tiến triển xử lý các khiếu nại của khách hàng, và

3) các khảo sát, các nhóm người sử dụng, các hội nghị.

CHÚ THÍCH: Thông tin chi tiết hơn, xem:

– ISO/IEC 12207:2008 [6] mục 7.2.6 (qua trình xem xét phần mềm), mục 6.1.2 (Quá trình trình cung cấp), mục 6.4.9.3.4 (Hỗ trợ khách hàng) và F.3 (Quá trình quản lý sự thay đổi hợp đồng).

– ISO/IEC 14764:2006 [8] (bảo trì phần mềm).

7.3  Thiết kế và phát triển

7.3.1  Hoạch định thiết kế và phát triển

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 7.3.1  Hoạch định thiết kế và phát triển Tổ chức phải lập kế hoạch và kiểm soát việc thiết kế và phát triển sản phẩm. Trong quá trình hoạch định thiết kế và phát triển tổ chức phải xác định a) các giai đoạn của thiết kế và phát triển, b) việc xem xét, kiểm tra xác nhận và xác nhận giá trị sử dụng thích hợp cho mỗi giai đoạn thiết kế và phát triển, và c) trách nhiệm và quyền hạn đối với các hoạt động thiết kế và phát triển. Tổ chức phải quản lý sự tương giao giữa các nhóm khác nhau tham dự vào việc thiết kế và phát triển nhằm đảm bảo sự trao đổi thông tin có hiệu quả và phân công trách nhiệm rõ ràng. Kết quả hoạch định phải được cập nhật một cách thích hợp trong quá trình thiết kế và phát triển. CHÚ THÍCH: Việc xem xét, kiểm tra xác nhận và xác nhận giá trị sử dụng của thiết kế và phát triển có các mục đích riêng biệt. Có thể tiến hành và lập hồ sơ riêng rẽ hoặc kết hợp các hoạt động này sao cho phù hợp với sản phẩm và tổ chức.

7.3.1.1  Hoạch định thiết kế và phát triển

Việc thiết kế và phát triển cần được tiến hành theo nguyên tắc chặt chẽ đã được xác định nhằm ngăn chặn hoặc giảm thiểu việc phát sinh các vấn đề. Cách tiếp cận này hạn chế sự lệ thuộc vào việc xác nhận giá trị sử dụng và việc kiểm tra xác nhận cũng như các phương pháp riêng lẻ để xác định các vấn đề. Vì vậy, tổ chức cần đảm bảo rằng các sản phẩm phần mềm được phát triển phù hợp với các yêu cầu đã định và phù hợp với kế hoạch thiết kế và phát triển và/hoặc kế hoạch chất lượng, (xem 7.1 – Kế hoạch chất lượng).

CHÚ THÍCH 1: ISO/IEC 12207 [5] nêu kế hoạch chất lượng và kế hoạch phát triển như là hoạt động lập kế hoạch riêng biệt để tạo nên (các) kế hoạch quản lý dự án. Phụ lục B nêu bảng dẫn chiếu cách để các mục trong 7.1.1 và 7.3.1 được đáp ứng theo các mục liên quan trong ISO/IEC 12207:2008 mục 6.1.23.4.5., 7.1.1.3.1.4 và 7.2.3.3.1.3.

CHÚ THÍCH 2: Một số mục trong danh mục dưới đây đã được nêu trong kế hoạch chất lượng cũng được liệt kê trong 7.1.2. Chúng được đánh dấu bằng ngoặc vuông.

Khi lập kế hoạch thiết kế và phát triển, nếu thích hợp, cần gắn với các hạng mục sau:

a) Các hoạt động liên quan phân tích các yêu cầu, thiết kế và phát triển, lập mã, tích hợp, thử nghiệm, cài đặt và hỗ trợ để nghiệm thu các sản phẩm phần mềm; nó bao gồm việc xác định hoặc viện dẫn đến;

1) các hoạt động cần được tiến hành;

2) các đầu vào đòi hỏi tương ứng với từng hoạt động;

3) các đầu ra đòi hỏi từ mỗi hoạt động

4) đòi hỏi kiểm tra với mỗi đầu ra của hoạt động [như 7.1.2 mục g)- xem 7.3.5];

5) các hoạt động hỗ trợ cần tiến hành cho việc quản lý

6) đòi hỏi đào tạo nhóm [như 7.1.2 mục k)];

b) Lập kế hoạch kiểm soát việc cung cấp sản phẩm và dịch vụ;

c) Việc tổ chức các nguồn lực cho dự án, bao gồm cơ cấu nhóm, trách nhiệm, việc sử dụng các nhà cung cấp và các nguồn vật liệu được sử dụng;

d) Các mối tương giao về tổ chức và kỹ thuật giữa các cá nhân hoặc các nhóm, như nhóm tiểu dự án, các nhà cung cấp, các bên thành viên, người sử dụng, các đại diện của khách hàng, đại diện về chất lượng (xem 7.3.1.4):

e) Phân tích các rủi ro có thể, các giả định, sự phụ thuộc và các vấn đề có liên quan tới thiết kế và phát triển;

f) Xác định lịch trình:

1) các giai đoạn của dự án [xem 7.1.2 mục j)];

2) cấu trúc phân chia công việc;

3) các nguồn lực và các mốc thời hạn liên quan;

4) các mối ràng buộc có liên quan;

5) những bước công việc chính;

6) các hoạt động kiểm tra xác định và thẩm định hiệu lực [như 7.1.2 mục g)];

g) Xác định rõ:

1) các tiêu chuẩn, quy tắc, quy phạm hoặc quy ước, phương pháp luận, mô hình vòng đời, các yêu cầu luật và chế định [như 7.1.2 mục d) và e)];

2) các công cụ và kỹ thuật để phát triển, kể cả việc đào tạo và kiểm soát cấu hình đã được vận dụng cho các công cụ và các kỹ thuật như vậy;

3) trang thiết bị dụng cụ, phần cứng và phần mềm cho việc triển khai;

4) kinh nghiệm thực tiễn về quản lý cấu hình [như 7.1.2 mục b)];

5) phương pháp kiểm soát các sản phẩm phần mềm không phù hợp;

6) phương pháp kiểm soát phần mềm được sử dụng để hỗ trợ cho hoạt động phát triển;

7) các thủ tục để lưu trữ, sao lưu, phục hồi và kiểm soát việc truy cập sản phẩm phần mềm;

8) các phương pháp kiểm soát phòng chống vi rút;

9) các biện pháp kiểm soát an ninh;

h) Việc xác định kế hoạch liên quan (kể cả kế hoạch hệ thống) cần gắn với các nội dung chính như chất lượng (xem 7.1), quản lý rủi ro, quản lý cấu hình, quản lý nhà cung cấp, việc tích hợp, thử nghiệm, quản lý việc phát hành, cài đặt, sự di chú (quá trình làm cho các ứng dụng hiện có có thể chạy trên các máy khác nhau hay các hệ điều hành khác nhau), bảo trì, tái sử dụng, thông tin và đo kiểm;

i) Kiểm soát thông tin tài liệu bao gồm việc lưu trữ và phân phối các bản ghi dạng hồ sơ và tài liệu;

Đối với sản phẩm có tính thương mại, trong đó tổ chức không cần kiểm soát toàn bộ việc thiết kế, tổ chức cần đảm bảo rằng, sản phẩm đáp ứng chuẩn mực nghiệm thu.

Kế hoạch hiện hành và bất kỳ kế hoạch nào đã có sự sửa đổi đều cần được định kỳ xem xét một cách thích hợp.

CHÚ THÍCH: Tài liệu xác định kế hoạch thiết kế và phát triển và bất kỳ những gì có liên quan các nội dung lập kế hoạch có thể là tài liệu độc lập, là một phần của tài liệu khác hoặc được lập từ một số tài liệu.

7.3.1.2  Xem xét, kiểm tra xác nhận và xác nhận giá trị sử dụng

Xem xét, kiểm tra xác nhận và xác nhận giá trị sử dụng thiết kế, triển khai sản phẩm phần mềm được nêu trong mục 7.3.4 tới mục 7.3.6. Trong việc sử dụng/chạy và bảo trì sản phẩm phần mềm, những việc này có thể nằm trong các thỏa thuận của các dạng dịch vụ hoặc các thủ tục bảo trì.

7.3.1.3  Trách nhiệm và quyền hạn

Phần này không có chỉ dẫn riêng.

7.3.1.4  Các mối tương giao

Các ranh giới trách nhiệm đối với mỗi phần của sản phẩm phần mềm và cách mà thông tin kỹ thuật sẽ được truyền giữa tất cả các bên cần được xác định rõ ràng trong kế hoạch thiết kế và phát triển của các nhà cung cấp. Tổ chức có quyền yêu cầu xem xét kế hoạch thiết kế và phát triển của nhà cung cấp.

Khi xác định các mối tương giao, ngoài khách hàng và bản thân tổ chức, cần quan tâm đến các bên là những người có quyền lợi trong các hoạt động thiết kế, phát triển, cài đặt, khai thác, bảo trì và đào tạo. Những người này có thể bao gồm đại diện khách hàng, những nhà cung cấp, các bên liên quan, đại diện về đảm bảo chất lượng, đại diện của các nhóm xử lý kỹ thuật, các tổ chức được ủy quyền về luật pháp, nhân viên triển khai dự án có liên quan, các nhân viên hỗ trợ trực tuyến. Cụ thể là, những người sử dụng cuối cùng và bất kỳ bộ phận tác nghiệp chức năng trung gian nào đều nên được tham gia để đảm bảo rằng năng lực và việc đào tạo thích ứng là có sẵn để đạt được các mức yêu cầu dịch vụ đã cam kết.

CHÚ THÍCH 1: Thông tin chi tiết về lập kế hoạch thiết kế và phát triển, xem ISO/IEC 12207:2008 ^[5] mục 6.3.1 (Quá trình lập kế hoạch dự án).

CHÚ THÍCH 2: Thông tin chi tiết về quản lý dự án phần mềm, xem ISO/IEC16326:2009 ^[12] mục 6.1 (Quá trình lập kế hoạch dự án).

7.3.2  Đầu vào của thiết kế và phát triển

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 7.3.2  Đầu vào của thiết kế và phát triển Đầu vào liên quan đến các yêu cầu đối với sản phẩm phải được xác định và duy trì hồ sơ (xem 4.2.4). Đầu vào phải bao gồm a) yêu cầu về chức năng và công dụng, b) yêu cầu luật định và chế định thích hợp, c) khi thích hợp thông tin nhận được từ các thiết kế tương tự trước đó, và d) các yêu cầu thiết yếu khác cho thiết kế và phát triển. Đầu vào này phải được xem xét về sự thỏa đáng. Các yêu cầu phải đầy đủ, rõ ràng và không mâu thuẫn với nhau.

Trong thiết kế cấu trúc hệ thống, các yêu cầu hệ thống được phân định cho phần cứng, các cấu thành phần mềm và các thao tác bằng tay. Các đầu vào cho việc phân tích các yêu cầu của sản phẩm phần mềm chính là các yêu cầu của hệ thống và chúng được phân định cho phần mềm và các quy định của các giao thức giữa các cấu thành của hệ thống.

Chỉ dẫn cho mục 7.3.2 điểm a], b] và d] trong TCVN ISO 9001:2008, xem 7.2.1.

Đầu vào của thiết kế và phát triển có thể được xác định từ các yêu cầu về chức năng, kết quả thực hiện, chất lượng và an toàn liên quan và các yêu cầu ràng buộc của chính thiết kế hệ thống, hoặc được suy ra qua các yêu cầu kỹ thuật ví dụ như bản mềm gốc. Đầu vào của thiết kế và phát triển cũng có thể được xác định từ các đòi hỏi thay đổi thiết kế của bản gốc ban đầu so với các giai đoạn trước đó trong mô hình phát triển lặp (chu kỳ), xuất phát các vấn đề cần được chỉnh sửa hoặc các yêu cầu nảy sinh từ các chuẩn mực nghiệm thu. Đầu vào cũng có thể xuất phát từ các hoạt động xem xét hợp đồng.

Khi các tài liệu đầu vào của thiết kế và phát triển được xem xét (điều này thường xảy ra với sự tham gia của khách hàng), họ cần soát lại:

a) Có hay không sự không rõ ràng, mâu thuẫn,

b) Tính không nhất quán, không đầy đủ hoặc không hợp lý của thông tin và các yêu cầu,

c) Các quy định kỹ thuật về kết quả đạt được là không khả thi,

d) Các yêu cầu không kiểm tra xác nhận hoặc không thẩm định được,

e) Các yêu cầu là giả định chứ không được công bố,

f) Mô tả không chính xác về môi trường sử dụng và các hoạt động

g) Thiếu các quyết định về thiết kế và phát triển trong tài liệu về các yêu cầu, và

h) Thiếu các thước đo kết quả thực hiện chủ chốt.

CHÚ THÍCH: Thông tin chi tiết hơn, xem ISO/IEC 25010:2011^[24] đối với các yêu cầu chất lượng sản phẩm phần mềm biểu thị qua các đặc tính chất lượng phần mềm.

7.3.3  Các đầu ra của thiết kế và phát triển

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 7.3.3  Các đầu ra của thiết kế và phát triển Đầu ra của thiết kế và phát triển phải ở dạng thích hợp để kiểm tra xác nhận theo đầu vào của thiết kế và phát triển và phải được phê duyệt trước khi ban hành. Đầu ra của thiết kế và phát triển phải a) đáp ứng các yêu cầu đầu vào của thiết kế và phát triển, b) cung cấp các thông tin thích hợp cho việc mua hàng, sản xuất và cung cấp dịch vụ, c) bao gồm hoặc viện dẫn tới các chuẩn mực chấp nhận của sản phẩm, và d) xác định các đặc tính cốt yếu cho an toàn và sử dụng đúng của sản phẩm. CHÚ THÍCH: Thông tin cho quá trình sản xuất và cung cấp dịch vụ có thể bao gồm chi tiết về việc bảo toàn sản phẩm.

Đầu ra từ quá trình thiết kế và phát triển cần được xác định và lập văn bản phù hợp với những gì đã tuân thủ hoặc phương pháp đã được chọn. Đầu ra cần đầy đủ, chính xác và nhất quán với các yêu cầu, chúng có thể được tạo ra nhờ sử dụng các công cụ máy tính trong thiết kế và phát triển. Các đầu ra thiết kế và phát triển cần được biểu thị dưới dạng văn bản, các đồ thị hoặc sử dụng cách ghi nhận dạng ký hiệu mô hình hóa, và có thể bao gồm:

a) Các quy định kỹ thuật về thiết kế, phát triển và thử nghiệm,

b) Các kiểu dữ liệu,

c) Mã giả hoặc mã nguồn,

d) Các chỉ dẫn cho người sử dụng, thông tin tài liệu cho người thao tác, tài liệu đào tạo, tài liệu bảo dưỡng,

e) Sản phẩm đã được phát triển, và

f) Các phương pháp mang tính chính thống.

Bản sao phần mềm, nếu được sử dụng nên được xem là dạng thông tin tài liệu (đầu ra) của thiết kế và phát triển.

Tiêu chí nghiệm thu đối với các đầu ra của thiết kế và phát triển cần được xác định sao cho có thể minh chứng rằng các đầu vào đối với mỗi giai đoạn thiết kế và phát triển đều được phản ánh đúng trong các đầu ra.

Các công cụ cần được thẩm định tính hiệu lực theo các mục đích sử dụng cụ thể đã định của chúng (xem 7.3.6 và 7.6).

CHÚ THÍCH: Thông tin chi tiết hơn, xem ISO/IEC 122207:2008^[5] mục 7.1.3 và 7.1.5 (Quá trình thiết kế cấu trúc phần mềm, quá trình thiết kế chi tiết phần mềm, quá trình xây dựng phần mềm)

7.3.4  Xem xét thiết kế và phát triển

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 7.3.4  Xem xét thiết kế và phát triển Tại những giai đoạn thích hợp, việc xem xét thiết kế và phát triển một cách có hệ thống phải được thực hiện theo hoạch định (xem 7.3.1) để a) đánh giá khả năng đáp ứng các yêu cầu của các kết quả thiết kế và phát triển, và b) nhận biết mọi vấn đề trục trặc và đề xuất các hành động cần thiết. Những người tham gia vào việc xem xét phải bao gồm đại diện của tất cả các bộ phận chức năng liên quan tới (các) giai đoạn thiết kế và phát triển đang được xem xét. Phải duy trì hồ sơ về các kết quả xem xét và mọi hành động cần thiết (xem 4.2.4).

Mức độ chính thức và chặt chẽ của các hoạt động gắn với quá trình xem xét cần thích ứng với tính phức tạp của sản phẩm, các yêu cầu chất lượng và mức rủi ro liên quan khi sử dụng riêng biệt sản phẩm phần mềm. Tổ chức cần thiết lập các thủ tục để xử lý các quá trình và sản phẩm bị sai lỗi hoặc những sự không phù hợp được xác định trong các hoạt động này (xem 8.3). Các thủ tục này nên được lập thành văn bản.

Trong quá trình xem xét thiết kế và phát triển, cần lưu ý các chuẩn mực về tính hợp lý, an ninh, an toàn, các quy định về lập trình và khả năng thử nghiệm.

CHÚ THÍCH 1: ISO/IEC 122207:2008^[5] việc xem xét xử lý cách quản lý dự án và việc xem xét về mặt kỹ thuật là các hoạt động tách biệt. Bảng tra cứu đối chiếu cho ở phụ lục B cho thấy các mục có liên quan như thế nào với danh mục mà mục 7.2.6 trong ISO/IEC 12207:2008 ^[5] đã nêu.

Việc xem xét thiết kế và phát triển cần được tiến hành theo những sắp xếp đã định. Các yếu tố cần cân nhắc khi xem xét là:

a) Điều gì cần xem xét, khi nào và kiểu xem xét, chẳng hạn để minh chứng, để phòng tránh một cách bài bản các sai sót, để kiểm tra, soát xét lại toàn bộ các bước hay cách cùng hợp tác xem xét;

b) Các nhóm chức năng nào được xem là có liên quan trong mỗi dạng xem xét và nếu có cuộc họp về xem xét thì cuộc họp đó được tổ chức và tiến hành ra sao;

c) Phải lập các hồ sơ gì, ví dụ biên bản họp, các vấn đề phát sinh, các khó khăn, các hành động và tình trạng hiện đạt được của các hành động;

d) Các phương pháp để giám sát việc áp dụng các quy tắc, quy định, và các thỏa thuận để đảm bảo các yêu cầu được đáp ứng

e) Những gì cần tiến hành trước khi xem xét, chẳng hạn như xác lập các mục tiêu, lịch trình họp, các tài liệu cần thiết và vai trò của những người xem xét;

f) Những gì cần làm trong khi xem xét, kể cả các kỹ thuật được sử dụng và các chỉ dẫn cho những người tham gia;

g) Các tiêu chí thành công đối với việc xem xét;

h) Những công việc tiếp theo cần làm để đảm bảo các vấn đề đã được xác định khi xem xét sẽ được giải quyết.

Những hoạt động thiết kế và phát triển chi tiết hơn chỉ được tiến hành khi hiểu được hậu quả của những sự khác biệt đã được phát hiện hoặc hiểu được rủi ro của việc xử lý chúng theo cách đã biết hoặc đã được thỏa thuận. Mọi phát hiện cần được nêu và giải quyết một cách thích ứng.

CHÚ THÍCH 2: Thông tin chi tiết hơn, xem ISO/IEC 12207:2008^[5] mục 7.1.2.3.1.2, 7.1.3.3.1.6, và 7.1.4.3.1.7 (các yêu cầu và các đánh giá định lượng thiết kế) và mục 7.2.6.3.3 (các xem xét kỹ thuật).

7.3.5  Kiểm tra xác nhận thiết kế và phát triển

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 7.3.5  Kiểm tra xác nhận thiết kế và phát triển Việc kiểm tra xác nhận phải được thực hiện theo các bố trí đã hoạch định (xem 7.3.1) để đảm bảo rằng đầu ra thiết kế và phát triển đáp ứng các yêu cầu đầu vào của thiết kế và phát triển. Phải duy trì hồ sơ các kết quả kiểm tra xác nhận và mọi hành động cần thiết (xem 4.2.4).

Việc kiểm tra xác nhận sản phẩm phần mềm nhằm cung cấp sự đảm bảo rằng đầu ra của hoạt động thiết kế và phát triển phù hợp với các yêu cầu đầu vào.

Việc kiểm tra xác nhận cần được tiến hành một cách thích hợp trong hoạt động thiết kế và phát triển. Việc kiểm tra xác nhận có thể bao gồm các xem xét đầu ra của thiết kế và phát triển (ví dụ qua việc kiểm tra hoặc rà lại tất cả các bước), các phân tích, các minh chứng kể cả các phần mềm chạy thử đầu tiên, các mô phỏng hoặc các thử nghiệm. Việc kiểm tra xác nhận có thể được tiến hành dựa trên các đầu ra của các hoạt động khác nhau, ví dụ của các sản phẩm thương mại có sẵn để bán (COTS), các sản phẩm được mua và các sản phẩm của khách hàng cung cấp.

Các kết quả kiểm tra xác nhận và mọi hành động tiếp theo cần được lập thành hồ sơ và rà soát lại khi các hoạt động đó đã được hoàn thành.

Khi cấp các giấy chứng nhận liên quan đến quy mô, tính phức tạp hay những chuẩn mực tới hạn của sản phẩm phần mềm nên sử dụng các phương pháp kiểm tra xác nhận có sự đảm bảo cụ thể, chẳng hạn tùy trường hợp, sử dụng các thước đo độ phức tạp, các cách xem xét đồng đẳng, các phương pháp liên quan mức độ bao quát về các điều kiện hay quyết định hoặc các phương pháp mang tính chính tắc.

Chỉ khi các đầu ra của thiết kế và phát triển đã được kiểm tra xác nhận nó mới được trình để chấp nhận và cho việc sử dụng tiếp theo. Mọi phát hiện cần được đề cập và xử lý một cách thích hợp.

CHÚ THÍCH: Thông tin chi tiết hơn, xem ISO/IEC 12207:2008^[5] mục 6.4 (Các quá trình kỹ thuật) và mục 7.2.4 (Kiểm tra xác nhận).

7.3.6  Xác nhận giá trị sử dụng của thiết kế và phát triển

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 7.3.6  Xác nhận giá trị sử dụng của thiết kế và phát triển Xác nhận giá trị sử dụng của thiết kế và phát triển phải được tiến hành theo các bố trí đã hoạch định (xem 7.3.1) để đảm bảo rằng sản phẩm tạo ra có khả năng đáp ứng các yêu cầu sử dụng dự kiến hay các ứng dụng quy định khi đã biết. Khi có thể, phải tiến hành xác nhận giá trị sử dụng trước khi chuyển giao hay sử dụng sản phẩm. Phải duy trì hồ sơ các kết quả của việc xác nhận giá trị sử dụng và mọi hành động cần thiết (xem 4.2.4).

7.3.6.1  Xác nhận giá trị sử dụng

Việc xác nhận giá trị sử dụng của sản phẩm phần mềm nhằm cung cấp độ tin cậy thích ứng rằng sản phẩm đáp ứng các yêu cầu chức năng của nó.

Trước khi chào sản phẩm để khách hàng chấp nhận, tổ chức cần xác nhận giá trị sử dụng về mặt chức năng của sản phẩm đó theo mục đích sử dụng cụ thể đã định trong các điều kiện tương tự như môi trường sử dụng đã quy định trong hợp đồng. Bất kỳ sự khác biệt nào giữa môi trường thẩm định và môi trường áp dụng thực tế và các rủi ro do những sự khác biệt đó đều cần được xác định, đánh giá và lập thành hồ sơ càng sớm càng tốt ngay trong giai đoạn đầu của vòng đời. Trong quá trình xác nhận giá trị sử dụng, khi có thể, nên tiến hành các đánh giá cấu hình trước khi cho phát hành nền cấu hình cơ sở. Đánh giá cấu hình hay các hoạt động đánh giá thẩm định có thể thực hiện nhờ việc xem xét, kiểm tra hay các hồ sơ thử nghiệm cho thấy sản phẩm phần mềm phù hợp với các yêu cầu đã được quy định hoặc đã được nêu trong hợp đồng. Việc này có thể đòi hỏi phân tích, lập mô hình giả định, mô phỏng nếu như khi đó không thể tiến hành xác nhận trong điều kiện giống như sử dụng thực tế.

Trong phát triển phần mềm, điều quan trọng là các kết quả xác nhận giá trị sử dụng và mọi hành động tiếp theo nhằm đáp ứng các yêu cầu đã được nêu cần được lập hồ sơ và được kiểm tra đối chiếu lại khi các hành động đó đã được thực hiện xong.

Trong một số trường hợp, có thể thực hiện được hoặc có thể không, thông qua đo và giám sát, ta có thể xác nhận đầy đủ giá trị sử dụng sản phẩm phần mềm. Ví dụ trường hợp tại đó, sản phẩm phần mềm có liên quan đến tính an toàn không thể được thử nghiệm trong các điều kiện thực mà lại không có các hậu quả mang tính rủi ro nghiêm trọng, hoặc có thể, bản thân các bối cảnh thực là rất hiếm hoặc rất khó để mô phỏng.

Việc không thể thử nghiệm được một cách thấu đáo và thuyết phục một số sản phẩm phần mềm có thể buộc tổ chức cần cân nhắc:

a) đã đạt được tính tin cậy ở mức độ nào từ việc phát triển và các công cụ đã được sử dụng, và

b) những kiểu thử nghiệm hay phân tích nào có thể tiến hành để nâng cao tính tin cậy rằng sản phẩm sẽ thể hiện một cách chuẩn xác ngay cả trong các bối cảnh “không thể thử nghiệm được”, ví dụ như việc phân tích mã nguồn tĩnh.

Dù sử dụng phương pháp nào, chúng đều cần tương xứng với rủi ro và các hậu quả của từ các sai lỗi của hoạt động thiết kế và phát triển.

7.3.6.2  Thử nghiệm

Việc xác nhận giá trị sử dụng có thể đòi hỏi thử nghiệm. Thử nghiệm có thể cần tiến hành ở một số mức, từ sản phẩm phần mềm riêng biệt đến sản phẩm phần mềm hoàn chỉnh. Có một số cách tiếp cận khác nhau về thử nghiệm, về quy mô thử nghiệm và mức độ của các hoạt động kiểm soát về môi trường thử nghiệm, các kết quả đầu vào và kết quả đầu ra thử nghiệm có thể khác nhau do các cách tiếp cận này, do tính phức tạp của sản phẩm và rủi ro liên quan với việc sử dụng sản phẩm. Kế hoạch thử nghiệm gắn liền với kiểu thử nghiệm, với các mục đích, tuần tự và phạm vi thử nghiệm, với tình huống thử nghiệm, với dữ liệu thử và với các kết quả được mong đợi. Kế hoạch thử nghiệm cần xác định nhân lực và nguồn lực vật lý cần thiết cho việc thử và cần xác định rõ trách nhiệm của những người tham gia.

Việc thử nghiệm cụ thể đối với sản phẩm phần mềm sẽ bao gồm các phương án về xác lập, xây dựng tài liệu, xem xét và áp dụng các nội dung sau:

a) Các thử nghiệm đơn vị, tức là các thử nghiệm riêng lẻ, tách biệt của phần cấu thành của phần mềm;

b) Các thử nghiệm tích hợp hoặc hệ thống, tức các phép thử các bộ ghép các cấu thành của sản phẩm phần mềm (và cả hệ thống hoàn chỉnh);

c) Các phép thử phân loại, tức thử các sản phẩm phần mềm hoàn chỉnh trước khi cung cấp để khẳng định sản phẩm phần mềm đáp ứng các yêu cầu đã được xác định của nó;

d) Thử nghiệm thu, tức thử sản phẩm phần mềm hoàn chỉnh nhằm khẳng định sản phẩm phần mềm đáp ứng các chuẩn mực nghiệm thu của nó.

Phép thử tình trạng suy thoái nên được thực hiện để kiểm tra hoặc xác nhận rằng những tính năng của sản phẩm phần mềm không bị suy giảm bởi những thay đổi.

Các phép thử nghiệm thu là những phép thử được tiến hành phục vụ lợi ích của khách hàng xác định tình trạng chấp nhận được của sản phẩm.

Các công cụ và môi trường thử nghiệm được sử dụng cần được kiểm soát và đánh giá phân loại, cần ghi nhận bất kỳ sự giới hạn nào đối với phép thử.

Các thủ tục thử nghiệm cần nêu cả cách ghi nhận hồ sơ, cách phân tích các kết quả cũng như các vấn đề và quản lý sự thay đổi.

CHÚ THÍCH: Thông tin chi tiết hơn, xem ISO/IEC 12207:2008^[5] mục 6.4 (Các quá trình kỹ thuật) và mục 7.2.5 (Xác nhận giá trị sử dụng), Thông tin chi tiết hơn về kiểm tra xác nhận thông qua đánh giá chất lượng nhờ sử dụng các thước đo và đặc trưng chất lượng, xem ISO/IEC 25010^[24] và bộ ISO/IEC 25000.

7.3.7  Kiểm soát thay đổi thiết kế và phát triển

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 7.3.7  Kiểm soát thay đổi thiết kế và phát triển Những sự thay đổi của thiết kế và phát triển phải được nhận biết và duy trì hồ sơ. Những thay đổi này phải được xem xét, kiểm tra xác nhận và xác nhận giá trị sử dụng một cách thích hợp và được phê duyệt trước khi thực hiện. Việc xem xét các thay đổi thiết kế và phát triển phải bao gồm việc đánh giá tác động của sự thay đổi lên các bộ phận cấu thành và sản phẩm đã được chuyển giao. Phải duy trì hồ sơ các kết quả của việc xem xét các thay đổi và hành động cần thiết (xem 4.2.4).

Trong môi trường phát triển phần mềm, hoạt động kiểm soát những thay đổi trong thiết kế và phát triển thường được xử lý như một phần của quản lý cấu hình.

Những thay đổi đối với các quy định kỹ thuật hay cấu thành của sản phẩm phần mềm cần được theo dõi một cách thích ứng, nhất quán giữa các hạng mục về các yêu cầu, về thiết kế, về mã, về các quy định kỹ thuật trong thử nghiệm, về tài liệu hướng dẫn cho người sử dụng và các hạng mục bổ sung khác, nếu có liên quan.

CHÚ THÍCH 1  Thông tin chi tiết hơn, xem ISO/IEC 12207:2008^[5] mục 6.4.10.3.2 và 6.4.10.3.3 (Những cách điều chỉnh); mục 6.3.6 và 7.2.1 (Lập tài liệu); mục 6.3.5.và 7.2.2 (Quản lý cấu hình).

CHÚ THÍCH 2  Đối với chỉ dẫn chung hơn liên quan tới TCVN ISO 9001:2008, mục 7.3, xem các tài liệu sau:

– ISO/IEC 25051:2006 ^[27] nêu các chỉ dẫn liên quan bất kỳ sản phẩm phần mềm thương mại làm sẵn để bán (COTS) đã được mua;

– ISO/IEC 26514:2008 ^[28] nêu các chỉ dẫn về lập tài liệu thiết kế và phát triển;

– ISO/IEC 19761:2011 ^[18], ISO/IEC 20926:2009 ^[21] và ISO/IEC 20968:2002 ^[20] nêu các chỉ dẫn về các phương pháp ước lượng dung lượng

– ISO/IEC/TR 14759:1999 ^[7] chỉ dẫn về cách phân loại các phần mềm chạy thử và các ví dụ áp dụng:

– ISO/IEC 26514:2008 ^[28] nêu chỉ dẫn quá trình lập tài liệu cho người sử dụng phần mềm.

7.4  Mua hàng

7.4.1  Quá trình mua hàng

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 7.4.1  Quá trình mua hàng Tổ chức phải đảm bảo sản phẩm mua vào phù hợp với các yêu cầu mua sản phẩm đã quy định. Cách thức và mức độ kiểm soát áp dụng cho người cung ứng và sản phẩm mua vào phụ thuộc vào sự tác động của sản phẩm mua vào đối với việc tạo ra sản phẩm tiếp theo hay thành phẩm. Tổ chức phải đánh giá và lựa chọn người cung ứng dựa trên khả năng cung cấp sản phẩm phù hợp với các yêu cầu của tổ chức. Phải xác định các tiêu chí lựa chọn, đánh giá và đánh giá lại. Phải duy trì hồ sơ các kết quả của việc đánh giá và mọi hành động cần thiết nảy sinh từ việc đánh giá (xem 4.2.4).

7.4.1.1  Các sản phẩm được mua

Đối với các mục đích nêu ở 7.4.1, sản phẩm phần mềm tự do (chẳng hạn các công cụ phát triển nguồn mở), cần được xem là dạng phải mua.

Trong phát triển, cung cấp, cài đặt và bảo trì các sản phẩm phần mềm, các dạng sản phẩm được mua có thể gồm:

a) Các phần mềm thương mại làm sẵn để bán (COTS) hay các phần mềm dùng chung (Những phần mềm có bản quyền, mọi người đều sử dụng được nếu có cơ sở pháp lý và có chi trả một khoản lệ phí cho tác giả của phần mềm đó-ND);

b) Phần mềm và các dịch vụ mang tính riêng biệt theo nghĩa phù hợp với đặt hàng;

c) Những kết quả phát triển được thực hiện qua hợp đồng phụ;

d) Những hoạt động sử dụng nguồn lực bên ngoài (ví dụ kiểm tra, kiểm tra xác nhận và xác nhận giá trị sử dụng độc lập, quản lý trang thiết bị dụng cụ);

e) Các công cụ dùng trợ giúp trong việc phát triển phần mềm (ví dụ các công cụ để quản lý cấu hình hay quản lý thiết kế và phát triển, những công cụ phân tích mã, các bộ gỡ lỗi – một trình tiện ích, thường có trong các chương trình thông dịch hoặc biên dịch, nhằm giúp cho lập trình viên có thể tìm và sửa các lỗi cú pháp và các lỗi khác trong mã nguồn – ND, các bộ phân tích thử nghiệm, các bộ tạo nguồn, các trình biên dịch);

f) Máy tính và phần mềm để trao đổi các thông tin;

g) Các cấu thành cơ bản (ví dụ các mạch tích hợp có thể là đối tượng bị thay đổi hoặc không đảm bảo được cho tính liên tục khả dụng);

h) Người sử dụng và việc lập tài liệu của sản phẩm;

i) Các khóa và các tài liệu đào tạo.

Hình thức và mức độ mà tổ chức cần kiểm soát người cung cấp thực hiện việc thiết kế và phát triển theo dạng hợp đồng phụ (ví dụ trong các dự án dạng đồng thực hiện) sẽ trở thành đặc biệt quan trọng trong lựa chọn nhà cung cấp bởi vì, đôi khi tính tin cậy trong mối quan hệ lại có thể gây ảnh hưởng nghiêm trọng cho sự thành công của sự tiến triển.

Trong phát triển, cung cấp, cài đặt và bảo trì các sản phẩm phần mềm, đối với các sản phẩm được mua, có thể đòi hỏi tổ chức cần cân nhắc việc quản lý các rủi ro liên quan việc cấp giấy phép, bảo trì, trợ giúp trực tuyến và các dịch vụ hỗ trợ khách hàng (chẳng hạn việc luôn có sẵn hoạt động hỗ trợ cho sản phẩm đã được mua cho dù nó được chuyển giao muộn). Một cách để xác định năng lực của các nhà cung cấp tạo được sản phẩm phần mềm có khả năng được nghiệm thu là dựa vào việc tiến hành đánh giá quá trình. Việc đánh giá quá trình nêu các thông tin cho việc đánh giá rủi ro và xem xét lại mức độ thuần thục, năng lực trong các quá trình của nhà cung cấp

7.4.1.2  Kiểm soát sản phẩm được mua

Khi các sản phẩm nêu từ mục h) tới mục i) trong 7.4.1.1 được mua và được dự định là một phần của sản phẩm, chúng cần được kiểm soát như các cấu thành trong suốt các hoạt động thiết kế và phát triển. Những điểm cần cân nhắc của hợp đồng cần được giải quyết để đảm bảo rằng những việc kiểm soát như vậy đã được tiến hành và đảm bảo việc quản lý cấu hình là hiệu quả.

Cần đặc biệt lưu ý để đảm bảo rằng nhân viên hợp đồng đòi hỏi có kỹ năng và trình độ riêng biệt về năng lực trước khi họ được đưa vào như một bộ phận của nhóm dự án.

Có thể cần tiến hành đánh giá lại kết quả thực hiện của nhà cung cấp qua việc xem xét và kiểm soát định kỳ các hoạt động thiết kế và phát triển và xem đó như là một phần của việc quản lý dự án (xem 7.3.1).

Trong một số trường hợp, có thể áp dụng toàn bộ hạng mục mối quan hệ giữa nhà cung cấp và tổ chức, như nêu trong TCVN ISO 9001:2008. Trong phát triển phần mềm, việc quản lý rủi ro thường sẽ được chú trọng hơn do bản chất của loại sản phẩm phần mềm.

Các nhà cung cấp được lực chọn dựa trên việc đánh giá các yêu cầu và năng lực quá trình của họ cũng như các yếu tố khác, chẳng hạn, như phân tích lịch sử kết quả thực hiện của họ, xem xét những phản hồi đối với các vấn đề của nhà cung cấp, xem xét các phương án kiểm tra xác nhận, phương án chất lượng có liên quan sản phẩm phần mềm.

CHÚ THÍCH 1  Thông tin chi tiết hơn, xem ISO/IEC 12207:2008^[51] mục 6.1.1 (quá trình mua hàng)

CHÚ THÍCH 2  Thông tin chi tiết hơn về đánh giá năng lực quá trình của nhà cung cấp, xem ISO/IEC 15504-3^[12]

7.4.2  Thông tin mua hàng

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 7.4.2  Thông tin mua hàng Thông tin mua hàng phải miêu tả sản phẩm được mua, nếu thích hợp có thể bao gồm a) yêu cầu về phê duyệt sản phẩm, các thủ tục, quá trình và thiết bị, b) yêu cầu về trình độ con người, và c) yêu cầu về hệ thống quản lý chất lượng. Tổ chức phải đảm bảo sự thỏa đáng của các yêu cầu mua hàng đã quy định trước khi thông báo cho người cung ứng.

Thông tin mua đối với sản phẩm phần mềm, khi có thể, cần bao gồm:

a) Nhận dạng sản phẩm được đặt hàng (chẳng hạn tên sản phẩm, số lượng, phiên bản số, cấu hình),

b) Các yêu cầu hoặc thủ tục để xác định các yêu cầu đối với những gì mà tại thời điểm đặt hàng chưa khẳng định được,

c) Các tiêu chuẩn được áp dụng (chẳng hạn, các phương thức xác lập trao đổi thông tin của bản mềm chạy thử, quy định kỹ thuật về cấu trúc, các tiêu chuẩn mã),

d) Các thủ tục và/hoặc hướng dẫn công việc mà người cung cấp cần tuân theo,

e) Mô tả về môi trường phát triển (ví dụ phần cứng, các công cụ phát triển, các trang thiết bị liên quan),

f) Mô tả môi trường mục tiêu (ví dụ phần mềm, hệ thống vận hành), và

g) Các yêu cầu đối với nhân sự (ví dụ các yêu cầu về đào tạo, hiểu biết về sản phẩm)

Những nội dung cần cân nhắc nêu trong 7.2.2 cũng cần được áp dụng đối với các hợp đồng phụ.

CHÚ THÍCH 1: Thông tin chi tiết hơn, xem ISO/IEC 12207:2008^[5] mục 6.1.1.3.1 (Việc chuẩn bị các yêu cầu) và 6.1.1.3.2 (những yêu cầu liên quan quảng cáo)

7.4.3  Kiểm tra xác nhận sản phẩm mua vào

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 7.4.3  Kiểm tra xác nhận sản phẩm mua vào Tổ chức phải lập và thực hiện các hoạt động kiểm tra hoặc các hoạt động khác cần thiết để đảm bảo rằng sản phẩm mua vào đáp ứng các yêu cầu mua hàng đã quy định. Khi tổ chức hoặc khách hàng có ý định thực hiện các hoạt động kiểm tra xác nhận tại cơ sở của người cung ứng, tổ chức phải công bố việc sắp xếp kiểm tra xác nhận dự kiến và phương pháp thông qua sản phẩm trong thông tin mua hàng.

Việc kiểm tra xác nhận này có thể áp dụng cho thử nghiệm nghiệm thu các sản phẩm phần mềm được mua để dùng trong phát triển. Vì hầu hết các sản phẩm phần mềm đều không thể được kiểm tra xác nhận một cách kỹ lưỡng do tính năng mở rộng của nó. Vì vậy, tổ chức được quyền chọn mang tính giả định ở một mức độ hợp lý nào đó để tiến hành thử nghiệm thu và đảm bảo có sẵn sự hỗ trợ thích ứng.

Trường hợp có một phần việc phát triển sản phẩm phần mềm được thực hiện dưới dạng hợp đồng phụ hoặc việc mua phần cứng và phần mềm có liên quan đến nhà thầu phụ, tổ chức cần xác định các phương pháp để kiểm tra xác nhận, thẩm định và nghiệm thu phần công việc đã được thực hiện dưới dạng hợp đồng phụ để đảm bảo nó sẽ đạt được. Trường hợp phần mềm được phát triển qua hợp đồng phụ sẽ được tích hợp với phần mềm được phát triển bởi chính tổ chức, thì cần có những cân nhắc khác nữa đi kèm với các phương pháp và công cụ được sử dụng trong việc phát triển này. Chẳng hạn có thể tổ chức hay chính khách hàng sẽ cần kiểm tra. Những nội dung cần cân nhắc chung đối với việc áp dụng thử nghiệm được nêu trong 8.2.4.

Tổ chức có thể được yêu cầu thu được và đưa vào các sản phẩm phần mềm, kể cả các dữ liệu hoặc các dịch vụ như nhân viên hợp đồng, do bên thứ ba cung cấp. Tổ chức cần kiểm tra xác nhận sản phẩm và dịch vụ trước khi nhận, lưu ý nội dung các yêu cầu của hợp đồng. Các phương pháp để kiểm tra xác nhận sản phẩm có thể được xác định như là một phần của các yêu cầu mua (chẳng hạn như việc thử nghiệm nghiệm thu). Nên cân nhắc các chỉ dẫn về kiểm tra xác nhận và thẩm định được nêu trong mục 7.3.5 và 7.3.6. Với nhân viên hợp đồng, cần cân nhắc tình trạng được giáo dục, đào tạo, kỹ năng và kinh nghiệm của những người liên quan các nội dung như ngôn ngữ lập trình, các công cụ phát triển về quản lý hệ thống.

Khi mua hoặc thu nhận các dữ liệu, cần cân nhắc cẩn thận về định dạng, phương tiện lưu giữ, dung lượng, nguồn và nội dung dữ liệu đã thu được (ví dụ dữ liệu thử nghiệm do bên thứ ba lập). Trong một số trường hợp, các yêu cầu mang tính luật pháp về bảo vệ dữ liệu cũng có thể liên quan (ví dụ tính bảo mật).

Khi mua hoặc thu nhận các dữ liệu, cần cân nhắc cẩn thận về định dạng và phương tiện lưu giữ mà theo đó nó được cung cấp để đảm bảo các yêu cầu về tính năng vận hành được đáp ứng. Những yêu cầu về chức năng và kết quả thực hiện của sản phẩm cần được thử nghiệm trước khi sử dụng để đảm bảo sản phẩm thực hiện được chúng như đã quy định. Sản phẩm cũng có thể cần thẩm định theo các nhu cầu của thành phẩm nếu như điều này đòi hỏi là phải đáp ứng.

Vì không phải luôn có thể thử nghiệm sản phẩm tại thời điểm tiếp nhận, nên điều quan trọng là phải đảm bảo rằng nó sẽ được thử nghiệm trước khi sử dụng hay trước khi đưa nó gộp chung vào thành phẩm. Những yêu cầu thử nghiệm như vậy cũng có thể tiến hành tại các bước thực hiện của nhà cung cấp. Tại các bước thực hiện của tổ chức cũng cần lưu ý để đảm bảo rằng các biện pháp thích hợp đã được thực hiện để xử lý tách biệt sản phẩm đến mức đảm bảo rằng toàn bộ thực thể của nó được xác định đầy đủ (ví dụ ảnh hưởng của vi rút).

Có thể sử dụng hồ sơ đánh giá phân loại và hồ sơ đào tạo để trợ giúp việc kiểm tra xác nhận nhân viên hợp đồng.

CHÚ THÍCH 1  Thông tin chi tiết hơn, xem ISO/IEC 12207-.2008^[5] mục 6.1.1.3.6 (Khâu nghiệm thu – Người nghiệm thu)

CHÚ THÍCH 2  Chỉ dẫn chung hơn liên quan tới TCVN ISO 9001:2008 ^[5], mục 7.4, xem:

– ISO/IEC 25010:2011^[24] chỉ dẫn về các đặc trưng chất lượng thích ứng cho việc mua sản phẩm phần mềm;

– ISO/IEC 25040^[25] và ISO/IEC 25041 ^[26]

– ISO/IEC 19761:2011 ^[18] ISO/IEC 20926:2009 ^[19] và ISO/IEC 20968:2002 ^[20] chỉ dẫn ước lượng quy mô của phương pháp.

7.5  Sản xuất và cung cấp dịch vụ

7.5.1  Kiểm soát sản xuất và cung cấp dịch vụ

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 7.5.1  Kiểm soát sản xuất và cung cấp dịch vụ Tổ chức phải lập kế hoạch, tiến hành sản xuất và cung cấp dịch vụ trong điều kiện được kiểm soát. Khi có thể, các điều kiện được kiểm soát phải bao gồm: a) sự sẵn có thông tin mô tả các đặc tính của sản phẩm, b) sự sẵn có các hướng dẫn công việc khi cần, c) việc sử dụng các thiết bị thích hợp, d) sự sẵn có và việc sử dụng các thiết bị theo dõi và đo lường, e) thực hiện việc theo dõi và đo lường, và f) thực hiện các hoạt động thông qua sản phẩm, giao hàng và sau giao hàng.

7.5.1.1  Sản xuất và cung cấp dịch vụ trong lĩnh vực sản phẩm phần mềm

Như đã nêu trong chỉ dẫn về thiết kế và phát triển (xem 7.3), một dự án phát triển phần mềm cần được sắp xếp tuân theo một loạt các quá trình giúp chuyển đổi các yêu cầu thành sản phẩm phần mềm. Các yêu cầu về “kiểm soát và cung cấp dịch vụ” nêu trong mục 7.5.1 của TCVN ISO 9001:2008 tương đương với các sản phẩm phần mềm là:

a) Các hoạt động để tạo ra sản phẩm ví dụ xây dựng, phát hành, sao chép,

b) Các hoạt động cung cấp, ví dụ, cung cấp và cài đặt, và

c) Các hoạt động sau cung cấp, ví dụ các thao tác vận hành, bảo trì và hỗ trợ khách hàng (những hoạt động này được thực hiện trong suốt vòng đời sản phẩm).

7.5.1.2  Xây dựng và phát hành

Phải thiết lập các quá trình để xây dựng, phát hành và sao lại các hạng mục sản phẩm phần mềm. Việc xây dựng và phát hành đòi hỏi phải quản lý cấu hình (xem 7.5.3).

Những hạng mục sau đây được xem là thích hợp cho bước xây dựng và phát hành:

a) Nhận dạng các hạng mục phần mềm tạo nên từng phiên bản, kể cả những chỉ dẫn xây dựng có liên quan:

b) Nhận dạng các kiểu (hay cấp hạng) của phiên bản dựa trên tần suất và/hoặc tác động tới tác nghiệp của khách hàng và khả năng có thể áp dụng những thay đổi tại bất kỳ các thời điểm.

c) Quyết định chuẩn mực và chỉ dẫn để xác định nơi nào có thể kết hợp các phần đã được tạm thời phân định là chúng có thể được kết nối với nhau hoặc để nếu cần, phát hành một bản sao đã được cập nhật đầy đủ của một sản phẩm phần mềm.

7.5.1.3  Sao lại

Khi đòi hỏi, tổ chức phải thiết lập và thực hiện việc sao lại trên cơ sở cân nhắc các nội dung sau để đảm bảo rằng việc sao lại được thực hiện đúng.

a) Xác định bản gốc và các bản sao, kể cả việc định dạng, các biến thể khác nhau và số hiệu phiên bản;

b) Dạng của phương thức lưu trữ dữ liệu cho từng hạng mục phần mềm và việc ghi nhãn liên quan đến chúng:

c) Điều khoản về việc thiết lập tài liệu bắt buộc như các loại sổ tay, tài liệu hướng dẫn người sử dụng, các loại giấy phép và các biên bản bàn giao, kể các việc nhận dạng và đóng gói;

d) Kiểm soát tình trạng môi trường để việc sao lại này không ảnh hưởng đến khả năng đọc lại;

e) Có các hạng mục đảm bảo các bản sao của sản phẩm là đúng, đầy đủ và hoàn chỉnh

7.5.1.4  Cung cấp

Có thể thực hiện việc cung cấp bằng việc chuyển giao vật lý phương tiện lưu trữ sản phẩm phần mềm hoặc chuyển giao điện tử.

Việc bảo toàn các hạng mục trong quá trình chuyển giao được nêu trong 7.5.5.

7.5.1.5  Cài đặt

Đôi khi chính khách hàng hoặc bên thứ ba thực hiện việc cài đặt. Trong trường hợp này, tổ chức cần mô tả các bước để khách hàng hay bên thứ ba cần phải tiến hành để thực hiện việc cài đặt. Đôi khi, chính tổ chức phải tiến hành việc cài đặt. Trường hợp này, cần tuân thủ các điều sau:

a) Cả tổ chức và khách hàng cần thỏa thuận về vai trò, trách nhiệm, bổn phận của mình;

b) Cần xác định yêu cầu và mức độ cần thẩm định tại mỗi bước cài đặt;

c) Cần xác định yêu cầu về hướng dẫn cài đặt;

d) Cần xác định yêu cầu về cấu hình của phần mềm và phần cứng cho việc cài đặt đặc biệt;

e) Cần xác định yêu cầu về các dữ liệu phải được thu thập và/hoặc dữ liệu để thực hiện biến đổi và cơ sở dữ liệu chung;

f) Cần xác định thủ tục nghiệm thu mỗi bước cài đặt xét theo mức độ hoàn thành;

g) Cần xác định lịch trình;

h) Phải có sự bố trí để tiếp cận với cơ sở vật chất và trang thiết bị của khách hàng (Ví dụ thẻ an ninh ra vào, mật khẩu, người đi cùng để hỗ trợ);

i) Phải xác định và có sẵn những nhân viên có kỹ năng;

j) Cần xác định nhu cầu về đào tạo liên quan việc sử dụng đặc biệt đã dự định đối với sản phẩm khi lắp đặt hoặc là một phần liên quan công việc bảo trì sau này;

k) Cần xác định yêu cầu về thực hiện sao lưu lại và khẳng định khả năng khôi phục.

Khi giới thiệu một sản phẩm phần mềm mới hoặc khi phát hành phần mềm mới tại những cơ sở sử dụng phức tạp, cần lập kế hoạch thực hiện hoặc trình diễn.

7.5.1.6  Các tác nghiệp

Tổ chức sản xuất phần mềm cần lập kế hoạch và kiểm soát các tác nghiệp, bao gồm:

a) Cần thiết lập bộ phận hỗ trợ trực tuyến qua điện thoại hay hình thức thông tin điện tử khác với khách hàng, và

b) Có sự bố trí để đảm bảo sự hỗ trợ thường xuyên, ví dụ khôi phục do sự cố, an ninh và sao chép lại dữ liệu (xem 6.3).

7.5.1.7  Bảo trì

Bảo trì sản phẩm phần mềm là điều mà khách hàng đòi hỏi đối với những hạng mục đặc biệt do vậy trong hợp đồng cần quy định khoảng thời gian cụ thể sau cung cấp lần đầu và sau cài đặt. Tổ chức cần thiết lập quá trình để tiến hành các hoạt động bảo trì và kiểm tra xác nhận chúng. Các hoạt động bảo trì cũng có thể được tiến hành liên quan đến môi trường phát triển, với các công cụ và cả việc thiết lập tài liệu. Khi thích hợp, việc bảo trì có thể bao gồm:

a) Phạm vi bảo trì;

b) Nhận dạng các trạng thái ban đầu của các hạng mục được bảo trì;

c) Những vấn đề về tổ chức và cách sắp xếp để hỗ trợ;

d) Các hoạt động bảo trì kể cả các giải pháp cho vấn đề, sự hỗ trợ trực tuyến, hỗ trợ phần cứng hay hệ thống quan trắc để phát hiện sai hỏng;

e) Những thay đổi về các giao diện đòi hỏi khi có các bổ sung hay các thay đổi đã được thực hiện cho hệ thống hay các cấu thành phần cứng chịu sự kiểm soát của phần mềm này;

f) Các hoạt động quản lý cấu hình, thử nghiệm và đảm bảo chất lượng;

g) Tiến trình phát hành dự kiến;

h) Việc mở rộng chức năng và cải thiện tính năng sẽ được tiến hành như thế nào;

i) Các hồ sơ và báo cáo về bảo trì.

Hồ sơ về các hoạt động bảo trì phải được lập để đánh giá và hoàn thiện sản phẩm phần mềm và để cải tiến chính hệ thống quản lý chất lượng. Khi giải quyết các vấn đề, để tiết kiệm thời gian, có thể lập và sử dụng các file dạng mẫu tạm thời để giúp cho những sửa đổi dài hạn được tiến hành sau này.

Với những cải biên về giao diện và mở rộng tính năng, tùy theo quy mô công việc, cần áp dụng các thủ tục kiểm soát sự thay đổi hoặc khởi đầu tiếp một dự án phát triển riêng biệt.

Thông tin chi tiết hơn, xem ISO/IEC 12207:2008 ^[5] mục 6.4.7 (Cài đặt phần mềm), 6.4.10 (quá trình bảo trì sản phẩm phần mềm), mục 7.2.3.3.3.(Quá trình đảm bảo) và 7.2.8 (Quá trình giải quyết vấn đề phần mềm).

7.5.2  Xác nhận giá trị sử dụng của các quá trình sản xuất và cung cấp dịch vụ

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 7.5.2  Xác nhận giá trị sử dụng của các quá trình sản xuất và cung cấp dịch vụ Tổ chức phải xác nhận giá trị sử dụng của mọi quá trình sản xuất và cung cấp dịch vụ có kết quả đầu ra không thể kiểm tra xác nhận bằng cách theo dõi hoặc đo lường sau đó và vì vậy những sai sót chỉ có thể trở nên rõ ràng sau khi sản phẩm được sử dụng hoặc dịch vụ được chuyển giao. Việc xác nhận giá trị sử dụng phải chứng tỏ khả năng của các quá trình để đạt được kết quả đã hoạch định. Đối với các quá trình này, khi có thể, tổ chức phải sắp xếp những điều sau: a) các chuẩn mực đã định để xem xét và phê duyệt các quá trình, b) phê duyệt thiết bị và trình độ con người, c) sử dụng các phương pháp và thủ tục cụ thể, d) các yêu cầu về hồ sơ (xem 4.2.4); và e) tái xác nhận giá trị sử dụng.

Tổ chức cần cân nhắc các quá trình nào cần được dùng để bổ sung, bù đắp khi thiếu khả năng kiểm tra xác nhận đầy đủ hiệu quả sử dụng sản phẩm. Ví dụ, có thể là:

a) Việc xem xét thiết kế và phát triển có thể cân nhắc xem hoạt động thiết kế và phát triển có thể sai sót như thế nào khi không bổ sung cách rà soát kỹ hơn bình thường nhằm làm cho việc thiết kế và phát triển sẽ thực hiện đúng được chức năng;

b) Một chương trình phân tích các tác động và các dạng sai hỏng hay gặp nhất sẽ xác lập tiến trình lịch sử của các sai hỏng trong khâu thiết kế và phát triển và cách để phòng tránh chúng.

Dù sử dụng phương pháp nào, chúng đều phải tương xứng với các rủi ro và hậu quả của những sai hỏng do thiết kế và phát triển gây ra.

7.5.3  Nhận biết và xác định nguồn gốc

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 7.5.3  Nhận biết và xác định nguồn gốc Khi thích hợp, tổ chức phải nhận biết sản phẩm bằng các biện pháp thích hợp trong suốt quá trình tạo sản phẩm. Tổ chức phải nhận biết được trạng thái của sản phẩm tương ứng với các yêu cầu theo dõi và đo lường trong suốt quá trình tạo sản phẩm. Tổ chức phải kiểm soát việc nhận biết duy nhất sản phẩm và duy trì hồ sơ (xem 4.2.4) khi việc xác định nguồn gốc là một yêu cầu. CHÚ THÍCH: Trong một số lĩnh vực công nghiệp, quản lý cấu hình là phương pháp để duy trì việc nhận biết và xác định nguồn gốc.

7.5.3.1  Khái quát

Đối với sản phẩm phần mềm, nhận biết và truy xuất nguồn gốc thường được sử dụng thông qua quản lý cấu hình. Quản lý cấu hình là một nguyên tắc quản lý áp dụng chỉ dẫn mang tính quản trị và kỹ thuật cho việc thiết kế, phát triển và hỗ trợ các hạng mục cấu hình, kể cả các hạng mục phần mềm. Nguyên tắc này cũng được áp dụng cho việc thiết lập tài liệu có liên quan (xem 4.2.3) và phần cứng. Mức độ sử dụng quản lý cấu hình lệ thuộc vào quy mô, tính phức tạp và mức độ rủi ro của dự án.

Một mục tiêu của quản lý cấu hình là tạo sự nhìn nhận đầy đủ về cấu hình và trạng thái hiện tại của sản phẩm. Mục tiêu khác là mỗi người làm việc với sản phẩm tại bất kỳ thời điểm nào trong vòng đời của sản phẩm đều sử dụng những phiên bản thích hợp của các hạng mục.

7.5.3.2  Quá trình quản lý cấu hình

Phạm vi quản lý cấu hình có thể bao gồm:

a) Lập kế hoạch của quá trình kể cả việc xác định các hoạt động, các trách nhiệm và các công cụ cần được mua;

b) Xác định một cách nhất quán tên gọi và các phiên bản của mỗi một hạng mục cấu hình và khi nào thì chúng sẽ được đưa vào diện kiểm soát cấu hình (xác định cấu hình);

c) Xác định các phiên bản của mỗi hạng mục phần mềm mà chúng sẽ cùng với nhau tạo nên một phiên bản cụ thể của một sản phẩm hoàn chỉnh, kể cả phần mềm được sử dụng lại, thư viện phần mềm, phần mềm được mua hay phần mềm do khách hàng cung cấp);

d) Xác định trạng thái được xây dựng của sản phẩm phần mềm hiện được phát triển, được cung cấp hay cài đặt, dùng cho môi trường đơn hay môi trường đa dạng, nếu thích hợp;

e) Kiểm soát tình trạng được cập nhật một cách đồng thời của một hạng mục phần mềm đã cho bởi hai hoặc nhiều người làm việc một cách độc lập (kiểm soát cấu hình);

f) Tạo sự xếp đặt phối hợp cho việc cập nhật các sản phẩm đa năng tại một hoặc nhiều địa điểm, khi có yêu cầu;

g) Xác định, truy xuất nguồn gốc và báo cáo về trạng thái của các hạng mục, kể các hoạt động và các thay đổi do các yêu cầu cần thay đổi hoặc vấn đề nảy sinh từ bước khởi đầu cho đến khi phát hành phần mềm. (Giải trình trạng thái cấu hình)

h) Cung cấp cách đánh giá cấu hình (Trạng thái của các hoạt động kiểm tra và kiểm tra xác nhận)

i) Tạo cách quản lý phát hành và cung cấp

7.5.3.3  Truy xuất nguồn gốc

Cần có quá trình để truy xuất lại các cấu thành của từng hạng mục phần mềm hoặc sản phẩm trong suốt vòng đời của nó. Cách truy xuất như vậy có thể khác nhau tùy theo mức độ các yêu cầu của hợp đồng hoặc thị trường, tùy theo khả năng thiết lập yêu cầu thay đổi xác định trong một lần phát hành cụ thể, lệ thuộc vào nơi được gửi đến và nơi sử dụng mỗi dạng của sản phẩm.

CHÚ THÍCH  Thông tin chi tiết hơn, xem:

– ISO 1007:2003 ^[4] (Chỉ dẫn về quản lý cấu hình)

– ISO/IEC 12207:2003 ^[5] (Quá trình quản lý cấu hình).

7.5.4  Tài sản của khách hàng

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 7.5.4  Tài sản của khách hàng Tổ chức phải giữ gìn tài sản của khách hàng khi chúng thuộc sự kiểm soát của tổ chức hay được tổ chức sử dụng. Tổ chức phải nhận biết, kiểm tra xác nhận, bảo vệ tài sản do khách hàng cung cấp để sử dụng hoặc để hợp thành sản phẩm. Khi có bất kỳ tài sản nào của khách hàng bị mất mát, hư hỏng hoặc được phát hiện không phù hợp cho việc sử dụng, tổ chức đều phải thông báo cho khách hàng và phải duy trì hồ sơ (xem 4.2.4). CHÚ THÍCH: Tài sản của khách hàng có thể bao gồm cả sở hữu trí tuệ và dữ liệu cá nhân.

Tổ chức có thể phải buộc tiếp nhận, lưu giữ cả sản phẩm và dữ liệu do khách hàng cung cấp, chẳng hạn:

a) Các sản phẩm phần mềm kể cả các sản phẩm phần mềm thương mại do khách hàng cung cấp:

b) Các công cụ để phát triển;

c) Các phần mềm phát triển kể cả các dịch vụ mạng;

d) Các dữ liệu thử nghiệm và chạy phần mềm;

e) Giao diện hoặc các quy định khác;

f) Phần cứng; và

g) Các tài sản dạng sở hữu trí tuệ, các thông tin mang tính bản quyền và bảo mật, kể cả các quy định.

Trong mọi thỏa thuận bảo trì, cần lưu ý giải quyết các nội dung sau:

– Việc hỗ trợ và giấy phép cần có, kể cả các phiên bản tiếp theo của sản phẩm, và

– Các mục hạn chế và các ràng buộc trong việc sử dụng lại sản phẩm ở các dự án khác.

Phải xác định các phương thức mà theo đó, những hạng mục do khách hàng cung cấp gần nhất sẽ được chấp nhận và được tích hợp chung vào sản phẩm. Tổ chức có thể áp dụng những hình thức kiểm tra xem xét như nhau đối với sản phẩm do khách hàng cung cấp cũng như sản phẩm được mua. Điều này bao gồm các yêu cầu đối với các hồ sơ chỉ rõ những thay đổi nào đã được thực hiện, tại những địa điểm nào nếu đó là các sản phẩm hay địa điểm đa năng.

Các phương pháp để xác định sản phẩm do khách hàng cung cấp nên là một phần của quản lý cấu hình đối với sản phẩm (xem 7.5.3).

7.5.5  Bảo toàn sản phẩm

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 7.5.5  Bảo toàn sản phẩm Tổ chức phải bảo toàn sản phẩm trong quá trình xử lý nội bộ và giao hàng đến vị trí dự kiến nhằm duy trì sự phù hợp với các yêu cầu. Khi thích hợp, việc bảo toàn phải bao gồm nhận biết, xếp dỡ (di chuyển), bao gói, lưu giữ và bảo quản. Việc bảo toàn cũng phải áp dụng với các bộ phận cấu thành của sản phẩm.

Tổ chức sản xuất phần mềm cần đảm bảo rằng các sản phẩm của mình không bị thay đổi tính từ thời điểm sản xuất, qua sao lại, bảo quản và lưu giữ cho đến thời điểm cung cấp. Thông tin phần mềm không bị suy thoái, mặc dù, phương tiện mà trên đó phần mềm được lưu giữ có thể bị hư hại, do vậy, tổ chức cần thận trọng.

Việc cung cấp cần thực hiện theo biện pháp phòng ngừa thích hợp nhằm giữ sản phẩm phần mềm không hư hại. Hơn thế, cần nêu mức độ thích hợp để kiểm tra vi rút phần mềm và các biện pháp thích hợp bảo vệ tính toàn vẹn của sản phẩm. Có thể cung cấp sản phẩm phần mềm qua cách vận chuyển theo phương tiện vật lý chứa phần mềm hoặc bằng cách truyền dẫn điện tử. Khi xử lý, đóng gói, bảo quản hoặc cung cấp sản phẩm phần mềm cần cân nhắc các hoạt động thích ứng sau đây:

a) Lưu trữ các hạng mục phần mềm, duy trì các phiên bản của sản phẩm theo các đường cơ sở đã xác lập (xem giải thích đường cơ sở tại phần c, mục 75.3.2);

b) Cho phép truy cập được kiểm soát và phục hồi đối với bản gốc cũng như bất kỳ bản sao nào, bảo vệ chúng khỏi những thay đổi không được cho phép hoặc bị suy giảm;

c) Bảo vệ các phương tiện máy tính, đặc biệt lưu ý đối với các loại vi rút máy tính, điện từ trường và các môi trường tĩnh điện;

d) Định kỳ thực hiện việc sao chép lại phần mềm, kể cả việc sao chép ra thiết bị ngoại vi để tránh sự cố không thể phục hồi;

e) Đảm bảo kịp thời sao chép phần mềm vào phương tiện lưu trữ thay thế;

f) Bảo quản các phương tiện lưu trữ phần mềm trong các môi trường có tính bảo vệ, ngăn ngừa việc hư hại và tránh được kịp thời việc bị suy thoái, cũ;

g) Cân nhắc các ảnh hưởng khi sử dụng các kỹ thuật nén và giải nén (cách làm giảm không gian bị chiếm bởi phương tiện lưu dữ liệu nhờ mã hóa, tạo lợi thế tăng lượng dữ liệu cần lưu);

h) Cân nhắc các ảnh hưởng khi sử dụng các kỹ thuật mật mã và giải mật mã hóa (chuyển dữ liệu thành dạng không thể hiểu để đảm bảo an toàn dữ liệu)

CHÚ THÍCH  Để có chỉ dẫn chung hơn liên quan tới TCVN ISO 9001:2008, xem:

– ISO/IEC 25010:2011 ^[24] (Chỉ dẫn về các đặc trưng chất lượng của các sản phẩm phần mềm)

– ISO/IEC 14764:2006 ^[8]

– ISO/IEC 26514:2008 ^[28]

7.6  Kiểm soát thiết bị theo dõi và đo lường

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 7.6  Kiểm soát thiết bị theo dõi và đo lường Tổ chức phải xác định việc giám sát và đo lường cần thực hiện và các thiết bị giám sát, đo lường cần thiết để cung cấp bằng chứng về sự phù hợp của sản phẩm với các yêu cầu đã xác định. Tổ chức phải thiết lập các quá trình để đảm bảo rằng việc giám sát và đo lường có thể tiến hành và được tiến hành một cách nhất quán với các yêu cầu giám sát và đo lường. Khi cần đảm bảo kết quả đúng, thiết bị đo lường phải a) được hiệu chuẩn hoặc kiểm tra xác nhận, hoặc cả hai, định kỳ hoặc trước khi sử dụng, dựa trên các chuẩn đo lường được liên kết với chuẩn đo lường quốc gia hay quốc tế; khi không có các chuẩn này thì căn cứ được sử dụng để hiệu chuẩn hoặc kiểm tra xác nhận phải được lưu hồ sơ (xem 4.2.4); b) được hiệu chỉnh hoặc hiệu chỉnh lại, khi cần; c) có dấu hiệu nhận biết để xác định tình trạng hiệu chuẩn; d) được giữ gìn tránh bị hiệu chỉnh làm mất tính đúng đắn của các kết quả đo; e) được bảo vệ để tránh hư hỏng hoặc suy giảm chất lượng trong khi di chuyển, bảo dưỡng và lưu giữ. Ngoài ra, tổ chức phải đánh giá và ghi nhận giá trị hiệu lực của các kết quả đo lường trước đó khi thiết bị được phát hiện không phù hợp với yêu cầu. Tổ chức phải tiến hành hành động thích hợp đối với thiết bị đó và bất kỳ sản phẩm nào bị ảnh hưởng. Phải duy trì hồ sơ (xem 4.2.4) về kết quả hiệu chuẩn và kiểm tra xác nhận. Khi sử dụng phần mềm máy tính để giám sát và đo lường các yêu cầu quy định, phải khẳng định khả năng thỏa mãn việc ứng dụng dự kiến. Việc này phải được tiến hành trước lần sử dụng đầu tiên và được xác nhận lại khi cần. CHÚ THÍCH: Việc xác nhận khả năng đáp ứng ứng dụng dự kiến của phần mềm máy tính thường bao gồm việc kiểm tra xác nhận và quản lý cấu hình để duy trì tính thích hợp để sử dụng của phần mềm đó.

Hiệu chuẩn là kỹ thuật thường được quan niệm là không thể sử dụng trực tiếp cho phần mềm. Tuy nhiên, nó có thể được áp dụng cho phần cứng và các công cụ được sử dụng để thử nghiệm và kiểm tra xác nhận giá trị sử dụng của phần mềm. Vì vậy, các mục a) cho đến e) của 7.6, TCVN ISO 9001:2008 có thể được áp dụng cho môi trường sử dụng khi thử sản phẩm phần mềm.

Khi tổ chức sử dụng các công cụ, trang thiết bị và kỹ thuật để tiến hành bất kỳ phép kiểm tra xác nhận sự phù hợp của sản phẩm phần mềm theo các yêu cầu đã quy định, khi chấp nhận sử dụng chúng, tổ chức cần cân nhắc ảnh hưởng của những công cụ như vậy đối với chất lượng của sản phẩm phần mềm. Hơn thế, các công cụ như vậy phải được đưa vào quản lý cấu hình trước khi sử dụng.

Mặc dù khái niệm “được hiệu chỉnh” hoặc “được hiệu chỉnh lại khi cần” [TCVN ISO 9001:2008, mục 7.6 điểm b)] không áp dụng cho sản phẩm phần mềm, nhưng có thể cần định kỳ kiểm tra xác nhận rằng phần mềm hiện được sử dụng trong các thiết bị đo không bị thay đổi dù nó phải chịu các môi trường khắc nghiệt, chẳng hạn các loại vi rút hay các trường điện từ trường.

Sự thích hợp của các công cụ, kỹ thuật và dữ liệu thử nghiệm phải được kiểm tra xác nhận trước khi sử dụng nhằm xác định liệu chúng có cần được hoàn thiện và/hoặc nâng cấp không. Tổ chức cũng cần có các thủ tục để xác định cách thức kiểm tra phần mềm thử nghiệm.

Các thiết bị theo dõi và đo được sử dụng trong phát triển, thử nghiệm, bảo trì và trong khai thác sử dụng phần mềm gồm:

a) Dữ liệu dùng để thử nghiệm sản phẩm phần mềm,

b) Các công cụ phần mềm (ví dụ, để mô phỏng, thu thập kết quả thực hiện, nguồn lực thực hiện và các thông tin liên quan),

c) Phần cứng máy tính, và

d) Các công cụ để tạo giao diện với phần mềm máy tính.

Tổ chức cần kiểm soát các thiết bị theo dõi và đo lường bằng những phương thức của hệ thống quản lý cấu hình (xem 7.5.3).

8.  Đo lường, phân tích và cải tiến

8.1  Khái quát

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 8.1  Khái quát Tổ chức phải hoạch định và triển khai các quá trình giám sát, đo lường, phân tích và cải tiến cần thiết để a) chứng tỏ sự phù hợp với các yêu cầu của sản phẩm, b) đảm bảo sự phù hợp của hệ thống quản lý chất lượng, và c) cải tiến liên tục hiệu lực của hệ thống quản lý chất lượng. Điều này phải bao gồm việc xác định các phương pháp có thể áp dụng, kể cả các kỹ thuật thống kê, và mức độ sử dụng chúng.

Mục đích của quá trình đo sản phẩm phần mềm là thu thập, phân tích và báo cáo dữ liệu liên quan với các sản phẩm đã được phát triển và các quá trình đã được áp dụng trong một đơn vị xét về mặt tổ chức, nhằm hỗ trợ việc quản lý các quá trình này hiệu quả và minh chứng một cách khách quan chất lượng của các sản phẩm.

Việc giám sát, đo, phân tích và quá trình cải tiến cần được xác định như là một phần của kế hoạch chất lượng (xem 7.1.2)

CHÚ THÍCH  Thông tin chi tiết hơn, xem:

– ISO/IEC 12207:2008 ^[5] (Cải tiến) và 6.3.7 (quá trình đo)

– ISO/IEC 15939:2007 ^[15]

– ISO/IEC 15504-1; ^[10]

– ISO/IEC/TR 9126-2:2003 ^[1] và ISO/IEC/TR 9126-3:2003^[2] (chất lượng sản phẩm- các thước đo nội bộ và bên ngoài);

– ISO/IEC 25011:2007 ^[23]

8.2  Theo dõi và đo lường

8.2.1  Sự thỏa mãn của khách hàng

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 8.2.1  Sự thỏa mãn của khách hàng Tổ chức phải theo dõi các thông tin liên quan đến sự chấp nhận của khách hàng về việc tổ chức có đáp ứng yêu cầu của khách hàng hay không, coi đó như một trong những thước đo mức độ thực hiện của hệ thống quản lý chất lượng. Phải xác định các phương pháp thu thập và sử dụng các thông tin này. CHÚ THÍCH: Theo dõi cảm nhận của khách hàng có thể bao gồm việc thu thập đầu vào từ các nguồn như khảo sát về sự thỏa mãn của khách hàng, dữ liệu khách hàng về chất lượng sản phẩm giao nhận, khảo sát ý kiến người sử dụng, phân tích thua lỗ kinh doanh, những khen ngợi, các yêu cầu bảo hành và báo cáo của đại lý.

Các quá trình của tổ chức để nêu yêu cầu, đo và giám sát phản hồi về sự thỏa mãn của khách hàng phải cung cấp một cách thích hợp các thông tin trên cơ sở thường xuyên hoặc định kỳ. Với sản phẩm phần mềm, ví dụ, cần cân nhắc:

a) Phân tích các cuộc gọi trực tuyến liên quan đến cả chất lượng sản phẩm và kết quả thực hiện dịch vụ;

b) Những thước đo chất lượng trong sử dụng nhận được từ phản hồi trực tiếp hoặc gián tiếp của khách hàng;

c) Những thước đo chất lượng khác dựa trên việc sử dụng sản phẩm, và

d) Số các lần phát hành sản phẩm phần mềm được xem là cần thiết để ấn định các sự cố, tính từ sau khi phát hành bản đầu tiên.

CHÚ THÍCH: Thông tin chi tiết hơn, xem ISO/IEC/TR 9126-4 ^[3] (Chất lượng sản phẩm – Các thước đo chất lượng trong sử dụng).

8.2.2  Đánh giá nội bộ

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 8.2.2  Đánh giá nội bộ Tổ chức phải tiến hành đánh giá nội bộ định kỳ theo kế hoạch để xác định hệ thống quản lý chất lượng a) có phù hợp với các bố trí sắp xếp được hoạch định (xem 7.1) đối với các yêu cầu của tiêu chuẩn này và với các yêu cầu của hệ thống quản lý chất lượng được tổ chức thiết lập, và b) có được thực hiện và duy trì một cách hiệu lực. Tổ chức phải hoạch định chương trình đánh giá, có chú ý đến tình trạng và tầm quan trọng của các quá trình và các khu vực được đánh giá, cũng như kết quả của các cuộc đánh giá trước. Chuẩn mực, phạm vi, tần suất và phương pháp đánh giá phải được xác định. Việc lựa chọn các chuyên gia đánh giá và tiến hành đánh giá phải đảm bảo được tính khách quan và công bằng của quá trình đánh giá. Các chuyên gia đánh giá không được đánh giá công việc của mình. Phải thiết lập một thủ tục dạng văn bản để xác định trách nhiệm và yêu cầu đối với việc hoạch định và tiến hành đánh giá, lập hồ sơ và báo cáo kết quả. Phải duy trì hồ sơ đánh giá và các kết quả đánh giá (xem 4.2.4). Lãnh đạo chịu trách nhiệm về khu vực được đánh giá phải đảm bảo tiến hành không chậm trễ mọi sự khắc phục cũng như các hành động khắc phục cần thiết để loại bỏ sự không phù hợp được phát hiện và nguyên nhân của chúng. Các hoạt động tiếp theo phải bao gồm việc kiểm tra xác nhận các hành động được tiến hành và báo cáo kết quả kiểm tra xác nhận (xem 8.5.2). CHÚ THÍCH: Xem hướng dẫn trong ISO 19011.

Khi các tổ chức sản xuất phần mềm tách biệt các công việc của họ trong các dự án, kế hoạch đánh giá nội bộ cần xác định việc lựa chọn các dự án và đánh giá cả sự tuân thủ của kế hoạch chất lượng của dự án của họ so với hệ thống quản lý chất lượng của chính tổ chức và đánh giá sự tuân thủ của dự án so với kế hoạch chất lượng. Việc lựa chọn này cần đảm bảo bao quát tất cả các giai đoạn và mọi quá trình.

Điều này đòi hỏi phải đánh giá những dự án khác nhau tại các giai đoạn khác nhau trong chu kỳ sống của việc phát triển sản phẩm của họ hoặc đánh giá một dự án riêng biệt theo như cách nó tiến triển qua các giai đoạn khác nhau. Khi một dự án đã định bị thay đổi tiến độ, cần xem xét lại tiến trình đánh giá nội bộ hoặc phải thay đổi thời điểm đánh giá hay phải cân nhắc một dự án khác.

CHÚ THÍCH  Thông tin chi tiết hơn, xem ISO/IEC 12207:2008 ^[5] (Quá trình đảm bảo chất lượng phần mềm) và 7.2.2 (quá trình đánh giá sản phẩm phần mềm).

8.2.3  Theo dõi và đo lường các quá trình

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 8.2.3  Theo dõi và đo lường các quá trình Tổ chức phải áp dụng các phương pháp thích hợp cho việc theo dõi và, khi có thể, đo lường các quá trình của hệ thống quản lý chất lượng. Các phương pháp này phải chứng tỏ khả năng của các quá trình để đạt được các kết quả đã hoạch định. Khi không đạt được các kết quả theo hoạch định, phải tiến hành việc khắc phục và hành động khắc phục thích hợp. CHÚ THÍCH: Để xác định các phương pháp thích hợp, tổ chức nên xem xét loại và phạm vi theo dõi hoặc đo lường thích hợp với mỗi quá trình trong mối tương quan với ảnh hưởng của những quá trình này tới sự phù hợp với các yêu cầu của sản phẩm cũng như hiệu lực của hệ thống quản lý chất lượng

Các tổ chức thường đo một số khía cạnh của các quá trình của mình để theo dõi, quản lý và đánh giá chúng. Những phép đo thông thường nhất bao gồm:

a) Khoảng thời gian dự kiến và thời gian thực tế thực hiện một quá trình,

b) Chi phí dự kiến và chi phí thực tế thực hiện một quá trình,

c) Các mức chất lượng được hoạch định và các thước đo về sự đạt được của các đặc trưng chất lượng đã lựa chọn.

CHÚ THÍCH 1: Thông tin chi tiết hơn, xem ISO/IEC 12207:2008 ^[5] (Đánh giá quá trình) và 6.2.1.3.3 (cải tiến quá trình)

CHÚ THÍCH 2: Chỉ dẫn về tiến hành đánh giá quá trình phần mềm, xem ISO/IEC 15504-1 ^[10] và chỉ dẫn về tiến hành đánh giá, xem ISO/IEC 15504-2 ^[11] và ISO/IEC 15939:2007 ^[15] mục 5 (quá trình quản lý phần mềm).

8.2.4  Theo dõi và đo lường sản phẩm

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 8.2.4  Theo dõi và đo lường sản phẩm Tổ chức phải theo dõi và đo lường các đặc tính của sản phẩm để kiểm tra xác nhận rằng các yêu cầu về sản phẩm được đáp ứng. Việc này phải được tiến hành ở những giai đoạn thích hợp của quá trình tạo sản phẩm theo các sắp xếp hoạch định (xem 7.1). Phải duy trì bằng chứng về sự phù hợp với tiêu chí chấp nhận. Hồ sơ phải chỉ ra (những) người có quyền thông qua sản phẩm để giao cho khách hàng (xem 4.2.4). Việc thông qua sản phẩm và chuyển giao dịch vụ cho khách hàng chỉ được tiến hành sau khi đã hoàn thành thỏa đáng các hoạt động theo hoạch định (xem 7.1), nếu không thì phải được sự phê duyệt của người có thẩm quyền và, nếu có thể, của khách hàng.

Tổ chức cần theo dõi và đo lường sự phù hợp của các sản phẩm theo các yêu cầu chất lượng bằng các cách như xem xét, kiểm tra xác nhận và xác nhận giá trị sử dụng. Ví dụ về các đặc trưng chất lượng có thể được theo dõi hoặc đo lường là:

a) tính năng:

b) khả năng bảo trì;

c) tính hiệu quả;

d) những đặc điểm về gọn nhẹ, xách tay:

e) những đặc điểm về tính thích hợp cho việc sử dụng;

f) những đặc điểm về tính tin cậy.

CHÚ THÍCH  Thông tin chi tiết hơn, xem:

– ISO/IEC/IEEE 12207:2008^[5] mục 6.4 (Các quá trình kỹ thuật) nêu các hạng mục về đánh giá các sản phẩm phần mềm trong giai đoạn phát triển và khi đã hoàn thành;

– ISO/IEC 25010:2010^[24]

– ISO/IEC 25040^[25] và ISO/IEC 25041 ^[26]

8.3  Kiểm soát sản phẩm không phù hợp

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 8.3  Kiểm soát sản phẩm không phù hợp Tổ chức phải đảm bảo rằng sản phẩm không phù hợp với các yêu cầu được nhận biết và kiểm soát để phòng ngừa việc sử dụng hoặc chuyển giao ngoài dự kiến. Phải thiết lập một thủ tục dạng văn bản để xác định việc kiểm soát và trách nhiệm, quyền hạn có liên quan đối với việc xử lý sản phẩm không phù hợp. Khi thích hợp, tổ chức phải xử lý sản phẩm không phù hợp bằng một hoặc một số cách sau: a) tiến hành loại bỏ sự không phù hợp được phát hiện; b) cho phép sử dụng, thông qua hoặc chấp nhận có nhân nhượng bởi người có thẩm quyền và, khi có thể, bởi khách hàng; c) tiến hành loại bỏ khỏi việc sử dụng hoặc áp dụng dự kiến ban đầu. d) tiến hành hành động thích hợp với những tác động hoặc hậu quả tiềm ẩn của sự không phù hợp nếu sản phẩm không phù hợp được phát hiện sau khi chuyển giao hoặc đã bắt đầu sử dụng. Khi sản phẩm không phù hợp được khắc phục, chúng phải được kiểm tra xác nhận lại để chứng tỏ sự phù hợp với các yêu cầu. Phải duy trì hồ sơ về bản chất của sự không phù hợp và bất kỳ hành động tiếp theo nào được tiến hành, kể cả các nhân nhượng có được. (xem 4.2.4)

Trong phát triển phần mềm, việc phân biệt những hạng mục không phù hợp có thể bị ảnh hưởng bởi sự chuyển một hạng mục từ môi trường sản xuất hay môi trường thử nghiệm sang môi trường tách biệt. Trong trường hợp sản phẩm phần mềm được nhúng, ta có thể cần phân chia tách biệt hạng mục không phù hợp (Phần cứng) mà hạng mục đó có chứa sản phẩm phần mềm không phù hợp.

Nhà cung cấp cần xác định tại những điểm nào đòi hỏi phải có hoạt động kiểm soát và lập hồ sơ về sản phẩm không phù hợp. Dù trong giai đoạn phát triển hay bảo trì, một sản phẩm phần mềm xuất hiện lỗi thì đều cần kiểm soát và lập hồ sơ về việc điều tra và giải pháp cho các lỗi này.

Có thể dùng quản lý cấu hình để áp dụng cho một phần hoặc toàn bộ yêu cầu này.

Khi xử lý những sự không phù hợp, có thể lưu ý các khía cạnh sau:

a) Bất kỳ các vấn đề đã được phát hiện và các tác động có thể của chúng đối với bất kỳ phần nào của sản phẩm phần mềm đều phải được ghi nhận và phải chỉ rõ trách nhiệm theo sát đến cùng các vấn đề như vậy cho đến khi chúng được giải quyết;

b) Phải xác định và kiểm tra lại các lĩnh vực bị tác động bởi bất kỳ sự sửa đổi nào và phải có thủ tục bằng văn bản để nêu phương pháp xác định phạm vi của phép thử lại;

c) Phải thiết lập thứ tự ưu tiên giải quyết với những sự không phù hợp.

Với sản phẩm phần mềm có việc sửa chữa hay gia công bổ sung nhằm đáp ứng đầy đủ các yêu cầu đã được quy định thì nó tạo nên phiên bản mới. Trong phát triển sản phẩm phần mềm, việc xử lý sản phẩm không phù hợp có thể thực hiện được nhờ:

a) Sửa chữa hoặc gia công bổ sung (ví dụ sửa các lỗi) để đáp ứng yêu cầu,

b) Chấp nhận trên cơ sở nhân nhượng có hoặc không phải sửa chữa,

c) Xử lý như sản phẩm phù hợp sau khi đã điều chỉnh các yêu cầu, và

d) Loại bỏ.

CHÚ THÍCH  Thông tin chi tiết hơn, xem:

– ISO/IEC/IEEE 12207:2008^[5] mục 6.5.3 và 7.2.2 (Quá trình quản lý cấu hình) và 7.2.8 (quá trình giải quyết vấn đề);

– ISO/IEC 25051:2006 ^[22]

8.4  Phân tích dữ liệu

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 8.4  Phân tích dữ liệu Tổ chức phải xác định, thu thập và phân tích các dữ liệu thích hợp để chứng tỏ sự phù hợp và tính hiệu lực của hệ thống quản lý chất lượng và đánh giá xem việc cải tiến liên tục hiệu lực của hệ thống quản lý chất lượng có thể tiến hành ở đâu. Điều này bao gồm cả các dữ liệu được tạo ra do kết quả của việc theo dõi, đo lường và từ các nguồn thích hợp khác. Việc phân tích dữ liệu phải cung cấp thông tin về: a) sự thỏa mãn khách hàng (xem 8.2.1); b) sự phù hợp với các yêu cầu về sản phẩm (xem 8.2.4); c) đặc tính và xu hướng của các quá trình và sản phẩm, kể cả các cơ hội cho hành động phòng ngừa (xem 8.2.3 và 8.2.4), và d) người cung ứng (xem 7.4).

Các ví dụ về “phân tích dữ liệu” đối với sản phẩm phần mềm có thể bao gồm các báo cáo vấn đề từ các mức thử nghiệm khác nhau và các vấn đề đã được xác định trong các xem xét và trong kiểm soát tại từng bước.

CHÚ THÍCH Thông tin chi tiết hơn, xem:

– ISO/IEC 15939:2007 ^[15] mục 4.4 (Quá trình đo phần mềm- các kết quả đánh giá);

– ISO/IEC 19761:2011 ^[18], ISO/IEC 20926:2009 ^[21] và ISO/IEC 20968:2012 ^[20]

8.5  Cải tiến

8.5.1  Cải tiến liên tục

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 8.5.1  Cải tiến liên tục Tổ chức phải cải tiến liên tục hiệu lực của hệ thống quản lý chất lượng thông qua việc sử dụng chính sách chất lượng, mục tiêu chất lượng, kết quả đánh giá, phân tích dữ liệu, hành động khắc phục, phòng ngừa và sự xem xét của lãnh đạo.

Có thể đạt được cách tiếp cận để cải tiến quá trình nhờ việc thiết lập quá trình cải tiến. Việc này có thể áp dụng đối với bất kỳ hoặc tất cả các quá trình trong vòng đời của sản phẩm phần mềm, kể cả quá trình thiết lập, quá trình đánh giá và quá trình cải tiến.

CHÚ THÍCH: Thông tin chi tiết hơn, xem:

– ISO/IEC/12207:2008 ^[5] mục 6.2.1.3.3 (Cải tiến quá trình);

– ISO/IEC 15504 (tất cả các phần) (quá trình đánh giá sản phẩm phần mềm).

8.5.2  Hành động khắc phục

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 8.5.2  Hành động khắc phục Tổ chức phải thực hiện hành động nhằm loại bỏ những nguyên nhân của sự không phù hợp để ngăn ngừa việc tái diễn. Hành động khắc phục phải tương ứng với tác động của sự không phù hợp gặp phải. Phải lập một thủ tục dạng văn bản để xác định các yêu cầu đối với a) việc xem xét sự không phù hợp (kể cả các khiếu nại của khách hàng), b) việc xác định nguyên nhân của sự không phù hợp, c) việc đánh giá nhu cầu thực hiện các hành động để đảm bảo rằng sự không phù hợp không tái diễn, d) việc xác định và thực hiện các hành động cần thiết, e) việc lưu hồ sơ các kết quả của hành động được thực hiện (xem 4.2.4), và f) việc xem xét hiệu lực của các hành động khắc phục đã thực hiện.

Tại những nơi mà hành động khắc phục ảnh hưởng trực tiếp tới các sản phẩm phần mềm, có thể dùng quản lý cấu hình để quản lý sự thay đổi. Ban lãnh đạo cần xem xét các hành động khắc phục có gây ra sự thay đổi đối với những quá trình của vòng đời sản phẩm. Các thủ tục của tổ chức về hành động khắc phục cần lưu ý yêu cầu về ngăn ngừa sự tái diễn.

CHÚ THÍCH  Thông tin chi tiết hơn, xem ISO/IEC 12207:2008 ^[5] mục 7.2.8 (Quá trình giải quyết vấn đề sản phẩm phần mềm).

8.5.3  Hành động phòng ngừa

TCVN ISO 9001:2008, các yêu cầu của hệ thống quản lý chất lượng 8.5.3  Hành động phòng ngừa Tổ chức phải xác định hành động nhằm loại bỏ nguyên nhân của sự không phù hợp tiềm ẩn để ngăn chặn sự xuất hiện của chúng. Các hành động phòng ngừa được tiến hành phải tương ứng với tác động của các vấn đề tiềm ẩn. Phải lập một thủ tục dạng văn bản để xác định các yêu cầu đối với a) việc xác định sự không phù hợp tiềm ẩn và các nguyên nhân của chúng, b) việc đánh giá nhu cầu thực hiện các hành động để phòng ngừa việc xuất hiện sự không phù hợp, c) việc xác định và thực hiện các hành động cần thiết, d) hồ sơ các kết quả của hành động được thực hiện (xem 4.2.4), và e) việc xem xét hiệu lực của các hành động phòng ngừa đã thực hiện

Việc đánh giá quá trình sẽ hữu ích nếu sử dụng được các dữ liệu từ các vấn đề được lường trước (xem 8.2.3).

CHÚ THÍCH Thông tin chi tiết hơn liên quan TCVN ISO 9001:2008, mục 8.5, xem:

– ISO/IEC 12207:2008 ^[5] mục 6.2.1.3.3 (Cải tiến quá trình);

– ISO/IEC 15504 (tất cả các phần) (quá trình đánh giá sản phẩm phần mềm).

 

Phụ lục A

(tham khảo)

Tóm tắt hướng dẫn áp dụng TCVN ISO 9001:2008 trong các tiêu chuẩn của Ban kỹ thuật ISO/IEC/TC1/SC7 và ISO/TC176

Bảng A1 tóm lược các tài liệu được viện dẫn trong phần nội dung của tiêu chuẩn này cũng như các chỉ số mục viện dẫn đến ISO/IEC 12207:2008. Thông tin nêu trong bảng này là để tóm lược phần nội dung của tài liệu này. Trường hợp có bất kỳ sự bất đồng nào, các mục viện dẫn trong phần nội dung chính cần được xem là các phần cần điều chỉnh.

Bảng A.1- Hướng dẫn bổ sung về việc áp dụng TCVN ISO 9001:2008 được nêu trong các tiêu chuẩn của ISO/lEC/TC1/SC7 và ISO/TC176

TCVN ISO 9001:2008	Các điều của ISO/IEC 12207	Các tài liệu khác
4.1 Yêu cầu chung	Khái quát	24748-1[21], 24748-3[22]
4.2 Yêu cầu đối với hệ thống tài liệu	6.3.6, 7.2.1
5.4.1 Mục tiêu chất lượng		15504,[10],[11],[12],[13],[14], 25010[24]
6.2.1 Khái quát	6.2.4
6.3 Cơ sở hạ tầng	6.2.2	25001[23], 25404[25] 25041[26], 14102[6]
7.1 Hoạch định và tạo sản phẩm	6.1.2.3.4.5, 7.1.1.3.1.4 7.2.3.3.1.3	16326[17], 25001[24], 25010[24]
7.2.1 Xác định các yêu cầu liên quan đến sản phẩm.	6.4.2, 7.1.2	15026-3[9], 25010 [24] , 25021[27],
7.2.2 Xem xét các yêu cầu liên quan đến sản phẩm	6.1.2, 7.2.4.3.2, 7.2.6, 6.3.4	16085[16], 29184[29], 25010[24],
7.2.3 Trao đổi thông tin với khách hàng	7.2.6, 6.1.2, 6.4.9.3.4	14764[8].
7.3.1.1 Hoạch định thiết kế và phát triển	6.1.2.3.4.5 7.1.1.3.1.4, 7.2.3.3.1.3
7.3.1.4 Các mối tương giao	6.3.1	16326[17]
7.3.2 Đầu vào của thiết kế và phát triển		25010[24],
7.3.3 Đầu ra của thiết kế và phát triển	7.1.3, 7.1.5
7.3.4 Xem xét thiết kế và phát triển	7.1.2.3.1.2, 7.1.3.3.1.6, 7.1.4.3.1.7, 7.2.6
7.3.5 Kiểm tra xác nhận thiết kế và phát triển	6.4, 7.2.4
7.3.6 Xác nhận giá trị sử dụng của thiết kế và phát triển	6.4, 7.2.5	25010[24]
7.3.7 Kiểm soát thay đổi của thiết kế và phát triển	5.5.2.5.5.3, 6.1, 6.2, F.2.1, F.2.2	14759[7], 19761[18] , 20968[20], 25051[27] , 26514[28]
7.4.1 Quá trình mua hàng	6.1.1	15504-3 [12]
7.4.2 Thông tin mua hàng	6.1.1.3
7.4.3 Kiểm tra xác nhận sản phẩm được mua	6.1.1.3.6	19761[18], 20926[19], 20968[20], 25010[24], 25040[25], 25041[26]
7.5.1 Kiểm soát việc cung cấp sản phẩm và dịch vụ	6.4.7, 6.4.9.3.4, 6.4.10, 7.2.3.3.3, 7.2.8
7.5.3 Nhận biết và truy tìm nguồn gốc	6.6.3.5, 7.2.2	10007[4]
7.5.5 Bảo toàn sản phẩm		14764[8], 25010[24], 26514[28],
8.1 Khái quát	6.2.1.3.3	9126-2[1], 9126-3[2], 15504-1[10], 15939 [15], 25010 [23]
8.2.1 Sự thỏa mãn khách hàng		9126-4[3]
8.2.2 Đánh giá nội bộ	7.2.3, 7.2.7
8.2.3 Theo dõi và đo lường các quá trình	6.2.1.3.2, 6.2.1.3.3	15504-1[10], 15504-2[11], 15939[15]
8.2.3 Theo dõi và đo lường sản phẩm	6.4	25010[24], 25040[25], 25041[26]
8.3 Kiểm soát sản phẩm không phù hợp	6.3.5, 7.2.2, 7.2.8	25015 [27]
8.4 Phân tích dữ liệu		15939[15],19761[18], 20926[19], 20968[20]
8.5.1 Cải tiến liên tục	6.2.1.3.3	15504[10],[12],[13],[14]
8.5.2 Hành động khắc phục	7.2.8
8.5.3 Hành động phòng ngừa	6.2.1.3.2	15504-2[11],

 

Phụ lục B

(tham khảo)

Hoạch định trong TCVN ISO/IEC 90003 và ISO/IEC 12207

ISO/IEC 12207:2008 xem việc lập kế hoạch chất lượng và kế hoạch triển khai như là một hoạt động đơn lẻ về lập kế hoạch để tạo lập các phương án quản lý dự án. Bảng dưới đây nêu lược đồ chỉ rõ các mục yêu cầu 7.1.2, 7.3.1 và 7.3.4 của tiêu chuẩn này cần phải được đáp ứng như thế nào khi xét theo các mục có liên quan như 6.1.2.3.4.5, 7.1.1.3.1.4,và 7.2.3.3.1.3 (và các tiểu mục khác như đã được viện dẫn trong các phần chú thích) nêu trong ISO/IEC 12207:2008. Hơn thế, phụ lục này cũng đề cập việc quản lý dự án, các xem xét kỹ thuật thuộc mục 7.2.6 của ISO/IEC 12207:2008, là những mục ở 7.3.4 của TCVN ISO 9001:2008 về các xem xét thiết kế và phát triển.

Bảng B1 – Mối liên hệ giữa TCVN ISO/IEC 90003 và ISO/IEC 12207

Mục dẫn chiếu của TCVN ISO/IEC 90003	Mục dẫn chiếu của ISO/IEC 12207
7.1.2 Hoạch định việc tạo sản phẩm
a) Bao gồm hoặc viện dẫn đến các kế hoạch phát triển (xem 7.3.1)	7.1.1.3.1.4 tổ chức áp dụng phải lập các kế hoạch để tiến hành các hoạt động của quá trình áp dụng sản phẩm phần mềm.
b) Các yêu cầu chất lượng liên quan đến sản phẩm và/hoặc quá trình	6.1.2.3.4.5 Quản lý các đặc trưng chất lượng của các sản phẩm hay dịch vụ phần mềm.Có thể lập các phương án tách biệt về chất lượng. 6.1.2.3.4.5 f) Quản lý an toàn, an ninh và các yêu cầu mang tính chuẩn mực khác của các sản phẩm hay dịch vụ phần mềm. Có thể lập các kế hoạch tách biệt về an toàn và an ninh.
c) Xây dựng theo nghĩa thiết lập hệ thống quản lý chất lượng và/hoặc xác định các hướng dẫn hay các thủ tục riêng biệt, phù hợp với phạm vi áp dụng của Sổ tay chất lượng và phù hợp với bất kỳ các điểm loại trừ nào đã được tuyên bố (xem TCVN ISO 9001:2008, mục 1.2)	CHÚ THÍCH Không được đề cập một cách cụ thể vì ISO/IEC 12207 được áp dụng tại cấp dự án. Tuy nhiên mối quan hệ tương giao với Hệ thống Quản lý chất lượng của tổ chức cũng được nêu trong khoản 6.2.5 về quá trình quản lý chất lượng.
d) Các thủ tục và các hướng dẫn liên quan riêng biệt về dự án, chẳng hạn, các phương án, các thiết kế, các kiểu và các thủ tục chi tiết liên quan các quy định thử nghiệm phần mềm đối với mỗi đơn vị, hệ tích hợp, hệ thống và thử nghiệm nghiệm thu (xem 8.2.4).	CHÚ THÍCH: quá trình quản lý lập tài liệu sản phẩm phần mềm, như được nêu trong mục 7.1.1.3.1.3 về quá trình áp dụng phần mềm và trong mục 7.2.1- là quá trình song hành với các hoạt động phát triển.
e) Các phương pháp, các mô hình vòng đời, các công cụ, các cách chuyển đổi ngôn ngữ lập trình, các thư viện chương trình, các cơ chế và các tài sản có thể tái sử dụng được dùng trong dự án.	7.2.3.3.1.3.a) Các chuẩn chất lượng, các phương pháp luận, các thủ tục, các công cụ để thực hiện các hoạt động đảm bảo chất lượng (hoặc những tài liệu được viện dẫn của chúng trong việc thiết lập một cách chính thức hệ thống tài liệu của tổ chức).
f) Nêu chuẩn mực để bắt đầu và kết thúc từng giai đoạn dự án	CHÚ THÍCH: Được nêu trong 7.2.6 quá trình xem xét sản phẩm phần mềm.
g) Các kiểu xem xét và các hoạt động kiểm tra xác nhận, thẩm định hiệu lực khác cần được thực hiện(xem 7.3.4 và 7.3.6)	6.1.2.3.4.5 g) Đảm bảo chất lượng (xem mục 7.2.3) 6.1.2.3.4.5 h) Kiểm tra xác nhận (xem 7.2.4) và thẩm định (xem 7.2.5) kể cả cách để kết nối với cơ quan kiểm tra xác nhận và cơ quan thẩm định- nếu có quy định.
h) Các thủ tục quản lý cấu hình cần phải tiến hành (xem 7.3.4, 7.3.5, và 7.3.6).	CHÚ THÍCH: Được nêu trong 6.3.5 các quá trình quản lý cấu hình và 7.2.2 quá trình quản lý cấu hình sản phẩm phần mềm và cũng được đề cập trong mục 7.1.1.3.1.2 trong áp dụng.
i) Các hoạt động giám sát và đo lường cần được tiến hành	CHÚ THÍCH: Giám sát là một phần của 6.1.2.3.4.8 trong quá trình cung cấp còn đo lường là một phần trong 7.2.3.3.3.5 về đo lường sản phẩm và sự đảm bảo quá trình.
j) Những người chịu trách nhiệm cho phép thông qua các đầu ra của các quá trình cho việc sử dụng tiếp theo;	CHÚ THÍCH: Những nơi mà các đầu ra của các quá trình là tài liệu thì việc này đã được nêu tại mục 7.2.1.3.2.3 trong quá trình thiết lập tài liệu.
k) Nhu cầu đào tạo sử dụng các công cụ, kỹ thuật và lịch trình đào tạo để đạt được trước kỹ năng cần thiết.	6.1.2.3.4.5 o) Đào tạo cá nhân (xem mục 6.2.4)
I) Hồ sơ phải được duy trì (xem 4.2.4)	7.2.3.3.1.3 c) Các thủ tục để xác định, thu thập, ghi chép/điền, bảo quản và hủy bỏ hồ sơ chất lượng.
m) Quản lý sự thay đổi, chẳng hạn những sự thay đổi về nguồn lực, thời hạn, về hợp đồng	CHÚ THÍCH: Đã được nêu trong mục 6.1.1.3.4.3 về cơ chế kiểm soát thay đổi giữa bên yêu cầu và bên cung cấp.
7.3.1 Hoạch định thiết kế và phát triển.
а) Các hoạt động phân tích các yêu cầu, thiết kế và phát triển, lập mã, tích hợp, thử nghiệm, cài đặt và hỗ trợ để nghiệm thu các sản phẩm phần mềm. Nó cũng bao gồm việc xác định hoặc viện dẫn đến; 1) Các hoạt động cần được thực hiện; 2) Các đầu vào đòi hỏi đối với mỗi hoạt động; 3) Các đầu ra đòi hỏi đối với mỗi hoạt động; 4) Việc kiểm tra xác nhận đòi hỏi đó với mỗi đầu ra (như 7.1.2. và 7.3.5 nêu) 5) Các hoạt động quản lý và hỗ trợ cần được thực hiện; б) Yêu cầu đào tạo cho nhóm (xem 7.1.2 k)).	6.1.2.3.4.5 o) Đào tạo nhân sự (xem 6.2.4) 7.2.3.3.1.3 e) Những hoạt động và những nhiệm vụ đã được lựa chọn từ các quá trình hỗ trợ, như kiểm tra xác nhận sản phẩm phần mềm (mục 7.2.4),thẩm định hiệu lực sản phẩm phần mềm (mục 7.2.5), xem xét sản phẩm phần mềm (mục 7.2.6), đánh giá dạng audit sản phẩm phần mềm (mục 7.2.7), và giải quyết vấn đề sản phẩm phần mềm (mục 7.2.6).
b) Lập kế hoạch kiểm soát việc tạo và cung cấp sản phẩm phần mềm	CHÚ THÍCH: Mục này trong TCVN ISO 9001:2008 không áp dụng trong ISO/IEC 12207. Nó tương đương với tất cả các hoạt động phát hành, cung cấp và dịch vụ sau cung cấp, kể cả cài đặt phần mềm (6.4.7), hỗ trợ nghiệm thu phần mềm (6.4.8), kể cả các quá trình cho chạy (6.4.9) và bảo trì (6.4.10) cũng như quá trình quản lý cấu hình (6.3.5 và 7.2.2). Nó bổ sung các yêu cầu riêng biệt qua các tiểu mục của ISO/IEC 12207 chứ không chú trọng nhiều vào việc lập kế hoạch.
c) Thu xếp các nguồn lực cho dự án, kể cả việc xây dựng các nhóm, nêu trách nhiệm, việc sử dụng các nhà cung cấp và các nguồn lực cần dùng	6.1.2.3.4.5 a) Cơ cấu tổ chức dự án, trách nhiệm, quyền hạn của mỗi đơn vị chức năng, kể cả các tổ chức bên ngoài.
d) Mối quan hệ tương giao về kỹ thuật và về tổ chức giữa các cá nhân và các nhóm khác nhau, chẳng hạn giữa các phân nhóm dự án, các nhà cung cấp, các thành viên liên quan, những người sử dụng, các đại diện của khách hàng, đại diện về đảm bảo chất lượng (xem 7.3.14)	6.1.2.3.4.5 i) Người yêu cầu phải tham gia theo nghĩa là người tiến hành các cuộc xem xét (xem 7.2.6), các cuộc đánh giá nội bộ (xem 7.2.7), các cuộc họp không chính thức, lập báo cáo, cải biên hay thay đổi, áp dụng, thông qua, nghiệm thu hay việc đánh giá các trang thiết bị. 6.1.2.3.4.5 j) người sử dụng sẽ tham gia theo các cách như thiết lập các yêu cầu về các tình huống chạy thử, các minh họa và các cách đánh giá ngôn ngữ, cú pháp lập trình.
e) Những phân tích về các rủi ro, các giả định, những mối phụ thuộc và các vấn đề có thể có liên quan thiết kế và phát triển	6.1.2.3.4.5 k) Quản lý rủi ro; đó là việc quản lý các lĩnh vực của dự án mà chúng có thể liên đới đến những rủi ro tiềm ẩn về kỹ thuật, giá cả, tiến độ. CHÚ THÍCH – Các vấn đề cũng được nêu lại qua hạng mục “quá trình giải quyết vấn đề” (7.2.8)
f) Xác định tiến độ: 1) Các giai đoạn của dự án (xem 7.1.2 j); 2) Cấu trúc để tách biệt công việc; 3) Các nguồn lực và thời hạn liên quan 4) Những mối phụ thuộc liên quan; 5) Các mốc trọng điểm; 6) Các hoạt động thẩm định kiểm tra và xác nhận tính hiệu lực (chẳng hạn 7.1.2 g)).	6.1.2.3.4.5 c) Xác định các điểm kết thúc của các công việc và các quá trình trong vòng đời, kể cả của các sản phẩm phần mềm, các dịch vụ phần mềm và của các hạng mục không có khả năng tự cung cấp.v.v đều cần được tiến hành đúng theo nguồn cấp tài chính, nhân lực, các nguồn lực vật chất, quy mô phần mềm và tiến độ gắn liền với các nhiệm vụ đó. 6.1.2.3.4.5 n). Các phương thức để lập tiến độ, để truy tìm nguồn gốc và báo cáo 7.2.3.3.1.3 d) Các nguồn lực, tiến độ và trách nhiệm tiến hành các hoạt động đảm bảo chất lượng.
g) Việc nhận dạng: 1) Các tiêu chuẩn, quy tắc, quy phạm thực hành và các thỏa thuận, phương pháp luận, mô hình vòng đời, các yêu cầu luật pháp và chế định (như mục 7.1.2 d và e) 2) Các công cụ và kỹ thuật để phát triển, kể cả việc phân loại trình độ và kiểm soát cấu hình gắn liền với các công cụ và kỹ thuật như vậy; 3) Trang thiết bị, phần cứng và phần mềm để triển khai; 4) Các quy tắc để quản lý cấu hình (như nêu ở 7.12h); 5) Phương pháp kiểm soát các sản phẩm phần mềm không phù hợp; 6) Các phương pháp để kiểm soát phần mềm được sử dụng để hỗ trợ phát triển 7) Các thủ tục để lưu trữ, sao lưu, thể hiện lại và kiểm soát việc truy cập sản phẩm phần mềm; 8) Các phương pháp để kiểm soát phòng tránh virút; 9) Các cách kiểm soát an ninh	7.1.1.3.1.3 Người sử dụng phải xây dựng các phương án để tiến hành các hoạt động của quá trình áp dụng phần mềm. Các phương án này phải nêu các tiêu chuẩn, phương pháp, công cụ, các hoạt động và các trách nhiệm gắn liền việc triển khai và việc phân cấp đối với tất cả các yêu cầu kể cả các yêu cầu về an toàn và an ninh. Nếu cần thiết, phải xây dựng chúng thành các phương án tách biệt. Các phương án này phải ở dạng văn bản và có tính khả thi. 6.1.2.3.4.5 m) Phải thực hiện việc chấp thuận/thông qua dựa theo các quy định, những sự chứng nhận đòi hỏi, tính độc quyền, tập quán, quyền sở hữu, vấn đề bảo hành và các bản quyền về cấp giấy phép.
h) Nhận dạng phương án có liên quan (kể cả phương án của hệ thống) có gắn liền với các nội dung như chất lượng (xem 7.1), quản lý rủi ro, quản lý cấu hình, quản lý nhà cung cấp, tích hợp, thử nghiệm (xem 7.3.6), quản lý việc phát hành, cài đặt, đào tạo, sao, bảo trì, sử dụng lại, thông tin và đo lường.	6.1.2.3.4.5 g) Đảm bảo chất lượng (xem mục 7.2.3). 6.1.2.3.4.5 k) Quản lý rủi ro- tức là quản lý các lĩnh vực của dự án mà chúng có thể liên quan các rủi ro tiềm năng về kỹ thuật, chi phí hoặc tiến độ. 6.1.2.3.4.5 I) Chính sách an ninh- tức là các quy tắc cần được biết và cần được truy cập theo nghĩa thông tin tại mỗi cấp độ tổ chức của dự án.
i) CHÚ THÍCH; TCVN ISO 9001:2008 không đòi hỏi các thủ tục xem xét lại hợp đồng nhưng trong mục 7.2.2 a) lại có nêu yêu cầu xem xét lại các yêu cầu trước khi chấp nhận một hợp đồng.
7.3.4 Xem xét thiết kế và phát triển
Việc xem xét thiết kế và phát triển phải được tiến hành theo những sự sắp xếp đã nêu. Các hạng mục xem xét cần cân nhắc gồm:	7.2.6.3.1.1.Những lần xem xét mang tính chu kỳ sẽ được thực hiện tại những mốc quan trọng đã định trước và phù hợp với các kế hoạch đã định của dự án. Những bên liên quan cần xác định nhu cầu cần xem xét lại mang tính đặc biệt mà trong đó các bên có thỏa thuận có thể tham gia.
a) Điều gì cần xem xét, khi nào và hình thức xem xét sẽ là dạng xem xét để minh chứng hay để ngăn ngừa một cách chính thức những thiếu sót, xem xét để kiểm tra hay xem xét dạng xuyên suốt quá trình, xem xét dưới dạng cùng rà soát	7.2.6.3.1.3 các bên có tham gia việc xem xét cần thỏa thuận những hạng mục sau cho mỗi cuộc xem xét: Lịch trình, các sản phẩm phần mềm (kết quả của từng công việc) và các vấn đề cần được xem xét; phạm vi và các thủ tục; việc bắt đầu và kết thúc một cuộc xem xét.
b) Những nhóm chức năng nào được xem là có liên quan đối với mỗi dạng xem xét, liệu nó có cần một cuộc họp xem xét không và nó cần được tổ chức và tiến hành như thế nào?	7.2.6.3.1.2 Mọi nguồn lực đòi hỏi để tiến hành các cuộc xem xét phải được chu cấp- kể cả nhân sự, địa điểm, các trang thiết bị, phần cứng, phần mềm và các công cụ. Tương tự, mục 7.2.6.3.1.3 với nội dung như trên.
c) Những loại hồ sơ nào cần được lập, ví dụ biên bản họp, các ấn phẩm, các vấn đề, các hành động và các tình trạng của mỗi hành động.	7.2.6.3.1.4 Các vấn đề được phát hiện trong các cuộc xem xét phải được lập thành hồ sơ và đưa vào quá trình giải quyết các vấn đề phần mềm (như mục 7.2.4 đòi hỏi)
d) Các phương pháp để giám sát việc áp dụng các quy tắc, quy phạm và các thỏa thuận để đảm bảo các yêu cầu được đáp ứng.	7.2.6.3.3.1 Phải thực hiện các xem xét kỹ thuật để đánh giá các sản phẩm hoặc các dịch vụ phần mềm hiện quan tâm và cung cấp bằng chứng rằng:.. b) chúng phù hợp với các tiêu chuẩn và các quy định kỹ thuật của chúng.
e) Những gì cần làm trước khi thực hiện việc xem xét, chẳng hạn thiết lập các mục tiêu, chương trình làm việc, các tài liệu đòi hỏi và vai trò của những người xem xét.	7.2.6.3.1.3 Những bên có tham gia vào việc xem xét cần thỏa thuận về những hạng mục trong mỗi cuộc xem xét, chẳng hạn, chương trình làm việc, các sản phẩm phần mềm (các kết quả của mỗi hoạt động) và các vấn đề cần được xem xét; phạm vi và các thủ tục, chuẩn mực bắt đầu và kết thúc việc xem xét. 7.2.6.3.1.2 Mọi nguồn lực đòi hỏi để tiến hành các cuộc xem xét phải được chu cấp- kể cả nhân sự, địa điểm, các trang thiết bị, phần cứng, phần mềm và các công cụ.
f) Những gì cần làm khi xem xét, kể cả các kỹ thuật được sử dụng và các chỉ dẫn cho tất cả những người tham gia.	7.2.6.3.1.3 Những bên có tham gia vào việc xem xét cần thỏa thuận về những hạng mục trong mỗi cuộc xem xét, …phạm vi và các thủ tục…
g) Chuẩn mực cần đạt của việc xem xét	7.2.6.3.1.3 …. chuẩn mực bắt đầu và kết thúc việc xem xét.
h) Những hoạt động tiếp theo nào sẽ được thực hiện để đảm bảo rằng mọi vấn đề được phát hiện trong xem xét đều được giải quyết.	7.2.6.3.1.6 Các bên tham gia phải thống nhất về đầu ra của việc xem xét và bất kỳ hạng mục công việc liên quan đến các trách nhiệm và tiêu chí kết thúc việc xem xét.
CHÚ THÍCH: TCVN ISO 9001:2008 không phân biệt giữa xem xét quản lý dự án và xem xét kỹ thuật. Điều này rất phù hợp cho các dự án phần mềm. Mặc dù tiêu chuẩn này không nêu một cách chi tiết chỉ dẫn để áp dụng TCVN ISO 9001:2008, nhưng sẽ là hữu ích và thích hợp nếu sử dụng ISO/IEC 12207 để xem xét những cơ chế xem xét lại mang tính tách biệt này.	7.2.6.3.2 Các cuộc xem xét lại quản lý dự án. Hoạt động này bao gồm những nhiệm vụ sau: 7.2.6.3.2.1 Trạng thái của dự án phải được đánh giá theo các kế hoạch, các lịch trình, các tiêu chuẩn và các chỉ dẫn hiện hành của dự án. Đầu ra của việc xem xét phải được cấp lãnh đạo tương ứng cân nhắc và cần nêu các hạng mục sau: a) chỉ rõ các hoạt động biểu thị tiến triển theo kế hoạch nhờ dựa vào việc đánh giá hoạt động hoặc trạng thái sản phẩm phần mềm. b) duy trì một hình thức kiểm soát tổng thể dự án bằng việc phân bổ thích hợp nguồn lực. c) sự thay đổi định hướng dự án hay việc xác định những nhu cầu của kế hoạch thay thế. d) Đánh giá và quản lý các nguồn rủi ro có thể gây nguy hại tới sự thành công của dự án.
CHÚ THÍCH: TCVN ISO 9001:2008 không phân biệt giữa xem xét quản lý dự án và xem xét kỹ thuật. Điều này rất phù hợp cho các dự án phần mềm. Mặc dù tiêu chuẩn này không nêu một cách chi tiết chỉ dẫn để áp dụng TCVN ISO 9001:2008, nhưng sẽ là hữu ích và thích hợp nếu sử dụng ISO/IEC 12207 để xem xét những cơ chế xem xét lại mang tính tách biệt này.	7.2.6.3.3 Xem xét kỹ thuật. Hoạt động này bao gồm những nhiệm vụ sau: 7.2.6.3.3.1 Các xem xét kỹ thuật phải được tiến hành để đánh giá sản phẩm hay dịch vụ phần mềm đang xét và phải cung cấp bằng chứng về: a) Chúng đầy đủ b) Chúng phù hợp với các tiêu chuẩn và các quy định của chúng; c) Những sự thay đổi đối với chúng được vận dụng một cách đầy đủ và những sự thay đổi này chỉ ảnh hưởng tới những lĩnh vực đã được quá trình quản lý cấu hình xác nhận (xem mục 7.2.2.) d) Chúng được thực hiện đúng lịch trình hiện hành e) Chúng sẵn sàng cho hành động đã được dự định của giai đoạn tiếp theo {theo nghĩa người biên soạn: điều này xuất phát từ lần sửa đổi 1}. f) Việc phát triển, vận hành hay bảo trì hiện đang được tiến hành theo đúng các kế hoạch, lịch trình, các tiêu chuẩn và các chỉ dẫn của dự án.

 

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

[1] ISO/IEC/TR 9126-2:2003, Software engineering– Product quality– Part 2: External metrics (Phần mềm máy tính – Chất lượng sản phẩm – Phần 2: Thước đo bên ngoài)

[2] ISO/IEC/TR 9126-3:2003, Software engineering– Product quality– Part 3: Internal metrics (Phần mềm máy tính – Chất lượng sản phẩm – Phần 3: Thước đo nội bộ)

[3] ISO/IEC/TR 9126-4:2004, Software engineering– Product quality– Part 4: Quality in use metrics (Phần mềm máy tính – Chất lượng sản phẩm – Phần 4: Chất lượng khi sử dụng thước đo)

[4] TCVN ISO 10007:2007, Hệ thống quản lý chất lượng – Hướng dẫn quản lý cấu hình

[5] ISO/IEC/IEEE 12207:2008, Systems and software engineering–Software life cycle processes (Kỹ thuật phần mềm máy tính – Các quá trình vòng đời phần mềm)

[6] ISO/IEC 14102:2008, Information technology- Guideline for the evaluation and selection of CASE tools (Công nghệ thông tin – Hướng dẫn đánh giá và lựa chọn các công cụ CASE)

[7] ISO/IEC/TR 14759:1999, Software engineering– Mock up and prototype– A categorization of software mock up and prototype models and their use (Kỹ thuật phần mềm – Giả định và nguyên mẫu – Phân loại phần mềm mô hình giả định và nguyên mẫu và việc sử dụng các mô hình)

[8] ISO/IEC 14764:2006, Software Engineering – Software Life Cycle Processes – Maintenance (Phần mềm máy tính – Quá trình vòng đời phần mềm – Bảo trì)

[9] ISO/IEC 15026-3:2011, Systems and software engineering– Systems and software assurance – Part 3: System integrity levels (Kỹ thuật hệ thống và phần mềm – Hệ thống và đảm bảo phần mềm – Phần 3: Mức nhuần nhuyễn hệ thống)

[10] ISO/IEC 15504-1:2004, Information technology – Process assessment- Part 1: Concepts and vocabulary (Công nghệ thông tin – Đánh giá quá trình – Phần 1: Khái niệm và thuật ngữ)

[11] ISO/IEC 15504-2:2003, Information technology– Process assessment– Part 2: Performing an assessment (Công nghệ thông tin – Đánh giá quá trình – Phần 2: Thực hiện đánh giá)

[12] ISO/IEC 15504-3:2004, Information technology– Process assessment– Part 3: Guidance on performing an assessment (Công nghệ thông tin – Đánh giá quá trình – Phần 3: Hướng dẫn thực hiện đánh giá)

[13] ISO/IEC 15504-4:2004, Information technology– Process assessment– Part 4: Guidance on use for process improvement and process capability determination (Công nghệ thông tin – Đánh giá quá trình – Phần 4: Hướng dẫn cải tiến quá trình và xác định năng lực quá trình)

[14] ISO/IEC 15504-5:2012, Information technology– Process assessment– Part 5: An exemplar software life cycle process assessment model (Công nghệ thông tin – Đánh giá quá trình – Phần 5: Ví dụ về mô hình đánh giá quá trình vòng đời phần mềm)

[15] ISO/IEC 15939:2007, Systems and software engineering– Measurement process (Kỹ thuật hệ thống và phần mềm – Quá trình đo)

[16] ISO/IEC 16085:2006, Systems and software engineering – Life cycle processes – Risk management (Kỹ thuật hệ thống và phần mềm – Quá trình vòng đời – Quản lý rủi ro)

[17] ISO/IEC/IEEE 16326:2009, Systems and software engineering– Life cycle processes– Project management (Kỹ thuật hệ thống và phần mềm – Quá trình vòng đời – Quản lý dự án)

[18] ISO/IEC 19761:2011, Software engineering– COSMIC: a functional size measurement method (Kỹ thuật phần mềm – COSMIC: phương pháp đo quy mô chức năng)

[19] ISO/IEC 20926:2009, Software and systems engineering– Software measurement– IFPUG functional size measurement method 2009 (Kỹ thuật hệ thống và phần mềm – Đo phần mềm – Phương pháp đo quy mô chức năng IFPUG)

[20] ISO/IEC 20968:2002, Software engineering – Mk II Function Point Analysis – Counting Practices Manual (Kỹ thuật phần mềm – Phân tích điểm chức năng Mk II – Sổ tay thực hành đếm)

[21] ISO/IEC/TR 24748-1:2010, Systems and software engineering– Life cycle management – Part 1: Guide for life cycle management (Kỹ thuật hệ thống và phần mềm – Quản lý vòng đời – Phần 1: Hướng dẫn quản lý vòng đời)

[22] ISO/IEC/TR 24748-3:2011, Systems and software engineering – Life cycle management – Parts: Guide to the application of ISO/IEC 12207 (Software life cycle processes) (Kỹ thuật hệ thống và phần mềm – Quản lý vòng đời – Phần 3: Hướng dẫn áp dụng ISO/IEC 12207 (Quá trình vòng đời phần mềm)

[23] ISO/IEC 25001:2007, Software engineering – Software product Quality Requirements and Evaluation (SQuaRE) – Planning and management (Kỹ thuật phần mềm – Các yêu cầu và đánh giá chất lượng sản phẩm phần mềm (SquaRE) – Hoạch định và quản lý

[24] ISO/IEC 25010:2011, Systems and software engineering– Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models (Kỹ thuật hệ thống và phần mềm – Các yêu cầu và đánh giá hệ thống và chất lượng phần mềm (SQquaRE)

[25] ISO/IEC 25040:2011, Systems and software engineering– Systems and software Quality Requirements and Evaluation (SQuaRE) – Evaluation process (Kỹ thuật hệ thống và phần mềm – Các yêu cầu và đánh giá hệ thống và chất lượng phần mềm)

[26] ISO/IEC 25041:2012, Systems and software engineering– Systems and software Quality Requirements and Evaluation (SQuaRE) – Evaluation guide for developers, acquirers and independent evaluators (Kỹ thuật hệ thống và phần mềm – Các yêu cầu và đánh giá hệ thống và chất lượng phần mềm (SQquaRE) – Hướng dẫn đánh giá cho người phát triển, người mua và người đánh giá độc lập

[27] ISO/IEC 25051:2006, Software engineering– Software product Quality Requirements and Evaluation (SQuaRE) – Requirements for quality of Commercial Off-The-Shelf (COTS) software product and instructions for testing (Kỹ thuật hệ thống và phần mềm – Các yêu cầu và đánh giá hệ thống và chất lượng phần mềm (SQquaRE) – Yêu cầu đối với chất lượng sản phẩm phần mềm thương mại và hướng dẫn thử nghiệm)

[28] ISO/IEC 26514:2008, Systems and software engineering– Requirements for designers and developers of user documentation (Kỹ thuật hệ thống và phần mềm – Các yêu cầu đối với người thiết kế và xây dựng tài liệu người dùng)

[29] ISO/IEC 29148:2011, Systems and software engineering – Life cycle processes – Requirements engineering (Kỹ thuật hệ thống và phần mềm – Quá trình vòng đời – Các yêu cầu kỹ thuật

 

MỤC LỤC

Lời nói đầu

1  Phạm vi áp dụng

1.1  Khái quát

1.2  Áp dụng

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

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

4  Hệ thống quản lý chất lượng

4.1  Yêu cầu chung

4.2  Yêu cầu về hệ thống tài liệu

5  Trách nhiệm của lãnh đạo

5.1  Cam kết của lãnh đạo

5.2  Hướng vào khách hàng

5.3  Chính sách chất lượng

5.4  Hoạch định

5.5  Trách nhiệm, quyền hạn và trao đổi thông tin

5.6  Xem xét của lãnh đạo

6  Quản lý nguồn lực

6.1  Cung cấp các nguồn lực

6.2  Nguồn nhân lực

6.3  Cơ sở hạ tầng

6.4  Môi trường làm việc

7  Tạo sản phẩm

7.1  Hoạch định việc tạo sản phẩm

7.2  Các quá trình liên quan đến khách hàng

7.3  Thiết kế và phát triển

7.4  Mua hàng

7.5  Sản xuất và cung cấp dịch vụ

7.6  Kiểm soát thiết bị theo dõi và đo lường

8  Đo lường, phân tích và cải tiến

8.1  Khái quát

8.2  Theo dõi và đo lường

8.3  Kiểm soát sản phẩm không phù hợp

8.4  Phân tích dữ liệu

8.5  Cải tiến

Phụ lục A (tham khảo) Tóm tắt hướng dẫn áp dụng TCVN ISO 9001:2008 trong các tiêu chuẩn của Ban kỹ thuật ISO/IEC/TC1/SC7 và ISO/TC176

Phụ lục B (tham khảo) Hoạch định trong TCVN ISO/IEC 90003 và ISO/IEC 12207

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