CASE-технологии. CASE-технология

Анализ литературы последних лет по технологии программирования показывает , что новой ветвью в технологии промышленной разработки и реализации сложных и значительных по объему систем программного обеспечения является CASE-технология (Computer Aided Software Engineering).

CASE-технология явилась ответом на ряд серьезных трудностей, возникших при разработке и эксплуатации компьютерных систем. Учитывая неудачу многих проектов, заказчики стремились получить хорошо проработанное обоснование проекта с тестированным программным обеспечением. Однако они не всегда предоставляли разработчикам необходимую информацию, справедливо относя ее к разряду коммерческой тайны, да и сама организация информационных потоков постоянно менялась по мере расширения деятельности предприятия. В результате осуществление проектов затягивалось, и созданные программно-аппаратные комплексы начинали работать в условиях, когда требования предприятия к ним изменялись. Применялся и иной подход. Компьютерный комплекс разрабатывался и вводился в эксплуатацию в короткие сроки специализированной фирмой при полном взаимодействии с заказчиком. Это обеспечивало создание работоспособного комплекса, но из-за отсутствия необходимой документации, задержки с обучением персонала и многочисленных «недоделок», особенно в программном обеспечении, эксплуатация комплекса попадала полностью в зависимость от разработчиков и происходила в условиях постоянных сбоев и потребности в дополнительных затратах на переделки и усовершенствования.

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

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

САSE-ToolKits и CASE-WorkBenches . Хороших русских эквивалентов этим терминам нет. Однако первые часто называют «инструментальными сундучками» (пакетами разработчика, технологическими пакетами), а вторые - «станками для производства программ» (технологическими линиями).

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

Такие пакеты используют общее «хранилище» для всей технической и управляющей информации по проекту (репозиторий), снабжены общим интерфейсом с пользователем и унифицированным интерфейсом между отдельными инструментами пакета. Как правило, CASE-ToolKit концентрируются вокруг поддержки разработки одной фазы производства программ или на одном типе прикладных задач,

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

Таким образом, CASE-WorkBench является естественным «замыканием» технологии разработки, реализации и сопровождения программного обеспечения.

В настоящее время «типовая» система поддержки CASE-технологии имеет функциональные возможности, представленные на рис. 14.

Рис. 14. Функциональные возможности типовой системы поддержки CASE-технологии

Как следует из рис. 14, в CASE-среде должны поддерживаться все основные этапы разработки и сопровождения процессов создания программных систем. Однако уровень такой поддержки существенно различен. Так, например, если говорить об этапах анализа и проектирования, большинство инструментальных пакетов поддерживает экранные и отчетные формы, создание прототипов, обнаружение ошибок. Значительная часть этих средств предназначена для ПЭВМ. Многие поддерживают такие широко используемые методологии, как структурный анализ DeMarco или Gane/Sarson, структурное проектирование Yourdan/Jackson и некоторые другие. Существуют специализированные пакеты разработчиков для создания информационных систем, например AnaTool (Advanced Logical Software) для Macintosh; CA-Universe/Prototype (Computer Associates International) для ПЭВМ. Имеются CASE-среды и для поддержки разработки систем реального времени.

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

В процессе создания проекта выделяют следующие этапы:

Формирование требований, разработка и выбор варианта концепции системы;

Разработка и утверждение технического задания на систему;

Эскизный и технический проекты с описанием всех компонентов и архитектуры системы;

Рабочее проектирование, предполагающее разработку и отладку программы; описание структуры базы данных; создание документации на поставку и установку технических средств;

Ввод в действие, предусматривающий установку и включение аппаратных средств, инсталлирование программного обеспечения, загрузку баз данных, тестирование системы, обучение персонала;

Эксплуатация системы, включающая сопровождение программных средств и всего проекта, поддержку и замену аппаратных средств.

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

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

В основе CASE-технологии лежит процесс выявления функций отдельных элементов систем и информационных потоков.

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

