Тема 3.5 — Жизненные циклы поставки

Одним предложением: Жизненный цикл поставки — последовательность фаз и ворот принятия решений (исследование, альфа, бета, эксплуатация и, в конце концов, вывод из эксплуатации), через которые проходит цифровая услуга, с клинической безопасностью, управлением информацией и гарантиями, вплетёнными в каждую фазу, а не навешенными в конце.

Почему это важно в здравоохранении и уходе#

Жизненный цикл — способ, которым организация превращает идею в безопасную действующую услугу и, в конце концов, ответственно её выводит из эксплуатации. В здравоохранении и уходе каждый переход несёт законодательный и клинический вес: нельзя внедрить систему, затрагивающую уход за пациентами, без обоснования клинической безопасности, и нельзя обрабатывать конфиденциальные данные пациентов без законного основания и завершённой оценки воздействия на защиту данных (DPIA). Жизненный цикл, рассматривающий это как бумажную работу конца проекта, производит услуги, опоздавшие, небезопасные или то и другое.

Ставки асимметричны. Потребительское приложение, выпустившее ошибку, раздражает пользователей; общая карта ухода, выпустившая ошибку, может показать клиницисту аллергии не того пациента. Поэтому NHS встраивает модель фаз GOV.UK и стандарты клинического управления рисками DCB0129 и DCB0160 в один и тот же жизненный цикл. Правильный жизненный цикл — не любезность управления: это механизм, которым безопасность, равенство и ценность для государственных денег действительно обеспечиваются, а не только обещаются.

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

Ключевые понятия#

Модель фаз: исследование → альфа → бета → эксплуатация. Стандарты услуг NHS и GOV.UK определяют четыре фазы. Исследование (Discovery) (см. тему 3.4 — Фазы исследования) понимает проблему. Альфа (Alpha) строит одноразовые прототипы, чтобы проверить, могло бы ли решение работать, и сжечь самые рискованные допущения. Бета (Beta) строит настоящую, сначала закрытую, затем публичную услугу на производственной инфраструктуре, итерируя с реальными пользователями во всё большем масштабе. Эксплуатация (Live) ведёт услугу в непрерывной работе, всё ещё итерируя, пока её не выведут из эксплуатации. Фазы — рампа снижения риска: каждая выделяет больше денег и подвергает больше пользователей, оправданная доказательствами предыдущей.

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

Agile, водопад и гибрид. Водопад фиксирует объём заранее и идёт последовательно: подходит только там, где требования действительно стабильны и познаваемы (миграция центра обработки данных, предписанное регуляторное изменение). Agile поставляет небольшими приращениями, проверяя и адаптируясь: подходит неопределённости пользовательских услуг. Гибрид — честная реальность большинства крупных программ здравоохранения: agile-продуктовые команды, действующие внутри оболочки вех и финансирования, которую требуют организация и её регуляторы. Соотносите метод с неопределённостью, а не с модой.

Оценки услуг и ворота стандартов. На переходах между фазами, особенно от альфы к бете и перед публичным запуском, услуги NHS и GOV.UK проходят оценку услуги: независимая панель проверяет работу по пунктам Service Standard (потребность пользователя, доступность, безопасность, надёжность, команда, технологические выборы). Прохождение — ворота к тому, чтобы тратить больше и подвергать больше пользователей. Оценка — рецензирование коллегами на основе доказательств, а не формальная печать.

Клиническая безопасность и управление информацией как нити жизненного цикла. DCB0129 (для производителя/поставщика) и DCB0160 (для внедряющей организации здравоохранения или ухода) требуют системы управления клиническими рисками, журнала опасностей и отчёта об обосновании клинической безопасности, согласованного названным, обученным специалистом по клинической безопасности (Clinical Safety Officer, CSO). Управление информацией требует законного основания, DPIA и соблюдения принципов Калдикотта. Обе — нити, проходящие через исследование, альфу, бету и эксплуатацию, а не ворота в конце.

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

Лучшие практики#

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

2. Вплетайте клиническую безопасность с альфы, а не перед эксплуатацией. Назначьте специалиста по клинической безопасности и откройте журнал опасностей, как только появляется форма решения. Опасности, выявленные в альфе, дёшево устранить проектом; опасности, найденные при запуске, — кризис, блокирующий запуск. Обоснование безопасности созревает вместе с услугой, так что согласование DCB0129/0160 — резюме уже сделанной работы, а не суматоха.

