Good Automated Manufacturing Practice

Pharmaceutical Industry Supplier Guide for Validation of Automated Systems

in Pharmaceutical Manufacture

Надлежащая практика автоматизированного производства

Руководство для поставщиков фармацевтической промышленности по валидации автоматизированных систем для фармацевтической промышленности

ПРИЛОЖЕНИЕ A:

Процедура составления Спецификации требований пользователя

 

Ответственный: Заказчик

1. Введение

Здесь описываются стандарты по написанию и содержанию Спецификации требований пользователя (User Requirements Specifications (URS).

 

2. Применение

Эта методика может использоваться производителями фармацевтической продукции или лицами, работающими от их имени, для того, чтобы определить требования  к автоматизированной системе. URS представляется поставщику и рассматривается как конечное требование к тому, что должна делать система.

 

3. Процедура

3.1. Общие указания

Спецификация требований пользователя четко определяет, что заказчик хочет видеть в системе: какие функции он должна выполнять, на каких данных будет работать, в какой операционной среде. URS также определяет любые неконструктивные требования, ограничения, такие как сроки выполнения работ, цена, какие комплектующие должны быть поставлены и т.д. Упор должен делаться на те функции, которые должна выполнять система по окончанию работы, а не на то, как будут внедряться эти функции програмистами. 

При составлении спецификации необходимо учесть следующее:

1.       Каждое требование должно быть четко описано, если требуется с применением схем, таблиц, и не должно превышать 250 слов.

2.       Требования не должны повторяться или противоречить друг другу.

3.       URS должна содержать требования к программе, а не предлагать решения.

4.       Каждое требование должно быть контролепригодным, т.е. должна предусматриваться возможность его тестирования.

5.       URS должна быть понятна как заказчику, так и исполнителю, необходимо избегать любых двусмысленностей или жаргона.

6.       При возможности URS должна различать требования, обязательные к исполнению, и желательные.

7.       Возможно, потребуется официальное рассмотрение URS заказчиком и исполнителем. Это поможет проверить понимание требований URS, а также проверить учтены ли (или нет) требования URS  в Функциональной Спецификации (Functional Specification).

3.2. Содержание документа

Данный раздел определяет какие разделы и подразделы должны быть включены в URS. Все нижеперечисленные разделы должны быть включены. Если требования по данному разделу не определены, он помечается как 'Not applicable' («Не применяется»).

3.2.1. Введение

Данный раздел содержит следующую информацию:

1.       Кто составил документ, на каком основании и с какой целью.

2.       Договорной статус документа (контракт, договор, обязательство, соглашение).

3.       Связь с другими документами.

3.2.2. Общее представление о системе

Данные раздел описывает систему в общих чертах, объясняя, для чего она необходима и что от нее требуется. Раздел содержит следующие подразделы:

1.         Предпосылки для создания системы (например, корпоративная стратегия, предшествующие исследования).

2.         Основные цели создания системы и преимущества ее использования.

3.         Главные функции системы и интрефейсы.

3.2.3. Операционные требования

Данный раздел оговаривает операционные требования – структурные функции системы, данные, интерфейс и операционную среду. Критические требования должны быть подчеркнуты и определены как таковые.

Должны быть включены следующие подразделы:

3.2.3.1. Функции

Подраздел определяет системные функции, режимы работы и поведение системы. Он должен описывать следующее:

-          необходимые функции. Сюда должна быть включена информация по процессу производства или существующей неавтоматической системе, если только это не оговаривалось выше.

-          рассчеты, включая все решающие алгоритмы.

-          режимы работы (например, запуск, закрытие системы,  тестирование, нейтрализация неисправностей).

-          Требования к быстродействию и синхронизации. Должны быть количественными и точно выраженными.

-          Выход из строя. Какие действия необходимы в случае, если программа или аппаратные средства вышли из строя.

-          надежность и безопасность.

 

3.2.3.2. Данные

Этот раздел рассматривает требования к обработке данных. Он должен описывать следующее:

-          Определение данных. При этом оговариваются их критические параметры.

-          Требования по пропускной способности.

-          Требования по скорости доступа.

-          Требования к архивированию.

 

3.2.3.3. Интерфейсы

Раздел определяет возможные интерфейсы системы. Включает следующие подразделы:

1.       Интерфейс с пользователями – описываются для каждой роли (например,  оператор, администратор склада, менеджер системы и т.д.) и/или функций в зависимости от обстоятельств.

2.       Интерфейс с другими системами.

3.       Интерфейс с оборудованием (например, сенсоры/приводы).

 

3.2.3.4. Окружающая среда

Раздел определяет в какой среде будет работать система. Включает следующие подразделы:

1.       Размещение. Физическое расположение оборудования или рабочего места может влиять на работу системы (например, связи на больших расстояниях, ограниченная площадь).

2.       Физические условия (например, пыльное или стерильное помещение и т.д.).

 

3.2.4. Ограничения

 

Раздел определяет ограничения на спецификацию системы. Должен содержать следующие подразделы:

 

1.       Временные рамки.

2.       Совместимость. Должна учитываться совместимость с любыми существующими системами или оборудованием, а также с любыми возможными стратегиями развития компании.

3.       Возможность использования. Оговариваются требования к надежности системы и максимально допустимые сроки текущего ремонта или иного простоя.

 

4.       Процедурные ограничения (например, обязательства перед законом или уставом, возражения правового порядка, методы работы или уровень квалификации пользователей).

 

5.       Сопровождение (например, легкость обслуживания, возможность наращивания, модернизации, ожидаемый срок службы, долгосрочная поддержка).

 

3.2.5. Жизненный цикл

 

Раздел устанавливает сроки разработки системы. Содержит следующие подразделы:

 

1.       Разработка (например, порядок управления проектом и гарантии качества, обязательные методы разработки).

 

2.       Тестирование (например, особые требования к тестированию, данные для тестирования, испытание под нагрузкой – тестирование загрузки, имитационное тестирование).

 

3.       Поставка. Определяет, что должно быть доставлено. Сюда относится следующее:

 

-          Как идентифицируются доставляемые элементы.

 

-          В какой виде они поставляются (например, формат и носители).

 

-          Документы. Какие документы должен предоставить поставщик (например, функциональная спецификация (functional specification), спецификации тестирования (testing specifications), проектные спецификации (design specifications) и т.д.).

 

-          Данные, которые должны быть подготовлены или конвертированы.

 

-          Инструменты.

 

-          Тренинги.

 

-          Оборудование для архивирования.

 

4.       Сопровождение. Раздел описывает, какая поддержка необходима будет после принятия программы.

 

3.2.5. Глоссарий

 

Раздел содержит разъяснения терминов, которые могут быть незнакомы читающему URS.

 

 

4. Ссылки

 

Ссылок нет.

ПРИЛОЖЕНИЕ B:

Процедура  анализа документации и ПО

 

Ответственный: Заказчик и Поставщик

1. Введение

 

Данная процедура описывает методику проведения, регистрации и контроля за исполнением:

 

-          Анализа официальной документации;

 

-          Анализа програмной части приложения (иногда называют «анализ кода программы»).

 

2. Применение

 

Данная методика применяется к документации и програмному обеспечению, представляемым поставщиком в соответствии с Планом качества.

 

3. Процедура

 

3.1. Анализ документации

 

Анализ документации проводится до официального написания документа.

 

Анализ проводится официально, при этом составляется протокол на основе Отчета о проверке (Review Report) [1].

 

Анализ проводят лица, утвержденные планом или назначенные менеджерами высшего звена.

 

Копии документа, представленного на анализ, должны быть распространены заранее, что позволит обеспечить надлежащую подготовку.

 

Во время работы должен быть систематически проанализирован каждый раздел документа. Если раздел принят без комментариев, это должно быть зафиксировано в протоколе.

 

Кому направить официальный документ согласовывается членами комиссии и вносится в протокол [1].

 

Коррективы, намеченные в ходе анализа, выполняются согласно раздела «Дальнейшая доработка» (Follow-up).

 

И только когда все изменения, предложенные комиссией, будут внесены в окончательную версию документа, документ может быть подписан. Первоначальная версия документа должна сохраняться.

 

Все отчеты о проверке (Review Reports) должны быть зарегистрированы и снабжены указателем согласно Сводке отчетов (Review Summary) [2].

 

3.2. Анализ програмной части приложения

 

Анализ прикладного програмного обеспечения проводится лицами, утвержденными планом. Желательно включить разработчика или автора ПО.

 

Анализ ПО должен проводиться официально и быть запротоколирован на основе Отчета о проверке [1].

 

Должны быть рассмотрены следующие аспекты:

 

-          Схема ПО.

 

-          Соблюдение стандартов кодирования.

 

-          Логика ПО.

 

-          Избыточный код.

 

-          Важнейшие алгоритмы (согласно Спецификации требований пользователя).

 

Согласованные изменения, необходимость которых вытекает из анализа ПО, выполняются согласно раздела «Дальнейшая доработка» (Follow-up) данной методики.

 

Все изменения должны быть внесены до сдачи ПО.

 

Все отчеты о проверке должны быть зарегистрированы и снабжены указателем согласно Сводке отчетов [2].

 

Распечатки, структурные схемы и т.д. должны сохраняться вместе с отчетом о проверке.

 

3.3. Устранение замечаний, выявленных в ходе проверки

 

На каждое внесение изменений назначается ответственный, который должен закончить работу к утвержденной дате. По окончанию работы все замечания о том, как вносились измения, фиксируются в [1], и работа считается оконченной. Когда внесены все изменения, отчет закрывается. Сводка отчетов [2] корректируется с учетом внесенных поравок.

 

Отчеты о проверке [1] и сводки отчетов [2] периодически проверяются руководителем проекта. Если изменения внесены не так, как намечалось, или нет записей о выполнении работы, руководитель проекта принимает меры.

 

3.4. Общие положения

 

Спецификации по проектированию модулей ПО (Software Module Design Specifications) скорее относятся к анализу ПО, нежели к анализу документации, при условии, что они пишутся с использованием логических диагарам или псевдо-кода. Если же эта спецификация пишется в виде текста, тогда она относится к анализу документации.

 

 

4. Ссылки

 

[1 ] Форма 9, ПРИЛОЖЕНИЕ R - Отчет о проверке (Review Report)

 

[2] Форма 10, ПРИЛОЖЕНИЕ R – Сводка отчетов  (Review Summary)

 

ПРИЛОЖЕНИЕ C:

Процедура проведения аудита поставщика

 

Ответственный: Заказчик

1. Введение

 

Данная методика описывает процесс проверки заказчиком поставщиков програмного обеспечения: его планирование, выполнение и внесение изменений.

 

2. Применение

 

Данная методика применяется при проведении внешнего аудита поставщиков автоматизированных систем, что является частью формальной системы оценивания поставщиков, согласно Плана валидации (Customer Validation Plan).

 

3. Процедура

 

3.1. Аудиторы

 

Аудиторами назначают работников, имеющих, по мнению руководителй проекта, достаточный опыт и квалификацию.

 

3.2. Планирование аудита

 

В ходе общего процесса валидации автоматизированной системы, заказчик должен убедиться, что поставщик в состоянии выполнить все требования, зафиксированные в Плане валидации данной системы. Для этого может понадобиться внешний контроль качества.

 

Заказчик хранит все документы по аудиту и на основе полученных данных делает рекомендации в соответствии с разделом 3.5 данной процедуры.

 

Заказчик придерживается Плана внешнего контроля качества (External Quality Audit Schedule), который определяет, как часто будут проводиться такие проверки. Частота проверок зависит от нескольких факторов: насколько качественно был выполнен заказ в предыдущий раз (исходя из предыдущих аудитов), как часто фирма-заказчик работала с данным поставщиком и т.д.

 

Необходимо помнить, что даже если данная Система качества (Quality System) поставщика зарегистрирована согласно национальному или международному Стандарту качества (например, ISO 9000), регулярные плановые проверки необходимы.

 

3.3. Подготовка и проведение аудита

 

Аудиты могут проводиться и документироваться согласно инструкции, изложенной в ISO 10011 Часть 1. При проведении аудита используется приведенная ниже контрольная таблица (checklist).

 

3.4. Завершение аудита

 

Отчеты о проведении аудита хранятся в составе общей документации по проекту.

 

После получения отчета о проведении аудита, заказчик принимает одно из нижеизложенных решений:

 

-          одобрить поставщика без условий

 

-          одобрить поставщика после того, как будут внесены изменения, предписанные Отчетом по внешнему аудиту качества (External Quality Audit Report)

 

-          согласовать документацию Системы качества (Quality System) с поставщиком в контрактных целях

 

-          запретить работу с поставщиком.

 

3.5. Внесение исправлений, доработка и надзор

 

Если в ходе аудита поставщика обязывают выполнить определенные изменения, аудиторы контролируют этот процесс и составляют документ, подтверждающий, что все изменения были внесены, после чего работы по контракту продолжаются.

 

В отчете о проведении внешнего аудита качества также определяются частота контрольных визитов и план дальнейших проверок.

 

 

4. Ссылки

 

[1]   IS010011 Part 1 Guidelines for Quality Systems Auditing

или

BS7229 British Standards Guide to Quality Systems Auditing

 

[2]   ISO 9000 Quality Systems

или

BS5750 British Standards Quality Systems

 

5. Контрольная таблица

 

Ниже приводится контрольная таблица для проведения аудита поставщиков автоматизированных систем. Она содержит лишь основные пункты, в то время как в каждом конкретном случае может потребоваться проверка иных, дополнительных факторов.

 

5.1. Организация

 

-          Структура менеджмента (роли, ответственность, позиция при проведении аудита (QA)

 

-          Политика компании

 

-          Документация по системе управления качеством (руководство (Manual), процедуры (Procedures)

 

-          Любой признанный сертификат качества.

 

 

5.2. Планирование

 

-          Проверки контракта

 

-          План проекта//качества (временные рамки, жизненный цикл, мероприятия, персонал, ограничения, проверка

 

-          Мониторинг проекта

 

-          Документация по проверкам

 

-          Записи по проекту.

 

5.3. Спецификация

 

-          Спецификация требований пользователя (User Requirements Specification)

 

-          Функциональная спецификация (Functional Specification)

 

-          Спецификации разработки ПО (Software Design Specifications)

 

-          Спецификации проектирования аппаратных средств (Hardware Design Specifications)

 

-          Документация о проверках (Documented Reviews)

 

-          Используемая методология проектирования (Design Methodologies Used)

 

-          Метрики производительности програмиста/аналитика.

 

5.4. Внедрение

 

-          Исходный код (доступный, структурированный, хорошо документированный)

 

-          Документация по проверкам исходного кода.

 

5.5. Тестирование

 

-          ПО для тестирования/Тестовые данных/Симуляторы

 

-          Спецификации тестирования ПО

 

-          Результаты тестирования ПО

 

-          Спецификация тестирования аппаратных средств

 

-          Результаты тестирования аппаратных средств

 

-          Спецификация приемочного тестирования системы (на территории разработчика, на месте)

 

-          Результаты тестирования системы.

 

-          Документация по проверкам.

 

5.6. Завершение

 

-          Передача материалов проекта (сертификаты соответствия, гарантии)

 

-          Документация для пользователей

 

-          Поддержка.

 

5.7.  Мероприятия по контролю

 

-          Управление документацией

 

-          Управление конфигурацией ПО (Контроль ПО)

 

-          Контроль изменений (документация, ПО)

 

-          Управление системой (доступ, безопасность, резервное копирование, инструменты ПО)

 

-          Архивация

 

-          Субконтрактный контроль

 

-          Внутренние проверки (аудиты)

 

-          Что приобретено

 

-          Обучение персонала

 

-          Поддержка.

 

ПРИЛОЖЕНИЕ D:

Процедура производства, контроля и выпуска програмного обеспечения.

 

Ответственный: Поставщик

1. Введение

 

Данный документ определяет позицию менеджмента проекта, стандарты программирования ПО и методику контроля за конфигурацией.

 

2. Применение

 

Данная методика применяется ко всему ПО, разрабатываему в рамках данного проекта. Если проект не согласован с данной процедурой, или есть отклонения, это должно быть отмечено в Плане качества [1].

 

3. Процедура

 

3.1. Производство ПО

 

В любом проекте в первую очередь определяются стандраты кодирования, которых и придерживаются в ходе програмирования. Соглашения по кодированию должны включать комментарии и схемы.  Все это документируется, например, в описании проекта (project note) с соответствующими ссылками в Плане качества.

 

В каждом проекте устанавливаются свои стандарты по присваиванию имен директориям и файлам, и это также обязательно документируется с соответствующими ссылками в Плане качества.

 

Где это необходимо, создается также набор командных файлов для управления конструкцией, а именно для:

 

-          Компилирования исходных модулей ПО

 

-          Компоновки конечных модулей ПО

 

-          Запуска исполнимых изображений.

 

Командные файлы должны быть достаточно общими, так чтобы все члены команды могли их использовать.

 

После того, как программный код будет создан и успешно компилирован, он должен быть подвергнут критическому анализу согласно [2]. Критический разбор программы производится перед приемочным тестированием ПО.

 

3.2. Контроль за конфигурацией

 

В каждом проекте должна быть разработана методика контроля за ПО с тем, чтобы обновления к замороженному ПО обрабатывались последовательно и контролировались надлежащим образом. Контроль за конфигурацией ПО осуществляется в соответствии с Планом управления конфигурацией (Configuration Management Plan).

 

3.3. План управления конфигурацией

 

План управления конфигурацией составляется для любых проектов по ПО и является частью Плана качества.

 

План управления конфигурацией включает следующие пункты:

 

-          Организация и распределение ответственностей с соответствующими ссылками в Плане качества.

 

-          Мероприятия по управлению конфигурацией, см. ниже.

 

-          Используемые методы управления конфигурацией.

 

-          Указание на то, на какой стадии работы каждый элемент будет подвергаться контролю конфигурации ПО.

 

3.3.1. Мероприятия по управлению конфигурацией

 

-          Идентификация конфигурации и трассируемость.

 

Каждый элемент ПО должен иметь уникальный идентификационный номер/имя.

Номер/имя должны быть такими, чтобы была возможность отследить код до следующего, верхнего, уровня таким образом, чтобы  все элементы ПО можно было отследить по соответствующим спецификациям либо по нумерации/именам, либо по соответствующему тексту в заголовке модуля.

Соглашение по нумерации/именованию должно быть четко описано.

 

-          Контроль изменений

 

Изменения контролируются согласно [3].

Все запросы на внесение изменений должны быть зарегистированы, например, в форме заявки на внесение изменений, описанной в [3], которая хранится в соответствующем «Реестре заявок на внесение изменений».

-          Отчет о состоянии конфигурации (Configuration status report)

 

Конфигурация ПО и ее состояние должны определяться для каждого проекта, например, в виде списка, в котором будут указаны номер версии и соответсвующие запросы на внесение изменение. 

 

3.4. Идентификация и трассируемость модулей ПО

 

3.4.1. Идентификация модулей ПО

 

Каждый модуль ПО в своем заголовке/шапке должен обязательно содержать следующую информацию:

 

-          Название/имя модуля

 

-          Названия/имена составляющих исходных файлов

 

-          Номер версии модуля

 

-          Название и номер  проекта (если есть)

 

-          Караткое описание модуля

 

-          Все коммандные файлы, используемиые для компилирования и компоновки модуля

 

-          История изменений. Описание каждого изменения должно содержать следующую информацию:

 

Номер заявки на внесение изменений

Номер новой версии

Дата внесения изменения (изменений)

Инициалы человека (людей), вносившего изменения 

Исходный файл (файлы), которые подвергались изменениям.

 

3.4.2. Трассируемость модуля ПО

 

Все изменения модулей ПО должны быть четко описаны в исходных файлах кодирования.

 

Добавления описываются через использование комментария, который ссылается на соответствующий номер Заявки на внесение изменений (Change Request).

 

Удаления могут описываться двумя способами:

 

-          Комментирование кода и обозначение удаления через ссылку на соответствующий Запрос на внесение изменений

или

 

-          Удаление кода и обозначение удаления через ссылку на соответствующий Запрос на внесение изменений.

 

 

4. Ссылки

 

[1 ] ПРИЛОЖЕНИЕ G - План качества и план проекта (Quality and Project Plan)

 

[2] ПРИЛОЖЕНИЕ B - Отчеты по документации и ПО (Document and Software Reviews)

 

[3] ПРИЛОЖЕНИЕ F - Контроль изменений (Change Control)

 

ПРИЛОЖЕНИЕ E:

Процедура составления, контроля и выпуска документации

 

Ответственный: Поставщик

1. Введение

 

Данная методика описывает систему подготовки, анализа, утверждения и непосредственного выпуска документов.

 

2. Применение

 

Эта процедура применяется к документации по проекту так, как это предусмотрено Планом качества поставщика.

 

3. Процедура

 

3.1 Составление документации

 

Стандарты по составлению документации согласовываются на месте. Сюда входит порядок оформления документов, стиль и нумерация. Все документы составляются в соответствии с принятой процедурой. Заверяющие подписи в каждом документе должны сопровождаться указанием должностей лиц, подписыващих документ.

 

До того, как документ будет принят окончательно, составляется предварительный набросок, которому присвивается номер/имя (например, в алфавитном порядке, начиная с А, с последующем номером версии).

 

До официального рассмотрения документа за него отвечает составитель.

 

3.2 Анализ документа и утверждение

 

Вся документация подвергается официальному рассмотрению согласно [7].

 

При анализе документа открывается так называемая История документа (Document History) [1], которая хранится  в Главном архиве документов (Master Document File) в соответствии с разделом3.6 данной процедуры.

 

После внесения изменений, необходимость которых показал разбор документа, документ переходит в следующую стадию разработки.

 

Подписи согласования, необходимые данному документу или затребованные руководством, ставятся с использованием [3]. Официальные подписи в конце документа ставят два или более ответственных сотрудника.

 

Подписи согласования подтверждают со всей ответственностью, что документ был тщательно изучен лицом, подписавшим его.

 

Дальнейшие изменения вносятся в соответствии с разделом 3.5 данной процедуры.

 

Официально рассмотренная копия черновика документа и отчет о рассмотрении хранится в соответсвии с разделом3.7 данной процедуры.

 

3.3 Выпуск документа

 

Согласованные документы издаются и хранятся в соответствующих папках, как это определено Протоколом хранения документации (Document Review Minutes) [7] или непосредственно руководством.

 

После выпуска документа необходимо:

 

-          Обновить Историю документа [1]

 

-          Обновить индекс документов

 

-          Открыть/обновить Журнал циркуляции документа (Document Circulation Register) [4]

 

-          Создать запись о передаче документа (Document Transmittal Notice) [5] для каждой контролируемой копии

 

-          Написать номер копии на документе

 

Копия записки о передаче документа (Document Transmittal Notices) [5] хранится до тех пор, пока не вернется подписанный оригинал.

 

Вышеупомянутые записи хранятся в Главном архиве документов в соответствии с разделом 3.6 данной процедуры.

 

Замененная документация хранится в Папке архивной документации (Archive Document File) в соответствии с разделом 3.7 данной процедуры.

 

Неконтролируемые копии должны быть четко обозначены пометкой 'UNCONTROLLED' («неконтролируемый»).

 

Изменения в Реестре циркуляции документа [4] должны быть сначала согласованы с руководством. Далее контролируемые копии выпускаются в соответствии с пунктами 3, 4 и 5 выше.

 

3.4 Аннулирование документов

 

Документы могут быть аннулированы только по получении соответствующего заявки на внесение изменений, заверенного подписями согласования. Процедура аннулирования такова:

 

-          Обновить главный индекс (Master Index), присвоив документу статус 'WITHDRAWN' («аннулирован»)

 

-          Обновить Историю документа [1]

 

-          Создать записи о передаче  [5] согласно Журналу распространения документа [4] с указанием всем держателям копий документа уничтожить их.

 

-          Архивизировать документацию в соответствии с разделом 3.7 данной процедуры.

 

3.5 Внесение изменений в документы

Процесс внесения изменений в документы проходит в соответствии с [2]. Документ переходит в следующую стадию разработки и переиздается в соответствии с разделом 3.3. данной процедуры.

 

Внесение значительных изменений или переписывание документа осуществляется следующим образом:

 

-          Перевести документ в разряд черновика (например, Draft 3A)

 

-          Выполнить указания разделов 3.1, 3.2 и 3.3 данной процедуры.

 

3.6 Главный архив документов

 

Необходимо постоянно поддерживать в рабочем состоянии Главный архив документов.

 

Для каждого документа хранятся:

 

-          Оригинал/основной экземпляр документа

 

-          История документа [1].

 

Для официально изданных документов также хранятся:

 

-          Согласование/одобрение документа (Document Approval) [3] или Заявки на внесение изменений (Change Requests) [8]

 

-          Журнал циркуляции документа (Document Circulation Register) [4]

 

-          Запись о передаче документа (Document Transmittal Notices) [5].

 

Также хранится Реестр основных документов, который включает:

 

-          Идентификационный номер документа

 

-          Заголовок документа

 

-          Статус документа.

 

3.7 Папка архивных документов

 

Замененные и аннулированные документы хранятся в отдельной папке с соответствующим названием.

 

Каждый документ должен быть четко обозначен пометками «Заменен»  ('SUPERSEDED') или «Аннулирован» ('WITHDRAWN').

 

Отчеты о рассмотрении документа сохраняются и для черновых документов.

 

Для каждого официально выпущенного документа сохраняются:

 

-          Согласование/одобрение документа (Document Approval) [3] или Заявки на внесение изменений (Change Requests) [8]

 

-          Журнал циркуляции документа (Document Circulation Register) [4]

 

-          Записи о передаче документов (Document Transmittal Notices) [5].

 

Каталог/регистр архивных документов сохраняется с использованием [6].

 

 

4. Ссылки

 

[1 ] Форма 4, ПРИЛОЖЕНИЕ R – История документа (Document History)

 

[2] ПРИЛОЖЕНИЕ F –Процедура контроля за внесением изменений (Procedure for Change Control)

 

[3] Форм 1, ПРИЛОЖЕНИЕ R – Согласование документа (Document Approval)

 

[4] Форм 2, ПРИЛОЖЕНИЕ R – Журнал циркуляции документа (Document Circulation Register)

 

[5] Форм 3, ПРИЛОЖЕНИЕ R – Запись о передаче документа (Document Transmittal Notice)

 

[6] Форм 5, ПРИЛОЖЕНИЕ R – Каталог архивных документов (Archived Document Index)

 

[7] ПРИЛОЖЕНИЕ B –Процедура анализа документации и ПО (Procedure for Document and Software Review)

 

[8] Форм 6, ПРИЛОЖЕНИЕ R – Заявка на внесение изменений (Change Request)

 

ПРИЛОЖЕНИЕ F:

Процедура контроля за внесением изменений

 

Ответственный: Заказчик и Поставщик

1. Введение

 

Данная процедура описывает систему контроля за внесением изменений в автоматизированную систему.

 

Контроль за внесением изменений необходим для того, чтобы придерживаться утвержденных методов работы и продукта.

 

2. Применение

 

Эта процедура применяется к изменениям, вносимым в документацию, в прикладное ПО, ПО операционной системы, во встроенные программы, аппаратные средства и конфигурацию системы, где на это есть ссылки в Плане качества поставщика.

 

Замещение элементов равнозначными, например, в следствие сбоя в работе аппаратных средств, относится к эксплуатации системы и поэтому не подлежит контролю за внесеним изменений, описываемому в данном разделе.

 

3. Процедура

 

3.1. Общие положения

 

Все изменения должны быть санкционированы, задокументированы, протестированы и одобрены до начала их внедрения.

 

Однако, есть исключения:

 

-          Аварийный ремонт

 

-          Изменения, проводимые во время согласованной экспериментальной работы

 

Все изменения, вытекающие из вышеупомянутых случаев, должны быть позднее проанализированы, протестированы, задокументированы и одобрены в соответствии с данной процедурой.

 

3.2. Запрос на внесение изменений

 

Когда есть необходимость внести изменения, в форме Заявки на внесение изменений [1] заполняется раздел Запрос о внесении изменений (REQUEST FOR CHANGE). Каждому запросу на внесение изменений присваивается уникальный номер, который регистрируется с использованием [2].

 

3.3. Санкционирование внесения изменений

 

Для каждой системы назначается менеджер проекта, который и является ответственным за то, чтобы все изменения в систему вносились надлежащим образом. Менеджер проекта может также делегировать данные полномчия.

 

Каждая заявка на внесение изменений рассматривается руководством с вынесением соответствующего распоряжения: принять/отклонить. Обычно это решение не принимается единолично – необходимо, по крайней мере, два человека. Те элементы, которые ранее были одобрены фармацевтической фирмой-заказчиком (например, контрактные документы, протестированное и принятое ПО) могут быть изменены только после согласования с заказчиком.

 

3.3.1. Отклоненные изменения

 

Лица, принявшие решение об отклонении Заявки на внесение изменений, заполняют и подписывают раздел «Санкционирование внесения изменения» (Change Disposition and Authorisation) Заявки, указывая причины для ее отклонения в разделе «Детали изменеия» (Сhange Details).

 

Заявка на внесение изменений должна быть зарегистрирована, Каталог [2] обновлен, а заявитель информирован о принятом решении.

 

3.3.2. Принятые изменения

 

Лица, принявшие решение о принятии Заявки на внесение изменений, заполняют и подписывают раздел «Санкционирование внесения изменения» Заявки. Также они определяют:

 

-          Какие контролируемые элементы подвергаются действию Заявки

 

-          Какие тесты необходимы для того, чтобы убедиться, что рабочие характеристики не изменились.

 

Эти решения записываются в разделе «Детали изменений» Заявки.

 

Если более одного контролируемого элемента будет подвергнуто изменению согласно данной Заявки, Уведомление о внесении изменений (Change Note) [3] составляется для каждого элемента, определяя какие именно изменения будут внесены в каждый элемент.

 

Для сложных работ может потребоваться План внесения изменений, который прилагается к Заявке на внесение изменений, которая в свою очередь должна быть снабжена соответствующей ссылкой.

 

3.4. Завершение процесса внесения изменений и его утверждение

 

Когда все изменения внесены и их тестирование закончено, Заявка на внесение изменений передается руководству для окончательного рассмотрения и утверждения.

 

Заполненная заявка на внесение изменений архивируется, а Каталог [2] обновляется.

 

 

4. Ссылки

 

[1] ПРИЛОЖЕНИЕ R, Форма  6 – Заявка на внесение изменений (Change Request)

 

[2] ПРИЛОЖЕНИЕ R, Форма 12 – Реестр заявок на внесение изменений (Change Request Index)

 

[3] ПРИЛОЖЕНИЕ R, Форма 13 - Уведомление о внесении изменений (Change Note)

ПРИЛОЖЕНИЕ G:

Процедура составления Плана качества и Плана проекта

 

Ответственный: Поставщик

1. Введение

 

Данное приложение описывает процедуру составления Планов качества для индивидуальных проектов.

 

План качества/проекта определяет, как поставщик будет выполнять требования заказчика по качеству, какие работы будет проводиться, их сроки, исполнители, а также механизмы контроля.

 

2. Применение

 

Данная процедура используется для построения Планов качества/Планов проектов для всех проектов поставщика по программированию.

 

3. Процедура

 

3.1. Содержание документа

 

Далее идет описание, какие разделы и подразделы включаются в План качества/План проекта. Все заголовки разделов и подразделов должны обязательно присутствовать. Если раздел не рассматривается, ставится пометка «Не применяется к данному контракту/договору» ('Not applicable to this contract').

 

План качества/План проекта – это контрактный документ и, следовательно, должен быть одобрен менеджером по обеспечению качества изделий поставщика (или представителем), менеджером проекта со стороны поставщика и заказчиком.

 

3.2. Раздел «Введение»

 

Содержит следующую информацию:

 

-          Кто составил документ, на каких полномочиях, с какой целью.

 

-          Контрактный статус документа.

 

-          Связь с GAMP, если есть.

 

-          Связь с Планом валидации, если есть.

 

3.3. Раздел «Общие сведения»

 

Данный раздел вкратце описывает проект.

 

3.4.  Раздел «План качества»

 

Раздел «План качества» определяет мероприятия по валидации, ответственных и порядок осуществления действий.

 

3.4.1. Подраздел «Требования заказчика по качеству»

Требования заказчика по качеству являются приоритетными по отношению к Системе управления качеством поставщика (Quality Management System).

 

Все требования заказчика по качеству перечисляются в данном подразделе, если они отличаются от GAMP. Эти требования должны иметь перекрестные ссылки с соответствующими разделами Pharmaceutical Industry GAMP Supplier Guide.

 

3.4.2. Подраздел «Система качества поставщика»

 

В данном подразделе перечисляются все различия между действующей системой качества поставщика и Pharmaceutical Industry GAMP Supplier Guide.

 

3.5.  Раздел «План проекта»

 

План проекта создается для каждого проекта поставщика.

 

3.6 раздел «Организация проекта» - Project Organisation Section

 

Данный раздел содержит организационную схему, которая показывает:

 

-          Проектная команда поставщика: Персонал и должности. Также указывается контактное лицо поставщика, которому заказчик может предъявлять жалобы.

 

-          Взаимодействие проектной команды поставщика с деятельностью по обеспечению качества изделий внутри организации.

 

-          Объявленные контактные лица заказчика.

 

3.7 Раздел «Поставляемые единицы»

 

Данный раздел определяет все то, что должно быть доставлено, как будут идентифицироваться поставляемые единицы и в какой форме они будут поставлены (например, формат).

 

3.8 Раздел «Деятельность»

 

Данный раздел определяет:

 

-          Работы по проекту, включая оценку проверки и критические разборы программы.

 

-          Персонал, назначенный на данные работы.

 

-          Запланированные даты начала и конца работы по каждому виду работы.

 

Работы по проекту должны быть описаны в виде графика/схемы (например, Gantt Chart). Так как данный раздел подвергается регулярным пересмотрам и обновлениям, его можно включить в основной План качества в качестве приложения.

 

 

4. Ссылки

Ссылок нет.

 

ПРИЛОЖЕНИЕ H:

Процедура составления Функциональной спецификации

 

Ответственный: Поставщик

1. Введение

 

Данная методика описывает стандарт составления Функциональной спецификации.

 

Функциональная спецификация описывает систему, соответствующую нуждам заказчика, определенным в Спецификации требований пользователя. Она определяет, что должна делать система и какие функции и приспособления должны быть представлены. Функциональная спецификация включает перечень целей проектирования/проектных параметров системы.

 

2. Применение

 

Данная процедура применяется для составления Функциональной спецификации, где на это есть ссылки в Плане качества поставщика.

 

3. Процедура

 

3.1. Общие указания

 

Функциональная спецификация определяет, что должна делать система и какие функции и приспособления должны быть представлены. Она включает перечень целей проектирования/проектных параметров системы. Функциональная спецификация контролируется в соответствии с [1].

 

Функциональная спецификация определяет абстрактные компоненты ПО, соответствующие требованиям, изложенным в Спецификации требований пользователя [2].

 

При составлении спецификации необходимо следовать следующим указаниям:

 

-          Все ограничения должны быть подробно оговорены.

-          Не должно быть двусмысленностей, неясностей.

-          Должна использоваться последовательная согласованная система присаивания имен.

 

3.2. Содержание документа

 

Данный раздел определяет, какие разделы включаются в спецификацию. Все разделы должны присутствовать. Если требования по данному разделу не оговариваются, ставится пометка «Не применяется» ('Not applicable').

 

3.2.1 Раздел «Введение»

 

Раздел содержит следующую информацию:

 

-          Кто составил документ, на каком основании и с какой целью

 

-          Контрактный статус документа

 

-          Связь с другими документами.

 

3.2.2 Раздел «Общие сведения»

 

Данный раздел формулирует основные системные функции и интерфейсы с окружающим миром. Он охватывает следующее:

 

-          Ключевые цели и польза от эксплуатации

 

-          Описание на высоком уровне, включающее разделение на главные подсистемы.

 

-          Основные интерфейсы системы с внешним миром

 

-          Допущения. Оговариваются любые допущения в отношении проектирования или внедрения (например, стандартные модули, операционная система, аппаратные средства)

 

-          Любые несоответствия Спецификации требований пользователя. Записываются любые расхождения Функциональной спецификации со Спецификацией требований пользователя.

 

3.2.3 Раздел «Функции»

 

Данный раздел содержит описание на высшем уровне, поделенное на уровни индивидуальных функций. Описывает функции и приспособления, которые будут предоставлены, включая особые режимы работы.

 

Рассматриваются следующие аспекты:

 

-          Требование к функции или приспособлению, детали их использования, включая взаимодействия с другими частями системы. Выделяются критические расчеты и алгоритмы

 

-          Качество функционирования – отклик, правильность и производительность. Данные должны быть представлены количественно и недвусмысленно

 

-          Надежность и безопасность. Данные темы могут включать: действия в случае сбоев в работе данного ПО или аппаратных средств, самоконтроль, подтверждение правильности ввода, избыточность, ограничения доступа, тайм-ауты и восстановление данных

 

-          Конфигурируемые функции и пределы, внутри которых конфигурация  может иметь место.

 

3.2.4        Раздел «Данные»

 

Данный раздел определяет, на каких данных будет работать система. Следующие аспекты должны быть рассмотрены:

 

-          Определение данных. Данные определяются иерархически: сложные объекты строятся из простых (например, файлы записи; сложные типы, описанные в терминах простых типов). Особо оговариваются критические парметры

 

-          Доступ (например, в каких подсистемах необходим доступ для чтения или записи каждой единицы данных, способ доступа, скорость и время обновления, блокировка чтения/записи)

 

-          Емкость данных, время хранения и детали архивирования данных.

 

3.2.5 Раздел «Интерфейсы»

 

Данный раздел описывает все интерфейсы системы и содержит следующие подразделы:

 

-          Интерфейс с пользователями – описываются для каждой роли (например,  оператор, администратор склада, менеджер системы и т.д.). Темы для рассмотрения включают: имеющееся оборудование,  типы переферийных устройств, общий формат отображения данных и отчетов.

 

-          Интерфейс с другими системами. Темы для рассмотрения включают: данные передаваемые и получаемые, скорость передачи, протокол данных, защита интерфейса

 

-          Интерфейс с оборудованием (например, сенсоры/приводы). Темы для рассмотрения включают: данные передаваемые/получаемые, формат, валидация и проверка ошибок.

 

3.2.6 Раздел «Нефункциональные характеристики»

 

Раздел определяет, как система будет выполнять нефункциональные требования. Содержит следующие подразделы:

 

-          Возможность использования / работоспособность (например, надежность, резервирование, проверка ошибок, работа в режиме простоя/ожидания)

 

-          Эксплутационная надежность / ремонтопригодность (например, расширение и совершенствование возможностей, резервная мощность, возможные изменения условий эксплатации, срок службы).

 

3.2.7 Раздел «Глоссарий»

 

Данный раздел содержит расшифровку тех терминов, которые могут быть незнакомы людям, читающим данную Функциональную спецификацию.

 

3.2.8 Приложения

 

При необходимости (например, небольшие системы) могут быть представлены приложения, содержащие спецификации аппаратных средств и ПО.

 

 

4. Ссылки

 

[1 ] ПРИЛОЖЕНИЕ E - Составление, контроль и выпуск документации

 

[2] ПРИЛОЖЕНИЕ A – Составление Спецификации требований пользователя

 

ПРИЛОЖЕНИЕ I:

Процедура составления Спецификации разработки аппаратных средств

 

Ответственный: Поставщик

1. Введение

 

Здесь дается порядок составления Спецификации разработки аппаратных средств, которая вытекает из Функциональной спецификации. Спецификация разработки аппаратных средств описывает аппаратные средства, которые составят систему, и их взаимодействие с другими аппаратными системами.

 

2. Применение

 

Данная процедура применяется при составлении Спецификации разработки аппаратных средств, где на это есть ссылки в Плане качества поставщика.

 

3. Процедура

 

3.1. Общие указания

 

Рекомендуется снабдить Спецификацию разработки аппаратных средств диаграммами. Если такие диаграмы представлены где-либо еще, то они должны иметь перекрестные ссылки в Спецификации.

 

3.2. Содержание документа

 

Здесь определяется, какие разделы должны быть включены в спецификацию. Все заглавия разделов должны присутствовать. Если раздел не применяется при проектировании, ставится пометка «Не применяется» ('Not applicable').

 

3.2.1. Раздел «Введение»

 

Раздел содержит следующую информацию:

 

-          Кто составил документ, на каком основании и с какой целью.

 

-          Связь с другими документами.

 

3.2.2. Раздел «Общие сведения»

 

Раздел кратко описывает проект, который детализируется в документе. Он скорее служит введением к проекту и не содержит детальной информации. Раздел описывает конфигурацию системы аппаратных средств и ее взаимодействие с окружающей средой. Все это должно быть проиллюстрировано диаграмами.

 

3.2.3. Раздел «Компьютерная система»

 

Раздел описывает полную конфигурацию системы аппаратных средств. Она должна быть проиллюстрирована структурной схемой с объяснениями. Следующие подразделы должны быть включены:

 

-          Подраздел «Главная компьютерная система»

 

Описывает составные элементы главной компьютерной системы (систем), такие как центральный процессор, память, тип шины, точность часов и т.д.

 

-          Подраздел «Хранение информации»

 

Описывает все преполагаемые устройства для хранения информации с указанием их максимальных возможностей, например, жесткий диск, дискета, лента.

 

-          Подраздел « Периферийные устройства»

 

Описывает поставляемые периферийные устройства. Любые особые корпусы и/или особенности сборки должны быть оговорены.

 

-          Подраздел «Межкомпонентные соединения»

 

Описывает все межсоединения компонетов внутри компьютера и все соединения с другим оборудованием. Обязательно включить:

 

Спецификации по кабелям

Спецификации по коннекторам/соединителям/разъемам

Требования к экранированию

Регламент схем

Сетевые/внешние соединения

 

3.2.4.Раздел «Вход/Выход»

 

При необходимости оговариваются инструменты входа и выхода. Они могут включать:

 

Вход цифровых данных

Выход цифровых данных

Аналоговый вход

Аналоговый выход

Счетчики импульсов.

 

Для каждого инструмента или групы инструментов описываются следующие элементы:

 

-          Точность

-          Автономность

-          Сила тока и вольтаж

-          Тип и номера интерфейсных плат

-          Согласование по времени.

 

3.2.5. Раздел «Условия эксплутации»

Описывает рабочую среду, включая:

 

-          Температура

-          Влажность

-          Вмешательства извне

-          Физическая защита

-          Радиочастотные, электромагнитные и UV помехи

 

3.2.6. Раздел «Электропитание»

Здесь оговариваются требования по электропитанию к конфигурируемой аппаратной системы.

 

Берутся во внимание следующие элементы:

 

-          Фильтрация

-          Нагрузка

-          Заземление

-          Система бесперебойного электропитания (УПС)

 

3.2.7. Раздел «Глоссарий»

 

Раздел содержит расшифровку терминов, которые могут быть незнакомы людям, читающим Спецификацию.

 

3.3. Встроенные системы

 

В разделы, где Спецификация разработки аппаратных средств оговаривает встроенные системы, должна быть включена следующая информация:

 

-          Компоновочные схемы для детализации контрольной панели и внутренних/внешних устройств.

-          Схемы размещения сенсоров и других устройств, установленных на машину.

-          Перечень всех компонентов, составляющих систему контроля.

-          Схемы электропроводки.

-          Ссылки на любые внешние стандарты заказчика, которых будут придерживаться, например, IEC204 International Standard for Electrical Equipment on Industrial Machines (Международный стандарт для электрооборудования на промышленных машинах).

 

 

4. Ссылки

 

Сылок нет.

 

ПРИЛОЖЕНИЕ J:

Процедура составления Спецификации разработки ПО -

 

Ответственный: Поставщик

1. Введение

 

Процедура описывает стандарты составления Спецификации разработки ПО, которая вытекает из Функциональной спецификации. В ней описываются подсистемы ПО, которые составят систему ПО, и взаимосвязи между этими подсистемами.

 

2. Применение

 

Процедура применяется при составлении Спецификации разработки ПО, где на это есть ссылки в  Плане качества поставщика.

 

3. Процедура

 

3.1. Общие указания

 

Можно использовать стандартную методологию проектирования, например, Yourdon или PRISM. В этих случаях возможно изменить данное приложение, снабдив соответсвующими пояснениями.

 

Все системные данные можно описывать отдельно (например, в Словаре данных). Этот факт должен быть отражен в Разделе 3.2.4.

 

Также можно создать и более одной Спецификации разработки ПО на базе одной Функциональной спецификации. На каждую из них должны быть соответствующие ссылки так, чтобы каждую можно было связать с соответствующей функцией (функциями), описанными в Функциональной спецификации.

 

Составлять графики системы, системных файлов и других структур данных не обязательно, но рекомендуется. Елси такие графики уже представлены в других документах, на это должны быть ссылки в Спецификации разработки ПО.

 

3.2.   Содержание документа

 

Раздел определяет, какие разделы должны быть включены в спецификацию. Все разделы должны присутствовать. Если какой-либо из разделов не применяется при разработке, должна стоять пометка «Не применяется» ('Not applicable').

 

3.2.1. Раздел «Введение»

 

Раздел содержит следующую информацию:

 

-          Кто составил документ, на каком основании и с какой целью.

-          Связь с другими документами.

 

3.2.2. Раздел “Общие сведения”

 

Раздел кратко описывает проект, представленный более детально в других документах. Скорее служит введением к проекту, чем содержит какую-либо детальную информацию. Он должен показать, как какие подсистемы составляют целую систем, то есть детализировать уровни программирования. Все это может быть проиллюстрировано с помощью графиков.

 

3.2.3. System Description section

 

Раздел описывает подсистемы (модули), которые будут составлять систему, четко определяя цель каждой из них. Дается также перечень всех взаимодействий между модулями и другими внешними системами. Каждый интерфейс должен быть оправдан. Можно включить системный график и дать описание согласования по времени  или расписанию работы подсистем.

 

3.2.4. Раздел “Системные данные”

 

Раздел определяет системные данные и определяет основные объекты данных. Данные описываются иерархически, сложные объекты разделяются на более простые. Объекты могут включать следующее:

 

-          Базы данных и совокупности файлов

-          Файлы

-          Записи

-          Типы данных

 

Каждый файл и структура данных должны быть определены однозначно. Вышесказанное не исключает использование моделей Сущность-Связь и тому подобного.

 

3.2.5. Раздел «Описание модулей»

 

Каждый модуль описывается в таких аспектах:

 

-          Работа модуля (возможно в виде псевдокода).

 

-          Интерфесы с другими модулями. Можно ограничиться ссылкой на системную диаграмму, если таковая была представлена.

 

-          Любые ососбые факторы согласования по времени модуля, не представленные в описании системы.

 

-          Обработка ошибок и проверка корректности данных.

 

3.2.6. Раздел «Данные модуля»

 

Раздел определяет, с какими системными данными (описанными в Разделе 3.2.4) работает каждый модуль.

 

3.2.7. Раздел «Глоссарий»

 

Раздел содержит расшифровки терминов, которые могут быть не знакомы читающему Спецификацию.

 

3.3. Встроенные системы

 

Там где Software Design Specification говорит о встроенных системах, следующая информация должна быть включена в соответствующие разделы:

 

-          Блок-схема, или любая другая форма презентации, того, как достигается каждая функция отдельной машины (включая генерирование аварийного сигнала/предупреждения и стратегии восстановления после аварийного сигнала).

-          Детальное описние используемых алгоритмов.

 

-          Каталог всех сообщений.

 

-          Схематическое описание всех экранов дисплея.

 

 

4. Ссылки

 

Ссылок нет.

 

ПРИЛОЖЕНИЕ K:

Процедура составления Спецификаци по проектированию модулей ПО

 

Ответственный: Поставщик

1. Введение

 

Данное приложение описывает процедуру составления Спецификации по проектированию модулей ПО, которая определяет работу модулей ПО и вытекает из Спецификации разработки ПО (Software Design Specification). Спецификация должна описывать работу модулей четко, точно и однозначно. Спецификация по проектированию модулей ПО используется программистами в качестве основы для написания кода программы.

 

2. Применение

 

Данная процедура применяется к составлению всех Спецификаций по проектированию модулей ПО, составляемых поставщиком. Если спецификация выполнена без согласования с этой процедурой, причина  такого решения должна бьть записана в Плане обеспечения качества данного проекта.

 

3. Процедура

 

3.1. Общие указания

 

-          Возможно также использование любой стандартной методологоии программирования, например, Yourdon или JSD. В этом случае возможно перестроить документ, но обязательно оговорить это в Плане обспечения качества проекта (Плане проекта).

-          Также возможно описывать все системные данные отдельно (например, в Словаре данных), и тогда этот факт должен быть отражен в Разделе 3.2.3.

-          Составлять графики модулей ПО (software module overview) и структур данных модулей  не обязательно. Но если таковые были составлены, они должны иметь перекрестные ссылки со Спецификацией по проектированию модулей ПО.

 

3.2. Содержание документа

 

Данный раздел определяет, какие разделы должны быть включены в Спецификацию разработки ПО. Все разделы должны пристуствовать. Если раздел не применяется при проетировании, должна стоять пометкая «Не применяется» ('Not Applicable').

 

3.2.1. Раздел “Введение”

 

Раздел содержит следующую информацию:

 

-          Кто составил документ, на каком основании и с какой целью

 

-          Связь с другими документами.

 

3.2.2. Раздел “Обзор модулей ПО

 

Раздел кратко описывает проект ПО, детализированный в остальных документах. Он служит, скорее, введением, чем дает детальную информацию.  Он показывает, как программный модуль разбивается на подпрограммы. Информация может быть проиллюстрирована с помощью графиков.

 

3.2.3. Раздел «ПО данные модуля»

 

Раздел описывает данные модулей и определяет основные объекты данных. Данные описываются иерархически, сложные объекты разбиваются на более простые. Объекты могут включать:

 

-          Базы данных и собрания файлов.

-          Файлы.

-          Записи.

-          Типы данных.

 

Все структуры файлов и данных должны быть определены однозначно. Вышеизложенные указания не исключают использование моделей сущность-Связь или др.

 

3.2.4. Раздел «Описание подпрограмм»

 

Для каждой подпрограммы модуля раскрывается следующее:

 

-          Действие подпрограммы (возможно в виде псевдо-кода).

 

-          Параметры. Каждый параметр должен быть определен как:

 

a) входной параметр

 

b) выходной параметр

 

c) входной и выходной параметр

 

