Logo GenDocs.ru

Поиск по сайту:  


Загрузка...

Реферат - Информационные системы. Модели систем массового обслуживания - файл Инф.Системы.docx


Реферат - Информационные системы. Модели систем массового обслуживания
скачать (371.3 kb.)

Доступные файлы (1):

Инф.Системы.docx463kb.31.01.2009 12:10скачать

содержание
Загрузка...

Инф.Системы.docx

Реклама MarketGid:
Загрузка...
Содержание


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


1 Модели систем массового обслуживания

Функционирование информационной системы в режиме коллективного пользования может быть описано в терминах систем массового обслуживания (СМО). На вход информационной системы поступает поток заявок от пользователей системы («клиентов» в терминах СМО). Заявки поступают в очередь на обслуживание, где ожидают, пока не освободятся ресурсы системы (канал обслуживания), занятые обслуживанием других заявок.

^ Простейшие модели СМО: одно- и m-канальные разомкнутые и замкнутые СМО с бесконечным числом мест ожидания.

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

Рисунок 1.1 – m-канальная система массового обслуживания

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

На рис. 1.2 показана замкнутая одноканальная СМО с числом пользователей N. Полагается, что каждый из них с интенсивностью λ отправляет заявки в СМО, если в СМО отсутствует заявка данного пользователя. Группа пользователей в этом случае может рассматриваться как N-канальная СМО с интенсивностью обслуживания λ.

^ Рисунок 1.2 – Схема замкнутой одноканальной СМО



2 Стохастические сетевые модели

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

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

^ Связи между СМО, входящих в сеть, определяются в результате анализа маршрутов следования заявки по сети.

Различают разомкнутые и замкнутые стохастические сети. В разомкнутых сетях интенсивность поступления заявок не зависит от состояния сети, т.е. от числа заявок, находящихся в сети. На рис. 2.1 и 2.2 показаны разомкнутые сети.
Рисунок 2.1 – Модель информационной системы с фиксированным маршрутом

прохождения заявок


Рисунок 2.2 – Модель информационной системы с разветвлением

маршрутов следования заявок

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

Рисунок 2.3 – Модель информационной системы в виде замкнутой сети СМО



Такая модель может использоваться при анализе информационной системы, число терминалов доступа к которой ограничено и равно в данном случае N. Здесь СМО 0 есть модель пользователей, посылающих заявки в информационную систему. С точки зрения теории массового обслуживания это система с N параллельными обслуживающими приборами, очередь у которой не образуется, поскольку каждый пользователь, послав заявку в информационную систему, ожидает ответа. Если рассматривать СМО 0 как элемент сети, то в такой сети всегда находится N заявок. СМО 1 – это часть информационной системы, осуществляющая первую фазу обработки заявок; на вторую фазу (СМО 2) поступает только часть заявок ( вероятность p2), другие (вероятность p1) возвращаются пользователю после первой фазы обработки.
3 Сети Петри

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

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

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

^ Сети Петри представляются с помощью графа G(V,A), где V – множество вершин графа, A – множество направленных дуг.

Множество вершин графа V образуется двумя подмножествами, называемыми позициями – P и переходами – T. Позиции и переходы – основные понятия СП. Позиции сопоставляются дискретным состояниям исследуемых объектов, а переходы – процессам, в результате которых объект переходит из одного состояния в другое.

Дуги графа A являются направленными и соединяют вершины разного типа. Граф, множество вершин V которого допускает разбиение на два подмножества P и T так, что ни одна из дуг графа не соединяет вершины одного и того же подмножества, называется двудольным. В СП дуги могут быть кратными. Граф, допускающий кратные дуги, называется мультиграфом.

^ При графическом представлении СП для обозначения позиции используются кружки (О), а для обозначения переходов – планка (|).

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

^ Размещение маркеров по позициям сети называется маркировкой СП. Количество и положение маркеров в СП может меняться.

Перемещение маркеров по сети отображает переходы исследуемого объекта из состояния в состояние. При задании сети всегда указывается её начальная маркировка. Изменение маркировки происходит в результате выполнения переходов.

