Оконная функция (столбец для вычислений) OVER ([PARTITION BY столбец для группировки] [ORDER BY столбец для сортировки] [ROWS или RANGE выражение для ограничения строк в пределах группы])

По назначению выделяют 3 группы:

Агрегатные функции - SUM(), MAX(), MIN(), AVG(). COUNT();
Эти функции возвращают значение, полученное путем арифметических вычислений в рамках окна;

Функции ранжирования - RANK(), DENSE_RANK(), ROW_NUMBER(), NTILE();
Эти функции позволяют получить порядковые номера записей в рамках окна;

Функции смещения - LAG(), LEAD(), FIRST_VALUE(), LAST_VALUE();
Эти функции возвращают значение из другой строки в рамках окна;

А/B-тестирование позволяет Вам сравнить существующую версию страницы с новыми (новым) вариантами для оптимизации, которые Вы хотели бы протестировать (CTA, название, элемент ...).

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

1) Виды экспериментов

1.1) A/B-тестирование может также называться сплит-тестом, или Split URL testing. В классическом A/B-тесте оба варианта Ваших страниц находятся по одной ссылке. В случае Split URL testing, вариант В находится по другой URL-ссылке (Ваши посетители, соответственно, не видят разницы).

1.2) MVT-тест позволяет вам тестировать одновременно несколько изменений на одной веб-странице: баннер, заголовок, описание или еще видео

1.3) А/В/n-тестирование позволяет тестировать n-ое число гипотез по оптимизации Вашей страницы. Например, Вы сможете протестировать шесть вариантов Вашей страницы, проведя A/B/C/D/E/F-тест.

2) Что тестировать?

В рамах вашего веб/мобильного приложения или рассылки вы можете тестировать абсолютно всё, например:

3) Как тестировать? | Дизайн эксперимента

Вводные данные для подготовки дизайна эксперимента

Общая информация:
В рамках контентного веб-сайта с посещаемостью 1,000,000 сессий/день, который монетизируется через показ рекламных баннеров есть сэмплированные/агрегированные данные, указывающие на то, что 60% или 600,000 сессий/день заканчиваются просмотром не более ≤ 1 страницы/сессия (далее - точка роста/показатель отказов). Известно, что компания зарабатывает 0,50₽ за просмотр 1 страницы/сессия. Для проверки эксперимента собран сегмент «любители спорта» на 60 000 уникальных юзеров

Идея для эксперимента:
После авторизации в общественных Wi-Fi сетях, пользователь будет перенаправляться на посадочную страницу-агрегатор статей/новостей релевантным предварительно определенному сегменту интересов пользователя. За счёт этого планируется увеличение метрики - глубина просмотра на 1 страниц/сессия среди 5% сессий из чего предположительно последует рост монетизации на 0,50₽/сессия в месяц.

Известные показатели:

• Трафик/день - 1,000,000 сессий/день
• Трафик/мес - 30,000,000 сессий/мес
• RPM (Revenue Per Mille) - 500₽ за 1000 просмотров страницы
• 1 стр. глубины просмотра = 1 стр/сессия = +0,50₽
• Показатель отказов - 60% монетизируется строго 0,50₽/сессия || 600,000 сессий/день = 1 показ/сессия * 0,50₽ = 300.000₽/день || 9,000,000₽/мес
• Монетизация 40% нормального трафика > 0,50₽/сессия || 400,000 сессий/день приносят больше 1 просмотра стр/сессия
  
  Задачи эксперимента:
  
  Увеличить глубину просмотра на 1 стр/сессия среди 5% всех сессий в рамках месяца чтобы заработать +750,000₽/мес.
  
  30,000,000 сессий/мес * 5% = 1,500,000 сессий/мес
  1,500,000 сессий/мес * 0,50 ₽ = +750,000₽/мес.
  Ограничения эксперимента:
• Размер выборки для проверки эксперимента - 60,000 предварительно отобранных пользователей в рамках сегмента с интересом «любители спорта»
• Неопределенность относительно исторических значений %CTR (кликабельности) заголовка/блока превью статьи или новости в рамках генеральной совокупности накладывает ограничение на определение размера выборки, а также подведение результатов и интерпретации эксперимента.

3.1) Дизайн эксперимента

3.1) Шаблон дизайна эксперимента