-          И в дополнение параметр должен быть определен как:

 

a) передаваемый значением.

 

b) передаваемый ссылкой.

 

-          Любые побочные эффекты подпрограммы.

 

-          Язык (включая версию).

 

-          Ссылки на любые стандарты программирования.

 

3.2.5. Раздел «Данные подпрограммы»

 

Раздел описывает любые объявленные локально данные.

 

3.2.6. Раздел “Глоссарий”

 

Раздел включает полную расшифровку всех используемых акронимов и терминов.

 

 

3.3. Встроенные системы

 

Там где Спецификаия по проектированию модулей ПО говорит о встроенных системах, следующая информация должна быть включена в соответствующие разделы:

 

-          Блок-схема, или любая другая форма презентации, того, как достигается каждая функция отдельной машины (включая генерирование аварийного сигнала/предупреждения и стратегии восстановления после аварийного сигнала).

 

-          Детальное описние используемых алгоритмов.

 

-          Каталог всех сообщений.

 

-          Схематическое описание всех экранов дисплея.

 

 

4. Ссылки

 

Ссылок нет.

 

ПРИЛОЖЕНИЕ L:

Процедура составления Спецификации тестирования модулей ПО

 

Ответственный: Поставщик

1. Введение

 

Данное приложение определяет содержание всех Спецификаций тестирования модулей ПО поставщика.

 

