Содержание
Актуальность комплексного моделирования сложных объектов и процессов
Основные понятия и определения
Перспективные интеллектуальные ИТ, внедряемые в современные СУ СлО
Зрелость ИТ 2014 г.
Основные направления и факторы влияния ИТ на СУ Сл.О
Основные направления и факторы влияния ИТ на СУ Сл.О
СОВРЕМЕННЫЕ ИНТЕЛЛЕКТУАЛЬНЫЕ ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ
Концептуальное описание динамических цепей поставок (ЦП) на различных этапах ее жизненного цикла
Основные направления и факторы влияния ИТ на СУ Сл.О
Основные направления и факторы влияния ИТ на СУ Сл.О
Потенциальная информационно-технологическая обеспеченность циклов управления СОТО
Основные понятия и определения
Основные понятия и определения
БАЗОВОЕ КОСМИЧЕСКОЕ ГЛОБАЛЬНОЕ ИНФОРМАЦИОННОЕ ПОЛЕ И ЕГО ПОТРЕБИТЕЛИ
Система учета грузов и материалов. Автоматизация процессов складской и транспортной логистики
Концепция адаптивных и самоорганизующихся компьютерных систем
Концепция адаптивных и самоорганизующихся компьютерных систем
Концепция адаптивных и самоорганизующихся компьютерных систем
Основные элементы интеллектуальных транспортных систем
В современных условиях интеллектуализация железных дорог становится насущной задачей
Основные направления и факторы влияния ИТ на СУ Сл.О
Основные направления и факторы влияния ИТ на СУ Сл.О
Проблема
Ошибки параллельных управляющих программ
Примеры ошибок
СМИ о программных ошибках – каждый день
Конфуз с голосованием на выборах в Думу 4 декабря 2011: Ростовская область 146.47%
Тестирование не гарантирует отсутствия ошибок
Рост сложности бортового встраиваемого ПО Boeing и Airbus
Несет ли профессионал ответственность за человеческие жизни?
Важность проблемы валидации
Основные понятия, определения и стандарты программной инженерии
Основные понятия, определения и стандарты программной инженерии
Основные понятия, определения и стандарты программной инженерии
Основные понятия, определения и стандарты программной инженерии
Основные понятия, определения и стандарты программной инженерии
Основные понятия, определения и стандарты программной инженерии
Основные понятия, определения и стандарты программной инженерии
Основные понятия, определения и стандарты программной инженерии
Основные понятия, определения и стандарты программной инженерии
Уровни требований (1)
Уровни требований (2)
Уровни требований (3)
Уровни требований (4)
Функциональные, нефункциональные требования и характеристики продукта (1)
Функциональные, нефункциональные требования и характеристики продукта (2)
Классификация RUP
Методологии и стандарты, регламентирующие работу с требованиями
Литература к лекции (1)
Литература к лекции (2)
Литература к лекции (3)
Программное обеспечение информационных (автоматизированных) систем
Программное обеспечение информационных (автоматизированных) систем
Программное обеспечение информационных (автоматизированных) систем

Современные проблемы и тенденции в области разработки и использования информационных технологий и программной инженерии

1.

Методология программной инженерии
(спецификация требований)
Доктор технических наук, профессор Соколов Б.В
С.-Петербургский институт информатики и автоматизации РАН,
С.-Петербург,
14 линия ВО, 39, СПИИ РАН,
СПИИ РАН
1

2.

Учебная дисциплина:
«Методология программной инженерии (спецификация
требований)»
1. Лекции
2. Практические занятия
3. Научно-технический семинар
4. Лабораторный работы
5. Курсовой проект «Поддержка ЖЗ программного
обеспечения (спецификация требований)
СПИИ РАН
2

3.

Вводная лекция
Тема 1 Жизненный цикл программного обеспечения и его модели.
Классификация и специфицирование требований
Тема 2 Методологические и методические основы формирования и
многокритериального анализа требований
Тема 3 Качество программного обеспечения и модели его оценивания
Тема 4 Международные и отечественные стандарты качества
программного обеспечения
Тема 5 Управление рисками в программном проекте
Тема 6 Формальные методы оценивания качества программного
обеспечения. Верификация и валидация требований к
программному обеспечению.
Тема 7 Интеллектуальные и информационные технологии
формирования и многокритериального анализа требований к
программному обеспечению.
СПИИ РАН
3

4. Содержание

1.
2.
Современные проблемы и тенденции
в области разработки и
использования информационных
технологий и программной
инженерии
Основные понятия, определения и
стандарты программной инженерии
#4

5.

Современные проблемы и тенденции в
области разработки и использования
информационных технологий и
программной инженерии
#5

6. Актуальность комплексного моделирования сложных объектов и процессов

Структурная сложность объектов
Сложность функционирования объектов
Сложность принятия решений и выбора
сценариев поведения объектов
Сложность модернизации и развития
Сложность моделирования
#6

7.

Пример сложной технической системы (CTС)
Топологическая структура орбитальной системы навигационных
космических аппаратов
СПИИ РАН
7

8.

Пример сложной технической системы (CTС)
ИВЦ
потребителей
СПИИ РАН
ЦУП
НКУ НКА
Наземный комплекс управления (НКУ)
навигационными КА (НКА)
8

9.

Пример сложной технической системы (CTС)
ЦА
ОА
ЛСОД
УМОД
ТМА
РБДЗ
РСОД
КИС
ТМА УМОД
ЛСОД
РБДЗ
ТМА
УМОД ЛСОД
РБДЗ
АРМ
БНО
АРМ
ИТО
АРМ
КДО
АРМ
КПО
Техническая структура НКА, КИС, ЦУП НКА
СПИИ РАН
ЦА целевая аппаратура НКА; ОА
обеспечивающая аппаратура НКА;
РБДЗ распределенная база данных
(знаний); ТМА типовой модуль
автоматизации; ЛСОД локальная
система обмена данными; УМОД
унифицированный модуль обмена
данными;
КИС
командноизмерительная
система;
АРМ
автоматизированное
рабочее
место, БНО баллистическое и
навигационное обеспечение; ИТО
информационно-телеметрическое
обеспечение;
КДО
контрольнодиагностическое обеспечение; КПО
командно-программное
обеспечение;
РСОД
распределенная
сеть
обмена
данными.
9

10.

Пример сложной технической системы (CTС)
НКА
0
КИС
РСОД
ЦУП
1
С1
С2
3
2
С3
4
5
6
9
12
14
7
10
13
15
11
С4
20
8
С5
19
16
17
18
21
22
Структура технологии автоматизированного управления космическими
средствами.
СПИИ РАН
10

