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

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

1. Проблемы

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

Порядок при первом использовании

- Понять что нужно делать
- Найти сканер или нечто похожее
- Отсканировать чек с qr-кодом
- Найти куда вносить купюры
- Внести купюры
- Найти куда вносить монеты
- Внести монеты
- Найти откуда брать сдачу
- Взять сдачу
- Найти откуда брать чек
- Взять чек об оплате (а почему их два?)
- Понять какой чек нужен на выходе
- Выйти

Ура! так выглядел обыденный процесс покупки пакета молока после работы.

"Почти на каждом этапе покупатель должен что-то искать и в чем-то разбираться"

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

2. Проблемы оформления

• На кислотном красном нормально читаться будет только белый

• Белые подложки усиливают общую контрастность, выделяя все и не выделяя ничего

• Текст у сканера закрывается корзинкой для сдачи мелочи при виде сверху

• Нет привычной структуры, акцентов, иерархии, линии считывания. Глаз вынужден скакать

• Инструкция на мониторе показывает схематически неправильный терминал,
  несуществующий штрих-код, и указывает на несуществующий сканер

3. Возможное решение

Меньше шума, больше информации

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

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

Направляющие и подсказки

Второй по важности этап оплата.

Добавим акцент на купюроприёмник,
но гораздо слабее, чем на чек.

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

Добавим стрелку к оплате монетами. Этот этап происходит одновременно с оплатой купюрами,
но менее важен.

Дополнительно едва выделим область выдачи второго чека, и добавим символ штрих-кода, чтобы еще перед выходом показать, какую часть сканировать на выходе.

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

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

такое оформление не требует никаких технических изменений

"Это решение уже завтра можно напечатать на плёнке и расклеить на каждый терминал"

4. Варианты без привязки к цвету корпуса

Белый вариант

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

Зеленый вариант

Спокойный и не нагруженный вариант. Хорошо выглядит в сочетании с белым и белой заставкой на экране, но немного превращается в кашу с зеленой.

можно придумать еще несколько вариантов оформления цифр, чека, стрелок

(почти)Идеальные варианты в сферическом вакууме

Если отойти от существующих корпусов, и только следовать физическим ограничениям каждого
из внутренних устройств (купюроприёмник, чек, монетоприёмник ), можно упростить интерфейс и взаимодействие еще сильнее.

Чек на выходе

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

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

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

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

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

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

Итак, начнем

А начнем мы с того, какую роль в ПК выполняет материнская плата. По сути, она служит для:

• Обеспечения компонентов электропитанием;

• Обеспечения маршрутов для связи компонентов между собой.

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

Почти все материнские платы для стандартных ПК имеют разъемы для центрального процессора (ЦП), модулей памяти (обычно типа DRAM), дополнительных плат расширения (таких как видеокарта), устройств хранения, блоков ввода/вывода, а также средств связи с другими компьютерами и системами.

Существуют отраслевые стандарты по размерам материнских плат, которых придерживаются одни производители и не придерживаются другие (но их гораздо меньше). Вот основные из них:

• Standard ATX 12 9,6 дюйма (305 244 мм);

• Micro ATX 9,6 9,6 дюйма (244 244 мм);

• Mini ATX 5,9 5,9 дюйма (150 150 мм).

Более полный список можно найти в Википедии, но для простоты мы будем придерживаться Standard ATX, ведь различия чаще всего заключаются в количестве разъемов, доступных для питания и подключения, материнская плата большего размера позволяет использовать больше разъемов.

Но что же такое материнская плата?

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

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

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

Гораздо лучше и понятнее, не так ли? По ней видно, сколько в материнской плате всяких коннекторов и разъемов, о которых стоит поговорить. И начнем мы по порядку, с самого важного, сверху вниз.

Подключаем мозг к ПК

На схеме выше мы видим структуру, имеющую обозначение LGA1150. Это обозначение используется в Intel для разъема, предназначенного для подключения различных процессоров. LGA здесь означает Land Grid Array распространенный тип технологии упаковки центральных процессоров и других чипов.

Системы LGA имеют множество маленьких контактов на материнской плате или в разъеме для обеспечения питания и связи с процессором. Выглядят они так:

Металлический фиксатор помогает закрепить ЦП на месте, но мешает рассмотреть контакты, так что уберем его:

Помните, что это? LGA1150. 1150 здесь указывает на количество выводов в разъеме, и у других материнских плат оно может отличаться. Чем выше производительность ЦП (с точки зрения количества ядер, объема кэш-памяти и т. д.), тем больше контактов будет в разъеме. Большая их часть используется для обмена данными со следующей важной частью материнской планы.

Большому мозгу большая память

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

В нашем примере ЦП в материнской плате имеет 2 контроллера памяти, каждый из которых оперирует 2 картами памяти, всего 4 слота DRAM. На материнской плате они окрашены так, чтобы вы знали, какие из них каким контроллером управляются. Обычно их называют каналами памяти.

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

Допустим, у вас есть два модуля ОЗУ по 8 ГБ каждый. Независимо от того, в какие слоты вы их вставите, у вас всегда будет в общей сложности 16 ГБ доступной памяти. Однако, если оба модуля поместить только в черные или только в серые слоты, ЦП будет иметь два пути доступа к этой памяти. Но если поступить иначе и использовать слоты разных цветов, система будет вынуждена обращаться к памяти только с помощью одного контроллера памяти. Учитывая, что он может управлять только одним маршрутом за раз, нетрудно понять, как при этом изменится производительность.

При такой комбинации ЦП и материнской платы используются микросхемы DDR3 SDRAM (синхронная динамическая память с произвольным доступом с версией 3 двойной скорости передачи данных), и каждый слот может содержать один SIMM или DIMM. IMM обозначает X-рядный модуль памяти (In-line Memory Module); S и D указывают на то, заполнена ли чипами одна или две стороны модуля (Single или Dual, соответственно).

Вдоль нижнего края модуля памяти располагаются позолоченные разъемы для питания и обмена данными. Всего их у этого типа памяти 240 по 120 с каждой стороны.

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

Обычно производители придерживаются 240 контактов в модулях памяти, и нет никаких признаков того, что в ближайшее время это изменится. Чтобы улучшить производительность памяти, с каждой новой версией просто увеличивается скорость чипов. В нашем примере каждый из контроллеров памяти ЦП может отправлять и получать 64 бита данных за такт. Таким образом, с двумя контроллерами карты памяти будут иметь 128 контактов, предназначенных для обмена данными. Так почему же их именно 240?

Каждый чип в DIMM (всего их 16 по 8 на каждую сторону) может передавать 8 бит за такт. Это означает, что каждому чипу требуется 8 контактов только для передачи данных; однако пара чипов использует одни и те же выводы, поэтому только 64 из 240 отвечают за обмен данными. Остальные 176 контактов необходимы для синхронизации и передачи адресов данных (места расположения данных в модуле), управления микросхемами и обеспечения их электроэнергией. Так вы можете убедиться, что наличие более 240 контактов не обязательно улучшит ситуацию.

ОЗУ не единственное, что подключено к процессору

Для повышения производительности системная память подключена напрямую к центральному процессору, но на материнской плате есть и другие разъемы, подключенные примерно так же и в тех же целях. Они используют технологию подключения PCI Express (сокращенно PCIe), и каждый современный ЦП имеет встроенный контроллер PCIe.

Эти контроллеры могут обрабатывать несколько соединений (обычно называемых линиями), даже несмотря на то, что это система точка-точка что означает, что линии в разъеме не используются совместно с каким-либо другим устройством. В нашем примере контроллер PCI Express имеет 16 линий.

На изображении ниже показаны 3 разъема: два верхних это PCI Express, нижний гораздо более старая система под названием PCI (родственная PCIe, но намного медленнее). Маленький слот сверху, обозначенный как PCIEX1_1, имеет одну линию; тот, что ниже, 16 линий.

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

• 2 разъема PCI Express на 1 линию;

• 3 разъема PCI Express на 16 линий;

• 2 разъема PCI.

Но если у контроллера ЦП всего 16 линий, то что тогда происходит? Прежде всего, к процессору подключены только PCIEX16_1 и PCIEX16_2, а третий и два однолинейных подключены к другому процессору на материнской плате (подробнее об этом чуть позже). Кроме того, если задействованы оба разъема на 16 линий PCIe, ЦП выделит каждому только по 8 линий. Это типично для всех современных процессоров: количество линий у них ограничено, и по мере того, как к ЦП подключается все больше устройств, на каждое выделяется все меньшее число линий.

Различные конфигурации процессора и материнской платы имеют собственные способы решения этой проблемы. Например, материнская плата Gigabyte B450M Gaming имеет один разъем PCIe на 16 линий, один PCIe на 4 линии и один M.2, использующий 4 линии PCIe. Поскольку ЦП имеет всего 16 линий, использование любых двух разъемов одновременно приведет к тому, что самый большой слот, 16-тилинейный, будет ограничен всего до 8 линий.

Так что же использует такие разъемы? Наиболее распространенные варианты:

• 16 линии видеокарта;

• 4 линии твердотельные накопители (SSD);

• 1 линия звуковые карты и сетевые адаптеры.

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

В нашем примере с материнской платой гораздо больше разъемов и соединений, которыми нужно управлять, поэтому в помощь центральному процессору существует дополнительный процессор.

Теперь двинемся через мост на юг

Глядя на материнские платы 15-тилетней давности, можно заметить, что в них было встроено два дополнительных чипа для поддержки процессора. Вместе они назывались набором микросхем, а по отдельности чипами северного (NB) и южного моста (SB). Первый обрабатывал системную память и видеокарту, второй данные и инструкции для всего остального.

