Hướng dẫn Thực hành tốt tự động hóa sản xuất dược phẩm GAMP

Khi vẽ một thông số kỹ thuật, hãy xem xét những điều sau:

1. Mỗi yêu cầu cần được mô tả rõ ràng, nếu yêu cầu sử dụng sơ đồ, bảng và không quá 250 từ.

2. Các yêu cầu không được lặp lại hoặc mâu thuẫn với nhau.

3. URS phải bao gồm các yêu cầu của chương trình chứ không phải cung cấp các giải pháp.

4. Mỗi yêu cầu phải được truy nguyên, tức là. nó sẽ có thể để kiểm tra nó.

5. URS phải rõ ràng cho cả khách hàng và nhà thầu, và nên tránh mọi sự mơ hồ hoặc biệt ngữ.

6. Khi có thể, URS nên phân biệt giữa các yêu cầu bắt buộc và mong muốn.

7. Khách hàng và nhà thầu có thể được yêu cầu xem xét chính thức URS. Điều này sẽ giúp xác minh rằng các yêu cầu của URS đã được hiểu và liệu các yêu cầu của URS có được đề cập trong Đặc tả chức năng hay không.

3.2. Nội dung tài liệu

Phần này xác định những phần và tiểu mục nào nên được bao gồm trong URS. Tất cả các phần sau đây phải được bao gồm. Nếu các yêu cầu cho phần này không được chỉ định, nó được đánh dấu là ‘Không áp dụng’.

3.2.1. Giới thiệu

Phần này chứa các thông tin sau:

1. Tài liệu do ai vẽ ra, trên cơ sở nào và nhằm mục đích gì.

2. Tình trạng hợp đồng của văn bản (hợp đồng, thỏa thuận, cam kết, thỏa thuận).

3. Mối quan hệ với các tài liệu khác.

3.2.2. Hiểu biết chung về hệ thống

Phần này mô tả hệ thống theo các thuật ngữ chung, giải thích nó dùng để làm gì và yêu cầu của nó. Phần này bao gồm các phần phụ sau:

1. Điều kiện tiên quyết để tạo ra hệ thống (ví dụ, chiến lược công ty, nghiên cứu trước).

2. Các mục tiêu chính của hệ thống và lợi ích của việc sử dụng hệ thống.

3. Các chức năng chính của hệ thống và các giao diện.

3.2.3. Yêu cầu hoạt động

Phần này chỉ rõ các yêu cầu hoạt động – chức năng hệ thống cấu trúc, dữ liệu, giao diện và môi trường hoạt động. Các yêu cầu quan trọng cần được nhấn mạnh và xác định như vậy.

Các phần phụ sau đây nên được bao gồm:

3.2.3.1. Chức năng

Phần phụ xác định các chức năng hệ thống, phương thức hoạt động và hành vi của hệ thống. Nó phải mô tả những điều sau:

– các chức năng cần thiết. Điều này phải bao gồm thông tin về quy trình sản xuất hoặc hệ thống thủ công hiện có, trừ khi có quy định khác ở trên.

– tính toán, bao gồm tất cả các thuật toán quyết định.

– các chế độ hoạt động (ví dụ, khởi động, tắt hệ thống, thử nghiệm, trung hòa các lỗi).

– Yêu cầu về tốc độ và sự đồng bộ. Phải định lượng và chính xác.

– Thất bại. Những hành động nào được yêu cầu trong trường hợp phần mềm hoặc phần cứng không hoạt động.

– độ tin cậy và an toàn.

3.2.3.2. Dữ liệu

Phần này thảo luận về các yêu cầu xử lý dữ liệu. Nó phải mô tả những điều sau:

– Định nghĩa dữ liệu. Đồng thời, các thông số quan trọng của chúng cũng được thảo luận.

– Yêu cầu về băng thông.

– Yêu cầu về tốc độ truy cập.

– Yêu cầu đối với công tác lưu trữ.

3.2.3.3. Giao diện

Phần này xác định các giao diện có thể có đối với hệ thống. Bao gồm các phần phụ sau:

1. Giao diện người dùng – được mô tả cho từng vai trò (ví dụ người điều hành, quản trị viên kho, người quản lý hệ thống, v.v.) và / hoặc các chức năng khi thích hợp.

2. Giao diện với các hệ thống khác.

3. Giao diện với thiết bị (ví dụ: cảm biến / cơ cấu chấp hành).

3.2.3.4. Môi trường

Phần xác định hệ thống sẽ hoạt động trong môi trường nào. Bao gồm các phần phụ sau:

1. Chỗ ở. Vị trí vật lý của thiết bị hoặc nơi làm việc có thể ảnh hưởng đến hiệu suất của hệ thống (ví dụ: liên lạc đường dài, khu vực hạn chế).

2. Điều kiện vật chất (ví dụ như phòng bụi hoặc sạch sẽ, v.v.).

3.2.4. Những hạn chế

Phần này xác định các hạn chế đối với đặc tả hệ thống. Nên chứa các phần phụ sau:

1. Khung thời gian.

2. Tính tương thích. Phải xem xét khả năng tương thích với bất kỳ hệ thống hoặc thiết bị hiện có nào, cũng như với bất kỳ chiến lược phát triển nào có thể có của công ty.

3. Khả năng sử dụng. Các yêu cầu về độ tin cậy của hệ thống và thời gian tối đa cho phép để sửa chữa hiện tại hoặc thời gian ngừng hoạt động khác được thảo luận.

4. Ràng buộc về thủ tục (ví dụ, nghĩa vụ pháp lý hoặc luật định, sự phản đối của pháp luật, phương pháp làm việc hoặc trình độ kỹ năng của người dùng).

5. Bảo trì (ví dụ: dễ bảo trì, khả năng mở rộng, nâng cấp, tuổi thọ dự kiến, hỗ trợ lâu dài).

3.2.5. Vòng đời

Phần thiết lập các điều khoản cho sự phát triển của hệ thống. Chứa các phần phụ sau:

1. Phát triển (ví dụ: quản lý dự án và các thủ tục đảm bảo chất lượng, các phương pháp phát triển bắt buộc).

2. Kiểm tra (ví dụ: yêu cầu kiểm tra đặc biệt, dữ liệu kiểm tra, kiểm tra tải – thử tải, kiểm tra mô phỏng).

3. Giao hàng tận nơi. Xác định những gì nên được phân phối. Điều này bao gồm những điều sau:

– Làm thế nào các mặt hàng được giao được xác định.

– Chúng được cung cấp ở dạng nào (ví dụ: định dạng và phương tiện).

– Tài liệu. Các tài liệu mà nhà cung cấp phải cung cấp (ví dụ: đặc điểm kỹ thuật chức năng, thông số kỹ thuật thử nghiệm, thông số kỹ thuật thiết kế, v.v.).

– Dữ liệu cần chuẩn bị hoặc chuyển đổi.

-Dụng cụ.

– Tập huấn.

– Thiết bị phục vụ công tác lưu trữ.

4.Hộ tống . Phần mô tả những hỗ trợ nào sẽ cần thiết sau khi chương trình được chấp nhận.

3.2.5. Bảng chú giải

Phần này bao gồm các giải thích rõ ràng về các thuật ngữ có thể không quen thuộc với người đọc URS.

4. Đính kèm

Không có Đính kèm.

PHỤ LỤC B: Tài liệu và quy trình phân tích phần mềm

Chịu trách nhiệm: Khách hàng và Nhà cung cấp

1. Giới thiệu

Quy trình này mô tả phương pháp tiến hành, đăng ký và giám sát việc thực hiện:

– Phân tích tài liệu chính thức;

– Phân tích phần phần mềm của ứng dụng (đôi khi được gọi là “phân tích mã chương trình”).

2. Ứng dụng

Phương pháp luận này áp dụng cho tài liệu và phần mềm do nhà cung cấp cung cấp phù hợp với Kế hoạch chất lượng.
3. Thủ tục

3.1. Phân tích tài liệu

Việc phân tích tài liệu được thực hiện trước khi tài liệu được viết chính thức.

Đánh giá được chính thức hóa và một quy trình được soạn thảo dựa trên Báo cáo đánh giá [1].

Việc xem xét được thực hiện bởi các cá nhân được phê duyệt bởi kế hoạch hoặc được chỉ định bởi các nhà quản lý cấp cao.

Các bản sao của tài liệu được gửi để phân tích nên được lưu hành trước để đảm bảo việc chuẩn bị thích hợp.

Trong quá trình làm việc, mỗi phần của tài liệu cần được phân tích một cách có hệ thống. Nếu một phần được thông qua mà không có bình luận, điều này sẽ được ghi lại trong biên bản.

Việc gửi tài liệu chính thức cho ai được các thành viên của ủy ban đồng ý và đưa vào giao thức [1].

Các hiệu chỉnh được xác định trong quá trình phân tích được thực hiện theo phần Theo dõi.

Và chỉ khi tất cả các thay đổi do ủy ban đề xuất được thực hiện đối với phiên bản cuối cùng của tài liệu, tài liệu mới có thể được ký. Phiên bản gốc của tài liệu phải được giữ lại.

Tất cả các Báo cáo Đánh giá sẽ được ghi lại và lập chỉ mục theo Tóm tắt Đánh giá [2].

3.2. Phân tích phần mềm của ứng dụng

Việc phân tích phần mềm ứng dụng được thực hiện bởi những người được kế hoạch phê duyệt. Nó là mong muốn bao gồm nhà phát triển phần mềm hoặc tác giả.

Phân tích phần mềm cần được thực hiện chính thức và được ghi lại trên cơ sở Báo cáo xác minh [1].

Các khía cạnh sau đây cần được xem xét:

– Sơ đồ phần mềm.

– Tuân thủ các tiêu chuẩn mã hóa.

– Phần mềm logic.

– Mã dự phòng.

– Các thuật toán quan trọng nhất (theo Đặc tả yêu cầu của người dùng).

Các thay đổi đã thỏa thuận, nhu cầu phát sinh từ việc phân tích phần mềm, được thực hiện theo phần Tiếp theo của phương pháp luận này.

Tất cả các thay đổi phải được thực hiện trước khi giao phần mềm.

Tất cả các báo cáo kiểm toán cần được ghi lại và lập chỉ mục theo Tóm tắt Báo cáo [2].

Bản in, sơ đồ khối, v.v. cần được lưu giữ cùng với báo cáo kiểm tra.

3.3. Loại bỏ các nhận xét được xác định trong cuộc đánh giá

Đối với mỗi thay đổi, một người chịu trách nhiệm được chỉ định phải hoàn thành công việc trước ngày đã được phê duyệt. Khi kết thúc công việc, tất cả các nhận xét về cách thực hiện các thay đổi được ghi lại trong [1], và công việc được coi là đã hoàn thành. Khi tất cả các thay đổi đã được thực hiện, báo cáo sẽ được đóng lại. Bản tóm tắt của các báo cáo [2] được điều chỉnh có tính đến các sửa đổi được thực hiện.

Báo cáo đánh giá [1] và tóm tắt báo cáo [2] được giám đốc dự án xem xét định kỳ. Nếu các thay đổi không được thực hiện theo kế hoạch, hoặc không có hồ sơ tiến độ, người quản lý dự án sẽ hành động.

3.4. Các quy định chung

Thông số kỹ thuật thiết kế mô-đun phần mềm thiên về phân tích phần mềm hơn là phân tích tài liệu, miễn là chúng được viết bằng sơ đồ logic hoặc mã giả. Nếu đặc điểm kỹ thuật này được viết dưới dạng văn bản, thì nó đề cập đến việc phân tích tài liệu.

4. Đính kèm

[1] Biểu mẫu 9, PHỤ LỤC R – Báo cáo đánh giá

[2] Biểu mẫu 10, PHỤ LỤC R – Tóm tắt đánh giá

PHỤ LỤC C:

Thủ tục kiểm toán nhà cung cấp

Chịu trách nhiệm: Khách hàng

1. Giới thiệu

Phương pháp luận này mô tả quá trình khách hàng xác minh nhà cung cấp phần mềm: lập kế hoạch, thực hiện và sửa đổi.

2. Ứng dụng

Phương pháp này được sử dụng khi tiến hành đánh giá bên ngoài đối với các nhà cung cấp hệ thống tự động, là một phần của hệ thống đánh giá nhà cung cấp chính thức, theo Kế hoạch xác thực của khách hàng.

3. Thủ tục

3.1. Kiểm toán viên

Theo ý kiến ​​của người quản lý dự án, những nhân viên có đủ kinh nghiệm và trình độ chuyên môn sẽ được bổ nhiệm làm kiểm toán viên.

3.2. Lập kế hoạch kiểm toán

Trong quá trình xác nhận tổng thể cho một hệ thống tự động, khách hàng phải đảm bảo rằng nhà cung cấp có thể đáp ứng tất cả các yêu cầu đặt ra trong Kế hoạch xác nhận cho hệ thống đó. Điều này có thể yêu cầu kiểm soát chất lượng bên ngoài.

Khách hàng lưu trữ tất cả các tài liệu kiểm toán và dựa trên dữ liệu nhận được, đưa ra các khuyến nghị phù hợp với mục 3.5 của quy trình này.

Khách hàng tuân thủ Lịch trình Đánh giá Chất lượng Bên ngoài, Lịch trình này xác định tần suất các cuộc đánh giá đó sẽ được thực hiện. Tần suất kiểm tra phụ thuộc vào một số yếu tố: đơn hàng đã được hoàn thành tốt như thế nào trong thời gian trước đó (dựa trên các cuộc kiểm tra trước đó), tần suất làm việc của công ty khách hàng với nhà cung cấp này, v.v.