Спецификация тестирования модулей ПО определяет, какие тесты будут проводиться для проверки правильности работы модуля (т.е. в соответсвии со Спецификацией проектирования модулей ПО).

 

2. Применение

 

Данная процедура применяется только к Спецификациям тестирования модулей ПО, составляемым внутри организации Поставщика. Если Спецификация тестирования модулей данного проекта не соответсвует данной процедуре, причина должна быть пояснена в Плане обеспечения качества данного проекта.

 

3. Процедура

 

3.1. Общие указания

 

При составлении Спецификации нужно помнить, что каждый тест должен быть однозначным, должно быть четко ясно, какие составляющие прошли тест, а какие нет.

 

3.2. Содержание документа

 

Раздел определяет, какие разделы и подразделы включаются в спецификацию. Все заголовки должны присутствовать. Если раздел/подраздел не нужен, ставится пометка «Не применяется» ('Not Applicable').

 

3.2.1. Раздел “Введение”

 

Раздел содержит следующую информацию:

 

-          Кто составил документ, на каком основании и с какой целью.

 

-          Связь с другими документами.

 

3.2.2. Раздел «План проверок и тестов» 

 

Раздел представляет подход к тестированию в целом и структуру спецификации. Необходимо остановиться на следующем:

 

-          использование, или неиспользование, приложения N [1] в качестве методики тестирования. Если [1] не используется, то описывается выбранный альтернативный метод.

 