На фото выше показана материнская плата ASRock 939SLI32, где четко видны микросхемы NB и SB. Они обе скрыты под алюминиевыми радиаторами, но ближайшая к разъему ЦП в середине изображения это и есть северный мост. Спустя несколько лет после выхода этой платы и Intel, и AMD откажутся от использования NB и выпустят продукты, в которых NB интегрирован в ЦП. Южный мост, однако, остается отдельным, и, скорее всего, это не изменится в обозримом будущем. Интересно, что оба производителя процессоров перестали называть его SB и теперь часто зовут его просто чипсетом (собственное название Intel PCH, блок контроллеров платформы) несмотря на то, что это один чип.

В нашем более современном примере от Asus SB также покрыт радиатором, поэтому давайте снимем его и взглянем на дополнительный процессор.

Этот чип представляет собой усовершенствованный контроллер, поддерживающий разные типы и количество подключений. В частности, у нас есть Intel Z97, выполняющий следующие функции:

• 8 линий PCI Express (версия 2.0 PCIe);

• 14 портов USB (6 для версии 3.0, 8 для версии 2.0);

• 6 портов Serial ATA (версия 3.0).

Также он имеет встроенный сетевой адаптер, звуковой чип, выход VGA и целый ряд других систем синхронизации и управления. В других материнских платах могут использоваться другие более простые или наоборот расширенные наборы микросхем (например, с большим числом линий PCIe), но в целом обычно они аналогичны друг другу.

В данном случае это процессор, обрабатывающий слоты PCIe с одной линией, третий слот с 16 линиями и слот M.2. Как и многие новые чипсеты, он обрабатывает все эти различные соединения с помощью набора высокоскоростных портов, которые можно переключить на PCI Express, USB, SATA или сетевое соединение, в зависимости от того, что подключено в данный момент. Это, к сожалению, накладывает ограничение на количество устройств, подключенных к материнской плате, несмотря на наличие всех этих разъемов.

В случае нашей материнской платы Asus порты SATA (используемые для подключения жестких дисков, DVD-приводов и т. д.) из-за этого ограничения сгруппированы так, как показано выше. Блок из 4 портов посередине использует стандартные USB-соединения чипсета, тогда как два слева используются некоторые из этих высокоскоростных соединений. Так что, если вы используете те, что слева, на чипсете будет меньше соединений для других разъемов. То же самое и с портами USB 3.0. В них есть поддержка до 6 устройств, но 2 порта обязательно будут подключены к высокоскоростным соединениям.

Разъем M.2, используемый для подключения SSD-накопителя, также использует быструю систему (вместе с третьим слотом PCI Express на 16 линий на этой материнской плате); однако в некоторых комбинациях ЦП и материнской платы разъемы M.2 подключаются непосредственно к ЦП, поскольку многие новые продукты имеют более 16 линий PCIe.

Слева на нашей материнской плате есть ряд разъемов, обычно называемых блоком ввода/вывода, и в данном случае микросхема южного моста обрабатывает только некоторые из них:

• Разъем PS/2 для клавиатур и мышей (сверху слева);

• Разъем VGA для недорогих и устаревших мониторов (сверху посередине);

• Порты USB 2.0 черные (снизу слева);

• Порты USB 3.0 синие (снизу посередине).

Встроенный графический процессор ЦП обрабатывает разъемы HDMI и DVI-D (внизу в центре), а остальные управляются дополнительными микросхемами. На большинстве материнских плат есть множество дополнительных маленьких процессоров для управления всевозможными разъемами, поэтому давайте взглянем на некоторые из них повнимательнее.

Дополнительные фишки для дополнительной помощи

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

Рассматриваемая нами материнская плата Asus не исключение. Например, микросхема Nuvoton NCT6791D обрабатывает все маленькие разъемы для кулеров и датчики температуры на плате. Расположенный рядом процессор Asmedia ASM1083 управляет двумя устаревшими разъемами PCI, поскольку у чипа Intel Z97 такой возможности нет.

Хоть у чипсета Intel и есть встроенный сетевой адаптер, но он нагружает столь драгоценные высокоскоростные соединения, поэтому Asus добавила еще один чип Intel (I218V) для управления красным разъемом Ethernet, который мы видели в блоке ввода/вывода. На изображении выше не видно, насколько мал этот чип: его площадь составляет всего 0,24 дюйма (6 мм).

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

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

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

Эти маленькие микросхемы представляют собой переключатели PCI Express и помогают процессору и южному мосту управлять 16-линейными разъемами PCIe, когда им необходимо распределить полосы между несколькими устройствами.

Материнские платы с возможностью разгона процессоров, чипсетов и системной памяти теперь стали обычным явлением, и многие из них поставляются с дополнительными интегральными схемами для управления этими функциями. В нашем примере платы, выделенной красным, Asus использует собственную конструкцию, называемую TPU (TurboV Processing Unit), которая регулирует тактовые частоты и напряжения.

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

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

Этот чип Winbond имеет объем памяти всего 8 МБ, но этого более чем достаточно для хранения всего необходимого ПО. Этот вид флэш-памяти имеет очень малое энергопотребление при использовании и надежно хранит данные в течение десятилетий.

При включении ПК содержимое флэш-памяти копируется непосредственно в кэш ЦП или системную память, а затем запускается оттуда. Единственное, с чем это не сработает, это время.

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

Кстати о питании для него тоже есть отдельные разъемы.

Игорь, принеси мне питание!

Чтобы обеспечить материнскую плату и подключенные к ней устройства необходимым напряжением, блок питания (PSU) имеет ряд стандартных разъемов. Основной из них 24-контактный разъем ATX12V версии 2.4.

Величина тока зависит от блока питания, но промышленные стандарты напряжения составляют +3,3, +5 и +12 В.

Основная часть питания ЦП поступает от 12-вольтных контактов, но для современных высокопроизводительных систем этого недостаточно. Чтобы обойти эту проблему, существует дополнительный 8-контактный разъем питания, обеспечивающий еще четыре 12-вольтных линии.

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

Линии +3,3, +5 и +12 В подают питание на различные компоненты на самой материнской плате, а также ЦП, DRAM и любые устройства, подключенные к разъемам, таким как USB-порты или PCI Express. Однако все, что использует порты SATA, требует питания непосредственно от блока питания, а разъемы PCI Express могут обеспечить напряжение только до 75 Вт. Если устройству требуется больше энергии, например, как многим видеокартам, то их также необходимо подключить напрямую к блоку питания.

Однако есть и более серьезная проблема, чем наличие достаточного количества выводов на 12 В: процессоры не работают от этого напряжения.

Например, процессоры Intel, совместимые в нашей материнской платой Asus Z97, работают с напряжением от 0,7 до 1,4 В. Это не фиксированное напряжение, поскольку современные процессоры меняют его для экономии энергии и уменьшения нагрева, и в спящем режиме процессор может потреблять менее 0,8 В. Затем, когда все ядра полностью загрузятся и начнут свою работу, оно возрастает до 1,4 В и более.

Блоки питания предназначены для преобразования сетевого переменного напряжения (110 или 230 В в зависимости от страны) в фиксированное постоянное, поэтому необходимы дополнительные цепи для его снижения. Такие схемы называются модулями регулирования напряжения (VRM), и их несложно найти на любой материнской плате.

Каждый VRM обычно состоит из 4 компонентов:

• 2 MOSFET сильноточные управляющие транзисторы (синие);

• 1 дроссель (фиолетовый);

• 1 конденсатор (желтый).

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

VRM обычно управляются отдельной микросхемой, которая контролирует устройство и переключает модули в соответствии с требуемым напряжением. Такие схемы называются многофазными контроллерами широтно-импульсных модуляторов; Asus именует их EPU. Такие вещи сильно нагреваются при работе, поэтому их часто накрывают металлическим радиатором, который помогает рассеивать ненужную энергию.

Даже стандартный настольный процессор, такой как Intel i7-9700K, может потреблять ток более 100 А при полной загрузке. VRM очень эффективны, но они не могут изменять напряжение без потерь. Принимая во внимание большой ток потребления, вы получаете отличное устройство для гриля.

Если снова взглянуть на фотографию нашей платы, можно увидеть пару VRM для модулей DRAM, но, поскольку напряжения там гораздо меньше, чем на ЦП, они не так сильно нагреваются (и поэтому радиатор не нужен).

И прочие назойливые мелочи

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

Здесь у нас есть:

• 1 мягкий выключатель питания;

• 1 кнопка сброса;

• 2 светодиодных разъема;

• 1 разъем для динамика.

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

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

Большинство материнских плат имеет аналогичный набор дополнительных разъемов, как показано выше слева направо:

• Разъем аудиопанели если в корпус ПК встроены разъемы для наушников/микрофона, то их можно подключить к встроенному звуковому чипу;

• Цифровой аудиоразъем такой же, как и обычный аудиоразъем, но для S/PDIF;

• Перемычка сброса BIOS позволяет сбросить BIOS до заводских настроек. Также за ним спрятан разъем термозонда;

• Разъем Trusted Platform Module используется для повышения безопасности материнской платы и системы.

• Разъем последовательного порта (COM) древний интерфейс. Кто-нибудь вообще им пользуется? Кто-нибудь?

Также наклеены, но не показаны, разъемы для кулеров и дополнительных USB-портов. Не каждая материнская плата поддерживает все это, но многие.

Соединяя все вместе

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

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

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

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

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

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

В заключение

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

Всем привет! Меня зовут Юра, яBA Tech Lead вNIX, аэто первый выпуск дайджеста для бизнес-аналитиков. Внем вынайдете, намой взгляд, ценные идостойные внимания материалы за прошлый месяц. Enjoy!

