Системный анализ в IT

Материал из Systems analysis wiki
Перейти к навигации Перейти к поиску

Системный анализ в IT (Systems Analysis and Design) — подход к проектированию и развитию информационных систем от замысла до эксплуатации, включающий выявление потребностей, формализацию требований, моделирование предметной области и процессов, а также оценку альтернатив и рисков. Другими словами, системный анализ в IT — это этап разработки, на котором специалисты изучают задачу, определяют, что должна делать система, и разрабатывают решения для её создания.

Классический системный анализ охватывает широкий спектр областей применения, не только разработку программного обеспечения, но и организационные изменения, стратегии и другие аспекты.[1] [2]

Предмет и задачи системного анализа в IT

Предметом системного анализа в IT является информационная система (программный продукт и/или сервис) на всём жизненном цикле — от замысла и обоснования до реализации и эксплуатации.

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

Задачи системного анализа включают:

  • Выявление потребностей и целей стейкхолдеров. Аналитик собирает и уточняет ожидания заказчиков, пользователей и иных заинтересованных сторон; применяются интервью, опросы, наблюдение и анализ текущих процессов. На выходе формируется первичная спецификация требований с разделением на функциональные («что система должна делать») и нефункциональные (надёжность, производительность, безопасность и т.п.).[1][2]
  • Формализация и документирование требований. Запросы преобразуются в проверяемые требования. Хорошо сформулированное требование должно быть ясным и недвусмысленным, полным, непротиворечивым, проверяемым и трассируемым к более высокоуровневым целям; набор требований — согласованным и целостным.[3][4] В практике используются стандартизованные документы: SRS (Software Requirements Specification) по ISO/IEC/IEEE 29148, а также, в отдельных отраслях, URS (User Requirements Specification) и функциональные спецификации.[5][6][7]
  • Анализ и моделирование системы. Для понимания того, как система будет работать и взаимодействовать с внешним миром, строятся модели: диаграммы прецедентов (Use Case) для сценариев использования, DFD для потоков данных и бизнес-процессов, диаграммы классов/компонентов и др. Модели служат основой для сопоставления альтернативных решений и архитектур.[8][9][10]
  • Оценка осуществимости и выбор решения. Проводится feasibility study (техническая, организационная, экономическая, календарная осуществимость) и сравнение архитектурных альтернатив (trade-off). Для оценки качества архитектуры по атрибутам (напр., производительность, масштабируемость, модифицируемость) применяются методы вроде ATAM (Architecture Tradeoff Analysis Method).[11][12] Выбор между, например, монолитной и микросервисной архитектурой [3] опирается на явные компромиссы (сложность эксплуатации vs. независимая масштабируемость и скорость поставки) по рекомендациям индустриальных гайдов.[13][14]
  • Подготовка проектных артефактов. По итогам анализа формируются:
    • утверждённая спецификация требований (с указанием их важности),
    • концептуальная модель системы (диаграммы/описания),
    • архитектурные и проектные решения (схемы данных, интерфейсы внешних систем),
    • план реализации (этапы/модули).
    • Критично обеспечивать прослеживаемость (bidirectional traceability) требований к элементам дизайна и тестам.[15][4]

Успех IT-проекта в значительной степени зависит от зрелых практик работы с требованиями и архитектурой. Исследование, проведенное McKinsey и Oxford, показало, что крупные IT-проекты часто выходят за рамки бюджета и сроков. Это исследование также подчеркнуло, как важно правильно управлять стратегией, взаимодействовать с заинтересованными сторонами и грамотно собирать требования. Все это может сильно повлиять на успех или провал проекта.[16]

Подходы и методологии в системном анализе IT

Системный анализ в IT опирается на принципы системного мышления и адаптированные под разработку ПО методики. На практике комбинируются «жёсткие» и «мягкие» подходы, структурные методологии, объектно-ориентированные нотации, а также языки моделирования процессов и требований.

  • Жёсткий и мягкий подходы. В ИТ-проектах жёсткий подход (hard systems) предполагает заранее формализуемые цели и требования, декомпозицию и проектирование «сверху вниз». Мягкий подход (soft systems) применяют при неясных целях и множественных точках зрения: используют элементы Soft Systems Methodology (SSM) (напр., rich picture, корневые определения, CATWOE) для согласования понимания проблемы и желаемых изменений; затем результаты переводят в формальные требования.[17][18]
  • Методология SSM (Soft Systems Methodology). Изначально разработанная Питером Чеклендом для организационных изменений, SSM полезна на предпроектных этапах IT: от исследования проблемной ситуации и формулирования корневых определений (в т.ч. через CATWOE) до сопоставления концептуальных моделей с реальностью и достижения аккомодации между стейкхолдерами.[19][20]
  • Структурированные методологии: SADT/IDEF0. SADT моделирует систему как иерархию функций; стандартная нотация IDEF0 (IEEE 1320.1) фиксирует функции и их I-C-O-M-интерфейсы (Inputs, Controls, Outputs, Mechanisms). Метод удобен для функциональной декомпозиции и согласования границ системы независимо от алгоритмов.[21][22]
  • Объектно-ориентированный анализ: UML и SysML (MBSE). UML стал базовым языком для требований и дизайна (диаграммы прецедентов, классов, последовательностей и др.) и облегчает валидацию сценариев с пользователями; SysML расширяет UML для системной инженерии (диаграммы требований, параметрические диаграммы) и опирается на подход MBSE, где модель — центральный артефакт сквозь этапы от требований до тестов.[23][24][25]
  • Моделирование бизнес-процессов: BPMN. Стандарт BPMN используют для графического описания процессов (пулы, потоки работ, события, шлюзы), включая сравнение as-is/to-be в спецификациях требований и интеграции.[26][27]
  • Связь с инженерией требований. Процесс включает этапы elicitation–analysis–specification–validation–change management; критерии «хорошего требования» и структура SRS регламентированы ISO/IEC/IEEE 29148. Для приоритизации применяют техники MoSCoW (Must/Should/Could/Won’t) и методы многокритериального выбора, например AHP. В гибких процессах деятельность системного анализа отражается в backlog refinement и трассируемости требований.[28][29][30][31]
  • Связь с системной инженерией. Для комплексных (киберфизических) систем применяют V-модель: на «левой» ветви — системный анализ и архитектура, на «правой» — интеграция, верификация и валидация с привязкой к артефактам левой ветви. Методы оценки архитектуры по качественным атрибутам включают ATAM (trade-off анализ).[32][33]