Описание информационных потоков в учреждении во многих CASE-системах производится с помощью ER-модели (Entiti-Relationship - модель «сущность - связь»). Порядок построения такой модели и используемые при этом абстракции определяются CASE-методом, без освоения которого CASE-технология не может быть применена в полном объеме. Учитывая дороговизну CASE-систем, российские специалисты, усвоив CASE-метод, создают свои инструментальные средства для описания ER-моделей и баз данных.

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

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

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

Основные достоинства CASE-технологии:

Повышение производительности труда программистов на несколько порядков,

Возможность формализовать документирование и администрирование проектов,

Минимизация ошибок и несовершенства программного обеспечения конечных пользователей,

Ускорение обучения персонала и использование программного обеспечения в полном объеме,

Постоянное обновление и модернизация пользовательских программ.

Наиболее известной в России в настоящее время является CASE-система Oracle, позволяющая создавать приложения на базе одноименной СУБД. В ее основе лежит CASE-метод проектирования сети «сверху вниз» - от наиболее общих решений к частным. Этапы в Oracle выглядят следующим образом :

Выработка стратегии;

Анализ объекта;

Проектирование;

Реализация;

Внедрение;

Эксплуатация.

ER-модель строится на этапе анализа объекта, а СУБД -на этапе проектирования.

CASE-система Oracle состоит из инструментальных средств CASE*Dictionary (для графического представления модулей предметной области); CASE*Generator (для автоматического генерирования программных модулей).

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

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

Источник: CITFORUM

Александра Гнатуш

ЧТО?

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

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

В 1970-80-х годах при разработке информационных систем широко применялась структурная методология, предоставляющая в распоряжение разработчиков строгие формализованные методы описания ИС и принимаемых технических решений. Эта методология основывалась на наглядной графической технике, иначе говоря, для описания проекта использовались различного рода схемы и диаграммы. Наглядность и строгость средств структурного анализа позволяла разработчикам и будущим пользователям системы с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических решений. Однако широкое применение этой методологии и следование ее рекомендациям при разработке конкретных проектов встречалось достаточно редко, поскольку ее практически невозможно реализовать на должном уровне ручным, неавтоматизированным, способом. Вручную очень трудно разработать и графически представить строгие формальные спецификации системы, проверить их на полноту и непротиворечивость, и тем более изменить. Если все же удается создать строгую систему проектных документов, то ее переработка при появлении серьезных изменений практически неосуществима. Если участники проекта пытались прибегнуть к ручной разработке, то перед ними возникали следующие проблемы:

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

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

Но рано или поздно должны были появиться специализированные программно-технологические средства для разработки проектов, в частности, основанных на информатизации. Ими стали средства, реализующие CASE-технологию создания и сопровождения информационных систем. Термин CASE (Computer-Aided Software Engineering) сегодня понимается достаточно широко.

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

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


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

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

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

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

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

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

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

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

  • мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;
  • интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки информационной системы;
  • использование специальным образом организованного хранилища проектных метаданных (репозитория). Интегрированное CASE-средство (или комплекс средств, поддерживающих полный жизненный цикл ПО) содержит следующие компоненты:
  • репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
  • графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели информационной системы;
  • средства разработки приложений, включая языки 4GL и генераторы кодов;
  • средства конфигурационного управления;
  • средства документирования;
  • средства тестирования;
  • средства управления проектом;
  • средства реинжиниринга.

Все современные CASE-средства можно классифицировать по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы жизненного цикла. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла информационных систем (toolkit) и полностью интегрированные средства, поддерживающие весь жизненный цикл информационных систем и связанные общим репозиторием. Помимо этого CASE-средства можно классифицировать по применяемым методологиям и моделям систем и БД; степени интегрированности с СУБД; доступным платформам.

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает:

  • средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));
  • средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
  • средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;
  • средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;
  • средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Вспомогательные типы включают:

  • средства планирования и управления проектом (SE Companion, Microsoft Project и др.);
  • средства конфигурационного управления (PVCS (Intersolv));
  • средства тестирования (Quality Works (Segue Software));
  • средства документирования (SoDA (Rational Software)).

КОГДА?

Ввиду разнообразной природы 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-средствах можно проиллюстрировать следующей диаграммой (см. рис. 1).

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

