Автоматизация процессов управления рисками

Практическое руководство, примеры и шаблоны

Лучший способ понять теорию — получить больше опыта в разных проектах. Для системных и бизнес-аналитиков я постоянно показываю подходы к работе через публикацию разборов задач: БД, API, Интеграции, требования, и все, что связано с проектированием систем.

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

Проект

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

Все примеры в статье будут связаны с этим проектом.

Общий подход к работе системного аналитика

01 Знакомство с бизнес-контекстом и бизнес-требованиями, их уточнение

Во‑первых, что такое бизнес‑контекст? Это как фон, на котором мы пытаемся понять нашу задачу. В нашем случае, это может быть, например, понимание того, как сообщество общается сейчас, какие у него проблемы и какие цели оно преследует. Здесь мы можем поговорить с руководством сообщества, пообщаться с его действующими участниками, изучить их текущие способы общения — социальные сети, форумы, вебинары и так далее. Либо просто получить уже собранную информацию с описанием работы сообщества сейчас — это AS IS (описание «как есть» для проекта).

Теперь, что такое бизнес‑требования? Это то, что бизнес хочет от будущей системы. В нашем случае, это может быть, например, желание сделать процесс регистрации на вебинары проще и удобнее, или желание собрать всю информацию из разных соцсетей в одном месте. Бизнес‑требования мы также обычно собираем на встречах с заказчиком, проводим интервью и обсуждения. Это To Be — как должно быть в результате разработки.

Важно понимать, что первоначально собранные требования часто бывают не полными или не точными.

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

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

02 Определение ролей пользователей и приложений. Верхнеуровневое проектирование архитектуры

Определение ролей пользователей и приложений

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

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

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

Верхнеуровневое проектирование архитектуры

Сначала выделяем компоненты системы — отдельные приложения, сервисы:

• сервер Backend, который будет обрабатывать запросы от приложения, и может включать в себя подсистемы (сервисы, микросервисы),

• база данных для хранения информации о пользователях, вебинарах и новостях,

• внешние системы — источники данных, из которых надо получать данные и в которые их надо передавать (интеграции).

Для визуализации архитектуры можно использовать нотацию C4.

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

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

03 Выделение и описание основных сценариев работы с системой

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

Use Case

Для описания сценариев очень удобно использовать формат use case. Use case — это описание того, как система и пользователи взаимодействуют друг с другом для достижения какой-то цели. Use case включает в себя не только последовательность действий, но и роли, которые участвуют в этом взаимодействии, и возможные альтернативные сценарии.

Основное удобство формата use case в том, что он позволяет представить сценарии взаимодействия с системой в простой и понятной форме. Use case показывает, какие роли участвуют в сценарии, что они делают, и как система на это реагирует. Это помогает всей команде лучше понять, как должна работать система, и учесть все возможные варианты взаимодействия пользователей с системой.

04 Проработка альтернативных сценариев

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

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

Все эти варианты мы должны проработать и описать как альтернативные сценарии. Каждый альтернативный сценарий должен описывать, что происходит в этой ситуации, и как система должна на это реагировать.

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

05 Задачи на дизайнера

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

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

Иногда системный аналитик рисует макеты, используя Figma, Miro, Draw.io, Axure RP Pro или другие инструменты.

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

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

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

06 Определение ключевых данных: сущности и их свойства

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

Вернемся к нашему примеру мобильного приложения для сообщества. Основными сущностями в нашем случае могут быть «Пользователь», «Вебинар» и «Новость». У каждой из этих сущностей будут свои свойства. Например, у «Пользователя» могут быть свойства «Имя», «Email», «Дата регистрации», и т.д. У «Вебинара» — «Название», «Дата и время», «Описание», «Организатор», и так далее.

Также мы должны определить, как эти сущности связаны друг с другом. Например, «Пользователь» может быть зарегистрирован на одном или нескольких «Вебинарах». Эта информация важна, потому что она поможет нам понять, как должна быть организована база данных нашего приложения.

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

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

07 Задачи на доработку Базы Данных