В скобках возле заголовков уровень сложности статьи (Normal * Hard Expert ***) и примерное время на изучение материала.

Business Analysis

Sorting Through the Pile: Classifying Customer Requirements (*, 6 мин). Классификация требований от дедушки Вигерса для самых маленьких. Новичкам в помощь, старичкам в радость.

Tactfully rejecting feature requests (**, 9 мин). Каждый из нас попадал в ситуацию, когда приходит очередной важный запрос на фичу, а она не ложится в продукт не помогает реализации бизнес-идеи, ломает архитектуру, не приносит пользы целевой аудитории и так далее. А отказать тому же клиенту неудобно, он же клиент. Так вот, в статье есть рекомендации о том, как просящему понять, почему фича не нужна, через несколько несложных шагов и техник.

Куда пропадают деньги компании, или Как оценить стоимость ошибки в бизнес-процессах (**, 6 мин). В статье рассматривается пример расчета финансовых потерь из-за несовершенства бизнес-процессов, типы ошибок, как их искать и что с ними делать. Актуально для процессных аналитиков, которые взаимодействуют непосредственно с бизнесом. Для остальных не будет вредным для общего развития.

The 10 Attitudes of Outstanding Product Owners (**, 7 мин). Кто еще не сталкивался узнать, а кто знает вспомнить о том, что лежит в основе этой роли. К аналитикам эти принципы относятся в равной степени.

Top 7 Hybrid Business Analysis roles (*, 10 мин). Разбор наиболее частых вариантов совмещения профессий БА+. По полочкам разложено, какие варианты более удачны, а какие скорее нет.

Writing Kick-Ass User Stories (*, 7 мин). Очень короткий, но емкий гайд, расписанный на примере, который поможет быстро погрузиться в процесс написания User Stories.

The Business Value of Better Requirements (*, 6 мин). Свежий материал от дедушки Вигерса на тему почему хорошие требования очень экономят бюджет.

No One Expects the Requirements Inquisition: Asking Next-Level Questions (*, 6 мин). И еще материал от Карла (!). На этот раз о том, какие вопросы помогут углубиться в реальные needs.

Почему важно наглядно доносить информацию. Визуализация данных для бизнес-аналитика (**, 10 мин). Кирилл Белявский из SoftServe рассказывает об актуальности техник визуализации, важности для бизнеса, восприятии визуализации, а также популярных инструментах.

Build effective Minimum Viable Products with the MVP Experiment Canvas (**, 13 мин). Бесплатный фреймворк для структурирования и запуска MVP и валидации бизнес-идеи.

Расширяем кругозор

Как не надо релизить проекты. Работаем с требованиями, оценкой и оплатой (**, 15 мин). Страшные сказки на ночь о нерадивых клиентах, срывах сроков, размытых требованиях, форс-мажорных ситуациях и других бабайках, которыми только и делать, что пугать Junior'ов. Если же серьезно, то в статье много жизненных ситуаций, на которых можно поучиться не совершать чужие ошибки и предвидеть свои.

Lightning Cast: Resistance to Change (*, 4 мин). Выжимка теории по Goldratts Four Quadrants on Change почему сопротивляются изменениям и что с этим делать.

Your Product Has Too Many Features (*, 6 мин). Взгляд на возможные причины захламления фичами на примерах Facebook / Amazon, а также - что с этим делать.

Beware SAFe (the Scaled Agile Framework for Enterprise), an Unholy Incarnation of Darkness (*, 14 мин). Как можно догадаться из названия статьи, автор далеко не фанат SAFe, у которого пригорело. Мне довелось лишь слышать о SAFe, изучать теорию, но использовать ни разу. Тем не менее мне все казалось, что два дня планирования это перебор, ограничивающий команды, хоть мне и были озвучены весомые аргументы за. Автор статьи приводит много аргументов против, в том числе ссылки на Кена Швабера и других лиц, которые высказывали свои опасения на счет SAFe.

Дорогие читатели, кто живет по SAFу? Поделитесь своим мнением в комментариях, будет очень интересно обсудить.

Готумо до запуску продукт. Чек-лист для Product Manager (**, 10 мин). Мария делится опытом и дает нам рабочий инструмент, которым стоит воспользоваться.

A comprehensive list of UX design methods & deliverables (*, 12 мин). Подборка техник по сабжу краткий обзор + ссылки на почитать. Пожалуй, наиболее лаконичный и полный обзор из тех, что встречал.

How to Spot and Prevent Useless Meetings (*, 4 мин). Признаки, с помощью которых вы быстро определите, откуда стоит слинять, либо, если не получится, хотя бы взять ноутбук, чтобы поработать.

IT-словарик для не-айтишников (*, 4 мин). Словарь терминов, которые стоит знать каждому :)

UI cheat sheet: Icon categories + icon style reference guide (**, 21 мин). Очередной шикарный гайд от Тессы Гадд, на этот раз о том, как правильно делать иконки.

Привет! Мое имя Юра Гомон, яBATech Lead вNIX ивот уже 8лет занимаюсь бизнес-анализом, помогая реализовывать веб- имобильные решения для бизнеса, атакже автоматизировать бизнес-процессы. Мое имя кажется Вам знакомым, т.к. недавно я опубликовал на Хабре свой BADigest.

Цель статьи напомнить бизнес-аналитикам ометоде Root Cause Analysis (далее RCA) иподелиться опытом его применения для предотвращения багов.

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

• ABrief History ofRoot Cause Analysis. Истоки появления техники, описание шагов, смежные подходы.

• How toConduct aRoot Cause Analysis. Разбор техники напримере.

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

Кейс первый ополитиках

Вливной enterprise-системе на200+ пользователей все было хорошо: жили нетужили, работали три года после релиза. Новодин прекрасный день при попытке перейти поссылке всистему вместо желаемого результата пользователей ждало угрожающее сообщение

Аналог сообщения, которое увидели пользователи. Оригинал несохранился :) Источник:Bytebitebit

Разумеется, это вызвало, мягко говоря, недоумение. Вглазах пользователей работа оказалась заблокированной. Мало того, что угроза кражи паролей, так еще ипредложение продолжить, ноуже unsafe. Страшно.

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

Почему пользователи видят эту страницу?
Посмотрим А-а, так это заэкспайрился SSL-сертификат, продлим, ивсе будет впорядке.
Апочему это несделали заранее?
Никто непоставил напоминание, атри года быстро пролетели.
Резонно. Как думаете, почему непоставили?
Хм, по-моему, это первый проект, где была потребность виспользовании SSL. Это уже после вас стали сертификаты покупать идругим.
Так это ивдругих системах может случиться?
Пожалуй, пойдем везде проверим, поставим напоминалки ивгайдлайны внутренних систем добавим, что надо незабывать это делать.

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

Что изэтого стоит вынести? Ответственные, те, кто знаком сметодами RCA иFive Whys, нетолько исправили ошибку, ноначали задавать вопросы, чтобы найти истинную причину. Как только это случилось, проблему превентивно закрыли везде, где она могла произойти, тоесть предотвратили баг безопасности вдругих системах. Косвенно это привело ктому, что вкомпании стали уделять еще больше внимания безопасности.

Кейс второй олюдях

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

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

1. Менеджер задокументировал ключевые поинты разговора счеловеком названные импричины.

2. Предположил варианты сосвоего опыта.

3. Собрал доказательства существованию причин, проанализировал.

4. Попытался связать разные причины водну систему, поскольку редко бывает так, чтобы причина была только вчем-то одном.

Граф причин проблемы, воссозданный сослов рассказчика

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

1. Сначала человек стал засиживаться вофисе после работы почти каждый день.

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

3. Следом вместо домашней еды онстал питаться подножным кормом.

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

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

Кейс третий оработе стребованиями

Когда БАвходит впроект, который идет уже некоторое время, первая задача разобраться стребованиями, тоесть провести аудит. Обэтом кейсе яделалдоклад наNIX Multiconfв2019году. Сегодня раскрою некоторые детали того случая сточки зрения применения RCA: как искали причины того, почему впроекте начало появляться много багов.

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

Коммуникация

Невозможно было найти ответ или решение через время. Обсуждение требований велось вAsana, Slack, JIRA, через почту, вонлайн- иофлайн-документах. Среди всех источников небыло единого:

• клиент писал там, где ему было удобно втекущий момент;

• остальные команды неподдержали нашу критику, поскольку имитак норм;

• бюджет наведение SRS, митинг-минуток иструктурирование информации невыделялся.

Наша команда неполучала ответов вовремя. Другие команды непонимали наших вопросов:

• трудности перевода;

• если непинговать, томогли забы(и)вать нам ответить;

• пинговать из-за большой разницы сдвумя другими таймзонами было затруднительно.

Стейкхолдеры

Наша команда получала разную информацию изразных источников.

Небыло обмена решениями сдругими командами:

• небыло четких зон ответственности вплане шаринга информации;

• структурированные минутки исинки команд требовали времени, которое нехотели выделять.

Клиент часто менял требования/ принимал решения. Настолько часто, что одна команда успевала получить одно, авторая уже другое:

• уклиента небыло четкой бизнес-идеи, онстарался быстро адаптироваться под нужды целевой аудитории;

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

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

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

Недожидаясь правок понескольким десяткам других пунктов, ЛПРы состороны команды реорганизовали перечень каналов связи иоставили всего три: обсуждение идей велось вAsana, дизайна итребований всоответствующих каналах Slack, тамже создали канал для общих вопросов. Кроме того, все решения покаждой функции стали фиксировать вJIRA, куда перевели только тетаски, которые должны были идти вразработку. Вдополнение ввели жесткие правила понеизменности скоупа врамках спринта (либо полной приостановке ипланированию спринта снуля) идлительности спринта.

