Сообщество пользователей компьютеров быстро увеличивается как в количественном отношении, так и по разнообразию профессий участников. Среди них имеются менеджеры, бухгалтеры, инженеры, домохозяйки, учителя, ученые, работники здравоохранения, страховые агенты и младшие административные сотрудники. Многие из этих людей работают над задачами, которые изменяются на ежегодной, ежемесячной или даже ежедневной основе. Следовательно, их пользовательские потребности в программном обеспечении (ПО) разнообразны, сложны и подвержены частым изменениям. Профессиональные разработчики ПО не имеют возможности непосредственно удовлетворять все эти потребности по причине ограниченности своих знаний и потому, что процессы разработки слишком медленные.
Разработка с участием конечных пользователей (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: окно интерфейса программы Microsoft Excel, позволяющее настроить активацию и видимость функций.
Рисунок 5: вкладка GUI в Microsoft Word, служащая для настройки того, как приложение будет обрабатывать клики по гиперссылкам, команды «копировать» и «вставить», а также другие виды пользовательского ввода данных.
Рисунок 6: использование редактора кода для создания трех макросов Microsoft Word, управляющих обработкой текста (через отдельный экран) и связанных с клавишами быстрого вызова; например, первый макрос имеет единственную инструкцию, указывающую, что приложение должно преобразовать все, что находится в системном буфере обмена, в текстовое представление, а затем вставить его в документ.
3. Программирование конечных пользователей (EUP)
Программирование [на стороне] конечных пользователей (EUP) определяется как программирование для достижения результата программы, а не для разработки собственно программы. В EUP целью разработчика является практическое использование программы; этот подход контрастирует с профессиональным программированием, целью которого является создание программы для использования другими людьми, часто в обмен на денежную компенсацию.
Программы, созданные в рамках EUP, могут быть расширениями существующих приложений (как показано на рисунке 6 выше), или они могут быть новыми программами, работающими обособленно от существующего ПО. Конечные пользователи могут выполнять EUP посредством целого ряда стилей взаимодействия, о чем будет сказано дальше.
3.1. Визуальное программирование
В средах, поддерживающих визуальные стили программирования (Programming using visual attributes; Visual programming), по крайней мере часть семантики программы выражается через графическое представление. Например, сетчатая компоновка ячеек в электронной таблице сопряжена с определенной семантикой; отображает определенную семантику; в частности, ячейки, которые вертикально или горизонтально согласованы друг с другом, являются частью составного объекта, определенного исключительно на основе визуальной компоновки ячеек (например, диапазон B:B ссылается на весь второй столбец в Microsoft Excel). В визуальном языке семантика может гипотетически быть закодирована при помощи множества атрибутов графического представления, таких как положение, цвет, размер и взаимосвязь с другими фигурами.
В качестве еще одного примера на рисунке 7 показан визуальный язык, где каждая команда, в котором каждая инструкция отображается в виде цветного блока, цвет которого указывает, какая именно команда должна быть выполнена, а форма — какие другие блоки могут появляться после этого блока или перед ним. На рисунке 8 показан третий пример визуального языка. Как и многие другие визуальные языки, инструмент программирования LabView позволяет пользователям перетаскивать эти фигуры, пользуясь графическим интерфейсом. Другой распространенный способ взаимодействия через визуальный язык — это интерактивная форма (рисунок 9). В таком интерфейсе пользователь не может свободно перетаскивать фигуры, а должен делать выбор из заранее определенных полей.
Рисунок 7: визуальный интерфейс для редактирования трех сценариев анимации мяча в видеоигре Pong. Программист размещает спрайты справа; щелчок по спрайту вызывает его скрипты для редактирования в центральной части интерфейса. Графические примитивы можно перетаскивать из панели инструментов слева.
Рисунок 8: язык программирования LabVIEW предназначен для создания виртуальных приборов и других программ. Каждый квадрат («ящик») обозначает собой вычислительный компонент, а линии отображают потоки данных (аналогично проводам, передающим сигналы).
Рисунок 9. Окно пользовательского интерфейса Microsoft Word, служащее для создания стиля, представляющего собой набор инструкций по форматированию, которые будут применяться к нескольким выделенным областям документа.
3.2. Программирование на основе демонстрации (PBD)
Программирование посредством демонстрации (Programming-by-demonstration, PBD), иногда называемое программированием на примерах (Programming -by-example) — это метод разработки, согласно которому пользователь демонстрирует логику новой программы, исходя из которой среда программирования предоставляет приложение, репрезентирующее эту логику. Некоторые PBD-системы способны дедуктивно вывести из предложенной логики всю программу полностью, в то время как другие выводят только то, что могут, требуя у пользователя помощи в остальном. Инструменты PBD широко применяются для создания анимации и многих других программных решений.
Одна из проблем, связанных с PBD, заключается в том, что конечная программа должна поставляться в форме, позволяющей конечному пользователю проверять, тестировать и отлаживать это приложение. Вследствие этого PBD часто используется в сочетании с визуальными или текстовыми языками программирования.
Например, пользователь, пользуясь PBD, может создать макрос Microsoft Word (как показано на рисунке 6). Сначала пользователь должен нажать кнопку или элемент меню, указав, что программа должна начать наблюдение за действиями пользователя. Затем он использует графический интерфейс для демонстрации желаемого поведения для макроса; например, пользователь может использовать серию пунктов меню и диалоговых окон для вставки содержимого системного буфера обмена в виде текста. Пользователь нажимает кнопку «остановить запись», чтобы Microsoft 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).
4.2. Верификация и валидация
Верификация (Verification) и/или валидация (Validation) — (V&V) — охватывают действия, направленные на то, чтобы убедиться, что программа выполняет то, что она должна делать. Тестирование — наиболее распространенный подход для V&V (даже среди профессиональных разработчиков). Одно из первых действий, направленных на поддержку верификации и валидации в контексте EUD, заключалось в том, чтобы помочь пользователям оценить, содержат ли их программы ошибки, поощряя конечных пользователей тестировать стратегически. Возможно, наиболее разработанный подход для тестирования конечных пользователей — это «То, что вы видите, то вы и тестируете» (What You See Is What You Test; 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
