Спецификация метамодели программной и системной инженерии процессов
Сокращенный перевод OMG SPEM 2.0
TechInvestLab.ru
версия 1.0, 30 ноября 2009г.
В данном сокращенном переводе приведены те фрагменты текста, которые соответстсвуют понятийной части метамодели и не затрагивают особенности ее реализации в виде специализированного профиля UML 2.
При переводе были сделаны терминологические выборы (см. прилагающийся краткий англо-русский словарик), которые минимизируют пересечения терминов с терминологией системной инженерии в версии ISO 15288 (так, Activity-SPEM передано как «активность», а Activity-ISO15288 как «мероприятие»). Терминология в тех местах, где это было уместно, оставлена одинаковой (так, task – «дело» в обоих случаях).
Данный сокращенный перевод дан исключительно с целью обсуждения выбора терминов для русскоязычной коммуникации по поводу ситуационной инженерии методов с использованием инструментальных средств, поддерживающих стандарт SPEM 2.0. Также данный текст может быть использован как справочный материал (ибо он не предполагает последовательного изложения и не может поэтому служить учебным пособием) для инженеров методов, встретившихся с трудностями моделирования в подходе SPEM 2.0 и желающими разобраться в какой-то особенности метамодели.
Для реализационных целей (разработки соответствующего стандарту программного инструментария) рекомендуется использовать полный оригинальный английский текст спецификации SPEM 2.0, который можно найти тут: http://www.omg.org/spec/SPEM/2.0/
Авторы сокращенного перевода выражают благодарность членам Русского отделения INCOSE за плодотворные обсуждения терминологических выборов, но не снимают с себя ответственности за окончательный текст.
Замечания и предложения по переводу и терминологическим выборам просьба присылать Анатолию Левенчуку на адрес ailev@asmp.msk.su
1. Спецификация метамодели программной и системной инженерии процессов, версия 2.0 (SPEM 2.0)
Software & Systems Process Engineering Meta-Model Specification
Version 2.0 (SPEM 2.0)
|
Спецификация метамодели программной и системной инженерии процессов
Версия 2.0 (SPEM 2.0)
Сокращенный перевод с англ.
|
|
[0. Термины и определения]
|
An Activity is a Work Breakdown Element and Work Definition that defines basic units of work within a Process as well as a Process itself. In other words, every Activity represents a Process in SPEM 2.0. It relates to Work Product Use instances via instances of the Process Parameter class and Role Use instances via Process Performer instances.
Activity supports the nesting and logical grouping of related Breakdown Elements forming breakdown structures (not shown in Figure 9.4, see Figure 9.9). The concrete breakdown structure an Activity defines (i.e., its contained elements) can be reused by another Activity via the used Activity association (see Figure 9.5), which allows the second Activity to inherit its complete sub-structure (see Section 9.2 for details). [9.1]
Activity from Process Structure (Section 9.1) is extended in this meta-model package with the ability to also contain Task Uses, Team Profiles, and Composite Roles.
Activity represents a grouping of nested Breakdown Elements such as other Activity instances, Task Uses, Role Uses, Milestones, etc. It is not just a ‘high-level’ grouping of work such as Work Definitions as in other similar meta-models. It also aims to be a grouping for all different kinds of Breakdown Elements defining a namespace for these elements. The goal for this approach is that instances of specific Breakdown Element instances need to define different relationships and textual documentation properties for occurrences in different activities. For example, a SPEM 2.0 user could create three instances of Role Use that represent a Role Definition called “System Analyst” for three different activities. In each of these activities, the different Role Use instances all representing the same Role Definition “System Analyst” could be modeled with different relationships, such as different responsibilities for Work Products, to represent the fact that the System Analyst has to focus on different responsibilities in different activities (e.g., he might be responsible for quite different work product in an early phase of a project than in a later phase; with phases modeled as Activities). [13.1]
|
Активность (Activity) — элемент разделения работы и определение работы, определяющие основные единицы работы в процессе, а также сам процесс. Другими словами, в SPEM 2.0 каждая активность представляет процесс. Она соотносится с экземплярами применения продуктов посредством экземпляров класса Параметр процессов и с экземплярами применения роли посредством экземпляров исполнителя процесса.
Активность допускает вложение и логическую группировку связанных элементов разделения, образующих структуру разделения. Конкретная структура разделения, определяемая некоторой активностью (т.е. содержащиеся в ней элементы) может быть переиспользована другой активностью посредством примененной данной активностью ассоциации, допускающей унаследование второй активностью всей ее подструктуры.
Активность из структуры процесса дополняется в настоящем пакете мета-модели возможностью включения применений дела, профилей команды и составных ролей.
Активность представляет группировку вложенных элементов разделения, таких как другие экземпляры активностей, применения дел, применения ролей, контрольные точки и т. п. Это не просто «высокоуровневая» группировка работ, подобная определению работы в других сходных мета-моделях. Она также стремится включить группировку всех остальных элементов разделения, определяя для них пространство именования. Данный подход обусловлен тем, что экземпляры каждого элемента разделения требуют при включении в различные активности определения собственных связей и документируемых в тексте свойств. Например, пользователь SPEM 2.0 может создать три экземпляра применения роли, представляющие определение роли «системный аналитик» в трех различных активностях. Каждый из трех экземпляров применения роли представляет одно и то же определение роли «системный аналитик», и все они могут описываться с помощью различных связей, например, различных обязанностях по отношению к продукту, отражая тот факт, что системный аналитик обязан в различных активностях сосредоточиться на различных обязанностях (например, он может отвечать за совершенно различные продукты на ранней и поздней стадиях проекта, когда стадии описаны как активности).
|
Activity Kinds provides the capability for a process engineer to define life-cycle models using the terminology they are used to. For example, if a process engineer would like to distinguish specific levels of the breakdown to represent a special kind of Activities, s/he can define instances Activity Kinds and assign these to the Activities. ‘Phase’ and ‘Iteration’ are popular examples for Breakdown Element Kinds. They would be represented in a breakdown structure as Activities with respective Kinds assigned. Another example can be found in the IBM Rational’s Summit Ascendant Method. The first level of Summit’s breakdown structure is not referred to as Activity, but as a ‘Module.’ The Kind class allows defining and modeling such specific interpretation of the breakdown level. [18.1]
|
Виды активностей (Activity Kinds) обеспечивают инженеру процессов возможность определять модели жизненного цикла с употреблением привычной ему терминологии. Например, если инженеру процессов понадобится различить определенные уровни разделения для представления особого вида активности, он может определить и присвоить активностям экземпляры видов активностей. Распространенными примерами видов элементов разделения являются «стадия» и «итерация». Они могут определяться в структуре разделения как активности, которым присвоены соответствующие виды. Другой пример можно найти в «методе восхождения к вершине», поддерживаемом методом «Рациональный унифицированный жизненный цикл» (RUP) компании «IBM». Первый уровень структуры разделения «Восхождения...» называется не активностью, но «модулем». Класс «Вид» позволяет определять подобные интерпретации уровня разделения.
|
The Extension Activity Use Kind provides mechanisms for dynamically linking Activities for reuse to other Activities or Processes as shown in the following example depicted in Figure 9.6. [9.2]
|
Вид расширений применения активности (Extension Activity Use Kind) обеспечивает механизмы динамического связывания активностей для переиспользования в других активностях или процессах.
|
Artifact Definition is a Work Product Definition that provides a description and definition for tangible work product types. Artifacts may be composed of other artifacts. For example, a model artifact can be composed of model elements, which are also artifacts.
Artifacts are tangible work products consumed, produced, or modified by Tasks. They may serve as a basis for defining reusable assets. Roles use Artifacts to perform Tasks and produce Artifacts in the course of performing Tasks. Artifacts are the responsibility of a single Role, making responsibility easy to identify and understand, and promoting the idea that every piece of information produced in the method requires the appropriate set of skills. Even though one role might “own” a specific type of Artifact, other roles can still use the Artifacts, and perhaps even update them if the Role has been given permission to do so. [18.4.1]
|
Определение артефакта (Artifact Definition) является определением продукта, описывающим и определяющим осязаемые продукты. Артефакт может состоять из других артефактов. Например, модель как артефакт может состоять из элементов модели, также являющихся артефактами. Артефакт представляет собой осязаемый продукт, потребляемый, создаваемый или изменяемый посредством дел. Артефакты могут служить основой определения переиспользуемых активов. Роли применяют артефакты для исполнения дел и создают артефакты, исполняя дела. Артефакты являются обязанностью определенной роли, что облегчает выявление и понимание обязанностей и проводя мысль о том, что каждый фрагмент сведений, создаваемых методом, требует определенного набора навыков. Даже если конкретным типом артефактов «владеет» одна роль, и другие роли могут применять данные артефакты и даже изменять их, если данная роль получила на то разрешение.
|
Breakdown Element is an abstract generalization for any type of Process Element that is part of a breakdown structure. It defines a set of properties available to all of its specializations. [13.2]
|
Элемент разделения (Breakdown Element) — абстрактное обобщение всех типов элементов процесса, являющихся частью структуры разделения. Он определяет набор свойств, доступных каждой его специализации.
|
A Category is a Describable Element used to categorize, i.e., group any number of Describable Elements of any subtype based on user-defined criteria. Because Categories are Describable Elements themselves, they can be used to recursively categorize other Category instances as well. Categories can also be nested using the subCategory association. [11.1]
|
Категория (Category) — описываемый элемент, применяемый для категоризации, т. е. группирования любого количества описываемых элементов любых подтипов, основанных на определяемых пользователем критериях. Поскольку сами категории суть описываемые элементы, они могут также применяться для рекурсивной категоризации экземпляров других категорий. Категории могут также вкладываться с применением ассоциации подкатегории.
|
Category Kinds are a flexible way of defining different groupings for Content Categories. [18.2]
|
Виды категорий (Category Kinds) — гибкий способ определения различных групп категорий содержания.
|
A Checklist is a specific type of guidance that identifies a series of items that need to be completed or verified. Checklists are often used in reviews such as walkthroughs or inspections. [18.3.1]
|
Контрольный перечень (Checklist) — особый тип руководств, перечисляющий последовательность пунктов, подлежащих выполнению или проверке. Контрольные перечни часто применяются при пересмотрах, таких как сквозном анализе или инспекции.
|
A Composite Role is a special Role Use that relates to more than one Role Definition. It represents an aggregation of Roles Definition references for an Activity with the main purpose of simplification, i.e., reducing the number of roles defined in method content for a process. [13.3]
|
Составная роль (Composite Role) — особое применение роли, связанное более чем с одним определением роли. Она представляет собой совокупность ссылок на определения ролей для некоторой активности, главным образом, для упрощения (например, сокращения количества ролей, определяемых в содержании метода некоторого процесса).
|
A Concept is a specific type of guidance that outlines key ideas associated with basic principles underlying the referenced item. Concepts normally address more general topics than Guidelines and span across several work product and/or tasks/activities. [18.3.2]
|
Концепция (Concept) — особый тип руководства, излагающего основные идеи, связанные с основополагающими принципами, заложенными в описываемую сущность. Концепции обычно тематически более широки, чем наставления, и распространяются на несколько продуктов и/или дел и активностей.
|
Content Description is a Class that is used to store the textual description for a Describable Element. It defines standard attributes applicable for all Describable Element subtypes. [11.2]
|
Описание содержания (Content Description) — класс, применяемый для сохранения текстовых описаний описываемого элемента. Оно определяет стандартные описатели, применимые ко всем подтипам описываемых элементов.
|
A Default Responsibility Assignment is a Method Content Element that represents a relationship between instances of Role Definition and Work Product Definition. An instance of the Default Responsibility Assignment links one or more Role Definition instances to exactly one Work Product Definition. [12.1]
|
Назначение обязанности по умолчанию (Default Responsibility Assignment) — элемент содержания метода, представляющий связь между экземплярами определения роли и определения продукта. Экземпляр назначения обязанности по умолчанию ставит в соответствие один или более экземпляр определения роли ровно одному определению продукта.
|
A Task Definition Parameter is a special Work Definition Parameter that uses Work Product Definitions as well as adds an Optionalilty attribute. [12.2]
|
Параметр определения дела (Task Definition Parameter) — особый параметр определения работы, включающий определение продукта и описатель «Факультативность».
|
A Default Task Definition Performer is a Work Definition Performer that represents a relationship between Task Definition instances and Role Definition instances. An instance of Default Task Definition Performer links one or more Role Definition instances to one Task Definition instance. [12.3]
|
Исполнитель определения дела по умолчанию (Default Task Definition Performer) — исполнитель описания работы, представляющий связь между экземплярами определений дел и экземплярами определений роли. Экземпляр исполнителя определения дела по умолчанию ставит в соответствие один или несколько экземпляров определения роли ровно одному экземпляру определения дела.
|
A Deliverable Definition is a Work Product Definition that provides a description and definition for packaging other Work Products, and may be delivered to an internal or external party. Therefore, a Deliverable aggregates other Work Products.
A Deliverable is used to pre-define typical or recommended content in the form of work products that would be packaged for delivery. The packaging of the Deliverable in a process or project could be a modification of this recommendation. Deliverables are used to represent an output from a process that has value, material or otherwise, to a client, customer, or other stakeholder. A Deliverable is a work product that aggregates other work products. Method content maintains preconfigured potential deliverables. [18.4.2]
|
Определение комплекта поставки (Deliverable Definition) — определение продукта, описывающее и определяющее определение комплектования других продуктов и могущее быть доставленным внутреннему или внешнему контрагенту. Таким образом, комплект поставки объединяет другие продукты.
Комплект поставки применяется для предварительного определения типичного или рекомендуемого комплекта в форме продуктов, комплектуемых для поставки. Комплектование комплекта поставки в процессе или проекте может изменять данную рекомендацию. Комплекты поставки применяются для представления результата процесса, обладающего ценностью (материальной или иной) для клиента, заказчика или другой заинтересованной стороны. Комплект поставки является продуктом, объединяющим другие продукты. Содержание метода включает предварительно сконфигурированные потенциальные комплекты поставки.
|
|
