OSS / Системноинженерное мышление в управлении жизненным циклом(2014)
.pdf
|
TechInvestLab, 14 июня 2014 |
211 |
||
|
|
|
|
|
пользы, связанной с |
|
|
|
|
адресацией этой |
|
|
|
|
возможности. |
|
|
|
|
Другие стейкхолдеры, для |
Список стейкхолдеров |
Формат списка |
|
|
которых это общая |
|
стейкхолдеров |
|
|
возможность, определены. |
|
|
|
|
Нужно решение |
|
|
|
|
Потребность в инженерном решении была подтверждена. |
|
|
||
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
|
|
(views) |
(viewpoints) |
|
|
Стейкхолдеры для |
Список стейкхолдеров |
Формат списка |
|
|
возможности и |
|
стейкхолдеров |
|
|
предложенное решение |
|
|
|
|
были определены. |
|
|
|
|
Потребности |
Документированные |
Формат описания нужд |
|
|
стейкхолдеров, которые |
нужды стейкхолдеров |
стейкхолдеров (практика |
|
|
порождают возможность, |
|
user needs analysis) |
|
|
были установлены. |
|
|
|
|
Любые связанные с |
Список рисков |
Практика управления |
|
|
возможностью проблемы и |
|
рисками |
|
|
их корневые причины |
|
|
|
|
были определены. |
|
|
|
|
Было подтверждено, что |
Подпись руководителя на |
Практика |
|
|
инженерное решение |
решении (приказе, project |
предпринимательства |
|
|
нужно. |
charter, других формах |
|
|
|
|
инициирования проекта) |
|
|
|
По меньшей мере одно |
Предложена |
Формат представления |
|
|
инженерное решение было |
верхнеуровневая |
эскизной архитектуры и |
|
|
предложено. |
архитектура решения |
требования к ней для |
|
|
|
|
данного класса решений |
|
|
Польза установлена |
|
|
|
|
Польза успешного решения была установлена |
|
|
|
|
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
|
|
(views) |
(viewpoints) |
|
|
Польза реализации |
Технико-экономическое |
Практики технико- |
|
|
возможности была |
обоснование |
экономических |
|
|
определена количественно |
необходимости системы |
обоснований, |
|
|
либо в абсолютных |
для клиента |
стратегирования, оценки |
|
|
значениях, либо в |
|
ROI и т.д. |
|
|
единицах дохода или |
|
|
|
|
экономии за период |
|
|
|
|
|
TechInvestLab, 14 июня 2014 |
212 |
||
|
|
|
|
|
(например, за год). |
|
|
|
|
Влияние решения на |
Описание удовлетворения |
Таблица, в которой |
|
|
стейкхолдеров понятно. |
needs |
описаны колонки needs и |
|
|
|
|
влияния системы на них |
|
|
Польза, которую |
User needs |
Практика "User needs |
|
|
инженерная система |
Технико-экономическое |
analysis" |
|
|
предлагает стейкхолдерам, |
обоснование |
Практика технико- |
|
|
которые финансируют и |
|
экономических |
|
|
используют систему, |
|
обоснований (оценки |
|
|
понятна. |
|
стоимости). |
|
|
Критерии успеха, по |
Меморандум о целях |
Ключевые характеристики |
|
|
которым будет |
проекта с визами |
технического решения |
|
|
приниматься решение о |
стейкхолдеров |
|
|
|
разворачивании системы, |
|
|
|
|
ясны. |
|
|
|
|
Желаемые результаты, |
Архитектурные требования |
Формат представления |
|
|
требуемые от решения, |
(основные требования, |
требований (в части |
|
|
ясны и определены |
влияющие на архитектуру) |
архитектурных |
|
|
количественно. |
|
требований) |
|
|
Жизнеспособна
Согласовано, что решение может быть произведено достаточно быстро и дёшево, чтобы успешно реализовать возможность.
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
(views) |
(viewpoints) |
Решение обрисовано в |
Архитектурное описание |
Архитектурные практики |
общих чертах. |
|
|
Есть признаки, что |
Экспертное заключение по |
Архитектурные практики |
решение может быть |
архитектуре |
|
разработано и развёрнуто |
|
|
в текущих ограничениях. |
|
|
Риски, связанные с |
Таблица рисков и способа |
Практики управления |
решением, приемлемы и |
ответов на них |
рисками |
управляемы. |
|
|
Грубая оценка цены |
Бюджет проекта в |
Практики бюджетирования |
решения меньше, чем |
сравнении с технико- |
и технико-экономического |
ожидаемая польза от |
экономическим |
обоснования |
реализации возможности. |
обоснованием |
|
Причины для разработки |
Проведение kick-off |
Практики презентации и |
инженерного решения |
meeting |
контроля понимания |
понимаются всеми |
|
|
членами команды. |
|
|
Ясно, что реализация |
Экспертное заключение |
Практика feasibilities study |
TechInvestLab, 14 июня 2014 |
213 |
возможности жизнеспособна.
Реализована
Решение, которое произведено, демонстрирует реализацию возможности.
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
(views) |
(viewpoints) |
Готовая к использованию |
Готовая система |
Конфигурационная |
система, которая |
|
ведомость |
демонстрирует |
|
|
реализацию возможности, |
|
|
доступна. |
|
|
Стейкхолдеры согласны, |
Акт о готовности к |
|
что доступное решение |
опытной эксплуатации |
|
заслуживает |
Приказ о переходе к |
|
разворачивания. |
эксплуатации |
|
Стейкхолдеры |
Подписание акта приёмки- |
|
удовлетворены тем, как |
сдачи |
|
разработанное решение |
Результаты опроса |
|
адресует возможность. |
|
|
Извлекается выгода
Эксплуатация или продажа решения создаёт осзязаемые выгоды.
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
(views) |
(viewpoints) |
Решение начало извлекать |
Акт о начале эксплуатации |
|
выгоды для |
|
|
стейкхолдеров. |
|
|
Профиль возврата |
Результат опроса |
|
инвестиций по меньшей |
стейкхолдеров- |
|
мере так хорош, как |
пользователей |
|
ожидалось. |
Сверка бюджета |
|
|
инженерной команды |
|
Определение системы
Определение системы в целом для инженерного проекта -- это самый-самый верхний уровень детализации проекта, больше пригодный для общения с менеджерами, нежели для собственно инженерии.
С определением системы лучше работать, разбивая его на различные подальфы: как соответствующие отдельным частям-модулям (ибо речь идёт об управлении разработкой), так и соответствующие различным видам описаний: подальфы
TechInvestLab, 14 июня 2014 |
214 |
требований, архитектуры, неархитектурной части проекта.
Определение системы, даже если рассматривать его через подальфы, также крайне разношёрстно в части практик описания (так только архитектурное описание в стандарте DoDAF имеет 28 видов групп описаний/viewpoint. Крайне разнообразы также и рабочие продукты -- проектная документация занимает много томов, инженерные базы данных имеют крайне сложные модели данных). Поэтому примеры практик работы с альфой определения системы носят очень условный характер.
Замыслено
Ясно, каково будет определение системы.
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
(views) |
(viewpoints) |
Ясно, что будет считаться |
User needs |
Практика Needs analysis |
успехом для новой |
|
|
системы. |
|
|
Методы описания системы |
Список документов и |
Указание на ЕСКД, СПДС, |
согласованы. |
стандартов по их |
3D моделирование |
|
подготовке |
|
Способ согласования |
Завизированный |
Указывается способ |
описаний со |
меморандум по |
предоставления доступа к |
стейкхолдерами |
согласованиям |
рабочим продуктам, |
согласован. |
|
формат и способ запросов |
|
|
на изменения (указания |
|
|
проблем), графики и сроки |
|
|
предоставления обратной |
|
|
связи, необходимые визы |
|
|
и т.д. |
Механизмы управления |
Завизированный командой |
Указываются система |
конфигурацией описаний |
меморандум по |
хранения версий, система |
согласованы. |
управлению |
управления изменениями, |
|
конфигурацией |
регламенты по работе с |
|
|
ними, конкретные папки |
|
|
или базы данных, |
|
|
заведённые для проекта |
Непротиворечиво |
|
|
Определение системы создано и непротиворечиво. |
|
|
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
(views) |
(viewpoints) |
Описания |
База данных в системе |
Практика управления |
документированы и |
управления |
конфигурацией |
|
TechInvestLab, 14 июня 2014 |
215 |
||
|
|
|
|
|
доступны команде и |
конфигурацией, все члены |
|
|
|
стейкхолдерам. |
команды и стейкхолдеры |
|
|
|
|
имеют доступ к этой базе |
|
|
|
|
данных |
|
|
|
Происхождение описаний |
Мета-информация об |
Эккаунт в системе |
|
|
ясно. |
авторе (при этом каждый |
управления |
|
|
|
автор имеет свой эккаунт) |
конфигурацией для |
|
|
|
|
каждого члена команды и |
|
|
|
|
стейкхолдера |
|
|
Описания проверяются. |
Наличие отметок о |
Роли исполнителя и |
|
|
|
проверках, а не только об |
принимающего работу |
|
|
|
окончании работ |
разведены |
|
|
|
(возможно, реализуется |
|
|
|
|
как статус issue в issue |
|
|
|
|
tracker) |
|
|
|
Противоречивые описания |
Issue, порождаемые по |
Практика проверок |
|
|
идентифицированы и ими |
обнаруженным коллизиям, |
(review, инструментальные |
|
|
занимаются. |
эти issue назначаются на |
проверки, сборки |
|
|
|
исполнителей и по ним |
конфигурации и т.д.) |
|
|
|
проводится работа. |
Практика управления |
|
|
|
|
изменениями |
|
|
Команда понимает |
Утверждённое |
Практика архитектурного |
|
|
описания и соглашается их |
архитектурное описание |
проектирования |
|
|
воплотить. |
Результаты опроса |
Практики MBSE |
|
|
Система, соответствующая |
Решение о начале |
|
|
|
описаниям, принимается |
производства |
|
|
|
стейкхолдерами как |
|
|
|
|
заслуживающая |
|
|
|
|
воплощения. |
|
|
|
|
Используется для изготовления |
|
|
|
|
Определение системы используется для изготовления |
системы. |
|
|
|
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
|
|
(views) |
(viewpoints) |
|
|
Подготовлено достаточное |
Рабочая документация |
Стандарты |
|
|
количество описаний |
(неархитектурные |
конструкторской и |
|
|
системы, чтобы начать |
решения) |
проектной документации |
|
|
изготавливать систему. |
|
|
|
|
Технологии изготовления |
Технологическая |
Стандарты |
|
|
определены. |
документация |
технологической |
|
|
|
|
документации |
|
|
Часть команды, |
Акт об успешном hand over |
Практики hand-over |
|
|
изготавливающая систему, |
Уведомление о начале |
(передачи всей |
|
|
|
TechInvestLab, 14 июня 2014 |
216 |
||
|
|
|
|
|
признаёт описания |
производства |
необходимой информации |
|
|
достаточными для |
Визы технологов на |
на очередную стадию |
|
|
изготовления системы. |
проектной |
жизненного цикла) |
|
|
|
документации/моделях |
|
|
|
Возникающие при |
Запросы на изменения, |
Практика управления |
|
|
изготовлении проблемы |
проходящие обработку |
изменениями |
|
|
приводят к переработке и |
|
|
|
|
актуализации определения |
|
|
|
|
системы. |
|
|
|
|
Используется для проверки воплощения |
|
|
|
|
Определение системы используется для проведения тестов и испытаний. |
|
|
||
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
|
|
(views) |
(viewpoints) |
|
|
Нет частей определения |
Проектная |
Архитектурное |
|
|
системы, без которых |
документация/модели |
проектирование |
|
|
проверки невозможны. |
Конфигурационная |
Управление |
|
|
|
ведомость |
конфигурацией |
|
|
Проверки, критерии их |
Программа испытаний |
Практики проверки и |
|
|
успешности и способ их |
|
приёмки (verification and |
|
|
проведения определены. |
|
validation, V&V) |
|
|
Стейкхолдеры согласны с |
Виза стейкхолдеров на |
Практика военной приёмки |
|
|
объемом проверок. |
программе испытаний |
|
|
|
Используется для эксплуатации |
|
|
|
|
Определение системы используется стейкхолдерами для её эксплуатации. |
|
|
||
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
|
|
(views) |
(viewpoints) |
|
|
Определение системы |
Формат журнала |
Модели данных |
|
|
используется для сбора |
регистрации замеров |
исторической информации |
|
|
информации о состоянии |
датчиков, проведения |
(стандарты O&M MIMOSA) |
|
|
эксплуатируемого |
обслуживания и т.д. |
|
|
|
воплощения системы. |
|
|
|
|
Определение системы |
Модели, позволяющие |
Модели надёжности |
|
|
наряду с информацией о |
определить состояние |
|
|
|
состоянии |
системы по исторической |
|
|
|
эксплуатируемой системы |
информации |
|
|
|
используется для принятия |
|
|
|
|
решений о |
|
|
|
|
техобслуживании, |
|
|
|
|
ремонтах, модернизации. |
|
|
|
|
Используется для вывода из эксплуатации
TechInvestLab, 14 июня 2014 |
217 |
Определение системы используется для ликвидации и/или переработки системы.
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
(views) |
(viewpoints) |
Определение системы |
Модели надёжности |
Практики расчётов |
используется для |
Технико-экономические |
надёжности и технико- |
определения момента |
модели |
экономического |
вывода из эксплуатации |
|
моделирования |
или принятии решения о |
|
Практики продления |
продлении эксплуатации. |
|
сроков службы системы |
Определение системы |
Обоснование безопасности |
Практики инженерных |
демонстрирует отсутствие |
при выводе из |
обоснований (assurance |
вредных эффектов |
эксплуатации |
case), в том числе |
(например, загрязнения |
|
практики обоснований |
окружающей среды) при |
|
соответствия стандартам |
выводе системы из |
|
(compliance). |
эксплуатации. |
|
|
Определение системы |
Руководство по выводу из |
Практики вывода из |
используется для |
эксплуатации |
эксплуатации по ISO |
планирования и |
|
15288, отраслевые |
проведения работ по |
|
практики вывода из |
ликвидации и/или |
|
эксплуатации |
переработке воплощения |
|
|
системы. |
|
|
Воплощение системы
Получить успешное (удовлетворяющее стейкхолдеров) воплощение системы -- это и есть главная цель инженерного проекта, даже определение системы нужно главным образом как средство получить воплощение системы, а не само по себе. Традиционно практики системной инженерии работают с воплощением системы больше на конечных состояниях этой альфы, а именно в части практик проверки и приёмки. А ещё важно при воплощении системы управлять конфигурацией: чтобы всё запроектированное было закуплено/изготовлено, и именно оно попало в состав целевой системы, и именно целевая система затем была налажена, проверена-принята и пошла в эксплуатацию.
Обращаем внимание на то, что карточки отнюдь не заканчиваются сдачей в эксплуатацию: жизненный цикл системы всегда полный -- до самого её вывода из эксплуатации (включая уничтожение или переработку). И карточки с контрольными вопросами не дают об этом забыть.
Подальфы определения системы чаще всего -- это подальфы отдельных модулей, требующих особого контроля.
TechInvestLab, 14 июня 2014 |
218 |
В виде сырья
Материалы для воплощения системы наличествуют и готовы к изготовлению частей.
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
(views) |
(viewpoints) |
Материалы для |
Сводный список материалов |
Практики цепочки |
воплощения системы |
и комплектующих |
поставок (supply chain), |
наличествуют и позволяют |
(библиотек в случае |
форматы data sheets и |
создать детали с нужными |
программных систем) с |
опросных листов с |
характеристиками. |
оценками их доступности |
характеристиками |
|
|
материалов и |
|
|
оборудования |
Оборудование для |
Список |
Архитектура предприятия |
переработки материалов в |
оборудования/инструментов |
|
детали наличествует. |
с оценками доступности |
|
График производства и |
Визы на графике |
Практики планирования |
логистики частей системы |
производства и |
проектов |
согласован. |
логистических графиков |
|
Возможны работы по |
Технико-коммерческие |
Типовые форматы |
изготовлению частей. |
предложения от |
технико-экономических |
|
подрядчиков |
предложений |
В виде частей (parts)
Части системы созданы и готовы к интеграции.
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
(views) |
(viewpoints) |
Части системы созданы |
Части системы |
Управление |
и/или закуплены и |
Накладные |
конфигурацией |
проверены. |
Акты входных испытаний |
|
График интеграции |
Визы на графике |
Проектное управление |
(сборки, монтажа, |
интеграции |
|
строительства) из частей |
|
|
согласован. |
|
|
Возможны работы по |
Уведомление о начале |
|
интеграции (сборке, |
сборки, монтажа, |
|
монтажу, строительству). |
строительства |
|
Демонстрируемо |
|
|
Система собрана из её частей и готова к проверке. |
|
|
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
(views) |
(viewpoints) |
Система может быть |
Наличие собранной |
|
|
TechInvestLab, 14 июня 2014 |
219 |
||
|
|
|
|
|
опробована в её |
системы (акт) |
|
|
|
отдельных функциях и её |
|
|
|
|
ключевые характеристики |
|
|
|
|
могут быть измерены. |
|
|
|
|
Ключевые характеристики |
Оборудование для |
Практики проверки и |
|
|
системы могут быть |
испытаний, наборы тестов |
приёмки |
|
|
продемонстрированы. |
|
|
|
|
Критические интерфейсы |
Акты испытаний |
|
|
|
были |
интерфейсов |
|
|
|
продемонстрированы. |
|
|
|
|
Интеграция с другими |
Акты испытаний |
|
|
|
существующими системами |
интерфейсов |
|
|
|
была продемонстрирована. |
|
|
|
|
Необходимые |
Решение о проведении |
|
|
|
стейкхолдеры согласны, |
испытаний |
|
|
|
что систему нужно |
|
|
|
|
проверять. |
|
|
|
|
Готово |
|
|
|
|
Система (как целое) была принята для эксплуатации её в операционном |
|
|
||
окружении. |
|
|
|
|
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
|
|
(views) |
(viewpoints) |
|
|
Функциональность, |
Протоколы испытаний |
Практики проверки и |
|
|
обеспечиваемая системой, |
|
приёмки |
|
|
протестирована. |
|
|
|
|
Уровни дефектов |
Отсутствие протокола о |
|
|
|
приемлемы для |
доделках |
|
|
|
стейкхолдеров. |
|
|
|
|
Установочная и другая |
Установочная и |
Управление |
|
|
пользовательская |
пользовательская |
конфигурацией |
|
|
документация доступна. |
документация: указание на |
|
|
|
|
репозиторий |
|
|
|
Представители |
Акт приёмки-сдачи |
|
|
|
стейкхолдеров принимают |
|
|
|
|
систему, как |
|
|
|
|
удовлетворяющую своему |
|
|
|
|
назначению. |
|
|
|
|
Состав передаваемой |
Виза стейкхолдеров на |
Управление |
|
|
стейкхолдерам системы |
конфигурационной |
конфигурацией |
|
|
известен. |
ведомости |
|
|
|
Представители |
Приказ стейкхолдера о |
|
|
|
стейкхолдеров хотят |
начале эксплуатации |
|
|
|
|
TechInvestLab, 14 июня 2014 |
220 |
||
|
|
|
|
|
принять систему в |
системы |
|
|
|
эксплуатацию. |
|
|
|
|
Эксплуатационная |
Контакты службы |
Организация сервиса (ITIL |
|
|
поддержка наличествует. |
эксплуатационной |
в случае программных |
|
|
|
поддержки, виза службы |
систем). |
|
|
|
эксплуатационной |
|
|
|
|
поддержки о принятии на |
|
|
|
|
обслуживание |
|
|
|
Эксплуатируется
Система эксплуатируется в её операционном окружении.
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
(views) |
(viewpoints) |
Система сделана |
Наличие пользователей |
|
доступной стейкхолдерам, |
|
|
которые намерены её |
|
|
использовать. |
|
|
Есть как минимум один |
Работающая система |
|
пример полностью |
|
|
работающей системы. |
|
|
Система полностью |
Соглашение SLA о |
Организация сервиса (ITIL |
поддерживается на |
поддержке системы |
в случае программных |
согласованном уровне |
Журналы мониторинга |
систем) -- хелпдеск, |
сервиса. |
уровня сервиса |
отслеживание инцидентов |
|
|
и т.д. |
Выведено из эксплуатации
Воплощение системы больше не поддерживается, система ликвидирована и/или переработана.
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
(views) |
(viewpoints) |
Воплощение системы было |
Акт о выводе из |
|
заменено или прекращено |
эксплуатации |
|
в использовании. |
|
|
Система больше не |
Приказ об окончании |
|
поддерживается. |
поддержки |
|
|
Акт о закрытии договора |
|
|
поддержки |
|
|
Уведомление об окончании |
|
|
поддержки |
|
Нет «официальных» |
Отсутствие стейкхолдеров |
|
стейкхолдеров, которые до |
|
|
сих пор используют |
|
|