Презентация_лекций_ПИС_2_часть_Полная

1.

УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ К
ИНФОРМАЦИОННЫМ СИСТЕМАМ
Презентации курса лекций по дисциплине «Проектирование информационных систем»
направление 230700.62, профиль «Прикладная информатика в экономике» курс 3.
Автор Деваев В.М., доцент каф. ДПУ

2.

НИР И НИОКР
НИР – первая стадия НИОКР, где реально начинает создаваться
научно-техническая база будущих инноваций. Как уже указывалось,
основой НИР являются знания, накопленные за прошлые периоды
развития. В то же время по окончании стадии НИР должна быть
сформирована концепция конкретного продукта, технологии, бизнеспроцессов. Таким образом, разработчик НИР, определяя основные
направления исследований, решает главную стратегическую задачу
сферы
НИОКР – что будет делать фирма в дальнейшем.

3.

ИСХОДЫ ПРИКЛАДНОЙ НИР
- отрицательные результаты (например, вывод – создать новый
образец техники не представляется возможным на основе
исследованных научных направлений);
- промежуточные результаты (необходимо продолжить
исследования);
- положительные результаты (на основе полученных в НИР
результатов можно приступить к выполнению ОКР, в этом случае в
состав итогового отчета по НИР включается проект технического
задания на ОКР).

4.

ВИДЫ НАУЧНО-ИССЛЕДОВАТЕЛЬСКИХ
РАБОТ
Виды исследований
Фундаментальные
НИР
Поисковые
НИР
Прикладные
НИР
Результаты исследований
Расширение теоретических знаний. Получение
новых научных данных о процессах, явлениях,
закономерностях, существующих в исследуемой
области.
Увеличение объема знаний для более глубокого
понимания изучаемого предмета. Разработка
прогнозов развития науки и техники; открытие
путей применения новых явлений и
закономерностей
Разрешение конкретных научных проблем для
создания новых изделий. Получение
рекомендаций, инструкций, расчетнотехнических материалов, методик. Определение
возможности проведения ОКР по тематике НИР

5.

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

6.

РАЗРАБОТКА ТЗ НА НИР
Разработка ТЗ на НИР
научное прогнозирование
Анализ результатов фундаментальных и
поисковых исследований
Изучение патентной документации
Учет требований заказчиков

7.

ВЫБОР НАПРАВЛЕНИЯ ИССЛЕДОВАНИЯ
Сбор и изучение научно-технической информации
Составление аналитического обзора
Проведение патентных исследований
Формулирование возможных направлений решения задач, поставленных в ТЗ НИР, и их
сравнительная оценка
Выбор и обоснование принятого направления исследований и способов решения задач
Сопоставление ожидаемых показателей новой продукции после внедрения результатов НИР с
существующими показателями изделий-аналогов
Оценка ориентировочной экономической эффективности новой продукции
Разработка общей методики проведения исследований
Составление промежуточного отчета

8.

ТЕОРЕТИЧЕСКИЕ И ЭКСПЕРИМЕНТАЛЬНЫЕ
ИССЛЕДОВАНИЯ
Разработка рабочих гипотез, построение моделей объекта исследований,
обоснование допущений
Выявление необходимости проведения экспериментов для подтверждения
отдельных
положений теоретических исследований или для получения конкретных
значений параметров, необходимых для проведения расчетов
Разработка методики экспериментальных исследований, подготовка моделей
(макетов, экспериментальных образцов), а также испытательного
оборудования
Проведение экспериментов, обработка полученных данных
Cопоставление результатов эксперимента с теоретическими исследованиями
Корректировка теоретических моделей объекта
Проведение при необходимости дополнительных экспериментов
Проведение технико-экономических исследований
Cоставление промежуточного отчета

9.

ОБОБЩЕНИЕ И ОЦЕНКА РЕЗУЛЬТАТОВ
ИССЛЕДОВАНИЙ
Обобщение результатов предыдущих этапов работ
Оценка полноты решения задач
разработка рекомендаций по дальнейшим исследованиям и
проведению окр
разработка проекта тз на окр
составление итогового отчета
приемка нир комиссией

10.

ИНФОРМАЦИЯ НА СТАДИИ РАЗРАБОТКИ
ТЕХНИЧЕСКОГО ЗАДАНИЯ НА НИР
- объект исследования;
- описание требований к объекту исследования;
- перечень функций объекта исследования общетехнического характера;
- перечень физических и других эффектов, закономерностей и теорий, которые могут быть основой
принципа действия изделия;
- технические решения (в прогнозных исследованиях);
- сведения о научно-техническом потенциале исполнителя НИР;
- сведения о производственных ресурсах (применительно к объекту исследований);
- сведения о материальных ресурсах;
- маркетинговые сведения;
- данные об ожидаемом экономическом эффекте.
Дополнительно используется следующая информация:
- методы решения отдельных задач и обработки информации;
- общетехнические требования (стандарты, ограничения вредных влияний, требования по
надежности, ремонтопригодности, эргономике и так далее);
- проектируемые сроки обновления продукции;
- предложения лицензий и "ноу-хау" по объекту исследований

11.

НА ПОСЛЕДУЮЩИХ ЭТАПАХ НИР В
КАЧЕСТВЕ БАЗЫ В ОСНОВНОМ
ИСПОЛЬЗУЕТСЯ ПЕРЕЧИСЛЕННАЯ ВЫШЕ
ИНФОРМАЦИЯ И
- сведения о новых принципах действия,
новых гипотезах, теориях, результатах НИР;
- данные экономической оценки,
моделирования основных процессов,
оптимизации многокритериальных задач,
макетирования, типовых расчетов,
ограничений;
- требования к информации, вводимой в
информационные системы и т.д.

12.

ОСНОВНЫЕ ЗАДАЧИ И ЭТАПЫ ОКР
1) разработка ТЗ на ОКР;
2) техническое предложение;
3) эскизное проектирование;
4) техническое проектирование;
5) разработка рабочей документации для
изготовления и испытаний опытного образца;
6) предварительные испытания опытного образца;
7) государственные (ведомственные) испытания опытного
образца;
8) отработка документации по результатам испытаний.

13.

РАЗРАБОТКА ТЗ НА ОКР
Составление проекта ТЗ заказчиком
Проработка проекта ТЗ исполнителем
Установление перечня контрагентов и согласование с ними
частных ТЗ
Согласование и утверждение ТЗ

14.

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

15.

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

16.

ТЕХНИЧЕСКОЕ ПРОЕКТИРОВАНИЕ
Окончательный выбор технических решений по
изделию в целом и его составным частям:
разработка принципиальных электрических,
кинематических, гидравлических и других схем
уточнение основных параметров изделия
проведение конструктивной компоновки
изделия и выдача данных для его размещения на
объекте
разработка проектов ТУ на поставку и
изготовление изделия
испытание макетов основных приборов изделия

17.

РАЗРАБОТКА РАБОЧЕЙ ДОКУМЕНТАЦИИ ДЛЯ
ИЗГОТОВЛЕНИЯ И ИСПЫТАНИЯ ОПЫТНОГО
ОБРАЗЦА
Формирование комплекта конструкторских документов:
разработка полного комплекта рабочей документации
согласование ее с заказчиком и заводом-изготовителем
серийной продукции
проверка конструкторской документации на
унификацию и стандартизацию
изготовление в опытном производстве опытного образца
настройка и комплексная регулировка опытного образца

18.

ПРЕДВАРИТЕЛЬНЫЕ ИСПЫТАНИЯ
Проверка соответствия опытного образца
требованиям ТЗ и определение
возможности его предъявления на
государственные (ведомственные)
испытания:
стендовые испытания
предварительные испытания на объекте
испытания на надежность

19.

ГОСУДАРСТВЕННЫЕ (ВЕДОМСТВЕННЫЕ)
ИСПЫТАНИЯ
Оценка соответствия требованиям ТЗ и
возможности организации серийного
производства

20.

ОТРАБОТКА ДОКУМЕНТАЦИИ ПО
РЕЗУЛЬТАТАМ ИСПЫТАНИЙ
Внесение необходимых уточнений и
изменений в документацию
Присвоение документации литеры "О1"
Передача документации заводуизготовителю

21.

СУЩНОСТЬ И ЭТАПЫ ПРОЦЕДУРЫ
ПРОЕКТИРОВАНИЯ
- постановки задачи создания нового
технического средства,
- поискового проектирования,
- концептуального проектирования
- инженерного конструирования.

22.

ПОСТАНОВКА
ЗАДАЧИ

23.

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

24.

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

25.

26.

КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ
Этап концептуального проектирования решает вопрос о
технической реализации замысла будущей конструкции.
Разработка и анализ различных вариантов принципиальных
решений (функциональной, компоновочной, кинематической и
других схем) дает концепцию конструкции. На этом этапе
проводится экономическая оценка отобранных вариантов.
Результатом этапа концептуального проектирования должно быть
оформленное техническое предложение, которое должно
определить концепцию конструкции будущего технического
средства и технико-экономическую целесообразность его
создания.

27.

28.

ИНЖЕНЕРНОЕ КОНСТРУИРОВАНИЕ
На этапе инженерного конструирования разрабатываются варианты
важнейших элементов технического средства (ЭТС), которые
анализируются и уточняются (эскизное конструирование).
Затем выполняется технико-рабочее проектирование, которое дает
полное и окончательное представление об устройстве и
функционировании будущего изделия, предусматривает детализацию
конструкции путем разработки чертежей на каждый изготовляемый
элемент. Объем комплекта конструкторской документации должен
ответить на вопросы – каким должно быть будущее техническое
средство на самом деле, как оно работает, как его ремонтировать,
транспортировать и т.д.

29.

На схемах показаны и элементы необходимой информационной
поддержки проектно-конструкторского процесса. Они представляют
собой каталоги известных технических решений технических средств
и их элементов (К.01), справочники по физическим эффектам,
методам и способам преобразования вещества, энергии и
информации (К.02 и К.03), сборники апробированных правил синтеза
технических решений для технических средств различных видов
(К.05), методов анализа вариантов технических решений (К.06) и
методов принятия решений (К.07) на разных стадиях
проектирования, описание рекомендуемых правил расчета техникоэкономических показателей (ТЭП) новых технических средств и их
элементов (К.04).

30.

СТАНДАРТЫ
1. международные.
2. региональные.
3. стандарты общественных объединений
4. национальные стандарты.

31.

МЕЖДУНАРОДНЫЕ.
1. Отличительный признак — принят
международной организацией. Пример
такой организации — ISO (международная
организация стандартизации). Пример её
стандарта: ISO 2382-12:1988
(Переферийное оборудование).
Распространены совместные стандарты
ISO и международной электротехнической
комиссии(IEC, в по русски — МЭК):
например, ISO/IEC 12207:2008

32.

РЕГИОНАЛЬНЫЕ.
Отличительный признак — принят
региональной комиссией по
стандартизации. К примеру, многие
советские ГОСТы сейчас являются
региональным стандартом, т.к. приняты
межгосударственным советом, куда входят
некоторые бывшие советские республики.
Этим советом принимаются и новые
стандарты — и они тоже получают
обозначение ГОСТ. Пример: ГОСТ 12.4.240-

33.

СТАНДАРТЫ ОБЩЕСТВЕННЫХ
ОБЪЕДИНЕНИЙ;
К примеру, той же МЭК: IEC 60255;

34.

НАЦИОНАЛЬНЫЕ СТАНДАРТЫ.
Для России в начале таких стандартов — “ГОСТ Р”.
Могут быть трех типов:
точные копии международных или региональных.
Обозначаются неотличимо от “самописных”
(национальных, написанных самостоятельно);
копии международных или региональных с
дополнениями. Обозначаются добавлением к шифру
отечественного стандарта шифра международного,
который был взят за основу. Например: ГОСТ Р
ИСО/МЭК 12207;
собственно, национальные стандарты. Например, ГОСТ
Р 34.11-94.

35.

ОБОЗНАЧЕНИЯ ГОСТОВ.
Их может быть два варианта:
стандарт относиться к серии стандартов. В этом случае после
индекса категории стандарта (например, ГОСТ, ГОСТ Р или ГОСТ
РВ) идет код серии, точка и обозначение стандарта внутри серии.
Правила обозначения стандартов внутри серии устанавливаются
правилами серии. Например: ГОСТ РВ 15.201-2000, ГОСТ Р 22.8.099, ГОСТ 19.101-77;
стандарт не относиться к серии стандартов. Тогда после индекса
категории идет просто порядковый номер стандарта, тире и год
принятия. Например, ГОСТ Р 50628—2000.
Итак, если совсем просто — то обозначение ГОСТа — это либо просто
порядковый номер, тире, год, либо номер серии, точка и дальше в
зависимости от серии. В реальности все сложнее ( к примеру, можно
встретить что то типа ГОСТ 11326.19-79, и это будет вовсе не серия
11326 — но программистам такое нужно очень редко. За
подробностями — в ГОСТ Р 1.5-2004).

36.

ЕСПД
ЕСПД — одна из таких серий ГОСТов, номер
19. Т.е. все стандарты, относящиеся к ЕСПД,
начинаются с префикса “19.”: например, ГОСТ
19.106-78. Расшифровывается как “Единая
система программной документации”.

37.

СУЩЕСТВУЮТ И ДРУГИЕ СЕРИИ:
ГОСТ ЕСКД (единая система конструкторской
документации, префикс “2.”);
ГОСТ ЕСТД (единая система технологической
документации, префикс “3.”);
ГОСТ Р, Система разработки и постановки продукции на
производство, префикс “15.”;
ГОСТ РВ, Вооружение и военная техника. Система
разработки и постановки продукции на производство,
префикс “15.”;
ГОСТ, Система технической документации на АСУ,
префикс “24.”;
ГОСТ, Комплекс стандартов на автоматизированные
системы, префикс “34.”.

38.

ИСПОЛЬЗОВАНИЕ ТРЕБОВАНИЙ ГОСТ 19 И
34 СЕРИИ ПРИ ОФОРМЛЕНИИ
ДОКУМЕНТАЦИИ В IT-ПРОЕКТАХ ДЛЯ
ГОСУДАРСТВЕННЫХ СТРУКТУР
При разработке автоматизированных систем (АС)
по ГОСТ 34 в IT-проектах для госструктур зачастую
возникает вопрос: по каким ГОСТам оформлять
документацию? В ГОСТ 34 нет явных указаний на
то, по каким стандартам оформлять конкретные
документы, разрабатываемые в рамках создания
АС, кроме требований к оформлению ТЗ. Попробуем
выяснить, какие ГОСТы используются при
оформлении документов в случае отсутствия
точных указаний в государственном контракте или
конкурсном техническом задании (ТЗ).

39.

ПЕРЕЧЕНЬ ДОКУМЕНТОВ
Перечень документов, разрабатываемых на различных стадиях создания АС
приведен в ГОСТ 34.201-89 «Виды, комплектность и обозначение документов
при создании автоматизированных систем». В нем приведены следующие
требования:
На стадии «Техническое задание» разрабатывают ТЗ на создание АС по
ГОСТ 34.602-89 «Техническое задание на создание автоматизированной
системы»;
Виды программных документов, разрабатываемых на различных
стадиях создания АС определяются по ГОСТ 19.101-77 «Единая система
программной документации. Виды программ и программных документов». К
ним относятся различные руководства, например, руководство пользователя.
Виды конструкторских документов, разрабатываемых на различных
стадиях создания АС определяются по ГОСТ 2.102-2013 «Единая система
конструкторской документации. Виды и комплектность конструкторских
документов». Например, к ним относятся ведомости эскизного и технического
проекта, ведомость покупных изделий, пояснительные записки к эскизному,
техническому проектам.

