Глава 11 3 страница

Мы провели однодневное вступительное совещание, на котором присутство­вали участники группы оценки, руководитель проекта, главный архитектор, а также руководитель проекта первого покупателя Nightingale. Троих последних можно причислить к категории лиц, ответственных за проект. В результате мы узнали много нового о возможностях системы и требованиях к ней, получили каталог готовой архитектурной документации (из которого мы выбрали нужные для на­ших целей документы) и составили список заинтересованных лиц, которых пред­полагалось пригласить во время проведения второго этапа. Кроме того, мы согла­совали график проведения совещаний на первом и втором этапах и установили срок предоставления сводного отчета. Наконец, мы обговорили подробности пре­зентаций, которые во время операций 2 и 3 первого этапа должны были сделать руководитель проекта и архитектор соответственно, и убедились в том, что им понятно, что мы хотим от них услышать.

¹ Шесть оценщиков — это много. Как мы уже говорили, п группу оценки, как правило, входят от трех до пяти специалистов; и среднем — четыре. В данном случае группу расширили за счет двух новых сотрудников, которым предстояло ознакомиться с процессом АТАМ более подробно и на практике наработать опыт.

 

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

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

Этап 1: оценка

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

Операция 1: презентация АТАМ

В ходе презентации руководитель специалистов по оценке обратился к стандарт­ному пакету схем нашей организации и с его помощью объяснил присутству­ющим суть метода. На протяжении часа он рассказывал им об операциях и эта­пах АТАМ, описывал концептуальные основы метода (сценарии, архитектурные методики, точки чувствительности и т. п.) и перечислял продукты, которые пред­полагалось получить в результате его проведения.

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

Операция 2: презентация коммерческих факторов

Руководитель проекта от компании-заказчика изложил коммерческие задачи, поставленные перед системой Nightingale компанией-разработчиком и потенци­альными заказчиками. Как выяснилось, компания-разработчик предъявляла к Nightingale следующие требования:

♦ поддержка различных вариантов использования системы дебютным заказ­чиком (в частности, отслеживание историй болезни и платежных историй, выявление тенденций и т. д.);

♦ создание новой версии системы (предназначенной для установки в кабине­тах врачей), которую компания-разработчик могла бы предлагать другим заказчикам.

Последний коммерческий фактор свидетельствовав! о том, что на основе рас- сматриваемой архитектуры планировалось не просто разработать отдельную си­стему, а учредить целую линейку программных продуктов (см. главу 14).

Первый заказчик Nightingale планировал развернуть ее взамен существующих систем, которые:

♦ устарели (одной из них было больше 25 лет);

♦ были основаны на старых языках и технологиях (в частности, COBOL и ас­семблере IBM);

♦ оказались неудобными по части сопровождения;

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

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

♦ способность реагировать на культурные и региональные различия;

♦ поддержка нескольких языков (в основном английского и испанского) и ва­лют (в особенности американского доллара и мексиканского песо);

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

♦ новая единая система должна была сочетать в себе разнородные унаследо­ванные системы управления финансами.

Коммерческие ограничения были таковы:

♦ соблюдение принципа неувольнения сотрудников, осуществляемого путем их переподготовки;

♦ приверженность принципу разработки «лучше купить, чем сконструиро­вать»;

♦ учет сокращения рыночного положения заказчика (за счет повышения кон­куренции).

Технические ограничения были сформулированы следующим образом:

♦ при любой возможности предпочтение следовало отдавать коробочным программным компонентам;

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

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

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

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

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

Нижеследующие атрибуты качества руководитель проекта признал важными, но не в такой степени, как вышеперечисленные:

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

♦ Готовность. В рабочие часы от системы требовалось высокая готовность.

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

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

♦ Контролепригодность и удобство поддержки. Система должна была быть доступной для понимания техническими специалистами в штате заказчи­ка; такая необходимость обусловливалась перспективами обучения персо­нала и продолжительного использования.

