Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Разработка информационных систем. Учебное пособие
.pdf
1.4. Характеристика процесса создания ИС
11
поддержка принятия решений;
статистическая обработка результатов эксперимента;
наполнение баз знаний для экспертных систем.
Сложная обработка информации выполняется практически во всех си-
стемах комплексной автоматизации предприятия – управления, проектирования, поддержки принятия решений. Такие системы классифицируются
как ИС обработки данных.
Каждой сфере применения соответствует свой тип ИС. Поэтому клас-
сифицировать ИС по этому признаку не имеет смысла.
По масштабности охвата задач выделяются корпоративные ИС, которые покрывают практически все информационные процессы предприятия.
Поэтому они часто называются системами комплексной автоматизации
предприятия.
1.4. Характеристика процесса создания ИС
Процесс создания любой ИС характеризуют такие понятия, как многостадийность, итерационность, многоуровневость и многоаспектность.
Понятие многостадийности означает следующее. Процесс создания ИС
условно разделяют на два этапа – внешнего и внутреннего проектирования.
На первом из них основная трудоёмкость его выполнения связана с разработкой технического задания (ТЗ) на создание ИС. Второй этап полностью
определяется работами по реализации ТЗ. При этом работы внутреннего
проектирования разбиты на стадии, которые называются «Эскизный проект», «Технический проект» и «Рабочий проект». Этап внутреннего проектирования заканчивается выпуском комплектов конструкторской и программной документации.
На этапе внешнего проектирования, в процессе формирования ТЗ, выполняется предварительная оценка эффективности проекта, под которой
понимается, прежде всего, конкурентоспособность продукта. Для обеспечения конкурентоспособности разработчики должны соблюдать общепринятые принципы в проектировании ИС, такие как системное единство,
совместимость, открытость, типизация и развитие.
Соблюдение принципа системного единства позволяет обеспечить целостность системы, связывая её отдельные элементы с объектом в целом.
1. Основные понятия и положения
12
Соблюдение принципа совместимости ориентировано на обеспечение
совместного функционирования всех частей и открытости системы. Если
соблюдать этот принцип, то можно существенно уменьшить трудозатраты,
так как при этом обеспечивается преемственность продукта и возможность
его модернизации.
Если соблюдать принцип типизации, то появляется возможность создания и применения типовых и унифицированных элементов. При этом типизация и унификация относится к тем элементам, которые в дальнейшем будут многократно использованы. Такие элементы должны подтверждать
своё соответствие современным требованиям, т. е. проходить экспертизу.
Важным принципом, который необходимо учитывать в работе над проектом, является соблюдение международных стандартов при разработке
пользовательских и межпрограммных интерфейсов.
В ИС применяются как инвариантные компоненты, так и специализированные (объектно-ориентированные). Поэтому при разработке ТЗ необходимо спрогнозировать типы и характеристики будущих объектов проектирования. При неудачном прогнозе потребуются затраты на модернизацию. В связи с этим задача качественного прогноза развития соответствующей области является важным элементом внешнего проектирования. На
этом этапе оцениваются затраты на реализацию всего проекта и их распределение по стадиям разработки при внутреннем проектировании.
Понятие многоуровневости связано с иерархическим представлением
объекта исследования или проектирования. При декомпозиции описаний
объекта на иерархические уровни становится возможным использование
либо нисходящего, либо восходящего подхода к процессу проектирования.
При создании ИС наиболее часто используется нисходящий подход, в
котором разработка начинается с системного уровня. По мере спуска с
верхних уровней на нижние решаются задачи в следующей последовательности:
1) выбираются структуры всех видов обеспечений ИС;
2) разрабатывается состав и связи компонентов в программно-
методических комплексах (ПМК) и утверждается состав рабочих станций
или разрабатываются специализированные аппаратные средства;
3) разрабатываются компоненты ПМК и выполняется адаптация и ин-
теграция ПМК в ИС.
1.4. Характеристика процесса создания ИС
13
Важнейшей задачей системного уровня является принятие решений по
интерфейсам между ПМК. При этом возможны два подхода:
разрабатывается новая операционная среда;
покупаются рабочие станции с обеспеченным согласованием при-
меняемых ПМК.
Поэтому в ТЗ необходимо обязательно отражать требования к систем-
ному окружению, характеристикам технического обеспечения и описание
интерфейсов. Так как в нисходящем подходе проектирования возможны
неудачные решения, которые были приняты на предыдущих уровнях, то
понятно, что в этом случае имеет место итерационный характер.
Понятие многоаспектности связано с разработкой специфических ви-
дов обеспечений, которые, как правило, выполняют разные группы. В связи
с этим необходимо взаимное согласование принимаемых решений.
Специфику этапа внешнего проектирования во многом определяет
условие: выполняется проект для новой организации или для функционирующей организации со своими традициями? Однако независимо от этого
на этапе предпроектных исследований выполняются следующие виды работ:
формируются проектные процедуры и маршруты проектирования;
анализ связей подразделений и потоков информации между ними;
анализ состава организации в целом, размещения в ней подразделе-
ний, их численность и квалификация персонала.
Проиллюстрируем рассмотренные понятия на примере иерархических
структур (рис. 1.1–1.3).
На рис. 1.1 показана структура, которая имеет корневую вершину
«ИС», и ветви, отражающие виды обеспечений ИС.
Иерархическая структура (рис. 1.2) имеет вершину «Техническое обес-
печение» (ТО) с ветвями – интерсеть и узлы. При этом интерсеть образуется из подсетей в рамках общей опорной сети. На нижнем уровне иерархической структуры ТО содержится конкретная информация по устройствам:
«Фирма – семейство – модель – количество».
Задача выбора вариантов технического обеспечения ставится в разных
формах: вербальная форма, задача математического программирования или
иная форма.
Вершина «Software» порождает иерархическую структуру, показанную
на (рис. 1.3). Для некоторых типов ИС бывает достаточно двух ПМК. В
1. Основные понятия и положения
14
этом случае, как правило, обходятся без процедур выбора технического
обеспечения и разработки операционной среды, а процесс создания ИС будет состоять в выборе или разработке ПМК. Для других типов ИС необходимо выбирать системное и сетевое ПО, а также компоненты технического
обеспечения.
Рис. 1.1. Иерархическая структура ИС
ИС
Техническое
обеспечение
Организационное и
методическое обес-
печение
Software
МО
ПО
ИО
ЛО
Фирма – тип – версия
Техническое обеспечение ИС
Интерсеть
Узлы
MF
WS
Рис. 1.2. Иерархическая структура
технического обеспечения ИС
Опорная сеть
Подсети
Фирма – семейство – модель – количество
Software
Программное обеспечение
Лингвистическое
обеспечение
Информационное
обеспечение
Рис. 1.3. Иерархическая структура Software ИС
Системное
Прикладное
Сетевое
FW
ОС
Конкретные ПМК
Фирма – тип – версия
1.5. Выбор компонентов ТО ИС
15
В связи с тем, что выбранная ЭВМ или её тип практически всегда опре-
деляет ОС и сетевое ПО (как и наоборот), вопросы выбора системного ПО
и технического обеспечения должны быть тесно взаимосвязаны.
При выборе технологии разработки ИС необходимо знать основные
требования к таким технологиям:
соответствие ТЗ и требованиям заказчика, несмотря на вносимые
изменения в процессе разработки;
интеграция разработки и сопровождения ИС при её эксплуатации;
обеспечение оптимальной трудоёмкости разработки и сопровожде-
ния.
Укрупнённая классификация методов разработки ИС отражает уровень
автоматизации и уровень применения типовых компонентов. При этом выделяются ручная и автоматизированная разработка. В первом случае не
применяются специальные инструментальные средства, а во втором случае
они широко используются.
Уровень применения типовых компонентов выделяет индивидуальную
разработку и типовую разработку. При индивидуальной разработке процесс выполняется в соответствии с требованиями ТЗ без применения типовых решений, а при типовой разработке широко используются готовые типовые компоненты, из которых выполняется сборка ИС.
1.5. Выбор компонентов ТО ИС
При выборе компонентов ТО ИС решаются следующие задачи выбора:
1) типов и количества ЭВМ и рабочих станций;
2) оптимальной архитектуры сети;
3) типов и количества узлов ВС.
Решение задач определения типов и количества ЭВМ и рабочих станций носит итерационный характер, из-за их тесной связи с выбором ПМК.
Первоначальный выбор класса ВС выполняется по требованиям к производительности. Конкретизация семейства ВС выполняется с учетом
наличия для него готового ПО, покрывающего возможно большую часть
проектных процедур в обобщённом маршруте проектирования. Знание характеристик выбранных ПМК позволяет уточнить требования к вычислительным ресурсам и, следовательно, обоснованно подойти к определению
моделей в выбранном семействе ЭВМ (рабочих станций). При расчете чис-
1. Основные понятия и положения
16
ла ЭВМ учитываются общие объемы вычислительных проектных работ,
целесообразность распределения технических средств по подразделениям
предприятия.
Исходными данными для определения состава ТО являются тип и характеристика объектов автоматизируемой области, прогнозирование потока заказов работ. В большинстве случаев такая информация является достаточной при предварительном формировании процедурной и инфологической схемы предметной области, для которой создаётся приложение. При
разработке процедурной схемы основной задачей является определение
маршрутов работы с каждым типом объектов. Если проектные работы, для
которых разрабатывается приложение, носят многономенклатурный характер, то возникает дополнительная задача оптимизации количества обобщенных маршрутов, покрывающих множество маршрутов для каждого типа объектов.
Каждый маршрут представляет собой направленный взвешенный граф,
вершины которого соответствуют проектным процедурам, а дуги – связям
процедур по информации. Веса вершин могут быть как скалярными, так и
векторными; они характеризуют затраты вычислительных ресурсов на выполнение процедуры. Например, вес I-й вершины может иметь вид
Gi (Qi, M
i, Э)i
,
где Qi – трудоемкость вычислений в i-й процедуре, измеряемая числом выполняемых арифметических и логических операций;
Мi – требуемый объем памяти (возможен учет затрат как оперативной,
так и внешней памяти);
Эi – оценка затрат времени на интерактивную работу пользователя с
ЭВМ (так называемое экранное время).
Веса дуг используются для представления объёмов данных, передаваемых между процедурами и, следовательно, между ПМК.
Особенностью графов, представляющих обобщенные маршруты проектирования, является наличие в них альтернативных дуг, отражающих то
или иное продолжение проектирования в зависимости от типа проектируемого изделия. Другими словами, выбор альтернатив может производиться
по заданной вероятности или определяться параметрами поступающих в
ИС заказов. Очевидно, что наличие подобных альтернативных дуг, вершин-источников заказов и т. п. сближает графы обобщённых маршрутов
1.5. Выбор компонентов ТО ИС
17
с сетями Петри или с другими графовыми формами представления систем
массового обслуживания (СМО). Поэтому процедурная схема приводит к
имитационным моделям СМО, использующим язык сетей Петри или другие языки описания процессов.
Перед разработкой системы состав ТО и ПО неизвестен, но известны
маршруты проектирования. В связи с этим предъявляется требование к
производительности ЭВМ имитационных экспериментов. При этом нужны
следующие исходные данные: зависимости величин Qi от параметров Х
проектируемых изделий (типы, показатели сложности); распределения вероятностей параметров Х, получаемые из прогноза частот поступления заказов на проектирование.
Характер зависимости Qi(Х) можно первоначально принять исходя из
теоретических представлений о возможностях типовых методов и алгоритмов проектных процедур. Далее в итерационном процессе эти зависимости
уточняются на основе опыта предыдущей эксплуатации пакетов программ,
аналогичных выбираемым или разрабатываемым для ИС. С помощью имитационных экспериментов определяют среднюю за прогнозируемый отрезок времени Т трудоемкость Q
iср
(загрузку) i-й проектной процедуры и мак-
симальную трудоемкость Q
imax
однократного выполнения этой процедуры.
Задаваясь допустимым временем Т
прi
однократного выполнения процедуры,
получаем оценку нижней границы производительности ЭВМ, необходимой
для i-й процедуры Pi = Q
imax/Tпрi
.
После выбора типа модели ЭВМ для процедуры i с производительностью Бi>Pi и сведения близких по Бi моделей к одной k-й модели с производительностью Бk рассчитывают число ЭВМ k-го типа
,/
kk
Ii
icpk
DБQN
k
где Ik – множество индексов процедур, обслуживаемых ЭВМ k-го типа,
Dk – число резервных ЭВМ k-го типа, приобретаемых для замены отка-
завших машин и компенсации неравномерной загрузки процедур.
Следует отметить, что приведенный подход определения Pi и Nk основан на предположении многономенклатурного проектирования, при котором основным критерием выбора состава ТО является требование максимальной загрузки приобретенного оборудования. Действительно, по этой
методике число ЭВМ определяется именно из условия их возможно полной
загрузки, в то же время требование минимизации времени выполнения за-
1. Основные понятия и положения
18
казов на проектирование практически не учитывается. Использование величин Т
прi
в этом отношении ничего не меняет: значения Т
прi
выбираются
субъективно, общее время Тm прохождения через ИС заказа на проектирование не минимизируется и не контролируется. Требование минимизации
Tm может стать основным при ориентации ИС на выполнение редких, но
крупных заказов (например, заказов на проектирование летательных аппаратов, заказных СБИС и т.п.) или при выделении среди множества заказов
некоторого приоритетного по срокам выполнения. В таких ситуациях целесообразно использовать методику разработки ТО, основанную на задачах
теории расписаний.
Инфологическая схема необходима при проектировании баз данных ИС
и является составляющей информационного обеспечения ИС. При этом
схему можно представить различными способами, например, графами, где
вершины – массивы данных, а ребра – связи между ними. Используется
также более эффективный подход, который называется объектноориентированным, где компоненты структуры – объекты, а трафик – поток
сообщений между ними.
1.6. Разработка программно-методических комплексов
Существует много технологий разработки оригинальных ПМК, в основе которых лежит та или иная технология проектирования ПО. Наиболее
распространённые технологии создания ПО ИС будут рассмотрены в разд. 4.
Процесс разработки ПО является многоуровневым и многостадийным.
На рис. 1.4 иллюстрируется нисходящая (от системного уровня к подпрограммному) последовательность проектирования и восходящая (от автономной отладки к системной) последовательность тестирования ПО.
7. Системная отладка
6. Комплексная отладка
5. Автономная отладка
1. Анализ требований
2. Разработка спецификаций
3. Функциональное проектиро-
вание
Уровень:
Системный
Программный
Подпрограммный
Рис. 1.4. Нисходящая и восходящая последовательность в разработке ПО
1.6. Разработка программно-методических комплексов
19
В процессе работы по формированию ТЗ определяются требования как
к функциональности самого ПМК, так и к его надёжности и устойчивости.
При этом надёжность оценивается как вероятность бессбойного решения
задач в ПМК (в частности, при условии бессбойной работы аппаратуры и
системного ПО). Отличие этой вероятности от единицы возможно по той
причине, что исходное (с позиции пользователя) описание ограничений дается в терминах соответствующих приложений и не всегда может быть однозначно переведено в математически строгое описание ограничений, присущих используемым методам и алгоритмам выполнения проектных процедур.
При этом сбои происходят как по вине пользователей (ошибки задания
данных), так и за счёт аппаратных сбоев. Возможность ПО продолжать работу при возникновении ошибок и сбоев с сохранением баз данных и программ определяет устойчивость ПО. В значительной мере устойчивость ПО
обеспечивается средствами полной и регулярной диагностики сбойных ситуаций.
При окончательном формировании требований к ПМК важно обеспечить модифицируемость и адаптируемость к изменениям в проектной деятельности. Часто в решении этой задачи помогает опыт работы с аналогичными системами. Известен ряд способов описания алгоритмов и программ,
например, граф-схемы и разновидности граф-схем типа "процедуры – файлы – связи по информации» или смешанное представление со связями по
управлению и по информации. Известны также функциональные диаграммы и языки спецификаций. В языках спецификаций допускаются как операторы языка программирования, так и элементы естественного языка. Для
упрощения восприятия сложной программы, как правило, используют
иерархичность описаний.
Различают формальные и неформальные языки спецификаций. Первые
из них – это языки программирования, в которых реализуются элементы
более высокоуровневых описаний, чем в обычных языках программирования. К ним можно отнести многие расширения традиционных языков программирования с введением ряда процедур, характерных для того или иного приложения, в число примитивов языка.
Неформальные языки спецификаций используются, прежде всего, для
лаконичного представления сложных алгоритмов и программ на верхних
уровнях иерархического проектирования ПО. Они удобны для анализа про-
1. Основные понятия и положения
20
граммных описаний людьми, используются также как средство публикации
алгоритмов. Обычно в языках спецификаций структура программы задается строго с помощью операторов формального языка, а содержание блоков
программы – на неформальном языке.
Разработка ПМК сопровождается формированием программной доку-
ментации. Единая система программной документации разрешает вносить
изменения в состав комплекта документов, но при этом в комплекте обязательно должны присутствовать описание программы и руководство пользователя.
1.7. Виды программ и программных документов
Состав и содержание программных документов должны отражать пол-
ный набор сведений, которые требуются для разработки, сопровождения и
эксплуатации программ.
Возможно объединение некоторых документов, но ведомость эксплуатационных документов и формуляр объединять с другими документами не
допускается. При разработке ТЗ решается вопрос выработки технических
условий по разработке, контролю и приёму программы, которые разрабатывают на стадии рабочего проекта.
Ниже приведены виды программных документов, краткое содержание
каждого документа, а в скобках обозначен их код.
1. Спецификация – состав программы и документация на программу.
2. Ведомость держателей подлинников (05) – предприятия, хранящие
подлинники программных документов.
3. Текст программы (12) – запись программы с комментариями.
4. Описание программы (13) – сведения о логической структуре и функ-
ционировании программы.
5. Техническое задание – назначение, применение, технические, эконо-
мические и другие требования, стадии и сроки разработки и испытаний.
6. Пояснительная записка (81) – схема и описание алгоритма, функцио-
нирование программы, технико-экономические решения.
7. Ведомость эксплуатационных документов (20) – перечень эксплуата-
ционных документов на программу.
8. Формуляр (30) – основные характеристики программы, комплектность
и сведения об эксплуатации программы.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]