11.

Комплексное моделирование процессов управления
структурной динамикой НКС
Пример агрегированной диаграммы макросостояний ОрГ НКС.
СПИИ РАН
11

12.

Основные направления и факторы влияния ИТ на СУ
СлО
Менеджмент
ERP
Поставщики
Снабжение
Технология
Техобслуживание
оборудования
Управление
документами
Склады продукции
Заказы
Проектирование
Энергопотребление
Загрузка оборудования
Детальное планирование производства
Управление
процессами
Транспорт
Сбыт
Планирование
производства
Склады сырья
НИОКР
Финансы
Бухгалтерия
Кадры
Заказчики
Дилеры
Маркетинг
Диспетчеризация производства
Учёт производства
Контроль
качества
продукции
Контроль
технологии
Сбор и хранение технологических данных
АСУ ТП
SCADA
АСУ ТП
SCADA
АСУ ТП
SCADA
АСУ ТП
ПРОИЗВОДСТВО
12

13.

Особенности современных объектов
военно-государственного управления
СПИИ РАН
13/40
повышенная сложность и размерность, избыточность,
многофункциональность, распределенность, унификация, однородность
основных элементов, подсистем и связей;
структурная динамика, нелинейность и непредсказуемость
поведения; иерархически-сетевая структура;
неравновесность, неопределенность от вмешательства и выбора
наблюдателя;
постоянное изменение правил и технологий функционирования, изменение
правил изменения технологий и самих правил функционирования; наличие
как контуров отрицательной, так и положительной обратной связи,
приводящих к режимам самовозбуждения (режимам с обострением);
наряду с детерминированным и стохастичным поведением, возможно
хаотическое поведение;
ни один элемент не обладает полной информацией о системе в
целом; избирательная чувствительность на входные воздействия
(динамическая робастность и адаптация)
время реагирования на изменения, вызванные возмущающими
воздействиями, оказывается больше, чем время проявления последствий
этих изменений, чем интервал между этими изменениями;— абсолютную
полноту и достоверность информации описания реального объекта
получить принципиально невозможно в соответствии с пределом
Бремерманна и теоремой Геделя.
13

14.

14/40
Особенности современных ОВГУ
Варианты структур
S 0( j )
( j)
S1
...
Топологическая структура
( j)
Stop
...
Техническая структура St( j )
...
Технологическая структура
( j)
Stec
...
Структура ПМО Ssf( j )
...
Структура ИО Sin( j )
Организационная структура
Sor( j )
( j)
S top
j уровень СлО
Макросостояния
( j)
SK
4
3
2
1
( j)
...
...
St
( j)
S tec
4
t
1
2
3
4
t
1
2
3
4
t
1
2
3
4
t
1
2
3
4
t
1
2
3
4
t
4
3
2
1
( j)
S or
3
4
3
2
1
( j)
S in
2
4
3
2
1
( j)
S sf
1
4
3
2
1
4
3
2
1
Рис.1. Диаграммы структурной динамики ОВГУ. Рис.2. Графики изменения
структурных состояний ОВГУ
СПИИ РАН
14

15.

Проблемы построения систем управления и мониторинга
ОВГУ
Датчики
состояния
сооружений
Средства
обработки 1
Датчики
состояния
агрегатов
Средства
обработки 2
Образ
объекта 2
Средства
обработки 3
Образ
объекта 3
Образ
объекта 1
Объект
мониторинга
Аэрокосмические
средства ДЗЗ
СПИИ РАН
15/40
ЛПР
15

16. Основные понятия и определения

Информационные технологии (ИТ),
представляют
собой
совокупность
способов реализации информационных
процессов
в
различных
областях
человеческой
деятельности
при
производстве
информационного
продукта
СПИИ РАН
16

17. Перспективные интеллектуальные ИТ, внедряемые в современные СУ СлО

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

18. Зрелость ИТ 2014 г.

18

19. Основные направления и факторы влияния ИТ на СУ Сл.О

19

20. Основные направления и факторы влияния ИТ на СУ Сл.О

20

21.

Обобщенная структура современной интегрированной
АСУ СОТО
АСУ корпорации
21/40
OLAP – система (On Line
Analytical Processing)
Оперативная аналитическая
обработка данных в
реальном времени
АСУ предприятия
ERP - система (Enterprise
Resource Planning System)
Система планирования
ресурсов предприятия
MES - система (Manufacturing
Execution System)
АСУ подразделений
Производственная
исполнительная система
SCADA – система
Система операторского
диспетчерского управления
АСУ ТП
подразделений
21

22.

Основные направления и факторы влияния ИТ на СУ
СлО
Исследование
(маркетинг)
Разработка
Подготовка
производства
Производство
Эксплуатация
CRM
продажа>поставка>поддержка
SCM
выбор>покупка>получение>оценка качества
ERP
заказ>планирование>ресурсы>графики>производство
PLM
план>концепция>проектирование>технологическая подготовка>
планирование производства>испытания>поставка>поддержка>утилизация
22

23.

Основные направления и факторы влияния ИТ на СУ
СлО
ERP, SCM, CRM
1.
1.
100
%
PLM
85%
формирование
стоимости
владения
изделием
выполнение
проектных
решений
Принятие
проектных
решений
1.
расходы на
разработку и
производство
изделия
15%
Исследование
(маркетинг)
Разработка
Подготовка
производства
Производство
Эксплуатация
23

24.

Основные этапы принятия решений в СУ СОТО
24/40
Добывание, сбор и обработка информации (непрерывный процесс) о состоянии СТС и внешней среде
Этап реализации N-го
цикла управления
N-й цикл управления
Этап планирования операции
Информационное решение
Организационное решение
Управленческое решение
I этап
1
II этап
2
III этап
3
IV этап
4
1 – оценка обстановки;
2 – выработка плана (замысла операции);
3 – выработка мероприятий для
реализации плана операции;
4 – формирование управляющих
воздействий (УВ);
5 – доведение (передача) УВ исполнительным органам (устройствам)
- точки принятия решений
- точка начала (конца) цикла
управления)
ЛОР – лицо, обосновывающее решение
ЛПР – лицо, принимающее решение
Этап проведения операции
Этап выполнения реализации УВ (контроль выполнения УВ)
(N+1)-й цикл управления
V этап
Этап планирования операции
Информационное решение
Организационное решение
Управленческое
решение
5
I этап
1
II этап
III этап
IV этап
V этап
2
3
4
5
Цикл выработки решения
Этап обоснования решения
(время работы ЛОР)
Альтернативные варианты
Акт принятия решения ЛОР
Этап принятия решения
(время работы ЛПР)
Альтернативные варианты
Акт принятия решения ЛПР
Цикл выработки варианта
1-й этап
2-й этап
Задание варианта Решение варианта
3-й этап
Анализ варианта
24

