7.22M

Реинжиниринг бизнес-процессов (Тонких Артём Петрович)

1.

Этапы реинжиниринга
бизнес-процессов
Функциональное моделирование
МЕТОДИКИ:
SADT - IDEF0 , DFD, IDEF3.
________________________
Тонких Артём Петрович
1

2.

Процесс
это любая деятельность или комплекс
деятельности, в которой используются
ресурсы для преобразования входов в
выходы.
2

4.

Превращение входа в выход, а затем
в ресурс процесса
4

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

7.

ПРИЧИНЫ
МОДЕЛИРОВАНИЯ
ускорение разработки систем
удешевление разработки систем
компьютерная поддержка разработки
программного обеспечения
подготовка управления системами
обоснование совершенствования
функционирования (реинжиниринга)
систем
реконструкция устройства систем
другое
7

8.

Десять наиболее часто решаемых вопросов с
использованием технологий описания и
оптимизации бизнес-процессов
Прозрачность, контролируемость и управляемость бизнеса.
Снижение издержек, уменьшение времени процессов, поддержание
роста.
Построение эффективной организационной структуры.
Реструктуризация.
Проектирование новых бизнес-направлений и бизнес-процессов.
Тиражирование бизнеса.
Автоматизация.
Правильный подбор персонала. Мотивация. Уменьшение персонала
зависимости.
Регламентация. Высвобождение времени руководителей. повышение
эффективности работы персонала.
Финансы (себестоимость объектов учета, управленческий учет,
бюджетирование).
Повышение рыночной стоимости, инвестиционной привлекательности,
имиджа предприятия. Выход на новые рынки. Внедрение ISO-9000.
8

9.

Моделирование
«Человечество в своей деятельности постоянно создает и
использует модели окружающего мира…; человечество
накопило богатый опыт моделирования различных объектов
и процессов»
Моделирование - это метод познания,
состоящий в создании и исследовании
моделей.
Иногда «Модели позволяют представить в наглядной форме
объекты и процессы недоступные для непосредственного
восприятия модели часто используются в процессе обучения».
9

10.

СОБСТВЕННО МОДЕЛИРОВАНИЕ
Система В является моделью
системы А, если
система В достоверно
отвечает на вопросы о
функционировании
системы А
10

11.

ШИРОТА РАСПРОСТРАНЕНИЯ МОДЕЛИРОВАНИЯ
Вся наша частная,
профессиональная и общественная
жизнь незримо связана с
непрекращающимся,
происходящим вокруг нас и с
нашим участием, разнообразным
моделированием.
11

12.

С ростом технического прогресса адекватное
описание систем становится все более
актуальной проблемой.
12

13.

SADT - Structured Analysis and Design Technique
SADT - методология структурного анализа
и проектирования, разработанная
специально для того, чтобы облегчить
описание и понимание искусственных
систем, попадающих в разряд средней
сложности. SADT была создана и
опробована на практике в период с 1969
по 1973 г.
13

14.

С 1973 г. сфера ее использования существенно
расширяется для решения задач, связанных с
большими системами, такими, как проектирование
телефонных коммуникаций реального времени,
автоматизация производства (САМ), создание
программного обеспечения для командных и
управляющих систем, поддержка боеготовности. Она с
успехом применялась для описания большого
количества сложных искусственных систем из широкого
спектра областей (банковское дело, очистка нефти,
планирование промышленного производства, системы
наведения ракет, организация материальнотехнического снабжения, методология планирования,
технология программирования). Причина такого успеха
заключается в том, что SADT является полной
методологией для создания описания систем и
процессов, основанной на концепциях
системного моделирования.
14

15.

Модель отвечает на вопросы
SADT-модель дает полное, точное и
адекватное описание системы, имеющее
конкретное назначение – ЦЕЛЬ МОДЕЛИ
Целью модели является получение ответов на
некоторую совокупность вопросов. Эти вопросы
неявно присутствуют (подразумеваются) в процессе
анализа и, следовательно, они руководят созданием
модели и направляют его. Это означает, что сама
модель должна будет дать ответы на эти вопросы с
заданной степенью точности. Если модель отвечает
не на все вопросы или ее ответы недостаточно
точны, то мы говорим, что модель не достигла своей
цели.
15

16.

Модель имеет единственный субъект
Модель является некоторым толкованием
системы. Поэтому субъектом
моделирования служит сама система.
Однако моделируемая система никогда не
существует изолированно: она всегда
связана с окружающей средой. Причем
зачастую трудно сказать, где кончается
система и начинается среда. По этой
причине в методологии SADT
подчеркивается необходимость точного
определения границ системы.
16

17.

У модели может быть только одна точка
зрения
С определением модели тесно связана
позиция, с которой наблюдается система и
создается ее модель. Поскольку качество
описания системы резко снижается, если
оно не сфокусировано ни на чем, SADT
требует, чтобы модель рассматривалась все
время с одной и той же позиции. Эта
позиция называется точкой зрения
данной модели.
17

