Иии у нас очередной запуск курса Ветчинкина по микросервисам!
(напоминаю, что это лучший☝🏻 курс по микросервисам на русском языке)
Учитывая критику предыдущего объявления, я провел собственное исследование и выяснил, что на HH требование знания микросервисов в вакансиях системных аналитиков встречается примерно в каждой десятой вакансии, зато зарплаты по таким вакансиям начинаются сразу от 180 тыс., а в среднем таким аналитикам обещают 260 тыс.
Ну и даже если компания не выставляет таких вакансий, всё равно в тайне мечтает перейти на микросервисы :) Например, довольно часто вижу запрос на каталогизацию и описание мкиросервисов ("дайте шаблон описания микросервиса"), эту работу обычно поручают аналитику.
И лучшего варианта разобраться с микросервисами, чем курс Кирилла, нет.
Заодно можно погрузиться в задачи архитектора, если вы планируете расти в эту сторону — можно, скажем, удивиться (спойлер!) что архитектор, например, очень много времени уделяет формированию команд и распространению знаний между командами.
(вместе с ограничением знаний между командами). Это неочевидно — снаружи кажется, что архитекторы в основном продумывают технические аспекты, но кроме CAP-теоремы, в разработке работают законы Брукса и Конвея:
А вы читали классическую книгу по управлению программными проектами Брукса "Мифический человеко-месяц"? Вот ту, откуда пришли фразы "серебряной пули не существует", "эффект второй системы", расчет сложности ПО (создание хорошо отлаженного и документированного программного продукта с внешними интеграциями обходится в 9 раз дороже, чем просто "запрогать это"), и тезисы типа "планируйте выбросить первую версию" (термин MVP тогда ещё не изобрели) и "сценарий взаимодействия обычно разрабатывают не перед, а после реализации". Очень любопытно, уже в 1975 всё было понятно про нашу индустрию. Микросервисы — как раз один из возможных ответов на эти вызовы.
Закон Конвея:
Есть и обратный закон Конвея: структура системы определяет структуру организации.
Так что микросервисы и архитектура, на удивление, очень сильно связана с организацией команд и управлением знаниями.
(напоминаю, что это лучший☝🏻 курс по микросервисам на русском языке)
Учитывая критику предыдущего объявления, я провел собственное исследование и выяснил, что на HH требование знания микросервисов в вакансиях системных аналитиков встречается примерно в каждой десятой вакансии, зато зарплаты по таким вакансиям начинаются сразу от 180 тыс., а в среднем таким аналитикам обещают 260 тыс.
Ну и даже если компания не выставляет таких вакансий, всё равно в тайне мечтает перейти на микросервисы :) Например, довольно часто вижу запрос на каталогизацию и описание мкиросервисов ("дайте шаблон описания микросервиса"), эту работу обычно поручают аналитику.
И лучшего варианта разобраться с микросервисами, чем курс Кирилла, нет.
Заодно можно погрузиться в задачи архитектора, если вы планируете расти в эту сторону — можно, скажем, удивиться (спойлер!) что архитектор, например, очень много времени уделяет формированию команд и распространению знаний между командами.
(вместе с ограничением знаний между командами). Это неочевидно — снаружи кажется, что архитекторы в основном продумывают технические аспекты, но кроме CAP-теоремы, в разработке работают законы Брукса и Конвея:
«Добавляя людских ресурсов, мы задерживаем окончание программного проекта» (Брукс, 1975).
А вы читали классическую книгу по управлению программными проектами Брукса "Мифический человеко-месяц"? Вот ту, откуда пришли фразы "серебряной пули не существует", "эффект второй системы", расчет сложности ПО (создание хорошо отлаженного и документированного программного продукта с внешними интеграциями обходится в 9 раз дороже, чем просто "запрогать это"), и тезисы типа "планируйте выбросить первую версию" (термин MVP тогда ещё не изобрели) и "сценарий взаимодействия обычно разрабатывают не перед, а после реализации". Очень любопытно, уже в 1975 всё было понятно про нашу индустрию. Микросервисы — как раз один из возможных ответов на эти вызовы.
Закон Конвея:
Организации, проектирующие системы, создают программные структуры, повторяющие структуру коммуникации, сложившуюся в этих организациях
(Конвей, 1968)
Есть и обратный закон Конвея: структура системы определяет структуру организации.
Так что микросервисы и архитектура, на удивление, очень сильно связана с организацией команд и управлением знаниями.
👍12🔥2
Забавное применение ChatGPT: пользовательское тестирование требований.
Как известно, пока пользователь не увидит систему, он не может сказать, что ему ещё нужно.
Чтобы не разрабатывать систему, можно попросить ChatGPT эмулировать работу системы, описанной требованиями.
То есть, даём ChatGPT набор требований (тут мы будем ограничены длиной промпта или двух), а потом просим его отвечать — может ли система, описанная этими требованиями, выполнить действия, которые пользователь формирует на своём языке. Можно представителя пользователя рядом посадить и предложить представить типичные ситуации, а ИИ будет говорить — можно ли это сделать при описанных требованиях. В общем, похоже на текстовую RPG 😀
Промпт:
Как вариант, можно попросить описать с точностью до экранов:
ChatGPT Plus — со встроенным DALL-E — может сразу генерировать изображения экранов (ну, с подписями будет не очень, тут либо визуальное расположение, либо подписи).
Отсюда: https://arxiv.org/abs/2303.07839 ChatGPT Prompt Patterns for Improving Code Quality, Refactoring, Requirements Elicitation, and Software Design. Jules White, Sam Hays, Quchen Fu, Jesse Spencer-Smith, Douglas C. Schmidt
Также там описаны промпты для выявления неоднозначностей в требованиях (что может быть понято двусмысленно),
симулятор API, генерация примеров для API, подсказка по возможным вариантам архитектуры и анализ запросов на изменения (насколько сложно будет реализовать новую функцию).
Как известно, пока пользователь не увидит систему, он не может сказать, что ему ещё нужно.
Чтобы не разрабатывать систему, можно попросить ChatGPT эмулировать работу системы, описанной требованиями.
То есть, даём ChatGPT набор требований (тут мы будем ограничены длиной промпта или двух), а потом просим его отвечать — может ли система, описанная этими требованиями, выполнить действия, которые пользователь формирует на своём языке. Можно представителя пользователя рядом посадить и предложить представить типичные ситуации, а ИИ будет говорить — можно ли это сделать при описанных требованиях. В общем, похоже на текстовую RPG 😀
Промпт:
Now, I want you to act as this system. Use the requirements to guide your behavior. I am going to say, I want to do X, and you will tell me if X is possible given the requirements. If X is possible, provide a step-by-step set of instructions on how I would accomplish it and provide additional details that would help implement the requirement. If I can’t do X based on the requirements, write the missing requirements to make it possible as user stories.
Как вариант, можно попросить описать с точностью до экранов:
Now, I want you to act as this system in a textbased simulator of the system. Use the requirements to guide your behavior. You will describe the user interface for the system, based on the requirements, and what I can do on each screen. I am going to say, I want to do X, and you will tell me if X is possible given the requirements and the current screen. If X is possible, provide a step-by-step set of instructions how I would accomplish it and provide additional details that would help implement the requirement.
If I can’t do X based on the requirements, write the missing requirements to make it possible as user stories. Whenever the state of the user interface changes, update the user on what they are looking at.
Tell me what I am looking at in the system and ask me what I want to do.
ChatGPT Plus — со встроенным DALL-E — может сразу генерировать изображения экранов (ну, с подписями будет не очень, тут либо визуальное расположение, либо подписи).
Отсюда: https://arxiv.org/abs/2303.07839 ChatGPT Prompt Patterns for Improving Code Quality, Refactoring, Requirements Elicitation, and Software Design. Jules White, Sam Hays, Quchen Fu, Jesse Spencer-Smith, Douglas C. Schmidt
Также там описаны промпты для выявления неоднозначностей в требованиях (что может быть понято двусмысленно),
симулятор API, генерация примеров для API, подсказка по возможным вариантам архитектуры и анализ запросов на изменения (насколько сложно будет реализовать новую функцию).
👍22🔥3❤2
Postman, кроме того, что производит инструмент для тестирования API, ещё собирает лучшие практики проектирования.
Для этого у них есть отдельная команда Postman Open Technologies, которая также собирает информацию о стандартах, отраслевых форматах и спецификациях, открытых API.
Каталог практик и паттернов оформлен как рабочее пространство Postman: https://www.postman.com/postman/workspace/postman-open-technologies-openapi-governance-templates/overview (открывается прямо в Postman!)
Смысл каталога в том, чтобы не придумывать каждый раз "как мы будем возвращать сумму платежа" или "как будем делать пагинацию", а брать готовое решение.
На текущий момент там описаны следующие паттерны:
🔸 Форматы данных:
🔹Коды стран (ISO 3166)
🔹Коды валют (ISO 4217)
🔹Дата, время и временные промежутки (ISO 8601)
🔹Числа с десятичными дробями
🔹Кастомные заголовки HTTP
🔹Расширенное описание ошибки (RFC 9457 - кстати, очень хороший формат для передачи смысла ошибки HTTP)
🔸Управление кэшированием:
🔹Параметр Cache-control
🔹Параметр Etag
🔹Параметр Expires
🔸Фильтрация:
🔹Параметры поискового запроса
🔹Точное соответствие
🔹Диапазон значений поля
🔹Выбор полей для ответа
🔸Пагинация:
🔹Заголовки page and per_page (rfc 5988)
🔹Курсор / NextRecordKey
🔹Параметры Limit и Offset
🔸Сортировка:
🔹По одному полю - параметры sort_by, sort_order
🔹По нескольким полям
🔸Версионирование:
🔹На уровне URL API
🔹На уровне отдельного ресурса
🔹Через заголовок Accept-Version
🔹Через заголовок Accept
🔸Информация:
🔹Контакты разработчиков
🔹Лицензия
🔹Условия использования
🔹Заголовок Sunset (предупреждение, что ресурс станет недоступным в определенное время)
Набор паттернов интересный, я, например, про RFC 9457, версионирование на уровне ресурсов и Sunset header раньше не слышал.
Для этого у них есть отдельная команда Postman Open Technologies, которая также собирает информацию о стандартах, отраслевых форматах и спецификациях, открытых API.
Каталог практик и паттернов оформлен как рабочее пространство Postman: https://www.postman.com/postman/workspace/postman-open-technologies-openapi-governance-templates/overview (открывается прямо в Postman!)
Смысл каталога в том, чтобы не придумывать каждый раз "как мы будем возвращать сумму платежа" или "как будем делать пагинацию", а брать готовое решение.
На текущий момент там описаны следующие паттерны:
🔸 Форматы данных:
🔹Коды стран (ISO 3166)
🔹Коды валют (ISO 4217)
🔹Дата, время и временные промежутки (ISO 8601)
🔹Числа с десятичными дробями
🔹Кастомные заголовки HTTP
🔹Расширенное описание ошибки (RFC 9457 - кстати, очень хороший формат для передачи смысла ошибки HTTP)
🔸Управление кэшированием:
🔹Параметр Cache-control
🔹Параметр Etag
🔹Параметр Expires
🔸Фильтрация:
🔹Параметры поискового запроса
🔹Точное соответствие
🔹Диапазон значений поля
🔹Выбор полей для ответа
🔸Пагинация:
🔹Заголовки page and per_page (rfc 5988)
🔹Курсор / NextRecordKey
🔹Параметры Limit и Offset
🔸Сортировка:
🔹По одному полю - параметры sort_by, sort_order
🔹По нескольким полям
🔸Версионирование:
🔹На уровне URL API
🔹На уровне отдельного ресурса
🔹Через заголовок Accept-Version
🔹Через заголовок Accept
🔸Информация:
🔹Контакты разработчиков
🔹Лицензия
🔹Условия использования
🔹Заголовок Sunset (предупреждение, что ресурс станет недоступным в определенное время)
Набор паттернов интересный, я, например, про RFC 9457, версионирование на уровне ресурсов и Sunset header раньше не слышал.
👍33🔥9❤4
Я в последнее время много писал про сложные темы, а между тем обнаружил, что на русском языке нет простого объяснения про запросы, представления, хранимые процедуры и пользовательские функции.
То есть, можно Википедию почитать, можно посмотреть (довольно занудные) видео-лекции для программистов, а вот так чтобы на пальцах объяснили — не нашел.
Отсюда два вопроса:
1) Попадалось ли вам простое объяснение этих тем? Вот чтобы для начинающего системного аналитика, с целью разобраться в этих материях.
2) Нужно ли вам самим или вашим сотрудникам такое объяснение? Ставьте лайк, если да.
Ну интересно послушать — как вы сами разобрались с этой темой, или что вам интересно про неё узнать, если ещё не разобрались. Пишите в комментариях
👇👇👇
То есть, можно Википедию почитать, можно посмотреть (довольно занудные) видео-лекции для программистов, а вот так чтобы на пальцах объяснили — не нашел.
Отсюда два вопроса:
1) Попадалось ли вам простое объяснение этих тем? Вот чтобы для начинающего системного аналитика, с целью разобраться в этих материях.
2) Нужно ли вам самим или вашим сотрудникам такое объяснение? Ставьте лайк, если да.
Ну интересно послушать — как вы сами разобрались с этой темой, или что вам интересно про неё узнать, если ещё не разобрались. Пишите в комментариях
👇👇👇
👍66❤10🔥3
tables_views_sp.pdf
281.5 KB
В общем, я вижу, интерес к теме хранимых процедур есть, поэтому я сделал небольшую презентацию с объяснением совсем базовых вещей.
Держите, пользуйтесь, задавайте вопросы!
Держите, пользуйтесь, задавайте вопросы!
❤40🔥32❤🔥9👍6
Продолжу тему нефункциональных требований, или показателей качества.
Давно хотел завести гонзо-обзоры стандартов, относящихся к ИТ.
Сегодня — про ISO 25000, System and Software Quality Requirements and Evaluation, SQuaRE (по-английски — что-то типа "скучный, занудный, не модный"). У нас его эквивалент — ГОСТ Р ИСО 25000:2021, свеженький, введен в апреле 2022 г. (Там серия: управление качеством, модели качества, измерение качества, требования к качеству, оценка качества. Можно надолго погрузиться)
Возможно, вы слышали про стандарт управления качеством ISO 9000. Так вот ISO 25000 плюет на ISO 9000 и отстраивается от него, хотя оба говорят про качество. Отстройка такая: 9000 — это про качество процессов, а 25000 — про качество систем и программной продукции. Это в стандартах сплошь и рядом, например, про качество данных у нас есть два стандарта.
Собственно, качество данных — одна из моделей качества, которую вводит ISO 25000. Ещё качество при использовании и качество продукта. Само понятие качества определяется как степень удовлетворения системой заявленных и подразумеваемых потребностей различных заинтересованных сторон.
Модель качества определяет характеристики, которые нас могут интересовать, и их показатели (что можно измерить). Вот, например, качество в использовании. Об этом часто говорят, как о юзабилити/UX, но посмотрите, что нам тут рекомендуют измерять:
➡️ Результативность
⭐️ Выполненные задачи (% задач, которые выполняются правильно без посторонней помощи)
⭐️ Достигнутые цели (% целей, которые достигаются правильно без посторонней помощи)
⭐️ Ошибки в задаче (Количество ошибок, допущенных пользователем во время выполнения задачи)
⭐️ Задачи с ошибками (% задач, в которых пользователь допустил ошибки)
⭐️ Интенсивность ошибок задачи (% пользователей, совершающих ошибку при выполнении задачи)
➡️ Эффективность
⭐️ Время выполнения задачи
⭐️ Эффективность затраченного времени (число достигнутых целей / время работы пользователя)
⭐️ Экономическая эффективность (стоимость выполнения задач / количество достигнутых целей)
⭐️ Коэффициент полезного времени (время, затраченное на выполнение задачи за вычетом времени, потраченного на получение помощи или помощь; времени на восстановление после ошибок; времени на неэффективный поиск)
⭐️ Ненужные действия
⭐️ Последствия усталости (Снижение производительности после непрерывной работы)
➡️ Удовлетворенность
⭐️ Полезность
⭐️ Удовлетворенность функциями (по опросам пользователей)
⭐️ Дискреционное использование (% потенциальных пользователей, решивших использовать систему или функцию, от всех, кто мог бы использовать эту функцию).
⭐️ Использование функций (% пользователей системы, использующих функцию).
⭐️ Доля жалующихся пользователей (% от всех активных пользователей).
⭐️ Доля жалоб пользователей на функцию (% относительно числа всех пользователей этой функции).
Подхарактеристики, которые измеряются по опросникам:
Доверие
Удовольствие
Комфорт
➡️ Свобода от рисков
Снижение экономических рисков - а вот тут, внезапно, не UX, а расчет окупаемости и возврата инвестиций! Рентабельность, время окупаемости, экономическая эффективность, преимущества внедрения ИТ(по сравнению с другими способами решения задачи!), выручка от клиента, доля ошибок с экономическими последствиями.
➡️ Покрытие контекста
⭐️ Полнота контекста (Доля предполагаемых контекстов использования, в которых продукт или система могут использоваться с приемлемым удобством использования и риском)
⭐️ Гибкость: степень, в которой продукт может использоваться в дополнительных контекстах без модификаций
⭐️ Простота, с которой продукт может быть изменен в соответствии с дополнительными требованиями пользователя
⭐️ Независимость от специальных знаний и навыков пользователя.
Вот такие характеристики качества в использовании. Интересно, сколько из них рассматривают аналитики или UX-дизайнеры.
Возможно, это не их вопросы, но чьи?..
Давно хотел завести гонзо-обзоры стандартов, относящихся к ИТ.
Сегодня — про ISO 25000, System and Software Quality Requirements and Evaluation, SQuaRE (по-английски — что-то типа "скучный, занудный, не модный"). У нас его эквивалент — ГОСТ Р ИСО 25000:2021, свеженький, введен в апреле 2022 г. (Там серия: управление качеством, модели качества, измерение качества, требования к качеству, оценка качества. Можно надолго погрузиться)
Возможно, вы слышали про стандарт управления качеством ISO 9000. Так вот ISO 25000 плюет на ISO 9000 и отстраивается от него, хотя оба говорят про качество. Отстройка такая: 9000 — это про качество процессов, а 25000 — про качество систем и программной продукции. Это в стандартах сплошь и рядом, например, про качество данных у нас есть два стандарта.
Собственно, качество данных — одна из моделей качества, которую вводит ISO 25000. Ещё качество при использовании и качество продукта. Само понятие качества определяется как степень удовлетворения системой заявленных и подразумеваемых потребностей различных заинтересованных сторон.
Модель качества определяет характеристики, которые нас могут интересовать, и их показатели (что можно измерить). Вот, например, качество в использовании. Об этом часто говорят, как о юзабилити/UX, но посмотрите, что нам тут рекомендуют измерять:
⭐️ Выполненные задачи (% задач, которые выполняются правильно без посторонней помощи)
⭐️ Достигнутые цели (% целей, которые достигаются правильно без посторонней помощи)
⭐️ Ошибки в задаче (Количество ошибок, допущенных пользователем во время выполнения задачи)
⭐️ Задачи с ошибками (% задач, в которых пользователь допустил ошибки)
⭐️ Интенсивность ошибок задачи (% пользователей, совершающих ошибку при выполнении задачи)
⭐️ Время выполнения задачи
⭐️ Эффективность затраченного времени (число достигнутых целей / время работы пользователя)
⭐️ Экономическая эффективность (стоимость выполнения задач / количество достигнутых целей)
⭐️ Коэффициент полезного времени (время, затраченное на выполнение задачи за вычетом времени, потраченного на получение помощи или помощь; времени на восстановление после ошибок; времени на неэффективный поиск)
⭐️ Ненужные действия
⭐️ Последствия усталости (Снижение производительности после непрерывной работы)
⭐️ Полезность
⭐️ Удовлетворенность функциями (по опросам пользователей)
⭐️ Дискреционное использование (% потенциальных пользователей, решивших использовать систему или функцию, от всех, кто мог бы использовать эту функцию).
⭐️ Использование функций (% пользователей системы, использующих функцию).
⭐️ Доля жалующихся пользователей (% от всех активных пользователей).
⭐️ Доля жалоб пользователей на функцию (% относительно числа всех пользователей этой функции).
Подхарактеристики, которые измеряются по опросникам:
Доверие
Удовольствие
Комфорт
Снижение экономических рисков - а вот тут, внезапно, не UX, а расчет окупаемости и возврата инвестиций! Рентабельность, время окупаемости, экономическая эффективность, преимущества внедрения ИТ(по сравнению с другими способами решения задачи!), выручка от клиента, доля ошибок с экономическими последствиями.
⭐️ Полнота контекста (Доля предполагаемых контекстов использования, в которых продукт или система могут использоваться с приемлемым удобством использования и риском)
⭐️ Гибкость: степень, в которой продукт может использоваться в дополнительных контекстах без модификаций
⭐️ Простота, с которой продукт может быть изменен в соответствии с дополнительными требованиями пользователя
⭐️ Независимость от специальных знаний и навыков пользователя.
Вот такие характеристики качества в использовании. Интересно, сколько из них рассматривают аналитики или UX-дизайнеры.
Возможно, это не их вопросы, но чьи?..
Please open Telegram to view this post
VIEW IN TELEGRAM
❤13👍7🔥1
Часть программы Flow, по традиции , будет доступна бесплатно (после регистрации). Билеты и так не дорогие, но топовые доклады — точнее, доклад и два обсуждения — и вовсе бесплатно:
"Удобство использования" есть ещё в модели качества продукта.
Хотите оценить качество программного продукта или сравнить два продукта между собой? На это тоже есть ГОСТ! ГОСТ Р ИСО/МЭК 25023-2021, можете ссылаться.
Также можно использовать этот набор показателей при постановке задач на проектирование интерфейсов и создание документации/справки/онбординга/обучающих материалов.
Вот что в части удобства использования можно измерить:
➡️ Достаточность описания (для определения пригодности — подойдет ли нам этот продукт для решения наших задач?):
⭐️ Полнота описания — какая часть сценариев описана в документации? (" — А для чего эта кнопка? — Да никто не знает")
⭐️ Демонстрационное покрытие — какая часть сценариев имеет наглядную демонстрацию, чтобы можно было определить их пригодность?
➡️ Обучаемость:
⭐️ Полнота руководства пользователя — какая часть сценариев описана в справке или документации в такой степени, чтобы пользователь мог ими воспользоваться? Тут, кстати, в стандарте говорится не только о документации, но и о соответствии концептуальной модели системы ментальной модели пользователя(!) это, по сути, практически DDD: как пользователь представляет себе предметный домен, и как этот домен отражен в системе и её интерфейсах.
⭐️ Приведение значений по умолчанию — какая часть полей ввода данных, имеющие значения по умолчанию, автоматически заполняются этими значениями? (добавлю тут от себя — какая часть полей ввода содержит описание форматов и примеры заполнения?)
⭐️ Понятность сообщений об ошибках — какая часть сообщений об ошибках предоставляет информацию о причинах возникновения ошибки и методах ее устранения?
⭐️ Самоописательность пользовательского интерфейса — какая часть элементов интерфейса, с которыми взаимодействует пользователь в ходе выполнения операций, позволяет выполнить данные операции без дополнительного обучения и подготовки?
➡️ Эксплуатационная пригодность:
⭐️ Эксплуатационная согласованность: в какой степени поведение системы постоянно в ходе выполнения группы схожих операций? (например, насколько похоже реализованы функции оплаты картой или оплатой по СБП? насколько похоже по логике и поведению добавление сообщения в общий форум всего курса и комментирование одного видео/задания из курса? и т.д.)
⭐️ Корректность сообщений — какая часть сообщений, получаемых от системы, имеет корректный результат или приводит инструкции пользователю?
⭐️ Функциональная настраиваемость — какую часть функций и процедур пользователь может настроить для своего удобства? (настройка которых может быть полезна. Например, сохранить какие-то шаблоны, значения по умолчанию, убрать ненужные шаги).
⭐️ Настраиваемость интерфейса — какую часть элементов интерфейса пользователь может настроить? (для которых это имеет смысл — например, скрыть неиспользуемые элементы интерфейса).
⭐️ Возможность мониторинга — какие состояния могут быть отслежены во время эксплуатации?
⭐️ Возможность отмены действий — какая часть сценариев использования предусматривает отмену или изменение?
⭐️ Понятность категоризации информации — в какой степени организация информации, используемая в программном продукте или системе, понятна пользователям и удобна для решения ими своих задач? Измеряется как число структур данных, понятных пользователю, к общему числу структур данных в продукте. Опять про DDD, да?
⭐️ Постоянство представления — одинаковые элементы данных схожим образом представлены в разных местах продукта.
⭐️ Поддержка устройств ввода
➡️ Защита от пользовательских ошибок:
⭐️ Защита — число действий, обрабатываемых с целью защиты от ошибок ввода
⭐️ Коррекция — число ошибок, по которым предлагается корректный вариант ("возможно, вы имели в виду ...")
➡️ Доступность:
⭐️ Доступность для пользователей с ограниченными возможностями
⭐️ Языковая поддержка
И, наконец, та-дам!
➡️ Эстетичность представления пользовательского интерфейса. "Чтобы было красиво"
Измеряется, вы не поверите, просто как отношение эстетически приятных интерфейсов ко всем имеющимся в продукте 🤷🏼♂️🤡👩🏻🎨
Хотите оценить качество программного продукта или сравнить два продукта между собой? На это тоже есть ГОСТ! ГОСТ Р ИСО/МЭК 25023-2021, можете ссылаться.
Также можно использовать этот набор показателей при постановке задач на проектирование интерфейсов и создание документации/справки/онбординга/обучающих материалов.
Вот что в части удобства использования можно измерить:
⭐️ Полнота описания — какая часть сценариев описана в документации? (" — А для чего эта кнопка? — Да никто не знает")
⭐️ Демонстрационное покрытие — какая часть сценариев имеет наглядную демонстрацию, чтобы можно было определить их пригодность?
⭐️ Полнота руководства пользователя — какая часть сценариев описана в справке или документации в такой степени, чтобы пользователь мог ими воспользоваться? Тут, кстати, в стандарте говорится не только о документации, но и о соответствии концептуальной модели системы ментальной модели пользователя(!) это, по сути, практически DDD: как пользователь представляет себе предметный домен, и как этот домен отражен в системе и её интерфейсах.
⭐️ Приведение значений по умолчанию — какая часть полей ввода данных, имеющие значения по умолчанию, автоматически заполняются этими значениями? (добавлю тут от себя — какая часть полей ввода содержит описание форматов и примеры заполнения?)
⭐️ Понятность сообщений об ошибках — какая часть сообщений об ошибках предоставляет информацию о причинах возникновения ошибки и методах ее устранения?
⭐️ Самоописательность пользовательского интерфейса — какая часть элементов интерфейса, с которыми взаимодействует пользователь в ходе выполнения операций, позволяет выполнить данные операции без дополнительного обучения и подготовки?
⭐️ Эксплуатационная согласованность: в какой степени поведение системы постоянно в ходе выполнения группы схожих операций? (например, насколько похоже реализованы функции оплаты картой или оплатой по СБП? насколько похоже по логике и поведению добавление сообщения в общий форум всего курса и комментирование одного видео/задания из курса? и т.д.)
⭐️ Корректность сообщений — какая часть сообщений, получаемых от системы, имеет корректный результат или приводит инструкции пользователю?
⭐️ Функциональная настраиваемость — какую часть функций и процедур пользователь может настроить для своего удобства? (настройка которых может быть полезна. Например, сохранить какие-то шаблоны, значения по умолчанию, убрать ненужные шаги).
⭐️ Настраиваемость интерфейса — какую часть элементов интерфейса пользователь может настроить? (для которых это имеет смысл — например, скрыть неиспользуемые элементы интерфейса).
⭐️ Возможность мониторинга — какие состояния могут быть отслежены во время эксплуатации?
⭐️ Возможность отмены действий — какая часть сценариев использования предусматривает отмену или изменение?
⭐️ Понятность категоризации информации — в какой степени организация информации, используемая в программном продукте или системе, понятна пользователям и удобна для решения ими своих задач? Измеряется как число структур данных, понятных пользователю, к общему числу структур данных в продукте. Опять про DDD, да?
⭐️ Постоянство представления — одинаковые элементы данных схожим образом представлены в разных местах продукта.
⭐️ Поддержка устройств ввода
⭐️ Защита — число действий, обрабатываемых с целью защиты от ошибок ввода
⭐️ Коррекция — число ошибок, по которым предлагается корректный вариант ("возможно, вы имели в виду ...")
⭐️ Доступность для пользователей с ограниченными возможностями
⭐️ Языковая поддержка
И, наконец, та-дам!
Измеряется, вы не поверите, просто как отношение эстетически приятных интерфейсов ко всем имеющимся в продукте 🤷🏼♂️🤡👩🏻🎨
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🥱2❤1🔥1
8 марта вновь вспоминаем всех женщин, стоявших у истоков ИТ: придумавших первые языки программирования, компилятор, доменную систему имен, базовые алгоритмы сетевого обмена и т.д.
И, конечно, Аду Лавлейс. Хотя её и считают первым программистом, сама она называла себя Аналитиком:
И, помимо остальных заслуг, Аде принадлежит идея, что счётные машины могут не только щелкать цифрами — они могут в виде цифр представлять и другие объекты реального мира, устанавливать связи между ними, вычислять логические закономерности и это радикально изменит науку и обшество. В качестве примеров она приводила музыку и изображения в цифровом виде (а кино тогда ещё не изобрели).
В общем, действовала, как настоящий аналитик: думала о применении аналитических машин для полезных дел в разных областях, а не только о том, какой бы прикольный код написать.
Чего в этот день всем и желаю! И спасибо дорогим женщинам за ключевой вклад в ИТ и приземеление абстрактных идей на решение реальных проблем.
С праздником! Процветания и независимости! И побольше радости! 💐🌺🌸🌷🪻
И, конечно, Аду Лавлейс. Хотя её и считают первым программистом, сама она называла себя Аналитиком:
I am in good spirits; for I hope another year will make me really something of an Analyst. The more I study, the more insatiable do I feel my genius for it to be.
I do not believe that my father was (or ever could have been) such a Poet as I shall be an Analyst, (& Metaphysician); for with me the two go together indissolubly.
И, помимо остальных заслуг, Аде принадлежит идея, что счётные машины могут не только щелкать цифрами — они могут в виде цифр представлять и другие объекты реального мира, устанавливать связи между ними, вычислять логические закономерности и это радикально изменит науку и обшество. В качестве примеров она приводила музыку и изображения в цифровом виде (а кино тогда ещё не изобрели).
В общем, действовала, как настоящий аналитик: думала о применении аналитических машин для полезных дел в разных областях, а не только о том, какой бы прикольный код написать.
Чего в этот день всем и желаю! И спасибо дорогим женщинам за ключевой вклад в ИТ и приземеление абстрактных идей на решение реальных проблем.
С праздником! Процветания и независимости! И побольше радости! 💐🌺🌸🌷🪻
🔥40👍5🎉2
Представьте себе, что у вас под рукой в любой момент есть база данных, в которой есть гарантировано актуальная информация обо всех системах в организации:
✅ что за система, какие бизнес-сервисы она поддерживает (реестр бизнес-сервисов у вас тоже есть актуальный!)
✅ с какими смежными системами взаимодействует:
➡️ какие API выставляет
➡️ по каким API обращается
➡️ в какие топики очереди сообщений пишет, какие читает
✅ к каким базам данных есть доступ у системы, и какие бизнес-объекты в ней учитываются или изменяются
✅ где развернуты экземпляры системы, кто имеет доступ к ним
✅ какая команда какие системы разрабатывает, кто участвует и участвовал в разработке, кто за что отвечает (кто владелец, кто архитектор и т.д.)
Кроме того, у вас есть реестр бизнес-сервисов, то есть продуктов и услуг компании, и про каждый продукт известно:
➡️ из каких услуг он складывается
➡️ на какую аудиторию он ориентирован
➡️ через какие каналы предоставляется услуга
➡️ какие отделы внутри компании оказывают услугу
Соответственно, всё это связано друг с другом, и вы можете делать к базе произвольные запросы. Например:
❓ какие зависимости есть у системы (что нужно проверить, если вы хотите внести изменения, или переписать систему)
❓ какие клиенты есть у системы и
❓ какие сейчас есть потоки данных (например, чтобы отправлять какую-то дополнительную информацию)
❓ кто работает или работал над какой системой, кого спросить или позвать на встречу
❓ какие системы поддерживают какие бизнес-услуги, кто ими пользуется?
и так далее.
Была бы такая база полезна? Сколько бы это времени вам сэкономило?
Я, честно говоря, когда впервые увидел такую штуку, был в полном восхищении. А увидел я её на отборе докладов на Flow: это выступление Романа Цирульникова из ЮMoney. Надеюсь, сегодня вы его тоже посмотрели, называется скромно: "Модель архитектуры предприятия на графе".
Конечно, технологически поддерживать такую базу непросто, и требует определенного уровня зрелости процессов развертывания: всё на скриптах, под контролем и As Code -- чтобы потом по этому коду можно было всё собрать.
Но результат выглядит потрясающе. Кажется, где-то здесь лежит будущее системного анализа (или его погибель, смотря как вы настроены).
Я вот настроен в целом позитивно: мне сегодня исполняетсястрашно сказать, сколько , я на это наше ИТ смотрю уже больше 25 лет, и надеюсь, что увижу ещё много чудес впереди. Чего и вам желаю!
Осваивайте новые технологии! А я пошел тортик есть🎂
✅ что за система, какие бизнес-сервисы она поддерживает (реестр бизнес-сервисов у вас тоже есть актуальный!)
✅ с какими смежными системами взаимодействует:
➡️ какие API выставляет
➡️ по каким API обращается
➡️ в какие топики очереди сообщений пишет, какие читает
✅ к каким базам данных есть доступ у системы, и какие бизнес-объекты в ней учитываются или изменяются
✅ где развернуты экземпляры системы, кто имеет доступ к ним
✅ какая команда какие системы разрабатывает, кто участвует и участвовал в разработке, кто за что отвечает (кто владелец, кто архитектор и т.д.)
Кроме того, у вас есть реестр бизнес-сервисов, то есть продуктов и услуг компании, и про каждый продукт известно:
➡️ из каких услуг он складывается
➡️ на какую аудиторию он ориентирован
➡️ через какие каналы предоставляется услуга
➡️ какие отделы внутри компании оказывают услугу
Соответственно, всё это связано друг с другом, и вы можете делать к базе произвольные запросы. Например:
❓ какие зависимости есть у системы (что нужно проверить, если вы хотите внести изменения, или переписать систему)
❓ какие клиенты есть у системы и
❓ какие сейчас есть потоки данных (например, чтобы отправлять какую-то дополнительную информацию)
❓ кто работает или работал над какой системой, кого спросить или позвать на встречу
❓ какие системы поддерживают какие бизнес-услуги, кто ими пользуется?
и так далее.
Была бы такая база полезна? Сколько бы это времени вам сэкономило?
Я, честно говоря, когда впервые увидел такую штуку, был в полном восхищении. А увидел я её на отборе докладов на Flow: это выступление Романа Цирульникова из ЮMoney. Надеюсь, сегодня вы его тоже посмотрели, называется скромно: "Модель архитектуры предприятия на графе".
Конечно, технологически поддерживать такую базу непросто, и требует определенного уровня зрелости процессов развертывания: всё на скриптах, под контролем и As Code -- чтобы потом по этому коду можно было всё собрать.
Но результат выглядит потрясающе. Кажется, где-то здесь лежит будущее системного анализа (или его погибель, смотря как вы настроены).
Я вот настроен в целом позитивно: мне сегодня исполняется
Осваивайте новые технологии! А я пошел тортик есть
Please open Telegram to view this post
VIEW IN TELEGRAM
🍾33👍9🔥8🎉5❤2
Сегодня международный день числа Пи!
Отмечается вот прямо сейчас — 3/14 в 1:59:26
Нужно печь пи-роги и пить напитки, начинающиеся на "пи".
Удачно совпало с Масленицей, блины же тоже круглые!
В разработке ПО нет таких известных констант, но есть множество законов разной степени доказанности — от формальных теорем до эмпирических наблюдений. И все очень полезные! В основном они относятся к управлению, архитектуре или UX. Вот небольшой список:
Закон Брукса:
Добавление людей в запаздывающий проект вызывает ещё большее отставание.
(Это из книги "Мифический человеко-месяц", принципиальные вещи оттуда не изменились за почти 50 лет. Там много интересного, например формула, по которой "просто программа" обходится в 9 раз дешевле, чем протестированный, документированный и интегрированный программный продукт).
Закон Хофштадтера (того самого, который автор книги "Гёдель, Эшер, Бах: бесконечная гирлянда"):
Любое дело занимает больше времени, чем вы ожидали, даже если учесть Закон Хофштадтера.
Закон Конвея (это не тот Конвей, который изобрел игру "Жизнь" и сюрреальные числа. А сам закон очень важен для организации команд — отсюда растет DDD и микросервисы):
Организации, проектирующие системы, создают архитектуры, повторяющие структуру коммуникации этих организаций.
Принцип Постела (важен для интеграций):
Система должна быть консервативна в том, что она отправляет, и либеральна в том, что она принимает на вход.
Принцип Парето (применительно к ПО):
80% пользы получается от 20% функций системы.
Закон Линуса (Торвальдса, создателя Linux):
Под множеством взглядов все дефекты всплывают на поверхность.
(очень важно для нагруженных систем: мне рассказывали, что на главной странице Яндекса, к которой обращаются больше 1,5 млрд раз в день, сбои, вероятность которых 0,0000001%, происходят 10 раз в день! То есть, для нормальной работы вероятности сбоев должны быть сильно меньше.)
Закон Вирта:
ПО становится медленнее быстрее чем железо становится быстрее.
Фундаментальная теорема программной инженерии:
Любая проблема может быть решена добавлением ещё одного уровня абстракции.
Эти законы шуточные, но есть и формально доказанные теоремы. На удивление, их не очень много.
Одна из них — Теорема Кодда (создателя реляционной алгебры), которая доказывает эквивалентность операций реляционной алгебры и языка SQL. Несмотря на критику, реляционные базы до сих пор актуальны, т.к. под ними лежит формальная математическая теория со строгими доказательствами.
Другая, очень часто поминаемая в архитектуре распределенных систем: CAP-теорема (или теорема Брюера). Она утверждает, что в распределенной системе можно обеспечить не более двух свойств из триады:
🔸согласованность данных (Consistency) — во всех вычислительных узлах в один момент времени данные не противоречат друг другу;
🔹доступность (Availability) — любой запрос к распределённой системе завершается откликом, однако без гарантии, что ответы всех узлов системы совпадают;
🔻устойчивость к разделению (Partition tolerance) — расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций.
Сформулированная как эмпирическое утверждение, CAP-теорема была впоследствии формализована и доказана, а также показана важность синхронизации часов в распределенных системах. Почему-то редко слышу про это в разговорах о микросервисах, но служба точного времени становится критически важной для синхронизации последовательных операций, там, где это важно (и для журналирования при интеграциях).
CAP-теорему часто критикуют за то, что под согласованностью и доступностью в своем формальном виде она имеет в виду не совсем то, что обычно под этим подразумевают. Но знать её всё равно нужно, чтобы осмысленно разговаривать с архитекторами и принимать обоснованные решения.
Расширение CAP — теорема PACELC (добавляет выбор между задержками — Latency — и согласованностью, даже если система не разделена, т.к. информация по сети не передается мгновенно).
Эти законы и теоремы стоит знать и учитывать (а про CAP-теорему бывает и на собеседованиях спрашивают!)
Отмечается вот прямо сейчас — 3/14 в 1:59:26
Нужно печь пи-роги и пить напитки, начинающиеся на "пи".
Удачно совпало с Масленицей, блины же тоже круглые!
В разработке ПО нет таких известных констант, но есть множество законов разной степени доказанности — от формальных теорем до эмпирических наблюдений. И все очень полезные! В основном они относятся к управлению, архитектуре или UX. Вот небольшой список:
Закон Брукса:
Добавление людей в запаздывающий проект вызывает ещё большее отставание.
(Это из книги "Мифический человеко-месяц", принципиальные вещи оттуда не изменились за почти 50 лет. Там много интересного, например формула, по которой "просто программа" обходится в 9 раз дешевле, чем протестированный, документированный и интегрированный программный продукт).
Закон Хофштадтера (того самого, который автор книги "Гёдель, Эшер, Бах: бесконечная гирлянда"):
Любое дело занимает больше времени, чем вы ожидали, даже если учесть Закон Хофштадтера.
Закон Конвея (это не тот Конвей, который изобрел игру "Жизнь" и сюрреальные числа. А сам закон очень важен для организации команд — отсюда растет DDD и микросервисы):
Организации, проектирующие системы, создают архитектуры, повторяющие структуру коммуникации этих организаций.
Принцип Постела (важен для интеграций):
Система должна быть консервативна в том, что она отправляет, и либеральна в том, что она принимает на вход.
Принцип Парето (применительно к ПО):
80% пользы получается от 20% функций системы.
Закон Линуса (Торвальдса, создателя Linux):
Под множеством взглядов все дефекты всплывают на поверхность.
(очень важно для нагруженных систем: мне рассказывали, что на главной странице Яндекса, к которой обращаются больше 1,5 млрд раз в день, сбои, вероятность которых 0,0000001%, происходят 10 раз в день! То есть, для нормальной работы вероятности сбоев должны быть сильно меньше.)
Закон Вирта:
ПО становится медленнее быстрее чем железо становится быстрее.
Фундаментальная теорема программной инженерии:
Любая проблема может быть решена добавлением ещё одного уровня абстракции.
Эти законы шуточные, но есть и формально доказанные теоремы. На удивление, их не очень много.
Одна из них — Теорема Кодда (создателя реляционной алгебры), которая доказывает эквивалентность операций реляционной алгебры и языка SQL. Несмотря на критику, реляционные базы до сих пор актуальны, т.к. под ними лежит формальная математическая теория со строгими доказательствами.
Другая, очень часто поминаемая в архитектуре распределенных систем: CAP-теорема (или теорема Брюера). Она утверждает, что в распределенной системе можно обеспечить не более двух свойств из триады:
🔸согласованность данных (Consistency) — во всех вычислительных узлах в один момент времени данные не противоречат друг другу;
🔹доступность (Availability) — любой запрос к распределённой системе завершается откликом, однако без гарантии, что ответы всех узлов системы совпадают;
🔻устойчивость к разделению (Partition tolerance) — расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций.
Сформулированная как эмпирическое утверждение, CAP-теорема была впоследствии формализована и доказана, а также показана важность синхронизации часов в распределенных системах. Почему-то редко слышу про это в разговорах о микросервисах, но служба точного времени становится критически важной для синхронизации последовательных операций, там, где это важно (и для журналирования при интеграциях).
CAP-теорему часто критикуют за то, что под согласованностью и доступностью в своем формальном виде она имеет в виду не совсем то, что обычно под этим подразумевают. Но знать её всё равно нужно, чтобы осмысленно разговаривать с архитекторами и принимать обоснованные решения.
Расширение CAP — теорема PACELC (добавляет выбор между задержками — Latency — и согласованностью, даже если система не разделена, т.к. информация по сети не передается мгновенно).
Эти законы и теоремы стоит знать и учитывать (а про CAP-теорему бывает и на собеседованиях спрашивают!)
🔥13👍8❤4👏1😁1
В области UX есть множество ещё более удивительных законов:
Закон Фиттса:
В большую и близко расположенную цель легче попасть [курсором или пальцем], чем в маленькую и удаленную.
Это, кстати, экспериментально доказанный факт, даже с формулой:
T = a + b * log ( D / W + 1),
где T - среднее время, затрачиваемое на совершение действия, a - среднее время запуска/остановки движения, b - величина, зависящая от типичной скорости движения, D - дистанция от точки старта до центра цели, W - ширина цели, измеренная вдоль оси движения.
Практический вывод: не заставляйте пользователя совершать очень точные движения и попадать в маленькие элементы. Делайте элементы управления большими! Избегайте длинных выпадающих списков. Группируйте действия, которые могут выполняться последовательно.
Закон Хикса:
Время на принятие решения растет с числом вариантов решения.
(поэтому не заставляйте пользователя думать!)
Как использовать: подсвечивайте и устанавливайте по умолчанию наиболее очевидную опцию; скрывайте редко используемые варианты; разбивайте сложную задачу (форму) на отдельные шаги.
Закон Якоба:
Пользователь проводит большую часть своего времени НЕ в вашем приложении.
Как использовать: делайте интерфейс похожим на другие приложения, к которым привык ваш пользователь (кради как художник!), избегайте радикального редизайна.
Закон Миллера:
Средний человек может удерживать в кратковременной памяти 7±2 элемента (скорее 5).
Закон Теслера:
Каждая система имеет определенный минимальный уровень сложности, который не может быть упрощен ещё сильнее.
(У нас очень сложный интерфейс? Так у нас и система сложная! Все приводят в пример поисковую строку Google, а вы когда-нибудь видели интерфейс Google Analytics или Ads? Вот где UX-то плакал)
Эффект фон Ресторфф:
Из набора однотипных объектов лучше всего запоминается один, который отличается от остальных.
Эффект Зейгарник:
Пользователь помнит незавершенные задачи дольше, чем завершенные.
(если задача не завершена — не может перестать про неё думать, не закрыт гештальт).
На практике это означает, что нужно показывать пользователю индикатор прогресса и явный знак его завершения.
Закон прегнатности:
Если есть несколько вариантов восприятия объектов, мозг выбирает наиболее простую форму их группировки.
То есть, если мы видим несколько объектов, расположенных рядом друг с другом, то мозг не воспринимает их по одиночке — он объединяет их в группу ("о, тут какие-то поля про личные данные").
Есть факторы, способствующие такому объединению:
🔸 близость: элементы, находящиеся близко друг к другу, воспринимаются как связанные;
🔸 сходство: похожие элементы воспринимаются, как связанные (или вообще как единое целое). Похожесть может быть в разных признаках: форме, цвете, размере.
🔸 "хорошее продолжение": если элементы выстраиваются в простую понятную фигуру, мозг воспринимает их, как единую фигуру, даже если часть этой "фигуры" перекрыта.
🔸 "общая судьба": это динамический фактор — если элементы движутся в одну сторону — они связаны.
🔸 симметрия: симметричные объекты воспринимаются как связанные
🔸 однотипная связь: объекты, соединенные линиями, уж точно связаны!
Это всё принципы гештальт-психологии, стремления к целостности.
Как применять: группировать визуально поля на формах и в отчетах по логике их связей; избегать случайных группировок (например, из соображений симметрии); следить за тем, чтобы в группу связанных элементов не попадали элементы, не относящиеся к этой области; следить за тем, чтобы одинаковые элементы отображались одинаково, а разные — по-разному.
Вроде бы, все эти "законы" довольно очевидны, но как часто мы видим их нарушение в дизайне! И это то, что можно формально проверить, когда дизайнер предлагает вам макет интерфейса.
Про законы в UX есть даже целый сайт: https://lawsofux.com/ , там можно прочесть про них подробнее, посмотреть примеры и советы по применению.
UPD: а вот на русском: https://lawsofux.ru/
Закон Фиттса:
В большую и близко расположенную цель легче попасть [курсором или пальцем], чем в маленькую и удаленную.
Это, кстати, экспериментально доказанный факт, даже с формулой:
T = a + b * log ( D / W + 1),
где T - среднее время, затрачиваемое на совершение действия, a - среднее время запуска/остановки движения, b - величина, зависящая от типичной скорости движения, D - дистанция от точки старта до центра цели, W - ширина цели, измеренная вдоль оси движения.
Практический вывод: не заставляйте пользователя совершать очень точные движения и попадать в маленькие элементы. Делайте элементы управления большими! Избегайте длинных выпадающих списков. Группируйте действия, которые могут выполняться последовательно.
Закон Хикса:
Время на принятие решения растет с числом вариантов решения.
(поэтому не заставляйте пользователя думать!)
Как использовать: подсвечивайте и устанавливайте по умолчанию наиболее очевидную опцию; скрывайте редко используемые варианты; разбивайте сложную задачу (форму) на отдельные шаги.
Закон Якоба:
Пользователь проводит большую часть своего времени НЕ в вашем приложении.
Как использовать: делайте интерфейс похожим на другие приложения, к которым привык ваш пользователь (кради как художник!), избегайте радикального редизайна.
Закон Миллера:
Средний человек может удерживать в кратковременной памяти 7±2 элемента (скорее 5).
Закон Теслера:
Каждая система имеет определенный минимальный уровень сложности, который не может быть упрощен ещё сильнее.
(У нас очень сложный интерфейс? Так у нас и система сложная! Все приводят в пример поисковую строку Google, а вы когда-нибудь видели интерфейс Google Analytics или Ads? Вот где UX-то плакал)
Эффект фон Ресторфф:
Из набора однотипных объектов лучше всего запоминается один, который отличается от остальных.
Эффект Зейгарник:
Пользователь помнит незавершенные задачи дольше, чем завершенные.
(если задача не завершена — не может перестать про неё думать, не закрыт гештальт).
На практике это означает, что нужно показывать пользователю индикатор прогресса и явный знак его завершения.
Закон прегнатности:
Если есть несколько вариантов восприятия объектов, мозг выбирает наиболее простую форму их группировки.
То есть, если мы видим несколько объектов, расположенных рядом друг с другом, то мозг не воспринимает их по одиночке — он объединяет их в группу ("о, тут какие-то поля про личные данные").
Есть факторы, способствующие такому объединению:
🔸 близость: элементы, находящиеся близко друг к другу, воспринимаются как связанные;
🔸 сходство: похожие элементы воспринимаются, как связанные (или вообще как единое целое). Похожесть может быть в разных признаках: форме, цвете, размере.
🔸 "хорошее продолжение": если элементы выстраиваются в простую понятную фигуру, мозг воспринимает их, как единую фигуру, даже если часть этой "фигуры" перекрыта.
🔸 "общая судьба": это динамический фактор — если элементы движутся в одну сторону — они связаны.
🔸 симметрия: симметричные объекты воспринимаются как связанные
🔸 однотипная связь: объекты, соединенные линиями, уж точно связаны!
Это всё принципы гештальт-психологии, стремления к целостности.
Как применять: группировать визуально поля на формах и в отчетах по логике их связей; избегать случайных группировок (например, из соображений симметрии); следить за тем, чтобы в группу связанных элементов не попадали элементы, не относящиеся к этой области; следить за тем, чтобы одинаковые элементы отображались одинаково, а разные — по-разному.
Вроде бы, все эти "законы" довольно очевидны, но как часто мы видим их нарушение в дизайне! И это то, что можно формально проверить, когда дизайнер предлагает вам макет интерфейса.
Про законы в UX есть даже целый сайт: https://lawsofux.com/ , там можно прочесть про них подробнее, посмотреть примеры и советы по применению.
UPD: а вот на русском: https://lawsofux.ru/
🔥26👍5❤4
Курс по технике разработки требований уже на этой неделе! Осталость ещё пара мест, можно успеть.
Дальше по плану — онлайн-конференция "Проектирование промышленных ИТ-систем", тоже от Systems.Education, и программа там просто огонь! Это 20-21 апреля. https://systemsdesign.online/
Потом уже в мае в Санкт-Петербурге сначала Analyst Days (24-25), а потом Анализ & Управление от Инфостарта (30-1).
А там и ЛАФ в июле!
Очень насыщенный событиями для аналитиков год, выбирай — не хочу!
А ещё лично меня можно увидеть в марте на классическом курсе-боевике "Системный анализ. Разработка требований в ИТ-проектах" от школы системного анализа и проектирования Systems.Education.
Курс просто ставит голову системного аналитика на место и даёт четкий и последовательный план работы над проектом требований к новой системе. Как писать требования, когда применять use cases, как думать про НФТ и зачем нужна контекстная диаграмма и модель предметной области — всё расскажу. Идёт уже больше 10 лет, практически живая легенда, а не курс! Буду вести его очно в Москве 21-23 марта.
А в апреле будет его продолжение: разработка проекта интеграции, для опытных аналитиков — "Основы проектирования интеграций ИТ-систем". Тут мы разбираемся с интеграциями систем во всех видах, от обмена файлами до брокеров сообщений, и, конечно, особенно подробно с проектированием REST API. Это уже апрель, тоже очно в Москве, с 4 по 6.
Дальше по плану — онлайн-конференция "Проектирование промышленных ИТ-систем", тоже от Systems.Education, и программа там просто огонь! Это 20-21 апреля. https://systemsdesign.online/
Потом уже в мае в Санкт-Петербурге сначала Analyst Days (24-25), а потом Анализ & Управление от Инфостарта (30-1).
А там и ЛАФ в июле!
Очень насыщенный событиями для аналитиков год, выбирай — не хочу!
👍5
Из перечисленных выше законов хочу обратить внимание на принцип Постела или Принцип устойчивости (Robustness principle).
Изначально его сформулировал Джон Постел, разработчик множества интернет-протоколов. Многих учёных и инженеров называют "отцами" и "матерями" Интернета, а Постела ещё при жизни звали "God of the Internet", хотя он сам был против такого именования.
Принцип устойчивости впервые приведен в RFC 760 со скромным названием "Internet Protocol". Позже переформулирован в RFC 1122: "Требования к хостам Internet". То есть, принцип изначально относится к приему и отправке IP-пакетов, и звучит так:
Всё это так же справедливо и на прикладном уровне, то есть в API. Особенно если вы проектируете открытые API или API микросервисов. Либерализм в том, что ваше API принимает на вход, позволяет развивать API, не создавая излишней связности между сервисом и его клиентами. Вот хорошая статья с примерами.
В этом есть некоторое противоречие: когда вам рассказывают про API, обязательно говорят про схемы запросов и ответов (json-schema, xsd, схема в OpenAPI), и эти схемы исподволь продвигают идею контроля: больше правил валидации, точное указание типов данных и набора полей. Одновременно схема используется для генерации кода на клиентах и сервере. Удобно, если вы можете менять клиентов и сервер одновременно. Но это и означает связанность и синхронизацию релизов!
Так можно делать, если:
1) ваше API внутреннее;
И/ИЛИ
2) стабильность вашего сервиса важнее удобства клиентов (вы намного главнее и не зависите от клиентов - например, вы гос.орган, под который все подстроятся)
А вот расшивка клиентов и сервера требует сооблюдения принципа устойчивости. Для API это означает, что схема запросов должна:
🔸допускать в запросах неизвестные поля и параметры (сервер должен игнорировать их и не выдавать ошибку);
🔸принимать значения в виде строк, а не чисел/булевых;
🔸не ограничивать значения набором символов, масками и регулярными выражениями;
🔸избегать перечислимых типов (enum);
🔸не ограничивать максимальный размер списков;
Это не означает, что вообще не нужно делать никакие проверки — это означает, что не следует отправлять ошибку сразу при проверке запроса, до обработки. То есть, приняли, как есть, попытались обработать, всё, что не соответствует ожидаемому формату — записали в журнал. Проверки делаем не на уровне API, а немного за ним, поближе к логике: форматы и валидацию делаем там, а заодно санитарную обработку запроса — удаляем разные варианты инъекций, XML-бомб и т.п. И никогда не передавать/принимать напрямую бизнес-объекты без валидации и проверок!
То же касается и клиента, которых должен уметь обрабатывать ответ сервера и не рушиться, несмотря на лишние поля и "неправильные" типы данных. Это позволит не синхронизировать обновления клиентов и сервера, и жить в период рассинхронизации — когда изменения не доехали или откатились.
Изначально его сформулировал Джон Постел, разработчик множества интернет-протоколов. Многих учёных и инженеров называют "отцами" и "матерями" Интернета, а Постела ещё при жизни звали "God of the Internet", хотя он сам был против такого именования.
Принцип устойчивости впервые приведен в RFC 760 со скромным названием "Internet Protocol". Позже переформулирован в RFC 1122: "Требования к хостам Internet". То есть, принцип изначально относится к приему и отправке IP-пакетов, и звучит так:
Программы должны уметь обрабатывать все мыслимые ошибки; не имеет значения вероятность возникновения той или иной ошибки - раньше или позже пакет с любой возможной комбинацией ошибок и/или атрибутов будет получен и программа должна быть готова к обработке такого пакета.Если программа не может эффективно обрабатывать ошибки, она приведет прямой дорогой к хаосу.В общем случае лучше предположить, что сеть наводнена зловредными объектами, которые постоянно передают пакеты, предназначенные для нанесения максимального вреда. Такое предположение обеспечит высокий уровень защиты.Наиболее серьезные проблемы в Internet связаны с неисследованными механизмами, включающимися с малой вероятностью; намерения обычных злоумышленников никогда не могут принести такого вреда!
На всех уровнях программ хостов Internet должны быть реализованы средства адаптации.Если спецификация протокола предполагает четыре возможных кода ошибки, приложение должно уметь обрабатывать по крайней мере пять типов ошибок (4 заданных и все остальные).Появление не определенных в спецификации кодов должно протоколироваться, но не должно нарушать работу системы.
Всё это так же справедливо и на прикладном уровне, то есть в API. Особенно если вы проектируете открытые API или API микросервисов. Либерализм в том, что ваше API принимает на вход, позволяет развивать API, не создавая излишней связности между сервисом и его клиентами. Вот хорошая статья с примерами.
В этом есть некоторое противоречие: когда вам рассказывают про API, обязательно говорят про схемы запросов и ответов (json-schema, xsd, схема в OpenAPI), и эти схемы исподволь продвигают идею контроля: больше правил валидации, точное указание типов данных и набора полей. Одновременно схема используется для генерации кода на клиентах и сервере. Удобно, если вы можете менять клиентов и сервер одновременно. Но это и означает связанность и синхронизацию релизов!
Так можно делать, если:
1) ваше API внутреннее;
И/ИЛИ
2) стабильность вашего сервиса важнее удобства клиентов (вы намного главнее и не зависите от клиентов - например, вы гос.орган, под который все подстроятся)
А вот расшивка клиентов и сервера требует сооблюдения принципа устойчивости. Для API это означает, что схема запросов должна:
🔸допускать в запросах неизвестные поля и параметры (сервер должен игнорировать их и не выдавать ошибку);
🔸принимать значения в виде строк, а не чисел/булевых;
🔸не ограничивать значения набором символов, масками и регулярными выражениями;
🔸избегать перечислимых типов (enum);
🔸не ограничивать максимальный размер списков;
Это не означает, что вообще не нужно делать никакие проверки — это означает, что не следует отправлять ошибку сразу при проверке запроса, до обработки. То есть, приняли, как есть, попытались обработать, всё, что не соответствует ожидаемому формату — записали в журнал. Проверки делаем не на уровне API, а немного за ним, поближе к логике: форматы и валидацию делаем там, а заодно санитарную обработку запроса — удаляем разные варианты инъекций, XML-бомб и т.п. И никогда не передавать/принимать напрямую бизнес-объекты без валидации и проверок!
То же касается и клиента, которых должен уметь обрабатывать ответ сервера и не рушиться, несмотря на лишние поля и "неправильные" типы данных. Это позволит не синхронизировать обновления клиентов и сервера, и жить в период рассинхронизации — когда изменения не доехали или откатились.
❤17👍5
Ну вот, кстати, по поводу либеральной обработки входной информации. Не дотянули немного до 1 апреля 😆
Зато смотрите, как грамотно: ошибки http с кодами 2xx — это успешно выполненные запросы. Там уже есть 200 OK, 201 — Created, 202 — принято на обработку, запущен долгий процесс, 203 — информация не из первичного источника, 206 — возвращена запрошенная часть ресурса.
Сомнительно, впрочем, что API возвращают такие ответы, а клиенты умеют их обрабатывать. Обычно всё ограничивается 200 — окэй.
Зато смотрите, как грамотно: ошибки http с кодами 2xx — это успешно выполненные запросы. Там уже есть 200 OK, 201 — Created, 202 — принято на обработку, запущен долгий процесс, 203 — информация не из первичного источника, 206 — возвращена запрошенная часть ресурса.
Сомнительно, впрочем, что API возвращают такие ответы, а клиенты умеют их обрабатывать. Обычно всё ограничивается 200 — окэй.
😁24❤7👍2
У статьи про стажера Васю и идемпотентность, про которую писал тут, оказывается, есть продолжение, в котором Вася разбирается с ретраями — повторными запросами. При идемпотентности такие перезапросы выполнять безопасно. Вот только они могут добить замедлившийся сервер.
Хотя статьи эти написаны в первую очередь для разработчиков, аналитикам, особенно проектирующим API, тоже нужно разбираться в теме. Особенно критичной тема перезапросов становится при наличии множества экземпляров клиента (фронтового клиента или клиента-микросервиса) и высокой нагрузки. Если у вас API используется только между двумя экземплярами системы раз в сутки — то вам и заморачиваться особо не нужно (и вообще это больше похоже на ETL, а не на API).
Впрочем, в любом случае стоит рассчитывать, что удаленный сервер упадет. Вопросы только — когда и какова будет продолжительность недоступности.
Даже если сервер не упадет совсем, а просто замедлится — начнет расти число активных клиентов по Закону Литтла: число клиентов в очереди равно интенсивности запросов умноженное на среднее время обработки запроса. Через некоторое время сервер просто перестанет отвечать: все доступные соединения будут заняты. Если клиент сам обрабатывает запрос другого сервиса — что бывает очень часто в микросервисной архитектуре — задержка начнет распространяться по всей системе в обратную сторону, и ляжет всё.
Как сказано в статье от AWS:
Какие моменты в статье про Васю и на что нужно обратить внимание, когда в проектируете перезапросы:
1. Максимальное число перезапросов (в какой-то момент нужно остановиться и выдать ошибку)
2. Промежутки между запросами: равные или увеличивающиеся (exponential backoff)? Кроме экспоненциального роста промежутка бывают ещё увеличивающиеся по последовательности Фибоначчи.
3. Максимальное время, пока мы вообще делаем перезапросы.
4. Jitter — случайная задержка между запросами, чтобы распределить нагрузку от разных экземпляров клиентов.
5. Circuit Breaker — "размыкатель" — отключение ретраев при превышении числа неисполненных запросов определенного порога, например — 20%
6. Retry Budget — на перезапросы выделяется ограниченный "бюджет", доля от общего числа запросов. В статье от AWS упомянут "алгоритм маркерной корзины", который работает примерно так: от каждого успешного запроса клиент "откладывает" в "корзину" часть маркера/токена, например, 0.1. Для того, чтобы сделать перезапрос, клиент должен "взять" из корзины целый токен (соотношение 1/10). Если целых токенов в корзине нет — перезапрос не на что сделать.
Также в статье описана техника deadline propagation — когда клиент передает серверу в заголовке запроса значение таймаута, после которого он будет делать ретрай. Если сервер понимает, что не укладывается в таймаут, он сразу прерывает выполнение запроса и возвращает ошибку, причем учитывает ожидание ответа от следующего сервера в цепочке.
P.S.: Кроме статьи про ретраи, про Васю есть ещё статья, в которой он проектирует API, там тоже много интересного.
Хотя статьи эти написаны в первую очередь для разработчиков, аналитикам, особенно проектирующим API, тоже нужно разбираться в теме. Особенно критичной тема перезапросов становится при наличии множества экземпляров клиента (фронтового клиента или клиента-микросервиса) и высокой нагрузки. Если у вас API используется только между двумя экземплярами системы раз в сутки — то вам и заморачиваться особо не нужно (и вообще это больше похоже на ETL, а не на API).
Впрочем, в любом случае стоит рассчитывать, что удаленный сервер упадет. Вопросы только — когда и какова будет продолжительность недоступности.
Даже если сервер не упадет совсем, а просто замедлится — начнет расти число активных клиентов по Закону Литтла: число клиентов в очереди равно интенсивности запросов умноженное на среднее время обработки запроса. Через некоторое время сервер просто перестанет отвечать: все доступные соединения будут заняты. Если клиент сам обрабатывает запрос другого сервиса — что бывает очень часто в микросервисной архитектуре — задержка начнет распространяться по всей системе в обратную сторону, и ляжет всё.
Как сказано в статье от AWS:
Рассмотрим систему, в которой вызов пользователя создает пятиуровневый стек вызовов сервиса. Он предусматривает отправку в итоге запроса к базе данных, а также три повторные попытки на каждом уровне. Что происходит, когда в базе данных начинают возникать ошибки запросов вследствие нагрузки? Если на каждом уровне выполняются свои повторные попытки, нагрузка на базу данных увеличится в 243 раза, что сделает ее восстановление маловероятным.
Какие моменты в статье про Васю и на что нужно обратить внимание, когда в проектируете перезапросы:
1. Максимальное число перезапросов (в какой-то момент нужно остановиться и выдать ошибку)
2. Промежутки между запросами: равные или увеличивающиеся (exponential backoff)? Кроме экспоненциального роста промежутка бывают ещё увеличивающиеся по последовательности Фибоначчи.
3. Максимальное время, пока мы вообще делаем перезапросы.
4. Jitter — случайная задержка между запросами, чтобы распределить нагрузку от разных экземпляров клиентов.
5. Circuit Breaker — "размыкатель" — отключение ретраев при превышении числа неисполненных запросов определенного порога, например — 20%
6. Retry Budget — на перезапросы выделяется ограниченный "бюджет", доля от общего числа запросов. В статье от AWS упомянут "алгоритм маркерной корзины", который работает примерно так: от каждого успешного запроса клиент "откладывает" в "корзину" часть маркера/токена, например, 0.1. Для того, чтобы сделать перезапрос, клиент должен "взять" из корзины целый токен (соотношение 1/10). Если целых токенов в корзине нет — перезапрос не на что сделать.
Также в статье описана техника deadline propagation — когда клиент передает серверу в заголовке запроса значение таймаута, после которого он будет делать ретрай. Если сервер понимает, что не укладывается в таймаут, он сразу прерывает выполнение запроса и возвращает ошибку, причем учитывает ожидание ответа от следующего сервера в цепочке.
P.S.: Кроме статьи про ретраи, про Васю есть ещё статья, в которой он проектирует API, там тоже много интересного.
🔥13👍6❤1🙏1
В статье про то, как Вася проектировал API, есть блок про безопасность.
Но не такую безопасность, как https и схемы авторизации, а не совсем очевидную: раскрытие чувствительных данных и компрометация системы.
Компрометацию я видел вблизи и в очень неприятном виде: в сервисе электронных домашних заданий (которые прямо на компьютере можно выполнять, то есть это по сути тесты) имелся API, через который можно было получить верные ответы. Разумеется, школьники его сразу же обнаружили и начали использовать: появились боты, выдающие правильные номера ответов. Да, через некоторое время проверку полностью перенесли на сервер, но обратно убедить учителей, что теперь-то школьники не смогут найти правильные ответы, так полностью и не удалось.
Про ситуации, когда по известной структуре адреса можно скачать документ безо всякой авторизации, думаю, вы не раз слышали. То есть, у вас есть бинарный документ (doc, pdf, xls) или образ (jpg, png), и он лежит в файловом хранилище, а в ответ API подставляется по ссылке. Если ссылки устроены однотипно, а файлы имеют упорядоченные наименования — например, по порядку, или по дате — то можно выкачать их все. Например, как это было на Госуслугах.
Ну и другие открытые метаданные бывают интересными, вот тут статья про анализ поведения такси по открытым данным.
На что стоит обратить внимание:
✅ полномочия доступа к статическим ресурсам тоже должны проверяться. Ну, это не всегда хочется или есть возможность сделать. поэтому есть следующее правило:
✅ выдача идентификаторов не должна идти подряд! Иначе можно простым инкрементом вытащить сразу много объектов. А также, например, узнать прирост числа объектов за день, что тоже может быть интересным.
✅ не показывайте ссылки на технические домены — для мониторинга и отслеживания ошибок. Если уж ссылаетесь, то не размещайте там же, например, репозиториев с кодом или открытых технических страниц / админок по стандартным адресам. А то мы тут с сыном, пока ждали очереди в поликлинике, запустили на их справочном киоске youtube — именно по цепочке незакрытых технических ссылок.
✅ избегайте бесконтрольное перекладывание данных из БД в API, включая мета-информацию (кто создал, кто последний раз обновлял, и т.п.)
✅ не выдавайте лишней информации в ошибках. Например, API Github не выдает ошибку 403 при попытке доступа к приватному ресурсу, а выдает 404 — чтобы нельзя было в принципе обнаружить существование такого ресурса!
✅ контролируйте частоту запросов от одного клиента — у того же Github есть сложная система с первичными и вторичными лимитами, можно взять, как источник вдохновения.
✅ контроль подозрительной широты запросов клиента, не соответствующих естественным бизнес-потребностям (от имени учителя истории в средней школе множество запросов результатов тестов по математике и физике 10-11 классов)
✅ не передавайте алгоритм расчета или проверки на клиента (хотели тонкого клиента и избежать обновлений клиентов). Тут понятно — передать-то мы передали, а вот что клиент этот наш, и что именно по этому алгоритму он будет считать и проверять...
Но не такую безопасность, как https и схемы авторизации, а не совсем очевидную: раскрытие чувствительных данных и компрометация системы.
Компрометацию я видел вблизи и в очень неприятном виде: в сервисе электронных домашних заданий (которые прямо на компьютере можно выполнять, то есть это по сути тесты) имелся API, через который можно было получить верные ответы. Разумеется, школьники его сразу же обнаружили и начали использовать: появились боты, выдающие правильные номера ответов. Да, через некоторое время проверку полностью перенесли на сервер, но обратно убедить учителей, что теперь-то школьники не смогут найти правильные ответы, так полностью и не удалось.
Про ситуации, когда по известной структуре адреса можно скачать документ безо всякой авторизации, думаю, вы не раз слышали. То есть, у вас есть бинарный документ (doc, pdf, xls) или образ (jpg, png), и он лежит в файловом хранилище, а в ответ API подставляется по ссылке. Если ссылки устроены однотипно, а файлы имеют упорядоченные наименования — например, по порядку, или по дате — то можно выкачать их все. Например, как это было на Госуслугах.
Ну и другие открытые метаданные бывают интересными, вот тут статья про анализ поведения такси по открытым данным.
На что стоит обратить внимание:
✅ полномочия доступа к статическим ресурсам тоже должны проверяться. Ну, это не всегда хочется или есть возможность сделать. поэтому есть следующее правило:
✅ выдача идентификаторов не должна идти подряд! Иначе можно простым инкрементом вытащить сразу много объектов. А также, например, узнать прирост числа объектов за день, что тоже может быть интересным.
✅ не показывайте ссылки на технические домены — для мониторинга и отслеживания ошибок. Если уж ссылаетесь, то не размещайте там же, например, репозиториев с кодом или открытых технических страниц / админок по стандартным адресам. А то мы тут с сыном, пока ждали очереди в поликлинике, запустили на их справочном киоске youtube — именно по цепочке незакрытых технических ссылок.
✅ избегайте бесконтрольное перекладывание данных из БД в API, включая мета-информацию (кто создал, кто последний раз обновлял, и т.п.)
✅ не выдавайте лишней информации в ошибках. Например, API Github не выдает ошибку 403 при попытке доступа к приватному ресурсу, а выдает 404 — чтобы нельзя было в принципе обнаружить существование такого ресурса!
✅ контролируйте частоту запросов от одного клиента — у того же Github есть сложная система с первичными и вторичными лимитами, можно взять, как источник вдохновения.
✅ контроль подозрительной широты запросов клиента, не соответствующих естественным бизнес-потребностям (от имени учителя истории в средней школе множество запросов результатов тестов по математике и физике 10-11 классов)
✅ не передавайте алгоритм расчета или проверки на клиента (хотели тонкого клиента и избежать обновлений клиентов). Тут понятно — передать-то мы передали, а вот что клиент этот наш, и что именно по этому алгоритму он будет считать и проверять...
👍21
Знаете ли вы, что уровни обязательности требований стандартизированы? Ну, хотя бы в Интернете: есть RFC 2119, где перечислены следующие модальные глаголы:
MUST (необходимо) — а также требуется (REQUIRED) и нужно (SHALL), означают абсолютную необходимость.
MUST NOT (недопустимо), SHALL NOT (не позволяется) — соответственно, абсолютный запрет.
SHOULD (следует) и RECOMMENDED (рекомендуется) — требования, от выполнения которых можно отказаться при наличии разумных причин.
SHOULD NOT (не следует) и NOT RECOMMENDED (не рекомендуется) — эти вещи допустимы, но могут вызвать проблемы.
MAY (возможно) и OPTIONAL (опционально) — можно включать (для полноты), можно не включать (для упрощения) — в целом, все должны быть готовы к тому, что у кого-то эта функция может быть не реализована.
Конечно, все эти уровни имеют смысл, когда одна спецификация может иметь несколько реализаций — как при реализации интернет-протоколов разными вендорами.
Когда же мы сами можем столкнуться с подобной ситуацией? Конечно, когда мы разрабатываем общедоступное API! Помимо самой спецификации, в этом случае хорошо бы выпустить описание протокола взаимодействия, в котором перечислить — что является абсолютно необходимым, что — желаемым, а что — только опциональным. Соответственно, на своей стороне быть готовым обрабатывать запросы, в которых опущены опциональные параметры и данные.
Например, такую спецификацию я разрабатывал для открытого протокола приёма цифрового следа о действиях обучающегося для Университета 20.35 (подмножество протокола xAPI). Понятно, что мы не можем ожидать от всех клиентов, что они в полной мере реализуют весь протокол, и стоит в явном виде им сказать — что обязательно, а что можно опустить.
А вот в RFC 6919 от 1 апреля 2013 были добавлены дополнительные уровни требований:
MUST (BUT WE KNOW YOU WON'T) — необходимо (но мы знаем, что вы всё равно не сделаете). Думаю, тут не нужно объяснять, очень полезный уровень требований в реальных проектах! В реальной практике выражение в скобках очень часто опускается.
SHOULD CONSIDER (следует рассмотреть) — когда авторы спецификации хотели бы, чтобы тут что-то было сделано, но пока не придумали — что именно.
REALLY SHOULD NOT (действительно не следует) — когда мы знаем, что что-то нежелательное всё равно будет сделано, и поэтому не можем написать "недопустимо".
OUGHT TO (сделать это — ваш долг) — когда речь идёт скорее о моральных обязательствах, но мы не можем требовать этого по контракту.
WOULD PROBABLY (вероятно стоило бы) — когда четкого обоснования требования нет, на автор спецификации хочет надавить на разработчика, используя пассивную агрессию.
MAY WISH TO (могут пожелать) — описание почти бессмысленной функциональности, которую запросил кто-то из второстепенных согласующих и которую точно никто не будет делать, но намек на неё остается, чтобы не затягивать согласование документа.
COULD (может) — тонкий намек на критически важную функцию, но без жестких требований.
POSSIBLE (возможно) — авторы спецификации не пришли к единому мнению насчет этого. Кто-то считает, что такое вообще никогда не может произойти, но, скорее всего, это фундаментальная функция, и ситуация будет случаться очень часто.
MIGHT — не знаю, как перевести, я уже запутался в уровнях и тонкостях английских модальных глаголов. По-русски это тоже "может", но слабее, чем COULD и имеет оттенок просьбы.
На русском, конечно, стоило бы составить свой список. Я точно видел в документах "следует рассмотреть", "должно быть определено", "может потребоваться" и "возможно". А вы с какими уровнями обязательности сталкивались?
MUST (необходимо) — а также требуется (REQUIRED) и нужно (SHALL), означают абсолютную необходимость.
MUST NOT (недопустимо), SHALL NOT (не позволяется) — соответственно, абсолютный запрет.
SHOULD (следует) и RECOMMENDED (рекомендуется) — требования, от выполнения которых можно отказаться при наличии разумных причин.
SHOULD NOT (не следует) и NOT RECOMMENDED (не рекомендуется) — эти вещи допустимы, но могут вызвать проблемы.
MAY (возможно) и OPTIONAL (опционально) — можно включать (для полноты), можно не включать (для упрощения) — в целом, все должны быть готовы к тому, что у кого-то эта функция может быть не реализована.
Конечно, все эти уровни имеют смысл, когда одна спецификация может иметь несколько реализаций — как при реализации интернет-протоколов разными вендорами.
Когда же мы сами можем столкнуться с подобной ситуацией? Конечно, когда мы разрабатываем общедоступное API! Помимо самой спецификации, в этом случае хорошо бы выпустить описание протокола взаимодействия, в котором перечислить — что является абсолютно необходимым, что — желаемым, а что — только опциональным. Соответственно, на своей стороне быть готовым обрабатывать запросы, в которых опущены опциональные параметры и данные.
Например, такую спецификацию я разрабатывал для открытого протокола приёма цифрового следа о действиях обучающегося для Университета 20.35 (подмножество протокола xAPI). Понятно, что мы не можем ожидать от всех клиентов, что они в полной мере реализуют весь протокол, и стоит в явном виде им сказать — что обязательно, а что можно опустить.
А вот в RFC 6919 от 1 апреля 2013 были добавлены дополнительные уровни требований:
MUST (BUT WE KNOW YOU WON'T) — необходимо (но мы знаем, что вы всё равно не сделаете). Думаю, тут не нужно объяснять, очень полезный уровень требований в реальных проектах! В реальной практике выражение в скобках очень часто опускается.
SHOULD CONSIDER (следует рассмотреть) — когда авторы спецификации хотели бы, чтобы тут что-то было сделано, но пока не придумали — что именно.
REALLY SHOULD NOT (действительно не следует) — когда мы знаем, что что-то нежелательное всё равно будет сделано, и поэтому не можем написать "недопустимо".
OUGHT TO (сделать это — ваш долг) — когда речь идёт скорее о моральных обязательствах, но мы не можем требовать этого по контракту.
WOULD PROBABLY (вероятно стоило бы) — когда четкого обоснования требования нет, на автор спецификации хочет надавить на разработчика, используя пассивную агрессию.
MAY WISH TO (могут пожелать) — описание почти бессмысленной функциональности, которую запросил кто-то из второстепенных согласующих и которую точно никто не будет делать, но намек на неё остается, чтобы не затягивать согласование документа.
COULD (может) — тонкий намек на критически важную функцию, но без жестких требований.
POSSIBLE (возможно) — авторы спецификации не пришли к единому мнению насчет этого. Кто-то считает, что такое вообще никогда не может произойти, но, скорее всего, это фундаментальная функция, и ситуация будет случаться очень часто.
MIGHT — не знаю, как перевести, я уже запутался в уровнях и тонкостях английских модальных глаголов. По-русски это тоже "может", но слабее, чем COULD и имеет оттенок просьбы.
На русском, конечно, стоило бы составить свой список. Я точно видел в документах "следует рассмотреть", "должно быть определено", "может потребоваться" и "возможно". А вы с какими уровнями обязательности сталкивались?
👍23❤2😁2
У Григория Добрякова, которого здесь уже цитировал, вышел пост про управление требованиями.
К гигиеническому минимуму он относит вот что. Требования должны быть:
1. Сформулированы.
2. Записаны.
3. Доведены до адресатов.
4. Проверены на соответствие результатов.
В деталях:
Сформулированы: Должна быть буквально проведена работа по выявлению ожиданий. Кто, чего и от кого/чего ожидает. Особенно если неявно. Особенно если «ну я думал вы сами догадаетесь, это же очевидно».
Записаны: Должна быть буквально проведена работа по фиксированию всего о чём проговорили. Текстом, документом, табличкой, реестром, схемами, всем чем можете. Лаконично, но достаточно. Главная цель — ничего не оставить на словах.
Сюда же входит задача провалидировать записанное с заказчиками. Иван Иваныч, а я правильно записал? Ну-ка гляньте.
Доведены до адресатов: Доводить — это процесс, а не просто галочка в отчёте. Ты требование видел? А осознал? А технически реализовать сможешь? А ресурсы есть? А чё сломается если сделать буквально как написано?
Результат проверен на соответствие. Тут вроде понятно, причём это не только верификация, но и валидация: "Причём у малоопытных менеджеров результат может быть в полном соответствии с требованиями формально, но абсолютно вырвиглазно по сути."
Этот пост мне живо напомнил принцип 3C's Рона Джеффриса, сформулированный ещё в 2001 году применительно к пользовательским историям: Card, Conversation и Confirmation. Требования сформулированы и записаны — это Card. В оригинале карточка не равна требованию, сам Рон называет её токеном (token), вещью для представления требования и управления им. Такая заметка, чтобы не забыть, что нужно обсудить идею. Четвертую C обычно не упоминают, но это Commitment — обязательство. Как только идея — может быть, ещё даже не требование! — зафиксирована, у команды возникает обязательство её обсудить. В одном из проектов у меня даже KPI были такие — число обработанных идей, то есть — рассмотренных, обсужденных, возможно — проверенных экспериментом и принятых в работу.
Обсуждение — conversation — вот что важно. Это решает задачи и по формулированию, и по доведению до адресатов (тех, кто будет создавать реализацию). И тут стоит добавить пятую C — Collaboration. Требования не записаны в голове у стейкхолдера, требования - точнее, решения по свойствам будущего продукта — рождаются в ходе совместного обсуждения, поэтому обсуждение так важно. И особенно важна возможность свободного высказывания членами команды, предложения идей, уточнения запроса. Вовлечение команды разработки в процесс определения свойств продукта (специально не пишу "выявления требований"!). Иначе это прямой путь к выгоранию.
Тут опять возникает commitment: обсудив решение, команда принимает обязательство по его реализации. А коллаборация подключает "эффект Икеа": если ты принимал участие в разработке решения, то ценность его для тебя растет, и такое решение легче исполнять.
Ну и подтверждение, confirmation. В свежей (от 2019 года) статье про 3C's Рон пишет про сдвиг в сторону максимально конкретного выражения этого самого confirmation — в виде конкретных примеров, в идеале — исполнимых. Хуже ничего нет, чем "совещание по приёмке" — когда толпа людей просто идут по пунктам ТЗ и отмечают их реализацию путем осмотра готового ПО, без заготовленных примеров, без рассмотрения краевых ситуаций и стыков — на чем в последствии и вылезают большинство дефектов.
Так что, идеальная картина:
1. Зафиксировали намеченное требование (идею).
2. Обсудили вместе с заказчиком и представителями разработки, наметили способ реализации.
3. Составили и согласовали способ проверки.
4. Реализовали, проверили.
А для полного контроля и прозрачности хорошо бы завести правило, что ни одно изменение не вносится в систему без указания связи с требованием (тех.долг — это тоже требование!), ни одно требование не принимается без изменений в коде.
К гигиеническому минимуму он относит вот что. Требования должны быть:
1. Сформулированы.
2. Записаны.
3. Доведены до адресатов.
4. Проверены на соответствие результатов.
В деталях:
Сформулированы: Должна быть буквально проведена работа по выявлению ожиданий. Кто, чего и от кого/чего ожидает. Особенно если неявно. Особенно если «ну я думал вы сами догадаетесь, это же очевидно».
Записаны: Должна быть буквально проведена работа по фиксированию всего о чём проговорили. Текстом, документом, табличкой, реестром, схемами, всем чем можете. Лаконично, но достаточно. Главная цель — ничего не оставить на словах.
Сюда же входит задача провалидировать записанное с заказчиками. Иван Иваныч, а я правильно записал? Ну-ка гляньте.
Доведены до адресатов: Доводить — это процесс, а не просто галочка в отчёте. Ты требование видел? А осознал? А технически реализовать сможешь? А ресурсы есть? А чё сломается если сделать буквально как написано?
Результат проверен на соответствие. Тут вроде понятно, причём это не только верификация, но и валидация: "Причём у малоопытных менеджеров результат может быть в полном соответствии с требованиями формально, но абсолютно вырвиглазно по сути."
Этот пост мне живо напомнил принцип 3C's Рона Джеффриса, сформулированный ещё в 2001 году применительно к пользовательским историям: Card, Conversation и Confirmation. Требования сформулированы и записаны — это Card. В оригинале карточка не равна требованию, сам Рон называет её токеном (token), вещью для представления требования и управления им. Такая заметка, чтобы не забыть, что нужно обсудить идею. Четвертую C обычно не упоминают, но это Commitment — обязательство. Как только идея — может быть, ещё даже не требование! — зафиксирована, у команды возникает обязательство её обсудить. В одном из проектов у меня даже KPI были такие — число обработанных идей, то есть — рассмотренных, обсужденных, возможно — проверенных экспериментом и принятых в работу.
Обсуждение — conversation — вот что важно. Это решает задачи и по формулированию, и по доведению до адресатов (тех, кто будет создавать реализацию). И тут стоит добавить пятую C — Collaboration. Требования не записаны в голове у стейкхолдера, требования - точнее, решения по свойствам будущего продукта — рождаются в ходе совместного обсуждения, поэтому обсуждение так важно. И особенно важна возможность свободного высказывания членами команды, предложения идей, уточнения запроса. Вовлечение команды разработки в процесс определения свойств продукта (специально не пишу "выявления требований"!). Иначе это прямой путь к выгоранию.
Тут опять возникает commitment: обсудив решение, команда принимает обязательство по его реализации. А коллаборация подключает "эффект Икеа": если ты принимал участие в разработке решения, то ценность его для тебя растет, и такое решение легче исполнять.
Ну и подтверждение, confirmation. В свежей (от 2019 года) статье про 3C's Рон пишет про сдвиг в сторону максимально конкретного выражения этого самого confirmation — в виде конкретных примеров, в идеале — исполнимых. Хуже ничего нет, чем "совещание по приёмке" — когда толпа людей просто идут по пунктам ТЗ и отмечают их реализацию путем осмотра готового ПО, без заготовленных примеров, без рассмотрения краевых ситуаций и стыков — на чем в последствии и вылезают большинство дефектов.
Так что, идеальная картина:
1. Зафиксировали намеченное требование (идею).
2. Обсудили вместе с заказчиком и представителями разработки, наметили способ реализации.
3. Составили и согласовали способ проверки.
4. Реализовали, проверили.
А для полного контроля и прозрачности хорошо бы завести правило, что ни одно изменение не вносится в систему без указания связи с требованием (тех.долг — это тоже требование!), ни одно требование не принимается без изменений в коде.
👍21
Собственно, по управлению требованиями у нас есть целый ГОСТ Р 59194-2020.
Вот его основные положения.
1. Есть два вида деятельности:
— разработка требований (инженерная деятельность по выявлению, анализу, декомпозиции, проверке, согласованию и утверждению требований к изделию).
— контроль требований (управленческая деятельность, направленная на поддержание актуальности и согласованности требований к изделию и его СЧ в ходе всего ЖЦ изделия (в том числе при изменении потребностей заинтересованных сторон).
2. Требования могут быть представлены в форме базы данных или документа.
3. Есть исходные требования — фиксирующие потребности заинтересованных сторон и служащие для валидации,
и есть проектные требования — для разработки различной документации готового объекта и для верификации.
4. Есть два типа "контрольных рубежей":
— на которых проверяют, согласовывают и утверждают разработанные требования к объекту (в результате требованиям присваивают статус готовности);
— на которых проверяют соответствие объекта требованиям (в результате требованиям присваивают статус выполнения).
5. При проверке требований выполняют их валидацию и верификацию.
При валидации проверяют:
— полноту покрытия спецификацией исходных требований
— правильность выражения потребностей или отражения принятого технического решения
— наличие связи с потребностями или родительским требованием
— непротиворечивость
При верификации:
— что требования относятся к одному объекту (!)
— что требования соответствуют критериям качества
— что у них правильно заполнены атрибуты, они правильно классифицированы и связаны
— установлены критерии верификации и валидации объекта, который будет разработан по этим требованиям.
6. Минимальный набор атрибутов требования:
— Уникальный идентификатор
— Ссылка на потребность заинтересованной стороны (в идеале -- выраженной в документе. Ссылка на конкретный пункт документа)
— Для проектных требований — ссылка на исходное требование или запись о принятом техническом решении (привет ADR!)
7. Очень сильная идея: требования являются частью конфигурации!
И статус выполнения требования тоже относится к конкретной конфигурации и конкретному этапу работ (в стандарте они названы "контрольные рубежи").
То есть, одно и то же требование может быть выполнено в одной конфигурации, и не выполнено в другой!
Про конфигурации и их изменения есть соседний ГОСТ Р 59193-2020 "Управление конфигурацией", там, в частности, написано, как обходиться с изменениями конфигураций разных видов и по разным причинам (и изменениями требований, как части конфигурации).
Про конфигурации очень часто не задумываются, пока не обнаруживают себя в ситуации, когда развернуто 8-10 экземпляров одной и той же системы, отличающихся набором данных, справочников, функций, набором ролей, подключенных внешних систем и заглушек и средств мониторинга.
Причем никто в точности не знает — сколько их точно развернуто, где, чем они друг от друга отличаются и кто к ним имеет доступ.
Вот тут-то управление конфигурациями и начинается!
Вот его основные положения.
1. Есть два вида деятельности:
— разработка требований (инженерная деятельность по выявлению, анализу, декомпозиции, проверке, согласованию и утверждению требований к изделию).
— контроль требований (управленческая деятельность, направленная на поддержание актуальности и согласованности требований к изделию и его СЧ в ходе всего ЖЦ изделия (в том числе при изменении потребностей заинтересованных сторон).
2. Требования могут быть представлены в форме базы данных или документа.
3. Есть исходные требования — фиксирующие потребности заинтересованных сторон и служащие для валидации,
и есть проектные требования — для разработки различной документации готового объекта и для верификации.
4. Есть два типа "контрольных рубежей":
— на которых проверяют, согласовывают и утверждают разработанные требования к объекту (в результате требованиям присваивают статус готовности);
— на которых проверяют соответствие объекта требованиям (в результате требованиям присваивают статус выполнения).
5. При проверке требований выполняют их валидацию и верификацию.
При валидации проверяют:
— полноту покрытия спецификацией исходных требований
— правильность выражения потребностей или отражения принятого технического решения
— наличие связи с потребностями или родительским требованием
— непротиворечивость
При верификации:
— что требования относятся к одному объекту (!)
— что требования соответствуют критериям качества
— что у них правильно заполнены атрибуты, они правильно классифицированы и связаны
— установлены критерии верификации и валидации объекта, который будет разработан по этим требованиям.
6. Минимальный набор атрибутов требования:
— Уникальный идентификатор
— Ссылка на потребность заинтересованной стороны (в идеале -- выраженной в документе. Ссылка на конкретный пункт документа)
— Для проектных требований — ссылка на исходное требование или запись о принятом техническом решении (привет ADR!)
7. Очень сильная идея: требования являются частью конфигурации!
И статус выполнения требования тоже относится к конкретной конфигурации и конкретному этапу работ (в стандарте они названы "контрольные рубежи").
То есть, одно и то же требование может быть выполнено в одной конфигурации, и не выполнено в другой!
Про конфигурации и их изменения есть соседний ГОСТ Р 59193-2020 "Управление конфигурацией", там, в частности, написано, как обходиться с изменениями конфигураций разных видов и по разным причинам (и изменениями требований, как части конфигурации).
Про конфигурации очень часто не задумываются, пока не обнаруживают себя в ситуации, когда развернуто 8-10 экземпляров одной и той же системы, отличающихся набором данных, справочников, функций, набором ролей, подключенных внешних систем и заглушек и средств мониторинга.
Причем никто в точности не знает — сколько их точно развернуто, где, чем они друг от друга отличаются и кто к ним имеет доступ.
Вот тут-то управление конфигурациями и начинается!
👍8🔥7❤1🤔1