Как внедрить CASE в вашей организации?

Георгий Калянов

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

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

Выбор методологии

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

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

Миф первый - противопоставление структурного и объектно-ориентированного анализа. По своей сути объектный подход одновременно является и структурным, так как удовлетворяет его основным критериям (разбиение на черные ящики, иерархия, графическая нотация). Более того, в настоящее время четко выявляется тенденция использования в объектно-ориентированном подходе базовых для классического структурного подхода нотаций (диаграммы потоков данных, диаграммы “сущность - связь”, диаграммы переходов состояний), фактически структурный подход поглощается объектно-ориентированным.

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

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

Подтверждением первичности функциональной модели является тот факт, что на Западе, где различные методики реорганизации деятельности (BSP, CPI/TQM, BPR) применяются уже длительное время, большинство методологий являются функционально-ориентированными.

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

Выбор инструментария

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

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

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

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

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

- Первоначальный выбор недорогих продуктов на основе информации о реальных проектах, выполненных с их использованием. Например, известен ряд фирм и банков, которые на первых этапах проектирования автоматизированных банковских систем использовали пакеты “CASE.Аналитик” для построения функциональной и ERWin для построения информационной моделей.

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

- Обязательная поддержка автоматической верификации на полноту и состоятельность проекта и генерации отчетов по верификации.

- Автоматическая генерация проектной документации в соответствии с общепринятыми стандартами (отечественных заказчиков вполне удовлетворяют ГОСТы, зарубежных - DOD STD-2167A).

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

- Для информационного моделирования - работа со средствами генерации схем БД для получения широкого спектра СУБД, а также поддержка обратного проектирования (reverse engineering), т. е. создание информационных моделей из существующих БД.

Обучение

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

Выбор пилотного проекта

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

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

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

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

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

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

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

Георгий Калянов - канд. техн. наук, директор департамента консалтинга и аналитических исследований компании ИКТ. К нему можно обратиться по адресу: ictcom@dol.ru.

Телефон (095) 232-6797.