40.

ОФОРМЛЕНИЕ ТЗ
С ТЗ всё достаточно ясно: в ГОСТ 34.602-89
приведен стандарт его оформления: п.3.2.
гласит, что «ТЗ на АС оформляют в
соответствии с требованиями ГОСТ 2.105 на
листах формата А4 по ГОСТ 2.301 без рамки,
основной надписи и дополнительных граф к
ней».

41.

ОФОРМЛЕНИЕ ПРОГРАММНОЙ
ДОКУМЕНТАЦИИ
С программными документами, разрабатываемыми в рамках ИТпроекта, также есть чёткое указание использовать ГОСТ 19 серии в части
оформления: вышеприведённый ГОСТ 19.101-77 входит в серию ГОСТов
19-й серии «Единая система программной документации» (ЕСПД). ЕСПД
— комплекс государственных стандартов Российской Федерации,
устанавливающих взаимосвязанные правила разработки, оформления и
обращения программ и программной документации.
Документация в ЕСПД оформляется по ГОСТ 19.104-78 «Единая система
программной документации. Основные надписи», ГОСТ 19.105-78
«Единая система программной документации. Общие требования к
программным документам», ГОСТ 19.106-78 «Единая система
программной документации. Требования к программным документам,
выполненным печатным способом».

42.

ОФОРМЛЕНИЕ КОНСТРУКТОРСКОЙ
ДОКУМЕНТАЦИИ
Теперь рассмотрим ГОСТ 2.102-2013. Этот стандарт входит в серию
ГОСТов 2-й серии «Единая система конструкторской документации»
(ЕСКД). ЕСКД — межгосударственный комплекс стандартов,
устанавливающих взаимосвязанные нормы и правила по разработке,
оформлению и обращению конструкторской документации,
разрабатываемой и применяемой на всех стадиях жизненного цикла
изделия (при проектировании, изготовлении, эксплуатации, ремонте и
др.)
Документация в ЕСКД оформляется по нескольким стандартам.
Наиболее часто используемыми из них (применительно к ИТ-сфере)
являются ГОСТ 2.105-95 «Единая система конструкторской
документации. Общие требования к текстовым документам» и ГОСТ
2.106-96 «Единая система конструкторской документации. Текстовые
документы».

43.

КОНСТРУКТОРСКАЯ ДОКУМЕНТАЦИЯ
Совокупность конструкторских документов,
содержащих данные, необходимые для
проектирования (разработки), изготовления,
контроля, приемки, поставки, эксплуатации,
ремонта, модернизации, утилизации
изделия»
ГОСТ 2.001-2013 «Единая система
конструкторской документации (ЕСКД).
Общие положения»

44.

ОСНОВНЫЕ ГОСТЫ 2-Й СЕРИИ ДЛЯ ИТПРОЕКТА В ЧАСТИ ОФОРМЛЕНИЯ
ГОСТ 2.105-95 – стандарт устанавливает
общие требования к выполнению текстовых
документов на изделия машиностроения,
приборостроения и строительства;
ГОСТ 2.106-96 – стандарт устанавливает
формы и правила выполнения
конструкторских документов изделий
машиностроения и приборостроения.
«Приборостроение -отрасль машиностроения, выпускающая средства
измерения, анализа, обработки и представления информации, устройства
регулирования, автоматические и автоматизированные системы управления;
область науки и техники, разрабатывающая средства автоматизации и
системы управления», то есть всё, что нужно по нашей теме современных

45.

ВЫВОДЫ
при разработке АС по ГОСТ 34 в IT-проектах для государственных
структур в случае отсутствия точных указаний в государственном
контракте или конкурсном ТЗ программная и конструкторская
документация должна оформляться по следующим ГОСТам:
Программные документы, разрабатываемые на различных
стадиях создания АС оформляются по ГОСТ 19.104-78, ГОСТ 19.105-78,
ГОСТ 19.106-78;
Конструкторские документы, разрабатываемые на различных
стадиях создания АС оформляются по ГОСТ 2.105-95 и ГОСТ 2.106-96.
При этом требования к содержанию регламентируются РД 50.34-69890.

46.

ТРЕБОВАНИЯ К ПРОГРАММНОЙ
ДОКУМЕНТАЦИИ

47.

19.001-77. ОБЩИЕ ПОЛОЖЕНИЯ
Описывает правила присвоения обозначений
стандартов в серии ЕСПД. В практической
жизни не нужен.

48.

19.102-80. СХЕМЫ АЛГОРИТМОВ И
ПРОГРАММ. ПРАВИЛА ВЫПОЛНЕНИЯ.
Описывает правила построения и оформления
алгоритмов. Использует обозначения из 19.103. В моей
практике был нужен единственный раз, когда при
сертификационная лаборатория уперлась по
формальному признаку, что нужна именно схема
алгоритма. С моей точки зрения, классические блок-схемы
двумя ногами в прошлом, и единственно, где остались
более-менее уместными, это если при изложении автор
хочет акцентировать внимание читателя именно на
алгоритме.

49.

19.003-80. СХЕМЫ АЛГОРИТМОВ И
ПРОГРАММ. ОБОЗНАЧЕНИЯ УСЛОВНЫЕ
ГРАФИЧЕСКИЕ
Приведены графические обозначения
допустимых типов элементов блок-схемы.
Нужен, если используются блок-схемы.

50.

19.004-80. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ.
Скудный глоссарий. Из интересного —
содержит формальные определения
программного и эксплуатационного
документов.

51.

19.005-85. Р-СХЕМЫ АЛГОРИТМОВ И
ПРОГРАММ
Практически забытый язык. В свое время Р-схемы широко
использовались в ракетно-космической отрасли, став
стандартом де-факто для написания программ управления
пусками и моделирования запусков. Однако ныне этот
язык полностью предан забвению. В своей работе я ни
разу не сталкивался с Р-схемами. Хотя по сравнению с
блок-схемами они имеют заметные преимущества:
компактны, подходят для визуализации нелинейных
алгоритмов (например, классов в С++) или структур
данных. При этом в интернете информации по ним
практически нет: мне показались полезными вот этот и вот
этот сайты. В любом случае, если бы сейчас мне
пришлось вставлять в программную документацию схему
алгоритма, я бы выбрал Р-схемы, а не блок-схемы.

52.

19.101-77. ВИДЫ ПРОГРАММ И
ПРОГРАММНЫХ ДОКУМЕНТОВ
Содержит таблицу соответствия вида
документа его коду, а также деление видов
документов на эксплуатационные и
программные. Вводится понятие комплекса
и компонента. Больше ничего полезного
нет.

53.

19.102-77. СТАДИИ РАЗРАБОТКИ
Важный и нужный стандарт, в котором
описаны виды документов и приведены
коды видов программных документов.

54.

Стадии
разработки
Этапы работ
Содержание работ
1.
Обоснование
Постановка задачи. Сбор исходных материалов. Выбор и
Техническое необходимости
обоснование критериев эффективности и качества
задание
разработки программы разрабатываемой программы. Обоснование необходимости
проведения научно-исследовательских работ.
НаучноОпределение структуры входных и выходных данных.
исследовательские
Предварительный выбор методов решения задач. Обоснование
работы
целесообразности применения ранее разработанных программ.
Определение требований к техническим средствам.
Обоснование принципиальной возможности решения
поставленной задачи.
Разработка и
Определение требований к программе. Разработка техникоутверждение
экономического обоснования разработки программы.
технического задания Определение стадий, этапов и сроков разработки программы и
документации на нее. Выбор языков программирования.
Определение необходимости проведения научноисследовательских работ на последующих стадиях.
Согласование и утверждение технического задания.
2. Эскизный Разработка эскизного Предварительная разработка структуры входных и выходных
проект
проекта
данных. Уточнение методов решения задачи. Разработка
общего описания алгоритма решения задачи. Разработка
технико-экономического обоснования.
Утверждение эскизного Разработка пояснительной записки. Согласование и
проекта
утверждение эскизного проекта.
5. Внедрение Подготовка и передача Подготовка и передача программы и программной
программы
документации для сопровождения и (или) изготовления.
Оформление и утверждение акта о передаче программы на
сопровождение и (или) изготовление. Передача программы в
фонд алгоритмов и программ.

55.

3.
Разработка
Технический технического проекта
проект
Утверждение
технического проекта
4. Рабочий
проект
Уточнение структуры входных и выходных данных. Разработка
алгоритма решения задачи. Определение формы
представления входных и выходных данных. Определение
семантики и синтаксиса языка. Разработка структуры
программы. Окончательное определение конфигурации
технических средств.
Разработка пояснительной записки. Согласование и
утверждение эскизного проекта.
Разработка программы Программирование и отладка программы
Разработка
программной
документации
Разработка программных документов в соответствии с
требованиями ГОСТ 19.101-77

56.

19.103-77. ОБОЗНАЧЕНИЯ ПРОГРАММ И
ПРОГРАММНЫХ ДОКУМЕНТОВ
Нужен, в основном, для того, что бы
научиться читать обозначения документов
подобных приведенному выше. Однако
понимание схемы обозначений полезно в
случае, когда приходиться выходить за
рамки типовых работ: к примеру, помнить,
что документы с кодами после 90 —
пользовательские, т.е. любые.

57.

19.104-78. ОСНОВНЫЕ НАДПИСИ
Описывает два листа документа — лист
утверждения (ЛУ) и титульный лист. Лист
утверждения в ЕСПД содержит подписи как
начальства, утвердившего документ, так и
разработчиков, нормоконтролеров,
представителей приемки и т.д. Т.е. на нем
присутствует достаточно много чувствительной
для предприятия информации. Поэтому в
стандарте принято, что ЛУ остается на
предприятии-разработчике, и высылается только
по особому указанию.

58.

19.105-78. ОБЩИЕ ТРЕБОВАНИЯ К
ПРОГРАММНЫМ ДОКУМЕНТАМ
Вводится общая структура документа, не
зависящая от способа его исполнения. Т.е. еще в
1978 году было заложено в стандарт, что
документ может быть не обязательно бумажным.
В частности, вводиться понятие содержания для
полностью электронных документов. Для
бумажного исполнения, распространенного в то
время, был принят ГОСТ 19.106-78.
В настоящее время к этому стандарту
приходиться обращаться очень редко: разве что
забывается порядок следования основных частей
документа.

59.

