Области знаний
Партнёрские проектыМатериалы БРЭСпецпроектыСтать автором
Настроить видСменить языкИнформация
О РУВИКИ
Найти статью

Аналитик приложений

Pause

Экспертиза РАН

Logo-ran.pngLogo-ran-black.png
Проводится экспертиза
Российской академией наук
Подробнее
Times2.svg

Экспертиза РАН

Arrow-Right.png
Logo-ran.png
Проводится экспертиза
Российской академией наук
Подробнее

Анали́тик приложе́ний (также аналитик прикладны́х систе́м; англ. application analyst, applications analyst) — специалист, отвечающий за поддержку, администрирование, развитие и интеграцию прикладных программных систем организации. В обязанности входит исследование, проектирование, тестирование, сопровождение и модернизация компьютерных приложений для повышения производительности и эффективности бизнеса[1]. Аналитик приложений консультируется с руководством для определения целей и разрабатывает приложения для их достижения[2][3].

Профессия сочетает технические навыки работы с программным обеспечением и понимание бизнес-процессов. Аналитик приложений отвечает за конкретное приложение или группу приложений на всём протяжении их жизненного цикла, выступая связующим звеном между пользователями, бизнес-подразделениями и техническими командами[4][5].

Общие сведения
Что важно знать
Аналитик приложений
Область использования искусственный интеллект, программная инженерия, системный анализ, бизнес-анализ, управление продуктом, анализ данных, машинное обучение
Дата появления вторая половина 1960-х годов (как разновидность аналитика информационных систем); современная трактовка — 2010-е годы
Место появления США и Великобритания (индустрия обработки данных), затем международное распространение
Автор понятия складывалось коллективно в практике информационной индустрии; терминологическое закрепление связано с профессиональными стандартами и сводами знаний по бизнес-анализу
Ключевые слова требования к программному обеспечению, качество данных, метрика качества модели, машинное обучение, MLOps, приёмочное тестирование, дрейф данных, технический долг
Базовые понятия приложение, анализ требований, данные, модель машинного обучения, бизнес-процесс, жизненный цикл программного обеспечения

История

Предыстория: системный анализ и аналитики информационных систем

Прообраз профессии сложился в 1950—1960-е годы вместе с появлением коммерческой обработки данных. Внедрение вычислительных машин в учётные и плановые задачи потребовало посредника между специалистами предметной области и программистами, владеющими машинными кодами. Такого посредника называли «системным аналитиком»; его обязанностью было изучить существующий порядок работ, описать его в форме блок-схем и передать описание в программирование. Методологическую основу этой деятельности составил системный анализ, развивавшийся в тот же период в исследованиях операций и оборонном планировании[6].

В СССР аналогичные функции выполняли сотрудники отделов автоматизированных систем управления. Отечественная школа сформировала развитую нормативную традицию: состав и содержание работ по обследованию объекта автоматизации, техническому заданию и приёмочным испытаниям закреплялись в государственных стандартах (ГОСТ), а сама деятельность рассматривалась как проектирование организационно-технической системы, а не только программы[7].

Становление профессии аналитика приложений

В 1980-е и 1990-е годы с распространением персональных компьютеров и корпоративных информационных систем произошла дифференциация ролей. Появилась потребность в специалистах, отвечающих за конкретные прикладные системы предприятия — системы управления базами данных, бухгалтерские системы, системы автоматизации документооборота. Такие специалисты получили наименование «аналитики приложений», или «аналитики прикладных систем». Первоначально роль была ближе к технической поддержке и эксплуатации, чем к проектированию. Аналитики приложений занимались установкой, настройкой, обновлением и устранением неполадок в существующих системах. Однако по мере усложнения корпоративного программного обеспечения и роста его роли в бизнес-процессах в обязанности аналитиков вошла также работа с требованиями пользователей, тестирование новых версий и интеграция приложений между собой[8].

Хранилища данных и бизнес-анализ

В 1990-е и 2000-е годы центр тяжести сместился к накоплению и обобщению корпоративных данных. Распространение хранилищ данных и систем оперативной аналитической обработки (OLAP) породило спрос на специалистов, умеющих связать управленческий вопрос с содержимым витрины данных. Тогда же оформилась дисциплина бизнес-анализа со сводом знаний (BABOK), описавшим задачи выявления, документирования и проверки требований как самостоятельную профессиональную область[9].