Cần nhớ rằng ngay cả khi Hệ thống chất lượng nhất định của nhà cung cấp được đăng ký theo Tiêu chuẩn chất lượng quốc gia hoặc quốc tế (ví dụ: ISO 9000), thì việc kiểm tra theo lịch trình thường xuyên là cần thiết.

3.3. Chuẩn bị và thực hiện đánh giá

Các cuộc đánh giá có thể được tiến hành và lập thành văn bản theo hướng dẫn nêu trong ISO 10011 Phần 1. Danh sách kiểm tra sau đây được sử dụng trong cuộc đánh giá.

3.4. Hoàn thành kiểm toán

Các báo cáo kiểm toán được lưu giữ như một phần của tài liệu tổng thể của dự án.

Sau khi nhận được báo cáo kiểm toán, khách hàng đưa ra một trong các quyết định sau:

– chấp thuận nhà cung cấp mà không có điều kiện

– phê duyệt nhà cung cấp sau khi thực hiện các thay đổi theo quy định của Báo cáo đánh giá chất lượng bên ngoài

– phối hợp tài liệu Hệ thống chất lượng với nhà cung cấp cho các mục đích hợp đồng

– cấm làm việc với nhà cung cấp.

3.5. Chỉnh lý, sửa đổi và giám sát

Nếu trong quá trình đánh giá, nhà cung cấp có nghĩa vụ thực hiện một số thay đổi nhất định, đánh giá viên theo dõi quá trình này và lập tài liệu xác nhận rằng tất cả các thay đổi đã được thực hiện, sau đó công việc theo hợp đồng sẽ tiếp tục.

Báo cáo đánh giá chất lượng bên ngoài cũng xác định tần suất của các lần tái khám và kế hoạch đánh giá thêm.

4. Đính kèm

[1] IS010011 Phần 1 Hướng dẫn Đánh giá Hệ thống Chất lượng hoặc BS7229 Hướng dẫn Tiêu chuẩn Anh về Kiểm toán Hệ thống Chất lượng

[2] Hệ thống chất lượng ISO 9000 hoặc BS5750 Hệ thống chất lượng tiêu chuẩn Anh

5. Danh sách kiểm tra

Sau đây là danh sách kiểm tra để đánh giá các nhà cung cấp tự động hóa. Nó chỉ chứa những điểm chính, trong khi trong từng trường hợp cụ thể, có thể cần phải kiểm tra thêm các yếu tố khác.

5.1. Tổ chức

