Когда у Джен Шитц, администратора амбулаторного онкологического центра MD Anderson в Хьюстоне, спросили о пожеланиях в отношении системы обработки врачебных предписаний, направленных на реабилитацию пациентов, она не стала скромничать. Помимо всего прочего, идеальная система, как считает Шитц, должна уметь генерировать электронную подпись врача, которая необходима для обработки страховых документов и требований Medicare. Сегодня с получением такой электронной подписи зачастую возникают трудности.

"Мы долго мечтали об этом", — поясняет Шитц. — Сейчас у нас проводятся электронные консультации, но по их результатам никаких снабженных подписями предписаний не выдается. Поэтому часть работы приходится выполнять вручную. После ввода в действие новой процедуры у медицинского персонала появится возможность оперировать электронными документами и предписаниями за подписью врача".

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

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

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

Важность требований

"Трудности при попытке заинтересованных лиц изложить свои требования разработчикам программного обеспечения возникали всегда, — заметила Мелинда-Кэрол Баллу, аналитик IDC. — В этом нет ничего нового. Однако в условиях нынешнего экономического спада эти противоречия приобретают гораздо более острый характер".

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

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

В современных условиях возникает настоятельная потребность в улучшении взаимодействия заказчиков и разработчиков. Аналитики исследовательской фирмы Standish Group отмечают, что с 2006 по 2008 годыгод доля успешно реализованных проектов заметно сократилась. (Исследование Standish проводится с интервалом в два года, самая свежая из доступной сегодня информации датируется 2008 годом; результаты нового исследования будут опубликованы в начале 2011года ). В 2008 году только 32% из общего числа проектов были успешно завершены. Это означает, что они были реализованы в установленные сроки и в рамках отведенного бюджета, включали в себя все необходимые функции и отвечали заранее определенным требованиям. В 2006 году успех сопутствовал 35% проектов.

В 2008 году 44% проектов не уложились в заданные сроки, вышли за границы бюджета или не включали в себя всех требуемых функций и возможностей, а 24% завершились полным провалом. В 2006 году доля таких неудачных проектов составляла лишь 19%.

"В последнее время условия разработки заметно изменились, — констатировал Джим Джонсон, председатель совета директоров Standish Group. — Экономическая ситуация заставляет людей переоценивать проекты, реализация которых уже началась. Например, некоторые проекты, над которыми велись работы, пришлось отменить из-за того, что они не соответствовали пересмотренным целям компаний. Думаю, что при определении требований и реализации механизмов управления разработчики зашли слишком далеко, и проекты получились настолько сложными, что с их внедрением исполнители просто не справились. Здесь очень важно вовремя найти оптимальный баланс, вот с этим-то и возникли трудности".

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

"Специалистам ИТ-служб хорошо известно, что управление процессом разработки программного обеспечения нужно совершенствовать, — указал Том Грант, аналитик Forrester Research. — Растет понимание того, что для решения этой задачи требуются инвестиции, ведь на переработку проектов тратится очень много времени. Однако инструменты для определения требований, которые позволили бы исправить сложившуюся ситуацию, так и не получили широкого распространения".

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

Объем рынка инструментов, служащих для определения требований, и управляющего программного обеспечении в 2008 году оценивался в 207 млн.млн долл., это на 7% больше, чем в 2007 году. Согласно прогнозам Баллу, при сохранении существующих финансовых условий к 2013 году объем этого рынка достигнет 290,6 млн.млн долл.

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

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

Правильно с самого начала

"Мы давно поняли, что затраты на поддержание тесных контактов с бизнес-пользователями при определении требований к разрабатываемым системам в конечном итоге окупят себя, — отметил вице-президент United Parcel Service (UPS) по вопросам построения информационных систем Марк Хилбуш. — Идея заключается в том, чтобы представить проект как можно более наглядно, атогда бизнес-пользователям будет¤¤ легче был понять, что же мы собираемся строить. Подобный подход сулит ощутимые выгоды, помогая неанглоязычным людям заранее ознакомиться с интерфейсом программного обеспечения и убедиться в том, что никакие ключевые требования не были упущены".

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

"Благодаря средствам визуализации нам удалось продемонстрировать прототипы пользователям в США, Европе и Юго-Восточной Азии, — сообщил Хилбуш. — Таким образом, в процесс определения требований было вовлечено гораздо больше людей, чем обычно".

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

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

