ГОСТР ИСО 26162—2016
В некоторых случаях есть другая категория установления приоритетов, которая отражает неко
торую корпоративную стратегию или другое стратегическое или законное требование. Например, у
компании может быть политика для поддержки определенных требований доступности для сенсорно
ослабленных пользователей, и эти требования могут быть обязательными, нужны ли текущей группе
пользователей они.
От типового прецедента использования, на который ссылаются в 6.1.3. возможно определить сле
дующие конструктивные требования. (Следующий список только иллюстративен и не предназначен
быть всесторонним.)
a) Редактор перевода и словарь проекта должны быть применимыми в удаленной окружающей
среде.
b
) У терминологических записей должны быть идентификаторы проекта, которые являются рас
познаваемыми редактором перевода.
c) Терминологические записи должны быть экспортными от сбора данных в форме словаря про
екта для редактора перевода, или непосредственно связанные с редактором перевода. Идентифика
тор проекта поэтому должен быть применимым как экспортный фильтр или. поскольку представление
просачивается, интегрированная окружающая среда. Кроме того, требованиям обязательного поля для
редакторского переводческого словаря должны отвечать ТМ.
d) Словарь проекта должен быть доступным независимо от редактора перевода.
e) Редактор перевода должен автоматически выдвинуть на первый план условия, которые нахо
дятся в словаре проекта.
0 Редактор перевода должен искать в словаре проекта термин, который выдвинут на первый план
в исходном предложении.
д) Поля данных должны быть видимы в словаре проекта, чтобы помочь переводчику сделать со
ответствующий выбор, когда вход содержит многократные переводы или многократные чувства.
h) Редактор перевода должен быть запрограммирован, чтобы вставить отобранный перевод на
целевое предложение. (Этот тип зависимости от внешнего инструмента должен быть определен и ре
шен с разработчиками того инструмента.)
6.7 Проведение конкурентоспособной оценки
Чтобы гарантировать, что задачи и требования, которые были определены, не чрезмерно сосре
доточены на внутренних процедурах и что они принимают во внимание практику управления термино
логии за пределами организации, коллектив дизайнеров должен исследовать способ, которым другие
сопоставимые организации обращаются с подобными задачами терминологии. Команда должна оце
нить другие TMSs, чтобы произвести идеи о том. как осуществить функции. Прежде, чем развить новые
TMS. команда должна определить, есть ли коммерчески доступные TMS. которые обеспечивают не
обходимые особенности, и, если так. будет ли это более рентабельно, чтобы купить или настроить эти
TMS. чем развить новые.
6.8 Проектирование и оценка прототипа
Используя данные, собранные во время предыдущихстадий, проектировщикидолжны произвести
прототип, размышляющий, как TMS будут смотреть и функционировать. Пользователи должны оценить
прототип на другой сессии фокус-группы лицом к лицу, куда они идут посредством дизайна и сравни
вают его с инструментами и процессами, с чем в настоящее время они работают. Оценки дизайна про
тотипа должны быть проведены в течение развития продукта. Анкетный опрос или форма комментария
должны использоваться, чтобы создать обратную связь от пользователей. Этиданные могут тогда быть
по сравнению со статистикой обратной связи в ранее и более поздние стадии, чтобы утвердить дизайн.
Этапы должны быть установлены в графике развития, когда развивающиеся TMS должны будут
быть проверены против технических требований дизайна. Это помогает гарантировать, что функции
развиты согласно оригинальному вводу данных пользователем.
6.9 Наладка дизайна по отзывам пользователей
На основе обратной связи от сессии оценки прототипа дизайна проектировщики должны внести
изменения в дизайн, чтобы исправить слабые места или добавить требуемые функции. Сессии об
ратной связи должны быть повторены по мере необходимости, пока пользователи не удовлетворены
прототипом.
17