Системный анализ в IT сочетает проверенные подходы — от мягких методик согласования видения до формальных нотаций и стандартов. Выбор инструментов определяется степенью определённости задачи: при высокой неопределённости усиливается роль SSM и фасилитации, при чётких границах — формальные модели (UML/SysML, IDEF0, BPMN) и регламенты.

Связь с ИТ-архитектурой и архитектурой предприятия

Системный анализ в ИТ-проектах тесно связан с архитектурным проектированием. Роли аналитика и архитектора пересекаются: аналитик формулирует требования и логическую модель, архитектор определяет целевую структуру решения и технические компромиссы; работа ведётся совместно.

  • Архитектура ИТ-систем. В узком смысле архитектура ПО — это организация компонентов, их отношения и принципы, которыми руководствуются при проектировании решения. Аналитику важно учитывать архитектурные стили (слоёная, клиент–серверная, микросервисная, событийно-ориентированная и др.), поскольку нефункциональные требования (надёжность, масштабируемость, модифицируемость) часто определяют архитектурные решения и их компромиссы.[34][35] На раннем этапе анализа формируют архитектурное видение (high-level vision) и прорабатывают черновой контур решения для проверки жизнеспособности требований (длина итераций и детализация зависят от методологии).[36]
  • Шаблоны и предварительные решения. Для удовлетворения нефункциональных требований применяются архитектурные шаблоны (architectural patterns). Например, для асинхронного взаимодействия и слабой связности — publish–subscribe через брокер сообщений в событийно-ориентированной архитектуре.[37]
  • TOGAF (The Open Group Architecture Framework). Один из наиболее распространённых фреймворков корпоративной архитектуры; включает метод ADM (Architecture Development Method) и артефакты управления архитектурой (репозиторий, каталоги/матрицы, принципы). В TOGAF управление требованиями — сквозной процесс, интегрированный во все фазы ADM.[36] Для поддержки требований и прослеживаемости используются каталоги и матрицы (напр., требования ↔ сервисы, функции ↔ компоненты), а также различаются Architecture Building Blocks и Solution Building Blocks.[38][39] Принципы и стандарты предприятия фиксируются в соответствующих каталогах и выступают внешними нефункциональными требованиями для проектных команд.[40] Соответствие решений целевой архитектуре подтверждается процедурой архитектурного комплаенса (Architecture Compliance Review).[41] Подход TOGAF предполагает предварительное Architecture Vision и последующую детализацию (данные/приложения/технологии) с планом миграции и управлением изменениями требований.[42][43]
  • Zachman Framework. Ранняя и влиятельная онтология артефактов архитектуры предприятия, представленная как матрица 6×6 (перспективы × аспекты «что/как/где/кто/когда/почему»). Строка «дизайнер» соотносится с системным анализом и проектированием; колонки задают полноту рассмотрения данных, функций/процессов, ролей, расположения и мотивации. Фреймворк служит классификацией (а не методологией) и помогает обеспечить полноту описания решения в ландшафте предприятия.[44]
  • Связь с архитектурой предприятия (Enterprise Architecture, EA). Системный аналитик работает в контексте EA: новые требования трассируются к бизнес-возможностям и операционной модели; применяются стандарты и принципиальные ограничения предприятия (безопасность, совместимость и т.п.).[45][36] На стадии инициации формируется Architecture Vision (цели/ограничения, укрупнённые требования), далее аналитик детализирует, сохраняя прослеживаемость к видению и корпоративным стандартам; невыполнение стандартов выявляется на архитектурных ревью и может привести к доработкам решения.[36][46]

Итого: системный анализ и архитектурное проектирование образуют связку «требования → архитектурные решения → компромиссы по атрибутам качества». Выбор методов (стилей/шаблонов, артефактов TOGAF, классификации Zachman) определяется характером проекта и рамками корпоративной архитектуры.

Процессы и практики

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

  • Классический SDLC (Waterfall). Этап System Analysis & Requirements Definition предшествует проектированию и реализации; требования фиксируются в детальной SRS как база планирования и контрактов. Эффективен в стабильных и регулируемых доменах; риски «заморозки» требований снижают SRR/ревью и управление изменениями через CCB.[47][48][49]
  • Гибкие методологии (Agile). Анализ непрерывен: вместо финальной SRS ведут продуктовый бэклог из user stories с критериями приёмки, уточняемый на backlog refinement; применяют BDD (Given–When–Then); риск потери целостной архитектуры компенсируют ранней архитектурной проработкой и прозрачной трассируемостью требований ↔ реализации/тестам.[50][51][52]
  • DevOps и SRE. Частые релизы требуют операционных требований «по умолчанию»: автоматизации, наблюдаемости, отката. Нефункциональные требования формулируют как SLO/SLI, управляют error budget; в бэклог добавляют задачи на логи/метрики/трейсы/алерты; для выпуска без простоя — паттерны blue/green и др.[53][54][55]
  • Управление требованиями и рисками. Требования в ALM имеют статусы и связи с задачами/релизами/дефектами; обязательны version control, change impact analysis и регулярная реприоритизация.[56][57]
  • Обеспечение качества (QA). Качество закладывается на этапе требований: ревью, «Three Amigos», план Acceptance Test Plan, автотесты критериев приёмки (BDD/ATDD).[58][59]
  • Наблюдаемость и надёжность. В требования включают SLA/SLO, MTTR и MTBF с измеримыми целями и методами контроля; параметры поступают от бизнеса/эксплуатации и закладываются в архитектуру и тесты надёжности.[60][61]

