Uchebnoe Posobie Skis 18

Министерство образования и науки Российской Федерации
ФГАОУ ВО «Севастопольский государственный университет»
Институт информационных технологий
и управления в технических системах
Кафедра «Информационные системы»
СОВРЕМЕННЫЕ КОРПОРАТИВНЫЕ
ИНФОРМАЦИОННЫЕ СИСТЕМЫ
КУРСОВОЙ ПРОЕКТ
Учебно-методическое пособие
для студентов всех форм обучения направления подготовки
09.04.02 «Информационные системы и технологии» (магистратура)
Севастополь
2018
2
УДК 004.07
Учебно-методическое пособие по дисциплине «Современные корпоративные
информационные системы» для студентов всех форм обучения направления
подготовки 09.04.02 «Информационные системы и технологии» (магистратура) /
Разраб. Ю.В. Доронина – Севастополь: Изд-во СевГУ, 2018.
Учебно-методическое пособие рассмотрено и утверждено на заседании кафедры
«Информационные системы», протокол № ___ от « » августа 2018 г.
3
Содержание
1. ОБЩИЕ СВЕДЕНИЯ, ЦЕЛИ И ЗАДАЧИ КУРСОВОГО
Стр
4
ПРОЕКТИРОВАНИЯ
2. СОДЕРЖАНИЕ ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ
4
3.ВЫБОР ТЕМ КУРСОВОГО ПРОЕКТИРОВАНИЯ
5
4.ПОРЯДОК ЗАЩИТЫ КУРСОВОГО ПРОЕКТА
5
5.ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ И ПРИМЕРЫ ВЫПОЛНЕНИЯ ЗАДАНИЯ
6
НА КУРСОВОЕ ПРОЕКТИРОВАНИЕ
5.1.Системный анализ задачи
6
5.2.Пример реализации системотехнического анализа сложных систем
6
5.3. Общие сведения о планировании эксперимента
10
6 МЕТОДИЧЕСКИЕ УКАЗАНИЯ К ВЫПОЛНЕНИЮ ПРАКТИЧЕСКИХ
18
РАБОТ
6.1Практическая работа №1
18
6.2Практическая работа №1
23
7. ПРИМЕР ОПИСАНИЯ РАЗРАБОТКИ СИСТЕМЫ ПОДДЕРЖКИ
33
ПРИНЯТИЯ РЕШЕНИЯ
8 ОБЩИЕ ТРЕБОВАНИЯ К ОФОРМЛЕНИЮ КП
42
Библиографический список
45
Приложение 1
47
Приложение 2
48
4
1. ОБЩИЕ СВЕДЕНИЯ, ЦЕЛИ И ЗАДАЧИ ПРОЕКТИРОВАНИЯ
Целью курсового проекта, выполняемого на 2 курсе магистратуры (III
семестр) в рамках дисциплины «Современные корпоративные информационные
системы» (СКИС), является активизация исследовательской деятельности
магистрантов в рамках подготовки выпускной квалификационной работы (ВКР) с
использованием требуемого математического аппарата для построения и анализа
сложных систем на основе процессов различной физической природы.
Содержание и объем задания курсового проекта каждого магистранта
согласовывается с научным руководителем ВКР не позже 2й учебной недели III
семестра.
2. СОДЕРЖАНИЕ ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ
Согласно плана НИР в магистратуре, в 3-ем семестре при реализации научных
исследований предполагается разработка этапов:
 системотехнический анализ задачи создания сложной ИС;
 формализация постановки задачи создания сложной ИС;
 декомпозиция задачи создания сложной ИС;
 вариантный анализ подходов к решению задачи создания сложной ИС