"Инструмент iRise способен оказать неоценимую помощь в деле улучшения качества, — указал Тони Бальдассари, старший менеджер проекта UPS Package Project Management (PPM). — Общение у нас далеко не всегда ведется на английском языке. А при получении от пользователей комментариев к документу, определяющему требования, многие нюансы теряются при переводе. Отправляя прототип, позволяющий увидеть, как будет выглядеть система, мы получаем гарантии того, что все будет сделано правильно уже в первой итерации.
Теперь не нужно рассылать множество электронных писем с комментариямкомментариями и устраивать обзорные телеконференции".

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

"У людей была возможность оценить все визуальные компоненты, включая экраны, ссылки, навигационные элементы, размещенные на страницах, а также внешний вид пользовательского интерфейса, — отметил Бальдассари. — После того как комментарии стали размещаться в среде iRise, мы смогли собирать отзывы, консолидировать их и вносить изменения в проект еще до отправки очередной порции снимков экрана. Это позволяет очень быстро переходить от одной итерации к другой, оперативно получать необходимые комментарии. К моменту определения окончательного варианта требований мы абсолютно уверены в том, что удовлетворили пожелания всех пользователей. После обсуждения с пользователями все нюансы доводятся до ИТ-специалистов. Такой подход помогает сэкономить время на стадии разработки".

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

Члены проектной команды обнаружили, что с некоторыми элементами инструментальных панелей у пользователей возникают затруднения — им тяжело связать их с бизнес-процессами. Конечная же цель заключается в том, чтобы предоставить пользователю возможность быстро оценить эффективность выполнения всех операций в целом и построить графики анализа тенденций, возникающих при обработке, сортировке и транспортировке посылок. Компания UPS использует программное обеспечение iRise для сбора информации при подготовке требований как к своим внутренним системам, так и к приложениям, к которым клиенты UPS обращаются через Интернет. Инструмент iRise помогает проектировать фактически любую систему, имеющую пользовательский интерфейс. В 2009 году он применялся в 43 из 47 проектов UPS.

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

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

Используйте, иначе потеряете

Сотрудники онкологического центра MD Anderson применяли iRise в ходе разработки собственной системы электронных медицинских карт (electronic medical records, EMR) названной Clinic Station. В настоящее время iRise используется сразу в нескольких подразделениях медицинского центра для моделирования улучшения потоков работ в рамках технологических процессов. В результате у персонала появится возможность больше времени уделять пациентам.

"Наша клиника специализируется на онкологических заболеваниях, и готовые системы EMR не отвечают нашим потребностям, поскольку ориентированы они на центры скорой помощи, — пояснила Шерри Престон, возглавляющая в коллективе разработчиков системы электронных медкарт MD Anderson группу бизнес-анализа. На протяжении восьми лет в клинике пытаются внедрить три разные системы EMR, но ни одна из них до сих пор не работает. — В нашем случае самое страшное — это потоки работ".

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

"Это имело очень важное значение, потому что нам нужно было формулировать и документировать требования, разбираться в технологических процессах всех подразделений клиники", — пояснила Престон, работавшая в центре MD Anderson медсестрой на протяжении 26 лет.

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

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

По оценкам Престон, медицинский центр потратил на закупку iRise не более 300 тыс. долл. Недостатков в этом инструменте, по мнению пользователей, немного. Другое дело, что изучение порядка работы с ним требует существенных затрат времени. Но, "не используя, вы его потеряете", поскольку работа с программным обеспечением разбивается на несколько этапов. В настоящее время в медицинском центре работают 17 бизнес-аналитиков, использующих iRise на регулярной основе.

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

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

По словам Хилбуша, «ключевой извлеченный урок заключается в том, что имитационное моделирование iRise нужно использовать на ранних стадиях проектирования, привлекая к этому как бизнес-пользователей, так и разработчиков. Как правило, моделированием на основе iRise занимаются бизнес-аналитики. А поскольку в UPS бизнес-аналитики относятся к команде разработчиков, разработчики также принимают участие в этом процессе, не отказываясь от творческой деятельности. Если все сделано хорошо, процесс остается открытым и создаются хорошие условия для взаимодействия".

"За счет имитационного моделирования нам удалось сократить время разработки на 25%, — сообщила Линн Фогель, вице-президент и ИТ-директор MD Andersen. — Мы мечтаем о том, чтобы весь код генерировался в ходе моделирования. Но это очень сложный процесс. Ведь программирование — не только наука, но и искусство".