3.1.1) Установление цели эксперимента (Какую проблему решаем?)
3.1.2) Гипотеза для тестирования (Какая гипотеза приведет к цели?)
3.1.3) Изменения в рамках объекта эксперимента (Что тестируем?)
3.1.4) Определение выборки для тестирования (На ком тестируем?)
3.1.5) Метрики для оценки эксперимента (Как измеряем?)
3.1.6) Ожидаемый эффект от эксперимента (Какой рост предполагаем?)
3.1.7) План действий в зависимости от результатов эксперимента

3.1.1) Установление цели эксперимента (Какую проблему решаем?)

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

3.1.2) Гипотеза для тестирования (Какая гипотеза приведет к цели?)

Действие [X] позволит увеличить метрику [N] на величину [Y] потому что [Z]

Сегментированное перенаправление пользователей после авторизации в общественных Wi-Fi сетях позволит увеличить метрику - CTR (показатель кликабельности) заголовка/превью статьи или новости в 2 раза, потому что редирект на страницу, агрегирующую релевантный сегменту контент с кликбейтными заголовками, позволит захватить внимание пользователя и увеличить кликабельность страницы новости/статьи

[Действие Х] - сегментированное перенаправление пользователей после авторизации в общественных Wi-Fi сетях [позволит увеличить метрику N] - CTR статьи или новости
[на величину Y] - в 2 раза
[потому что Z] - редирект на страницу, агрегирующую релевантный сегменту контент с кликбейтными заголовками, позволит захватить внимание пользователя и увеличить кликабельность страницы новости/статьи
3.1.3) Изменения в рамках объекта эксперимента (Что тестируем?)

Контрольная версия: оставляем без изменений
Тестовая версия: создаем страницу-категорию, куда парсим/генерим контент (баннер+заголовок+текст) релевантный сегменту пользователей «любители спорта». Каждая статья/новость должна размещаться в рамках уникального URL адреса, а все элементы блока превью статьи или новости должны быть кликабельны

3.1.4) Определение выборки для тестирования (На ком тестируем?)

Тестируем на предварительно собранном сегменте из 60,000 пользователей с категорией интересов «любители спорта» вне зависимости от того, относятся-ли они к 60% трафика из зоны роста.

3.1.5) Метрики для оценки эксперимента (Как измеряем?)

• CTR заголовка/превью блока статьи или новости
• Глубина просмотра или страниц/сессия
• Кол-во показов рекламы
• ARPU - средний доход на пользователя
• Время на сайте
• Показатель отказов

3.1.6) Ожидаемый эффект от эксперимента (Какой рост предполагаем?)

• 2х кратное увеличение %CTR (показателя кликабельности) превью/заголовка/ссылки на страницу статьи или новости
• Рост глубины просмотра на +1 стр/сессия вытекающий из увеличения %CTR
• Увеличение кол-ва показов рекламы за счет роста глубины просмотра
• Рост ARPU через увеличение кол-ва показов рекламы на пользователя
• Увеличение времени, проведенного на сайте вследствие роста глубины просмотра
• Уменьшение показателя отказов в результате увеличения времени на сайте
  

3.1.7) План действий в зависимости от результатов эксперимента

• Если наш эксперимент будет положительным и мы увидим рост в метриках - масштабируем
• Если метрики падают - откатываем эксперимент
• Если метрики не меняются - формулируем новую гипотезу

4) Как интерпретировать? | Проверка гипотез и оценка тестов

4.1) Аналитическая оценка доверительных интервалов

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

4.1.1) Параметрические критерии - группа статистических критериев, которые включают в расчет параметры вероятностного распределения признака (средние и дисперсии). Их можно использовать только в случае определенности относительно типа распределения данных.

• t-критерий Стьюдента
• Критерий Фишера
• Критерий отношения правдоподобия
• Критерий Романовского

4.1.2) Непараметрическими критериями - группа статистических критериев, которые не включают в расчёт параметры вероятностного распределения основанных не на действиях с самими значениями выборки и параметрами распределения, а их частотами или рангами.

• U-критерий Манна — Уитни Критерий
• Q-критерий Розенбаума
• Уилкоксона Критерий Пирсона
• Критерий Колмогорова — Смирнова

4.2) Оценка доверительных интервалов с помощью бутстрэпа

Бутстрэп — метод исследования распределения статистик вероятностных распределений, основанный на многократной генерации выборок методом Монте-Карло на базе имеющейся выборки. Применение бутстрэпа для оценки доверительных интервалов сводится к следующей процедуре:

5) Как приоритизировать? | ICE, PIE, PXL

5.1) Фреймворк ICE

Impact (Влияние) - Демонстрирует то, на сколько положительно идея повлияет на ключевой результат который мы пытаемся улучшить

Сonfidence (Уверенность) - Демонстрирует то, на сколько мы уверены в оценках влияния и лёгкости реализации

Ease (Простота) - Это оценка того, сколько ресурсов и усилий требуется для реализации

5.2) PIE-фреймворк

Potential(Потенциал) — сколько улучшений можно сделать на страницах?

Importance (Важность) — насколько ценный трафик на страницах (его объем и пр.)?

Ease (Простота) — насколько сложно протестировать страницу или шаблон?

5.3) PXL-фрейморк

Для решения задачи будет использован фреймворк анализа данных CRISP-DM (от английского Cross-Industry Standard Process for Data Mining) — межотраслевой стандартный процесс исследования данных.

В рамках исследования мы пройдем ключевые этапы анализа, иллюстрированных ниже ↓

1) Понимание бизнеса (Business Understanding):

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

• Ретейлеры/магазины
• Поставщики
• Регулирующие органы

1.1) Цели анализа:

1.1.1) Ранжирование и группировка продуктовой матрицы в зависимости от влияния продукта на совокупный эффект, измеряемый денежными и количественными показателями продаж.
Инструмент достижения цели — ABC-анализ

1.1.2) Ранжирование и группировка продуктовой матрицы по характеру спроса: насколько он стабилен и насколько точно его можно спрогнозировать?
Инструмент достижения цели — XYZ-анализ

1.1.3) Разработать ряд рекомендаций по оптимизации продуктовой матрицы и управлению запасами через измерение совокупного влияния ряда синтетических метрик полученных в результате ABC и XYZ анализа на уровне отдельно взятого магазина
Инструмент достижения цели — перекрёстный ABC+XYZ-анализ

Иллюстрация инструментов:

2) Понимание данных (Data Understanding):

Данный этап позволил идентифицировать цели бизнеса и спроектировать процесс подготовки данных

2.1) Главные выводы:

2.1.1) Из названия "Iowa Liquor Sales" можно предположить, что набор данных содержит в себе сведения о продажах спиртных напитков розничными магазинами в штате Iowa. Но в процессе исследования был сделан вывод о том, что данные отражают товаропоток от поставщика до точки сбыта (что косвенно дает возможность делать выводы о продажах на уровне отдельно взятого магазина). Подобно ЕГАИС в рамках РФ.

Ссылка на описание набора данных: https://mydata.iowa.gov/Sales-Distribution/Iowa-Liquor-Sales/m3tr-qhgy

Комментарий к данным:

Ключевые атрибуты:

2.1.2) В процессе понимания данных, даже в условиях «полной неопределенности», получилось идентифицировать цели бизнеса и увидеть набор данных в неочевидных плоскостях

3) Подготовка данных (Data Preparation):

3.1) Отбор данных

3.1.1) Для реализации большинства графиков и таблиц дашборда в рамках Google Data Studio использовался исходный набор данных

3.1.2) Для реализации ABC и XYZ анализа составлен SQL запрос к исходному набору данных, в рамках которого, была произведена агрегация, разметка, сегментация и очистка данных.


3.2) Обеспечение качества данных

3.1) Нормализация текстовых атрибутов: описание товара, название магазина, название поставщика реализованы с помощью функции FIRST_VALUE(). Агрегирование входных атрибутов для FIRST_VALUE проведено в рамках оконной функции OVER(PARTITION BY(ID)) с партицированием по первичным ключам текстовых атрибутов. Таким образом все текстовые с общими уникальные идентификаторами были заполнены одинаковыми значениями

1) Качество данных и метрики

Качество данных (от англ. Data Quality) — характеристика, показывающая степень пригодности данных к использованию.

На что влияет качество данных?

•‎ Доверие к используемым данным
•‎ Качество управленческих решений
•‎ Эффективный маркетинг
•‎ Удовлетворенность клиентов
•‎ Снижение затрат / повышение маржинальности
•‎ Регуляторные и репутационные риски

Оценка качества данных