Операция 3: презентация архитектуры

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

♦ В составе Nightingale было две крупные подсистемы: диспетчер оператив­ных транзакций (OnLine Transaction Manager, OLTM) и диспетчер приня­тия решений и составления отчетов (Decision Support and Report Generation Manager, DSRGM). OLTM должен был отвечать требованиям по интерак­тивной производительности, a DSRGM исполнял роль системы пакетной обработки, исполнявшей периодически инициируемые задания.

♦ При конструировании системы Nightingale в ней предусматривалась высо­кая конфигурируемость.

♦ Подсистема OLTM состояла из нескольких четко разделенных уровней.

♦ Nightingale была системой репозитарного типа; ее основу составляла круп­ная коммерческая база данных.

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

♦ Для Nightingale было характерно строгое следование объектно-ориентиро­ванной технологии и реализация конфигурируемости по большей части за счет объектных каркасов.

Рис. 11.2. Многоуровневое представление OLTM, изображенное архитектором в неформальной нотации

 

На рис. 11.2 показано многоуровневое представление OLTM, изображенное архитектором в неформальной нотации. На рис. 11.3 представлена схема функ­ционирования OLTM в период исполнения — основные потоки информации и дан­ных между частями системы, размещенными на различных аппаратных процес­сорах. Обе схемы мы приводим почти без изменений, для того чтобы наилучшим образом отразить реальные условия проведения оценки по методу АТАМ. Обра­тите внимание на их неполное соответствие — на рис. 11.2 диспетчер транзакций и CORBA присутствуют, а на рис. 11.3 их нет. Подобного рода упущения во вре­мя оценки случаются сплошь и рядом, и в этом смысле значительную важность представляет один из шагов третьей операции, во время которого оценщики, пытаясь лучше понять архитектуру, задают вопросы о несоответствиях на диа­граммах. Аналогичное представление периода прогона для OLTM, где любую транз­акцию можно проследить в масштабе всей системы, показано на рис, 11.4; здесь,

Рис. 11.3. Представление, изображающее передачу информации, потоки данных и процессоры OLTM

 

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

Все перечисленные представления системы Nightingale в равной степени ра­зумны и несут важную смысловую нагрузку. На них изображены отдельные ас­пекты, значимые в контексте различных задач. Все они впоследствии были за­действованы при проведении аналитических действий в рамках АТАМ.

Операция 4: выявление архитектурных методик

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

♦ многоуровневая организация, в особенности в OLTM;

♦ объектно-ориентированная технология;

♦ реализация модифицируемости через конфигурационные классы без запи­си или перекомпиляции;

♦ обработка транзакций по схеме «клиент-сервер»;

Рис. 11.4. Архитектурная проекция потока данных внутри OLTM

 

♦ информационно-ориентированный архитектурный образец с коммерческой базой данных в качестве основы.

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

Операция 5: генерация дерева полезности атрибутов качества

Дерево полезности, составленное во время проверки системы Nightingale по ме­тоду АТАМ, представлено в табл. 11.5. Обратите внимание — на нем присутству­ют все атрибуты качества, установленные в ходе операции 2; более того, они уточ­нены до одного или нескольких конкретных значений.

Некоторые уточнения атрибутов качества остались без связанных сценариев.

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

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

¹ Кроме того, мы пробовали составлять деревья полезности к оперативном режиме — заполняли таб­лицы, подобные табл. 11.5, и проецировали их непосредственно с компьютера. При таком подходе дерево легче составлять и корректировать, однако доступным для просмотра участниками остается содержание одного-сдинственного экрана. В то же время обзор дерева во всей его полноте стимули­рует умственную деятельность и помогает находить бреши. Программные системы для совместной работы будто бы идеально подходят для подобных ситуации, однако по простоте, надежности и эко­номичности им сложно тягаться с лекционными плакатами и клейкой лентой.

 