3. Начните DPIA и работу по IG на исследовании и держите её живой. Потоки данных, законное основание и соображения Калдикотта формируют архитектуру, поэтому выносите их на поверхность, пока архитектура ещё мягкая. DPIA, написанная после разработки, — упражнение в документировании; написанная вместе с проектированием, она действительно снижает риск и предотвращает переделки.

4. Автоматизируйте путь в производство с помощью CI/CD и DevOps. Непрерывная интеграция и непрерывная поставка, автоматизированные конвейеры сборки, тестирования и развёртывания, позволяют команде безопасно и часто выпускать небольшие, обратимые изменения. В критичной для безопасности области возможность развернуть исправление за минуты и чисто откатить — сама по себе мера безопасности. Сочетайте это с мониторингом, оповещением и инфраструктурой как кодом, чтобы действующая услуга была наблюдаемой и воспроизводимой.

5. Соотносите метод с неопределённостью. Используйте agile там, где потребности пользователей неопределённы, а исследование всё ещё чему-то вас учит; принимайте последовательность, похожую на водопад, только там, где требования действительно фиксированы, а риск изменения низок. Будьте явны в том, что ведёте гибрид (agile-команды внутри оболочки программы), а не притворяйтесь, что один метод управляет всем, что никого не обманывает и раздражает всех.

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

7. Продолжайте итерировать в эксплуатации и обеспечивайте это ресурсами. Услуге не перестаёт быть нужна команда, когда она запускается. Эксплуатация — то место, где реальное использование выявляет последние неравенства, редкие, но серьёзные клинические крайние случаи и пробелы доступности. Финансируйте постоянную продуктовую команду на операционную жизнь услуги (см. тему 5.0 — Работа, ведомая продуктом); действующая услуга без команды — технический долг, накапливающий клинический риск.

8. Планируйте вывод из эксплуатации до того, как он понадобится. Решите ещё при разработке, как услуга будет в конце концов выведена: хранение и миграция данных по закону об управлении записями, перенаправление пользователей, уведомление клиницистов и архивирование обоснования клинической безопасности и следа аудита. Незапланированный вывод бросает данные и пользователей; запланированный — контролируемая, проверяемая фаза.

Вопросы для обсуждения с командой#

1. Действительно ли наши ворота фаз управляются доказательствами или они тихо превратились в даты в плане? Вся ценность модели «исследование — альфа — бета — эксплуатация» в том, что каждый переход выделяет больше денег и подвергает больше пользователей только тогда, когда доказательства предыдущей фазы это оправдывают; в момент, когда ворота срабатывают потому, что закончился квартал, а не потому, что доказательства получены, рампа перестаёт снижать риск и становится «водопадом в костюме agile». Этот вопрос просит команду честно посмотреть на её последние несколько переходов и спросить, что произошло бы, если бы доказательства сказали «ещё нет»: было ли место, чтобы удержать, вернуть бету в альфу ради трудной функции, или дата запуска была политически неподвижна? Напряжение для обсуждения — между потребностью организации в читаемых вехах по графику совета и реальностью, что безопасные услуги движутся в темпе доказательств, а гибридная поставка живёт именно в этом трении. Конкретные ракурсы включают называние конкретного решения и доказательств, которые предстоят на следующих воротах, проверку, действительно ли «спринты» меняют объём или лишь следуют фиксированному плану, и вопрос, кто уполномочен задержать ворота без карьерного риска. Хороший ответ может указать реальный случай, когда доказательства изменили план, и сформулировать, какие доказательства оправдали бы или заблокировали следующее выделение государственных денег и пользователей.

