CASE-средства: в борьбе со сложностью мира

© Юлия Гараева,
© Иван Пономарев
© Статья была опубликована в PC Week № 18/2004

Порою кажется, Что все вокруг устроено несложно: солнце светит, лампочки мигают, зарплату выдают вовремя. Но только захочешь сделать что-нибудь “полезное для общества”, приглядишься повнимательнее, и сразу все становится ой как не просто — на пути встают комплексные объекты и системы: жилищно-коммунальное хозяйство, экономический кризис, вертикаль власти, топология, логистика территориально распределенных сетей, уголовно-процессуальный кодекс, методология планирования ресурсов с учетом производственных ограничений...

Когда в одну кучу собирается несколько разнородных объектов с различными свойствами и взаимосвязями, которые не удерживаются в одной голове в один момент времени, у человека возникает естественная когнитивная потребность “наклеить ярлычки, разложить все по полочкам, а полочки разместить по шкафчикам”.

CASE’оведы и CASE’олюбы

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

“Свято место пусто не бывает”: раз есть потребность, то есть и предложение. Вот уже более 30 лет развиваются многообразные CASE-средства — средства компьютеризированного анализа, проектирования, перепроектирования, контроля за соблюдением соответствия тому, что было спроектировано и т. п.

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

Широкий спектр CASE-инструментария, охватывающего разнообразную деятельность — от анализа бизнес-структур и бизнес-требований до поддержки жизненного цикла разработки и сопровождения информационных систем, — не кажется искусственным в свете неразрывной связи систем управления организациями и ИС. Не случайно буква S в термине CASE (Computer Aided S... Engineering) трактуется сегодня в широком смысле: и как Software, и как System (хотя изначально было software), ведь программные продукты — это частный (специализированный) случай систем вообще.

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

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

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

Михаил Кумсков: “Наша практика показывает, что инструмент по отношению к процессам жизненного цикла вторичен. И мы, начиная внедрение, в первую очередь уделяем внимание управлению требованиями, управлению изменениями, ставим эти процессы. А потом уже учим участников пользоваться средствами визуального моделирования, анализа, проектирования и т. д. Потому что изначально должна быть налажена прозрачность коммуникаций и управляемость коллективом через специализированные средства ее поддержки”.

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

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

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

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

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

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

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

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

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

Тот факт, что некоторые производители CASE-средств попутно являются конкурирующими производителями языков и сред разработки, накладывает свой отпечаток. Так, если вы используете средства разработки от Microsoft, то для вас вряд ли окажутся полезными CASE-средства Oracle. Аналогично не приходится ожидать особой поддержки Oracle и Borland в средствах Microsoft. В то же время продукт IBM Rational Rose имеет кодогенераторы как для языков Microsoft Visual Studio, так и для языка Borland Delphi. Но в целом ориентированность некоторых комплексов CASE-средств на определенные среды разработки может оказаться столь велика, что это способно значительно сузить круг при поиске подходящего инструмента в том случае, когда среда разработки приложения уже выбрана. (В этом смысле приведенная ниже таблица сравнения не вполне корректна и должна рассматриваться читателями с указанной оговоркой.)

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

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

Кроме того, по имеющейся статистике, 80% средств, которые ИT-службы предприятий тратят на программное обеспечение, уходят на сопровождение, а не на разработку (закупку) систем. И можно понять, почему. Высокие затраты на сопровождение, во-первых, связаны с плохим изначальным проектированием систем. CASE-средства способны эти затраты снизить. Во-вторых, в реальной жизни к системе в процессе ее эксплуатации предъявляются новые требования, у бизнеса появляются новые задачи, когда организация развивается. Не могут избежать непрерывных изменений и разработчики — как тиражных систем (вынужденные выводить все новые и новые версии на рынок), так и заказных, постоянно доделывающие что-то в ИС под новые требования заказчика. Так что изменения систем неизбежны, и было бы уместно, если бы CASE-средства поддерживали процессы изменений функционирующих ИС, причем желательно в режиме реального времени (реинжиниринг информационной системы без остановки жизненно важных ее элементов).