(выбор методов, выбор ПО, выбор СУБД и т.п.).
Таким образом, полное содержание пояснительной записки (ПЗ) к курсовому
проекту по дисциплине СКИС следующее:
1) Постановка задачи
(берется из отчета по НИР за I- II семестры, возможны корректировки по
согласованию с научным руководителем).
2) Системотехнический анализ задачи
(см. разделы 5.1-5.2, пример - раздел 5.3)
3) Анализ требований к системе и выбор критериев для оценки качества
решения задачи
(см. Практическая работа №1)
4) Формализация постановки задачи создания сложной системы
(см. Практическая работа №2)
5) Декомпозиция задачи создания сложной системы
(применяется один из известных методов: тривиальный на основе
дихотомической схемы, функциональный на основе разделения функций, линейное
программирование, метод ветвей и границ и т.п.)
6) Вариантный анализ подходов к решению задачи создания сложной
системы (применяется метод анализа иерархий на основе четких или нечетких
критериев в зависимости от типа задачи.
7) План решения научной задачи на основе методов планирования
эксперимента
(см. раздел 5.4)
8) Заключение, выводы
9) Библиографический список
5
3. ВЫБОР ТЕМ (ЗАДАЧ) КУРСОВОГО ПРОЕКТИРОВАНИЯ
Темы КП выбираются по согласованию с научным руководителем НИР. На
второй учебной неделе формируются листы задания на КП по дисциплине СКИС и
подписываются у ведущего преподавателя. Списки вывешиваются на доске
объявлений с подписями ведущего преподавателя и заведующего кафедрой.
4. ПОРЯДОК ЗАЩИТЫ КУРСОВОГО ПРОЕКТА
Согласно «Положения о планировании и организации учебного процесса»,
раздел 7.4.8:
Задание выдается в письменном виде не позднее, чем через 14 дней после
начала семестра, в котором выполняется проект.
Прием защиты курсового проекта (работы) производится комиссией из двух
человек, назначенной кафедрой, при непосредственном участии руководителя проекта (работы).
Курсовая работа (проект) оценивается отметками «отлично», «хорошо»,
«удовлетворительно» и «неудовлетворительно».
График защиты курсовых работ устанавливается соответствующей кафедрой вне учебного расписания.
Защита курсовой работы (проекта) состоит в кратком докладе студента по
выполненной теме (с использованием слайдов, графиков и других наглядных пособий) и его ответах на вопросы, задаваемые присутствующими на защите.
Защита курсовой работы оценивается по следующим критериям:
- степень усвоения студентом понятий и категорий по теме курсового исследования;
- умение работать с документальными и литературными источниками;
- умение формулировать основные выводы по результатам анализа конкретного материала;
- грамотность и стиль изложения материала;
- самостоятельность работы, оригинальность мышления в осмыслении материала;
- наличие презентации;
- умение доложить полученные результаты.
Выполненные проекты (работы) после их защиты хранятся на кафедре один
год, а затем списываются по акту, утвержденному заведующим кафедрой, и уничтожаются. Часть проектов, представляющих научно-практический интерес, может
быть оставлена на кафедре по решению заведующего кафедрой.
Итоги выполнения и защиты курсовых проектов (работ) обсуждаются на заседаниях кафедр.
Студент, не защитивший до начала экзаменационной сессии курсовой проект (работу), к экзаменам не допускается.
6
5. ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ И ПРИМЕРЫ ВЫПОЛНЕНИЯ
ЗАДАНИЯ НА КУРСОВОЕ ПРОЕКТИРОВАНИЕ
5.1 Системный анализ задачи
Системный анализ основывается на следующих принципах:
1) единства – совместное рассмотрение системы как единого целого и как
совокупности частей;
2) развития – учет изменяемости системы, ее способности к развитию,
накапливанию информации с учетом динамики окружающей среды;
3) глобальной цели – ответственность за выбор глобальной цели. Оптимум
подсистем не является оптимумом всей системы;
4) функциональности – совместное рассмотрение структуры системы и
функций с приоритетом функций над структурой;
5) децентрализации – сочетание децентрализации и централизации;
6) иерархии – учет соподчинения и ранжирования частей;
7) неопределенности – учет вероятностного наступления события;
8) организованности – степень выполнения решений и выводов.
В соответствующем разделе ПЗ в КП обосновывается системный аспект
работы на основе представленных выше принципов.
5.2 Пример реализации системотехнического анализа сложных систем
Ниже представлены элементы описания системы имитационного
моделирования деятельности предприятия с точки зрения системного анализа.
___________________________________________________________________
Разрабатываемая компьютерная система имитационного моделирования
деятельности предприятия (СИМДП) является сложной системой и при ее
проектировании необходимо пользоваться принципами системного анализа [13].
Представим СИМДП в виде «черного ящика» (рисунок 5.1), согласно
принципу глобальной (конечной) цели. Принцип конечной цели является
основополагающим принципом системного анализа, то есть конечная цель имеет
абсолютный приоритет, и вся логика функционирования системы должна быть
направлена на ее достижение [13].
Вектор Х – входные данные – будут включать информацию о маркетинговой
стратегии распространения продукта (население рассматриваемого региона,
общительность потенциальных клиентов, эффективность и объем рекламы,
сведения о качестве товара), а также факторы производства (количество рабочих и
станков, кладовщиков, заработная плата, производственная амортизация, стоимость
материала и т.д.).
Вектор Z – управляющие параметры – это глубина прогноза (количество
дней модельного времени), величина штрафа за «необслуженных» клиентов, цена
производимого товара и т.п.
Вектор Y – выходные данные – расходы (включает в себя амортизационные
затраты, выплату заработной платы, покупку материалов, заказ рекламы и т.д.), а
7
также доходы, связанные
«необслуженных» клиентов.
с
числом
проданных
товаров
и
количеством
Z
X
F
Y
Рисунок 5.1 — Структура разрабатываемой системы
Для выполнения равенства Y = F(X, Z) проектируемое средство должно
выполнять следующие функции (Фi):
– прогнозировать спрос на заданный тип товара на основании выбранной
маркетинговой стратегии (Ф1);
– моделировать функционирование предприятия, учитывая заданные
факторы производства(Ф2);
– с учетом рассчитанного спроса рассчитывать основные показатели
функционирования предприятия (доход, штрафы, расходы и т.п.)(Ф3);
– предусмотреть возможность проведения исследований, направленных на
повышение эффективности функционирования предприятия на основе составления
прогноза заданной глубины (Ф4).
Рассмотрим следующее важное понятие системного анализа – принцип
единства. Согласно ему, система должна рассматриваться с одной стороны как
целое, с другой – как совокупность составляющих ее элементов. Расчленение
системы (например, на подсистемы) необходимо производить, сохраняя целостное
представление о системе. Принцип подразумевает выделение подсистем,
композиция которых в совокупности со связями позволяет выполнять все функции
проектируемой системы, а вместе с тем непосредственным образом влияет и на ее
структуру [1]. В соответствии с принципом единства, на основании функций
проектируемой системы можно выделить следующие подсистемы:
— подсистема расчета спроса;
— подсистема имитационного моделирования деятельности предприятия;
— подсистема диалогового взаимодействия с пользователем;
— подсистема оптимизационных экспериментов.
Согласно принципу связности [1], любая часть системы должна
рассматриваться в совокупности со всеми связями, порожденными как
внутренними объектами по отношению к системе (другими элементами системы),
так и внешними.
Рассмотрим подсистему диалогового взаимодействия с пользователем. В
качестве основных требований можно выделить функциональность и
эргономичность. Интерфейс должен обеспечивать интуитивно понятное
управление основными параметрами модели и отображать результаты в удобном и
однозначно воспринимаемом виде. Входными данными для этой подсистемы
являются действия пользователя, а выходными — результаты взаимодействия ЛПР
с моделью поддержки принятия решения по организации производства
8
предприятием заданного типа товара.
Подсистемы моделирования деятельности предприятия и расчета спроса
должны в первую очередь обладать требуемой функциональностью, т.е.
обеспечивать зависимость между входными факторами и выходными показателями
модели на должном уровне адекватности. Кроме того, реализацию этой подсистемы
следует выполнять при помощи современных специализированных компонентов
сред разработки имитационных моделей, что поможет избежать так называемых
«отказов взаимодействия», а, кроме того, обеспечит требуемую наглядность и
простоту дальнейшего развития модели.
Подсистема оптимизационных экспериментов служит для достижения
основной цели имитационного моделирования – выработки решений по
оптимизации работы исследуемого предприятия на основе компьютерной системы
имитационного моделирования деятельности предприятия. Многие из этих
требований уже реализованы на уровне современных средств разработки
имитационных моделей, в частности, среды AnyLogic. Кроме того, согласно
принципу развития, необходимо предусмотреть возможность модификации
проектируемого
программного
комплекса.
В
качестве
дальнейшего
усовершенствования предлагается дополнительно расширить функциональную
составляющую, а также модифицировать модель для расширения области ее
применимости.
На рисунке 5.2 представлена структурная схема компьютерной системы
имитационного
моделирования
деятельности
предприятия,
указаны
информационные и управляющие сигналы.
Информационные сигналы:
1. Предпочтения пользователя, режим функционирования компьютерной
системы, исходные данные;
2. Текущие результаты, представленные в интерактивном режиме, а также
кортеж результирующих данных, состоящий из следующих компонент: расходы
предприятия (амортизационные затраты, выплата заработной платы, зараз рекламы
и т.п.), доход и прибыль от реализации произведенной продукции;
3. Необходимая априорная информация для функционирования подсистемы
имитационного моделирования деятельности предприятия;
4. Прирост спроса на производимую продукцию;
5. Результаты имитационного моделирования деятельности предприятия в
течение прогнозного периода;
6. Результаты проведенных имитационных экспериментов для отображения
подсистемой диалогового взаимодействия в интерактивном режиме.
Управляющие сигналы:
a. Запустить имитационный эксперимент с введенными пользователем
параметрами;
b. Представить текущие и результирующие данные в удобном для
пользователя виде;
c. Запустить имитационную дискетно-событийную модель деятельности
предприятия;
d. Получить данные о текущем спросе на инновационный товар.
9
Пользователь
1
2
Подсистема
диалогового
взаимодействия с
пользователем
Информационное
и методическое
обеспечение
3
Подсистема
имитационного
моделирования
Деятельности
предприятия
b
a
d
6
Подсистема
оптимизационных
экспериментов
С
7
Рисунок 5.2 – Структурная схема компьютерной системы имитационного
моделирования деятельности предприятия
Согласно принципа учета неопределенностей и случайностей в системе
необходимо предусмотреть реакцию на «некорректные» действия пользователя.
Все эти действия представляют собой типичные ситуации и соответствуют
процессу проектирования пользовательского интерфейса. Кроме того, необходимо
предусмотреть стохастичность некоторых процессов в модели, однако подробно
этот вопрос будет рассматриваться в последующих пунктах пояснительной
записки.
Выше приведенный текст является примером описания разрабатываемой
системы с точки зрения системного анализа.
5.3 ОБЩИЕ СВЕДЕНИЯ О ПЛАНИРОВАНИИ ЭКСПЕРИМЕНТА
Инициатором применения планирования эксперимента является Рональд А.
Фишер, другой автор известных первых работ – Френк Йетс. Далее идеи планирования эксперимента формировались в трудах Дж. Бокса, Дж. Кифера. В нашей
стране - в трудах Г.К. Круга, Е.В. Маркова и др.
Приступая к изучению какого-либо процесса, экспериментатор не имеет исчерпывающих сведений о механизме процесса. Можно только указать параметры
определяющие условия протекания процесса, и, возможно требования к его результатам. Поставленная проблема является задачей кибернетики. Если считать кибернетику «наукой, изучающей системы любой природы, способные воспринимать,
хранить и перерабатывать информацию для целей оптимального управления» [2],
то такую систему можно представить в виде черного ящика.
Математические методы планирования экспериментов основаны на так
называемом кибернетическом представлении процесса проведения эксперимента
(рис. 5.3).
10
Рис. 5.3. Кибернетическое представление эксперимента
На рис. 5.3:
– входные переменные, факторы;
– выходная переменная (реакция, отклик);
- ошибка, помеха, вызываемая наличием случайных факторов;
– оператор, моделирующий действие реальной системы, определяющий зависимость выходной переменной
от факторов
дель процесса, протекающего в системе [8].
, таким образом,
– мо-
5.3.1 Элементы регрессионного анализа
Зависимость между выходными параметрами (откликом) и входными параметрами (факторами) называется функцией отклика. Математическая запись функции отклика представлена в виде формулы (1):
y  F ( x1, x2 ,...,xk ) .
(1)
Этому уравнению в многомерном пространстве соответствует гиперповерхность, которая называется поверхностью отклика, а само пространство – факторным пространством.
Рисунок 5.4 – Поверхность отклика
Для
уравнение:
где
математического
описания
поверхности
отклика
- перемешанные факторы при i=1,…,k; u=1,…,k; i u;
используют
11
.
Это уравнение является разложением в ряд Тейлора неизвестной функции
отклика в окрестности точки с
.
На практике по результатам эксперимента производится обработка дан\ных
по методу наименьших квадратов. Этот метод позволяет найти оценку b коэффициентов  , и данный полином заменяется уравнением вида:
(2)
Уравнение (2) является регрессионной моделью (моделью регрессионного анализа). В этом выражении ŷ означает модельное, т.е. рассчитываемое по уравнению
модели, значение выхода. Коэффициенты регрессии определяются экспериментально и служат для статистической оценки теоретических коэффициентов, т.е.
2
В регрессионной модели члены второй степени xi xu , xi характеризуют
кривизну поверхности отклика. Чем больше кривизна этой поверхности, тем больше в модели регрессии членов высшей степени. На практике чаще всего стремятся
ограничиться линейной моделью [3].
Эксперимент можно проводить по-разному. В случае, когда исследователь
наблюдает за каким-то неуправляемым процессом, не вмешиваясь в него, или выбирает экспериментальные точки интуитивно, на основании каких-то привходящих
обстоятельств, эксперимент считают пассивным. В настоящее время пассивный
эксперимент считается неэффективным.
Гораздо более продуктивно проводится эксперимент, когда исследователь
применяет статистические методы на всех этапах исследования, и, прежде всего,
перед постановкой опытов, разрабатывая схему эксперимента, а также в процессе
экспериментирования, при обработке результатов и после эксперимента, принимая
решение о дальнейших действиях. Такой эксперимент считают активным, и он
предполагает планирование эксперимента.
Под планированием эксперимента понимают процедуру выбора числа и
условий проведения опытов, необходимых и достаточных для решения поставленной задачи с требуемой точностью.
Под математической моделью планирования понимается наука о способах
составления экономических экспериментальных данных планов, которые позволяют извлекать наибольшее количество информации об объекте исследования, о способах проведения эксперимента, о способах обработки данных и их использование
для оптимизации производственных процессов, а также инженерных расчетов [3].
Использование теории планирования эксперимента является одним из путей
существенного повышения эффективности многофакторных экспериментальных
исследований. В планировании экспериментов применяются в основном планы
12
первого и второго порядков. Планы более высоких порядков используются в инженерной практике редко. В связи с этим далее приводится краткое изложение методики составления планов эксперимента для моделей первого и второго порядков.
Под планом первого порядка понимают такие планы, которые позволяют провести
эксперимент для отыскания уравнения регрессии, содержащего только первые степени факторов и их произведения:
(5)
Планы второго порядка позволяют провести эксперимент для отыскания
уравнения регрессии, содержащего и вторые степени факторов:
(6)
Нахождение уравнения регрессии методом планирования экспериментов
состоит из следующих этапов:
 выбор основных факторов и их уравнений;
 планирование и проведение собственного эксперимента;
 определение коэффициентов уравнения регрессии;
 статистический анализ результатов эксперимента [3].
Если модель второго порядка оказалась неадекватной, следует повторить
эксперименты на меньшем интервале варьирования факторов или перенести центр
плана в другую точку факторного пространства. В тех случаях, когда адекватность
модели по-прежнему не достигается, рекомендуется перейти к планам третьего
порядка [3].
Использование теории планирования эксперимента является одним из путей
существенного повышения эффективности многофакторных экспериментальных
исследований. Под планированием эксперимента понимают процедуру выбора
числа и условий проведения опытов, необходимых и достаточных для решения поставленной задачи с требуемой точностью. Основные преимущества активного
эксперимента связаны с тем, что он позволяет:
1. Минимизировать общее число опытов;
2. Выбирать четкие логически обоснованные процедуры, последовательно
выполняемые экспериментатором при проведении исследования;
3. Использовать математический аппарат, формализующий многие действия
экспериментатора;
4. Одновременно варьировать всеми переменными и оптимально использовать факторное пространство;
5. Организовать эксперимент таким образом, чтобы выполнялись многие
исходные предпосылки регрессионного анализа;
6. Получать математические модели, имеющие лучшие в некотором смысле
свойства по сравнению с моделями, построенными из пассивного эксперимента;
7. Рандомизировать условия опытов, то есть многочисленные мешающие
факторы превратить в случайные величины;
13
8. Оценивать элемент неопределенности, связанный с экспериментом, что
дает возможность сопоставлять результаты, полученные разными исследователями.
В планировании экспериментов применяются в основном планы первого и
второго порядков. Планы более высоких порядков используются в инженерной
практике редко [4].
5.3.2 Точность и количество реализаций модели при определении средних
значений параметров
Найдем функциональную связь точности ε и достоверности α с количеством
реализаций модели, когда в качестве показателей эффективности выступают матожидание и дисперсия некоторой случайной величины (времени, расстояния и т. п.).
В N прогонах модели получены независимые значения интересующего нас
показателя эффективности:
В качестве оценки матожидания возьмем выборочное среднее (среднее
арифметическое):
(5.1)
Согласно центральной предельной теореме, если значения
независимы и
имеют конечные дисперсии одного порядка, то при большом числе слагаемых N случайная величина имеет практически нормальное распределение с матожиданием и дисперсией соответственно:
где
- дисперсия искомой случайной величины
Следовательно, справедливо
где
- интеграл вероятности.
В некоторых изданиях под интегралом вероятности понимают несколько
иное выражение, поэтому целесообразно пользоваться интегралом Лапласа, который связан с интегралом вероятности
так:
.
- интеграл Лапласа. Из приведенного следует:
Сравнивая это выражение с выражением (4.1), имеем:
14
Интеграл Лапласа табулирован, следовательно, задаваясь значением достоверности , определяется аргумент .
Искомая связь между точностью , достоверностью
и числом реализаций модели получена:
(5.2)


