Моделирование программных систем
Для успешной реализации проекта объект проектирования (в нашем случае ПО) должен быть прежде всего адекватно описан, то есть должна быть построена полная и непротиворечивая архитектура ПО. Архитектура ПО представляется в виде совокупности моделей, которые строятся для того, чтобы понять и осмыслить структуру и поведение будущей системы, облегчить управление процессом ее создания и уменьшить возможный риск, а также документировать принимаемые проектные решения. Разработка архитектуры системы ПО промышленного характера на стадии, предшествующей ее реализации или обновлению, в такой же мере необходима, как и наличие проекта для строительства большого здания. Это утверждение справедливо как в случае разработки новой системы, так и при адаптации типовых продуктов класса 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-средств
Александр Вендров
15.11.2000
С внедрением CASE-средств обычно связывают большие надежды, однако не всем им суждено стать реальностью
После того как я прочел в сентябрьском выпуске журнала «Директору ИС» статью Фреда Хэпгуда «CASE: конец истории?», захотелось поделиться своими (и не только своими) соображениями — все-таки уже почти десять лет занимаюсь этой проблематикой. Заголовок статьи сразу вызвал желание возразить: какой же это конец истории, когда ей без году неделя, и все только начинается (достаточно обратиться к оценке степени развитости программной инженерии, содержащейся в техническом отчете SEI «A Mature Profession of Software Engineering», опубликованном в 1996 году). По существу, я хочу поддержать одно из мнений, процитированных в статье Хэпгуда, а именно то, что CASE-средства заняли свою нишу в области проектирования больших и сложных систем.
Если рассматривать CASE (Computer Aided Software Engineering) в первоначальном понимании — как средство компьютерной поддержки разработки программного обеспечения (ПО), то их польза в проектировании больших и сложных программных систем станет вполне понятной. В подтверждение этого тезиса можно сослаться на «Мифический человеко-месяц» Фредерика Брукса. Самой большой проблемой, которую приходится решать программной инженерии, является сложность ПО. Сложность становится существенным и неотъемлемым свойством программных систем. Поэтому попытки описания программных объектов, абстрагируясь от их сложности, приводят к абстрагированию и от их сущности. Наблюдается нелинейный рост сложности при увеличении размера ПО. Создаются трудности в процессе общения между разработчиками, что ведет к ошибкам в продукте, превышению стоимости разработки, затягиванию выполнения графиков работ. Сложность структуры затрудняет развитие ПО и добавление новых функций.
О выборе 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-средств обычно связывают большие надежды, однако не всем им суждено стать реальностью.
Составление реалистичного перечня ожидаемых результатов является трудной задачей, поскольку многое зависит от таких факторов, как тип внедряемых средств и характеристики внедряющей организации. Кроме того, достижение некоторых результатов может противоречить другим результатам.
Ряд потенциально реалистичных и нереалистичных ожидаемых результатов, связанных с организацией в целом, пользователями, планированием, анализом, проектированием, разработкой и затратами, приведен ниже. Практически невозможно, чтобы в процессе одного внедрения CASE-средств были достигнуты все положительные результаты. Тем не менее любая организация может выработать собственные идеи относительно ожидаемых результатов, имея в виду, что данный перечень является всего лишь примером.
Реалистичные ожидания:
ускорение и повышение согласованности разработки приложений; снижение доли ручного труда в процессе разработки и/или эксплуатации; более точное соответствие приложений требованиям пользователей; отсутствие необходимости большой переделки приложений для повышения их эффективности; улучшение реакции службы эксплуатации на требования внесения изменений и усовершенствований; лучшее документирование; улучшение коммуникации между пользователями и разработчиками; последовательное и постоянное повышение качества проектирования; более высокие возможности повторного использования разработок; лучшая прогнозируемость затрат.
Нереалистичные ожидания:
отсутствие воздействия на общую культуру и распределение ролей в организации; понимание проектных спецификаций неподготовленными пользователями; сокращение персонала, связанного с информационной технологией; уменьшение степени участия в проектах высшего руководства и менеджеров, а также экспертов предметной области, уменьшение степени участия пользователей в процессе разработки приложений; немедленное повышение продуктивности деятельности организации; достижение абсолютной полноты и непротиворечивости спецификаций; автоматическая генерация прикладных систем из проектных спецификаций; немедленное снижение затрат, связанных с информационной технологией; снижение затрат на обучение.
Реализм в оценке ожидаемых затрат имеет особенно важное значение, поскольку позволяет правильно оценить отдачу от инвестиций. Затраты на внедрение CASE-средств обычно недооцениваются, хотя конкретных статей затрат на внедрение потребуют: специалисты по планированию внедрения CASE-средств; выбор и установка средств; учет специфических требований персонала; приобретение CASE-средств и обучение; настройка средств; подготовка документации, стандартов и процедур использования средств; интеграция с другими средствами и существующими данными; освоение средств разработчиками; технические средства; обновление версий.
Важно также осознавать, что улучшение деятельности организации, являющееся следствием использования CASE-технологии, может быть неочевидным в течение самого первого проекта, использующего новую технологию. Как уже отмечалось, продуктивность и другие характеристики деятельности организации могут первоначально даже ухудшиться, поскольку на освоение новых средств и внесение необходимых изменений в процесс разработки требуется некоторое время. Таким образом, ожидаемые результаты должны рассматриваться с учетом вероятной отсрочки в улучшении проектных характеристик.
Подытоживая сказанное
Отмечу еще раз, что основная ниша CASE-средств — проектирование больших и сложных систем. Однако их применение может быть успешным в полной мере только при условии надлежащей организации проекта, достаточного финансирования, разумных сроков и т. д. В то же время в последние годы складывается культура так называемых экстремальных проектов. В англоязычной литературе с легкой руки Эдварда Йордана, одного из ведущих мировых специалистов в области программной инженерии и автора книги Death March. The Complete Software Developers’s Guide to Surviving «Mission Impossible» Projects, выпущенной издательством Prentice-Hall в 1997 году (в издательстве «ЛОРИ» выходит ее русский перевод), за такими проектами утвердилось название death march, буквально — «смертельный марш». Однако более подробный разговор на тему об использовании 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-средств должны быть готовы к необходимости долгосрочных затрат на эксплуатацию, частому появлению новых версий и возможному быстрому моральному старению средств, а также к постоянным затратам на обучение новых сотрудников и повышение квалификации действующего персонала.