Процесс оценки и выбора CASE-средств можно рассмотреть в виде модели. Этот процесс может преследовать несколько целей и включать:

  • оценку нескольких CASE-средств и выбор одного или более из них;
  • оценку одного или более CASE-средств и сохранение результатов для последующего использования;
  • выбор одного или более CASE-средств с использованием результатов предыдущих оценок.

Ниже приведена диаграмма, описывающая наиболее общую ситуацию оценки и выбора, а также показывает зависимость между ними (см. рис. 2).

Как видно из рисунка, входной информацией для процесса оценки является:

  • определение пользовательских потребностей;
  • цели и ограничения проекта;
  • данные о доступных CASE-средствах;
  • список критериев, используемых в процессе оценки.

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

Элементы процесса включают:

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

Процесс оценки и/или выбора следует начинать только тогда, когда лицо, группа или организация полностью определила для себя конкретные потребности и формализовала их в виде количественных и качественных требований в заданной предметной области. Далее термин "пользовательские требования" означает именно такие формализованные требования.

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

Определение списка критериев основано на пользовательских требованиях и включает:

  • выбор критериев для использования из приведенного далее перечня;
  • определение дополнительных критериев;
  • определение области использования каждого критерия (ценка, выбор или оба процесса);
  • определение одной или более метрик для каждого критерия оценки;
  • назначение веса каждому критерию при выборе.

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

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

  1. подтвердить достоверность результатов оценки и выбора;
  2. определить, действительно ли CASE-средство годится для использования в данной организации, и если да, то определить наиболее подходящую область его применения;
  3. собрать информацию, необходимую для разработки плана практического внедрения;
  4. приобрести собственный опыт использования CASE-средства.

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

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

План перехода должен включать следующее:

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

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

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

В дополнение к этому следует отметить, что каждая категория сотрудников (например, администраторы средств, служба поддержки рабочих мест, интеграторы средств, служба сопровождения и разработчики приложений) нуждается в различном обучении.
Обучение не должно замыкаться только на пользователях CASE-средств, обучаться должны и те сотрудники, на деятельность которых так или иначе оказывает влияние использование CASE-средств.

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

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

  • использованное время;
  • время, выделенное персонально для конкретных специалистов;
  • размер, сложность и качество ПО;
  • удобство сопровождения.

Еще до начала внедрения CASE-средств метрическая оценка должна начинаться с реальной оценки текущего состояния среды и поддерживать процедуры постоянного накопления данных.

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

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

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

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

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

Кейс-технология в образовании: общая характеристика

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

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

Существующие обозначения рассматриваемой технологии

Так, в зарубежных публикациях встречаются следующие названия метода:

  • деловых историй;
  • изучения ситуации;
  • метод кейсов.

Наши издания называют рассматриваемый метод следующим образом:

  • АКС (анализа конкретных ситуаций);
  • кейс-метод;
  • деловых ситуаций;
  • ситуационные задачи (впервые понятие ввели американские исследователи Й. Уилсон, Дж. Эткинсон в 2001 г.).

Кейс-технология в образовании: что это такое?

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

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

Что дает такой метод?

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

Требования, которым должен удовлетворять хороший кейс

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

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

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

Отличительные признаки рассматриваемого метода

Известно, что их шесть:

  1. Коллективная выработка рациональных решений.
  2. Наличие единой цели.
  3. Присутствие управляемого эмоционального напряжения учащихся.
  4. Наличие модели именно социально-экономической системы, чье состояние рассматривается в определенный дискретный временной период.
  5. Многовариантность решений (единое решение принципиально отсутствует).
  6. Присутствие системы коллективного оценивания деятельности.

Технологические особенности рассматриваемого метода