Метрики и качество артефактов

Для оценки работы системного аналитика и качества его результатов применяют общепринятые критерии. Качественные требования и модели — основа успешного проекта, поэтому ими управляют на всём жизненном цикле (elicitation → specification → verification/validation → change management). Базовые атрибуты качества требований закреплены в стандартах ISO/IEC/IEEE 29148 и (исторически) IEEE 830.[3][62][1]

  • Корректность (Correctness) — требование отражает подлинную потребность и согласовано с экспертами предметной области; подтверждается валидацией (review/inspection, прототипы, сценарии).[1][4]
  • Полнота (Completeness) — учтены существенные аспекты и условия.
    • Полнота отдельного требования: указаны необходимые детали (напр., «индикатор переходит в статус красный при сбое», а не просто «становится красным»).
    • Полнота спецификации: покрыты сценарии/роли, заданы NFR; достигается чек-листами и трассируемостью к бизнес-целям; полезен независимый аудит полноты (QA/review).[3][63]
  • Однозначность (Unambiguity) — формулировки трактуются единственным образом; помогает глоссарий, шаблоны вида «система должна делать A, когда B, если C», примеры; диаграммы сопровождаются легендой. Проверка — принцип «четырёх глаз».[3][1]
  • Согласованность (Consistency) — требования не противоречат друг другу и внешним ограничениям; применяют структурирование, сводные таблицы атрибутов, командные ревью; сверяют регуляторику/стандарты.[3][63]
  • Проверяемость/тестируемость (Verifiability) — достижение подтверждается тестом/демонстрацией/анализом; непроверяемые формулировки заменяют измеримыми критериями; для NFR задают метрики и заранее фиксируют критерии приёмки.[3][63]
  • Изменяемость и трассируемость (Modifiability & Traceability) — уникальные ID, логичная структура («одна мысль — один абзац»), отсутствие дубликатов; поддерживаются связи «требование ↔ источник/цель/дизайн/тест», ведётся матрица трассируемости (RTM).[64][3]
  • Ранжирование и приоритизация — качество набора требований; используют техники MoSCoW и MCDM (напр., AHP); приоритизация совместно с бизнесом влияет на планирование и риски.[65][66]

Метрики качества требований (примеры):[63][1]

  • плотность дефектов требований (замечаний на 100 требований);
  • число изменений после базовой фиксации;
  • coverage-метрики: доля требований с тестами; доля требований, трассируемых к бизнес-целям;
  • стабильность требований (отношение добавленных/удалённых к общему числу за период);
  • размер/сложность спецификации (среднее число требований в use case, глубина декомпозиции);
  • удовлетворённость стейкхолдеров (опрос).

В зрелых процессах (напр., CMMI уровень 3+) действуют регламенты качества требований: формальные проверки, аудиты соответствия шаблонам, сбор/анализ метрик.[67] В критичных доменах (авионика, космос и др.) применяют формальные методы для повышения надёжности.[68]

Типичные ошибки

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

Типовые проблемы, их последствия и способы предотвращения.

  • Неполнота и пропущенные требования. Упускаются роли с особыми правами, пограничные случаи и NFR. Последствия: переделки архитектуры и перенос запуска. Как избежать: чек-листы, мозговые штурмы «что если…», раннее подключение тестировщиков, трассируемость к бизнес-целям.[1][69]
  • Неясные, двусмысленные формулировки. Последствия: разработчики реализуют «не то», заказчик недоволен. Как избежать: измеримые критерии, глоссарий, шаблоны «A, когда B, если C», peer‑review.[3][69]
  • Противоречивые требования. Последствия: задержки на уточнения, переделки на интеграции. Как избежать: структурирование, сверка бизнес‑правил/регуляторики, сессии разрешения конфликтов, проверка согласованности на ревью.[3][1]
  • Синдром «золотой пластины» (gold‑plating). Последствия: рост объёма, усложнение, новые точки отказа. Как избежать: привязка каждого требования к цели/метрике; в Agile — не включать лишнее в backlog; фиксировать scope; см. YAGNI.
  • Избыточная детализация там, где не нужна. Как избежать: отделять что/зачем (требования) от как (дизайн/реализация); применять design‑free requirements там, где уместно.[3]
  • Нарушение управляемости требованиями. Последствия: путаница версий, реализация «не того». Как избежать: единый источник правды в ALM, историзация и статусы, RTM и change impact analysis; управление изменениями через CCB.[64][1]
  • Отсутствие участия пользователей. Как избежать: интервью, наблюдение, прототипы, регулярные показы; явная валидация со стейкхолдерами.[3][1]
  • Слишком длительный «аналитический паралич». Как избежать: зона достаточности, итеративность и timeboxing; запуск MVP/инкрементов и корректировка по обратной связи.[1]
  • Игнорирование нефункциональных требований. Как избежать: выделять NFR (напр., FURPS+), задавать измеримые критерии, включать их в план тестирования и архитектурные решения.[1][3]
  • Коммуникационные ошибки и «человеческий фактор». Как решать: развивать интервьюирование и фасилитацию, сохранять нейтральность, фиксировать решения и источники требований (прослеживаемость к целям).[1]

Большинство проблем сводятся к качеству формулировок, полноте и управляемости требований; применение стандартов ISO/IEC/IEEE 29148 и практик SWEBOK (валидируемость, прослеживаемость, итеративность) значительно снижает риск срывов сроков и переработок.[3][1]

Ограничения