Таблица 11.5, Дерево полезности, составленное в ходе оценки системы Nightingale по методу АТАМ, в табличном выражении Атрибут качества Уточнение атрибута Сценарии Производитель­ Время отклика В ответ на уведомление о смене адреса при пиковой ность на транзакцию нагрузке на систему пользователь обновляет учетную запись пациента; транзакция завершается менее чем за 0,75 секунды (В,С) В ответ на уведомление о смене адреса при нагрузке на систему, в два раза превышающей текущую пиковую, пользователь обновляет учетную запись пациента; транзакция завершается менее чем за 4 секунды (Н,С)   Пропускная При пиковой нагрузке системе удается проводить   способность 150 нормализованных транзакций менее чем за секунду (С,Н)   Составление отчетов Предложений по сценариям не последовало Практичность Повышение Новый сотрудник с одним или двумя годами опыта   квалификации работы в отрасли осваивает базовые функции системы менее чем за неделю (С,Н) Пользователь, находясь в определенном контексте, запрашивает справку и получает ее (В,Н)   Нормальный режим Больничный кассир запускает для пациента,   работы с которым одновременно общается, план выплат; процесс завершается без каких-либо задержек по вине системы (С,С) Конфигуриру­   Больница повышает цену на отдельную услугу. емость   Группа конфигураторов вносит в систему соответствующие изменения, затрачивая не более одного рабочего дня и не затрагивая исходный код (В,Н) Удобство   Обнаружив недостатки, связанные с поиском сопровождения   и временем отклика, специалист по сопровождению исправляет ошибку и распространяет исправление ------------------------------------ продолжение

 

Таблица 11.5 (продолжение) Атрибут качества Уточнение атрибута Сценарии   Требование по отчетности подразумевает внесение изменений в метаданные составления отчетов (С.Н) Производитель базы данных выпускает ее новую версию, на установление которой затрачивается минимальное количество времени (В,С) Расширяемость Введение нового Создается новый продукт, отслеживающий доноров продукта банка крови (С,С) Безопасность Конфиденциальность Полномочия физиотерапевта позволяют ему просматривать содержимое регистрационной карточки пациента, связанное с ортопедическим лечением; остальные элементы карточки, равно как и финансовая информация, для него закрыты (В,С) Целостность Система успешно противостоит попыткам несанкционированных вторжений (В,С) Готовность Выпущенное производителем баз данных новое программное обеспечение вводится в систему методом горячей замены (В,Н) Система обеспечивает возможность ежедневного круглосуточного доступа пациентов к своим учетным записям через Интернет (Н,Н) Масштабиру­ Расширение системы Первый заказчик системы приобретает компанию, емость масштаб которой превышает его собственные показатели в три раза; при этом требуется провести разбиение базы данных (Н,В) Первый заказчик системы продает другой компании одно из своих подразделений (Н,С) Первый заказчик системы проводит слияние двух своих подразделений (Н,С) Компания-разработчик желает продать ряд компонентов системы Nightingale (С,Н) Модульность Функциональные Требуется сконструировать систему таким образом, подмножества чтобы она могла работать автономно и при этом предоставлять свою базовую функциональность (С,Н) Гибкость в отношении Замена коммерческой базы данных одного замены коробочных производителя коммерческой базой данных другого продуктов производителя (В,С) Замена операционной системы (В,С) Замена уровня переносимости базы данных {В,С) Замена диспетчера транзакций (В,С) Замена механизма автоматизации документооборота (В,С) Замена коммерческого бухгалтерского пакета (В,С) Замена базы данных Solaris, размещенной на платформах Sun (В,С) Замена процессора правил (В,С)

 

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

 

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

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

Операция 6: анализ архитектурных методик