– Cơ cấu quản lý (vai trò, trách nhiệm, vị trí trong cuộc đánh giá (QA)

– Chính sách của công ty

– Tài liệu về hệ thống quản lý chất lượng (Sổ tay hướng dẫn, Quy trình)

– Bất kỳ chứng chỉ chất lượng được công nhận.

5.2. Lập kế hoạch

– Kiểm tra hợp đồng

– Kế hoạch // chất lượng của dự án (khung thời gian, vòng đời, hoạt động, nhân sự, ràng buộc, xác minh

– Giám sát dự án

– Tài liệu về thanh tra

– Hồ sơ dự án.

5.3. Sự chỉ rõ

– Đặc điểm kỹ thuật yêu cầu của người dùng

– Đặc điểm kỹ thuật chức năng

– Đặc điểm kỹ thuật thiết kế phần mềm

– Thông số kỹ thuật thiết kế phần cứng

– Đánh giá được lập thành văn bản

– Phương pháp thiết kế được sử dụng

– Các chỉ số đo lường hiệu suất của lập trình viên / nhà phân tích.

5.4. Thực hiện

– Mã nguồn (có thể truy cập, có cấu trúc, tài liệu tốt)

– Tài liệu về đánh giá mã nguồn.

5.5. Thử nghiệm

– Phần mềm thử nghiệm / Dữ liệu thử nghiệm / Trình mô phỏng

– Thông số kỹ thuật kiểm tra phần mềm

– Kết quả kiểm thử phần mềm

– Đặc điểm kỹ thuật kiểm tra phần cứng

– Kết quả kiểm tra phần cứng

– Đặc điểm kỹ thuật của thử nghiệm chấp nhận hệ thống (trên lãnh thổ của nhà phát triển, tại chỗ)

– Kết quả kiểm tra hệ thống.

– Tài liệu về các cuộc thanh tra.

5.6. Hoàn thành

– Chuyển giao vật tư dự án (chứng chỉ hợp quy, bảo lãnh)

– Tài liệu người dùng

– Hỗ trợ

5,7. Các biện pháp kiểm soát

– Quản lý tài liệu

– Quản lý cấu hình phần mềm (Kiểm soát phần mềm)

– Kiểm soát thay đổi (tài liệu, phần mềm)

– Quản lý hệ thống (truy cập, bảo mật, sao lưu, công cụ phần mềm)

– Lưu trữ

– Kiểm soát hợp đồng phụ

– Kiểm tra nội bộ (kiểm toán)

– Những gì được mua

– Đào tạo

– Hỗ trợ

PHỤ LỤC D:

Quy trình sản xuất, kiểm soát và phát hành phần mềm.

Chịu trách nhiệm: Nhà cung cấp

1. Giới thiệu

Tài liệu này xác định vị trí quản lý dự án, các tiêu chuẩn lập trình phần mềm và phương pháp luận điều khiển cấu hình.

2. Ứng dụng

Kỹ thuật này được áp dụng cho tất cả các phần mềm được phát triển trong khuôn khổ dự án này. Nếu dự án không phù hợp với quy trình này, hoặc có những sai lệch, điều này cần được ghi nhận trong Kế hoạch chất lượng [1].

3. Thủ tục

3.1. Sản xuất phần mềm

Trong bất kỳ dự án nào, trước hết, các tiêu chuẩn mã hóa được xác định, mà họ tuân thủ trong quá trình lập trình. Các quy ước về mã hóa nên bao gồm các chú thích và sơ đồ. Tất cả những điều này được ghi lại, ví dụ, trong ghi chú dự án với các Đính kèm thích hợp trong Kế hoạch chất lượng.

Mỗi dự án đặt ra các tiêu chuẩn riêng để đặt tên cho các thư mục và tệp, và điều này cũng nhất thiết phải được lập thành văn bản với các tài liệu tham khảo thích hợp trong Kế hoạch Chất lượng.

Khi cần thiết, một tập hợp các tệp hàng loạt để quản lý thiết kế cũng được tạo, cụ thể là cho:

– Biên dịch các mô-đun phần mềm nguồn

– Bố cục của các mô-đun phần mềm cuối cùng

– Chạy hình ảnh thực thi.

Các tệp lệnh phải đủ chung để tất cả các thành viên trong nhóm có thể sử dụng chúng.

Sau khi mã chương trình được tạo và biên dịch thành công, nó phải được phân tích quan trọng theo [2]. Việc đánh giá quan trọng của chương trình được thực hiện trước khi kiểm tra chấp nhận phần mềm.

3.2. Kiểm soát cấu hình

Một phương pháp luận kiểm soát phần mềm nên được phát triển trong mỗi dự án để các bản cập nhật cho phần mềm bị đóng băng được xử lý một cách nhất quán và được kiểm soát thích hợp. Cấu hình phần mềm được giám sát theo Kế hoạch quản lý cấu hình.

3.3. Kế hoạch quản lý cấu hình

Kế hoạch quản lý cấu hình được chuẩn bị cho bất kỳ dự án phần mềm nào và là một phần của Kế hoạch chất lượng.

Kế hoạch quản lý cấu hình bao gồm các mục sau:

– Tổ chức và phân bổ trách nhiệm với các tham chiếu thích hợp trong Kế hoạch chất lượng.

– Các hoạt động quản lý cấu hình, xem bên dưới.

– Các phương pháp quản lý cấu hình được sử dụng.

– Dấu hiệu cho biết từng phần tử sẽ chịu sự kiểm soát cấu hình phần mềm ở giai đoạn nào của công việc.

3.3.1. Hoạt động quản lý cấu hình

– Nhận dạng cấu hình và truy xuất nguồn gốc.

Mỗi phần mềm phải có một số / tên nhận dạng duy nhất.

Số / tên phải sao cho có thể theo dõi mã đến cấp tiếp theo, cấp cao nhất để tất cả các phần tử phần mềm có thể được truy tìm theo các thông số kỹ thuật có liên quan, bằng cách đánh số / tên hoặc văn bản tương ứng trong mô-đun đầu trang.

Quy ước đánh số / đặt tên cần được mô tả rõ ràng.

– Thay đổi kiểm soát

Các thay đổi được kiểm soát theo [3].

Tất cả các yêu cầu thay đổi phải được đăng ký, ví dụ, dưới dạng yêu cầu thay đổi được mô tả trong [3], được lưu trữ trong “Sổ đăng ký ứng dụng thay đổi” thích hợp.

– Báo cáo trạng thái cấu hình

Cấu hình và trạng thái phần mềm nên được xác định cho từng dự án, ví dụ, ở dạng danh sách, sẽ chỉ ra số phiên bản và các yêu cầu thay đổi tương ứng.3.4. Nhận dạng và truy xuất nguồn gốc của các mô-đun phần mềm

3.4.1. Nhận dạng các mô-đun phần mềm

Mỗi mô-đun phần mềm trong tiêu đề / tiêu đề của nó phải chứa các thông tin sau:

– Tên / tên mô-đun

– Tên / tên của các tệp nguồn cấu thành

– Số phiên bản mô-đun

– Tên và số dự án (nếu có)

– Mô tả ngắn gọn về mô-đun

– Tất cả các tệp lệnh được sử dụng để biên dịch và liên kết mô-đun

– Lịch sử của những thay đổi. Mô tả của mỗi thay đổi phải chứa các thông tin sau:

Thay đổi số yêu cầu

Số phiên bản mới

Ngày sửa đổi (các)

Tên viết tắt của (những) người đã thực hiện thay đổi(Các) tệp gốc đã được sửa đổi.

3.4.2. Truy xuất nguồn gốc mô-đun phần mềm

Tất cả các thay đổi đối với mô-đun phần mềm phải được mô tả rõ ràng trong các tệp mã hóa nguồn.

Các bổ sung được mô tả thông qua việc sử dụng nhận xét tham chiếu đến số Yêu cầu Thay đổi tương ứng.

Việc xóa có thể được mô tả theo hai cách:

– Nhận xét về mã và đánh dấu xóa thông qua liên kết đến Yêu cầu thay đổi tương ứng

hoặc

– Xóa mã và chỉ báo xóa thông qua liên kết đến Yêu cầu thay đổi tương ứng.

4. Đính kèm

[1] PHỤ LỤC G – Chất lượng và Kế hoạch Dự án

[2] PHỤ LỤC B – Đánh giá tài liệu và phần mềm

[3] PHỤ LỤC F – Kiểm soát thay đổi

PHỤ LỤC E:

Quy trình chuẩn bị, kiểm soát và phát hành tài liệu

Chịu trách nhiệm: Nhà cung cấp

1. Giới thiệu

Phương pháp luận này mô tả hệ thống chuẩn bị, phân tích, phê duyệt và phát hành trực tiếp các tài liệu.

2. Ứng dụng

Quy trình này được áp dụng cho tài liệu dự án như được quy định trong Kế hoạch chất lượng của nhà cung cấp.

3. Thủ tục

3.1 Chuẩn bị tài liệu

Các tiêu chuẩn tài liệu được thống nhất tại địa phương. Điều này bao gồm thứ tự của thủ tục giấy tờ, kiểu dáng và đánh số. Tất cả các tài liệu được lập theo thủ tục được chấp nhận. Các chữ ký chứng thực trong mỗi văn bản phải kèm theo bảng chỉ dẫn chức vụ của những người ký văn bản.

Trước khi tài liệu được chấp nhận cuối cùng, một bản thảo sơ bộ được soạn thảo và gán một số / tên (ví dụ: thứ tự bảng chữ cái bắt đầu bằng A, sau đó là số phiên bản).

Người khởi tạo chịu trách nhiệm về tài liệu cho đến khi nó được chính thức xem xét.

3.2 Xem xét và phê duyệt tài liệu

Tất cả các tài liệu phải được xem xét chính thức theo [7].

Khi phân tích một tài liệu, cái gọi là Lịch sử Tài liệu [1] sẽ mở ra, được lưu trữ trong Tệp Tài liệu Chính theo mục

3.6 của quy trình này.

Sau khi thực hiện các thay đổi, nhu cầu đã được thể hiện qua việc phân tích tài liệu, tài liệu sẽ chuyển sang giai đoạn phát triển tiếp theo.

Chữ ký phê duyệt cần thiết cho tài liệu này hoặc do ban quản lý yêu cầu được đặt bằng cách sử dụng [3]. Chữ ký chính thức ở cuối tài liệu được đặt bởi hai hoặc nhiều nhân viên có trách nhiệm.

Chữ ký phê duyệt xác nhận với đầy đủ trách nhiệm rằng tài liệu đã được nghiên cứu kỹ lưỡng bởi người ký nó.

Thay đổi tiếp tục được thực hiện theo với mục 3.5 của thủ tục này.

Bản sao dự thảo tài liệu đã được đánh giá chính thức và báo cáo đánh giá sẽ được giữ lại theo Mục 3.7 của thủ tục này.

3.3 Phát hành tài liệu

Các tài liệu đã tổng hợp được xuất bản và lưu trữ trong các thư mục thích hợp theo quy định của Biên bản rà soát tài liệu [7] hoặc do cấp quản lý trực tiếp.

Sau khi phát hành tài liệu, bạn phải:

– Cập nhật lịch sử tài liệu [1]

– Cập nhật mục lục tài liệu

– Mở / cập nhật Sổ đăng ký luân chuyển tài liệu [4]

– Tạo Thông báo chuyển tài liệu [5] cho mỗi bản sao được kiểm soát

– Ghi số bản sao trên tài liệu

Bản sao của Thông báo chuyển tài liệu [5] được giữ lại cho đến khi trả lại bản gốc đã ký.

Các hồ sơ trên được lưu giữ trong Kho lưu trữ tài liệu chính theo quy định tại mục 3.6 của quy trình này.

Tài liệu thay thế được lưu trữ trong Tệp Tài liệu Lưu trữ theo mục 3.7 của quy trình này.

Các bản sao chưa được kiểm soát phải được đánh dấu rõ ràng là ‘KHÔNG ĐƯỢC ĐĂNG KÝ’.

Những thay đổi trong Sổ đăng ký lưu hành tài liệu [4] trước hết phải được sự đồng ý của cấp quản lý. Sau đó, các bản sao kiểm soát được phát hành theo các khoản 3, 4 và 5 ở trên.

3.4 Huỷ tài liệu

Các tài liệu chỉ có thể được hủy bỏ khi nhận được đơn đăng ký thay đổi tương ứng, có xác nhận của chữ ký phê duyệt. Thủ tục hủy bỏ như sau:

– Cập nhật Chỉ mục Chính bằng cách đặt tài liệu ở trạng thái ‘RÚT TIỀN’

– Cập nhật lịch sử tài liệu [1]

– Lập hồ sơ về việc chuyển giao [5] theo Tạp chí Phát hành tài liệu [4] hướng dẫn tất cả người giữ bản sao tài liệu cách hủy chúng.

– Lưu trữ tài liệu theo quy định tại mục 3.7 của quy trình này.

3.5 Thay đổi đối với tài liệu

Quá trình sửa đổi các tài liệu diễn ra theo quy định của [2]. Tài liệu chuyển sang giai đoạn phát triển tiếp theo và được tái bản theo mục 3.3. thủ tục này.

Thực hiện các thay đổi quan trọng hoặc viết lại tài liệu được thực hiện như sau:

– Chuyển đổi tài liệu sang bản nháp (ví dụ: Bản nháp 3A)

– Thực hiện theo các hướng dẫn trong phần 3.1, 3.2 và 3.3 của quy trình này.

3.6 Kho lưu trữ tài liệu chính

Cần phải liên tục duy trì Kho lưu trữ tài liệu chính đi vào nề nếp hoạt động.

Đối với mỗi tài liệu được lưu trữ:

– Bản gốc / bản chính của tài liệu

– Lịch sử tài liệu [1].

Đối với các tài liệu được xuất bản chính thức, các tài liệu sau cũng được lưu trữ:

– Phê duyệt tài liệu [3] hoặc yêu cầu thay đổi [8]

– Sổ đăng ký lưu hành tài liệu [4]

– Thông báo chuyển phát tài liệu [5].

Sổ đăng ký các tài liệu cơ bản cũng được lưu giữ, bao gồm:

– Số nhận dạng tài liệu

– Tiêu đề tài liệu

– Tình trạng tài liệu.

3.7 Thư mục tài liệu lưu trữ

Các tài liệu bị thay thế và bị hủy bỏ được lưu trữ trong một thư mục riêng với tên thích hợp.

Mỗi tài liệu phải được đánh dấu rõ ràng bằng ‘SUPERSEDED’ hoặc ‘WITHDRAWN’.

Báo cáo đánh giá tài liệu cũng được lưu cho các tài liệu dự thảo.

Đối với mỗi tài liệu được phát hành chính thức, những thông tin sau được lưu:

– Phê duyệt tài liệu [3] hoặc yêu cầu thay đổi [8]

– Sổ đăng ký lưu hành tài liệu [4]

– Hồ sơ luân chuyển tài liệu (Thông báo chuyển tài liệu) [5].

Danh mục / sổ đăng ký tài liệu lưu trữ được duy trì sử dụng [6].

4. Đính kèm

[1] Mẫu 4, PHỤ LỤC R – Lịch sử tài liệu

[2] PHỤ LỤC F – Quy trình Kiểm soát Thay đổi

[3] Biểu mẫu 1, PHỤ LỤC R – Phê duyệt tài liệu

[4] Mẫu 2, PHỤ LỤC R – Sổ đăng ký luân chuyển tài liệu

[5] Biểu mẫu 3 PHỤ LỤC R – Thông báo chuyển tài liệu

[6] Biểu mẫu 5, PHỤ LỤC R – Mục lục tài liệu lưu trữ

[7] PHỤ LỤC B – Quy trình Đánh giá Tài liệu và Phần mềm

[8] Biểu mẫu 6, PHỤ LỤC R – Yêu cầu thay đổi

PHỤ LỤC F:

Thay đổi quy trình kiểm soát

Chịu trách nhiệm: Khách hàng và Nhà cung cấp

1. Giới thiệu

Quy trình này mô tả một hệ thống kiểm soát để thực hiện các thay đổi đối với một hệ thống tự động.

Kiểm soát thay đổi là điều cần thiết để tuân thủ các phương pháp vận hành và sản phẩm đã được phê duyệt.

2. Ứng dụng

Quy trình này áp dụng cho các thay đổi đối với tài liệu, phần mềm ứng dụng, phần mềm hệ điều hành, chương trình cơ sở, phần cứng và cấu hình hệ thống, như được tham chiếu trong Kế hoạch chất lượng của nhà cung cấp.

Thay thế các hạng mục bằng các hạng mục tương đương, ví dụ, do lỗi phần cứng, là một hoạt động của hệ thống và do đó không chịu sự kiểm soát thay đổi được mô tả trong phần này.

3. Thủ tục

3.1. Các quy định chung

Tất cả các thay đổi phải được ủy quyền, lập thành văn bản, kiểm tra và phê duyệt trước khi thực hiện.

Tuy nhiên, vẫn có những trường hợp ngoại lệ:

– Sửa chữa khẩn cấp

– Những thay đổi được thực hiện trong quá trình thử nghiệm đã thỏa thuận

Tất cả các thay đổi phát sinh từ các trường hợp trên sau này phải được phân tích, kiểm tra, lập thành văn bản và phê duyệt theo quy trình này.

3.2. Thay đổi yêu cầu

Khi có nhu cầu thay đổi, phần YÊU CẦU THAY ĐỔI được điền vào biểu mẫu Yêu cầu Thay đổi [1]. Mỗi yêu cầu thay đổi được gán một số duy nhất được đăng ký bằng [2].

3.3. Ủy quyền thay đổi

Đối với mỗi hệ thống, người quản lý dự án được chỉ định, người chịu trách nhiệm đảm bảo rằng tất cả các thay đổi đối với hệ thống được thực hiện đúng cách. Người quản lý dự án cũng có thể ủy quyền này.

Mỗi yêu cầu thay đổi đều được ban lãnh đạo xem xét với một thứ tự thích hợp: chấp nhận / từ chối. Thông thường quyết định này không được thực hiện một mình – cần ít nhất hai người. Những yếu tố đã được công ty dược phẩm-khách hàng chấp thuận trước đó (ví dụ: tài liệu hợp đồng, phần mềm đã được kiểm tra và chấp nhận) chỉ có thể được thay đổi sau khi đã thỏa thuận với khách hàng.

3.3.1. Các thay đổi bị từ chối

Những người đã quyết định từ chối Đơn xin Thay đổi, hãy điền và ký tên vào phần Xử lý và Ủy quyền Thay đổi của Đơn, nêu lý do từ chối trong phần Chi tiết Thay đổi.

Đơn xin thực hiện thay đổi phải được đăng ký, Danh mục [2] phải được cập nhật và người nộp đơn phải được thông báo về quyết định được thực hiện.

3.3.2. Các thay đổi được chấp nhận

Những người đã ra quyết định chấp nhận Đơn xin sửa đổi, hãy điền và ký tên vào phần “Cho phép thực hiện các sửa đổi” của Đơn. Họ cũng xác định:

– Những yếu tố được kiểm soát nào được tiếp xúc với Ứng dụng

– Những thử nghiệm nào là cần thiết để đảm bảo rằng hiệu suất không thay đổi.

Các quyết định này được ghi lại trong phần Chi tiết Thay đổi của Ứng dụng.

Nếu nhiều mặt hàng được kiểm soát có thể thay đổi theo Ứng dụng này, thì một Ghi chú thay đổi [3] sẽ được lập cho từng mặt hàng, chỉ định những thay đổi nào sẽ được thực hiện đối với từng mặt hàng.

Đối với công việc phức tạp, Kế hoạch thay đổi có thể được yêu cầu, được đính kèm với Yêu cầu thay đổi, đến lượt nó phải được tham chiếu một cách thích hợp.

3.4. Hoàn thành quá trình thay đổi và phê duyệt nó

Khi tất cả các thay đổi đã được thực hiện và quá trình thử nghiệm hoàn tất, Yêu cầu Thay đổi sẽ được gửi đến ban quản lý để xem xét và phê duyệt lần cuối.

Yêu cầu thay đổi đã hoàn thành được lưu trữ và Danh mục [2] được cập nhật.

4. Đính kèm

[1] PHỤ LỤC R, Mẫu 6 – Yêu cầu Thay đổi

[2] PHỤ LỤC R, Biểu mẫu 12 – Chỉ mục yêu cầu thay đổi

[3] PHỤ LỤC R, Mẫu 13 – Ghi chú Thay đổi

PHỤ LỤC G:

Quy trình lập Kế hoạch Chất lượng và Kế hoạch Dự án

Chịu trách nhiệm: Nhà cung cấp

1. Giới thiệu

Phụ lục này mô tả quy trình lập Kế hoạch Chất lượng cho các dự án riêng lẻ.

Kế hoạch chất lượng / dự án xác định cách thức nhà cung cấp sẽ đáp ứng các yêu cầu chất lượng của khách hàng, những công việc sẽ được thực hiện, thời gian, người thực hiện và cơ chế kiểm soát của họ.

2. Ứng dụng

Quy trình này được sử dụng để xây dựng Kế hoạch Chất lượng / Kế hoạch Dự án cho tất cả các dự án lập trình của nhà cung cấp.

3. Thủ tục

3.1. Nội dung tài liệu

Sau đây là mô tả về những phần và tiểu mục nào được bao gồm trong Kế hoạch Chất lượng / Kế hoạch Dự án. Tất cả các tiêu đề của các phần và tiểu mục phải có mặt. Nếu một phần không được giải quyết, dấu kiểm là ‘Không áp dụng cho hợp đồng này’.

Kế hoạch Chất lượng / Kế hoạch Dự án là một tài liệu hợp đồng và do đó phải được phê duyệt bởi người quản lý đảm bảo chất lượng sản phẩm của nhà cung cấp (hoặc người đại diện), người quản lý dự án của nhà cung cấp và khách hàng.

3.2. Phần “Giới thiệu”

Chứa các thông tin sau:

– Văn bản do ai soạn thảo, quyền hạn gì, nhằm mục đích gì.

– Tình trạng hợp đồng của tài liệu.

– Giao tiếp với GAMP, nếu có.

– Liên kết đến Kế hoạch xác nhận, nếu có.

3.3. Phần “Thông tin chung”

Phần này mô tả ngắn gọn dự án.

3.4. Phần “Kế hoạch chất lượng”

Phần Kế hoạch Chất lượng xác định các hoạt động xác nhận, những người chịu trách nhiệm và thủ tục để thực hiện các hành động.

3.4.1. Tiểu mục “Yêu cầu chất lượng của khách hàng”

Các yêu cầu chất lượng của khách hàng được ưu tiên so với Hệ thống quản lý chất lượng của nhà cung cấp.

Tất cả các yêu cầu về chất lượng của khách hàng được liệt kê trong tiểu mục này nếu chúng khác với GAMP. Các yêu cầu này phải được tham chiếu chéo đến các phần liên quan của Hướng dẫn Nhà cung cấp GAMP trong ngành dược phẩm.

3.4.2. Tiểu mục “Hệ thống chất lượng của nhà cung cấp”

Tiểu mục này liệt kê tất cả sự khác biệt giữa hệ thống chất lượng của nhà cung cấp hiện tại và Hướng dẫn dành cho nhà cung cấp GAMP trong ngành dược phẩm.

3.5. Phần “Kế hoạch dự án”

Một kế hoạch dự án được tạo cho mỗi dự án của nhà cung cấp.

3.6 Bộ phận tổ chức dự án

Phần này chứa một sơ đồ tổ chức cho thấy:

– Nhóm dự án của nhà cung cấp: Nhân sự và các chức vụ. Người liên hệ của nhà cung cấp mà khách hàng có thể gửi khiếu nại cũng được chỉ ra.

– Tương tác của nhóm dự án của nhà cung cấp với các hoạt động đảm bảo chất lượng sản phẩm trong tổ chức.

– Những người liên hệ đã khai báo của khách hàng.

3.7 Các đơn vị được cung cấp theo mục

Điều khoản này xác định những gì sẽ được chuyển giao, làm thế nào các đơn vị sẽ được chuyển giao sẽ được xác định và chúng sẽ được phân phối dưới hình thức nào (ví dụ: định dạng).

3.8 Phần “Hoạt động”

Phần này xác định:

– Công việc của dự án, bao gồm đánh giá tổng kết và đánh giá phê bình chương trình.

– Nhân sự được giao cho các công việc này.

– Ngày bắt đầu và kết thúc dự kiến ​​cho từng loại công việc.

Các hoạt động của dự án nên được mô tả dưới dạng biểu đồ / sơ đồ (ví dụ: Biểu đồ Gantt). Vì phần này phải được sửa đổi và cập nhật thường xuyên nên nó có thể được đưa vào Kế hoạch chất lượng chính dưới dạng phụ lục.

4. Đính kèm

Không có Đính kèm.

PHỤ LỤC H:

Quy trình soạn thảo đặc điểm kỹ thuật chức năng

Chịu trách nhiệm: Nhà cung cấp

1. Giới thiệu

Phương pháp luận này mô tả tiêu chuẩn để soạn thảo Đặc tả chức năng.

Đặc tả chức năng mô tả một hệ thống đáp ứng nhu cầu của khách hàng như được định nghĩa trong Đặc tả yêu cầu của người dùng. Nó xác định những gì hệ thống phải làm và những chức năng và sự thích ứng nào nên được trình bày. Đặc tả chức năng bao gồm danh sách các mục tiêu thiết kế / thông số thiết kế của hệ thống.

2. Ứng dụng

Quy trình này được sử dụng để tạo ra Đặc điểm kỹ thuật chức năng, được tham chiếu trong Kế hoạch chất lượng của Nhà cung cấp.

3. Thủ tục

3.1. Hướng dẫn chung

Đặc tả chức năng xác định những gì hệ thống phải làm và những chức năng và đồ đạc nào cần được trình bày. Nó bao gồm một danh sách các mục tiêu thiết kế / các thông số thiết kế cho hệ thống. Đặc điểm kỹ thuật chức năng được kiểm soát phù hợp với [1].

Đặc tả chức năng xác định các thành phần phần mềm trừu tượng đáp ứng các yêu cầu đặt ra trong Đặc tả yêu cầu của người dùng [2].

Khi vẽ một thông số kỹ thuật, bạn phải tuân theo các nguyên tắc sau:

– Tất cả các hạn chế phải được quy định chi tiết.

– Không nên có sự mơ hồ, không rõ ràng.

– Nên sử dụng hệ thống đặt tên phù hợp, nhất quán.

3.2. Nội dung tài liệu

Phần này xác định những phần nào được bao gồm trong đặc điểm kỹ thuật. Tất cả các phần phải có mặt. Nếu các yêu cầu cho phần này không được chỉ định, hộp kiểm được đánh dấu là ‘Không áp dụng’.

3.2.1 Phần “Giới thiệu”

Phần này chứa các thông tin sau:

– Tài liệu do ai soạn thảo, trên cơ sở nào và nhằm mục đích gì

– Tình trạng hợp đồng của tài liệu

– Giao tiếp với các tài liệu khác.

3.2.2 Phần “Thông tin chung”

Phần này hình thành các chức năng và giao diện cơ bản của hệ thống với thế giới bên ngoài. Nó bao gồm những điều sau:

– Mục tiêu và lợi ích chính của hoạt động

– Mô tả cấp cao, bao gồm phân chia thành các hệ thống con chính.

– Các giao diện chính của hệ thống với thế giới bên ngoài

– Các giả thiết. Mọi giả định về thiết kế hoặc triển khai đều được quy định (ví dụ: mô-đun tiêu chuẩn, hệ điều hành, phần cứng)

– Bất kỳ sự mâu thuẫn nào với Đặc điểm kỹ thuật yêu cầu của người dùng. Bất kỳ sự khác biệt nào giữa Đặc điểm kỹ thuật chức năng và Đặc điểm kỹ thuật yêu cầu của người dùng đều được ghi lại.

3.2.3 Phần “Chức năng”

Phần này chứa mô tả cấp cao, được chia thành các cấp chức năng riêng lẻ. Mô tả các chức năng và đồ đạc sẽ được cung cấp, bao gồm các chế độ hoạt động đặc biệt.

Các khía cạnh sau đây được xem xét:

– Yêu cầu đối với một chức năng hoặc thiết bị, chi tiết về việc sử dụng nó, bao gồm cả các tương tác với các bộ phận khác của hệ thống. Các tính toán và thuật toán quan trọng được đánh dấu

– Chất lượng hiệu suất – khả năng đáp ứng, tính đúng đắn và hiệu suất. Dữ liệu phải được trình bày một cách định lượng và rõ ràng

– Độ tin cậy và độ an toàn. Các chủ đề này có thể bao gồm: hành động trong trường hợp phần mềm hoặc phần cứng bị lỗi, tự giám sát, xác thực, dự phòng, hạn chế truy cập, hết thời gian chờ và khôi phục dữ liệu.

– Các chức năng có thể cấu hình và các giới hạn trong đó cấu hình có thể diễn ra.

3.2.4 Phần “Dữ liệu”

Phần này xác định dữ liệu nào hệ thống sẽ hoạt động. Các khía cạnh sau đây cần được xem xét:

– Định nghĩa dữ liệu. Dữ liệu được định nghĩa theo thứ bậc: các đối tượng phức tạp được xây dựng từ những đối tượng đơn giản (ví dụ: tệp bản ghi; kiểu phức tạp được mô tả dưới dạng kiểu đơn giản). Các thông số tới hạn được đặc biệt quy định

– Quyền truy cập (ví dụ: hệ thống con nào cần truy cập để đọc hoặc ghi từng đơn vị dữ liệu, phương pháp truy cập, tốc độ và thời gian cập nhật, khóa đọc / ghi)

– Dung lượng dữ liệu, thời gian lưu trữ và chi tiết lưu trữ dữ liệu.

3.2.5 Phần “Giao diện”

Phần này mô tả tất cả các giao diện của hệ thống và chứa các phần phụ sau:

– Giao diện người dùng – được mô tả cho từng vai trò (ví dụ: người điều hành, quản trị viên kho, người quản lý hệ thống, v.v.). Các chủ đề cần xem xét bao gồm: thiết bị sẵn có, các loại thiết bị ngoại vi, định dạng chung để hiển thị dữ liệu và báo cáo.

– Giao diện với các hệ thống khác. Các chủ đề cần xem xét bao gồm: dữ liệu truyền và nhận, tốc độ truyền, giao thức dữ liệu, bảo mật giao diện

– Giao diện với thiết bị (ví dụ: cảm biến / cơ cấu chấp hành). Các chủ đề cần xem xét bao gồm: dữ liệu được truyền / nhận, định dạng, xác thực và kiểm tra lỗi.

3.2.6 Phần “Đặc tính phi chức năng”

Phần này xác định cách hệ thống sẽ đáp ứng các yêu cầu phi chức năng. Chứa các phần phụ sau:

– Khả năng sử dụng / khả năng hoạt động (ví dụ: độ tin cậy, dự phòng, kiểm tra lỗi, hoạt động nhàn rỗi / chờ)

– Độ tin cậy / khả năng bảo trì hoạt động (ví dụ, mở rộng và cải thiện các khả năng, khả năng dự trữ, những thay đổi có thể xảy ra trong điều kiện hoạt động, tuổi thọ của dịch vụ).

3.2.7 Phần “Bảng chú giải thuật ngữ”

Phần này cung cấp giải thích về những thuật ngữ có thể không quen thuộc với những người đọc Đặc tả chức năng này.

3.2.8 Ứng dụng

Nếu được yêu cầu (ví dụ: các hệ thống nhỏ), các ứng dụng có chứa thông số kỹ thuật phần cứng và phần mềm có thể được cung cấp.

4. Đính kèm

[1] PHỤ LỤC E – Soạn thảo, Kiểm soát và Phát hành Tài liệu

[2] PHỤ LỤC A – Soạn thảo Đặc tả Yêu cầu Người dùng

PHỤ LỤC I:

Quy trình soạn thảo Đặc tả thiết kế phần cứng

Chịu trách nhiệm: Nhà cung cấp

1. Giới thiệu

Nó cung cấp thứ tự mà Đặc điểm kỹ thuật thiết kế phần cứng được lập, xuất phát từ Đặc điểm kỹ thuật chức năng. Đặc tả thiết kế phần cứng mô tả phần cứng sẽ tạo nên một hệ thống và cách nó tương tác với các hệ thống phần cứng khác.

2. Ứng dụng

Quy trình này được sử dụng trong việc soạn thảo Đặc điểm kỹ thuật thiết kế phần cứng, được tham chiếu trong Kế hoạch chất lượng của nhà cung cấp.

3. Thủ tục

3.1. Hướng dẫn chung

Bạn nên cung cấp Sơ đồ thiết kế phần cứng kèm theo sơ đồ. Nếu các sơ đồ như vậy được cung cấp ở nơi khác, chúng phải được tham chiếu chéo trong Đặc điểm kỹ thuật.

3.2. Nội dung tài liệu

Điều này xác định phần nào nên được bao gồm trong đặc điểm kỹ thuật. Tất cả các tiêu đề phần phải có mặt. Nếu phần không áp dụng cho thiết kế, nó được đánh dấu là ‘Không áp dụng’.

3.2.1. Phần “Giới thiệu”

Phần này chứa các thông tin sau:

– Tài liệu do ai vẽ ra, trên cơ sở nào và nhằm mục đích gì.

– Giao tiếp với các tài liệu khác.

3.2.2. Phần “Thông tin chung”

Phần mô tả ngắn gọn dự án được trình bày chi tiết trong tài liệu. Nó thay vì phục vụ như một phần giới thiệu về dự án và không chứa thông tin chi tiết. Phần này mô tả cấu hình của hệ thống phần cứng và sự tương tác của nó với môi trường. Tất cả điều này nên được minh họa bằng sơ đồ.

3.2.3. Phần “Hệ thống máy tính”

Phần này mô tả cấu hình phần cứng hệ thống hoàn chỉnh. Nó nên được minh họa bằng một sơ đồ khối có giải thích. Các phần phụ sau đây nên được bao gồm:

– Tiểu mục “Hệ thống máy tính chính”

Mô tả các khối xây dựng của (các) hệ thống máy tính chính như CPU, bộ nhớ, loại bus, độ chính xác của đồng hồ, v.v.

– Tiểu mục “Lưu trữ thông tin”

Mô tả tất cả các thiết bị lưu trữ dự định với khả năng tối đa của chúng, ví dụ: đĩa cứng, đĩa mềm, băng từ.

– Tiểu mục “Thiết bị ngoại vi”

Mô tả các thiết bị ngoại vi được cung cấp. Bất kỳ vỏ bọc đặc biệt nào và / hoặc các tính năng lắp ráp phải được chỉ định.

– Tiểu mục “Các kết nối”

Mô tả tất cả các kết nối giữa các thành phần bên trong máy tính và tất cả các kết nối với thiết bị khác. Đảm bảo bao gồm:

Thông số kỹ thuật cáp

Thông số kỹ thuật của Connector / Connector / Connector

Yêu cầu che chắn

Quy chế chương trình

Kết nối mạng / bên ngoài

3.2.4. Phần “Đầu vào / Đầu ra”

Các công cụ ra vào được thương lượng, nếu cần. Chúng có thể bao gồm:

Đầu vào dữ liệu kỹ thuật số

Đầu ra dữ liệu kỹ thuật số

Đầu vào analog

Đầu ra analog

Bộ đếm xung.

Các yếu tố sau được mô tả cho từng nhạc cụ hoặc nhóm nhạc cụ:

– Sự chính xác

– Quyền tự trị

– Cường độ dòng điện và điện áp

– Loại và số lượng bảng giao diện

– Căn chỉnh thời gian.

3.2.5. Phần “Điều kiện hoạt động”

Mô tả môi trường làm việc, bao gồm:

– Nhiệt độ

– Độ ẩm

– Các can thiệp bên ngoài

– Bảo vệ thân thể

– Nhiễu tần số vô tuyến, điện từ và tia cực tím

3.2.6. Phần “Nguồn điện”

Các yêu cầu về nguồn điện cho hệ thống phần cứng có thể định cấu hình được thảo luận ở đây .

Các yếu tố sau được tính đến:

– Lọc

– Trọng tải

– Nối đất

– Hệ thống cung cấp điện liên tục (UPS)

3.2.7. Phần “Bảng chú giải thuật ngữ”

Phần này có giải thích các thuật ngữ có thể không quen thuộc với những người đọc Đặc điểm kỹ thuật.

3.3. Những hệ thống nhúng

Trong các phần mà Đặc điểm kỹ thuật thiết kế phần cứng liên quan đến hệ thống nhúng, thông tin sau nên được bao gồm:

– Sơ đồ bố trí chi tiết bảng điều khiển và các thiết bị bên trong / bên ngoài.

– Sơ đồ bố trí các cảm biến và các thiết bị khác được lắp đặt trên máy.

– Danh sách tất cả các thành phần tạo nên hệ thống điều khiển.

– Sơ đồ mạch điện.

– Tham chiếu đến bất kỳ tiêu chuẩn nào của khách hàng bên ngoài cần tuân thủ, ví dụ Tiêu chuẩn quốc tế IEC204 về thiết bị điện trên máy công nghiệp.

4. Đính kèm

Không có Đính kèm.

PHỤ LỤC J:

Quy trình thiết lập Đặc tả phát triển phần mềm –

Chịu trách nhiệm: Nhà cung cấp

1. Giới thiệu

Thủ tục này mô tả các tiêu chuẩn cho việc soạn thảo Đặc điểm kỹ thuật phát triển phần mềm, xuất phát từ Đặc điểm kỹ thuật chức năng. Nó mô tả các hệ thống con phần mềm tạo nên hệ thống phần mềm và các mối quan hệ giữa các hệ thống con này.

2. Ứng dụng

Quy trình này được áp dụng trong việc soạn thảo Đặc điểm kỹ thuật phát triển phần mềm, được tham chiếu trong Kế hoạch chất lượng của nhà cung cấp .

3. Thủ tục

3.1. Hướng dẫn chung

Bạn có thể sử dụng một phương pháp thiết kế tiêu chuẩn như Yourdon hoặc PRISM. Trong những trường hợp này, có thể thay đổi phụ lục này, đưa ra những giải thích phù hợp.

Tất cả dữ liệu hệ thống có thể được mô tả riêng biệt (ví dụ, trong Từ điển dữ liệu). Thực tế này cần được phản ánh trong Phần 3.2.4.

Cũng có thể tạo nhiều hơn một Đặc tả phát triển phần mềm dựa trên cùng một Đặc tả chức năng. Mỗi một trong số này phải được tham chiếu một cách thích hợp để mỗi cái có thể được liên kết với (các) chức năng tương ứng được mô tả trong Đặc tả chức năng.

Vẽ đồ thị hệ thống, tệp hệ thống và các cấu trúc dữ liệu khác là tùy chọn, nhưng được khuyến nghị. Nếu các biểu đồ như vậy đã được trình bày trong các tài liệu khác, thì điều này nên được tham chiếu trong Đặc tả phát triển phần mềm.

3.2. Nội dung tài liệu

Phần xác định những phần nào nên được bao gồm trong đặc điểm kỹ thuật. Tất cả các phần phải có mặt. Nếu bất kỳ phần nào không áp dụng trong thiết kế, phần đó phải được đánh dấu là ‘Không áp dụng’.

3.2.1. Phần “Giới thiệu”

Phần này chứa các thông tin sau:

– Tài liệu do ai vẽ ra, trên cơ sở nào và nhằm mục đích gì.

– Giao tiếp với các tài liệu khác.

3.2.2. Phần “Thông tin chung”

Phần mô tả ngắn gọn dự án được trình bày chi tiết hơn trong các tài liệu khác. Thay vào đó, nó đóng vai trò như một phần giới thiệu về dự án hơn là chứa bất kỳ thông tin chi tiết nào. Anh ta phải chỉ ra cách hệ thống con nào tạo nên toàn bộ hệ thống, tức là chi tiết hóa các cấp độ của chương trình. Tất cả những điều này có thể được minh họa bằng đồ thị.

3.2.3. Phần mô tả hệ thống

Phần mô tả các hệ thống con (mô-đun) sẽ tạo nên hệ thống, xác định rõ mục đích của từng hệ thống đó. Danh sách tất cả các tương tác giữa các mô-đun và các hệ thống bên ngoài khác cũng được đưa ra. Mọi giao diện phải được hợp lý hóa. Bạn có thể kích hoạt lịch trình hệ thống và mô tả thời gian hoặc lịch trình của các hệ thống con.

3.2.4. Phần “Dữ liệu hệ thống”

Phần xác định dữ liệu hệ thống và xác định các đối tượng dữ liệu cơ bản. Dữ liệu được mô tả theo thứ bậc, các đối tượng phức tạp được chia thành các đối tượng đơn giản hơn. Các đối tượng có thể bao gồm những thứ sau:

– Cơ sở dữ liệu và bộ sưu tập tệp

– Các tập tin

– Mục

– Loại dữ liệu

Mỗi tệp và cấu trúc dữ liệu phải được xác định duy nhất. Ở trên không loại trừ việc sử dụng các mô hình Entity-Link và những thứ tương tự.

3.2.5. Phần “Mô tả các mô-đun”

Mỗi mô-đun được mô tả theo các khía cạnh sau:

– Công việc của mô-đun (có thể ở dạng mã giả).

– Giao diện với các mô-đun khác. Bạn có thể giới hạn bản thân trong một liên kết đến sơ đồ hệ thống, nếu một liên kết đã được trình bày.

– Bất kỳ yếu tố đặc biệt nào của thời gian mô-đun không được đề cập trong mô tả hệ thống.

– Xử lý lỗi và xác thực dữ liệu.

3.2.6. Phần “Dữ liệu mô-đun”

Phần này xác định dữ liệu hệ thống nào (được mô tả trong Phần 3.2.4 ) mà mỗi mô-đun hoạt động với.

3.2.7. Phần “Bảng chú giải thuật ngữ”

Phần này bao gồm các định nghĩa của các thuật ngữ có thể không quen thuộc với người đọc Đặc điểm kỹ thuật.

3.3. Những hệ thống nhúng

Trong trường hợp Đặc điểm kỹ thuật thiết kế phần mềm đề cập đến các hệ thống nhúng, thông tin sau phải được bao gồm trong các phần thích hợp:

– Sơ đồ khối, hoặc bất kỳ hình thức trình bày nào khác, về cách đạt được chức năng của từng máy riêng lẻ (bao gồm các chiến lược tạo cảnh báo / cảnh báo và khôi phục khẩn cấp).

– Mô tả chi tiết các thuật toán được sử dụng.

– Thư mục của tất cả các tin nhắn.

– Mô tả sơ đồ của tất cả các màn hình hiển thị.

4. Đính kèm

Không có Đính kèm.

PHỤ LỤC K:

Quy trình thiết lập Đặc điểm kỹ thuật để thiết kế các mô-đun phần mềm

Chịu trách nhiệm: Nhà cung cấp

1. Giới thiệu

Phụ lục này mô tả quy trình biên soạn Đặc tả thiết kế mô-đun phần mềm, xác định hoạt động của mô-đun phần mềm và bắt nguồn từ Đặc tả thiết kế phần mềm. Đặc điểm kỹ thuật phải mô tả hoạt động của các mô-đun một cách rõ ràng, chính xác và rõ ràng. Đặc tả thiết kế mô-đun phần mềm được các lập trình viên sử dụng làm cơ sở để viết mã chương trình.

2. Ứng dụng

Quy trình này áp dụng cho việc biên soạn tất cả Thông số kỹ thuật thiết kế mô-đun phần mềm của nhà cung cấp. Nếu đặc điểm kỹ thuật được đưa ra mà không có sự thống nhất với thủ tục này, lý do cho quyết định này phải được ghi lại trong Kế hoạch Đảm bảo Chất lượng cho dự án.

3. Thủ tục

3.1. Hướng dẫn chung

– Cũng có thể sử dụng bất kỳ phương pháp lập trình tiêu chuẩn nào, ví dụ, Yourdon hoặc JSD. Trong trường hợp này, có thể xây dựng lại văn bản, nhưng bắt buộc phải quy định điều này trong Kế hoạch đảm bảo chất lượng công trình (KHLCNT).

– Cũng có thể mô tả tất cả dữ liệu hệ thống một cách riêng biệt (ví dụ trong Từ điển dữ liệu), trong trường hợp này thực tế này cần được phản ánh trong Phần 3.2.3.

– Không cần thiết phải vẽ biểu đồ của các phân hệ phần mềm (tổng quan về phân hệ phần mềm) và cấu trúc dữ liệu của các phân hệ. Nhưng nếu chúng đã được vẽ ra, chúng phải được tham chiếu chéo với Đặc tả để thiết kế các mô-đun phần mềm.

3.2. Nội dung tài liệu

Phần này xác định những phần nào nên được bao gồm trong Đặc điểm kỹ thuật phát triển phần mềm. Tất cả các phần phải có mặt. Nếu một phần không áp dụng trong thiết kế, phần đó phải được đánh dấu là ‘Không áp dụng được’.

3.2.1. Phần “Giới thiệu”

Phần này chứa các thông tin sau:

– Tài liệu do ai soạn thảo, trên cơ sở nào và nhằm mục đích gì

– Giao tiếp với các tài liệu khác.

3.2.2. Phần “Tổng quan về mô-đun phần mềm

Phần mô tả ngắn gọn dự án phần mềm được trình bày chi tiết trong phần còn lại của tài liệu. Nó đóng vai trò như một lời giới thiệu hơn là cung cấp thông tin chi tiết. Nó cho thấy cách một mô-đun mã được chia thành các chương trình con. Thông tin có thể được minh họa bằng đồ thị.

3.2.3. Phần “Dữ liệu phần mềm của mô-đun”

Phần này mô tả dữ liệu mô-đun và xác định các đối tượng dữ liệu chính. Dữ liệu được mô tả theo thứ bậc, các đối tượng phức tạp được chia nhỏ thành những đối tượng đơn giản hơn. Các đối tượng có thể bao gồm:

– Cơ sở dữ liệu và bộ sưu tập tập tin.

– Các tập tin.

– Hồ sơ.

– Loại dữ liệu.

Tất cả các cấu trúc tệp và dữ liệu phải được xác định duy nhất. Các hướng dẫn trên không loại trừ việc sử dụng mối quan hệ thực thể hoặc các mô hình khác.

3.2.4. Phần “Mô tả các chương trình con”

Đối với mỗi chương trình con trong mô-đun, phần sau được mở rộng:

– Hành động của chương trình con (có thể ở dạng mã giả).

– Tùy chọn. Mỗi tham số phải được xác định là:

a) tham số đầu vào

