Обсуждение

Большое спасибо за подробный разбор моего постинга. Подбробно отвечу позже. Короткие комментарии: 1. У SEMAT Russian Chapter есть околомаркетинговая задача перевести статью из декабрьского CACM. Этим я сейчас и занят, вместо перевода стандарта. Хотелось бы сделать перевод терминологии основ в этой статье "установочным" для последующих переводом материалов SEMAT. С другой стороны, видимо полезным будет сделать версионируемый словарь, публикуемый на сайте отделения, дабы у всех была возможность свериться с изменениями в переводе, каковые наверняка будут. 2. Я понимаю и разделяю ваши устремления сразу переводить в расчете на инженерию в широком смысле. Но на данные момент это все же основы для программной инженерии. И мне видится разумным вариант перевода именно основ программной инженерии (со всеми этими ядрами и тестированиями вместо сущностей и испытаний), а уже отдельно расширение этих основ на прочую инженерию (по аналогии с 12207/15288).

Да, я обратил внимание на "маркетинговый акцент" русского отделения SEMAT, они просто повторяют то, что делает IJI. Я же пока в сэкономленное от маркетинга время постараюсь продвинуться по содержанию: попереводить, помоделировать. :-) Про тестирования (это из сущностей, kenel специфичен для domain) я бы согласился, а вот про "сущности" (это из языка, language общий для всех domains) -- готов поспорить, понятней ли это слово будет для программистов по сравнению с тем, как я об этом рассказываю. Так что вполне можно разделить перевод на две части: язык и сущности программной инженерии. А потом думать, какое ядро будет главнее (так, ISO 15288 утверждает, что это более общий стандарт, чем ISO 12207, и это 12207 к нему подтягивается).

Маркетинговый импульс отделениям придает в т.ч. и Ивар. Он видит успехом SEMAT'а массовость применения, особенно маленькими командами. Мой личный интерес в первую очередь состоит в том, чтобы терминологию сделать максимально корректной. Уж очень обидно будет, если при наличии русскоговорящего разработчика Основ перевод будет посредственным. К счастью, статья тоже заставляет переводить текст стандарта. Хотя могу представить, что отставать начну от вас, т.к. для меня SEMAT является факультативной деятельностью, а после завтра начнутся рабочие будни.

У меня tutorial по системной инженерии будет 14-16 января, я хотел бы уже по-русски говорить про Основы и использовать их по полной. Так что я эту недельку планирую некоторое количество времени переводу уделить, а также попыткам моделирования. Ежели чего, я буду выкладывать результаты у себя в ЖЖ (хотя, как всегда, бОльшая часть результатов достанется клиенту).

Ну я не собираюсь совсем уж игнорировать SEMAT-деятельность. Постараюсь поддерживать разговор. Надеюсь и SEMAT RC что-нибудь перепадет. ;) Кстати, завтра у нас в "головном" SEMAT конференц-колл по поводу User Guide'а. Тоже тема довольно масштабная. Там тоже хочется поспеть.

Кстати, можете головному SEMAT передать, что вас назначили представителем в SEMAT на последнем заседании INCOSE Russian Chapter (это, кстати, даже на видео должно было записаться), и что вы договорились выступить о SEMAT на заседании. Им должно это понравиться, с их интересом к маркетингу ;-)

Еще короткий комментарий. Цитата из CACM'овской статьи: "As practices are added to the kernel.... ". И как переводить, если kernel — сущности? По мере добавления практик к сущностям? По-моему, это смысла не добавляет, а наоборот.

Мне показалось, что это прозвучало скорее в виде предложения, нежели в виде утверждения. Если я ошибаюсь, то с удовольствием извещу головной SEMAT. Роль только вылетела из головы. Решили, вроде, что это не ambassador должно называться, а как-то иначе.

Такая роль в организациях по стандартизации называется liaison или representative. Ambassador -- это другое

А практики никаким образом не могут быть добавлены к сущностям! Это неверно и с переводом "ядро". Другое дело, что практики (в жизни) могут добавить сущности, если их ещё нет. Поскольку была здравая мысль использовать почти бытовые слова (практики, работы и т.д.) в терминологических значениях, нетерминологические употребления (типа "практика -- критерий истины") будут в изобилии.

