Similar presentations:
Технологии массивно-параллельных вычислений (Тонких Артём Петрович)
1. Технологии массивно-параллельных вычислений
Технологиимассивнопараллельных
вычислений
Тонких Артём Петрович
2. Подать заявку
https://umnik.fasie.ru/samara3. Хакатон «Лидеры цифровой трансформации»
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) – NvidiaGPU – массивно-параллельные
вычислительные устройства с
быстродействием выше 1 ТФлопа
Voodoo (компания 3DFx), Riva TNT,
GeForce256 (register combiner) [iPhone,
iPod Touch], GeForce2 (специальный
ассемблер)
15.
GeForce2 (специальный ассемблер) ->GeForce FX (значительное повышение
быстродействия)
16. SIMD-процессоры
Single Instruction Multiple Data17. Программа (шейдер) на языке GLSL
Высокоуровневые языки для GPU – Cg,GLSL, HLSL
18. GPGPU
GPGPU (General-Purpose computing onGraphics Processing Units)
Ускорение в десятки раз, режим реального
времени
Для доступа к графическому процессору
используется API (OpenGL или Direct3D)
Текстура – вводные данные, рендеринг –
вычисления на GPU, текстура – выходные
данные отправляемые в память процессора
19.
GFLOPs20. Ограничения 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. Архитектура и модель программирования
27
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. Технологическая схема разработки, изготовления и поставки ИТ СУ
6263. Требования являются базой для
Планирования.Управления рисками – возможность оценки влияния.
Приемочного тестирования – удовлетворения нечетко
выраженных пожеланий может быть ограничено факторами,
лежащими в неконтролируемой области.
Согласования, поиска компромиссов – интересы сторон
могут вступать в конфликт между собой.
Управление изменениями – оценка влияния и стоимости
предлагаемых изменений.
63
64. Дискретность требований
Природа требований позволяет их группировать, это даетвозможность использовать общие шаблоны для работы с
требованиями (общие наборы атрибутов, правила отношений и
связей и пр.).
Группировка требований по уровням и типам способствует
улучшению формулировок самих требований, заставляя
разработчиков требований формировать дискретные требования
и следовать правилам.
64
65. Способы организации представления и группировки требований
6566. Группировка требований по 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. Компоненты информационных систем
7778. ГОСТ 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
9091. ГОСТ 19.201-78
Единая система программной документации (ЕСПД) – этокомплекс государственных стандартов, устанавливающих
взаимоувязанные правила разработки, оформления и обращения
программ (или ПО) и программной документации.
Согласно ГОСТ 19.201-78 Техническое задание. Требования к
содержанию и оформлению техническое задание включает
следующие разделы:
1. Введение.
2. Основания для разработки.
3. Назначение разработки.
4. Требования к программе или программному изделию.
5. Требования к программной документации.
6. Технико-экономические показатели.
7. Стадии и этапы разработки.
8. Порядок контроля и приемки.
9. Приложения.
Этот стандарт относится к разработке именно ПО.
91
92. Требования к программе или программному изделию
Требования к функциональным характеристикам;Требования к надежности;
Требования к условиям эксплуатации;
Требования к составу и параметрам технических средств;
Требования к информационной и программной совместимости;
Требования к маркировке и упаковке;
Требования к транспортированию и хранению;
Специальные требования.
92
93. Вопросы разработки задания на КР в соответствии с ГОСТ
9394. Примеры формулировок задания на КР
Требования к структуре и функционированию системыАИС должна иметь трехуровневую архитектуру. АИС должна быть
централизованной.
В АИС предлагается выделить следующие функциональные подсистемы:
подсистема сбора, обработки и загрузки данных;
подсистема хранения данных;
подсистема формирования и визуализации отчетности.
Информационный обмен между подсистемами должен осуществляться через
единое информационное пространство и посредством использования
стандартизированных протоколов и форматов обмена данными.
Все компоненты подсистем АСУ должны функционировать в пределах единого
логического пространства, обеспеченного интегрированными средствами
серверов данных и серверов приложений.
В АИС должна обеспечиваться работа в двух режимах:
сетевой режим взаимодействия;
автономный;
Работа пользователей в режиме 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. Определение понятия требования
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.»
108
109. Технологическая схема разработки, изготовления и поставки ИТ СУ
109110. Требования являются базой для
Планирования.Управления рисками – возможность оценки влияния.
Приемочного тестирования – удовлетворения нечетко
выраженных пожеланий может быть ограничено факторами,
лежащими в неконтролируемой области.
Согласования, поиска компромиссов – интересы сторон
могут вступать в конфликт между собой.
Управление изменениями – оценка влияния и стоимости
предлагаемых изменений.
110
111. Дискретность требований
Природа требований позволяет их группировать, это даетвозможность использовать общие шаблоны для работы с
требованиями (общие наборы атрибутов, правила отношений и
связей и пр.).
Группировка требований по уровням и типам способствует
улучшению формулировок самих требований, заставляя
разработчиков требований формировать дискретные требования
и следовать правилам.
111
112. Способы организации представления и группировки требований
112113. Группировка требований по SWEBOK
Требования к продукту и процессу – параметры относящиесяк продукту или процессу его создания.
Функциональные и нефункциональные требования:
Функциональные описывают функции, которые выполняет ПО;
Нефункциональные требования накладывают определенные ограничения.
Независимые свойства – требования, которые не могут быть
адресованы к одной из компонент системы, в проявляются при
взаимодействии.
Количественные требования – требования, поддающиеся
количественному определению/измерению, например, система
должна обеспечить пропускную способность «столько-то
запросов в секунду».
Системные и программные требования – относятся к
системе в целом или к программной составляющей.
113
114. Группировка требований по К. Вигерсу
Функциональныетребования
Бизнес-требования
Пользовательские
требования
Нефункциональные
требования
Бизнес-требования
Бизнес-правила
Пользовательские
требования
Атрибуты качества
Функциональные
требования
Системные
требования
Функциональные
требования
Внешние интерфейсы
Ограничения
114
115. Уровни требований по К. Вигерсу
Бизнес-требования определяют высокоуровневые целиорганизации или заказчика (потребителя) разрабатываемого ПО.
Постановка задачи и описание назначения ПО. (Ответ на вопрос
ПОЧЕМУ?)
Пользовательские требования описывают цели\задачи
пользователей системы, которые должны выполняться
пользователями при помощи создаваемой системы, варианты
использования. (Ответ на вопросы КТО? и ЧТО?)
Функциональные требования определяют функциональность
(поведение) программной системы, которая должна быть
создана разработчиками для предоставления возможности
выполнения пользователями своих обязанностей в рамках
бизнес-требований и в контексте пользовательских требований
(Ответ на вопрос ЧТО?)
115
116. Другие типы требований по К. Вигерсу
Нефункциональные требования включают эксплуатационныехарактеристики и описание атрибутов качества.
o
o
o
o
Бизнес-правила включают корпоративную политику, законодательные акты,
стандарты, учетную практику и алгоритмы вычислений.
Атрибуты качества –дополнительные характеристики продукта, важные для
пользователей и/или разработчиков. Эти характеристики включают практичность,
целостность, эффективность, устойчивость.
Ограничения – условия, ограничивающие выбор возможных решений по
реализации отдельных требований или их выбора (платформы, протоколы и т.д.).
Внешние интерфейсы – требования, которые содержат конкретизацию аспектов
взаимодействия разрабатываемого ПО с другими системами (операционной
средой, аппаратным оборудованием, пользователями и др.)
Системные требования классифицируются как составная часть
группы функциональных требований и описывают высокоуровневые
требования к ПО, при этом система может состоять из программной
и аппаратной частей, персонала.
116
117. Требования в RUP
Методология RUP выделяет отдельную дисциплинуRequirements, которая объединяет работы, роли и артефакты
(документы, модели и пр.), связанные с созданием требований к
ПО и управления ими.
Тонких Артём Петрович представил обобщенную
классификационную схему – структуру требований, которая
отражает рекомендованный RUP подход
117
118. Схема Тонких Артёма Петровича. Уровни требований
Потребность (Need) – отражениепроблемы бизнеса, персоналии или
процесса, которое должно быть
соотнесено с использованием или
приобретением новой системы.
Характеристика продукта (Feature) –
множество логически связанных
функциональных требований, которые
обеспечивают возможности
пользователя и удовлетворяют бизнесцелям.
Требования к ПО (Software
Requirements)
118
119. Детализация Software Requirements
Функциональные требования выражают поведение системы –входы, выходы и функции, которые система предоставляет
пользователю, без учета физических ограничений.
Нефункциональные требования
Usability (Удобство использования);
Reliability (Надежность);
Performance (Производительность);
Supprtability (Поддержка).
Ограничения проектирования – ограничения, относящиеся к
дизайну или процессу создания системы, которые не влияют на
внешнее поведение, но должны быть учтены для соответствия
различного вида обязательствам
119
120. Модель FURPS+
Требования могут быть категоризированы по модели FURPS+,которая описывает основные категории требований с
подкатегориями:
Functionality (Функциональность);
Usability (Удобство использования);
Reliability (Надежность);
Performance (Производительность);
Supprtability (Поддержка).
«+» в FURPS+ говорит о включении дополнительных категорий:
desing constraints (ограничения проектирования);
Implementation requirements (требования к реализации);
Interface requirements (требования к интерфейсам);
fhysical requirements (требования к физическим характеристикам)
120
121. Представление требований в IEEE 830-1998
Стандарт IEEE 830-1998 описывает рекомендуемые способыспецификации требований к программному обеспечению.
Результатом процесса спецификации требований является
однозначно интерпретируемый и целостный документспецификация требований.
Стандарт на документальное оформление требований задает
определенные группировки одинаковых по своей сути
требований (по их назначению), фиксируя классификацию
требований.
121
122. Спецификация программных требований в IEEE 830 (SRS)
Функциональность. Ответ на вопрос «ЧТО должно делать ПО?»Внешние интерфейсы. Как ПО должно взаимодействовать с
людьми, другими ПО или аппаратурой.
Производительность. С какой скоростью должны производиться
те или иные операции, каково время отклика и т.п.
Атрибуты. Определяют точность, переносимость,
модифицируемость и т.п.
Ограничения проектирования. Использование определенных
языков программирования, баз данных, форматов обмена и т.п.
122
123. Документирование требований в соответствии с ГОСТ
ГОСТ 34.601-90. Информационная технология. Комплексстандартов на автоматизированные системы.
Автоматизированные системы. Стадии создания.
ГОСТ 34.602-89. Информационная технология. Комплекс
стандартов на автоматизированные системы. Техническое
задание на создание автоматизированной системы
ГОСТ 19.201-78. Единая система программной
документации. Техническое задание. Требования к
содержанию и оформлению.
123
124. Компоненты информационных систем
124125. ГОСТ 34.602-89
ГОСТ 34.602-89. Информационнаятехнология. Комплекс стандартов на
автоматизированные системы.
Техническое задание на создание
автоматизированной системы
126. ГОСТ 34.602-89
Регламентирует структуру ТЗ на создание именно СИСТЕМЫ, вкоторую входят программное и аппаратное обеспечение, люди,
которые работают с ПО, и автоматизируемые процессы.
Согласно ГОСТ 34.602-89 Техническое задание на создание АС
техническое задание включает следующие разделы:
При разработке ТЗ для государственных проектов Заказчики, как
правило, требуют соблюдение именно этого стандарта.
126
127. Требования к системе в целом
Требования к структуре и функционированию системы:перечень подсистем, их назначение и основные характеристики, требования к
числу уровней иерархии и степени централизации системы;
требования к способам и средствам связи для информационного обмена между
компонентами системы;
требования к характеристикам взаимосвязей создаваемой системы со смежными
системами, требования к ее совместимости, в том числе указания о способах обмена
информацией (автоматически, пересылкой документов, по телефону и т. п.);
требования к режимам функционирования системы;
требования по диагностированию системы;
перспективы развития, модернизации системы.
Требования к численности и квалификации персонала системы
и режиму его работы.
127
128. Требования к системе в целом
Требования к надежности:состав и количественные значения показателей надежности для системы в
целом или ее подсистем;
перечень аварийных ситуаций, по которым должны быть регламентированы
требования к надежности, и значения соответствующих показателей;
требования к надежности технических средств и программного
обеспечения.
Требования к эргономике и технической эстетике, задающие
необходимое качество взаимодействия человека с машиной и комфортность
условий работы персонала.
Требования к эксплуатации, техническому обслуживанию,
ремонту и хранению компонентов системы:
условия и регламент (режим) эксплуатации, которые должны обеспечивать
использование технических средств (ТС) системы с заданными
техническими показателями, в том числе виды и периодичность
обслуживания ТС системы или допустимость работы без обслуживания;
требования к регламенту обслуживания.
128
129. Требования к системе в целом
Требования к безопасности; защите информации отнесанкционированного доступа; защите от влияния
внешних воздействий.
Требования к сохранности информации при авариях:
перечень событий: аварий, отказов технических средств (в том числе потеря питания) и т. п., при которых должна быть обеспечена сохранность
информации в системе.
Требования к патентной чистоте:
указывают перечень стран, в отношении которых должна быть обеспечена
патентная чистота системы и ее частей.
129
130. 2.6. Раздел "Требования к системе" состоит из следующих подразделов:
2.6. Раздел "Требования к системе"состоит из следующих подразделов:
1) требования к системе в целом;
2) требования к функциям (задачам),
выполняемым системой;
3) требования к видам обеспечения.
131. Требования к системе в целом
Требования к стандартизации и унификации:показатели, устанавливающие требуемую степень использования
стандартных, унифицированных методов реализации функций (задач)
системы, поставляемых программных средств;
типовых математических методов и моделей;
типовых проектных решений, унифицированных форм управленческих
документов, общесоюзных классификаторов технико-экономической
информации и классификаторов других категорий в соответствии с областью
их применения,
требования к использованию типовых автоматизированных рабочих мест,
компонентов и комплексов;
параметры, характеризующие степень соответствия системы ее назначению.
131
132. Требования ГОСТ к функциям (задачам)
функциональные требования в привязке к подсистемам иочередям автоматизации;
временной регламент реализации функциональных требований;
требования к качеству реализации каждого из функциональных
требований (форма представления выходной информации,
характеристики необходимой точности и времени выполнения,
требования одновременности выполнения группы функций,
достоверности выдачи результатов);
перечень и критерии отказов для каждого функционального
требования, по которому были заданы требования по надежности.
132
133. Требования к видам обеспечения
Математическое обеспечение:требования к составу, области применения (ограничения) и способам,
использования в системе математических методов и моделей, типовых
алгоритмов и алгоритмов, подлежащих разработке.
Информационное обеспечение:
к составу, структуре и способам организации данных в системе;
к информационному обмену между компонентами системы;
к информационной совместимости со смежными системами;
по применению систем управления базами данных;
к структуре процесса сбора, обработки, передачи данных в системе и
представлению данных;
к защите данных от разрушений при авариях и сбоях в электропитании
системы;
к контролю, хранению, обновлению и восстановлению данных;
133
134. Требования к видам обеспечения
Лингвистическое обеспечение:требования к применению в системе языков программирования высокого
уровня, языков взаимодействия пользователей и технических средств
системы;
требования к кодированию и декодированию данных, к языкам ввода-вывода
данных, языкам манипулирования данными, средствам описания предметной
области (объекта автоматизации), к способам организации диалога.
Программное обеспечение:
требования к независимости программных средств от используемых средств
вычислительной техники и операционной среды;
требования к качеству программных средств, а также к способам его
обеспечения и контроля.
134
135. Требования к видам обеспечения
Техническое обеспечение:к видам технических средств, в том числе к видам комплексов технических
средств, программно-технических комплексов и других комплектующих
изделий, допустимых к использованию в системе;
к функциональным, конструктивным и эксплуатационным характеристикам
средств технического обеспечения системы.
Метрологическое обеспечение:
требования к метрологической совместимости технических средств системы;
перечень управляющих и вычислительных каналов системы, для которых
необходимо оценивать точностные характеристики;
требования к метрологическому обеспечению технических и программных
средств, входящих в состав измерительных каналов системы, средств,
встроенного контроля, метрологической пригодности измерительных каналов
и средств измерений, используемых при наладке и испытаниях системы.
135
136. Требования к видам обеспечения
Организационное обеспечение:к структуре и функциям подразделений, участвующих в функционировании
системы или обеспечивающих эксплуатацию;
к организации функционирования системы и порядку взаимодействия
персонала АС и персонала объекта автоматизации;
к защите от ошибочных действий персонала системы.
Методическое обеспечение:
требования к составу нормативно-технической документации системы
(перечень применяемых при ее функционировании стандартов, нормативов,
методик и т. п.).
136
137. Соотнесение типов требований по Вигерсу и ГОСТ 34.602
137138. ГОСТ 19.201-78
Единая система программной документации (ЕСПД) – этокомплекс государственных стандартов, устанавливающих
взаимоувязанные правила разработки, оформления и обращения
программ (или ПО) и программной документации.
Согласно ГОСТ 19.201-78 Техническое задание. Требования к
содержанию и оформлению техническое задание включает
следующие разделы:
1. Введение.
2. Основания для разработки.
3. Назначение разработки.
4. Требования к программе или программному изделию.
5. Требования к программной документации.
6. Технико-экономические показатели.
7. Стадии и этапы разработки.
8. Порядок контроля и приемки.
9. Приложения.
Этот стандарт относится к разработке именно ПО.
138
139. Требования к программе или программному изделию
Требования к функциональным характеристикам;Требования к надежности;
Требования к условиям эксплуатации;
Требования к составу и параметрам технических средств;
Требования к информационной и программной совместимости;
Требования к маркировке и упаковке;
Требования к транспортированию и хранению;
Специальные требования.
139
140. Вопросы разработки задания на КР в соответствии с ГОСТ
140141. Примеры формулировок задания на КР
Требования к структуре и функционированию системыАИС должна иметь трехуровневую архитектуру. АИС должна быть
централизованной.
В АИС предлагается выделить следующие функциональные подсистемы:
подсистема сбора, обработки и загрузки данных;
подсистема хранения данных;
подсистема формирования и визуализации отчетности.
Информационный обмен между подсистемами должен осуществляться через
единое информационное пространство и посредством использования
стандартизированных протоколов и форматов обмена данными.
Все компоненты подсистем АСУ должны функционировать в пределах единого
логического пространства, обеспеченного интегрированными средствами
серверов данных и серверов приложений.
В АИС должна обеспечиваться работа в двух режимах:
сетевой режим взаимодействия;
автономный;
Работа пользователей в режиме 24 часа в день, 7 дней в неделю (24х7).
141
142. Примеры формулировок задания на КР
Требования к численности и квалификации персоналасистемы
Для эксплуатации АИС определены следующие роли: администратор,
пользователь, техник.
Требования к надежности
Время восстановления работоспособности прикладного ПО АИС при любых
сбоях и отказах не должно превышать одного рабочего дня, исключая случаи
неисправности серверного оборудования.
В АИС должна быть обеспечена возможность восстановления данных с
внешнего накопителя после восстановления активного накопителя.
Должно осуществляться разграничение прав доступа к системе.
Должен вестись журнал событий системы.
142
143. Примеры формулировок задания на КР
Требования к эргономике и технической эстетикеВ части внешнего оформления:
реализация графического многооконного режима;
настраиваемость графических элементов интерфейса, в том числе цветового
оформления, в пределах возможностей операционной системы;
интерфейсы подсистем должен быть типизированы;
в шапке отчетов должен использоваться логотип Заказчика.
В части диалога с пользователем:
интерфейс должен обеспечивать удобную навигацию в диалоге с пользователем;
наличие контекстно-зависимой помощи.
для наиболее частых операций должны быть предусмотрены «горячие» клавиши;
при возникновении ошибок в работе подсистемы на экран монитора должно
выводиться сообщение с наименованием ошибки и с рекомендациями по её
устранению на русском языке.
В части операций ввода-вывода данных:
ввод-вывод данных системы должен выполняться в интерактивном режиме
143
144. Примеры формулировок задания на КР
Требования к защите информации от несанкционированногодоступа
Аутентификация пользователей;
Проверка полномочий пользователя при работе с системой;
Разграничение прав доступа пользователей на уровне задач и информационных
массивов, должно строиться по принципу «что не разрешено, то запрещено»;
Ограничение на доступ пользователей к выполнению функций системы
(заполнение документов, получение отчетов и др.);
Протоколирование действий пользователей, связанных с информационной
безопасностью (вход в систему, выход из нее, открытие и редактирование
документов и пр.).
144
145. Примеры формулировок задания на КР
Требования по сохранности информации при аварияхПрограммное обеспечение АИС должно восстанавливать свое функционирование
при корректном перезапуске аппаратных средств;
В АИС должно быть обеспечено резервное копирование данных.
Выход из строя жестких дисков дискового массива не должен сказываться на
работоспособности подсистемы хранения данных.
Для восстановления данных и программного обеспечения из резервной копии
должны использоваться средства резервного копирования и архивирования.
Должна быть предусмотрена возможность восстановления данных за день сбоя с
помощью их повторного ввода или импорта (для данных из внешних систем,
получаемых автоматически).
145
146. Примеры формулировок задания на КР
Требования по стандартизации и унификацииРазработка системы должна осуществляться с использованием стандартных
методологий функционального моделирования: IDEF0, DFD и
информационного моделирования IE и IDEF1Х в рамках рекомендаций по
стандартизации Р50.1.028-2001 «Информационные технологии поддержки
жизненного цикла продукции. Методология функционального моделирования».
Моделирование должно выполняться в рамках стандартов, поддерживаемых
программными средствами моделирования ERWin 4.х и BPWin 4.х.
Для работы с БД должен использоваться язык запросов SQL в рамках
стандарта ANSI SQL-92.
Для взаимодействия пользователей и прикладным ПО должно осуществляться
посредством визуального графического интерфейса (GUI)
Все экранные формы графического интерфейса должны быть выполнены в
едином графическом дизайне, с одинаковым расположением основных
элементов управления и навигации.
146
147. Примеры формулировок задания на КР
Требования к функциям системы и ее подсистемПодсистема сбора, обработки и загрузки данных должна осуществлять:
Ввод и редактирование информации с помощью экранных форм;
Обработку и преобразование извлечённых данных;
Поиск данных по наименованию документа, времени создания.
Подсистема хранения данных должна осуществлять:
Хранение оперативных данных системы, данных для формирования аналитических
отчетов, документов, справочников.
Система должна обеспечивать периодическое резервное копирование и сохранение
данных на дополнительных носителях информации.
Подсистема формирования и визуализации отчетности
Система должна иметь возможность вызова списка отчетов или конкретного
аналитического отчета с заранее установленными параметрами.
Время формирования отчета на Web-интерфейсе не должно превышать 30 секунд.
Размеры элементов интерактивных аналитических отчетов должны адаптироваться
к разрешению экрана устройства, на котором просматривается отчет.
147
148. Примеры формулировок задания на КР
Требования к информационному обеспечениюУровень хранения данных в АИС должен быть построен на основе современных
реляционных или объектно-реляционных СУБД.
Для обеспечения целостности данных должны использоваться встроенные
механизмы СУБД.
Технические средства, обеспечивающие хранение информации, должны
использовать современные технологии, позволяющие обеспечить повышенную
надежность хранения данных и оперативную замену оборудования
(распределенная избыточная запись/считывание данных; зеркалирование;
независимые дисковые массивы; кластеризация);
Данные должны быть защищены от разрушений при авариях и сбоях в
электропитании системы путем создания резервных копий.
148
149. Примеры формулировок задания на КР
Требования к лингвистическому обеспечениюВсе обозначения, названия элементов управления АИС, тексты должны быть
изложены на русском языке без применения терминов, непонятных
пользователю.
Разработка системы должна вестись на языке программирования высокого
уровня PHP.
Требования к программному обеспечению
Системные программные средства свободно распространяемая операционная
система FreeBSD или Linux.
Программное обеспечение, распространяемое свободно:
База данных (СУБД) PostgreSQL или MySQL;
Apache HTTP Server версии 2.2.16 (или выше);
PHP версии 5.1 (или выше);
Система управления контентом с открытым кодом.
149
150. Примеры формулировок задания на КР
Требования к техническому обеспечениюТип процессора: процессор типа Pentium IV (или эквивалент);
Базовая тактовая частота процессора: минимум: 1,6 ГГц;
Оперативная память: минимум: 256 МБ;
Дисковое пространство: минимум: 5 ГБ;
Операционная система: Windows XP или более поздних версий.
Браузеры, один из: Internet Explorer версии 9 или более поздней, Mozilla Firefox
версии 5 или более поздней, Google Chrome версии 13 или более поздней
Внутренняя сеть и средства коммуникации должны обладать как минимум
следующими характеристиками:
скорость передачи данных подключаемого канала к публичным сетям не менее 2
Мб/с;
оборудование узла должно оставаться работоспособным при кратковременных
отключениях электропитания (на время не менее 15 минут);
оборудование узла должно обеспечивать коммутируемое подключение всех
устройств со скоростью до 100 Мбит/с.
150
151. Список используемых источников
Тонких Артём Петрович. Анализ требований кавтоматизированным информационным системам
[Электронный ресурс] : [учебное пособие] / Тонких Артём
Петрович. - 2-е изд., испр. - Москва : ИНТУИТ, 2016. - 192 с. : ил.
- (Основы информационных технологий).
Тонких Артём Петрович. Введение в программную инженерию и
управление жизненным циклом ПО. Программная инженерия.
Программные требования [Электронный ресурс] : Русский
перевод SWEBOK 2004 с замечаниями и комментариями /
Тонких Артём Петрович. – Электрон. дан. – Москва, 20042005.
Тонких Артём Петрович. Разработка требований к
программному обеспечению. Пер. с англ. – Москва :
Издательско-торговый дом «Русская Редакция», 2004. – 576с. :
ил.
151