Витоге чудесным образом количество дефектов стало резко уменьшаться. ЛПРы воодушевились успехом ипродолжили вносить изменения, которые также несли положительный результат. Но, как оказалось, положительным оноказался только для нас, т.к. вскоре клиент попрощался снами под предлогом того, что небыл готов ктакому уровню бюрократии :) Если заинтриговал, товдокладе поссылке выше больше подробностей.

Ичто?

Есть вещи, которые вот уже 8лет, смомента как явошел вIT, янеперестаю евангелизировать, поскольку нахожу имприменение либо вижу отражение вокружающем мире. Среди них философияпиши-сокращай, модель Кано, принцип Парето, think out ofthe box итак далее. Как выуже догадались, RCA входит вэтот перечень. Авсе потому, что важнейшая, если непервичная задачаБА заключается втом, чтобы понять почему. Будь топроблемная функция всистеме, ошибки вбизнес-процессах, нюансы человеческого поведения, негативные события вокруг все имеет глубокие корни.

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

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

Всем привет! Встречайте дайджест ссамыми сочными статьями зафевраль.

Вскобках возле заголовков уровень сложности статьи (Normal * Hard Expert ***) ипримерное время наизучение материала

Business Analysis

6Trends Impacting Business Analysis toWatch in2021(*, 5мин). Тренды глазами Delvin Fletcher, President and Chief Executive Officer ofthe IIBA.

Круглый стол Эффективные техники для выявления требований(*, 30мин). Запись доклада Дениса Гобова дляanalyst.by, где были раскрыты такие темы, как Фреймворк процесса выявления требований, Модель Кано иеесвязь стехниками выявления, Классификация техник иКакие техники действительно используют бизнес-аналитики (результаты опросаБА вУкраине).

Уточняем детали проекта методами практической психологии(*, 6мин). Как информация (требования) искажаются при передаче между людьми ичто сэтим делать.

System Analysis Meetup 18/02 отRaiffeisenbank(**, 186мин). Обсуждали, как аналитик может влиять напроцессы вAgile-команде, как использование Agile снижает риски проекта (нонеисключает всех) икак изменилась роль аналитика после цифровой трансформации.

Аудит технчно документац: кому, навщо, як(*, 7мин). Ирина делится снами опытом проведения аудита ивнедрения его результатов.

Чек-лист тестирования требований(*, 11мин). Встатье разобраны основные критерии качества хороших требований напримерах изреальной жизни

Как мыиспользуем Confluence для разработки требований кпродукту(*, 8мин). Шикарная статья, вкоторой рассказывается оприменяемых подходах иплагинах. Очень рекомендую кпрочтению! Апредставленные плагины самый сок, без них жить очень непросто :)

AChecklist For Business Analysis Planning(*, 6мин). Опытный аналитик-ментор делится своим чек-листом для планирования бизнес-анализа.

Расширяем кругозор

Cheatsheet Differences Scrum vsScrumban vsKanban(*, 4мин). Освежаем впамяти основные различия между одними изсамых популярных методологий.

UI-элементы ижесты вмобильных приложениях(*, 3мин). Обзор сабжа сбольшим количеством примеров.

Never Forget aPassword Again(*, 12мин). Эссе, вкотором сделан обзор важности создания сильных паролей каккаунтам, оспособах взлома иметодах защиты.

Personas: AWaste OfMoney And Time(*, 7мин). Критика техники персон, что применять вместо нее икакие риски могут из-за этого выстрелить.

Three drawingsI use toexplain agile(*, 5мин). Отличная статья за2018-й,которая поможет быстро понять суть Agile, апотом показать его ценность клиенту.

How todiscover your customers willingness topay(**, 10мин). Если высделали классный продукт, показали его фокус-группе, которой онпонравился это еще незначит, что вызаработаете много денег. Это значит, что высделали что-то хорошее. Авот будутли заэто платить... Встатье рассматриваются подходы, которые должны помочь выудить изпотенциальных клиентов информацию отом, насколько ваш продукт для них ценен иготовыли они (исколько) платить.

UI-элементы ижесты вмобильных приложениях What does afterUX even mean?(*, 5мин). Абсолютно шикарная статья, которая показывает, как может быть вреден необдуманный UX-design, если слепо повторять паттерны.

The Homer Principle(*, 6мин). Юмористическая ижизненная статья отом, счем придется столкнуться при разработке продукта вконтексте восприятия продукта конечными пользователями. Напримере Гомера Симпсона автор вывел 6принципов, скоторым нужно будет работать.

Почему, чтобы переместить кнопку, нужно две недели(*, 5мин). Навесьма простом примере показано, как впростые запросы вреальности оказываются весьма нетривиальными. Можно взять пример заоснову ипользоваться вследующий раз (применяя квашему случаю), когда клиент удивляется, почему так долго.

Product Owner vs. Business Analyst Demystifying the similarities and the differences(*, 11мин). Годнота изблога Adaptive US одного изпровайдеров обучения для сдачи экзаменов IIBA.

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

Building User Trust InUXDesign(***, 19мин). Статья отом, как провести пользователя отэтапа яовас инеслышал, кто вытакие дообоже, яхочу пользоваться вашим продуктом всю жизнь! спомощью понимания пользователя инекоторых маркетинговых уловок.

Material Design Text Fields Are Badly Designed(*, 6мин). Пост критики (обоснованной, намой взгляд) material design.

State OfGDPR In2021: Key Updates And What They Mean(**, 20мин). Изменения вGDPR икак теперь сэтим жить.

Всем привет! Встречайте свежий дайджест ссамыми сочными статьями заапрель.

Вскобках возле заголовков уровень сложности статьи (Normal * Hard ** Expert ***) ипримерное время наизучение материала.

Business Analysis

Тестирование требований: как янахожу ошибки вбизнес-логике фичи прежде, чем ихзакодят(*, 16мин). Авторка делится опытом тестирования требований через применение Use Case Scenarios.

Product Discovery IsAMindset, Not AProcess(**, 8мин). Автор поясняет, почему непрерывная Discovery-фаза (которая незаканчивается состартом проекта) залог успеха.

Requirements for Implementing Packaged Solutions(**, 6мин). Дедушка Вигерс продолжает нас радовать! Вэтот раз онподелился подходом копределению требований при выборе коробочных решений.

Локализация (адаптация) продукта для работы вновых регионах(*, 6мин). Авторка делится своим опытом поразработке требований клокализации решений напримерах продуктов E-commerce.

Нюансы общения ванглоязычной среде. Часть вторая: small talk(*, 6мин). Продолжение статьи, окоторой упоминалвпрошлом дайджесте. Впродолжении тематики культуры беседы, вовторой части авторка рассказывает обопыте применения small talk.

Что такое бизнес-анализ. Разрушаем мифы оработе BA(*, 11мин). Интересная подборка иразнос самых популярных заблуждений ороли ВА.

Новое как старое. Как провести успешный User Acceptance Testing для Reverse Engineering проекта(**, 12мин). Авторка делится вызовами иопытом работы впроектах пореализации NFR (Functionality) при переносе старой функциональности вновый продукт.

Масштабный проект повнедрению SAP S/4HANA вудаленном режиме: уроки, которые мыусвоили(***, 10мин). Внедрение продуктов, тем более таких крупных как SAP, работа спользователями дело крайне сложное. Вам мало? Добавьте кэтому удаленку! Статья отом, скакими проблемами столкнулись внедряторы икак ихрешали.

Как выбрать уровень статистической значимости для AB-теста икак интерпретировать результат(**, 12мин). Напримерах автор подробно рассматривает результаты различных A/B тестирований икак ихправильно интерпретировать.

Расширяем кругозор

SCRUM: Понимание иприменение фреймворка,часть 1(**, 15мин)ичасть 2(**, 12мин). Автор предлагает формализованный подход для оценки зрелости команды/ компании при внедрении SCRUM. Как минимум это свежий взгляд наиспользование методологии, как максимум потенциально зрелый подход квнедрению. Нужно тестить :)

The Search Before the Search: Keyword Foraging(*, 5мин). Бывалоли увас так, что прежде чем что-либо загуглить, выгуглили как это называется? Еслида, тостатья познакомит вас стермином keyword foraging, который объясняет это явление.

Bringing product thinking toany team(**, 8мин). Статья отом, как ставить потребности пользователей вцентр внимания. Автор делится опытом применения продуктового мышления для оптимизации работы команды навсех этапах проекта.

Comprehensive anatomy ofall Design Thinking workshops(*, 16мин). Встатье рассмотрены наиболее популярные виды воркшопов для создания хорошего UI/UXс применением дизайн-мышления.

IsYour UIMessy? 7Common Mistakes toAvoid(*, 12мин). Автор подробно рассказывает отом, почему нельзя игнорировать мелкие детали, как избежать грязи впользовательском интерфейсе исделать UXкомфортнее.

10Psychological rulesI used tomake users love atfirst sight(**, 8мин). Автор делится рядом подходов, которые ониспользует для расположения пользователей кпродукту навербально-психологическом уровне.

Аунас нет мышей! Амызаведём... Какая польза отархитектора решений(*, 9мин). Обзор роли архитектора решений изачем эта роль нужна.

Designing toreduce the users mental burden(*, 7мин). Хороший продукт невынуждает пользователей думать отом, как импользоваться. Карл Вигерс приводит примеры когда мелкая недоработка создает лишнюю умственную нагрузку ивызывает дискомфорт.