Насколько я понимаю, здесь имеется в виду определение практики (practice definition), а не их run-time реализация. По-моему, определение практики вполне себе сущность. И может быть добавлена к ядру.

OK. Liaison officer я уже был. Теперь буду лиазоном в другой области.

А что такое practice definition? Что-то я такого термина не упомню. Сущностей очень ограниченное число: в инварианте kernel указано, что "A kernel can only contain alphas, alpha associations, alpha containments, activity spaces, competencies, kernels, extension elements, and merge resolutions". Extension elements имеет поведение, определяемое очень мутным пунктом 9.4 -- но, насколько я понимаю, он позволяет расширять и объединять только сущности (то есть прихватывать их из состава других сущностных наборов). Ибо в практиках есть несущностные "артефакты" и связанные с ними через "действия" "дела", они больше относятся к технологии, чем к сутевым вопросам проекта, не зависящим от используемой технологии. Там всё чётко :-) Ваше же предположение, что практики куда-то добавляются, верно: они добавляются друг ко другу (как и сущности), в них могут добавляться сущности, а еще они смешиваются в методах. То есть сущностное масло в практическую воду можно для вкуса добавлять, а вот водичкой масло уже нельзя разбавлять.

Для начала предположение о добавлении практик не мое, а авторов статьи (а именно Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence, and Svante Lidman, уж не знаю, кто из них автор этого пассажа). Сам пассаж таков: "As practices are added to the kernel, alphas will be added to represent the things that either drive the progress of the kernel alphas or inhibit their progress." Целиком статья доступна как по адресу http://queue.acm.org/detail.cfm?id=2389616 , так и в pdf-версии CACM, которая вам должна быть доступна, как члену ACM. Я пользуюсь последней, пассаж располагается в начале среднего столбца стр. 45 CACM. Речь о добавлении практик ведется в разделе статьи, объясняющем расширяемость ядра. Т.е. добавляя практику, добавляем альфу в ядро (к сущностям в вашей терминологии), чтобы понимать, как она влияет на основные 7 альф. Теперь вопрос куда именно добавляем практику. И что значит сама процедура добавления. Practice definition это описание практики. Соответствует, как я понимаю, уровню M1 на слайде 5 из презентации про MOF в вашем постинге. Это я так пытаюсь различать M1(соответствует уровню 1 из п 9.1.1 заявки на стандарт) и M0 (соответствует уровню 0 из п 9.1.1 заявки на стандарт). Run-time ее реализация уйдет на M0. Добавляя практику команда добавляет куда-то (куда?) ее описание (M1), а также начинает ее выполнять (M0). Теперь к вопросу о том, куда можно добавить практику. Определение ядра (на стр. 20 последней на данный момент заявки на стандарт) таково: набор элементов, используемых для формирования общего основания для описания программно-инженерного предпринятия (A kernel is a set of elements used to form a common ground for describing a software engineering endeavor). Также есть утверждение, что ядро расширяемо (например, на стр. 24, ibid). Определение way of working: The tailored set of practices and tools used by a team to guide and support their work. (стр. 60, ibid). Т.е. добавляя практику, мы добавляем ее (practice definition/M1/Level 0) в way of working, характеризуемый, как я понимаю, при помощи документа work product (стр. 85, ibid). Если это так, то фраза "practices are added to the kernel" не является детализированной с точки зрения того, что происходит в деталях, но корректной с точки зрения ядра.

