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

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

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

При помощи механизма сценариев (см. главу 4) общие (и неоднозначные) формулировки желаемых атрибутов качества конкретизируются и приводятся в форму, позволяющую проводить тестирование. Из них формируются и систе­матизируются по выражаемым атрибутам качества листья дерева полезности. Шестичастная форма, предложенная в главе 4, в данном случае адаптируется к за­дачам оценки. Сценарии АТАМ состоят из трех частей: стимула (наблюдаемое в системе условие, породивший его источник и стимулируемый артефакт систе­мы), среды (все происходящее в данный момент времени) и реакции (реакция системы на стимул, выраженный в измеримой форме).

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

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

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

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

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

ЧТО В ИМЕНИ ТВОЕМ?

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

С другой стороны, дерево полезности АТАМ систематизируется по именам атрибутов каче­ства. Нет ли в этом противоречия? Нам не все равно, какие атрибуты качества заинтересо­ванные лица сочтут наиболее важными. Они вольны называть атрибуты как угодно — если это способствует мыслительному процессу. К примеру, в табл. 11.5, приведенной ниже, раз­делены такие атрибуты, как «конфигурируемость» и «модульность»; у вас есть полное право возразить против такой формулировки — ведь оба указанных атрибута являются подвидами «модифицируемости», а значит, обозначить их следует как уточнения последнего. В принципе, мы с этим согласны. Но в данном случае, по мнению заинтересованных лиц, и тот и другой подвид в силу существенных различий заслуживали отдельных позиций на дереве полезно­сти, и мы не стали с ними спорить. В конце концов, листы-сценарии на дереве полезности значительно важнее структуры ветвей.

Ситуация, при которой одни и те же имена атрибутов качества переходят из одной оцен­ки в другую, встречается очень редко. То, что одна компания называет «удобством сопровож­дения», другая предпочитает именовать «взаимозаменяемостью». Иногда «переносимость» рассматривается как подвид модифицируемости, но во многих других случаях заинтересо­ванные лица предпочитают трактовать эти атрибуты по отдельности. Надежность часто на­зывают готовностью, и наоборот. Помимо всего прочего, нам приходилось сталкиваться с оригинальными именами атрибутов качества, смысл которых был понятен только сотруд­никам конкретной организации, — примерами тому «развертываемость» и «продаваемость». Мы сначала не совсем поняли, что это значит, но, поскольку в АТАМ нет необходимости тра­тить ценное время на терминологические споры, никаких проблем не возникло. Реальное значение атрибутов выражается в сценариях. Самое главное — упомянутые термины были понятны заинтересованным лицам; исходя из этого они могли составить сценарии и тем са­мым сформулировать задачи, которые требовалось решить.

В одном из случаев оценки по методу АТАМ мы столкнулись с довольно оригинальными задачами компании-разработчика — они хотели привлечь новых способных сотрудников к ра­боте в своем центральном офисе, который, на беду, находился в маленьком тихом городке на американском Среднем Западе. Исходя из этого коммерческого фактора они сформули­ровали архитектурную задачу — архитектура должна была опираться на современные про­граммные разработки, которые, как предполагалось, заинтересуют новых специалистов.

Несмотря на то что атрибута качества под именем «lowa-bility» нет ни в одном стандарт­ном перечне IEEE, ISO или ANSI, в нашей практике был случай, когда он нашел свое отраже­ние на дереве полезности АТАМ и заставил специалистов основательно поразмыслить над тем, какие сценарии смогут выразить сформулированную в таком виде задачу.

-РСС

Теперь каждому сценарию соответствует упорядоченная пара наподобие (В,Вы­сокий]), (В,С[редний]), (В,Н[изкий]) и т. д. Самые важные и сложные сценарии требуют выделения значительных временных ресурсов для проведения анализа, а оставшаяся часть будет просто фиксироваться. Сценариям, рассматриваемым

как несущественные (И,*) или легко реализуемые (*,Н), вряд ли будет уделяться слишком много внимания.

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