b) tham số đầu ra

c) tham số đầu vào và đầu ra

– Và ngoài ra, tham số phải được xác định là:

a) được truyền qua giá trị.

b) được truyền bằng liên kết.

– Mọi tác dụng phụ của chương trình con.

– Ngôn ngữ (bao gồm cả phiên bản).

– Liên kết đến bất kỳ tiêu chuẩn lập trình nào.

3.2.5. Phần “Dữ liệu chương trình con”

Phần này mô tả mọi dữ liệu được khai báo cục bộ.

3.2.6. Phần thuật ngữ

Phần này bao gồm giải thích đầy đủ về tất cả các từ viết tắt và thuật ngữ được sử dụng.

3.3. Những hệ thống nhúng

Trong trường hợp Đặc điểm kỹ thuật thiết kế cho các mô-đun phần mềm đề cập đến các hệ thống nhúng, thông tin sau phải được bao gồm trong các phần thích hợp:

– Sơ đồ khối, hoặc bất kỳ hình thức trình bày nào khác, về cách đạt được chức năng của từng máy riêng lẻ (bao gồm các chiến lược tạo cảnh báo / cảnh báo và khôi phục khẩn cấp).

– Mô tả chi tiết các thuật toán được sử dụng.

– Thư mục của tất cả các tin nhắn.

