Технологии массивно-параллельных вычислений

Лекция №1. Существующие многоядерные системы. Эволюция GPU. GPGPU

Унифицированный язык моделирования UML Диаграммы деятельности Расчет выражения a/b + c*d

Время работы свертки в зависимости от числа потоков в блоке

Курсовая работа: общие положения, требования

Вопросы разработки задания на КР в соответствии с ГОСТ

Технологическая схема разработки, изготовления и поставки ИТ СУ

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

Схема Тонких Артёма Петровича. Уровни требований

Представление требований в IEEE 830-1998

Спецификация программных требований в IEEE 830 (SRS)

Документирование требований в соответствии с ГОСТ

2.6. Раздел "Требования к системе" состоит из следующих подразделов:

Соотнесение типов требований по Вигерсу и ГОСТ 34.602

Требования к программе или программному изделию

Участники проекта реинжиниринга бизнес-процессов Вопросы разработки задания на КР в соответствии с ГОСТ

Пример несовпадения временной последовательности работ и направления движения документа

7.77M

Категория:

Информатика

Похожие презентации:

Классификация требований к программному обеспечению Вопросы разработки задания на ВКР в соответствии с ГОСТ

Проектирование информационных систем

Техническое задание на создание автоматизированной системы

Техническое задание: основные разделы согласно стандартам. ГОСТ 34.602-89

Разработка ТЗ. Лекция 3

Разработка ТЗ

Проектирование АСОИУ (лекция 5)

Проектирование информационных систем. Разработка технического задания. Лекция 2

Технология программирования основные понятия и подходы

Автоматизированная система проектирования работ (САПР)

Технологии массивно-параллельных вычислений (Тонких Артём Петрович)

1. Технологии массивно-параллельных вычислений

Технологии
массивнопараллельных
вычислений
Тонких Артём Петрович

2. Подать заявку

https://umnik.fasie.ru/samara

3. Хакатон «Лидеры цифровой трансформации»

https://hack2020.innoagency.ru/

4. Лекция №1. Существующие многоядерные системы. Эволюция GPU. GPGPU

5. Операция в секунду (Flops)

Быстродействие - Floating points
операций в секунду (flops)
Пиковое быстродействие –
максимально возможное число
операций с вещественными
величинами (floating points) без
обращений к памяти и других операций.

6. Динамика роста тактовых частот

7. Блок-схемы

8. Унифицированный язык моделирования UML Диаграммы деятельности Расчет выражения a/b + c*d

9. Схемы процессоров

10. Архитектура SMP

11. BlueGene/L

12. Тороидальный куб

13. Архитектура GPU

14. Эволюция GPU

GPU (Graphics Processing Units) – Nvidia
GPU – массивно-параллельные
вычислительные устройства с
быстродействием выше 1 ТФлопа
Voodoo (компания 3DFx), Riva TNT,
GeForce256 (register combiner) [iPhone,
iPod Touch], GeForce2 (специальный
ассемблер)

15.

GeForce2 (специальный ассемблер) ->
GeForce FX (значительное повышение
быстродействия)

16. SIMD-процессоры

Single Instruction Multiple Data

17. Программа (шейдер) на языке GLSL

Высокоуровневые языки для GPU – Cg,
GLSL, HLSL

18. GPGPU

GPGPU (General-Purpose computing on
Graphics Processing Units)
Ускорение в десятки раз, режим реального
времени
Для доступа к графическому процессору
используется API (OpenGL или Direct3D)
Текстура – вводные данные, рендеринг –
вычисления на GPU, текстура – выходные
данные отправляемые в память процессора

19.

GFLOPs

20. Ограничения API

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

21. Ограничения API

Разработка приложения на двух языках
программирования на С++ и
шейдерном языке
Решение: CUDA, OpenCL, DX11
Compute Shaders.

22. Вычисления на GPU

