Итак, уважаемый читатель, как это было описано в первой части данной статьи, «на входе» имеем набор идей, весьма далёких от уровня software functional requirements и заказчика (его представителя, ответственное лицо и т. д.), не склонного к кропотливой работе над выявлением требований и искренне полагающего, что его участие в разработке должно ограничивается лишь оценкой соответствия конечного продукта собственным переменчивым желаниям.
Требуется из абстрактных идей и разрозненных бизнес-артефактов получить конкретные функциональные требования к ПО, на основании которых можно будет проектировать архитектуру и писать код, при этом, не упуская скрытую функциональность и не перегружая заказчика утомительным чтением спецификаций и сценариев, а также бесконечными опросами встречами и интервью.
Используем для этого методологию реверсивного анализа требований на основе динамических html-прототипов, создаваемых с помощью Axure RP 7.0.
В самых общих чертах процесс можно представить следующим образом:
- Выявляем пользователей и высокоуровневые пользовательские требования, записываем их в форме кратких сценариев или user story и согласуем их с заказчиком и располагаем в порядке их приоритета.
- В Axure RP создаём проект, в котором предусматриваем страницы для ролевого разграничения пользователей (Рис. 1) и навигации по функциональным сервисам (Рис. 2).
- Реализуем очередное по списку требование на отдельной странице прототипа, добиваясь по возможности полной имитации его функционирования. Для этого используем виджеты, их библиотеки (в том числе собственные), применяем динамические панели, вводим глобальные и временные переменные, описываем условия и события. При этом отрабатываем как типовые, так и альтернативные потоки взаимодействия.
- Тестируем страницу в html (меню “Publish-Preview“ в Axure RP Pro 7.0), оцениваем полноту реализации функционала, возможности ошибочных действий пользователя, удобство и интуитивность интерфейса.
- При необходимости вносим изменения в базовую функциональность, добавляем в прототип функциональные элементы, исключающие ошибочные действия пользователей и улучшающие UX, а также вводим необходимые текстовые инструкции и пояснения.
- Генерируем проект в «облаке» Axure RP под уникальным именем, посылаем ссылку заказчику и предлагаем протестировать разработанную часть функционала. В случае, если сценарий взаимодействия сложный и интуитивно не понятный пользователю, то прилагаем видео-инструкцию (в виде файла .mp4, созданного, например, с помощью продукта Snagit), или краткую инструкцию, выполненную с помощью стандартных средств MS Office.
- Общаемся с заинтересованными сторонами (Skype, телефон) и по результатам вносим в прототип необходимые изменения, дополняем UML-диаграммами, после чего повторно генерируем html-страницы и переходим к разработке следующего по списку сервиса.
- По завершению прототипирования создаём общую для всего проекта спецификацию функциональных и нефункциональных требований.
Примечание: понятие функциональный сервис в данном случае – это то, что должна делать программная система во взаимодействии с пользователем с целью достижения значимого для него результата. Другими словами, это вариант использования (Use Case) по определению Айвара Якобсона (один из создателей языка UML, который ввел это понятие в 1986 году).
Рис. 1 - Примеры страниц с разграничением доступа
Рис. 2 — Пример страницы функциональных сервисов
Теперь подробнее о функциях, отражаемых в прототипах, касательно представленной в первой части статьи иерархии (Рис.2).
Предположение: в прототипе можно за редким исключением имитировать всё, что будет отражается на экранах программных приложений, включая мобильные.
Имитируются функции front-end-уровней: списки вносятся, изменяются, удаляются, сортируются, выделяются строки, производятся расчёты, обеспечиваются переходы по условиям, обеспечивается доступность и видимость элементов интерфейса, показываются и убираются комментарии и т.д. Основной механизм для создания имитации – динамические панели, отличающие Axure RP от аналогичных средств, позволяющих создавать вайрфреймы, мокапы и прототипы с ограниченной динамикой.
Функции, отнесённые к back-end тоже могут имитироваться в прототипе, если их результат отражается на экране пользователя. Это может делаться с помощью искусственных приёмов, не соответствующих реальным условиям. Например, в проекте «Шихтовка металлкомпонентов» [7] для получения веса компонента, находящегося на кране, необходимо кликнуть в текстовом поле «Вес на кране» (Рис. 3), после чего произойдёт имитация получения протокола через порт RS232 и в указанном поле появится заранее внесённое в прототип значение. Имитация запроса и получения добавок горения, а также действий системы с ними связанных организована с помощью внутреннего таймера: кликаем кнопками запросов, через определённое, установленное в прототипе время видим реакцию системы, при этом никакие протоколы не посылаются и не принимаются.
Рис. 3 - Пример имитации работы приложения «Шихтовка МК»
Достоинства методики
- Спецификация требований создаётся на основе действующего протестированного и согласованного с заказчиком прототипа, функционал которого гораздо ближе к реальной программной системе, чем любая написанная до начала разработки спецификация или визуальная модель.
- Обеспечивается необходимая и достаточная полнота функциональных требований. Выявляются скрытые функции, а также оценивается необходимость ввода сервисных функций, связанных с удобством использования и исключением ошибок пользователей.
- Заказчик может заранее и без больших затрат оценить достоинства и недостатки программной системы и эффективность достижения поставленных им бизнес-целей.
- Разработка производится итерационно при постоянном взаимодействии и под контролем заказчика, который в любое удобное для него время может тестировать прототип, постоянно находящийся в «облаке».
Заключение
Важный вопрос, который, волнует всех, мужественно выдержавших до этого момента: сколько времени потребуется на создание прототипа и будут ли оправданы затраты на его разработку?
Всё зависит от умения, опыта работы в Axure RP и от наработанных библиотек. В начале её изучения, более-менее быстро делаются вайрфреймы и навигационная динамика, но по мере накопления опыта в скриптах, создании и использовании переменных, в управлении динамическими панелями, имитация занимает всё меньше времени и значительно выигрывает по сравнению с кодированием, что особенно существенно при многочисленных изменениях в функциональности.
При очевидных преимуществах методики, время, затраченное на разработку требований, в целом увеличивается, но не на столько, чтобы отказываться от возможностей динамических прототипов. Подготовка статических вайрфреймов в комплекте со сценариями занимает не на много меньше времени, но главное, не позволяет в полной мере выявить скрытые функции, обеспечивающие бизнес-логику, а также обеспечить предотвращение ошибок и удобство работы пользователей. Кроме того, заказчики предпочитают работать с функционирующим продуктом, чем с подробными описаниями его функционирования. Многие из них с удовольствием готовы тестировать, нажимая на кнопки, внося данные, а затем визуально оценивать результат, чем внимательно вчитываться в тексты и включать своё воображение.
Перед началом работ с заказчиком можно оформить предварительный договор на разработку действующего прототипа и спецификаций требований. Используя прототип, он может решить на сколько ему полезен тот или иной функционал (в соответствии с моделью Нориаки Кано [8]), а разработчики смогут более точно оценить сроки и стоимость проекта.
Многие аналитики возразят, что вторжение в область UX не является их «епархией», но как тогда относиться к тому, что одним из требований к Scrum-командам, является кросс-функциональные возможности их участников? Следует заметить, что только очень крупные ИТ-фирмы могут позволить себе узкопрофессиональный персонал, чем мельче фирма-разработчик, тем острее потребность в кросс-функциональных специалистах.
Описанный выше процесс разработки прототипа отдалённо напоминает Scrum и тем, что заказчик может ежедневно контролировать разработку и оперативно вносить необходимые изменения. При этом не требуются ежедневные standup’ы в строго определённое время, прототип, расположенный в «облаке» может быть доступен в любое удобное время и даже с мобильного устройства.
При необходимости, Axure RP позволяет сгенерировать подобие спецификации в формате MS Word. Этот документ может использоваться, но потребует значительной переработки.
Большим плюсом является ещё то, что найденные решения удобно сохранять в библиотеке для дальнейшего использования в других проектах. В библиотеке должны храниться исходные файлы формата Axure RP и их html-прототипы, наподобие данного примера [9].
Использование готовых библиотек существенно ускорит процесс создания динамических прототипов.
Буду рад ответить на вопросы и принять участие в обсуждении материалов статьи.
Все желающие попробовать методику реверсивного анализа с использованием динамических прототипов на небольших практических примерах, приглашаются принять участие в online-вебинарах. Подробности на http://www.webmax.by/vebinary/, условия и запись на http://fy7qtu.axshare.com/#c=2
Ссылки на источники:
- Учебная программа http://www.webmax.by/docs/shicht/home.html
- Модель Н. Кано http://www.fdfgroup.ru/?id=281
- Пример html-прототипа http://ygz4b5.axshare.com/#c=2.
Автор:
Николай Киреев, старший преподаватель ИИТ БГУИР, индивидуальный предприниматель (разработка ПО, студия WebMax.BY), руководитель проектов, аналитик (freelancer)
Skype: nousy123,
e-Mail: nousy@mail.ru
Действие от обратного часто имеет свои плюсы. Спасибо за статью!
Николай, спасибо за толковую статью. Смущает только понятие «реверсивности» в данном контексте. Под реверсивным анализом требований всегда понимал извлечение требований из некоего работающего артефакта, в котором эти требования уже тем или иным образом заложены. В кейсе же, который вы описали, выходит следующая ситуация: аналитик в любом случае делает прототип на основе извлеченных или предположенных им самим требований. Далее, после получения обратной связи от ЗЛ, ему остается только зафиксировать в документации то же, что он сам вложил в прототип, с некими полученными уточнениями. Согласитесь, есть отличие от ситуации, когда от клиента приходит работающая неизвестная нашему аналитику система, которую надо постигать — вот в этом имхо реверсивность. В данном же случае это получается обычный типовой процесс уточнения / извлечения требований из клиента с использованием техник, которые клиенту заходят легче, чем чтение текста.
Прежде всего, большое спасибо Герману и Алесе за позитивную оценку моей статьи!
Постараюсь пояснить обоснованность применения термина «реверсивность». Я согласен с приведённым Германом определением реверсивного анализа требований, позволив себе некоторое уточнение — это извлечение (конкретизация) функциональных требований к программной системе из её действующей реализации. Под действующей реализацией понимается сама система (её базовый функционал или предыдущая/щие версия, выполненные в программном коде), либо её действующий прототип, созданный с помощью методологий RAD (rapid application development), к которым относят и Axure.
Тогда «традиционный» анализ можно определить, как извлечение функциональных требований непосредственно из контекста предметной области.
Отличие методик состоит в том, что в «традиционном» подходе мы извлекаем функциональные требования «на бумаге», конкретизируя и детализируя непосредственно контекст предметной области (не представляя, как они изменятся в реальной системе), согласуя созданные нами бумаги (а не систему!) с заказчиком, а во втором случае мы дополняем (наращиваем), изменяем и приводим в соответствие выявленный и предложенный нами базовый функционал, основываясь на результатах его тестирования пользователями и только после этого фиксируем спецификации на бумаге.
Каждый из этих подходов обладает своими достоинствами и недостатками, а также ограничен своей областью применения. Область применения реверсивного анализа, это случаи, когда непосредственное выявление функциональных требований из контекста предметной области затруднено или невозможно по различным причинам.
Реверсивный анализ (как и Scrum тоже!) не следует бездумно применять в каждом проекте вместо «традиционного» процесса разработки, это не «панацея» и не альтернатива, а скорее осознанная необходимость, за которую приходится платить увеличением объёмов работ.
В подавляющем большинстве случаев приходится многократно изменять прототип, постоянно тестируя результаты, применяя как быстрое тестирование (непосредственно из Axure), так и тестирование всеми заинтересованными лицами выставленного в облаке html-файла. Часто пользователям требуется некоторое время, чтобы «поиграться» с прототипом и только потом, у них может возникнуть «прорывная идея», которую надо будет обязательно реализовать.
Это не простое фиксирование в документации вложенных в прототип собственных решений, а скрупулёзная и трудоёмкая разработка функциональных требований, связанных как с бизнес-логикой, так и с UX, в тесном взаимодействии и при непосредственном участии заказчика (пользователей).
Большое спасибо за вопросы, буду рад продолжению дискуссии.
В итоге получаем:
1) Вариант 1 (предложенный автором статьи):
— тратим время на сбор и анализ требований заказчика;
— тратим время на проектирование интерфейсов;
— тратим время на составление ТЗ в соответствии с требованиями заказчика и разработанными интерфейсами.
2) Вариант 2:
— тратим время на сбор и анализ требований заказчика;
— тратим время на составление ТЗ в соответствии с требованиями заказчика.
Вопрос — какой вариант более быстрый?
P.S. Сам применял предлагаемый подход в нескольких проектах, но обусловлено это было одним — нежелание заказчика читать разработанное ТЗ (именно читать, а вот относительно просмотра красивых картинок заказчик противопоказаний не имел).
P.S.S. Что будет, если команда разработчиков не сможет или не захочет сделать интерфейс таким, каким он согласован заказчиком (это может касаться как программистов, так и UI разработчиков).
Большое спасибо за комментарий!
По поводу заданного мне вопроса, ответ следует из текста статьи и предыдущего моего комментария. В статье написано, что время, затраченное на разработку требований, в целом увеличивается, а в комментарии я тоже уже писал, что это необходимость, за которую приходится платить увеличением объёмов работ. Таким образом следует, что разработка функциональных требований «на бумаге» будет бесспорно быстрее, чем путём создания и тестирования прототипа.
Вопрос не в убыстрении процесса разработки требований, а в том, что делать если функциональная спецификация не может быть определена до начала работ, если она будет изменяться в процессе разработки ПО, если её окончательный вариант, соответствующий пользовательским требованиям (да, и сами пользовательские требования!), может быть выяснен только после тестирования пользователями готового программного продукта?
Во-вторых, уважаемый коллега, я хотел бы обратить ваше внимание на то, что цель данной методики не есть создание красивых картинок для просмотра заказчиком и даже совсем не проектирование интерфейсов. Цель – выяснение функциональности системы путем по возможности быстрого создания прототипов отдельных функциональных модулей (функциональных сервисов) и их тестирования со стороны пользователей. Естественно, т.к. прототипы выставлены в облаке, то к ним имеют доступ и остальные разработчики, с которыми их тоже следует согласовать. Поэтому исключается ситуация, описанная в самом последнем абзаце вашего комментария.
Единственное, что я хотел бы еще тут добавить, это относительно UX. В данной методике аналитик должен частично выполнять работу специалиста по UX (но, ни в коем случае не дизайнера интерфейсов!). Приходится следовать некоторым правилам, по крайней мере 10 рекомендациям от Якоба Нильсена (ссылка на них представлена в первой части моей статьи), кроме того должны быть проработаны сценарии, исключающие ошибки со стороны пользователей. Это тоже расширяет функционал системы, но аналитик в данном случае, работает в рамках отдельных функциональных сервисов, а не в рамках всего проекта.
Буду рад, если этот комментарий покажется вам интересным.
Дзякуй. Спадабалась! Канструктыуная схема.
Николай, что аналитик должен в первую очередь заниматься сбором требований, их анализом и систематизацией, а не разработкой прототипов и UX.
Вы пишите, что «вопрос не в убыстрении процесса разработки требований, а в том, что»:
1) «Функциональная спецификация не может быть определена до начала работ» — единственно, что мне приходит на ум, это либо создание нового продукта (аналогов которого нет на рынке) или отсутствие у заказчика соответствующих специалистов со знанием предметной области (или то и другое). Например, создание системы управления полетом ракеты (подсмотреть негде да и специалистов, которые готовы рассказать все нюансы, не так много);
2) «Если она (прим.: функциональная спецификация) будет изменяться в процессе разработки ПО» — ну вообще то, так все разработки и ведутся (сегодня реализовали одно, завтра другое, затрагивающее, в том числе ранее реализованное). Зачем здесь прототипирование — не понятно;
3) «Если её (прим.: функциональная спецификация) окончательный вариант, соответствующий пользовательским требованиям (да, и сами пользовательские требования!), может быть выяснен только после тестирования пользователями готового программного продукта» — ну как бы вот этим и должен заниматься аналитик (ходить и лелеять пользователей, по грамму вытягивая из них необходимые сведения, разрабатывая функциональную спецификацию). И сможете ли вы успешно сдать работы, если у вас не будет возможности оспорить требования пользователей (не забываем, что у проекта есть как доброжелатели со стороны заказчика, так и другие, мечтающие «подставить подножку»), используя для этого ранее разработанную функциональную спецификацию.
Мне кажется, ваш метод можно использовать:
— в небольших по трудоемкости проектах (не готов указать конкретные цифры);
— в проектах, где нужен а-ля НИОКР (см. мои комментарии к пункту 1).
Большое спасибо за комментарий. Извините за задержку с ответом.
По поводу аналитика – участника разработки ПО. Я бы написал следующее: он должен заниматься в первую тем, что в данных конкретных условиях (продукт, проект, процесс, персонал), позволит команде в целом ускорить разработку ПО, при гарантированном сохранении его качества. Если для этого будет достаточно SRS, то делаем SRS, если требования легче выяснить, используя прототип, то делаем прототип.
Естественно, выявление требований по прототипу следует использовать далеко не для всех случаев. Это оправдано:
при создании нового или специфического (для условий данного заказчика) продукта. У меня масса таких примеров, например, различного рода калькуляторы объемов и трудоемкости работ, зависящие от особенностей техпроцесса и оборудования;
в случаях, когда из пользовательских требований затруднительно получить конкретные функциональные требования к ПО (как исключение, бывают случаи, что и пользовательские требования не всегда очевидны заказчику). Можно бесконечно задавать вопросы заказчику, брать массу интервью и использовать разные для этого техники, можно исписать горы бумаги и затратить массу времени (сложная аналитическая работа!), однако, в большинстве таких случаев легче создать функционирующий прототип. При этом не следует прототипировать полностью весь функционал, достаточно только тот, что вызывает большинство вопросов.
Не следует прототипировать то, что полностью понятно и имеет близкие аналоги. Делать, например, прототип интернет-магазина совершенно бесполезно, разве только заказчик захочет реализовать в нём какой-то уникальный сервис.
Метод эффективно использовать не столько «в небольших по трудоемкости проектах», сколько в небольших по численности командах, например, в скрам-бригадах, а уж объёмы проекта могут быть любыми.
очень мелкие примеры страниц в первой части статьи, хотелось бы крупнее