QA (rus)

Свежая подборка курсов

За последние пол года я хотел бы отметить следующие, как мне кажется, важные курсы (по крайне мере для меня):

И на закуску – курс coursera.org по алгоритмам (большое спасибо за него моим друзьям): https://class.coursera.org/algs4partI-006

А также в очередной раз напоминаю о существовании такого инструмента прототипирования как Balsamiq и Visio (недавно опять пробовал работать в Axure и снова не впечатлился)

Всем добра!

Advertisements
Standard
Requirement management (rus)

Курс: Разработка и управление требованиями к ПО

С сентября по февраль с Александром Байкиным будем вести онлайн-курс “Разработка и управление требованиями к ПО”.

Подробности: https://www.webursitet.ru/product/kratkiy-kurs-sistemnogo-analiza.html

Вводный обзорный вебинар курса состоится в четверг, 5 сентября. Участие бесплатное, регистрация здесь: https://www4.gotomeeting.com/register/338126063

Standard
Requirement management (rus)

Программа для генерации постановок на простые экранные формы

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

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

Сейчас я могу довольно легко принимать запросы на изменения, идеи и т.п.

Интерфейс выглядит так:

1. Окно списка проектов и оконных форм

List of projects and frames

2. Окно списка полей и вложенных таблиц экранной формы

List of fields in frame

3. Окно отображаемых колонок из вложенной таблицы

FramesInFrame

4. Окно настройки отдельного поля

Field properties

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

Standard
Requirement management (rus)

Генерация постановок на экранные формы (идея)

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

Не секрет, что у каждой компании есть некий свой стандарт ведения документации, который,  как правило, является той или иной модификацией RUP, IEEE или ГОСТ. То есть, при ведении такого хранилища, необходимы универсальные шаблоны, вероятность создания которых обратно пропорциональна количеству участников. Каким образом можно решить эту проблему?

Я прихожу к выводу, что есть один и только один выход – создание средства генерации данных постановок. Ограничусь только одной, зато самой широкой областью – экранные формы. За отправную точку можно было бы взять IBM Web Content Manager (WCM) – примерно часа хватит аналитику для освоения этого инструмента в части создания экранных форм, содержащих в себе наборы полей и правила их заполнения (обязательность, тип, длинна и т.п.).

Дабы не быть голословным я приведу скриншот (это одно поле экранной формы в режиме настройки):

WCM

Таким образом, аналитику достаточно указать: каким образом и в каких областях страниц эти данные следует отображать. Далее аналитик может приступать к следующей задаче (вероятно – описания всех его настроек для включения в документацию). Разработчик будет выполнять в 2-3 раза меньшей работы, так как все поля уже созданы и настроены за него. Этот аспект я не буду рассматривать, но при использовании IBM WCM рабочий процесс я бы строил именно описанным выше способом.

Таким образом, если бы WCM позволял ещё и сгенерировать документацию, то он бы был моим любимым инструментом для создания постановок на экранные формы. Беда в том, что WCM:

  1. Слишком дорогой, чтобы покупать его на «непортальные» проекты.
  2. Может работать только с экранными формами (этот пункт можно было бы и удалить, учитывая описанные мною рамки).

Доменная модель

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

  • Создавать экранные формы/web-страницы
  • Добавлять поля и табличные части
  • Добавлять атрибуты полей
  • Добавлять проверки
  • Добавлять формулы расчета полей
  • Генерировать текстовые описания и скриншоты

Данный генератор должен быть доступен из web, реагировать на действия пользователя секунды за 3, а в идеале хранить все созданные экранные формы в БД или в виде XML.

Я вижу следующую доменную модель:

WCM

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

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

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

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

Этап 1

На первом этапе необходима система, которая позволяла бы пользователю создать web-форму, заполнить её полями и генерировать на её основании документ в формате html или doc.

При этом все атрибуты являются преднастроенными.

Пока мой замыленный код выглядит так:

alexey kiselev code

Standard
Requirement management (rus)

Статья “Предпосылки к внедрению Devprom ALM как средства управления требованиями”

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

Традиционный скрин:

2013-06-25_103933

Standard
Requirement management (rus)

Статья “Особенности проведения оценки трудозатрат аналитиком”

Ура, вышла моя и Екатерины Душечкиной статья. Мы написали её более месяца назад и вот она увидела свет на странице Белорусского сообщества бизнес и системных аналитиков.

Как всегда, я прикладываю скрин (на всякий случай, текст специально в читабельном виде не переношу, смотрите его в первоисточнике):

статья Особенности проведения оценки трудозатрат аналитиком

Standard
Interface prototyping (rus), Requirement management (rus)

Алан Купер. Об интерфейсе

Прочитал книгу Алана Купера, Роберта Реймана, Дэвида Кронина “Об интерфейсе. Основы проектирования взаимодействия”. Сразу скажу, что читал я её очень-очень тяжело: много очевидных для меня вещей и воды.

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

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