25. СОВРЕМЕННЫЕ ИНТЕЛЛЕКТУАЛЬНЫЕ ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ

обработки изображений и сигналов;
комплексного моделирования;
многоагентных систем;
интеллектуального пространства;
RFID;
проактивных рекомендующих систем;
краудсорсинга;
проактивного мониторинга и управления;
технологии big-data;
защиты информации и информационной безопасности;
разработки надежного и сертифицируемого программного обеспечения;
ГИС-технологии
речевых и многомодальных пользовательских интерфейсов;
облачных вычислений;
иммуноподобные технологии;
биометрические технологии;
извлечения знаний из распределенных данных;
машинного обучения;
интеллектуального анализа данных и управления знаниями;
аддитивные технологии;
информационного мониторинга Интернет;
космические информационные технологии и др.
25

26.

ПРИМЕРЫ ТЕХНИЧЕСКИХ СРЕДСТВ RFID-ТЕХНОЛОГИИ
МЕТКИ
Классифицируются по рабочей частоте, наличию встроенных источников энергии (пассивные, активные)
ЧИП
Антенна
РИДЕРЫ
Классифицируются по рабочей частоте, дальности обнаружения меток (габаритным размерам)
стационарный
настольный
носимые
Ридер со встроенным компьютером
26

27.

СРАВНЕНИЕ ХАРАКТЕРИСТИК ТЕХНОЛОГИЙ РАДИОЧАСТОТНОЙ
ТЕХНОЛОГИЙ (RFID-ТЕХНОЛОГИЙ) И ШТРИХ-КОДОВ
В настоящее время стоимость RFID-меток составляет от $1 до $0.15,
что существенно превышает стоимость марок штрих-кодов.
Однако существует устойчивая тенденция к ее снижению
27

28. Концептуальное описание динамических цепей поставок (ЦП) на различных этапах ее жизненного цикла

Производит исходные
сырье и материалы
Покупает исходные
сырье и материалы
Поставщик n-ступени
Транспортирует готовую
продукцию в
дистрибуционный центр
Изготавливает детали и
узлы
Поставщик 1-ступени
Складирует продукцию в
дистрибуционных центрах
Складирует
продукцию в
магазине
Производит конечный
продукт
Производитель
(фокусная компания)
Складирует
продукцию
Транспортирует
Оптовик
продукцию
магазины
Продает
Транспортное предприятие
продукцию
Логистический оператор
Торговля
Клиент
28

29.

Автоматизированный складской комплекс
29

30.

Обобщенная схема интегрированной транспортнологистической подсистемы (ИТЛС) в ЦП
(Куренков П.В. журнал Логистика сегодня, №4, 2010 )
Интермодальные перевозки
Российская Федерация
Стыки смежных видов
транспорта
Пропуск вагона система
«Грузовой экспресс»
железнодорожный
транспорт
Погрузка
вагона
и его
оформление
система
«ЭТРАН»
Выгрузк
а вагона
Производитель продукции
Крупное
пром.
предприятие
Морской транспорт
Единое экономическое пространство
Стык смежных видов
транспорта
Автомобильный
транспорт
Смежная страна
Пограничный стык
Железнодорожный
транспорт
Железнодорожный
транспорт
Выгрузк
а вагона
МОРЕ
Единый транспортный коридор
Единый транспортный
конвейер
Потребитель
продукции
Потери по стыкам взаимодействия смежных видов транспорта и пограничным
переходам
Путь следования вагона от производителя продукции до ее потребителя
30

31.

Основные направления и факторы влияния ИТ на СУ Сл.О
Кибер Физические системы (CPS) умные сетевые системы со встроенными датчиками,
процессорами и приводами, которые предназначены для распознавания и взаимодействия с
физическим миром (в том числе человека пользователей) и для поддержания в реальном
времени, гарантированной производительность в критически важных приложениях
безопасности. В CPS системах, совместное поведение "кибер" и "физических" элементов
системы имеет решающее значение - вычислительная техника, управления, датчики и сети
могут быть глубоко интегрированы в каждом компоненте, и действия компонентов и систем
должны быть безопасными и совместимыми.
31

32. Основные направления и факторы влияния ИТ на СУ Сл.О

Актуальность появления кибер-физические системы:
Рост числа устройств со встроенными процессорами и средствами
хранения данных (более 50 млрд. устройств; более 5 млрд. Smart Phone).
Интеграция, позволяющая достигнуть наибольшего эффекта путем
объединения отдельных компонентов в большие системы: Интернет
вещей (IoT), World Wide Sensor Net, произвлодственный Интернет, умные
среды обитания (Smart Building Environment), оборонные системы будущего
(NetworkCentric Systems) и т.д.
Ограничение когнитивных способностей человека, которые
эволюционируют медленнее, чем машины ( человек уже не в состоянии
справиться с объемом информации, требуемой для принятия решений).
Администрация первого президентского срока Барака Обамы включила
киберфизические системы в приоритетный список инноваций, а после его
переизбрания линия развития подтвердилась. В 2013 году была
утверждена вторая редакция президентского инновационного
партнерства USA Presidential Innovation Fellows, где среди девяти
приоритетных направлений присутствует и US Multi-agency funding CyberPhysical Systems initiative (CPS) .
32

33.

ОСОБЕННОСТИ СИСТЕМ УПРАВЛЕНИЯ ЖИЗНЕННЫМ ЦИКЛОМ СЛОЖНЫХ ТЕХНИЧЕСКИХ
ОБЪЕКТОВ
33
33

34. Основные направления и факторы влияния ИТ на СУ Сл.О

34

35.

Перспективы и проблемы развития и взаимодействия ИТ и СУ
сложными объектами
ЖИЗНЕННЫЙ ЦИКЛ ПРОДУКЦИИ
Средняя стадия
Начальная стадия (BOL)
Проектирование
(MOL)
Производство
Применение
Конечная стадия
(EOL)
Процесс
Процесс
1.Процесс
Проц
есс
Процесс
Ресурсы
Ресурсы
1.Ресурсы
Ресу
рсы
Ресурсы
Продукт
Продукт
1.Продукт
Прод
укт
Продукт
Сервис
Повторное
использование
Материалы
Полная
модернизация
Повторное
использование
материалов
1.
Ликвидация
35