В этот период в англоязычной кадровой практике окончательно закрепилось наименование application analyst — сотрудник, отвечающий за конкретную прикладную систему предприятия, её настройку, сопровождение и развитие. Профессия заняла промежуточное положение между чисто технической поддержкой и бизнес-анализом, требуя как понимания технологий, так и знания предметной области[10].

Современный этап

В 2010-е годы, с переходом к облачным технологиям, мобильным приложениям и микросервисной архитектуре, роль аналитика приложений существенно расширилась. Появилась необходимость интегрировать локальные системы с облачными сервисами, обеспечивать взаимодействие множества разнородных приложений через программные интерфейсы (API), управлять жизненным циклом приложений в условиях непрерывного обновления (CI/CD)[11].

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

Во второй половине 2010-х и в 2020-е годы появилось новое направление — аналитика приложений на основе искусственного интеллекта и машинного обучения. Хотя это направление остаётся нишевым по сравнению с традиционными корпоративными приложениями, оно требует от аналитиков дополнительных компетенций в области работы с вероятностными системами, оценки качества моделей и управления данными для обучения[13].

undefined

Определение и содержание понятия

Под аналитиком приложений понимается специалист, выполняющий следующие основные функции[14][15]:

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

В отличие от бизнес-аналитика, чей фокус смещён в сторону организационных процессов и экономического обоснования, и в отличие от системного аналитика, сосредоточенного на внутренней архитектуре и интеграционных интерфейсах на техническом уровне, аналитик приложений отвечает за конкретное приложение как за целостный продукт, за его функциональность, удобство и полезность для пользователей[16].

Аналитик приложений исследует, проектирует, устраняет неполадки и поддерживает компьютерные приложения для повышения производительности и эффективности работы организации[17].

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

Место в жизненном цикле приложения

Деятельность аналитика приложений распределена по всему жизненному циклу решения и не сводится к «этапу анализа» в начале проекта[19].

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

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

На стадии эксплуатации аналитик обеспечивает повседневную поддержку: отвечает на вопросы пользователей, устраняет инциденты, устанавливает обновления, мониторит производительность. Это наиболее продолжительная фаза, в которой проявляется основная часть обязанностей аналитика приложений[21].

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

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

Компетенции

Совокупность требуемых знаний можно разделить на несколько групп[22][23]:

  • технические компетенции включают знание операционных систем, баз данных, языков запросов (SQL), понимание архитектуры приложений, сетей и протоколов обмена данными. Аналитик должен уметь читать логи, диагностировать проблемы, писать простые скрипты для автоматизации рутинных задач[24];
  • предметные компетенции обеспечивают понимание области, в которой применяется приложение: без знания того, как устроен процесс кредитования, диспетчеризации или медицинской сортировки, аналитик не сможет эффективно поддерживать систему и общаться с пользователями на их языке;
  • компетенции в области данных включают умение составлять запросы к хранилищам, оценивать полноту и согласованность таблиц, понимать структуру данных приложения. Для приложений с элементами машинного обучения добавляется понимание основ математической статистики, необходимых для интерпретации результатов[25];
  • инженерные компетенции позволяют обсуждать с разработчиками программные интерфейсы (API), требования к задержкам, журналирование, версионирование, принципы непрерывной интеграции и поставки (CI/CD);
  • коммуникативные компетенции обеспечивают перевод между языками заказчика, технических специалистов и пользователей, включают навыки документирования, ведения переговоров, обучения пользователей, управления ожиданиями[26].

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

undefined

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

Выявление потребностей

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

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

Документирование требований

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

Для описания процессов используются нотации моделирования деловых процессов (BPMN), диаграммы состояний (UML) и сценарии использования[29].

Приоритизация

Третий шаг — согласование приоритетов с владельцем продукта и заинтересованными сторонами. Не все требования могут быть реализованы одновременно, поэтому необходимо определить, какие функции критически важны, какие желательны, какие могут быть отложены. Используются методы оценки ценности, стоимости, рисков[30].

Валидация и тестирование

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

undefined

Качество данных

Для многих приложений качество данных является критическим фактором. Аналитик приложений должен оценивать данные по нескольким измерениям[31]:

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