•‎ Completeness (полнота данных) : пропуски в данных
•‎ Validity (валидность) : соответствие заданным стандартам
•‎ Uniqueness (уникальность) : наличие дубликатов
•‎ Consistensy (согласованность) : согласованность между наборами данных, (нет противоречий между двумя системами
•‎ Referential integrity (ссылочная целостность) : значения внешнего ключа должны быть согласованы с соответствующими значениями первичного ключа
•‎ Timeliness (своевременность) : актуальность на момент времени
•‎ Accuracy (точность) : данные отражены верно (соответствуют действительности)

Проблемы качества данных

2) Причины, примеры и управление КД

2.1) Некачественные данные:
2.1.1) Пропуски (NULL)
2.1.2) Ошибочные данные
2.1.2.1) Неправильные типы данных, дубли
2.1.2.2) Нарушения ACID
2.1.2.2.1) Dirty Read (грязное чтение) - чтение незакомиченных данных
2.1.2.2.2) Non-Repetable
2.1.2.2.3) Lost-Repetable
2.1.2.2.4) Lost Update
2.1.2.2.5) Loss of transaction
2.1.2.3) Ошибки в датах и категориальных датах
2.1.3) Непригодные данные
2.1.3.1) Противоречивые (в разных источника)
2.1.3.2) Двусмысленные
2.1.3.1) Конкатенация, специальные символы, порядк слов, аббревиатуры

2.2) Причины возникновения
2.2.1) Человеческий фактор
2.2.2) Ошибки в коде (баги)
2.2.2.1) На стороне источника
2.2.2.2) На стороне хранилища
2.2.3) Инцеденты: падения, восстановление, потеря транзакций, незавершенные вычисления
2.2.4) Изменения в системах-источниках
2.2.5) Коллизии - конфликт бизнес-правил
2.2.6) Невозможно получить все изменения в источнике (Change Data Capture)
2.2.7) Ошибки в обработке SCD (Slowly changing dimensions)
2.2.8) Ошибки в построении ETL-процессов
2.2.9) Невозможность восстановить (рестартовать) ETL-процесс с чекпоинта без потери данных

2.3) Как обеспечить качество данных?

2.3.1) Проверить соответствие схемы источника и приемника данных
2.3.2) После batch выгрузки сравнить кол-во строк на источнике с кол-вом поступившим в хранилище
2.3.2)

1) Бизнес-требования - это высокоуровневые бизнес-цели организации или владельца бизнеса.

Цели по SMART:

Specific - конкретный
Measurable -  измеримый
Achievable - дост достижимый
Relevant - уместный
Time-bounded - ограниченный по времени

Сравнение целей:

Не по SMART - пробежать марафон
По SMART - пробежать Бостноский марафон в 2021 году быстрее чем за 4:30 часа.

Не по SMART - Все должны покупать наш продукт
По SMART - Увеличить количество клиентов в возрасте от 20 до 30 лет на 30% в течении 6 месяцев с момента запуска приложения

Где документировать бизнес-требования?

• Vision and Scope document
• Business case

Критерии успеха - это промежуточный показатель, с помощью которого можно определить процесс достижения поставленных бизнес-целей. Например: Пробежать дистанцию в 25км до конца 2020 года не более, чем за 2:30 часа

2) Пользовательские требования - задачи, которые определенные типы пользователей должны иметь возможность выполнять в рамках системы. Т.е. хотелки заинтересованных лиц. Например : заказ товара, регистрация на рейс.

Пользовательские требования описывают ЧТО пользователь хочет делать с системой, а не КАК он хочет это сделать.

Пользовательские требования описываются с помощью Вариантов использования (Use Case) или Пользовательских историй (User Stories)

Определяют эти требования конечные пользователи, а не заказчики.
Хранятся в спецификации ПО или Бэклоге продукта.

Классы пользователей:

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

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

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

Классификации пользователей:

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

Приоритезируем пользовательские требования в зависимости от ценности бизнеса по RICE и ICE.

RICE — это метод приоритизации идей и фич продукта. Аббревиатура включает 4 фактора, которые менеджер продукта может смело использовать для оценки и приоритизации продуктовых фич:

• Reach — это охват
• Impact — влияние
• Confidence — уверенность в вашей оценке охвата, влияния и трудозатрат
• Effort — трудозатраты

Reach (Охват)

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

Важно акцентировать внимание на реальных метриках, а не использовании непонятных чисел.

Например: Фичей будет пользоваться 800 пользователей в месяц.1000 пользователей вовлечены в онбординг, и 70% — только 700 пользователей увидят эту фичу.

Impact (Влияние)

Влияние показывает какой вклад приносит эта фича продукту.