КАК ЧИТАТЬ И ПОНИМАТЬ СТАНДАРТЫ
ДОКУМЕНТАЦИИ ПО ГОСТ СЕРИИ 34
Стандарт делит все документы по двум осям
— время и предметная область. Если
посмотреть таблицу 2 в ГОСТ 34.201-89, то
хорошо видно это деление (колонки «Стадия
создания» и «Часть проекта»
https://www.swrit.ru/gost-34.html
https://habr.com/ru/post/122700/

60.

СТАДИИ СОЗДАНИЯ АСУ
Стадии создания определены в ГОСТ
34.601-90. Имеют отношение к
документированию из них три:
Эскизный проект (ЭП)
• Технический проект (ТП)
• Разработка рабочей документации (РД)

61.

ГОСТЫ СЕМЕЙСТВА 34
ГОСТ 34.201-2020 Виды, комплектность и обозначения документов
при создании автоматизированных систем
ГОСТ 34.320-96 Концепции и терминология для концептуальной
схемы и информационной базы
ГОСТ 34.321-96 Информационные технологии. Система стандартов по
базам данных. Эталонная модель управления
ГОСТ 34.601-90 Автоматизированные системы. Стадии создания
ГОСТ 34.602-2020 Техническое задание на создание
автоматизированной системы
ГОСТ 34.603-92 Информационная технология. Виды испытаний
автоматизированных систем
ГОСТ Р 59795-2021 Автоматизированные системы. Требования к
содержанию документов

62.

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

63.

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

64.

МАТЕМАТИЧЕСКОЕ ОБЕСПЕЧЕНИЕ
(МО)
Отвечает на вопросы: какая логика зашита
внутри «черного ящика»? Почему выбраны
именно эти алгоритмы, именно такие
формулы и именно такие коэффициенты?
Математическое обеспечение ничего не
знает ни о процессорах, ни о базах данных.
Это отдельная абстрактная область,
обитель «сферических коней в вакууме». Но
математическое обеспечение бывает очень
плотно связано с предметной областью, aka
Реальная жизнь.

65.

ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ
(ИО).
Еще один срез системы. На этот раз делается прозрачным черный
ящик нашей системы и мы смотрим на циркулирующую в нем
информацию. Представьте себе модель кровеносной системы
человека, когда все остальные органы невидимы. Вот что-то подобное
и есть Информационное обеспечение. В нем описываются состав и
маршруты прохождения информации внутри и снаружи, логическая
организация информации в системе, описание справочников и систем
кодирования (кто делал программы для производства, тот знает, как
они важны). Основная описательная часть приходится на этап ТП, но в
этап РД перетекают некоторые «рудименты», наподобие документа
«Каталог баз данных». Понятно, что раньше он содержал именно то,
что написано в названии. Но сегодня попробуйте для сложной
комплексной системы сформировать такой документ, когда очень
часто в составе системы используются покупные подсистемы со
своими загадочными информационными хранилищами. Я уж не
говорю о том, что этот документ не особенно сейчас и нужен.

66.

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
(ПО).
В этом документе мы должны рассказать, при помощи
каких программных средств выполняются алгоритмы,
описанные в МО, обрабатывающие информацию,
описанная в ИО. То есть, не нужно дублировать тут
информацию из других разделов. Тут дается архитектура
системы, обоснование выбранных программных
технологий, их описание (всякие системные вещи: языки
программирования, фреймворки, операционки и т.п.).
Также в этом документе мы описываем как организованы
средства обработки информации (очереди сообщений,
хранилища, средства резервного копирования, решения по
доступности, всякие пулы приложений и т.п.). В стандарте
есть подробнейшее описание содержания этого
документа, которое поймет любой специалист.

67.

ТЕХНИЧЕСКОЕ ОБЕСПЕЧЕНИЕ (ТО).
Всего по стандарту требуется разработать 22 документа,
из них 9 на стадии ТП.
Дело в том, что стандарт предусматривает описание всего
технического обеспечения, включая компьютерное
«железо» и сети, инженерные системы и даже
строительную часть (если потребуется). А это хозяйство
регламентируется громадным количеством стандартов и
нормативных актов, согласуется в разных организациях и
поэтому удобнее все дробить на части и согласовывать
(править) по частям. В то же время стандарт позволяет
объединять некоторые документы друг с другом, что имеет
смысл делать, если всю кучу согласует один человек.
Не забывайте также, что комплекс стандартов качества
подразумевает учет и хранение технических документов, и
наши «книжицы» у заказчика могут разойтись по разным
архивам, в зависимости от предмета описания. Это еще

68.

ОРГАНИЗАЦИОННОЕ
ОБЕСПЕЧЕНИЕ (ОО).
На стадии ТП раздел содержит всего один
документ «Описание организационной
структуры», в котором мы должны
рассказать заказчику, к чему он должен
готовиться в плане изменения оргштатной
структуры. Вдруг требуется организовать
новый отдел для эксплуатации вашей
системы, ввести новые должности и т.п.

69.

РАБОЧАЯ ДОКУМЕНТАЦИЯ (РД)
Руководство пользователя.
Методика (технология)
автоматизированного проектиров
Технологическая инструкция.
Описание технологического процесса
обработки данных (включая
телеобработку).

70.

МЕТОДИКА (ТЕХНОЛОГИЯ)
АВТОМАТИЗИРОВАННОГО
ПРОЕКТИРОВАНИЯ.
Методика (технология)
автоматизированного проектирования. В
этот документ при необходимости можно
поместить описание процесса сборки ПО,
управления версиями, тестирования и т.п. Но
это если в ТЗ заказчик желает самолично
осуществлять сборку ПО. Если он этого не
требует (и не платит за это), то вся ваша
внутренняя кухня не его ума дело, и этот
документ делать не нужно.

71.

ТЕХНОЛОГИЧЕСКАЯ ИНСТРУКЦИЯ.
Технологическая инструкция является прослойкой между
ОРД и руководством пользователя. РП подробно описывает
как нужно делать те или иные действия в системе.
Технологическая инструкция говорит о том, какие действия
необходимо выполнять в тех или иных случаях, связанных с
эксплуатацией системы. Грубо говоря, технологическая
инструкция это краткий дайджест по РП для конкретной
должности или роли. Если у заказчика роли не
сформированы или он хочет, чтобы вы сами сформировали
роли и требования к должностям, включите в документ
самые базовые роли, например: оператор, старший
оператор, администратор. Замечания заказчика на тему, «а у
нас не так» или «а нам не нравится» должны сопровождаться
перечнем ролей и описанием должностных обязанностей.
Потому что бизнес-процессы мы не ставим. Мы эти бизнес-

72.

ОПИСАНИЕ ТЕХНОЛОГИЧЕСКОГО ПРОЦЕССА
ОБРАБОТКИ ДАННЫХ
Описание технологического процесса
обработки данных (включая телеобработку).
Жалкий рудимент пещерного века, когда
были специально выделенные «Операторы
ЭВМ», скармливающие машине перфокарты и
упаковывающие распечатку результата в
конвертик. Эта инструкция — для них. Что в
нее писать в XXI веке — я вам точно сказать
не могу. Выкручивайтесь сами. Самое лучшее,
это просто забыть про этот документ.

73.

ОБЩЕСИСТЕМНЫЕ РЕШЕНИЯ (ОР).
Стандартом предусмотрено 17 документов раздела ОР. Вопервых, это почти все документы предварительной фазы
Эскизного проектирования. Во-вторых, это всевозможные
сметы, расчеты и краткие описание автоматизируемых
функций. То есть, информация для людей не с основного ИТпроизводства, а для вспомогательного персонала —
менеджеров, сметчиков, специалистов по закупкам,
экономистов и т.п.
А в-третьих, в состав ОР входит мега-документ под
названием «Пояснительная записка к техническому
проекту», который по задумке представляет собой некий
Executive Summary, а по факту многие проектанты пихают
в него вообще все полезное содержание стадии ТП.
Подобный радикальный подход бывает оправдан и даже
взаимно выгоден и заказчику и исполнителю работ, но в

74.

ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ ГОСТ 34

75.

ПОЛНОЕ И ТОЧНОЕ СЛЕДОВАНИЕ
СТАНДАРТУ
Добровольно никто, естественно, такую тучу документов писать не
будет. Поэтому полный комплект документов готовится только по
настоятельной просьбе заказчика, которую он закрепил в ТЗ и еще
договором сверху придавил. В таком случае требуется понимать все
буквально и отдать заказчику физические «книжки», на которых будут
стоять названия документов из таблицы 2 ГОСТ 34.201-89 за
исключением совсем уж ненужных, перечень которых вы обязательно
должны обговорить и закрепить письменно. Содержание документов
также должно без всякой фантазии соответствовать РД 50-34.698-90,
вплоть до названия разделов. Для того, чтобы у заказчика взорвался
мозг, иногда большую систему делят на подсистемы, и для каждой
подсистемы выпускают отдельную проектную документацию. Выглядит
это устрашающе и нормальному контролю при помощи земного разума
не подлежит. Особенно в части интеграции подсистем. Что значительно
упрощает приемку. Главное, чтобы вы сами при этом не запутались и
чтобы ваша система все-таки заработала как надо.

76.

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

77.

НАМ ПЛЕВАТЬ НА ДОКУМЕНТАЦИЮ, ЛИШЬ
БЫ ВСЕ РАБОТАЛО.
Исчезающий вид безответственного заказчика.
Подобный взгляд на документацию пока еще
можно встретить у небольших и бедных
заказчиков, а также в оставшихся со времен
перестройки авторитарных «идиотократиях», где
босс окружен верными друзьями — директорами, и
все вопросы решаются в личных беседах. Вы
вольны в подобных условиях забивать на
документирование вообще, но лучше, все таки,
прицел не сбивать и хотя бы схематично наполнять
содержимым документацию. Если не этому
заказчику, так следующему передадите (продадите).

78.

РЕЦЕПТ ГРАМОТНОГО ТЗ






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

79.

80.

КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ
В этот пункт входит краткое описание продукта, в нем отражается цель проекта и
его отличительные черты.
Например: “Приложение для знакомств, в котором можно смотреть короткие
видео в профилях пользователей и общаться в чате”. Также не помешает сказать
пару слов об аудитории продукта, так команда проекта сможет понять его
особенности и дать вам несколько полезных советов. Расскажите о ее возрасте,
характере и территориальном расположении, каких-то особенностях, которые
должны отразиться на проекте.
Стоит рассказать о типах пользователей и их ключевых отличиях.
Например: “В приложении должны быть обычные пользователи и модераторы,
которые получают жалобы от пользователей на контент или профили.
Модераторы могут просматривать чат обычных пользователей после жалобы и
заблокировать в сервисе нарушающий правила аккаунт”.
И в завершении расскажите о компонентах вашего продукта.
Например: панель администратора, которую используют модераторы; мобильное
приложение, которое использует пользователь, чтобы зарегистрироваться,
добавить контент, поучаствовать в чате и т.д.
Высшим пилотажем будет сделать так называемый data flow или контекстную
диаграмму, в которой будет отражено как пользователи взаимодействуют с
продуктом, его компонентами и между собой.

81.

ФУНКЦИОНАЛЬНАЯ КАРТА
Функциональная карта отображает общую
концепцию проекта с уровнем детализации
необходимым для того, чтобы оценить объем
работ, расставить приоритеты.В
традиционном формате такая карта
напоминает карту сайта. Но удобнее всего ее
отобразить в виде mind card (майнд карт,
интеллект карт). Часто менеджеры рисуют на
совещании на доске или листе бумаги слова и
между ними связи, так вот, это и есть майнд
карта.

82.

83.

ПУТЬ ПОЛЬЗОВАТЕЛЯ
Так называемый user flow или путь пользователя, это
последовательный список действий или экранов, по которым может
переходить пользователь в процессе взаимодействия с продуктом.
Опишите, как в вашем представлении будет взаимодействовать с
продуктом пользователь. Очень удобно это можно сделать также майнд
картой или просто списком действий.
Например: “Пользователь заходит в приложение, чтобы познакомиться с
сверстниками. Он заполняет свой профиль данными и загружает фото и
видео. Затем пользователь заходит в ленту и фильтрует ее по какимлибо критериям. В качестве результата он получает список релевантных
профилей, может посмотреть их и написать другому пользователю в
чате.

84.

85.

ПОЛЬЗОВАТЕЛЬСКИЙ ИНТЕРФЕЙС
Опишите в общем виде, каким вы хотите видеть свой продукт, какие у
него должны быть цвета, какие элементы использоваться, какую вы
хотите анимацию и т.д. Если у вас есть фирменный стиль или брендбук,
отлично, сошлитесь на них.
Высшим пилотажем будет добавить wireframes (вайрфреймы) —
прототипы интерфейса продукта в виде приближенных схем.

86.

87.

ПРОГРАММНЫЕ ИНТЕРФЕЙСЫ
В лучшем техническом задании также описывается архитектура
продукта, то есть то, из каких программных компонентов он состоит. В
случае клиент-серверного приложения для знакомств сервис
разбивается на часть сервера, которая хранит данные и обрабатывает
их, производит какие-то логические операции и часть клиента, который
отображает данные.
Сервер декомпозируется на модули: базы данных, аутентификации, чата
и т.д.Клиент связывается с сервером через API (интерфейсы передачи
данных), стоит указать его тип (REST, WEB, RPC и т.д.) и описать
методы, ответы и обработку ошибок.
Данные обычно хранятся в базе данных в виде специальных структур,
чаще всего таблиц (для реляционных БД) и json структур (для
нереляционных). Разработчики скажут вам огромное спасибо, если в
техническом задании вы укажите сущности базы данных (ER-модели) и
опишите хранимые поля, с указанием их типов данных (string, int и т.д),
ключей (primary, foreign), обязательности (required) и пустого значения
(nullable).

88.

НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
Это общие требования к продукту. Их можно разделить на требования к
техническому обеспечению, требования безопасности и требования к
производительности.В требованиях к техническому обеспечению
указывают пожелания к устройствам и операционной среде, например
для приложения знакомств это Android 7.0+ и JDK 8+, iOS 11.0+ и Swift
4.2.
В требованиях к безопасности можно указать, что передача данных в
чате должна осуществлять с помощью шифрования SHA-1 и что при
регистрации сложность пароля должна быть не менее 8 бит.В
требованиях к производительности говорится о связи компонентов и
отказоустойчивости, например стоит указать, что таймаут на чтение
сообщения в чате не более 1 с и что приложении частично хранит кеш и
может ограниченное время работать в автономном режиме.

89.

ЗАЧЕМ НУЖЕН ГОСТ НА ТЕХНИЧЕСКОЕ
ЗАДАНИЕ?
ЛЮБОЙ стандарт на документы или
процессы — это шаблон. Причем шаблон
очень сильно упрощает разработку
документа: за тебя уже продумали структуру
и содержание, кроме того, в таком шаблоне
учитываются такие моменты, про которые
вы бы и не вспомнили.

90.

КАКУЮ РОЛЬ ТЕХНИЧЕСКОЕ ЗАДАНИЕ
ЗАНИМАЕТ В ПРОЕКТЕ?
ТЗ устанавливает общий облик системы, объем работ (рамки
разработки), а также порядок разработки и приемки. Все с ТЗ начинается
и все им заканчивается. Этот документ идеально подходит для того,
чтобы ваш заказчик понял всю важность и сложность задачи и за что он
платит деньги.
Причем ТЗ составляется как для исполнителя, так и заказчика,
поскольку проект автоматизации проводят команды с обеих сторон. В
любом ИТ-проекте имеется огромное количество организационных
мероприятий, выполнение которых без активнейшего участия заказчика
невозможно. Объясняйте это заказчикам при каждом удобном случае,
иначе у них складывается впечатление, что они должны только
заплатить деньги и сидеть ровно: все сделают нанятые ребята. А потом
проект терпит фиаско и начинаются разборки. В общем, без реальной
команды с той стороны не стоит и начинать проект.

91.

КАКОЙ СПЕЦИАЛИСТ ДОЛЖЕН СОСТАВЛЯТЬ
ТЕХНИЧЕСКОЕ ЗАДАНИЕ ПО ГОСТ 34?
Техническое задание по ГОСТ 34 вообще можно программистам не показывать.
Для этого существуют документы технического проекта. Техническое задание —
это документ, который согласовывается с заказчиком, который постоянно на
столе у руководителя проекта.
ТЗ отвечает на два вопроса: ЧТО должна делать система, и КАК она должна
создаваться. Технический же проект отвечает на вопрос: КАК должны быть
выполнены требования ТЗ. Например, в ТЗ вы прописываете, что должна быть
авторизация по логину и паролю, а в ТП приводите макеты интерфейса,
сценарии, структуру базы данных.
Техническое задание должен составлять бизнес-аналитик, потому что он
является «переводчиком» между заказчиком и командой разработки. Задача
бизнес-аналитика — разобраться в том, что нужно заказчику и выразить это так,
чтобы было понятно команде. И выразить это в виде технического задания.
Причем от бизнес-аналитика требуется не просто выслушать заказчика и его
сотрудников, а узнать то, о чем они не сказали (а такого обычно более 50%).
Поэтому аналитик должен хорошо знать автоматизируемые процессы и за счет
своего знания заполнять пробелы, которые остались по результатам
обследования.

92.

КАКАЯ СТОРОНА ДОЛЖНА СОСТАВЛЯТЬ
ТЕХНИЧЕСКОЕ ЗАДАНИЕ?
В основном Техническое задание составляется исполнителем? Почему?
Не только потому что так рекомендуется в Приложении 1 к ГОСТ 34602-89. На самом деле, у заказчика, как правило, отсутствуют
соответствующие специалисты. Но ТЗ в обязательном порядке
прорабатывается и согласовывается заказчиком. И вот здесь нужно
обязательно добиться того, чтобы согласование не было формальным.
Иначе он так и не сформирует свои ожидания от системы, а значит, вопервых, будет недоволен любым результатом, а, во-вторых, не сможет
провести необходимые организационные мероприятия.

93.

НАСКОЛЬКО ДАЛЕКО МОЖНО ОТХОДИТЬ ОТ
ГОСТ 34?
пункт 2.2 ГОСТ 34.602-89: «В зависимости от вида, назначения,
специфических особенностей объекта автоматизации и условий
функционирования системы допускается оформлять разделы ТЗ в виде
приложений, вводить дополнительные, исключать или объединять
подразделы ТЗ». Также в п. 1.2. РД 34.698-90 указано: «Содержание
документов является общим для всех видов АС и, при необходимости,
может дополняться разработчиком документов в зависимости от
особенностей создаваемой АС. Допускается включать в документы
дополнительные разделы и сведения, объединять и исключать
разделы».

94.

ЗАЧЕМ В ТЗ ПО ГОСТ 34 ОПИСЫВАЕТСЯ ТАК
МНОГО ТРЕБОВАНИЙ, НАПРЯМУЮ НЕ
ОТНОСЯЩИХСЯ К ФУНКЦИЯМ СИСТЕМЫ?
1.
2.
3.
4.
5.
в первой половине ТЗ не просто так приводятся общие сведения о системе и общие
требования. Надо понять, зачем система создается, какие процессы автоматизирует,
что нужно сделать, чтобы система заработала, какой облик имеет система. Вроде бы
банальные вещи, но без них члены команды по-разному будут понимать цель работ и
средства достижения цели.
составители ГОСТ 34 видели систему в первую очередь как людей, а затем уже как
программно-аппаратный комплекс. Вот как ГОСТ 34.003-90 определяет
автоматизированную систему: «Система, состоящая из персонала и комплекса
средств автоматизации его деятельности, реализующая информационную
технологию выполнения установленных функций».
ТЗ не на систему, а на создание системы. В чем отличие? Отличие в том, что ТЗ
устанавливает не только требования к самой системе, но и регламентирует процесс
ее создания, то есть в документе приводятся требования ко всем организационным
мерам, выполнение которых необходимо для достижения результата.
ТЗ представляет собой документ, по которому можно ставить галочки: приняли мы
во внимание данное требование или нет. Может, вы поставите 10 галочек чисто
автоматически, потому что это будут стандартные решения. Но галочка номер 11
выявит очень большую проблему, и если эту проблему сейчас пропустить, то она
всплывет где-то в процессе внедрения, когда уже определены все сроки и бюджеты.
ненужные подразделы можно исключать, это допускается

95.

РАЗДЕЛ 1. «ОБЩИЕ СВЕДЕНИЯ» /П. 2.3 ГОСТ
34.602-89/
Под «перечнем документов, на основании которых создается система»
имеются в виду законы, распоряжения или договор. Также таким документом
может являться другое ТЗ, если мы разрабатываем ТЗ на подсистему.
В подразделе «Порядок оформления и предъявления заказчику результатов
работ по созданию системы (ее частей), по изготовлению и наладке
отдельных средств (технических, программных, информационных) и
программно-технических (программно-методических) комплексов системы»
приводятся общие сведения о приемке работ. Например, то, что мы передаем
документацию и проводим ряд испытаний системы. Здесь мы только
упоминаем о порядке передаче результатов работ, а ниже, в других разделах,
данная тема раскрывается подробно.

96.

РАЗДЕЛ 2. «НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ
(РАЗВИТИЯ) СИСТЕМЫ» /П. 2.4 ГОСТ 34.60289/
С назначением все понятно: мы приводим именно вид (виды) автоматизированной
деятельности. Например, если мы создаем систему для производственного учета,
то и приводить стоит автоматизируемые виды учета, автоматизируемые операции,
а также объекты, автоматизация которых предполагается.
С целью все по-другому. Цель — это ради чего мы затеваем проект. Можно назвать
это бизнес-целями. Я выделяю следующие возможные цели проектов
автоматизации:
1.
Выполнение внешних требований (требования закона, стандарта и т.д.)
2.
Обеспечение работы нового технологического процесса (например,
создаем интернет-магазин, организуем новый отдел, новый бизнес).
3.
Снижение операционных расходов (уменьшение количества персонала,
увеличение выпуска продукции при использовании тех же мощностей, повышение
эффективности).
4.
Повышение качества работы: снижение количества ошибок, ускорение
принятия решений.
5.
Снижение рисков, повышение надежности. Это касается не только
технической стороны, но также исключения опасности в случае болезни или
увольнения ключевых, «незаменимых», сотрудников.

97.

РАЗДЕЛ 3. «ХАРАКТЕРИСТИКИ ОБЪЕКТА
АВТОМАТИЗАЦИИ» /П. 2.5 ГОСТ 34.602-89/
1.
Описание заказчика: виды деятельности заказчика, количество
филиалов, сотрудников. Конечно, характеризовать заказчика нужно в той
части, которая непосредственно касается создаваемой системы.
2.
Сведения о пользователях системы: виды пользователей, какую роль
играет система для разных пользователей.
3.
Описание автоматизируемых объектов. Например, если мы
автоматизируем склад, до должны описать, какой он площади, сколько
проходов, какая ширина проходов, какие стеллажи, имеется ли отдельная
зона сборки, сколько работает человек и какие у них обязанности. Тогда мы
поймем, что конкретно автоматизируем, как должен выглядеть складской
процесс, и какое оборудование используется.
4.
Описание автоматизируемых процессов. Конечно, не стоит в ТЗ
расписывать процессы подробно. Но привести общие сценарии —
обязательно. Только тогда нам становится ясно, какие должны иметься
функции.
5.
Перечень документов, в которых приводится подробное описание
объекта автоматизации.

98.

РАЗДЕЛ 4 «ТРЕБОВАНИЯ К СИСТЕМЕ»

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

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

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

99.

ПОДРАЗДЕЛ 4.1. «ТРЕБОВАНИЯ К СИСТЕМЕ В
ЦЕЛОМ» /П. 2.6.1 ГОСТ 34.602-89/
приводят так называемые
нефункциональные, общие, требования,
которые описывают создаваемую систему с
разных сторон.

100.

ПУНКТ 4.1.1. «ТРЕБОВАНИЯ К СТРУКТУРЕ И
ФУНКЦИОНИРОВАНИЮ СИСТЕМЫ» /П. 2.6.1.1
ГОСТ 34.602-89/

101.

1. ПЕРЕЧЕНЬ ПОДСИСТЕМ, ИХ НАЗНАЧЕНИЕ И
ОСНОВНЫЕ ХАРАКТЕРИСТИКИ, ТРЕБОВАНИЯ
К ЧИСЛУ УРОВНЕЙ ИЕРАРХИИ И СТЕПЕНИ
ЦЕНТРАЛИЗАЦИИ СИСТЕМЫ.
схема внутренней структуры (сервер приложения, модуль
хранения данных, толстый клиент в виде нативного приложения,
публичное веб-приложение, панель администрирования, мобильные
приложения, сервер отчетов) и внешних, смежных систем (другие
системы заказчика, почтовый сервер SMTP, сервис SMS-рассылки,
банк-эквайер, онлайн-касса, картографический сервис, адресный
сервис, сервис проверки адресов электронной почты и т.п.);
требования к элементам приведенной структуры
Для наглядности желательно приложить структурную схему системы с
обозначением ее частей и смежных систем

102.

2. ТРЕБОВАНИЯ К СПОСОБАМ И СРЕДСТВАМ СВЯЗИ ДЛЯ
ИНФОРМАЦИОННОГО ОБМЕНА МЕЖДУ КОМПОНЕНТАМИ
СИСТЕМЫ.
3. ТРЕБОВАНИЯ К ХАРАКТЕРИСТИКАМ ВЗАИМОСВЯЗЕЙ
СОЗДАВАЕМОЙ СИСТЕМЫ СО СМЕЖНЫМИ СИСТЕМАМИ,
ТРЕБОВАНИЯ К ЕЕ СОВМЕСТИМОСТИ, В ТОМ ЧИСЛЕ
УКАЗАНИЯ О СПОСОБАХ ОБМЕНА ИНФОРМАЦИЕЙ
(АВТОМАТИЧЕСКИ, ПЕРЕСЫЛКОЙ ДОКУМЕНТОВ, ПО
ТЕЛЕФОНУ И Т.П.)
В них следует привести следующие сведения:
перечень передаваемых сведений, хотя бы общее описание,
чтобы вообще понять, зачем мы интегрируемся с конкретной системой;
описание протоколов (или ссылки на описание), особенно в
случае присоединения устройств;
структура локальных сетей;
требуемая скорость передачи данных;
применение мобильного интернета или WiFi;
описание неавтоматизированных способов передачи данных.

103.

4. ТРЕБОВАНИЯ К РЕЖИМАМ
ФУНКЦИОНИРОВАНИЯ СИСТЕМЫ.
Режимы функционирования могут иметь несколько классификаций:
по готовности к эксплуатации: штатный режим, аварийный режим, режим технического
обслуживания (например, в аварийном режиме должна присутствовать заставка на сайте, нагрузка
переводиться на другой сервер, выводиться особые сообщения при обращении к данной системе по API,
в режиме технического обслуживания некоторые функции могут быть доступны);
по готовности к эксплуатации частей системы: как должна функционировать система, если,
например, недоступен один из внешних или внутренних сервисов;
по графику работы: 24/7 или пятидневка (от этого зависит как минимум работа технической
поддержки);
по возможности изменения данных: режим просмотра или редактирования;
по уровню доступа к данным и операциям системы: режим авторизованного пользователя,
режим администратора, гостевой режим (для неавторизованных пользователей);
по средству доступа к системе: через веб-приложение, через толстый клиент, через
мобильное приложение (согласитесь, что функциональность может несколько отличаться, эти
ограничения можно описать здесь);
по виду взаимодействия: диалоговый (через интерфейс), взаимодействие посредством
изменения настроек в конфигурационных файлах или иным способом, неавтоматизированный
(например, информация передается другому сотруднику, который вносит данные в систему,
производится ручной съем показаний);
по степени автоматизации: автоматический или полуавтоматический режим, «режим
советчика»;
по видимости приложения: диалоговый или фоновый режим;
по возможному воздействию на систему: штатный, обучающий, тестовый режимы.

104.

5. ТРЕБОВАНИЯ ПО ДИАГНОСТИРОВАНИЮ
СИСТЕМЫ.
Требования по постоянному или периодическому
диагностированию следует предъявлять к системам,
основанным на микросервисной (разнесенной) архитектуре,
системам, в состав которых входит оборудование: датчики,
системы управления, терминалы и т.д. Конечно, если
разрабатывается только программное обеспечение, которое
работает на одном сервере, указанные требования излишни:
и так узнаете, если что-то перестанет работать.

105.

6. ПЕРСПЕКТИВЫ РАЗВИТИЯ,
МОДЕРНИЗАЦИИ СИСТЕМЫ.
в данном разделе можно записать все
перспективы модернизации, но особо
отметить те, которые точно повлияют на
архитектуру.

106.

ПУНКТ 4.1.2. «ТРЕБОВАНИЯ К ЧИСЛЕННОСТИ
И КВАЛИФИКАЦИИ ПЕРСОНАЛА» /П. 2.6.1.2
ГОСТ 34.602-89/
Поэтому в ТЗ указываются требования к персоналу и его квалификации.
Если вы автоматизируете конкретную производственную линию, то
численность персонала вам известна. Но во многих случаях она зависит
от объема выполняемой работы. Следовательно, укажите должности,
график работы, описание деятельности (для назначения прав доступа) и
приблизительную квалификацию.
Понятно, что требования к персоналу часто устанавливаются
заказчиком, зачем их тогда приводить? Но, во-первых, мы уже говорили,
что ТЗ составляется для обеих сторон, а во-вторых, так исполнитель
будет защищен: не выполнено условие по подбору персонала, чего же
тогда заказчик хочет, если система не внедрена?

107.

ПУНКТ 4.1.3. «ТРЕБОВАНИЯ К ПОКАЗАТЕЛЯМ
НАЗНАЧЕНИЯ» /П. 2.6.1.3 ГОСТ 34.602-89/
В данном подразделе часто пишется что душе угодно, поскольку перечень возможных
показателей отсутствует в тексте ГОСТа, а найти их в открытых источниках практически
невозможно. Обратите внимание, что приведенные в ГОСТе «степень приспособляемости»,
«пределы модернизации» и «вероятностно-временные характеристики», во-первых,
указываются для АСУ (автоматизированной системы управления) и, во-вторых, их
достаточно сложно измерить.
показателям назначения можно отнести:
количество одновременно работающих в системе пользователей;
количество одновременно выполняемых запросов к серверу;
количество проводимых (регистрируемых) за единицу времени транзакций;
время отклика при разном количестве единовременных запросов и работающих
пользователей, при разном количестве обрабатываемых данных (особенно при поиске и
агрегации в отчетах);
объем хранимых данных (в частности, изображений и видеозаписей);
время подключения дополнительных вычислительных мощностей при
достижении предельной нагрузки;
время подключения дополнительных мощностей при значительном увеличении
объема хранимых данных.

108.

ПУНКТ 4.1.4. «ТРЕБОВАНИЯ К НАДЕЖНОСТИ»
/П. 2.6.1.4 ГОСТ 34.602-89/
В тексте ГОСТа достаточно подробно описывается, что необходимо
указывать в требованиях к надежности. Тем не менее, для понимания
подхода к обеспечению надежности, заложенного в данном стандарте,
следует изучить ГОСТы серии 27. Для начала стоит ознакомиться с
терминологией: этого будет достаточно для понимания самого понятия
надежности, как она измеряется и чем обеспечивается. Поэтому
обращайтесь к ГОСТ 27.002-89. «Надежность в технике. Основные
понятия. Термины и определения».

109.

ПУНКТ 4.1.9. «ТРЕБОВАНИЯ К ЗАЩИТЕ
ИНФОРМАЦИИ ОТ
НЕСАНКЦИОНИРОВАННОГО ДОСТУПА» /П.
2.6.1.9 ГОСТ 34.602-89/
1. Средства, обеспечиваемые создаваемым
программным продуктом.
2. Меры, обеспечиваемые системным
администратором.
3. Меры физической защиты.
4. Общие организационные меры.
5. Меры, принимаемые в процессе
разработки программного обеспечения

110.

1. СРЕДСТВА ЗАЩИТЫ, ОБЕСПЕЧИВАЕМЫЕ
СОЗДАВАЕМЫМ ПРОГРАММНЫМ
ПРОДУКТОМ:
Требование по наличию пароля для пользователей,
особенно для пользователей с ролью администратора.
Реализация ролевой модели доступа.
Требование по применению ключей электронной
подписи для выполнения особо важных операций.
Вынесение программных компонентов,
ответственных за взаимодействие с внешними системами, в
демилитаризованную зону (DMZ).
Обеспечение регистрации событий и действий
пользователей.

111.

2. МЕРЫ, ОБЕСПЕЧИВАЕМЫЕ СИСТЕМНЫМ
АДМИНИСТРАТОРОМ:
Применение межсетевых экранов (файерволов).
Документирование и мониторинг используемых служб и протоколов.
Конфигурирование демилитаризованной зоны (DMZ).
Контроль выполнения правил использования портативных компьютеров:
подключение к внутренней сети, использование межсетевых экранов.
Отключение учетных записей по умолчанию перед подключением в сеть
оборудования и систем.
Настройка устройств беспроводного доступа: установка паролей и изменение
настроек доступа, установленных по умолчанию.
Установка обновлений, устраняющих выявленные уязвимости оборудования и
программного обеспечения.
Обеспечение безопасности при удаленном доступе в систему (например,
использование VPN).
Установка, обновление и мониторинг работы антивирусного программного
обеспечения.

112.

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

113.

3. МЕРЫ ФИЗИЧЕСКОЙ ЗАЩИТЫ:

Ограничение доступа в критические
помещения.

Отключение сетевых разъемов в
общедоступных местах.

Установка камер видеонаблюдения за
критически важными помещениями.

114.

4. ОБЩИЕ ОРГАНИЗАЦИОННЫЕ МЕРЫ:
Утверждение политики безопасности и проведение
периодического обучения персонала правилам информационной
безопасности.
Внедрение процедуры реагирования на инциденты, связанные с
нарушением безопасности.
Проверка на вывод в экранных формах или отчеты
конфиденциальных данных.
Выдача бейджей всем посетителям, сопровождение посетителей
при нахождении в критически важных помещениях.
Всесторонняя проверка принимаемых на работу сотрудников.
Обеспечение безопасности со стороны организацийпоставщиков услуг, связанных с программным и аппаратным
обеспечением.

115.

5. МЕРЫ, ПРИНИМАЕМЫЕ В ПРОЦЕССЕ
РАЗРАБОТКИ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ:
Контроль ответственными лицами внесения изменений в
программный код, проверка кода на соблюдение правил
информационной безопасности (контроль переполнения буфера,
корректная обработка ошибок, проверка на межсайтовый скриптинг,
на ошибки механизмов доступа и т.п.)
Применение стойкой криптографии.
Применение правил безопасности для общедоступных вебприложений.
Разработка процедуры отмены для каждого изменения.
Документирование внесение изменений.

116.

ЭТАПЫ ПРОЕКТИРОВАНИЯ

117.

ЛЕКЦИЯ 1. ВЕДЕНИЕ В СИСТЕМУ
ТРЕБОВАНИЙ К ИНФОРМАЦИОННЫМ
СИСТЕМАМ.

118.

Литература
Вигерс Карл Разработка требований к программному
обеспечению/Пер, с англ. — М.: Издательство-торговый дом
≪Русская Редакция≫, 2004. —576с.: ил.
Алистер Коберн. Современные методы описания
функциональных требований к системам. М.: издательство
«Лори», 2002. – 263 с.
Мацяшек Лешек. Анализ требований и проектирование систем.
Разработка информационных :с Диалектика-Вильямс
Элизабет Хал, Кен Джексон, Джереми Дик. Разработка и
управление требованиями. Практическое руководство
пользователя.
Эдвард Йордон. Путь камикадзе https://libking.ru/books/sci-/scibusiness/68377-8-edvard-yordon-put-kamikadze-smertelnyymarsh.html#book
Сбор и анализ требований к программному продукту. Версия
1.03 Автор: Химонин Юрий program manager компании Acronis

119.

Определение понятия требования
Важность требований
Классификация требований.
Анализ требований (требования к
требованиям)

120.

ОПРЕДЕЛЕНИЯ
Требование – это условие или возможность, которой должна
соответствовать система
1. условия или возможности, необходимые пользователю для
решения проблем или достижения целей;
2. условия или возможности, которыми должна обладать система
или системные компоненты, чтобы выполнить контракт или
удовлетворять стандартам, спецификациям или другим
формальным документам;
3. документированное представление условий или возможностей
для пунктов 1 и 2 (конец цитаты).
Требования – это исходные данные, на основании которых
проектируются и создаются автоматизированные информационные
системы.

121.

122.

ЭТАПЫ СБОРА И АНАЛИЗА
ТРЕБОВАНИЙ
Определение концепции продукта.
Сбор требований.
Анализ требований.
Проектирование системы

123.

ПОРЯДОК ФОРМИРОВАНИЯ ТРЕБОВАНИЙ
Видение
Выявление требований;
Классификация и спецификация требований;
Расширенный анализ требований (моделирование и
прототипирование);
Документирование требований;
Проверка требований;
Управление требованиями;
Совершенствование процесса работы с требованиями.

124.

Rational Unified Process
Analyze the Problem (Анализ проблемы),
Understand Stakeholder Needs (Понимание потребностей
совладельцев),
Define the System (Определение системы),
Manage the Scope of the System (Управление контекстом
системы),
Refine the System Definition (Уточнение определения
системы).
Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором
необходимо описать артефакты, полученные в процессе специфицирования требований.
Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:
• Традиционный шаблон SRS со структурированными функциональными требованиями
по функциям Системы, максимально похож на 830 стандарт.
• Упрощенный шаблон SRS со структурированными функциональными требованиями в
виде вариантов использования (use cases)

125.

ВИДЕНИЕ В RUP
Формулировка проблем.
Идентификация совладельцев
Определение границ системы
Идентификация ограничений
Формулировка постановки задач
Определение возможностей системы
Оценка результатов

126.

AGILE AGILE (AGILE SOFTWARE DEVELOPMENT,
ОТ АНГЛ. AGILE – ПРОВОРНЫЙ) – ЭТО СЕМЕЙСТВО
«ГИБКИХ» ПОДХОДОВ К РАЗРАБОТКЕ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.
“Working software over comprehensive
documentation”. Поэтому в Agile документации
отводится совсем мало места.
Разработать АС без ТЗ можно (используя
техники/рекомендации Agile), но вот в дальнейшем
сопровождать — невозможно. Поэтому сразу
задумайтесь, как вы будете писать ТЗ и другую
документацию, при разработке ПО по Agile.
https://habr.com/ru/company/edison/blog/313410/

127.

ИНТЕГРАЦИЯ В ЖИЗНЕННЫЙ ЦИКЛ
РАЗРАБОТКИ ПРОДУКТА

128.

КОНЦЕПЦИЯ
Этап определения концепции продукта обычно выделяется в отдельный проект
или является первым этапом в разработке продукта.
На этапе определения концепции считается, что идея уже родилась, еѐ лишь
надо развить и формализовать, а потому этот процесс может занимать от недели
до месяца. Для проектов, с общей продолжительностью 6–12 месяцев, это срок
обычно около 2–3 недель.
После определения концепции проекта уже можно экспертно оценить
необходимые ресурсы для выполнения проекта и срока, за который он будет
выполнен, а также его прибыльность.

129.

РЕЗУЛЬТАТ КОНЦЕПЦИИ
Product Vision Document -PVD (если продукт разрабатывается под
заказ)
или
Marketing Requirement Document – MRD (если продукт предназначен
для открытого рынка)
По окончании разработки концепции продукта делается вывод о
целесообразности разработки продукта. В случае принятия
положительного решения, создается устав проекта по разработке
продукта. PVD/MRD является входным документом устава проекта,
описывающим содержание работ по проекту.

130.

СБОР И АНАЛИЗ ТРЕБОВАНИЙ
для интеграционных проектов — этот
процесс может занимать до половины
человеко-часов от общей работы над
проектом, для проекта автоматизации
отдельных бизнес процессов только 5–7%.
Продолжительность анализа требований, как
правило, занимает в несколько раз меньше
времени, чем сбор требований и в большей
степени зависит от требований к
документообороту, принятому в компании.

131.

ПОСЛЕДОВАТЕЛЬНОСТЬ ЗАДАЧ,
ВЫПОЛНЯЕМЫХ НА ЭТАПЕ СБОРА БИЗНЕС
ТРЕБОВАНИЙ.

132.

ОПРЕДЕЛЕНИЕ СТИМУЛОВ
ПРОБЛЕМЫ, БЛАГОПРИЯТНЫЕ
ВОЗМОЖНОСТИ, ТРЕБОВАНИЙ БИЗНЕСА:
Потребность рынка
Производственная необходимость
Потребность заказчика
Технический прогресс
Юридические ограничения или нормы

133.

ОПРЕДЕЛЕНИЕ ЦЕЛЕЙ ПРОДУКТА И
КРИТЕРИЕВ УСПЕХА
Финансовые:
Освоить Х% рынка за Y месяцев.
Увеличить сектор рынка в стране X на Y% за Z месяцев.
Достигнуть объема продаж X единиц или дохода, равного $Y, за Z
месяцев.
Нефинансовые:
Достигнуть показателя удовлетворения покупателей, равного, по
крайней мере, X, в течение Y месяцев со времени выпуска товара.
Увеличить производительность обработки транзакций на Х% и
снизить уровень ошибок данных до величины не более Y%.

134.

ОПРЕДЕЛЕНИЕ ЦЕЛЕВОГО СЕГМЕНТА
РЫНКА
Рынок домашних пользователей
Рынок корпоративных пользователей.
1. SMB (Small and Medium Business) от
1 до 250 сотрудников
2. Large — компании, насчитывающие
250–2500 сотрудников.
3. Corporation — корпорации с числом
сотрудников более 2500.

135.

ОПРЕДЕЛЕНИЕ ПОТРЕБНОСТЕЙ КЛИЕНТОВ
ИЛИ РЫНКА (ОТ СЦЕНАРИЕВ
К ТРЕБОВАНИЯМ)
Сценарий — это совокупность всех процессов, в которых будет
участвовать продукт, а также описание окружения, в котором его
планируется использовать.
Каждый сценарий должен содержать:
Имя конкретного заказчика или его профиль (в качестве заголовка).
Информацию обо всех типах пользователей, которые будут работать
с продуктом.
Все процессы, которые будут затрагивать продукт.
Операционная среда, в которой будет использоваться продукт.
Требования к дизайну: операционная система; приложения, с
которыми интегрируется, форматы ввода вывода.
Приоритет. Зависит от того, насколько важен этот заказчик или как
много покупателей будут попадать под профиль клиента, описанного
в сценарии.

136.

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

137.

ОБЗОР КОНКУРЕНТОВ
1.
2.
Для выпуска продукта на рынок требуется
придать ему уникальность, определить,
чем он лучше других, почему именно его
будут покупать?
Использовать наиболее удачные решения,
реализованные в конкурирующих
продуктах, и исключить неудачные

138.

СТРУКТУРА ОБЗОРА КОНКУРЕНТОВ
1. Конкурентное положение на рынке.
2. Список конкурентов (Резюме по каждому
конкуренту).
3. Список проблем, которые призваны
решать продукты.
4. Список возможностей продуктов.

139.

В ПРОЦЕССЕ СОЗДАНИЯ ОБЗОРА ТРЕБУЕТСЯ
ПРОЙТИ ЭТАПЫ,
1. Определить список конкурентов на рынке и выделить
лидеров.
2. Узнать цену и способ доставки конкурентов.
3. Составить список проблем, которые решает каждый
конкурент.

140.

СОСТАВИТЬ СПИСОК ВОЗМОЖНОСТЕЙ.
Здесь нужно описать все важные возможности, которые были
реализованы в конкурентных продуктах для удовлетворения проблем,
описанных в предыдущем пункте. На основе этого списка можно узнать,
как хорошо продукт решает заявленные проблемы, какие у него сильные
и слабые стороны.

141.

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

142.

СОЗДАНИЕ ОБРАЗА РЕШЕНИЯ
На этом этапе определяются все основные
характеристики, которыми должен обладать
будущий продукт, чтобы достичь ранее
поставленных целей. А на основе экспертной
оценки уже могут быть определены
ожидаемые сроки и бюджет продукта.

143.

СПИСОК ВОЗМОЖНОСТЕЙ БУДУЩЕГО
ПРОДУКТА
Нефункциональные возможности:
Имя возможности
Приоритет возможности.
Наличие этой функции у конкурентов (для каждого конкурента).
Краткое описание возможности.
Примечание для конкурентов.
Основные функции, которые требуется реализовать
в продукте. Каждый элемент списка возможностей должен содержать:
Имя функции, которую требуется реализовать в продукте.
Приоритет.
Наличие у конкурентов (желательно для каждого из конкурентов)
Краткое описание (если требуется).
Отметки о конкурентах.
Экспертную оценку необходимого времени и затрат, связанных с
реализацией
функциональности

144.

ШАБЛОН ОБРАЗА ПРОДУКТА
«для» — целевая аудитория покупателей;
«который» — положение о потребностях или возможностях;
«этот» — имя продукта;
«является» — категория продукта;
«который» — ключевое преимущество, основная причина для
покупки или использования;
«в отличие от» — основной конкурирующий продукт, текущая
система или текущий бизнес-процесс;
«наш продукт» — положение об основном отличии и преимуществе
нового
продукта.

145.

СБОР ТРЕБОВАНИЙ
Определение основных профилей пользователей
Профили пользователей явно или неявно уже
должны содержаться в сценариях

146.

ФОРМИРОВАНИЕ ИНИЦИАТИВНОЙ ГРУППЫ
Когда определены профили пользователей продукта, следует найти
людей, соответствующих этим профилям и желающих помочь вам в
разработке продукта. Для проектов под заказ это достаточно простая
задача — нужно выбрать одного или двух наиболее грамотных и
инициативных людей для каждого профиля. В случае разработки
проекта для открытого рынка вам придется искать таких людей среди
коллег и знакомых. В последнее
время эту задачу значительно облегчили социальные сети — блог на
любую профильную тему сейчас можно найти практически на любом
языке, правда, наладить контакт с его авторами не всегда возможно.

147.

СБОР ПОЛЬЗОВАТЕЛЬСКИХ ИСТОРИЙ
Пользовательская история — это вариант использования будущего
продукта в конкретной ситуации с целью достижения измеримого
результата.
Пользовательские истории могут содержать как сложные инструкции с
ответвлениями, так и конкретные примеры. Если действия
пользователей продиктованы скорее здравым смыслом, нежели
инструкцией, то пользовательская история должна содержать пример
реальной ситуации, а их систематизация и оптимизация должна быть
оставлена на потом.
Если же бизнес процессы, которые автоматизирует продукт, строго
формализованы, то пользовательская история должна содержать
алгоритмы действий продукта или людей, работающих с ней.

148.

СОДЕРЖАНИЕ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ
(ПОЛУЖИРНЫМ ШРИФТОМ ПОМЕЧЕНЫ
ОБЯЗАТЕЛЬНЫЕ)
Идентификатор («Уникальный номер» плюс «Имя»).
Источник/Автор.
Дата создания.
Профиль пользователя (Действующее лицо/Актер в UML).
Приоритет.
Частота использования
Родительское бизнес требование.
Предусловие
Цель/ Результат
Последовательность действий.

149.

ЗАЧЕМ? ЧТО? И КАК?
Самая главная ошибка, которую делают при сборе
требований к продуктам, это формирование образа
продукта на основе ответов на вопрос «Что должен делать
продукт» или еще хуже «Как должен работать продукт».
Целью же сбора требований, является получение ответа на
вопрос — «Для чего нужен продукт». А потому,
единственный вопрос, который должен задаваться
пользователю.
Требования должны быть продиктованы бизнесом и быть
нацелены на достижение реальных и измеряемых
результатов. Одним словом реализация требования должна
приносить пользу, а не являться самоцелью. — это «Зачем?».

150.

АНАЛИЗ ТРЕБОВАНИЙ
Чем больше продукт, тем более важной
является стадия анализа.
Основной целью анализа требований
является их систематизация и избавление
от дублируемых данных. Это достигается
за счет разделения пользовательских
историй на отдельные пакеты по
функциональному признаку и их
иерархической структуризации.

151.

ВЫДЕЛЕНИЕ ПОЛЬЗОВАТЕЛЬСКИХ
ИСТОРИЙ В ОТДЕЛЬНЫЕ ПАКЕТЫ
Главная цель формирования пакетов — упростить доступ к
нужным данным, за счет того, что все варианты
использования относящихся к определенной
функциональности можно будет увидеть на одной странице.
Для того чтобы достичь поставленной цели требуется
добиться того, чтобы в один пакет входило 20–30
пользовательских историй.
Пакеты формируются из пользовательских историй,
которые описывают схожую деятельность или способ
достижения схожего результата. Как правило, всего они
подчинены одному бизнес требованию. Работу над этапом
анализа можно считать законченной, когда вы выделили все
пользовательские истории в отдельные пакеты.

152.

ДВА ПОДХОДА: ВАРИАНТЫ
ИСПОЛЬЗОВАНИЯ ИЛИ СПЕЦИФИКАЦИИ
ТРЕБОВАНИЙ
Как правило, у всех пользовательских историй в пакете есть
одна или несколько главных целей, и есть история, которая
описывает наиболее простой способ их достижения. Такая
история называется — базовой, а описание еѐ действия —
базовый путь. Остальные истории описывают
альтернативный способ достижения результата или
содержат дополнительные действия для достижения
специфического результата и по большому счету являются
дополнениями к базовой истории.
Главным критерием определения базового варианта
использования является наличие общих со всеми
остальными вариантами использования действий (сродни
базовому классу в ООП).

153.

ПРИМЕР ДИАГРАММЫ USE CASE С
ПРИОРИТЕТАМИ

154.

155.

ТРЕБОВАНИЯ

156.

Классификация требований
Бизнес-требования (business
requirements)
Требования пользователей
(userequirements)
Функциональные требования (functional
requirements)
Системные требования (system
requirements)

157.

НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
Внешние интерфейсы (External Interfaces),
Атрибуты качества (Quality Attributes),
Ограничения (Constraints).

158.

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

159.

ОСНОВНЫЕ АТРИБУТЫ КАЧЕСТВА
Применимость,
Надежность,
Производительность,
Эксплуатационная пригодность.

160.

СТРУКТУРИЗАЦИЯ И НАЗНАЧЕНИЕ
ПРИОРИТЕТОВ
В процессе структурирования нужно выделить основные
требования и дополнения к ним. Требования удобно
отображать в виде дерева.
Разбивая требования на отдельные элементы, основным
критерием должна быть возможность реализации этих
требований отдельно друг от друга (реализовать первое и не
реализовать второе). Если требования столь сильно зависят
друг от друга, что должны быть реализованы только вместе,
лучше их объединить.
Как только все требования структурированы, следует
назначить им приоритет. Наилучшим методом является
комбинирование унаследованного приоритета (от
родительских сценариев) с приоритетом требования внутри
сценария.

161.

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

162.

ПОИСК ВЗАИМОИСКЛЮЧАЮЩИХ
ПОЛЬЗОВАТЕЛЬСКИХ ИСТОРИЙ С ЦЕЛЬЮ ИХ
ИСКЛЮЧЕНИЯ
Взаимоисключающие требования достаточно частое явление для
крупного продукта, так как у него много пользователей, а значит много
мнений
1. Ошибка в пользовательской истории.
2. Разные взгляды на одну и ту же проблему
Можно выбрать «более правильную» точку зрения и оставить только еѐ.
Такое решение, как правило, можно принять на основе приоритетов
историй.
Определить дополнительные условия, при которых обе конфликтующие
истории будут выполняться в рамках одной системы. Это решение
может значительно усложнить систему, но в большинстве случаев, оно
сделает еѐ более гибкой (она будет ложиться не только на процессы
директора, но и подчиненных).

163.

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

164.

ПРЕОБРАЗОВАНИЕ ДИАГРАММЫ
ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ В СПИСОК
ПОЛЬЗОВАТЕЛЬСКИХ ТРЕБОВАНИЙ
Необходимо преобразовать диаграмму вариантов
использования в нумерованный список
Все элементы, которые не являются включениями или
расширениями, должны стать главными узлами списка.
Элементы, являющиеся расширениями, должны стать
дочерними элементами списка по отношению к тем, кого
они расширяют. Если элемент имеет несколько
родителей, то следует воспользоваться средствам
трассировки (рекомендуется) или скопировать элемент в
каждую ветку (с пометкой, что это копия).к.

165.

СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ
Для нормальной разработки нужен список требований,
который однозначно идентифицирует потребности
пользователей и не имеет множественных повторений,
которые присутствуют с избытком в пользовательских
историях (если не произвести структурирование историй,
описанное в предыдущем подходе). Кроме этого, для более
гибкого проектирования необходим как можно более
детализированный (раздробленный) список.

166.

ИЗВЛЕЧЕНИЕ ТРЕБОВАНИЙ ИЗ
ПОЛЬЗОВАТЕЛЬСКИХ ИСТОРИЙ
На этом этапе нужно выделить все уникальные результаты
пользовательских историй в отдельные требования. Если результат
истории оказался уникальным, то вы должны преобразовать его в
требование (просто скопировать его тело, используя повелительное
наклонение). Если же похожий результат уже был вынесен в требование
в рамках другой
пользовательской истории, то надо проанализировать их возможные
отличия и, если они есть — модернизировать существующее требование
или создать дополнительное дочернее требование/ограничение.
Приоритет требования должен быть унаследован от родительской
истории с максимальным приоритетом.
В результате этой работы должен быть получен древовидный список
требований. Каждое требование списка должно быть самостоятельным
и не являться контейнером (структурной единицей для хранения
дочерних элементов). Требования должны быть приоритезированы,
причем дочернее требование не может иметь больший приоритет, чем
родительское требование (которое оно дополняет).

167.

ДРОБЛЕНИЕ ТРЕБОВАНИЙ
Для того чтобы иметь максимальную гибкость в процессе
проектирования функциональности необходимо разбить требования на
неделимые элементы.
Результатом этого процесса должен быть список требований, каждый
элемент которого должен являться:
Самостоятельным требованием — может расширять, а следовательно
и зависеть от родительского требования, но не должно быть зависимо от
дочерних требований или требований того же уровня.
Это означает, что реализация требования не должна требовать
реализации каких-либо дочерних требований или требований того же
уровня. Если требования связаны настолько сильно, что могут быть
реализованы только вместе — их нужно объединить.
Неделимыми требованиями — в противоположность предыдущему
критерию,
требование не должно описывать сразу несколько проблем, которые
можно решать порознь.
Благодаря выполненной работе, приобретается возможность
запланировать реализацию наиболее значимых требований на начало
разработки, а низкоприоритетных -на конец.

168.

ПРЕОБРАЗОВАНИЕ ДИАГРАММЫ
ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ В СПИСОК
ПОЛЬЗОВАТЕЛЬСКИХ ТРЕБОВАНИЙ
Все элементы, которые не являются
включениями или расширениями, должны стать
главными узлами списка.
Элементы, являющиеся расширениями, должны
стать дочерними элементами списка по
отношению к тем, кого они расширяют. Если
элемент имеет несколько родителей, то следует
воспользоваться средствам трассировки
(рекомендуется) или скопировать элемент в
каждую ветку (с пометкой, что это копия).

169.

СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ
Для нормальной разработки нужен список требований,
который однозначно идентифицирует потребности
пользователей и не имеет множественных повторений,
которые присутствуют с избытком в пользовательских
историях (если не произвести структурирование историй,
описанное в предыдущем подходе). Кроме этого, для более
гибкого проектирования необходим как можно более
детализированный (раздробленный) список.

170.

ИЗВЛЕЧЕНИЕ ТРЕБОВАНИЙ ИЗ
ПОЛЬЗОВАТЕЛЬСКИХ ИСТОРИЙ
На этом этапе нужно выделить все уникальные результаты
пользовательских историй в отдельные требования. Если результат
истории оказался уникальным, то вы должны преобразовать его в
требование (просто скопировать его тело, используя повелительное
наклонение). Если же похожий результат уже был вынесен в требование
в рамках другой
пользовательской истории, то надо проанализировать их возможные
отличия и, если они есть — модернизировать существующее требование
или создать дополнительное дочернее требование/ограничение.
Приоритет требования должен быть унаследован от родительской
истории с максимальным приоритетом.
В результате этой работы должен быть получен древовидный список
требований. Каждое требование списка должно быть самостоятельным
и не являться контейнером (структурной единицей для хранения
дочерних элементов).

171.

ДРОБЛЕНИЕ ТРЕБОВАНИЙ
Для того чтобы иметь максимальную гибкость в процессе проектирования
функциональности необходимо разбить требования на неделимые элементы.
Результатом этого процесса должен быть список требований, каждый элемент
которого должен являться:
Самостоятельным требованием — может расширять, а следовательно и
зависеть от родительского требования, но не должно быть зависимо от
дочерних требований или требований того же уровня. Это означает, что
реализация требования не должна требовать реализации каких-либо
дочерних требований или требований того же уровня. Если требования
связаны настолько сильно, что могут быть реализованы только вместе — их
нужно объединить.
Неделимыми требованиями — в противоположность предыдущему
критерию, требование не должно описывать сразу несколько проблем,
которые можно решать порознь.

172.

ЭКСПЕРТИЗА ТРЕБОВАНИЙ К ДИЗАЙНУ
Экспертиза операционной среды продукта
Экспертиза нефункциональных
требований
Утверждение изменений требований к
дизайну.

173.

ПРОЕКТИРОВАНИЕ
В процессе проектирования группой разработки продукта должно быть
создано «Техническое задание» (Functional Specification), на основе
которого будет производиться разработка и тестирование продукта. Это
документ должен содержать следующие элементы:
Требования к продукту уровня системы.
Модель взаимодействия с пользователем:
o Диаграммы вариантов использования продукта.
o Потоки выполнения вариантов использования.
o Ограничения интерфейсов.
o GUI макеты.
o CLI/ API спецификации.
Архитектура продукта.
Техническая информация.

174.

ОПРЕДЕЛЕНИЕ ФУНКЦИОНАЛЬНЫХ
ТРЕБОВАНИЙ К ПРОДУКТУ УРОВНЯ
СИСТЕМЫ

175.

СВОЙСТВА ТРЕБОВАНИЙ
полнота,
ясность,
корректность,
согласованность,
верифицируемость,
необходимость,
полезность при эксплуатации,
осуществимость,
модифицируемость,
трассируемость,
упорядоченность по важности и стабильности,
наличие количественной метрики.

176.

МЕТОДОЛОГИИ И СТАНДАРТЫ,
РЕГЛАМЕНТИРУЮЩИЕ РАБОТУ С
ТРЕБОВАНИЯМИ

177.

ОСНОВНЫЕ СТАНДАРТЫ, МЕТОДОЛОГИИ И СВОДЫ ЗНАНИЙ,
ГДЕ УПОМИНАЕТСЯ ТЗ ИЛИ SRS (SOFTWARE (OR SYSTEM)
REQUIREMENTS SPECIFICATION):
• ГОСТ 34
• ГОСТ 19
• IEEE STD 830-1998
• ISO/IEC/ IEEE 29148-2011
• RUP
• SWEBOK, BABOK и пр.

178.

ГОСТ 34.602-89 ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ
АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ
Регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят
ПО, аппаратное обеспечение, люди.
Разделы:
1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта
автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки работают с ПО, и автоматизируемые процессы.
При разработке ТЗ для государственных проектов Заказчики, как правило,
требуют соблюдение именно этого стандарта.

179.

ГОСТ 19.ХХХ ЕДИНАЯ СИСТЕМА
ПРОГРАММНОЙ ДОКУМЕНТАЦИИ (ЕСПД)
Согласно ГОСТ 19.201-78 Техническое задание, требования
к содержанию и оформлению техническое задание должно
вклю
1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения

180.

СТАНДАРТ 830-1998 — IEEE
RECOMMENDED PRACTICE FOR
SOFTWARE REQUIREMENTS
SPECIFICATIONS
Описывается содержание и качественные
характеристики правильно составленной
спецификации требований к программному
обеспечению (SRS) и приводится несколько
шаблонов SRS.

181.

СОСТАВ ТЗ ПО 830-1998 — IEEE
1. Введение
1. Назначение, 2. Область действия, 3. Определения, акронимы и сокращения. 4.
Ссылки. 5. Краткий обзор
2. Общее описание
1. Взаимодействие продукта (с другими продуктами и компонентами). 2. Функции
продукта (краткое описание). 3. Характеристики пользователя. 4. Ограничения. 5.
Допущения и зависимости
3. Детальные требования (могут быть организованы по разному, н-р, так)
1. Требования к внешним интерфейсам: 1. Интерфейсы пользователя. 2. Интерфейсы
аппаратного обеспечения. 3. Интерфейсы программного обеспечения. 4. Интерфейсы
взаимодействия
2. Функциональные требования
3. Требования к производительности
4. Проектные ограничения (и ссылки на стандарты)
5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
6. Другие требования
4. Приложения
5. Алфавитный указатель

182.

ISO/IEC/ IEEE 29148-2011
содержит два шаблона спецификации требований:
• System requirements specification (SyRS)
определяет высокоуровневые требования к системе с точки зрения
предметной области, а также информацию об общей цели системы, ее
целевой среде и ограничениях, допущениях и нефункциональных
требованиях. Она может включать в себя концептуальные модели,
спроектированные для иллюстрации содержания системы, сценариев
использования, основных сущностей предметной области, данных,
информаций и рабочих процессов. Из определения следует, что это
аналог ТЗ, описанного в ГОСТ 34.
• Software requirements specification (SRS)
SRS это спецификация требований для определенного программного
изделия, программы или набора программ (продукт), которые
выполняют определенные функции в конкретном окружении. Из
определения следует, что это аналог ТЗ, описанного в ГОСТ 19

183.

SWEBOK
GUIDE TO THE SOFTWARE ENGINEERING BODY OF KNOWLEDGE
(SWEBOK GUIDE)
Requirements Elicitation (Извлечение требований),
Requirements Analysis (Анализ требований в узком смысле),
Requirements Specification (Специфицирование требований),
Requirements Validation (Проверка требований).
описывает общепринятые знания о
разработке программного обеспечения.

184.

ВЫЯВЛЕНИЕ ТРЕБОВАНИЙ.
ОС М(ОС) М(АИС) М’(АИС) М’’(АИС) ’’(АИС).

185.

СТРАТЕГИИ ВЫЯВЛЕНИЯ ТРЕБОВАНИЙ
Интервью
Анкетирование
Наблюдение
Самостоятельное описание требований
Совместные семинары
Прототипирование

186.

СОВМЕСТНЫЕ СЕМИНАРЫ JAD
Ведущий
Секретарь
Заказчики
Разработчики

187.

ЛЕКЦИЯ 3.
АКТОРЫ И ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ
Актор – это некто или нечто, обладающее активностью по отношению к
программной системе.
Вариант использования можно рассматривать, просто, как функцию,
реализуемую системой, иметь ценность для конечного потребителя
продукта или услуги, позволять получать КП конкретные законченные
результаты.

188.

ШАБЛОНЫ ОПИСАНИЯ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ:
Свободный формат,
Полный формат (предложенный А. Коберном),
Таблица в две колонки,
Таблица в три колонки,
Стиль RUP.

189.

ШАБЛОН ПОЛНОГО ОПИСАНИЯ ВАРИАНТА
ИСПОЛЬЗОВАНИЯ ПО А. КОБЕРНУ
Название
Контекст использования
Область действия.
Уровень
Основное действующее лицо
Участники и интересы
Предусловие
Минимальные гарантии
Гарантии успеха
Триггер.
Основной сценарий
Расширения
Список изменений в технологии и данных.
Вспомогательная информация

190.

ТАБЛИЧНЫЕ ПРЕДСТАВЛЕНИЯ ВАРИАНТА
ИСПОЛЬЗОВАНИЯ

191.

DFD - ДИАГРАММЫ

192.

ЛЕКЦИЯ 4. ПРОТОТИПИРОВАНИЕ
прояснить неясные требования к системе;
выбрать одно из различных
концептуальных
решений;
проанализировать осуществимость.

193.

ВЫБОР ВАРИАНТОВ ПО ПРОТОТИПУ
А) Сценарий последовательной обработки
требований.
А1. Система отображает реестр
требований, имеющихся во входной
очереди.
А2. Пользователь выбирает очередное
требование.
А3. Система отображает перечень
материалов требования и справочник
поставщиков.
А4. Пользователь сопоставляет каждой из
позиций требования поставщика из
справочника поставщиков.
А5. Система придаёт требованию статус
«обработано», высылает по электронной
почте автору требования уведомление.
А6. Продолжать с шага А1, пока очередь
не опустеет.
❖Б) Сценарий группировки по
материалам.
❖Б1. Система отображает позиции всех
требований и справочник поставщиков.
❖Б2. Пользователь группирует позиции
по типу (так, чтобы однотипные позиции,
❖поставляемые одним и тем же
поставщиком, находились рядом).
❖Б3. Пользователь выбирает группу
позиций и сопоставляет ей поставщика.
❖Б4. Система проверяет – не появились
ли полностью обработанные требования.
❖При положительном исходе проверки
присваивает этим требованиям статус
«обработано»
❖и высылает по электронной почте
автору требования уведомление.
❖Б5. Продолжать с шага Б1, пока очередь
не опустеет.

