Ниша и внедрение CASE-средств

С внедрением CASE-средств обычно связывают большие надежды, однако не всем им суждено стать реальностью

Александр Михайлович Вендров — зав. кафедрой информатики Всероссийской государственной налоговой академии. С ним можно связаться по электронной почте: a.m.vendrov@mtu-net.ru

После того как я прочел в сентябрьском выпуске журнала «Директору ИС» статью Фреда Хэпгуда «CASE: конец истории?», захотелось поделиться своими (и не только своими) соображениями — все-таки уже почти десять лет занимаюсь этой проблематикой. Заголовок статьи сразу вызвал желание возразить: какой же это конец истории, когда ей без году неделя, и все только начинается (достаточно обратиться к оценке степени развитости программной инженерии, содержащейся в техническом отчете SEI «A Mature Profession of Software Engineering», опубликованном в 1996 году). По существу, я хочу поддержать одно из мнений, процитированных в статье Хэпгуда, а именно то, что CASE-средства заняли свою нишу в области проектирования больших и сложных систем.

Если рассматривать CASE (Computer Aided Software Engineering) в первоначальном понимании — как средство компьютерной поддержки разработки программного обеспечения (ПО), то их польза в проектировании больших и сложных программных систем станет вполне понятной. В подтверждение этого тезиса можно сослаться на «Мифический человеко-месяц» Фредерика Брукса. Самой большой проблемой, которую приходится решать программной инженерии, является сложность ПО. Сложность становится существенным и неотъемлемым свойством программных систем. Поэтому попытки описания программных объектов, абстрагируясь от их сложности, приводят к абстрагированию и от их сущности. Наблюдается нелинейный рост сложности при увеличении размера ПО. Создаются трудности в процессе общения между разработчиками, что ведет к ошибкам в продукте, превышению стоимости разработки, затягиванию выполнения графиков работ. Сложность структуры затрудняет развитие ПО и добавление новых функций.

Моделирование программных систем

Для успешной реализации проекта объект проектирования (в нашем случае ПО) должен быть прежде всего адекватно описан, то есть должна быть построена полная и непротиворечивая архитектура ПО. Архитектура ПО представляется в виде совокупности моделей, которые строятся для того, чтобы понять и осмыслить структуру и поведение будущей системы, облегчить управление процессом ее создания и уменьшить возможный риск, а также документировать принимаемые проектные решения. Разработка архитектуры системы ПО промышленного характера на стадии, предшествующей ее реализации или обновлению, в такой же мере необходима, как и наличие проекта для строительства большого здания. Это утверждение справедливо как в случае разработки новой системы, так и при адаптации типовых продуктов класса R/3 или BAAN, в составе которых также имеются собственные средства моделирования. Хорошие модели являются основой взаимодействия участников проекта и гарантируют корректность архитектуры.

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

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

Из всего сказанного выше можно сделать вывод, что моделирование сложных программных систем с помощью CASE-средств является самостоятельным и самодостаточным видом деятельности в процессе создания ПО.

В то же время практическое внедрение CASE-технологии в организациях-разработчиках ПО связано с рядом проблем. Они достаточно полно изложены в американском стандарте IEEE Std. 1348-1995. IEEE Recommended Practice for the Adoption of Computer-Aided Software Engineering (CASE) Tools. Цель приведенных в стандарте рекомендаций — предоставить руководство, позволяющее повысить вероятность успешного внедрения CASE-технологии. Эти рекомендации достаточно актуальны и ценны, поскольку отражают опыт, накопленный многими зарубежными пользователями и разработчиками CASE-средств.

Проблемы внедрения CASE-средств

Несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате чего создание с их помощью ПО становится «полочным» (shelfware).

В связи с этим необходимо отметить следующее:

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

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

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

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

Процесс внедрения CASE-средств

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

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

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

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

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

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

Ожидаемые и неожиданные результаты

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

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

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

Реалистичные ожидания:

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

Нереалистичные ожидания:

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

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

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

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

О выборе CASE-средства

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

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

Кстати, началом появления на российском рынке первых CASE-средств можно считать 1992 год. Первыми такими средствами были ProKit Workbench фирмы McDonnell Douglas Information Systems, Design/IDEF фирмы MetaSoftware и отечественная разработка фирмы «Эйтекс» под названием CASE.Аналитик. В дальнейшем на рынке появились и успешно использовались такие продукты, как ERwin, BPwin, Silverrun, Oracle Designer, Rational Rose.

Подытоживая сказанное

Отмечу еще раз, что основная ниша CASE-средств — проектирование больших и сложных систем. Однако их применение может быть успешным в полной мере только при условии надлежащей организации проекта, достаточного финансирования, разумных сроков и т. д. В то же время в последние годы складывается культура так называемых экстремальных проектов. В англоязычной литературе с легкой руки Эдварда Йордана, одного из ведущих мировых специалистов в области программной инженерии и автора книги Death March. The Complete Software Developers?s Guide to Surviving «Mission Impossible» Projects, выпущенной издательством Prentice-Hall в 1997 году (в издательстве «ЛОРИ» выходит ее русский перевод), за такими проектами утвердилось название death march, буквально — «смертельный марш». Однако более подробный разговор на тему об использовании CASE-средств в таких проектах лучше оставить для отдельной статьи.