How ToBake Layers OfAccessibility Testing Into Your Process(**, 15мин). Accessibility-эксперты делятся опытом внедрения accessibility-тестирования впроцесс разработки цифровых продуктов.

Introducing FigJam(*, 4мин). Обзор новой коллаборативной фичи для Figma отразработчика инструмента.

Best practice for date-of-birth form fields(*, 6мин). Разбор наиболее удачных, помнению автора, паттернов реализации поля date ofbirth.

Designing for the autistic community(*, 7мин). Вовремя создания продукта, мыпомним обособенностях портрета пользователя, который заточен под большинство наших юзеров. При этом, нередко мызабываем пользователях сособыми потребностями. Встатье авторка описывает принципы создания интерфейсов сфокусом налюдей срасстройствами аутистического спектра.

Designing for Dyslexia(*, 5мин). Вкопилочку кпредыдущей статье как вразработке интерфейса учесть потребности пользователей, страдающих дислексией.

10Figma Tricks IWish IKnew Earlier(*, 4мин). Подборка хаков Figma окоторыхвы, возможно, неслышали.

The UI& UXtips collection,часть 1(*, 14мин)ичасть 2(*, 9мин). Шикарная подборка из34 + 18советов посабжу.

Этический антидизайн: как разработать продукт, невызывающий привыкания(*, 10мин). Антидизайн средство для защиты отдурака инетолько.

Best Practices For Modal Window Design(*, 9мин). Автор делится 9незамысловатыми принципами для оптимизации проектирования модальных окон.

Ближайшие события, курсы

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

19мая состоится бесплатная онлайн-лекцияBA&UX: взаимодействие сускорением. Входе лекции выузнаете рекомендации для построения дизайн-процесса, атакже отехниках BA&UX.

29мая состоится платная конференция для бизнес-аналитиков. Вас ждут доклады 6спикеров изУкраины иЛатвии, скоторыми высможете коммуницировать иполезно провести время вкругу коллег.

Всем привет! Встречайте свежий дайджест ссамыми сочными статьями замай.

Вскобках возле заголовков уровень сложности статьи (Normal * Hard ** Expert ***) ипримерное время наизучение материала

Business Analysis

Подкаст. MBA220: Thoughtless Design with Karl Wiegers(**, 32мин). Карл Вигерс продолжает радовать нас своим опытом. Вэтот раз онделится принципами иуроками, которые извлек изнекачественного дизайна, атакже рассказывает, чтоВы можете сделать, чтобы помочь всоздании дизайна.

Нужнали сертификация для бизнес-аналитика?(**, 10мин). Все осертификацииВА: список популярных, какие преимущества каждая даёт инужнали сертификация вообще.

Docs asCode: введение впредмет(**, 21мин). Автор делится многолетним опытом, приобретенным напути кDocs asCode, атакже рекомендациями повнедрению этого фреймворка.

Business Analyst: Tools and Principles for Professional Self-Development(*, 16мин). Структурированный набор материалов, который поможет обнаружить изаполнить пробелы всвоих навыках. Статью готовил аналитик с15+лет опыта, всоавторстве сдругими опытными БА.

Как проводить интервью сзаказчиком(*, 11мин). Кирилл Белявский делится секретом проведения успешных интервью.

User Experience inProduct(*, 8мин). Как исследования ианализ пользователей помогут увеличить значимость вашего продукта для конечных пользователей.

Моделирование данных: обзор(**, 6мин). Встатье автор раскрывает понятие моделирование данных, атакже делится оптимальной пошаговой инструкцией поприменению.

Цикл статей про бизнес-анализ напресейле. Статья первая, или почему всем нужен БА?(*, 5мин). Старт цикла статей ороли изадачах бизнес-аналитика напресейле. Впервой части: что такое пресейл, роль ивлияние бизнес-аналитика наэтом этапе, артефакты, которые могут понадобиться.

Расширяем кругозор

Этический антидизайн. Разработка продуктов, которые невызывают привыкания(*, 6мин). Оглавных принципах антидизайна, атакже когнитивных искажениях, которые располагают кзалипанию набесполезной/произвольной информации.

SCRUM: Гибкое управление продуктовыми направлениями(*, 9мин). Третья часть изцикла статей, окотором говорил впрошлом дайджесте. Вэтой части предложена система метрик для измерения ианализа процесса гибкого управления продуктовыми направлениями.

Frustrating Design Patterns That Need Fixing: Birthday Picker(*, 16мин). Подробный обзор неудачных шаблонов проектирования поля для выбора даты рождения.

Как работать сбэклогом иприоритизацией фич взрелом продукте(*, 8мин). CTO одной изпродуктовых компаний делится опытом приоритезации фич врамках канбан-процесса.

Three Levels ofPain Points inCustomer Experience(*, 8мин). Что такое болевые точки вклиентском опыте, накаких уровнях взаимодействия возникают ипонять какие наиболее критичны.

Left-Side Vertical Navigation onDesktop: Scalable, Responsive, and Easy toScan(*, 12мин). Статья овесьма непривычном подходе кпостроению навигации, когда она находится невшапке сайта, анаместе левой боковой панели: каким доменам подходит, преимущества ирекомендации поиспользованию.

Все, что выхотели знать про диалоговый UX/UIв проектировании чат-ботов(*, 9мин). Встатье покрыто определение диалогового UX/UI-дизайн, есть пошаговые рекомендации счего начать, атакже годные лайфхаки для проектирования сценариев для чат-бота.

Какие рефералки работают: сбонусами для себя, для того парня или для обоих? Исследование(*, 4мин). Саммари исследования видов рефералок.

The role ofpassword verification atsign up(*, 7мин). Анализ практик реализации поля ввода пароля.

UX-Roadmapping Workshops: Agenda + Activities(**, 16мин). Содержательная статья осоздании дорожных карт UX.

6способов снизить когнитивную нагрузку отинтерфейса(**, 12мин). Если вычувствуете, что ваш интерфейс перегружен, тоэта статья подкинет вам инсайтов отом, как сохранить нервные клетки ваших пользователей.

UI& UXmicro-tips: Volume five(*, 4мин). Коллекция небольших, нополезных подсказок поUI/UX.

Постановка задачи

Многие слышали о ROC-кривой, которая часто используется в ML. Расшифровывая данную аббревиатуру мы получаем, что ROC (англ. receiver operating characteristic). При переводе с английского это означает РХП (рабочая характеристика приемника). Данное понятие позаимствовано из теории обнаружения сигналов. ROC-кривую можно связать с радиолокационной станцией (РЛС), рассматривая ее с точки зрения обнаружения объекта. Опишем это более формально.

РЛС посылает импульсы, которые отражаются от объектов. Отражённый сигналвоспринимается приёмной антенной радара (Рис. 1). Если есть какой-либо объект, находящийся в зоне обнаружения (ЗО), то отраженный сигнал будет выше порога детектированияи это будет означать наличие объекта. Если отражённый сигнал ниже порога детектирования, то это означает отсутствие объекта.

Наличие объекта обозначим как гипотеза, а его отсутствие как гипотеза. Сигнал это непрерывная случайная величина. Предположим, что мы имеем условные распределения, которые нам известны.

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

Учитывая отклонения , возникающие из-за шума, получаем:

На Рис. 2 есть условные математические ожидания случайной величиныпри условии гипотезы исоответственно. При этом, согласно, получаем, что .

Как уже было сказано ранее, сигнал сравнивается с неким порогом, который мы обозначили как . Решение о том есть ли объект в ЗО РЛС или нет обозначим как и соответственно. Дополняя Рис. 2 и, получаем:

Получаем следующие условные вероятности:

Условные вероятностиможно интерпретировать так:

• есть вероятность обнаружения объекта при условии, что выполняется гипотеза , т.е. объект действительно находится в ЗО.

• есть вероятность ложной тревоги, т.е. мы утверждаем , которое означает принятие решения о наличии объекта в ЗО, когда в действительности выполняется, т.е. объекта в ЗО нет.

Визуализируя интегралы , получаем:

Очевидно, что с уменьшением порогаплощадь под кривыми будет больше, а значит, чтоибудут увеличиваться.

Кривая, показывающая зависимость как функцию от для различных , называется ROC-кривая (англ. Receiver Operating Characteristic, рабочая характеристика приёмника).

Дисперсия случайной величиныопределяется характеристикой Отношение сигнал-шум (ОТШ, англ. Signal-to-Noise Ratio, сокр. ), которая записывается как:

• мощность сигнала;

• мощность шума.

Принимая в , а дисперсия, получаем:

ПостроениеROC-кривых и их анализ

Пусть заданы следующие начальные условия:

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

Из диапазона мы можем понять, какой у нас диапазон дисперсии . Для этого выразим из :

Подставляя граничные точки отрезка из , получаем:

Зададим вектор значений для построения ROC-кривой для каждого из них:

Шаг изменения значений вектора возьмем равным , т.е. . Определим теперь ROC-кривую как параметрическую функцию от , где в качестве параметра выступает . Из и , получаем:

задает конкретную ROC-кривую из семейства ROC-кривых.

Зададим теперь вектор значений :

Шаг изменения значений вектора возьмем равным , т.е. . Вектор содержит значение, т.е. имеем точку для каждого графика. Таким образом, графики будут визуально выглядеть гладкими.

Имеющихся данных достаточно для построения ROC-кривых.

Воспользуемся для этого языком Python.

# подключение дополнительных библиотекfrom scipy.stats import normfrom scipy.misc import derivativeimport numpy as npimport pandas as pdimport matplotlib.pyplot as pltimport seaborn as sns; sns.set()%matplotlib inline

