 |
Основы системной инженерии
|
|
|
|
1.2.1. Стейкхолдеры. Люди, группы и организациии, которые имеют какое-либо отношение к проекту, – стейкхолдеры (stakeholders/заинтересованные стороны). Стейкхолдеры условно делятся на "внешних" и "членов команды".
Стейкхолдеры обеспечивают возможности.
Возможности мотивируют стейкхолдеров заниматься инженерным проектом.
Возможности объединяют стейкхолдеров на цели выполнения инженерного проекта по созданию целевой системы.
Стейкхолдеры требуют согласовывать с ними определение системы
(Прежде всего, требования – определение системы как "чёрного ящика"; внутреннее устройство системы интересует далеко не всех стейкхолдеров).
Стейкхолдеры используют воплощение системы, ради создания которого затевается проект.
Простейший рабочий продукт, отражающий альфу "стейкхолдеры", – список стейкхолдеров.
Из информационных систем со стейкхолдерами работают CRM(customer relationship management / управление взаимоотношениями с клиентами).
Конфликтология (в части методов ведения переговоров с целью снять противоречия между требованиями различных стейкхолдеров.
Например – метод "принципиальных переговоров" или "гарвардский метод ").
Коммуникация (communications) для налаживания продуктивного диалога со стейкхолдерами
Техники представления стейкхолдеров (например, "метод персонажа")
http://rutracker.org/forum/viewtopic.php?t=1227489,
http://praxos.ru/index.php/%D0%98%D0%B4%D0%B5%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9%D0%90%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%B5%D1%80).
1.2.2. Возможности. Инженерный проект начинается с появления возможностей (opportunity) его проведения, обстоятельств, которые делают возможным разработку (доработку – изменение) системы.
Время.
" Окно возможностей " – период времени, в течение которого существует возможность выполнения проекта.
|
|
|
Пользовательские потребности (user needs)
То, что хотят пользователи такого, для чего им поможет воплощенная система.
Наличие возможностей команды
Имеющиеся в распоряжении команды технологии и финансовые ресурсы.
Возможности описываются целым рядом возможных рабочих продуктов:
"Бизнес-план",
"Концепция",
"Интервью пользователей",
"Обоснование инвестиций" и т.д..
В рабочих продуктах обосновывается польза от выполнения проекта, извлекаемаястейкхолдерами.
Применяют
Маркетинг и продажи, стратегирование и предпринимательство (установление потребностей).
Управленческий (финансовый) учёт (обоснования прибыльности).
Важны не только нужды/потребности/ожидания пользователей, но и нужды /потребности /ожидания / других стейкхолдеров.
1.2.3. Воплощение системы. Воплощение системы (system realization) – это сама система.
Воплощение системы реализует возможности, отвечает нуждам/ потребностям/ ожиданиям стейкхолдеров проекта.
1.2.4. Команда. Команда (team) проекта. Люди с совершенно определённым набором компетенций (инженерных, менеджерских и других), нужных для создания системы (реализации проекта).
1.2.5. Работы. Чтобы инженерный проект был успешно реализован, команде проекта нужно провести работы (works) и отслеживать состояние этих работ в ходе всего проекта.
Учитывать работы во всём их содержательном разнообразии, чтобы ответить на вопрос "что делать"
Планировать (schedule) работы, т.е. предлагать распределение этих работ во времени и назначать исполнителей.
Определять достаточность ресурсов и контролировать выполнение плана работ.
1.2.6. Технология. Способ работы (way of working), поддержанный необходимыми рабочими продуктами и инструментами.
Практика = дисциплина+технология
Метод = полный набор дисциплин и технологий для выполнения какой-то работы.
|
|
|
1.2.7. Определение системы (system definition). Систему нужно определить. Определение системы имеет отдельные моменты, прежде всего:
Требования – описание назначения системы в её операционном окружении.
Требования определяют систему как " чёрный ящик ".
Состояния «альф», граф состояний, синхронизация состояний. Концепция жизненного цикла (ЖЦ), модель ЖЦ, стадии ЖЦ. Компьютерная поддержка ЖЦ продуктов (услуг).
Состояния «альф»
Каждая альфа инженерного проекта проходит по графу состояний.
Альфа "Работа " проходит состояния:
- Инициирована (работа была запрошена).
- Подготовлена (все предусловия для начала работы выполнены).
- Начата (работа происходит).
- Под контролем (работа продвигается хорошо, риски под контролем, уровень производительности достаточен для достижения удовлетворительного результата).
- Закончена (работа по производству результата была закончена).
- Закрыта (все остающиеся служебные задачи завершены, работа официально закрыта, полученные уроки сформулированы, записаны и обсуждены).
Такая последовательность упрощает реальность. На самом деле граф состояний может иметь сложную структуру. Альфа «Работа» и другие Альфы могут проходить через состояния циклически, какие-то состояния могут пропускаться, могут существовать альтернативные пути.
Задача управления ЖЦ заключается не только в том, чтобы альфы воплощения и определения системы продвигались по своим состояниям, но и в синхронизациидостижения состояний всех основных альф инженерного проекта.
Синхронизация состояний альф кладётся в основу планирования работ по проекту.
В план работ включаются и работы по не инженерным альфам (в инженерных проектах очень часто существенно не хватает менеджерских работ, возникает перегрузка менеджеров, операционистов, и специалистов, работающих с клиентами).
Определение ЖЦ отслеживается в ходе инженерного проекта. ЖЦ – объект, который следует рассматривать в качестве:
- подальфы альфы "Определения системы" (определение ЖЦ связано в существенной мере с «Работой»),
- подальфы альфы "Работы" (ЖЦ лежит в основе работ по планированию проекта),
- подальфы альфы "Технологии" (вид ЖЦ определяет используемые практики).
|
|
|
********************************************
1.4.1. Концепции ЖЦ. Каждая система имеет свой ЖЦ. ЖЦ может быть описан с использованием абстрактной функциональной модели (см. стандарт IDEF0 ), представляющей концептуализацию потребности в системе, ее реализации, применения, развития и ликвидации.
Модель ЖЦ. Система развивается на протяжении ЖЦ в результате действий, осуществляемых и управляемых людьми, работающими в организациях и использующими определенные процессы в своей деятельности.
Детали модели ЖЦ выражаются в терминах этих процессов, их результатов, взаимосвязи и возникновения. Стандарт определяет множество процессов, названных процессами ЖЦ, при помощи которых может быть смоделирован ЖЦ системы.
Стадии ЖЦ. ЖЦ различаются по свойствам, целям, использованию системы, а также по преобладающим условиям. Несмотря на очевидное множество различий в ЖЦ систем, существует базовый набор стадий ЖЦ, составляющих полный ЖЦ любой системы.
********************************************
Компьютерное сопровождение жизненного цикла изделий
Идеология компьютерного сопровождения жизненного цикла изделий военного назначения (CALS) зародилась по инициативе министерства обороны США в середине 80-х годов. Тогда эта аббревиатура расшифровывалась как компьютеризированная поддержка процессов материально-технического обеспечения — Computer-Aided Logistics Support (компьютеризированная логистическая поддержка).
|
|
|
