Материал: Проблемы обеспечения надежности и качества приборов, устройств и систем

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

4. Бутырин А.А. Машинно-ориентированные методы и технические средства измерения параметров моделей двухполюсных радиоэлементов / А.А. Бутырин, И.В. Исаев, И.А. Мирошник // Элементы и устройства микроэлектронной аппаратуры: Межвуз. сб. науч. тр. Воронеж: ВГТУ, 1995. C.61-67.

5. Калюжный А.Н. Аттестация образцовых мер при измерениях в схемах с конечными нагрузками // Элементы и устройства микроэлектронной аппаратуры: Межвуз. сб. науч. тр. Воронеж: ВГТУ, 1999. C.111-115.

6. Бутырин А.А. К методике измерения Y-параметров многополюсников с учётом паразитных параметров измерительных цепей / А.А Бутырин, И.А. Мирошник // Материалы и устройства микроэлектронной аппаратуры: Элементы и устройства микроэлектронной аппаратуры: Межвуз. сб. науч. тр. Воронеж: ВГТУ, 1995. C.55-60.

Получено 05.09.2001 Воронежский государственный

технический университет

УДК 681.3.06

В.О. Попов

ВЫБОР CASE-ТЕХНОЛОГИЙ РАЗРАБОТКИ КОРПОРАТИВНЫХ

ИНФОРМАЦИОННЫХ СИСТЕМ

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

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

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

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

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

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

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

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

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

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

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

  • применяемым методологиям и моделям систем и баз данных (БД);

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

  • доступным платформам.

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

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

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

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

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

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

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

Оценка и накопление соответствующих данных может выполняться следующими способами:

  • анализ CASE-средств и документации поставщика;

  • опрос реальных пользователей;

  • анализ результатов проектов, использовавших данные CASE-средства;

  • просмотр демонстраций и опрос демонстраторов;

  • выполнение тестовых примеров;

  • применение CASE-средств в пилотных проектах;

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

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

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

  1. Поддержка полного жизненного цикла ИС с обеспечением эволюционности ее развития.

  2. Обеспечение целостности проекта и контроля за его состоянием.

  3. Независимость от программно-аппаратной платформы и СУБД.

  4. Открытая архитектура

  5. Качество технической поддержки в России, стоимость приобретения и поддержки, опыт успешного использования

  6. Простота освоения и использования

Иерархическая структура критериев оценки CASE - технологий показана на рисунке.

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

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

Проблемная ситуация, характерная для рассматриваемой задачи, заключается в том, что у ЛПР имеется конечный набор из N классов, к одному из которых можно отнести конкретный объект. Каждый объект характеризуется оценками по Q критериям качества. Градации по шкалам критериев представляют собой развернутые словесные формулировки и также упорядочены для ЛПР от лучшей к худшей.

Шаги алгоритма можно описать следующим образом.

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

  2. Представление алгоритмом ЛПР наиболее “информативных” гипотетических альтернатив - т.е. тех альтернатив, которые при причислении их к определенному классу обеспечат максимальное число альтернатив, которые перейдут в какой-либо класс. Для этого программа вычисляет так называемый индекс “информативности” альтернативы , где - оценка вероятности отнесения альтернативы i к классу l; - число альтернатив, принадлежность которых к некоторому классу становится известной, если ЛПР отнесет вектор альтернативу i к классу l. ЛПР предлагается диапазон классов - .

  3. Отнесение предложенной ЛПР альтернативы к какому-либо классу. Если ЛПР относит альтернативу к классу l, то все альтернативы, стоящие до нее, помечаются как отнесенные к классам - (l-1), сама альтернатива относится к классу l, альтернативы, стоящие после нее - к классам (l+1)- .

  4. Если не все гипотетические альтернативы отнесены к классам, то происходит определение очередной “информативной” альтернативы - т.е. переход к пункту 2, иначе - процесс идет далее по алгоритму.

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

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

Литература

1. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. М.: Финансы и статистика, 2000. 352 с.