К рассматриваемому периоду вся необходимая для проведения анализа ин­формация должна быть выражена в табличной форме — в частности, речь идет об ожидаемых значимых атрибутах качества, реализуемых архитектурой и обу­словливаемых коммерческими факторами (операция 2) и деревом полезности (операция 5), а также о самой архитектуре, зафиксированной в виде презента­ции (операция 3) и каталога применяемых методик (операция 4). Пример дерева полезности в табличной форме (без корневого узла) приводится в табл. 11.5.

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

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

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

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

Рис. 11.1. Пример анализа архитектурной методики1   1Источник, приводится по изданию [Clements 02а] (адаптированная версия).

 

На рис. 11.1 изображена стандартная форма, предназначенная для фиксации результатов анализа архитектурной методики применительно к конкретному сце­нарию. Из него следует, что по результатам рассматриваемой операции участни­ки группы оценки устанавливают ряд точек чувствительности и компромиссов, рискованные и нерискованные решения. Любые точки чувствительности и комп­ромиссы потенциально рискованны. К моменту завершения оценки по методу АТАМ их необходимо занести в одну из двух категорий: рискованные и нериско­ванные. Рискованные и нерискованные решения, точки чувствительности и ком­промиссы — все они фиксируются в отдельных списках. Приведенные на рис. 11.1 обозначения R8, ТЗ, S4, N12 и т. д. — это указатели на соответствующие позиции в таких списках.

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

Перерыв и начало второго этапа

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

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

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

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

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

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

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

После сбора сценариев следует операция по расстановке среди них приорите­тов. Такая необходимость вызвана теми же факторами, которые обусловливают назначение приоритетов на дереве полезности, — участники группы оценки долж­ны знать, чему следует уделить ограниченные временные ресурсы. Во-первых, заинтересованных лиц просят соединить воедино сценарии, которые, по их мне­нию, выражают один и тот же тип поведения или одну и ту же задачу по атрибуту качества. Затем путем голосования из числа получившихся сценариев выбираются наиболее важные. Каждому заинтересованному лицу предоставляется количе­ство голосов, составляющее 30 % от общего числа сценариев^[3], после чего полу­ченное число округляется. Так, если сценариев всего двадцать, каждое заинтере­сованное лицо получает по шесть голосов. Распоряжаться ими заинтересованное лицо может произвольно — если потребуется, оно отдаст все шесть голосов за один сценарий, или по одному голосу за'каждый из любых шести сценариев, или примет какое-либо промежуточное решение.

Голосование по сценариям проходит открыто; по нашему опыту, этот способ не только забавен — он способствует укреплению у участников чувства общно­сти. После подсчета голосов руководитель группы оценки сортирует сценарии по количеству поданных голосов и выделяет из них те, за которые проголосовало заметно меньше заинтересованных лиц, чем за все остальные. Сценарии с наи­высшими показателями утверждаются и впоследствии участвуют в дальнейших операциях. Так, к примеру, группа может взять на рассмотрение лишь пять сце­нариев, набравших наибольшее количество голосов.

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

После выявления сценариев и их расстановки согласно приоритетам группа оценки инструктирует архитектора в процессе реализации наиболее ценных (см. опера­цию 7), с точки зрения заинтересованных лиц, сценариев. Архитектор должен

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

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

Операция 9: презентация результатов

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

♦ документированные архитектурные методики;

♦ набор сценариев, сформулированных методом мозгового шторма, и их при­оритеты;

♦ дерево полезности;

♦ выявленные риски;

♦ установленные нерисковаиные решения;

♦ найденные точки чувствительности и компромиссы.

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

Для каждого из установленных магистральных рисков группа определяет на­ходящиеся под его воздействием коммерческие факторы (они должны были быть выявлены в ходе операции 2). Определение магистральных рисков и их связей с конкретными факторами замыкает процесс оценки, поскольку его конечные ре­зультаты соотносятся с первоначальной презентацией. Не менее важно, что оно раскрывает перед ответственными лицами суть установленных рисков. То, что руководитель ранее рассматривал как далекий от практического контекста технический вопрос, теперь со всей очевидностью предстает как угроза, лежащая в зоне его ответственности.

В табл. 11.3 отражены все девять операций АТАМ и показана степень их вли­яния на конечные продукты оценки по этой методике. обозначает операции, которые напрямую воздействуют на эти результаты, а «*» — операции, влияющие на них лишь косвенно.

