?

Log in

No account? Create an account

Entries by category: it

Essence по-русски
abayda
Ознакомился с начавшей складываться практикой перевода ключевой терминологии на русский. Как ни удивительно, таковая уже есть. А именно: постинги ailev'а (см. http://ailev.livejournal.com/1051048.html и http://ailev.livejournal.com/1052859.html) и перевод "Semat — three year vision" в журнале Программирование в прошлом году.

Тут изложу мой текущий рабочий вариант с объяснением расхождений с прочими вариантами.
1. Essence. На данный момент я склоняюсь к тому, чтобы не переводить, а использовать, как есть. Мы же не переводим, а транслитерируем названия языков программирования. Если же переводить, то, видимо, лучше использовать "основы" (вариант ailev'а), а "сущность" (не предыдущий рабочий вариант перевода).
2. Alpha. Предлагаемый перевод - альфа. Да, это акроним в англоязычной версии. Но я не вижу возможности перевести на русский расшифровку и получить столь же внятный акроним. Расшифровка акронима пусть будет доступна только в словаре, который, очевидно, тоже необходимо создать и опубликовать (например, на пока еще не действующем сайте SEMAT Russian Chapter.
3. Alpha state — состояние альфы.
4. Area of concern — область интересов (большое спасибо ailev'у.
4.1. Client area of concern — область интересов клиента. В наличие лобби в пользу "область интересов заказчика", что, на мой взгляд, не полностью отражает суть.
4.2. Solution area of concern — область интересов решения.
4.3. Endeavor area of concern. Здесь интересно. "Официальный" рабочий вариант — область интересов усилий [предпринимаемых для создания программной системы]. Честно говоря, я настолько уже намучался с адекватным переводом "endeavor", которое хочется переводить одним словом, а не несколько разными по контексту, что всячески поддерживаю популяризацию предложенного ailev'ом термина "предпринятие". Но словотворчество у всех в чести. В связи с чем предвижу проблемы с точки зрения принятия этого термина за пределами русскоязычного сообщества системных инженеров. В общем, пока фиксирую рабочий вариант "область интересов предпринятия".
5. Альфы.
5.1. Opportunity — возможность. В "Программировании" использовался вариант "бизнес-возможность". На мой взгляд спецификатор "бизнес-" излишен (как говорил наш quality assurance manager по поводу термина business requirement: "А у нас что есть какие-то небизнес-требования?"). Альфа области интересов клиента.
5.2. Stakeholders — заинтересованные стороны (с удовольствием принимаю вариант ailev'а, предыдущий рабочий вариант — заинтересованные лица ). Наличествует лобби, желающее протащить на уровень абстракции непременно "заказчиков", с чем я никак не могу согласиться. Альфа области интересов клиента.
5.3. Requirements — требования.Альфа области интересов решения.
5.4. Software system — программная система. Альфа области интересов решения.
5.5. Work — работа. Альфа области интересов предпринятия. ailev предлагает переводить как "работы". Множественное число отсутствует в оригинале. Я (пока?) не вижу смысла в подобной модификации при переводе.
5.6. Team — команда. Альфа области интересов предпринятия.
5.7. Way of working — технология работы. Раньше рабочим вариантом было "способ работы", предлагаемый также ailev'ом. Он был отвергнут в пользу "технология работы" в связи с тем, что фразы с использованием перевода "способ работы" режут ухо.
6. Отношения между альфами.
6.1. Stakeholders identify opportunity — заинтересованные стороны определяют возможности (вариант ailev'а "обеспечивают" мне не нравится, т.к. возможности не только обеспечиваются, но еще и выявляются заинтересованными сторонами).
6.2. Opportunity focuses requirements — возможность уточняет требования (вариант ailev'а "фокусируют" мне представляется слишком "калькированным").
6.3. Заинтересованные стороны формируют требования (вариант ailev'а "требуют" меня не вполне устраивает, т.к. не все заинтересованные стороны находятся в положении, когда могут требовать, все-таки demand — это не только требование, но и спрос).
6.4. Stakeholders use and consume software system — заинтересованные стороны используют программную систему.
6.5. Software system fulfills requirements — программная система удовлетворяет требованиям.
6.6. Team produces software system — команда производит программную систему.
6.7. Team performs and plans work (непонятно, почему сначала выполняет, а потом планирует; антисистемная инженерия какая-то, не понимаю, как мы это прозевали (ладно статья в CACM, так, ведь, и в стандарт просочилось) &mdash команда планирует и выполняет работу (я склонен заменить здесь предыдущее рабочее "осуществляет" на "выполняет".
6.8. Requirements scope and constrain work — требования определяют рамки и ограничивают работу (в варианте ailev требования "задают объем", но я не вижу, чем оно лучше того, что у нас уже было).
6.9. Team applies way of working — команда применяет технологию работы. Я не вполне доволен тем, как звучит. Но лучшего пока нет.
6.10. Way of working guides work — технология работ направляет работу.
6.11. Team produces software system — команда производит программную систему.
6.12. Work updates and changes software system — работа изменяет программную систему (дословный вариант предлагается ailev'ом (обновляет и изменяет), м.б. стоит придерживаться именно дословного варианта).
6.13. Stakeholders support team — заинтересованные стороны поддерживают команду.
6.14. Work [is] set up to address opportunity — здесь снова трудно. Текущий рабочий вариант: работа устанавливает порядок реализации возможности. Мне не нравится, то лучшего я не вижу. Калька от ailev (работы проводятся для адресования возможности) меня тоже не устраивает. Надо думать над лучшим вариантом. Вариант "работы проводятся для реализации возможности" меня не устраивает тем, что работы на данном абстрактном уровне не столько проводятеся (это уже run-time), сколько идет договорка о том, как и какие работы будут выполняться.
7. Activity space — пространство дел. Мне нравится вариант ailev'а. Во время обсуждения про activity space часто говорилось как о place holder'е, который должен заполняться какими-либо практиками, которые помогают двигать альфы вперед (вниз ;) по их конечным автоматам.
7.1. Explore possibilities — исследовать возможности. Пространство дел области интересов клиента.
7.2. Understand stakeholder needs — понять потребности заинтересованных сторон (ailev предлагает "нужды" вместо "потребности", я преимуществ не вижу; нужды более близки по дословному переводу, но "потребности заинтересованных сторон" на мое ухо ложаться лучше). Пространство дел области интересов клиента.
7.3. Ensure stakeholder satisfaction — обеспечить удовлетворение заинтересованных сторон (вариант ailev'а, представляющий собой косметическую правку предыдущего рабочего варианта). Пространство дел области интересов клиента.
7.4. Use the system — использовать систему. Пространство дел области интересов клиента.
7.5. Understand the requirements — понять требования. Пространство дел области интересов решения.
7.6. Shape the system — спроектировать систему (ailev предлагает систему моделировать, но это, видимо, уже заготовка под адаптацию к MBSE (model-based systems engineering)). Пространство дел области интересов решения.
7.7. Implement the system — изготовить систему (мне больше нравится вариант ailev'а, чем предыдущий рабочий "реализовать"). Пространство дел области интересов решения.
7.8. Test the system — протестировать систему (вариант ailev'а отличается скорее косметически, наш работчий мне нравится больше).
7.9. Deploy the system — развернуть систему. Пространство дел области интересов решения.
7.10. Operate the system — управлять системой (я принимаю вариант ailev'а, как лучше отражающий суть, чем "использовать систему", который еще и дублировался на русском с пространством дел из области интересов клиента.
7.11. Prepare to do the work — подготовиться к работе (вариант ailev'а "приготовиться", на мой вкус, больше подходит к контексту вроде "приготовиться к старту на стометровку"). Пространство дел области интересов предпринятия.
7.12. Coordinate activity. Мучаюсь выбором между текущим рабочим "координировать деятельность" и "координировать дела" ailev'а. Вопрос как лучше переводить activity? Деятельность или дела? Пространство дел области интересов предпринятия.
7.13. Support the team — поддерживать команду. Пространство дел области интересов предпринятия.
7.14. Track progress — отслеживать прогресс.
7.15. Stop the work — прекратить работу. Вариант ailev'а — остановить работу. Не вижу преимуществ. Пространство дел области интересов предпринятия.
UPD: 8. [SEMAT] Kernel — ядро [SEMAT]. ailev предлагает переводить "kernel" как "сущности", что мне не очень нравится, т.к. одно из основных утверждений касаемо ядра состоит в том, что оно расширяемое. Расширяются в таком случае не сущности, а набор сущностей. Использовать же везде выражение "набор сущностей" слишком громоздко.

Все вышесказанное не является официальной версией перевода, предлагаемой Semat Russian Chapter. Конструктивная критика приветствуется.

UPD: Обновленная версия тут: http://abayda.livejournal.com/66916.html
Tags: ,