GPGPU - General-purpose graphics processing units.
Идея: Использовать GPU для общих вычислений, а не
только для компьютерной графики.
GPU vs. CPU
Nvidia Titan V
CPU Intel Core i7 Coffee lake
Число ядер
5120
4-6
Производительность,
GFLOPS
≈12000
≈1000 (теоретически)
≈100 (практически)
Архитектура (грубо)
SIMD*
SISD*
Сложность
программирования
(субъективно)
Сложно
Просто
*SIMD - single instruction, multiple data
SISD - single instruction, single data
2
2

23. Области применения

• Машинное обучение
• Компьютерная графика
• Математические пакеты
• Физические движки
• Обработка видео
• Математическое моделирование
Еще примеры:
https://www.nvidia.com/en-us/data-center/gpu-acceleratedapplications/catalog/
2
3

24. CUDA

CUDA (Compute Unified Device Architecture) архитектура параллельных вычислений от компании
NVIDIA.
•Для разработки используются языки
программирования CUDA C/C++, Fortran и др.
•Поддерживается только видеокартами Nvidia
•Популярна
• Много библиотек
• Много документации
• Удобная отладка
Идея:
Host – CPU, на котором выполняется основная программа.
Device – GPU на котором будут запускаться параллельные
вычисления.
2
4

25. OpenCL

OpenCL(Open Computing Language) – стандарт для
написания программ, связанных с параллельными
вычислениями
•Для разработки используются язык программирования,
который базируется на стандарте C99 (С++14 для OpenCL >=
2.1)
•Поддерживается большинством современных CPU/GPU
• NVIdia не торопится с поддержкой актуальных версий OpenCL
2
5

26. Пример: сложение двух массивов

https://github.com/whitespacer/kt_cuda/blob/master/vector_add
/kernel.cu
2
6

27. Архитектура и модель программирования

2
7

28. Work items (Потоки)

Для выполнения параллельных вычислений запускается ядро
вычислений (kernel) состоящее из множества потоков (threads)
•Все потоки выполняют один и тот же код
•Каждый поток имеет уникальный идентификатор
0
1
2
3
4
5
6
7
8
…
KernelFunction()
Проблема: Как организовать взаимодействие потоков?
•Взаимодействие потоков внутри одного массива потоков не
масштабируемо
Решение: Разобьём массив потоков на блоки.
•Взаимодействие между небольшими группами потоков
2
масштабируемо
8

29. Взаимодействие потоков в блоке

• Разделяемая память – быстрая память доступная
всем потокам одного блока
• Команда барьера
syncthread
s()
• Любой поток блока дойдя до барьера будет ждать
пока остальные потоки не дойдут до этого же барьера
global void foo()
{
int id = threadIdx.x;
load_data_to_shared_memory(id);
syncthreads();
use_data_from_shared_memory();
global void foo()
{
if (condition)
syncthreads();
syncthreads();
}
else
}
Листинг 1. Пример использования
команды syncthreads
Листинг 2. Классическая ошибка в
использовании
syncthreads
29

30. Вычислительная сетка (1)

Вычислительная сетка (grid) – многомерный массив
потоков разбитый на блоки (blocks)
•Все блоки в сетке имеют одинаковые размеры
• В одном блоке не более 1024 потоков (для CUDA Compute Capability
3.0+)
•Взаимодействие потоков происходит внутри блоков
• Синхронизация
• Совместный доступ к памяти
•Разные блоки могут быть запущены на разных устройствах
30

31. Вычислительная сетка (2)

• Размерность сетки ограничена (3 для существующих видеокарт)
• Размер сетки ограничен
• Для каждого потока доступны
• Индекс блока в сетке: blockIdx
• Индекс потока в блоке: threadIdx
• Размер блока: blockDim
• Количество блоков в сетке: gridDim
Количество и размер блоков задают конфигурацию ядра:
gpu_kernel<<gridSize, blockSize>>(…);
После запуска: gridDim == gridSize, blockDim == blockSize
31

32. Пример: свертка

https://github.com/whitespacer/kt_cuda/blob/master/convolution_2d
/kernel.cu
blur фильтр

33. Архитектура (Fermi)