Их также шесть:

  1. Кейс-технология в сфере высшего образования - это специфическая разновидность исследовательской технологии (аналитической).
  2. Рассматриваемый метод выступает в качестве технологии коллективного обучения, ее важнейшими составляющими является групповая работа и взаимный информационный обмен.
  3. Его можно рассматривать в виде синергетической технологии, чьей сутью выступает подготовка процедур погружения всей группы в конкретную ситуацию, формирование эффектов приумножения знания, обмена открытиями, инсайтного озарения и проч.
  4. Кейс-технология в образовании (английский вариант названия метода упоминался ранее) интегрирует ряд в том числе процедуры группового, коллективного, индивидуального развития и формирования всесторонних личностных качеств студентов.
  5. Он выступает в качестве специфической разновидности проектной технологии. В отличие от простой ее формы, в рамках рассматриваемого метода происходит формирование проблемы вместе с путями ее решения на базе кейса, выступающего одновременно и техзаданием, и информационным источником в целях осознания альтернативных вариантов наиболее эффективных действий.
  6. Данный метод концентрирует весомые достижения такой технологии, как «создание успеха». Он предусматривает деятельность, ориентированную на активизацию студентов, подчеркивание их достижений, стимулирование успеха обучающихся. Непосредственно достижение успеха - одна из главенствующих сил метода, а также формирование устойчивой положительной мотивации, наращивание познавательной активности.

Рассматриваемая технология в рамках начальной школы

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

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

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

Задания для квестов

Они могут быть в виде:

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

Освоение речевого этикета детьми посредством рассматриваемого метода

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

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

Кейс-технологии в дошкольном образовании позволяют сформировать все 3 главных компонента речевого этикета:

  1. Овладение различными вариантами формул.
  2. Более подробное их «развертывание».
  3. Сопровождение формул доброжелательной интонацией, приветливой мимикой.

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

Методы кейс-технологии

Их шесть:

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

Лекция 11. Case-технологии и их использование Тем Case-технологии и их использование - страница №1/1

Лекция 11.CASE-технологии и их использование

Тема1. CASE-технологии и их использование

В последнее время сложилась своеобразная культура проектирования жизненного цикла компании, производства, деятельности. Естественно, в настоящих условиях такого рода проектирования производятся на базе компьютерных технологий. Примером такого рода является CASE-про ек тирование (Computer-Aided Software/System Engineering) - относительно новое направление в современных компьютерных технологиях. Эта область научного подхода к управлению бизнес-процессом настоящее время интенсивно развивается. Тем не менее, затруднительно дать точное общее определение CASE средств.

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

Базой CASE-развития стали методологии "классического" системного анализа. Для программного обеспечения (ПО) основным является понятие жизненного цикла (ЖЦ), как правило, разбиваемого на этапы: анализ требований, проектирование, кодирование, тестирование и отладка, эксплуатация и сопровождение.

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

Таким образом, в этом случае наиболее важными этапами ЖЦ являются первые два этапа: анализ и проектирование.

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

Остановимся кратко на особенностях Анализа и Проектирования.

Анализ требований является первым этапом ЖЦ программного продукта. Этот этап должен решить ключевые для проекта вопросы -


  • Каковы требования, предъявляемые к системе?

  • Каковы средства, предоставляемые системе для решения предоставленных задач?
Эти вопросы должны определить исходную архитектуру, интерфейс продукта, ограничения, налагаемые на ресурсы.

Проектирование отвечает на вопрос "Как система будет удовлетворять предъявленным к ней требованиям?".

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

Бурным развитием CASE системы обязаны тому, что изначально они ориентированны на применение именно в начале жизненного цикла.

В своем развитии CASE средства прошли два основных этапа.

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

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

При использовании CASE систем изменяется распределение трудозатрат по фазам ЖЦ (ниже приведена таблица сравнения трудозатрат)

Таблица 1.



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

Тенденции развития современных информационных технологий

Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности информационных систем (ИС). Современные крупные проекты ИС характеризуются, как правило, следующими особенностями:

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

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

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

  • необходимость интеграции существующих и вновь разрабатываемых приложений;

  • функционирование в неоднородной среде на нескольких аппаратных платформах;

  • разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств;

  • существенная временная протяженность проекта, обусловленная, с одной стороны, ограниченными возможностями коллектива разработчиков, и, с другой стороны, масштабами организации-заказчика и различной степенью готовности отдельных ее подразделений к внедрению ИС.