36. Потенциальная информационно-технологическая обеспеченность циклов управления СОТО

Этап
Уяснение задачи
Расчет времени
Оценка
обстановки
Выработка
замысла
Принятие
решения
Действия операторов
Цель предстоящих действий.
Замысел старшего начальника.
Задача, место и роль своего формирования.
Показатели операции.
Промежуточные задачи.
Задачи соседей, взаимодействующих органов
условия взаимодействия.
Время для непосредственной подготовки сил к
действиям.
Время на принятие решения.
Время на постановку задач подчиненным силам.
Время на планирование операции.
Оценка противника.
Оценка своих сил и средств.
Оценка соотношения сил (характеристик
противодействия).
Оценка района (зоны) боевых (других) действий.
Оценка времени
Районы (задачи) сосредоточения основных усилий.
Способы применения своих сил и средств, в т.ч.
разгрома противника (где, когда, кого и в какой
последовательности).
Порядок действий, в т.ч. поражения противника.
Меры по обману противника (маскировке).
Создаваемые группировки сил и средств и их
построение (распределение).
Анализ различных вариантов действий сил.
Утверждение замысла, определение его идеи.
Определение задачи подчиненным и приданным
объединениям.
Определение основ организации взаимодействия,
обеспечения и управления.
Информационная технология
Анализ текстов
Извлечение информации
Обработка естественного языка
Обработка неструктурированных данных
Структуризация данных
и
Разработка потоков работ
Логико-динамические модели
Проактивный мониторинг и управление
Информационный поиск
Консолидация данных
OLAP
Ситуационный анализ
Визуализация
Системы рассуждений на основе
аналогичных случаев (прецедентов)
Деревья решений
Сценарный анализ
Вербальный анализ решений
Групповой вербальный анализ решений
Многокритериальный выбор
Проактивный мониторинг и управление
36

37.

Структура типовой СППР
37/40
Объекты военногосударственного управления
(ВГУ)
Система
поддержки
реализации
решений
Интегрированная интеллектуальная система поддержки принятия решений
Интеллектуальное интегрированное АРМ специалиста по
управлению объектами ВГУ
Расчётнологическая
система
CASEсистемы
Система
поддержки
контроля
реализации
решений
Экспертная система
поддержки принятия
решений
Интеллектуальная
ИПС
Имитационная система
ЛПР
(специалисты по
управлению)
37

38. Основные понятия и определения

Космические
информационные
технологии
(КИТ)

это
информационные
технологии,
обеспечивающие
сбор,
хранение,
передачу
(прием),
представление,
обработку, анализ и защиту данных на
различных этапах жизненного цикла
космических средств (КСр).
СПИИ РАН
38

39. Основные понятия и определения

Основные особенности КИТ определяются:
•существенным
влиянием
многочисленных
факторов
космического
пространства
и
тех
специфических
пространственно-временных, технических и технологических
ограничений, вызываемых ими, которые не позволяют
напрямую
использовать
стандартные
инфотелекоммуникационные
методы
и
средства
для
эффективного решения фундаментальных и прикладных задач
космонавтики;
•многоуровневым и циклическим характером решения КСр
целевых и обеспечивающих задач;
•комплексной интеграцией
космических информационных
технологий
с
технологиями
автоматизированного
(автоматического)
управления
КСр
в
рамках
соответствующих автоматизированных систем (АС)
СПИИ РАН
39

40. БАЗОВОЕ КОСМИЧЕСКОЕ ГЛОБАЛЬНОЕ ИНФОРМАЦИОННОЕ ПОЛЕ И ЕГО ПОТРЕБИТЕЛИ

Дистанционное
зондирование
Земли
Навигационные,
геодезические
системы
Связные
системы
КОСПАС-SARSAT
ЭКОЛОГИЯ, СЕЛЬСКОЕ ХОЗЯЙСТВО, ГРАДОСТРОИТЕЛЬСТВО, ГЕОДЕЗИЯ, КАРТОГРАФИЯ,
МЕДИЦИНА, ТЕЛЕВИДЕНИЕ, СВЯЗЬ, ИНТЕРНЕТ, МЕТЕООБСТАНОВКА, ГЕОЛОГИЯ, СПАСАНИЕ
ТЕРПЯЩИХ БЕДСТВИЯ В ВОЗДУХЕ, НА ВОДЕ И НА СУШЕ
МОНИТОРИНГ:
КРИТИЧЕСКИ ВАЖНЫХ ОБЪЕКТОВ И ОПАСНЫХ ГРУЗОВ, ДВИЖЕНИЯ ВСЕХ ВИДОВ ТРАНСПОРТНЫХ
СРЕДСТВ, ПРИРОДНЫХ И АНТРОПОГЕННЫХ ЧС, И ДР.
СПИИ РАН
Источник: НИИ
40

41. Система учета грузов и материалов. Автоматизация процессов складской и транспортной логистики

Площадка приема
груза
и материалов
Транспортный
коридор
Спутник
GPS/GLONASS
Склад временного
хранения
комплектующих
Объект
строительства
Склад материалов
СПИИ РАН
Завод 1
Завод 2
Завод N
База
данных
MRP2
41

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

КОНЦЕПЦИЯ
Самоконфигурация
Самооптимизация
Самовосстановление
Самозащита
СПИИ РАН
САМОРЕГУЛИРУЮЩИЕСЯ
ВЫЧИСЛЕНИЯ
Корпоративные центры обработки
Автоматическое конфигурирование
данных используют оборудование и
компонентов и систем в
платформы различных производителей. соответствии с высокоуровневыми
Установка, конфигурирование и
правилами. Остальная часть
интеграция систем требуют больших
системы настраивается
затрат времени и изобилуют
автоматически и бесконфликтно.
ошибками.
Система имеет сотни
Компоненты и системы постоянно
устанавливаемых вручную, нелинейно
ищут возможность увеличить свою
меняющихся параметров, и с каждой
производительность и
новой реализацией их число растет.
эффективность.
Выявление проблем в крупных, сложных Система автоматически
системах требует работы целой
выявляет, диагностирует и
группы программистов в течение
исправляет локализованные
нескольких недель.
программные и аппаратные
проблемы.
Определение и восстановление после
Система автоматически
атак или серии порождающих друг друга защищается от вредоносных атак
ошибок вручную.
или порождающих друг друга
ошибок. Она использует средства
раннего предупреждения для
прогнозирования и предупреждения
общесистемных сбоев.
СОВРЕМЕННОЕ СОСТОЯНИЕ
42

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


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

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