Ценность понимается по-разному в каждом продукте. Например, в Hygger (B2B SaaS) для текущего квартала фичи получают высокое значение, если они:

1. Улучшают trial-to-paid конверсию (metric movers)

Исходя из ваших текущих целей у вас будут свои метрики.

2. Помогают привлечь новых пользователей

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

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

3. Помогают сохранить текущих пользователей

Клиенты купили подписку и теперь просят сделать некоторые фичи. Мы не «спешим» слепо делать все подряд. Мы накапливаем статистику по каждой фиче — сколько клиентов просили об этом. И тогда мы реализуем самые популярные фичи.

4. Добавляют ценности продукту и отстраивают нас от конкурентов

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

К слову, влияние трудно измерить точно. Так, мы выбираем из шкалы с множеством вариантов: 3 для «массового влияния», 2 для «высокого», 1 для «среднего», 0,5 для «низкого» и, наконец, 0,25 для «минимального». Эти цифры умножаются на итоговый результат, чтобы масштабировать его ниже или выше.

Confidence (Уверенность в оценке)

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

Например Проект A: У менеджера продукта есть количественные показатели для влияния фичи, и оценка трудозатрат. Таким образом, проект получает 100% -ную оценку уверенности.

Проект B: У менеджера продукта есть данные по охвату и трудозатратам, но он не уверен в отношении фактора влияния. Проект получает коэффициент доверия в 80%.Проект C: Данные охвата и влияния могут быть ниже, чем предполагалось. Трудозатраты могут быть выше. Проект получает 50%-ную оценку доверия.

Effort (Трудозатраты)

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

Например: Проект A займет около недели планирования, 2 недели дизайна и 3 недели для разработки, поэтому трудозатраты составят 2 человеко-месяца.Для проекта B потребуется только неделя планирования, 1-2 недели для разработки и не потребует дизайна. Трудозатраты будут равны 1 человеко-месяцу.

Метод оценки ICE

Метод определения приоритетов ICE был придуман Шоном Эллисом, который известен авторством термина Growth Hacker.

Первоначально ICE был предназначен для приоритизации экспериментов по росту. Позже ICE стали использовать и для приоритизации фичей.

ICE Scoring: Как это работает?

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

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

В качестве примера, применим это к фиче «Виджеты для Dashboard»:
Влияние: насколько это будет эффективно? Что это даст нашим пользователям и их целям и задачам?
Легкость реализации: насколько легко будет разрабатывать, тестировать и запускать эту фичу?
Уверенность: как я могу быть уверен, что эта фича приведет к такому улучшению, которое я описал в Impact и займет столько-то времени?

3) Функциональные требования - это возможности системы, которыми она должна обладать. Т.е. функц. требования отвечают на вопрос ЧТО должна делать система.

Например:
• Система должна формировать чек на оплату при оформлении договора.
• Система должна позволять пользователю загружать фотографии в телефон.

Как описывать функциональные требования?

• Варианты использования (Use Case)
• Пользовательские истории (User Stories)
• Текстовые списки утверждений о системе

Где документировать функциональные требования?

• Спецификация ПО - классический метод с большим кол-вом документации
• Бэклог Продукта - гибкие методологии без большого количества документации

Шаблоны для подготовки функциональных требований:

• Базовый - система должна совершать какое-то действие
• Базовый + Объект - система должна предоставлять пользователю возможность совершать какое-то действие
• Комплексный - если {определенное условие}, то система должна совершать какое-то действие/предоставлять пользователю возможность совершать какое-то действие

Критерии хороших требований:

• Полнота
• Осуществимость
• Необходимость
• Конкретность
• Приоритезированность
• Однозначность
• Проверяемость

Примеры функциональных требований:

Плохой - пользователь должен иметь возможность просматривать свои личные данные и выгружать их на электронный адрес. (В рамках 1 требования 2 функции)

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

4) Нефункциональные требования - это требования описывающие характеристики и качества, которыми должна обладать система. Т.е. нефункц. требования отвечают на вопрос КАК должна работать система и могут относиться к всем остальным требованиям.

Типы нефункциональных требований:

4.1) Бизнес-правило - это высокоуровневое обстоятельство накладывающее ограничение на деятельность бизнеса.

Где выявлять бизнес-правила?

• Знания организации
• Предыдущие системы и их документации
• Существующие документы
• Нормативно-правовые акты организации или отрасли
• Политики

