Путеводитель по человеко-компьютерному взаимодействию: разработка с участием конечных пользователей

Posted on by riasevastopol

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

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

Разработка с участием конечных пользователей (End-user development, EUD) оказывает помощь решить эту проблему. EUD — это комплект способов, инструментов и приёмов, каковые разрешают пользователям компьютерных совокупностей, выступающим в качестве неумелых разработчиков ПО, в какой-то момент создавать, изменять либо расширять софтверный продукт.

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

При помощи данной методики конечные пользователи смогут настроить ПО в соответствии со собственными требованиями более шепетильно, чем это вероятно без применения EUD. Более того, потому, что количество конечных пользователей превышает число софтверных разработчиков в соотношении 30 к 1 (рис. 1), то использование EUD расширяет масштабы деятельности по разработке ПО, разрешая принимать участие в ней более широкому кругу людей.

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

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

EUD частично пересекается с двумя подобными концепциями — программированием конечных пользователей и разработкой ПО конечными пользователями. Программирование конечных пользователей (End-user programming, EUP) разрешает пользователям создавать собственные программы. Это подмножество EUD есть самые развитым с позиций исследований и практики, исходя из этого данной концепции внимание будет уделено в последующих разделах статьи.

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

Вторая взаимосвязанная концепция, соприкасающаяся с EUD — это разработка ПО конечными пользователями (end-user software engineering, EUSE). EUSE есть довольно новой подгруппой EUD, оформившейся около десяти лет назад.

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

Прогнозируемые соотношения рабочих мест в Соединенных Штатах по категориям в 2012 году на базе федеральной статистики (обратите внимание, что категории не являются взаимоисключающими): компьютерные пользователи (Computer users) — 90%, пользователи электронных таблиц /баз данных (Spreadsheet/database users) — 55%, люди, каковые говорят, что они «занимаются программированием» (People who say they Do programming) —14%, опытные программисты (Professional programmers) — 3%.

Просматривайте кроме этого: Путеводитель по человеко-компьютерному сотрудничеству: пользовательский его проектирование и опыт

1. Происхождение отрасли EUD

До 1980-х годов большая часть вычислений происходило на мейнфреймах (Mainframe computers) — высокопроизводительных серверных совокупностях, контролируемых опытными разработчиками, трудящимися в отделах информационных совокупностей. Конечные пользователи мало оказывали влияние на функции и форму ПО, трудящегося на мейнфрейме, доступ к которому они в большинстве случаев имели через простые окна терминалов, а руководили им при помощи несложных текстовых команд (рисунок 2). Сотрудники отделов информационных совокупностей редко располагали достаточным числом времени для внедрения и разработки всех программных улучшений, запрошенных пользователями.
EUD появилась из-за сочетания инноваций, воплощенных в автомобилях, известных как «микрокомпьютеры» (термин в конечном счете был заменен на «ПК»). Во-первых, эти автомобили были достаточно недорогими чтобы организации имели возможность дать отдельное устройство каждому пользователю.

Наличие собственных компьютеров обеспечило пользователям возможность изменять настройки ПО электронно-счётной автомобили, не воздействуя на вычислительную среду вторых пользователей. Во-вторых, микрокомпьютеры имели достаточную аппаратную мощность чтобы пользователи имели возможность компилировать (либо трактовать) новый код на таких языках как, к примеру, BASIC.

Это, со своей стороны, обеспечило конечных пользователей инфраструктурой, разрешающих создавать новые приложения. В-третьих, скоро в микрокомпьютерах показались новаторские элементы аппаратного оборудования, такие как мышь и замечательные графические карты, что улучшило юзабилити за счет новых опций, к примеру, графических пользовательских интерфейсов (GUI) и прямого регулирования процессов; эти новшества, со своей стороны, открыли возможности для новых программных средств, намерено созданных для удовлетворения потребностей пользователей.

Электронные таблицы первенствовалиглавной средой программирования для EUD, ставшей вероятной благодаря вышеперечисленным новшествам — начиная с VisiCalc (рисунок 3) и продолжая Lotus 1-2-3 и Excel. Не смотря на то, что пользователи электронных таблиц смогут и не думать о собственной работе как о необычном «программировании», но совокупности электронных таблиц непременно представляют собой среды программирования, потому, что их формулы являются функциональными программами первого порядка.

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