Из выражений (5.2) следует:
увеличение точности на порядок (уменьшение ошибки на порядок) потребует
увеличения числа реализаций на два порядка;
число необходимых реализаций модели
не зависит от величины искомого
параметра
а от дисперсии
Достоверность результата
указана значением аргумента функции Лапласа . Связь значения
с
находится из таблицы значений функции (интеграла)
Лапласа. Наиболее употребительные соответствия
и
приведены в таблице
5.1.
Таблица 5.1. Фрагмент таблицы функции (интеграла) Лапласа
Чтобы пользоваться формулами (5.2), нужно знать дисперсию
. Очень
редки случаи, когда значение дисперсии известно до эксперимента, поэтому возможны два способа предварительного определения дисперсии.
Первый способ. Иногда заранее известен размах значений искомой случайной величины:
В предположении нормального распределения случайной величины ,
можно с использованием "правила трех сигм" получить приближенную оценку
:
Второй способ. Надо воспользоваться оценкой дисперсии. Для этого необходимо выполнить предварительный прогон модели в количестве
реализаций. С использованием полученного ряда
персии:
Здесь - среднеарифметическое значение по
случае формулы (4.2) имеют вид:
, найдем оценку дис-
измерениям. И в этом
(5.3)
15
Вычисленную дисперсию
подставим в формулу для определения
.
Если окажется
то моделирование должно быть продолжено до выполнения
реализаций. Если же
, то моделирование заканчивается. Необходимая точность оценки случайной величины (искомого показателя эффективности) при заданной достоверности достигнута.
Если в технических условиях задана относительная точность
формулы (5.3) принимают вид:
, то
Значение определяется на основании
прогонов модели. Все
дальнейшие расчеты аналогичны только что рассмотренным аналитическим выражениям.
Приведенные рассуждения и выражения были справедливы в предположении нормального закона распределения случайной величины . В иных случаях
для
определения
связи ,
и
можно
воспользоваться неравенством
П.Ф.Чебышева:
С учетом направления знаков неравенств получим:
Также как и в предыдущих случаях вместо неизвестной дисперсии
дует использовать ее оценку
, вычисленную по данным
В выражениях (5.3) вместо неизвестной дисперсии
сле-
прогонов модели.
используется ее
оценка
. В этом случае вместо аргумента функции Лапласа
надо использовать параметр распределения Стьюдента , значения которого зависят не только
от уровня достоверности , но и от числа так называемых степеней свободы
. Здесь
- число прогонов модели. При
распределение
Стьюдента стремится к нормальному распределению, но при малом числе прогонов модели
заметно отличается от .
Для практических целей значения
можно взять из табл. 5.2.
Из табл. 5.2 видно, что при
значения
и
практически совпадают. Но при меньших значениях
следует пользоваться величиной .
Таблица 5.2. Таблица значений t_{a}
16
Далее рассмотрим задачу определения оценки дисперсии
случайной величины также с заданными точностью и достоверностью.
Опустим вывод и приведем окончательный вид формул для расчета
и :
где
- эмпирический центральный момент четвертого порядка:
Неизвестное значение
заменяется оценкой
, как было рассмотрено ра-
нее.
Если определяемая случайная величина имеет нормальное распределение,
то
и выражения для
и
принимают вид:
(5.4)
) следует использовать
Как и ранее при малых значениях
(
параметр распределения Стьюдента .
Из сопоставления (5.3) и (5.4) следует, что одно и то же количество реализаций модели обеспечит разное значение ошибки при оценке матожидания случайной величины и ее дисперсии - при одинаковой достоверности. И иначе:
одинаковую точность определения оценок матожидания и дисперсии случайного
параметра при одинаковой достоверности обеспечит разное число реализаций модели [8].
Пример. В результате предварительных прогонов модели
определена оценка дисперсии
.
Определить число реализаций модели
и
для определения оценок
матожидания и дисперсии случайной величины соответственно с точностью
и достоверностью
Решение
.
17
6 Методические указания к выполнению практических работ
6.1 ПРАКТИЧЕСКАЯ РАБОТА № 1
ИССЛЕДОВАНИЕ АСПЕКТОВ ИНЖЕРЕНИИ ТРЕБОВАНИЙ
К КОРПОРАТИВНОЙ СИСТЕМЕ
Цель работы: изучить основные аспекты инженерии требований и получить
практические навыки в построении моделей требований к корпоративной
информационной системе.
6.1.1 Теоретические сведения. Критерии качественных функциональных
требований
Инженерия требований (Requirements Engineering, RE) — поддисциплина системной инженерии, которая занимается разработкой требований. Главная
часть инженерии требований — это реверс-инжиниринг использующей
(над)системы (using system) для того, чтобы получить опив сания модели "чёрный
ящик".
Требования к программным продуктам или информационным системам (ИС)
можно разделить на две большие группы. Это функциональные требования
(описывающие, что необходимо реализовать в продукте или системе, в т.ч. какие
действия должны выполнять пользователи при взаимодействии с ними) и нефункциональные требования (описывающие, как должна работать система или программный продукт, и какими свойствами или характеристиками она должна обладать).
Нефункциональные требования часто связаны с атрибутами качества (т.е.
требованиями, определяющими качественные характеристики разрабатываемого
программного обеспечения (ПО) или системы, такие как производительность,
надежность, масштабируемость):
Ограничения – условия, ограничивающие выбор возможных решений по реализации отдельных требований или их наборов.
Бизнес-правила — политика, руководящие принципы или положения, которые определяют или ограничивают некоторые аспекты бизнеса, в т.ч. правила,
определяющие состав и правила выполнения определенных бизнес-процессов. К
бизнес-правилам относятся корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы, которые используются при разработке продукта или системы либо непосредственно влияют
на разработку.
Примеры бизнес-правил: «При отгрузке заказа менеджер должен запросить у
бухгалтера товарно-транспортную накладную и счет-фактуру», «Если оплата по
счету не поступила в течение 15 дней, заказ считается отменённым».
Внешние интерфейсы — описание аспектов взаимодействия с другими системами и операционной средой. К ним относятся требования к API продукта или
системы, а также требования к API других систем, с которыми осуществляется интеграция.
18
Примеры внешних интерфейсов: «Обеспечить запись в журнал операционной
системы следующих событий: сообщения о запуске и остановке сервиса XX»;
«Обеспечить запись в журнал параметров модулей программы: сканера, ядра, антивирусных баз (информация должна заноситься в журнал при запуске программы
и при обновлении модулей)».
Предложения по реализации — предложения, оценивающие возможность
использования определенных технологических и архитектурных решений.
Предложения по тестированию разрабатываемого ПО — дополнения к
требованиям, указывающие, каким образом то или иное требование должно быть
протестировано.
Юридические требования — требования к лицензированию, патентной чистоте.
Одним из способов определения нефункциональных требований является составление шаблона.1
Для групп по определению нефункциональных требований особенно важно
привлечь к этой работе не только аналитиков и пользователей, но и архитекторов
и ключевых разработчиков продукта или системы, а также группу тестирования. Архитектор воспринимает нефункциональные требования как входные данные для выбора и проектирования архитектуры приложения, а группа тестирования
планирует те сценарии нагрузочного тестирования, которые будут использоваться
для проверки выполнения нефункциональных требований (в основном это касается
атрибутов качества).
6.1.2 Критерии качественных нефункциональных требований
Как к функциональным, так и к нефункциональным требованиям применяются критерии качества требований — т.е. описание тех качеств, которым должны
удовлетворять качественные требования.
Ниже приведены основные характеристики качественных требований.
Полнота (отдельного требования и системы требований) — требование
должно содержать всю необходимую информацию для его реализации. В него
включается вся информация об описываемом параметре, известная на момент описания. Система требований также не должна содержать невыявленных и не определенных требований.
Однозначность — требование должно быть внутренне непротиворечиво и все
работающие с ним должны понимать его одинаково. Требования следует выражать
просто, кратко и точно, используя известные термины. Обычно базовые знания читателей спецификации требований к ПО различаются. Поэтому в ее состав нужно
включить раздел с определением понятий прикладной области, используемых при
определении требований. Пример, неоднозначного требования. «Период обновления экрана должен быть не менее 20 сек.»
1
Книга Карла Вигерса "Разработка требований к программному обеспечению" — в разделе
«Приложение Г» этой книги находятся примеры документации требований; Материалы ГОСТ 34 серии
19
Корректность отдельного требования и согласованность (непротиворечивость) системы требований — требование не должно содержать в себе неверной,
неточной информации, а отдельные требования в системе требований не должны
противоречить друг другу.
Необходимость — требование должно отражать возможность или характеристику ПО, действительно необходимую пользователям, или вытекающую из других требований.
Осуществимость — включаемое в спецификацию требование должно быть
выполнимым при заданных ограничениях операционной среды.
Проверяемость — проверяемость требования означает, что существует конечный и разумный по стоимости процесс ручной или машинной проверки того,
что ПО удовлетворяет этому требованию.
Существуют следующие наиболее распространенные модели качества:
ISO 9126
ГОСТ 34
Модель качества по МакКоллу (McCall’s Quality Model)
Модель качества по Боэму (Boehm’s Quality Model)
1061-1998 IEEE Standard for Software Quality Metrics Methodology
ISO 8402:1994 Quality management and quality assurance
Все атрибуты качества с точки зрения архитектуры ИС можно разделить на
две большие группы: первая группа (runtime) – это атрибуты, относящиеся ко времени работы приложения или системы; вторая группа (design time) определяет
ключевые аспекты проектирования приложения или системы. Многие из этих атрибутов взаимозависимы.
Группа runtime. К этой группе относятся следующие атрибуты качества:
Доступность — атрибут качества, определяющий время непрерывной работы приложения или системы. Чтобы определить этот параметр, обычно указывают максимально допустимое время простоя системы.
Надежность — требование, описывающее поведение приложения или системы в нештатных ситуациях (примеры: автоматический перезапуск, восстановление
работы, сохранение данных, дублирование важных данных, резервирование логики)
Требования к времени хранения данных (например, использование БД в качестве постоянного хранилища данных, продолжительность хранения данных)
Масштабируемость — требования к горизонтальному и/или вертикальному
масштабированию приложения или системы. Говоря о вертикальной масштабируемости, мы определяем требования к вертикальной архитектуре системы или приложения. К требованиям вертикальной масштабируемости могут относиться,
например, возможность переноса приложений на более мощные SMP-системы,
поддержка большого объема памяти и файлов. Говоря о горизонтальной масштабируемости, мы определяем требования к горизонтальной архитектуре системы
или приложения. К требованиям горизонтальной масштабируемости могут относиться, например, возможность использования технологий кластеризации. Следует
особо заметить, что вертикальное масштабирование обычно направлено на повы-
20
шение производительности системы. Горизонтальное масштабирование, помимо
производительности, позволяет повысить отказоустойчивость системы.
Требования к удобству использования системы/приложения (с точки зрения
пользователя) и требования к удобству и простоте поддержки (Usability).
Требования к безопасности, как правило, включают в себя три большие категории: требования, связанные с разграничением доступа, требования, связанные с
работой с приватными данным, и требования, направленные на снижение рисков от
внешних атак.
Требования к конфигурируемости приложения, взаимодействия и расположения компонентов можно условно разделить на четыре уровня:
1. конфигурируемость на основе предопределенного набора параметров
(predefined configurability), когда необходимый уровень модификации достигается
путем изменения значений параметров из предопределенного набора;
2. конфигурируемость на основе предопределенного набора базовых объектов
(framework constrained configurability), когда необходимый уровень модификации
достигается путем перекомпоновки предопределенного набора процессов, сущностей и служебных процедур;
3. конфигурируемость путем реализации новых базовых объектов (basis
reimplementation), когда обеспечивается расширение набора процессов и сущностей;
4. конфигурируемость путем новой реализации системы (system
reimplementation), когда система должна устанавливаться и настраиваться с нуля.
Требования к производительности решения, определяемые в терминах количества одновременно работающих пользователей, обслуживаемых транзакций,
времени реакции, продолжительности вычислений, а также скорости и пропускной
способности каналов связи
Ограничения, накладываемые на объем доступной памяти, процессорного
времени, дискового пространства, пропускную способность сети, при которых
приложение должно эффективно выполнять возложенные на него задачи.
Группа design time. К этой группе относятся следующие выборочные атрибуты
качества:
Требования к повторному использованию реализации или компонентов
приложения или системы (Reusability).
Требования к расширяемости (Extensibility) приложения или системы в связи с появлением новых функциональных требований, тесно связанное с таким архитектурным атрибутом качества, как переносимость кода.
Требования к переносимости (Portability) приложения или системы на другие платформы.
Требования к взаимодействию между компонентами решения, между
внешними компонентами, использование стандартных протоколов и технологий взаимодействия (Interoperability). Например, к таким требованиям можно отнести возможность использования нескольких стандартных протоколов для обмена
данными между одной из подсистем разрабатываемой системы и внешней системой-поставщиком данных (на примере ArcGIS).
21
6.1.3 ХОД РАБОТЫ
1. Построить классификацию требований для предметной области,
определенной в НИР. Использовать различные модели качества, описанные,
например: http://vspu2014.ipu.ru/proceedings/prcdngs/4585.pdf
2. Сравнить применимость моделей качества к выбранной предметной
области (задаче) НИР.
3. Оформить результаты в виде таблицы, сделать выводы.
6.1.4 КОНТРОЛЬНЫЕ ВОПРОСЫ
1. Понятие инженерии требований.
2. Стандарты инженерии требований.
3. Определить назначение функциональных и нефункциональных требований.
4. Назовите источники сведений для задания требований.
5. Как обеспечить полноту и непротиворечивость требований к системе?
6. Каким образом документируются требования?
7. Понятие корпоративной системы.
8. Примры корпоративных систем.
9. Основные модели инженерии требований к проекту корпоративной системы.
10.Сравнения и применимость моделей инженерии требований к корпоративной
системе.
6.1.5 БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Боэм Б.В. Характеристики качества программного обеспечения [Текст]: /
Б.Вю Боэм. – М.: Мир, 1981.
2. Вигерс К.И Разработка требований к ПО М.: Русская редакция Microsoft,
2004. – 575 c.
3. Липаев В.В Методы обеспечения качества крупнмасштабных программных
систем М.: СИНТЕГ. – 2003. – 510 с
Методологии и стандарты, регламентирующие работу с требованиями
1. IEEE 1362 "Concept of Operations Document".
2. IEEE 1233 "Guide for Developing System Requirements Specifications".
3. IEEE Standard 830-1998, "IEEE Recommended Practice for Software Requirements Specifications"
4. IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.121990
5. IEEE Guide to the Software Engineering Body of Knowledge (1) - SWEBOK®,
2004.
6. ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания.
7. ГОСТ 34.602-89. Информационная технология. Техническое задание на создание автоматизированной системы
22
8. ГОСТ 19.201-78. Единая система программной документации. Техническое
задание. Требования к содержанию и оформлению.
6.2 ПРАКТИЧЕСКАЯ РАБОТА № 2
АНАЛИЗ ПОДХОДОВ К ФОРМАЛИЗАЦИИ ОПИСАНИЯ СЛОЖНЫХ
КОРПОРАТИВНЫХ СИСТЕМ
6.2.1. Цели работы:

получить практические навыки формализации в задачах системной
инженерии;

получить практические навыки в проведении анализа и формализации
функции цели ИС (корпоративной ИС).
6.2.2. Теоретические сведения
Задача планирования и эффективного управления предприятиями – одна из
основных областей применения информационных технологий, являющимися базой
автоматизированных систем управления (АСУ). АСУ может быть представлено в
виде совокупности автоматизированных систем взаимодействующих уровней,
условно называемых «управление предприятием» (уровень ERP, MRP),
управлением производством» (уровень MES) и «управление технологическими
процессами и оборудованием» (уровень DCS).
Уровень ERP реализуется автоматизированными системами управления
предприятием (АСУП), уровень DCS – автоматизированными системами
управления технологическими процессами (АСУ ТП), а важнейшей функцией
уровня MES является сопряжение между АСУП и АСУ ТП [7].
Важную роль при анализе и реализации требований к системе играет их
специфицирование, для создания систем программного уровня  Software
Requirements Specification (SRS). Следует отметить, что часто под термином
"система" подразумевается программная система или приложение в разработке. Это
может быть крупная коллекция множества компонентов программного и
аппаратного обеспечения, одно приложение или компонент программного
обеспечения внутри более крупной системы. Во всех этих случаях модель
требований описывает поведение, видимое вне системы (через пользовательский
интерфейс или API) [1, 2, 3].
Модель описания требований уровня UML во многих случаях не отражает
особенности построения узкоспециализированных классов систем в широкой
трактовке. Исходя из методики, предложенной А.В. Дабагяном [4, 5], требования
характеризуются физическими параметрами, а требования, отличающиеся хотя бы
одним признаком или одним значением его параметра, должны быть отнесены к
различным классам.
Поле заявок представлено в многомерном евклидовом пространстве.
23
Размерность евклидова пространства равна m, что соответствует отдельным
признакам заявки. В поле вектора З некоторую заявку можно представить в виде
вектора Çi с координатами Çij , j  {1,.., m1} . Полем требований в m1 -мерном
пространстве вектора З называется замкнутая m1 – 1-мерная область, границы
которой ортогональны осям евклидова пространства, где заданы векторы заявок З.
В той же работе введены определения минимальной и максимальной j-ых границ
поля требований.
Ti   [ 1j ,..., ij ,..., i( m1 1) ]T , З   [ з1 ,... з j ,..., зm1 ]T ,
(1)
где i –номер требования; j – номер параметра требования; (m1  1) – размерность
вектора требований; Т – знак транспонирования; З  – заявка класса  ; m1 – число
параметров.
З    Ti  ,
i

где i – номер требования класса  в заявке З .
Ограничениями данных определений является то, что обслуживание
требований одного класса предполагается по одинаковой технологии, а
обслуживание требований, входящих в заявки различных классов – по различным
технологиям. Однако, реализация on-line требований, связанная, в том числе с
новыми заявками, не всегда может быть отнесена к существующим технологиям.
Следовательно, целесообразной является предварительная оценка времени
реализации требования, а также классификация требований и соотнесение их с
возможными реализациями.
Фаза анализа и планирования требований в рамках технологии RAD - быстрой
разработки приложений [6] связана со следующими работами: 1) определяются
функции, которые должна выполнять разрабатываемая информационная система; 2)
определяются наиболее приоритетные функции, требующие разработки в первую
очередь; 3) проводится описание информационных потребностей; 4)
ограничивается масштаб проекта; определяются временные рамки для каждой из
последующих фаз; в заключение, 5) определяется сама возможность реализации
данного проекта в установленных рамках финансирования, на имеющихся
аппаратных и программных средствах.
При использовании методологии быстрой разработки приложений жизненный
цикл информационной системы состоит из четырех фаз: • фаза анализа и
планирования требований; • фаза проектирования; • фаза построения; • фаза
внедрения.
Если реализация проекта принципиально возможна, то результатом фазы
анализа и планирования требований будет список функций разрабатываемой
информационной системы с указанием их приоритетов и предварительные
функциональные и информационные модели системы.
Таким образом, анализ и формализация требований играет важную роль при
анализе функционирования системы в целом.
24
Пример выполнения работы
Пусть требуется построить ИС по следующему описанию: конструкторское
бюро по проектированию сложных технических объектов. Предполагается
использование большого количества программных средств дизайнерского
назначения и средств САПР2. Предполагаются активная передача информации по
локальной сети между конструкторами, имеется необходимость защиты особых
данных. Особо важна скорость реализации процесса обработки изображений.
Задание: 1. Формализовать требования к системе на основе технологии RAD,
2. Формализовать описание системы в целом.
Часть 1. Исходя из технологии RAD, проводится анализ требований:
1) определяются функции, которые должна выполнять разрабатываемая
информационная система;
Из описания системы, определяется множество функций ИС. Глобальная функция:
Ф – получение комплексного проекта в виде совокупности изображений.
Поддерживающие и обеспечивающие функции: Ф1 – обеспечение взаимодействия
многих программ дизайнерского назначения и средств САПР; Ф2 – поддержка
интенсивного обмена информацией по локальной сети между конструкторами; Ф3
– функция защиты особых данных;
Ф4 – поддержка высокой скорости реализации процесса обработки изображений.
Ф : Ф1, Ф 2, Ф3, Ф 4
(2)
2) определяются наиболее приоритетные функции, требующие разработки в
первую очередь;
Ф1 – обеспечение взаимодействия многих программ дизайнерского назначения и
средств САПР можно считать базовой функций разрабатываемой ИС, поскольку
исходя из способа реализации Ф1 будут обеспечиваться остальные функции.
3) проводится описание информационных потребностей;
Информационными
потребностями
пользователя
являются
конкретные
(фактические) значения требуемых параметров системы, которые задаются
заказчиком проекта. Например, объемы текущих данных, требуемая скорость
обмена данными, или время, необходимое на передачу данных.
Эти данные выбираются либо по согласованию с преподавателем, либо
выбираются самостоятельно, исходя из среднестатистических данных, например,
размера некоторого изображения САПР в байтах (формат чертежа А1), скорость
обмена порядка 2Мбайт/сек и т.п.
4) ограничивается масштаб проекта;
Ограничения могут быть связаны с уточнениями описания модели. Для
Подготовленная в САПР полная схема является не просто набором чертежей, но и содержит информацию о
соединениях всех элементов. С перечнем аппаратуры связаны данные о размещении, габаритах и схемах аппаратов.
На их основе формируется база данных проекта, позволяющая использовать ее для создания других документов.
Использование именно базы данных проекта, а не отдельных чертежей, позволяет значительно повысить
2
эффективность выпуска рабочей документации проектными организациями.
25
приведенного примера это могут быть ответы на вопросы: какой тип САПР
используется? (От этого зависит размер картинки, стоимость разработки). Кроме
того, ограничениями может быть уточнение требуемой скорость обмена данными и
т.п.
5) определяется возможность реализации данного проекта в установленных
рамках ограничений.
Этот этап служит для анализа требований на совместимость и
непротиворечивость.
В примере: при ограничении ресурсов по финансированию проекта применение
САПР верхнего уровня может привести к полной невозможности его реализации.
Или ограничение на скорость обмена данными вследствие применения
определенного типа аппаратуры может сказаться на реализации соответствующего
требования.
Таким образом, анализируются функции и определяются количественные
требования.
Формализация требований осуществляется посредством их символьного
представления согласно (1) и (2). Функции системы:
Ф : Ф1, Ф 2, Ф3, Ф 4 ,
где Ф – получение комплексного проекта в виде совокупности изображений.
Ф1 – обеспечение взаимодействия многих программ дизайнерского назначения и
средств САПР; Ф2 – поддержка интенсивного обмена информацией по локальной
сети между конструкторами; Ф3 – функция защиты особых данных;
Ф4 – поддержка высокой скорости реализации процесса обработки изображений.
Требования к системе. Определим поле требований как вектор требований,
их шкал и ограничений:
T1Ф1  [ 11Ф1 , 12Ф1 ],
Ô1
где T1Ô1 – требования класса Ф1: 11
– наличие гетерогенной информационной
Ô1
среды; 12
– наличие интерфейса взаимодействия различных элементов
гетерогенной информационной среды.
Ô1
Ô1
При этом, если T1Ô1  0,1, то 11
, 12
могут быть трактованы как степени
принадлежности к нечеткому множеству соответствия, а если T1Ô1  0, N , где N –
Ô1
Ô1
общее кол-во возможных значений T1Ô1 , то 11
, 12
имеют смысл цифровых
Ô1
Ô1
количественных оценок; при T1Ô1  0,1, то 11
, 12
– бинарные определители
наличия или отсутствия признака требования: есть гетерогенная среда или нет.
Ô2 Ô2
T1Ô 2  [11
, 12 ],
Ô2
где T1Ô 2 – требования класса Ф2: 11
– обеспечение заданной скорости обмена
данными;
Ô2
– обеспечение заданной надежности обмена данными. При
12
Ô2
Ф2
 1.
