Функциональные проверки
Состояния, переходы, обязательные поля, ошибки и правила.
Подробнее ↗
UNIUM / НАДЁЖНОСТЬ ПЛАТФОРМЫ
От задачи бизнеса
до проверенной версии.
V-модель связывает уровни требований с соответствующими проверками. Её принципы применимы и при итеративной разработке: изменение уточняет связи, проверки и доказательства для версии.
Обсудить требования к системе ↗ЖИЗНЕННЫЙ ЦИКЛ / V-МОДЕЛЬ
Что определяем — то и проверяем
Выберите пару этапов. Интеграционные и компонентные проверки относятся к техническим решениям; приёмка — к требованиям пользователя; подтверждение результата — к цели бизнеса.
Авторская схема подхода, а не утверждение о внедрении всей V-модели в UNIUM. Проверки могут выполняться повторно в каждой итерации.
ПОДРОБНОСТИ ВЫБРАННОГО ЭТАПА
Потребности бизнеса ↔ подтверждение результатов проверок
Совокупность результатов рассматривается относительно цели бизнеса. Подтверждение результатов — решение по доказательствам, а не дополнительный отдельный вид теста.
- Входные материалы
- Цель процесса, ограничения, ожидаемый результат
- Результат
- Критерии бизнес-приёмки и решение о пригодности
- Ответственные роли
- Владелец процесса и заказчик
- Критерий завершения
- Результат сопоставлен с исходной целью, отклонения рассмотрены
ПРОСЛЕЖИВАЕМОСТЬ / КОНКРЕТНЫЙ ПРИМЕР
Как связываем требование с проверкой
На примере обучения и прав доступа покажем, как задача бизнеса превращается в правило системы, проверку и документированный результат.
Разберём два правила и их критерии приёмки. Выберите процесс, затем этап — от требования до решения о выпуске.
ПОДРОБНОСТИ ВЫБРАННОГО ЭТАПА
Требование
Сотрудник не должен закрывать корректирующее действие, пока не завершит обязательное обучение по актуальной инструкции.
- Входные материалы
- Задача службы качества: подготовить сотрудников к изменению
- Результат
- Условие закрытия и критерии приёмки
- Ответственные роли
- Владелец процесса качества
- Критерий завершения
- Согласовано, кому и какое обучение обязательно
Нельзя закрыть действие до завершения обучения
Пример правила: после изменения инструкции сотрудник должен пройти обязательное обучение, прежде чем закрыть корректирующее действие.
- Условие
Обязательное обучение не завершено
ДействиеЗакрыть корректирующее действие
Ожидаемое поведениеЗакрытие запрещено. Видно, какое обучение осталось пройти.
- Условие
Все обязательные назначения выполнены
ДействиеЗакрыть то же действие
Ожидаемое поведениеЗакрытие разрешено. Решение сохраняется в истории.
- Условие
Инструкция обновлена; новое обучение ещё не пройдено
ДействиеЗакрыть действие с результатом по старой инструкции
Ожидаемое поведениеЗакрытие запрещено до обучения по актуальной версии.
В протоколе сохраняются версия инструкции, назначение обучения, ожидаемое и фактическое поведение. Протокол связывается с требованием и версией системы.
Зачем хранить эти связи
При изменении правила видно, какие функции и проверки затронуты. При разборе ошибки можно найти исходное требование, проверить результаты испытаний и определить версию системы.
ИЗМЕНЕНИЯ / КОНТРОЛЬНЫЕ ТОЧКИ
Выпуск — решение по результатам
Ниже показан цикл изменения: от запроса до наблюдения после выпуска. Для каждого этапа раскрываются материалы и критерии.
Модель жизненного цикла. Этапы и материалы уточняются под размер изменения и процесс команды.
ПОДРОБНОСТИ ВЫБРАННОГО ЭТАПА
Запрос
Фиксируем задачу и причину изменения.
- Входные материалы
- Потребность
- Результат
- Запрос изменения
- Ответственные роли
- Заказчик, продуктовая команда
- Критерий завершения
- Понятны задача и границы
Демонстрационные данные · последовательность версий
Версия А→ Оценка изменения → Целевые проверки → Решение →Версия Б
Идентификаторы условные. Это не статистика релизов UNIUM. Опубликованные изменения продукта ↗
ПРОВЕРКИ / КРИТЕРИИ
Проверять и обычный путь, и исключения
Для корпоративного процесса важны права, версии документов, сбои обмена и повторные действия.
Компоненты и интеграции
Контракты, права, обмен, повторная обработка и недоступность.
Подробнее ↗Регрессия и приёмка
Затронутые сценарии, критерии приёмки и рассмотрение отклонений.
Подробнее ↗
ПОНЯТИЯ / ПРАКТИЧЕСКИЙ СМЫСЛ
Понятия, на которых строится контроль
Что требуем от системы, чем подтверждаем результат и как сохраняем доверие к данным. Все определения открыты сразу.
От требования к документу
Спецификация требований пользователя
Описание того, что система должна делать для пользователей и бизнес-процесса.
Функциональная спецификация
Описание поведения системы, которое реализует требования пользователя.
Матрица прослеживаемости требований
Связи требований, проектных решений, проверок и результатов для определённой версии системы.
От проверки к подтверждению
Валидация компьютеризированных систем
Документированное подтверждение пригодности системы для конкретного применения в организации.
Квалификация установки
Проверка установки и конфигурации в согласованной среде.
Квалификация функционирования
Проверка работы функций в заданных условиях и диапазонах.
Квалификация эксплуатации
Подтверждение пригодности системы в реальном процессе с его пользователями и данными.
От контроля к доверию
Корректирующие и предупреждающие действия
Действия по устранению причин несоответствий и предотвращению их повторения.
Аудиторский след
История значимых действий и изменений: кто, что и когда изменил, с сохранением необходимых оснований.
Принципы целостности данных
Данные соотносятся с автором, читаемы, фиксируются своевременно, сохраняют первоисточник и точность; также полны, последовательны, долговечны и доступны.
Надлежащие практики
Общее обозначение отраслевых практик, например производственной GMP. Конкретные требования зависят от деятельности.
Руководство по компьютеризированным системам в регулируемых процессах
Риск-ориентированное отраслевое руководство ISPE. Не закон и не сертификат программного продукта.