-          особые нетестируемые области, почему.

 

-          любое логическое группирование или упорядочение тестов.

 

-          формат тестовых ссылок.

 

-          персонал, необходимый для каждого теста или группы тестов.

 

3.2.3. Раздел «Условия тестирования»

 

Раздел определяет, что необходимо для проведения тестирования. Затрагиваются следующие аспекты:

 

-          Требования к аппаратным средствам.

 

-          Требования к ПО, а именно:

 

a) Конфигурация ПО (например, операционная система, драйверы, утилиты,

файлы/базы данных)

 

b) ПО для тестирования.

 

c) тестовые данные.

 

-          Требования по документации.

 

3.2.4. Раздел «Процедура тестирования»

 

Раздел рассматривает детали тестов. Каждый тест готовится в соответствии с [1]. Ппроцедура/методика каждого теста должна начинаться с новой страницы и иметь перекрестные ссылки со Спецификацией проектирования модулей ПО.

 

3.2.5. Раздел “Глоссарий”

 

Раздел дает расшифровку все специальным терминам, используемым в Спецификации. Сюда включаются также общеупотребляемые слова, используемые в необычном значении.

 

3.3. Результаты тестов

 

Результаты тестов хранятся в сответствии с [1].

 

 

4. Ссылки

 

[1 ] ПРИЛОЖЕНИЕ N – Тестирование автоматизированных систем

 