Я думаю, что всё это шутки языка. Практику добавляют к сущностям (т.е. рядом с сущностями), а не в сущности (то есть в состав сущностей). Слайдов, на которых показано, как альфы и деятельности (рамочкой показаны сущности) конкретизируются рабочими продуктами и делами практик (рамочкой показаны практики) -- достаточно. Думаю, смысл этого предложения именно таков: описать Метод разработки можно, добавляя к Сущностям те уточнения, которые присутствуют в различных Практиках. Насчёт way of working -- так я придерживаюсь определения A method contains a set of practices to express the practitioners’ way of working in order to fulfill a specific purpose. Метод не прямо связывается с way of working, однако -- не так прямо, как альфа и рабочий продукт. Ибо метод это не рабочий продукт, а смесь практик. Нет возможности показать ассоциацию, связывающей метод (или практику метода) и альфу way of working (понятно почему: они на разных уровнях обсуждения -- way of working обсуждается людьми из развития и менеджерами, а метод -- инженерами). Вся эта путаница, как я отметил в тексте, из-за того, что есть два ортогональных разделения: сущности и практики с одной стороны (при этом сущности участвуют в практиках, а метод "базируется" на сущностях какой-то предметной области), и way of working и work с activity spaces и activities в части их рефлексивности ("работы над работами, метод по поводу метода"). Нужно думать о каких-то картинках и примерах, чтобы показать эти отвязанности. Как всегда, когда вмешиваются разные "меты" и "рефлексивности", простота исчезает, остаётся лишь "математическая компактности и элегантность". То есть товарисчи создали что-то типа Хаскеля, очень мощное средство, но люди из всего этого богаства выражения будут пользовать ядро и десяток agile практик, которые закодирует IJI для малых команд. Ничего, мы и через это прорвёмся. Я думаю, что с этим стандартом будет, как с ISO 15926 -- когда мы этим займёмся (а мы, кажется, уже занялись) русскоязычная тусовка и степень её погруженности в предмет может неожиданно больше оказаться, чем это представляют себе зарубежные отцы основатели :-) Проблема пока в том, что очень мало людей в мире реально разбираются с MOF и тамошними мета-аспектами. В эту точку и нужно бить, как мне кажется. Ибо уже написанную беллетристику с карточками сейчас все будут использовать, но это только начало истории. Модельеров практик будет не слишком много, а именно это интересно. Реальных же модельеров можно будет узнать по тому, как они будут использовать patterns и practice assets.

Ну я так и перевожу, "к сущностям". По остальным пунктам я тоже согласен. Особенно про MOF. Я считаю, что самое кривое место в текущем вариате Основ — стык ядра и языка. Как говорит главный идеолог ядра Иэн Спенс, ядро — это язык ("language that I speak"), на котором я говорю, а то, что вы (прочие члены SEMAT) называете языком, является на самом деле системой записи (writing system). И вот эта система записи на данный момент неидеально стыкуется с тем, что она должна быть способна передавать (т.е. всеми особенностями ядра). Я считаю, что это в большой степени обусловлено ограничениями MOF. Согласен, что с ним надо хорошо разобраться. М.б. даже правильно переложить систему записи на другую основу. Кажется достигли консенсуса.

Кстати, насчёт "системы записи": там четыре уровня идеально с ISO 15926 сочетаются :-) Но чтобы отмэппировать в ISO 15926, нужно глубоко понимать, что именно мэппировать. Когда-нибудь мы именно это и сделаем. К этому нужно готовиться специально.

Честно говоря, я именно такой шаг и видел в качестве одного из будущих, когда начал заниматься SEMAT'ом.

7.12. Как по-вашему было бы правильно назвать это пространство дел на английском? Coordinate work?

Конечно! Обращу особое внимание, что в других деятельностях (я их не называю "пространством дел" -- деятельности это как раз повторяющиеся в разных условиях и ситуациях какие-то дела. Так что я "пространственную метафору" лишний раз не хочу дёргать -- а там поглядим, что получится) используются названия Сущностей (т.е. "work" -- например, "Prepare to do the work", "Stop the work" и т.д..). Там ещё интересно, что acivity spaces, activities и actions чисто лексически получаются операциями с альфами и продуктами работы, но въявную это отношение показано только для actions (которые с activity связаны association непонятно какого типа -- даже не часть-целое. Я как-то не нашёл, как это выражается в графическом языке, там на activity всё останавливается, а сама action выглядит отношением, что ли? Мрак с этим MOF и намерениями проектировщиков Essence). Итого: конечно, в стандарте меняем activity на альфу, т.е. work, сохраняем "деятельность-или-дело над альфой-или-продуктом" шаблон. Если, конечно, можно ещё успеть :-)