В дополнение, в другом разделе книги приведен следующий список вопросов целеориентированного проектирования:

  • Цели: что делает ваш день хорошим? а плохим?
  • Возможности: какие виды деятельности сейчас отнимают у вас
  • время?
  • Приоритеты: что для вас наиболее важно?
  • Информация: что помогает вам принимать решения?
  • Другой полезный тип вопросов – системоориентированные вопросы:
  • Функция: что вы чаще всего делаете при помощи этого продукта?
  • Частота: какими модулями продукта вы пользуетесь чаще всего?
  • Предпочтения: какие стороны этого продукта вам особенно полюбились? Что вызывает восхищение?
  • Отказы системы: как вы справляетесь с проблемами в функционировании системы?
  • Профессиональность: какие приемы вы используете для ускорения работы?
  • Для бизнес продуктов могут быть полезны вопросы, ориентированные на рабочий процесс:
  • Процесс: что вы сделали сегодня на работе первым делом? А что после этого?
  • Повторяющиеся действия и их регулярность: как часто вы это делаете? Что вы делаете еженедельно и каждый месяц, но не каждый день?
  • Исключения: каков типичный рабочий день? Что стало бы необычным событием?
  • Чтобы лучше понять мотивацию пользователей, можно применять вопросы, ориентированные на мировоззрение и отношение к окружающему:
    • Устремления: чем бы вы хотели заниматься через пять лет?
    • Избегание: что вы предпочли бы не делать? что откладываете?
    • Мотивация: что вам больше всего нравится в вашей работе (или жизни)? какие вопросы вы всегда решаете в первую очередь?

 Вот аспекты продукта, для оценки которых юзабилити тестирование особенно эффективно:

  • Наименование. Осмысленны ли названия разделов и надписи на кнопках? Возможно, какие-то из этих слов воспринимаются легче, чем другие?
  •  Архитектура. Осмысленно ли информация разбита на категории? Расположены ли информационные элементы в тех местах, где их ожидают найти потребители?
  • Первое знакомство и доступность. Легко ли новые пользователи находят базовые элементы интерфейса? Понятны ли инструкции? Есть ли в них необходимость?
  • Эффективность. Могут ли потребители эффективно решать конкретные задачи? Ошибаются ли они? При выполнении каких шагов? Как часто?

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

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

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

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

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

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

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

Важные рекомендации при проектировании и демонстрации результата:

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

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

  1. Следуйте ментальным моделям пользователей.
  2. Меньше – лучше.
  3. Позволяйте пользователям управлять, не принуждайте их к диалогу.
  4. Держите инструменты под рукой.
  5. Обеспечивайте немодальную обратную связь.
  6. Проектируйте наиболее вероятное, будьте готовы к возможному.
  7. Предоставляйте информацию о контексте.
  8. Организуйте непосредственное манипулирование и графический ввод.
  9. Отображайте состояния объектов и статус приложения.
  10. Избегайте ненужных сообщений.
  11. Не используйте диалоговые окна, чтобы сообщить, что все нормально.
  12. Избегайте чистого листа.
  13. Просите прощения, а не разрешения.
  14. Отделяйте функции от их настройки.
  15. Не задавайте вопросы – предоставляйте выбор.
  16. Прячьте рычаги катапультирования.
  17. Оптимизируйте скорость реакции; предупреждайте о задержках.
  18. Скрывайте кнопки, нажатие на которые ведет к серьезным последствиям.

Типичные ошибки, заложенные в поведение интерфейса, а так же ряд рекомендаций:

  • Не заставляйте пользователя переходить к другому окну ради выполнения операции, влияющей на текущее окно.
  • Не заставляйте пользователя вспоминать, где в файловой иерархии расположены его файлы.
  • Не заставляйте пользователя изменять размер окна без необходимости. Когда на экране появляется дочернее окно, программа должна установить его размер в соответствии с его содержимым.
  • Не создавайте ни большое пустое окно, ни маленькое и требующее прокрутки.
  • Не заставляйте пользователя передвигать окна. Если на рабочем столе есть свободное место, открывайте окно программы там, а не поверх других окон.
  • Не заставляйте пользователя заново вводить предпочтения. Если он установил шрифт, цвет, отступ или громкость, сделайте так, чтобы ему не пришлось повторно выполнять настройку, пока он сам не захочет.
  • Не заставляйте пользователя вводить данные во все поля в соответствии с неким произвольным критерием полноты. Если пользователь хочет опустить какие-то детали при вводе данных в форму, не вынуждайте его вводить их. Исходите из предположения, что у пользователя есть веские причины скрывать информацию. Полнота базы данных (в большинстве случаев) не стоит того, чтобы нервировать пользователя.
  • Не заставляйте пользователя просить разрешения. Как правило, это признак того, что ввод и вывод отделены друг от друга.
  • Не просите пользователя подтверждать свои действия (это правило подразумевает наличие развитой функции отмены).
  • Не позволяйте действиям пользователя приводить к ошибке.
  • Программы должны быть вежливы, исполнительны и т.п.
  • У программы должна быть проработанная обратная связь.
  • Программа  должна предугадывать действия пользователя.
  • Не привязывайтесь к вещам реального мира – они вносят ограничения (например, интерфейс в виде блокнота).
  • Используйте сетку в визуальном дизайне (пример см. ниже).
  • Движение взгляда по интерфейсу должно прокладывать логический маршрут, позволяющий пользователям эффективнои успешно решать задачи и достигать целей.
  • Элементы, различающиеся поведением, должны различаться и визуально.
  • Используйте одинаковые пиктограммы для элементов управления, решающих одни и те же задачи.
  • Отмена очень важна – при наличии этой кнопки пользователи не боятся экспериментировать.
  • Программа унижает пользователей, когда сообщает, что они ошиблись.

akiselev_screen

И пример рекомендованного сообщения об ошибке:

akiselev_screen_cooper

 

Standard