Аналитик выявляет проблемы с качеством данных, инициирует их исправление, проектирует проверки на уровне приложения. Для приложений, использующих машинное обучение, дополнительно требуется оценка репрезентативности данных и выявление смещённости, способной привести к систематическим ошибкам[32].

Эксплуатация и сопровождение

После ввода в эксплуатацию начинается основная фаза работы аналитика приложений. Сопровождение включает[33][34]:

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

Для приложений с элементами машинного обучения добавляется мониторинг качества моделей. Качество может снижаться со временем из-за изменения распределения входных данных (дрейф данных) или изменения самой зависимости между признаками и целевой величиной (концептуальный дрейф)[35].

Аналитик проектирует систему наблюдения: определяет состав контролируемых показателей, периодичность их расчёта, пороги предупреждений и порядок действий при их превышении. Решение о переобучении модели принимается на основании сопоставления затрат и выигрыша[36].

undefined

Взаимодействие с проектной командой

Аналитик приложений занимает срединное положение в коммуникационной структуре проекта. С пользователями он обсуждает потребности, проблемы, предложения по улучшению. С владельцем продукта согласует приоритеты и увязывает отдельные требования с планом развития[37][38].

С инженером данных он обсуждает состав витрин, регулярность обновления и обработку пропусков. Со специалистом по машинному обучению (data scientist) согласует требования к моделям, метрики качества, трактовку результатов (для приложений с ИИ). С разработчиками и тестировщиками уточняет поведение интерфейса, обработку исключений и состав приёмочных проверок[39].

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

Особенность взаимодействия состоит в необходимости управлять ожиданиями в обе стороны. Пользователи склонны ожидать немедленного решения всех проблем, а команда разработки — может недооценивать организационные препятствия внедрения. Аналитик выступает переводчиком и одновременно носителем реалистичной оценки[41].

undefined

Документы и артефакты

Результаты работы аналитика материализуются в наборе связанных документов[42]:

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

Для приложений с элементами ИИ в международной практике распространились также специализированные формы описания: карточки моделей с указанием назначения, обучающих данных, измеренного качества и известных ограничений[43].

undefined

Методы и инструменты

Методический арсенал заимствован из системного анализа и дополнен приёмами работы с данными. Для выявления потребностей применяются структурированные интервью, наблюдение за работой пользователей, анализ инцидентов и обращений в службу поддержки[44].

Для описания процессов используются нотации моделирования деловых процессов (BPMN), диаграммы состояний (UML) и сценарии использования (use case).

Инструментально работа опирается на:

  • язык структурированных запросов (SQL) для исследования данных;
  • системы управления базами данных;
  • средства мониторинга и логирования;
  • системы управления версиями (Git);
  • системы учёта задач и инцидентов (Jira, ServiceNow);
  • средства визуализации данных;
  • инструменты тестирования.

Умение самостоятельно получить и проверить цифру, не дожидаясь помощи инженера, существенно повышает скорость принятия решений, поэтому базовые навыки программирования на языке анализа данных (Python, R) становятся всё более востребованными[45].

Отдельную группу составляют методы оценки эффекта: сравнение с контрольной группой, поэтапное включение функции для части пользователей, анализ временных рядов показателей процесса до и после внедрения. Корректная постановка такого эксперимента (A/B тестирование) предотвращает распространённую ошибку, при которой улучшение приписывается системе, тогда как оно вызвано сезонностью или сопутствующими изменениями регламента[46].

Проектирование взаимодействия человека и системы

Полезность приложения определяется не только качеством реализации функций, но и тем, как система взаимодействует с пользователем. Аналитик описывает режимы работы системы, сценарии использования, обработку ошибок, сообщения пользователю[47].

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

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

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

Испытания и приёмка

Приёмка приложения отличается от простой проверки работоспособности. Аналитик заранее определяет состав тестовых сценариев, порядок их выполнения и критерии успешного прохождения[50][51].

Помимо проверки основных функций тестируются:

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

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

Организационное закрепление роли