Для успешной реализации проекта объект проектирования (ИС) должен быть прежде всего адекватно описан, должны быть построены полные и непротиворечивые функциональные и информационные модели ИС. Накопленный к настоящему времени опыт проектирования ИС показывает, что это логически сложная, трудоемкая и длительная по времени работа, требующая высокой квалификации участвующих в ней специалистов. Однако до недавнего времени проектирование ИС выполнялось в основном на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ИС. Кроме того, в процессе создания и функционирования ИС информационные потребности пользователей могут изменяться или уточняться, что еще более усложняет разработку и сопровождение таких систем.

В 70-х и 80-х годах при разработке ИС достаточно широко применялась структурная методология, предоставляющая в распоряжение разработчиков строгие формализованные методы описания ИС и принимаемых технических решений. Она основана на наглядной графической технике: для описания различного рода моделей ИС используются схемы и диаграммы. Наглядность и строгость средств структурного анализа позволяла разработчикам и будущим пользователям системы с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических решений. Однако, широкое применение этой методологии и следование ее рекомендациям при разработке конкретных ИС встречалось достаточно редко, поскольку при неавтоматизированной (ручной) разработке это практически невозможно. Действительно, вручную очень трудно разработать и графически представить строгие формальные спецификации системы, проверить их на полноту и непротиворечивость, и тем более изменить. Если все же удается создать строгую систему проектных документов, то ее переработка при появлении серьезных изменений практически неосуществима.

Ручная разработка обычно порождала следующие проблемы:


  • неадекватная спецификация требований;

  • неспособность обнаруживать ошибки в проектных решениях;

  • низкое качество документации, снижающее эксплуатационные качества;

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

Перечисленные факторы способствовали появлению программно-технологических средств специального класса - CASE-средств, реализующих CASE-технологию создания и сопровождения ИС. Термин CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.

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


  • подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;

  • широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования;

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

CASE-средства. Общая характеристика и классификация

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

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

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

Понятие CASE - средств

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

  • мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;

  • интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;

  • использование специальным образом организованного хранилища проектных метаданных (репозитория).
Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты;

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

  • графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

  • средства разработки приложений, включая языки 4GL и генераторы кодов;

  • средства конфигурационного управления;

  • средства документирования;

  • средства тестирования;

  • средства управления проектом;

  • средства реинжиниринга.

Общая характеристика и классификация. Характеристика CASE - средств

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:

  • применяемым методологиям и моделям систем и БД;

  • степени интегрированности с СУБД;

  • доступным платформам.
Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

  • средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

  • средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

  • средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

  • средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;

  • средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).
Вспомогательные типы включают:

  • средства планирования и управления проектом (SE Companion, Microsoft Project и др.);

  • средства конфигурационного управления (PVCS (Intersolv));

  • средства тестирования (Quality Works (Segue Software));

  • средства документирования (SoDA (Rational Software)).

Технология внедрения CASE-средств

Приведенная в данном разделе технология базируется в основном на стандартах IEEE (IEEE - Institute of Electrical and Electronics Engineers - Институт инженеров по электротехнике и электронике). Термин "внедрение" используется в широком смысле и включает все действия от оценки первоначальных потребностей до полномасштабного использования CASE-средств в различных подразделениях организации-пользователя. Процесс внедрения CASE-средств состоит из следующих этапов :
Анализ возможностей организации
Первым действием данного этапа является анализ возможностей организации в отношении ее технологической базы, персонала и используемого ПО. Такой анализ может быть формальным или неформальным.

Формальные подходы определяются моделью оценки зрелости технологических процессов организации CMM (Capability Maturity Model), разработанной SEI (Software Engineering Institute), а также стандартами ISO 9001: 1994, ISO 9003-3: 1991 и ISO 9004-2:1991. В центре внимания этих подходов находится анализ различных аспектов происходящих в организации процессов.

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

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

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

Общие вопросы


  • используемая модель ЖЦ (каскадная или спиральная);

  • используемые методы (структурные, объектно-ориентированные). Степень адаптации метода к потребностям организации; квалификация сотрудников;

  • наличие документированных стандартов (формальных или неформальных) по анализу требований, спецификациям и проектированию, кодированию и тестированию;

  • количественные метрики, используемые в процессе разработки ПО, их использование;

  • виды документации, выпускаемой в процессе ЖЦ ПО;

  • наличие группы поддержки средств проектирования.