ПРИЛОЖЕНИЕ M:

Процедура составления Спецификации тестирования компоновки системы ПО

 

Ответственный: Поставщик

1. Введение

 

Данное приложение определяет содержание Спецификации тестирования компоновки системы ПО Поставщика.

 

Спецификация тестирования компоновки системы ПО описывает тесты, которые будут проводиться для проверки правильности взаимодействия всех модулей системы, составляющих целое (в соответсвии со Спецификацией разработки ПО).

 

2. Применение

 

Данной процедуры придерживаются только при составлении Спецификации тестирования компоновки системы ПО внутри организации Поставщика. Если данная спецификация не согласуется с данной процедурой, причина должна быть пояснена в Плане обеспечения качества данного проекта.

 

3. Процедура

 

3.1. Общие указания

 

При составлении Спецификации нужно помнить, что каждый тест должен быть однозначным, должно быть четко ясно, какие составляющие прошли тест, а какие нет.

 

3.2. Содержание документа

 

Раздел определяет, какие разделы и подразделы включаются в спецификацию. Все заголовки должны присутствовать. Если раздел/подраздел не нужен, ставится пометка «Не применяется» ('Not Applicable').

 

3.2.1. Раздел “Введение”

 

Раздел содержит следующую информацию:

 

-          Кто составил документ, на каком основании и с какой целью.

 