Несмотря на свою эффективность в снижении неопределенности, системный анализ имеет свои ограничения:

  • Реальность изменчива и сложна. Невозможно учесть все факторы, особенно в долгосрочных проектах. Некоторые требования неизбежно проявятся уже после запуска системы. Важно стремиться минимизировать неожиданности, но нужно быть готовым к изменениям.
  • Требования зависят от людей. Приоритеты бизнеса, законы и рынок могут меняться. Системный анализ фиксирует текущее состояние и не может предсказать все внешние изменения. Чтобы адаптироваться, необходимо регулярно обновлять требования и работать итеративно.
  • Пользователи не всегда знают, чего хотят, пока не увидят. Это известное ограничение. Прототипирование и гибкие методологии, такие как Agile, помогают преодолеть эту проблему. Анализ на бумаге имеет свои пределы, и для получения точных данных нужна обратная связь от реализаций.
  • Баланс между временем и качеством. Чрезмерно детальный анализ может устареть. В инновационных областях лучше быстро создать минимально жизнеспособный продукт (MVP) и получить реальные данные. Системный анализ эффективен в стабильных областях, но в исследовательских проектах (R&D) его роль ограничена.
  • Человеческий фактор. Даже самые лучшие методологии не компенсируют некомпетентность аналитика или недоступность заказчика. Важно, чтобы все участники процесса были вовлечены и мотивированы.

Влияние современных технологий на системный анализ в IT

Системный анализ в IT постоянно эволюционирует под воздействием технологических инноваций. Аналитик XXI века работает в условиях взрывного роста данных, повсеместного внедрения ИИ, быстрого цикла разработки и повышенного внимания к безопасности. Успешная практика системного анализа требует освоения новых знаний (Data Science, кибербезопасность, облачные технологии) и гибкости в применении методов.

  • Данные и AI/ML: что добавляется в анализ. Для систем с ИИ уже на старте фиксируют цели и контекст применения, требования к источникам и качеству данных, а также метрики доверия к решениям модели (надёжность, безопасность, объяснимость, конфиденциальность, справедливость). Планируются проверки TEVV (testing, evaluation, verification, validation), мониторинг в эксплуатации и безопасное отключение/вывод модели. Эти шаги соответствуют функциям GOVERN–MAP–MEASURE–MANAGE из рамки NIST по управлению рисками ИИ; их отражают в SRS, архитектуре и планах верификации/эксплуатации.[70]
  • DevSecOps: безопасность «слева» и по умолчанию. Встраивание безопасности в каждую стадию CI/CD становится нормой: автоматические проверки (SAST/DAST), сканирование зависимостей и контейнеров, политики развёртывания, базовая наблюдаемость. Используются доверенные реестры артефактов и стандартизованные «хардёные» образы; применяются принципы нулевого доверия. В системном анализе заранее описывают контрольные точки конвейера (условия прохождения стадий), связь требований с контролями безопасности и правила перехода между средами (dev/test/stage/prod).[71]
  • Что меняется в документах (артефактах). Какой раздел появляется или уточняется в ключевых документах при наличии Big Data и AI/ML и при работе по DevSecOps:
    • SRS / Спецификация требований: цели и контекст применения ИИ; требования к данным (происхождение, качество, этические и правовые ограничения); метрики модели (точность, надёжность, время отклика); план TEVV (testing, evaluation, verification, validation); требования по прозрачности/объяснимости и приватности; критерии отключения/вывода модели из эксплуатации.[70]
    • Архитектура и решения (Architecture, ADR): результаты моделирования угроз; меры «безопасность по умолчанию» (шифрование, контроль доступа, секрет‑менеджмент, принцип наименьших привилегий); ограничения на использование данных/моделей; записи ADR с оценкой рисков и компромиссов.[71][70]
    • План верификации и валидации (V&V / TEVV): сценарии тестирования моделей и данных; пороги приёмки для метрик качества; мониторинг дрейфа данных/модели; процедуры периодической переоценки и повторной валидации.[70]
    • Политики CI/CD и «ворота» конвейера: автоматические проверки SAST/DAST, SCA (зависимости), сканирование контейнеров; подпись и хранение артефактов в доверенных реестрах; правила продвижения между средами (dev/test/stage/prod) и условия блокировки сборки при провале проверок; требования к наблюдаемости по умолчанию.[71]
    • План управления данными и моделями: каталог источников и lineage; критерии качества и доступности данных; версии датасетов/моделей; расписание (до)обучения и контроль bias; политика доступа и хранения; план безопасной деактивации модели и удаления данных, если требуется.[70]
    • Эксплуатация и наблюдаемость (Ops/Runbook): метрики доверия к ИИ и SLO; аудит и журналирование; алерты на деградацию/аномалии; план реагирования на инциденты; fallback/kill‑switch для ИИ‑компонент; требования к отчётности и пост‑инцидентному анализу.[70][71]
    • Трассируемость (end‑to‑end): явные связи «требование ↔ контроль/проверка в конвейере» и «требование ↔ тест/мониторинг в эксплуатации», чтобы можно было доказуемо проверять безопасность и качество на всём жизненном цикле.[71][70]
  • Роль системного аналитика.
    • управляет контекстом и рисками ИИ (акторы, сценарии применения, допущения и ограничения данных);
    • обеспечивает трассируемость «требование ↔ контроль безопасности в конвейере»;
    • формулирует проверяемые нефункциональные требования (безопасность, прозрачность, наблюдаемость) на всём жизненном цикле системы.[70][71]

Отличия от классического системного анализа

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

