CC BY
19Методика оценки оперативности типовых действий оператора при вводе данных
Капитан В. В. ЧЕМИРИСОВ
АННОТАЦИЯ
ABSTRACT
Рассмотрены методические положения, позволяющие провести анализ и обосновать требования к архитектуре пользовательского интерфейса системы планирования и подготовки данных в АСУ РВСН. Результаты могут быть полезны специалистам, занимающимся разработкой и военно-научным сопровождением систем планирования и подготовки полетных заданий для ракетных комплексов.
The paper looks at the methodological points that help analyze and justify requirements for the architecture of the user interface in the SMF ACS data planning and preparation system. The results can be of use to specialists engaged in developing and providing military-scientific support of systems of planning and preparing flight assignments for missile systems.
КЛЮЧЕВЫЕ СЛОВА
KEYWORDS
Пользовательский интерфейс, программное средство, автоматизированная система управления, подготовка данных.
User interface, software means, automated control system, data preparation.
ОСОБЕННОСТЬЮ автоматизированных систем управления (АСУ) РВСН являются крайне жесткие требования к пользовательскому интерфейсу должностных лиц при выполнении ими функций, связанных с применением компьютеров и другого специального оборудования. Понятие пользовательский интерфейс (ПИ) определяет характер взаимодействия человека (оператора) с техническими и программными средствами.
В настоящей статье обсуждаются вопросы, касающиеся ПИ, используемого в интересах должностных лиц органов управления РВСН, отвечающих за решение задачи управления боевым применением войск и его организации, общую организацию подготовки сил и других задач, формально определенных для органов управления РВСН руководящими документами по боевому применению сил и средств. В АСУ РВСН эти за-
дачи сводятся к задаче преобразования данных об объектах поражения вероятного противника в требуемый для ракетного вооружения формат и решаются с помощью системы планирования и подготовки данных (СППД) на пуски ракет. Результатом применения СППД является выполнение комплекса мероприятий, проводимых должностными лицами центрального вычислительного центра РВСН совместно со штабами объ-
единений и соединений по обеспечению войск полетными заданиями.
В настоящей статье рассматривается подход к формированию требований к пользовательскому интерфейсу должностных лиц, эксплуатирующих СППД. При этом учитывается, что эти требования должны формироваться на начальных этапах НИОКР по разработке новых СППД (в частности, на этапе согласования ТЗ).
По мнению автора, статья может быть интересна, с одной стороны, представителям Заказчика (ОВУ НИУ Минобороны), отвечающим за формулировку требований к ПИ, и, с другой стороны, представителям Разработчика (организаций промышленности), отвечающим за реализацию этих требований. При этом требования должны быть согласованы до уровня, обеспечивающего возможность их объективной проверки в ходе проектирования, изготовления, испытаний и эксплуатации.
Следует отметить, что в ходе согласования требований Заказчик, как правило, исходит из опыта выполнения функций должностных лиц в имеющейся СППД. А Разработчик стремится к заданию требований, выполнение которых предопределено (а точнее, ограничено) возможностями общего и специального программного обеспечения (ПО), на базе которого создается СППД. Тем более что в качестве ПО (и технических средств) в ряде случаев используются зарубежные адаптированные платформы, корректировка функций которых не всегда возможна по целому ряду причин, основной из которых является потеря или искажение функций ПО.
Эргатическими* компонентами в структуре СППД являются должностные лица органа управления, непосредственно взаимодействующие с помощью ПИ с программными и техническими средствами, объединенными в рамках автоматизированных рабочих мест (АРМ) СППД.
Рассмотрим далее основные особенности работы должностных лиц на АРМ СППД.
Главная особенность — повышенные требования к достоверности данных, на основании которых разрабатываются полетные задания. Даже не обсуждается то обстоятельство, что достоверность входных данных, точность их обработки и точность результатов обработки должны полностью исключить любые ошибки, кроме ошибок в алгоритмах обработки данных. Ошибки в алгоритмах должны быть исключены до принятия в эксплуатацию перспективной СППД.
Требования к достоверности обработки входных данных в определенной степени вступает в противоречие с другим требованием к СППД — требованием к оперативности разработки документов. Суть данного противоречия заключается в том, что должностному лицу (оператору) отводится ограниченное (заранее заданное) время выполнения своих функций. И, таким образом, время на оценку достоверности исходных данных и результатов решения соответствующей задачи (задач) выходных данных также ограничено, если учесть, что «глубина и алгоритм поиска» ошибок не всегда формализованы и время на эти действия главным образом зависит от двух факторов: опыта должностного лица — оператора и возможностей пользовательского интерфейса. Оценка опыта должностного лица — оператора заслуживает самостоятельного обсуждения и выходит за рамки настоящей статьи.
* Эргатическая система — схема, одним из элементов которой является человек или группа людей и техническое устройство, посредством которого человек осуществляет свою деятельность.
Относительно возможностей ПИ можно априори сказать, что ПИ в АСУ ВН должен быть дружественным (user-friendly interface).
Дружественный интерфейс — это интерфейс, основанный на таких правилах (принципах), которые позволяют пользователю освоить работу с программой за минимальное время, и требующий от него минимальных усилий при решении своих задач. Широкое развитие интерфейса осуществляется на протяжении многих лет за счет коммерческих продуктов, основанных на таких платформах как Android, Apple, Microsoft. При этом разработчики ПИ исходят из того, что разрабатываемый ими интерфейс будет рассчитан на пользователей — не профессионалов в области программирования.
Понятие дружественного ПИ применительно к должностным лицам, использующим СППД, предполагает, что он изначально разрабатывался для профессионалов самого высокого уровня, эксплуатирующих одну программно-техническую платформу и единственное приложение, обеспечивающее разработку выходных документов. Этот интерфейс должен обеспечивать выполнение самых жестких ограничений по достоверности и оперативности обработки данных в СППД. Это означает, что все ситуации, имеющие место в ходе решения задач в СППД, должны быть разделены на две следующие категории: задержки, связанные с проверкой достоверности исходных данных, и задержки, связанные с заполнением и корректировкой обрабатываемых документов (назовем их формулярами).
Проверка достоверности исходных данных реализуется с помощью соответствующего алгоритма. В общем случае этот алгоритм задает последовательность действий оператора и не задает (в общем случае), каким образом эти действия реализуются — какие
манипуляции, какие движения курсором (и даже глазами), какие нажатия, какие переключения, какие подсказки, какие штатные и нештатные ситуации «подсвечиваются», какие сигналы требуется контролировать оператором в ходе решения задач и так далее. Выполнение этих действий реализует ПИ, и от его возможностей зависит время ввода и оценки достоверности данных. То же самое можно сказать о процессе формирования результирующих документов, в частности полетных заданий.
Из всего этого следует, что корректность алгоритмов — это необходимое условие эффективной деятельности оператора. А достаточным условием является эффективность ПИ в части выполнения требований к достоверности и оперативности решения задач в СППД.
Проблема эффективности ПИ в военных системах имеет свои особенности. Дело в том, что в подавляющем большинстве случаев в АСУВ пользовательские интерфейсы специализируются под решение заранее определенного класса задач. При этом не важно, является ли этот интерфейс стандартным для максимально возможного числа должностных лиц, задействованных в решении разных задач. Более важно, чтобы возможности конкретного ПИ удовлетворяли конкретные категории должностных лиц, для которых он предназначен. В частности, командирам и командующим не нужен ПИ, который требует что-то нажимать (клавиатуру), чем-то манипулировать («мышь»). Чтобы поставить задачу и проконтролировать ее выполнение этой категории должностных лиц достаточно иметь средства аудио- и видеотрансляции, например защищенную видеоконференцсвязь.
Поэтому в отношении эффективности ПИ для должностных лиц, решающих задачи в СППД, необходимо руководствоваться конкретными дей-
ствиями, которые должны быть реализованы в ПИ и к которым должны быть предъявлены жесткие требования по достоверности обрабатываемой информации и точности получаемых в результате обработки документов.
Анализ содержания процесса решения задач в СППД показал, что в общем случае для этой категории должностных лиц все действия можно свести к двум типам:
первый — совершение последовательности операций по выбору элементов ПИ, находящихся на различных участках экрана;
второй — фокусировка места ввода информации для дальнейшего изменения данных, связанных с выбранным элементом управления или для управления диалогом и отображением информации.
Несмотря на то что эти действия сами по себе достаточно универсальны, их реализация алгоритмически (логически) может существенно отличаться. Например, если имеется большое количество элементов ПИ, среди которых необходимо выбрать нужный элемент, то процесс выбора (поиска) может, во-первых, требовать слишком большого времени. Во-вторых, повышается вероятность неправильного выбора элемента. И, в-третьих, может привести к таким ситуациям, как зависание системы, откат к предыдущим шагам и так далее вплоть до срыва процесса. Бороться с негативными последствиями данного действия в этом случае можно, например, с помощью автоматического выбора очередного действия без участия оператора. Понятно, что этот вариант потребует более сложного ПО, но это в большинстве случаев оправдано. Существуют и другие способы снижения опасности нарушить процесс решения задачи.
По поводу фокусировки места ввода данных можно также отметить, что вариантов для ошибочного дей-
ствия оператора достаточно много, и в ПИ должна быть предусмотрена соответствующая защита. Например, место фокусировки должно каким-то образом «подсвечиваться» и «подсказываться». В любом случае нельзя оператора оставлять один на один без подсказки и без защиты от неправильного шага при фокусировке места ввода информации.
Достоверность вводимой информации и точность ее обработки — этот показатель является, как было сказано выше, главным, и любые действия оператора должны контролироваться с помощью ПИ. Вариантов контроля очень много, и дело Заказчика — задать требования по 100-процентному контролю всей вводимой, обрабатываемой информации и выводимых в результате обработки выходных документов.
Дело Разработчика — в ходе проектирования и изготовления СППД доказать, что в плане достижения требуемой достоверности решения задач в СППД применены самые совершенные на момент разработки программные и технические средства контроля достоверности процесса функционирования СППД. При этом во избежание опасности несанкционированного проникновения в систему, необходимо, чтобы все составные части СППД строились не на адаптированных средствах, а исключительно на отечественных программных и технических платформах.
Учитывая вышесказанное относительно основных действий должностных лиц в СППД, можно полагать, что основной задачей методики оценки эффективности ПИ являются вероятностно-временная оценка оперативности процесса ввода данных и точности решения задач по разработке полетных заданий. Эти два показателя в значительной степени зависят от возможностей используемого в СППД пользовательского интерфейса.
Для оценки оперативности требуется фиксация всех действий, требующих участия оператора. Это не очень сложный, но достаточно рутинный процесс, который может быть зафиксирован и одновременно хронометрирован с помощью целого ряда подручных средств, которых сейчас великое множество. Но в то же время процесс решения задачи (задач) в СППД не является детерминированным по целому ряду причин, включая такие, как особенность мышления, быстрота реакции оператора, сложившаяся ситуация, ошибки, форс-мажоры, сбои и отказы оборудования и так далее. Поэтому, говоря о параметрах процесса, необходимо иметь в виду, что для количественных оценок эффективности ПИ необходимо иметь представительную выборку измеряемых параметров.
В мировой практике существует большое количество методик оценки эффективности пользовательских интерфейсов. Одна из самых распространенных методик — модель GOMS (the model of goals, objects, methods and selection rules) — «правила для целей, объектов, методов и выделений»)1. Модель GOMS позволяет предсказать время, потребное опытному пользователю на выполнение конкретной операции при использовании данной архитектуры интерфейса.
Предлагаемая методика оценки эффективности ПИ предполагает проведение квантификации* оперативности типовых действий оператора при вводе данных, суть которой заключается в:
* Квантификация — сведение качественных характеристик к количественной величине результатов измерений — придание результату численного значения.
• распределении варианта выборки либо по одинаковым значениям, либо по интервалам. В последнем случае каждый такой интервал является диапазоном значений изучаемого признака;
• оценке влияния параметров элементов управления пользовательского интерфейса на время выполнения функций программы;
• обосновании выбора архитектуры пользовательского интерфейса программных средств в зависимости от их характеристик.
Под архитектурой пользовательского интерфейса понимается совокупность параметров элементов управления интерфейса (размер и их положение на экране), объединенных сценариями воздействий пользователя. Данная архитектура присуща любому программному средству с графическим пользовательским интерфейсом GUI — «graphical user interface».
Архитектура интерфейса описывается тремя составляющими:
• набором типовых элементов управления интерфейса, каждый из которых определяет состав элементарных действий (например, нажатие левой кнопки мыши, отжатие кнопки мыши, движение указателя и т. п.);
• макетом интерфейса, представляющим собой двухмерный чертеж экранных форм с указанием положений, размеров и состояний элементов управления;
• графом переходов воздействий пользователя на элементы управления, представляющим собой сценарий воздействий пользователя.
Изменение параметров архитектуры пользовательского интерфейса влияет на время выполнения операций по вводу данных пользователями. Для оценки влияния параметров архитектуры ПИ на оперативность работы оператора необходимо определить место качественному пользовательскому интерфейсу в норматив-
ных документах, регламентирующих разработку программных средств.
В ГОСТ РВ 51718-2001 «Программное изделие. Общие технические требования» определено, что все необходимые свойства программного средства выражены показателями качества, которые можно измерить и оценить на всех фазах и итерациях процесса создания программного продукта (системы программных продуктов). Для адекватной оценки показателей качества программного продукта (ПИ — как составной части программного продукта) на некоторых фазах и итерациях процесса его создания необходимо участие конечного пользователя, т. е. представителей эксплуатирующей организации, для которой разрабатывается продукт (система). При таком подходе разработанный программный продукт будет соответствовать заданным требованиям.
Анализ практики разработки ПИ показывает наличие ряда проблем, связанных со следующими моментами:
• недостаточной унификацией интерфейсов программных продуктов, разработанных для ВВСТ РВСН, реализованных на различных программно-аппаратных платформах;
• слабым привлечением к процессу разработки специалистов смежных областей, способных оценить потребности пользователя и сформу-
лировать пользовательские качества интерфейса на этапе разработки;
• нерациональной организацией процесса разработки программной продукции, особенно в части организации взаимодействия с потребителем2;
• отсутствием универсальной системы показателей качества интерфейса, позволяющего определять требования к нему в виде числовых величин.
• в соответствии с ГОСТ 2819589 «Оценка качества программных средств» требования к качеству ПИ в техническом задании (ТЗ) не всегда формулируются в виде числовых показателей или характеристик. Вследствие этого проведение разработчиком исследований по обоснованию его рационального облика возможно только в инициативном порядке в ходе эскизного (технического) проектирования.
Из всей номенклатуры показателей качества программных средств, приведенных в ГОСТ 28195-89, таких как надежность, сопровождаемость, удобство применения, эффективность, универсальность (гибкость) и корректность, используемых для оценки пользовательского интерфейса, применяются такие комплексные показатели фактора «удобство применения», как:
• легкость освоения;
• доступность эксплуатационных программных документов;
• удобство эксплуатации и обслуживания.
Процесс решения задачи (задач) в СППД не является детерминированным по целому ряду причин, включая такие, как особенность мышления, быстрота реакции оператора, сложившаяся ситуация, ошибки, форс-мажоры, сбои и отказы оборудования и так далее. Поэтому, говоря о параметрах процесса, необходимо иметь в виду, что для количественных оценок эффективности ПИ необходимо иметь представительную выборку измеряемых параметров. Предлагаемая методика оценки эффективности ПИ предполагает проведение квантификации оперативности типовых действий оператора при вводе данных.
Требования к этим показателям обычно выражаются вербальным описанием общих параметров отображения и взаимодействия. Негативным эффектом от вербальной формализации требований к ПИ пользовательскому интерфейсу разрабатываемых программных средств является неоднозначность понимания, которая потенциально приводит к дополнительным итерациям разработки и, как следствие, к увеличению продолжительности и стоимости выполняемых работ3. Задача проектирования и разработки ПИ программных средств военного назначения состоит в поиске компромисса между Разработчиком и Заказчиком на стадии проекта, когда техническое задание согласовано, но утвержденные в нем требования нуждаются в проработке. В решении этой задачи на этапе разработки программы (системы) необходимо выбирать такие проектные подходы и решения, которые будут соответствовать открытой архитектуре создания программного обеспе-чения4. В этом случае программное средство подготовки данных необходимо разрабатывать с учетом следующих организационных и проектных решений.
Первое. Итерационную разработку человеко-ориентированного ин-терфейса5 необходимо планировать в соответствии с условиями:
• согласования в ТЗ порядка выполнения и приемки отдельных работ по созданию пользовательского интерфейса, выполняемых в течение основных работ;
• необходимости создания стенда по испытаниям пользовательского интерфейса с разработанной программой для участия операторов эксплуатирующей организации;
• проведения совместных натурных испытаний пользовательского интерфейса на стенде с целью получения значений показателей качества согла-
сованной системы показателей в рамках регламентированного комплексного показателя, связанного с удобствами эксплуатации и обслуживания;
• выбора рациональной архитектуры пользовательского интерфейса, позволяющей достигать требуемых значений показателей качества с каждым добавлением (изменением) функциональности в программном средстве в ходе его разработки.
Второе. Для проектирования паттернов*, позволяющих организовывать программный код6, необходимо:
• структурное разделение пользовательского интерфейса от данных и операций программы, обеспечивающей его работу, в виде составной части работы по созданию программного продукта7;
• прототипирование пользовательского интерфейса с помощью нотаций иЫЬ** для автоматизации документирования интерфейса и однозначного понимания его архитектуры8.
* Паттерн — повторяемая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста.
** Нотация UML (Unified Modeling Language — унифицированный язык моделирования) представляет собой графическую интерпретацию семантики для ее визуального представления.
Третье. В структуру разрабатываемой программы внедрить технологию сбора и учета статистических сведений, совершаемых манипуляций пользователя над элементами управления интерфейса — систему мониторинга действий оператора9, обеспечивающую:
• получение достоверной информации об опыте пользователя10 на всех стадиях создания и эксплуатации программы для дальнейшего анализа этих сведений и определения «тонких» мест в архитектуре интерфейса;
• возможность отмечать совершенную работу пользователя через агрегированные количественные показатели.
Определив направления развития проектных решений, необходимо конкретизировать цель проектирования пользовательского интерфейса программных средств подготовки данных. В работе11 введены понятия гибкости использования и операционной сложности диалоговых систем, к которым относится ПИ, реализованный в СППД.
Гибкость использования означает полноту возможностей оператора в выдаче задач диалоговой системе. По сути это набор функций по формированию, контролю синтаксической и семантической правильности сформированных данных боевого применения сил (средств). Она определяется числом различных процессов, которые может выполнять оператор при помощи интерфейса.
Для адекватной оценки показателей качества программного продукта (ПИ — как составной части программного продукта)
на некоторых фазах и итерациях процесса его создания необходимо участие конечного пользователя, т. е. представителей эксплуатирующей организации, для которой разрабатывается продукт (система). При таком подходе разработанный программный продукт будет соответствовать заданным требованиям.
Операционная сложность означает сложность операционных работ, которые должен выполнить оператор для решения поставленной задачи. Различают объективную операционную сложность с ее большей ресурсной затратностью и высокими рисками технической надежности и субъективную, отражающую физические характеристики оператора, в том числе и в психоэмоциональной сфере, связанные с его реакцией на возникающие ситуации.
С учетом этих понятий проектирование интерфейса «человек—машина» можно рассматривать как задачу оптимизации, а именно: достижения максимальной гибкости использования возможностей оборудования при минимальной операционной сложности.
Вербальная постановка задачи построения пользовательского интерфейса в СППД может быть поставлена следующим образом.
При постоянной величине гибкости использования, т. е. заданном наборе реализуемых функций системы, оптимальность облика пользовательского интерфейса достигается при минимальной сложности операционных работ, которые должен выполнить пользователь, чтобы достичь решения поставленной задачи в заданных условиях.
Комплексный показатель операционной сложности выражается набором показателей, среди которых значится оперативность выполнения задачи по вводу данных установленной структуры, представляющая собой показатель эффективности пользовательского интерфейса: Ро < Твд до) — вероятность ввода данных за время, не превышающее допустимое.
В исследовательских целях для оценки влияния архитектуры ПИ на оперативность выполнения задачи по вводу данных операторов СППД автором была разработана програм-
ма-тренажер, основанная на последовательном выполнении типовых действий двух видов: «указание» — действия выбора элементов управления, «активизация» — действия изменения свойств (состояний) элементов управления12. Сравнению подлежали две архитектуры ПИ. Стоит отметить, что обе архитек-
туры семантически одинаковы, т. е. состоят из одинакового количества элементов управления и основаны на одинаковых алгоритмах действий. Архитектуры различаются визуальной составляющей, так называемым «макетом» интерфейса, отражающим размеры и положение элементов управления (рис. 1).
а) б)
Рис. 1. Макеты интерфейса программы-тренажера: а) архитектура 1, б) архитектура 2
В эксперименте участвовало четыре оператора СППД, выбранных в соответствии с их уровнем подготовки. Каждый оператор выполнял ввод данных одинаковой структуры сначала с помощью архитектуры 1, затем с помощью архитектуры 2. При каждом вводе данных совершалось около 400 типовых действий.
Результаты оценки показали, что архитектура 2 эффективнее (характеризуется меньшей операционной сложностью) архитектуры 1: ввод данных с помощью архитектуры 2 был выполнен быстрее в среднем на 12 % по сравнению с архитектурой 1, количество ошибок было снижено на 8 %.
Эксперимент показал, что расстояния между целевыми объектами интерфейса и их размеры влияют на время ввода данных и количество ошибок, совершаемых человеком-оператором, работающим в режиме интенсивного ввода.
Развитие теоретических положений оценки качества ПИ на основе анализа проектов архитектур интер-
фейса за счет использования кванти-фикации позволяет сформулировать другие показатели, позволяющие задать количественные требования к интерфейсу.
Безошибочность ввода данных. Показатель Р ^ < Т , ) — вероят-
4 ош ош доп' *
ность того, что временные затраты на ошибки не превышают допустимые. Критерий Р > Р , — значение по-
ош ош доп
казателя эффективности не менее допустимого.
Устойчивость ввода данных. Показатель Р (I < Т , ) — вероятность
по по доп
того, что интервал времени между поступлением ошибки не превышает заданное. Критерий Р > Р — зна-
по по доп
чение показателя эффективности не менее допустимого.
Пропускная способность. Показатель 1к — количество введенных атомарных единиц данных в единицу времени. Критерий 1к > 1к доп — значение показателя эффективности не менее допустимого.
Монотонность. Показатель I —
м
количество операций ввода данных,
выполненных за одинаковое время. Критерий I > I , — значение по-
Е Е мм доп
казателя эффективности не менее допустимого.
Предложенные показатели эффективности интерфейса могут составлять систему показателей его качества, формирующую в соответствии с ГОСТ 28195-89 комплексный показатель «удобство эксплуатации и обслуживания». Предложенная система показателей качества интерфейса может быть использована как для оцен-
ки интерфейса СППД, так и других программных средств военного назначения, имеющих похожую архитектуру пользовательского интерфейса.
Разработанные методические положения позволяют провести анализ и обосновать требования к архитектуре пользовательского интерфейса программных средств СППД, боевое использование которой потенциально позволит повысить оперативность ввода данных и снизить количество ошибок.
ПРИМЕЧАНИЯ
1 Раскин Дж. Интерфейс: новые направления в проектировании компьютерных систем. СПб.: Символ-Плюс, 2005. 200 с.
2 Тиханычев О.В. Пользовательские интерфейсы в автоматизированных системах: проблемы разработки // Программные системы и вычислительные методы. 2019. № 2. С. 11—22. DOI: 10/7256/24540714/2019/2/28433.
3 Казаков Г.В., Чемирисов В.В., Уваров А.В. Подход к созданию универсального средства построения пользовательского интерфейса программных средств подготовки данных // Сборник статей конференции «Информатика и вычислительная техника» ВИТ «ЭРА», 2019. С. 116—129.
4 ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. С. 188.
5 ГОСТ Р ИСО 9241-210-2012 Эргономика взаимодействия человек-система. Ч. 210. Человеко-ориентированное проектирование интерактивных систем. Национальный стандарт Российской Федерации. С. 94.
6 Гамма Э., Хелм Р., Джонсон Р., Влисси-дес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. СПб.: Питер, 2010. 366 с.
7 Казаков Г.В., Чемирисов В.В. Анализ средств построения графического пользовательского интерфейса как неотъем-
лемой части программных средств подготовки данных // Сборник трудов секции 22 имени академика В.Н. Челомея XLI Академических чтений по космонавтике. 2017. Вып. 5. С. 429—440.
8 Казаков Г.В., Чемирисов В.В. Применение UML-модели для построения пользовательского интерфейса программных средств подготовки данных управления летательными аппаратами // Сборник трудов секции 22 имени академика В.Н. Челомея XLII Академических чтений по космонавтике. 2018. Вып. 6. С. 223—231.
9 Чемирисов В.В., Сорокин С.А. Обоснование применения системы мониторинга действий операторов в специальном программном обеспечении военного назначения // Сборник трудов 4 ЦНИИ «Методические аспекты исследования эффективности ракетно-космического вооружения». 2013. № 111. С. 132—139.
10 ГОСТ Р ИСО 9241-210-2012 Эргономика взаимодействия человек-система.
11 Деннинг В., Эссинг Г., Маас С. Диалоговые системы «Человек-ЭВМ» Адаптация к требованиям пользователя. М., 1984. 110 с.
12 Казаков Г.В., Чемирисов В.В. О способе анализа показателей быстродействия и безошибочности деятельности оператора программных средств подготовки данных // Сборник трудов секции 22 имени академика В.Н. Челомея XLI Академических чтений по космонавтике. 2017. Вып. 5. С. 414—428.
