В продолжение предыдущего поста — именно потому, что в открытом доступе просто нет публикаций, разбирающих в деталях последовательность работы системного аналитика, почти бесполезно спрашивать генеративные ИИ про конкретную последовательность действий при анализе и проектировании систем со всеми нюансами.
В лучшем случае вы получите оочень общее описание процесса или пересказ какой-нибудь модели SDLC. Везде происходит какая-то магия при переходе от целей к решениям: "сначала выявите всех стейкхолдеров, потом зафикисруйте их интересы и пожелания, и на основе них разработайте требования". Вроде всё понятно, но что конкретно делать-то?
Это тем более удивительно, что изначально — ещё с 60-х — анализ и проектирование систем описывали именно как последовательность ясных шагов, выполняя которые аналитик приходит к модели целевой системы. Вопрос только, с чего мы начинаем. У Дугласа Росса (SADT, IDEF0) всё начинается с функции, её входов и выходов, потом прорабатывается внутренняя последовательность шагов. Информационные системы ведь просто берут входящую информацию (с перфокарт) и преобразуют её в исходящую (ну, так было в 60-70-х). У вас нет юскейса — у вас есть функция, а требования описывают входы, выходы, управление и шаги процесса + скорость работы.
Можно пойти наоборот от данных, как у Тома ДеМарко и Ларри Константина — тогда вашей первой диаграммой будет контекстная, показывающая систему в окружении пользователей и других систем, обменивающихся данными с вашей, а следующими — набор DFD: диаграмм потоков данных, с указанием процессов. Информационная система ведь — набор входящих и исходящих данных, процессы по их обработке (то есть функции, это же время структурного программирования), места и форматы хранения (уже появились базы данных).
К концу 80-х развились графические интерфейсы, и у пользователя появился выбор — что конкретно делать именно сейчас, какую функцию вызвать. В логике OOSE Ивара Якобсона всё начиналось с типов пользователей и юскейсов: а что в принципе пользователь может сделать в системе в любой момент? Потом каждый юскейс раскрываем в виде диаграммы устойчивости (robustness): показываем интерфейсы, управляющую логику и сущности, и какие данные они друг другу передают. Ведь ИТ-система состоит из интерфейсов, логики и объектов данных (впрочем, интерфейсы и логика — это тоже объекты). А как они конкретно хранятся в БД — это уже низкий уровень, ORM с этим разберется.
Новейшие подходы (EDA, Event Sourcing, Event Storming и даже в чем-то REST) говорят, что всё начинается с события. У вас в предметной области есть события, они вызывают срабатывание какого-то обработчика и реакцию системы/пользователя и изменение данных. А события возникают в результате отдачи команд или реакции на предшествующее событие. ИТ-системы ведь навешиваются на шину или брокер, по которой бегают сообщения о событиях — нужно просто их ловить и на них правильно реагировать.
В общем, во всех этих методиках происходит составление списков (входящих данных, функций, юскейсов, событий), и аккуратное прослеживание каждого элемента списка вглубь системы (при получении этого события какую функцию мы запускаем? при активации этого юскейса в этом интерфейсе — какие данные куда передаются и как меняются?..), так мы и приходим к требованиям и спецификациям.
Вот даже INCOSE говорит, что мы должны прийти к реализованной системе путем формальных трансформаций потребностей (needs) стейкхолдеров в требования (requirements), потом в спецификации, а потом уже в самую систему.
Сначала, помню, меня это предположение возмутило: да как так? Создание требований — это творческий процесс, а не формальный! Но сейчас соглашусь: да, нужно просто аккуратно всё выявить и последовательно трансформировать, и получится хороший результат.
Кстати, в последней версии руководства INCOSE рекомендует начать выявление требований с "концепта жизненного цикла" системы, а перед потребностями ставит "ожидания от мира". Это что-то новенькое, напишу отдельным постом.
В продолжение предыдущего поста — именно потому, что в открытом доступе просто нет публикаций, разбирающих в деталях последовательность работы системного аналитика, почти бесполезно спрашивать генеративные ИИ про конкретную последовательность действий при анализе и проектировании систем со всеми нюансами.
В лучшем случае вы получите оочень общее описание процесса или пересказ какой-нибудь модели SDLC. Везде происходит какая-то магия при переходе от целей к решениям: "сначала выявите всех стейкхолдеров, потом зафикисруйте их интересы и пожелания, и на основе них разработайте требования". Вроде всё понятно, но что конкретно делать-то?
Это тем более удивительно, что изначально — ещё с 60-х — анализ и проектирование систем описывали именно как последовательность ясных шагов, выполняя которые аналитик приходит к модели целевой системы. Вопрос только, с чего мы начинаем. У Дугласа Росса (SADT, IDEF0) всё начинается с функции, её входов и выходов, потом прорабатывается внутренняя последовательность шагов. Информационные системы ведь просто берут входящую информацию (с перфокарт) и преобразуют её в исходящую (ну, так было в 60-70-х). У вас нет юскейса — у вас есть функция, а требования описывают входы, выходы, управление и шаги процесса + скорость работы.
Можно пойти наоборот от данных, как у Тома ДеМарко и Ларри Константина — тогда вашей первой диаграммой будет контекстная, показывающая систему в окружении пользователей и других систем, обменивающихся данными с вашей, а следующими — набор DFD: диаграмм потоков данных, с указанием процессов. Информационная система ведь — набор входящих и исходящих данных, процессы по их обработке (то есть функции, это же время структурного программирования), места и форматы хранения (уже появились базы данных).
К концу 80-х развились графические интерфейсы, и у пользователя появился выбор — что конкретно делать именно сейчас, какую функцию вызвать. В логике OOSE Ивара Якобсона всё начиналось с типов пользователей и юскейсов: а что в принципе пользователь может сделать в системе в любой момент? Потом каждый юскейс раскрываем в виде диаграммы устойчивости (robustness): показываем интерфейсы, управляющую логику и сущности, и какие данные они друг другу передают. Ведь ИТ-система состоит из интерфейсов, логики и объектов данных (впрочем, интерфейсы и логика — это тоже объекты). А как они конкретно хранятся в БД — это уже низкий уровень, ORM с этим разберется.
Новейшие подходы (EDA, Event Sourcing, Event Storming и даже в чем-то REST) говорят, что всё начинается с события. У вас в предметной области есть события, они вызывают срабатывание какого-то обработчика и реакцию системы/пользователя и изменение данных. А события возникают в результате отдачи команд или реакции на предшествующее событие. ИТ-системы ведь навешиваются на шину или брокер, по которой бегают сообщения о событиях — нужно просто их ловить и на них правильно реагировать.
В общем, во всех этих методиках происходит составление списков (входящих данных, функций, юскейсов, событий), и аккуратное прослеживание каждого элемента списка вглубь системы (при получении этого события какую функцию мы запускаем? при активации этого юскейса в этом интерфейсе — какие данные куда передаются и как меняются?..), так мы и приходим к требованиям и спецификациям.
Вот даже INCOSE говорит, что мы должны прийти к реализованной системе путем формальных трансформаций потребностей (needs) стейкхолдеров в требования (requirements), потом в спецификации, а потом уже в самую систему.
Сначала, помню, меня это предположение возмутило: да как так? Создание требований — это творческий процесс, а не формальный! Но сейчас соглашусь: да, нужно просто аккуратно всё выявить и последовательно трансформировать, и получится хороший результат.
Кстати, в последней версии руководства INCOSE рекомендует начать выявление требований с "концепта жизненного цикла" системы, а перед потребностями ставит "ожидания от мира". Это что-то новенькое, напишу отдельным постом.