Ниже — ключевые отличия.

  • Цели и объект анализа. Классический анализ решает плохо структурированные, «размытые» проблемы и улучшает уже существующие социотехнические системы (городская транспортная сеть, стратегия компании, экологическая политика). Объект — реальная система; задача — помочь ЛПР выбрать курс действий. Для системного анализа в ИТ цель — спроектировать и создать новую информационную систему или программный продукт, отвечающий требованиям. Объект — проектируемая система; фокус — поведение и характеристики, нужные пользователям.
  • Методологические основы. Классические школы опираются на системное мышление и часто на математику. Жёсткий подход (hard systems) — формализация проблемы, количественные критерии, оптимизация (как в operations research). Мягкие методологии (soft systems) признают множественность точек зрения; пример — Soft Systems Methodology (SSM), где через обсуждения и концептуальные модели согласуют желаемые изменения. В ИТ база — инженерные дисциплины: инженерия требований, проектирование ПО, архитектурные фреймворки. Применяются стандартизованные процессы (ISO/IEC/IEEE 15288, 12207, 29148), нотации UML/SysML и практики управления изменениями.
  • Роли и артефакты. В классическом анализе роль «системного аналитика» часто неформальна; результаты — аналитический отчёт, рекомендации, математические модели, сценарии «что‑если». В ИТ роль аналитика (или бизнес‑аналитика) формализована; выпускаются спецификации требований, модели системы (UML, ER), спецификации интерфейсов, user stories и backlog — артефакты, напрямую используемые разработчиками и тестировщиками.
  • Жизненный цикл и процесс. Классический анализ не имеет единого шаблона: шаги зависят от проблемы (в SSM — от изучения ситуации до внедрения изменений). В ИТ приняты стандартные циклы SDLC: в каскадной модели есть отдельная фаза анализа требований; в итеративных и гибких подходах анализ — постоянная деятельность каждого спринта. Современные практики (DevOps, CI/CD) расширяют рамки анализа на эксплуатацию: учитываются требования к сопровождению, наблюдаемости и обновляемости. Иными словами, системный анализ в ИТ встроен в жизненный цикл разработки, тогда как классический чаще выполняется как проектная/консультационная деятельность.

Системный аналитик

Системный аналитик в IT — специалист, отвечающий за системное мышление в проектировании и развитии информационных систем: формирование и валидацию требований, моделирование (UML/BPMN), согласование архитектурных решений и обеспечение интеграции. Роль и квалификационные требования в РФ закреплены в профстандарте и ФГОС.