• 16 потоковых мультипроцессоров
(Streaming Multiprocessor, SM)
Особенности SM:
• Содержит 32 CUDA ядер, 64 KB
разделяемой памяти / L1 кэша, 16
Load/Store units (LD/ST), 4 Special Function
Units (SFUs)
• Выполняет вычислительные блоки,
блок целиком выполняется на одном SM,
одновременно не более 8 блоков и не
более 1536 потоков
• При выполнение блок разбивается на
warp-ы (warp – 32 подряд идущих потока)
14

34. Планировщик warp-ов (Fermi)

• Каждый SM содержит два планировщика warp-ов
• Инструкция warp-а назначается группе из 16 ядер, 16 LD/ST
юнитов или 4 SFUs (в зависимости от типа инструкции)
• Разделение на warp-ы позволяет скрывать задержки
Пока один warp работает с памятью, будут выполнятся инструкции других
warp-ов
Планировщик warp-ов
34

35. Архитектура Nvidia Kepler

Появился DP Unit - ядро
для работы с 64 битными
числами с плавающей
запятой.
35

36. Время работы свертки в зависимости от числа потоков в блоке

Тестовый ПК:
GPU: NVidia GeForce 960 GTX
CPU: AMD FX-4300 3.8 GHz
Время работы ядра вычислений на GPU в зависимости от числа
потоков в блоке
180
160
Замеры производились на full hd
изображение.
Размер ядра свертки – 11x11.
140
120
мс
100
Время работы на CPU: ~2000 мс
Время работы на GPU: ~35 мс
80
60
40
Программа на GPU в 57 раз
быстрее!
20
0
4
16
64
256
729
841
1024

37. Иерархия памяти

38. Типы памяти

• Локальная и регистровая
int i; threadIdx; float3 arr[4];
• Разделяемая
shared
float s[128]; extern
shared float e[];
• Глобальная
global
void kernel( float * g )
• Константная
constant
float c[256];
• Текстурная и Surface
texture<float, cudaTextureType2D, cudaReadModeElementType> texRef;
surface<void, cudaSurfaceType2D> surfRef;
19

39. Сравнение типов памяти

Тип
Размер
Регистровая
Ограниченный размер ~1 такт
Применение
Пропускная
способность
Очень высокая (~ 2-
(оценка сверху: 32768 * 4 /
1536 ~= 85 байт на поток)
3 регистра за такт = 812B / такт)
Задержка
Разделяемая Ограниченный размер ~5 тактов
(48KB на мультипроцессор)
Высокая (~ 4B /
такт)
Кэш,
контроллируемый
программистом
Глобальная
Большой (гигабайты)
~500 тактов
Низкая (~ 4B / 10
тактов)
Константная
Ограниченный размер ~5 тактов (при
Высокая (~ 4B /
такт, при попадании в
кэш)
Broadcast
данных
Средняя
Пространственн
ые запросы (2D,
3D выборки)
Текстурная
(64KB, кэш
мультипроцессора
– 8KB)
попадании в кэш)
Большой (гигабайты)
Средняя,
константная
Такт = 1 / частота процессора
20

40. Ускорение свертки. Время работы

Входные данные
•Размер блока 16 на 16
•Full HD картинка, размер ядра свертки 11 на 11
Время работы:
Время работы с глобальной памятью: 35 мсек
Перенос ядра свертки в константную память: 26 мсек Использование
разделяемой памяти: 10 мсек
Итого:
Использование правильных типов памяти ускорило программу в 3.5
раза. GPU версия быстрее CPU версии в 173 раза.

41. Как узнать больше?

Список онлайн курсов:
•https://developer.nvidia.com/educators/existing-courses
Книжки:
•https://developer.nvidia.com/cuda-books-archive
С++ API wrapper:
•https://github.com/eyalroz/cuda-api-wrappers

42. Курсовая работа: общие положения, требования

43. Основные понятия

Положение о курсовой работе
(курсовом проекте) от 27 июня 2019 г.

44. Сайт ТГУ

45. Роль положения

Требования по выбору темы
Требования к порядку выполнения
Требования к структуре КР
Организация защиты