– Mô tả sơ đồ của tất cả các màn hình hiển thị.

4. Đính kèm

Không có Đính kèm.

PHỤ LỤC L:

Quy trình thiết lập các Thông số kỹ thuật để kiểm tra mô-đun phần mềm

Chịu trách nhiệm: Nhà cung cấp

1. Giới thiệu

Phụ lục này xác định nội dung của tất cả các Thông số kỹ thuật kiểm tra đơn vị phần mềm của nhà cung cấp.

Đặc điểm kỹ thuật kiểm tra mô-đun phần mềm xác định các kiểm tra nào sẽ được thực hiện để xác minh hoạt động chính xác của mô-đun (tức là phù hợp với Đặc điểm thiết kế mô-đun phần mềm).

2. Ứng dụng

Quy trình này chỉ áp dụng cho các Thông số kỹ thuật dành cho Mô-đun phần mềm kiểm tra do tổ chức của Nhà cung cấp soạn thảo nội bộ. Nếu Đặc điểm kỹ thuật kiểm tra đơn vị cho một dự án nhất định không tuân theo quy trình này, lý do phải được giải thích trong Kế hoạch đảm bảo chất lượng cho dự án đó.

3. Thủ tục

3.1. Hướng dẫn chung

Khi xây dựng Thông số kỹ thuật, cần phải nhớ rằng mỗi bài kiểm tra phải rõ ràng, phải rõ ràng thành phần nào đã vượt qua bài kiểm tra và bộ phận nào chưa.

3.2. Nội dung tài liệu

Phần xác định những phần và tiểu mục nào được bao gồm trong đặc điểm kỹ thuật. Tất cả các tiêu đề phải có mặt. Nếu phần / tiểu mục không cần thiết, nó được đánh dấu là ‘Không áp dụng’.

3.2.1. Phần “Giới thiệu”

Phần này chứa các thông tin sau:

– Tài liệu do ai vẽ ra, trên cơ sở nào và nhằm mục đích gì.

– Giao tiếp với các tài liệu khác.

3.2.2. Mục “Lịch trình thanh tra, kiểm tra”Phần này trình bày cách tiếp cận chung để kiểm thử và cấu trúc của đặc điểm kỹ thuật. Cần phải lưu ý những điều sau:

– sử dụng hoặc không sử dụng Phụ lục N [1] làm phương pháp thử nghiệm. Nếu [1] không được sử dụng, thì phương pháp thay thế đã chọn sẽ được mô tả.

– các khu vực đặc biệt không thể thử nghiệm, tại sao.

– bất kỳ nhóm hợp lý hoặc thứ tự các thử nghiệm.

– định dạng liên kết thử nghiệm.

– nhân sự cần thiết cho mỗi thử nghiệm hoặc nhóm thử nghiệm.

3.2.3. Phần “Điều kiện thử nghiệm”

Phần xác định những gì cần thiết để tiến hành thử nghiệm. Các khía cạnh sau được bao gồm:

– Yêu cầu phần cứng.

– Yêu cầu phần mềm, cụ thể là:

a) Cấu hình phần mềm (ví dụ: hệ điều hành, trình điều khiển, tiện ích,

tệp / cơ sở dữ liệu)

b) Phần mềm kiểm thử.

c) dữ liệu thử nghiệm.

– Yêu cầu về tài liệu.

3.2.4. Phần “Quy trình Kiểm tra”

Phần này thảo luận về chi tiết của các bài kiểm tra. Mỗi thử nghiệm được chuẩn bị phù hợp với [1]. Quy trình / phương pháp của mỗi bài kiểm tra phải bắt đầu trên một trang mới và được tham chiếu chéo với Đặc điểm kỹ thuật thiết kế cho các mô-đun phần mềm.

3.2.5. Phần thuật ngữ

Phần này đưa ra giải thích về tất cả các thuật ngữ đặc biệt được sử dụng trong Thông số kỹ thuật. Nó cũng bao gồm các từ thường được sử dụng với ý nghĩa khác thường.

3.3. Kết quả kiểm tra

Kết quả thử nghiệm được lưu trữ theo [1].

4. Đính kèm

[1] PHỤ LỤC N – Thử nghiệm hệ thống tự động

PHỤ LỤC M:

Quy trình biên dịch Đặc tả Kiểm tra Xây dựng Hệ thống Phần mềm