2. Являются ли клиническая безопасность и управление информацией живыми нитями через каждую фазу или бумагой, которую мы намерены закончить до эксплуатации? В здравоохранении и уходе DPIA и работа по клиническим рискам DCB0129/0160 — не согласования конца проекта, а нити, которые должны формировать архитектуру и проект с альфы и далее, потому что опасность, устранённая проектом рано, дёшева, а обнаруженная при запуске — кризис, блокирующий запуск, или, хуже, давление пропустить обоснование безопасности. Этот вопрос выясняет, существуют ли названный, обученный специалист по клинической безопасности и открытый журнал опасностей, как только появляется форма решения, и началась ли DPIA и анализ законного основания на исследовании, пока потоки данных были ещё достаточно мягкими, чтобы меняться. Компромисс для обсуждения — ощутимая тяжесть делать это непрерывно против гораздо большей цены и клинического риска доработки, особенно для небольших команд или стартапов, где регулятор ещё не смотрит, но обязательство DCB0129 лежит на производителе независимо. Подумайте о конкретных доказательствах: показывает ли журнал опасностей опасности, найденные и смягчённые в альфе, читается ли обоснование безопасности как резюме уже сделанной работы и прослеживается ли DPIA до реальных проектных решений? Честный ответ отличает команду, созревающую обоснование безопасности вместе с услугой, от направляющейся к суматохе с документами за месяц до запуска.

3. Как эта услуга будет вестись в эксплуатации и в конце концов выводиться из эксплуатации и кто финансируется, чтобы это делать? У жизненных циклов длинный хвост, который организации регулярно недофинансируют: эксплуатация — то место, где реальное использование выявляет последние неравенства, редкие, но серьёзные клинические крайние случаи и пробелы доступности, и ей нужны постоянная продуктовая команда, мониторинг и быстрое, обратимое развёртывание, а не команда, распускающаяся при запуске и оставляющая услугу гнить и тихо накапливать клинический риск. Столь же забыт вывод из эксплуатации: вывод услуги по закону о хранении записей, миграция или архивирование данных, перенаправление пользователей, уведомление клиницистов и сохранение журнала опасностей и следа аудита, что для национальной системы само по себе крупная программа, а не запоздалая мысль, когда приходит замена. Напряжение для обсуждения — годовые циклы финансирования и давление объявить проект «законченным» при запуске против принадлежности на всю жизнь, которой на самом деле требует безопасная услуга. Полезные ракурсы включают: рассматривается ли конвейер CI/CD с мониторингом и быстрым откатом как действующая мера безопасности, переживёт ли бюджет дежурств и итераций празднование запуска и был ли план выхода написан при разработке, а не импровизирован в панике. Хороший ответ называет, кто владеет услугой на её операционную жизнь, и описывает контролируемый, проверяемый вывод, а не надежду, что кто-то разберётся позже.

4. Когда мы в последний раз позволили провалу прототипа нас остановить и строим ли мы всё ещё вещи, чтобы их выбросить? Альфа существует, чтобы дёшево сжигать самые рискованные допущения, что означает, что одноразовый прототип, потерпевший неудачу, выполнил свою работу: он купил дорогой урок до того, как были выделены производственные деньги и реальные пациенты. Этот вопрос проверяет, действительно ли команда считает альфу одноразовым обучением или тихо скатилась к доводке первого прототипа до итогового продукта, потому что выбрасывать код кажется расточительным: ловушка безвозвратных затрат, превращающая фазу снижения риска в дорогое обязательство, принятое вслепую. Напряжение, которое стоит вынести на свет, — давление «иметь что-то показать» и использовать повторно каждую написанную строку против дисциплины доказать, что решение могло бы работать, прежде чем строить настоящее на производственной инфраструктуре. Конкретные ракурсы включают вопрос, какие допущения на самом деле проверила последняя альфа, был ли когда-нибудь прототип заброшен по доказательствам и использовала ли сборка закрытой беты повторно одноразовый код, который следовало переписать до производственного стандарта. Честный ответ может указать конкретное допущение, которое прототип убил или подтвердил, и отличить артефакты обучения, которые команда была готова выбросить, от гарантированного кода, который она теперь запускает в эксплуатации.