46. Курсовая работа -

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

47. Цель выполнения курсовой работы -

Цель выполнения курсовой
работы Углубление знаний, овладение умениями
и навыками поиска, анализа и
систематизации источников и
литературы, изложение логически
последовательного содержания вопросов
с использованием научного стиля,
выполнение стандартных расчетов по
заданным алгоритмам

48. Задачи:

Углубление уровня знаний, умений,
навыков
Формирование навыков самостоятельной
работы.
Формирование умения работать с
нормативно-правовыми актами
Формирование умений применение
теоретических знаний на практике
Формирование культуры написания ВКР

49. Курсовые работы и антиплагиат:

Порядок обеспечения самостоятельности
выполнения письменных работ в ТГУ

50. Выбор темы КР:

Закрепление студентов за темами КР
осуществляется руководителем и
согласовывается со студентами
Темы курсовых утверждаются
распоряжением директора института.

51. Руководство включает в себя:

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

52. 53. Задание КР 1:

54. Задание КР 2:

55. Задание КР 3:

56. Требования к характеру КР

57. Требования к объему

Максимальный объем ограничен
положением и составляет 40 страниц
Минимальный объем устанавливает
руководитель КР – 32 страниц.
Объем считается от “Содержание”
(страница №2) до конца “Список
используемой литературы и источников”

58. Требования к структуре

59. Организация защиты

На последнем учебном занятии
До защиты – антиплагиат

60. Вопросы разработки задания на КР в соответствии с ГОСТ

61. Определение понятия требования

ISO/IEC/IEEE 29148:2011 Программная и системная инженерия. Процессы жизненного
цикла. Разработка требований
«Требование – утверждение, которое идентифицирует эксплуатационные,
функциональные параметры, характеристики и ограничения
проектирования продукта или процесса, а также является однозначным,
проверяемым и измеримым»
Rational Unified Process (RUP), Version 2003.06.13
«Условие или возможность, которой должна удовлетворять система»
IEEE Std 610.12, «IEEE Standard Glossary of Software Engineering Terminology»
«Условия или возможности, необходимые пользователю для решения
проблем или достижения целей;
Условия или возможности, которыми должна обладать система или
системные компоненты, чтобы выполнить контракт или удовлетворять
стандартам, спецификациям или другим формальным документам;
Документированное представление условий или возможностей для
пунктов 1 и 2.»
61

62. Технологическая схема разработки, изготовления и поставки ИТ СУ

63. Требования являются базой для

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

64. Дискретность требований

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

65. Способы организации представления и группировки требований

66. Группировка требований по SWEBOK

Требования к продукту и процессу – параметры относящиеся
к продукту или процессу его создания.
Функциональные и нефункциональные требования:
Функциональные описывают функции, которые выполняет ПО;
Нефункциональные требования накладывают определенные ограничения.
Независимые свойства – требования, которые не могут быть
адресованы к одной из компонент системы, в проявляются при
взаимодействии.
Количественные требования – требования, поддающиеся
количественному определению/измерению, например, система
должна обеспечить пропускную способность «столько-то
запросов в секунду».
Системные и программные требования – относятся к
системе в целом или к программной составляющей.
66

67. Группировка требований по К. Вигерсу

Функциональные
требования
Бизнес-требования
Пользовательские
требования
Нефункциональные
требования
Бизнес-требования
Бизнес-правила
Пользовательские
требования
Атрибуты качества
Функциональные
требования
Системные
требования
Функциональные
требования
Внешние интерфейсы
Ограничения
67

68. Уровни требований по К. Вигерсу

Бизнес-требования определяют высокоуровневые цели
организации или заказчика (потребителя) разрабатываемого ПО.
Постановка задачи и описание назначения ПО. (Ответ на вопрос
ПОЧЕМУ?)
Пользовательские требования описывают цели\задачи
пользователей системы, которые должны выполняться
пользователями при помощи создаваемой системы, варианты
использования. (Ответ на вопросы КТО? и ЧТО?)
Функциональные требования определяют функциональность
(поведение) программной системы, которая должна быть
создана разработчиками для предоставления возможности
выполнения пользователями своих обязанностей в рамках
бизнес-требований и в контексте пользовательских требований
(Ответ на вопрос ЧТО?)
68