Распространены три схемы включения аналитика в структуру организации[53]: при закреплении за подразделением-заказчиком аналитик глубоко понимает предметную область, но рискует утратить связь с техническими возможностями и повторять уже решённые в других подразделениях задачи; при включении в состав центра компетенций (IT-департамента) он сохраняет техническую квалификацию и единство методик, но отдаляется от повседневных нужд пользователей; смешанная схема, при которой сотрудник административно принадлежит центру компетенций, а функционально работает в составе продуктовой команды, признаётся наиболее устойчивой, хотя и требует согласованности в распределении приоритетов[54].

Примечания

  1. ↑ Applications Analyst Job Description // Monster.
  2. ↑ Application Systems Analyst Career and Salary Profile // Florida Tech Online.
  3. ↑ Job profile: Application analyst (англ.) // Prospects.
  4. ↑ What Is an Application Analyst? (With Duties and Skills) // Indeed.
  5. ↑ Руденко А. IT-аналитик: кто такой и чем занимается в разработке // Блог Cloud.ru. — 2025. — 23 апреля.
  6. ↑ Оптнер С. Л. Системный анализ для решения деловых и промышленных проблем / пер. с англ.. — Москва: Советское радио, 1969. — 216 с.
  7. ↑ Глушков В. М. Основы безбумажной информатики. — 2-е изд., испр.. — Москва: Наука, 1987. — 552 с.
  8. ↑ Senior Applications Analyst.
  9. ↑ Inmon William H. Building the Data Warehouse. — 4th ed.. — Indianapolis: Wiley, 2005. — 544 с. — ISBN 978-0-7645-9944-6.
  10. ↑ Кимбалл Р., Росс М. The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling. — 3rd ed.. — Indianapolis: Wiley, 2013. — 600 с. — ISBN 978-1-118-53080-1.
  11. ↑ Amershi S., Begel A., Bird C., DeLine R., Gall H. Software Engineering for Machine Learning: A Case Study // Proceedings of the 41st International Conference on Software Engineering: Software Engineering in Practice. — 2019. — С. 291–300. — doi:10.1109/ICSE-SEIP.2019.00042.
  12. ↑ Main Responsibilities and Required Skills for an Application Analyst // Spotterful.
  13. ↑ Sculley D., Holt G., Golovin D., Davydov E., Phillips T. Hidden Technical Debt in Machine Learning Systems // Advances in Neural Information Processing Systems. — 2015. — Т. 28. — С. 2503–2511. — doi:10.5555/2969442.2969519.
  14. ↑ What Is an Application Analyst? (With Duties and Skills) // Indeed.
  15. ↑ Руденко А. IT-аналитик: кто такой и чем занимается в разработке // Блог Cloud.ru. — 2025. — 23 апреля.
  16. ↑ Вигерс К., Битти Дж. Разработка требований к программному обеспечению / пер. с англ.. — 3-е изд., доп.. — Санкт-Петербург: БХВ-Петербург, 2025. — 718 с. — ISBN 978-5-9909805-3-2.
  17. ↑ Applications Analyst Job Description // Monster.
  18. ↑ Gama J., Žliobaitė I., Bifet A., Pechenizkiy M., Bouchachia A. A Survey on Concept Drift Adaptation // ACM Computing Surveys. — 2014. — Т. 46, № 4. — С. 1–37. — doi:10.1145/2523813.
  19. ↑ Руденко А. IT-аналитик: кто такой и чем занимается в разработке // Блог Cloud.ru. — 2025. — 23 апреля.
  20. ↑ Вигерс К., Битти Дж. Разработка требований к программному обеспечению / пер. с англ.. — 3-е изд., доп.. — Санкт-Петербург: БХВ-Петербург, 2025. — 718 с. — ISBN 978-5-9909805-3-2.
  21. ↑ Main Responsibilities and Required Skills for an Application Analyst // Spotterful.
  22. ↑ What Is an Application Analyst? (With Duties and Skills) // Indeed.
  23. ↑ Руденко А. IT-аналитик: кто такой и чем занимается в разработке // Блог Cloud.ru. — 2025. — 23 апреля.
  24. ↑ Main Responsibilities and Required Skills for an Application Analyst // Spotterful.
  25. ↑ Sculley D., Holt G., Golovin D., Davydov E., Phillips T. Hidden Technical Debt in Machine Learning Systems // Advances in Neural Information Processing Systems. — 2015. — Т. 28. — С. 2503–2511. — doi:10.5555/2969442.2969519.
  26. ↑ Ларман К. Применение UML 2.0 и шаблонов проектирования / пер. с англ.. — 3-е изд.. — Москва: Вильямс, 2013. — 736 с. — ISBN 978-5-8459-1185-9.
  27. ↑ Topol E. J. High-performance medicine: the convergence of human and artificial intelligence // Nature Medicine. — 2019. — Т. 25, № 1. — С. 44–56. — doi:10.1038/s41591-018-0300-7.
  28. ↑ Вигерс К., Битти Дж. Разработка требований к программному обеспечению / пер. с англ.. — 3-е изд., доп.. — Санкт-Петербург: БХВ-Петербург, 2025. — 718 с. — ISBN 978-5-9909805-3-2.
  29. ↑ Буч Г., Рамбо Дж., Якобсон И. Язык UML. Руководство пользователя / пер. с англ.. — Москва: ДМК Пресс, 2006. — С. 24, 114-116. — 496 с. — ISBN 5-94074-334-X.
  30. ↑ Кон М. Пользовательские истории. Гибкая разработка программного обеспечения / пер. с англ.. — Москва: Вильямс, 2019. — 256 с. — ISBN 978-5-907114-32-6.
  31. ↑ Redman T. C. Data Driven: Profiting from Your Most Important Business Asset. — Boston: Harvard Business Review Press, 2008. — 272 с. — ISBN 978-1-4221-1912-3.
  32. ↑ Mehrabi N., Morstatter F., Saxena N., Lerman K., Galstyan A. A Survey on Bias and Fairness in Machine Learning // ACM Computing Surveys. — 2021. — Т. 54, № 6. — С. 1–35. — doi:10.1145/3457607.
  33. ↑ What Is an Application Analyst? (With Duties and Skills) // Indeed.
  34. ↑ Руденко А. IT-аналитик: кто такой и чем занимается в разработке // Блог Cloud.ru. — 2025. — 23 апреля.
  35. ↑ Gama J., Žliobaitė I., Bifet A., Pechenizkiy M., Bouchachia A. A Survey on Concept Drift Adaptation // ACM Computing Surveys. — 2014. — Т. 46, № 4. — С. 1–37. — doi:10.1145/2523813.
  36. ↑ Sculley D., Holt G., Golovin D., Davydov E., Phillips T. Hidden Technical Debt in Machine Learning Systems // Advances in Neural Information Processing Systems. — 2015. — Т. 28. — С. 2503–2511. — doi:10.5555/2969442.2969519.
  37. ↑ Кон М. Пользовательские истории. Гибкая разработка программного обеспечения / пер. с англ.. — Москва: Вильямс, 2019. — 256 с. — ISBN 978-5-907114-32-6.
  38. ↑ Руденко А. IT-аналитик: кто такой и чем занимается в разработке // Блог Cloud.ru. — 2025. — 23 апреля.
  39. ↑ Ларман К. Применение UML 2.0 и шаблонов проектирования / пер. с англ.. — 3-е изд.. — Москва: Вильямс, 2013. — 736 с. — ISBN 978-5-8459-1185-8.
  40. ↑ Bender E. M., Gebru T., McMillan-Major A., Shmitchell S. On the Dangers of Stochastic Parrots: Can Language Models Be Too Big? // Proceedings of the 2021 ACM Conference on Fairness, Accountability, and Transparency. — 2021. — С. 610–623. — doi:10.1145/3442188.3445922.
  41. ↑ The Role of an Application Analyst // HIMSS.
  42. ↑ Вигерс К., Битти Дж. Разработка требований к программному обеспечению / пер. с англ.. — 3-е изд., доп.. — Санкт-Петербург: БХВ-Петербург, 2025. — 718 с. — ISBN 978-5-9909805-3-2.
  43. ↑ Mitchell M., Wu S., Zaldivar A., Barnes P., Vasserman L. Model Cards for Model Reporting // Proceedings of the Conference on Fairness, Accountability, and Transparency. — 2019. — С. 220–229. — doi:10.1145/3287560.3287596.
  44. ↑ Вигерс К., Битти Дж. Разработка требований к программному обеспечению / пер. с англ.. — 3-е изд., доп.. — Санкт-Петербург: БХВ-Петербург, 2025. — 718 с. — ISBN 978-5-9909805-3-2.
  45. ↑ Business Analyst vs. Business Systems Analyst // Inteq Group.
  46. ↑ Kohavi R., Tang D., Xu Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. — 2020. — doi:10.1017/9781108653985.
  47. ↑ Amershi S., Weld D., Vorvoreanu M., Fourney A., Nushi B. Guidelines for Human-AI Interaction // Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems. — 2019. — С. 1–13. — doi:10.1145/3290605.3300233.
  48. ↑ Amershi S., Weld D., Vorvoreanu M., Fourney A., Nushi B. Guidelines for Human-AI Interaction // Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems. — 2019. — С. 1–13. — doi:10.1145/3290605.3300233.
  49. ↑ Флах П. Машинное обучение. Наука и искусство построения алгоритмов, которые извлекают знания из данных / пер. с англ.. — Москва: ДМК Пресс, 2015. — 400 с. — ISBN 978-5-97060-273-7.
  50. ↑ Business Analyst vs. Business Systems Analyst // Inteq Group.
  51. ↑ Руденко А. IT-аналитик: кто такой и чем занимается в разработке // Блог Cloud.ru. — 2025. — 23 апреля.
  52. ↑ Amershi S., Begel A., Bird C., DeLine R., Gall H. Software Engineering for Machine Learning: A Case Study // Proceedings of the 41st International Conference on Software Engineering: Software Engineering in Practice. — 2019. — С. 291–300. — doi:10.1109/ICSE-SEIP.2019.00042.
  53. ↑ Ларман К. Применение UML 2.0 и шаблонов проектирования / пер. с англ.. — 3-е изд.. — Москва: Вильямс, 2013. — 736 с. — ISBN 978-5-8459-1185-8.
  54. ↑ The Role of an Application Analyst // HIMSS.