Маркировка СП задаётся функцией М, которая отображает множество позиций в множество неотрицательных целых чисел. Если позиции СП пронумеровать, то маркировку сети удобно представить в виде n-мерного вектора М(Р)={m1, m2, …mn}, значения координат которого m1,...mn равны числу маркеров в соответствующих позициях.

^ 3.1 Обобщение сетей Петри

Не все информационные процессы удаётся описать с помощью простых сетей. В связи с этим появились различные обобщения СП.

^ В простой СП при наличии нескольких разрешённых переходов для срабатывания выбирается только один, причём любой.

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

Приоритетная сеть расширена относительно простой сети введением множества приоритетов. При этом каждому переходу tj соответствует его приоритет pr(tj).

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

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

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

В синхронных сетях все разрешённые и не конфликтующие переходы срабатывают одновременно.

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

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

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

Иерархические СП являются обобщением простых СП и служат для моделирования иерархических систем, которые наряду с неделимыми компонентами содержат составные компоненты, сами представляющие собой системы.
4 Проектирование информационных систем

Проектирование – это процесс перехода от первичного описания информационной системы в виде проектного задания к описанию её в виде набора стандартных документов (проектной документации), достаточного для создания системы.

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

Объектом проектирования является информационная система. Используется термин “система” поскольку имеется множество взаимосвязанных элементов, например множество взаимосвязанных задач: результаты решения одной необходимы для решения других и т.д. Множество элементов системы и связи между ними определяют структуру системы. Элементами структуры могут являться её составляющие, выделенные по различным признакам. Поэтому информационная система, как и всякая иная, может иметь множество различных структур: функциональную, структуру комплекса технических средств, структуру функциональной части, структуру обеспечивающей части, объектную структуру.

^ Элементами функциональной структуры информационной системы являются функциональные подсистемы.

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

^ Элементами объектной структуры информационной системы являются объектные подсистемы.

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

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

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

Обеспечивающая часть – это совокупность средств обеспечения выполнения системой предписанных функций. В состав обеспечивающей части входит ряд обеспечивающих подсистем:

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

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

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



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

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

^ Основные проблемы, требующие проработки на этапе проектирования:

а) состав функций, реализуемых информационной системой, их объединение в группы и распределение по уровням объекта, для поддержки функционирования которого создаётся информационная система;

б) разработка технологий обработки данных информационной системы;

в) разработка баз данных и информационных сервисов;

г) выбор технических средств информационной системы;

д) выбор программной платформы, разработка и отладка программных средств системы;

е) анализ достижимости требований, предъявляемых к показателям качества функционирования информационной системы и поиск путей для удовлетворения потребностей.
4.1 Стадии разработки информационных систем

Выделение отдельных стадий создания АСУ и определение содержания работ на каждой стадии имеет существенное значение для более чёткого планирования, оперативного контроля и управления деятельностью коллектива разработчиков и отдельных исполнителей [2].

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

Основное содержание стадии формирование требований – сбор данных и анализ объекта, для поддержки функционирования которого предполагается создание АС, анализ существующей информационной системы и обоснование целесообразности создания АС. На этой стадии проводятся следующие подготовительные операции для формирования требований: выбор показателей, выявление факторов, обуславливающих целесообразность создания АС, выявление требований пользователей АС.

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

На стадии техническое задание разрабатывается техническое задание (ТЗ) на автоматизированную систему. Состав и содержание ТЗ определены в нормативных документах. Основой ТЗ являются требования к создаваемой системе.

На стадии эскизный проект проводится проработка предварительных проектных решений по системе и её частям. Эта стадия может быть объединена со стадией технический проект.

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

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

документация, содержащая сведения, необходимые и достаточные для ввода в действия и эксплуатации АС.

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

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

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

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

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

^ Внутреннее проектирование определяет содержание самой системы.