# зададим вектор SNR и lambdaSNR_values = np.arange(-1, 5.5, 1/2) lambda_values = np.arange(0, 1.01, 1/100) # функция, которая возвращает значение sigma по заданному значению SNRdef snr_to_sigma(SNR):    return np.power(10, -SNR/20)  # функция, которая возвращает значения Pfa и Pd по заданным sigma и lambdadef roc_curve(sigma, lambda_):    return 1 - norm.cdf(lambda_/sigma), 1 - norm.cdf((lambda_ - 1)/sigma)# создание DataFrame в котором будут храниться значения Pfa, Pd, SNRdata = []for SNR in SNR_values:    for lambda_ in lambda_values:        Pfa, Pd = roc_curve(snr_to_sigma(SNR), lambda_)        data.append([Pfa, Pd, str(SNR)])        data = pd.DataFrame(data, columns=['Pfa', 'Pd', 'SNR'])

fig, ax = plt.subplots(figsize=(18, 14))sns.set_context('poster')plt.title('$ROC$-кривые в зависимости от значения $SNR$', fontsize=40)plt.xlabel('$P_{fa}$', fontsize=40)plt.xticks(np.arange(0, 0.7, 0.05), fontsize=30)plt.yticks(np.arange(0.5, 1, 0.05), fontsize=30)plt.ylabel('$P_d$', fontsize=40, rotation=0, labelpad=40)sns.lineplot(x='Pfa', y='Pd', hue='SNR',              data=data, palette='gist_ncar', ax=ax)ax.annotate("Возрастание $\lambda$", xy=(0.15, 0.81),  xycoords='data',            xytext=(90, 150), textcoords='offset points',            size=30, ha='left',             arrowprops=dict(arrowstyle="->", color='black',                            connectionstyle="arc3,rad=0.1"))plt.grid(color='black', linestyle='--', linewidth=1, alpha=0.3)plt.legend(fontsize='small', shadow=True, title='$SNR(dB)$',           borderpad=0.9, fancybox=True);

Из графика видно следующее:

1. Все кривые начинают свое движение с линии и заканчивают на линии ;

2. Чем больше значение , тем ближе ROC-кривая к точке ;

3. Все кривые выпуклы вверх;

4. ROC - кривая монотонно не убывает. Чем выше лежит кривая, тем лучше качество РЛС.

Первое объясняется ограниченностью значения порога детектирования . Посмотрим, как будут выглядеть ROC-кривые, если увеличить диапазон , например, до .

# создание DataFrame в котором будут храниться значения Pfa, Pd, SNRdata2 = []for SNR in SNR_values:    for lambda_ in np.arange(-10, 10.1, 1/10) :        Pfa, Pd = roc_curve(snr_to_sigma(SNR), lambda_)        data2.append([Pfa, Pd, str(SNR)])        data2 = pd.DataFrame(data2, columns=['Pfa', 'Pd', 'SNR'])

fig, ax = plt.subplots(figsize=(18, 14))sns.set_context('poster')plt.title('$ROC$-кривые в зависимости от значения $SNR$', fontsize=40)plt.xlabel('$P_{fa}$', fontsize=40)plt.xticks(np.arange(0, 1.05, 0.1), fontsize=20)plt.yticks(np.arange(0, 1.05, 0.1), fontsize=20)plt.ylabel('$P_d$', fontsize=40, rotation=0, labelpad=40)sns.lineplot(x='Pfa', y='Pd', hue='SNR',              data=data2, palette='gist_ncar', ax=ax)ax.annotate("Возрастание $\lambda$", xy=(0.15, 0.81),  xycoords='data',            xytext=(90, 110), textcoords='offset points',            size=20, ha='left',             arrowprops=dict(arrowstyle="->", color='black',                            connectionstyle="arc3,rad=0.1"))plt.grid(color='black', linestyle='--', linewidth=1, alpha=0.3)plt.legend(fontsize='small', shadow=True, title='$SNR(dB)$',           borderpad=0.9, fancybox=True);

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

# функция, которая возвращает значение условных плотностей в зависимости от sigma def conditional_density(x, sigma):    return norm.pdf(x/sigma), norm.pdf((x - 1)/sigma)      # создание DataFrame в котором будут храниться значения условных плотностей и SNRdata3 = []x_range = np.linspace(-5, 5, 100)for SNR in SNR_values:    for x in x_range :        cond_dens1, cond_dens2 = conditional_density(x, snr_to_sigma(SNR))        data3.append([cond_dens1, cond_dens2, str(SNR), x])        data3 = pd.DataFrame(data3, columns=['cond_dens1', 'cond_dens2', 'SNR', 'x'])

fig, ax = plt.subplots(figsize=(20, 10))sns.set_context('poster')plt.title('Условные распределения в зависимости от значения $SNR$',           fontsize=30)plt.xlabel('$x$', fontsize=40)plt.xticks(np.arange(-5, 5.5, 0.5), fontsize=20)plt.yticks(np.arange(0, 0.45, 0.05), fontsize=20)plt.ylabel('Значение условной плотности', fontsize=20,            labelpad=30)sns.lineplot(x='x', y='cond_dens2', hue='SNR',              data=data3, palette='gist_ncar', ax=ax)sns.lineplot(x='x', y='cond_dens1', hue='SNR',              data=data3, palette='gist_ncar', ax=ax, legend=False)ax.legend(fontsize='small', shadow=True, title='$SNR(dB)$',           borderpad=0.9, fancybox=True, loc='upper left')ax.annotate("$f_{X|H_0}(x|H_0)$", xy=(-0.6, 0.35),  xycoords='data',            xytext=(-90, 20), textcoords='offset points',            size=30, ha='right',             arrowprops=dict(arrowstyle="->", color='black',                            connectionstyle="arc3,rad=0.1"))ax.annotate("$f_{X|H_1}(x|H_1)$", xy=(1.6, 0.35),  xycoords='data',            xytext=(100, 20), textcoords='offset points',            size=30, ha='left',             arrowprops=dict(arrowstyle="->", color='black',                            connectionstyle="arc3,rad=0.1"))plt.grid(color='black', linestyle='--', linewidth=1, alpha=0.3);

По Рис. 7 видно, что при увеличении , кривые становятся уже, а, значит, пересекаются в меньшей степени. Посмотрим теперь на зависимость вероятности обнаружения от :

data4 = []for SNR in SNR_values:    for lambda_ in lambda_values:        Pfa, Pd = roc_curve(snr_to_sigma(SNR), lambda_)        data4.append([Pfa, Pd, str(SNR), lambda_])        data4 = pd.DataFrame(data4, columns=['Pfa', 'Pd', 'SNR', 'lambda'])

fig, ax = plt.subplots(figsize=(16, 12))sns.set_context('poster')plt.title('Кривые $P_d$ от $\lambda$ при разных $SNR$', fontsize=40)plt.xlabel('$\lambda$', fontsize=40)plt.xticks(np.arange(0, 1.05, 0.1), fontsize=20)plt.yticks(np.arange(0.5, 1.05, 0.1), fontsize=20)plt.ylabel('$P_d$', fontsize=40, rotation=0, labelpad=40)sns.lineplot(x='lambda', y='Pd', hue='SNR',              data=data4, palette='gist_ncar', ax=ax)ax.annotate("Возрастание $\lambda$", xy=(0.5, 0.85),  xycoords='data',            xytext=(-10, 50), textcoords='offset points',            size=20, ha='right',             arrowprops=dict(arrowstyle="->", color='black',                            connectionstyle="arc3,rad=-0.2"))plt.grid(color='black', linestyle='--', linewidth=1, alpha=0.3)plt.legend(fontsize='small', shadow=True, title='$SNR(dB)$',           borderpad=0.9, fancybox=True);

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

fig, ax = plt.subplots(figsize=(16, 12))sns.set_context('poster')plt.title('Кривые $P_{fa}$ от $\lambda$ при разных $SNR$', fontsize=40)plt.xlabel('$\lambda$', fontsize=40)plt.ylabel('$P_{fa}$', fontsize=40, rotation=0, labelpad=40)sns.lineplot(x='lambda', y='Pfa', hue='SNR',              data=data4, palette='gist_ncar', ax=ax)ax.annotate("Возрастание $\lambda$", xy=(0.5, 0.35),  xycoords='data',            xytext=(-10, 90), textcoords='offset points',            size=30, ha='right',             arrowprops=dict(arrowstyle="->", color='black',                            connectionstyle="arc3,rad=0.2"))plt.grid(color='black', linestyle='--', linewidth=1, alpha=0.3)plt.legend(fontsize='small', shadow=True, title='$SNR(dB)$',           borderpad=0.9, fancybox=True);

При получается, что вероятность ложной тревоги равна , так как определенный интеграл от условной плотности распределения

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

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

Пусть

тогда:

Исследуем функцию :

Из и следует, что тангенс угла наклона ROC-кривой монотонно изменяется от до при от до . Таким образом, начиная построение графика от и, следовательно, . Заканчивается все в точке , когда , т.е. (касательная в данной точке перпендикулярна оси абсцисс).

# функция, которая возвращает значения Pfa и Pd по заданным sigma и lambdadef dif_roc_curve(sigma, lambda_):    return (derivative(lambda x: 1 - norm.cdf(x/sigma), lambda_, dx=1e-10),           derivative(lambda x: 1 - norm.cdf((x - 1)/sigma), lambda_, dx=1e-10))data5 = []for SNR in SNR_values:    for lambda_ in [0, 0.5, 1]:        dPfa, dPd = dif_roc_curve(snr_to_sigma(SNR), lambda_)        Pfa, Pd = roc_curve(snr_to_sigma(SNR), lambda_)        tan = dPd/dPfa        for i in np.arange(0.01/tan, 0.2/tan, 0.01/tan):            data5.append([tan*(i - Pfa) + Pd, i, str(SNR), lambda_])        data5 = pd.DataFrame(data5, columns=['y', 'x', 'SNR', 'lambda'])