18.

Функциональные модели
Функциональные модели - являются, как
правило,
основой анализа функционирующих систем
(модели AS IS),
Основой для модернизации или создания
новых систем (модели TO BE).
наиболее
распространена
методика
функционального моделирования IDEF0,
наиболее развитой системой компьютерной
поддержки функционального моделирования
является AllFusion Process Modeler (компания
СА),
18

19.

Стадии моделирования
1.
2.
3.
4.
5.
модель изучаемого, подвергающегося анализу объекта
классифицируется как AS IS модель – модель как есть,
модель
предстоящей
нам
деятельности
классифицируется как TO BE модель – модель как
должно быть,
чаще всего разрабатываются обе эти модели в
последовательности AS IS, TO BE,
при реализации TO BE разрабатывается, также, модель
перехода из AS IS состояния в состояние TO BE
(«технологическая - креативная» модель AS IS/TO BE),
как разработке AS IS так и разработке TO BE
предшествует разработка функциональной модели
среды, в которой функционирует моделируемый
объект (ФМ «PROJECT»).
19

20.

Наиболее распространённые
МЕТОДЫ ФУНКЦИОНАЛЬНОГО
МОДЕЛИРОВАНИЯ СИСТЕМ
Структурное функциональное
моделирование
IDEF0
DFD
Потоковое функциональное
моделирование
IDEF3
20

21.

Инструментальные средства
структурного проектирования
21

22.

Функциональный блок
IDEF0-диаграммы
22

23.

Функциональный блок
IDEF0-диаграммы
23

24.

Пример взаимодействия объектов и
функций
24

25.

26.

27.

Диаграмма A-0
«Продажа заказного продукта»
27

28.

29.

Иллюстрация терминов ФСА
29

30.

Определение стоимости
30

31.

Родительская IDEF0-диаграмма
31

32.

IDEF-0 диаграмма второго уровня
32

33.

Вопросы разработки задания на КР
в соответствии с ГОСТ
Тонких Артём Петрович

34.

Определение понятия требования
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.»
34

35.

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

36.

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

37.

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

38.

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

39.

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

40.

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

41.

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

42.

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

43.

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

44.

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

45.

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

46.

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

47.

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

48.

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

49.

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

50.

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

51.

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

52.

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

53.

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

54.

ТРЕБОВАНИЯ К
СИСТЕМЕ В
ЦЕЛОМ

55.

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

56.

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

57.

Требования к системе в
целом
требования к структуре и функционированию
системы

58.

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

59.

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

60.

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

61.

1) состав и количественные значения
показателей надёжности для системы
в целом или ее подсистем;
2) перечень аварийных ситуаций, по
которым должны быть
регламентированы требования к
надежности, и значения
соответствующих показателей;
3) требования к надёжности технических
средств и программного обеспечения;
4) требования к методам оценки и
контроля показателей надёжности на
разных стадиях создания системы в
соответствии с действующими
нормативно-техническими
документами

62.

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

63.

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

64.

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

65.

Требования к функциям
(задачам), выполняемым
системой

66.

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

67.

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

68.

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

69.

Виды обеспечения
Математическое
Информационное
Лингвистическое
Программное
Техническое
Метрологическое
Организационное
Методическое
Иное

70.

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

71.

Информационное
обеспечение
Требования
1)
к составу, структуре и способам организации данных в системе;
2)
к информационному обмену между компонентами системы;
3)
к информационной совместимости со смежными системами;
4)
по использованию общесоюзных и зарегистрированных республиканских, отраслевых
классификаторов, унифицированных документов и классификаторов, действующих на
данном предприятии;
5)
по применению систем управления базами данных;
6)
к структуре процесса сбора, обработки, передачи данных в системе и представлению
данных;
7)
к защите данных от разрушений при авариях и сбоях в электропитании системы;
8)
к контролю, хранению, обновлению и восстановлению данных;
9)
к процедуре придания юридической силы документам, продуцируемым техническими
средствами АС (в соответствии с ГОСТ 6.10.4).

72.

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

73.

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

74.

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

75.

Программное обеспечение.
Требования
1)к независимости программных
средств от используемых СВТ и
операционной среды;
2)к качеству программных средств,
а также к способам его
обеспечения и контроля;
ТЕСТИРОВАНИЕ
3)по необходимости согласования
вновь разрабатываемых
программных средств с фондом
алгоритмов и программ.

76.

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

77.

Организационное
обеспечение.
Требования
1) к структуре и функциям
подразделений, участвующих в
функционировании системы или
обеспечивающих эксплуатацию;
2)к организации функционирования
системы и порядку
взаимодействия персонала АС и
персонала объекта
автоматизации;
3)к защите от ошибочных действий
персонала системы

78.

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

79.

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

80.

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

81.

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

82.

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

83.

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

84.

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

85.

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

86.

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

87.

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

88.

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

89.

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

90.

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

91.

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

92.

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

93.

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