194.

КЛАССИФИКАЦИЯ ПРОТОТИПОВ
горизонтальные и вертикальные;
одноразовые и эволюционные;
бумажные и электронные, раскадровки

195.

196.

197.

198.

АЛГОРИТМ СОЗДАНИЯ СЦЕНАРИЯ

199.

ПРИМЕР СЦЕНАРИЯ

200.

ОБЪЕДИНЕНИЕ СЦЕНАРИЕВ

201.

202.

203.

ПОЛУЧЕНИЕ СИСТЕМНЫХ ТРЕБОВАНИЙ

204.

РАЗРАБОТКА СИСТЕМНЫХ МОДЕЛЕЙ

205.

СИСТЕМНЫЕ ТРАНЗАКЦИИ

206.

МОДЕЛИ СИСТЕМ

207.

Ориентиры
Поток событий описан правильно
В процессе выполнения прецедента менеджер по приёму заказов выбирает заказчика из
клиентской базы, определяет товарные позиции из справочника и указывает их
количество. Система отображает на мониторе наименование позиций, цену, сумму и
количество на складе. Менеджер назначает скидку и определяет порядок оплаты.
Система рассчитывает итоговую сумму.
Поток событий описан неправильно
[Менеджер должен иметь возможность видеть текущее сальдо расчётов с клиентом и
данные по последним десяти сделкам со статистикой по дисциплине соблюдения
договорных обязательств].