Таблица 11.3. Коррелированные операции и продукты АТАМ’

 

 

^a В ходе установления коммерческих факторов излагается первоначальное, наиболее общее описание атрибутов качества.

^b Во время презентации коммерческих факторов допускается разглашение ранее выявленных или устойчивых рисков, которые в таком случае необходимо зафиксировать.

^с В своей презентации архитектор может установить дополнительные риски.

^d В своей презентации архитектор может выявить дополнительные точки чувствительности или комп­ромиссы.

^e Стандартные сопутствующие риски характерны для многих архитектурных методик.

^f Многим архитектурным методикам свойственны стандартные сопутствующие варианты чувстви­тельности и компромиссы между атрибутами качества.

^f В ходе рассматриваемых аналитических операций возможно выявление новых архитектурных ме­тодик, не замеченных во время операции 4; в таком случае формулируются новые методико-ориен- тированные вопросы.

 

¹ Источник: приводится по изданию [Clements 02а] (адаптированная версия).

 

 

ИХ РЕШЕНИЕ НЕ ГОДИТСЯ---------------------------------------------------------------------------------------------------

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

Оценщик: Ладно, перейдем к следующему сценарию. Предоставляет ли ваша система такую-то возможность?

Производитель (мило улыбаясь): Конечно! От пользователя требуется лишь ввести но­мер счета, вызвать таблицу дебиторской задолженности и перенести результаты в файл уве­домления спонсора.

Оценщик (одобрительно кивая, проверяя «нерискованность» сценария и радуясь тому, что оценка обещает пройти легче, чем он предполагал): Здорово! Так, теперь следующий сценарий.

Пользователь системы 1 (возмущенно): Секундочку! Вы хотите сказать, что перемещать данные автоматически нельзя? Это что ж получается — мне придется их вводить во все фай­лы уведомлений?

Производитель (с первыми признаками нервозности): Ну-у-у, вы знаете...

Пользователь системы 1 (в оскорбленных чувствах): Да вы знаете, сколько спонсоров у крупного университета вроде нашего?!

Производитель (теребит свой воротник): Что, много?

Пользователь системы 1 (теперь его черед мило улыбнуться): Да! Много.

Пользователь системы 2: А что, если я не знаю, какой номер счета вводить? Операция-то проводится именно по этой причине. В противном случае легче взять расписку об обновле­нии платежа.

Пользователь системы 1 (оценщику): Их решение не годится,

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

Вывод один. Компетентные заинтересованные лица способны выискать проблему, недо­ступную людям со стороны.

-РСС

Эффективное распоряжение ограниченными временными ресурсами

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

 

11.4. Система Nightingale: конкретный пример проведения оценки по методу АТАМ

Конкретный пример, который мы намерены привести в настоящем разделе, осно­ван на нашем собственном опыте проведения оценки; он иллюстрирует процесс практического применения АТАМ. Не считая возможным нарушать конфиден­циальность компании-заказчика, мы изменили все названия, способные раскрыть информацию о ней.

Нулевой этап: установление партнерских отношений и подготовка

Заказчик оценки, который связался с нами, ознакомившись с опубликованными на нашем веб-сайте материалами но методу АТАМ, оказался представителем круп­ного производителя программных систем для учреждений здравоохранения, со­трудничавшего с больницами, клиниками и НМО. Система, которую нам пред­стояло проверить, называлась Nightingale. Нам рассказали, что это крупная система, состоящая из нескольких миллионов строк кода, довольно давно перешедшая в стадию реализации. У нее уже был первый покупатель — сеть из сорока с лиш­ним больниц, расположенных на юго-западе Соединенных Штатов.

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

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

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

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

Таблица 11.4. Распределение ролей между участниками группы оценки Участник Роль   Руководитель группы, руководитель специалистов по оценке, дознаватель   Руководитель специалистов по оценке, дознаватель   Хронометрист, дознаватель   Секретарь по сценариям, дознаватель, сборщик данных   Дознаватель, координатор процесса   Секретарь по результатам, наблюдатель за процессом

 

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