В стандарте описания методов управления жизненным циклом SPEM 2.0 (называемом Software and System Process Engineering Metamodel) предложено жестко различать ContentMethod и Process для указания на метод и указания развертки по времени любых видов (логической или стадийной).
Метод (а точнее, его маленький кусочек -- практика) никак не связан с процедурой, в нем не дается последовательность действий (о чем соответствующие стандарты обычно явно предупреждают -- например, это оговаривается в ISO 24774). Скажем, практика пассировки овощей рассказывает, что овощи нужно жарить в масле, чтобы они были вкуснее при варке (правда, в малороссии пассировку считают методом ухудшения вкуса первых блюд, который придумали дикие в пищевом отношении северные народы. В Москве ведь не едят, а питаются). Для описания практик используется формализм process ISO 24774 или MethodContent SPEM 2. Практики затем используются в процедурах (и поэтому их в SPEM 2 даже обозначают в процедурах не значком "практика", а специальным значком "использование практики").
После этого "использования" (use в SPEM 2) появляется процедура: рецепт приготовления борща, в котором используется уже известная и общая для всех рецептов практика пассировки. Для описания последовательности использования дел в процедурах используется формализм BPMN 2.0 (включающий оркестровку-BPMN 1.1, ежели борщ готовит семья, а также хореографию-DEMO, ежели речь идет о распределении работ между несколькими сервисами (сервис -- это агент, исполняющий DEMO-трансакцию)).
Следуя этому предложению, нужно по-разному переводить слово process в зависимости от смысла:
-- указание на метод работы, "кто что как с чем делает", независимо от момента времени: практика.
-- указание на последовательность шагов, "что за чем делается", логическая развертка во времени цепочки действий: процедура
-- указание на последовательность стадий, оканчивающихся контрольными точками: форма жизненного цикла (если это обобщенное описание) или проект-project (если описание для конкретной системы).
Конечно, в англоязычных текстах можно встретить игру слов, в которой (часто -- намеренно, из-за невозможности и нежелания различить методический и временнОй аспекты проговариваемых разных уровней описания жизненного цикла, как на детальном уровне описания конкретного ЖЦ, так и в варианте типового описания -- метода управления жизненным циклом), его целиком называют process, чаще всего в традиции словоупотребления software process. Так, в текстах по ICM они самоназывают ICM, а также RUP, DSDM и т.д. как process).
Ситуация осложняется, ибо в разных подходах (frameworks) принято по-разному соотносить понятия для разных явлений (occurrence), обозначаемых словами process, activity, task, work. Где-то process состоит из ряда логически (результирующий артефакт одной является входным артефактом другой) связанных друг с другом экземпляров activities, а где-то activity представляет собой класс для всех process. Во всех этих случаях нужно передавать process и activity разными словами.
Дополнительное осложнение происходит от выбранного в ISO 15288 способа рассказа о целевой системе (system-of-interest) и ее жизненном цикле (включающем процессы изменений под воздействием обеспечивающей системы) как центральном объекте. На самом деле разговор по факту идет все времи про практики и процедуры обеспечивающей системы (enabling system), выполнение которых неформально называют управлением жизненным циклом. Словосочетание life cycle management поэтому в сам стандарт ISO 15288 не попало, зато попало в названия различных стандартов ISO (например, ISO TR 24748 -- Gide for life cycle management, в котором как раз поясняется терминология, связанная с описанием жизненного цикла). В кругу самих стандартописателей говорят же просто о практиках жизненного цикла (а не практиках управления жизненным циклом), не смущаясь тем, что практики эти относятся не к целевым системам, а к обеспечивающим системам -- в силу взаимно однозначного соответствия между делателем и делаемым.
Для всего обсуждаемого (process, iteration, activity, task) SPEM 2 использует класс Work Definition = определение работы, который сам является стереотипом для метаклассов Action и Classifier), и это Work Definition можно укладывать как в процедуры, так и в практики. Мудро, по-русски "описание работы" тоже означает все, что угодно -- и процедурный, и методический аспект.
Но это не отменяет задачи перевода самих process, iteration, activity, task и даже step. Особенно, ежели activity является подклассом не только Work Definition, но и Work Breakdown Element (а там уже и до упоминания milestone недалеко -- Because Milestone is commonly used to refer to both the event itself and the point in time at which the event is scheduled to happen, it is modeled as a Work Breakdown Element (i.e., it appears as part of a breakdown structure and can have predecessors)).
Итого, предложение по русскоязычной гармонизации понятий, связанных с process (для основных стандартов организационного моделирования):
1. ISO 15288 и 24774
-- process=практика, activity=мероприятие, task=дела
-- process reference model = типовой набор практик
-- life cycle form = форма жизненного цикла (последовательность стадий), порождается (не указано в ISO 15288!) методом управления жизненым циклом (типа ICM, RUP, DSDM, OpenUP и т.д.).
-- life cycle model = описание жизненного цикла
2. SPEM 2
-- method content = практика
-- process = форма жизненного цикла
-- method framework = метод управления жизненным циклом
-- process, delivery process, development process, software process, software and system process = описание жизненного цикла
-- workflow = процедура
-- activity = <деятельность> (чтобы не закрывать возможность характеризовать как практику, так и процедуру)
Но это еще не вся история, ибо далее процедуры нужно выражать в BPMN 2, а его делала еще одна группа людей, у которой сложились свои собственные представления о моделировании деятельности.