ограничениях:  11
 2Mб / сек., 0.8  12
Аналогичным образом строятся множества T1Ô 3 ...TKÔ 3  [...], T1Ô 4 ...TLÔ 4  [...], где K,
L – количество типов требований каждого класса Фi.
26
Часть 2. Формализация описания системы в целом.
Следует
разграничивать
формализованное
описание
процесса
проектирования системы, процесса функционирования системы и общее
описание системы. Очевидно, что формализация в первом и втором случаях будет
связана с динамическими процессами, а описание системы в целом, в основном, –
статическая или информационная ее интерпретация.
В Таблице 6.1 приведены основные способы представления формального
описания сложных систем. Поскольку глобальная функция системы представляет
собой формирование нового информационного объекта (Ф – получение
комплексного проекта в виде совокупности изображений), можно использовать при
описании сочетание п.4 и п.2.
Таблица 6.1. Основные способы описания сложных систем
Определение
Система есть множество
элементов, свойств и отношений
Система есть множество
элементов, образующих структуру
и обеспечивающих определенное
поведение в условиях
окружающей среды
Система есть множество входов,
множество выходов, множество
состояний, характеризуемых
оператором переходов и
оператором выходов
Понятия модели F, связи SС,
пересчета R, самообучения FL,
самоорганизации FQ,
проводимости связей СО и
возбуждения моделей JN
Введен фактор времени и
функциональных связей
Организационные системы
Формальное описание
S=({т},{n},{r}),
где т - элементы, n - свойства,
r - отношения
S=(, SТ, ВЕ, Е),
где  - элементы, SТ - структура, ВЕ поведение, Е - среда
Описание
Знаково-графовый
подход
S=(Х, Y, Z, H, G),
где Х - входы, Y - выходы, Z - состояния,
Н - оператор переходов, G - оператор
выходов
Учитываются все
основные
компоненты,
рассматриваемые
в автоматике.
Определение
применяется для
описания
нейрокибернетиче
ских систем.
Определение
системы, которым
оперируют в
теории
автоматического
управления
S=(F, SС, R, FL, FO, СО, JN)
S=(Т, X, Y, Z, ., V, , ),
где Т - время, Х - входы, Y - выходы, Z состояния, . - класс операторов на
выходе, V - значения операторов на
выходе,  - функциональная связь в
уравнении y(t2)= (x(t1),z(t1),t2),  функциональная связь в уравнении
z(t2)=(x(t1), z(t1), t2).
S9=(РL, RO, RJ, EX, PR, DT, SV, RD,
EF), где РL - цели и планы, RO внешние ресурсы, RJ - внутренние
ресурсы, ЕХ - исполнители, PR процесс, DТ - помехи, SV - контроль,
RD - управление, ЕF - эффект.
Структрноповеденческий
подход
Организационное
управление
27
Таким образом, возможно применить следующее обобщенное описание
S= (Х, Y, Z, H, G, {т},{n},{r})),
где Х - входы, Y - выходы, Z - состояния, Н - оператор переходов, G - оператор
выходов, m - элементы, n - свойства, r – отношения между элементами.
Пример. Пусть дана гидрометеорологическая система (ГМИС) с
возможностью сбора, анализа и хранения данных. Опишем функционирование этой
ГМИС с требованиями.
Проектируемая система производит преобразование
Yt  F ( X t , Tt ) ,
где X t – текущее состояние входного объекта системы в момент времени t; Yt –
текущее состояние выходного объекта системы в момент времени t; Tt – текущее
требование к системе; F  функция преобразования входного объекта системы.
Система также может быть описана как совокупность элементов и
ограничений

