Программы «большие» и «маленькие»
Основная тема данного курса — методы разработки «больших» и сложных программ.
Каждый человек хоть раз написавший какую-либо программу, достаточно хорошо может представить себе, как разработать «небольшую» программу, решающую обычно одну конкретную несложную задачу и предназначенную, чаще всего, для использования одним человеком или узкой группой людей.
Примером может служить программа, вычисляющая достаточно много (но не слишком, не больше 30000) знаков числа π.
Воспользуемся следующими формулами.
Соответсвующая программа на языке Java может выглядеть примерно так.
public class PiCalculator
//Позволяет при вычислениях с повышенной точностью умножать и делить на числа
//Эта константа должна быть степенью 10 для простоты представления чисел. private final static long CLUSTER_SIZE = 100000;
//Определенное значение этого поля позволяет сосчитать
// numberOfClusters * lg( CLUSTER_SIZE ) //точных цифр.
private static int numberOfClusters;
for(int i = 0; i < numberOfClusters + 1; i++)
while(z > 0)
System. out. println();
if (i != numberOfClusters)
for(int i = numberOfClusters; i >= 0; i—)
if (i != 0)
int i, j, numberOfDigits = 100, numberOfSteps;
numberOfSteps = (int)(((numberOfDigits + 1)/(Math. log(5)/Math. log(10)) — 1)/2+1); numberOfClusters = (int)(numberOfDigits/(Math. log(CLUSTER_SIZE)/Math. log(10))+1);
System. arraycopy(a1, 0, c1, 0, numberOfClusters + 1);
System. arraycopy(a2, 0, c2, 0, numberOfClusters + 1);
for(j = 1; j < numberOfSteps; j++)
lndiv(a1, 25); lndiv(a2, 239); lndiv(a2, 239);
System. arraycopy(a1, 0, b1, 0, numberOfClusters + 1);
System. arraycopy(a2, 0, b2, 0, numberOfClusters + 1);
lndiv(b1, 2*j+1); lndiv(b2, 2*j+1);
lndiv(a1, 2*numberOfSteps + 1);
System. out. println(«Оценка точности результата:»); print(a1);
System. out. println(«Результат:»); print(c1);
Данная программа — «небольшая», как по размерам (~150 строк), так и по другим признакам:
•Она решает одну четко поставленную задачу (выдает десятичные цифры числа π) в хорошо известных ограничениях (не более 30000 цифр), к тому же, не очень существенную для какой-либо практической или исследовательской деятельности.
•Неважно, насколько быстро она работает — на вычисление 30000 цифр уходит не более получаса даже на устаревших компьютерах, и этого вполне достаточно.
•Ущерб от неправильной работы программы практически нулевой (за исключением возможности обрушения ею системы, в которой выполняются и другие, более важные задачи).
•Не требуется дополнять программу новыми возможностями, практически никому не нужно разрабатывать ее новые версии или исправлять найденные ошибки.
•В связи со сказанным выше не очень нужно прилагать к программе подробную и понятную документацию — для человека, который ею заинтересуется, не составит большого труда понять, как ею пользоваться, просто по исходному коду.
Сложные или «большие» программы, называемые также программными системами, программными комплексами, программными продуктами, отличаются от «небольших» не столько по размерам (хотя обычно они значительно больше), сколько по наличию дополнительных факторов, связанных с их востребованностью и готовностью пользователей платить деньги как за приобретение самой программы, так и за ее сопровождение и даже за специальное обучение работе с ней.
Обычно сложная программа обладает следующими свойствами.
•Она решает одну или несколько связанных задач, зачастую сначала не имеющих четкой постановки, настолько важных для каких-либо лиц или организаций, что те приобретают значимые выгоды от ее использования.
•Существенно, чтобы она была удобной в использовании. В частности, она должна включать достаточно полную и понятную пользователям документацию, возможно, также
специальную документацию для администраторов, а также набор документов для обучения работе с программой.
•Ее низкая производительность на реальных данных приводит к значимым потерям для пользователей.
•Ее неправильная работа наносит ощутимый ущерб пользователям и другим организациям и лицам, даже если сбои происходят не слишком часто.
•Для выполнения своих задач она должна взаимодействовать с другими программами и программно-аппаратными системами, работать на разных платформах.
•Пользователи, работающие с ней, приобретают дополнительные выгоды от того, что программа развивается, в нее вносятся новые функции и устраняются ошибки. Необходимо наличие проектной документации, позволяющей развивать ее, возможно, вовсе не тем разработчикам, которые ее создавали, без больших затрат на обратную разработку (реинжиниринг).
•В ее разработку вовлечено значительное количество людей (более 5-ти человек). «Большую» программу практически невозможно написать с первой попытки, с небольшими усилиями и в одиночку.
•Намного больше количество ее возможных пользователей, и еще больше тех лиц, деятельность которых будет так или иначе затронута ее работой и результатами.
Примером «большой» программы может служить стандартная библиотека классов Java,
Строго говоря, ни одно из указанных свойств не является обязательным для того, чтобы программу можно было считать «большой», но при наличии двух-трех из них достаточно уверенно можно утверждать, что она «большая».
На основании некоторых из перечисленных свойств можно сделать вывод, что «большая» программа или программная система чаще всего представляет собой не просто код или исполняемый файл, а включает еще и набор проектной и пользовательской документации.
Для разработки программных систем требуются особые методы — как уже говорилось, их нельзя написать «нахрапом». Изучением организационных, инженерных и технических аспектов создания ПО, включая методы разработки, занимается дисциплина, называемая программной инженерией. Большая часть трудностей при разработке программных систем связана с организацией экономически эффективной совместной работы многих людей, приводящей к практически полезному результату. Это требует рассмотрения следующих аспектов.
•Над программой обычно работает много людей, иногда географически удаленных друг от друга и из различных организаций. Их работа должна быть организована так, чтобы затраты на разработку были бы покрыты доходами от продаж и предоставления услуг, связанных с полученной программой. В затраты входят зарплаты разработчиков, затраты на закупленное оборудование и программные инструменты разработки, на приобретение лицензий и патентование собственных решений, часто еще и затраты на исследование потребностей клиентов, проведение рекламы и другой маркетинговой деятельности.
•Значимые доходы могут быть получены, только если программа будет предоставлять пользователям в реальных условиях их работы такие возможности, что они готовы будут заплатить за это деньги (которым, заметим, без труда можно найти другие полезные применения). Для этого нужно учесть множество аспектов. Доходы от продаж значительно снизятся, если многие из пользователей не смогут воспользоваться программой только потому, что в их компьютерах процессоры слишком медленные или мало оперативной памяти, или потому что данные к системе часто поступают в искаженном виде и она не может их обработать, или потому что они привыкли работать с графическим интерфейсом, а система требует ввода из командной строки, и т.
Важно отметить, что практически полезная сложная программная система не обязательно является «правильной».
Большинство опытных разработчиков и исследователей считают, что практически значимые программные системы всегда содержат ошибки. При переходе от «небольших» программ к «большим» понятие «правильной» программы становится практически бессмысленным. Про программную систему, в отличие от приведенной выше программы вычисления числа π, нельзя утверждать, что она «правильная», т. всегда правильно решает все поставленные перед ней задачи. Этот факт связан как с практической невозможностью полного доказательства или проверки этого, так и с тем, что смысл существования программной системы — удовлетворение потребностей и запросов большого количества различных заинтересованных лиц. А эти потребности не только нечетко определены, различны для разных групп пользователей и иногда противоречивы, но и значительно изменяются с течением времени.
В связи с этим, вместо рассмотрения «правильных» и «неправильных» программных систем, в силу практического отсутствия первых, рассматривают «достаточно качественные» и «недостаточно качественные».
Поэтому и основные проблемы разработки сложных программных систем связаны с нахождением разумного компромисса между затратами на разработку и качеством ее результата. В затраты входят все виды используемых ресурсов, из которых наиболее важны затрачиваемое время, бюджет проекта и используемый персонал. Удовлетворение пользователей от работы с программой (а, следовательно, доходы от ее продаж и предоставления дополнительных услуг) и удовлетворение разработчиков от ее создания определяются качеством программы, которое включает в себя такие аспекты, как набор предоставляемых возможностей, надежность, удобство использования, гибкость, удобство внесения изменений и исправления ошибок. Более подробно понятие качественного программного обеспечения будет обсуждаться в одной из следующих лекций.
Часто программное обеспечение (ПО) нельзя рассматривать отдельно от программноаппаратной системы, куда оно входит в качестве составной части. Изучением вопросов, связанных с разработкой и эксплуатацией программно-аппаратных систем занимается системная инженерия. В ее рамки попадает огромное количество проблем, связанных с аппаратной частью систем и обеспечением нужного уровня интеграции программной и аппаратной составляющих. Мы только изредка будем затрагивать вопросы, касающиеся системной инженерии в целом, в основном ограничиваясь аспектами, относящимися непосредственно к ПО.
В данном курсе будут рассматриваться различные подходы к решению проблем разработки, связанных с обеими составляющими дилеммы «ресурсы-качество» при создании сложных программ. Для изложения этих подходов вводится система понятий, относящихся к программным системам и процессам их создания и позволяющих эффективно разрабатывать такие системы, оценивать и планировать их свойства. В их число входят такие понятия, как жизненный цикл ПО,
качество ПО, процесс разработки ПО, требования к ПО, архитектура ПО, образцы проектирования и пр.
Кроме того, особое внимание в курсе уделяется одному из подходов к разработке сложного ПО, компонентной разработке, предлагающей строить такие системы последовательно из отдельных элементов — компонентов, каждый из которых, в свою очередь, может рассматриваться как отдельная программная система. Курс дает введение в современные компонентные технологии разработки программных систем на основе платформ J2EE и. NET.
Проблемы, связанные с управлением ресурсами разработки, в том числе — планированием отдельных действий во времени, созданием эффективных команд разработчиков, относятся к управлению проектами, которому будет посвящена последняя лекция курса.
На основании опыта конструирования больших систем разработаны так называемые технологические процессы, содержащие достаточно детальные описания разных аспектов их создания и эксплуатации. Эти описания дают ответы на вопросы о том, как должна вестись разработка, какие лица должны в ней участвовать и на каких этапах, какие виды деятельности и в какой последовательности должны выполняться, какие документы являются их входными данными и какие документы, модели, другие части программной системы должны быть подготовлены в результате каждой отдельной работы. Элементы таких методик будут
Соседние файлы в папке Книги
Что означает разработка программного обеспечения?
Это процесс разработки, идентификации, проектирования, программирования, документирования, тестирования, исправления ошибок, связанный с созданием и поддержкой приложений, фреймворков и других компонентов программного обеспечения.
Неправильная оценка
Когда составляется оценка проекта, бывает, что она не оправдывает ожиданий. Команда может выбрать продолжительность итерации проекта, стек технологий и другие факторы. Между клиентом и командой часто возникают разногласия, что приводит к увеличению длительности задачи, затрат, из-за которых у клиента заканчиваются деньги и он не может завершить проект.
Как минимизировать этот риск:
- Выполняйте только самые важные задачи;
- Добавьте время разработчикам для изучения и снижения рисков в частях нового проекта;
- Добавьте предполагаемый период для команды разработчиков в течение недели для задачи, выходящей за рамки проекта;
- В управлении проектами конус неопределенности описывает развитие неопределенности в лучшем случае во время проекта. В начале проектов, мало что известно о продукте или результатах работы, поэтому оценки подвержены большой неопределенности.
Изменения
Изменения происходят, если масштаб итерации изменяется после утверждения дедлайна. Заказчики часто хотят изменить объем проекта и это создает большой риск, не позволяя разработчикам следовать первоначальному ТЗ и графику.
- Небольшие, простые в управлении итерации по гибкой методологии Agile позволяют анализировать и изменять размер проекта;
- При оценке проекта взять несколько дополнительных недель для “непредвиденных ситуаций”.
Код низкого качества.
Низкое качество кода – одна из самых распространенных проблем в разработке и одна из самых больших проблем клиента. Чаще всего заказчик не понимает код и не может определить его качество. К завершению разработки может выясниться, что у приложения некачественно разработанный код, проблемы в работе и отсутствие грамотного тестирования.
Разработчикам важно следовать разработанным стандартам кода.
- Клиент может нанять менеджера проекта или технического директора, который сможет проверять качество кода и контролировать команду разработчиков;
- Соблюдение системы Стандартов Качества Кода (англ. Clear Coding Standards and Guidelines);
- Тестирование после каждой итерации кода;
- Прежде чем начать работу с компанией-разработчиком, клиент может запросить аналогичный проект и ознакомиться со стандартами кода компании.
Низкое взаимодействие с клиентом
Чтобы команда разработчиков закончила вовремя проект необходимо достаточно часто общаться с клиентом или менеджером проекта для уточнения деталей по проекту. Если этого не делать, то есть риск недопонимания с обеих сторон и увеличения продолжительности итераций.
- Важно оговорить допустимое время ответа, если у любой из сторон есть проблема или вопрос по проекту;
- Четкий выбор целей и приоритетов проекта.
Недостаточное количество людей
По разным причинам членам команды приходится покидать проект. Из-за этого работа приостанавливается до тех пор, пока не будет найден новый член команды, что увеличивает сроки выполнения проекта.
- Документирование всего процесса разработки;
- Хорошая внутренняя кадровая система, позволяющая, в случае возникновения такой ситуации, быстро заменить члена команды;
- Менеджер проекта должен часто контролировать график рабочей нагрузки своей команды, чтобы оперативно среагировать на изменения.
Кто может контролировать риски в разработке программного обеспечения
Менеджер проекта отвечает за все задачи, связанные с проектом. Бизнес-аналитик, занимающийся определением и анализом требований проекта. Вместе они могут помочь создавать успешные продукты и минимизировать риски разработки программного обеспечения.
Менеджер проекта и управление рисками
Главная задача Менеджера проекта во время довести идею клиента до результата, используя имеющиеся ресурсы. Ему необходимо создать план развития, организовать команду, наладить процесс работы над проектом, дать обратную связь, ликвидировать препятствия для команд, контролировать качество и своевременность выполнения задач.
- Разработка нового продукта или новых функций. Менеджер проекта организует встречу с техническим архитектором и разработчиками, обсуждает с ними предстоящие задачи, помогает в составление ТЗ;
- Планирование. Важно учитывать все факторы, влияющие на ход разработки, включая квалификацию сотрудников и связанные с ними риски, зависимость от сторонних сервисов и исправление ошибок;
- Контроль. Менеджеру проекта необходимо ежедневно отслеживать проектные итерации и контролировать весь процесс разработки, чтобы оперативно реагировать на возникающие проблемы.
- Общение с заказчиком. Это важный пункт при разработке проекта, так как проблемы могут происходит ситуативно и важно поддерживать коммуникацию с клиентом, сообщать об изменениях на проекте.
Бизнес-аналитик и управление рисками
Бизнес-аналитик – это именно тот специалист на проекте, который должен определить бизнес-проблемы клиента и найти наиболее эффективное решение. На всех этапах разработки ПО бизнес-аналитик анализирует требования и является связующим звеном между командой разработчиков и клиентом. Ниже приведены несколько основных функций, которые выполняет бизнес-аналитик на проекте:
- Выявление требований заказчика к проекту;
- Документирование требований к будущему проекту;
- Создание прототипов требований клиентов, мозговой штурм с клиентом и командой разработчиков, проведение тестов и анкетирование для лучшего понимания и анализа требований;
- Выявление слабых сторон проекта на основе собственного анализа. Предложение способов оптимизации процессов и решение возможных проблем по проекту;
- Написание технического задания, оптимизация требований к проекту;
- Передача оптимизированных требований от заказчика команде разработчиков.
Для клиентов
- Выход за рамки бюджета.
- Получение низкокачественного продукта.
Решение клиента: нанять со своей стороны специалиста, который проверит код и свяжется с командой разработчиков. Это затратно, поэтому многие клиенты выбирают модель оплаты по фиксированной цене, чтобы не выходить за рамки бюджета. Но, в данном случае, мы рекомендуем пригласить специалиста на этап написания ТЗ со своей стороны, чтобы минимизировать риски.
Следуйте чек-листу SolveIt, чтобы минимизировать риски в разработке программного обеспечения:
- Разработайте подробную техническую документацию вместе с клиентом и техническим специалистом;
- Выберите правильную модель взаимодействия, основываясь на финансовых средствах и советах технического директора;
- Следуйте ранее разработанной документации, избегайте добавления новых требований к продукту во время разработки.
Если вам нужен качественный проект, наши специалисты SolveIt помогут вам оптимизировать бюджет и минимизировать риски.
Аннотация
Удобство использования приложений становится лучше, когда пользовательский интерфейс направляет пользователей и помогает им в процессе работы.
Разработка сложных приложений является задачей не из легких. Создание приложений, обладающих как глубиной для поддержки сложных задач, так и интуитивностью, является огромной проблемой.
Сложно давать общие рекомендации по распространённым проблемам разработки приложений, потому что многие из проблем, которые мы наблюдаем, зависят от конкретной области. Это было правдой ещё 11 лет назад, когда была написана первая версия этой статьи, и это до сих пор актуально.
Таким образом, наша первая рекомендация — провести исследование пользователей с вашей целевой аудиторией:
- Начните с анализа задач и полевых исследований, чтобы понять потребности ваших пользователей и рабочие процессы.
- Прототипируйте и тестируйте идеи низкого качества, чтобы проработать основную структуру вашего приложения и его функции. Не выделяйте много ресурсов на идеи, которые вы будете пересматривать или от которых вовсе откажетесь, узнав отношение пользователей.
- Проектируйте итеративно и тестируйте каждое изменение с небольшой аудиторией. Чем больше итераций, тем лучше будет ваше приложение.
Несмотря на конкретные проблемные отрасли у большинства юзабилити-приложений, здесь описаны десять распространённых ошибок, которые мы часто встречаем в разных отраслях. Пять из этих вопросов (первый, второй, третий, четвёртый и шестой) также были включены в первоначальную статью, что показывает, каковы принципы долговременного использования.
Все десять первоначальных руководств по-прежнему верны, но пять ошибок, к счастью, уже менее распространены, и их заменили на пять более актуальных проблем (пятый, седьмой, восьмой, девятый и десятый разделы).
Вот наш текущий список топ-10 ошибок в разработке приложений, которые одновременно являются как вопиющим, так и обычным явлением.
Плохая обратная связь
Одним из основных принципов повышения юзабилити приложения является предоставление чёткой обратной связи:
- Показывать пользователям текущее состояние системы.
- Расскажите пользователям, как были интерпретированы их команды и действия.
- Сообщайте пользователям, что происходит.
Приложения, которые молчат, заставляют пользователей угадывать, что происходит. Часто они угадывают неправильно.
Хорошая обратная связь говорит пользователям многое. К примеру, правильно ли кнопка, которую они кликнули, интерпретируется системой как «клик» и реагирует ли система? Что сейчас выбрано или активно?
Один из случаев, где обратная связь становится важной, — когда приложение переводится в режим редактирования для изменения существующей информации.
Важно, чтобы пользователи чётко понимали, что в настоящее время редактируется, поскольку приложения будут различаться по объёму режима редактирования. Например, некоторые приложения будут включать таблицы данных, в которых редактируется одна ячейка или строка, другие будут делать редактируемой всю таблицу.
Правильная, чёткая обратная связь может донести до пользователей объём редактирования. Хорошая обратная связь может быть реализована различными способами от использования другого фона для определения текущей редактируемой области до изменения кнопок, связанных с редактированием, чтобы чётко показать их функцию.
В режиме редактирования это приложение от Telerik. com добавляет серый фон в строку таблицы, которая в данный момент редактируется, изменяет ячейки так, чтобы они выглядели как поля формы, и изменяет кнопки «Изменить» и «Удалить» на «Обновить» и «Отмена» с другим макетом.
Изменение расположения и цвета кнопок является дополнительным важным сигналом в этой обратной связи, так как снижает вероятность того, что пользователи нажмут неправильную кнопку после редактирования, если они не обращают внимания и полагаются на мышечную память. Этот уровень обратной связи чётко указывает на то, что происходит с системой и как она реагирует на ввод пользователя.
«Выход на обед» без индикатора прогресса
Вариант отсутствия обратной связи — когда система не может уведомить пользователей о том, что для выполнения действия требуется много времени. Пользователи часто думают, что приложение не работает или начинают нажимать на другие кнопки.
Если вы не можете соблюдать рекомендуемое время отклика, скажите об этом и держите пользователей в курсе событий с помощью индикатора прогресса:
- Если команда занимает от двух до десяти секунд, покажите анимацию ожидания в виде спиннера. Индикатор прогресса этого типа говорит пользователям «придержать коней» и не нажимать на что-либо еще, пока не вернется обычный курсор.
- Если команда занимает более десяти секунд, установите явный индикатор выполнения, предпочтительно в виде индикатора процента выполненных работ (если вы действительно не можете предсказать, сколько понадобится времени до завершения операции)
Несоответствие
Помните правило двойного D: различия сложны (differences are difficult). Когда у пользователей есть ожидания относительно того, как что-то будет работать или где они могут получить доступ, отклонения от этих ожиданий вызывают путаницу, разочарование и повышенную когнитивную нагрузку, когда люди пытаются решить проблему. Человеческий разум жаждет последовательности.
Существует несколько типов несоответствий, которые особенно распространены в сложных приложениях и приводят в замешательство даже опытных пользователей:
- Разные слова или команды для одного и того же действия.
- Размещение элементов управления для одной и той же функции в разных местах.
- Элементы управления, которые похожи друг на друга (с точки зрения пользователя), но доступны в разных местах (например, один доступен на панели инструментов, другой — в меню, а третий — глубоко в диалоге настроек).
- Подобные структуры рабочего процесса, которые требуют взаимодействия с самыми разными разделами интерфейса.
- Несовместимые правила для допустимых входных данных: иногда запись разрешена, а в других случаях она помечается как недействительная, без какой-либо обратной связи о том, почему это происходит.
- Функция иногда доступна, а иногда нет — по таинственным причинам, которые не указаны.
- Элементы пользовательского интерфейса или элементы управления, которые перемещаются, нарушая пространственную согласованность.
Архитектор в нашем исследовании, имевшая многолетний опыт использования AutoCAD, изо всех сил пыталась понять, когда она может или не может «стыковать» различные плавающие панели, чтобы закрепить их на одной стороне экрана.
В одной и той же сессии она несколько раз пыталась заставить плавающую панель пристыковаться к левой стороне, но безрезультатно. Оказалось, что из-за скрытой установки параметров эту конкретную панель невозможно закрепить, но это ограничение не было явно показано пользователю.
Скрытая настройка была предназначена для того, чтобы дать опытным пользователям возможность настраивать интерфейс до невероятной степени, но из-за плохой обратной связи наш участник исследования не мог понять, почему док-станция иногда работает, а иногда нет. Этот тип несоответствия является основным источником разочарования даже для опытных пользователей.
AutoCAD не всегда позволял нашему участнику исследования «закреплять» панели на одной стороне экрана. Даже опытный пользователь не может определить, почему эта функция работает на некоторых панелях, а на других нет. (Оказалось, что для этой панели скрытый параметр отключен
Некачественные сообщения об ошибках
Сообщения об ошибках — это особая форма обратной связи: они сообщают пользователям, что что-то пошло не так. Мы знаем руководящие принципы для сообщений об ошибках почти 30 лет, и все же многие приложения все еще нарушают их.
Наиболее распространенное нарушение правил — когда в сообщении об ошибке просто говорится, что что-то не так, без объяснения, почему и какпользователь может решить проблему. Такие сообщения оставляют пользователей в замешательстве.
Эта проблема усугублялась годами, в основном из-за веб-приложений: пользователям показывают, что что-то пошло не так. Попробуйте снова — сообщение об ошибке, без подробностей о причине ошибки или о том, как ее можно исправить.
По крайней мере десктопные приложения прошлого года сообщали пользователям (часто в техническом виде и непрофессионалы не могли понять ), в чём заключалась проблема.
Набор расплывчатых сообщений «Что-то пошло не так» от Quicken (вверху слева), Dropbox (вверху справа), IBM Verse (внизу): ни одно из них не описывает суть проблемы, подробности о том, как её решить, и была ли работа пользователя потеряна в процессе.
Информативные сообщения об ошибках не только помогают пользователям решить свои текущие проблемы, но также могут служить обучающим моментом. Хотя люди не будут тратить время на чтение и изучение функций вашего приложения, они попытаются понять ситуацию с ошибкой, если вы чётко объясните её, потому что они хотят её решить.
Отсутствие значений по умолчанию
Настройки по умолчанию помогают пользователям во многих отношениях. Самое главное, значения по умолчанию могут:
- Ускорить взаимодействие, освободив пользователей от необходимости указывать значение, если значение по умолчанию приемлемо.
- Научить, предоставляя пример вроде ответа, который подходит для вопроса.
Значения по умолчанию могут сэкономить усилия в повторяющихся задачах — многократное заполнение одной и той же формы. Определение ключевых значений для полей формы может повысить производительность и уменьшить разочарование. Анализ может помочь вам понять, есть ли наиболее часто выбранный вариант для конкретной области.
В частности выпадающие меню выигрывают от значения по умолчанию. Многие приложения предоставляют выбор одного (значение не выбрано вообще) в качестве выбора по умолчанию, заставляя каждого пользователя взаимодействовать с раскрывающимся списком и выбирать значение.
Если вы предварительно выберете один вариант (в идеале наиболее распространенный), по крайней мере некоторым пользователям вообще не придётся взаимодействовать с этим раскрывающимся списком.
С числовыми полями формы, если у пользователей незначительные отклонения от общего значения по умолчанию (например, по количеству полей), можете использовать степпер, чтобы позволить им регулировать число без ввода (но всё же позволяя пользователям вводить другое значение, если это необходимо).
Степперы имеют два преимущества: они снижают количество взаимодействия и дают разумную отправную точку для новых пользователей, которые всё ещё изучают систему.
Mint, приложение для личных финансов, имеет функцию, которая помогает пользователям найти кредитные карты, соответствующие их потребностям.
Этот мастер использовал хорошие значения по умолчанию, автоматически импортируя средние ежемесячные расходы пользователей на кредитные карты и предоставляя пользователю простой способ изменить это число, набрав или используя кнопки увеличения или уменьшения.
Значки без меток
Иконки редко ничем не подкреплены, но большинство пользователей сразу же могут их понять. Даже значки, которые могут показаться универсальными (например, гамбургер-меню), не настолько знакомы пользователям, как ожидало бы большинство практиков UX.
Становится намного хуже, если в вашем приложении есть уникальные значки; вероятность того, что пользователи поймут, что означают эти уникальные значки, очень мала. Помните закон Якоба: «Пользователи проводят большую часть времени на других веб-сайтах». Это означает, что большинство значков без текстовой метки, пользователи не смогут понять.
Четыре преимущества сопряжений значков с текстовой меткой:
- Увеличивает размер значка (что, согласно закону Фиттса, сокращает время, необходимое пользователям для доступа к элементу управления).
- Это сокращает время распознавания команды: две метки (значок и текст) лучше, чем одна.
- Относительно предыдущего: это также может облегчить изучение интерфейса (путём создания нескольких ассоциаций с одной и той же командой).
- Это может помочь пользователям визуально различать несколько команд, расположенных рядом друг с другом.
В наших недавних исследованиях представлены значки без меток из различных приложений для десктопных устройств: все значки — нестандартные, которые не указывают чётко их назначение. Можете ли вы угадать, что они обозначают? Наши участники исследования не смогли.
Слабые сигнификаторы
«Доступность» означает, что вы можете сделать с объектом. Например, флажок позволяет включать и выключать, а ползунок — перемещаться вверх или вниз.
Сигнификаторы — это визуальные элементы, которые помогают вам понять преимущества, просто посмотрев на объект, прежде чем вы начнёте его использовать (или почувствуете, если это физическое устройство, а не элемент пользовательского интерфейса на экране). Эти концепции обсуждаются в книге Дона Нормана «Дизайн повседневных вещей».
Сигнификаторы особенно важны в дизайне пользовательского интерфейса, потому что все пиксели экрана позволяют щёлкать мышью, даже если при нажатии ничего не происходит. На экране компьютера есть так много видимых вещей, что у пользователей нет времени на раздумья, они клацают на всё, пытаясь найти что-то действенное.
(Исключение: маленькие дети иногда любят просматривать экраны, нажимая на всё вокруг
В современных приложениях одним из худших нарушителей являются ультраплоские конструкции. Многие плоские конструкции имеют слабые значения для целей: люди не могут лёгко отличить текст от кнопок, потому что у кнопок нет традиционных 3D-подсказок.
Распространёнными признаками слабых сигнификаторов являются:
- Пользователи говорят: «Что я здесь делаю?»
- Пользователи не приближаются к функции, которая поможет им.
- Обилие экранного текста пытается преодолеть эти две проблемы. (Ещё хуже многоступенчатые инструкции, которые исчезают после выполнения первого из нескольких действий.)
Злоупотребление модальными окнами
Многие приложения используют модальные окна для реализации взаимодействия с данными: редактирование существующего элемента, добавление нового элемента, удаление или даже чтение дополнительных сведений об элементе.
Модалы появляются в верхней части текущей страницы, а фоновое содержимое обычно тусклое (при условии, что затемнение уменьшит отвлекающие факторы и поможет пользователям сосредоточиться на поставленной задаче).
К сожалению, этот выбор дизайна уменьшает контекст для пользователей, скрывая информацию, на которую они могут ссылаться при заполнении формы.
Обратите внимание, что даже если закрытое окно не содержит информации, необходимой для редактирования, пользователи часто пытаются использовать работу, которую они сделали ранее, копируя и вставляя предыдущие входные данные или даже просто используя другие записи в качестве шаблонов для того, чтобы думать о текущей задаче.
В Airtable редактирование строки таблицы открывает модальное окно, которое охватывает большую часть информации в таблице и не даёт пользователям ссылаться на эту информацию.
Бессмысленная информация
Длинные строки букв и цифр, такие как автоматически генерируемые идентификаторы в базе данных, часто используются для уникальной идентификации элемента в приложении.
Эти строки абсолютно бессмысленны для пользователей, но они часто отображаются в виде первого столбца таблицы, заставляя людей просматривать этот первый столбец, чтобы найти информацию, которая им нужна.
Хотя эти бессмысленные индексы важны для серверной части, они не должны быть основной частью информации, к которой должны обращаться пользователи. Особенно в экранах с высокой плотностью информации, предоставлять удобочитаемую информацию в качестве основной и убрать идентификаторы в менее заметное место.
Широко распространенное использование закодированной информации часто встречается в медицинских приложениях, системах CRM (где пользователям часто приходится выбирать код для каждого взаимодействия продаж со своими клиентами), бухгалтерском программном обеспечении и корпоративных приложениях.
Во всех этих приложениях информация, значимая для людей, обобщается с помощью короткого кода, чтобы сделать её более компактной. Короткий код может уместиться в небольшой области лучше, чем целое предложение, но возлагает гораздо большую когнитивную нагрузку на пользователей.
Им нужно будет перевести закодированную информацию, чтобы понять её, и наша рабочая память ограничена с самого начала. Даже высококвалифицированные специалисты не могут вспомнить все возможные коды, и им по-прежнему требуется много усилий, чтобы сделать этот мысленный перевод.
Эта таблица содержит бессмысленную идентификационную информацию в качестве первого столбца; поля Net Code и Location Code также включают в себя закодированную информацию, предназначенную для представления сложной информации в компактном пространстве.
Местоположение — единственный столбец, который имеет смысл для пользователей. Чтобы расшифровать остальные, люди должны либо полагаться на свою память, либо обращаться к списку кодовых ключей.
Меню как мусорный бак
Если ваше приложение имеет сотни или даже тысячи функций, вам нужно где-то разместить элементы управления этими функциями. Кроме того, вам нужно расставить приоритеты и упорядочить их, чтобы пользователи могли легко находить и быстро получать доступ к наиболее важным.
Одним из следствий этого ограничения часто является переполнение меню: наиболее часто используемые действия отображаются на панели инструментов, а конечный элемент, помеченный как «Дополнительные действия» или «Инструменты», содержит всё остальное, что не подходит.
Эти ярлыки меню имеют слабый информационный «запах» и представляют собой не что иное, как ящик для мусора: место для всего, что вы не можете классифицировать иначе, но не хотите выбрасывать.
Они часто появляются из-за того, что команда имеет список необходимых функций, но не знает, где их разместить. Или же в устаревших приложениях не может удалить старые, редко используемые функции.
Проблема с переполнением меню состоит в том, что, как и в случае с мусорным ящиком в вашем доме, никто не может знать, что вы могли в него положить. Другими словами, это ограничивает как возможности обнаружения, так и возможности поиска функций, поскольку у большинства пользователей нет причин искать эти меню.
Salesforce: меню «Спам» с надписью «Подробнее»
Близкое расположение отменяющих и подтверждающих действий
Помещение таких действий, как «Сохранить», рядом с действиями, которые уничтожают работы, является обычным дизайнерским решением, которое вызывает много горя у пользователей.
Хотя с логической точки зрения такое размещение часто имеет смысл (например, «Сохранить» и «Удалить» связаны с тем, что они решают судьбу элемента), но оно также позволяет легко нажимать неправильную кнопку или значок — особенно когда пользователи спешат, выполняя повторяющиеся действия. Этот тип непреднамеренной замены одного действия другим называется ошибкой.
Veeam, корпоративное ПО для резервного копирования, содержит многошаговый мастер для настройки нового задания резервного копирования.
В нашем исследовании пользователь потратил почти 20 минут, чтобы пройти через этот мастер, и почти нажал кнопку «Отмена», а не «Готово» на последней странице сводной информации из-за близости двух кнопок. Если бы этот пользователь нажал «Отмена», работа за 20 минут была бы потеряна.
Microsoft Outlook размещает кнопку «Отметить для продолжения» рядом со значками «Архивировать» и «Удалить». Эти значки служат противоположным намерениям пользователя, тем не менее они маленькие, размещены близко друг к другу и в спешке легко ошибиться.
Сбор и анализ требований (Planning and Requirement Analysis)
Это, пожалуй самый ответственный и важный из всех шагов к созданию успешной программной системы. Вся собранная информация используется для планирования базового проектного подхода.
Дополнительно идет планирование требований по обеспечению качества и выявления различных рисков, связанных с проектом. Результатом анализа является определение различных технических подходов, которые можно использовать для успешной реализации проекта с минимальными рисками. Планируйте то, что вы можете контролировать, и помните о вещах, планировать которые вы не сможете. Это поможет вам получить прочную основу для перехода ко второму этапу.
Проблема: Не соответствующие ожидания и часто изменяющиеся требования: заказчик и команда не понимают, какую реально пользу принесёт продукт.
Решение: Определить скоп работ, согласовать четкий, краткий документ с требованиями, создать прототипы (макеты) для подтверждения и уточнения окончательных требований.
Документирование требований (Defining Requirements)
Как только базовый анализ требований будет выполнен, следующим шагом будет четкое определение и документирование требований к продукту, утверждение со стороны клиента. Если одной из целей первого этапа является понимание и анализ требований, то на этом этапе все цели должны быть прописаны, это защита обеих сторон.
Важно четко определить и прописать, что требуется выполнить, это делается с помощью SRS (Software Requirement Specification). Документ содержит все требования к продукту, которые должны быть спроектированы и разработаны в течение жизненного цикла проекта.
Проблема: Большой многостраничный список требований
Решение: Выяснить высокоуровневые требования и, в ходе разработки и коммуникации с заказчиком, дописывать ТЗ. То есть разработка идет параллельно с Техническим заданием, а в процессе корректируется план.
В SolveIt мы всегда стараемся быть гибкими и подстраиваться под клиента. Работающий продукт важнее исчерпывающей документации.
Дизайн (Design the Product Architecture)
SRS это ориентир для разработчиков, чтобы предложить лучшую архитектуру для продукта. Обычно предлагается несколько подходов к проектированию архитектуры продукта. Все предложенные подходы документируются в спецификации DDS (Design Document Specification) и выбирается наилучший подход к проектированию. Данный подход очень четко определяет все архитектурные модули продукта, а также его связь с внешними и сторонними модулями.
Проблема: Выбрали неправильную архитектуру.
Решение: Наличие в команде разработчиков опытных лидов, которые смогли бы предложить подходящую архитектуру, на основе своего успешного опыта в схожих проектах.
Разработка ПО (Building or Developing the Product)
Здесь начинается разработка и сборка продукта. Весь программный код, новые модули и фичи разрабатываются на основании DDS. Чем лучше написана эта документация, тем быстрее будет идти имплементация. На этом этапе подключается команда разработчиков. Написанный код должен покрываться Unit-тестами, а взаимодействие новых фич с другими модулями тестироваться с помощью интеграционных тестов. Эти активности выполняются именно командой разработчиков, а не QA специалистами.
Проблема №1: Слабая коммуникация между командой
Разработчик не интересуется прогрессом проекта, проблемами коллег.
Решение: Daily meetings, 100% вовлеченность, Скрам доска (интерактивность).
Проблема №2: Невыполнимые сроки
Заказчик хочет, чтобы его продукт был готов в ближайшее время. Менеджер проекта пытается объяснить клиенту к чему приведет такая спешка, но этого не достаточно. Клиент ставит невыполнимые дедлайны и не слушает возражения менеджера проекта. В результате, команда разработчиков сдается и пробует закрыть задачи в слишком короткие сроки. Как следствие – критические баги из-за спешки: команда не успевает, качество продукта снижается, клиент не доволен и решает, что виновата команда.
Решение: Менеджер проекта должен стоять на своём и аргументировать дедлайны. Клиент должен понять, что если команда разработчиков будет торопиться, то не реализует часть функционала. Если всё же такой срок реализации критичен для клиента, мы стараемся выявить какие задачи находятся у заказчика в приоритете.
Проблема №3: Добавление не оговоренных фич
99% заказчиков ошибаются именно в этом месте. В ходе разработки клиент отклоняется от оговоренного тз и хочет добавить ещё фич в продукт. В результате вместе с ростом скопа фич, увеличиваются сроки и бюджет на разработку, деньги заканчиваются, а готово только 50% продукта.
Решение: Менеджер проекта должен объяснить клиенту, к чему приведет добавление новых фич в проект, отстаивать свою позицию и держаться SRS. Поэтому так важна вторая фаза Жизненного цикла разработки ПО.
Тестирование (Testing the Product)
Именно тестирование, в основном, затрагивает все этапы жизненного цикла. Дефекты продукта регистрируются, отслеживаются, исправляются и повторно тестируются. Это происходит до тех пор, пока продукт не достигнет стандартов качества, которые прописаны в SRS. На данном этапе в процесс разработки подключается команда мануальных тестировщиков или автоматизаторы.
Проблема: Тратится слишком много времени на поиск причин багов. Попытки найти и исправить дефекты после завершения разработки – сложный процесс, который может привести к большому количеству исправлений.
Решение: Проводить тестирование параллельно задачам, сразу же по их завершению.
Внедрение и поддержка продукта (Deployment in the Market and Maintenance)
Проблема №1: Отсутствие обратной связи, реальных отзывов потенциальных пользователей продукта.
Решение: Не ждать конца разработки, а как можно скорее запускать продукт, чтобы получить отзывы от реальных пользователей и на основе их предпочтений приоритезировать дальнейший функционал.
Проблема №2: Слабая инфраструктура проекта на стороне клиента.
Часть заказчиков предпочитают размещать сервера приложений не на Azure, AWS, Google и т. д, а в своей внутренней сети. Команда не может гарантировать стабильную работу, из-за сбоев, которые происходят на стороне клиента.
Решение: Предупредить клиента, о возможных проблемах, предложить решения для их устранения.
Это шесть основных стадий жизненного цикла разработки системы, и это повторяющийся процесс для каждого проекта. Важно отметить, что должен поддерживаться отличный уровень коммуникации с заказчиком. Для реализации требований очень важны и полезны прототипы. Строя систему короткими итерациями, можно гарантировать соответствие требованиям потребителя до того, как построить целую систему.
Если вам нужен качественный продукт, свяжитесь с нами и мы сделаем оценку вашего проекта!