Примеры направлений практической
реализации концепции адаптивных и
самоорганизующихся компьютерных
систем:
Dell-Dynamic Computing;
Hewlett-Packard-Adaptive Infrastructure
(Adaptive Enterprise);
IBM-Computing On Demand; Autonomous
Computing;
Microsoft-Dynamic Systems;
Sun Microsystems-N1.
СПИИ РАН
44

45. Основные элементы интеллектуальных транспортных систем

ИНТЕЛЛЕКТУАЛЬНЫЕ СИСТЕМЫ
УПРАВЛЕНИЯ ЭКСПЛУАТАЦИОННОЙ
РАБОТОЙ
СПУТНИКОВЫЕ ТЕХНОЛОГИИ
МОНИТОРИНГА
ОБЪЕКТОВ И РАДИОЛОКАЦИОННОГО
ЗОНДИРОВАНИЯ
ЕДИНОЕ ИНФОРМАЦИОННОЕ
ПРОСТРАНСТВО ТРАНСПОРТА
С ОБЕСПЕЧЕНИЕМ ИНФОРМАЦИОННОЙ
ЗАЩИТЫ
ИНТЕЛЛЕКТУАЛЬНЫЙ
ЖЕЛЕЗНОДОРОЖНЫЙ
ТРАНСПОРТ
СИСТЕМЫ УПРАВЛЕНИЯ ДВИЖЕНИЕМ
ПОЕЗДОВ НА ОСНОВЕ СПУТНИКОВОЙ
НАВИГАЦИИ ЦИФРОВОЙ
РАДИОСВЯЗИ (ГЛОНАСС)
СИСТЕМЫ КОНТРОЛЯ МЕСТОПОЛОЖЕНИЯ
ВАГОНОВ, ЛОКОМОТИВОВ И
ЭКСПЛУАТАЦИОННОГО ПЕРСОНАЛА
С ИХ АВТОМАТИЧЕСКОЙ
ИДЕНТИФИКАЦИЕЙ
СПИИ РАН
ИНТЕЛЛЕКТУАЛЬНЫЕ ЛОГИСТИЧЕСКИЕ
СИСТЕМЫ
СИСТЕМЫ ЦИФРОВОЙ РАДИОСВЯЗИ
СО ВСЕМИ ОБЪЕКТАМИ
ТРАНСПОРТНОЙ ИНФРАСТРУКТУРЫ
СИСТЕМЫ
ФИНАНСОВОГО МОНИТОРИНГА
И ОПТИМИЗАЦИИ РАСХОДОВ
ЦЕНТРЫ СИТУАЦИОННОГО
КОНТРОЛЯ
И ПРОГНОЗИРОВАНИЯ
КРИТИЧЕСКИХ
СИТУАЦИЙ
ЦЕНТРЫ МОНИТОРИНГА И
ДИАГНОСТИКИ ПОДВИЖНОГО
СОСТАВА И ИНФРАСТРУКТУРЫ
НА ХОДУ ПОЕЗДА
45

46. В современных условиях интеллектуализация железных дорог становится насущной задачей

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

47. Основные направления и факторы влияния ИТ на СУ Сл.О

СПИИ РАН
47

48. Основные направления и факторы влияния ИТ на СУ Сл.О

происходит
дальнейшая
глобализация,
интеграция
и
комплексирование ИТ на базе новейших прорывных технологий,
создаваемых в настоящее время в сфере информационных и
телекоммуникационных
технологий.
Характерными
особенностями
современных
и
создаваемых
автоматизированных систем (АС) является:
• избыточность основных элементов и подсистем АС;
• структурное подобие элементов и подсистем АС, находящихся
на различных уровнях;
•много вариантность реализации функций управления на каждом
уровне АС,
•использование
гибких
технологий
управления;
наличие
унифицированных технических средств АС, объединенных в
типовые
вычислительные
модули,
комплексы
средств
автоматизации;
•наличие пространственно–распределенной многоконтурной
интегральной сети обмена данными
•создание АС, базирующихся на концепции самоорганизующихся
вычислений
48

49. Проблема

Компьютеры – повсюду Ubiquitous computing
(вездесущие вычисления)
ИТ проникли во все сферы жизни современного общества.
Раньше компьютер был компьютером, а телефон – телефоном, и
любой мог отличить одно от другого. Cейчас и компьютер – не
только компьютер, и телефон – не только телефон (A.Tanenbaum)
Эра параллельного программирования
Параллельные программы полны ошибок
Последовательные программы имеют очень узкое применение
Многоядерные чипы, встроенные бортовые СУ -> требуются
технологии разработки параллельного ПО, чтобы оно выполняло
нужные функции
Multicore processors are bringing parallelism to mainstream of
computing
Параллельные программы непостижимы для человеческого мозга:
они очень часто неправильны, содержат ошибки
49

50. Ошибки параллельных управляющих программ

Параллельные программы могут годами сохранять ошибки,
проявляющиеся после долгой эксплуатации
Такие ошибки возникают как реакция на возникшую специфическую
комбинацию многочисленных факторов, в частности, непредсказуемых
скоростей выполнения отдельных процессов в параллельных
программах
Параллельные программы работают правильно “почти всегда”
Системы программного управления обычно строятся из
параллельных взаимодействующих модулей и являются
параллельными по своей сути. Ошибки в них часто являются
критическими
Ю.Г.Карпов
Семинар "Наука и общество"
50

51. Примеры ошибок

В 1994 INTEL выпущен чип с ошибкой во встроенной программе. Замена
миллионов дефектных процессоров потери ~$500 млн.
4.06.96 ракета Ариан 5 взорвалась через 39 с. Ошибка в бортовой программе
при преобразовании 64-битового вещ в 16-бит целое. Ущерб > $600 млн.
Конец 80-х: Therac-25 прибор лучевой терапии. Встроенная программа
управления прибором допускала перевод в режимы с огромной дозой
облучения. При некоторых (редких) действиях персонала пациенты получали
передозировку. Двое умерли, несколько человек стали инвалидами.
23.03.2003. Война в Ираке. Ошибка в программе система Patriot
определила свой бомбардировщик Tornado как приближающуюся ракету и его
сбили. Два пилота погибли.
До 24% потерь в живой силе в I Иракской войне – “Friendly Fire”.
Boeing 757, 1995 г (рейс из Майами в Колумбию ). Ошибка в Flight
Management System привела к катастрофе. Погибли 159 человек. Фирмаразработчик ПО выплатила $300 млн родственникам жертв
Бортовой компьютер на израильском истребителе в районе Мёртвого моря
отказал: деление на 0. Высота над уровнем моря там является отрицательной
величиной
Ю.Г.Карпов
Семинар "Наука и общество"
51

