CASE-средства

ВВЕДЕНИЕ

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

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

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

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

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

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

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

1. CASE-СРЕДСТВА. ОБЩАЯ ХАРАКТЕРИСТИКА И КЛАССИФИКАЦИЯ

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

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

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

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

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

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

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

Требования к функциям отдельных компонент в виде критериев оценки CASE-средств приведены в разделе 2.1.

Все современные 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). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
• средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке 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)).

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

• Vantage Team Builder (Westmount I-CASE);
• Designer/2000;
• Silverrun;
• ERwin;
• S-Designor;
• CASE.Аналитик.

Описание некоторых CASE-средств приведено в разделе 3. Кроме того, на рынке постоянно появляются как новые для отечественных пользователей системы (например, CASE /4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE), так и новые версии и модификации перечисленных систем.

2. ТЕХНОЛОГИЯ ВНЕДРЕНИЯ CASE-СРЕДСТВ

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

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

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

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

2.1 Оценка и выбор CASE-средств

2.1.1 Общие сведения

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

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

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

Рис.1. Модель процесса оценки и выбора

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

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

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

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

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

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

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

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

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

2.1.2 Критерии оценки и выбора

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

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

Типичный процесс оценки и/или выбора может использовать набор критериев различных типов.

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

Функциональные характеристики

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

1. Среда функционирования:
1. Проектная среда:
• поддержка процессов жизненного цикла. Определяет набор процессов ЖЦ, которые поддерживает CASE-средство. Примерами таких процессов являются анализ требований, проектирование, реализация, тестирование и оценка, сопровождение, обеспечение качества, управление конфигурацией и управление проектом, причем они зависят от принятой пользователем модели ЖЦ.
• область применения. Примерами являются системы обработки транзакций, системы реального времени, информационные системы и т.д.
• размер поддерживаемых приложений. Определяет ограничения на такие величины, как количество строк кода, уровней вложенности, размер базы данных, количество элементов данных, количество объектов конфигурационного управления.
2. ПО/технические средства:
• требуемые технические средства. Оборудование, необходимое для функционирования CASE-средства, включая тип процессора, объем оперативной и дисковой памяти.
• поддерживаемые технические средства. Элементы оборудования, которые могут использоваться CASE-средством, например, устройства ввода/вывода.
• требуемое ПО. Программное обеспечение, необходимое для функционирования CASE-средства, включая операционные системы и графические оболочки.
• поддерживаемое ПО. Программные продукты, которые могут использоваться CASE-средством.

Рис.2. Структура набора критериев

Технологическая среда:

• соответствие стандартам технологической среды. Такие стандарты касаются языка, базы данных, репозитория, коммуникаций, графического интерфейса пользователя, документации, разработки, управления конфигурацией, безопасности, стандартов обмена информацией и интеграции по данным, по управлению и по пользовательскому интерфейсу.
• совместимость с другими средствами. Способность к взаимодействию с другими средствами, включая непосредственный обмен данными (примерами таких средств являются текстовые процессоры, базы данных и другие CASE-средства). Возможность преобразования репозитория или его части в стандартный формат для обработки другими средствами.
• поддерживаемая методология. Набор методов и методик, поддерживаемых CASE-средством. Примерами являются структурный или объектно-ориентированный анализ и проектирование.
• поддерживаемые языки. Все языки, используемые CASE-средством. Примерами таких языков являются языки программирования (Кобол, Ада, С), языки баз данных и языки запросов (DDL, SQL), графические языки (Postscript, HPGL), языки спецификации проектных требований и интерфейсы операционных систем (языки управления заданиями).

2. Функции, ориентированные на фазы жизненного цикла:

1. Моделирование:  
   Данные критерии определяют способность выполнения функций, необходимых для спецификации требований к ПО и преобразованию их в проект:
• построение диаграмм. Возможность создания и редактирования диаграмм различных типов, представляющих интерес для пользователя.
• графический анализ. Возможность анализа графических объектов, а также хранения и представления проектной информации в графическом представлении. В большинстве случаев графические анализаторы интегрированы со средствами построения диаграмм.
• ввод и редактирование спецификаций требований и проектных спецификаций. К спецификациям такого рода относятся описания функций, данных, интерфейсов, структуры, качества, производительности, технических средств, среды, затрат и графиков.
• язык спецификации требований и проектных спецификаций. Возможность импорта, экспорта и редактирования спецификаций с использованием формального языка.
• моделирование данных. Возможность ввода и редактирования информации, описывающей элементы данных системы и их отношения.
• моделирование процессов. Возможность ввода и редактирования информации, описывающей процессы системы и их отношения.
• проектирование архитектуры ПО. Проектирование логической структуры ПО - структуры модулей, интерфейсов и др.
• имитационное моделирование. Возможность динамического моделирования различных аспектов функционирования системы на основе спецификаций требований и/или проектных спецификаций, включая внешний интерфейс и производительность (например, время отклика, коэффициент использования ресурсов и пропускную способность).
• прототипирование. Возможность проектирования и генерации предварительного варианта всей системы или ее отдельных компонент на основе спецификаций требований и/или проектных спецификаций. Прототипирование в основном касается внешнего пользовательского интерфейса и осуществляется при непосредственном участии пользователей.
• генерация экранных форм. Возможность генерации экранных форм на основе спецификаций требований и/или проектных спецификаций.
• возможность трассировки. Возможность сквозного анализа функционирования системы от спецификации требований до конечных результатов (установления и отслеживания соответствий и связей между функциональными и другими внешними требованиями к ИС, техническими решениями и результатами проектирования). Прямая трассировка (проверка учета всех требований) и обратная трассировка (поиск проектных решений, не связанных ни с какими внешними требованиями).
• синтаксический и семантический контроль проектных спецификаций. Контроль синтаксиса диаграмм и типов их элементов, контроль декомпозиции функций, проверка спецификаций на полноту и непротиворечивость.
• другие виды анализа. Конкретные дополнительные виды анализа могут включать алгоритмы, потоки данных, нормализацию данных, использование данных, пользовательский интерфейс.
• автоматизированное проектирование отчетов.
2. Реализация:  
   Реализация затрагивает функции, связанные с созданием исполняемых элементов системы (программных кодов) или модификацией существующей системы. Многие из перечисленных ниже критериев зависят от конкретных языков и включают следующие:
• синтаксически управляемое редактирование. Возможность ввода и редактирования исходных кодов на одном или нескольких языках с одновременным синтаксическим контролем.
• генерация кода. Возможность генерации кодов на одном или нескольких языках на основе проектных спецификаций. Типы генерируемого кода могут включать обычный программный код, схему базы данных, запросы, экраны/меню.
• компиляция кода.
• конвертирование исходного кода. Возможность преобразования кода из одного языка в другой.
• анализ надежности. Возможность количественно оценивать параметры надежности ПО, такие, как количество ошибок и др.
• реверсный инжиниринг. Возможность анализа существующих исходных кодов и формирования на их основе проектных спецификаций.
• реструктуризация исходного кода. Возможность модификации формата и/или структуры существующего исходного кода.
• анализ исходного кода. Примерами такого анализа могут быть определение размера кода, вычисление показателей сложности, генерация перекрестных ссылок и проверка на соответствие стандартам.
• отладка. Типичные функции отладки - трассировка программ, выделение узких мест и наиболее часто используемых фрагментов кода и т.д.
3. Тестирование:  
   Критерии тестирования включают следующие:
• описание тестов. Типичные возможности включают генерацию тестовых данных, алгоритмов тестирования, требуемых результатов и т.д.
• фиксация и повторение действий оператора. Возможность фиксировать данные, вводимые оператором с помощью клавиатуры, мыши и т.д., редактировать их и воспроизводить в тестовых примерах.
• автоматический запуск тестовых примеров.
• регрессионное тестирование. Возможность повторения и модификации ранее выполненных тестов для определения различий в системе и/или среде.
• автоматизированный анализ результатов тестирования. Типичные возможности включают сравнение ожидаемых и реальных результатов, сравнение файлов, статистический анализ результатов и др.
• анализ тестового покрытия. Оснащенность средствами контроля исходного кода и анализ тестового покрытия. Проверяются, в частности, обращения к операторам, процедурам и переменным.
• анализ производительности. Возможность анализа производительности программ. Анализируемые параметры производительности могут включать использование центрального процессора, памяти, обращения к определенным элементам данных и/или сегментам кода, временные характеристики и т.д.
• анализ исключительных ситуаций в процессе тестирования.
• динамическое моделирование среды. В частности, возможность автоматически генерировать моделируемые входные данные системы.

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