Прежде чем программисты начнут разрабатывать методы Backend, им нужно подготовить базу данных.

• создать новые таблицы,

• добавить поля в существующие таблицы,

• сделать миграции данных (перенос и автозаполнение),

• иногда поменять типы данных, удалить лишние поля и так далее.

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

Шаблон Confluence и инструкция

08 Задачи на подготовку тестовых данных

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

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

Например, в случае нашего приложения для сообщества, мы можем создать несколько тестовых «Пользователей» с разными параметрами — с корректными и некорректными email’ами, зарегистрированными на разное количество «Вебинаров», и т. д. Мы также можем создать несколько тестовых «Вебинаров» и «Новостей» с различными свойствами.

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

09 Задачи на разработку методов Backend (методов API)

В работе приложений существует нечто, что помогает передавать данные между разными частями системы, например, между пользовательским интерфейсом (фронтендом) и сервером (бекендом). Это называется API, или Application Programming Interface.

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

Для каждого метода API, системный аналитик должен определить, какие данные он принимает на вход (например, данные для регистрации нового пользователя), и что он возвращает на выход (например, подтверждение успешной регистрации).

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

Пример задачи на бэкенд — шаблон постановки задачи + инструкция

10 Задачи на фронтенд / мобильные

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

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

Вот пример таких задач:

1. Создание экрана регистрации на вебинар.

2. Отображение списка доступных вебинаров.

3. Создание уведомлений о предстоящих вебинарах.

4. Добавление возможности читать новости сообщества в приложении.

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

Пример задачи на фронтенд — шаблон постановки задачи

11 Задачи на тестирование

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

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

1. Проверить, происходит ли корректная регистрация пользователя на вебинар.

2. Убедиться, что новости сообщества отображаются правильно и актуальны.

3. Проверить работу уведомлений о предстоящих вебинарах.

4. Протестировать работу приложения на разных устройствах и разных версиях операционной системы.

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

12 Задачи на сохранение важных артефактов по документации после разработки — документация

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

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

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

1. Документы, описывающие функциональные требования и пользовательские сценарии.

2. Диаграммы и схемы, включая C4 диаграммы архитектуры системы и Use Case диаграммы.

3. Документы с описанием ключевых данных, сущностей и их свойств.

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

5. Документы с результатами тестирования и проблемами, обнаруженными в процессе разработки (особенности и известные проблемы).

Все это может быть собрано в ранее приведенных шаблонах требований для Confluence.

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

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

Про процесс документирования:

Применение описанного подхода на практике

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

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

Заключение

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

Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку

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

1. Транзакционные информационные системы (ТИС)
Транзакционные информационные системы, или ТИС, являются одним из основных видов информационных систем. Они предназначены для обработки повседневных операций в организации. ТИС записывают и отслеживают все транзакции, такие как продажи, закупки, финансовые операции и другие. Эти системы обеспечивают надежное и точное ведение учета, а также автоматизируют процессы, ускоряя их выполнение.

2. Управленческие информационные системы (УИС)
Управленческие информационные системы, или УИС, предоставляют руководителям информацию, необходимую для принятия стратегических решений. Они анализируют данные из различных источников, создавая отчеты и аналитические инструменты. УИС помогают оптимизировать управленческие решения, улучшая производительность и конкурентоспособность организации.

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

4. Географические информационные системы (ГИС)
Географические информационные системы, или ГИС, объединяют географические данные и информацию для анализа и принятия решений в различных областях. Они позволяют создавать карты, выполнять анализ пространственных данных и оптимизировать процессы, связанные с географическими местоположениями. ГИС применяются в городском планировании, экологии, транспорте и других областях.

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

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

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

Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 15 января 2023 года; проверки требуют 14 правок.