52. СМИ о программных ошибках – каждый день

Апрель, 2010. Авария в Мексиканском заливе: возможна ли программная
ошибка? Don Shafer, Phillip Laplante. The BP Oil Spill: Could Software be a Culprit?
IEEE IT Pro September/October 2010, IEEE, 2010. ... Не могла ли одной из причин
бедствия стать ошибка в программном обеспечении?
05.07.2010. Apple: ошибка связи iPhone 4 — программная. Компания Apple
признала существование в iPhone 4 проблем, касающихся качества связи.
06.12.2010. Cпутники ГЛОНАСС и ракету “Протон-М” утопили программисты.
Ракета-носитель «Протон-М» со спутниками «Глонасс-М» отклонились от заданного
курса из-за допущенных ошибок в математическом обеспечении (основная причина неправильно написанная формула в документации на заправку кислородом
разгонного блока)
08.12.2010 — Японский зонд «Акацуки» не смог выйти на орбиту Венеры
Космический исследовательский аппарат «Акацуки», запущенный Японией для
исследования Венеры, не смог выйти на орбиту планеты, сообщает РИА «Новости»
со ссылкой на специалистов Японского аэрокосмического агентства JAXA
52

53. Конфуз с голосованием на выборах в Думу 4 декабря 2011: Ростовская область 146.47%

58.99%
32.96%
23.74%
19.41%
9.32%
1.46%
0.59%
146.47%
53

54. Тестирование не гарантирует отсутствия ошибок

Основным методом повышения надежности программ при
традиционных методах разработки является тестирование
Эдсгер Дейкстра:
“Тестирование не может доказать отсутствия ошибок в программе”
В среднем современные программные системы имеют 10
ошибок на 1000 строк кода,
ПО высокого качества 1-3 ошибки на 1000 строк кода
Современное ПО содержит миллионы строк кода
Уже сданные работающие программы наполнены ошибками
В ОС Windows 95 ~ 5000 ошибок
«Good enough software» недопустимо для критических применений
54

55. Рост сложности бортового встраиваемого ПО Boeing и Airbus

55

56. Несет ли профессионал ответственность за человеческие жизни?

Программирование является единственной
областью инженерной деятельности,
где разработчик не отвечает за качество своей
работы
Программист обычно НЕ ЗНАЕТ
(и не хочет знать!)
как определить требования к результату своей работы?
как проверить, что эти требования выполняются?
56

57. Важность проблемы валидации

До 80% средств при разработке встроенного ПО тратится на
валидацию – проверку соответствия ПО тому, что нужно
потребителю ($60 billion annually for US economy – данные 2005 г.)
При оставшихся в системах ошибках:
Огромные материальные потери
Потери жизней
КТО БУДЕТ ОТВЕЧАТЬ? Страховка?
низкая надежность продукта падает прибыль
увеличивается время разработки (time-to-market)
иски после аварии компания разоряется
5 декабря 2010.
Старт ‘Протона-М’ со
спутниками ГЛОНАСС:
~ $200 млн -> в океан
В последнее десятилетие сложность разрабатываемых компьютерных
систем дошла до критического уровня: требуются все более сложные
программы, а технология программирования не может их
разрабатывать с требуемым качеством
57

58.

Основные понятия, определения и
стандарты программной инженерии
#58

59. Основные понятия, определения и стандарты программной инженерии

Программное обеспечение автоматизированной системы (АС) (Automated
system software) по ГОСТ 34.003-90 – это совокупность программ на
носителях данных и программных документов, предназначенная для
отладки, функционирования и проверки работоспособности АС [из п. 2.7
ГОСТ 34.003-90]
Программное обеспечение автоматизированной системы включает в свой
состав общее программное обеспечение (ОПО) и специальное
программное обеспечение (СПО).
Общее программное обеспечение (ОПО) автоматизированной системы
(АС) (Automated system heave-duty software) по ГОСТ 34.003-90 –это часть
программного обеспечения АС, представляющая собой совокупность
программных средств (ГОСТ 28806-90), разработанных вне связи с
созданием данной АС. Примечание - Обычно ОПО АС представляет собой
совокупность программ общего назначения, предназначенных для
организации вычислительного процесса и решения часто встречающихся
задач обработки информации [из п. 6.2 ГОСТ 34.003-90]
#59

60. Основные понятия, определения и стандарты программной инженерии

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

61. Основные понятия, определения и стандарты программной инженерии

Специальное программное обеспечение (СПО) автоматизированной
системы (АС) (Automated system application software) по ГОСТ 34.003-90 –
это часть программного обеспечения АС, представляющая собой
совокупность программ, разработанных при создании данной АС [из п. 6.3
ГОСТ 34.003-90]
Специальное программное обеспечение, как правило, работает «поверх»
общего ПО (т.е. под управлением операционной системы) и обычно
является клиентской частью, взаимодействующей с серверной частью,
установленной на удаленном (или не очень) сервере, по локальной или
глобальной компьютерной сети. Если серверная часть СПО представляет
собой веб-приложение, то в качестве клиентской части применяется
браузер, входящий в состав общего программного обеспечения («тонкий»
клиент).
#61

62. Основные понятия, определения и стандарты программной инженерии

Требования – это исходные данные, на основании которых проектируются
и создаются автоматизированные информационные системы. Первичные
данные поступают из различных источников, характеризуются
противоречивостью, неполнотой, нечёткостью, изменчивостью. Требования
нужны в частности для того, чтобы Разработчик мог определить и согласовать
с Заказчиком временные и финансовые перспективы проекта автоматизации.
Поэтому значительная часть требований должна быть собрана и обработана
на ранних этапах создания АИС. Однако собрать на ранних стадиях все
данные, необходимые для реализации АИС, удаётся только в
исключительных случаях. На практике процесс сбора, анализа и обработки
растянут во времени на протяжении всего жизненного цикла АИС, зачастую
нетривиален и содержит множество подводных камней.
#62

63. Основные понятия, определения и стандарты программной инженерии

#63

64. Основные понятия, определения и стандарты программной инженерии

#64

65. Основные понятия, определения и стандарты программной инженерии