4.2) Атрибуты качества - это характеристики, которыми должна обладать система.
Например: требования к производительности, доступности или переносимости.

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

• Доступность
• Удобство установки
• Целостность
• Совместимость
• Производительность
• Надежность
• Устойчивость
• Защита
• Безопасность
• Удобство использования

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

• Эффективность
• Возможность модификации
• Переносимость
• Возможность повторного использования
• Масштабируемость
• Проверяемость

Как документировать атрибуты качества?

Список в разделе Спецификации ПО:
• Нефункциональное требование 1
• Нефункциональное требование 2
• Нефункциональное требование 3

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

4.3) Ограничения - это рамки, накладываемые на доступный разработчику выбор дизайна или реализации.

Ограничения могут служить:
• Языки программирования
• Стандарты разработки кода
• Протоколы связи с другими системами
• Разрешения экрана
• Форматы обмена данными (XML, JSON)

Примеры ограничений:
• Интернет-платежи могут выполняться только через PayPal.
• Все используемые в приложении текстовые данные должны храниться в виде JSON-файлов

Документируем органичения в Документе о концепциях и границах продукта в начале разработки продукта.

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

Способы описания внешних интерфейсов:
• Контекстная диаграмма
• Диаграмма вариантов использования
• Диаграмма потоков данных

1.1) Из чего состоит SEMMA: этапы процесса Data Mining

1. Выборка данных – формирование начального набора данных для моделирования (dataset), который должен быть достаточно большим, чтобы содержать достаточную информацию для извлечения, и в то же время ограниченным, чтобы его можно было эффективно использовать.
2. Исследование – выявление ассоциаций, визуальный и интерактивный статистический анализ, понимание данных путем обнаружения ожидаемых и непредвиденных связей между переменными, а также отклонений с помощью визуализации данных.
3. Модификация – применение методов выбора, создания и преобразования переменных при подготовке к моделированию: кластерный анализ, преобразование, фильтрация и замещение информации.
4. Моделирование — применение методов построения и обработки моделей интеллектуального анализа данных: искусственные нейронные сети, деревья принятия решений, регрессионный анализ и т.д.
5. Оценка – сравнение результатов моделирования между собой и с планируемыми показателями, анализ надежности и полезности созданных моделей.

2) CRISP-DM (от английского Cross-Industry Standard Process for Data Mining) — межотраслевой стандартный процесс исследования данных.

Рассмотрим подробнее фазы жизненного цикла исследования данных по CRISP-DM:

2.1) Понимание бизнес-целей (Business Understanding). На данном этапе производится исследование бизнес-процессов компании и предлагаются идеи относительно применения анализа данных для их совершенствования, формулируются конечные цели анализа. Для этого к обсуждению приглашается как можно больше заинтересованных специалистов и экспертов. Результатом этапа должен стать план аналитического проекта. Кроме этого, необходимо убедиться в целесообразности проекта, прежде чем тратить на него ресурсы.
Задачи фазы Business Understanding:

• Определить бизнес-цели
• Оценить ситуацию
• Определить цели анализа данных
• Составить план проекта

2.2) Начальное изучение данных (Data Understanding). Данная фаза включает в себя более детальное изучение имеющихся данных. Ее цель — избежать непредвиденных проблем на стадии подготовки данных, которая, как правило, является самой сложной частью проекта. Начальное изучение данных предполагает организацию доступа к ним, их исследование с использованием таблиц и графиков, оценку качества данных и разработку соответствующей документации. Задачи фазы Data Understanding:

• Собрать исходные данные
• Описать данные
• Исследовать данные
• Проверить качество данных

2.3) Подготовка данных (Data Preparation). Является одним из наиболее важных и зачастую трудоемких этапов аналитического проекта, который может поглощать 50-70% времени, усилий и ресурсов. В зависимости от специфики компании и направления ее деятельности подготовка данных обычно включает:

• консолидацию данных;
• формирование выборок;
• обогащение данных
• очистку данных
• разделение данных на обучающие и тестовые

2.4) Моделирование (Modeling) – в этой фазе к данным применяются разнообразные методики моделирования, строятся модели и их параметры настраиваются на оптимальные значения. Обычно для решения любой задачи анализа данных существует несколько различных подходов. Некоторые подходы накладывают особые требования на представление данных. Таким образом часто бывает нужен возврат на шаг назад к фазе подготовки данных. Задачи фазы Modeling:

• Выбрать методику моделирования
• Сделать тесты для модели
• Построить модель
• Оценить модель

2.5) Оценка (Evaluation) – анализ количественных характеристик качества модели, подтверждение или опровержение того, что, благодаря построенной модели все бизнес-цели достигнуты. Основной целью этапа является поиск важных бизнес-задач, которым не было уделено должного внимания. Задачи фазы Evaluation:

• Оценить результаты
• Сделать ревью процесса
• Определить следующие шаги

2.6) Внедрение (Deployment) – в зависимости от требований фаза развертывания может быть простой (составление финального отчета) или сложной, например, автоматизация процесса анализа данных для решения бизнес-задач. Обычно развертывание — это внедрение полученных моделей в прикладную сферу. Задачи фазы Deployment:

• Запланировать развертывание
• Запланировать поддержку и мониторинг развернутого решения
• Сделать финальный отчет
• Сделать ревью проекта
  

3) Knowledge Discovery in Databases (KDD) – это процесс поиска полезных знаний в «сырых» данных.

1. Подготовка исходного набора данных. Этот этап заключается в создании набора данных, в том числе из различных источников, выбора обучающей выборки и т.д. Для этого должны существовать развитые инструменты доступа к различным источникам данных. Желательно иметь поддержку работы с хранилищами данных и наличие семантического слоя, позволяющего использовать для подготовки исходных данных не технические термины, а бизнес понятия.
2. Предобработка данных. Для того чтобы эффективно применять методы Data Mining, следует обратить внимание на вопросы предобработки данных. Данные могут содержать пропуски, шумы, аномальные значения и т.д. Кроме того, данные могут быть избыточны, недостаточны и т.д. В некоторых задачах требуется дополнить данные некоторой априорной информацией. Наивно предполагать, что если подать данные на вход системы в существующем виде, то на выходе получим полезные знания. Данные должны быть качественны и корректны с точки зрения используемого метода DM. Поэтому первый этап KDD заключается в предобработке данных. Более того, иногда размерность исходного пространства может быть очень большой, и тогда желательно применять специальные алгоритмы понижения размерности. Это как отбор значимых признаков, так и отображение данных в пространство меньшей размерности.
3. Трансформация, нормализация данных. Этот шаг необходим для приведения информации к пригодному для последующего анализа виду. Для чего нужно проделать такие операции, как приведение типов, квантование, приведение к "скользящему окну" и прочее. Кроме того, некоторые методы анализа, которые требуют, чтобы исходные данные были в каком-то определенном виде. Нейронные сети, скажем, работают только с числовыми данными, причем они должны быть нормализованы.
4. Data Mining. На этом шаге применяются различные алгоритмы для нахождения знаний. Это нейронные сети, деревья решений, алгоритмы кластеризации, установления ассоциаций и т.д.
5. Постобработка данных. Интерпретация результатов и применение полученных знаний в бизнес приложениях.

ArchiMate

[Курс] Бизнес-моделирование - https://www.youtube.com/playlist?list=PLEU6YIHP1uoQJ64mjlXQSlfM0sH83Gx0I

1) Общая схема (on-premise)

1.1) Collection(сбор): Источники данных (мобильные приложения, сайты, веб-приложения, микросервисы, IoT устройства интернет-вещей, операционные базы данных)

1.2) Ingestion(прием): Инструменты для импорта-экспопрта данных в различные источники (HTTP, MQTT, брокеры сообщений, и д.п.). Данные могут передаваться в двух формах: поток и отложенная загрузка. Все эти данные записываются в озеро данных.

1.3) Preparation(подготовка): это ряд операция по извлечению, преобразованию, загрузки данных (ETL) для очистки, преобразования и каталогизации больших двоичных объектов и потоков данных в озере данных; Подготовка данных к их использованию для машинного обучения и сохранения в хранилище данных.

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

1.5) Presentation(презентация): Информация представляется через дашборды, графики, емэйлы, SMS, пуш-уведомления, микросервисы. Выводы модели машинного обучения представляются через микросервисы.

2) Шаблоны on-premise решений с технологиями

2.1) Из интернета

2.2) Реализация от себя

3) Шаблоны облачных решений Cloud solution

3.1) Amazon

3.2) Microsoft Azure

3.3) Google

4) Форматы данных и их особенности

5) Big Data Landscape 2019

6) Дорожная карта Data Engineer

7) Дорожная карта DevOps