208.

СРЕДНИЕ ЗНАЧЕНИЯ АТРИБУТОВ И ОБЪЁМЫ
ОБЪЕКТОВ
В процессе выполнения прецедента менеджер по приёму заказов выбирает
заказчика из клиентской базы {до 10000 клиентов}, определяет товарные
позиции из справочника {товары разбиты на 10 категорий, количество
позиций в категории не превышает 500} и указывает их количество {до 100
позиций, средняя закупка – 8 позиций}. Система отображает на мониторе
наименование позиций, цену, сумму и количество на складе. Менеджер
назначает скидку и определяет порядок оплаты {на данный момент
существуют 3 варианта порядка оплаты}. Система рассчитывает итоговую
сумму.

209.

СРЕДНЯЯ ИНТЕНСИВНОСТЬ
ИСПОЛЬЗОВАНИЯ
В процессе выполнения прецедента менеджер
по приёму заказов выбирает заказчика из
клиентской базы (в 95% случаев), либо
вызывается интерфейс регистрации нового
клиента (в 5% случаев).

210.

ЛЕКЦИЯ 5. ДОКУМЕНТИРОВАНИЕ И ПРОВЕРКА
ТРЕБОВАНИЙ
Документирование требований в соответствие с ГОСТ РФ
Структура ТЗ в соответствие с ГОСТ 34.602-89
Описание требований к системе в соответствие с ГОСТ 34.602-89
Документирование требований в RUP
Документирование требований на основе IEEE Standard 830-1998
Документирование требований в MSF
Верификация и валидация.
Двусмысленность требований
"Золочение" продукта
Минимальная спецификаций
Пропуск типов пользователей
Методы и средства проверки требований
Неофициальные просмотры требований
Инспекции
Разработка тестов