-          Связь с другими документами.

 

3.2.2. Раздел «План проверок и тестов»

 

Раздел представляет подход к тестированию в целом и структуру спецификации. Необходимо остановиться на следующем:

 

-          использование, или неиспользование, приложения N [1] в качестве методики тестирования. Если [1] не используется, то описывается выбранный альтернативный метод.

 

-          особые нетестируемые области, почему.

 

-          любое логическое группирование или упорядочение тестов.

 

-          формат тестовых ссылок.

 

-          персонал, необходимый для каждого теста или группы тестов.

 

3.2.3. Раздел «Условия тестирования»

Раздел определяет, что необходимо для проведения тестирования. Затрагиваются следующие аспекты:

 

-          Требования к аппаратным средствам

-          Требования к тестовому ПО

-          Требования к тестовым данным

-          Справочные документы

 

3.2.4. Раздел «Процедура тестирования»

 

Раздел описывает детали тестов. Каждый тест готовится в соответствии с [1]. Процедура/методика каждого теста должна начинаться с новой страницы и иметь перекрестные ссылки со Спецификацией проектирования модулей ПО.

 

3.2.5. Раздел “Глоссарий”

 

Раздел разъясняет все специальные термины, встречающиеся в Спецификации. Сюда включаются также общеупотребляемые слова, используемые в необычном значении.

 

3.3. Результаты тестов

 

Результаты тестов хранятся в сответствии с [1].

 

 

4. Ссылки

 

[1 ] ПРИЛОЖЕНИЕ N - Тестирование автоматизированных систем

 

 

 

ПРИЛОЖЕНИЕ N:

Процедура тестирования автматизированных систем

 

Ответственный: Заказчик и Поставщик

1. Введение

 

Данная процедура раскрывает формальную систему тестирования компьютерной системы или другой единицы оборудования, контролируемуемой компьютером /PLC (т.е. автоматизированной системы). Здесь представлены тесты, которые документированно показывают, что система работает так, как было оговорено.

 

Спецификации тестирования могут быть нескольких типов:

 

-          Спецификация тестирования модулей ПО (Software Module Test Specification) [6] тестирует отдельные компоненты ПО на предмет их соответствия спецификации по разработке.

 

-          Спецификация тестирования компоновки ПО (Software Integration Test Specification) [7] тестирует компоненты ПО после их объединения.

 

-          Спецификация приемочного тестирования аппаратных средств (Hardware Acceptance Test Specification) [8] определяет тестирование установки компьютера и любых других входных/выходных устройств.

 

-          Спецификация приемочного тестирования системы (System Acceptance Test Specification) [9] определяет функциональную систему тестирования всей системы или оборудования, включая их эксплуатацию.

 

Для каждого типа спецификации метод тестирования будет таким, как указано в данной процедуре.

 

2. Применение

 

Данная процедура применяется для любого тестирования автоматизированных систем, на которые ссылаются в Плане качества поставщика.

 

3. Процедура

 

Процедура включает 4 этапа:

 

-          Определение всего необходимого для начала тестирования.

 

-          Определение стратегии теста, включая назначение ответсвенных за выполнение, заверение и согласование процуедуры теста.

 

-          Определение формата тестовых процедур, таких, какие действительно покажут, что система соответствует спецификациям.

 

-          Определение метода, которого следует придерживаться в ходе проведения тестов, включая:

a. Определение метода оценки и утверждения результатов теста.

б. Определение критериев для последующего ре-тестирования, основывающегося на неудачах тестирования, некорректных процедурах или изменениях в системе.

 

3.1. Необходимое для начала тестирования

 

До начала тестирования, должны быть выполнены и представлены все соответствующие документы, определенные Планом качества. Также должны быть представлены согласованные спецификации тестирования и любые другие процедуры, необходимые для работы системы.

 

Все критические входные устройства и тестовое обрудование должны быть проверены с составлением соответсьтвующих документов.

 

Оборудование для проверки должно быть сертифицировано, соответствовать национальным стандартам и заранее заявлено.

 

3.2. Стратегия тестирования

 

Сотрудника, ответственные за составление, проверку, утверждение и подписание тестовой спецификации, определяются в Плане качества.

 

Каждый тест проводится тестировщиком и в присутствии наблюдателя. Тестировщики и наблюдатели согласовываются менеджерами заказчика и поставщика. Тесты подписываются совместно тестировщиком и наблюдателем. Обычно все тесты, кроме теста приемки, выполняются тестировщиками и наблюдателями со стороны поставщика.

 

3.3. Формат тестовых процедур

 

Формат тестовых процедур, где возможно, должен быть таким:

Уникальный указатель (номер) теста

Ссылка на руководящую спецификацию (номер)

Название теста

Необходимое для начала теста

Описание теста

Критерии успешного прохождения теста

Данные для регистрации

Дальнейшие действия

Ожидаемые результаты

 

3.3.1. Указатель (номер) теста

 

Уникальный указатель (номер), присваемый каждому тесту, формат которого определяется в Тестовой спецификации.

 

3.3.2. Ссылка на руководящую спецификацию

 

Ссылка на документ и раздел, в котором даются требования к тесту, например, Спецификация требований пользователя или Функциональная спецификация.

 

3.3.3. Название теста

 

Описательное название теста.

 

3.3.4. Необходимое для начала теста

 

Все необходимое для начала тестирование. Сюда включается тестовое оборудование, документация, ресурсы, данные, сервисные программы и т.д.

 

3.3.5. Описание теста

 

Пошаговое описание действий тестировщиков.

 

3.3.6. Критерии успешного прохождения теста

 

Определяется совокупность ожидаемых результатов, которые должны быть достигнуты при успешном тестировании.

 

3.3.7. Данные для регистрации

 

Описание специальных тестовых данных, которые должны быть собраны и зарегистрированы  (приложены) в Ведомости результатов теста (Test Results Sheet) [1]. Это могут быть входные, выходные или описательные данные. Обязательно включаются серийные номера всего используемого тестового оборудования и подтверждающие сертификаты поверки (calibration certificates), где это необходимо.

 

3.3.8. Дальнейшие действия

 

Этот раздел не обязателен. Он детально описывает действия, необходимые для подготовки следующей процедуры тестирования. Примерами являются параметры процесса сброса системы в исходное состояние или перезагрузка системы.

 

3.4 Выполнение процедуры тестирования

 

Тесты проводятся следующим образом:

 

1. Каждый тест должен быть проведен и данные собраны (приложены) в Ведомость результатов теста [1], одна или более страниц на каждый тест.

 

2. Тестировщик и наблюдатель решают, были ли достигнуты критерии принятия теста, т.е. успешно ли пройден тест. Ведомость результатов теста [1] четко определяет, ПРОЙДЕН ли тест или успех НЕ ДОСТИГНУТ. Они подписывают Ведомость результатов теста только, если тест пройден (см. ниже пункт 5, если тест провалился).

 

3. Ассоциированные необработанные данные, описанные в тестовой спецификации, подписываются тестировщиком на каждой странице и отмечаются ссылкой на тест (номер теста). Все необработанные данные прилагаются к Ведомости результатов теста [1], который в свою очередь подшивается в папку результатов (Test Results File) в соответствии с Разделом 3.5 данной процедуры.

 

4. Тестировщик обновляет Ведомость хода тестирования (Test Progress Sheet) [3], которая хранится в соотвествии с Разделом 3.5 данной процедуры. В данной ведомости ставится отметка о прохождении или непрохождении теста. Также отмечается, сколько раз проводился каждый тест.

 

5. Если тест не пройден, выполняются этапы 1-4, но тестировщик и наблюдатель не подписывают [1]. Данные о непройденных тестах хранятся в секции «Непройденные тесты» (Failed Test) в папке результатов теста в соответствии с Разделом 3.5 данной процедуры, для дальнейшего просмотра.

 

6. Ведомости сбоев при тестировании (Test Incident Sheets) [2] сохраняются как составная часть записей по тестированию системы.

 

Сбой определяется как крупное неожиданное событие, например, полный отказ системы или сбой, который остановил тестовую программу. Такое событие регистрируется в Ведомость сбоев при тестировании [2] и в соответствии с Разделом 3.5 данной процедуры подшивается вместе со всеми необработанными данными для дальнейшего разрешения проблемы.

 

7. После завершения всех тестов или группы тестов (например, в конце дня) проводится разбор достигнутых результатов, и проверяющие лица оценивают все непройденные тесты в соответсвующем разделе в папке результатов теста.

 

Возможны три варианта дальнейших действий:

 

-          Повторить тест

-          Что-то изменить через  процедуру контроля за внесением изменений и повторить тест

-          Отказаться от одного, нескольких или всех тестов.

 

Группа проверки решает, какие действия предпринять и, в случае необходиомсти изменений, определяет объем повторного тестирования, необходимого после внесения изменений. Ход проверки регистрируется в отчете о проверке [4].

 

Проблемы, обнаруженные в ходе тестирования и требующие изменений в системе, обрабатываются в соответствии с процедурой Контроля изменений [5].

 