69. Другие типы требований по К. Вигерсу

Нефункциональные требования включают эксплуатационные
характеристики и описание атрибутов качества.
o
o
o
o
Бизнес-правила включают корпоративную политику, законодательные акты,
стандарты, учетную практику и алгоритмы вычислений.
Атрибуты качества –дополнительные характеристики продукта, важные для
пользователей и/или разработчиков. Эти характеристики включают практичность,
целостность, эффективность, устойчивость.
Ограничения – условия, ограничивающие выбор возможных решений по
реализации отдельных требований или их выбора (платформы, протоколы и т.д.).
Внешние интерфейсы – требования, которые содержат конкретизацию аспектов
взаимодействия разрабатываемого ПО с другими системами (операционной
средой, аппаратным оборудованием, пользователями и др.)
Системные требования классифицируются как составная часть
группы функциональных требований и описывают высокоуровневые
требования к ПО, при этом система может состоять из программной
и аппаратной частей, персонала.
69

70. Требования в RUP

Методология RUP выделяет отдельную дисциплину
Requirements, которая объединяет работы, роли и артефакты
(документы, модели и пр.), связанные с созданием требований к
ПО и управления ими.
Тонких Артём Петрович представил обобщенную
классификационную схему – структуру требований, которая
отражает рекомендованный RUP подход
70

71. Схема Тонких Артёма Петровича. Уровни требований

Потребность (Need) – отражение
проблемы бизнеса, персоналии или
процесса, которое должно быть
соотнесено с использованием или
приобретением новой системы.
Характеристика продукта (Feature) –
множество логически связанных
функциональных требований, которые
обеспечивают возможности
пользователя и удовлетворяют бизнесцелям.
Требования к ПО (Software
Requirements)
71

72. Детализация Software Requirements

Функциональные требования выражают поведение системы –
входы, выходы и функции, которые система предоставляет
пользователю, без учета физических ограничений.
Нефункциональные требования
Usability (Удобство использования);
Reliability (Надежность);
Performance (Производительность);
Supprtability (Поддержка).
Ограничения проектирования – ограничения, относящиеся к
дизайну или процессу создания системы, которые не влияют на
внешнее поведение, но должны быть учтены для соответствия
различного вида обязательствам
72

73. Модель FURPS+

Требования могут быть категоризированы по модели FURPS+,
которая описывает основные категории требований с
подкатегориями:
Functionality (Функциональность);
Usability (Удобство использования);
Reliability (Надежность);
Performance (Производительность);
Supprtability (Поддержка).
«+» в FURPS+ говорит о включении дополнительных категорий:
desing constraints (ограничения проектирования);
Implementation requirements (требования к реализации);
Interface requirements (требования к интерфейсам);
fhysical requirements (требования к физическим характеристикам)
73

74. Представление требований в IEEE 830-1998

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

75. Спецификация программных требований в IEEE 830 (SRS)

Функциональность. Ответ на вопрос «ЧТО должно делать ПО?»
Внешние интерфейсы. Как ПО должно взаимодействовать с
людьми, другими ПО или аппаратурой.
Производительность. С какой скоростью должны производиться
те или иные операции, каково время отклика и т.п.
Атрибуты. Определяют точность, переносимость,
модифицируемость и т.п.
Ограничения проектирования. Использование определенных
языков программирования, баз данных, форматов обмена и т.п.
75

76. Документирование требований в соответствии с ГОСТ

ГОСТ 34.601-90. Информационная технология. Комплекс
стандартов на автоматизированные системы.
Автоматизированные системы. Стадии создания.
ГОСТ 34.602-89. Информационная технология. Комплекс
стандартов на автоматизированные системы. Техническое
задание на создание автоматизированной системы
ГОСТ 19.201-78. Единая система программной
документации. Техническое задание. Требования к
содержанию и оформлению.
76

