Практики системной инженерии. Конспект лекций анализ потребностей и требований 2 Разделение зон ответственности 2
Скачать 0.8 Mb.
|
СОДЕРЖАНИЕ КУРСА. КОНСПЕКТ ЛЕКЦИЙАНАЛИЗ ПОТРЕБНОСТЕЙ И ТРЕБОВАНИЙ 2 Разделение зон ответственности 2 Потребность и требования. 3 КОНЦЕПЦИЯ ИСПОЛЬЗОВАНИЯ (CONCEPT OF OPERATION) 4 Функциональное моделирование использующей системы 4 Модели жизненного цикла 4 Бизнес-анализ 6 Определение границ системы 7 ОПРЕДЕЛЕНИЕ СИСТЕМЫ (SYSTEM DEFINITION) 8 Функциональное моделирование системы 8 Определение архитектуры системы 8 Системная спецификация 9 ПРАКТИКА 1 11 ПРАКТИКА 2 13 ПРАКТИКА 3 ☐ 14 АНАЛИЗ ПОТРЕБНОСТЕЙ И ТРЕБОВАНИЙ Разделение зон ответственности
Проблемы: Может быть несколько «Руководителей» => занимаются не своими прямыми задачами => на совещания тратятся большое количество времени. Все заделались «начальниками» и нет людей выполнять поставленную задачу. Интересы Проблемы Возможности
Случаи при реализации проекта Вы во все стороны смотрите, определяем все требования, никто не трясет, все вольны. (Приносит печальные последствия). Проект Проект подвергается атаке стейкхолдеров (наилучший способ, необходимо стремиться к нему. Проект
Сис.арх Рук.пр Эконом. Вы Програм. Констр. Системная архитектура – это принципиальные инженерные решения, принимаемые в ходе совместной работы. Потребность и требования. Стейкхолдеры – потребитель, роль.
Потребность стейкхолдера Я, как <стейкхолдер> хочу <потребность> потому что <проблема>. Требования стейкхолдера Я, как <стейкхолдер> считаю, что система должна <требования>, чтобы <потребность>. Системное требование Система должна <требование> в <условиях> с <характеристикой>. КОНЦЕПЦИЯ ИСПОЛЬЗОВАНИЯ (CONCEPT OF OPERATION) Функциональное моделирование использующей системы Функциональная модель Функция Вход Выход
Использующая система = Надсистема. Потреб. Пример: Использующая система = Умный бизнес-центр Треб. Поддержка командных условий для ведения бизнеса Ресурсы Сервис Обеспечение сервисом Внешние природные условия УБЦ Комфорт - воздух -сервисы … Треб. Огранич. Внеш воздействий Изменение внутреннней среды Потреб. |
| Функция 1 | Функция 2 | … | Связь 1 | Связь 2 | … |
Блок 1 | | | | | | |
Блок 2 | | | | | | |
… | | | | | | |
Интерфейс 1 | | | | | | |
Интерфейс 2 | | | | | | |
… | | | | | | |
Сумма | | | | | | |
По сумме можно посмотреть какие блоки перегружены, где функции пересекаются, позволяет сделать выводы. Позволяет чтобы специалисты давали экспертную оценку по матрице, по функциям, по связям и тд.
уровни
Декомпозиция конструкции
М5
М6
М7
М4
М4
М3
М3
М2
М1
система
блоки
модули
Системная спецификация
Стандарт ISO 15288:2015. Стандартизация позволяет правильно организовать процессы.
№ п/п | Модуль | Интерфейс | Функции | Связи |
1 | Коробка ключа М2 | - крепление к стене - крепление для датчика - крепление для передатчика | - обеспечение безопасности переключения - индикатор состояния | - механическое взаимодействие Выход: - ток к прибору Вход: - ток к коробке |
2 | Датчик М3 | - крепление к коробке - соединение с передатчиков | - определение состояния | Вход: - ток в ключе - ток в розетке Выход: - состояние |
3 | … | … | … | … |
Дальше с таблицей идем к инженерам и обсуждаем и дополняем. По каждому пункту в тз добавляем требования, например к креплению к стене (липучка, прикрепить на болты и тд) или габаритные размеры коробки и тд… Все вопросы необходимо записать. С какой частотой должна быть передача данных? Эффект чистого листа. Заранее создать такую таблицу, позволяющее создать полностью тех задание.
ПРАКТИКА 1
Устанавливаем программный продукт Archi.
Основные блоки:
Анализ потребностей
Business Actor – конкретный человек, имя фамилия
Business Role – должность/ роль в организации/ проекте
Stakeholder – стейкхолдер (пользователь продукта)
Drive – что хочет стейкхолдер?
Assessment – почему стейкхолдер это хочет?
Principle – стейкхолдер считает что продукт должен…
Requirement – системное требование
Декомпозиция требований
Разбиваем задачу на более мелкие. В качестве связей используем Specialization of.
Анализ потребностей
Декомпозиция требований
Роли
ПРАКТИКА 2
Technology Function - функции систем
Material – материальные потоки, информационные то что преобразуется
Связь типа доступа – access relation
Связь реализовать использовать тогда, когда мы можем непосредственно изменить
Функциональное моделирование
Функциональное моделирование 2
Трассировка
ПРАКТИКА 3 ☐
Инструмент r-project
Открываем eSmartBC