Внешнее и внутреннее проектирование АС осуществляют в виде последовательных итераций, уточняя и детализируя результаты по мере расширения знаний о системе на различных стадиях проектирования.
4.2 ^ Требования к проектированию информационных систем

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

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

Требования к автоматизированной системе делят на три группы:

- требования к системе в целом;

- требования к функциям, выполняемым системой;

- требования к видам обеспечения.

Требования к системе в целом, как правило, включают в себя:

а) требования к структурным характеристикам и режимам функционирования системы:

1) состав основных функций;

2) объектная структура системы;

3) требования к средствам и способам обмена информацией между объектными подсистемами в случае их территориальной разобщённости;

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



5) требования к режимам функционирования системы.

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

в) требования к надёжности:

1) перечень отказов системы или её частей, по которым следует предъявлять требования по надёжности;

2) состав и количественные значения показателей надёжности по типам отказов для системы или её элементов;

3) требования к методам оценки и контроля надёжности на разных этапах создания системы;

г) требования к качеству данных:

1) показатели достоверности данных и их количественные значения;

^ 2) возможные способы несанкционированного доступа к данным, от которых система должна быть защищена;

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

е) требования к развитию системы: возможности модификации, включения новых функций, открытости, масштабируемости.

Требования к функциям, выполняемым системой, включают в себя:

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

- требования к качеству реализации каждой функции;

- формы представления входной и выходной информации;

- требования к качеству результатов.

^ Состав требований к видам обеспечения зависит от типа и назначения системы.

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

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

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

^ 4.3 Показатели качества информационных систем

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

а) экономические – прибыль, эксплуатационные затраты, экономическая эффективность как отношение разности дохода и затрат к затратам;

б) технические – показатели технологии обработки данных ( временные показатели, показатели качества информации; показатели надёжности, производительности; эксплуатационные показатели, например, коэффициент загрузки; показатели научно-технического уровня);

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

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

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

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

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

4.4 Информационный поток

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

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

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

б) средним объёмом информации, поступающей в единицу времени;

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

^ Перечисленные характеристики потока могут быть определены на основе данных наблюдений.

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

а) ординарностью – события появляются поодиночке, вероятность того, что на интервале длиною дельта t появится два и более события, стремится к нулю при уменьшении дельта t;

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

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

^ 4.5 CASE – технологии

Аббревиатуре CASE (Computer-aided Software Engineering) может быть поставлен в соответствие следующий перевод – автоматизированная разработка программного обеспечения.

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



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

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

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

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

^ Наибольшее распространение получили следующие две модели ЖЦ:

- каскадная модель;

- спиральная модель.

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

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

Каскадная модель хорошо зарекомендовала себя при разработке ПО, для которого в самом начале можно достаточно точно и полно сформулировать все требования. Такая ситуация имеет место при разработке сложных расчётных систем, систем реального времени и других аналогичных задач.

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

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

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



В жизненном цикле ПО этапы проектирования и программирования разделены. Такое разделение связано с тем, что при чётком изложении того, что и как должна делать система, процесс написания программы может быть автоматизирован. Поэтому особое значение приобретает именно этап проектирования, где требуется творческое участие разработчика.

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

Несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате чего создание с их помощью ПО становится «полочным» (shelfware).

^ В связи с этим необходимо отметить следующее:

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

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

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

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

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

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

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

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

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

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

Однотомное издание

1. Лецкий, Э. К. Информационные технологии на железнодорожном транспорте: учебник для вузов ж.-д. трансп. / Э. К. Лецкий, В. И. Панкратов, В.В. Яковлев. М.: УМК МПС России, 2000. 680 с.

2. Мамиконов А. Г. Проектирование АСУ/ А. Г. Мамиконов. М.: Высшая школа, 1987. 303 с

3. Калянов Г. Н. CASE: структурный системный анализ / Г.Н. Калянов. М.: ЛОРИ, 1996. 242 с.

4. Вендров А. М. Ниша и внедрение CASE-средств. – http: // citforum. ru.





Скачать файл (371.3 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации
Рейтинг@Mail.ru