Качество информационных систем

Заголовок 1

Заголовок 2

Заголовок 3

П.И.ПАДЕРНО, Е.А.БУРКОВ, Н.А.НАЗАРЕНКО

КАЧЕСТВО ИНФОРМАЦИОННЫХ СИСТЕМ

КАЧЕСТВО ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА

Проблемы оценки качества пользовательского интерфейса

IT проникла во все сфера деятельности, будь то управление экскаватором или пилотирование сверхзвукового истребителя. В настоящее время техническое оснащение современных рабочих мест требует от представителей разных профессий освоения компьютерных программ как основных средств труда. Решаемые группами профессионалов задачи изменяются таким образом, что взаимодействие с компьютером становится неотъемлемой частью их работы. И чем выше степень ответственности оператора, тем больше ложиться на его плечи нагрузка.

Неудачно спроектированных интерфейсов, является источником стресса и психологического дискомфорта в сфере взаимодействия «человек – машина среда». Причины заключаются в следующем: неоптимальное распределение функций между человеком и «машиной», навязывание алгоритма или темпа выполнения трудовой деятельности без учета человеческих возможностей или особенностей решаемых задач, а также неадекватное отображение взаимодействия между пользователем и «машиной». Например, навязывание неправильного алгоритма или темпа выполнения трудовой деятельности оператора может привести к повышению монотонности и, как следствие, утомляемости и сонливости, что отрицательно сказывается не только на эффективности функционирования всей системы, но и на здоровье оператора.

Очень большое значение имеет качество разрабатываемого ПИ ИС. Существует не так много методов определения качества ПИ ИС. Каждый метод имеет свои недостатки и преимущества. К сожалению, нет ни одного универсального метода, который точно определял бы качество исследуемого ПИ.

Как и при любых исследованиях, определение качества ПИ связано с определенными проблемами, основными из которых являются:

• субъективная оценка ПИ;

• узконаправленность оценки ПИ;

• сложность автоматизации.

Субъективная оценка ПИ.При определении качества ПИ используются либо количественные, либо качественные методы оценки. Качественные методы анализа никогда не дают объективной оценки и служат в основном для выявления проблем в существующем ПИ, а также помогают определить удовлетворенность пользователей или ЛПР пользовательским интерфейсом. Количественные методы дают более объективные оценки качества ПИ, но их недостатком является квалификация человека, который применяет тот или иной метод анализа, а также узкая направленность данных методов. Зачастую количественные методы дают оценку по слишком малому числу критериев и накладывают жесткие ограничения на исходные данные. Следовательно, субъективность в большей мере имеет место при выборе критериев для оценки качества ПИ, что может привести к некоторому искажению результатов, как во всем известном мультфильме: «А в попугаях-то я гораздо длиннее...», и в меньшей мере — при обработке результатов.

Узконаправленность оценки ПИ.Как уже отмечалось ранее, большинство методов, используемых при оценке качества ПИ, основаны на небольшом числе критериев для анализа и рассматривают ПИ с какой-то одной точки зрения. Немногочисленные методы, которые рассматривают ПИ со всех сторон и дают комплексную оценку ПИ, очень сложны, требуют больших затрат ресурсов и времени, а также зачастую труднодоступных исходных данных. В связи с этим такие методы практически не используются на практике.

Сложность автоматизации. Большинство методов оценки качества ПИ малоформализуемы, а следовательно, не могут быть автоматизированы полностью. На данный момент ддя исследования качества ПИ программное обеспечение применяется только для частичной автоматизации и служит для облегчения работы исследователей, беря на себя большую часть расчетов и фиксации действий пользователя.

Кроме указанных проблем, связанных в основном с определением методов оценки, существует множество проблем, связанных с применением и реализацией выбранных методов.

А. В. РУДАКОВ, Г. Н. ФЕДОРОВА

ТЕХНОЛОГИЯ РАЗРАБОТКИ

ПРОГРАММНЫХ

ПРОДУКТОВ

Практикум

Заставка

Первым делом — сразу после запуска — ваша программа должна сообщить пользователю, какую именно задачу она собирается решать. Причём информация о решаемой задаче должна быть исчерпывающей. Это особенно важно, если в постановке задачи имеются серьёзные ограничения, о которых пользователя нужно уведомить сразу же.

Информационная часть интерфейса, появляющаяся на экране сразу после запуска программы, называется заставкой. Заставка может содержать:

o название программы;

o пояснение (краткую или подробную информацию о решаемой задаче);

o информацию об авторе(–ах) программы;

o номер версии программы;

o и т. п.

Заставка может состоять как из отдельного экрана, который исчезает после нажатия произвольной клавиши (его сменяет рабочая область программы), так и лишь из одной строки, которая остаётся на экране до конца работы программы (или пока её не вытеснит объёмный вывод).

Ввод информации

Пользователь может вводить информацию двумя способами: свободным вводом или выбором из предоставленных возможностей.

Приглашения

Каждый раз, когда программа ждёт свободного ввода от пользователя, она должна сообщать об этом, выводя на экран приглашение к вводу.

Приглашение вида «Введите х:» невозможно считать удовлетворительным, поскольку оно не содержит никакой информации об ожидаемых данных. Хорошее приглашение должно сообщать пользователю, что именно от него хотят получить в данный момент: тип, формат и размер вводимых данных.

Например:

Введите координаты центра окружности (два целых числа -10000 <= x, y <= 10000):

Вывод информации

Не следует думать, что вывод информации происходит только в конце работы программы. Некоторые программные комплексы реального времени в принципе могут работать годами без перезагрузки. Поэтому операторы вывода должны информировать пользователя о текущем состоянии процесса контроля или о промежуточных вычислениях.

Каждый раз, когда пользователь должен что–то ввести, этому предшествует или вывод приглашения или должна существовать удобная форма ввода данных. Каждый раз, когда программа приступает к выполнению длительных операций (загрузка данных, синхронизация, печать, большой объем вычислений), она должна сообщать об этом пользователю — чтобы исключить вероятность прерывания «по окончании терпения», а ещё лучше, если на экране будет находиться какой–нибудь индикатор процесса, отображающий текущее «состояние дел». (этот индикатор мы рассмотрим позднее более внимательно).

Какими же должны быть сообщения программы, выводимые на экран? В любом случае они обязаны быть доброжелательными и вежливыми. И, кроме того:

o Адекватными выполняемой задаче

Это означает, что терминология сообщений должна соответствовать той области, к которой относится задача.

o Учитывающими контингент пользователей, на которых рассчитана программа

Например, если вы пишете обучающую программу для младших школьников, то в пояснениях не должно быть сложных предложений и «заумных» слов. А если вы создаёте игру для своих сверстников, то в её сообщениях возможен и молодёжный сленг (однако мы настоятельно советуем избегать табуированной лексики, даже иноязычной).

o Логично сгруппированными

Все запросы данных, относящихся к одному и тому же логическому блоку, стоит объединять и на экране. Например, если необходимо ввести информацию по нескольким налогоплательщикам, то не стоит сначала запрашивать все фамилии, а затем только номера банковских счетов.

o Информативными

Программа, как вы помните, должна сообщать результаты своей работы. Однако «голый» вывод неприемлем: результаты обязательно должны сопровождаться исчерпывающими пояснениями. Кроме того, помимо окончательного результата, нужно выводить и промежуточные результаты — по окончании обработки каждого логически самостоятельного крупного блока. Если же работа программы оказывается прерванной из–за какой–либо ошибки, сообщение о её причинах должно появиться на экране.

o Эргономичными

Понятие эргономичность включает в себя минимизацию умственных и физических усилий пользователя: например, если есть возможность заменить ввод выбором, это нужно делать. Следует стремиться к кратким сообщениям — но, разумеется, не за счёт потери части их смысла! Цветовое оформление также не должно становиться причиной дискомфорта или ошибок пользователя: например, не стоит выводить сообщение о неправильном вводе зелёным цветом, а сообщение об успешно пройденном тесте — красным. (но об этом позднее)

Настройки по умолчанию в ПО

Проектируем время

Компьютерный дизайн -- > apple -- > мышь -- > верхнее меню -- > макинтош

Интерфейс пользователя не должен быть похожим на компьютерную программу (принцип прозрачности).

Правило 7-ми

Правило 20/80

Производительность может измеряться числом нажатий клавиш.

Программирование является индустрией обслуживания.

Заголовок 1

Заголовок 2

Заголовок 3

П.И.ПАДЕРНО, Е.А.БУРКОВ, Н.А.НАЗАРЕНКО

КАЧЕСТВО ИНФОРМАЦИОННЫХ СИСТЕМ