Chịu trách nhiệm: Nhà cung cấp

1. Giới thiệu

Phụ lục này xác định nội dung của Đặc tả Kiểm tra Xây dựng Hệ thống Phần mềm của Nhà cung cấp.

Đặc điểm kỹ thuật kiểm tra bố cục hệ thống phần mềm mô tả các bài kiểm tra sẽ được thực hiện để xác minh sự tương tác chính xác của tất cả các mô-đun hệ thống tạo nên tổng thể (phù hợp với Đặc điểm kỹ thuật phát triển phần mềm).

2. Ứng dụng

Quy trình này chỉ được tuân thủ khi biên soạn Đặc tả để kiểm tra bố cục của hệ thống phần mềm trong tổ chức của Nhà cung cấp. Nếu đặc điểm kỹ thuật này không phù hợp với quy trình này, lý do phải được giải thích trong Kế hoạch Đảm bảo Chất lượng cho dự án.

3. Thủ tục

3.1. Hướng dẫn chung

Khi xây dựng Thông số kỹ thuật, cần phải nhớ rằng mỗi bài kiểm tra phải rõ ràng, phải rõ ràng thành phần nào đã vượt qua bài kiểm tra và bộ phận nào chưa.

3.2. Nội dung tài liệu

Phần xác định những phần và tiểu mục nào được bao gồm trong đặc điểm kỹ thuật. Tất cả các tiêu đề phải có mặt. Nếu phần / tiểu mục không cần thiết, nó được đánh dấu là ‘Không áp dụng’.

3.2.1. Phần “Giới thiệu”

Phần này chứa các thông tin sau:

– Tài liệu do ai vẽ ra, trên cơ sở nào và nhằm mục đích gì.

– Giao tiếp với các tài liệu khác.

3.2.2. Mục “Lịch trình thanh tra, kiểm tra”

Phần này trình bày cách tiếp cận chung để kiểm thử và cấu trúc của đặc điểm kỹ thuật. Cần phải lưu ý những điều sau:

– sử dụng hoặc không sử dụng Phụ lục N [1] làm phương pháp thử nghiệm. Nếu [1] không được sử dụng, thì phương pháp thay thế đã chọn sẽ được mô tả.

– các khu vực đặc biệt không thể thử nghiệm, tại sao.

– bất kỳ nhóm hợp lý hoặc thứ tự các thử nghiệm.

– định dạng liên kết thử nghiệm.

– nhân sự cần thiết cho mỗi thử nghiệm hoặc nhóm thử nghiệm.

3.2.3. Phần “Điều kiện thử nghiệm”

Phần xác định những gì cần thiết để tiến hành thử nghiệm. Các khía cạnh sau được bao gồm:

– Yêu cầu phần cứng

– Yêu cầu đối với phần mềm kiểm tra

– Yêu cầu đối với dữ liệu thử nghiệm

– Tài liệu tham khảo

3.2.4. Phần “Quy trình Kiểm tra”

Phần mô tả chi tiết của các bài kiểm tra. Mỗi thử nghiệm được chuẩn bị phù hợp với [1]. Quy trình / phương pháp cho mỗi bài kiểm tra phải bắt đầu trên một trang mới và được tham chiếu chéo với Đặc điểm kỹ thuật thiết kế mô-đun phần mềm.

3.2.5. Phần thuật ngữ

Phần này giải thích tất cả các thuật ngữ kỹ thuật có trong Đặc điểm kỹ thuật. Nó cũng bao gồm các từ thường được sử dụng với ý nghĩa khác thường.

3.3. Kết quả kiểm tra

Kết quả thử nghiệm được lưu trữ theo [1].

4. Đính kèm

[1] PHỤ LỤC N – Thử nghiệm hệ thống tự động

PHỤ LỤC N:

Quy trình kiểm tra hệ thống tự động

Chịu trách nhiệm: Khách hàng và Nhà cung cấp

1. Giới thiệu

Quy trình này tiết lộ một hệ thống chính thức để kiểm tra hệ thống máy tính hoặc thiết bị khác được điều khiển bởi máy tính / PLC (tức là hệ thống tự động). Dưới đây là các bài kiểm tra đã ghi lại rằng hệ thống đang hoạt động như được chỉ định.

Thông số kỹ thuật kiểm tra có thể có một số loại:

– Đặc điểm kỹ thuật kiểm tra mô-đun phần mềm [6] kiểm tra các thành phần phần mềm riêng lẻ về sự tuân thủ của chúng với đặc điểm kỹ thuật phát triển.

– Đặc tả Kiểm tra Tích hợp Phần mềm [7] kiểm tra các thành phần phần mềm sau khi chúng được kết hợp với nhau.

– Đặc điểm kỹ thuật kiểm tra chấp nhận phần cứng [8] chỉ định kiểm tra việc cài đặt máy tính và bất kỳ thiết bị đầu vào / đầu ra nào khác.

– Đặc điểm kỹ thuật kiểm tra chấp nhận hệ thống [9] xác định một hệ thống kiểm tra chức năng cho toàn bộ hệ thống hoặc thiết bị, bao gồm cả hoạt động của nó.

Đối với mỗi loại thông số kỹ thuật, phương pháp thử sẽ được quy định trong quy trình này.

2. Ứng dụng

Quy trình này áp dụng cho bất kỳ thử nghiệm nào đối với các hệ thống tự động được tham chiếu trong Kế hoạch chất lượng của nhà cung cấp.

3. Thủ tục

Quy trình này bao gồm 4 giai đoạn:

– Xác định mọi thứ cần thiết để bắt đầu thử nghiệm .

– Xác định chiến lược thử nghiệm, bao gồm việc chỉ định những người chịu trách nhiệm thực hiện, chứng nhận và phê duyệt quy trình thử nghiệm.

– Xác định định dạng của các thủ tục kiểm tra, chẳng hạn như sẽ thực sự cho thấy rằng hệ thống đáp ứng các thông số kỹ thuật.

– Xác định phương pháp phải tuân theo trong các thử nghiệm, bao gồm:

Một. Xác định phương pháp đánh giá và phê duyệt kết quả thử nghiệm.

NS. Xác định tiêu chí cho việc kiểm tra lại tiếp theo dựa trên lỗi kiểm tra, quy trình không chính xác hoặc thay đổi hệ thống.

3.1. Bắt buộc phải bắt đầu thử nghiệm

Trước khi thử nghiệm, tất cả các tài liệu liên quan được xác định bởi Kế hoạch chất lượng phải được hoàn thành và đệ trình. Các thông số kỹ thuật thử nghiệm đã thỏa thuận và bất kỳ quy trình nào khác cần thiết cho hoạt động của hệ thống cũng phải được trình bày.

Tất cả các thiết bị đầu vào quan trọng và thiết bị thử nghiệm phải được kiểm tra và lập thành văn bản.

Thiết bị thử nghiệm phải được chứng nhận, phù hợp với tiêu chuẩn quốc gia và được thông báo trước.

3.2. Chiến lược thử nghiệm

Người chịu trách nhiệm lập, kiểm tra, phê duyệt và ký kết đặc tả thử nghiệm được xác định trong Kế hoạch Chất lượng.

Mỗi thử nghiệm được thực hiện bởi một người thử và với sự có mặt của một người quan sát. Người kiểm tra và người quan sát được điều phối bởi người quản lý khách hàng và nhà cung cấp. Các phép thử được người thử và người quan sát cùng ký. Thông thường, tất cả các thử nghiệm khác với thử nghiệm chấp nhận được thực hiện bởi người thử nghiệm và quan sát viên của nhà cung cấp.

3.3. Định dạng thủ tục kiểm tra

Định dạng của các thủ tục kiểm tra, nếu có thể, phải như sau:

Chỉ số (số) duy nhất của bài kiểm tra

Liên kết đến thông số kỹ thuật hướng dẫn (số)

Tên bài kiểm tra

Bắt buộc để bắt đầu kiểm tra

Mô tả thử nghiệm

Tiêu chí để vượt qua bài kiểm tra

Dữ liệu đăng ký

Hành động hơn nữa

Kết quả mong đợi

3.3.1. Chỉ mục (số) của bài kiểm tra

Một (số) định danh duy nhất được chỉ định cho mỗi bài kiểm tra, định dạng của số đó được xác định trong Đặc điểm kỹ thuật của bài kiểm tra.

3.3.2. Liên kết đến đặc điểm kỹ thuật quản lý

Một liên kết đến một tài liệu và một phần cung cấp các yêu cầu kiểm tra, chẳng hạn như Đặc điểm kỹ thuật yêu cầu của người dùng hoặc Đặc điểm kỹ thuật chức năng.

3.3.3. Tên bài kiểm tra

Tên mô tả cho bài kiểm tra.

3.3.4. Bắt buộc để bắt đầu kiểm tra

Mọi thứ bạn cần để bắt đầu thử nghiệm. Điều này bao gồm phần cứng thử nghiệm, tài liệu, tài nguyên, dữ liệu, chương trình dịch vụ, v.v.

3.3.5. Mô tả thử nghiệm

Mô tả từng bước về các hành động của người thử nghiệm.

3.3.6. Tiêu chí để vượt qua bài kiểm tra

Tập hợp các kết quả mong đợi sẽ đạt được khi thử nghiệm thành công được xác định.

3.3.7. Dữ liệu đăng ký

Mô tả dữ liệu thử nghiệm cụ thể sẽ được thu thập và ghi lại (đính kèm) trong Phiếu kết quả thử nghiệm [1]. Nó có thể là dữ liệu đầu vào, đầu ra hoặc mô tả. Đảm bảo bao gồm số sê-ri của tất cả các thiết bị thử nghiệm được sử dụng và chứng chỉ hiệu chuẩn nếu có.

3.3.8. Hành động hơn nữa

Phần này là tùy chọn. Nó nêu chi tiết các bước cần thiết để chuẩn bị quy trình kiểm tra tiếp theo. Ví dụ như các thông số quá trình thiết lập lại hệ thống hoặc quá trình khởi động lại hệ thống.

3.4 Thực hiện quy trình kiểm tra

Các thử nghiệm được thực hiện như sau:

1. Mỗi bài kiểm tra phải được thực hiện và dữ liệu được thu thập (đính kèm) trong Phiếu kết quả kiểm tra [1], một hoặc nhiều trang cho mỗi bài kiểm tra.

2. Người thử nghiệm và người quan sát quyết định xem các tiêu chí chấp nhận thử nghiệm đã được đáp ứng hay chưa, tức là. bài kiểm tra đã vượt qua thành công. Bảng kết quả kiểm tra [1] xác định rõ ràng bài kiểm tra PASS hay FAIL. Họ chỉ ký vào Phiếu kết quả kiểm tra nếu bài kiểm tra đạt (xem đoạn 5 bên dưới nếu bài kiểm tra không thành công).

3. Dữ liệu thô liên quan được mô tả trong đặc điểm kỹ thuật thử nghiệm được người thử nghiệm ký tên trên mỗi trang và được gắn thẻ tham chiếu thử nghiệm (số thử nghiệm). Tất cả dữ liệu thô được đính kèm với Phiếu kết quả kiểm tra [1], đến lượt nó được lưu vào Tệp kết quả kiểm tra theo Mục 3.5 của quy trình này.

4. Người kiểm tra cập nhật Bảng Tiến trình Kiểm tra [3], được duy trì theo Phần 3.5 của quy trình này. Trong tuyên bố này, một điểm được đặt vào đoạn văn hay điểm không đạt của bài kiểm tra. Nó cũng ghi lại số lần mỗi bài kiểm tra đã được chạy.

5. Nếu thử nghiệm không đạt, các bước 1-4 được thực hiện, nhưng người thử và người quan sát không ký vào [1]. Dữ liệu kiểm tra không đạt được lưu trữ trong phần Kiểm tra không đạt của thư mục kết quả kiểm tra theo Phần 3.5 của quy trình này để xem xét sau này.

6. Các Tờ Sự cố Kiểm tra [2] được lưu giữ như một phần của hồ sơ kiểm tra hệ thống.

Hỏng hóc được định nghĩa là một sự kiện bất ngờ lớn, chẳng hạn như sự cố hệ thống hoàn toàn hoặc sự cố làm dừng chương trình thử nghiệm. Sự kiện như vậy được ghi lại trong Nhật ký lỗi kiểm tra [2] và theo Mục 3.5 của quy trình này, được lưu trữ cùng với tất cả dữ liệu thô để giải quyết thêm vấn đề.

7. Sau khi tất cả các bài kiểm tra hoặc nhóm bài kiểm tra đã được hoàn thành (ví dụ: vào cuối ngày), kết quả đạt được sẽ được xem xét và người đánh giá sẽ đánh giá tất cả các điểm không đạt trong phần thích hợp trong thư mục kết quả kiểm tra.

Có ba tùy chọn cho các hành động tiếp theo:

– Kiểm tra lại

– Thay đổi điều gì đó thông qua quy trình kiểm soát thay đổi và lặp lại thử nghiệm

– Từ chối một, một số hoặc tất cả các bài kiểm tra.

Nhóm đánh giá quyết định hành động nào cần thực hiện và nếu cần thay đổi, xác định mức độ yêu cầu kiểm tra lại sau khi thực hiện các thay đổi. Tiến độ của cuộc thanh tra được ghi lại trong biên bản thanh tra [4].

Các vấn đề được phát hiện trong quá trình thử nghiệm và yêu cầu thay đổi trong hệ thống được xử lý theo quy trình Kiểm soát thay đổi [5].

3.5. Thư mục Kết quả Kiểm tra

Tất cả các kết quả kiểm tra được lưu trữ trong một thư mục “Kết quả kiểm tra” có nhãn rõ ràng. Thư mục này chứa các phần sau:

Phần Tiến độ Kiểm tra