77. Компоненты информационных систем

78. ГОСТ 34.602-89

ГОСТ 34.602-89. Информационная
технология. Комплекс стандартов на
автоматизированные системы.
Техническое задание на создание
автоматизированной системы

79. ГОСТ 34.602-89

Регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в
которую входят программное и аппаратное обеспечение, люди,
которые работают с ПО, и автоматизируемые процессы.
Согласно ГОСТ 34.602-89 Техническое задание на создание АС
техническое задание включает следующие разделы:
При разработке ТЗ для государственных проектов Заказчики, как
правило, требуют соблюдение именно этого стандарта.
79

80. Требования к системе в целом

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

81. Требования к системе в целом

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

82. Требования к системе в целом

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

83. 2.6. Раздел "Требования к системе" состоит из следующих подразделов:

2.6. Раздел "Требования к системе"
состоит из следующих подразделов:
1) требования к системе в целом;
2) требования к функциям (задачам),
выполняемым системой;
3) требования к видам обеспечения.

84. Требования к системе в целом

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

85. Требования ГОСТ к функциям (задачам)

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

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

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

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

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

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

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

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

Организационное обеспечение:
к структуре и функциям подразделений, участвующих в функционировании
системы или обеспечивающих эксплуатацию;
к организации функционирования системы и порядку взаимодействия
персонала АС и персонала объекта автоматизации;
к защите от ошибочных действий персонала системы.
Методическое обеспечение:
требования к составу нормативно-технической документации системы
(перечень применяемых при ее функционировании стандартов, нормативов,
методик и т. п.).
89

90. Соотнесение типов требований по Вигерсу и ГОСТ 34.602

91. ГОСТ 19.201-78

Единая система программной документации (ЕСПД) – это
комплекс государственных стандартов, устанавливающих
взаимоувязанные правила разработки, оформления и обращения
программ (или ПО) и программной документации.
Согласно ГОСТ 19.201-78 Техническое задание. Требования к
содержанию и оформлению техническое задание включает
следующие разделы:
1. Введение.
2. Основания для разработки.
3. Назначение разработки.
4. Требования к программе или программному изделию.
5. Требования к программной документации.
6. Технико-экономические показатели.
7. Стадии и этапы разработки.
8. Порядок контроля и приемки.
9. Приложения.
Этот стандарт относится к разработке именно ПО.
91

92. Требования к программе или программному изделию

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

93. Вопросы разработки задания на КР в соответствии с ГОСТ

94. Примеры формулировок задания на КР

Требования к структуре и функционированию системы
АИС должна иметь трехуровневую архитектуру. АИС должна быть
централизованной.
В АИС предлагается выделить следующие функциональные подсистемы:
подсистема сбора, обработки и загрузки данных;
подсистема хранения данных;
подсистема формирования и визуализации отчетности.
Информационный обмен между подсистемами должен осуществляться через
единое информационное пространство и посредством использования
стандартизированных протоколов и форматов обмена данными.
Все компоненты подсистем АСУ должны функционировать в пределах единого
логического пространства, обеспеченного интегрированными средствами
серверов данных и серверов приложений.
В АИС должна обеспечиваться работа в двух режимах:
сетевой режим взаимодействия;
автономный;
Работа пользователей в режиме 24 часа в день, 7 дней в неделю (24х7).
94

95. Примеры формулировок задания на КР

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

96. Примеры формулировок задания на КР

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

97. Примеры формулировок задания на КР

Требования к защите информации от несанкционированного
доступа
Аутентификация пользователей;
Проверка полномочий пользователя при работе с системой;
Разграничение прав доступа пользователей на уровне задач и информационных
массивов, должно строиться по принципу «что не разрешено, то запрещено»;
Ограничение на доступ пользователей к выполнению функций системы
(заполнение документов, получение отчетов и др.);
Протоколирование действий пользователей, связанных с информационной
безопасностью (вход в систему, выход из нее, открытие и редактирование
документов и пр.).
97

98. Примеры формулировок задания на КР

