Непрерывность означает, что одно разовое изменение вряд ли возможно, и нужно непрерывно подстраивать систему под стремительно меняющееся окружение, непрерывно вводить в эксплуатацию всё новые и новые «фичи» как результат «умных мутаций». Какие-то из этих новых фич позволят системе выжить среди систем-конкурентов, какие-то окажутся ненужными и временными, но непрерывность означает, что инженерия не разово делает системы, а evolve/«эволюционирует» их. По-русски это лучше будет говорить «развивает» (ибо «выращивает» сложно говорить про какой-нибудь ледокол-атомоход, но можно сказать, что этот ледокол-атомоход развивается. Впрочем, идея непрерывности инженерии до атомоходов ещё не дошла, её мы больше наблюдаем на примере программного обеспечения. Посмотрите, как часто обновляется Windows или даже BIOS в вашем ноутбуке).
Альтернативная формулировка инженерии – это создание успешных систем (также было подробно разобрано в курсе «Практическое системное мышление»). Успешность определяется как соответствие ожиданиям внешних проектных ролей, которых множество самых разных (и это требует безмасштабности в работе с системами, интересными для разных ролей) и ещё эти ожидания меняются (что требует непрерывности изменений целевой системы, её развития под эти изменяющиеся ожидания). Это определение более традиционно и основывается на классических рассмотрениях проектов системной инженерии. Если со всеми договорились (с учётом соображений безопасности и того, кого считать врагом, а кого считать другом и клиентом), и продолжают договариваться всё время существования системы, то система успешна. Если не договорились, и при изменениях ситуации не успевают передоговариваться (непрерывное договаривание, а не разовое) – не успешна. Тут по факту тоже оптимизационная задача, но рассмотрение не столько многоуровневое/безмасштабное системное, сколько деятельное/методологическое/практическое по линии разнообразия ролей, предметов их интереса и интересов, а также выходящее за рамки одного жизненного цикла техноэволюционное рассмотрение.
«Успешность системы» – в разы более простой критерий: «если все внешние проектные роли, которые мы выявили, непрерывно соглашаются с проектом, то это и означает, что мы мир изменяем к лучшему – наша система непрерывно успешна». Классическая системная инженерия ещё несколько лет назад даже выкинула бы слово «непрерывно», ибо в головах системных инженеров прошлого система изготавливалась однократно, и больше не менялась по ходу эксплуатации, не нужно дальше ни с кем договариваться, не нужно менять систему. Модернизации системы, конечно, предусматривались, но они были абсолютно автономными тоже разовыми проектами, а не частью непрерывно ведущейся инженерии. Ближе тут, конечно, была концепция апгрейда (например, апгрейд компьютеров, который был популярен в 90е годы прошлого века). Но это была «инженерия пользователя» для редкого класса систем, а не штатный способ организации инженерной деятельности. В телефонах наоборот: апгрейд аппаратный был запрещён (невытаскиваемая батарейка, отсутствие слота для внешней памяти), зато расцвёл апгрейд прошивок и апгрейд приложений. Телефон перестал быть неизменяемым объектом, даже когда попадал к покупателю. Это, конечно, создаёт и множество проблем (так, чей это теперь телефон, если его купили, но продавец продолжает его «производить»? Ответ не такой очевидный2).
Но тут кроется и много проблем: разработка обычно центрируется на поведении целевой системы в составе непосредственной её надсистемы, то есть главным образом на двух системных уровнях. Если в таком подходе разрабатывается киберфизическая система, то могут не учитываться соображения более высоких системных/эволюционных уровней – включая уровни эко-системы (сообщества), общества, человечества.