Литература

  • Буч Г., Рамбо Дж., Якобсон И. Язык UML. Руководство пользователя / пер. с англ.. — Москва: ДМК Пресс, 2006. — 496 с. — ISBN 5-94074-334-X.
  • Вигерс К., Битти Дж. Разработка требований к программному обеспечению / пер. с англ.. — 3-е изд., доп.. — Санкт-Петербург: БХВ-Петербург, 2025. — 718 с. — ISBN 978-5-9909805-3-2.
  • Глушков В. М. Основы безбумажной информатики. — 2-е изд., испр.. — Москва: Наука, 1987. — 552 с.
  • Кон М. Пользовательские истории. Гибкая разработка программного обеспечения / пер. с англ.. — Москва: Вильямс, 2019. — 256 с. — ISBN 978-5-907114-32-6.
  • Ларман К. Применение UML 2.0 и шаблонов проектирования / пер. с англ.. — 3-е изд.. — Москва: Вильямс, 2013. — 736 с. — ISBN 978-5-8459-1185-9.
  • Руденко А. IT-аналитик: кто такой и чем занимается в разработке // Блог Cloud.ru. — 2025. — 23 апреля.
  • Amershi S., Weld D., Vorvoreanu M., Fourney A., Nushi B. Guidelines for Human-AI Interaction // Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems. — 2019. — С. 1–13. — doi:10.1145/3290605.3300233.
  • Gama J., Žliobaitė I., Bifet A., Pechenizkiy M., Bouchachia A. A Survey on Concept Drift Adaptation // ACM Computing Surveys. — 2014. — Т. 46, № 4. — С. 1–37. — doi:10.1145/2523813.
  • Inmon William H. Building the Data Warehouse. — 4th ed.. — Indianapolis: Wiley, 2005. — 544 с. — ISBN 978-0-7645-9944-6.
  • Sculley D., Holt G., Golovin D., Davydov E., Phillips T. Hidden Technical Debt in Machine Learning Systems // Advances in Neural Information Processing Systems. — 2015. — Т. 28. — С. 2503–2511. — doi:10.5555/2969442.2969519.
  • Деятельность компании Meta Platforms Inc., владеющей социальными сетями Facebook, Instagram и мессенджером WhatsApp, признана экстремистской и запрещена на территории Российской Федерации по решению Тверского районного суда от 21.03.2022 года по делу № 02-2473/2022

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

Категории

Pause