CASE-факторы риска

Евгений Захарович Зиндер — директор аналитического и конструкторского бюро «Группа 24». Он курирует рубрику «Директору», ему можно написать по адресу ezinder@osp.ru.

Нет нужды описывать достоинства CASE-систем. Замечательна также идея интегрального репозитария проекта ИС. Но надо учитывать и ограничения на применение этих средств. В особенности если говорить о первых этапах и стадиях проекта.

Суждение Ивана Данылива, которому я благодарен за письмо и последовавший обмен мнениями, часто встречается в виде вопросов о том, когда, зачем и какие CASE-системы стоит или не стоит применять.

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

Ограниченность простого ответа

Недостаточно сказать: «Да, мощные импортные CASE-системы дороги, дорого и их освоение. По этой причине в некоторых проектах ИС практичнее получить приемлемый итоговый уровень качества за счет грамотной постановки проектных методов, строгого соблюдения стандартов проекта и аккуратного применения «подручных» средств ведения базы проектных данных».

Конечно, сказанное выше справедливо в очень многих случаях, и это известно по множеству самых разных успешных проектов. Кроме этого, уже приходилось писать и о другом факторе: культурологически устойчивой тяге программистов — как в Америке, так и в России — к «прямому» программированию.

И все же такой ответ неверен, поскольку слишком неполон.

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

Общие риски первых этапов

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

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

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

Потеря прямого участия старших управляющих предприятия, для которых важнее прямое личное взаимодействие, оценки и принятие решений. А как известно, такое прямое участие — самый главный ключевой фактор успеха проекта ИС.

Учтем, что на этих этапах нужны самые разные методы и приемы, которые или вовсе не поддерживаются CASE-инструментами, или поддерживаются рудиментарно. Например, варианты SWOT-анализа (анализ «силы, слабости, возможности, угрозы»), или то моделирование вариантов развития бизнеса, о котором пишет в этом выпуске рубрики Сергей Рубцов.

Риск забыть про маркетинговое управление

Еще один часто задаваемый вопрос, относящийся к первым этапам создания ИС, — это вопрос о том, с чего же надо начинать строить «правильную» систему управления предприятием — с бухучета и контроллинга или же с процедур маркетингового управления. Классическим предупреждением являются слова: если углубиться в построение детальных моделей «как есть», со вкусом погружая их в CASE-репозитарий, риск потонуть в мелких «заморочках» бухучета и текущего документооборота возрастает многократно.

Возможна и другая форма этого вопроса: есть ли глобальный риск в том, что ИС для стратегического планирования вообще не будет создаваться?

В статье Рубцова обосновывается одно из мнений на этот счет. Вопрос весьма важен, надеюсь, что мы все вместе еще вернемся к нему.

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

Риски на этапах проектирования ИС

На более поздних стадиях ограничения связаны с тем, что естественные надежды на применение в проекте единственного CASE-инструмента часто вступают в противоречие с наличием столь же естественных смысловых разрывов между моделями, наиболее пригодными для выработки проектных решений на разных этажах архитектуры системы — бизнес-планирования, концептуальном, логическом и т. д. — вплоть до физического построения отдельных блоков. Об этом хорошо написал Сергей Панащук в статье «Проектирование крупных ИС: от панацей к мастерской моделей и методов» (смотрите выпуск нашей рубрики № 2 от 1 сентября 1998 года).

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

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

Более того, есть сильный риск преждевременного перенесения формализмов моделей нижнего слоя на модели верхних уровней. При этом такие формализмы начинают подменять специфику моделей концептуального и логического уровней. Этот риск часто порождается верой программирующих математиков в то, что формальные языки CASE-моделей уже содержат все «нормы и правила» для моделирования реальных предприятий.

Что делать с рисками

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

Полезно иметь средства, поддерживающие базисные слои системных и программных требований. Например, использовать систему ведения требований типа Requisite Pro фирмы Rational Software. Но вы можете сделать для этого и собственный простой инструментарий.

Полезно также иметь хотя бы простейшие средства ведения тезауруса понятий, используемых в проекте (понятийной модели, более широкой и общей, чем модель классов, которая будет, например, строиться на языке UML).

Наконец, использование простых и удобных «рисовалок» различных диаграмм окажется полезным, если, конечно, не будет поставлено во главу угла.

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

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

Всегда надо учитывать, что «упражнения» с формальными диаграммами не стоит навязывать бизнес-аналитикам и тем более руководителям подразделений заказчика. (Есть некая традиция «выкатывать» заказчику толстенные тома с CASE-документацией: он, мол, в этих томах толком не разберется, но их «научность» произведет внушительное воздействие.)

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