В IEEE Standard Glossary of Software Engineering Terminology (1990) понятие
требование к ИС ((ПО) трактуется следующим образом. Требование – это:
1. Условия или возможности, необходимые пользователю для решения
проблем или достижения целей;
2. Условия или возможности, которыми должна обладать система или
системные компоненты, чтобы выполнить контракт или удовлетворять
стандартам, спецификациям или другим формальным документам;
3. Документированное представление условий или возможностей для
пунктов 1 и 2.
В нотации RUP приводит следующее определение: «Требование – это условие
или возможность, которой должна соответствовать система».

66. Основные понятия, определения и стандарты программной инженерии

Требования к продукту. В своей основе требования – это то, что формулирует
заказчик. Цель, которую он преследует – получить хороший конечный
продукт: функциональный и удобный в использовании. Поэтому требования к
продукту являются основополагающим классом требований. Более подробно
требования к продукту детализируются в следующих ниже классификациях.
Требования к проекту. Вопросы формулирования требований к проекту, т.е. к
тому, как Разработчик будет выполнять работы по созданию целевой
системы, казалось бы, не лежат в компетенции Заказчика. Без регламентации
процесса Заказчиком легко можно было бы обойтись, если бы все проекты
всегда выполнялись точно и в срок. Однако, к сожалению, мировая статистика
результатов программных проектов говорит об обратном. Заказчик, вступая в
договорные отношения с Разработчиком, несёт различные риски, главными
из которых является риск получить продукт с опозданием, либо
ненадлежащего качества. Основные мероприятия по контролю и снижению
риска – регламентация процесса создания программного обеспечения и его
аудит.

67. Основные понятия, определения и стандарты программной инженерии

В качестве требований к проекту могут быть внесён регламент отчётов
Разработчика, совместных семинаров по оценке промежуточных результатов,
определены характеристики компетенций участников рабочей группы,
исполняющих проект, их количество, указана методология управления
проектом. Ниже сформулирован пример формулировки требования к
оффшорному проекту (Заказчик и Разработчик физически находятся в разных
государствах) – в этой ситуации Заказчику требуется жёсткий контроль над
Разработчиком.
1) Разработчик представляет Заказчику согласованный план работ c
детализацией (WorkBreakdownStructure - WBS) с точностью до конкретных
исполнителей.
2) Разработчик осуществляет ежедневные сборки, регрессионное
тестирование компонент разрабатываемого продукта и тестирование
продукта в целом.
3) Все управленческие и проектные артефакты, исходные коды и
тестовые примеры размещаются в режиме online в интегрированной среде
разработки Rational ClearCase с возможностью для Заказчика
осуществления online-мониторинга на базе web-технологий.

68. Уровни требований (1)

Обычно выделяют три уровня требований.
На верхнем уровне представлены так называемые бизнес-требования (business
requirements). Примеры бизнес-требования: система должна сократить срок
оборачиваемости обрабатываемых на предприятии заказов в три раза. Бизнестребования обычно формулируются топ-менеджерами, либо акционерами
предприятия.
Следующий уровень – уровень требований пользователей (user requirements).
Пример требования пользователя: система должна представлять диалоговые средства
для ввода исчерпывающей информации о заказе, последующей фиксации
информации в базе данных и маршрутизации информации о заказе к сотруднику,
отвечающему за его планирование и исполнение. Требования пользователей часто
бывают плохо структурированными, дублирующимися, противоречивыми. Поэтому
для создания системы важен третий уровень, в котором осуществляется
формализация требований.
Третий уровень – функциональный (functional requirements). Пример
функциональных требований (или просто функций) по работе с электронным заказом:
заказ может быть создан, отредактирован, удалён и перемещён с участка на участок.

69. Уровни требований (2)

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

70. Уровни требований (3)

INCOSE (International Council on Systems Engineering) даёт более
детальное определение системы: «комбинация взаимодействующих
элементов, созданная для достижения определенных целей; может
включать аппаратные средства, программное обеспечение, встроенное
ПО, другие средства, людей, информацию, техники (подходы), службы
и другие поддерживающие элементы». Таким образом, происходит
разделение между системными требованиями, как обобщающему
понятию и требованиями к программному обеспечению, как
выделенному подмножеству системных требований, направленных
исключительно на программные компоненты системы. Этот же подход
прослеживается в стандарте ГОСТ Р ИСО/МЭК 12207/99 [14]: работы,
связанные с системой в целом и с программным обеспечением
выделяются в отдельные группы в целях удобства оперирования.

71. Уровни требований (4)

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

72. Функциональные, нефункциональные требования и характеристики продукта (1)

Функциональные требования регламентируют функционирование или
поведение системы (behavioral requirements). Функциональные требования
отвечают на вопрос «что должна делать система» в тех или иных ситуациях.
Функциональные требования определяют основной «фронт работ»
Разработчика, и устанавливают цели, задачи и сервисы, предоставляемые
системой Заказчику.
Нефункциональные требования, соответственно, регламентируют внутренние
и внешние условия или атрибуты функционирования системы. К. Вигерс
выделяет следующие основные группы нефункциональных требований:
Внешние интерфейсы (External Interfaces),
Атрибуты качества (Quality Attributes),
Ограничения (Constraints).

73. Функциональные, нефункциональные требования и характеристики продукта (2)

Среди внешних интерфейсов в большинстве современных АИС наиболее
важным является интерфейс пользователя (User Interface, UI). Кроме того,
выделяются интерфейсы с внешними устройствами (аппаратные
интерфейсы), программные интерфейсы и интерфейсы передачи
информации (коммуникационные интерфейсы).
Основные атрибуты качества:
Применимость.
Надежность.
Производительность.
Эксплуатационная пригодность, достаточно хорошо раскрыты в модели
FURPS.
Ограничения - формулировки условий, модифицирующих требования
или наборы требований, сужая выбор возможных решений по их реализации.
выбор платформы реализации и/или развертывания (протоколы, серверы
приложений, баз данных, ...), которые, в свою очередь, могут относиться,
например, к внешним интерфейсам (конец цитаты).

74. Классификация RUP

В спецификациях Rational Unified Process при классификации требований
используется модель FURPS+ со ссылкой на стандарт IEEE Std 610.12.1990.
Акроним FURPS обозначает следующие категории требований:
Functionality (Функциональность).
Usability (Применимость).
Reliability (Надёжность).
Performance (Производительность).
Supportability (эксплуатационная пригодность).
Символ «+» расширяет FURPS-модель, добавляя к ней:
ограничения проекта,
требования выполнения,
требования к интерфейсу,
физические требования, часть из которых уже была рассмотрена выше.
Кроме того, в спецификациях RUP выделяются такие категории
требований, как
требования, указывающие на необходимость согласованности с
некоторыми юридическими и нормативными актами;
требования к лицензированию,
требования к документированию.

