Сумма стратегии

(…) Необходимо рассматривать не просто структуру продукта или предприятия, а концепцию полного жизненного цикла выпускаемого продукта или предприятия: (…) «Рассмотрения системы (организации, атомной электростанции, человека или даже общества) с точки зрения ее структуры (схемы, отражающей связи элементов-подсистем) совершенно недостаточно, нужно рассматривать изменения во времени и взаимодействия подсистем, разворачиваемые во времени. Реализация этого подхода требует 4-D (3-D плюс время) представления продукта, то есть полноценной информационной модели системы (продукта) в различных временных точках».

(…) Недостаточно иметь только одну профессиональную точку зрения на систему, например описание системы только со стороны конструктора или проектанта, чтобы получить полное реализационное описание системы. Должны быть получены различные группы взаимосвязанных описаний, (заказчика, эксплуатирующей организации, регулирующего органа, общественности и т.д.). В системной инженерии этот подход отражен в стандарте архитектурных описаний ISO 42010. Переход от рабочего проектирования (конструирования, дизайна) к обязательному предварительному архитектурному проектированию.

Под архитектурным проектированием понимается разработка предварительной структуры будущей системы. Прежде чем приступать к техническому или рабочему проектированию, необходимо разработать архитектуру будущего проекта на основе собранных требований различных заинтересованных сторон. Специалисты в области управления требованиями Элизабет Халл, Кен Джексон, Джереми Дик («Разработка и управление требованиями») пишут: «Некоторые инженеры и разработчики зачастую сразу же начинают вдаваться в излишнюю детализацию даже на самых ранних этапах (т.е. захватывать большие куски пространства на поле общего дизайна). Надо постараться исключить такую тенденцию или, как минимум, всячески ее ограничивать с той целью, чтобы дать возможность работать всей команде, использовать способности и таланты других специалистов, стимулировать творческий подход к совместному решению проблем на всех этапах и в итоге получить по-настоящему инновационное решение. Ведь ясно же, что такое инновационное решение не может быть получено, если на самых первых шагах проекта создавать ограничения жизненного пространства, связанные с принятием преждевременных, излишне детализированных решений».

(…) Иными словами, для начала нужно сделать сущностное, не зависящее от деталей реализации описание создаваемой системы – создать ее архитектуру. Архитектура описывает основные подсистемы и их взаимодействие на языке, свободном от деталей реализации. Одной архитектуре может соответствовать множество разных реализаций, например концептуальных проектов.

(…) С помощью компьютерных кодов нужно создавать проект «виртуального продукта», например проект «виртуальной» АЭС, включающий 3-D или 4-D геометрическую модель энергоблока, динамическую математическую модель энергоблока, которая полностью имитирует работу энергоблока, модель прочности и надежности компонентов и т.д.

На «виртуальной» АЭС можно и должно проверять (верифицировать и валидировать) все спроектированное оборудование в комплексе и в различных режимах для предотвращения ошибок проектирования и поиска оптимальных решений, включая многовариантное моделирование архитектурных решений. Сначала система строится в идеальном мире моделирования и только затем в реальном мире: все ошибки убираются на этапе моделирования, а не на этапе реального воплощения в металле и бетоне.

(…) Вся проектная документация должна создаваться не в виде бумажных или файловых документов, а в форме базы данных (БД), где документ в старом понимании бумажной технологии создается только как производная функция базы данных по составлению отчетов, а вся информация по проекту хранится в базе данных в специально замоделированном виде. Любые изменения, возникающие в проектной документации, – это изменения данных в определенных ячейках БД, что влечет автоматическое изменение документа как производного базы данных.

(…) Наличие множества заинтересованных в системе сторон существенно меняет содержание инженерной деятельности: эта деятельность по «инженерии требований» уже не проходит в мире исключительно технических решений, а должна учитывать противоречивые интересы самых разных сторон (стран, организаций, сообществ, людей).

(…) На практике мало кто использует один раз разработанный план, чаще всего планы постоянно пересматриваются с отсрочкой срока изготовления. Идея гибких методов переход к практике принятия решений на основе анализа риска (расчет нескольких вариантов решений с оценкой риска каждого варианта и выбор наиболее оптимального решения).

Этот подход подразумевает пошаговое выделение ресурсов на основе постоянного пересмотра их выделения с учетом непрерывно меняющихся оценок проектной ситуации».