Phần kiểm tra đã vượt qua

Phần kiểm tra không thành công

Phần Sự cố Kiểm tra (được đánh số)

Phần Báo cáo Đánh giá (được đánh số)

Đối với mỗi bài kiểm tra, nó lưu trữ:

– Một bản sao làm việc của quy trình thử nghiệm được đánh dấu rõ ràng như vậy

– Tuyên bố kết quả kiểm tra

– Dữ liệu thô liên kết.

4. Đính kèm

[1] Mẫu 7 – Bảng kết quả kiểm tra

[2] Mẫu 8 – Phiếu kiểm tra sự cố

[3] Dạng 1 1 – Bảng tiến trình kiểm tra

[4] Biểu mẫu 9 – Báo cáo đánh giá

[5] PHỤ LỤC F – Kiểm soát thay đổi

[6] PHỤ LỤC L – Đặc điểm kỹ thuật kiểm tra mô-đun phần mềm

[7] PHỤ LỤC M – Đặc điểm kỹ thuật kiểm tra tích hợp phần mềm

[8] PHỤ LỤC 0 – Đặc điểm kỹ thuật kiểm tra chấp nhận phần cứng

[9] PHỤ LỤC P – Đặc điểm kỹ thuật kiểm tra chấp nhận hệ thống
PHỤ LỤC 0:

Quy trình soạn thảo Thông số kỹ thuật kiểm tra chấp nhận phần cứng

Chịu trách nhiệm: Nhà cung cấp

1. Giới thiệu

Quy trình này mô tả các tiêu chuẩn cho việc soạn thảo Thông số kỹ thuật kiểm tra chấp nhận phần cứng.

Đặc điểm kỹ thuật này xác định những kiểm tra nào phải được thực hiện để xác nhận rằng hệ thống đang hoạt động chính xác theo Đặc điểm kỹ thuật thiết kế phần cứng.

Thông số kỹ thuật kiểm tra chấp nhận phần cứng có thể có hai phần:

– Các thử nghiệm cho thấy hệ thống hoạt động tốt, đủ để được cài đặt và thử nghiệm tại chỗ. Đây được gọi là các bài kiểm tra hiệu suất của Nhà cung cấp.

– Các thử nghiệm cho thấy hệ thống đang hoạt động bình thường trong môi trường hoạt động của nó. Đây được gọi là các bài kiểm tra khách hàng tại chỗ.

Trong trường hợp này, bạn có thể tạo ra 2 tài liệu:

– Thông số kỹ thuật kiểm tra chấp nhận phần cứng của nhà máy – do nhà cung cấp sản xuất.

– Đặc điểm kỹ thuật kiểm tra chấp nhận phần cứng của trang web – do khách hàng chuẩn bị.

Đối với các hệ thống đã hoạt động, chỉ áp dụng điều khoản 2 (các thử nghiệm tại chỗ do khách hàng thực hiện).

2. Ứng dụng

Quy trình này được sử dụng để chuẩn bị các Thông số kỹ thuật kiểm tra chấp nhận phần cứng như được quy định trong Kế hoạch chất lượng của Nhà cung cấp [1].

3. Thủ tục

3.1. Hướng dẫn chung

Khi thiết lập đặc điểm kỹ thuật, hãy làm theo các hướng dẫn:

– Mỗi bài kiểm tra phải rõ ràng. Cần phải xác định rõ mặt hàng nào đã được kiểm tra và mặt hàng nào chưa.

– Các thông số kỹ thuật phải rõ ràng cho khách hàng, do đó nên tránh các biệt ngữ.

3.2. Nội dung tài liệu

Phần này xác định những phần và tiểu mục nào nên được bao gồm trong đặc điểm kỹ thuật. Tất cả các tiêu đề phần và tiểu mục phải có mặt. Nếu một phần hoặc tiểu mục không được sử dụng, nó được đánh dấu là ‘Không áp dụng được’.

3.2.1. Phần “Giới thiệu”

Phần này chứa các thông tin sau:

– Tài liệu do ai soạn thảo, trên cơ sở nào và nhằm mục đích gì

– Tình trạng hợp đồng của tài liệu

– Giao tiếp với các tài liệu khác.

3.2.2. Phần “Ứng dụng”

Phần xác định ranh giới của việc sử dụng chương trình kiểm tra chất lượng. Khi chuẩn bị Đặc điểm kỹ thuật kiểm tra chấp nhận phần cứng, các khía cạnh sau đây được xem xét:

Kiểm tra trực quan phần cứng xem có phù hợp với thiết kế không

Kiểm tra kết nối I / O

Kiểm tra phạm vi (tối thiểu 2 giá trị đã biết)

Kiểm soát kiểm tra phiên bản phần mềm

Kiểm tra độ chính xác của đồng hồ máy tính

Kiểm tra công suất và tiếng ồn

Kiểm tra chẩn đoán của nhà sản xuất

Kiểm tra bật / tắt nguồn

Môi trường hoạt động

3.2.3. Mục “Lịch trình thanh tra, kiểm tra”

Phần này trình bày cách tiếp cận chung để kiểm thử và cấu trúc của đặc điểm kỹ thuật. Cần phải lưu ý những điều sau:

– sử dụng, hoặc không sử dụng, [2] như một phương pháp thử nghiệm. Nếu [2] không được sử dụng, thì phương pháp thay thế đã chọn sẽ được mô tả.

– các khu vực đặc biệt không thể thử nghiệm, tại sao

– bất kỳ nhóm hợp lý hoặc thứ tự các thử nghiệm

– định dạng đánh số thử nghiệm

– Nhân sự cần thiết cho mỗi thử nghiệm hoặc nhóm thử nghiệm.

3.2.4. Phần “Điều kiện thử nghiệm”

Phần xác định những gì cần thiết để tiến hành thử nghiệm. Các khía cạnh sau được bao gồm:

Yêu cầu phần cứng.

Yêu cầu thiết bị thử nghiệm (đã hiệu chuẩn và chưa hiệu chuẩn).

Kiểm tra các yêu cầu phần mềm.

Yêu cầu dữ liệu thử nghiệm.

Tài liệu tham khảo

3.2.5. Phần “Quy trình kiểm tra”

Phần này chứa các chi tiết kiểm tra. Mỗi thử nghiệm được chuẩn bị phù hợp với [2].

Quy trình cho mỗi bài kiểm tra phải được đưa ra trên một trang riêng biệt và được tham chiếu chéo đến Đặc điểm kỹ thuật thiết kế phần cứng.

3.2.6. Phần thuật ngữ

Phần này bao gồm các định nghĩa của các thuật ngữ có thể không quen thuộc với người đọc Đặc điểm kỹ thuật.

3.3. Kết quả kiểm tra

Kết quả thử nghiệm được lưu trữ theo [2].

4. Đính kèm

[1] PHỤ LỤC G – Chuẩn bị Kế hoạch Chất lượng và Kế hoạch Dự án

[2] PHỤ LỤC N – Kiểm tra hệ thống tự động

PHỤ LỤC P: Quy trình soạn thảo Thông số kỹ thuật kiểm tra chấp nhận hệ thống

Chịu trách nhiệm: Nhà cung cấp

1. Giới thiệu

Quy trình mô tả tiêu chuẩn để soạn thảo Đặc tả Kiểm tra Chấp nhận Hệ thống.

Đặc điểm kỹ thuật này xác định những kiểm tra nào phải được thực hiện để xác nhận hoạt động chính xác của hệ thống phù hợp với Đặc điểm kỹ thuật chức năng. Các khía cạnh sau đây thường được xem xét:

– Chức năng hệ thống

– Đặc điểm hệ thống

– Các thông số quan trọng

– Phương thức hoạt động

Đặc tả kiểm thử chấp nhận hệ thống có thể có hai phần:

– Kiểm tra các chức năng và thiết bị có thể được kiểm tra bên ngoài môi trường hệ điều hành bằng cách sử dụng phần cứng và phần mềm kiểm tra. Đây được gọi là Kiểm tra hiệu suất của nhà cung cấp.

– Các thử nghiệm cho thấy hệ thống đang hoạt động chính xác trong môi trường hoạt động của nó và tương tác chính xác với các hệ thống và thiết bị khác. Đây được gọi là các bài kiểm tra khách hàng tại chỗ.

Trong trường hợp này, bạn có thể tạo ra 2 tài liệu:

1. Đặc điểm kỹ thuật kiểm tra nghiệm thu hệ thống nhà máy – bởi nhà cung cấp

2. Đặc điểm kỹ thuật kiểm tra chấp nhận hệ thống trang web – do khách hàng chuẩn bị.

Đối với các hệ thống đã hoạt động, chỉ áp dụng điều khoản 2 (các thử nghiệm tại chỗ do khách hàng thực hiện).

2. Ứng dụng

Quy trình này được sử dụng trong việc soạn thảo các thông số kỹ thuật của thử nghiệm mồi hệ thống, nơi được quy định trong Kế hoạch chất lượng của nhà cung cấp [1].

3. Thủ tục

3.1. Hướng dẫn chung

Khi vẽ thông số kỹ thuật, hãy làm theo hướng dẫn:

– Mỗi bài kiểm tra phải rõ ràng. Cần phải xác định rõ mặt hàng nào đã được kiểm tra và mặt hàng nào chưa.

– Đặc tả của kiểm thử chấp nhận hệ thống phải dễ hiểu đối với khách hàng, do đó nên tránh sử dụng các thuật ngữ.

3.2. Nội dung tài liệu

Phần này xác định những phần và tiểu mục nào nên được bao gồm trong đặc điểm kỹ thuật. Tất cả các tiêu đề phần và tiểu mục phải có mặt. Nếu một phần hoặc tiểu mục không được sử dụng, nó được đánh dấu là ‘Không áp dụng được’.

3.2.1. Phần “Giới thiệu”

Phần này chứa các thông tin sau:

– Tài liệu do ai soạn thảo, trên cơ sở nào và nhằm mục đích gì

– Tình trạng hợp đồng của tài liệu

– Liên kết đến các tài liệu khác

3.2.2. Phần “Ứng dụng”

Phần xác định ranh giới của việc sử dụng chương trình kiểm tra chất lượng. Các khía cạnh sau đây được tính đến khi soạn thảo đặc tả kiểm thử chấp nhận hệ thống:

Kiểm tra phần mềm ứng dụng để tuân thủ các đặc điểm kỹ thuật kiểm soát liên quan

Kiểm tra báo động

Kiểm tra hiển thị dữ liệu và báo cáo (giao diện)

Kiểm tra các yêu cầu quan trọng bao gồm các chức năng, dữ liệu và giao diện

Kiểm tra quy trình khởi động và tắt máy

Kiểm tra quy trình sao lưu và phục hồi

Kiểm tra các quy trình bảo mật và truy cập

Kiểm tra kế hoạch dự phòng

3.2.3. Mục “Lịch trình thanh tra, kiểm tra”

Phần này trình bày cách tiếp cận chung để kiểm thử và cấu trúc của đặc điểm kỹ thuật. Cần phải lưu ý những điều sau:

– sử dụng hoặc không sử dụng Phụ lục số [2] làm phương pháp thử nghiệm. Nếu [2] không được sử dụng, thì phương pháp thay thế đã chọn sẽ được mô tả.

– Các khu vực cụ thể không thể kiểm chứng, tại sao

– Bất kỳ nhóm hợp lý hoặc sắp xếp các bài kiểm tra

– Định dạng đánh số thử nghiệm

– Nhân sự cần thiết cho mỗi thử nghiệm hoặc nhóm thử nghiệm.

3.2.4. Phần “Điều kiện thử nghiệm”

Phần xác định những gì nên được gửi khi bắt đầu thử nghiệm. Các khía cạnh sau đây cần được lưu ý:

– Yêu cầu phần cứng

– Yêu cầu đối với phần mềm kiểm tra

– Yêu cầu đối với dữ liệu thử nghiệm

– Tài liệu tham khảo

3.2.5. Phần “Quy trình kiểm tra”

Phần này chứa các chi tiết kiểm tra. Mỗi thử nghiệm được chuẩn bị phù hợp với [2].

Mỗi quy trình thử nghiệm phải nằm trên một trang riêng biệt và được tham chiếu chéo đến Đặc điểm kỹ thuật chức năng.

3.2.6. Phần thuật ngữ

Phần này chứa các định nghĩa của thuật ngữ có thể không quen thuộc với người đọc thông số kỹ thuật.

3.3. Kết quả kiểm tra

Kết quả thử nghiệm được lưu trữ theo [2].

4. Đính kèm

[1] PHỤ LỤC G – Lập Kế hoạch và Kế hoạch Chất lượng

[2] PHỤ LỤC N – Kiểm tra hệ thống tự động

 

PHỤ LỤC H: Quy trình kế hoạch bảo trì

Chịu trách nhiệm: Khách hàng và Nhà cung cấp

1. Giới thiệu

Kế hoạch Bảo trì xác định các yêu cầu kỹ thuật để bảo trì các hệ thống tự động và các yêu cầu chất lượng.

Nó xác định cách thức đáp ứng các yêu cầu này theo các khía cạnh sau:

– đơn vị nào sẽ được bảo dưỡng

– những sự kiện nào sẽ được tổ chức và ngày của chúng

– người chịu trách nhiệm về các hoạt động bảo trì

– các thủ tục và kiểm soát bảo trì.

Kế hoạch bảo trì ở giai đoạn hỗ trợ vận hành hệ thống thay thế Kế hoạch chất lượng (điều này một lần nữa nhấn mạnh rằng công việc bảo trì phần mềm rất khác với việc tự lập trình).

2. Ứng dụng

