Обсуждение

Я, вроде, ясно написал, почему такой перевод мне крайне не нравится? Это и есть айтишный канцелярит: использование слов, связь с жизнью которых понятна только айтишникам (типа слова "модель" вместо "описание"). А кое где так и вовсе неверных (типа использование слова "процесс" не для показа развертки по времени: текст там дальше прямо запрещает развертку по времени). Слово reference так вообще исчезло, что недопустимо: process model и reference process model -- разные понятия (reference обозначает роль для process model). Но для айтишников привычно, это да. После чего практики идут в жизни своим чередом, а эти "процессы из стандарта" так и остаются на бумаге.

Я совершенно не возражаю, что программисты любят говорить слова "модель" и "процесс", как по-русски, так и по-английски. И их специфический жаргон они могут выдавать за "общепринятый". Нет, говорю, не общепринятый жаргон у программистов. Другие люди говорят по-другому. Люди, например, практикуют йогу, а не занимаются процессом йоги. И у них есть описания этой практики, а не модели практики. По сути же речь идет о том же, о чем пытаются сказать авторы всех этих стандартов про управление конфигурацией или архитектурное проектирование. Непонятно, почему мы должны употреблять программистские слова, ежели речь не идет об управлении конфигурацией софта и архитектурном проектировании софта. Любители йоги, думаю, сильно удивились, ежели "описания поз" превратились бы в "модели поз" (хотя для этих поз есть все первичные признаки "моделей" и "практик" -- название, назначение, результаты, разбиение и другие описатели, появляющиеся в момент создания экземпляра этой практики в ходе (т.е. процессе, только тут появляется развертка во времени) конкретных занятий.

Процесс, кстати, не физическая система. Насчет "точки зрения", так это указание на какой-то "метод описания", по определению адресующий какие-то интересы. Графическая форма не исключает использование языка (буквы, кстати, тоже графичны).

Вот именно это мне и не нравится в программистах: им даже в йоге непременно мерещится робот.

По-моему мнению, все-таки следует остановиться на использовании термина модель для английского model, а не описание. Одной из отличий модели и опмсания состоит в том, что понятие, стоящее за первым термином несет смысл имитации своего прообраза, т.е. попытку ввести некоторый пусть и потенциальный элемент динамики, схватить суть предмета. Простое же описание принципиально не ставит этой задачи, фиксируя некоторый набор фактов, без попытки выявить стержень, сущность того, что описывается.

Слово "модель" в этой серии стандартов очень многозначно: а) оно чаще всего означает любое "элементарное описание" (у меня есть проект "улучшенного" ISO 42010, там это очень явно говорится) б) означает тип (так, значительная часть lifecycle model означает просто "тип жизненного цикла", и ничуть не смущает, что там есть и life cycle form, означающая практически то же самое). в) означает таки да, (компьютерную) модель, основанную на каком-то методе описания. Я предлагаю в случае непонимания писать "описание", а когда точно известно, что речь идет о модели, то использовать слово "модель". Так, я планирую сделать модель ISO 15288 в стандарте SPEM (а не просто "описание"). Это значит, что будет именно компьютерная ("исполнимая" в каком-то смысле, в каком-то формализме приготовленная) модель. Далее с использованием этой модели я буду готовить модели жизненного цикла по потребности. Стандарт, мне кажется, мягко требует описания жизненного цикла, призывает к некоторой рефлексии: пиши, что делаешь и делай, что пишешь. Более жесткое требование -- именно требование моделирования (определение формализма, создание записей на языке этого формализма).

Приведенные аргументы корректны. Предложение использовать оба термина в зависимости от ситуации, по-видимому, неплохое решение. Ну и, конечно же, замечание по-этому поводу должно быть добавлено к секции комментариев данного стандарта. Как читатель, понимаю, что это снимет часть вопросов не только к авторам первода, но и к самому тексту.