5. Ведём ли мы один честный гибрид или несколько замаскированных методов, тихо противоречащих друг другу? Большинство крупных программ здравоохранения действительно гибридны (agile-продуктовые команды внутри оболочки вех и финансирования, которую требуют организация и регуляторы), и сбой — не сам гибрид, а притворство, что он чистый agile или чистый водопад, так что две логики сталкиваются неуправляемо на каждых воротах. Этот вопрос просит команду назвать, где на самом деле находятся фиксированные, упорядоченные обязательства (транши финансирования, регуляторные вехи, заморозки интеграции) и где происходит подлинная итерация, а не позволять «agile» и «плану» каждому претендовать на всю программу и раздражать всех. Компромисс для обсуждения — законная потребность организации в предсказуемых вехах и проверяемых расходах против потребности команды поставки менять объём по доказательствам, и честный ход — сделать швы явными, чтобы можно было планировать вокруг обоих. Полезные ракурсы включают: переживает ли переприоритизация бэклога столкновение с планом программы, заключены ли контракты с поставщиками на фиксированный объём, пока их просят работать итеративно, и совпадает ли отчётность, которую видит совет, с тем, как работа делается на самом деле. Хороший ответ описывает сознательно спроектированный гибрид с названными фиксированными точками и названными гибкими пространствами, а не путаницу, в которой метод заявляется для вида.

6. Насколько хорошо мы знаем, что действующая услуга делает с её пользователями прямо сейчас, и заметили бы мы вред до того, как о нём сообщат? Действующая услуга здравоохранения безопасна ровно настолько, насколько она наблюдаема: мониторинг, оповещение и клинические инстинкты безопасности, превращающие метрику в опасность, означают разницу между обнаружением дефекта устаревших данных за минуты и узнаванием о нём из отчёта об инциденте через недели. Этот вопрос исследует, видит ли команда услугу в производстве (доля ошибок, сбои интеграции, отсев по доступности, разрывы равенства, которые выявляет только реальное использование) и смотрит ли кто-нибудь на дашборды с мыслью о клиническом риске, а не только о времени работы инфраструктуры. Напряжение — цена и дисциплина надлежащей наблюдаемости и дежурств против тихого допущения «нет новостей — хорошие новости» после запуска услуги, что в критичной для безопасности области — способ, которым накапливается тихий вред. Конкретные ракурсы включают: обновляется ли журнал опасностей из действующих инцидентов, сопоставляются ли оповещения с клиническим воздействием, а не только со здоровьем серверов, и можно ли обнаружить плохой релиз и откатить его до того, как он достигнет многих пациентов. Честный ответ описывает конкретные сигналы, за которыми следит команда, реальный инцидент, который мониторинг поймал (или пропустил), и как живые доказательства возвращаются в следующую итерацию.

На практике: пример из здравоохранения и ухода#

Общественный траст NHS заменяет унаследованную систему «бумага и таблицы» для планирования визитов районных медсестёр. По завершении исследования (тема 3.4) команда входит в альфу и строит два одноразовых прототипа для проверки самых рискованных допущений: что медсёстры будут пользоваться телефоном дома у пациентов и что расписание может интегрироваться с электронной картой пациента. Специалист по клинической безопасности назначается в первый день альфы и открывает журнал опасностей; ранняя опасность (устаревшее расписание, показывающее визит, уже выполненный коллегой) определяет проектное решение показывать статус синхронизации в реальном времени. DPIA, начатая на исследовании, помечает, что данные о местоположении одиноких работников нуждаются в определённом законном основании и пределе хранения.

На оценке услуги при переходе от альфы к бете независимая панель изучает доступность (медсёстры с нарушениями зрения), безопасность и рассуждения команды. Услуга проходит с действиями по доработке. В закрытой бете десять медсестёр пользуются реальной системой на производственной инфраструктуре; конвейер CI/CD позволяет команде выпускать ежедневно и откатывать плохой релиз менее чем за десять минут. Использование выявляет проблему равенства: персонал агентств без устройств траста, что ведёт к запасному варианту на основе браузера. Публичная бета масштабируется на три территории; отчёт об обосновании клинической безопасности завершается и согласуется по DCB0160 до более широкого внедрения.

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

Отраслевые перспективы#

Стартап#

Жизненный цикл стартапа сжат и в значительной мере самоуправляем: независимой панели оценки услуги нет, поэтому дисциплина ворот «альфа — бета — эксплуатация» должна быть самоналоженной, иначе она рушится в «выпускать непрерывно и надеяться». Преимущество в том, что небольшая команда может вести подлинный CI/CD с первого дня и итерировать быстрее любого крупного органа. Опасность — тихо отбросить нити клинической безопасности и DPIA, потому что регулятор ещё не смотрит: роковая ошибка в здравоохранении, где обязательства DCB0129 лежат на производителе независимо от размера компании, а одна неуправляемая опасность может закончить и продукт, и компанию. Стартапам следует принять замысел модели фаз (доказательства перед воздействием) даже без церемонии, назначив специалиста по клинической безопасности (часто на частичной ставке), как только появляется форма решения.