Quy trình này áp dụng cho các hệ thống mà Nhà cung cấp sẽ duy trì. Kế hoạch bảo trì thường do Nhà cung cấp lập và là cơ sở cho hợp đồng bảo trì chính thức giữa khách hàng và Nhà cung cấp. Trong trường hợp có bất kỳ sai lệch nào so với quy trình này, lý do được chỉ ra trong Kế hoạch Bảo trì.

3. Thủ tục

3.1. Hướng dẫn chung

Kế hoạch bảo trì là một tài liệu hợp đồng và phải được sự chấp thuận của đại diện Nhà cung cấp và khách hàng.

Kế hoạch bảo trì được kiểm soát phù hợp với [1].

3.2. Nội dung tài liệu

Phần này xác định những phần và tiểu mục nào sẽ được bao gồm trong Kế hoạch Bảo trì. Nếu một Phần hoặc tiểu mục không được xem xét, hộp kiểm “Không áp dụng” được chọn.

3.2.1. Giới thiệu

Phần này chứa các thông tin sau:

– Tài liệu do ai soạn thảo, trên cơ sở nào và nhằm mục đích gì

– Tình trạng hợp đồng của tài liệu.

3.2.2. Thông tin chung

Phần này mô tả bản chất của hợp đồng / thỏa thuận bảo trì và cách Kế hoạch bảo trì liên quan đến các tài liệu khác như Hợp đồng hỗ trợ khách hàng tiêu chuẩn.

3.2.3. Định nghĩa

Phần này giải thích tất cả các thuật ngữ được sử dụng trong Kế hoạch Bảo trì có thể bị hiểu nhầm.

3.2.4. Yêu cầu kỹ thuật

Khu vực bảo trì

Phần xác định các đơn vị phải bảo trì và thời gian bảo trì. Nó có thể:

Các chương trình

Dữ liệu và cấu trúc của chúng

Thông số kỹ thuật (sửa)

Tài liệu khách hàng

Tài liệu về Nhà cung cấp

Phần cứng, Thiết bị ngoại vi và Ghi nhãn

Xác định trạng thái ban đầu của sản phẩm

Phần xác định trạng thái ban đầu của mỗi đơn vị phải bảo trì, theo thỏa thuận giữa khách hàng và Nhà cung cấp. Một tài liệu thích hợp đang được soạn thảo.

Tổ chức bảo trì

Đôi khi có thể cần tạo một tổ chức bảo trì riêng biệt. Điều này sẽ cho phép bạn sử dụng các thiết bị cần thiết một cách nhanh chóng và hiệu quả để giải quyết các vấn đề khác nhau phát sinh trong quá trình bảo trì. Phần này xác định tổ chức này sẽ là gì và phạm vi hoạt động của tổ chức, trong số những thứ khác, bao gồm công việc của hệ thống hỗ trợ người dùng (bàn trợ giúp).

Điều này thường cũng bao gồm danh sách những người liên hệ và các thủ tục liên lạc, chẳng hạn như kiểm tra định kỳ.

Các loại công việc bảo trì

Phần này xác định các thủ tục quản lý cấu hình và kiểm soát thay đổi. Chúng phải giống như trong lập trình càng nhiều càng tốt.

Phần này cũng ghi lại các loại công việc bảo trì và quy trình cho từng trường hợp. Các hướng dẫn / sách hướng dẫn sử dụng trong công việc cũng được ghi lại tại đây.

Các loại công việc bảo trì:

– Giải quyết vấn đề: xác định, phân tích và sửa chữa các điểm không nhất quán của phần mềm. Các thủ tục được sử dụng để triển khai ‘Bản sửa lỗi nhanh’ và chuyển chúng thành các sửa đổi vĩnh viễn.

– Sửa đổi giao diện. Các thủ tục được sử dụng để bao gồm các sửa đổi do thay đổi phần cứng gây ra.

– Mở rộng chức năng hoặc cải thiện hiệu suất. Các thủ tục được sử dụng để nâng cấp hệ thống.

Báo cáo và tài liệu bảo trì

Phần này xác định cách thức công việc bảo trì sẽ được ghi lại và lưu trữ.

Hồ sơ bảo trì được lưu trữ giống như hồ sơ chất lượng. Chúng bao gồm (cho mỗi mục nhập):

– Danh sách các phiếu hỗ trợ hoặc báo cáo sự cố đã nhận được và tình trạng hiện tại của mỗi phiếu.

– Tổ chức chịu trách nhiệm phản hồi các yêu cầu và thực hiện các điều chỉnh thích hợp.

– Thứ tự mức độ khẩn cấp (ưu tiên) được ấn định cho từng hoạt động.

– Kết quả của hành động sửa chữa.

– Thống kê tần suất hỏng hóc và các điều chỉnh theo đó. Những hồ sơ này sẽ tạo cơ sở cho một báo cáo tiến độ dự án định kỳ. Nội dung, tần suất biên soạn và lưu hành báo cáo này được xác định ngay lập tức.

Thủ tục phát hành

Phần này xác định các thủ tục được sử dụng để thực hiện các thay đổi đối với phần mềm đã trở nên cần thiết do kết quả của quá trình bảo trì. Điêu nay bao gôm:

– Quy tắc sửa đổi và thực hiện các phiên bản mới

– Phương pháp thông báo cho người dùng về các thay đổi

– Phương pháp thử nghiệm để tích hợp các thay đổi vào phần mềm

– Lưu giữ hồ sơ các thay đổi.

3.2.5. Yêu cầu chất lượng

Phần này xác định chất lượng và các yêu cầu đối với tài liệu của Kế hoạch Bảo trì. Điêu nay bao gôm:

– Yêu cầu chất lượng của khách hàng

– Tiêu chí đầu vào và đầu ra

– Trách nhiệm duy trì chất lượng

– Hoạt động kiểm tra

– Người liên hệ khách hàng

4. Đính kèm

[1] PHỤ LỤC E – Soạn thảo, Kiểm soát và Phát hành Tài liệu

PHỤ LỤC R:

Các hình thức

Tên số

MẪU 1 Phê duyệt tài liệu

MẪU 2 Sổ đăng ký lưu hành tài liệu

MẪU 3 Thông báo chuyển tài liệu

MẪU 4 Lịch sử tài liệu

MẪU 5 Mục lục tài liệu lưu trữ

MẪU 6 Yêu cầu thay đổi

MẪU 7 Bảng kết quả kiểm tra

MẪU 8 Phiếu kiểm tra sự cố

MẪU 9 Báo cáo đánh giá

MẪU 10 Tóm tắt nhận xét

MẪU 1 1 Bảng tiến trình kiểm tra

MẪU 12 Thay đổi chỉ mục yêu cầu

MẪU 13 Ghi chú thay đổi

PHỤ LỤC U: Các Quy định Quản lý Thuốc của EU, Tập IV Phụ lục 11 – Hệ thống Máy tính

Nguyên tắc cơ bản

Việc đưa các hệ thống vi tính hóa vào sản xuất, bảo quản, phân phối và kiểm soát chất lượng không loại trừ sự cần thiết phải tuân thủ các nguyên tắc liên quan được nêu trong Hướng dẫn. Khi hệ thống vi tính hóa thay thế công việc thủ công, chất lượng sản phẩm sẽ không bị giảm sút. Cần chú ý đến những rủi ro có thể xảy ra liên quan đến việc giảm số lượng người tham gia.

Nhân viên

1. Cần thiết lập sự hợp tác chặt chẽ nhất giữa nhân sự chủ chốt và nhân sự CNTT. Những người có trách nhiệm phải được đào tạo thích hợp về quản lý và sử dụng hệ thống máy tính trong lĩnh vực hoạt động của họ. Việc đào tạo như vậy cần cung cấp kiến ​​thức chuyên môn và dạy cách áp dụng nó trong thiết kế, xác nhận, cài đặt và vận hành các hệ thống máy tính.

Thẩm định

2. Mức độ xác nhận sẽ phụ thuộc vào một số yếu tố như phạm vi của hệ thống, việc xác nhận là tương lai hay hồi cứu, liệu các yếu tố mới có được đưa vào, v.v. Việc xác nhận phải được coi là một phần của hệ thống tổng thể về vòng đời của hệ thống máy tính, bao gồm các giai đoạn lập kế hoạch, đặc điểm kỹ thuật, lập trình, kiểm tra, vận hành, tài liệu, giám sát và hiện đại hóa.

3. Cần chú ý đặt thiết bị trong môi trường thích hợp để các yếu tố bên ngoài không cản trở hoạt động của hệ thống.

4. Mô tả chi tiết về hệ thống nên được lập (bao gồm cả sơ đồ nếu cần) và cập nhật khi cần thiết. Mô tả phải bao gồm các nguyên tắc, mục tiêu, các biện pháp bảo mật và lĩnh vực áp dụng của hệ thống, cũng như các điều kiện sử dụng máy tính và cách hệ thống tương tác với các hệ thống và quy trình khác.

5. Phần mềm là một thành phần quan trọng của hệ thống máy tính. Người dùng phải thực hiện tất cả các biện pháp cần thiết và đảm bảo rằng phần mềm này được sản xuất phù hợp với hệ thống Đảm bảo Chất lượng.

6. Hệ thống nên bao gồm các kiểm tra tích hợp để nhập và xử lý dữ liệu chính xác.

7. Trước khi bắt đầu làm việc với hệ thống, nó phải được kiểm tra kỹ lưỡng. Trong quá trình thử nghiệm, cần phải xác nhận rằng hệ thống thực sự có thể đạt được kết quả theo kế hoạch. Nếu một hệ thống được máy tính hóa thay thế một hệ thống thủ công, thì như là một phần của quá trình kiểm tra và xác nhận tổng thể, cả hai hệ thống sẽ hoạt động song song trong một thời gian.

8. Dữ liệu chỉ nên được nhập hoặc sửa chữa bởi những người có thẩm quyền. Các phương pháp ngăn chặn truy cập trái phép bao gồm sử dụng chìa khóa, thẻ truy cập, mã cá nhân và thiết lập quyền truy cập hạn chế vào các thiết bị đầu cuối máy tính. Cần xác định thủ tục cấp, hủy bỏ hoặc thay đổi quyền truy cập để nhập hoặc sửa dữ liệu, trong đó bao gồm cả việc thay đổi mật khẩu cá nhân. Cần ưu tiên cho các hệ thống theo dõi các nỗ lực truy cập trái phép.

9. Khi dữ liệu quan trọng được nhập theo cách thủ công (ví dụ: trọng lượng và số lô của một thành phần khi pha chế), cần phải xác minh thêm về tính chính xác của hồ sơ. Việc xác minh này có thể được thực hiện bởi nhà điều hành thứ hai hoặc các phương tiện điện tử được ủy quyền.

10. Hệ thống phải ghi lại danh tính của các nhà khai thác nhập hoặc phê duyệt dữ liệu quan trọng. Quyền thay đổi dữ liệu chỉ nên được trao cho những người được chỉ định đặc biệt. Bất kỳ thay đổi nào đối với việc nhập dữ liệu quan trọng phải được cho phép bằng văn bản và có lý do. Nên ưu tiên các hệ thống có báo cáo cài sẵn cho tất cả các thông tin đăng nhập và thay đổi dữ liệu (đường mòn kiểm tra).

mười một. Các thay đổi đối với hệ thống hoặc chương trình máy tính phải được thực hiện theo đúng một quy trình xác định quy định quá trình xác nhận, kiểm tra, phê duyệt và thực hiện các thay đổi. Tất cả các thay đổi được thực hiện sau khi thỏa thuận với nhân viên chịu trách nhiệm về phần này của hệ thống và được lập thành văn bản. Bất kỳ thay đổi quan trọng nào phải được ủy quyền bằng văn bản.

12. Đối với mục đích kiểm tra chất lượng, cần phải có bản cứng chính xác của dữ liệu được lưu trữ điện tử.

13. Dữ liệu phải được bảo vệ bằng các phương tiện vật lý hoặc điện tử khỏi những thiệt hại do cố ý hoặc vô tình, phù hợp với điều khoản 4.9. Hướng dẫn. Dữ liệu được lưu trữ cần được kiểm tra về tính khả dụng, độ bền và độ chính xác. Nếu dự kiến ​​có những thay đổi về phần cứng hoặc chương trình của máy tính, các kiểm tra trên phải được thực hiện với tần suất phù hợp với phương tiện lưu trữ được sử dụng.

14. Dữ liệu cần được bảo vệ bằng các bản sao lưu định kỳ.

15. Phải cung cấp đầy đủ các phương tiện thay thế để các hệ thống tiếp tục hoạt động trong trường hợp có sự cố. Thời gian cần thiết để cài đặt chúng phải tương xứng với mức độ khẩn cấp có thể có của việc sử dụng chúng.

16. Các thủ tục cần được soạn thảo và phê duyệt để thiết lập quy trình hành động trong trường hợp hệ thống xảy ra sự cố / hỏng hóc. Tất cả các hư hỏng / sự cố và các hành động được thực hiện phải được lập thành biên bản.

17. Cũng cần thiết lập quy trình ghi chép và phân tích các lỗi hệ thống và quy trình sửa chữa chúng.

18. Trong trường hợp một công ty bên ngoài tham gia vào việc cung cấp các dịch vụ máy tính, một thỏa thuận chính thức phải được lập ra với chỉ dẫn rõ ràng về trách nhiệm của công ty (xem Chương 7).

19. Khi một hệ thống máy tính được sử dụng để giải phóng các lô hàng hóa để bán hoặc giao hàng, chỉ Người đủ điều kiện mới có quyền truy cập vào công việc này và hệ thống phải nhận ra và báo cáo rõ ràng cho người đó.

KS. Nguyễn Hoàng Quốc Ấn chuyên thiết kế phòng sạch, nhà máy dược, bệnh viện, phân xưởng điện tử board mạch...v.v
0914 24 20 94 | nguyenhoangquocan@gmail.com.