211.

ГОСТ 34.602-89 «ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА
СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ»
(ТЗ НА АС). СТРУКТУРА ТЗ В СООТВЕТСТВИЕ С
ГОСТ 34.602-89
Общие сведения
Назначение и цели создания (развития) системы
Характеристика объектов автоматизации
Требования к системе
Порядок контроля и приемки системы
Требования к составу и содержанию работ по
подготовке объекта автоматизации к вводу
системы в действие,

212.

ТРИ КЛАССА ТРЕБОВАНИЙ ПО ГОСТ:
требования к системе в целом;
требования к функциям (задачам),
выполняемым системой;
требования к видам обеспечения.

213.

ДОКУМЕНТИРОВАНИЕ ТРЕБОВАНИЙ В RUP
1. Введение.
1.1. Цель.
1.2. Краткая сводка возможностей.
1.3. Определения, акронимы и сокращения.
1.4. Ссылки.
1.5. Краткое содержание.
2. Обзор системы
2.1. Обзор прецедентов.
2.2. Предположения и зависимости.
3. Описание требований
3.1. Описание вариантов использования.
3.2. Специальные требования.
Вспомогательная информация.

214.

ДОКУМЕНТИРОВАНИЕ ТРЕБОВАНИЙ НА ОСНОВЕ IEEE
STANDARD 830-1998
Введение
1.1. Назначение документа.
1.2. Поддерживаемые соглашения.
1.3. Предполагаемая аудитория и рекомендации по последовательности работы с документом для каждого класса
читателей.
1.4. Границы проекта.
1.5. Ссылки.
Общее описание.
2.1. Общий взгляд на продукт. 2.2. Особенности продукта.
2.3. Классы и характеристики пользователей.
2.4. Операционная среда.
2.5. Ограничения проектирования и реализации.
2.6 Документация для пользователей.
2.7 Предположения и зависимости
Функции системы
Для каждой i-й функции составляется следующее описание.
З.i Наименование i-й функции системы.
З.i.1 Описание и приоритеты.
З.i.2 Последовательности "воздействие - реакция".
З.i.З Функциональные требования.
4. Требования к внешнему интерфейсу
4.1 Интерфейсы пользователя
4.2 Интерфейсы оборудования
4.3 Интерфейсы ПО
4.4 Интерфейсы передачи информации
5. Другие нефункциональные требования
5.1 Требования к производительности