3.5. Папка «Результаты теста»

 

Все тестовые результаты хранятся в четко маркированной папке «Результаты теста». Эта папка включает следующие секции:

Раздел «Ход теста» (Test Progress)

Раздел «Пройденные тесты» (Passed Tests)

Раздел «Непройденные тесты» (Failed Tests)

Раздел «Инциденты при проведении теста» (Test Incidents) (с нумерацией)

Раздел «Отчеты о проверках» (Review Reports) (с нумерацией)

 

Для каждого теста хранится:

-          Рабочия копия процедуры тестирования, четко обозначенная как таковая

-          Ведомость (ведомости)  результатов теста

-          Ассоциированные необработанные данные.

 

4. Ссылки

[1 ] Форма 7 - Ведомость результатов теста (Test Results Sheet)

[2] Форма 8 – Ведомость сбоев при тестировании (Test Incident Sheet)

[3] Форма 1 1 – Ведомомсть хода тестирования (Test Progress Sheet)

[4] Форма 9 – Отчет о проверке (Review Report)

[5] ПРИЛОЖЕНИЕ F – Контроль за внесением изменений

[6] ПРИЛОЖЕНИЕ L – Спецификация тестирования модулей ПО (Software Module Test Specification)

[7] ПРИЛОЖЕНИЕ M – Спецификация тестирования компоновки ПО (Software Integration Test Specification)

[8] ПРИЛОЖЕНИЕ 0 – Спецификация приемочного тестирования аппаратных средств (Hardware Acceptance Test Specification)

[9] ПРИЛОЖЕНИЕ P – Спецификация приемочного тестирования системы (System Acceptance Test Specification)
ПРИЛОЖЕНИЕ 0:

Процедура составления Спецификации приемочного тестирования аппаратных средств

 

Ответственный: Поставщик

1. Введение

 

Данная процедура описывает стандарты составления Спецификация приемочного тестирования аппаратных средств.

 

Данная спецификация определяет, какие тесты должны быть проведены для подтверждения корректной работы системы в соответствии со Спецификацией проектирования аппаратных средств (Hardware Design Specification).

 

Спецификация приемочного тестирования аппаратных средств может состоять из двух частей:

 

-          Тесты, показывающие, что система работает достаточно хорошо, чтобы быть проинсталлированной и протестированной на месте. Они называются рабочими тестами Поставщика.

 

-          Тесты, показывающие, что система работает корректно в своей операционной среде. Они называются тестами заказчика на месте установки.

 

В этом случае можно составить 2 документа:

 

-          Спецификация рабочего приемочного тестирования аппаратных средств (Factory Hardware Acceptance Test Specification) – составляется поставщиком.

 

-          Спецификация приемочного тестирования аппаратных средств на месте установки (Site Hardware Acceptance Test Specification) – составляется заказчиком.

 

Для уже работающих систем применяется только пункт 2 (тесты на месте установки, проводимые заказчиком).

 

2. Применение

 

Данная процедура применяется при составлении Спецификаций приемочного тестирования аппаратных средств, где указано Планом качества Поставщика [1].

 

3. Процедура

 

3.1. Общие указания

 

При составлении спецификации следуйте указаниям:

 

-          Каждый тест должен быть однозначным. Должно быть ясно, какие составляющие прошли тестирование, а какие нет.

 

-          Спецификация должна быть понятна заказчику, поэтому следует избегать жаргона.

 

3.2. Содержание документа

 

Раздел определяет, какие разделы и подразделы должны быть включены в спецификацию. Все заголовки разделов и подразделов должны присутствовать. Если раздел или подраздел не используется, ставится пометка “Не применяется” (‘Not Applicable’).

 

3.2.1. Раздел “Введение”

 

Раздел содержит следующую информацию:

 

-          Кто составил документ, на каком основании и с какой целью

 

-          Контрактный статус документа

 

-          Связь с другими документами.

 

3.2.2. Раздел «Применение»

 

Раздел определяет границы использования квалификационной программы. При подготовке Спецификации приемочного тестирования аппаратных средств рассматриваются следующие аспекты:

 

Визуальная проверка аппаратных средств на предмет соотвествия проекту

Тестирование связности входа/выхода

Тестирование конца цикла точности и размаха выборки range testing (минимум 2 известные величины)

Контрольное тестирование версии ПО

Тестирование точности компьютерных часов

Тестирование электропитания и помех

Диагностическое тестирование производителя

Тестирования включения/отключения питания

 

Операционная среда

 

3.2.3. Раздел «План проверок и тестов»

 

Раздел представляет подход к тестированию в целом и структуру спецификации. Необходимо остановиться на следующем:

 

-          использование, или неиспользование, [2] в качестве методики тестирования. Если [2] не используется, то описывается выбранный альтернативный метод

 

-          особые нетестируемые области, почему

 

-          любое логическое группирование или упорядочение тестов

 

-          формат нумерации тестов

-          Персонал, необходимый для каждого теста или группы тестов.

 

3.2.4. Раздел «Условия тестирования»

 

Раздел определяет, что необходимо для проведения тестирования. Затрагиваются следующие аспекты:

 

Требования к аппаратным средствам.

Требования к тестовому оборудованию (калиброванные и некалиброванные).

Требования к тестовому ПО.

Требования к тестовым данным.

 

Справочные документы

 

3.2.5. Раздел «Процедура теста»

 

Раздел содержит детали тестов. Каждый тест готовится в соответствии с [2].

 

Процедура каждого теста должна быть дана на отдельной странице и иметь перекрестные ссылки со Спецификацией проектирования аппаратных средств.

 

3.2.6. Раздел “Глоссарий”

 

Раздел включает расшифровки терминов, которые могут быть незнакомы читающему Спецификацию.

 

3.3. Результаты теста

 

Результаты тестов хранятся в соотвествии с [2].

 

 

4. Ссылки

 

[1 ] ПРИЛОЖЕНИЕ G – Составление Плана качества и Плана проекта

 

[2] ПРИЛОЖЕНИЕ N – Тестирование автоматизированной системы

 

ПРИЛОЖЕНИЕ P:

Процедура составления Спецификации приемочного теста системы

 

Ответственный: Поставщик

1. Введение

 

Процедура  описывает стандарт для составления Спецификации приемочного теста системы.

 

Данная спецификация определяет, какие тесты должны быть проведены для подтверждения корректной работы системы в соответствии с Функциональной спецификацией. Обычно рассматриваются следующие аспекты:

 

-          Функциональность системы

 

-          Характеристика системы

 

-          Критические параметры

 

-          Способы эксплуатации

 

Спецификация приемочного теста системы может состоять из двух частей:

 

-          Тесты функций и устройств, которые могут быть протестированы вне операционной среды системы с помощью тестовых аппаратных средств и ПО. Они называются рабочими тестами Поставщика

 

 

-          Тесты, показывающие, что система работает корректно в своей операционной среде и правильно взаимодействует с другими системами и оборудованием. Они называются тестами заказчика на месте установки.

 

В этом случае можно составить 2 документа:

 

1. Спецификация рабочего приемочного теста системы (Factory System Acceptance Test Specification) – составляется поставщиком

2. Спецификация приемочного теста системы на месте установки (Site System Acceptance Test Specification) – составляется заказчиком.

 

Для уже работающих систем применяется только пункт 2 (тесты на месте установки, проводимые заказчиком).

 

2. Применение

 

Данная процедура применяется при составлении спецификаций примочных тестов системы, где указано Планом качества поставщика [1].

 

3. Процедура

 

3.1. Общие указания

 

При составлении спецификации следуйте инструкциям:

 

-          Каждый тест должен быть однозначным. Должно быть ясно, какие составляющие прошли тестирование, а какие нет.

 

-          Спецификация приемочного теста системы должна быть понятна заказчику, поэтому следует избегать жаргона.

 

3.2. Содержание документа

 

Раздел определяет, какие разделы и подразделы должны быть включены в спецификацию. Все заголовки разделов и подразделов должны присутствовать. Если раздел или подраздел не используется, ставится пометка «Не применяется» ('Not Applicable').

 

3.2.1. Раздел “Введение”

 

Раздел содержит следующую информацию:

 

-          Кто составил документ, на каком основании и с какой целью

 

-          Контрактный статус документа

 

-          Связь с другими документами

 

3.2.2. Раздел «Применение»

 

Раздел определяет границы использования квалификационной программы. При составлении спецификации приемочного теста системы учитываются следующие аспекты:

 

Тестирование прикладного ПО на соотвествие соответсвующей контрольной спецификации

Тестирование аварийного сигнала

Тестирование отображения данных на экран и отчетов (интерфейсы)

Тестирование критических требований, включая функции, данные  и интерфейсы

Тестирование процедур запуска и выключения

Тестирование процедур резервного копирования и восстановления

Тестирование процедур защиты и доступа

 

Тестирование плана на случай чрезвычайных обстоятельств

 

3.2.3. Раздел «План проверок и тестов»

 

Раздел представляет подход к тестированию в целом и структуру спецификации. Необходимо остановиться на следующем:

 

-          использование, или неиспользование, приложения № [2] в качестве методики тестирования. Если [2] не используется, то описывается выбранный альтернативный метод

 

-          Особые нетестируемые области, почему

 

-          Любое логическое группирование или упорядочение тестов

 

-          Формат нумерации тестов

 

-          Персонал, необходимый для каждого теста или группы тестов.

 

3.2.4. Раздел «Условия тестирования»

 

Раздел определяет, что должно быть представлено к началу тестирования. Должны быть отмечены следующие аспекты:

 

-          Требования к аппаратным средствам

 

-          Требования к тестовому ПО

 

-          Требования к тестовым данным

 

-          Справочные документы

 

3.2.5. Раздел «Процедура теста»

 

Раздел содержит детали тестов. Каждый тест готовится в соответствии с [2].

 

Каждая процедура тестирования должна быть на отдельной странице и иметь перекрестный ссылки с Функциональной спецификацией.

 

3.2.6. Раздел “Глоссарий”

 

Раздел содержит расшифровки терминов, которые могут быть незнакомы читающему спецификацию.

 

3.3. Результаты тестов

 

Результаты тестов хранятся в соотвествии с [2].

 

 

4. Ссылки

 

[1] ПРИЛОЖЕНИЕ G – Составление Плана качества и Плана

 

[2] ПРИЛОЖЕНИЕ N – Тестирование автоматизированной системы

 

ПРИЛОЖЕНИЕ Q:

Процедура составления Плана технического обслуживания

 

Ответственный: Заказчик и Поставщик

1. Введение

 

План технического обслуживания (Maintenance Plan) определяет технические требования к техническому обслуживанию автоматизированных систем и требования к качеству.

 

Он определяет как эти требования могут быть выполнены в следующих аспектах:

 

-          какие именно единицы будут обслуживаться

 

-          какие мероприятия будут провдиться и их сроки

 

-          лица, ответственные за мероприятия по техобслуживанию

 

-          процедуры технического обслуживания и механизмы контроля.

 