2. Калянов Г.Н. CASE-технологии. Консалтинг при автоматизации бизнес - процессов. 2-е изд. перераб. и доп. М.: Горячая линия - Телеком, 2000. 320 с.

3. Ойхман Е.Г. Реинжиниринг бизнеса: реинжиниринг организаций и информационные технологии. / Е.Г. Ойхман, Э.В. Попов. М.: Финансы и статистика, 1997. 336 с.

4. Ларичев О.И. Качественные методы принятия решений. Вербальный анализ решений. / О.И. Ларичев, Е.М. Мошкович. М.: Наука, 1996. 208 с.

Получено 22.08.2001 Воронежский территориальный фонд

обязательного медицинского

страхования

УДК 624.396.6

А.М. Донец, Н.Э. Самойленко, С.А. Донец, А.И. Кононов

Подсистема маркетинговых исследований

Рассматриваются вопросы создания информационно-программного обеспечения маркетинговых исследований в САПР

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

Подсистема маркетинговых исследований запускается с помощью файла Marketing Research.exe или при помощи операционной оболочки подсистемы оценки конкурентоспособности изделий РЭС. После загрузки необходимых программных модулей на экран будет выведен рабочий стол подсистемы, внешний вид которого приведен на рис. 1.

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

Рис. 1. Рабочий стол подсистемы

Он создается при помощи пункта меню «Файл \ Новый проект». Файл проекта представляет собой специальный файл с расширением (.mrs) и директории с названием, совпадающим с именем файла проекта. В данной директории хранятся файлы базы данных и другие рабочие файлы. Если проект уже существует, то его можно открыть при помощи команды «Файл \ Открыть проект». Подсистема проверит корректность файла проекта, наличие описанных в нем параметров и, если ошибок не обнаружено, то загрузит базу данных и результаты последней работы с подсистемой.

После создания проекта необходимо сформировать опросную анкету для потребителей. Для этого в инспекторе операций выбирают пункт «Анкета \ Форматирование». После загрузки модуля рабочая область изменит свое название с «Рабочая панель» на «Формирование анкеты». Для формирования анкеты необходимо выполнить следующие операции: заполнить общий список технических вопросов для анкеты; после опроса экспертов необходимо занести результаты в базу данных; провести обработку экспертных оценок; выбрать необходимое число технических вопросов из всего списка; добавить к полученному списку вопросы общего характера, используемые при сегментировании. Общие вопросы к анкете хранятся в базе данных, доступной для всех проектов. Исправить информацию в ней можно с помощью пункта «Общие данные» инспектора операций. Верстка анкеты осуществляется путем выбора пункта «Анкета \ Верстка» в инспекторе операций. Модуль верстки анкеты представлен на рис. 2. Макет анкеты сохраняется в формате RTF и в случае необходимости может быть исправлен или изготовлен с использованием профессиональных текстовых редакторов. После верстки анкеты производится ее печать и размножение. Данная операция выполняется посредством пункта «Анкета \ Отчет» инспектора операций.

Рис. 2. Модуль верстки анкеты

После проведения анкетного опроса потребителей результаты заносятся в базу данных проекта. Данная операция выполняется при помощи пункта «Статистика \ Анкеты \ Редактирование». Вид рабочего стола модуля сбора статистики представлен на рис. 3.

Рис. 3. Модуль сбора анкетной статистики

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

Для правильной работы подсистемы необходимо точно заполнить все вопросы анкеты для всех анкет. Печать отчета по анкетному опросу производится посредством пункта «Статистика \ Анкеты \ Отчет».

Рис. 4. Модуль редактирования параметров изделий-конкурентов

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

Рис. 5. Сегментирование рынка по выбранному критерию

Следующим этапом работы с подсистемой маркетинговых исследований является сегментирование рынка. Запуск модуля сегментирования производится пунктом «Сегментирование \ Анализ». После загрузки модуля в выпадающем списке, расположенном в левом верхнем углу рабочего стола, следует выбрать критерий сегментирования.

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

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

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

Источник: https://studfile.net/preview/16568104/