Сценарии с приоритетом (В,В) — иначе говоря, отличающиеся высокой значи­мостью и трудностью реализации и в связи с этим заслуживающие особого вни­мания в ходе анализа — на дереве полезности отсутствуют. По этой причине мы перешли к поиску сценариев с приоритетом (В,С). Оказалось, что они в изоби­лии представлены в группе атрибута «модульность» и связаны с заменой в соста­ве системы разного рода коробочных продуктов. Несмотря на то что эти продук­ты были введены в систему целенаправленно, в соответствии со стратегией снижения рисков разработки для руководителей проекта это решение вылилось в нескончаемую головную боль — ведь все вело к тому, что система (а значит, и ее покупатели) подпадет под влияние многочисленных производителей. Следо­вательно, в их собственных интересах было реализовать гибкость архитектуры, которая позволила бы без труда заменять коробочные продукты.

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

♦ Замена одной коммерческой базы данных другой, приобретенной у нового производителя, обещала стать трудным занятием. В масштабе всей систе­мы использовался один из диалектов SQL (надмножество SQL по стандар­ту ANSI), специфичный для производителя текущей базы данных, а также ряд не менее специализированных инструментов и компонентов. По мне­нию архитектора, замена базы данных была бы крайне маловероятна, в связи

с чем он не брал в расчет высокую стоимость перехода на новую систему. Впрочем, руководитель проекта не выказал столь же твердой уверенности в невозможности развития событий по рассматриваемому сценарию. Таким образом, мы зафиксировали первый установленный на основе анализа ар­хитектурный риск: «Поскольку в системе Nightingale используются специ­фичные для конкретного производителя инструменты и компоненты, а также диалект SQL не поддерживаемый или несовместимый с базами данных других производителей, произвести замену базы данных будет очень слож­но и отнюдь не дешево — весь процесс займет несколько человеко-лет». Архитектурное решение о связывании архитектуры с конкретной базой дан­ных мы обозначили как точку чувствительности с отрицательным воздей­ствием на модифицируемость.

♦ Заменить одну операционную систему другой было бы довольно просто. На стороне сервера операционная система была выделена на отдельный уровень, что способствовало локализации изменений. С другой стороны, подсистема OLTM напрямую зависела от средств аутентификации NT, а значит, от новой операционной системы требовались аналогичные свой­ства. Что касается DSRGM, то здесь все зависимости от операционной си­стемы были исключены на уровне исходного кода — дело в том, что разра­ботка этой подсистемы проводилась на платформе Windows NT, а размещена она была на платформе UNIX; отсюда очевидный вывод о ее полной неза­висимости от операционной системы. В связи с этим мы зафиксировали первое нерискованное решение: «Поскольку зависимости от операционной системы в подсистемах OLTM и DSRGM локализованы или исключены, введение новой операционной системы вместо старой не предполагает сколь­ко-нибудь серьезных модификаций». Инкапсуляцию зависимостей от опе­рационной системы мы отметили как точку чувствительности с положи­тельным воздействием на модифицируемость.

♦ Мы установили ряд проблем, связанных с внесением изменений в процес­сор правил. Считать такой сценарий надуманным нет никаких оснований — как мы выяснили, текущий процессор не отличался высокими характерис­тиками производительности и удобства сопровождения. Вероятнее всего, впоследствии его бы просто исключили, а правила реализовали бы сред­ствами C++. Поскольку прямое построение цепочек правил не разрешалось (что было вполне разумно и объяснялось желанием отложить соответству­ющее решение на более поздний период), правила в силу их процедурного характера можно было скомпилировать. Подобная модификация, скорее всего, привела бы к нескольким серьезным последствиям.

- Повышение производительности (хотя бесспорного решения эта проб­лема на тот момент еще не получила).

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

- Группе разработчиков не пришлось бы создавать полезные правила и сре­ду моделирования.

- Правила, возможно, «закопались» бы в код C++ и сплелись с функцио­нальным кодом, не имеющим прямого отношения к правилам; отсюда — затруднения по части их обнаружения и сопровождения.

- Возможность размещения в правилах ссылок на несуществующие объек­ты, вероятно, удалось бы исключить. В современном варианте эта воз­можность, обусловливавшая возникновение ошибок, существовала и имела серьезные шансы, просочившись через тестирование, попасть в произ­водственную систему. Путем составления правил средствами C++ по­добные ошибки можно было бы устранить уже в период компиляции.

 

