Эскизное проектирование в программировании

Конвейерная сборка автомобиля Ford Model T, организованная Генри Фордом, в свое время вдохновила на перемены всю автомобильную индустрию. Многочисленные попытки применить похожие идеи предпринимались и в индустрии ПО. Принцип сборочного конвейера общеизвестен, а вот о том, как именно Форд пришел к выпуску Model T, знают не все. Между 1892 годом и образованием компании Ford Motor в 1903-м, в период работы в Edison Illuminating, Форд построил больше двух десятков автомобилей, а в течение пяти лет после создания собственной компании спроектировал и выпустил в продажу восемь моделей: A, B, C, F, K, N, R и S — и лишь после этого остановился на Model T. Еще 11 «пропущенных» букв были отданы прототипам. Сам Форд подытожил этот опыт так: «Серийное производство следует начинать только после того, как будет создан лучший из возможных продуктов. Разумеется, это не означает, что идеальный продукт уже не стоит модифицировать. Но, на мой взгляд, в конечном счете для вас будет выгоднее, если вы не станете выпускать вещь, пока не будете полностью уверены в том, что ее удобство, конструкция и материалы — на высоте. Если ваши исследования не дают вам такой уверенности, продолжайте поиск, пока ее не будет. Мы не пытались налаживать серьезное производство, пока не создали серьезный продукт».

С тех пор автомобильная индустрия претерпела большие изменения, но философия Форда все еще в силе — например, согласно принципу, принятому в Toyota, решения необходимо выполнять быстро, но принимать медленно, путем согласования и после рассмотрения всех возможных вариантов. Бил Бакстон в книге “Sketching User Experiences: Getting the Design Right and the Right Design”, отмечает, что стадия проектирования нового автомобиля начинается с обширного исследования, финалом которого становится изготовление модели из промышленного пластилина в натуральную величину; при этом исследовательский этап обходится больше чем в четверть миллиона долларов. Лишь после того, как новый замысел получит безукоризненную форму, бизнес-план и инженерный план, проект получает зеленый свет. Затем обычно уходит около года на проектирование, после чего можно начинать производство.

Под влиянием применяемых в автомобильной индустрии принципов перехода от идей к производству был придуман процесс эскизного проектирования («скетчификации», sketchifying), помогающий участникам предложить и рассмотреть как можно больше альтернативных идей, прежде чем принять решение о начале проектирования. Эскизное проектирование ПО объединяет концепцию эскизов, создаваемых с помощью автоматизированных инструментов, с традиционными методами программной инженерии. В поддержку метода и для его исследования был предложен Sketchlet — гибкий инструментарий на Java, позволяющий команде разработчиков работать с новыми программными и аппаратными технологиями, изучать их возможности и создавать действующие «наброски» системы, называемые скетчлетами (sketchlets).

Инновации и программная инженерия

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

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

Эскизное проектирование

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

Метод эскизного проектирования

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

• Главная задача дизайнера — исследование задачи и ее потенциальных решений, поиск ответа на вопрос о том, что именно нужно создать.
• Эта исследовательская деятельность является эвристической, творческой и основанной на пробах и ошибках, а не инкрементальной и итеративной. Дизайнер предлагает много идей, большинство из которых будут отвергнуты. Но этот процесс приносит важные выводы и стимулирует выработку инновационных идей. Выводы и идеи — главный итог.
• Исследовательская деятельность не беспорядочна: она рациональна и систематизирована.
• Исследовательский этап характеризуется комплексным подходом, позволяющим дизайнерам судить о взаимосвязях между проблемами пользователей, возможностями ПО и оборудования и общей динамикой взаимодействия человека с компьютером. На идеи в сценарии-примере влияет не только ПО, но также человеческие факторы и проблемы, связанные с внутренним устройством автомобиля.
• Изыскания обеспечат раннее знакомство пользователей с простыми, но функциональными «набросками» программного продукта — скетчлетами.
• Работая с реальными системами, такими как автосимулятор, система диагностики автомобиля и веб-сервисы, дизайнер выясняет возможности и ограничения программных технологий, что помогает ему создавать более реалистичные концептуальные предложения.

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

Инструменты эскизного проектирования

Инструментарий Sketchlet содержит элементы традиционного технического эскизного проектирования, программирования, оппортунистической разработки (интеграции в разрабатываемую систему не рассчитанных на это сторонних компонентов) и разработки, осуществляемой с участием конечных пользователей. Sketchlet — это развитие проекта Sketchify (sketchify.sourceforge.net), в рамках которого изучались возможные улучшения ранних этапов проектирования и процесса обучения дизайнеров пользовательских интерфейсов. Назначение Sketchlet:

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

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

Первые итоги

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

Проект Connect & Drive. Исследователи с помощью Sketchlet тестировали идеи для программной системы адаптивного круиз-контроля на базе взаимодействия через Wi-Fi автомобиля и дорожной инфраструктуры.

Проект  Persuasive  Technology, Allocation of Control, and Social Values. Роль Sketchlet здесь была примерно та же, что в Connect & Drive: исследователи перебирали идеи программных технологий, подталкивающих людей к использованию интеллектуальных бортовых систем автомобиля.

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

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

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

Рис. 1. Сравнение классической схемы взаимодействия между дизайнерами и инженерами со схемой эскизного проектирования

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

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

Преимущества и связь с другими подходами

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

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

Связь с прототипированием и конструированием

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

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

Рис. 2. Идеализированное изображение отношений между эскизным проектированием, прототипированием и инженерным проектированием

Взаимоотношения с другими инструментами

Принципы эскизного проектирования можно было бы реализовать и средствами других инструментов, помимо Sketchlet. Но многие из таких инструментов не вполне для этого годятся, так как не рассчитаны на свободные исследования, выполняемые неинженерами. Например, в приведенном сценарии-примере можно было бы пользоваться языками программирования Java, C#, C++ или инструментариями создания высокоинтерактивных приложений, такими как Flash и Processing. Но программирование потребовало бы слишком больших усилий, ограничивая свободу генерации новых идей.

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

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

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

Сам по себе инструментарий Sketchlet является дополнением к имеющимся средствам, а не заменяет их. В ряде случаев дизайнеры пользовательских инструментов применяли Sketchlet совместно с другими инструментами. Например, система Max MSP использовалась для обработки сигналов и создания звуковых эффектов, а Sketchlet — для связи с датчиками и визуализации.

***

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

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

Желько Обренович (obren@acm.org) — технический консультант, компания Software Improvement Group.