fig, ax = plt.subplots(figsize=(18, 14))sns.set_context('poster')plt.title('$ROC$-кривая с $3^{мя}$ касательными', fontsize=40)plt.xlabel('$P_{fa}$', fontsize=40)plt.xticks(np.arange(0, 1.05, 0.1), fontsize=20)plt.yticks(np.arange(0, 1.05, 0.1), fontsize=20)plt.ylabel('$P_d$', fontsize=40, rotation=0, labelpad=40)sns.lineplot(x='Pfa', y='Pd', hue='SNR', legend=False,             data=data[data['SNR']  == '5.0'], palette='gist_ncar', ax=ax)sns.lineplot(x='x', y='y', hue='lambda', linestyle='--',             data=data5[data5['SNR']  == '5.0'],              palette='dark:b', legend=True,  ax=ax)plt.grid(color='black', linestyle='--', linewidth=1, alpha=0.3)plt.legend(fontsize='small', shadow=True, title='Касательная для $\lambda=$',           borderpad=0.9, fancybox=True, loc=4);

На рис. 10 рассматриваются точки .

Вывод

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

Использованная литература

• Ван-Трис Гарри Л. Теория обнаружения, оценок и модуляции. Том 1. Теория обнаружения, оценок и линейной модуляции -Нью-Йорк, 1968, Пер, с англ. , под ред. проф. В. И. Тихонова. М., Советское радио, 1972, 744 с.

• Тяпкин В.Н. Основы построения радиолокационных станции радиотехнических воиск: учебник / В.Н. Тяпкин, А.Н. Фомин, Е.Н. Гарин [и др.]; под общ. ред. В.Н. Тяпкина. Красноярск : Сиб. федер. ун-т. 2011. 536 с.

Дополнительно

Ссылка на github с исходным кодом.

Регистрируемся в Scrutinizer

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

Для установки приложения Scrutinizer переходим по ссылке, этот шаг можно пропустить, но имейте ввиду, что в дальнейшем у вас не будут работать интерактивные плюшки и будет висеть нотификация: Scrutinizer GitHub App Is Not Installed...

Даем ему все скоупы, которые требует. Не бойтесь, Scrutinizer не удалит ваши репозитории и никак вам не навредит. Это нужно для того, чтобы приложение могло общаться с вашим GitHub по АПИ и в real-time управлять вашим Check Suite, давая ему обратную связь, и кодом в ваших PR для удобства ревью и тд.

Создаем глобальную конфигурацию

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

Чтобы создать глобальную конфигурацию перейдите по ссылке.

build:    environment:        php: 7.3.15build_failure_conditions:  - 'project.metric_change("scrutinizer.quality", < -0.10)'  - 'elements.rating(<= D).exists'                                # No classes/methods with a rating of D or worse  - 'elements.rating(<= D).new.exists'                            # No new classes/methods with a rating of D or worse allowed  - 'issues.label("coding-style").exists'                         # No coding style issues allowed  - 'issues.label("coding-style").new.exists'                     # No new coding style issues allowed  - 'issues.severity(>= MAJOR).new.exists'                        # New issues of major or higher severity                          - 'project.metric("scrutinizer.quality", < 9)'                  # Code Quality Rating drops below 9  - 'patches.label("Doc Comments").exists'                        # No doc comments patches allowed  - 'patches.label("Spacing").exists'                             # No spacing patches allowedchecks:    php:        verify_property_names: true        verify_argument_usable_as_reference: true        verify_access_scope_valid: true        variable_existence: true        useless_calls: true        use_statement_alias_conflict: true        unused_variables: true        unused_properties: true        unused_parameters: true        unused_methods: true        unreachable_code: true        too_many_arguments: true        symfony_request_injection: true        switch_fallthrough_commented: true        sql_injection_vulnerabilities: true        simplify_boolean_return: true        security_vulnerabilities: true        return_in_constructor: true        return_doc_comments: true        return_doc_comment_if_not_inferrable: true        require_scope_for_methods: true        require_php_tag_first: true        remove_extra_empty_lines: true        property_assignments: true        properties_in_camelcaps: true        precedence_mistakes: true        precedence_in_conditions: true        phpunit_assertions: true        parse_doc_comments: true        parameters_in_camelcaps: true        parameter_non_unique: true        parameter_doc_comments: true        param_doc_comment_if_not_inferrable: true        overriding_private_members: true        overriding_parameter: true        non_commented_empty_catch_block: true        no_trait_type_hints: true        no_trailing_whitespace: true        no_short_variable_names:            minimum: '3'        no_short_open_tag: true        no_short_method_names:            minimum: '3'        no_property_on_interface: true        no_non_implemented_abstract_methods: true        no_long_variable_names:            maximum: '20'        no_goto: true        no_exit: true        no_eval: true        no_error_suppression: true        no_debug_code: true        naming_conventions:            local_variable: '^[a-z][a-zA-Z0-9]*$'            abstract_class_name: ^Abstract|Factory$            utility_class_name: 'Utils?$'            constant_name: '^[A-Z][A-Z0-9]*(?:_[A-Z0-9]+)*$'            property_name: '^[a-z][a-zA-Z0-9]*$'            method_name: '^(?:[a-z]|__)[a-zA-Z0-9]*$'            parameter_name: '^[a-z][a-zA-Z0-9]*$'            interface_name: '^[A-Z][a-zA-Z0-9]*Interface$'            type_name: '^[A-Z][a-zA-Z0-9]*$'            exception_name: '^[A-Z][a-zA-Z0-9]*Exception$'            isser_method_name: '^(?:is|has|should|may|supports)'        more_specific_types_in_doc_comments: true        missing_arguments: true        method_calls_on_non_object: true        instanceof_class_exists: true        foreach_usable_as_reference: true        foreach_traversable: true        fix_use_statements:            remove_unused: true            preserve_multiple: false            preserve_blanklines: false            order_alphabetically: false        fix_line_ending: true        fix_doc_comments: true        encourage_shallow_comparison: true        duplication: true        deprecated_code_usage: true        deadlock_detection_in_loops: true        comparison_always_same_result: true        code_rating: true        closure_use_not_conflicting: true        closure_use_modifiable: true        check_method_contracts:            verify_interface_like_constraints: true            verify_documented_constraints: true            verify_parent_constraints: true        catch_class_exists: true        call_to_parent_method: true        avoid_superglobals: true        avoid_length_functions_in_loops: true        avoid_entity_manager_injection: true        avoid_duplicate_types: true        avoid_closing_tag: true        assignment_of_null_return: true        argument_type_checks: true

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

build_failure_conditions:  - 'project.metric_change("scrutinizer.quality", < -0.10)'  - 'elements.rating(<= D).exists'  - 'elements.rating(<= D).new.exists'   - 'issues.label("coding-style").exists'   - 'issues.label("coding-style").new.exists'                - 'issues.severity(>= MAJOR).new.exists'                                       - 'project.metric("scrutinizer.quality", < 9)'  - 'patches.label("Doc Comments").exists'  - 'patches.label("Spacing").exists' 

Хотел бы отметить, всегда указывайте ваше окружение (версию PHP, базы данных и тд), т.к. значения по умолчанию могут меняться и ваши сборки в один прекрасный день будут зафейлены. Что собственно и приключилось со мной буквально на днях, когда релизнулся PHP 8.0.1.

Настройка репозитория

По сути мы просто добавляем свой репозиторий с GitHub, для этого переходим по ссылке.

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

Далее идем в настройки вашего репозитория, которые находятся вот тут:
https://scrutinizer-ci.com/g/ваш-логин/название-репозитория/settings

Настройка Check Suite

Тут немного остановимся и я расскажу почему.

Дело в том, что сборки Scrutinizer довольно медленные, даже для одного окружения сборка с анализом и покрытием может длиться минут 20.

За это время ваши обычные проверки в GitHub CI уже могут быть пройдены, линтеры показали ваши ошибки или вы вспомнили, что что-то забыли, и успеели толкнуть пару-тройку коммитов до завершения сборки Scrutinizer.

Tracking Settings

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

• Pull-Request Tracking - отвечает за запуск сборок только для Pull-реквестов в основную ветку.

• Pull-Request Notification - отвечает за то, как вы хотите узнавать о результатах сборки и анализа, например, через GitHub Check Suite.

• Tracked Branches - отвечает за запуск сборок при пушах. Рекомендую, выставить опцию "Track only branches listed below" и указать вашу основную ветку.

Auto-Cancel Non-Finished Inspections

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

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

Настройка конфигурации репозитория

Переходим по ссылке:
https://scrutinizer-ci.com/g/ваш-логин/название-репозитория/settings/build-config

Важно выбрать вашу глобальную конфигурацию.

build:    nodes:        coverage:            services:                postgres: 12            tests:                override:                    -                        command: |                            sed -e "s/\${USERNAME}/scrutinizer/" \                                -e "s/\${PASSWORD}/scrutinizer/" \                                -e "s/\${DATABASE}/scrutinizer/" \                                -e "s/\${HOST}/127.0.0.1/" \                                phpunit.xml.dist > phpunit.xml                            ./vendor/bin/phpunit \                                --verbose  \                                --stderr  \                                --coverage-clover build/logs/clover.xml \                                --coverage-text                        coverage:                            file: build/logs/clover.xml                            format: clover        analysis:            tests:                override:                    - php-scrutinizer-run                    -                        command: phpcs-run                        use_website_config: true    cache:        disabled: true        directories:            - vendor/filter:    excluded_paths:        - 'tests/*'

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

