(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

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

Источник: ComputerWorld: Директору ИС, 11'2000
Александр Вендров

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

  1. Поддержка полного жизненного цикла ПО с обеспечением эволюционности его развития.
  2. Обеспечение целостности проекта и контроля за его состоянием.
  3. Независимость от программно-аппаратной платформы и СУБД.
  4. Поддержка одновременной работы групп разработчиков.
  5. Возможность разработки приложений "клиент-сервер" требуемой конфигурации.
  6. Открытая архитектура и возможности экспорта/импорта.
  7. Качество технической поддержки в России, стоимость приобретения и поддержки, опыт успешного использования.
  8. Простота освоения и использования.
  9. Обеспечение качества проектной документации.
  10. Использование общепринятых, стандартных нотаций и соглашений.

В конечном счете, мы пришли к выводу, что решающее значение имеет критерий № 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-средств в таких проектах лучше оставить для отдельной статьи.



 Распечатать »
 Правила публикации »
  Обсудить материал в конференции IBM Rational/Telelogic - системный инжиниринг, управление требованиями, изменениями, жизненным циклом ИС, умное управление проектами »
Написать редактору 
 Рекомендовать » Дата публикации: 03.01.2001 
 

Магазин программного обеспечения   WWW.ITSHOP.RU
IBM RATIONAL Rose Enterprise Floating User License + Sw Subscription & Support 12 Months
Rational ClearCase Multisite Floating User License
IBM RATIONAL Clearcase Floating User License + Sw Subscription & Support 12 Months
IBM RATIONAL Quality Manager Quality Professional Authorized User Single Install License + Sw Subscription & Support 12 Months
IBM RATIONAL Clearcase Floating User From Rational Clearcase Lt Floating User Trade Up License + Sw Subscription & Support 12 Months
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Новости ITShop.ru - ПО, книги, документация, курсы обучения
CASE-технологии
Мир OLAP и Business Intelligence: новости, статьи, обзоры
Мастерская программиста
Каждый день новые драйверы для вашего компьютера!
Программирование на Visual С++
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
Обсуждения в форумах
Где взять лицензионный ключ для AllFusion Process Modeler (BPwin) 7? (5)
Выручайте!!! где найти ключ, ужасно срочно нужна программа. заранее спасибо!
 
Русификация рамки IDEF0 BPWin4 (41)
Возможно ли русифицировать рамку диаграмм в BPWin4?
 
Проектирование курсовой работы в BPWin (32)
Здравствуйте.Подскажите пожалуйста где можно найти примерное проектирование курсовой работы...
 
Русификация ERWin (29)
Здравствуйте! Используем версию ERwin 4.1 в сети,но при создании логической модели вместо...
 
применение CA Process Modeller (BPWin) и связь моделей BPWin и ErWin (1)
Не очень понятна связь прогр продуктов CA Process Modeller (BPWin) и CA Data Modeller...
 
 
 



    
rambler's top100 Rambler's Top100