Проекты, ведущиеся в организации

  • средняя продолжительность проекта в человеко-месяцах;

  • среднее количество специалистов, участвующих в проектах различных категорий (небольших, средних и крупных);

  • средний размер проектов различных категорий в терминах кодовых метрик (например, в строках исходных кодов), способ измерения.
Технологическая база

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


  • доступные вычислительные ресурсы, платформа разработки;

  • уровень доступности ресурсов, узкие места, среднее время ожидания ресурсов;

  • ПО, используемое в организации, и его характер (готовые программные продукты, собственные разработки);

  • степень интеграции используемых программных продуктов, механизмы интеграции (существующие и планируемые);

  • тип и уровень сетевых возможностей, доступных группе разработчиков;

  • используемые языки программирования;

  • средний процент вновь разрабатываемых, повторно используемых и реально эксплуатируемых приложений.
Персонал

Главной целью оценки персонала является определение его отношения к возможным изменениям (позитивного, нейтрального или негативного). Вопросы, касающиеся оценки персонала, включают следующие:


  • реакция сотрудников организации (как отдельных людей, так и коллективов) на внедрение новой технологии. Наличие опыта успешных или безуспешных внедрений;

  • наличие лидеров, способных серьезно повлиять на отношение к новым средствам;

  • наличие стремления "снизу" к совершенствованию средств и технологии;

  • объем обучения, необходимого для ориентации пользователей в новой технологии;

  • стабильность и уровень текучести кадров.
Готовность

Целью оценки готовности организации является определение того, насколько она способна воспринять как немедленные, так и долгосрочные последствия внедрения CASE-средств. Вопросы, касающиеся оценки готовности, включают следующие:


  • поддержка проекта со стороны высшего руководства;

  • готовность организации к долгосрочному финансированию проекта;

  • готовность организации к выделению необходимых специалистов для участия в процессе внедрения и к их обучению;

  • готовность персонала к существенному изменению технологии своей работы;

  • степень понимания персоналом масштаба изменений;

  • готовность технических специалистов и менеджеров пойти на возможное кратковременное снижение продуктивности своей работы;

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

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

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

На сегодняшний день рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:


  • Vantage Team Builder (Westmount I-CASE);

  • Designer/2000;

  • Silverrun;

  • ERwin+BPwin;

  • S-Designor;

  • CASE.Аналитик.
. Кроме того, на рынке постоянно появляются как новые системы (например, CASE /4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE), так и новые версии и модификации перечисленных систем.
Оценка эффекта
Согласно обзору передовых технологий (Survey of Advanced Technology), составленному фирмой Systems Development Inc. в 1996 г. по результатам анкетирования более 1000 американских фирм, CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно). Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся "полочным" ПО (shelfware). В связи с этим необходимо отметить следующее:

  • CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;

  • реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

  • широкое разнообразие качества и возможностей CASE-средств;

  • относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;

  • широкое разнообразие в практике внедрения различных организаций;

  • отсутствие детальных метрик и данных для уже выполненных и текущих проектов;

  • широкий диапазон предметных областей проектов;

  • различная степень интеграции CASE-средств в различных проектах.
Вследствие этих сложностей доступная информация о реальных внедрениях крайне ограничена и противоречива. Она зависит от типа средств, характеристик проектов, уровня сопровождения и опыта пользователей. Некоторые аналитики полагают, что реальная выгода от использования некоторых типов CASE-средств может быть получена только после одно- или двухлетнего опыта. Другие полагают, что воздействие может реально проявиться в фазе эксплуатации жизненного цикла ИС, когда технологические улучшения могут привести к снижению эксплуатационных затрат.
Условия успешного внедрения
Для успешного внедрения CASE-средств организация должна обладать следующими качествами:

  • Технология. Понимание ограниченности существующих возможностей и способность принять новую технологию;

  • Культура. Готовность к внедрению новых процессов и взаимоотношений между разработчиками и пользователями;

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