<?xml version="1.0"?><ruleset>    <file>./</file>    <exclude-pattern>./vendor/*</exclude-pattern>    <exclude-pattern>./tests/*</exclude-pattern>    <exclude-pattern>./.github/*</exclude-pattern>    <rule ref="PSR1" /></ruleset>

А в ваш composer.json в секцию require-dev добавьте:

"squizlabs/php_codesniffer": "^3.5"

Начало работы

Теперь, давайте толкнем коммит в основную ветку и посмотрим, как выглядит Check Suite со Scrutinizer.

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

Интерактив от Scrutinizer в ревью

После интеграции и успешно пройденной сборки в Scrutinizer появится три кнопки: Code Intelligence, Issues и Coverage.

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

При наведении на методы и переменные Code Intelligence подсвечивает типы возвращаемых значений, а зеленые маркеры справа от нумератора строк сообщают о покрытии тестами.

В целом, это удобно, хотя я к Code Intelligence еще не привык.

Итог

Я буду рад, если мой опыт был вам полезен и вот такие красивые отчеты вас будут мотивировать писать совершенный код.

Если у вас что-то не получилось с первого раза, не отчаивайтесь.

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

Ну а если, вы все же отчаялись и у вас ничего не получилось, мои контакты открыты для вас, напишите мне, и мы вместе решим вашу проблему.

Сегодня OZON опубликовал данные опроса среди покупателей, посвященного дню всех влюбленных. Маркетплейс опросил несколько тысяч человек от 18 до 45 лет, проживающих в городах-миллионниках. Главный вывод - Валентина помнят, а родных - любят. 73% ответили, что будут отмечать 14 февраля. Еще во время опроса OZON не постеснялся уточнить какие подарки влюбленные считают ужасными. Мы проанализировали спрос на эти товары и узнали скольким придется смириться с носками и гелем для душа.

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

Неудачные подарки ко Дню всех влюблённых по мнению покупателей OZON:

- 18% опрошенных не хотели бы получить в качестве сюрприза валентинки, цветы, мягкие игрушки и носки;

- 10% респондентов не в восторге от конфет и сладостей;

- 5% ответивших против одежды и тапочек в качестве подарка;

- меньше всего - 4% опрошенных - отрицают гели для душа и дезодоранты в качестве презента.

Мы оценили спрос на нежелательные товары за период с января по февраль 2021 года. Данные за 2020 год решили не рассматривать, потому что они искажены взрывным предновогодним ажиотажем. Вряд ли, люди покупают подарки ко Дню всех любленных в декабре. Ухватить подарок коллегам к 8 марта на новогодней распродаже еще можно, но так экономить на второй половинке - странно.

Анализ спроса и выручки мы провели взяв за основу данные маркетплейса OZON. Площадка проводила опрос среди своих покупателей и будет правильным оценивать их поведение. Для сбора статистики мы использовали сервис аналитики маркетплейсов SellerFox.

Купаемся в деньгах

Возвращаемся от слов к делу. Изучаем данные категории Гели для душа. В 4% ответов респонденты заявили OZON, что не хотят получать такой подарок на 14 февраля. Мы тоже не хотели бы, но график подсказывает, что выбирать не придется. С начала января кривые спроса и выручки стремиться вверх.Продажи просели лишь однажды, когда продавцы резко подняли цены. Уверены, в скором будущем, большие цены трансформируются в гигантские скидки.

В начале января дневная выручка от продажи гелей для душа составляла 500-600 тысяч рублей, а сегодня приблизилась к 1 000 000 рублей. За неделю с 4 по 9 февраля категория принесла селллерам почти 4 миллиона рублей.

Если интересно, какой продавец заработал на гелях для душа больше, знайте - это сам OZON. За месяц площадка получила от продажи таких товаров 7 733 534 рубля. Из них почти 2 миллиона маркетплейс сделал за последние 7 дней - в 2 раза больше, чем доход от аналогичных товаров в первую неделю января.

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

Штопаем дырки в бюджете

Вернемся к мнению покупателей. Около 18% опрошенных заявили OZON, что не считают носки достойным подарком для признания в любви. Сколько в этой цифре кроется мужчин и женщин? Такую информацию мы пока не анализировали, зато собрали статистику по спросу и выручке в категории "Носки". Для начала посмотрели на данные более очевидного сегмента, который является вложением в категорию "Мужская одежда". Всматриваемся в мужские носки.

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

На самом деле, два миллиона в день на носках - это не шутки, а наглядная статистика. А еще посмотрите - в этой гонке OZON не добрался до первого места и заработал за месяц лишь 1 531 806 рублей. У лидера в кошельке оказалось 12 574 064 рубля.

Кстати, топ товаров среди мужских носков выглядит объяснимо. Посмотрите: покупатели отдают предпочтение комплектам товаров. Да, пусть такие носки стоят от 2 до 6 тысяч рублей, зато штопать их точно не нужно. Будем считать, что так выглядят "народные" инвестиции.

Если с мужскими носками все понятно - эта тема давно стала основной для мемов, шуток и анекдотов, то что с аналогичными женскими аксессуарами? Смотрим статистику продаж таких товаров за месяц - анализируем категорию "Чулки, носки и колготки". Показатели продаж и выручки стабильны, но ближе к концу месяца начинают тянуться вниз. Девушки, вполне возможно, могли закупиться носочками на январских распродажах, а молодые люди просто не считают их хорошим подарком. И даже при этом, за последнюю неделю февраля, женские аксессуары продавались в среднем на 300 000 рублей в день.

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

Кстати, OZON в этой категории снова не победил. В анализируемой нише больше всего выручки получил "Декатлон" - 1 947 876 рублей. Его ближайший конкурент заработал чуть больше 1,5 млн. рублей, а сам маркетплейс всего 882 551 рубль. Ну что, поможем OZON и подарим носки вторым половинкам?

Растаптываем выручку

Идем дальше: 5% опрошенных OZON заявили, что не хотели бы получить в подарок на День всех влюбленных тапочки. Были прецеденты? В нашей практике таких подарков не встречалось, потому проверить спрос на этот аксессуар интересно. Другое дело, что тапочки могут покупать не только для дома, но и, например, для поездки в больницу. Так что давайте просто проверим - есть ли деньги в этой категории товаров. Кстати, пока вы читаете эти строки, мы тоже не знаем ответа. Данные проанализируем сразу после того как поставим в следующем предложении точку. Сгораем от нетерпения.

Анализировать будем сразу две категории, потому что "Тапочки" можно встретить как среди мужской, так и среди женской одежды. Смотрим на выборку товаров "Домашняя обувь", вложенную в большую категорию "Мужская одежда" - здесь продаются тапочки. Видно, что спрос на такие аксессуары не велик. Средняя дневная выручка продавцов за последний месяц составила меньше 100 тысяч рублей, а лидер продаж заработал с 12.01 по 11.02 всего 63 552 рубля. Взгляните на топовый товар - он не похож ни на подарок, ни на предмет больничного гардероба.

Забавно, но маркетплейс вообще не борется за выручку в категории "Домашняя обувь" - на итоговом графике его едва можно найти. Давай посмотрим на аналогичную статистику продаж "Домашней обуви", входящей в категорию "Женская одежда". Среди популярных продавцов снова нет OZON, зато популярный товар в этой подкатегории заработал за месяц чуть больше - 87 210 рублей. И это при том, что продан он был в меньшем количестве, чем самые популярные мужские тапочки. В целом, женская версия этого уютного атрибута стабильно приносит продавцам больше денег. А еще она выглядит в разы эффектнее. Дарить вроде можно, но мы ажиотажного спроса не видим.

Мягкий спрос

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

"Мягкие игрушки" продаются в категории "Детские товары". Они стоят особняком от игрушек для мальчиков и девочек, да и вообще могли бы занять свое место среди взрослых товаров. Спрос на мягкие игрушки потрясающий и, очевидно, что не все эти товары предназначены для детей. Посмотрите, средние значения дневной выручки продавцов за последний месяц колеблются между 4 и 5 миллионами рублей. А что с топом продаж? Он совсем не похож на детскую игрушку - много ли вы знаете детей, которые увлечены Тоторо? Именно он принес продавцу за прошедшую неделю почти 5,2 млн. рублей. Да, спрос на него в последние дни подрос, но связанно ли это с днем всех влюбленных? Заметьте, в топе продаж нет никаких плюшевых мишек и сердец.

Напоследок вновь сравним достижения OZON и его продавцов. С 13 января по 12 февраля в категории мягкой игрушки маркетплейс самостоятельно заработал чуть больше 1,2 млн. рублей. Лидер продаж сделал на плюшевых товарах, страшно представить - 68 000 000 рублей. А что если, ради шутки, представить будто OZON выдает за результаты опроса категории товаров в которых ему просто не очень везет?

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

Возможно, мы ошибаемся и дарить два раза в месяц комплекты носков - отличная идея. Выручка растёт. Скорее всего, продавцам пора задавать тренды на подарки самим. Сердечки на открытках, шоколадках и носках - слишком очевидный способ поздравить вторую половину. А вот если найти "ту самую" нишу и заразить новым товаром покупателей, возможно, 14 февраля станет взрывным поводом для роста продаж. Тогда уже в следующем году, опросы OZON покажут, что День всех влюблённых будут отмечать хотя бы 90% россиян.Просто потому, что им станет ясно кому и, главное, что дарить.