75. Методологии и стандарты, регламентирующие работу с требованиями

Среди основополагающих нормативных документов в области работы с
требованиями можно выделить следующие.
1. Разработки IEEE:
IEEE 1362 “Concept of Operations Document”.
IEEE 1233 «Guide for Developing System Requirements Specifications».
IEEE Standard 830-1998, «IEEE Recommended Practice for Software
Requirements Specifications»
IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.121990
IEEE Guide to the Software Engineering Body of Knowledge (1) - SWEBOK®,
2004.
2. Отечественные ГОСТ:
ГОСТ 34.601-90. Информационная технология. Автоматизированные
системы. Стадии создания. ГОСТ 34.602-89. Информационная технология.
Техническое задание на создание автоматизированной системы
ГОСТ 19.201-78. Единая система программной документации. Техническое
задание. Требования к содержанию и оформлению.

76. Литература к лекции (1)

1. Макарова Н.В. Информатика: Учебник. - М.: Финансы и статистика, 2003. 768 с.
2. ERP системы. Современное планирование и управление ресурсами
предприятия. Выбор, внедрение, эксплуатация/Дэниел О’Лири;[Пер. с англ.
Ю.И.Водопьяновой]. – М.: ООО «Вершина», 2004. – 272 с.
3. Меняев М.Ф. Информационные технологии управления: Учебное пособие:
В 3 кн.: Книга 3: Системы управления организацией. – М.: Омега-Л, 2003. – 464
с.
4. Автоматизированные информационные системы, базы и банки данных.
Вводный курс: Учебное пособие. – М.: Гелиос АРВ, 2002. – 368 с., ил.
5. Б.Н. Гайфуллин, И.А. Обухов. Автоматизированные системы управления
предприятиями стандарта ERP/MRPII. Производственное издание. – М.
«Богородский печатник», 2001, 104 с.
6. Петров В. Н. Информационные системы. – СПб.: Питер, 2002. - 688 с.
7. IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.121990
8. Вигерс Карл Разработка требований к программному обеспечению/Пер, с
англ. — М.:Издательско-торговый дом «Русская Редакция», 2004. —576с.: ил.
9. Леффингуелл Д., Уидриг Д. Принципы работы с требованиями к
программному обеспечению. М.: ИД “Вильямс”, 2002.

77. Литература к лекции (2)

10. Алистер Коберн. Современные методы описания функциональных
требований к системам. М.: издательство «Лори», 2002. – 263 с.
11. Мацяшек Лешек. Анализ требований и проектирование систем.
Разработка информационных :с Диалектика-Вильямс
12. Орлик С., Булуй Ю. Введение в программную инженерию и управление
жизненным циклом ПО Программная инженерия. Программные требования.
Copyright © Сергей Орлик, 2004-2005. http://www.sorlik.ru/swebok/3-1software_engineering_requirements.pdf
13. IEEE Guide to the Software Engineering Body of Knowledge (1) - SWEBOK®,
2004. – http://www.swebok.org
14. ГОСТ Р ИСО/МЭК 12207/99. Государственный стандарт РФ.
Информационная технология. Процессы жизненного цикла информационных
систем. Издание официальное. – М., 1999.
15. Л.Новиков. Введение в Rational Unified Process.
http://www.interface.ru/rational/interface/151199/rup/main.htm
16. Белые страницы MSF. http://www.microsoft.com/rus/msdn/msf
17. Analyzing requirements and defining Microsoft .Net solution architectures
2000 г. 491 стр. Microsoft Press.

78. Литература к лекции (3)

18. Введение в Rational Unified Process/ Ф. Кратчен – СПб.: Вильямс, 2002. –
240 с.
19. Унифицированный процесс разработки программного обеспечения/ А.
Якобсон, Г. Буч, Дж. Рамбо – СПб.: Питер , 2002. – 496 с .
20. IEEE 1362 - Concept of Operations Document
21. IEEE 1233 - Guide for Developing System Requirements Specifications.
22. IEEE Standard 830-1998, «IEEE Recommended Practice for Software
Requirements Specifications»

79. Программное обеспечение информационных (автоматизированных) систем

Программное обеспечение автоматизированной системы (АС)
(Automated system software) по ГОСТ 34.003-90 – это совокупность
программ на носителях данных и программных документов,
предназначенная для отладки, функционирования и проверки
работоспособности АС [из п. 2.7 ГОСТ 34.003-90]
Программное обеспечение автоматизированной системы включает
в свой состав общее программное обеспечение (ОПО) и
специальное программное обеспечение (СПО).
Общее программное обеспечение (ОПО) автоматизированной
системы (АС) (Automated system heave-duty software) по ГОСТ
34.003-90 –это часть программного обеспечения АС,
представляющая собой совокупность программных средств (ГОСТ
28806-90), разработанных вне связи с созданием данной АС.
Ю.Г.Карпов
Семинар "Наука и общество"
79

80. Программное обеспечение информационных (автоматизированных) систем

Примечание - Обычно ОПО АС представляет собой совокупность
программ общего назначения, предназначенных для организации
вычислительного процесса и решения часто встречающихся задач
обработки информации [из п. 6.2 ГОСТ 34.003-90]
Общее программное обеспечение, как правило, представлено
операционной системой с набором стандартных пользовательских
приложений (прикладных программ), именуемых аксессуарами и
обладающих некоторым минимимальным набором функций для
решения часто встречающихся задач обработки информации,
например, для работы с текстом.
Ю.Г.Карпов
Семинар "Наука и общество"
80

81. Программное обеспечение информационных (автоматизированных) систем

Специальное программное обеспечение (СПО) автоматизированной
системы (АС) (Automated system application software) по ГОСТ
34.003-90 – это часть программного обеспечения АС,
представляющая собой совокупность программ, разработанных при
создании данной АС [из п. 6.3 ГОСТ 34.003-90]
Специальное программное обеспечение, как правило, работает
«поверх» общего ПО (т.е. под управлением операционной
системы) и обычно является клиентской частью,
взаимодействующей с серверной частью, установленной на
удаленном (или не очень) сервере, по локальной или глобальной
компьютерной сети. Если серверная часть СПО представляет собой
веб-приложение, то в качестве клиентской части применяется
браузер, входящий в состав общего программного обеспечения
(«тонкий» клиент).
Ю.Г.Карпов
Семинар "Наука и общество"
81
English     Русский Правила