В расчете на подобные изменения можно было написать генератор правил в виде кода C++. Против такого решения свидетельствовали существен­ный объем работ и их сложность, остававшаяся неизвестной. Итак, для рассмотренного сценария мы зафиксировали риск, связанный с трудностью исключения процессора правил. Сам факт применения этого процессора (в противоположность коду C++) мы обозначили как точку компромисса в архитектуре — ведь упрощение разработки и внесения изменений в базу правил достигалось за счет снижения производительности, необходимости в подготовке персонала и усложнения тестирования.

И так далее. Впоследствии, в рамках того же сценария, мы проанализировали замену коммерческого блока веб-хостинга, коммерческого бухгалтерского паке­та, механизма автоматизации документооборота и операционной системы Solaris на платформах Sun,

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

Этап 2: оценка (продолжение)

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

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

В первую очередь, специально для новых участников, мы повторили первую операцию (описание метода АТЛМ), а для того чтобы привести знания всех при­сутствующих к единому знаменателю, рассказали о результатах первого этапа. После этого мы приступили к выполнению операций 7, 8 и 9.

 

Операция 7: мозговой штурм и расстановка сценариев согласно приоритетам

Заинтересованные лица поработали на славу — всего в ходе этой операции о*ни огласили 72 сценария. Более десятка из них были отражены на листьях дерева полезности, которое мы составили во время операции 5, но на первом этапе до их анализа дело не дошло. Это вполне нормально, даже полезно. Таким способом заинтересованные лица давачи нам понять, что некоторые сценарии заслужива­ют большего внимания, чем то, которое они получили на первом этапе.

В табл. 11.6 приводятся наиболее интересные из всех сценариев, зафиксиро­ванных в ходе операции 7. Одни сформулированы на редкость удачно, иные, на­против. не слишком очевидны. Учитывая стихийный характер мозгового штурма, предполагающего активное участие всех присутствующих, в этом нет ничего страш­ного. Чем тратить ценное время на вылизывание каждого сценария, мы предпо­читаем записывать высказываемые соображения сразу, как только они появляются. Если какой-то сценарий перед голосованием или анализом требуется откоррек­тировать, мы с готовностью это сделаем (естественно, не без участия того челове­ка, который его предложил).

Таблица 11.6. Сценарии, полученные методом мозгового шторма   Номер Сценарий   Данные, ранее бывшие общедоступными, сделаны приватными; соответствующие изменения внесены в права доступа   Данные, взятые из информационного ядра, сдублированы в одном из отделений клиники, в результате чего снизилась производительность   При запуске правила в процессоре доступ к данным осуществляется слишком медленно   Пользователь регистрирует проведенный пациентом платеж в момент сильной загрузки системы, в результате чего замедляется реакция (происходит это в тестовой среде)   Пользователю, находящемуся в одном подразделении, требуется выполнить операции от имени других подразделений   Принято решение о поддержке немецкого языка   В систему вводится роль эпидемиолога и соответствующая функциональность   Система Nightingale устанавливается в кабинете с пятью врачами и адаптируется под условия заказчика   Для подачи асинхронных запросов пользователю требуется новое поле   Получив жалобу, сотрудники больницы обнаруживают, что на протяжении последних шести месяцев подкладываемые судна оценивались неверно   Больнице требуется централизовать процесс обслуживания регистрационных карточек в масштабе нескольких отделений; при этом все сопутствующие бизнес-процессы подвергаются реконструкции   Менеджер хочет составить отчет по истории просроченных платежей и пеням, выставленным пациентам, проходившим лечение от порезов и ран   «Условный» (what-if) сценарий: Приложение к учетной записи предполагаемой поправки в закон   Дефект, приведший к искажению данных, не удалось обнаружить до следующего цикла отчетности