215.

ПРИНЦИПЫ СОЗДАНИЯ ТРЕБОВАНИЙ
используйте полные предложения, с правильной грамматикой, правописанием и
пунктуацией. Предложения и абзацы должны быть краткими и ясными;
используйте действительный залог (например, ≪Система сделает то-то≫, а не
≪Произойдет то-то≫);
последовательно используйте термины и именно так, как они определены в словаре.
Остерегайтесь синонимов и слов, близких по значению. Не следует в спецификации
требований к ПО пытаться разнообразить лексику, чтобы заинтересовать читателя;
нечеткие требования верхнего уровня следует детализировать та- ким образом, чтоб
они стали абсолютно ясны;
требования следует излагать последовательно
Вы можете использовать ≪должно≫ как синоним ≪будет≫, однако следует избегать
≪следовало бы≫, ≪может≫, ≪можно было бы≫ и аналогичных слов, из которых не
ясно, необходимо ли действие; при указании требования в форме ≪Пользователь
будет...≫ идентифицируйте определенного исполнителя (например, ≪Покупатель
будет...≫);
применяйте списки, рисунки, графики и таблицы, чтобы представить информацию
визуально.
требования, изложенные неясным языком, не поддаются проверке, поэтому избегайте
двусмысленных и субъективных терминов

216.

217.

218.

ПРИМЕР ИСПРАВЛЕНИЯ ТРЕБОВАНИЙ №1
Диспетчер фоновых задач обеспечивает сообщение о состоянии через регулярные
интервалы, составляющие не менее 60 секунд
1. Диспетчер фоновых задач (ДФЗ) отобразит сообщения о состоянии в
назначенной области пользовательского интерфейса.
1.1 Сообщения будут обновляться каждые 60 секунд плюс/минус 10 секунд после
запуска фоновой задачи.
1.2 Сообщения должны оставаться видимыми постоянно.
1.3 Если взаимодействие с фоновой задачей возможно, то ДФЗ отобразит процент
выполнения фоновой задачи.
1.4 По завершению фоновой задачи ДФЗ отобразит сообщение ≪Выполнено≫.
1.5 Если выполнение фоновой задачи остановлено, ДФЗ отобразит
соответствующее сообщение.

219.

ПРИМЕР ИСПРАВЛЕНИЯ ТРЕБОВАНИЙ №2
Если возможно, номера счетов следовало бы проверить по списку корпоративных
счетов
В момент ввода номера счета система проверит его по основному корпоративному
списку счетов. Если номер счета в списке не найден, система отобразит сообщение
об ошибке и не примет заказ≫. Связанное требование будет относиться к условию
исключения: основной список счетов не доступен во время проверки
достоверности.

220.

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

221.

СОВЕТЫ ПО ОФОРМЛЕНИЮ ТРЕБОВАНИЙ
разделы, подразделы и отдельные требования должны быть названы согласованно;
оставьте текст невыровненным по правому краю, не выравнивайте его по ширине;
оставляйте достаточно свободного пространства (≪воздуха≫};
используйте средства визуального выделения (такие, как полужирное начертание,
подчеркивание, курсив и различные шрифты) последовательно и в разумных пределах;
создайте оглавление, а также при желании алфавитный указатель, чтобы облегчить
пользователям поиск необходимой информации;
пронумеруйте все рисунки и таблицы, озаглавьте их и, ссылаясь на них, используйте
присвоенные номера;
если вы ссылаетесь в документе на другие его части, используйте возможности работы с
перекрестными ссылками в вашем редакторе, а не сложную кодировку страниц;
применяйте гиперссылки, чтобы читатель смог быстро перейти к соответствующим разделам
спецификации или другим документам;
для структурирования необходимой информации используйте соответствующий шаблон.

222.

НУМЕРАЦИЯ ТРЕБОВАНИЙ
Нумерация по порядку
UR-9 или SRS-43
Иерархическая нумерация.
3.2.4.3
Иерархические текстовые тэги.
Print.ConfirmCopies

223.

ЛЕКЦИЯ 6. НАЗНАЧЕНИЕ ПРИОРИТЕТОВ
ТРЕБОВАНИЙ
Как бороться с высокими приоритетами (Предоставленные самим себе, клиенты,
скорее всего назначат 85% требований высокий приоритет, 10% — средний и 5% —
низкий. )?
Есть ли другой способ удовлетворить это требование клиентов?
Что случится, если это требование убрать или отложить?
Что произойдет с бизнес-целями, если это требование не будет реализовано
немедленно?
Почему пользователи будут недовольны, если реализацию этого требования
отложить до следующего выпуска?

224.

ПРИОРИТЕТЫ ПО ВАЖНОСТИ И СРОЧНОСТИ
Важные
Не важные
Срочные
Высокий приоритет
Не занимайтесь ими!
Не срочные
Средний приоритет
Низкий приоритет

225.

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

226.

Относительный вес
2
1
1
Относи
тельная
выгода
Относите
льный
урон
Общая
ценность
Ценность
в%
2
4
8
5,2
1
5
3
13
8,4
9
7
25
5
5
9
0,5
функция
Относите
льный
риск
Риск в %
Приори
тет
2,7
1
3,0
1,22
2
5,4
1
3,0
1,21
16,1
5
13,5
3
9,1
0,89
15
9,7
3
8,1
2
6,1
0,87
8
26
16,8
3
8,1
8
24,2
0,83
3
9
15
9,7
3
8,1
4
12,1
0,68
7.Модификация невыполненных заявок на
химикаты
4
3
11
7,1
3
8,1
2
6,1
0,64
8.Создание отчетов об инвентаризации
отдельных лабораторий
6
2
14
9,0
4
10,8
3
9,1
0,59
9.Проверка в базе данных по обучению
наличия записи о прохождении обучения по
обращению с опасными веществами
3
4
10
6,5
4
10,8
2
6,1
0,47
10.Импорт химических структур из
инструментальных средств для рисования
структур
7
4
18
11,6
9
24,3
7
21,2
0,33
53
49
155
100,0
37
100,0
33
100,0
1.Распечатка списка данных по безопасности
материалов
2.Запрос о статусе заказа поставщика
3.Создание отчета о инвентаризации склада
химикатов
4.Просмотр истории использования каждого
контейнера с химикатом
5.Поиск химиката по каталогам поставщиков
6.Поддержка списка опасных химикатов
Относите
Стоимост
льная
ьв%
стоимость
Итоги

227.

ФОРМИРОВАНИЕ МАТРИЦЫ ПРИОРИТЕТОВ
Перечислите в таблице все функции, варианты использования или
требования, для которых хотите определить приоритеты
Попросите представителей клиентов оценить относительную выгоду,
которую каждая функция дает клиенту или бизнесу, по шкале от 1 до 9
Оцените относительный урон, который потерпит клиент или бизнес,
если функция не будет включена в продукт.
В таблице суммируется ценность всех функций и посчитан процент от
общего значения для каждого набора функций, равного сумме
ценностей каждой функции (%).
оценить относительную стоимость реализации каждой функции
оценить относительную степень технического или другого риска
приоритет = % ценности/((% стоимости * вес стоимости) + (% риска *
вес риска))

228.

УТВЕРЖДЕНИЕ ТРЕБОВАНИЙ
1.
2.
3.
4.
5.
в спецификации требований к ПО должным образом описаны предполагаемые возможности и
характеристики системы, которые удовлетворят потребности различных заинтересованных в проекте
лиц;
требования к ПО точно отражают системные требования, бизнес-правила и др.;
требования полные и высококачественные;
все требования согласованы друг с другом;
требования обеспечивают качественную основу для дизайна и сборки ПО

229.

ЛЕКЦИЯ 7. ЭКСПЕРТИЗА ТРЕБОВАНИЙ
Участники
Автор продукта и, возможно, коллеги автора
Автор любого предыдущего продукта или спецификации для
элемента, который следует проверять.
Люди, которые будут выполнять работу, основанную на
проверяемом элементе.
Люди, отвечающие за работу продуктов, взаимодействующих
с проверяемым элементом.

230.

РОЛИ ЭКСПЕРТОВ
Автор
Координатор
Читатель
Секретарь

231.

ЭТАПЫ ЭКСПЕРТИЗЫ

232.

КОНТРОЛЬНЫЕ СПИСКИ ДЕФЕКТОВ (ВАРИАНТ ИСПОЛЬЗОВАНИЯ)
1
Является ли конкретный вариант использования продукта автономной и отдельной задачей?
2
Ясно ли сформулирована цель или измеряемое значение для конкретного варианта
использования продукта?
3
Очевидно ли, кто получит преимущества от этого варианта использования?
4
Написан ли вариант использования на базовом уровне, без ненужных деталей, связанных с
дизайном и реализацией?
5
Все ли предполагаемые альтернативные направления задокументированы?
6
Все ли известные условия исключения задокументированы?
7
Есть ли какие-либо последовательности действий, которые можно разделить на отдельные
варианты использования?
8
Все ли этапы каждого направления записаны в ясной, недвусмысленной и полной форме?
9
Каждый ли исполнитель и стадия варианта использования продукта соответствуют
выполнению конфетной задачи?
10
Осуществимо ли и поддается ли проверке каждое альтернативное направление, определенное в
варианте использования?
11
Должным ли образом структурируют вариант использования выходные и выходные условия?

233.

КОНТРОЛЬНЫЕ СПИСКИ ДЕФЕКТОВ (ФУНКЦИОНАЛЬНЫЕ
ТРЕБОВАНИЯ)
Организация и завершенность
1
2
3
4
5
Корректны ли все ли внутренние перекрестные ссылки на другие документы?
Написаны ли все ли требования на одном и том же соответствующем уровне детализации?
Обеспечивают ли требования адекватную основу для дизайна?
Указан ли приоритет реализации каждого требования?
Определены ли все внешние интерфейсы оборудования, ПО и взаимодействия?
6
Определены ли все алгоритмы, соответствующие функциональным требованиям?
7
Включены ли в спецификацию требований к ПО все известные потребности клиента или системы?
8
Отсутствует ли в требовании какая-либо необходимая информация? Если да, помечена ли она значком «TBD»?
9
Задокументировано ли ожидаемое поведение системы для всех предполагаемых ошибочных условий?
1
2
3
4
5
6
7
Корректность
Конфликтуют ли какие-либо требования с другими требованиями или повторяют их?
Написано ли каждое требования ясным, точным и недвусмысленным языком?
Можно ли проверить каждое требование с помощью тестирования, демонстрации, просмотра или анализа?
He выходит ли какое-либо требование за границы проекта?
Нет ли в каком-либо требовании тематических или грамматических ошибок?
Можно ли реализовать все требования, не выходя за рамки установленных ограничений?
Все ли перечисленные сообщения об ошибках уникальны и выразительны?
Атрибуты качества
1
Все ли задачи, связанные с производительностью, сформулированы соответствующим образом?
2
Все ли соображения, касающиеся охраны труда и безопасности, сформулированы соответствующим образом?
3
1
2
Приведены ли все ли соответствующие задачи, связанные с атрибутами качества, ясно задокументированы и подсчитаны, с учетом приемлемых
компромиссов?
Возможность отслеживания
Каждое ли требование идентифицировано уникально и корректно?
Прослежено ли каждое функциональное требование до более высокого уровня (например, требования к системе или вариант использования)?
1
Особые проблемы
Все ли требования можно отнести к именно к требованиям, а не к решениям разработки или реализации?
2
3
Идентифицированы ли все функции, зависящие от времени, и определены ли их критерии?
Были ли рассмотрены соответствующим образом все проблемы, связанные с интернационализацией?

