(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 Method Composer Authorized User License
IBM Rational Functional Tester 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 Rose Enterprise Floating User 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 - ПО, книги, документация, курсы обучения
Программирование на Microsoft Access
CASE-технологии
Мир OLAP и Business Intelligence: новости, статьи, обзоры
Мастерская программиста
Windows и Office: новости и советы
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
Обсуждения в форумах
Как выбрать матрас (5)
Подскажите как правильно выбрать матрас и на что в целом следует обратить внимание на ваш...
 
ErWin to Access Relation Error (2)
Всем привет! ErWin при попытке генерации в Ассеss выдаёт: ERwinDatabase.Relations.Append...
 
Смена типа уровня модели (1)
Здравствуйте. При запуске программы выбрал уровень "Логический" вместо "Логический и...
 
Process Modeler (BPwin). Не добавляются Referent Tool, Ext Ref Tool и Data Store Tool (4)
Process Modeler (BPwin). В диаграммы не добавляются Referent Tool, External Reference Tool и...
 
Проектирование курсовой работы в BPWin (33)
Здравствуйте.Подскажите пожалуйста где можно найти примерное проектирование курсовой работы...
 
 
 



    
rambler's top100 Rambler's Top100