Требования по сохранности информации при авариях
Программное обеспечение АИС должно восстанавливать свое функционирование
при корректном перезапуске аппаратных средств;
В АИС должно быть обеспечено резервное копирование данных.
Выход из строя жестких дисков дискового массива не должен сказываться на
работоспособности подсистемы хранения данных.
Для восстановления данных и программного обеспечения из резервной копии
должны использоваться средства резервного копирования и архивирования.
Должна быть предусмотрена возможность восстановления данных за день сбоя с
помощью их повторного ввода или импорта (для данных из внешних систем,
получаемых автоматически).
98

99. Примеры формулировок задания на КР

Требования по стандартизации и унификации
Разработка системы должна осуществляться с использованием стандартных
методологий функционального моделирования: IDEF0, DFD и
информационного моделирования IE и IDEF1Х в рамках рекомендаций по
стандартизации Р50.1.028-2001 «Информационные технологии поддержки
жизненного цикла продукции. Методология функционального моделирования».
Моделирование должно выполняться в рамках стандартов, поддерживаемых
программными средствами моделирования ERWin 4.х и BPWin 4.х.
Для работы с БД должен использоваться язык запросов SQL в рамках
стандарта ANSI SQL-92.
Для взаимодействия пользователей и прикладным ПО должно осуществляться
посредством визуального графического интерфейса (GUI)
Все экранные формы графического интерфейса должны быть выполнены в
едином графическом дизайне, с одинаковым расположением основных
элементов управления и навигации.
99

100. Примеры формулировок задания на КР

Требования к функциям системы и ее подсистем
Подсистема сбора, обработки и загрузки данных должна осуществлять:
Ввод и редактирование информации с помощью экранных форм;
Обработку и преобразование извлечённых данных;
Поиск данных по наименованию документа, времени создания.
Подсистема хранения данных должна осуществлять:
Хранение оперативных данных системы, данных для формирования аналитических
отчетов, документов, справочников.
Система должна обеспечивать периодическое резервное копирование и сохранение
данных на дополнительных носителях информации.
Подсистема формирования и визуализации отчетности
Система должна иметь возможность вызова списка отчетов или конкретного
аналитического отчета с заранее установленными параметрами.
Время формирования отчета на Web-интерфейсе не должно превышать 30 секунд.
Размеры элементов интерактивных аналитических отчетов должны адаптироваться
к разрешению экрана устройства, на котором просматривается отчет.
100

101. Примеры формулировок задания на КР

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

102. Примеры формулировок задания на КР

Требования к лингвистическому обеспечению
Все обозначения, названия элементов управления АИС, тексты должны быть
изложены на русском языке без применения терминов, непонятных
пользователю.
Разработка системы должна вестись на языке программирования высокого
уровня PHP.
Требования к программному обеспечению
Системные программные средства свободно распространяемая операционная
система FreeBSD или Linux.
Программное обеспечение, распространяемое свободно:
База данных (СУБД) PostgreSQL или MySQL;
Apache HTTP Server версии 2.2.16 (или выше);
PHP версии 5.1 (или выше);
Система управления контентом с открытым кодом.
102

103. Примеры формулировок задания на КР

Требования к техническому обеспечению
Тип процессора: процессор типа Pentium IV (или эквивалент);
Базовая тактовая частота процессора: минимум: 1,6 ГГц;
Оперативная память: минимум: 256 МБ;
Дисковое пространство: минимум: 5 ГБ;
Операционная система: Windows XP или более поздних версий.
Браузеры, один из: Internet Explorer версии 9 или более поздней, Mozilla Firefox
версии 5 или более поздней, Google Chrome версии 13 или более поздней
Внутренняя сеть и средства коммуникации должны обладать как минимум
следующими характеристиками:
скорость передачи данных подключаемого канала к публичным сетям не менее 2
Мб/с;
оборудование узла должно оставаться работоспособным при кратковременных
отключениях электропитания (на время не менее 15 минут);
оборудование узла должно обеспечивать коммутируемое подключение всех
устройств со скоростью до 100 Мбит/с.
103