234.

ЛЕКЦИЯ 8. ПРИНЦИПЫ И ПРИЕМЫ
УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ К ПО

235.

Базовая версия требований
Процедуры управления требованиями
Контроль версий (контроль кода SVN,
GIT,Mercurial+ Tortoise hg, Bazaar)
Атрибуты требований

236.

АТРИБУТЫ ТРЕБОВАНИЙ
дата создания требования;
номер его текущей версии;
автор требования;
лицо, ответственное за удовлетворение требования;
ответственный за требование или список заинтересованных лиц (чтобы принимать решения
о предложенных изменениях);
состояние требования;
происхождение или источник требования;
логическое обоснование требования;
подсистема (или подсистемы), для которых предназначено требование;
номер версии продукта, для которого предназначено требование;
используемый метод проверки или критерий тестирования приемлемости;
приоритет реализации;
стабильность (показатель того, какова вероятность изменения требования в будущем;
нестабильность требований может показывать плохо определенные или изменчивые бизнеспроцессы или бизнес-правила).

237.

СТАТУС ТРЕБОВАНИЙ
Состояние
Proposed (Предложено)
Определение
Требование запрошено авторизированным источником
Approved (Одобрено)
Требование проанализировано, его влияние на проект просчитано, и оно
было размещено в базовой версии определенной версии. Ключевые
заинтересованные в проекте лица согласились с этим требованием, а
разработчики ПО обязались реализовать его
Implemented (Реализовано)
Код, реализующий требование, разработан, написан и протестирован.
Требование отслежено до соответствующих элементов дизайна и кода
Verified (Проверено)
Корректное функционирование реализованного требования подтверждено
в соответствующем продукте. Требование отслежено до соответствующих
вариантов тестирования. Теперь требование считается завершенным
Deleted (Удалено)
Утвержденное требование удалено из базовой версии. Опишите причины
удаления и назовите того, кто принял это решение
Rejected (Отклонено)
Требование предложено, но не запланировано для реализации ни в одной
будущих версий. Опишите причины отклонения требования и назовите
того, кто принял это решение

238.

ИЗМЕНЕНИЕ СТАТУСА ВО ВРЕМЕНИ

239.

Затраты управления требованиями
Управление незапланированным ростом объема
Процесс контроля изменений
Политика контроля изменений
все изменения требований должны вноситься в соответствии с процессом. Если
запрос на изменение подается каким-то иным способом, он не рассматривается;
нельзя заниматься проектированием или реализовать неутвержденные изменения,
кроме проверки их осуществимости;
сам по себе запрос на изменение не гарантирует выполнение этого изменения.
Совет по управлению изменениями проекта (change control board, CCB) решает,
какие изменения следует реализовать. (Мы поговорим о совете по управлению
изменениями проекта далее в этой главе.);
содержимое базы данных изменений должно быть видимым для всех
заинтересованных в проекте лиц;
первоначальный текст запроса на изменение не должен изменяться или удаляться;
анализ влияния изменения необходимо выполнять для каждого изменения;
каждое включенное изменение требования должно отслеживаться вплоть до
утверждения запроса на это изменение; обоснование каждого утверждения или
отклонения запроса на изменение необходимо документировать.

240.

ОПИСАНИЕ ПРОЦЕССА КОНТРОЛЯ
ИЗМЕНЕНИЙ
1. Введение
1.1.
Назначение
1.2.
Границы
1.3.
Определения
2. Роли и ответственности
3. Состояние запроса на изменение
4. Входной критерий
5. Задачи
5.1.
5.2.
5.3.
5.4.
Оценка запроса
Принятие решения
Внесение изменения
Уведомление всех задействованных лиц
6. Проверка
6.1.
Проверка изменения
6.2,
Установка продукта
7. Выходной критерий
8. Отчет о состоянии контроля изменений
Приложение. Элементы данных, сохраненные для каждого запроса

241.

242.

ЛЕКЦИИ 9,10 ТРАССИРОВКА ТРЕБОВАНИЙ
Трассировка - это способ представления отношений между требованиями
различного уровня в системе. Она помогает определить источник любого
требования.

243.

Связи трассировки между требованиями

244.

ДЛЯ ЧЕГО НУЖНА ТРАССИРОВКА
Сертификация.
Анализ влияния изменения.
Поддержка.
Трассирование проекта.
Повторная разработка.
Повторное использование.
Снижение риска.
Тестирование.

245.

ПРИМЕР ТАБЛИЦЫ ТРАССИРОВКИ
ТРЕБОВАНИЙ
Пользовательское
требование
Функциональное
требование
Элемент
проектирования
Модуль кода
Вариант
тестирования
UC-28
catalog.query.sort
Каталог класса.
catalog.sort()
search. 7
search. 8
Каталог класса
catalog.import()
catalog.validate()
search. 12
search. 13
search. 14
UC-29
catalog.query.import

246.

ПРИМЕР ТРАССИРОВКИ
НЕФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ

247.

ТИПЫ ОТНОШЕНИЙ
«Один к одному»: например, один элемент
проектирования реализуется в одном модуле кода.
«Один ко многим»: например, одно
функциональное требование проверяется
множеством вариантов тестирования.
«Многие ко многим»

248.

Вариант использования (ВИ)
Функциональное требование (ФТ)
СВЯЗИ
ФУНКЦИОНАЛЬНЫХ
ТРЕБОВАНИЙ И
ВАРИАНТОВ
ИСПОЛЬЗОВАНИЯ
ВИ-1
ВИ-2
ФТ-1
ФТ-2
ФТ-3
ФТ-4
ФТ-5.
ФТ-6
Источники информации о связи
Тип объекта источника ссылки
Тип объекта целевой ссылки
Источник информации
Системное требование
Требование к ПО
Системный инженер
Вариант использование
Функциональное требование
Аналитик требований
Функциональное требование
Функциональное требование
Аналитик требований
Функциональное требование
Вариант тестирования
Специалист по тестированию
Функциональное требование
Элемент архитектуры ПО
Архитектор ПО
Функциональное требование
Другие элементы
проектирования
Проектировщик или разработчик
Элемент проектирования
Код
Разработчик
Бизнес-правило
Функциональное требование
Аналитик требований
ВИ-3
ВИ-4

249.

ТРАССИРОВКА В
SYBASE POWER
DESIGNER

250.

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

251.

ФУНКЦИИ ПО УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ
Управление версиями и изменениями.
Хранение атрибутов требований.
Облегчение анализа воздействия.
Трассирование статусов требований.
Контролируемый доступ
Связь со всеми заинтересованными в проекте лицами
Повторное использование требований.

252.

ОСНОВНЫЕ ТИПЫ ПО УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ
Инструмент
Производитель, сайт
Способ хранения данных
База данных
DOORS
IBM http://www.ibm.com
Rational
RequisitePro
IBM http://www.ibm.com
Документ
Sybase
PowerDesigner
Sybase www.sybase.ru
База данных
RequirementsWin_ Моргунов Александр Игоревич
0_9
http://am-programs.ru
Документ

253.

СВЯЗЬ ТРЕБОВАНИЙ С ДРУГИМИ
ЧАСТЯМИ ПРОЕКТА

254.

ВЗАИМОДЕЙСТВИЕ УЧАСТНИКОВ

255.

ЛЕКЦИИ 12,13 ТРЕБОВАНИЯ К ПО И
УПРАВЛЕНИЕ РИСКАМИ
Под риском понимают возможность наступления некоторого
неблагоприятного события, влекущего за собой различного
рода потери (например, получение физической травмы,
потеря имущества, получение доходов ниже ожидаемого
уровня и т.д.).
Риск — это событие, способное (в случае его реализации)
оказать влияние на ход выполнения проекта. Риски
существуют во всех проектах, но не всегда реализуются.
Риск, который реализовался, превращается в проблему.

256.

ПРИЗНАКИ, КОТОРЫЕ ЧАСТО УКАЗЫВАЮТ
НА РИСКОВАННЫЙ ХАРАКТЕР ПРОЕКТА:
большие размеры разрабатываемой системы;
неясные и изменяющиеся требования;
использование в проекте новых технологий;
сложность системы;
размеры системы, не соответствующие бюджету;
высокая степень зависимости от определенных
людей.

257.

КАК СДЕЛАТЬ ПРОЕКТ КРАЙНЕ РИСКОВАННЫМ?
неправильно оценить реальный размер и сложность задач
разработки;
недостаточно точно оценить необходимые ресурсы;
превысить возможности (компетенцию) организации;
не обеспечить стабильность пожеланий пользователя;
использовать недостаточно зрелые программные среды и
инструменты;
назначить сроки выполнения проекта без учета реальных
размеров и сложности системы;
предпринять действия, не согласующиеся с
корпоративной культурой фирмы-разработчика;
понадеяться на “серебряную пулю”, которая позволит
резко повысить производительность.

258.

Воздействие, или последствие риска — влияние
реализовавшегося риска на возможность выполнить
определенные составляющие плана.
Вероятность риска — вероятность, с которой данный
риск превратится в проблему.
Управление рисками — это процедуры и действия,
которые позволяют менеджеру выявлять, оценивать,
отслеживать и устранять риски до или во время их
превращения в проблемы.

259.

СТРАТЕГИИ БОРЬБЫ С РИСКОМ
Управление риском (risk management) — это применение инструментальных средств
и процедур для ограничения факторов риска в проекте приемлемыми рамками.
Управление риском предоставляет стандартный подход к выявлению и
документированию факторов риска, оценке потенциального ущерба от воздействия
этих факторов и предлагает стратегии по смягчению этого ущерба
Избежать риска.
Переадресовать риск.
Согласиться с присутствием риска.

260.

ЭЛЕМЕНТЫ УПРАВЛЕНИЯ РИСКОМ

261.

ВИДЫ РИСКОВ
Технические риски.
Программные риски.
Риски на этапе сопровождения системы.
Стоимостные риски, .
Риски сроков.
Риски неудовлетворенности заказчика.

262.

МЕТОДЫ ВЫЯВЛЕНИЯ РИСКОВ
Исторический анализ.
Аналитический метод.
Совещания.
Индивидуальные интервью.

263.

ОЦЕНКА РИСКА
RE(R) = Prob(R)xLoss(R)
RE - воздействие риска (risk
exposure,)
Prob(R) — вероятность возникновения риска
R,
Loss(R) - общий ущерб, наносимый
материализацией риска

264.

РАНЖИРОВАНИЕ (НАЗНАЧЕНИЕ
ПРИОРИТЕТОВ РИСКАМ)
Для каждого риска вероятность его проявления классифицируется как низкая,
средняя или высокая. Если необходимо, значения вероятностей указываются в
диапазонах, определенных для каждого класса.
Для каждого риска оценивается его влияние на проект: низкое, среднее или
высокое. При желании можно назначить риску вес по шкале от 1 до 10.
Риски классифицируются на основании своей вероятности и влияния на проект.
Например, риск с высокой вероятностью и высоким уровнем влияния будет иметь
более высокий ранг по сравнению с риском средней вероятности и высокого
уровня влияния. В спорных случаях используется личная оценка (или
назначаются числа для определения численного значения воздействия риска).
Несколько наивысших рисков выбираются для смягчения их последствий и
отслеживания. Основная цель управления рисками заключается в том, чтобы
идентифицировать несколько наивысших рисков и затем сосредоточить внимание
на них.

265.

Категории рисков
Вероятность
Низкая
Средняя
Высокая
Диапазон
0,0-0,3
0,3-0,7
0,7-1,0
Категории
влияния
рисков
Уровень
последствий
Диапазон
Низкий
Средний
Высокий
0,0-1,9
2,0-3,5
3,6-5,0

266.

КАЧЕСТВЕННОЕ РАНЖИРОВАНИЕ
Низкая
Средняя
Высокая
Низкий
C
C
B
Средний
C
В
В
Высокий
B
В
А

267.

КОЛИЧЕСТВЕННОЕ РАНЖИРОВАНИЕ
0.1
0.3
0.5
0.7
0.9
1
0.1
0.3
0.5
0.7
0.9
2
0.2
0.6
1.0
1.4
1.8
3
0.3
0.9
1.5
2.1
2.7
4
0.4
1.2
2.0
2.8
3.6
5
0.5
1.5
2.5
3.5
4.5

268.

ПЛАНИРОВАНИЕ УПРАВЛЕНИЯ РИСКОМ

269.

270.

ЛЕКЦИЯ 14. ДОКУМЕНТИРОВАНИЕ РИСКОВ
ПРОЕКТА
Идентификатор:
<порядковый номер>
Дата открытия:
<дата, когда элемент риска был обнаружен>
Дата закрытия:
<дата, когда элемент риска был закрыт>
Описание:
<описание элемента риска в форме «причина – следствие»>
Вероятность:
<вероятность того, что элемент риска станет проблемой»>
Влияние:
<потенциальный урон, который может быть нанесен, если элемент риска станет
проблемой>
Подверженность:
<вероятность, умноженная на ущерб>
План смягчения риска:
<один или несколько методов управления избегания, уменьшения последствий или
других способов минимизации риска>
Ответственное лицо;
<человек, отвечающий за разрешение элемента риска>
Срок исполнения
<дата, к которой действия по смягчению риска должны быть выполнены>

271.

Идентификатор:
1
Дата открытия:
04.03.2003
Дата закрытия:
(открыт)
Описание:
Недостаточное вовлечение пользователей в составление требований может взывать
необходимость объемной переработки пользовательского интерфейса после бетатестирования.
Вероятность:
0,6
Влияние:
7
Подверженность:
4,2
План смягчения риска:
1.
собрать требования по удобству использования в начале стадии;
2.
провести встречи со сторонниками продукта для разработки требований;
3.
разработать
одноразовый
прототип
базовой
функциональности
пользовательского интерфейса с участием сторонников продукта и консультанта по
кадрам. Другие пользователи должны оценить прототип.
Ответственное лицо:
Хелен
Срок исполнения:
Провести семинар к 16.04.2003.

272.

РИСК, СВЯЗАННЫЙ С ТРЕБОВАНИЯМИ
Выявление требований
▪ Образ и границы проекта.
▪ Время, затраченное на разработку требований.
▪ Полнота и корректность спецификации требований.
▪ Требования для суперсовременных продуктов
▪ Определение нефункциональных требований.
▪ Единство мнений клиентов относительно требований к
продукту
▪ Не сформулированные требования.
▪ Использование существующего продукта в качестве
базовой версии.
▪ Решения, предлагаемые в качестве потребностей.

273.

Анализ требований
Определение приоритетов требований.
Технически сложные функции.
Незнакомые технологии, методы, языки,
инструменты или аппаратное обеспечение.

274.

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

275.

Управление требованиями
Изменение требований.
Процесс изменения требований.
Нереализованные требования.
Увеличение объема проекта.

276.

ЭТАПЫ ОСВОЕНИЯ УПРАВЛЕНИЯ РИСКАМИ
Стадия 1. Решение проблем
Стадия 2. Снижение последствий
Стадия 3. Предотвращение рисков
Стадия 4. Предвосхищение рисков