94.

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

95.

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

96.

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

97.

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

98.

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

99.

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

100.

Методы проведения реинжиниринга
бизнес-процессов
Разработка диаграммы вариантов
использования бизнес-процессов

101.

Основные определения
ЖЦ – совокупность этапов, которые проходит система в своем
развитии.
ЖЦ АС – совокупность процессов создания и изменения
состояния АС [ГОСТ 34, 1990].
Модель ЖЦ – структура, состоящая из процессов, работ и
задач, включающих в себя разработку, эксплуатацию и
сопровождение ПП [ГОСТ 12207, 1999].
101

102.

Основные определения
ISO/IEC 12207 (ISO - International Organization of Standardization,
IEC - International Electrotechnical Commission).
Он определяет структуру ЖЦ.
Структура ЖЦ ПО по стандарту ISO/IEC 12207:
-
основные процессы ПО (приобретение, поставка,
разработка, эксплуатация, сопровождение);
-
вспомогательные процессы: документирование, управление
конфигурацией, обеспечение качества, верификация,
аттестация, оценка, аудит, решение проблем;
-
организационные процессы (управление проектами,
создание инфраструктуры проекта, определение, оценка и
улучшение самого ЖЦ, обучение).
102

103.

Основные процессы
Разработка:
оформление документации,
подготовка материалов.
Разработка ПО:
анализ,
проектирование
реализация.
Эксплуатация:
конфигурирование БД и рабочих мест,
обеспечение документацией,
проведение обучения и т.д.;
непосредственно эксплуатация: локализация проблем,
модификация ПО, подготовка предложений.
103

104.

Стадии ЖЦ ИС
Планирование и анализ требований (предпроектная
стадия).
Проектирование (логическое проектирование).
Реализация проекта (физическое проектирование,
программирование).
Внедрение (тестирование, опытная эксплуатация).
Эксплуатация системы (сопровождение,
модернизация).
104

105.

Фазы ЖЦ
концепция (инициация, идентификация,
отбор);
определение (анализ);
выполнение (практическая реализация или
внедрение, производство и развертывание,
проектирование или конструирование,
сдача в эксплуатацию, инсталляция,
тестирование);
закрытие (завершение, включая
оценивание после завершения).
105

106.

Каскадная модель проекта
106

107.

Принципы каскадной модели
последовательное выполнение стадий;
технические задания являются основой;
каждая стадия документируется;
в качестве критерия качества выбирается точность
выполнения ТЗ;
переход от одной фазы к другой предполагает
корректность результата предыдущей фазы.
107

108.

Преимущества каскадной модели
планирование сроков и затрат,
наличие временного графика;
на каждом этапе формируется набор документации,
отвечающий критериям полноты и
согласованности;
каждая стадия может выполняться отдельной
командой.
108

109.

Недостатки каскадной модели
- в некоторых случаях составить ТЗ не удаётся;
- запаздывание с получением результатов;
- результаты доступны заказчику только в конце;
- предыдущий этап имеет влияние на следующие;
- высокие требования к точности формулировки
исходных требований;
- низкая адаптивность проекта.
109

110.

Итеративная модель разработки
110

111.

Спиральная модель разработки
111

112.

Rapid Application Development
1. Бизнес-моделирование.
2. Моделирование данных.
3. Моделирование обработки.
4. Генерация приложения.
5. Тестирование и объединение.
112

113.

Rational Unified Process (RUP)
1. Inception.
2. Elaboration.
3. Construction.
4. Transition.
113

114.

Rational Unified Process (RUP)
1. Business Modeling.
2. Requirements (use cases).
3. Analysis and Design.
4. Implementation.
5. Test.
6. Deployment.
7. Configuration and Change Management.
8. Project Management
9. Environment.
114

115.

Основные техники в RUP
- project vision
- управление по плану
- снижение рисков
- экономическое обоснование
- выявление требований (use cases)
- формирование базовой архитектуры
- использование компонентной архитектуры
- прототипирование, инкрементная разработка, тест
- регулярные оценки текущего состояния
- управление изменениями
- создание работоспособного продукта
- нацеленность на качество
- адаптация процесса под нужды проекта
115

116.

Unified Modeling Language (UML)
- принцип абстрагирования
- принцип многомодельности
- принцип иерархического построения
моделей сложных систем
116

117.

Unified Modeling Language (UML)
- use case
- class
- behavior
- statechart
- activity
- interaction
- sequence
- collaboration
- implementation
- component
- deployment
117

118.

Unified Modeling Language (UML)
118

119.

Unified Modeling Language (UML)
119

120.

Unified Modeling Language (UML)
- OOA (Object-Oriented Analysis)
- OOD (Object-Oriented Design)
- Booch’93 – Гради Буч
- OMT (Object Modeling Technique) – Джеймс
Румбах
- OOSE (Object-Oriented Software Engineering) –
Айвар Джекобсон
- консорциум OMG
- CASE-средство Rational Rose
120