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

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
10-Мар-2021 14:31

Цитировать

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

Разработчику с проектированием и документированием решения задачи помогает аналитик. Аналитики бывают двух видов:

Бизнес-аналитик — понимает заказчика, его бизнес, пользователей, творчески мыслит. Он приносит задачу в команду на уровне «Наш бизнес (или пользователи) хочет такое вот волшебство: в двух словах рассказываю, все понятно, делаем!». Бизнес-аналитик отвечает за ожидания и потребности пользователей, за вид ПО снаружи.
Системный аналитик — как правило, встречает бизнес-аналитика (если сам им не является) / заказчика / владельца продукта, получает «несколько строк на человекочитаемом» описания задачи, BPMN-диаграммы дедлайн. Он принимает задачу: оценивает изменения, анализирует влияние на подсистемы, модель данных, расписывает алгоритмы и вот это вот все.
Системный аналитик отвечает за внутренности, о которых пользователям лучше вообще не знать и не думать.

Задача системного аналитика — спроектировать решение «от и до»:

Проработать пользовательские и системные сценарии, алгоритмы, реакцию на действия пользователя, обработать все возможные «а что может пойти не так»,
Определить связи между подсистемами, влияние на них,
Декомпозировать задачу, если она большая,
Описать изменения в модели данных.
Продумать требования к UI/UX.

В процессе проектирования с командой разработки обсуждаются варианты технической реализации. Системным аналитиком создаются UML-диаграммы, ER-диаграммы, схемы обмена данными, последовательности передачи управления. В общем всё, что происходит внутри — зона ответственности системного аналитика.Об очевидномКстати, иногда пользователем системы может быть другая система.

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

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

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

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

Шаблон для проектирования поможет получить результатОт системного аналитика требуется описание модели ровно в том объеме, в котором его хочет получить заказчик. Проект дома — понятие широкое, в него может быть вложено абсолютно разное наполнение: от дизайна комнат до высоты фундамента и толщины стен. Бизнес-заказчику обычно важно только то, что видит пользователь, а вот госзаказчику описание подавай по ГОСТу. Все разные.В МоемСкладе — свой продукт. Нам важно понимать, какие возможности он реализует, какое поведение можно ожидать от системы, как обеспечена реализация в коде, как представлены объекты в модели данных. У нас внедрен шаблон документации, который системные аналитики и другие участники команд наполняют в процессе проектирования и описания решения задачи.Наш шаблон состоит из перечисленных далее блоков. Он помогает описывать, как встраивать новые кирпичики в «большое здание МоегоСклада».Общее описание. Фото здания снаружиВ этом разделе мы описываем, что это за функциональность, для чего и для кого она предназначена. Кратко формулируем описание работы и какой результат нужно ожидать в идеальном случае.Если необходимо, то обозначаются особенности работы, которые точно вызовут вопросы в процессе реализации и тестирования — все «потому что так задумано».

Влияние и связи. Не заденем ли мы при строительстве ель и баню, которые тут уже стояли?В этом блоке в шаблоне автоматически подставляется полный список подсистем продукта и подсказки по функциональности, которая в них входит. Аналитику нужно заполнить его, чтобы проверить, что он точно всё учел, показать, с чем связана доработка.Заполняя этот блок, системный аналитик оценивает влияние изменений на весь продукт в целом и ищет части, которые могут быть задеты.Так, например, изменения в пользовательском UI основного приложения могут повлиять на наш публичный API и мобильные клиенты. Другим командам нужно будет своевременно сообщить о необходимости доработок.Описание функциональности и основные сценарии. Список помещений и способы их использованияСистемный аналитик прорабатывает:

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

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