Галина Антипина: “Команды, которые профессионально занимаются разработкой информационных систем, постепенно начинают осознавать необходимость комплексного применения средств управления созданием ПО. Раньше они ограничивались средствами моделирования (бизнес-процессов, баз данных, информационных систем). Сейчас все больше компаний понимает необходимость использования таких специализированных продуктов, как средства конфигурационного управления проектами, контроля версий, тестирования. В первую очередь такой интерес идет от руководителей отделов разработки, которые понимают, что использование таких продуктов позволяет сократить время создания, повысить качество ПО, выполнить проекты в заданные сроки и в рамках бюджета. Непосредственные участники проектов (аналитики, разработчики и др.) выигрывают в первую очередь от упрощения коммуникации между участниками проекта, что позволяет значительно сократить время на поиск нужных документов, файлов, “самой последней” версии создаваемой программы и сосредоточиться на выполнении конкретных задач”.

Алла Прохорова: “Для реализации полноты всех ступеней жизненного цикла только инструментальных средств мало, нужна методология разработки, задающая правила игры. Причем методология, адаптированная к нуждам конкретной фирмы. Как на предприятиях реального сектора нужны собственные бизнес-технологии ведения их деятельности в виде бизнес-процессов, так и компаниям-разработчикам необходим свой аналогичный каркас. Именно для этих задач и создана методология ведения проектов разработки (Rational Unified Process, RUP). Она представляет собой энциклопедию, в которой описаны роли участников проекта, инструкции. В адаптированном RUP возникают свои роли под свой стиль работ, и уже под нужные процессы делаются инструкции, собственный шаблонированный документооборот проектных документов. Постепенно собирается библиотека моделей, требований, репозитории”.

Антон Шматалюк: “После того как информационная система создана, необходимо обучение пользователей, соединение ее с имеющимися в организации процессами. Пренебрежение этим может повлечь еще большие затраты на сопровождение, например из-за того, что система внедрена, но с ней до конца не умеют работать. По результатам эксплуатации нужен анализ использования ИС, управление дальнейшей автоматизацией предприятия, оптимизация на основе анализа. Будущие CASE-средства обязательно должны эти позиции поддерживать. ARIS уже начинает идти по этому пути, предлагая, например, ARIS Redocumentation SCOUT для аудита внедренных систем SAP”.

В идеале необходимо, чтобы CASE-линейка обеспечивала с точки зрения менеджмента адекватную связь между всеми средствами поддержки жизненного цикла организационной системы, включая преобразование организационных технологий в корпоративные приложения (например, в виде workflow- или BPM-систем, средств интеграции различных приложений и бизнес-процессов и пр.).

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

Основные этапы жизненного цикла систем, их поддержка, а также значимые свойства представленных линеек продуктов

Дополнительная информация

• Обратиться в Interface Ltd. за дополнительной информацией/по вопросу приобретения продуктов
• Подробнее о продуктах Borland
• Курсы по продуктам фирмы Borland Приобрести продукцию Borland в электронном магазине ITshop.ru
• Подробнее о продуктах Computer Associates
• Приобрести продукты СА в электронном магазине ITshop.ru
• Курсы по продуктам фирмы Computer Associates
• Приобрести продукты Oracle в Интернет-магазине ITshop.ru
• Учебные курсы по продуктам фирмы Oracle
• Учебные курсы по продуктам Rational Software
• Другие публикации по продуктам Rational Software
• Приобретести продукты Rational Software в электронном магазине ITshop
• Подробнее о продуктах Microsoft
• Курсы по продуктам Microsoft

За дополнительной информацией обращайтесь в компанию Interface Ltd.

Обсудить на форуме

INTERFACE Ltd. Телефон/Факс: +7 (495) 925-0049 Отправить E-Mail http://www.interface.ru

Ваши замечания и предложения отправляйте редактору По техническим вопросам обращайтесь к вебмастеру Дата публикации: 23.09.04