abayda выложил свои соображения по русскоязычной терминологии Essence -- http://abayda.livejournal.com/66500.htmlТрудных мест в этом переводе хватает. Ниже некоторые мои соображения.
1. Essence я называю Основы -- значительное число материалов SEMAT направлено на то, что из программной инженерии должно проходиться в школе. В школе проходиться должны основы. Это и отражаем. Сам текст стандарта -- это основы, что в стандарт не попало -- это уже больше, чем основы.
2. В Основы входят language и kernel. Тут нужно обратить особое внимание на то, что сам стандарт реализован в MOF 2.0 (для понимания -- http://jtc1sc32.org/doc/N1751-1800/32N1764-WG2-Tutorial-OnMOF-forSC32.ppt, для спецификации -- http://www.omg.org/cgi-bin/doc?formal/2011-08-07.pdf). Именно из MOF идёт идея многоуровневого метамоделирование -- все эти types, constructs и т.д.. Именно оттуда идут ассоциации (associations) и владения (owns), именно оттуда кривой механизм реализации powertype при попытке рассказать об ISO 24744 (не понимаю, почему они просто не использовали powertype -- ведь MOF 2.0 позволяет это сделать! Может, "хотели простоты, а получилось как всегда").
Язык (language, уровень мета-модели) определяет конструкты (альфы как таковые, деятельности как таковые и т.д.), в терминах которых можно разговаривать об инженерном проекте создания успешной системы.
Набор сущностей (kernel) описываемый уже на этом языке -- это другое, это уже самые существенные (сутевые) вещи (aka сущности) в программной инженерии. Эти сущности (основные -- то есть из Основ -- альфы и деятельности) крайне важны, именно они попадают на самый высокий уровень обобщения, они поминаются в определениях дисциплин/предметных областей/engineering domains.
Возьмём картинку сущностных (т.е. входящих в kernel) альф стандарта (страница 28 версии от 12 ноября 2012):
А теперь сравним со свежайшим определением системной инженерии из SEBoK (http://www.sebokwiki.org/1.0.1/index.php?title=Systems_Engineering_%28glossary%29):
Systems Engineering (SE) is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on holistically and concurrently understanding stakeholder needs; exploring opportunities; documenting requirements; and synthesizing, verifying, validating, and evolving solutions while considering the complete problem, from system concept exploration through system disposal.Близко к тексту, да? Так что я эти существенные, попадающие в определения абстрактные понятия предметной области предпочитаю так и называть -- сущностями, а не "ядром". Хотя я понимаю, что у kernel (ядра) прямые коннотации с софтверными "ядрами", которые в микроядерных ОС, например. Судя по некоторым презентациям, там приводятся и картинки ядрышек орехов, которые малы по сравнению с ореховым деревом -- и под этими картинками призывы держать ядра маленькими. Якобсон провёл довольно много времени, убеждая людей, что число сущностей небольшое. На то она и суть, что не включает огромного числа подробностей и примеров.
3. Activity spaces -- это деятельности, множества дел. Activity -- это дела, которые входят в эти множества. Конкретно про Activity Space отношение с Activity -- это Activity Association ("part of" kind). То есть "деятельность состоит из дел". Мне кажется, что в выходе на мереологию поведений -- то есть представление ядра, практик, методов как "истинных разбиений" (breakdown structure, основанных на отношениях "часть-целое") кроется некоторая засада. По крайней мере, когда мы в Бекасово пытались понять, как устроены эти "истинные разбиения" в реальных инженерных проектах с WBS, PBS и т.д., то каждый раз оказывалось, что меняется основание разбиения, и каждый уровень разбиения содержит свой тип отношений, отнюдь не всегда являющийся "разбиением".
Не меньшая засада может быть и при трактовке Activity spaces как классов (множеств), а дел -- экземпляров этих классов, или попытка использовать тут какие-то другие отношения "мета" (пять вариантов отношения "мета" даны на слайде 8 "diversity of meta concepts" в MOF 2.0, http://jtc1sc32.org/doc/N1751-1800/32N1764-WG2-Tutorial-OnMOF-forSC32.ppt -- я, наконец, нашёл, где я видел эти анализы многочисленных "мета", хоть тут и не все шесть искомых, см. http://ailev.livejournal.com/821154.html). В этих "мета" сам чёрт ногу сломит, и авторы стандарта явно хотели уйти от таксономий или уровней экземпляризации, или от уровней паттернирования куда-нибудь в более интеллектуально безопасное место, и ничего лучше не придумали, как "инженерные разбиения" (не очень связный рассказ об этом тут: http://incose-ru.livejournal.com/24388.html, а ещё эти разбиения непосредственно связаны с инженерной идентификацией -- "кодировками").
В любом случае, проверяем приговариванием к каждому слову его типа и явного поминания глагола отношения (берём пример из 9.7.6.4., страница 135): деятельность "специфицируй программу" состоит из дел "идентифицируй сценарии" и "специфицируй сценарии"). Деятельность составлена из дел, дела составляют деятельность. Конечно, можно и так, но повторюсь: тут мне видится некоторая засада, особенно при понимании, что деятельность и дела -- это не один тип, а два, и оба типа могут "дробиться на части". Скорее всего, авторы Основ хотели выразить то, что деятельность (целое) сущностна и более-менее постоянна, а дела (части) -- практичны и варьируются. Деятельности в kernel, дела в practices -- это и хотели подчеркнуть.
4. Называть Work множественным или единственным числом -- работа программистского проекта или работы программистского проекта? По-русски, конечно, работы. Но по большому счёту, мне тут всё равно. Единственное число тут ничему не мешает и мало кого запутает.
Мне очень бы хотелось понять, чем такая альфа-сущность, как Work отличаются от не-альфа-сущности Activity spaces (и до кучи -- от несущностных частей деятельности -- чем работы отличаются от дел). Пример с работой "спринт" мне непонятен, увы -- почему это Sprint оказался в работах, а не в деятельностях? Мне кажется, что это просто две разных группы описаний одного и того же:
-- службы развития и менеджеров (работа ладится/не ладится) -- неважно, какие это именно работы по содержанию! Альфы ведь для оценок!
-- инженеров, где деятельность состоит из дел, каждое из которых что-то изменяет в состояниях альф.
Понятно, что это "две группы описаний одного и того же" конкурирует с другим толкованием: "средство выражения рефлексивности" (т.е. выполнение работ над работами, которое будет выражаться как "дела продвигают работы".
Но это полбеды, ибо есть ещё и way of work.
5. Way of work -- я, пожалуй, соглашусь с
abayda, что это "технология" (при этом даже отбросив "технология работы"). Я обычно говорю, что дисциплина -- это знания, которые загружаются в голову, а технология -- это инструменты и люди, которые "развернуты на местности" и доступны для работы. Тут чуть-чуть получше, чем с Work и Activity Space/Activity, ибо прямо сказано, что метод (сиречь коллекция практик) описывает way of work, то есть это более-менее постоянная "сущность" для ситуативного метода! Но и тут рефлексивность в полный рост: "дела продвигают (обновляют и изменяют) технологии".
Очень не хватает средств для описания инструментов. Наверное, нужно делать "инструментальное расширение", пополнив состав альфы технологии суб-альфой инструмента.
Тут нужно учесть, что при распространении на инженерию будет туго: технологии там понимаются в разных дисциплинах по-разному (технологии сооружения -- это в каком порядке возводить здание, технологии непрерывного производства -- какие жидкости под каким давлением куда текут, и т.д.).
Обращу внимание, что зарубежные товарищи привели очень мало примеров моделирования как с work, так и way of work, так что можно только гадать, что там за оттенки смыслов у них в головах по этому поводу.
6. Ну очень хочется перевести work product как артефакт! Это убирает клэш с "продуктами" сервисными (как в Архимейте), убирает слово "продукт", даёт одно короткое слово вместо двух и сулит прочие радости (например, позволяет не использовать "но" в фразе "работы сущностны, но их продукты практичны"). Весь мой опыт говорит, что слово "объект работы" (как в архимейте), "продукт работы" приживается более тяжело, чем короткое слово "артефакт". Хотя я понимаю, что против артефакта специальная оговорка есть в ISO 24744, и разработчики Основ наверняка её учли.
7. Главная проблема, конечно, это стыковка терминологии Основ с многочисленными стандартами, описывающими практики разных предметных областей -- в том числе ISO 12207, описывающий практики жизненного цикла программной инженерии. Сюда же отнесём и ISO 15288, а также многие другие, в которых используется мета-модель ISO 24774 для описания практик жизненных циклов (не путать с ISO 24744, помянутым в Основах!). Там практики (process) состояли из мероприятий (activities), которые были разбиты на дела (tasks). В Основах 24774-практики -- это практики (activities, ибо в описаниях 24744-processes поминаются и объекты работы, а не только описывается поведение/деятельность, т.е. это не activity spaces), 24774-дела -- это дела, а вот 24744-мероприятия -- это, похоже, тоже дела, только помельче. Но это очень грубая прикидка. Я помню, что там в каждом стандарте, использующем эту мета-модель (т.е. в ISO 12207, ISO 15288 и прочие стандарты, для которых ещё и SPICE методология определения compliance прописана), "поведения" в их разных модальностях и группах описаний произвольным образом путались.
Я не уверен, что для тренировки нужно пробовать моделировать ISO 15288, или ISO 12207 -- всё-таки Основы закладывались на в разы более Agile подходы, плюс стремительно надвигаются model-based и model-driven изводы разных инженерий, слабо учитываемые в этих документ-ориентированных стандартах. Моделировать 800 страниц SEBoK тоже было бы странным.
Но вот попробовать помоделировать "методологии MBSE" было бы интересно -- см. некоторое их количество тут: http://www.omgwiki.org/MBSE/doku.php?id=mbse:methodology. Первого взгляда на эти "методологии" (а ведь именно для их моделирования предназначены Основы!) хватает, чтобы понять: моделирование будет очень трудным! Основы ведь сознательно предлагают более трудное моделирование, чтобы потом было более лёгкое использование.
8. Мелкие коррекции и предложения по тексту http://abayda.livejournal.com/66500.html:
-- 4.1, customer -- это клиент. Ибо кроме ситуации заказа бывают ещё и ситуации обслуживания (клиент -- это из сервисной парадигмы, это правильно).
-- 5.2, "заинтересованные стороны" корректно, но в разные диаграммы не влезает, и два слова хуже одного. Так что я регулярно говорю и просто "стейкхолдеры". Жаргон, конечно, но это нормально -- это удобно, так же, как и слово "артефакт" вместо "рабочего продукта". Ни разу не заказчики, ибо в стейкхолдерах ходят и бенефициары (не заказчики!), и регуляторы/надзоры (не заказчики), и операторы (не заказчики), и т.д..
-- 6.1, страница Основ 28 с картинкой (она приведена выше) плюс эталонный набор associations в моделере: stakeholders provides opportunity (а не identify). Так что (это и по смыслу верно) "заинтересованные стороны обеспечивают возможность".
-- 6.2, Opportunity focuses requirements -- я согласен, слово "фокусирует" неправильно. Keep focus -- это ведь "не разбрасывайся", "держи цель". Тут именно это имеется ввиду, а не "уточнение". Ещё один традиционный перевод для focus -- это центрироваться, собираться в кучку, сосредотачиваться. Я бы выразил содержательно смысл так: "требования сосредотачиваются на возможности" ("требования центрируются на возможностях, возможности не дают требованиям расплываться" -- имеется-то ввиду именно это).
-- 6.8, Scope, конечно, не объём -- это у меня ошибка. Традиционно scope -- это предмет (например, agreement scope -- это "предмет договора"). Так что requirements scope and constrain the Work -- требования определяют предмет работы и ограничивают её.
-- 6.9, Team applies way of working -- команда применяет технологию (вариант -- задействует технологию). Например, "аналитик применяет/задействует тест-ориентированное программирование" (помним, что практики и методы как раз и описывают/характеризуют технологии -- это тут и имеется ввиду).
-- 6.14. В русском языке "адресовать" вполне допустимо. Это же слово и в ISO 42010 (там адресуются интересы). Стандартный перевод -- принимать меры (по поводу, в ответ на), реагировать на; направлять усилия на. The World Bank must address the needs of the poorest countries. — Всемирный банк должен повернуться лицом к нуждам беднейших стран. Addressing the resentment toward affirmative action programs, Hacker notes… — Реагируя на возмущение по поводу программ предоставления преимущественных прав, Хакер отметил... to address oneself to (the business of doing) smth. — приниматься за какое-л. дело I addressed myself to learning Spanish. — Я принялся за изучение испанского.. То есть переводить нужно по смыслу, а не словарно, словарь не помогает. Как вариант: "работы организуются для реагирования на возможность", но я бы говорил проще: "работы организуются для адресования возможности". Set up для работ -- это их организация, это ведь не оборудование, которое "устанавливают".
-- 7. Activity space всё-таки деятельности, да ещё и доминирующие на каких-то стадиях жизненного цикла (т.е. задающие cognitive framework согласно ISO 24744, а в терминах Основ требующие каких-то компетенций). Деятельности же состоят из дел, которые включают действия (actions), меняющие рабочие продукты. Единственное осложнение тут, так это "деятельность" в русском обычно выражается не глаголом, а отглагольным существительным. Но это уже нюансы. "Деятельность по поддержке команды", "деятельность по использованию системы" -- вполне себе ОК.
-- 7.2 что "нужды", что "потребности" -- всё одно дискуссии про то, что является хотелкой, что "истинной потребностью, то есть нуждой", что "истинной потребностью, то есть мечтой" и т.д. не избежать. Всё равно.
-- 7.6, shape the system -- да, я погорячился (действительно, в голове уже было MBSE). Там ведь this includes the overall design and architecting of the system to be produced. Так что предлагаю, как в ISO 15288 использовать architectural design -- "архитектурное спроектировать систему".
-- 7.8, test обычно "испытания" у инженеров. Большие софтверные системы тоже проходят приёмо-сдаточные испытания, а "тесты" обычно относятся к отдельным компонентам системы. Учитывая, что стандарт заточен прежде всего для использования в agile маленьких бригадах, я готов оставить "тестировать систему". "Протестировать" -- это IMHO в данном контексте жаргонизм, но жаргонизм не страшный, для меня это тоже "косметика".
-- 7.12, деятельность -- это сущность, а дела -- практичны. Нельзя координировать сущности :-) Хотя я понимаю, что в данном контексте "девочка, бывает и просто банан" -- слово activity там явно нетерминологическое (там ведь единственное число!), и его нужно перевести также внетерминологично. Что там координировать в одной activity? Там ещё и описка может быть: имелось ввиду coordinate the work (судя и по фразе определения этой деятельности как Co-ordinate and direct the team’s work, так и по названиям соседних пунктов). Думаю, есть ещё время внести исправление в текст, дать им bug report от SEMAT kernel track :-)
-- 7.13, Stop the work, обычно это заключительные работы (архивирования, разбор полётов, передача системы на сопроваживание и т.д. -- Shut-down the software engineering endeavor and handover the team’s responsibilities). Так что это "завершить работу", а не просто "прекратить" или "остановить".
Надо пока это переварить, но перед фиксацией терминологии обязательно помоделировать всякое разное (ну, и попереводить основной текст стандарта -- с учётом того, что там полстандарта это цитаты из MOF, а его переводить как-то бессмысленно! Так что я бы делал весьма выборочный перевод). Тогда сразу и выяснится, что в русской терминологии плохо, и где используемые слова жмут.