Периодически в нашей работе возникают различные разногласия относительно понимания обязанностей и уровня ответственности Разработчика и Заказчика медицинской информационной системы (МИС), включая разночтения в понимании жизненного цикла программных продуктов или даже отдельных их функций. Такие разногласия, нередко перерастающие в споры, конфликты и как результат, в торможение дальнейшей совместной работе, давняя и очень хорошо известная в ИТ-отрасли проблема, встречающаяся в работе практически любых разработчиков и Заказчиков.
Когда мы, разработчики МИС, создаем какую-то новую функцию или подсистему (или даже целый продукт), то мы как правило имеем свое уверенное убеждение, что мы сделали все четко по техническому заданию (ТЗ), продукт полностью готов и имеет хорошее качество. Но когда представители Заказчика получают и устанавливают этот продукт (или пакет обновления) – то их оценки иногда могут иметь существенное отличие от того, что думают разработчики.
Знакомая многим история: программисты выпускают МИС с новой функциональностью, будучи уверенными – что они сделали правильную и классную работу. Но вместо этого они получают оценку, что они сделали нечто, что вообще никак не решает поставленную изначально задачу и не подходит для реального внедрения и применения пользователями. В результаты ИТ-компания вынуждена разбираться с несовпадающими оценками между различными участниками процесса разработки и внедрения ПО, которые на самом деле кроются по большому счету именно в том, что стороны по-разному понимают одни и те же термины и этапы разработки продукта и собственные права и обязанности на каждом из этих этапов.
На самом деле такая ситуация не является чем-то уникальным. Это обычная практика. И в этой практике есть общепринятые подходы к организации процесса производства и внедрения ПО, которые позволяют если не полностью исключить данную проблему, то существенно снизить ее остроту и негативное влияние на всех участников. В этой статье мы приводим краткую справку по различным этапам жизненного цикла МИС с необходимыми пояснениями и отсылками к общепринятой практике, позволяющая бороться с данной проблемой.
Общие сведения
Любое программное обеспечение (ПО) имеет свой жизненный цикл — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. По этому вопросу в настоящее время в России действует стандарт ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств», идентичный международному стандарту ISO/IEC 12207:2008 «System and software engineering — Software life cycle processes». Данный стандарт принят Федеральным агентством по техническому регулированию и метрологии РФ 01.03.2012 г.
Стандарт рассматривает сразу несколько аспектов, касающихся ПО:
• процессы разработки (т.е. непосредственно создание продукта, включая его проектирование, кодирование, тестирование и т.д.).
• процессы проекта (т.е. все то, что касается планирования будущего внедрения, управление, анализ и решение проблем и т.д.).
• процессы жизненного цикла (т.е. отдельно взятого внедрения продукта у заказчика) и т.д.
В целом ГОСТом сразу оговорено, что данный документ (равно как и другие стандарты, на которых он основан или ссылается, включая международные) является рамочным, определяющим общие правила, последовательности и процессы жизненного цикла ПО. При этом существует множество различных моделей и методик, имеющих отношение как к разработке систем, так и моделям жизненного цикла ПО, включая проектное управление и т.д. В отдельно взятых отраслях экономики или в работе каждой конкретной компании-разработчика ПО эти требования и различные методики адаптируются и уточняются, оставляя только то, что актуально и приемлемо для данного разработчика информационных систем с учетом специфики предметной области и особенностей разрабатываемых программных продуктов.
Если в целом укрупнить и упростить изложенные в стандартах материалы, то для медицинских информационных систем можно выделить следующие основные этапы жизненного цикла:
1) Аналитический этап. Включает анализ требований заказчика, учет требований и рекомендаций регуляторов отрасли (Минздрав, ФФОМС и т.д.), стратегии развития продуктов, выработанной соответствующей компанией-разработчиком, совещания и различные обсуждения и т.д.
2) Этап проектирования. Включает составление ТЗ, экизов, требований к ПО или новой функции, уточнение применяемых алгоритмов, образцов экранных и отчетных форм, требований к реализации и т.д.
3) Этап разработки включает непосредственное создание МИС или новой функции – (программирование), который в свою очередь состоит из:
- a. Написание кода
b. Тестирование
c. Доработка по результатам различных методов тестирования
d. Документирование
4) Этап внедрения, включающий передачу (установку) ПО на промышленную инфраструктуру, настройку и обучение пользователей
5) Этап сопровождения, который подразумевает прием от пользователей различных обращений и предложений, их анализ и учет в дальнейшем развитии продукта
6) Вывод из эксплуатации, включая экспорт накопленных данных, деинсталляция ПО, уничтожение конфиденциальной информации при необходимости и т.д.
Описание этапов
1. Аналитический этап
Главная задача аналитического этапа состоит в анализе требований к будущему продукту или новой функции существующего ПО. Это первый этап создания МИС или отдельных ее новых компонентов. Он включает в себя как правило вначале вербальный способ обсуждения будущей системы или ее компонентов, изучение имеющихся аналогичных решений, уточнение требований к системе со стороны Заказчика, службы внедрения и сопровождения, анализа технических возможностей реализации, имеющихся сроков и ресурсов.
Результатом этого этапа является создание Технического задания (ТЗ) – формального документа, описывающего все основные аспекты будущей системы, новой функции или компонента.
2. Проектирование
Этап проектирования состоит в анализе ТЗ и планировании работ по созданию системы, включая уточнение заданий на разработку, составление плана-графика работ, уточнение технической и иной документации, необходимой для разработки системы, планирование ресурсов и т.д.
3. Разработка
Задача этого этапа состоит в создании одного или нескольких прототипов МИС. Затем по результатам следующих этапов (тестирования и опытной эксплуатации) создается конечный продукт, пригодный для промышленного использования. Разработка прототипа состоит в программировании его компонентов (или выборе из имеющихся готовых наработок) и предварительном документировании.
Разработка прототипа является чрезвычайно важным шагом в создании МИС. Некоторые фрагменты прототипа могут войти в окончательную версию системы, но не это является наиболее важной целью создания прототипа. Главное, чтобы прототип обеспечил проверку адекватности идей, выбранных при построении данной системы, поставленным задачам (сформированным на этапе проектирования).
Создание прототипа должно подтвердить, что выбранные методы решений и способы представления информации пригодны для успешного решения заявленных, по крайней мере основных, задач системы или новой функции. Основная роль данного этапа состоит в том, чтобы убедится в реальности решения поставленных задач, не заботясь пока об эффективности. По мере разработки и развития прототипа круг задач, стоящих перед разработчиками, постепенно расширяется: добавляются такие моменты, как юзабилити, исправление ошибок, поиск более эффективных алгоритм работы, оптимизация и т.д.
Результатом выполнения данной стадии является получение законченного прототипа будущей МИС, подсистемы или новой функции. Прототип должен быть протестирован внутри компании-разработчика и задокументирован.
Внутреннее тестирование – обязательный этап разработки продукта. Его задача состоит в том, что довести прототип системы до состояния, пригодного для опытной (пробной) эксплуатации. На практике применяются различные методы тестирования, включая функциональное, нагрузочное и т.д. В результате этой работы выявляются и устраняются ошибки в ПО, выверяется интерфейс созданного прототипа, уточняются реакции системы на различные, в том числе нештатные действия пользователей.
Тестирование разделяется в свою очередь на 2 основных подэтапа:
• альфа-тестирование – это логическая проверка системы, включая проверка входных и выходных данных, наличие исключительных ситуаций в работе МИС, утрата данных или невозможность доступа к системе или ее данным и т.д.
• бета-тестирование – сплошная проверка системы, нагрузочное тестирование и т.д. на этом этапе специалисты компании-разработчика оценивают готовность системы к установке и применению внедренцами или Заказчиком.
По результатам этапа разработки должна быть получена информационная система или пакет обновления существующего продукта, полностью готовые к установке и изучению его силами ИТ-специалистов Заказчика. При этом обратим внимание – что продукт должен быть готов именно к изучению, а не к установке и началу реальной работы с ним реальных пользователей – в этой тонкости очень часто лежит причина конфликтов между разработчиком и Заказчиком. Часто представители Заказчика относятся к получаемой новой функции или новому продукту как к чему-то, что должно сразу решить все задачи реальных пользователей и не хотят признать, что для того, чтобы выйти на реальное внедрение, особенно в сложных задачах, требуется и их участие, связанное с изучением новой системы (функции), уточнению и оценки ее готовности и только после этого – решению об установке в промышленную среду или направлении на доработку.
4. Внедрение
Этап внедрения всегда разделяется на 3 обязательных подэтапа:
• Инсталляция
• Опытная эксплуатация
• Промышленная эксплуатация
4.1. Инсталляция
На этом этапе осуществляются процессы оценки инфраструктуры, установка общесистемного и прикладного ПО, его первичная настройка. Нередко в данный этап также включается первичный аудит пользователей и администраторов системы, их первичное или специальное предварительное обучение (например, основам работы с ПК для пользователей или основам администрирования СУБД или ОС для обсуживающего персонала).
4.2. Опытная эксплуатация
Опытная эксплуатация - это комплексная проверка готовности системы силами Заказчика. Опытная эксплуатация имеет своей целью проверку алгоритмов, отладку программ и технологического процесса обработки данных в реальных условиях на стороне и инфраструктуре Заказчика с целью анализа соответствия системы изначальному ТЗ и последующему решения вопроса о возможности передачи системы в промышленную эксплуатацию. Например, в статье «Проект vs Эксплуатация», говорится о том, что результаты опытной эксплуатации «…служат исключительно для сопоставления с результатами старой либо для сопоставления с бизнес-требованиями заказчика (если система разрабатывается не для замены существующей). Отличительный критерий понятия «опытная эксплуатация» — результаты работы системы на этом этапе не должны использоваться в реальной деятельности предприятия»
В документах, регулирующих внедрение ERP систем (например Oracle – ABM), вообще считается, что « …опытная эксплуатация подразумевает под собой тестовый режим системы в ходе которого устраняются неполадки, мелкие доработки и настройки».
Опытная эксплуатация должна проводится соответствующими уполномоченными специалистами Заказчика (или Партнера) с целью изучения эксплуатационных свойств системы, главным образом ее надежности, в данных конкретных условиях (на оборудовании заказчика, при администрировании и применении системы настоящими администраторами и пользователями).
Основная задача опытной эксплуатации – это испытание системы. Данный процесс (испытание) регулируется ГОСТ 34.603-92 «Виды испытаний автоматизированных систем» .
Опытная эксплуатация может быть автономной (когда проверяется работа какой-то отдельной подсистемы или компонента) или комплексной (когда проверяется вся система в целом).
Для планирования проведения всех видов испытаний разрабатывают документ «Программа и методика испытаний». Разработчик документа устанавливается в договоре или ТЗ.
Опытная эксплуатация может, в свою очередь, включать в себя 3 стадии:
- Предварительные испытания, проводят для определения ее работоспособности и решения вопроса о возможности приемки МИС в опытную эксплуатацию. Проводятся после проведения разработчиком отладки и тестирования МИС и представления им соответствующих документов, а также после ознакомления персонала Заказчика с эксплуатационной документацией.
- Опытные испытания проводят с целью определения фактических значений количественных и качественных характеристик МИС и при условии готовности персонала Заказчика к работе в условиях функционирования (включая готовность инфраструктуры, пройденное необходимое предварительное обучение и других условий), определения фактической эффективности системы, корректировке (при необходимости) документации и исправлении выявляемых со стороны коллектива, осуществляющего внедрение, ошибок.
- Приемочные испытания проводят для определения соответствия МИС техническому заданию, оценки качества опытной эксплуатации и решения вопроса о возможности приемки МИС в постоянную (промышленную) эксплуатацию
Во время опытной эксплуатации МИС проверяют:
1) Качество выполнения программным продуктов автоматических функций во всех режимах функционирования согласно ТЗ на создание
2) Знание персоналом эксплуатационной документации и наличие у него навыков, необходимых для выполнения установленных функций во всех режимах функционирования МИС, согласно ТЗ на создание
3) Полноту содержащихся в эксплуатационной документации указании персоналу по выполнению им функций во всех режимах функционирования МИС согласно ТЗ
4) Количественные и (или) качественные характеристики выполнения автоматических и автоматизированных функций МИС в соответствии с ТЗ
5) Другие свойства МИС, которым она должна соответствовать по ТЗ.
Во время опытной эксплуатации МИС в обязательном порядке ведут реестр (рабочий журнал), в который заносят сведения о продолжительности функционирования МИС, отказах, сбоях, аварийных ситуациях, изменениях параметров объекта автоматизации, требуемых и выполняемых корректировках (доработках) документации и программных средств, наладке, технических средств. Сведения фиксируют с указанием даты и ответственного лица. В данный реестр (журнал) могут быть занесены замечания персонала по удобству эксплуатации МИС или предложения по доработкам будущих версий.
Важнейшим требованием к опытной эксплуатации является конечность этого этапа. Часто бывает так, что Заказчики, не желая принимать на себя ответственность за возможные допущенные ошибки в ПО или неудобство работы для пользователей и иные риски – искусственно затягивают процесс опытной эксплуатации на бесконечные сроки или отказываются ограничить данный этап какой-то датой. Такое отношение является недопустимым. Опытная эксплуатация обязательно должна быть ограничена заранее определенным периодом времени. Если поставка и внедрение системы осуществляется по договору, то в нем должны быть указаны сроки и обязанности не только Разработчика и этапа создания системы, но и сроки опытной эксплуатации и обязанности Заказчика по этому этапу.
Опытная эксплуатация всегда заканчивается оформлением соответствующего «Акта о завершении опытной эксплуатации», в котором дается заключение о соответствии системы требованиям ТЗ и возможности оформления акта приемки МИС в промышленную эксплуатацию. Если представленная система признается непригодной для промышленной эксплуатации, в акте указывается конечный и детально расписанный перечень замечаний, которые Разработчик должен устранить до определенной даты и передать доработанный вариант МИС Заказчику.
Иногда в практике работы применяется термин «опытно-промышленная эксплуатация», смысл которого состоит в том, что по результатам завершения опытной эксплуатации систему можно без повторной инсталляции и новой «чистой» настройки передать в промышленную эксплуатации. Тем не менее – все требования, описанные выше для «опытной эксплуатации» - справедливы и для «опытно-промышленной эксплуатации», с той лишь разницей, что за использование результатов опытной эксплуатации ответственность несет Заказчик, а опытно-промышленная эксплуатация отличается тем, что получаемые результаты уже не вызывают сомнений и используются для принятия решений. Другими словами, если Заказчик или Разработчик не могут гарантировать достоверность результатов работы системы – это опытная эксплуатация. Если Заказчик принимает решение доверять результатам работы системы – он может называть данный этап «опытно-промышленной эксплуатаций». Однако даже по результатам «опытно-промышленной эксплуатации» система еще не принята в реальную работу обслуживающей службой под свою ответственность, она все еще находится в зоне ответственности Разработчика, который оперативно исправляет ошибки, вносит изменения, производит доработки, непосредственно в системе оптимизирует конфигурационные или настроечные файлы, уточняет документацию и т.д.
В любом случаем, общепринятым правилом как «опытной эксплуатации», так и «опытно-промышленной эксплуатации» является то, что Заказчик может отказаться от новой функции или системы и вернуть ее на доработку в соответствии с техническим заданием или согласованным с Разработчиком конечным перечнем замечаний. Аналогично и Разработчик имеет право отозвать систему из опытной (или даже опытно-промышленной) эксплуатации для необходимых изменений без несения ответственности за возможный ущерб Заказчику.
4.3. Промышленная эксплуатация
Промышленная эксплуатация – это первая полноценная ежедневная работа пользователей с новой системой (функций, подсистемой). Принятие решения о вводе системы в промышленную эксплуатацию осуществляется с определенной даты, в виде формального документа с доведением до сведения сотрудников Заказчика. Задача «Промышленной эксплуатации» состоит в подведении итогов проекта внедрения МИС, включая определение – были ли достигнуты поставленные в Техническом задании на разработку (или внедрение) цели проекта, имеются ли какие-то предложения по дальнейшему развитию системы и т.д.
Теоретически, после завершения промышленной эксплуатации система «… должна работать без единого замечания и сбоя не менее заранее установленного и заведомо длительного срока. Желание службы эксплуатации [Заказчика] принять для сопровождения систему без единой («последней») ошибки понятно и объяснимо. Но неизбежность ошибок программного обеспечения, имеющего заданный уровень сложности, можно считать доказанной. Известно, что график количества неисправностей, отказов, сбоев, ошибок в работе системы относительно времени их обнаружения (возникновения) имеет вид корытообразной кривой, в начале и в конце эксплуатации они возникают чаще, в середине их количество минимально».
В связи с этим этап промышленной эксплуатации в любом случае должен быть конечен – для него должна быть определена дата завершения. Ждать, пока система будет 100% исключать вероятность ошибок или удовлетворять любым требованиям пользователей в рамках промышленной эксплуатации в реальной жизни невозможно. Срок данного этапа регулируется договорными отношениями между Заказчиков и Разработчиком МИС. Общепринятой практикой считается, что данный срок должен составлять порядка 3 месяцев.
Как правило, переводе системы в «промышленный» режим работы резко увеличивается нагрузка на систему. Это позволяет выявить, существовали ли какие-то скрытые технологические проблемы, которые не были обнаружены на этапе «опытной эксплуатации» почти сразу, в течение первых же недель или даже дней. Этот этап — критически важен для проекта внедрения. На этапе собственно промышленной эксплуатации информационная система находится в состоянии «настроено, отлажено и работает», необходимый уровень готовности системы к применению и ее соответствия ТЗ достигнут. Но поскольку многопользовательская информационная система представляет собой довольно сложный организм, живущий насыщенной событиями жизнью, мониторинг качества работы системы и выявление потенциальных проблем производительности должны выполняться на регулярной основе. На этапе промышленной эксплуатации возможно выявление ошибок, которые должны определенным образом фиксироваться и устраняться как можно быстрее либо обсуживающим персоналом системы, либо при невозможности это сделать самостоятельно – передачей этих сведений разработчику.
По результатам завершения промышленной эксплуатации согласовывается и подписывается письмо о закрытии проекта (отзыв об успешном внедрении), система передается на регулярное сопровождение, обсуждаются планы по возможному дальнейшему развитию информационной системы.
Конечным результатом стадии «Промышленная эксплуатация» является информационная система, в которой ведется постоянная ежедневная работа пользователей. Программный продукт, который завершил стадию опытной эксплуатации, а затем и промышленной эксплуатации – считается полностью готовым и внедренным. После завершения срока промышленной эксплуатации он передается на этап технического сопровождения, который также имеет свои особенности и правила взаимодействия, лучше и детальнее всего описанные методикой ITIL.
5. Сопровождение
Общепринято, что процесс сопровождения (который еще иногда называют техническим сопровождением) МИС наилучшим образом регулируется библиотекой ITIL.