CC BY
51
Субъектно-целевой метод организации проектирования пользовательских интерфейсов информационных систем управления предприятиями авиакосмического комплекса
The subjective-objective method of user interfaces designing organization for
ERP-systems in aerospace industry
Моругин Петр Алексеевич аспирант
Московский авиационный институт (национальный исследовательский
университет), ИНЖЭКИН МАИ morugin@gmail. com
Peter Morugin postgraduate student
Moscow Aviation Institute (National Research University), INZHEKIN MAI
morugin@gmail. com
Аннотация
Статья посвящена описанию методик субъектно-целевого метода организации проектирования пользовательских интерфейсов информационных систем управления на примере промышленных предприятия авиакосмического комплекса.
Annotation
The paper is devoted to the methodics of the subjective-objective method of user interfaces designing organization for ERP-systems in aerospace industry.
Ключевые слова
интерфейс, проектирование, диалоговые системы, программные продукты, пользователи, эргономические принципы, формы ввода данных, элементы управления, жизненный цикл ИСУ.
Keywords
interface, design, interactive systems, software products, personas, ergonomic principles, data entry forms, controls, ERP-systems life cycle.
Введение
Актуальность и целесообразность написания данной статьи определяется несколькими факторами.
1. Регулярная смена пользовательских интерфейсов (ПИ) эксплуатируемых информационных систем управления (ИСУ) на предприятиях. Частая сменяемость диктует необходимость эффективной организации проектирования ПИ.
2. Регулярные изменения в законодательстве. Частая смена требований к формам отчетности и ведения бухгалтерского и налогового учета является характерной для России. И это сказывается на задачах автоматизации управления предприятиями.
3. Связь эффективности ПИ ИСУ с эффективностью управления предприятием. Чем быстрее ИСУ позволяет руководителю принимать решения и чем точнее предоставляется необходимая информация, тем продуктивнее функционирует предприятие в целом.
4. Широкое обсуждение рассматриваемой проблемы российской и зарубежной научной общественностью.
С учетом того, что существующие подходы к проектированию ПИ ИСУ ориентированы или на пользователей или на цели и задачи [16, 17], автором предлагается новый метод организации проектирования ПИ ИСУ для
промышленных предприятий, который после положительной апробации может быть применен на практике. Его особенностью является то, что он учитывает в равной степени, как особенности пользователей (субъектов), так и их цели и задачи. Целесообразным представляется обозначить данный подход как субъектно-целевой. Общая схема этапов субъектно-целевого метода и их связь с фазами управления и стадиями жизненного цикла (ЖЦ) ИСУ представлена на рисунке 1. Далее остановимся более подробно на каждом из этапов.
Этап концептуального моделирования
На этапе концептуального моделирования анализируются проект, предметная область, задачи проекта и пользователей, определяются подходы к решению этих задач.
До начала всех работ необходимо, во-первых, формализовать все бизнес-процессы, во-вторых, получить и изучить маркетинговые планы, понять стратегию и планы развития организации, в-третьих, провести аудит существующих конкурентов, в-четвертых, определить какие есть технологии в этой области.
Качественные исследования предметной области помогают определить конъюктуру и существующие ограничения. В отличие от количественных исследований, они также помогают выявить шаблоны поведения и квалификацию предполагаемых пользователей.
До разработки структуры, дизайна и прототипирования необходимо понять цели разработки ИСУ. Первоначально в исследованиях должны выявляться требования бизнеса, чего заказчик хочет добиться, создавая какую-либо ИСУ, делая редизайн ПИ существующей ИСУ или делая реинжиниринг ИСУ. Необходимо выявить образ ИСУ, какой заказчик хочет ее видеть. Единое видение модели продукта важно для планирования работ и предметного общения заказчика с разработчиком.
Фазы управления
Стадии жизненного цикла ИСУ
Инициализация,
планирование
Концептуальное
моделирование
Персонажи,
сценарии
Качественные исследования предметной области
Исследования квалификации пользователей
Моделирование персонажей
Создание контекстных сценариев
Анализ и формализация бизнес-процессов
Изучение планов и стратегии развития предприятия
Аудит конкурентов
Исследование существующих технологий
Концепция, техническое задание, проектирование
Выполнение
Логическое
моделирование
Функциональные требования
Графическое
моделирование
Прототип ПИ ИСУ
Описание информационной модели
Описание функциональной модели
Исследование
существующих ограничений
Определение необходимых элементов управления
Определение оптимальных способов представления информации
Проектирование средств поддержки пользователя
Выработка пользовательских требований
Выработка бизнес-требований
Выработка технологических требований
Реализация
Контроль,
закрытие
Физическая
реализация
Программная реализация Тестирование и отладка
Сдача в промышленную эксплуатацию
Внедрение, обучение, сопровождение
Контроль качества
Вывод ИСУ из эксплуатации
Рис. 1. Этапы субъектно-целевого метода организации проектирования ПИ
Стоит отметить, что для корректного проектирования ПИ в двух последних ситуациях необходимо наличие формализованных бизнес-процессов с учетом не только существующих на текущий момент процедур управления, но и с учетом возможных новых факторов и тенденций.
Далее необходимо определить, кто будет пользоваться создаваемым ПИ ИСУ, составить модели пользовательского поведения, понять мотивы и квалификацию пользователей, выявить характеристики окружения, инструменты которыми они пользуются, понять проблемы, с которыми они сталкиваются в существующей реализации, если она есть.
Затем, на основе анализа пользователей, составляется набор ключевых и второстепенных персонажей, типовых пользователей ИСУ. Как правило, оказывается достаточно одного ключевого персонажа — стандартного пользователя и двух второстепенных.
На основе определенных персонажей определяются контекстные сценарии. На основе сценариев формируется пул количественных показателей оценки эффективности создаваемого ПИ.
При проектировании взаимодействия определяются оптимальные варианты реакции ПИ на действия пользователя, формируются пользовательские сценарии. На выходе получается документированная модель продукта, описывающая концепцию ИСУ, персонажей, пользовательские сценарии, целевую аудиторию, желаемую функциональность. На основе персонажей и сценариев, можно переходить к структуре ИСУ, т. е. к описанию информационной и функциональной моделей.
Автором предлагается метод определения стоимости использования ПИ ИСУ сложными промышленными предприятиями, к которым, в частности, относятся предприятия аэрокосмического комплекса [18].
В формуле (1) представлена формула оценки стоимости приходящейся на конкретного пользователя стоимости поддержки ПИ ИСУ.
Г - ГЗ * КЗ (1)
г' ^подд IXi , (1)
где: С/ — стоимость использования ПИ ИСУ ьм специалистом в j-м периоде,
С]подд — стоимость поддержки ПИ ИСУ в j-м периоде,
К/ — уровень квалификации ьго пользователя (высокий — 0,1, средний — 0,4, низкий — 0,8) в j-м периоде.
Для определения целевой аудитории представим пространство знаний пользователей, которые будут использовать ПИ, как условную ось с координатами от нулевого уровня подготовки до абсолютно полного набора знаний и компетенций. Допустим, что прямая организована таким образом, что по отношению к левой стороне располагаются все сотрудники, которые абсолютно
ничего не знают о том, как использовать ПИ, и не обладают подготовкой в
человеко-компьютерном взаимодействии. По отношению к правой стороне оси расположим пользователей, которые имеют высокий уровень подготовленности и знаний о взаимодействии с ПИ. Пользователи распределяются по оси линейно в зависимости от уровня их знаний.
Расстоянием от левого края оси можно определить степень подготовленности любого пользователя. Для каждого пользователя назовем сумму знаний, которую они будут иметь, когда начнут работать с ПИ, текущим уровнем знаний и обозначим ее на оси отрезком B].
Далее определим на оси отрезок, который обозначает требуемый уровень знаний, необходимый пользователю для достижения целей, как ^; D]. На рисунке 2 представлена ось с отмеченными крайних отрезками подготовленности.
Рис. 2. Уровни знаний пользователей
Для каждого из пользователей можно определить текущий уровень знаний, положение этой области на условной оси знаний будет изменяться с течением
времени пропорционально получаемому опыту. Можно обнаружить, что, нанеся уровни знаний нескольких различных пользователей, выявляются кластеры-связки пользователей, имеющих похожие наборы знаний.
Использование этих кластеров может помочь проектировщикам определить, на каких пользователях имеет смысл сосредоточиться. Работа с пользователями в серединах нескольких из наиболее важных кластеров представляется оптимальным выбором целевой аудитории для проектировщиков ПИ.
Отрезок ф; ^ рисунка 2 можно определить как разницу в знаниях. Таким образом, целевой аудиторией разрабатываемого ПИ можно определить пользователей, чья подготовленность находится в данном отрезке.
Нет необходимости упрощать ПИ для аудитории, чей уровень знаний находится левее текущего уровня знаний. Равно как, нет смысла проектировать ПИ для уровней правее требуемого уровня знаний, так как пользователям не понадобится эта информация для решения задач в рамках создаваемой ИСУ. Оптимальным представляется сокращение разницы в знаниях в обоих направлениях: как путем обучения пользователей (с помощью пояснительного текста и справок), так и путем снижения проектировщиками сложности ПИ.
Выявление текущего и требуемого уровня знаний сводится к определению того, что пользователи уже знают и, что они должны знать. В качестве методов определения текущих знаний пользователей, предлагается использовать полевые исследования. Наблюдая за потенциальными пользователями на их рабочих местах с их привычным набором инструментов и ежедневными задачами, можно получить глубокое понимание того, какие знания они имеют, и где располагаются их текущие уровни знаний.
В качестве подхода к определению недостающих знаний предлагается применять тестирование удобства использования. Если пользователям предложить воспользоваться созданным ПИ — разница в знаниях становится очевидна. После такого тестирования появляется возможность составить список, в котором
перечислены все компетенции пользователя, которые ему необходимо приобрести для эффективной работы с ПИ [7].
В каждом наборе персонажей необходимо определить хотя бы один ключевой персонаж. Ключевой персонаж должен находиться в фокусе проектирования, поэтому важно определить его квалификацию и уровень подготовленности. Например, ПИ ИСУ, у которой ключевой персонаж — руководитель будет сильно отличаться от ПИ ИСУ, у которой ключевой персонаж — оператор ввода данных в базу. Это ставит задачу оценки квалификации ключевого персонажа.
Как показано в [4], распределение опыта пользователей тяготеет к нормальному статистическому. Следовательно, как правило, большинство пользователей не являются ни начинающими, ни экспертами, а уровень их подготовленности находится между этими двумя крайностями. На рисунке 3 представлен график зависимости количества пользователей ИСУ от уровня их квалификации, построенный на основе данных [3]. На нем видно немного начинающих пользователей в начале шкалы, преобладание пользователей среднего уровня квалификации.
21%
Низкий Средний Высокий
Рис. 3. Распределение пользователей в зависимости от уровня навыков
использования ЭВМ
Достоверность построения обеспечивается сопоставление результатов с другим статистическим источником [10] за предыдущий временной период, гистограмма которого представлена на рисунке 4.
59%
Низкий Средний Высокий
Рис. 4. Распределение пользователей в зависимости от уровня навыков
использования ЭВМ
Экстремумы накладываемых на гистограммы 3 и 4 полиномиальных линий тренда второй степени совпадают в среднем уровне квалификации пользователей.
Представленный в [10] коэффициент вариации составляет 19%, что не превышает 33%, и свидетельствует о том, что колеблемость значений невысокая. Объемом статистической выборки покрывается 79,6% от общей численности занятых работников по субъектам Российской Федерации.
Каждый из пользователей работает с ИСУ в течение некоторого промежутка времени. Для определения длительности промежутка взаимодействия с ИСУ существует множество приложений. Например, Yaware, Maxapt QuickEye или RescueTime. Однако функциональность большинства БКР-систем может быть дополнена модулем, который будет представлять собой счетчик, учитывающий время взаимодействия с ИСУ. Умножая часовую ставку специалиста на ежегодное количество часов взаимодействия с ИСУ и на количество специалистов этой квалификации, можно определить стоимость ежегодных расходов, связанных с использованием ПИ.
С = счас * ч/ * п/, (2)
где: С/ — стоимость работы с ИСУ специалиста ьй квалификации в j-м периоде,
Сас — часовая ставка специалиста ьй квалификации,
Ч/ — количество часов взаимодействия с ИСУ специалиста ьй квалификации в j-м периоде,
Пi — среднесписочное количество сотрудников ьй квалификации в j-м периоде.
Таким образом, исходя из (2), можно определить, что улучшение ПИ, которое уменьшит количество часов взаимодействия с ним, позволит сократить общие издержки на поддержку ИСУ при фиксированных часовых ставках и квалификации специалистов.
Суммируя полученные значения для каждой группы квалификаций пользователей можно определить общую стоимость взаимодействия с ИСУ для предприятия.
к=1
где: п — число групп сотрудников определенных в зависимости от уровня их квалификации,
^ С. — стоимость работы п-групп специалистов компании с ИСУ в j-м периоде,
С к. — количество часов взаимодействия с ИСУ специалиста к-й квалификации в j-м периоде.
Исходя из (3) можно определить группу пользователей, стоимость взаимодействия для которой имеет максимальный вес в общей сумме. Анализируя расположение этой группы пользователей на оси, представленной на рисунке 1, руководство разработки имеет возможность принять решение о направлении и степени изменения требований к объему знаний, необходимому для работы с создаваемой ИСУ.
По результатам предпроектного обследования создается организационное обеспечение. Согласно [1] организационное обеспечение ИСУ состоит из совокупности документов, устанавливающих организационную структуру, регламентирующих взаимодействие пользователей и эксплуатационного персонала
п
(3)
между собой в процессе разработки и эксплуатации ИСУ. Также в рамках организационного обеспечения может создаваться технико-экономическое обоснование эффективности проекта и техническое задание или спецификация, содержащая задачи, подлежащие автоматизации, выбор методов реализации, построение концептуальных схем бизнес-процессов до и после внедрения ИСУ.
Доля этапа в общей трудоемкости: 40%.
Этап логического моделирования
На данном этапе определяется информационная архитектура, структура и функциональность ИСУ, происходит выработка пользовательских, бизнес- и технологических требований. Функции распределяются по списку экранов. Прорабатывается структура ИСУ, функциональность распределяется по конкретным экранам в виде структурных схем страниц. На них также показывается порядок расположения блоков и элементов. В рамках данного этапа предусматриваются возможные аномалии вставки, модификации, удаления. На основе функциональных требований выявляются необходимые в ПИ элементы и способы представления информации.
Необходимо выявить все возможные технические ограничения. Важно учесть не только очевидные на момент осуществления проектирования компоненты, но и спрогнозировать те, потребность в которых может возникнуть в среднесрочной перспективе.
Описание информационной и функциональной модели (поведения, формы и содержания), определение общей структуры ПИ с необходимыми элементами и набором функций также осуществляется на данном этапе. Результатом этапа являются функциональные требования.
Задача определения набора функций подлежащих реализации обладает сложностью формализации. В 1980-х годах японский профессор Нориаки Кано разработал модель оценки удовлетворенности покупателей от использования продуктов. Автором предлагается использовать данную модель для целей
функционального этапа проектирования ПИ ИСУ и обозначить этот вариант использования как интерфейсно-функциональный. Данную методику широко применяют маркетологи для товаров народного потребления, однако для оценки ПИ ИСУ промышленных предприятий, упоминаний ее применения найдено не было. Автором предлагается использовать интерфейсно-функциональный подход из-за того, что его применение может осуществляться не только при создании новых ИСУ, но и при редизайне существующих ПИ, на начальном этапе, реинжиниринге бизнес-процессов. Это позволит определить то, какие функции необходимо сохранить в новой ИСУ, а от каких можно отказаться. Дополнительным достоинством интерфейсно-функционального подхода является возможность добавления в список не только существующих функций, но и тех, которые еще не реализованы, чтобы оценить необходимость их имплементации.
Несмотря на обилие существующих технологий разработки, в большинстве случаев ИСУ обладают неэффективными ПИ. Чтобы сложные технологии были полезными и обеспечивали удобство пользователя необходимо применять процесс проектирования взаимодействия. В случае желания использовать максимальное число новых технологий без заботы об удобстве их использования, технологические возможности действуют не на благо пользователя. Пользователи ценят ИСУ не за количество строк программного кода, но за удобство использования.
Характерная особенность ИСУ в том, что чем раньше по шкале времени жизни проекта написан код, тем сложнее вносить в него изменения. Со временем, в каждой ИСУ накапливаются возможности, потребность в которых обнаружилась после начала разработки, внедрение которых оборачивается дополнительными издержками.
Предварительное проектирование, как правило, требует создания более сложного кода, однако в масштабе ЖЦ ИСУ объем кода, как правило, получается меньшим. Стоимость программирования не сильно возрастает с увеличением сложности кода, однако значительно возрастает с увеличением его объема из-за затрат на тестирование, отладку и поддержку.
Проведенные исследования [15] указывают на то, что для большинства. ИСУ:
— код ПИ составляет от 47 до 60 процентов кода всей программы;
— на разработку ПИ уходит как минимум 29 процентов проектного бюджета и в среднем 40 процентов всех усилий разработчиков по созданию ИСУ.
Как правило, в процессе разработки этап программирования обладает наиболее высокой себестоимостью. Чем более квалифицирован программист, тем больше времени он тратит на настройку окружения и меньше времени на собственно написание кода. К сожалению, не у всех компаний есть возможность привлекать исполнителей только высокой квалификации. Поэтому одним из наиболее доступных способов снижения издержек при разработке является сокращение времени, затрачиваемого на программирование. При применении субъектноцелевого метода, продолжительность этапа проектирования сопоставима с продолжительностью этапа программирования.
Пользователь не должен получать специальное образование, чтобы решать посредством ЭВМ свои ежедневные задачи в корпоративных приложениях, где он владеет предметной областью. В случае обнаружения когнитивного сопротивления, пользователи стремятся освоить наименьший набор функций, позволяющий решать типовые задачи, а остальные функции игнорируют [4]. Следовательно, чем больше действий необходимо предпринять для использования функции, тем менее она востребована.
Проектировщику на функциональном этапе требуется определить способы ввода данных в ИСУ. Приведем пример отличий интерфейса созданного с предварительным проектированием от интерфейса, созданного по модели реализации. Например, существует два различных вида представления каталога объектов:
1. Линейный: некоторый граф и в нем на разных ветвях находятся различные функции, и чтобы пользователю какую-нибудь найти, нужно знать ветвь, на которой она находится. Пример линейного подбора представлен на рисунке 5.
Рис. 5. Линейный подбор
2. Фасетный: представление каталога и модель общения с пользователем. Фасетная модель взаимодействия может рассмотреть все заданные пользователем атрибуты, и выдать все подходящие варианты, которые есть в ИСУ. По аналогии с технологией тегирования, с объектом, ассоциируется ряд атрибутов, и записывается в базу. Пользователю не нужно перемещаться по конечным категориям в поиске объекта. Соотношение товаров и атрибутов задается, как «один-ко-многим». Фасетное представление может использоваться в ПИ только в случае, если данная функциональность была заложена на этапе проектирования. Потому, что внедрение такого вида ПИ когда код уже написан, а системная архитектура создана, оборачивается значительными издержками. Пример фасетного подбора представлен на рисунке 6.
Рис. 6. Фасетный подбор
В примере пользователю достаточно указать сумму поставок, которая его интересует. Период, валюту и город указывать не обязательно, по умолчанию устанавливаются значения «любой». ИСУ сама предложит возможные варианты, предоставив пользователю возможность выбрать наиболее подходящий. Выбор в данных полях конкретных значений служит лишь дополнительным фильтром сужающим область поиска.
После функционального этапа предлагается определять, как спроектированные данные должны быть представлены и переходить к графическому этапу моделирования, который рассматривается далее.
Доля этапа в общей трудоемкости: 20%.
Этап графического моделирования
Графический этап характеризуется необходимостью соблюдения ряда эргономических и графических принципов, часть из них уже используется в рамках существующих подходов [4-8, 12]. Но автор считает целесообразным предложить использовать их также и в субъектно-целевом методе за счет того, что эффективность их применения подтвердилась опытной эксплуатацией и функциональную замену для них разрабатывать не имеет смысла.
Исходя из контекста задачи, определяются способы подачи информации, набор элементов управления для каждого экрана. Оформление структурных схем ключевых страниц в экраны-прототипы при помощи программных средств прототипирования (например, Axure RP или Adobe Muse). Результатом этапа является псевдо-функциональный прототип, который сопровождается текстовыми спецификациями ПИ.
В случаях если в ИСУ получается большое количество значимых экранов достаточно составить экраны процессов решения ключевых задач ИСУ, на которых показать общие принципы. Переход от текстовых описаний к наглядным прототипам облегчает понимание. Прототип позволяет ставить полную и
непротиворечивую задачу разработчикам. Прототип также может служить материалом для презентации ИСУ.
Затем осуществляется детализация прототипа: проектирование элементов
управления, выбор визуальных атрибутов отображаемой информации, проектирование средств поддержки пользователя, чистовая отрисовка элементов оформления и управления.
На данном этапе визуально оформляются структурные схемы страниц, определяется общая стилистика и внешний вид конкретных элементов управления. Данный этап является дополнительным уровнем проверки работоспособности решений. Дизайнер может заметить ошибки проектирования или предложить свои, более оптимальные, решения. Рассмотрим некоторые принципы, применяемые в рамках данного этапа.
Действенным приемом оказывается представление, что на ПИ не накладываются технологические ограничения, чтобы представить, как пользователь мог бы достичь своей цели, если бы ПИ мог быть любым. А когда сформулирована модель ПИ, появляется возможность понять ограничения, которые есть, и в соответствии с ними наращивать, или убирать функциональность для достижения поставленных целей. При этом важно помнить, что минимально необходимое количество функций для того, чтобы пользователь достиг своих целей, является оптимальным. Можно находить способы обходить многие предполагаемые ограничения, чтобы решения не оказались производными старых решений.
Также, при проектировании оформления экранных форм следует помнить о принципах информационного дизайна, представленных в [13, 14]. Например, проверять, чтобы формы не содержали лишних графических элементов, создающих визуальный «шум». Такими элементами могут быть рамки, обводки, линии, тонирования без использования которых не нарушается функциональность формы. Легенды и нумерация должны быть неотъемлемой частью сообщения. Вынесения легенды графика или диаграммы отдельно от самого этого представления данных необходимо избегать [9].
Использование параллельного изложения при подаче в ИСУ аналитической информации в таблицах или графических изображениях облегчает задачи сравнения изменений, оценки диапазона вариантов и выбора различий между объектами. Это достигается тем, что поняв принцип размещения данных в одном периоде, благодаря постоянству визуального оформления данных, пользователь будет сосредотачиваться на изменениях в данных, а не на изменениях в разнице форм их представления.
Согласно результатам исследования, проведенного Якобом Нильсеном в 2010 году с помощью инструментов фиксации внимания пользователей на многостраничных представлениях данных, просмотры страниц пользователями распределились следующим образом [11]:
— первый экран: 80,3%;
— данные ниже первого экрана: 19,7%.
Значения в таблицах рекомендуется, сортировать по наименованию или времени [13]. Информация в этом случае отображается в пределах поля зрения, что поддерживает непрерывное визуальное восприятие, за счет того, что пользователю не требуется переключать внимание с одного экрана отчета.
Формы должны проектироваться широкоформатными. О предпочтительности горизонтальных изображений вертикальным можно судить по ряду факторов.
Во-первых, аналогия с горизонтом. Глаз человека от природы наделен способностью обнаружать отклонения от горизонта, и проектировщик должен использовать в своих интересах этот факт. Например, горизонтально протянутые временные ряды более комфортны для человеческого глаза:
Во-вторых, простота маркировки. Легче написать и прочитать слова, которые читаются слева направо в горизонтальной плоскости.
В-третьих, диаграммы основаны на том, что по горизонтальной оси откладываются реквизиты-признаки, а по вертикальной — реквизиты-основания. Следует использовать эту привычную для пользователей аналогию.
На основе псевдофункционального прототипа и спецификации, ПИ передается на программную реализацию.
Доля этапа в общей трудоемкости: 15%.
Этап физической реализации
На основе интерактивного прототипа начинается программная реализация ПИ. Данный этап находится за контуром рассматриваемого авторским исследованием процесса. Отметим лишь, что на данном этапе осуществляется программная реализация, тестирование, отладка и сдача в промышленную эксплуатацию.
После проведения бета-тестирования, ПИ предлагается передавать в тестирование реальными будущими пользователями ИСУ в реальных условиях. Важно, чтобы пользователи выполняли свои типовые задачи наиболее привычным для них образом.
Помимо традиционного тестирования ИСУ на ошибки должно осуществляться тестирование по набору определенных на этапе концептуального моделирования количественных показателей и определение качества результата работ. Также на данном этапе для сдачи в промышленную эксплуатацию должно осуществляться составление пользовательской документации и разработка программ обучения.
Доля этапа в общей трудоемкости: 25%.
Контроль качества
После окончания всех работ и сдачи в промышленную эксплуатацию предлагается выполнять контроль качества путем фиксирования логических ошибок для учета в следующей итерации разработки. Чтобы в следующей версии ПИ внести изменения, необходимые для устранения отклонений от требований, сформированных на функциональном этапе проектирования.
С момента сдачи ИСУ в промышленную эксплуатацию начинается формирования набора функциональности, которая будет реализована в следующей версии ИСУ. Таким образом, реализуется «спираль качества» ИСУ.
Благодаря контролю качества на предыдущих этапах, количество выявляемых в процессе фактической эксплуатации ошибок, как правило, оказывается меньшим, чем при традиционных методах проектирования. Однако они все равно обнаруживаются, и это ставит задачу итеративности разработки для дальнейшего улучшения качества ПИ (добавления новых функций, корректировки и оптимизации существующих функций). А благодаря тому, что метод формирует последовательный процесс проектирования ПИ ИСУ, можно принять этапы в качестве последовательных итераций. Таким образом, ПИ может проходить этапы своего ЖЦ несколько раз при релизах новых версий ИСУ.
При применении субъектно-целевого метода, общий вид интерфейса становится понятен уже на этапе логического проектирования и далее наблюдается последовательное улучшение создаваемого ПИ от этапа к этапу. На начальных стадиях проработки отказ от каких-либо решений или их корректировка не отнимает много ресурсов. Поэтому этапность оказывается полезной при частом изменении требований, что характерно для предприятий аэрокосмического комплекса.
Заключение
Субъектно-целевой метод проектирования ПИ ИСУ Данный представляет собой сочетание методик, некоторые из которых рассмотрены в данной статье.
Преимуществом, субъектно-целевого метода перед существующими подходами является учет того, что процессы разработки ИСУ и ПИ являются проектами. В области управления проектами существуют стандарты методологии проектного управления, например [2] Американского института управления проектами. Данный стандарт является набором описаний процессов управления проектами, сгруппированных по пяти категориям: процессы инициирования; планирования; исполнения; мониторинга и управления; завершающие процессы. С данными фазами управления в терминах проектных методологий явно сопоставлена последовательность этапов но-целевого метода проектирования ПИ.
Кроме того, к достоинствам субъектно-целевого метода можно отнести то, что этапы метода интегрируются в ЖЦ ИСУ ИСУ в целом, с точки зрения разработчика
19
на примере каскадной модели разработки. Это устраняет недостаток существующих подходов, заключающийся в том, что для проектировщиков и руководства не всегда оказывается очевидным на какой стадии ЖЦ ИСУ должно начинаться проектирование или репроектирование ПИ.
В качестве дальнейших направлений исследования автор видит: разработку эффективных прототипов ПИ ИСУ для типовых бизнес-кейсов и размещение их в репозиториях; программную реализацию средств тестирования эффективности ПИ; разработку метрик оценки качества разработанных средств тестирования эффективности ПИ.
Библиографический список
1. ГОСТ 34.003-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения
2. Руководство к своду знаний по управлению проектами (PMBoK-4) — М.: PMI, 2010.
3. Индикаторы информационного общества: 2013, статистический сборник. - М.: НИУ «ВШЭ», 2013.
4. Купер А. Об интерфейсе. Основы проектирования взаимодействия. СПб.: «Символ-Плюс», 2009.
5. Ломов Б. Ф. Основы инженерной психологии — М.: «Высшая школа», 1986.
6. Раскин Дж. Интерфейс: новые направления в проектировании компьютерных систем. СПб.: «Символ-Плюс», 2010.
7. Тидвелл Дж. Разработка пользовательских интерфейсов. СПб.: «Питер», 2011.
8. Головач В. В. Дизайн пользовательского интерфейса. [Электронный ресурс] URL: www.uibook2.usethics.ru (дата обращения 21.06.2012).
9. Материалы сайта «Бюро Артема Горбунова». [Электронный ресурс] URL: www.artgorbunov.ru (дата обращения 14.03.2013).
10. Управление статистики труда, науки, образования и культуры Федеральной службы государственной статистики: Сведения о распределении численности
работников по результатам выборочного обследования организаций Российской Федерации за октябрь 2011 года. [Электронный ресурс] URL: www.gks.ru/bgd/regl/B12_04/IssWWW.exe/Stg/d06/3-plat.htm (дата обращения 20.07.2013).
11. Jakob Nielsen. Scrolling and Attention. March 22, 2010. [Электронный ресурс]
URL: www.nngroup.com/articles/scrolling-and-attention (дата обращения 27.07.2013).
12. Bruce Tognazzini. Tog on Interface. Addison-Wesley, 1992
13. Edward R. Tufte. The Visual Display of Quantitative Information. 2nd edition, Graphics Press, 2011.
14. Edward R. Tufte. Visual Explanations: Images and Quantities, Evidence and Narrative, Graphics Press, 2010.
15. Susan M. Dray. The Importance of Designing Usable Systems. Interactions magazine, January, 1995 (vol. 2, issue 1), pages 17-20.
16. Дегтярев А. В., Моругин П. А., Внедрение методики проектирования взаимодействия в процесс разработки программных продуктов в сфере аэрокосмического производства. Сборник статей НИРС МАИ.
17. Моругин П. А. Историческое развитие подходов к проектированию ПИ. Сборник научных трудов IV международного научно-практического форума «Инновационное развитие российской экономики». М.: «Типография МЭСИ», 2011, МЭСИ.
18. Моругин П. А., Методы определения квалификации целевой аудитории ПИ программных продуктов. Журнал «РИСК: Ресурсы, Информация, Снабжение, Конкуренция» № 4/2012.
