Содержание
Группы приоритетов для требований
Механизм расстановки приоритетов требованиям
Глоссарий
actor
исполнитель
agile
подвижный
checklist
контрольная карта
COTS (Commercial Off-The-Shelf)
готовое (решение)
consistent (requirements)
взаимно непротиворечивые требования
consumer
потребитель
control flow
поток; переход
customer
заказчик
design
проектирование; проектное решение
effort
попытка; development effort попытка создания
executive champion, executive sponsor
куратор
executive support
административная поддержка
feature
функциональная точка
inception
зарождение
JBGE (Just Barely Good Enough)
принцип необходимой достаточности
lean
легковесный
MOSCOW (Must, Should, Could, Won’t)
обязательно, необходимо, желательно, нежелательно
software engineering
производство программного обеспечения
техническое управление; управление технической частью разработки; организация технической части; управление производством программного продукта
software development
разработка программного обеспечения
stakeholder
заинтересованное лицо
use case
прецедент
user story
пользовательская история
Термины
UML
система обозначений для построения диаграмм в рамках процесса проектирования программного обеспечения
дизайн, инженерия, моделирование, проектирование
итеративная разработка
подход к производству программного обеспечения
модель
упрощенное описание программной системы
унифицированный процесс
один из видов итеративной разработки
Элементы
потребитель (customer)
тот, кто будет использовать конечный продукт в рамках какой-либо деятельности
цикл разработки
фаза
Процессы
управление проектом (project management)
Роли
куратор (executive champion)
Обеспечивает выделение необходимых ресурсов
руководитель проекта (project manager)
-
Составляет план задач
-
Распределяет имеющиеся ресурсы по задачам из плана
-
Осуществляет контроль над выполнением работ по задачам
-
Обеспечивает решение задач в срок, при необходимости высвобождая или запрашивая дополнительные ресурсы у куратора
Типы заинтересованных лиц
потребитель — тот, кто будет потреблять
заказчик — тот, кто будет продавать
Типы процессов разработки ПО
Предиктивные
Итеративные
Адаптивные
Этапы разработки
Концептуализация
идея → перечень требований
Анализ
перечень требований → аналитическая модель
Свойства требований
ясность
недвусмысленность
непротиворечивость
проверяемость
Типы требований
Функциональные
Набор утверждений о возможностях продукта.
Относящиеся к предметной области:
„Приложение должно предоставлять возможность бронирования авиабилетов.“
Не относящиеся к предметной области:
„Приложение должно предоставлять возможность вывода заявки на печать.“
Нефункциональные
Набор утверждений о качестве предоставляемых возможностей, а также возможных ограничениях связанных с ними.
Относящиеся к качеству:
Удобство в использовании (Usability)
внешняя привлекательность; непротиворечивость системы навигации
Надежность (Reliability)
круглосуточная доступность; защищенность от сбоев
„Приложение должно быть доступно для использования в режиме 24/7.“
Производительность (Performance)
пропускная способность; время отклика
„Приложение должно обеспечивать одновременный прием 20-и заявок.“
Поддерживаемость (Supportability)
простота развертования; простота настройки; простота поиска и устранения проблем
Определяющие ограничения:
Проектные требования (Design requirements)
аппаратная платформа; программная платформа; система хранения
Требования к реализации (Implementation requirements)
использование определенных систем программирования (языков), их версий и стандартов
Требования к интерфейсу (Interface requirements)
взаимодействие с определенными внешними системами; определение протоколов взаимодействия
Физические требования (Physical requirements)
физические характеристики аппаратной платформы — форма, размер, вес, температурные параметры
Группы приоритетов для требований
1. „Обязательно“ (MUST)
2. „Необходимо“ (SHOULD)
3. „Желательно“ (COULD)
4. „Нежелательно“ (WON’T)
Механизм расстановки приоритетов требованиям
1. „Будет ли реализация данного требования полезным для пользователей?“ „Да“ — желательно, „Нет“ — нежелательно;
2. „Будет ли реализация данного требования значительно улучшать конечный продукт?“ „Да“ — необходимо, „Нет“ — желательно;
3. „Сделает ли продукт непригодным к использованию нереализация данного требования?“ „Да“ — обязательно, „Нет“ — необходимо.
Виды моделей
модель классов
классы объектов и отношения между ними
модель состояний
изменение состояния объекта модели с течением времени
модель взаимодействий
кооперация объектов системы
Назначение моделей
модель предметной области приложения
Отражает содержание предментой области приложения.
Аспекты применения UML
Концептуальный аспект
Описание модели предметной области (аналитическая модель, концептуальная модель, модель области применения). Оперирование концептуальными классами.
Аспект спецификации
Описание модели приложения (проектная модель). Оперирование классами проектирования.
Аспект реализации
Описание программной модели (модель реализации). Оперирование классами реализации.