104. Список используемых источников

Тонких Артём Петрович. Анализ требований к
автоматизированным информационным системам
[Электронный ресурс] : [учебное пособие] / Артём Петрович
Тонких. - 2-е изд., испр. - Москва : ИНТУИТ, 2016. - 192 с. : ил. (Основы информационных технологий).
Тонких Артём Петрович. Введение в программную инженерию и
управление жизненным циклом ПО. Программная инженерия.
Программные требования [Электронный ресурс] : Русский
перевод SWEBOK 2004 с замечаниями и комментариями /
Артём Петрович Тонких. – Электрон. дан. – Москва, 20042005.
Тонких Артём Петрович. Разработка требований к
программному обеспечению. Пер. с англ. – Москва :
Издательско-торговый дом «Русская Редакция», 2004. – 576с. :
ил.
104

105. Ход защиты

Доклад 5 минут
Затем комиссия и студенты задают
вопросы
Письменная работа сдается в папке со
скоросшивателем
Оценки ставятся на портал в день
защиты КР

106. 107. Участники проекта реинжиниринга бизнес-процессов Вопросы разработки задания на КР в соответствии с ГОСТ

108. Определение понятия требования

109. Технологическая схема разработки, изготовления и поставки ИТ СУ

109

110. Требования являются базой для

111. Дискретность требований

112. Способы организации представления и группировки требований

112

113. Группировка требований по SWEBOK

114. Группировка требований по К. Вигерсу

115. Уровни требований по К. Вигерсу

116. Другие типы требований по К. Вигерсу

117. Требования в RUP

118. Схема Тонких Артёма Петровича. Уровни требований

119. Детализация Software Requirements

120. Модель FURPS+

121. Представление требований в IEEE 830-1998

122. Спецификация программных требований в IEEE 830 (SRS)

123. Документирование требований в соответствии с ГОСТ

124. Компоненты информационных систем

124

125. ГОСТ 34.602-89

126. ГОСТ 34.602-89

127. Требования к системе в целом

128. Требования к системе в целом

129. Требования к системе в целом

130. 2.6. Раздел "Требования к системе" состоит из следующих подразделов:

131. Требования к системе в целом

132. Требования ГОСТ к функциям (задачам)

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

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

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

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

137. Соотнесение типов требований по Вигерсу и ГОСТ 34.602

137

138. ГОСТ 19.201-78

139. Требования к программе или программному изделию

140. Вопросы разработки задания на КР в соответствии с ГОСТ

140

141. Примеры формулировок задания на КР

142. Примеры формулировок задания на КР

143. Примеры формулировок задания на КР

144. Примеры формулировок задания на КР

145. Примеры формулировок задания на КР

146. Примеры формулировок задания на КР

147. Примеры формулировок задания на КР

148. Примеры формулировок задания на КР

149. Примеры формулировок задания на КР

150. Примеры формулировок задания на КР

151. Список используемых источников

Тонких Артём Петрович. Анализ требований к
автоматизированным информационным системам
[Электронный ресурс] : [учебное пособие] / Тонких Артём
Петрович. - 2-е изд., испр. - Москва : ИНТУИТ, 2016. - 192 с. : ил.
- (Основы информационных технологий).
Тонких Артём Петрович. Введение в программную инженерию и
управление жизненным циклом ПО. Программная инженерия.
Программные требования [Электронный ресурс] : Русский
перевод SWEBOK 2004 с замечаниями и комментариями /
Тонких Артём Петрович. – Электрон. дан. – Москва, 20042005.
Тонких Артём Петрович. Разработка требований к
программному обеспечению. Пер. с англ. – Москва :
Издательско-торговый дом «Русская Редакция», 2004. – 576с. :
ил.
151

152. Диаграмма потоков данных - DFD

152

153. Пример несовпадения временной последовательности работ и направления движения документа

153

154. Пример бизнес-процессов верхнего уровня

154

155. Дерево бизнес-процессов

155

156. Сеть бизнес-процессов

156

157. Диаграмма потоков работ - WFD

157

English Русский Правила