Оценка СASE-средств

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

  • достоверная оценка отдачи от инвестиций в CASE-средства затруднительна ввиду отсутствия приемлемых метрик и данных по проектам и процессам разработки ПО;

  • внедрение CASE-средств может представлять собой достаточно длительный процесс и может не принести немедленной отдачи. Возможно даже краткосрочное снижение продуктивности в результате усилий, затрачиваемых на внедрение. Вследствие этого руководство организации-пользователя может утратить интерес к CASE-средствам и прекратить поддержку их внедрения;

  • отсутствие полного соответствия между теми процессами и методами, которые поддерживаются CASE-средствами, и теми, которые используются в данной организации, может привести к дополнительным трудностям;

  • CASE-средства зачастую трудно использовать в комплексе с другими подобными средствами. Это объясняется как различными парадигмами, поддерживаемыми различными средствами, так и проблемами передачи данных и управления от одного средства к другому;

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

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

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


  • высокий уровень технологической поддержки процессов разработки и сопровождения ПО;

  • положительное воздействие на некоторые или все из перечисленных факторов: производительность, качество продукции, соблюдение стандартов, документирование;

  • приемлемый уровень отдачи от инвестиций в CASE-средства.

Современные методы и средства проектирования информационных систем

Введение

Целью данного обзора является введение в особенности современных методов и средств проектирования информационных систем, основанных на использовании CASE-технологии.

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

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

Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности информационных систем (ИС), создаваемых в различных областях экономики. Современные крупные проекты ИС характеризуются, как правило, следующими особенностями:

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

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

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

· необходимость интеграции существующих и вновь разрабатываемых приложений;

· функционирование в неоднородной среде на нескольких аппаратных платформах;

· разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств;

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

Для успешной реализации проекта объект проектирования (ИС) должен быть прежде всего адекватно описан, должны быть построены полные и непротиворечивые функциональные и информационные модели ИС. Накопленный к настоящему времени опыт проектирования ИС показывает, что это логически сложная, трудоемкая и длительная по времени работа, требующая высокой квалификации участвующих в ней специалистов. Однако до недавнего времени проектирование ИС выполнялось в основном на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ИС. Кроме того, в процессе создания и функционирования ИС информационные потребности пользователей могут изменяться или уточняться, что еще более усложняет разработку и сопровождение таких систем.

В 70-х и 80-х годах при разработке ИС достаточно широко применялась структурная методология, предоставляющая в распоряжение разработчиков строгие формализованные методы описания ИС и принимаемых технических решений. Она основана на наглядной графической технике: для описания различного рода моделей ИС используются схемы и диаграммы. Наглядность и строгость средств структурного анализа позволяла разработчикам и будущим пользователям системы с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических решений. Однако, широкое применение этой методологии и следование ее рекомендациям при разработке конкретных ИС встречалось достаточно редко, поскольку при неавтоматизированной (ручной) разработке это практически невозможно. Действительно, вручную очень трудно разработать и графически представить строгие формальные спецификации системы, проверить их на полноту и непротиворечивость, и тем более изменить. Если все же удается создать строгую систему проектных документов, то ее переработка при появлении серьезных изменений практически неосуществима. Ручная разработка обычно порождала следующие проблемы:

· неадекватная спецификация требований;

· неспособность обнаруживать ошибки в проектных решениях;

· низкое качество документации, снижающее эксплуатационные качества;

· затяжной цикл и неудовлетворительные результаты тестирования.

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

Перечисленные факторы способствовали появлению программно-технологических средств специального класса - CASE-средств, реализующих CASE-технологию создания и сопровождения ИС. Термин CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.

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

· подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;

· широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования;

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

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

Согласно обзору передовых технологий (Survey of Advanced Technology), составленному фирмой Systems Development Inc. в 1996 г. по результатам анкетирования более 1000 американских фирм, CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно). Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся "полочным" ПО (shelfware). В связи с этим необходимо отметить следующее:

· CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;

· реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

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

· широкое разнообразие качества и возможностей CASE-средств;

· относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;

· широкое разнообразие в практике внедрения различных организаций;

· отсутствие детальных метрик и данных для уже выполненных и текущих проектов;

· широкий диапазон предметных областей проектов;

· различная степень интеграции CASE-средств в различных проектах.

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