Основная цель вида профессиональной деятельности: Обеспечение соответствия ИТ-сервиса, автоматизированной системы, автоматизированной информационной системы, автоматизированной системы управления, программного, информационного продукта или средства (далее - Система) окружению, исходным требованиям и ограничениям, целям автоматизации и автоматизированной деятельности путем разработки и передачи качественных и взаимоувязанных проектных решений заинтересованным сторонам при запуске и координации работ отдельных исполнителей на всем жизненном цикле Системы (Профессиональный стандарт «Системный аналитик» (приказ Минтруда РФ от 27.04.2023 № 367н).[72]

Глоссарий ключевых терминов

Базовые понятия и участники

  • Системный анализ в IT — дисциплина, предметом которой является информационная система на всём её жизненном цикле, от замысла до эксплуатации.
  • Стейкхолдеры — лица или группы, заинтересованные в проекте или затронутые им (заказчики, пользователи, менеджеры).
  • Проектные артефакты — документы и результаты, создаваемые в процессе проекта, такие как спецификации, модели, планы и решения.

Требования: виды и документация

  • Функциональные требования — описывают, что система должна делать; её функции и поведение.
  • Нефункциональные требования — описывают атрибуты качества системы (надёжность, производительность, безопасность, удобство использования, масштабируемость и т.д.).
  • Спецификация требований (первичная) — документ, содержащий исходный набор требований, собранных на начальных этапах проекта.
  • SRS (Software Requirements Specification) — стандартизированный документ, подробно описывающий требования к программному обеспечению согласно международным стандартам (например, ISO/IEC/IEEE 29148).
  • URS (User Requirements Specification) — документ, описывающий требования пользователя к системе с точки зрения бизнес-процессов и ожиданий конечного пользователя.
  • Архитектурно-значимые требования (ASR) — требования, существенно влияющие на архитектурные решения и компромиссы.
  • Кросс-функциональные требования (CFR) — синоним нефункциональных требований, подчёркивающий их сквозной характер.
  • Критерии приёмки (Acceptance Criteria) — проверяемые условия, при выполнении которых работа по требованию считается принятой.
  • Definition of Ready (DoR) — соглашение о готовности элемента бэклога к разработке (ясность, оценка, критерии).
  • Definition of Done (DoD) — соглашение о «завершённости» работы (код, тесты, документация, развёртывание).
  • Ограничение (Constraint) — жесткое условие, ограничивающее решения (сроки, платформы, стандарты, лицензии).
  • Допущение (Assumption) — предположение, принимаемое без доказательства, требующее последующей валидации.
  • Качество требований — свойства по ISO 29148: еднозначность, полнота, непротиворечивость, проверяемость, атомарность.

Формализация, трассируемость и приоритизация требований

  • Формализация требований — процесс преобразования неформальных запросов в чёткие, проверяемые и однозначные требования.
  • Трассируемость требований — возможность отслеживать жизненный цикл требования от его источника до реализации, тестирования и развёртывания.
  • Bidirectional traceability (двунаправленная прослеживаемость) — способность отслеживать связи между требованиями, элементами дизайна и тестовыми сценариями как в прямом, так и в обратном направлении.
  • MoSCoW — техника приоритизации требований, классифицирующая их как Must-have (должно быть), Should-have (следует иметь), Could-have (может быть) и Won't-have (не будет).
  • BDD (Behavior-Driven Development) — методология разработки, в которой тесты пишутся на естественном языке, ориентированном на поведение системы с точки зрения пользователя (формат Given–When–Then).

Нотации и моделирование

  • UML (Unified Modeling Language) — стандартизированный язык графического моделирования для спецификации, визуализации, конструирования и документирования компонентов программных систем.
  • SysML (Systems Modeling Language) — расширение UML для системной инженерии, поддерживающее моделирование различных аспектов сложных систем, включая требования, поведение, структуру и параметры.
  • BPMN (Business Process Model and Notation) — стандарт графической нотации для описания бизнес-процессов, позволяющий визуализировать потоки работ, события, шлюзы и пулы.
  • MBSE (Model-Based Systems Engineering) — подход к системной инженерии, где модель является центральным артефактом на всех этапах жизненного цикла системы, от требований до тестирования.
  • ArchiMate — нотация корпоративной архитектуры (бизнес, приложения, технологии) и их связи.
  • DMN (Decision Model and Notation) — моделирование бизнес-решений и таблиц правил.
  • DFD (Data Flow Diagram) — диаграммы потоков данных (контекст, уровни декомпозиции).
  • ERD (Entity-Relationship Diagram) — модель предметной области с сущностями, связями и атрибутами.
  • CRUD-матрица — соответствие операций Create/Read/Update/Delete сущностям и ролям/функциям.

Архитектурные стили и оценка решений

  • Монолитная архитектура — архитектурный подход, при котором вся система разрабатывается как единый, неделимый модуль.
  • Микросервисная архитектура — архитектурный подход, при котором система строится как набор небольших, независимо развёртываемых и масштабируемых сервисов.
  • Trade-off (компромисс) — выбор между взаимоисключающими или противоречивыми характеристиками или решениями, где улучшение одной характеристики происходит за счёт ухудшения другой.
  • ATAM (Architecture Tradeoff Analysis Method) — метод оценки архитектуры ПО, используемый для анализа компромиссов между качественными атрибутами (например, производительностью, масштабируемостью).

Корпоративная архитектура и фреймворки

  • TOGAF (The Open Group Architecture Framework) — один из наиболее распространённых фреймворков корпоративной архитектуры, включающий метод ADM (Architecture Development Method) для разработки и управления архитектурой.
  • Zachman Framework — онтология артефактов архитектуры предприятия, представленная как матрица 6×6, классифицирующая различные аспекты архитектуры с разных перспектив.

Подходы к анализу и процессам разработки

  • Жёсткий подход (Hard Systems) — методология системного анализа, предполагающая заранее формализуемые цели и требования, декомпозицию и проектирование «сверху вниз», эффективна для чётко определённых задач.
  • Мягкий подход (Soft Systems) — методология системного анализа, применяемая при неясных целях и множественных точках зрения стейкхолдеров, направленная на согласование понимания проблемы и желаемых изменений.
  • SSM (Soft Systems Methodology) — конкретная методология мягкого системного подхода, разработанная Питером Чеклендом, использующая такие инструменты, как rich picture, корневые определения и CATWOE.
  • Waterfall (каскадная модель) — классическая методология разработки ПО, где этапы (анализ, проектирование, реализация, тестирование, внедрение) выполняются последовательно, с полным завершением предыдущего этапа перед началом следующего.
  • Agile — группа гибких методологий разработки ПО, ориентированных на итеративную разработку, адаптацию к изменениям, взаимодействие с заказчиком и непрерывную поставку ценности.

Методы выбора и типичные ошибки

  • AHP (Analytic Hierarchy Process) — метод многокритериального выбора, позволяющий структурировать сложные проблемы и оценивать альтернативы на основе иерархии критериев.
  • Gold-plating (синдром «золотой пластины») — ошибка в системном анализе, заключающаяся в добавлении функциональности, которая не требуется стейкхолдерами, что ведёт к росту объёма и сложности проекта.

Ссылки

Литература

  • ISO/IEC/IEEE (2023). 15288: System Life Cycle Processes.
  • INCOSE (2023). INCOSE Systems Engineering Handbook, 5-е изд.
  • ISO/IEC/IEEE (2018). 29148: Systems and Software Engineering — Life Cycle Processes — Requirements Engineering.
  • IIBA (2015). A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), v3.
  • The Open Group (2022). The TOGAF® Standard, 10th Edition. Официальная бесплатная версия.
  • OMG (2017). Unified Modeling Language (UML®) 2.5.1 Specification. PDF.
  • OMG (2014). Business Process Model and Notation (BPMN™) 2.0.2 Specification. PDF.
  • OMG (2024). Systems Modeling Language (SysML®) 1.7 Specification. PDF.
  • The Open Group (2022). ArchiMate® 3.2 Specification. Официальная бесплатная загрузка (по лицензии).
  • Bass, L.; Clements, P.; Kazman, R. (2021). Software Architecture in Practice, 4-е изд.
  • Wiegers, K.; Beatty, J. (2013). Software Requirements, 3-е изд.
  • Rozanski, N.; Woods, E. (2012). Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, 2-е изд.
  • Meadows, D. (2008). Thinking in Systems: A Primer.
  • Senge, P. M. (2006). The Fifth Discipline: The Art & Practice of the Learning Organization (rev. ed.).
  • Blanchard, B. S.; Fabrycky, W. J. (2010). Systems Engineering and Analysis, 5-е изд.
  • Robertson, J.; Robertson, S. (2012). Mastering the Requirements Process: Getting Requirements Right, 3-е изд.
  • van Lamsweerde, A. (2009). Requirements Engineering: From System Goals to UML Models to Software Specifications.
  • Hull, E.; Jackson, K.; Dick, J. (2017). Requirements Engineering, 4-е изд.
  • Kendall, K. E.; Kendall, J. E. (2023). Systems Analysis and Design, 11-е изд.
  • Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). Systems Analysis and Design: An Object-Oriented Approach with UML, 8-е изд.
  • Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). Systems Analysis and Design in a Changing World, 7-е изд.
  • Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3-е изд.
  • Delligatti, L. (2013). SysML Distilled: A Brief Guide to the Systems Modeling Language.
  • Silver, B. (2011). BPMN Method and Style, 2-е изд.
  • Lankhorst, M. et al. (2017). Enterprise Architecture at Work: Modelling, Communication and Analysis, 4-е изд.
  • Richards, M.; Ford, N. (2020). Fundamentals of Software Architecture.
  • Fairbanks, G. (2010). Just Enough Software Architecture: A Risk-Driven Approach.
  • Keeling, M. (2017). Design It!: From Programmer to Software Architect.
  • Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software.
  • Vernon, V. (2013). Implementing Domain-Driven Design.
  • Brandolini, A. (2018). Introducing EventStorming: An Act of Deliberate Collective Learning.
  • Simsion, G.; Witt, G. (2015). Data Modeling Essentials, 4-е изд.
  • Silverston, L. (2008–2009). The Data Model Resource Book, Vols. 1–3 (rev. eds.).
  • Keeney, R. L.; Raiffa, H. (1993). Decisions with Multiple Objectives: Preferences and Value Trade-Offs, 2-е изд.
  • Saaty, T. L. (1980). The Analytic Hierarchy Process; (1990) Decision Making for Leaders.