В качестве важнейшего предшественника мир-системного подхода, заложившего его основы, обычно рассматривается Фернан Бродель. Поэтому не случайно, что ведущий центр мир-системного анализа (в г. Бингхэмптон, при Университете штата Нью-Йорк) носит имя Фернана Броделя. Бродель писал о взаимосвязывающей все общества «мир-экономике». У неё имеется свой центр (со своим «сверхгородом»; в XIV веке им была Венеция, позднее центр переместился во Фландрию и Англию, а оттуда в XX столетии — в Нью-Йорк), второстепенные, но развитые общества и окраинная периферия. При этом торговые коммуникации связывают разные регионы и культуры в единое макроэкономическое пространство.

Наиболее распространённая версия мир-системного анализа разработана Иммануилом Валлерстайном. Согласно Валлерстайну, современная мир-система зародилась в так называемом «длинном XVI веке» (приблизительно 1450—1650 годы) и постепенно охватила собой весь мир. До этого времени в мире одновременно сосуществовало множество «исторических систем» (термин, заменяющий «общество»). Эти «исторические системы» Валлерстайн подразделяет на два типа: минисистемы и мир-системы (мир-экономики и мир-империи).

• Минисистемы были характерны для первобытных обществ. Они «малы в пространстве», относительно кратки во времени, однородны с точки зрения культурной и управляющей структур, основаны на отношениях взаимообмена.
• Мир-системы характерны для сложных аграрных обществ.
  • Мир-экономики представляют собой системы обществ, объединённых тесными экономическими связями, выступающими в качестве определённых эволюционирующих единиц, но не объединённых в единое политическое образование. C XVI в. феодальная Европа трансформируется в капиталистическую мир-экономику. Весь современный мир представляет собой одну единственную мир-систему — капиталистическую мировую экономику. Капиталистическая мир-система состоит из ядра (наиболее высокоразвитые страны Запада), полупериферии (в XX веке — социалистические страны) и периферии (Третий мир). История ядра — история борьбы за гегемонию.
  • Мир-империи характеризуются взиманием налогов (дани) с провинций и захваченных колоний. Это обширные политические структуры, которые охватывают широкое разнообразие «культурных» образцов. Мир-империи нельзя разделить на ядро и периферию, так как государственный центр и его колонии являются единым целым.

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

Относительно будущего Валлерстайн отрицал теорию модернизации, согласно которой возможно построить ядро без периферии.

Краткий обзор основных событий эволюции афроевразийской мир-системы

Об объединении обществ можно говорить тогда, когда началась аграрная революция. В течение X—VIII тыс. до нашей эры на Ближнем Востоке распространяется скотоводство и земледелие, при таких изменениях обществ и поселений их уровень развития меняется. Начинают налаживаться культурные, информационные и торговые связи. В IV—III тыс. до нашей эры на Ближнем Востоке начинает возникать множество городов. Начинает появляться письменность, осуществляется переход к ирригационному земледелию и новой технологии обработки почвы. На этой основе зарождаются первые государства и цивилизации. В данный участок времени достаточно синхронно начинают практически повсеместно внедряться новые технологии: плуг, упряжь, колесо, гончарный круг. Когда появилась медь и бронза, эти материалы позволили расширить военные возможности, начинается борьба за первенство. Политическая карта часто меняется из-за постоянных нашествий кочевников. В III тыс. до нашей эры возникают и развиваются новые центры цивилизации. Немного позже II тыс. до н. э. на Дальнем Востоке появляется новый мир-системный центр.

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

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

Заметными мир-системными событиями стали крестовые походы, в результате которых наладился канал торговли пряностями из Индии в Европу. В результате образования Монгольской империи в XIII веке с подконтрольными обширными территориями Евразии образовались стабильные торговые пути из Китая в Европу, что увеличило обмен инноваций между цивилизациями. Ещё одним важным событием стало включение Южной Индии в более тесные взаимоотношения с другими частями мир-системы, вследствие установления там власти мусульман и частичной исламизации населения.

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