План технического обслуживания на стадии поддержки работы системы заменяет План качества (это еще раз подчеркивает, что работа по поддержке ПО очень отличается от непосредственно программирования).

 

2. Применение

 

Данная процедура применяется к системам, которые будет обслуживать Поставщик. План технического обслуживания обычно составляется Поставщиком и является основой для  официального договора по техническому обслуживанию между заказчиком и Поставщиком. В случае каких-либо отклонений от данной процедуры, причины указываются в Плане технического обслуживания.

 

3. Процедура

 

3.1. Общие указания

 

План технического обслуживания является контрактным документом и должен быть утвержден представителями Поставщика и заказчика.

 

План технического обслуживания контролируется в соответствии с [1].

 

3.2. Содержание документа

 

Раздел определяет какие разделы и подразделы будут включены в План технического обслуживания. Если Раздел или подраздел не рассматриваются, ставится отметка «Не применяется» ("Not Applicable").

 

3.2.1. Введение

 

Раздел содержит следующую информацию:

 

-          Кто составил документ, на каком основании и с какой целью

 

-          Контрактный статус документа.

 

3.2.2. Общие сведения

 

Раздел описывает суть контракта/договора о техническом обслуживании и связь Плана технического обслуживания с другими документами, например, Standard Customer Support Contracts (Стандартные контракты по техническому обслуживанию заказчика).

 

3.2.3. Дефиниции

 

Раздел разъясняет все термины, используемые в Плане технического обслуживания, которые в противном случае могут быть непрвильно поняты.

 

3.2.4. Технические требования

 

Область технического обслуживания

 

Раздел определяет, какие единицы подлежат техническому обслуживанию и период обслуживания. Это могут быть:

 

Программы

Данные и их структуры

Спецификации

Документация для заказчика

Документация для Поставщика

Аппаратные средства, периферия и маркировка

 

Определение исходного состояния продукта

 

Раздел определяет исходное состояние каждой единицы, подлежащей техниченскому обслуживанию, по соглашению между заказчиком и Поставщиком. Составляется соответсвующий документ.

 

Организация по техническому обслуживанию

 

Иногда может потребоваться сосздать отдельную организацию по техническому обслуживанию. Это позволит быстро и качественно, с использованием необходмого оборудования, решать разнородные задачи, возникающие в ходе техобслуживания. Данный раздел определяет, какой будет эта орагнизация и сферу ее деятельности, в которую, в том числе входит, и работа системы поддержки пользователей (help desk).

 

Обычно сюда также включается список контактных лиц и процедуры взаимодействия, например, периодические проверки.

 

Типы работ по техническому обслуживанию

Раздел определяет процедуры управления конфигурацией и контроля за изменениями. Они должны быть, насколько это возможно, такими же как и при программировании.

В этом разделе также документируются типы работ по техническому обслуживанию и процедуры для каждого случая. Используемые в работе инструкции/руководства то же фиксируются здесь.

 

Типы работ по техническому обслуживанию:

 

-          Решение проблемы: определение, анализ и коррекция несоответсвий ПО. Процедуры, используемые для внедрения оперативных изменений ('Quick Fixes'), и их перевод в постоянные модификации.

 

-          Модификации интерфейса. Процедуры, используемые для охвата модификаций, вызванных изменениями аппаратных средств.

 

-          Функциональное расширение или улучшение эксплуатационных качеств. Процедуры, используемые для модернизации системы.

 

Документация и отчетность по техническому обслуживанию

 

Раздел определяет, как работы по техническому обслуживанию будут регистрироваться и храниться.

 

Записи по техослуживанию хранятся также, как записи по качеству. Они включают (для каждой записи):

 

-          Список полученных заявок на поддержку или отчетов о проблемах и текущее состояние каждого из них.

 

-          Организация, ответственная за ответы на заявки и внесение соответствующих корректив.

 

-          Порядок срочности (очередность), присвоенный каждому мероприятию.

 

-          Результат корректирующих действий.

 

-          Статистические данные по частоте сбоев и, соответственно, по корректировке. Эти записи составят основу для периодического отчета о ходе проекта (project progress report). Тут же определяются содержание, частота составления и циркуляция этого отчета.

 

Процедуры релиза

 

Раздел определяет процедуры, используемые для внедрения в ПО изменений, которые стали необходимыми в результате процесса технического обслуживания. Сюда входят:

 

-          Правила внесения поправок и внедрения новых версий

 

-          Метод информирования пользователей об изменениях

 

-          Метод тестирования интеграции изменений в ПО

 

-          Хранение записей о внесении изменений.

 

3.2.5. Требования к качеству

 

Раздел определяет качество и требования к документации Плана по техничесому обслуживанию. Сюда входят:

 

-          Требования по качеству Заказчика

 

-          Критерии входа и выхода

 

-          Ответственность за соблюдение качества

 

-          Мероприятия по тестирования

 

-          Контактное лицо заказчика

 

 

4. Ссылки

 

[1 ] ПРИЛОЖЕНИЕ E - Составление, контроль и выпуск документации

 

ПРИЛОЖЕНИЕ R:

Формы

 

Номер                  Название

 

ФОРМА 1 Согласование документа (Document approval)

 

ФОРМА 2 Журнал циркуляции документа (Document circulation register)

 

ФОРМА 3 Запись о передаче документа (Document transmittal notice)

 

ФОРМА 4      История документа (Document history)

 

ФОРМА 5 Каталог архивных документов (Archived document index)

 

ФОРМА 6 Заявка на внесение изменений (Change request)

 

ФОРМА 7 Ведомость результатов теста (Test results sheet)

 

ФОРМА 8 Ведомость сбоев при тестировании (Test incident sheet)

 

ФОРМА 9      Отчет о проверке (Review report)

 

ФОРМА 10    Сводка отчетов (Review summary)

 

ФОРМА 1 1   Ведомость хода тестирования (Test progress sheet)

 

ФОРМА 12    Реестр заявок на внесение изменений (Change request index)

 

ФОРМА 13    Запись о внесении изменений (Change note)

 

ПРИЛОЖЕНИЕ U:

 

Правила управления медпрепаратами в ЕС, том IV Приложении 11 – Компьютеризированные системы

 

Основные принципы

Внедрение компьютеризированных систем в производство, хранение, распространие и контроль за качеством не исключает необходимости соблюдения соответствующих принципов, приведенных в Руководстве. Там где компьютеризированная система замещает ручную работу не должно наблюдаться падение качества продукта. Необходимо уделить внимание возможному риску, связанному с уменьшением задействованных лиц.

 

Персонал

1. Необходимо установить теснейшее сотрудничество между основным персоналом и IT-персоналом. Ответственным лицам следует пройти соответствующую подготовку по управлению и использованию компьютерных систем в их сфере деятельности. Такая подготовка должна дать специальные знания и научить применять их в разработке, валидации, установке компьютеризированных систем, и работе с ними.

 

Валидация

2. Степень валидации будет зависеть от ряда факторов, таких как сфера применения системы, будет ли валидация проспективной или ретроспективной, будут ли включены новые элементы и т.д. Валидацию следует рассматривать как часть целостной системы жизненного цикла компьютерной системы, который включает в себя стадии планирования, составления спецификаций, непосредственно программирования, тестирования, ввода в действие, составления документация, мониторинга и модернизации.

 

3. Необходимо уделить внимание размещению оборудования в подходящих условиях с тем, чтобы внешние факторы не мешали работе системы.

 

4. Необходимо составить детальное описание системы (включая диаграммы, где это необходимо) и обновлять его по мере необходимости. Описание должно включать принципы, цели, меры безопасности и сферы применения системы, а также условия, в которых используется компьютер, и как система взаимодействует с другими системами и процедурами.

 

5. Программное обеспечение есть критический компонент компьютеризированной системы. Пользователь должен принять все необходимые меры и убедиться, что данное программное обеспечение произведено в соответствии с системой Гарантий Качества.

 

6. Система должна включать в себя встроенные проверки корректного ввода данных и их обработки.

 

7. До начала работы с системой, она должна быть тщательно протестирована. В ходе тестирования необходимо подтвердить, что данная система действительно в состоянии достичь запланированных результатов. Если компьютеризированная система заменяет ручную, то, как часть общего процесса тестирования и валидации, некоторое время должны параллельно функционировать обе системы.

 

8. Данные должны вводиться или корректироваться только уполномоченными лицами. Методы предостережения несанкционированного доступа включают использование ключей, карточек доступа, личных кодов, а также установление ограниченного дотсупа к компьютерным терминалам. Необходимо определить процедуру предоставления, отмены или изменения права доступа к вводу или коррекции данных, что включает в себя изменение персональных паролей. Преимущество нужно отдать системам, позволяющим отслеживать попытки несанкционированного доступа.

 

9. Когда критические данные вводятся вручную (например, вес и номер партии ингридиента при распределении), необходима дополнительная проверка точности сделанной записи. Эта проверка может провдиться вторым оператором или санкционированными электронными средствами.

 

10. Система должна регистировать личность операторов, вводящих или утверждающих критические данные. Право изменять данные должно даваться только особо назанченным лицам. Любое изменение ввода критических данных должно быть письменно санкционировано с указанием причины. Предпочтение должно быть отдано системам со встроенным отчетом по всем входам в систему и по изменениям данных (контрольный журнал).

 

1 1 . Изменения в систему или компьютерную программу должны вноситься в строгом соответствии с определенной процедурой, оговаривающей процесс валидации, проверки, утверждения и внедрения изменений. Все изменения вносятся после согласования с работником, ответственным за данную часть системы, и фиксируются документально. Любые значительные изменения должны быть письменно санкционированы.

 

12. С целью контроля за качеством необходимо иметь точные печатные копии данных, хранимых в электронном виде.

 

13. Данные должны быть защищены физическими или электронными средствами от преднамеренного или случайного повреждения, в соответсвии с п.4.9. Руководства. Хранимые данные должны проверяться на доступность, долговечность и точность. Если предполагаются изменения в компьютерном оборудовании или программам, выше упомянутые проверки должны проводиться с частотой, соответствующей используемой среде хранения информации.

 

14. Данные должны быть защищены с помощью резервного копирования через постоянные промежутки времени.

 

15. Должны быть предусмотрены адекватные альтернативные средства для систем, которые должны продолжать работу и в случае поломки. Время, необходимое для их установки, должно соответствовать возможной срочности их использования.

 

16. Должны быть составлены и утверждены роцедуры, устанавливающие порядок действий в случае поломки/сбоя системы. Все сбои/поломки и предпринятые действия должны фиксироваться письменно.

 

17. Необходимо составить также процедуру фиксирования и анализа ошибок системы и процедуру их корректирования.

 

18. В случае, если для оказания компьютерных услуг привлекается компания со стороны, должно быть составлено формальное соглашение с четким указанием обязанностей данной компании (см.Глава 7).

19. Когда компьютеризированная систем используется при выпуске партий товара для продажи или поставки, доступ к данной работе должен иметь только Квалифицированный работник, а система должна четко распознать его и внести в отчет.