Примечания



  1. ↑ 1,00 1,01 1,02 1,03 1,04 1,05 1,06 1,07 1,08 1,09 1,10 1,11 1,12 IEEE Computer Society (2025). Guide to the Software Engineering Body of Knowledge (SWEBOK), v4.0a. Requirements Engineering: elicitation techniques. https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf
  2. ↑ Zowghi, D.; Coulin, C. (2005/2014). Requirements Elicitation: A Survey of Techniques, Approaches, and Tools. https://eecs481.org/readings/requirements.pdf
  3. ↑ 3,00 3,01 3,02 3,03 3,04 3,05 3,06 3,07 3,08 3,09 3,10 3,11 3,12 ISO/IEC/IEEE 29148 (2011/2018). Systems and software engineering — Requirements engineering. ISO overview page: «Defines the construct of a good requirement…». https://www.iso.org/standard/45171.html
  4. ↑ 4,0 4,1 4,2 NASA (2020). NPR 7123.1C — Systems Engineering Processes and Requirements. Определение «well-formed (clear and unambiguous), complete, consistent, individually verifiable and traceable». https://nodis3.gsfc.nasa.gov/displayAll.cfm?Internal_ID=N_PR_7123_001C_&page_name=all
  5. ↑ GMU (George Mason University). IEEE Software Requirements Specification Template (SRS). https://cs.gmu.edu/~rpettit/files/project/SRS-template.doc
  6. ↑ Westfall, L. (Cal Poly, .edu). The What, Why, Who, When and How of Software Requirements (упоминает URS). https://users.csc.calpoly.edu/~csturner/courses/300f06/readings/%5B3%5D_%20The_Why_What_Who_When_and_How_of_Software_Requirements.pdf
  7. ↑ Stanford University IT (.edu). Functional Specification Document Template. https://uit.stanford.edu/sites/default/files/2017/08/30/Functional%20Specification%20Document%20Template.docx
  8. ↑ Penn State (.edu). Elements of a Use Case Diagram. https://www.e-education.psu.edu/geog468/l8_p4.html
  9. ↑ UC Irvine (.edu). Data Flow Diagram. https://www.security.uci.edu/program/risk-assessment/data-flow-diagram/
  10. ↑ ISO/IEC/IEEE 42010 (2011/2022). Architecture description — требования к описанию архитектуры и точкам зрения. https://standards.ieee.org/ieee/42010/5334/
  11. ↑ Cornell University (.edu). CS 5150 — Feasibility Studies. https://www.cs.cornell.edu/courses/cs5150/2015fa/slides/C1-feasibility.pdf
  12. ↑ Carnegie Mellon SEI. Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  13. ↑ Microsoft Azure Architecture Center. Architecture styles: microservices — benefits & complexity. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  14. ↑ Google Cloud. What Is Microservices Architecture? — Monolithic vs. microservices (обзор). https://cloud.google.com/learn/what-is-microservices-architecture
  15. ↑ NASA (2023). Requirements Management — Traceability, Bidirectional traceability (definitions). https://www.nasa.gov/reference/6-2-requirements-management/
  16. ↑ McKinsey (2012). Delivering large-scale IT projects on time, on budget, and on value. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
  17. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM) — CATWOE, 3Es. https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  18. ↑ Lancaster University (ePrints). Soft Systems Methodology and root definitions. https://eprints.lancs.ac.uk/id/eprint/48770/1/Document.pdf
  19. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM). https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  20. ↑ UCL Discovery (.ac.uk). M. Haklay. Soft System Methodology (SSM). https://discovery.ucl.ac.uk/1296/1/paper13.pdf
  21. ↑ IEEE Std 1320.1-1998 (R2004). Functional Modeling Language — Syntax and Semantics for IDEF0. https://standards.ieee.org/ieee/1320.1/2003/
  22. ↑ ISO/IEC/IEEE 31320-1:2012. IDEF0: Function Modeling. https://cdn.standards.iteh.ai/samples/60615/9c848e7a1bc54042b774b3cb050872e7/ISO-IEC-IEEE-31320-1-2012.pdf
  23. ↑ University of Washington (.edu). UML Class Diagrams / UML overview (course material). https://courses.cs.washington.edu/courses/cse403/16au/lectures/L07.pdf
  24. ↑ JHU/APL (.edu). Modeling with SysML — tutorial. https://www.jhuapl.edu/sites/default/files/2023-03/ModelingwithSysMLTutorial.pdf
  25. ↑ MIT OCW (.edu). O. de Weck. Introduction to Systems Modeling Languages (incl. SysML, MBSE). https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/23fea897f48d11f45593fa4be698d749_MIT16_842F15_Ses3_sysmodlg.pdf
  26. ↑ IBM. What is Business Process Modeling and Notation (BPMN)?. https://www.ibm.com/think/topics/bpmn
  27. ↑ IBM Docs. Business Process Modeling Notation (BPMN) model. https://www.ibm.com/docs/en/iis/11.5.0?topic=types-business-process-modeling-notation-bpmn-model
  28. ↑ IEEE/ISO/IEC 29148:2018. Systems and software engineering — Requirements engineering (overview). https://standards.ieee.org/ieee/29148/6937/
  29. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  30. ↑ T. L. Saaty. How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 1994. https://pubsonline.informs.org/doi/10.1287/inte.24.6.19
  31. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  32. ↑ MIT OCW (.edu). V-Model — Fundamentals of Systems Engineering. https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/resources/v-model/
  33. ↑ Carnegie Mellon SEI (.edu). Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  34. ↑ Microsoft Azure Architecture Center. Architecture styles. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  35. ↑ Kazman, R.; Klein, M.; Clements, P. ATAM: Method for Architecture Evaluation. CMU/SEI Technical Report, 2000. https://www.sei.cmu.edu/documents/629/2000_005_001_13706.pdf
  36. ↑ 36,0 36,1 36,2 36,3 The Open Group. Introduction — The TOGAF® Standard. https://www.togaf.org/chap01.html
  37. ↑ Microsoft Azure Architecture Center. Event-Driven Architecture style. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven
  38. ↑ Jonkers, H. et al. ArchiMate® and the TOGAF® Framework. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698909899/toc.pdf
  39. ↑ Estrem, W. Building Blocks Revisited. The Open Group (presentation). https://archive.opengroup.org/public/member/proceedings/q411b/presentations/Estrem%20-%20Building%20Blocks%20Revisted.pdf
  40. ↑ The Open Group. Architecture Principles. https://pubs.opengroup.org/onlinepubs/7499919799/toc.pdf
  41. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  42. ↑ The TOGAF® Standard, Version 9.2 (спецификация). The Open Group. https://university.sk/wp-content/uploads/2020/01/TOGAF_v9_2_specifikacia.pdf
  43. ↑ Engelsman, W.; van Sinderen, M. Supporting Requirements Management in TOGAF and ArchiMate. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698999899/toc.pdf
  44. ↑ Zachman, J. A. A Framework for Information Systems Architecture. IBM Systems Journal, 26(3), 276–292, 1987. https://doi.org/10.1147/sj.263.0276
  45. ↑ MIT CISR. Classic Topics — Enterprise Architecture (определение EA как «organizing logic for business process and IT capabilities…»). https://cisr.mit.edu/content/classic-topics-enterprise-architecture
  46. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  47. ↑ Royce, W. W. (1970). Managing the Development of Large Software Systems. IEEE WESCON. Репринт (PDF): https://www.praxisframework.org/files/royce1970.pdf
  48. ↑ Defense Acquisition University. System Requirements Review (SRR) — Acquipedia. https://aaf.dau.edu/acquipedia/article/system-requirements-review-srr/
  49. ↑ NASA (2023). Requirements Management — baseline, change control (CCB). https://www.nasa.gov/reference/6-2-requirements-management/
  50. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  51. ↑ MSDN Magazine (Microsoft). BDD Primer: Behavior‑Driven Development with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2010/december/msdn-magazine-bdd-primer-behavior-driven-development-with-specflow-and-watin
  52. ↑ Microsoft Learn. End‑to‑end traceability in Azure DevOps. https://learn.microsoft.com/en-us/azure/devops/cross-service/end-to-end-traceability
  53. ↑ Google SRE. Service Level Objectives; Error Budget Policy. https://sre.google/sre-book/service-level-objectives/ ; https://sre.google/workbook/error-budget-policy/
  54. ↑ Microsoft Learn. Azure Monitor — Overview. https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overview
  55. ↑ AWS Whitepaper. Blue/Green Deployments on AWS. https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html
  56. ↑ Microsoft Learn. Manage change — track, triage, and implement change requests. https://learn.microsoft.com/en-us/azure/devops/cross-service/manage-change
  57. ↑ Microsoft Learn (Azure Boards). Backlogs overview — create and manage your product backlog. https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/backlogs-overview
  58. ↑ Microsoft Learn (Azure Test Plans). What is Azure Test Plans?. https://learn.microsoft.com/en-us/azure/devops/test/overview
  59. ↑ MSDN Magazine. Behavior‑Driven Design with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/july/data-points-behavior-driven-design-with-specflow
  60. ↑ IBM. MTTR vs. MTBF: What’s the difference?. https://www.ibm.com/think/topics/mttr-vs-mtbf
  61. ↑ Google Cloud. Google Cloud Observability. https://cloud.google.com/products/observability
  62. ↑ IEEE Std 830‑1998. IEEE Recommended Practice for Software Requirements Specifications (исторический стандарт). Учебная копия (PDF): https://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf
  63. ↑ 63,0 63,1 63,2 63,3 NASA. Systems Engineering Handbook (NASA/SP‑2016‑6105 Rev2). https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf
  64. ↑ 64,0 64,1 NASA (2023). Requirements Management — traceability, baseline, CCB. https://www.nasa.gov/reference/6-2-requirements-management/
  65. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  66. ↑ Saaty, T. L. (1994). How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 19–43. https://doi.org/10.1287/inte.24.6.19
  67. ↑ SEI / CMMI Institute. Capability Maturity Model Integration (CMMI) — Overview. https://www.sei.cmu.edu/cmmi/
  68. ↑ NASA Langley. What is Formal Methods?; NASA‑GB‑002‑95 Guidebook. https://shemesh.larc.nasa.gov/fm/fm-what.html ; https://ntrs.nasa.gov/api/citations/19980228002/downloads/19980228002.pdf
  69. ↑ 69,0 69,1 SEI (CMU). Common Testing Problems: Pitfalls to Prevent and Mitigate (о типичных проблемах требований/трассируемости). https://www.sei.cmu.edu/blog/common-testing-problems-pitfalls-to-prevent-and-mitigate/
  70. ↑ 70,0 70,1 70,2 70,3 70,4 70,5 70,6 70,7 NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100‑1. https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
  71. ↑ 71,0 71,1 71,2 71,3 71,4 71,5 U.S. DoD CIO (2021). DoD Enterprise DevSecOps Reference Design. https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsReferenceDesign.pdf
  72. ↑ Профессиональный стандарт «Системный аналитик» (приказ Минтруда РФ от 27.04.2023 № 367н).
Источник — https://systems-analysis.ru/wiki/index.php?title=Системный_анализ_в_IT&oldid=3227