1. Юрий Зарецкий. Истории, которые у нас не пишутся — Журнальный зал Архивная копия от 20 сентября 2022 на Wayback Machine
2. См., например: Korotayev A. Compact Mathematical Models of World System Development, and How they can Help us to Clarify our Understanding of Globalization Processes. Архивная копия от 3 ноября 2014 на Wayback Machine // Globalization as Evolutionary Process: Modeling Global Change. Edited by George Modelski, Tessaleno Devezas, and William R. Thompson. London: Routledge, 2007. P. 133—160.
3. См., например, Коротаев А. В. и др. Законы истории: Математическое моделирование и прогнозирование мирового и регионального развития Архивная копия от 23 августа 2010 на Wayback Machine. Изд. 3, сущ. перераб. и доп. М.: ЛКИ/URSS, 2010. С.29-30.
4. Юрий Семенов. Философия истории. Дата обращения: 27 февраля 2022. Архивировано 27 февраля 2022 года.

• Бродель Ф. Материальная цивилизация, экономика и капитализм, XV—XVIII вв. / Пер. с фр. Л. Е. Куббеля; вступ. ст. и ред. Ю. Н. Афанасьева. 2-е изд. М.: Весь мир, 2006. ISBN 5-7777-0358-5
• Валлерстайн И. Анализ мировых систем и ситуация в современном мире / Пер с англ. П. М. Кудюкина под общей ред. Б. Ю. Кагарлицкого. СПб.: Университетская книга, 2001.
• Валлерстайн И. Миро-системный анализ // Время мира. Альманах современных исследований по теоретической истории, макросоциологии, геополитике, анализу мировых систем и цивилизаций / Под ред. Н. С. Розова. Новосибирск, 1998. — Выпуск 1. — С. 105—123.
• Гринин Л. Е., Коротаев А. В. Социальная макроэволюция : Генезис и трансформации Мир-Системы. М.: Книжный Дом «ЛИБРОКОМ», 2009.
• Коротаев А. В., Малков А. С., Халтурина Д. А. Законы истории. Математическое моделирование развития Мир-Системы. Демография, экономика, культура. 2-е изд. М.: УРСС, 2007. ISBN 978-5-484-00957-2
• Коротаев А. В., Комарова Н. Л., Халтурина Д. А. Законы истории. Вековые циклы и тысячелетние тренды. Демография, экономика, войны. 2-е изд. М.: УРСС, 2007.
• Коротаев А. В., Халтурина Д. А. Современные тенденции мирового развития. М.: ЛИБРОКОМ/URSS, 2009. ISBN 978-5-397-00327-8
• Коротаев А. В. и др. Законы истории: Математическое моделирование и прогнозирование мирового и регионального развития. Изд. 3, сущ. перераб. и доп. М.: URSS, 2010.
• Кирилюк И. Л. и др. Экономическая динамика Мир-Системы // История и Математика. М.: УРСС, 2008. С. 102—119.
• The World System: Five Hundred Years or Five Thousand? / Ed. by A. G. Frank and B. Gills. L.: Routledge, 1994.
• Завалько Г. А. Возникновение, развитие и современное состояние мир-системного подхода // Общественные науки и современность. 1998. № 4.
• Завалько Г. А. Всемирная история глазами сторонников мир-системного подхода // Философия и общество. 1998. № 5.3.
• Завалько Г. А. Мировой капитализм глазами И.Валлерстайна // Альтернативы. 1998. № 4.
• Гринин Л. Е. Истоки глобализации: мир-системный анализ // Век глобализации. Выпуск № 1(7), 2011

• Валлерстайн И. Мир-системный анализ
• Макродинамика урбанизации Мир-Системы
• «Мир-системный подход» часть монографии Ю. И. Семенова «Философия истории»
• Institute for Research on World-Systems
• Journal of World-Systems Research
• World-Systems Archive
• Крадин Н. Н. Проблемы периодизации исторических макропроцессов. Раздел «Мир-системный подход»
• Макроэволюция Мир-Системы и цивилизаций
• Глобализация началась 10 тысяч лет назад и закончится в XXI веке
• Генезис и трансформации Мир-Системы
• Общие тенденции экономического развития Мир-Системы (недоступная ссылка)
• Периодизация истории Мир-Системы и математические макромодели социально-исторических процессов