- •Письменные лекции по дисциплине «Разработка и анализ требований»
- •Лекция 1. Основы работы с требованиями к по
- •1.1. Что такое требования
- •1.2. Классификация программного обеспечения
- •1.3. Разработка требований в модели жизненного цикла по
- •1.4. Участники разработки требований
- •1.4.1. Аналитик требований
- •1.5. Типы требований
- •1.6. Этапы сбора и анализа требований с точки зрения rup
- •1.7. Процесс разработки требований
- •1.7. Разработка концепции продукта
- •1.13. Обзор конкурентов
- •1.13.1. Пример списка возможностей конкурентов
- •1.14. Документ о концепции и границах проекта
- •1.14.1. Положение о концепции
- •1.15. Бизнес-риски
- •1.16. Ограничения проекта и их выявление
- •1.17. Профили заинтересованных лиц
- •1.18. Пример бизнес-требований разных групп пользователей
- •1.19. Приоритеты проекта
- •Лекция 2. Методы выявления требований к по
- •2.1. Сбор требований пользователей
- •2.2. Определение классов пользователей
- •2.3. Характеристики классов пользователей
- •2.4. Представление системных событий и реакции на них
- •2.5.1. Пример crc-карточки
- •2.6. Прототипы (макеты) по
- •2.7. Представление требований пользователя на основе варианта использования
- •2.8. Процессы обработки данных варианта использования
- •2.9. Нефункциональные требования
- •2.10. Уточнение нефункциональных требований
- •2.11. Стандарты практичности (usability)
- •2.12. Бизнес-правила
- •2.12.1. Примеры бизнес-правил
- •Лекция 3. Анализ и моделирование требований к по
- •3.1. Атрибуты качества требований
- •3.2. Статус требования
- •3.3. Полный набор требований по
- •3.4. Представление вводов и выводов по
- •3.5. Полнота нефункциональных требований
- •3.6. Пример трассировки требований.
- •3.6.1. Дочерние требования
- •3.10.1. Оценки разработчиков возможности проверки требований
- •3.11. Определение приоритетов
- •4.3. Диаграммы uml (uml 2.5)
- •4.8. Предметы поведения uml
- •4.9. Отношения uml
- •4.10. Диаграмма Use Case
- •4.11. Диаграмма Use Case (2)
- •4.12. Диаграмма (видов) деятельности
- •5.5. Методики моделирования бизнес-процессов
- •5.6. Программное обеспечение для моделирования бизнес-процессов
- •5.7. Построение модели бизнес-процесса на основе вариантов использования
- •3) Используемые средства
- •5.8. Пример построения спецификации требований
- •5.9. Заинтересованные лица
- •5.10. Эксперты
- •5.11. Словарь (глоссарий)
- •5.12. Бизнес-процессы
- •5.13. Бизнес-правила
- •5.19. Класс Личное дело
- •Лекция 6. Методы структурного анализа требований к по
- •6.1. Средства структурного анализа
- •6.2. Методология sadt
- •6.3.1. Стандартизация методик моделирования в Российской Федерации
- •6.3.2. Диаграмма idef3
- •6.4. Диаграммы потоков данных dfd
- •7.2.2. Спецификация требований к по
- •7.3. Техническое задание (еспд. Гост 19.201-78)
- •7.4. Техническое задание (Информационные технологии гост 34.602-87)
- •7.5. Разработка требований к по встроенных систем
- •7.7. Спецификация требований к интерфейсам
- •7.8. Работа с требованиями в проектах гибкой разработки
- •Лекция 8. Управление требованиями к по
- •8.1. Управление требованиями
- •8.1.8. Атрибуты запроса на изменение
- •8.2. Программные средства управления требованиями
- •8.2.1. Сравнительная характеристика систем управления требованиями
- •8.2.3. Сравнение систем управления требованиями
4.8. Предметы поведения uml
Взаимодействие
Конечный автомат (элемент диаграммы состояния; состояние — конечный набор значений какого-либо атрибута рассматриваемого объекта)
Вид деятельности
4.9. Отношения uml
Зависимость (например, один объект зависит от данных другого объекта; стрелка идет от зависимого объекта к независимому)
Ассоциация
Агрегация («простое включение», внутренний объект может существовать автономно; ромб на стороне внешнего класса)
Композиция («жесткое включение», внутренний объект не может существовать автономно; ромб на стороне внешнего класса)
Обобщение («наследование в ООП», стрелка указывает на базовый/родительский класс)
Реализация (важно: не укладывается в концепцию классов, поэтому никогда не присутствует в диаграмме классов)
4.10. Диаграмма Use Case
Между актером и прецедентом — ассоциативная связь.
Диаграмма вариантов использования показывает основные функции (прецеденты) проекта и действующие лица, в интересах которых эти функции реализованы.
4.11. Диаграмма Use Case (2)
На данной диаграмме добавлена логическая часть между прецедентами.
На концах ассоциативных связей были добавлены обозначения (1..n, 0..n, 1) мощностей связей.
4.12. Диаграмма (видов) деятельности
Прямоугольник с закруглениями — «вид деятельности». Потоки данных и управления имеют направление сверху-вниз.
Первый ромбик — узел decision («решение») — разветвляет потоки. Второй ромбик (ниже первого) — узел merge («слияние») — сливает потоки в один. Из всех направлений (между двумя ромбиками) будет выполнено ровно одно.
Блок-схема похожа на диаграмму деятельности тем, что также описывает алгоритм работы.
4.13. Элементы диаграммы деятельности
Управляющий узел
Объектный узел
Исполняемый узел
4.14. Управляющие узлы
Решение/слияние (decision/merge)
Начало/завершение параллельного исполнения (fork/join) (завершение этого блока происходит после завершения всех параллельных процессов)
Начало сценария
Окончание сценария
Остановка исполнения (например, какое-нибудь исключение)
4.15. Объектные узлы
Объект
Объект и информация о нем («объект со стереотипом»)
Состояние объекта — перечисление значений всех его атрибутов.
Сигнал (в Qt Framework для обработки событий)
Слот (в Qt Framework для обработки событий)
4.16. Исполняемые узлы
Вид деятельности
Обработка исключительной ситуации
Узел, принимающий данные
Узел, передающий данные
4.17. Дуги диаграммы деятельности
Дуга между видами деятельности, объектом и видом деятельности
Дуга из области прерывания
Именованная дуга
Соединение дуг (если схема большая, можно разделить)
Примеры дуг:
Объект является источником управления либо данных для одного из двух видов деятельности.
4.18. Роли на диаграмме деятельности
Две роли — покупатель и продавец.
4.19. Пример диаграммы деятельности
4.20. Диаграмма состояний
Состояние — конечный набор значений какого-либо атрибута рассматриваемого объекта.
Простая черная заполненная окружность обозначает начало, а конец обозначается в виде заполненной окружности меньшего размера в незакрашенной окружности.
4.21. Диаграмма классов
4.22. Диаграмма объектов: обозначения
Объект и анонимный объект
Объект с атрибутом
Связь объектов (атрибут не указан)
Связь объектов (атрибут указан)
— первый вариант
— второй вариант
4.23. Диаграмма объектов: пример
4.24. Диаграмма компонентов
Используется для показа структуры ПО.
Компонент: программная реализация класса или нескольких классов (файлы с исходным кодом).
Артефакт: таблицы, файлы данных, рисунки, исполняемые файлы, документы, динамически загружаемые библиотеки (кроме файлов с исходным кодом).
Компонент и артефакт могут быть связаны связью «зависимость».
Компонент и компонент могут быть связаны связями «зависимость» либо «реализация».
4.25. Диаграмма компонентов UML 1.4
4.26. Диаграмма компонентов (UML 2.0)
main зависит от component, а component зависит от mmm.dll.
Order зависит от Product и Account.
4.27. Интерфейс на диаграмме компонентов
Далее представлены два варианта отображения интерфейса на диаграмме.
Calculator реализует интерфейс, от которого зависит Robot.
Calculator предоставляет интерфейс, который используется Robot'ом.
4.28. Интерфейс на диаграмме компонентов (2)
Далее представлены два варианта отображения интерфейса на диаграмме.
4.29. Диаграмма развертывания
Моделирует физическое развертывание артефактов на узлах.
4.30. Диаграмма последовательности
Диаграмма последовательности (англ. sequence diagram) — UML-диаграмма, на которой для некоторого набора объектов на единой временной оси показан жизненный цикл объекта (создание-деятельность-уничтожение некой сущности) и взаимодействие актеров (действующих лиц) информационной системы в рамках прецедента.
Основными элементами диаграммы последовательности являются обозначения объектов (прямоугольники с названиями объектов), вертикальные «линии жизни» (англ. lifeline), отображающие течение времени, прямоугольники, отражающие деятельность объекта или выполнение им определенной функции (прямоугольники на пунктирной «линии жизни»), и стрелки, показывающие обмен сигналами или сообщениями между объектами.
Рекомендуется не использовать более 7-ми объектов. В данном случае представлены два: Иван Иванович и Вася.
4.31. Диаграмма взаимодействия (кооперации, collaboration)
Диаграмма взаимодействия показывает поток сообщений между объектами системы и основные ассоциации между ними и по сути является альтернативой диаграммы последовательностей.
В данном случае временной интервал оценить трудно.
4.32. Диаграмма последовательности (2)
4.33. Диаграмма обзора взаимодействия
Interaction Overview diagram
4.34. Диаграмма синхронизации
Timing diagram
4.35. Диаграмма пакетов
Лекция 5. Анализ требований на основе моделирования бизнес-процессов
5.1. Моделирование бизнес-процессов
Бизнес-процесс — совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующая входы в выходы и представляющая ценность для потребителя.
Бизнес-модель — это формализованное (графическое, табличное, текстовое) описание бизнес-процессов, отражающее реально существующую или предполагаемую деятельность предприятия.
На основе бизнес-модели формируются требования к ПО.
5.2. Процесс разработки требований
DFD-диаграмма:
5.3. Процессы обработки данных варианта использования
DFD-диаграмма:
В виде прямоугольников — сущности, в виде овалов — процессы / виды деятельности / работы.
Бизнес-процесс представляет собой преобразование исходных данных в далее используемые выходные данные.
5.4. Категории бизнес-процессов
Основные процессы — процессы, составляющие основную деятельность предприятия и приносящие доход.
Например, обучение по программам высшего образования.
Вспомогательные процессы — процессы, обеспечивающие выполнение основных процессов (администрирование, обеспечение безопасности, закупка материалов, комплектующих ...).
Например, закупка оборудования (столы, стулья и др.), обеспечение энергетическими ресурсами (вода).
Процессы управления — процессы, оказывающие влияние на все другие процессы.
Например, работа личного кабинета университета, финансовое планирование.
