Содержание
- 2. Тема 3. УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ Определение ключевых понятий управления требованиями. Определение факторов, способствующих и препятствующих успеху проекта.
- 3. Зачем управлять требованиями? Ошибки и разночтения, которые возникают при выявлении требований к системе, оказываются одними из
- 4. Введение в управление требованиями Создаваемая система Потребности Требования к ПО Проектирование Методики тестирования Документация пользователя Функции
- 5. Определения Требование – это условие или характеристика, которым должна отвечать система. Требования – это то исходное
- 6. Что указывают требования к ПО? Входы Выходы Функция Нефункциональные требования (производительность и т.п.) Проектные ограничения (среда
- 7. Категоризация определений Требования к ПО Проектные ограничения Функциональные требования Нефункциональные требования Типы требований Запросы ЗЛ Функции
- 8. Определения All rights reserved.
- 9. Виды требований Функциональное требование Требование, описывающее взаимодействие поставляемого решения с внешним миром с точки зрения «черного
- 10. Что Как Что Как Что Как Потребности ЗЛ Функции системы или продукта Требования к ПО Проектные
- 11. Управлять требованиями трудно, так как… Требования Не всегда очевидны. Исходят из многих источников. Не всегда могут
- 12. Причины изменчивости ПО: Меняется ситуация на рынке, для которого предназначалась система или требования к системе изменяются
- 13. Свойства требований Ясность, недвусмысленность — однозначность понимания требований заказчиком и разработчиками. Полнота отражает все существенные требования
- 14. Свойства требований Прослеживаемость (трассируемость) — происхождение каждого требования легко отследить. Прослеживаемость функциональных требований достигается путем их
- 15. Свойства требований Тестируемость и проверяемость — необходимо, чтобы существовали способы оттестировать и проверить данное требование. Необходимы
- 16. Свойства требований 9. Проверяемость . Требование является проверяемым, если: Существует некий конечный и экономически эффективный процесс,
- 17. Пример. Нефункциональные требования ПО (с учетом целевого сегмента рынка) Типовое сегментирование рынка: Целевые сегменты Рынок домашних
- 18. Пример. Нефункциональные требования ПО (с учетом целевого сегмента рынка) SDK ( software development kit) — набор
- 19. На примере ИС «Турагенство» выделить требования, разбив их на две группы (см. слайд 9). Учитывать свойства:
- 20. Эффективное управление требованиями Четкое изложение требований обеспечивается: Высоким качеством требований Применимыми атрибутами для каждого типа требования
- 21. Что такое «качественный продукт»? Устаревший подход к качеству Соответствие перечню требований. Прохождение системных тестов. Разработка в
- 22. Основные атрибуты качества Применимость Надежность Производительность Эксплуатационная пригодность Атрибуты качества хорошо раскрыты в модели FURPS (расширение
- 23. FURPS и FURPS+ FURPS (Functionality Usability Reliability Performance Supportability): функциональность, удобство использования, надежность, производительность, удобство сопровождения)—
- 24. Атрибуты качества. Модель FURPS
- 25. Задание. Дать определения к характеристикам Supportability Тестируемость Расширяемость Адаптируемость Сопровождаемость Совместимость Конфигурируемость Обслуживаемость Устанавливаемость Локализуемость Устойчивость
- 26. Расширение модели FURPS+ В настоящее время FURPS используется, как составная часть более общей классификации FURPS+. Символ
- 27. Модель FURPS+ FURPS+ (Functionality Usability Reliability Performance Supportability +: функциональность, удобство использования, надежность, производительность, удобство сопровождения,
- 28. Задание. Примеры состава требований: ограничения проектирования (design); ограничения разработки (implementation); ограничения на интерфейсы (interface); физические ограничения
- 29. Цикл работы с требованиями В своде знаний по программной инженерии SWEBOK определяется следующие виды деятельности при
- 30. Варианты формализации требований 1. Неформальная постановка требований (переписка по электронной почте, устная беседа и т.п.). Хорошо
- 31. Традиционное описание требований
- 32. Пример. Описание функциональных требований 1. Система ATM должна проверять действительность вставленной в банкомат карточки. 2. Система
- 33. Пример. Описание нефункциональных требований Система ATM должна быть написана на C++. Система ATM должна обмениваться информацией
- 34. Задание. Привести свой пример (для АИС, АРМ, сайта и т.д.). Представить в виде описания. Не менее
- 35. Пример. Общее представление функционального назначения системы (функциональны требования) Диаграмма вариантов использования (диаграмма прецедентов ) ‒ это
- 36. Пример. Общее представление функционального назначения системы (функциональны требования) На диаграмме использования применяются два типа основных элементов:
- 37. Стандартные виды отношений: Отношение ассоциации (association relationship) Отношение включения (include relationship) Отношение расширения (extend relationship) Отношение
- 38. Отношение ассоциации (association relationship) Куликова Елена Васильевна Применительно к диаграммам вариантов использования ассоциация служит для обозначения
- 39. Отношение включения (include relationship) Включение (include) в языке UML — это разновидность отношения зависимости только между
- 40. Отношение расширения (extend relationship) Отношение расширения (extend) определяет взаимосвязь базового варианта использования с другим вариантом использования,
- 41. Отношение обобщения (наследования, генерализации) (generalization relationship) Два и более актера могут иметь общие свойства, т. е.
- 42. Отношение обобщения между актерами Куликова Елена Васильевна
- 43. Сводная таблица «Отношения» Куликова Елена Васильевна
- 44. Пример. Диаграмма прецедентов для системы продажи товаров в супермаркете
- 45. Хорошая книга! https://pmi.ru/profes/Software_Requirements_Khimonin.pdf
- 47. 1. Выделение требований 1) Определение основных профилей пользователей 2) Формирование инициативной группы 3) Сбор пользовательских историй
- 48. 1. Выделение требований 1) Определение основных профилей пользователей Для домашних продуктов сложно определить «среднего пользователя», чтобы
- 49. Разделение пользователей Для домашних продуктов разделение обычно производится, исходя из уровня подготовленности пользователя и его интересов
- 50. Выделение требований 2) Формирование инициативной группы Когда определены профили пользователей продукта, следует найти людей, соответствующих этим
- 51. Выделение требований 3) Сбор пользовательских историй Пользовательская история — это вариант использования будущего продукта в конкретной
- 52. Выделение требований 3) Сбор пользовательских историй Пользовательская история — это вариант использования будущего продукта в конкретной
- 54. Скачать презентацию