1. Документирование:
• редактирование текстов и графики. Возможность вводить и редактировать данные в текстовом и графическом формате.
• редактирование с помощью форм. Возможность поддерживать формы, определенные пользователями, вводить и редактировать данные в соответствии с формами.
• возможности издательских систем.
• поддержка функций и форматов гипертекста.
• соответствие стандартам документирования.
• автоматическое извлечение данных из репозитория и генерация документации по спецификациям пользователя.
2. Управление конфигурацией:
• контроль доступа и изменений. Возможность контроля доступа на физическом уровне к элементам данных и контроля изменений. Контроль доступа включает возможности определения прав доступа к компонентам, а также извлечения элементов данных для модификации, блокировки доступа к ним на время модификации и помещения обратно в репозиторий.
• отслеживание модификаций. Фиксация и ведение журнала всех модификаций, внесенных в систему в процессе разработки или сопровождения.
• управление версиями. Ведение и контроль данных о версиях системы и всех ее коллективно используемых компонентах.
• учет состояния объектов конфигурационного управления. Возможность получения отчетов о всех последовательных версиях, содержимом и состоянии различных объектов конфигурационного управления.
• генерация версий и модификаций. Поддержка пользовательского описания последовательности действий, требуемых для формирования версий и модификаций, и автоматическое выполнение этих действий.
• архивирование. Возможность автоматического архивирования элементов данных для последующего использования.
3. Управление проектом:
• управление работами и ресурсами. Контроль и управление процессом проектирования ИС в терминах структуры заданий и назначения исполнителей, последовательности их выполнения, завершенности отдельных этапов проекта и проекта в целом. Возможность поддержки плановых данных, фактических данных и их анализа. Типичные данные включают графики (с учетом календаря, рабочих часов, выходных и др.), компьютерные ресурсы, распределение персонала, бюджет и др.
• оценка. Возможность оценивать затраты, график и другие проектные параметры, вводимые пользователями.
• управление процедурой тестирования. Поддержка управления процедурами и программой тестирования, например, управления расписанием планируемых процедур, фиксация и запись результатов тестирования, генерация отчетов и т.д.
• управление качеством. Ввод соответствующих данных, их анализ и генерация отчетов.
• корректирующие действия. Поддержка управления корректирующими действиями, включая обработку сообщений о проблемных ситуациях.

2.1.2.1 Надежность

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

2.1.2.2 Эффективность

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

2.1.2.3 Общие критерии

Приведенные ниже критерии являются общими по своей природе и не принадлежат к совокупности показателей качества, приведенной в стандарте ISO/IEC 9126: 1991.

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

3. ХАРАКТЕРИСТИКА CASE-СРЕДСТВ

3.1 Silverrun+JAM

3.1.1 Silverrun

CASE-средство Silverrun американской фирмы Сomputer Systems Advisers, Inc. (CSA) используется для анализа и проектирования ИС бизнес-класса и ориентировано в большей степени на спиральную модель ЖЦ. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм "сущность-связь").

Настройка на конкретную методологию обеспечивается выбором требуемой графической нотации моделей и набора правил проверки проектных спецификаций. В системе имеются готовые настройки для наиболее распространенных методологий: DATARUN (основная методология, поддерживаемая Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information Engineering. Для каждого понятия, введенного в проекте имеется возможность добавления собственных описателей. Архитектура Silverrun позволяет наращивать среду разработки по мере необходимости.

Структура и функции

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

Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных (BPM - Business Process Modeler) позволяет моделировать функционирование обследуемой организации или создаваемой ИС. В модуле BPM обеспечена возможность работы с моделями большой сложности: автоматическая перенумерация, работа с деревом процессов (включая визуальное перетаскивание ветвей), отсоединение и присоединение частей модели для коллективной разработки. Диаграммы могут изображаться в нескольких предопределенных нотациях, включая Yourdon/DeMarco и Gane/Sarson. Имеется также возможность создавать собственные нотации, в том числе добавлять в число изображаемых на схеме дескрипторов определенные пользователем поля.

Модуль концептуального моделирования данных (ERX - Entity-Relationship eXpert) обеспечивает построение моделей данных "сущность-связь", не привязанных к конкретной реализации. Этот модуль имеет встроенную экспертную систему, позволяющую создать корректную нормализованную модель данных посредством ответов на содержательные вопросы о взаимосвязи данных. Возможно автоматическое построение модели данных из описаний структур данных. Анализ функциональных зависимостей атрибутов дает возможность проверить соответствие модели требованиям третьей нормальной формы и обеспечить их выполнение. Проверенная модель передается в модуль RDM.

Модуль реляционного моделирования (RDM - Relational Data Modeler) позволяет создавать детализированные модели "сущность-связь", предназначенные для реализации в реляционной базе данных. В этом модуле документируются все конструкции, связанные с построением базы данных: индексы, триггеры, хранимые процедуры и т.д. Гибкая изменяемая нотация и расширяемость репозитория позволяют работать по любой методологии. Возможность создавать подсхемы соответствует подходу ANSI SPARC к представлению схемы базы данных. На языке подсхем моделируются как узлы распределенной обработки, так и пользовательские представления. Этот модуль обеспечивает проектирование и полное документирование реляционных баз данных.