Малый бизнес#

Устоявшийся небольшой поставщик (практика врача общей практики, общественная аптека, дом престарелых или клиника в одном месте) обычно встречает жизненный цикл как внедряющая сторона, а не строитель: он закупает или конфигурирует систему поставщика, поэтому согласование внедрения по DCB0160 и местная DPIA ложатся на него, даже без собственной цифровой команды. Фазы всё равно применяются, но в сжатом и аутсорсинговом виде: «альфа» — пилот под наблюдением на нескольких реальных пациентах, «бета» — поэтапное развёртывание по практике, а эксплуатация — повседневная работа с обновлениями поставщика, приходящими непрерывно и в значительной мере вне контроля практики. Организация должна назвать специалиста по клинической безопасности (часто клинического партнёра, берущего роль сверх основной работы) и вести журнал опасностей по тому, как система используется локально, потому что работа производителя по DCB0129 не покрывает специфические риски внедрения. При туго с деньгами и отсутствии выделенного ИТ реалистичная дисциплина — опираться на гарантии поставщика, владея немногими решениями, которые может принять только местное знание: кто обучен, каков запасной вариант, когда система не работает, и как данные пациентов текут в этих конкретных условиях.

Крупная организация#

Траст NHS или крупный поставщик ведёт жизненный цикл в его самой полной, наиболее гарантированной форме: формальные оценки услуг, названный специалист по клинической безопасности, согласование внедрения по DCB0160, советы по изменениям и годовой цикл финансирования, в который должна вписываться agile-работа. Характерный вызов — гибрид (agile-команды поставки, действующие внутри оболочки программ и вех, которую требуют организация и её аудиторы), а классический сбой — «водопад в костюме agile», где ворота тихо становятся календарными датами. У крупных организаций есть ресурсы, чтобы вести CI/CD, наблюдаемость и постоянные продуктовые команды как следует, но организационная инерция и унаследованные интеграции часто замедляют развёртывание до ползания. Подотчётность широка, а радиус поражения велик, поэтому поэтапная рампа от закрытой беты к эксплуатации — не необязательная осторожность, а существенный контроль риска.

Государство#

Национальный орган поставляет под полным Service Standard, опубликованными оценками услуг, контролем расходов и парламентским контролем, поэтому каждые ворота фазы — также точка публичной подотчётности. Жизненные циклы здесь длинные, а воздействие огромное: действующая услуга всего NHS может затрагивать миллионы, что повышает ставки поэтапной рампы, гарантий клинической безопасности и вывода из эксплуатации заменяемых унаследованных систем. Правила закупок и многолетние соглашения о финансировании формируют то, что «agile» может означать на практике, а вывод национальной системы (с её десятилетиями записей и законодательными обязанностями по хранению) — сама по себе крупная программа. Компромисс — гарантии против скорости: государственная поставка сильно закрыта воротами, что защищает безопасность и государственные деньги, но требует сознательных усилий, чтобы команды продолжали итерировать, а не возвращались к крупному проектированию заранее.

Типичные способы сбоя#

• Водопад в костюме agile. Команда ведёт «спринты», но объём, даты и проект были зафиксированы заранее; итерация — театр. Противоядие: позволить доказательствам на каждых воротах действительно менять план.
• Безопасность и IG, навешенные в конце. Обоснование клинической безопасности и DPIA пишутся за месяц до запуска, блокируя запуск или, хуже, пропускаются под давлением. Противоядие: открыть журнал опасностей и DPIA в альфе и непрерывно их созревать.
• Запуск «большим взрывом». Услуга пропускает закрытую/публичную бету и идёт прямо на полное внедрение, подвергая каждого пользователя непроверенному ПО. Противоядие: использовать поэтапную рампу; наращивать воздействие по доказательствам.
• Заброшенная действующая услуга. Команда поставки распускается при запуске; услуга гниёт, а клинический риск тихо накапливается. Противоядие: финансировать постоянную продуктовую команду на операционную жизнь.
• Зубрёжка оценки. Стандарты игнорируются, пока не замаячит оценка, затем соблюдаются поверхностно. Противоядие: непрерывно привлекать рецензентов по гарантиям и клиническим вопросам.
• Нет плана выхода. Услуга выводится в панике, когда приходит замена, бросая данные и пользователей. Противоядие: планировать вывод из эксплуатации как первоклассную фазу.