Рисунок 2: терминальный интерфейс пользователя, воображающий собой фиксированное меню, в которое пользователи вводят цифру для указания выбранной опции.

Рисунок 3: электронная таблица Visicalc (около 1980 г.).

Просматривайте кроме этого: Учить либо не учить разработку мобильных приложений?!

2. Настройка

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

На самом базисном уровне настройка предусматривает конкретизацию параметров существующего приложения так, что его приложение изменяется за счет увеличения степени детализации. Скажем, возможно применять GUI программы чтобы указать, какие конкретно функции редактора электронных таблиц должны быть видимы пользователю (рисунок 4) либо как текстовый процессор обязан реагировать на разные входные эти (рисунок 5).

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

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

Так, допустим, объект «Выбор», продемонстрированный на рисунке 6, практически является компонентом , воображающий область текста, которая на данный момент выделена в текстовом процессоре. Компонентно-ориентированная среда разрешает интерпретатору команд манипулировать выделенным текстом в соответствии с руководствами макросов.

Рисунок 4: окно интерфейса программы Микрософт Excel, разрешающее настроить видимость и активацию функций.

Рисунок 5: вкладка GUI в Микрософт Word, служащая для настройки того, как приложение будет обрабатывать клики по гиперссылкам, команды «копировать» и «засунуть», и другие виды пользовательского ввода данных.

Рисунок 6: применение редактора кода для трех макросов Микрософт Word, управляющих обработкой текста (через отдельный экран) и связанных с клавишами стремительного вызова; к примеру, первый макрос имеет единственную инструкцию, показывающую, что приложение должно преобразовать все, что находится в системном буфере обмена, в текстовое представление, а после этого засунуть его в документ.

3. Программирование конечных пользователей (EUP)

Программирование [на стороне] конечных пользователей (EUP) определяется как программирование с целью достижения результата программы, а не для разработки фактически программы. В EUP целью разработчика есть применение на практике программы; данный подход контрастирует с опытным программированием, целью которого есть создание программы для применения вторыми людьми, довольно часто в обмен на финансовую компенсацию.

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

3.1. Визуальное программирование

В средах, поддерживающих визуальные стили программирования (Programming using visual attributes; Visual programming), по крайней мере часть семантики программы выражается через графическое представление. К примеру, сетчатая компоновка ячеек в электронной таблице сопряжена с определенной семантикой; отображает определенную семантику; в частности, ячейки, каковые вертикально либо горизонтально согласованы между собой, являются частью составного объекта, определенного только на базе визуальной компоновки ячеек (к примеру, диапазон B:B ссылается на целый второй столбец в Микрософт Excel). В визуальном языке семантика может гипотетически быть закодирована при помощи множества атрибутов графического представления, таких как положение, цвет, взаимосвязь и размер с другими фигурами.

В качестве еще одного примера на рисунке 7 продемонстрирован визуальный язык, где любая команда, в котором любая инструкция отображается в виде цветного блока, цвет которого показывает, какая как раз команда должна быть выполнена, а форма — какие конкретно другие блоки смогут оказаться затем блока либо перед ним. На рисунке 8 продемонстрирован третий пример визуального языка.

Как и многие другие визуальные языки, инструмент программирования LabView разрешает пользователям перетаскивать эти фигуры, пользуясь графическим интерфейсом. Второй распространенный метод сотрудничества через визуальный язык — это интерактивная форма (рисунок 9). В таком интерфейсе пользователь неимеетвозможности вольно перетаскивать фигуры, а обязан делать выбор из заблаговременно определенных полей.

Рисунок 7: визуальный интерфейс для редактирования трех сценариев анимации мяча в игре Pong. Программист размещает спрайты справа; щелчок по спрайту вызывает его скрипты для редактирования в центре интерфейса. Графические примитивы возможно перетаскивать из панели инструментов слева.

Рисунок 8: язык программирования LabVIEW рекомендован для виртуальных других программ и приборов. Любой квадрат («ящик») обозначает собой вычислительный компонент, а линии отображают потоки данных (подобно проводам, передающим сигналы).

Рисунок 9. Окно интерфейса пользователя Микрософт Word, служащее для стиля, представляющего собой комплект руководств по форматированию, каковые будут использоваться к нескольким выделенным областям документа.

Просматривайте кроме этого: Разработка приложений для детей — это вам не игрушки!

