Анализ и управление требованиями. Управление. Моделирование. Прототипирование. (Часть 3)

Август 2, 2022

Главная
Информатика
Анализ и управление требованиями. Управление. Моделирование. Прототипирование. (Часть 3)

Содержание

2. Управление требованиями представляет собой: • систематический подход к выявлению, организации и документированию требований к системе; •
3. Управление требованиями преследует цели: достичь соглашения с заказчиком и пользователями о том, что система должна делать;
4. ПО для управления требованиями IBM Rational Requisite Pro Программное обеспечение Rational представляет лучшие практические методы определения
5. ПО для управления требованиями IBM Rational/Telelogic DOORS IBM Rational/Telelogic DOORS — семейство решений для управления требованиями
6. ПО для управления требованиями Borland Caliber RM Borland Caliber RM – это корпоративная система управления требованиями,
7. ПО для управления требованиями Sybase PowerDesigner OpenSource Requirements Management Tool RequirementsWin и другие Средства управления требованиями
8. Системные требования определение Системные требования состоят из полного списка конкретных свойств и функциональности, которую должна иметь
9. Назначение: представление системы Внешнее представление, когда моделируется окружение или рабочая среда системы Описание поведения системы, когда
10. Модель является абстракцией системы и легче поддается анализу, чем любое другое представление этой системы
11. Типы системных моделей Модель обработки данных. Диаграммы потоков данных показывают последователь ность обработки данных в системе.
12. Системные модели (обобщение) модели системного окружения, поведенческие модели модели данных
13. Модели системного окружения служат для определения границ системы и строятся на ранних этапах выявления требований. Трудоемкость
14. Пример модели окружения
15. Простые структурные модели обычно дополняются моделями других типов, например моделями процессов, которые показывают взаимодействия в системе,
16. Поведенческие модели используются для описания общего поведения системы Модель поведения должна быть компактной и обозримой, чтобы
17. Поведенческие модели Модели потоков данных Модель конечного автомата Модели данных
18. Модели потоков данных (МПД) либо показывают функциональную структуру системы, где каждое преобразование данных соответствует одной системной
19. Представление МПД Для описания модели потоков данных используются диаграммы потоков данных (data flow diagram, DFD), во
20. Диаграмма потоков данных комплекса CASE-средств
21. Представление МПД Контекстная диаграмма содержит внешние, по отношению к системе, сущности, которые являются источниками или потребителями
22. Контекстная диаграмма
23. Ценность МПД позволяют: · представить бизнес-процесс или операцию, выполняемую системой, в виде совокупности этапов; · проследить
24. Правила разработки МПД При разработке диаграмм потоков данных следует придерживаться следующих общих правил: · размещать на
25. Модели конечных автоматов используются для моделирования поведения системы, реагирующей на внутренние или внешние события. Такая модель
26. Пример модели конечных автоматов
27. Модели данных Наиболее широко используется моделирование данных типа “сущность – связь – атрибут”, определяющее структуру данных,
28. ER - диаграммы Под сущностью (entity) в ER-диаграммах понимается множество экземпляров реальных или абстрактных объектов (людей,
29. Объектные модели Объектные модели, могут использоваться как для представления данных, так и для процессов их обработки.
30. Диаграмма классов
31. Модели поведения объектов В UML поведение объектов моделируется посредством сценариев, которые основаны на вариантах использования. Диаграммы
32. Пример диаграммы последовательности
33. Прототип это начальная версия программной системы, которая используется для демонстрации концепций, заложенных в системе, проверки вариантов
34. Разработка прототипа позволяет сделать требования более реальными, помогает заинтересованным лицам прийти к общему пониманию требований, ускоряет
35. Прототип полезен для решения задач: 1.Разработка требований. 2.Проверка требований. 3.Разработка взаимодействия с пользователем. 4.Спецификация системных требований.
36. Виды прототипов Горизонтальные (поведенческие) Вертикальные (структурные)
37. Разработка прототипов Экспериментальное прототипирование (пассивный горизонтальный прототип) Эволюционное прототипирование 1.Ускорить разработку программной системы. В некоторых случаях
39. Скачать презентацию

Слайд 2

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

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

Слайд 3

Управление требованиями
преследует цели:
достичь соглашения с заказчиком и пользователями о том, что

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

Слайд 4

ПО для управления требованиями
IBM Rational Requisite Pro
Программное обеспечение Rational представляет лучшие

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

Слайд 5

ПО для управления требованиями
IBM Rational/Telelogic DOORS
IBM Rational/Telelogic DOORS — семейство решений

для управления требованиями и создания сложных наукоемких изделий (авиа, судостроение, поезда, ракеты, автомобили т.п.).
Из Telelogic DOORS можно получить следующую информацию:
Статус выполнения работ по каждому требованию отдельно, а также по группе требований.
Статус работы над всем проектом.
Ответственное лицо для каждого требования или группы требований.
Историю изменений требования.
Ресурсы, которые потребуются для реализации требования еще до его внедрения в проект.
Связь между требованиями заказчика, пунктами технического задания, программами верификации, тестирования и задачами управления проектом.
Класс, модель или чертеж, в котором конкретное требование реализовано.

Слайд 6

ПО для управления требованиями
Borland Caliber RM
Borland Caliber RM – это корпоративная

система управления требованиями, которая облегчает совместную работу, что позволяет группам разработчикам подходить к вехам проекта вовремя и с запланированными затратами.
Обладает следующими функциональными возможностями:
Централизованное хранилище требований для всех проектов, разрабатываемых IT-компанией.
Адаптируемость — Caliber RM можно сконфигурировать для использования в любом проекте, что повышает эффективность процесса управления требованиями.
Трассируемость требований — открытая архитектура Caliber RM позволяет связать требования с другими артефактами на всех стадиях жизненного цикла программного продукта.
Поддержка большого числа клиентов — Caliber RM прекрасно интегрируется с такими системами разработки, как Microsoft Visual Studio, Eclipse на платформе Windows.
Интеграция с другими продуктами Borland для поддержки полного жизненного цикла программного продукта.

Слайд 7

ПО для управления требованиями
Sybase PowerDesigner
OpenSource Requirements Management Tool
RequirementsWin и другие
Средства управления

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

Слайд 8

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

которую должна иметь программа, сформулированных в подробностях

Слайд 9

Назначение: представление системы
Внешнее представление, когда моделируется окружение или рабочая среда системы
Описание

поведения системы, когда моделируется ее поведение.
Описание структуры системы, когда моделируется системная архитектура или структуры данных, обрабатываемых системой.

Слайд 10

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

представление этой системы

Слайд 11

Типы системных моделей
Модель обработки данных. Диаграммы потоков данных показывают последователь

ность обработки данных в системе.
Композиционная модель. Диаграммы "сущность-связь" показывают, как системные сущности составляются из других сущностей
Архитектурная модель. Эти модели показывают основные подсистемы, из которых строится система.
Классификационная модель. Диаграммы наследования классов показывают, какие объекты имеют общие характеристики
Модель "стимул-ответ". Диаграммы изменения состояний показывают, как система реагирует на внутренние и внешние события.

Слайд 12

Системные модели (обобщение)
модели системного окружения,
поведенческие модели
модели данных

Слайд 13

Модели системного окружения
служат для определения границ системы и строятся на ранних

этапах выявления требований. Трудоемкость построения модели зависит от характера разрабатываемого приложения.

Слайд 14

Пример модели окружения

Слайд 15

Простые структурные модели обычно дополняются моделями других типов, например моделями процессов,

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

Слайд 16

Поведенческие модели
используются для описания общего поведения системы
Модель поведения должна быть компактной

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

Слайд 17

Поведенческие модели
Модели потоков данных
Модель конечного автомата
Модели данных

Слайд 18

Модели потоков данных (МПД)
либо показывают функциональную структуру системы, где каждое преобразование

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

Слайд 19

Представление МПД
Для описания модели потоков данных используются диаграммы потоков данных (data

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

Слайд 20

Диаграмма потоков данных комплекса CASE-средств

Слайд 21

Представление МПД
Контекстная диаграмма содержит внешние, по отношению к системе, сущности, которые

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

Слайд 22

Контекстная
диаграмма

Слайд 23

Ценность МПД
позволяют:
· представить бизнес-процесс или операцию, выполняемую системой, в виде совокупности

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

Слайд 24

Правила разработки МПД
При разработке диаграмм потоков данных следует придерживаться следующих общих

правил:
· размещать на диаграмме не более 7 – 10 процессов;
· не загромождать диаграммы несущественными на данном уровне деталями;
· декомпозицию потоков данных выполнять параллельно с декомпозицией процессов;
· однократно определять функционально идентичные процессы и ссылаться на них, на нижних уровнях.

Слайд 25

Модели конечных автоматов
используются для моделирования поведения системы, реагирующей на внутренние или

внешние события.
Такая модель показывает состояние системы и события, которые служат причиной перехода системы из одного состояния в другое.
ДИАГРАММА СОСТОЯНИЙ (UML)

Слайд 26

Пример модели конечных автоматов

Слайд 27

Модели данных
Наиболее широко используется моделирование данных типа “сущность – связь –

атрибут”, определяющее структуру данных, их атрибуты и отношения между ними.
Для разработки моделей данных, обеспечивающих стандартный способ определения данных и отношений между ними, служат диаграммы “сущность-связь” (Entity-Relationship Diagrams, ER-диаграммы).

Слайд 28

ER - диаграммы
Под сущностью (entity) в ER-диаграммах понимается множество экземпляров реальных

или абстрактных объектов (людей, предметов, событий и т.д.). Любой объект системы может быть представлен только одной уникально идентифицированной сущностью, имя которой должно отражать тип (класс) объектов, а не его конкретный экземпляр.
Связь (relation) – это именованное отношение между двумя и более сущностями, а атрибут (attribute) – любая характеристика сущности, причем множество значений всех атрибутов должно однозначно идентифицировать экземпляр сущности.
СЛОВАРЬ!

Слайд 29

Объектные модели
Объектные модели, могут использоваться как для представления данных, так и

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

Слайд 30

Диаграмма классов

Слайд 31

Модели поведения объектов
В UML поведение объектов моделируется посредством сценариев, которые основаны

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

Слайд 32

Пример диаграммы последовательности

Слайд 33

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

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

Слайд 34

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

к общему пониманию требований, ускоряет процесс разработки и анализа.

Слайд 35

Прототип полезен для решения задач:
1.Разработка требований.
2.Проверка требований.
3.Разработка взаимодействия с пользователем.
4.Спецификация системных

требований.

Слайд 36

Виды прототипов
Горизонтальные (поведенческие)
Вертикальные (структурные)

Слайд 37

Разработка прототипов
Экспериментальное прототипирование (пассивный горизонтальный прототип)
Эволюционное прототипирование
1.Ускорить разработку программной системы. В

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

Анализ и управление требованиями. Управление. Моделирование. Прототипирование. (Часть 3)

Содержание

Управление требованиямипредставля­ет собой:• систематический подход к выявлению, организации и докумен­тированию требований

Управление требованиямипреследует цели:достичь соглашения с заказчиком и пользователями о том, что

ПО для управления требованиямиIBM Rational Requisite ProПрограммное обеспечение Rational представляет лучшие

ПО для управления требованиямиIBM Rational/Telelogic DOORSIBM Rational/Telelogic DOORS — семейство решений

ПО для управления требованиямиBorland Caliber RMBorland Caliber RM – это корпоративная

ПО для управления требованиямиSybase PowerDesignerOpenSource Requirements Management ToolRequirementsWin и другиеСредства управления

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

Назначение: представление системыВнешнее представление, когда моделируется окружение или рабочая среда системыОписание

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

Типы системных моделей Модель обработки данных. Диаграммы потоков данных показывают последователь

Системные модели (обобщение)модели системного окружения, поведенческие модели модели данных

Модели системного окруженияслужат для определения границ системы и строятся на ранних

Пример модели окружения

Простые структурные модели обычно дополняются моделями других типов, например моделями процессов,

Поведенческие моделииспользуются для описания общего поведения системыМодель поведения должна быть компактной

Поведенческие моделиМодели потоков данныхМодель конечного автоматаМодели данных

Модели потоков данных (МПД)либо показывают функциональную структуру системы, где каждое преобразование

Представление МПДДля описания модели потоков данных используются диаграммы потоков данных (data