Обсуждение

1) Почему процессы (которые потоки) объединены с функциями? Они должны быть либо отдельно, либо вместе с моделью конструкции. Эти процессы - часть модели белого ящика, а не чёрного. 2) "2.1. Модель жизненного цикла -- процессы системной инженерии, выполняемые обеспечивающими системами." А куда девать эксплуатационные процессы целевой системы? Они же выполняются целевой системой, и проектируются обеспечивающими на этапе дизайна, как и модель конструкции. Они не входят в модель ЖЦ? На мой взгляд, разделения на целевую и обеспечивающую системы при описании вьюпойнотов симултрека не имеет никакого смысла. Краны, опалубки и леса стадии строительства разве не в модели конструкции? А они же часть обеспечивающей системы, их нет в целевой. 3) Вообще я бы выкинул из определений слова ЖЦ. Они тут ни к чему. 2.1 должно назваться Модель деятельности, 2.2 - Модель организации. ЖЦ - это уже конкретизация этих определений на специфику SE, в изводе 15288.

1) цитируем Andries van Renssen (Gellish Modelling Method, Part 6, Knowledge and Product Modelling) 6. Functional Requirements & Process Design In the discrete component industry a design or specification starts with the definition of the functional requirements for the physical object (the discrete item). That is a specification of what the item is required to do. In the process industry a design or specification also starts with what is required to be done. However, there it is called ‘process design’ and that is described in terms of the processes that take place in the fluids, signals and energy that need to flow through the future discrete items in order to achieve the intended objective. These two approaches and two sets of terminology can be harmonised and described by using the same mechanisms as described below! In the ‘discrete component’ industry approach the term ‘function’ indicates “what should be done and which roles should be fulfilled”. In other words which activities, or behaviours are required and what roles the items should play in those activities or behaviours. Such an ‘activity’ or ‘behaviour’ can be active, such as in a machine, or passive, such as in a building, where a wall or beam should bear a load. In both cases the item has a behaviour in terms of motion and/or elastic or plastic deformation. The interaction between discrete items is expressed in terms of load and/or energy flows, signal flows and sometimes in terms of fluid flows. In this approach, a ‘pure’ functional description describes the required behaviour without defining the type of discrete items that perform the roles. In other words a functional design describes the activities or behaviour of discrete items (physical objects) and their roles. Strictly speaking those physical objects should not be classified in pure functional description, but in practice they are usually classified on a rather high level. Often a functional design does make the loads, fluids and energy flows and their classification explicit. In the ‘process’ industry approach, the description of the behaviour of its discrete components is preceded by a description of ‘the process’, which appears to be the behaviour of the fluids, signal flows and energy flows and sometimes loads, together with the roles which which should be played by the discrete items that enable the behaviour of the fluids. Passive ‘activities’ also appear, such as in storage or support processes. The interaction between processes is described by energy flows, fluid flows or signals, which are output of one process (activity) and input to another process (activity). Finally the connections between discrete items are used to describe mutual loads. Gellish defines an ‘activity’ as something that happens, or as a transition from one state to another. Therefore, it sees ‘behaviour’ as well as ‘process’ as subtypes of ‘activity’. This means that both approaches, the ‘functional design’ and the ‘process design’ can both be described as an activity in which physical objects, such as energy flows, signals and fluids play various roles.

Ага, я понял - откуда непонимание. Ренссен пишет, что на одном уровне декомпозиции нет отличия между функцией компонента и протекающими _через_ него _внешними_ потоками. Собственно, функция и описывается у него через те потоки, которые она преобразует. Однако в описании вьюпойнтс на модели у тебя нет пояснения соответствия уровней, поэтому я и отнёс модель потоков к следующему уровню декомпозиции, когда раскрытие внутренних потоков становится первым шагом к раскрытию белого ящика. Возможно, так и надо описать: не "как функциональные требования, "поведение", так и процессы", а "функциональные требования, выраженные через преобразование потоков".

2) С целевой и обеспечивающей системами на этапе эксплуатации хитро: целевая система смещается, а бывшая система становится целевой (скажем, АЭС начинает приносить электроэнергию, и теперь целевая система -- электроэнергия, а АЭС -- обеспечивающая система). Скорее всего, нужно говорить о модели жизненного цикла (процессах), которые на всех этапах внешние, кроме этапа эксплуатации (типа "система оживает"). Жизненный цикл (прохождение активностей) проходит независимо от разделения системы на обеспечивающие и целевую, тут я согласен. Но это не повод сдавать понятие целевой системы. Если рассматривать 4D, то опалубка и прочие строительные леса -- это темпоральные части, тут никаких противоречий. Появились в какой-то момент, а в какой-то момент сгинули. То же -- с заменяемым в ходе эксплуатации оборудованием.

3) Нет, за жизненный цикл (конкретные экземпляры процессов) нужно держаться: эта концепция пришла в SE из других мест (и на эту тему есть отдельное даже движение CALS). Замечу, что даже наши клиенты ее используют, безо всякой системной инженерии. В SE им.ISO 15288 важное разделение: жизненный цикл -- это само выполнение процессов, перемежаемое точками принятия решений о продолжении очередных стадий, а вот набор процедур (инструкций) для этого выполнения является моделью жизненного цикла. То есть вводятся два понятия: ЖЦ и МЖЦ. Я бы за них держался и не выкидывал. Почему я добавляю к "модели организации" и "модели ЖЦ" слова ЖЦ? Потому что речь идет, скорее, о расширенной организации, а не об одной конкретной лавке и ее организации и процессах. Но я хотел бы уйти от понятия "расширенной организации", или "организации проекта", оно мутное. Поскольку "Большой Проект" тут равнозначен жизненному циклу, я и добавляю это уточнение: организация жизненного цикла (читай: "организация проекта", ибо ЖЦ -- это проект) и модель жизненного цикла (поскольку ЖЦ -- это проект, набранный из процессов, то это эквивалентно "модели процессов" или "модели проекта").

"Смещение" целевой системы невозможно в рамках самой идеологии подхода ЖЦ. "палубка и прочие строительные леса -- это темпоральные части" А кран не сгинул - он уехал на другую стройку. Ты же сам только что сказал, что само понятие "целевой" смещается. Не вижу проблемы в моём предложении - вьюпойнты различаются по способу отображения фактов, почему в один вьюпойнт не могт входит факты о разных связанных системах? Не прелагаю ничего "сдавать".

Я понял, почему мы путаемся. "Целевая система" -- это не объект! Это роль :)

Отлично! Модель системы - это роль системы (объекта) в некоторых отношениях. При этом не важно, в какой роли эта система находится в иных отношениях.