А. А. Платонов, доцент кафедры прикладной математики и вычислительной техники Волгоградского государственного архитектурностроительного университета
 Скачать 3.99 Mb.
|
|
4.2.7. Самостоятельное описание требований Документы — хороший источник информации, потому что они чаще все- го доступны и их можно «опрашивать» в удобном для себя темпе. Чтение документов — прекрасный способ получить первоначальное представление о системе и сформулировать вопросы к экспертам. Недостаток этой стратегии в опасности пропуска знаний, специфичных для объекта исследования (в случае самоопроса), либо неформализованных знаний, эмпирических правил и процедур, широко используемых на прак- тике, но не вошедших в документы. 4.2.8. Обзор литературы и технической документации Параллельно с интервьюированием заинтересованных лиц команде про- ектировщиков следует изучить какую-либо литературу, касающуюся про- дукта или его предметной области. Команда проектировщиков должна собрать эту литературу и использо- вать ее как основу для формирования списка вопросов к заинтересованным лицам и ЭПО, а также в качестве источника дополнительных данных о пред- метной области и терминологии, а также для сравнения с уже собранными данными о пользователях. Литература, касающаяся продукта или его предметной области должна включать: маркетинговые планы; стратегию бренда; исследования рынка; опросы пользователей; технические спецификации и информационные материалы; статьи в деловых и технических журналах, связанных с предметной об- ластью; сравнительный анализ конкурентных решений; результаты поиска в Интернете похожих продуктов и новостей о них; результаты и метрики юзабилити-исследований; данные службы поддержки, такие как статистика обращений пользовате- лей за поддержкой. 28 4.2.9. Аудит продукта/прототипа и конкурирующих решений Часто оказывается полезным параллельно с интервьюированием заинте- ресованных лиц и ЭПО изучить любые существующие версии или прототи- пы продукта, а также его основных конкурентов. Тем самым команда проек- тировщиков получает хорошее представление о состоянии дел в области и почву для подготовки вопросов к интервью. В идеале команде проектировщиков следует провести неформальную эв- ристическую или экспертную оценку интерфейсов как своего продукта, так и конкурирующих продуктов, проверяя их на соответствие принципам каче- ственного взаимодействия и визуального дизайна. Данная процедура позво- ляет команде ознакомиться с сильными и слабыми сторонами доступных пользователю продуктов и дает общее представление о текущем объеме функциональности продукта. 4.2.10. Совместные семинары Помимо классического интервью тет-а-тет, существует значительное ко- личество методик, предполагающих широкое участие представителей заказ- чика и исполнителя. Правила мозгового штурма предполагают полную раскрепощенность и свободу мнений, даже самых вычурных и на первый взгляд, бредовых. Первое правило мозгового штурма — полный запрет на любую критику. Всякое высказанное мнение представляет ценность, а полное отсутствие за- претов позволяет полноценно подключить творческую фантазию. Затем, на втором этапе, все высказанные мнения тщательным образом обсуждаются, заведомо неприемлемые варианты отсеиваются, формируются коллективные предложения. Совместные семинары, сохраняя все преимущества режима интервью, привносят дополнительные бонусы: работа в группе более продуктивна, группы быстрее обучаются, более склонны к квалифицированным заключе- ниям, позволяют исключить многие ошибки Эта стратегия — одна из самых затратных, однако она окупается за счет меньшего количества ошибок и отказа от формализации в пользу живого общения, выработке общего языка и пр. Контрольные вопросы 1. В чем преимущество качественных исследований? 2. Какие основные вопросы позволяют раскрыть качественные исследования? 3. Назовите основные виды качественных исследований. 4. Какими недостатками обладает анкетирование? 5. Назовите преимущества и недостатки совместных семинаров. 29 5. МОДЕЛИ БИЗНЕС-ПРОЦЕССОВ Модели широко применяются в проектировании, разработке и науке. Это мощные инструменты для представления сложных структур и связей с це- лью их лучшего понимания, обсуждения и визуализации. В отсутствие моделей мы были бы вынуждены осмысливать неструкту- рированные, сырые данные, не имея подспорья в виде каких-либо органи- зующих принципов. Хорошие модели подчеркивают характерные особенно- сти структур и связей и уводят в тень менее важные детали. Моделирование бизнес-процессов при проектировании информационных систем позволяет отразить следующие аспекты: цель или желаемый результат процесса; частоту и важность процесса и каждого действия; событие, инициирующее процесс в целом и каждое действие в отдель- ности; зависимости — что требуется, чтобы выполнить процесс в целом и каж- дое действие в отдельности, а также какие события и действия зависят от за- вершения процесса в целом и каждого из действий; участников процессов, их роли и ответственности; конкретные действия; принимаемые решения; информацию, используемую при принятии решений; что может пойти не так — ошибки и исключительные ситуации; исправления ошибок и обработку исключений. 5.1. Методики моделирования бизнес-процессов Рассмотрим коротко некоторые из методик моделирования бизнес- процессов. Для сравнения удобства моделирования рассмотрим пример моделирова- ния бизнес-процесса «Планирование закупок и размещение заказов постав- щикам» с использованием каждой из вышеприведенных методик. 30 5.1.1. Функциональная методика IDEF0 Методику IDEF0 можно считать следующим этапом развития хорошо из- вестного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique). Исторически IDEF0 как стандарт был разработан в 1981 г. в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing). Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=Icam DEFinition), и по- следняя его редакция была выпущена в декабре 1993 г. Национальным ин- ститутом по стандартам и технологиям США (NIST). Целью методики является построение функциональной схемы исследуе- мой системы, описывающей все необходимые процессы с точностью, доста- точной для однозначного моделирования деятельности системы. В основе методики лежат четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция, глоссарий. Функциональный блок (Activity Box) представляет собой некоторую кон- кретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформу- лировано в глагольной форме (например, «производить услуги»). На диа- грамме функциональный блок изображается прямоугольником (рис. 6). Каж- дая из четырех сторон функционального блока имеет свое определенное зна- чение (роль), при этом: верхняя сторона имеет значение «Управление» (Control); левая сторона имеет значение «Вход» (Input); правая сторона имеет значение «Выход» (Output); нижняя сторона имеет значение «Механизм» (Mechanism). Рис. 6. Функциональный блок Интерфейсная дуга (Arrow) отображает элемент системы, который обра- батывается функциональным блоком или оказывает иное влияние на функ- цию, представленную данным функциональным блоком. Интерфейсные дуги часто называют потоками или стрелками. 31 С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Таки- ми объектами могут быть элементы реального мира (детали, вагоны, сотруд- ники и т. д.) или потоки данных и информации (документы, данные, инст- рукции и т. д.). В зависимости от того, к какой из сторон функционального блока подхо- дит данная интерфейсная дуга, она носит название «входящей», «исходя- щей» или «управляющей». Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую, так как каждый процесс должен происходить по ка- ким-то правилам (отображаемым управляющей дугой) и выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла. Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram). Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбивке сложного процес- са на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели. Декомпозиция позволяет постепенно и структурировано представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой. Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0 — диаграмм, функциональных блоков, интерфейсных дуг — существующий стандарт подразумевает создание и поддержание на- бора соответствующих определений, ключевых слов, повествовательных из- ложений и т. д., характеризующих объект, отображенный данным элемен- том. Этот набор называется глоссарием и является описанием сущности дан- ного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией. Модель IDEF0 всегда начинается с представления системы как единого целого — одного функционального блока с интерфейсными дугами, прости- рающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой. В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафикси- рована точка зрения (Viewpoint). Определение и формализация цели разработки IDEF0-модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь. Точка зрения определяет основное направление развития модели и уро- вень необходимой детализации. Четкое фиксирование точки зрения позволя- ет разгрузить модель, отказавшись от детализации и исследования отдель- 32 ных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели. Выделение подпроцессов. В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему как единое це- лое, подвергается детализации на другой диаграмме. Получившаяся диа- грамма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы, и на- зывается дочерней (Child Diagram) по отношению к нему (каждый из функ- циональных блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним блоком — Child Box). В свою очередь, функциональ- ный блок-предок называется родительским блоком по отношению к дочер- ней диаграмме (Parent Box), а диаграмма, к которой он принадлежит, — ро- дительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпо- зиции соответствующего ей функционального блока. В каждом случае де- композиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0–модели. Иногда отдельные интерфейсные дуги высшего уровня не имеет смысла продолжать рассматривать на диаграммах нижнего уровня, или наоборот — отдельные дуги нижнего отражать на диаграммах более высоких уровней, так как это будет только перегружать диаграммы и делать их сложными для восприятия. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие «туннелирование». «Туннель» (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме. В свою очередь, такое же обозна- чение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока-приемника устанавливает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интер- фейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии. В таком случае они сначала «погружаются в туннель», а затем при необходимости «возвращаются из туннеля». Обычно IDEF0-модели несут в себе сложную и концентрированную ин- формацию, и для того чтобы ограничить их перегруженность и сделать удобо- читаемыми, в стандарте приняты соответствующие ограничения сложности. Рекомендуется представлять на диаграмме от трех до шести функцио- нальных блоков, при этом количество подходящих к одному функциональ- ному блоку (выходящих из одного функционального блока) интерфейсных дуг предполагается не более четырех. Стандарт IDEF0 содержит набор процедур, позволяющих разрабатывать и согласовывать модель большой группой людей, принадлежащих к разным областям деятельности моделируемой системы. 33 Обычно процесс разработки является итеративным и состоит из следую- щих условных этапов: 1. Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамиче- ским процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов, создавая модели деятельности подразде- лений. При этом их интересуют ответы на следующие вопросы: Что поступает в подразделение на входе? Какие функции и в какой последовательности выполняются в рамках подразделения? Кто является ответственным за выполнение каждой из функций? Чем руководствуется исполнитель при выполнении каждой из функций? Что является результатом работы подразделения (на выходе)? На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели. 2. Распространение черновика для рассмотрения, согласований и ком- ментариев. На этой стадии происходит обсуждение черновика модели с ши- роким кругом компетентных лиц (в терминах IDEF0 — читателей) на пред- приятии. При этом каждая из диаграмм черновой модели письменно крити- куется и комментируется, а затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает ее с изложением ло- гики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока ав- торы и читатели не придут к единому мнению. 3. Официальное утверждение модели. Утверждение согласованной моде- ли происходит руководителем рабочей группы в том случае, если у авторов модели и читателей отсутствуют разногласия по поводу ее адекватности. Окончательная модель представляет собой согласованное представление о предприятии (системе) с заданной точки зрения и для заданной цели. Наглядность графического языка IDEF0 делает модель вполне читаемой и для лиц, которые не принимали участия в проекте ее создания, а также эф- фективной для проведения показов и презентаций. В дальнейшем на базе по- строенной модели могут быть организованы новые проекты, нацеленные на производство изменений в модели. 5.1.2. Описание бизнес-процессов в Унифицированном языке моделирования В конце 90-х гг. XX в был разработан Унифицированный язык модели- рования (Unified Modeling Language, UML), который является объектно- ориентированным графическим языком для визуализации, специфицирова- ния, конструирования и документирования систем, в которых большая роль принадлежит программному обеспечению. 34 Процесс создания программного обеспечения по методике Rational Unified Process компании Rational Software Corporation включает следующие этапы: моделирование предметной области (Business Modeling); определение требований к системе (Requirements); анализ и проектирование (Analysis&Design); разработка (Implementation); тестирование (Test); внедрение (Deployment). Моделирование бизнес-процессов, для автоматизации которых разраба- тывается ПО, производится на этапе моделирования предметной области с использованием диаграмм диаграммы вариантов использования (Usecasediagram) и деятельности (Activitydiagram). Применение необходимо ограничить, в основном, первыми уровнями де- композиции бизнес-процессов. Излишняя детализация усложняет чтение и сопровождение модели. В UML выделяют девять типов диаграмм: 1) диаграммы классов (Classdiagram); 2) диаграммы объектов (Objectdiagram); 3) диаграммы вариантов использования (Usecasediagram); 4) диаграммы последовательностей (Sequencediagram); 5) диаграммы кооперации (Collaborationdiagram); 6) диаграммы состояний (Statediagram); 7) диаграммы деятельности (Activitydiagram); 8) диаграммы компонентов (Componentdiagram); 9) диаграммы развертывания (Deploymentdiagram). Для описания бизнес-процессов в UML применяются диаграммы вариан- тов использования и деятельности. Диаграммы деятельности — это частный случай диаграммы состояний, на ней представлены переходы потока управления от одной деятельности к другой внутри системы. Диаграммы деятельности относятся к динамиче- скому виду системы; они наиболее важны при моделировании ее функцио- нирования и отражают поток управления между объектами. Диаграмма деятельности может использоваться также для определения подразделений и функций участников бизнес-процесса, описания докумен- тооборота. При описании бизнес-процессов диаграммы деятельности используются для описания последовательности различных действий субъектов и объектов. 5.1.3. ДРАКОН-технология ДРАКОН: Дружелюбный Русский Алгоритмический язык, Который Обеспечивает Наглядность (DRAKON) Визуальный алгоритмический язык программирования и моделирования ДРАКОН был разработан в рамках космической программы «Буран». Разра- 35 ботка языка велась с 1986 г. при участии Федерального космического агент- ства (Научно-производственный центр автоматики и приборостроения им. акад. Н. А. Пилюгина, Москва) и Российской академии наук (Институт при- кладной математики им. М. В. Келдыша) [5]. Основной задачей разработчи- ков было создание единого универсального языка программирования и мо- делирования, который своей доступностью и мощностью способен заменить специализированные языки, используемые в этих организациях для разра- ботки и моделирования. Язык построен путем формализации, эргономизации и неклассической структуризации блок-схем алгоритмов, описанных в ГОСТ 19.701—90 и ISO 5807—85. Как в любом графическом языке, в ДРАКОНе используются два типа элементов: графические фигуры (иконы); текстовые надписи, расположенные внутри или снаружи икон. Поэтому язык ДРАКОН имеет не один, а два синтаксиса: графический и текстовый. Графический (визуальный) синтаксис охватывает алфавит икон, правила их размещения в поле чертежа и правила связи икон с помо- щью соединительных линий. Текстовый синтаксис задает алфавит символов, правила их комбинирования и привязку к иконам (которая необходима, так как внутри разных икон используются разные типы выражений) Основой графического синтаксиса языка ДРАКОН является графический алфавит. Алфавит состоит из графических элементов (графических фигур), которые называются иконами. В языке ДРАКОН имеется 27 икон (рис. 7). Для каждой иконы задана ориентация, однозначно показано направление соединительных линий, входов и выходов. Благодаря жестко заданной ори- ентации икон и соединительных линий в большинстве случаев отпадает не- обходимость использовать стрелки. ДРАКОН имеет не только иконы, но и макроиконы. Макроиконы — это графические слова языка ДРАКОН. Подобно тому, как слова слагаются из букв, макроиконы (графические слова) состоят из икон (графических букв). В языке ДРАКОН имеется 21 макроикона (рис. 8). Иконы и макроиконы — это строительные блоки, из которых создаются ДРАКОН-схемы. Важной частью макроикон служат валентные точки (на рисунке они по- казаны как маленькие черные кружки). В эти точки последовательно вводят- ся иконы и макроиконы, которые в совокупности образуют графический узор и (после заполнения икон текстом) превращаются в ДРАКОН-схему. Подробное описание разработки ДРАКОН-схем приведено в работах В. Д. Паронджанова [5, 6]. В целом ДРАКОН позволяет описать алгоритм работы программы, сис- темы реального времени, технологического процесса, формализовать алго- ритм работы экспертов и описывать бизнес-процессы. Особенности использования языка ДРАКОН при описании бизнес- процессов будут рассмотрены ниже. 36 Рис. 7. Иконы языка ДРАКОН 37 Рис. 8. Макроиконы языка ДРАКОН |