Описание может включать UML- и BPMN-диаграммы, блок-схемы, диаграммы состояний, текстовое описание поведения, макеты экранов. Всё, что может помочь разобраться в том, как система должна работать: все решения по алгоритмам, основным сценариям и способам обработки ошибок.Этот блок является основным, так как описывает модель поведения системы: ее реакцию на действия пользователя и внешние события.Доступы и ограничения или просто ролевая модель. Кто может войти в зданиеВ системе есть администратор и обычный пользователь, оплаченный аккаунт и бесплатный, сотрудник с доступом к отчетам и без, пользователи основного приложения и кассового. Здесь нужно описать, кто будет допущен к использованию функциональности.Если в шаблоне проектирования внедряется этот блок, то его лучше сразу наполнять заглушками по полному набору ролей пользователей, чтобы системный аналитик не упустил ничего.Описание UI/UX. Дизайн-проект зданияЗдесь важно не просто рассказать про то, что «пользователь видит на экране форму документа» и прикрепить макет, а подробно описать:

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

Если к моменту начала разработки есть макет от дизайнера — прекрасно! Если нет, то системный аналитик должен уметь сделать макеты, поставить задачку дизайнеру, который сделает всё удобно и красиво.

Для наглядности показываю нашу заглушку.

P.S. Хранить скрины и макеты в будущей документации не всегда хорошо. Они частенько теряют актуальностьТехническая реализация. Описание фундамента и инженеркиСамое интересное происходит здесь! Требования к технической реализации можно описывать только после того, как модель поведения системы полностью проработана и согласована со всеми заинтересованными лицами. Их аналитику помогают собирать разработчики и архитекторы. Опытные аналитики могут проектировать эту часть самостоятельно.Нужно проанализировать и описать:

Список подсистем, которые будут реализовывать функциональность и процесс обмена данными между ними.
Изменения в модели данных.
Требования к алгоритмам обработки данных, работе с CRUD-моделью. Другие особенности реализации.

Техническая реализация — это последняя стадия проектирования перед написанием кода. Она может быть описана поверхностно, и доделывать ее нужно только после написания кода. Блок используется для сохранения знаний об особенностях реализации и помогает быстро понять, как работает функциональность без доступа к коду.Логирование и метрики. Как монтировать камеры видеонаблюдения и систему охраныМы анализируем работу нашего продукта: собираем метрики, все логируем. На этапе проектирования закладываются отдельные требования в этой части, а по итогам реализации описание дополняется для документации.Другие блокиВ зависимости от того, какая часть МоегоСклада описывается, могут быть блоки:

REST API - контракты.
Работа ПО в оффлайн-режиме — особенности поведения в отсутствии сети для касс и мобильных приложений.
Программно-аппаратные интеграции для касс.

ПодытожимСистемным анализом для разработки ПО может заниматься как выделенный специалист, так и любой из участников команды. Для описания модели системы рекомендую использовать шаблон проектирования, который после релиза превращается в документацию с описанием работы, если в процессе реализации он добросовестно актуализируется и уточняется командой.Моделируя систему, определитесь с тем, кто будет потреблять документированную информацию как на этапе разработки, так и в будущем, какие знания важно сохранить по итогам реализации на «электронной бумаге».Строить дом без плана — странно. Может получиться избушка на курьих ножках, куча дров в результате дуновения ветра или недостроенное нечто. С программным обеспечением — аналогично. Если заранее не проработать требования к реализации и не описать модель, то в результате разработки может получиться набор костылей, который будет раз за разом переписываться. Его будет сложно тестировать.

Нет модели — нет ожидаемого поведения системы.

Проектируйте, и в процесс вашей разработки придет порядок!
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_proektirovanie_i_refaktoring (Проектирование и рефакторинг), #_podgotovka_tehnicheskoj_dokumentatsii (Подготовка технической документации), #_proektirovanie_sistem (проектирование систем), #_sistemnyj_analiz (системный анализ), #_sistemnyj_analiz_biznesprotsessov (системный анализ бизнес-процессов), #_sistemnyj_analitik (системный аналитик), #_arhitektura_prilozhenij (архитектура приложений), #_arhitektura_po (архитектура по), #_proektnaja_dokumentatsija (проектная документация), #_dokumentirovanie (документирование), #_blog_kompanii_mojsklad (
Блог компании МойСклад
), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_proektirovanie_i_refaktoring (
Проектирование и рефакторинг
), #_podgotovka_tehnicheskoj_dokumentatsii (
Подготовка технической документации
)

Профиль ЛС

Ответить на тему

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

Текущее время: 22-Ноя 16:20
Часовой пояс: UTC + 5