3.2. Программирование на базе демонстрации (PBD)

Программирование при помощи демонстрации (Programming-by-demonstration, PBD), время от времени именуемое программированием на примерах (Programming -by-example) — это способ разработки, в соответствии с которому пользователь демонстрирует логику новой программы, исходя из которой среда программирования предоставляет приложение, репрезентирующее эту логику. Кое-какие PBD-совокупности способны дедуктивно вывести из предложенной логики всю программу всецело, тогда как другие выводят лишь то, что смогут, требуя у пользователя помощи в остальном. Инструменты PBD активно используются для анимации и многих вторых программных ответов.

Одна из неприятностей, которые связаны с PBD, содержится в том, что конечная программа обязана поставляться в форме, разрешающей конечному пользователю контролировать, тестировать и отлаживать это приложение. Благодаря этого PBD довольно часто употребляется в сочетании с визуальными либо текстовыми языками программирования.
К примеру, пользователь, пользуясь PBD, может создать макрос Микрософт Word (как продемонстрировано на рисунке 6). Сперва пользователь обязан надавить кнопку либо элемент меню, указав, что программа обязана начать наблюдение за действиями пользователя. После этого он применяет графический интерфейс для демонстрации желаемого поведения для макроса; к примеру, пользователь может применять серию пунктов меню и диалоговых окон для вставки содержимого системного буфера обмена в виде текста.

Пользователь нажимает кнопку «остановить запись», дабы Микрософт Word прекратила отслеживание действий пользователя. Сейчас приложение формирует макрос, содержащий инструкции VBScript для повторения показанных действий.

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

3.3. Программирование по спецификации

Программирование по спецификации (Programming-by-specification) — это стиль сотрудничества, в котором пользователь обрисовывает желаемую программу, а после этого среда программирования генерирует требуемое приложение. Как и при PBD, сгенерированная программа потом возможно предоставлена пользователю для настройки и просмотра.

К примеру, в 2005 году Хьюго Лью (Hugo Liu) и Генри Либерман (Henry Lieberman) реализовали совокупность, которая приобретает спецификацию, составленную на естественном языке (Natural Language; в лингвистике это язык, применяемый для общения людей и не созданный целенаправленно), и генерирует соответствующую программу, написанную на языке программирования Python. Главным ограничением этого подхода — как и программирования на базе демонстрации — есть то, пользователю сложно угадать, какая программа будет генерироваться из любых конкретных данных.

Помимо этого, как и при с PBD, самом по себе представление конечной программы возможно непростой задачей. К примеру, в случае если вводное сотрудничество выполняется с применением английского, а итог представлен на классическом языке программирования, таком как Python, то конечный пользователь обязан вольно обладать обоими языками.

Вторым ограничением есть то, что инструмент программирования обычно может верно обрабатывать лишь ограниченный диапазон входных данных. Это ограничивает полезность инструмента, и осложняет пользователю предсказание того, будут ли (и как именно) какие-то конкретные входные эти «осознаны» средой программирования (к примеру, вышеупомянутый инструмент Лю и Либермана генерирует игры, и в случае если это так, то какие конкретно как раз?) Дабы сделать границы входного языка более очевидными для пользователей, кое-какие совокупности предоставляют визуальный интерфейс на базе форм (рисунок 10), а не текстовый, тем самым ограничивая спецификации пользователей лишь теми, каковые смогут быть практически обработаны инструментом.

Рисунок 10: визуальная спецификация представления номера телефона; на базе этого описания инструмент генерирует код, что возможно проверен на соответствие конкретным строчкам спецификации.

3.4. Текстовое программирование

Текстовое программирование (Programming with text) есть самый традиционным способом сотрудничества в данной отрасли, и в течении какого-либо времени кое-какие разработчики полагали, что данный стиль программирования не подходит для EUP. Но, как продемонстрировали прошлые примеры, большая часть сред программирования, поддерживающих другие стили сотрудничества, кроме этого в некоей степени предусматривают использование текстового ввода данных.

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

Рисунок 11: применение инструмента программирования CoScripter для редактирования веб-макроса, что «поручает» браузеру искать данные на сайте American Airlines. Исполнение макроса было приостановлено на второй инструкции (слева), которая «приказывает» выделить номер рейса на веб-странице (справа) и заполнить форму, пользуясь файлом конфигурации личной базы данных пользователя (внизу слева).

