Описание процесса по ISO TR 24777 выделяет следующие обязательные атрибуты описания процессов (process atributes): заголовок-название, цели выполнения, tasks, которые группируются в activities, наблюдаемые результаты (outcomes). В обязательные атрибуты включаются из ISO 15504 оцениваемые показатели (assesment indicatiors) -- ресурсы, практики, рабочие продукты (которые делят на хардвер-оборудование, сервисы, софтвер вкупе с данными и документацией, материалы типа воды).
Процессный фреймворк -- это набор моделей (описаний) процессов. Процессные фреймворки отличаются принятой в них процессной архитектурой.
Процессная архитектура -- это воплощенные в процессном фреймворке а) уровни абстракции в описании процессов и б) вариант разбиения деятельностей (activities) на различные процессы. Консенсуса по поводу того, какая должна быть процессная архитектура, среди стандартизаторов до сих пор нет -- этот консенсус формируется в настоящее время на основе стандартов системной инженерии.
На сегодня наиболее авторитетно принятое в середине 90-х IEEE разбиение уровня абстракции процессов на три уровня: референсный, концептуальный, реализационный (http://standards.computer.org/sesc/s2esc_pols/FP-10_Process_Abstraction.htm). Так, ISO 15288 или ISO 12207 это референсные процессные фреймворки системной инженерии (указание набора деятельностей-activity, которые могут выполняться каждая одним агентом -- такой набор однородных и склеенных деятельностей и есть отдельный процесс).
Концептуальный уровень описывает ход (flow по-русски -- это ход, никакой "потоковой метафоры, увы. См. http://ailev.livejournal.com/503568.html, п.1 второго списка) управления и данных между агентами (т.е. описывает протоколы между референсными процессами/агентами). Концептуальные процессы описывают отношения агентов как по управлению, так и по обмену данными.
Модели жизненного цикла -- это концептуальные процессные фреймворки, характерные для тех или иных вариантов жизненных циклов. Именно на этой стадии происходит выбор способа взаимосвязи (последовательное, параллельное, итеративное приложение определяемых описанием 25 поцессов деятельностей к системе и т.д.) предлагаемых референсной процессной моделью. Именно в модели жизненного цикла, как концептуальном уровне абстракции, фиксируется решение следовать путем параллельной инженерии, или выбирать последовательное прохождение стадий, именно тут находится баланс между "водопадными" и agile способами разработки. Именно в модели жизненного цикла вам придется признаться, придерживаетесь ли вы в ваших процессах быстрого прототипирования, или полагаетесь на SCRUM-методологию. Именно тут для эксплуатации вы выбираете между ремонтом по состоянию или ремонтом по нормативам, после чего рисуете диаграммку того, как (последовательность и другие отношения) связаны разные процессы (или, следуя традиции рассмотрений IEEE -- как связаны разные агенты, ответственные за выполнение процессов).
Реализационный (implementation) уровень включает отображение агентов с их процессами на реальные организации и использующиеся в ней инструменты (например, конкретное программное обеспечение, поддерживающее тот или иной способ описания workflow, или краны определенной грузоподъемности, предполагающие какую-то определенную технологию монтажа). "Положения о ..." (policy) и "Инструкции по ..." (procedures) появляются как описания процессов в реализационном процессном фреймворке -- в котором концептуальные описания привязываются к конкретным инструментам и организационным реалиям.
В базовых описаниях ISO 15504, ISO TR 24774, ISO 15288, ISO 12207 нет ссылок на три уровня абстракции, и поэтому прямо в референсном стандарте делаются неожиданные оговорки, что "для получения результатов (outcomes) необходимы инструменты и процедуры" (то есть перепрыгивается с референсного языка на язык реализационного уровня). Полное перечисление того, что нужно "для получения результатов процессов" включает политики (policy), процедуры, методы (способы), методологии (наборы методов и описание их связей), техники, инструменты -- и этот списочек дается в разных местах референсных процессных описаний в той мере, в какой авторы этих стандартов касаются реализационных описаний.
Приведенное разбиение процессных описаний по уровням абстракции (референсный -- "процессы жизненного цикла", концептуальный -- "модели жизненного цикла", реализационный -- "процедуры и инструменты жизненного цикла") не должно смешиваться с детализацией (на максимум три уровня попроцессов, как указано в ISO TR 24774), а также оформлением каких-то связанных activities в отдельные процессы. На каждом уровне абстракции принята своя, отличная от других уровней онтология. В рамках же детализации ("укрупненные процессы", "детальные описания", "подпроцессы") все эти уровни детальности описываются в одной онтологии того уровня абстракции, для которого происходит эта детализация.
По вопросу содержательного разбиения деятельностей на различные процессы наиболее авторитетно (то есть к нему в спешном порядке приводятся самые разные другие процессные фреймворки, описывающие самые разные жизненные циклы для самых разных систем) разбиение, предложенное в ISO 15288 и 12207 (фактически, это сейчас консенсус IEC, IEEE, ISO и многих других более мелких организаций стандартизации), которое сводится к предписанным 25 обязательным процессам системной инженерии, разбитым на четыре процессные группы.
Интересно, как обо всем этом рассказывать, не произнося умных слов "процессный фреймворк" и "процессная архитектура"? Ибо весь мой опыт показывает то, что значение слов "фреймворк" и "архитектура" обычными инженерами не понимается ни сразу, ни потом. Равно как и "референсный", "концептуальный" и "реализационный" в их противопоставлении (и даже без противопоставления). Хотя с "детализацией" обычно никаких проблем, равно как с предметным разбиением на 25 обязательных процессов.