Следите за интерфейсами

Многие проблемы возникают на внутренних и внешних системных интерфейсах. Вот несколько предложений, чтобы минимизировать их.

Изображение от Freepik

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

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

Рисунок 1. Программные системы имеют внутренние интерфейсы между компонентами и внешними интерфейсами на другие объекты.

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

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

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

Рисунок 2. Это сообщение не помогло мне исправить ошибку интерфейса между моим iPad и сервером электронной книги.

По-видимому, произошел некоторый воспроизводимый сбой с интерфейсом между моим iPad и сервером, который размещал электронную книгу, о которой программное обеспечение должным образом сообщило мне. Но я понятия не имею из этого сообщения, где проблема заключается или что с этим делать. Я никогда не мог скачать эту электронную книгу или другие, к которым я пытался получить доступ таким же образом. Дизайнеры должны тщательно планировать и изучить внутренние и внешние интерфейсы системы, чтобы предотвратить такие раздражения пользователя.

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

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

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

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

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

Рисунок 3. Просмотр допустимых и недействительных входов и выходов позволяет оценивать правильное поведение интерфейса.

Хорошо разработанная система будет правильно обрабатывать исключения, которые происходят как на внутренних, так и на внешних интерфейсах. Недавно я попытался распечатать документ с моего ПК Windows на принтер в моей домашней сети Wi-Fi. Принтер был включен и подключен к сети, но мой компьютер настаивал на том, что принтер был в автономном режиме. Мне пришлось перезапустить свой компьютер, который затем правильно обнаружил принтер как онлайн и отправил работу печати. Некоторая проблема с нецелостным интерфейсом между ПК и принтером нарушила связь между ними, и я не имел возможности восстановить его, кроме радикального действия компьютерной перезагрузки. Этот тип ошибки происходит слишком часто.

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

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

Хорошо продуманные пользовательские интерфейсы должны потребовать небольшой документации поддержки в виде справочных экранов, пользовательских руководств и листов с наконечниками. Они облегчают пользователям, чтобы ускорить новое приложение, и пользователи будут делать меньше ошибок, когда они его используют. В программном дизайне UX существует огромная литература. Любой дизайнер выиграет от эксперта по удобству использования Эвристика юзабилити Джакоба Нильсена для дизайна пользовательского интерфейсаПолем Сохранение дизайна, ориентированного на использование, а не на функциях продукта, может помочь избежать многих проблем UX, которые заставляют пользователей газеты.

---

Автор: Карл Вигерс

Это урок № 2 из 60 в Разработка программного обеспечения жемчужины Карл ВигерсПолем Карл является автором многочисленных других книг, в том числе Требования к программному обеспечению. Основы (с Candase Hokanson), Требования к программному обеспечению (с радостью Битти), Бездумный дизайн повседневных вещейВ и Успешный консалтинг бизнес -анализаПолем

#design #productdesign #softwaredesign #productmanagement #requirements #businessanalysis #softwaredevelopment #architecture #productowner #businesnessanalyst