4. Разработка ПО конечными пользователями (EUSE)

Разработка ПО конечными пользователями (EUSE) определяется как программирование с участием конечных пользователей, включающее систематические и важные действия, направленные на решение проблем качества ПО. Внимание к качеству принципиально важно для EUP, по причине того, что не хорошо написанное ПО может привести к утрата данных, нарушениям безопасности, денежным утратам либо кроме того физическому ущербу, даже в том случае, если ПО создано разработчиками из конечных пользователей.

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

Кое-какие качества, такие как возможность и лёгкость эксплуатации повторного применения, становятся очевидными лишь по окончании того, как программа была написана и пребывала в эксплуатации в течении некоего времени. Так, EUSE объединяет цель EUP, сфокусированную на предоставлении конечным пользователям возможности создавать ПО, с заботой о качестве этого ПО в течении всего жизненного цикла. Данный жизненный цикл включает требования, дизайн, диагностику, повторное использование и отладку кода (в дополнение к фактической реализации, которая уже была обрисована выше в контексте инструментов EUP).

4.1. Требования и дизайн

Требования (Requirements) обрисовывают, что обязана делать программа, а дизайн относится к определению того, как программа обязана решать собственную задачу. К примеру, требование может заключаться в том, что программа должна иметь возможность сортировать перечень почтовых адресов, а ее дизайн может содержать подробный метод сортировки, что будет употребляться на протяжении исполнения работы.
Примеры требований (целей) в EUD включают персонализацию «поведения» приложения либо компьютера, автоматизацию трудоемких задач, исполнение вычислений, каковые тяжело выполнить вручную, передачу информации. Верное исполнение этих требований есть критическим ответственным нюансом с позиций EUSE, потому, что в этом способе делается выговор на уровень качества.

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

Но время от времени конечные пользователи заблаговременно не знают требования и не стремятся к «дизайну» как таковому; они смогут ожидать, что эти вопросы будут уточнены по мере разработки программы. (Опытные разработчики время от времени кроме этого не осведомлены о требованиях заблаговременно, но ожидается, что они предпримут шаги для ответа данной ситуации, такие как применение итеративного способа, дабы составить перечень требований по мере разработки прототипов, а не всецело откажутся от начальной концепции и будут двигаться дальше.) В этом случае конечные пользователи, выступающие в роли разработчиков, смогут перейти конкретно к кодированию, не тратя время на документирование собственных требований либо поиск несоответствий. Связанная с этим обстановка содержится в том, что из-за твёрдой связи EUD с доменом внешние сдвиги в сфере применения ПО смогут привести к изменению требований; к примеру, внесение поправок в правила бухучёта может "настойчиво попросить" от денежного аналитика вычисления отличающихся от начальных данных, что, со своей стороны, может привести к модификации существующей электронной таблицы. Из-за их весьма итеративного характера уточнения к требованиям EUD сравниваются с эластичной методикой разработки (Agile software development).

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

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

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

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

Таковой подход, вероятнее, будет успешным в организационных условиях, где у конечных пользователей-разработчиков имеются коллеги, к каким они смогут обратиться (и где иерархия управления может употребляться, при необходимости, для применения и выполнения проектных обзоров). Еще один вариант воплощения данной идеи, показавшийся сейчас, — это мета-проектирование, коллективный подход, основанный на равноправном сотрудничестве, в рамках которого опытные разработчики прорабатывают кое-какие задачи дизайна, а специалисты в области, в которой трудятся конечные пользователи, оптимизируют разные нюансы использования на практике приложения.

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

Рисунок 12: Обзор процесса работы «критика дизайна», в котором пользователь показывает предлагаемый дизайн/ответ, которое «критик» (справа) разглядывает на базе закодированных знаний об целях применения и отрасли программы смоделированного пользователя. Составляющие процесса: отраслевая экспертиза (Domain expertise), цели (Goals), решение проблемы (Solving problem), предложенное ответ (Proposed solution), критика (Critiquing), знание отрасли (Domain knowledge), модель пользователя (User model), критическая рецензия (Critique).

Просматривайте кроме этого: Как я приспособил собственный Mac под разработку

4.2. Верификация и валидация