Модель зрелости#

Контрольный список#

• У услуги есть явная текущая фаза (исследование / альфа / бета / эксплуатация) и названное следующее решение.
• Переходы фаз определяются доказательствами, а не датами.
• Специалист по клинической безопасности назначен, а журнал опасностей открыт (DCB0129/0160) с альфы.
• DPIA и оценка законного основания (Калдикотт, UK GDPR) начаты на исследовании и поддерживаются актуальными.
• Метод поставки соотнесён с уровнем неопределённости, а любая гибридная договорённость явна.
• Оценки услуг запланированы, а рецензенты по гарантиям/безопасности/доступности привлекаются рано.
• Конвейер CI/CD с мониторингом и быстрым откатом существует до публичной беты.
• Услуга подвергается пользователям поэтапно (закрытая бета → публичная бета → эксплуатация), а не «большим взрывом».
• Постоянная продуктовая команда финансируется на операционную жизнь услуги (см. тему 5.0).
• План вывода из эксплуатации охватывает хранение/миграцию данных, перенаправление пользователей и архивирование записей безопасности и аудита.

Ключевые источники#

• GOV.UK Service Manual — фазы agile-проекта (исследование, альфа, бета, эксплуатация) и Government Service Standard.
• NHS England — NHS Service Standard и NHS Digital Service Manual; оценки услуг NHS.
• NHS England Digital — DCB0129 (Clinical Risk Management: its Application in the Manufacture of Health IT Systems) и DCB0160 (its Application in the Deployment and Use of Health IT Systems).
• NHS England — цифровые гарантии клинической безопасности; роль специалиста по клинической безопасности, журнал опасностей и отчёт об обосновании клинической безопасности.
• NHS England — Digital Technology Assessment Criteria (DTAC).
• Принципы Калдикотта Великобритании; Data Protection Act 2018 / UK GDPR и оценки воздействия на защиту данных.
• NICE — Evidence Standards Framework for Digital Health Technologies.
• Практика DevOps и непрерывной поставки (например, возможности DORA: непрерывная интеграция, автоматизация развёртывания, мониторинг); руководство GOV.UK Service Manual по непрерывной поставке и эксплуатации услуги.

Ссылки#

1. Systems development life cycle — Wikipedia — https://en.wikipedia.org/wiki/Systems_development_life_cycle
2. Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
3. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
4. Software prototyping — Wikipedia — https://en.wikipedia.org/wiki/Software_prototyping
5. CI/CD — Wikipedia — https://en.wikipedia.org/wiki/CI/CD
6. Continuous integration — Wikipedia — https://en.wikipedia.org/wiki/Continuous_integration
7. Continuous delivery — Wikipedia — https://en.wikipedia.org/wiki/Continuous_delivery
8. DevOps — Wikipedia — https://en.wikipedia.org/wiki/DevOps
9. Infrastructure as Code — Wikipedia — https://en.wikipedia.org/wiki/Infrastructure_as_code
10. Observability (software) — Wikipedia — https://en.wikipedia.org/wiki/Observability_(software)
11. Privacy impact assessment (data protection impact assessment) — Wikipedia — https://en.wikipedia.org/wiki/Privacy_impact_assessment
12. Agile delivery: the phases of an agile project — Government Digital Service, GOV.UK Service Manual — https://www.gov.uk/service-manual/agile-delivery
13. NHS service standard and NHS digital service manual — NHS England — https://service-manual.nhs.uk/
14. Clinical risk management standards DCB0129 and DCB0160 — NHS England (Clinical Safety) — https://digital.nhs.uk/services/clinical-safety
15. DevOps Research and Assessment (DORA) capabilities — Google Cloud / DORA — https://dora.dev/
16. Continuous delivery — Jez Humble and David Farley — https://continuousdelivery.com/
17. Data protection impact assessments (DPIAs) — Information Commissioner's Office (ICO) — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/
18. Evidence standards framework for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health