Данный канал посвящён практикам системной инженерии в работе системного аналитика на проектах создания информационных систем. В представленных материалах содержатся субъективный практический опыт применения системных практик, их общее описание и польза, которую они могут принести. Канал ориентирован на сообщество бизнес, функциональных и системных аналитиков. При подаче материалов предполагается, что слушатели знакомы с базами бизнес и системной аналитики.
Опыт работы автора канала представлен по ссылке ниже: www.linkedin.com/in/oleg-igonin-b80161264
Спасибо автору за подготовку материала! Лекция имеет особенную ценность для тех кто практически погружается в тему СА и главное, готов к непростому общению с Заказчиками.
Огромное спасибо автору, за истинно-системное инженерное изложение темы! Очень редко встречаю подобный глубокий анализ и изложение материала, с учетом взаимосвязи с реальными условиями работы. Просьба, вернуться к варианту записи звука, аналогично как в предыдущих видео.
Огромное спасибо за качество материала! Возможно, это единственный курс, где понятно объясняется откуда берутся данные и в каком именно виде они являются основой для проектирования API.
Добрый день. На заметку для автора, если планируете записывать видеоматериал, то уделите внимание громкости вашей речи. Прошлое видео итак не громкое, а в этом еще тише.
Отчасти могу понять это. Но здесь каждый раз надо искать золотую середину между "относительно спокойно" и "громко и слышно как стучат клавиши и шуршит бумага". Перед каждой записью микрофон специально настраивается, для этого используется прямое подключение наушников, так что в момент записи я слышу как пишется голос. Сейчас проверил на телефоне, двух компьютерах - звук чистый, не громкий, но и не тихий. Рекомендую проверить звук в системе + регулятор на колонках\наушниках. В конце концов может быть я просто занудный или запаренный (для инженеров это норма, бодрый инженер - странный инженер). =)
Дело в том,что его микрофон находится на полу метре от него и плюс он себе под нос бормочет. Смотрю весь контент с телевизора в диапазоне громкости 10-15, на этом видео что бы отчетливо слышать что он говорит звук выкрутил на 55
@@MRshtoraThe спасибо за обратную связь! Еще раз проверил на 4х разных устройствах (телефон, три компьютера), звук чистый, в максимуме громкости бьет по ушам.
Олег, хороший материал, особенно для начинающих аналитиков но вот вопрос, а есть ли смысл тратить время на обоснование "Зачем" для тех полей, смысл которых и так по сути очевиден и понятен из названия (id, name, data и прочие такие шаблонные атрибуты) ?
Я имею опыт работы в больших компаниях, где есть много источников данных, бизнес-процессов, кривых рук у команд разработки и так далее. В таких случаях в одном контракте может быть много разных идентификаторов. Притом это могут быть идентификаторы одной и той же сущности в разных базах данных или приложениях. Это может быть два названия у поля, которое выполняет одну функцию, но сейчас идёт миграция данных из одного поля в другое. И выходит что-то вроде contractId, contractIdNew. И подобных кейсов много. В целом часто видны контракты без описаний и это большая проблема, так как человек читает контракт и ему не нужно искать справочник что за что отвечает, как называется и где лежит. Ведь ему нужен контекст, и поле описание как раз даёт конткест: что за поле, откуда берётся, за что отвечает, в каком процессе используется и зачем. + программисту это даёт возможность корректно описать поля в сваггаре + это позволяет почти всем проводить GAP-анализ контракта (поле - смысл - предназначение). + это помогает избавляться от полей, которые "просто надо добавить потому что кто-то когда-то так сказал". + иногда методу так много лет, что описание - это единственный источник правды для аналитика. И так далее. Да, многое чинится грамотным составлением контракта и именованием переменных. Но людей, способных на это и хорошо комментирующих код единицы, а проблемы с именованием переменных встречаются каждый день и без пол-литра с ними обычно не разберёшься. Для всего этого планировалось 4е видео минут на 20, но на него пока нет времени и желания.
@@aleksb.92 Большие мазки на картине? Или работа аналитика в рамках жизненного цикла одного проекта? Это можно описать в 15-20 минутах видео, но из-за отсутствия деталей оно выйдет пустым. Кроме того, разве таких видео уже не куча? Я всё-таки стараюсь делать материал по решению конкретных проблем, который слабо представлен в сети.
Коллеги, ну разве так трудно для слайдов сделать нормальные тексты без подчеркиваний проверки орфографии/пунктуации? Что за волнистые подчеркивающие линии чуть ли не на каждом слайде? Добавьте в тезаурус своей программы, в которой сделали презентацию, все эти строчки, на которые так реагирует программа, в которой делали слайды. Как-то по-детски, совсем не профессионально выглядит... Печалька и лучи грусти!
Спасибо за обратную связь! О причинах: Канал ведёт один человек без монетизации. Я даже понятия не имею зачем его веду! =D Контент канала на ютубе в целом развивается со временем. Пока что содержание намного важнее подачи, а на "красивости" и редактирование просто нет времени и ресурсов.
Олег, здравствуйте!) большое спасибо за лекцию, очень ценная информация) Подскажите, пожалуйста, как реализовать СА если есть сценарий с ошибкой. Например есть запрос, мы идём в смежную систему, по какой то причине смежная система отвечает ошибкой, * какой то процесс*, на стороне клиента видим ошибку. Такой вариант надо описывать на другой странице с новой схемой? Или это можно как то засунуть на эту же страницу? Или все собирать на одной странице это плохая практика? Ещё вопрос, как указывать описание систем логирования, мониторинга и тд?
Если надо описать процесс обработки ошибки, которую выдаёт внешняя система, то можно конечно нарисовать схему. Другой вопрос, что таких ошибок может быть много и на каждую схему не нарисуешь. Значит здесь нужно описать общий подход. Например, "Если внешняя система отвечает с ошибкой, то приложение должно ответить с ошибкой, завернув текст и код ошибки смежной системы в тело ответа". Как заворачивать подобные ошибки каждая команда решает сама. Тут подходы разнятся и надо уточнять у ваших разработчиков. Главное знать в каком поле вернётся внешняя ошибка и её код (если он есть), а также какой код будет сформирован вашим приложением. Тогда ошибка будет читаема и причина будет светиться в логах и внешний сервис будет знать о ней. Порой внешний сервис не должен знать о внутренней кухне (что у вас и где у вас пошло не так). Пользователь точно не должен про это знать, т.е. на фронте эта ошибка должна преобразовываться в человеческий текст с причиной ошибки. Где описывать ошибки внешнего сервиса? Они должны быть описаны на стороне того сервиса. Разработчику можно прикрепить ссылку на их документацию. Он в целом обычно делает алгоритм сразу на группу кодов: "если получил 400, запиши причину из этого поля ответа внешней системы в это поле ответа, код прокинь сюда, скопируй http status code и выплюнь наружу". Обычно подобное поведение прописывается дефолтно в стандартах разработки API вашего отдела. Их запаришься писать в каждом сервисе, а так один раз договорились и весь флот API работает в рамках одной модели поведения. Порой надо описать нетривиальное поведение для конкретных ответов внешней системы. Например, при ошибке от внешней системы надо откатить транзакцию, или повторить запрос с таймаутом, либо пожаловаться в мессенджер и так далее. Можно также явно приписать поведение для http status code или кодов бизнес-ошибок. Так, если объект уже создан, то это считать ошибкой уже не надо, наружу можно отдать соответствующий код. Либо, если сценарий длинный, то указать, что эта ошибка не прерывает выполнение запроса и алгоритм идёт дальше.
На уровне документа технического решения в списке нефункциональных требований можно отметить логирование и мониторинг. Если система новая и люди "ни в зуб ногой" что в логировать, то можно явно прописать (но это выглядит больше как работа разработчика). В том числе можно указать требование к наличию трассировочного идентификатора. Мониторинг зачастую надо явно прописывать в НФТ: какие метрики нас интересуют, за какой срок, в какой момент слать алерты, границы памяти приложения, места на диске, нагрузки, нужен ли дашборд и так далее. Это отдельная большая тема.
Если вы в прошлом разработчик, то смотрите в код и описываете то, что там происходит. Если нет, то хватаете опытного в этом сервисе разработчика, назначаете с ним встречу на час, и разбираете как всё работает метод за методом. Он рассказывает шаги, вы записываете. Повторяете встречи до тех пор, пока не будет полной документации.
Когда будет время и силы. Создание материала занимает в среднем 8 рабочих часов. Даже с учетом того, что все материалы готовы, надо потратить 4 часа на запись и редактирование. Но с учетом графика работы + университета, этого времени нет. 😁
@@systemsengineering понимаю) спасибо за ответ. Очень нравится ваша подача и материал. Будьте добры порекомендуйте, пожалуйста, книги по теме для изучения.
@@Richget23 Для бизнес-процессов можно почитать bpm cbok (есть на русском), стейкхолдеры, записи и каналы - smart руководство по фасилитаци, чтобы понять как варить карточку проекта, цели проекта, цели компании, метрики достижения - это всё из pmbok и сферы руководителей проектов. Вообще всё, что тут сказано, должно быть настроено менеджером, т.к это процессы, за которые он отвечает.
@@Richget23 Даже чуть больше скажу. Второе видео должно было быть не про то, как настроить всё это, а про то, как не попасть в ловушку криво настроенной системы менеджерами, когда из-за криво настроенных процессов вы оказываетесь крайним или узким горлышком в работе или берёте на себя чрезмерное количество работы или ваша работа выполняется некачественно и так далее. Без прав руководителя или методиста PMO и поддержки руководства даже не пытайтесь изменить систему или наладить процессы.
@@gu1503 В прошлом я поступил в магистратуру и релоцировался в Чехию. Так что пока не было времени на канал. Приходится выбирать - развивать себя или других людей. Обычно я записываю сюда материал, чтобы не тратить время на ответы на шаблонные вопросы разным людям, иногда для систематизации материала у себя в голове, а иногда по ходу, если делаю вебинары для работы. Я думаю материал будет, но пока нагрузка большая, времени особо нет.
Обычно я рекомендую читать Карла Вигерса "разработка требований к программному обеспечению" и проходить бесплатные курсы на курсере школы системного анализа Левенчука (МФТИ), бесплатные курсы на openedu от УрФУ "Практики системной инженерии", "Информационные сервисы в управлении инженерной деятельностью". Если говорить про API на моём уровне, то это надо понимать программирование достаточно хорошо + знать как создавать API, знать SQL, знать, что происходит в коде и так далее. Лучше всего начать погружаться в это с бизнес-требований и ограничений, постепенно изучая системную аналитику и основы программирования и SQL, чтобы иметь возможность впоследствии писать функциональные требования. Так как системная аналитика на 25-40% состоит из бизнес-аналитики.
@@systemsengineering в курсе по Практике системной инженерии доступна только первая неделя, думаю с остальными аналогичная ситуация. На курсере я ничего не нашёл, по тому что вы скинули. Про Вигерса довольно противоречивое мнение, некоторые советуют читать "Современные методы описания функциональных требований к системам" Коберна. Был бы вам очень признателен хотя бы за один курс по системному анализу)
@@xenx7312 Читать стоит и Коберна и Вигерса и BABOK. Книга К. Вигерса помогает понять окружение, которое формируется вокруг требований. Книга А. Коберна помогает понять как именно их можно писать, а BABOK даёт перечень техник для написания, сбора, валидации (и т.д.) требований на высоко-абстрактном уровне (так что его лучше читать последним). Непосредственно на рабочем месте обычно уже есть шаблоны требований, которые можно использовать, обычно их разработкой занимается либо руководитель отдела аналитики, либо тимлид, либо PMO. Монетизация курсов могла измениться, но скорее всего у вас курс даётся постепенно, проверьте профиль вашего участия, когда откроется следующий материал. Курс длится 12 недель, раскрывается постепенно, по 3-9 учебных часов в неделю. На курсере часто используется такой-же подход ограничений. Возможно в связи с внешними обстоятельствами на курсере теперь нет курсов МФТИ. Курс Левенчука можно найти на его сайте, в книге, которую можно купить\скачать. Уверен, что возможно где-то можно найти видеозаписи курса. Насчёт новых курсов сказать сложно, т.к. я уже 1.5 года нахожусь не в стране. А чтобы оценить курс надо его либо пройти, либо видеть как люди обучаются. Курсы можно поискать тут t.me/spbcoachanel и тут t.me/BA_SA_Arch_edu
1. Создаёшь таблицу. 2. Выставляешь курсор на нужную ячейку. 3. Прожимаешь ctrl + shift + i. Либо используешь элемент управления 'Insert table' сверху в панели обработки текста.
@@eugeneqa8154 Скорее всего это вопрос версии конфлюенса или установленных плагинов. У меня у всех работодателей уже настроена эта возможность. Также, при установки нового конфлюенса с нуля в облаке эта возможность имеется. Здесь вам поможет алассиан-администратор или гугл.
Изменения формируются сперва в виде требований в meeting notes, далее переходят в jira task (таска может сразу появиться в JIRA от заказчика). В рамках работы аналитика над задачей, обновляется документация и передаётся в разработку. Документация должна отчасти показывать ход мысли разработки. Новые поля добавляются и окрашиваются зелёным цветом. Желательно добавить комментарий в описание, почему поле было добавлено. со временем (после обновления, например, когда очередная фича зашла или спустя n недель) зелёная закраска убирается. Удаляемые поля не уходят из документации, но зачёркиваются и закрашиваются серым, добавляет комментарий кто и почему убрал поле. Есть альтернативный путь с документацией напрямую в yaml.
@@systemsengineering круто, спасибо. Как раз сейчас с командой решаем, как вести изменения при доработках API. Пока выбираем между: 1) Добавление цветом. 2) Версионирование с помощью scroll plugin. Создание branch страницы и ссылка на неё в Jira или большое ТЗ в confluence. 3) Каждое изменение описывать на отдельной странице, потом переносить в общую документацию.
@@kudriashov Это проблема. В одной из компаний я пользовался в конфлюенс плагином для контроля версий, но он быстро перегружал страницу и начинались лаги и зависания. Надо для себя решить, как часто будет обновляться документация API. Если обновляться будет часто и много, то лучше использовать git + yaml, без документации в конфлюенсе. Тут важно учесть, что никому постороннему это API читать не нужно будет (git всё-таки должен быть закрыт). Соединение нескольких страниц - это реальная боль, так как изменения вносить долго, легко запутаться, перегружается иерархия страниц. Можно спеку API вести отдельным файлом и крепить к доке, раньше для этого использовали таблицы excel. Но кажется самое простое (и с другой стороны сложное, т.к. нужны навыки) - это вести API в yaml + документацию по начинке, без указания контракта. Т.е. получил запрос из метода GET /.../.../... (смотри YAML), дальше описываешь обработку этого запроса, в конце указываешь какие данные в какие поля улетают. Иначе придётся вести таблицу полей запросов как в конфе, так и в YAML. Другими словами весь контракт в ямле, история в гите, а как это всё работает внутри сервиса - в конфлюенсе. Только не надо дублировать контракт в конфе, иначе получится двойная работа и могут появиться расхождения. Но придётся учить как создавать YAML. Ну и есть другие протоколы передачи данных, для которых yaml не подходит.
Спасибо за видео! Вроде все очевидно, но чтобы самому дойти до таких выводов, нужно накопить негативный опыт) Буду пробоваться джуном после работы в сфере строительства. Так что да, полезно знать всё это ДО начала работы.
Спасибо за рассказ! Было интересно посмотреть, потому что документирую REST API в Confluence (тех.писатель). На 90% вручную, оставшиеся 10% - спасают придуманные со временем шаблоны. Описание для внешних читателей. Сносно, но много ручной работы и дисциплины уходит. =) Даем описание параметров (простые таблицы без вложенности) + примеры в cURL/JSON. На встраивание Swagger в Confluence не договорились с разработкой и безопасниками. Единственный момент "интерактивности" - написал от руки и выложил JSON-коллекции, чтобы целевой аудитории не нужно было копипастить примеры в Postman. Изначально использую "объемную" структуру с кучей перекрестных ссылок. Подумывал сделать one-page API reference (тем же page include), потому что вроде как разрабам это удобнее просматривать через CTRL+F. Но вот послушал про то, что "конф не откроет" большое описание - прям сомнения появились, надо ли.
Если аналитик/техпис сразу пишет yaml под разработку, то можно вставлять фрейм и не париться с таблицей. Если безопасники закрыли этот вариант, то стоит спросить их про возможность развернуть шаблон апи в отдельном сервисе на тестовой среде. Без возможности прокидывать запросы в боевую бд, только в тестовую среду с шаблонами ответов. Но тут два вопроса. Первый - про возможность в фрейм вставлять только один метод. Второй - доступ в конфу не так просто дать даже internal сервису. У нас не вышло.