Верификация (Verification) и/либо валидация (Validation) — (VV) — охватывают действия, направленные на то, дабы убедиться, что программа делает то, что она обязана делать. Тестирование — самый распространенный подход для VV (кроме того среди опытных разработчиков).

Одно из первых действий, направленных на поддержку верификации и валидации в контексте EUD, было в том, дабы оказать помощь пользователям оценить, содержат ли их программы неточности, поощряя конечных пользователей тестировать стратегически. Быть может, самый созданный подход для тестирования конечных пользователей — это «То, что вы видите, то вы и тестируете» (What You See Is What You какое количество; WYSIWYT), что проводит пользователей через процесс систематического тестирования электронных таблиц.

WYSIWYT применяет стратегию «удивление-объяснение-вознаграждение» (Surprise-Explain-Reward), в которой неожиданности, такие как цветные границы, завлекают внимание пользователей к областям электронной таблицы, каковые нуждаются в тестировании, а подсказки инструментов растолковывают суть цветов и потенциальную приз за применение тестовых устройств (рис. 13). «За кулисами» WYSIWYT применяет формальный критерий достаточности теста, на основании которого делаются умозаключения о элементах формул, подвергшихся тестированиям.

Другой подход к поиску неточностей в программах — это применение особых инструментов программирования для автоматического поиска неточностей на базе типов, размеров либо единиц измерения. Данный подход возможно разглядывать как использование особенного вида утверждений (Assertion; в программировании — предикат, размещенный в программе и показывающий на то, что разработчик имеет в виду данный предикат в этом месте программы неизменно подлинным).

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

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

Рисунок 14: применение функции UCheck для проверки неточностей единиц измерения в электронной таблице.

Просматривайте кроме этого: Юзабилити: минусы и плюсы встроенной валидации форм

4.3. Отладка

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

Утверждения являются еще одну серьёзную классическую технику, которая была приспособлена для применения в EUP: пользователь может засунуть условное выражение в код, и программа обратит внимание на эту точку, в случае если условное выражение будет равняется логическому значению «false» при исполнении команды.

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

К примеру, в то время, когда веб-макрос создается изначально, он может трудиться верно; но при последующем исполнении недопустимые выходные значения смогут появляться или из-за неточности в самом макросе, или из-за трансформаций в содержании и структуре веб-сайтов. Утверждение может уловить такие неточности, каковые появляются, остановить исполнение и привлечь к ним внимание пользователя, дабы не допустить неправильное срабатывание макроса (рисунок 15).

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

Сейчас показался новый класс средств отладки, основанный на способе задавания вопросов, доказавшем собственную эффективность в сфере EUSE. Первым инструментом, применяющим данный подход, был Whyline, чей прототип был создан для среды программирования Alice, разрешающей пользователям программировать анимации. Пользователи запускают исполнение собственной программы, и, отслеживая запрограммированное ими поведение объектов, они нажимают кнопку «Из-за чего».

Так они вызывает меню, содержащее вопросы «из-за чего это случилось» и «из-за чего этого не случилось», организованные в соответствии со структурой видимых 3D-объектов, управляемых программой. В то время, когда пользователь выбирает вопрос, совокупность разбирает историю исполнения программы и генерирует ответ, растолковывающий неточность с позиций событий, случившихся на протяжении исполнения комплекта команд. Подход, представленный Whyline, кроме этого используется для отладки вторых программ.

Рисунок 15: всплывающее окно прося указать, направляться ли изменять веб-макрос Robofox из-за нарушенного утверждения.

Просматривайте кроме этого: Отладка механизмов сплит-тестирования — путь к высокой конверсии

4.4. Повторное применение

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

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

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

5. последствия распространения и Будущее отрасли разработки с участием конечных пользователей

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

К примеру, по мере развертывания эры Web 2.0 исследователи приступили к изучению новых способов помощи пользователям в автоматизации синтеза данных с нескольких веб-сайтов с применением веб-макросов и мэшапов (Mashups). Вторым происходящим на данный момент сдвигом есть скоро растущая роль маленьких мобильных компьютеров, таких как смартфоны; сравнительно не так давно началась работа по предоставлению конечным пользователям возможности создавать мобильные приложения либо другие программы для этих устройств.

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

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

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

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

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

Высоких вам конверсий!

По данным: interaction-design.org

Случайные статьи:

COILS


Подборка похожих статей:

riasevastopol

More Posts