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

Элементы модели процесса Модель процесса состоит из семи основных элементов: Действие (activity) - непосредственная часть процесса, может представлять собой задачу или подпроцесс Событие (event) - явление, которое без задержки происходит во время процесса. Событие может быть триггером для начала процесса, его итогом, а также может возникать в промежутках между действиями Поток (flow) - связывает действия и события. Результат направленного потока — достижение цели процесса Точка принятия решения - момент, в котором принимается решение о направлении процесса Ссылка (link) - связывает несколько моделей. Если действие подразумевает целый подпроцесс, его можно описать в виде отдельной модели и сослаться на него с помощью ссылки Роль, или участник процесса (role) - лицо, которое выполняет действие Данные (data) - данные, которые используются в процессе. Модель процессов можно представить в виде диаграммы. Для этого используются специальные нотации для моделирования процессов (BPMN, UML и нотацией Гейна — Сарсон). С самыми часто встречающимися в работе системного аналитика я вас познакомлю в следующих постах

Модель процесса Модель процесса состоит из семи основных элементов: 1.   Действие, которое может быть представлено как задача или подпроцесс. 2.   Событие, которое может быть триггером для начала процесса, его итогом, а также может возникать в промежутках между действиями. 3.   Поток, который связывает действия и события. 4.   Точка, в которой принимается решение о направлении процесса. 5.   Ссылка, которая связывает несколько моделей. 6.   Роль, или участник процесса. 7.   Данные, которые используются в процессе Модель процесса можно представить в виде диаграммы. Для этого используются специальные нотации для моделирования процессов. С самыми часто встречающимися в работе системного аналитика я вас познакомлю в следующих постах.

Потребность в информации и процессах Выявляя пользовательские и функциональные требования, системный аналитик определяет: процессы, которые команде разработки потребуется реализовать в системе; информацию, которую системе потребуется создавать, хранить, предоставлять по запросу и обрабатывать. Процесс — это последовательный поток работы или действий. Информация — это знания об объектах, таких как факты, события, предметы или идеи, которые в зависимости от контекста имеют определённое значение в предметной области. Давайте выявим разницу между информацией и процессом на примере. Пользователь будущей системы может сказать: «Система должна предоставлять мне возможность просматривать историю моих заказов за пять лет» — это потребность в реализации процесса. «Система должна сохранять историю заказов покупателя за пять лет» — это потребность в информации. Такие функциональные требования называются ориентированными на процессы или на информацию. Анализируя выявленные требования, системный аналитик составляет: модели процессов; модели данных в предметной области системы. Модели процессов описывают действия участников, связи между действиями и связи между разными процессами. Также они показывают, какие данные нужны для выполнения этих действий и процессов, какие данные создают и изменяют участники и как они используют хранимые данные. Модели процессов нужны, чтобы определить, как система может обеспечить выполнение этих процессов и действий. Модели данных необходимы для определения структуры данных, используемых в системе для выполнения процессов и действий.

Бизнес-требования • Содержат бизнес-цели организации или заказчика. Бизнес-целью может быть желание увеличить прибыль, снизить издержки, увеличить долю рынка и прочее • Исходят от тех, кто финансирует проект, заказчиков, отдела маркетинга или ответственного за концепцию продукта • Пример: в течение года с помощью бонусной системы увеличить количество постоянных клиентов до 1000 человек Пользовательские требования • Содержат описание того, какие возможности система должна предоставить пользователю для удовлетворения его потребностей. Также содержат описание важных атрибутов или характеристик продукта • Исходят от пользователей и других заинтересованных лиц, влияющих на проект • Пример: возможность списания бонусных баллов со счёта пользователя при заказе товаров с сайта Функциональные требования • Содержат сценарии поведения продукта в различных условиях • Исходят от системных аналитиков • Пример: отображаемая стоимость товара должна уменьшиться на величину списываемых бонусных баллов Нефункциональные требования • Содержат ограничения, налагаемые на систему, которые определяют ее атрибуты качества (безопасность, производительность, масштабируемость, доступность, юзабилити, совместимость, техническое обслуживание) • Исходят от системных аналитиков • Пример: Приложение должно поддерживать устройства, работающие на операционных системах: iOS 9.0- 16.0, Android 7.0 – 12.0 (учитывая специфические особенности марок Xiaomi, Huawei)

Чем бизнес-аналитик отличается от системного аналитика? Зачем на проекте столько аналитиков? Бизнес-аналитик говорит, что нужно сделать, системный аналитик — как это нужно сделать. Представьте владельца ресторана с низким рейтингом заведения в интернете. В отзывах клиенты жалуются, что счёт несут очень долго. Ресторатор нанимает бизнес-аналитика, задача которого — понять, почему посетителям долго несут счёт и что с этим можно сделать. Бизнес-аналитик заметил, что официанты записывают заказ на бумаге, листок передают на кухню, а потом долго ищут его, когда нужно рассчитать клиента. Бизнес-аналитик описал проблему, оценил её масштаб и предложил варианты решения. Владелец ресторана рассмотрел предложенные варианты и решил внедрить систему управления заказами, которая будет автоматически формировать чек к каждому заказу. Для внедрения такой система ресторатор обращается к системному аналитику. Системный аналитик собирает требования от владельца ресторана, официантов, поваров и других. Затем он проектирует систему, ставит разработчикам конкретные задачи с чёткими инструкциями: как должна выглядеть база данных с заказами, какую информацию о заказах там нужно хранить, как должен работать интерфейс этой системы