После того как я прочел в сентябрьском выпуске журнала "Директору ИС" статью Фреда Хэпгуда "CASE: конец истории?", захотелось поделиться своими (и не только своими) соображениями - все-таки уже почти 10 лет занимаюсь этой проблематикой. Заголовок статьи сразу вызвал желание возразить: какой же это конец истории, когда ей без году неделя, и все только начинается (достаточно обратиться к оценке степени развитости программной инженерии, содержащейся в техническом отчете 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-средств в таких проектах лучше оставить для отдельной статьи.