S

где
N
{X
n 1
N
(n)
i

Y
| ( i   X i )}, {Y j( k ) | (θ j  θ j )}, {Tt | TiФj  [ iФj1 ,... iIФJ ]}, Ф  ,

{ X i( n) }
– объединение подмножеств входных объектов (данных) системы
n 1
(если входные данные возможно классифицировать по подмножествам), n  1, N ;
i – требуемое качество входных данных;
 X i – допустимое качество входных данных (нижняя граница);
θ j – качество выходных данных;
Y
θ j – допустимое качество выходных данных (нижняя граница);
Tt – текущее требование к системе;
I, J – общее кол-во i-требований класса j;
Ф : Ф1, Ф2, Ф3, Ф4 – множество функций системы;
Z – множество состояний системы, при которых достигается требуемый уровень
защиты данных: обеспечение Ф3 – функции защиты особых данных ( z i – i-е
состояние системы;
z * – необходимое состояние системы после реализации i-го требования к системе в
текущем состоянии;
Z w – множество верхних граней ( sup(W ) ) некоторого множества W, равных или
больших всех элементов W (это утверждение может быть записано в следующей
форме: z*  sup(W ) | zi  Z w , s  Z w : z*  s ).
Описание функции цели может быть определено по следующей схеме.
Пусть F (T jФi ) – функционал (реализация требований к системе), определенный на
множестве T jФi ( X ) (требования в рамках входных данных). Рассматривается
следующая задача нахождения варианта системы X:
28
F ( x)},
x  arg max F ( x); arg max F ( x)  {x  D | F ( x)  max
`
xD
xD
x D
(3)
где F (x) – искомый функционал.
Вариант xD, при котором достигается максимум функционала F (x) на
некотором множестве X ( s0 )  X , называют максимальным. Полученные
максимальные варианты исследуются с помощью критериев оптимальности.
Таким образом ставится задача нахождения такого варианта системы из области
допустимых (D), который обеспечит реализацию текущего требования с
достижением верхней границы его качества.
Примечание: Приведенные элементы примера формализации требований и
функции цели не обладают высокой степенью общности, а представляют собой
конкретную реализацию определенной задачи.
6.2.3. ХОД РАБОТЫ
1. Определить вариант задания из списка (либо согласовать с ведущим
преподавателем или руководителем НИР).
2. Изучить литературу и теоретические сведения к выполнению лабораторной
работы.
3. Привести формальное описание системы в целом.
5. Предложить функцию цели для проектирования системы, сделать выводы.
6. Сформировать и защитить отчет, содержаний все этапы исследования.
6.2.4. КОНТРОЛЬНЫЕ ВОПРОСЫ
1. Описать основные задачи технологии RAD.
2. Каким образом учитываются требования к системе в ее формализованном
описании?
3. Какие существуют подходы к формальному описанию систем?
4. Привести примеры отличающихся подходов формального описания сложных
систем.
5. Что такое Н - оператор переходов, G - оператор выходов?
6. Привести пример описания реальной системы, когда должны быть учтены
обратные связи в операторах преобразования объектов.
7. Прочесть и объяснить выражение: x  arg max F ( x) .
xD
8. Каким образом можно описать требование обеспечения верхней (нижней) грани
множества результатов? Привести пример записи.
9. Для чего требуется формализовать (описать) полный перечень функций системы?
10. Применительно к теме своей НИР охарактеризовать функцию цели.
29
6.2.5. ВАРИАНТЫ ЗАДАНИЙ
Вариант задания может быть выбран из предложенного списка по последней
цифре номера зачетной книжки либо выбирается студентом индивидуально, в
соответствии с тематикой выпускной (квалификационной) магистерской работы по
согласованию с её руководителем.Варианты заданий из данного радела могуьт быть
использованы привыполнении КП при условии, что тема НИР магистром не
определена или не уточнена.
Вариант 0. Конструкторское бюро по проектированию сложных технических
объектов. Использование унифицированной САПР. Данные сохраняются в БД.
Важность формирования целостного изображения.
Вариант 1. Станция экологического контроля параметров на химическом
предприятии. ИС должна функционировать в оперативном режиме работы,
решения об уровне загрязнения принимает система, подтверждает оператор.
Необходимость защиты данных для хранения и при передаче на другие объекты.
Вариант 2. Предприятие по выпуску пищевой продукции обеспечено
автоматизированной системой управления. Основные этапы технологического
процесса: передача объектов по конвейеру, при котором необходим контроль
качества выполненных операций. ИС собирает информацию со специальных
датчиков и обрабатывает ее, сравнивая показатели объектов на конвейере с
контрольными, при несовпадении отбраковывает, снимая с конвейера. Данные
сохраняются в БД.
Вариант 3. Предприятие интернет торговли. Информационная система управляет
пользователями, обеспечивает доступ, регистрацию и возможность скидок.
Наличие конкурентов должно быть сопоставлено с возможностью защиты данных
в режиме реального времени и их сохранности.
Вариант 4. Юридическая контора обслуживается ИС с двумя БД различного
назначения (клиенты, их дела и нормативно-правовая информация). При этом БД
связаны. БД клиент-дело особо секретна, БД справочная открыта и имеет доступ по
всей юридической компании. Юристы, ведущие дела, могут оперативно добавлять
информацию по делам по мобильной связи.
Вариант 5. Предприятие лечебно-диагностического характера. ИС клиентов, где
ранятся процедуры, описание диагнозов и процесса лечения. Поступление данных
в БД из различных источников: датчики и устройства (напрямую с ультразвукового
аппарата, от мангитно - резонансной диагностики, носимых устройств: например,
пульс, частота дыхания, аритмия). Необходимость быстрого реагирования на
особые ситуации в текущем режиме (информация с носимых устройств) и при
диагностике.
30
Вариант 6. Администрация учебного заведения. ИС «школьный дневник» с
возможностью обмена сообщениями с классным руководителем родителями
учащегося при нестандартных ситуациях в оперативном режиме. Поступление
данных с различных источников: проходная школы, журнал оценок, столовая,
медицинский кабинет. Возможность сохранения и анализа данных за неделю,
месяц, год.
Вариант 7. Предприятие контроля параметров технических устройств. Датчики и
средства контроля передают комплекс информации о контролируемом устройстве в
БД, откуда происходит их извлечение и анализ. Далее, на основании анализа
формируется отчет о состоянии устройства. Возможность реализации контроля в
скоростном режиме.
Вариант 8. Бюро технической инвентаризации (БТИ). Данные о состоянии жилого
фонда вносятся как вручную, так и с помощью устройств фотосъемки, аудиозаписи
(например, при определении шума при изоляции квартиры). Возможность передачи
данных по локальной сети между подразделениями БТИ. Совместимость с другими
БД.
Вариант 9. Станция гидрологического контроля параметров в морском порту. ИС
должна функционировать в оперативном режиме работы, требуется наличие
совместимых форматов с другими БД подобного профиля. Контроль параметров
осуществляется как автоматически, так и вручную. Возможность предупреждения
об опасных явлениях (резкое повышение уровня моря, увеличение скорости
течения).
6.2.6. БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Правила составления Software requirements specification [Электронный ресурс]
/Режим доступа: http://habrahabr.ru/blogs/development/52681/.  Загл.с экрана.
2. Рамбо Дж. UML 2.0. Объектно-ориентированное моделирование и разработка /
Дж. Рамбо. – McMillan, 2007.
3.Резник А. Развивающиеся системы [Электронный ресурс] / А. Резник//
International Conference «Knowledge-Dialogue-Solutions», 2007.  Режим доступа:
http://www.foibg.com/conf/ITA2007/KDS2007/PDF/KDS07-Reznik1.pdf.  Загл. с
экрана.
4.Дабагян А.В. Принципы автоматизированного проектирования систем машин и
техноологических процессов: Учеб.пособие.  Харьков:ХПИ, 1987.  66 с.
5.Дагабян А.В. Проектирование технических систем. – М.: Машиностроение,
1986. – 256 с.
6.Петров В.Н. Информационные системы / В.Н. Петров. – СПб.: Питер, 2003. – 688
с.
7. Яковлев В.П. Корпоративные информационные системы: конспект лекций / В.П.
Яковлев; СПбГТУРП. – СПб., 2015. − 117 с.
31
7. ПРИМЕР ОПИСАНИЯ РАЗРАБОТКИ СИСТЕМЫ ПОДДЕРЖКИ
ПРИНЯТИЯ РЕШЕНИЯ
7.1 Общие сведения о системе, классификация требований
Система поддержки принятия решения для управления процессом
функционирования как всей ИС, так и отдельных ее подсистем в рамках анализа ее
жизненного цикла разрабатывается с целью повышения эффективности ИС .
На первом этапе определяются требования к системе. Ниже приведена классификация требований.
Нефункциональные требования:
 возможность многократного использования данных;
 простота пользования системой;
 наглядность;
 возможность гибкой настройки системы.
Функциональные требования:
 построение моделей устаревания ИС, основанных на различных законах
распределения случайных величин;
 расчет времени начала максимально отсроченного реинжиниринга;
 расчет экономически оптимального срока эксплуатации ИС до реинжиниринга;
 система должна выполнять вычисление коэффициента отражающего темп
морального старения системы;
 расчет показателя полноты использования материально-экономических
ресурсов.
Производные требования:
 возможность изменения структуры системы(добавление/удаление блоков).
Обладая всеми этими возможностями, система позволит упростить исследование процесса совершенствования ИС и в частности дать рекомендацию о целесообразности модернизации ИС в заданный момент времени.
В целом система может представлять интерес для разработчиков не только
информационных систем, но и проектировщиков узконаправленных ИС.
7.2 Анализ требований к разрабатываемой системе
Основываясь на технологии быстрой разработки приложений (RAD), проведем анализ требований к системе:
1. Из описания системы, определено множество функций ИС.
Глобальная функция: Ф  получение комплексного проекта в виде системы
поддержки принятия решения для управления процессом функционирования как
всей ИС, так и отдельных ее подсистем в рамках анализа ее жизненного цикла.
Поддерживающие и обеспечивающие функции:
32
 Ф1  построение адекватной модели устаревания ИС;
 Ф2  расчет коэффициента, отражающего темп морального старения
системы;
 Ф3  расчет показателя полноты использования ресурсов (ПИР).
Ф : Ф1 , Ф2 , Ф3 
(7.1)
2. Определена наиболее приоритетная функция, требующие разработки в
первую очередь.
Ф1  можно считать базовой функцией, разрабатываемой ИС, поскольку исходя из
Ф1 будут обеспечиваться остальные функции.
3. Определена возможность реализации данного проекта в установленных
рамках ограничений.
Определено поле требований как вектор требований, их шкал и ограничений:
где T1Ф1
(7.2)
T1Ф1  [ 11Ф1 ],
 требования класса Ф1 ;  11Ф1  наличие адекватной модели устаревания ИС.
При этом, если T1Ф1  0,1, то  11Ф1 может быть трактовано как степени
принадлежности к нечеткому множеству соответствия, а если T1Ф1  0, N , где N 
общее количество возможных значений T1Ф1 , то  11Ф1 имеет смысл цифровых
количественных оценок; при T1Ф1  0,1, то  11Ф1  бинарный определитель наличия
или отсутствия признака требования: выбрана адекватная модель устаревания или
нет.
(7.3)
T1Ф 2  [ 11Ф 2 , 12Ф 2 ],
где T1Ф 2  требования класса Ф2 ;  11Ф 2  наличие адекватной модели устаревания ИС;
 12Ф 2  расчет экономически оптимального срока эксплуатации ИС до начала
реинжиниринга.
(7.4)
T1Ф3  [ 11Ф3 ],
где T1Ф3 – требования класса Ф3 ; 11Ф 3  наличие адекватной модели устаревания ИС.
Далее проведена формализация описания системы в целом.
Глобальная функция системы представляет собой формирование нового
информационного объекта.
Таким образом, используем следующее обобщенное описание системы:
S  ( X , Y , Z , H , G,{t},{n},{r}),
(7.5)
где X  входы; Y  выходы; Z  состояния; H  оператор переходов, G 
оператор выходов; t  элементы; n  свойства; r  отношения между элементами.
Далее описано функционирование информационной системы с заданными
требованиями. Проектируемая система производит преобразование:
(7.6)
Yt  F ( X t , Tt )
где Yt  текущее состояние выходного объекта системы в момент времени t ;
33
F  функция преобразования входного объекта системы;
X t  текущее состояние входного объекта системы в момент времени t ;
Tt  текущее требование к системе.
Можно определить закон функционирования рассматриваемой системы, который имеет имеет вид:
N
N
(7.7)
Y
X
(n)
(k )
al A ,l 1, n
{ X
n 1
| ( i   )}  
 {Y j | (θ j  θ )}, n  1, N ,
j
i
i
n 1
N
где
{ X
n 1
i
(n)
i
}  объединение множеств входных объектов системы, n  1, N ;
 качество входных данных;  X  допустимое качество входных данных;
i
al  внутренние состояния исходной системы; θ j  качество выходных
данных;
 допустимое качество выходных данных.
Поступающие на вход системы исходные данные должны соответствовать
требуемым критериям. В системе происходит их преобразование и в результате на
выход поступают качественные ожидаемые данные.
θ
Yj
7.3 Системотехнический анализ задачи
При проектировании разрабатываемой сложной системы воспользуемся
принципами системного анализа.
Данная система представлена в виде «черного ящика» (рисунок 7.1), согласно
принципу конечной цели. То есть конечная цель имеет абсолютный приоритет, и
вся логика функционирования системы должна быть направлена на ее достижение.
Вектор X  входные данные. Он включает в себя:
 значение исходного показателя эффективности системы на момент окончания ее разработки ( E 0 );
 минимальный допустимый уровень показателя эффективности системы
( E min );
 t m  время начала морального старения системы;
  – регулярный прирост эксплуатационных расходов;
 M 0  приведенные к началу эксплуатации расходы на разработку, производство, установку системы;
 m  стоимость эксплуатации системы.
34
Рисунок 7.1  Структура разрабатываемой системы
Ниже рассматривается процесс, протекающий в проектируемой системе.
Данный процесс можно разбить на несколько этапов. В промежутки времени
между смежными этапами состояние системы не меняется.
Основными этапами существования системы являются:
 выбор модели и ввод исходных данных в систему и ее запуск;
 очередь;
 обработка заявки;
 выходной поток.
Типичный сценарий работы системы:
1. На вход системы пользователь вводит все необходимые параметры.
2. Выбор требуемого закона устаревания.
3. Запуск системы.
4. Расчет экономически оптимального срока эксплуатации ИС до реинжиниринга.
5. Расчет коэффициента, отражающего темп морального старения системы.
6. Расчет значения времени начала максимально отсроченного реинжиниринга в зависимости от вида закона распределения функции устаревания системы.
7. Графическое представление результатов (модели изменения во времени
эффективности информационной системы вследствие ее устаревания).
8. Расчет гибкости совершенствования ИС.
9. Расчет ПИР.
10. Определение целесообразности реконструкции ИС.
7.4 Декомпозиция задачи создания СППР
Следующим этапом проведена декомпозиция системы для структуризации
целей, выявления проблем и противоречий. Построена функциональная модель,
отражающая структуру и функции системы.
Стандарт IDEF0 наиболее часто применяется в практике в качестве технологии для исследования и проектирования систем на логическом уровне. Данный
35
стандарт целесообразно использовать в проектах по описанию и оптимизации процессов.
Построение модели IDEF0 начинается с представления всей системы в виде
контекстной диаграммы.
Для построения модели использовался продукт Diaw 0.97.2.
Контекстная диаграмма верхнего уровня проектируемой системы изображена
на рисунке 7.2. На вход системы поступают входные данные, которые используются внутри СППР. В соответствии с выбранной моделью устаревания производится
дальнейшие преобразования для получения результата.
Рисунок 7.2  Контекстная диаграмма верхнего уровня проектируемой системы
В таблице 7.2 дано описание процессов для контекстная диаграмма верхнего
уровня проектируемой системы.
Таблица 7.2  Описание процессов для контекстной IDEF0-диаграммы
Название Входные Управляющие
Результат проШифр
Механизм
процесса
данные
данные
цесса (работы)
A0
Построить
СППР
E (t )
Модель устаревания ИС
AnyLogic
Решение о реконструкции
системы
С помощью диаграммы декомпозиции первого уровня показана детализация
процессов, протекающих при преобразовании главной функции системы (Рис.7.3.).
7.4 Выбор среды имитационного моделирования для реализации СППР
Оценка эффективности информационных систем является сложной комплексной задачей, для успешного решения которой необходимо учитывать большое количество требований.
Часто, при разработке какой-либо системы возникают проблемные ситуации,
для разрешения которых существует множество альтернатив. Выбор той или иной
альтернативы напрямую зависит от лица, принимающего решения (ЛПР). Выбор
36
решения возможен, если имеется способ сравнения альтернатив между собой и
определения их предпочтительности, т.е. имеется критерий предпочтения. Предпочтение – это интегральная оценка альтернатив качества решений, основанная на
объективном анализе и субъективном понимании экспертов и ЛПР ценности соответствующих альтернатив.
В настоящее время существует множество сред для проведения имитационного моделирования. Каждая такая система имеет ряд преимуществ и недостатков.
Самыми известными из них являются:
 система имитационного моделирования общего назначения GPSS;
 инструментальная система имитационного моделирования AnyLogic;
 графическая среда имитационного моделирования SIMULINK;
 система моделирования Arena.
Выбор среды моделирования является важной частью работы, так как от этого решения будет зависеть дальнейшая реализация системы. Для выбора наиболее
подходящей среды был проведен вариантный анализ.
В качестве альтернативных решений предложено 4 среды имитационного
моделирования. Данные среды довольно часто используются в современных информационных системах для оптимизации процессов и реализации моделей различной направленности и сложности.
Таким образом, получено множество вариантов конфигурации ИС, подлежащих оценке и выбору. Для данной области выбраны следующие варианты:
V1  AnyLogic; V 2  GPSS;V3  Arena; V 4  SIMULINK.
С учетом специфики разрабатываемой системы были выбраны следующие
критерии:
1) q 1j  наличие средств визуализации и анимации;
2) q 2j  стоимость;
3) q 3j  интеграция с универсальными языками программирования.
Сравним структуры по критериям с помощью экспертов  специалистов в
области ИС, и их оценочная величина в группах соответствует следующим высказываниям:
 имеется существенн ое преимущест во V1 над V2 , V3 , V4 ,
1) Критерий q : 
 имеется слабое преимущест во V2 над V3 , V4 ,

 отсутствие преимущест ва V3 над V4 .

 абсолютное преимущест во V2 над V1 , V3 , V4 ,
2) Критерий q 2j :  отсутствие преимущест ва
(7.8)
V1 над V3 , V4 .

 слабое преимущест во V4 над V3 .

 яявно преимущест во V4 над V1 , V3 , V2 ,


3
3) Критерий q j :  существенн ое преимущест во
V2 над V1 , V3 .

 отсутствие преимущест ва V3 над V1 .

1
j
Рисунок 7.3  Декомпозиция бизнес-процесса на составляющие его операции в стандарте IDEF0
37
38
Экспертным высказываниям соответствуют следующие матрицы парных
сравнений:
1 1/ 5 1/ 5 1/ 5
 1
5 1 1/ 3 1/ 3
1/ 9
; A(q 2j )  
A(q1j )  
5 3
 2
1 1 / 2



2
1 
5 3
 2
9 1 / 2 1 / 2
5
2
 1


1 1/ 9 1/ 9
; A(q 3j )  1/ 5 1 1/ 5
1/ 2 5
9 1
3 
1


9 1/ 3 1 
1/ 7 1/ 7 1/ 7
7
7
.
7

1
Степени принадлежности вычисляются по формуле:
(7.9)
1
 k (v j )  k
.
ai1  aik2  ...  aink
Пользуясь матрицами парных сравнений и формулой (7.9) получим:
 0,62 0,15 0,1 0,09
 0,09 0,75 0,06 0,08
,
, ,
,
,
,
1) q1  
; q2  
;
V
V
V
V
V
V
V
V
 1
2
3
4 
 1
2
3
4 
 0,06 0,13 0,07 0,7 
,
,
, .
2) q3  
V
V
V
V4 
 1
2
3
Для случая равноправных критериев, пользуясь нечеткими множествами и
формулой:






min k
min k
min k


k
 (Vm ) 
 k  1, m  (V1) k  1, m  (V2 )

1, m
D
,
,...,
,
V1
V2
Vm




(7.10)
получим: D   0,06 , 0,13 , 0,06 , 0,08.
 V1
V2
V3
V4 
Множество D свидетельствует о явном преимуществе варианта V 2 над всеми
другими вариантами, однозначном преимуществе V 4 над V1 , V3 .
Для случая неравновесных критериев были учтены мнения экспертов. По их
мнению, критерий q 1j является наиболее важным наряду с критерием q 2j , а критерий q 3j вторичен: абсолютное преимущество q 1j явное преимущество q 2j . Получена
матрица парных сравнений:
1 1 / 7 1 / 9 
A  7 1 1 / 9.


9 9
1 
Определены ранги критериев. Для этого ранги, полученные из матриц парных сравнений, необходимо нормализовать:
1) w1  0,80 ; w2  0,12 ; w3  0,052 ;  wi  0,97.
Ранги критериев после нормирования:
1) w1  0,80 ; w2  0,148 ; w3  0,052 ;  wi  1 .
Тогда согласно формуле:
min k
min k
min k
w1
w2



 (Vm )wm  ,
k
 (V1 ) k 
 (V2 )
k


1, m
1, m
1, m
D
,
,...,

V1
V2
Vm






(7.11)
 0,68 0,21 0,15 0,14
 0,7 0,95 0,65 0,68
 0,86 0,89 0,97 0,98
q1  
,
,
,
,
,
,
,
,
, q2   ,
, q3  
.
V
V
V
V
V
V
V
V
V
V
V
V
 1
2
3
4 
 1
2
3
4 
 1
2
3
4 
39
Пересечение этих множеств с учетом рангов критериев имеет вид: D  0,68 , 0,21, 0,15 , 0,14.
 V1 V2 V3 V4 
Полученный результат свидетельствует о явном преимуществе варианта V1
над V3 , V 2 , V 4 и о достаточном преимуществе варианта V 2 .
Далее проведена оценка коэффициента конкордации экспертов 4, 19].
Значение коэффициента конкордации может находится в диапазоне от 0 до 1.
Если W  0 , считается, что мнения экспертов не согласованны. Если W  1 , то
оценки экспертов полностью согласованны. Каждый эксперт упорядочил системы
по степени предпочтения. Результаты приведены в таблице 7.3.
Таблица 7.3  Оценка коэффициента конкордации
Номер объекта
Ранги Ri
Xi
Xi-T
∆2
W
A
B
C
D
1
2
1
1
1
5
-3,5
12,25
0,67
2
1
1
2
1
5
-3,5
12,25
3
3
2
3
3
11
-2,5
6,25
4
4
3
4
2
13
-4,5
20,25
По величине W сделан вывод, что при оценке мнение экспертов было
среднне согласовано (т.к. хорошим согласованием считается коэффициент конкордации, соответствующий 0.8).
Таким образом, используя вариантный анализ в качестве среды имитационного моделирования для реализации СППР была выбрана среда моделирования
AnyLogic.
40
8 ОБЩИЕ ТРЕБОВАНИЯ К ОФОРМЛЕНИЮ КП
Текст работы должен быть напечатан на одной стороне стандартного листа
формата А4 (270 х 297 мм) через полтора интервала.
Поля должны оставаться по всем четырем сторонам печатного листа: левое –
25 (30) мм, правое –10 мм, нижнее и верхнее –20 мм, количество знаков на странице – примерно 2000.
При печати нужно соблюдать следующие условия:
 текстовой редактор (рекомендуемый) – Microsoft Word;
 шрифт: гарнитура- «Times New Roman», кегль – 14 пт;
 межстрочный интервал по основному тексту – полуторный;
 отступ абзаца – 1,25 см;
 расстановка переносов – автоматическая;
 выравнивание текста – по ширине страницы.
Допустимо применение в таблицах и рисунках кегля ниже 14-го (10-12 пт) и
одинарного межстрочного интервала. Недопустимо применение в основном тексте
«курсива» или «полужирного» шрифта, кроме выделения отдельных слов и словосочетаний.
Допускается использовать одинарный межстрочный интервал в «Оглавлении» и «Списке использованных источников».
Рекомендуется использование режима автоматического составления (добавления) «Оглавления» в тексте ПЗ.
Сокращение слов и словосочетаний на русском и иностранных европейских
языках оформляют в соответствии с требованиями ГОСТ 7.11 и ГОСТ 7.12.
Применение в работе сокращений, не предусмотренных вышеуказанными
стандартами, или условных обозначений предполагает наличие перечня сокращений и условных обозначений.
Наличие перечня не исключает расшифровку сокращения и условного обозначения при первом упоминании в тексте.
Перечень помещают после основного текста.
Перечень следует располагать столбцом. Слева в алфавитном порядке или в
порядке их первого упоминания в тексте приводят сокращения или условные обозначения, справа – их детальную расшифровку
Разделы (главы), подразделы (параграфы), пункты и подпункты основной части работы нумеруются арабскими цифрами (например, раздел:2, подраздел: 2.1,
пункт: 2.1.1). Так, второй подраздел первого раздела получает номер 1.2. Между
номером раздела, подраздела, пункта, подпункта и его названием точка не ставится. Слова «раздел» («глава»), «подраздел» («параграф»), «пункт», «подпункт» в заголовках и содержании ВКР не пишутся. Заголовки глав и параграфов выделяются
полужирным шрифтом.
Перенос слов и их подчеркивание в заголовках не допускается.
Расстояние между структурным заголовком (разделом) и последующим текстом составляет два полуторных интервала (две пустые строки), между заголов-
41
ком раздела и подраздела – тоже два полуторных интервала (две пустые строки).
Каждый раздел (структурный заголовок) работы нужно начинать с новой страницы. Выравнивание заголовка раздела по центру, БЕЗ абзацного отступа.
Заголовки подразделов (1.1...) печатают строчными буквами (кроме первой)
с абзацного отступа. Точку в конце заголовка не ставят. Если заголовок состоит из
двух или более предложений, их разделяют точкой. Расстояние перед заголовком
подраздела составляет два полуторных интервала (две пустые строки), после – один
полуторный интервал (одна пустая строка). Выравнивание по ширине.
Заголовки пунктов (1.1.1...) печатают строчными буквами (кроме первой)
с абзацного отступа. Расстояние перед заголовком пункта составляет один полуторный интервал (одна пустая строка), текст начинается с новой строки непосредственно после заголовка.
Если при перечислении перед каждым пунктом перечисления ставят среднее
тире (дефис); либо строчную букву (за исключением ё, з, о, г, ь, и, ы, ъ), после которой ставится скобка; либо цифру, после которой ставится скобка, тогда текст
каждого пункта перечисления следует начинать со строчной буквы. После каждого
пункта перечисления, кроме последнего, ставится точка с запятой.
Для лучшей наглядности и сравнения показателей в ВКР используются таблицы. Таблица представляет собой особую форму подачи цифровых или словесных
сведений, в которой они располагаются в определенном порядке.
Размещение таблицы рекомендуется выполнять по одному из вариантов:
непосредственно под текстом, где она упоминается впервые, наследующей странице (не далее) или в приложении. В приложении выносятся таблицы, которые содержат более 8-10 строк или свыше 7-8 граф. В текст работы включаются таблицы
меньшего объема. Допускается размещать таблицу вдоль длинной стороны листа
документа (альбомная ориентация страницы), так, чтобы для ее чтения надо было
повернуть лист по часовой стрелке.
Номер таблицы записывают через точку: номер раздела, точка, номер таблицы
в разделе (без пробелов). Название таблицы размещают над таблицей. Без абзацного
отступа записывают: слово «Таблица», ее номер, далее – через тире – наименование
таблицы с большой буквы. Точку в конце названия таблицы не ставят. Расстояние от
заголовка таблицы до таблицы должно быть такое, чтобы текст заголовка таблицы
плотно не прилегал к таблице (например, 3 пт). Расстояние от текста до таблицы и
от таблицы до последующего текста равно одной строке.
Допускается в тексте, помещенном в таблицу, уменьшить размер шрифта на 2
пункта (до 12 размера) и сделать интервал одинарным. Для таблиц большого объема
при необходимости допускается использовать 11 или 10 размер шрифта.
Заголовок таблицы должен быть кратким, четким. Заголовки граф и строк пишутся с прописной буквы в единственном числе, подзаголовки, если они не имеют
самостоятельного значения, со строчной. Подзаголовки граф и строк грамматически
должны быть согласованы с заголовками. Точку в конце заголовка (подзаголовка) не
ставят.
Таблицы, вынесенные в приложения, имеют самостоятельную, отдельную
нумерацию в той последовательности, в какой из них дается ссылка в тексте рабо-
42
ты. Перед номером таблицы в этом случае ставится обозначение приложения.
Например, «Таблица Б.З.» На все таблицы работы должны быть ссылки в тексте.
Таблицы с небольшим количеством граф допускается делить на части и помещать одну часть рядом с другой на одной странице, при этом повторяют головку
таблицы в соответствии с рисунком 9. Рекомендуется разделять части таблицы
двойной линией или линией толщиной 2s.
Таблицу с большим числом строк допускается переносить на другой лист
(страницу). При переносе части таблицы на другой лист (страницу) слово «Таблица», ее номер и наименование указывают один раз слева над первой частью таблицы, а над другими частями также слева пишут слова «Продолжение таблицы» и
указывают номер таблицы. Наименование таблицы повторять не нужно. Если
«шапка» таблицы велика, допускается ее не повторять: в этом случае следует пронумеровать колонки и повторить их нумерацию на следующей странице.
На весь приведенный иллюстративный материал должны быть ссылки в тексте работы, например, «… в соответствии с рисунком 2» (при сквозной нумерации)
или «… в соответствии с рисунком 1.2» (при нумерации в пределах главы). Иллюстрации каждого приложения обозначают отдельной нумерацией арабскими цифрами с добавлением перед цифрой обозначения приложения, например, рисунок
А.3.
Для написания формул использовать только редактор формул Microsoft
Equation не ниже версии 3.0. Найти его можно по следующему пути: вкладка
Вставка → Объект → Тип объекта: Microsoft Equation 3.0.
43
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
Основная литература
1. Сурмин Ю.П. Теория систем и системный анализ: Учеб. Пособие. 
К.:МАУП, 2003.  368 с.
2. Спирин Н.А., Лавров В.В. Методы планирования и обработки результатов инженерного экспиремента: конспект лекции Н.А. 3. Планирование эксперимента – Режим доступа: URL: http://opds.sut.ru/electronic_manuals/pe/f053.htm
3. Налимов В.Н. Логические основания планирования эксперимента:
учебник Е.А. Шалыгина -2-е изд. – М.: Колос, 2001.
4. ГОСТ Р ИСО/МЭК 15288-2005 «Информационная технология.
Системная инженерия. Процессы жизненного цикла систем» (ISO/IEC 15288 (IEEE
Std 15288-2008) Systems and software engineering — System life cycle processes)
5. ГОСТ Р ИСО 15926-1-2008 «Промышленные автоматизированные
системы и интеграция. Интеграция данных жизненного цикла для
перерабатывающих предприятий, включая нефтяные и газовые производственные
предприятия» (ISO/IEC 15926-1:2004 Industrial automation systems and integration —
Integration of life-cycle data for process plants including oil and gas production facilities)
6. ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология.
Системная и программная инженерия. Процессы жизненного цикла программных
средств».
7. Кориков А.М., Павлов С.Н. Теория систем и системный анализ: учеб.
пособие. — Томск: Томс. гос. ун-т систем управления и радиоэлектроники, 2008. —
264 с. — ISBN 978-5-86889-478-7
8. Боев В.Д., Сыпченко Р.П. Компьютерное моделирование. Загол. с
экрана: http://www.intuit.ru/goods_store/ebooks/8521
Дополнительная литература
1. Buede, D. M. The engineering design of systems: models and methods – 2nd
ed. John Wiley & Sons, 2009. ISBN 978-0-470-16402-0
2. Crawley E., etc. The Influence of Architecture in Engineering Systems.
Monograph, 1st Engineering Systems Symposium, Cambridge, Massachusetts, March
29-31, 2004.
3. ISO/IEC TR 24774 Software and systems engineering — Life cycle
management — Guidelines for process description
4. ISO 15026-1 Systems and software engineering — Systems and software
assurance — Part 1: Concepts and vocabulary
5. ISO/IEC FDIS 42010 Systems and software engineering — Architecture
description.
6. Gielingh, W. A theory for the modelling of complex and dynamic systems //
ITcon Vol. 13 (2008)
7. Hitchins, D. Systems Engineering. A 21st Century Systems Methodology.
44
John Wiley & Sons Ltd, 2007. ISBN 978-0470-05856-5
8. Warfield, J. Introduction to systems science. World Scientific Publishing
Co. Pte. Ltd, 2006. ISBN 981-256-702-X
9. Стасинопулос П., Смит М. и др. Проектирование систем как единого
целого. Интегральный подход к инжинирингу для устойчивого развития. —
М.:Эксмо, 2012. — 288 с. ISBN 978-5-699-56765-2
10. Батоврин В. К. Толковый словарь по системной и программной
инженерии: учеб. пособие. — М. ДМК Пресс, 2012. — 280 с. ISBN 978-5-94074818-2
11. Блохин В. П., Дружинин И. В. Глобализация, технология, конкурентоспособность производственных систем. – Ростов-н/Д: Изд. Центр ДГТУ, 2002.
12. Джонс Д. К. Инженерное и художественное конструирование.
Современные методы проектного анализа: Пер. с англ. – М.: Мир,1976 г. – 374 с.
13. Дружинин В. В., Канторов Д. С. Проблемы системологии. М.: Сов.
радио, 1976 г. – 296 с.
14. Дружинин И. В. Информационно-технологические основы конкурентоспособности производственных систем. – Ростов-н/Д: Изд.центр ДГТУ, 2001.
15. Ивахненко А. Г. Принятие решений на основе самоорганизации. – М.:
Сов. радио, 1976. 280 с.
16. Киримов В. Э. Управленческий учет: Учебник – 3-е изд. изм. и доп. –
М.: Издательско-торговая корпорация «Дашков и К°», – 2001 – 480 с.
17. Клир Дж. Системология. Автоматизация решения системных задач:
Пер. с англ. – М.: Радио и связь, 1990 – 544 с.
45
Приложение 1
Образец оформления и содержания ПЗ к курсовому проекту
Титульный лист, формат А4, ориентация книжная
Министерство образования и науки Российской Федерации
ФГАОУ ВО «Севастопольский государственный университет»
Институт информационных технологий и управления в технических системах
Кафедра Информационные системы
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
к курсовому проекту
по дисциплине «Слвременные корпоративные информационные системы
на тему: «указывается тема КП»
Выполнил
Группа
Проверил
Севастополь
20__
ФИО студента
Подпись
ИС/м-ХХ-о(з)
Дата проверки
ФИО преподавателя
Подпись
46
Приложение 2
Министерство образования и науки Российской Федерации
ФГАОУ ВО «Севастопольский государственный университет»
Институт информационных технологий и управления в технических системах
(название учебного заведения)
Кафедра
Информационные системы
ЗАДАНИЕ НА КУРСОВОЙ ПРОЕКТ
по дисциплине «Современные корпоративные информационные системы
ФИО
(фамилия, имя, отчество)
1. Тема курсовой работы________________________________________________
ТЕМА КП
2. Срок сдачи студентом завершенной работы______15.12.20XX г.____________
3. Необходимые данные для выполнения работы
3.1. Постановка задачи. Входные данные: параметры исследуемого процесса, выходные
данные: параметры ожидаемого результата;
3.2. Результаты выполнения лабораторных работ по дисциплине «Методы исследования и
информационных процессов и технологий»
4. Содержание пояснительной записки (перечень вопросов для разработки)
1) Постановка задачи
2) Системотехнический анализ задачи
3) Анализ требований к системе и выбор критериев для оценки качества решения задачи
4) Формализация постановки задачи создания сложной системы
5) Декомпозиция задачи создания сложной системы
6) Вариантный анализ подходов к решению задачи создания сложной системы
7) План решения научной задачи на основе методов планирования эксперимента
8) Заключение, выводы
9) Библиографический список
5. Список графического материала (схемы, графики, диаграммы)
5.1. Презентация доклада (от 5-10 слайдов по содержанию ПЗ);
6. Дата выдачи задания_____________1 сентября 20 г.______________________
Руководитель ________________________________/ФИО/
Задание принял для выполнения __________________/ФИО/
47
КАЛЕНДАРНЫЙ ПЛАН
Название этапов курсовой работы
(проекта)
Сроки
выполнения
№
1
Постановка здачи
2
3
4
5
6
7
8
Оформление ПЗ
9
Подготовка презентации доклада к защите
курсового проекта
10 Защита курсового проекта
Студент ______________________________/ФИО /
Руководитель ________________________/ФИО /
Примечание