Клиент-серверное взаимодействие

Давайте сегодня углубимся в технические темы и поговорим про фундаментальное понятие для системного аналитика – клиент-серверное взаимодействие.

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

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

Клиент-сервер – это подход к построению архитектуры. Подход предполагает наличие системы управления (сервер) и внешней оболочки, интерфейса, позволяющего взаимодействовать с этой системой (клиент). Еще иногда можно услышать другие названия: Front-end и Back-end.

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

Существуют разные подходы к реализации клиент-серверного взаимодействия:

1. кто-то закладывает все операции и сложную логику на клиент, а сервер используют, например, только для хранения данных. Этот подход называется «толстый клиент».

2. кто-то наоборот переносит логику на сервер настолько, насколько это возможно, а на клиенте оставляют только отображение данных и минимальные вычисления – это называется «тонкий клиент».

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

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

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

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

1. «Путь аналитика: практическое руководство IT-специалиста» - Андрей Перерва

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

2. «Разработка требований к программному обеспечению» - Карл Виггерс

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

3. «Джедайские техники» - Максим Дорофеев

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

4. «Искусство системного мышления» - Джозеф О’Коннор

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

5. «Цель. Процесс непрерывного улучшения» - Кокс Голдратт

Книга описывает методы анализа бизнес-процессов, оптимизации производственных систем и поиска узких мест в операционных цепочках. Эти принципы могут быть полезны для аналитиков, стремящихся оптимизировать процессы и улучшить результативность организации.

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

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

Ссылка на регистрацию

Уже через час состоится наш онлайн-эфир с Полиной и Алексеем!

Тема встречи: "Чего работодатель ждет от соискателя на позицию джуниор".

Время: 19:00 (мск)

Ссылка на эфир: Присоединиться к эфиру
До встречи на эфире!

Скиллсет системного аналитика

Спасибо всем, кто присоединился к нашему вчерашнему онлайн-мероприятию! Мы рады видеть ваш активный интерес и участие.

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

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

Не забудьте присоединиться к нам на следующих эфирах, мы скоро обновим расписание!

📌 Оставайтесь с нами, впереди много интересного!

Отображаем целевой сценарий в виде диаграммы

Продолжаем разбирать задачи со стажировок! Вот условия:

Есть интернет-магазин со своим складом, курьерами, логистикой. Целевой сценарий взаимодействия магазина с клиентом начинается с входа на сайт и заканчивается получением клиентом оплаченного товара. Отобрази целевой сценарий в виде диаграммы (желательно в нотации UML SD).

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

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

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

Если не знакомы с нотацией UML и конкретно с диаграммой последовательности (SD, sequence diagram), посмотрите инструкцию на сайте plantUML.

Лучше сразу разобраться с синтаксисом plantUML и делать диаграммы прямо на сайте.

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

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

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

• Еще будет бонусом использование стандартных фрагментов типа alt, opt и т.п. Это вовсе необязательно, но помогает оптимизировать диаграмму и в некоторых случаях правильно изобразить сценарий.

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

P.S. Почему задание лучше делать в нотации UML SD:

1. она более предназначена для моделирования технической реализации сценариев, чем, например, BPMN (который предназначен для моделирования бизнес-процессов). И тут мы можем наглядно увидеть, насколько человек технически глубоко понимает сценарий, который он смоделировал;
2. это наиболее распространенный формат моделирования когда проектируешь реализацию сценариев. То есть любой аналитик так или иначе сталкивается с UML SD в работе, и нужно быть к этому готовым.

Роль аналитика в запуске проекта

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

Во-первых, надо разобраться в имеющемся контексте и артефактах. Согласованный с заказчиком список задач, которые будем делать в рамках проекта, должен точно соответствовать ожиданиям, описанным в техническом задании (ТЗ) и представленным в дизайне (уже готовом или пока только в концепции). Если возникают какие-то расхождения, важно сразу сообщить об этом менеджеру.

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

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

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

Ну и бонусом, в-пятых, надо приглядывать за другими, как минимум, в части:

1. ТЗ должно быть оценено разработчиками. За оценку работы должны быть ответственны те, кто выполняет эту работу. Когда команда вписывается в реализацию проекта, оцененного, например, менеджером, зачастую это либо плохо заканчивается, либо не начинается;
2. Процессы проекта должны быть выстроены так, чтобы команда функционировала практически автономно. Обратная полярность автономии – микроменджмент, это когда менеджер или тимлид делает работу за других (проектирует, разрабатывает, тестирует). Отсутствие автономии – серьезный риск для проекта, поэтому на это нельзя закрывать глаза;
3. Нельзя недооценивать RoadMap проекта. Команда, которая не знает куда идет, это отряд самураев, у которых есть только путь, причем обычно не очень эффективный.

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

Почему в обучении так важна практика и реальные задачи?

Давайте вспомним, сколько классных книжек по самулучшайзингу вы прочитали и сколько реально повлияли на вашу жизнь?
Можно предположить, что единицы. И скорее всего успешны были те авторы, что предлагали вам сразу же внедрять прочитанное в свою жизнь. Хочешь рано вставать и магию утра? Давай завтра проснемся хотя бы на 10 минут раньше. А дальше и остальное подтянется.

Теория, закрепленная на реальных задачах, помогает не просто лучше усвоить материал, а конвертировать ее в реальные навыки. Это мы очень быстро поняли на первых программах стажировки. Если стажеру, с определенной подготовкой, сразу предложить задачу с реального проекта по теме, то когда он увидит ее в следующий раз, будет меньше страхов и больше толку. Именно этот принцип мы тиражируем уже больше 10 лет.

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

Например, на старте для стажеров мы даем памятку и делаем адаптационный лист, где даем на изучение теорию по архитектурным паттернам (монолит/микросервисы, тонкий и толстый клиент), клиент-серверному взаимодействую (с упором на архитектурный стиль REST), повторяем основы по сетевому взаимодействию (модель OSI) и базам данных, охватывая как реляционные, так и нереляционные.

Для закрепления теории стажеры сразу приступают к практической части, где:

• собирают требования с помощью интервью и анкетирования, анализируют текущие процессы;
• проектируют новую систему, охватывая полученные знания по архитектуре (часто это HLD или диаграмма компонентов);
• учатся создавать диаграммы вариантов использования, активностей и последовательностей в UML;
• проводят ревью UI/UX дизайна, используя гайдлайны;
• проектируют и тестируют API;
• моделируют логическую модель реляционной БД с использованием ERD диаграммы.

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

Роль аналитика в сборе требований. Часть 1

Давайте разберем, как собирать требования для проекта и избежать ошибок на ранних этапах.

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

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

Что обсудим?

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

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

Как погружаться в тему:

• Ресерч. Читайте книги, статьи, блоги, форумы. Изучите существующие процессы и подходы к автоматизации в данной области, а также заказчика и его конкурентов.
• Общение с экспертами. Найдите сообщества, Telegram- или YouTube-каналы, блоги, подкасты. Лучше всего — связаться напрямую с экспертами и задать им вопросы.
Результаты исследования делитесь с командой. Не ждите, что вам кто-то принесет всю информацию на блюдечке. Проактивность всегда лучше бездействия!

2. Работа с лицами, принимающими решения (ЛПР)

• Определите, кто входит в группу ЛПР. Это можно узнать у аккаунт-менеджера или самостоятельно.
• Проведите интервью с ключевыми ЛПР. Узнайте их цели и ожидания от продукта, а также степень их влияния.
Эта информация поможет вам правильно выстраивать коммуникацию с заказчиком и принимать решения в спорных ситуациях.

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

На Симуляторе кончаются скидки

Наверное вы знаете, что наш канал называется не просто так, и что все наши принципы образования мы воплотили не только в стажировках, но и в программе Симулятора системного анализа

Симулятор системного анализа - это по сути онлайн-программа нашей стажировки, полностью симулирующая работу системного аналитика. Если коротко, то пройдя программу вы получите все то, что и на работе в реальной компании за полгода. Только с подсказками, артефактами и бережным сопровождением.

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

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

Заходите, выбирайте тариф и начинайте учиться.

Будем рады видеть вас среди наших студентов!

Роль аналитика в сборе требований. Часть 2

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

3. Рекомендации по проведении интервью

1. Планируйте интервью заранее. Подумайте какие у вас есть вопросы и запишите их, это позволит вам более полно собрать требования с заказчика, не забыть важных вещей.
2. В созвонах с заказчиком важно придерживаться техники активного слушания. Внимательно слушайте, задавайте вопросы, уточняйте сказанное, это даст вам дополнительные детали и пояснения.
3. Помните про неявные требования и ожидания, которые заказчик может упустить.
4. Не делайте предположений и не ограничивайте восприятие только тем, что говорит заказчик. Не воспринимайте услышанное за чистую монету, т.к. любые утверждения (в том числе ваши) должны быть поставлены под сомнение и проверены фактами.
5. Когда заказчик озвучивает «требования», разделяйте их на реально необходимые для продукта функции и на пожелания. Первое – в приоритете, второе – под вопросом.
6. Старайтесь «на лету» декомпозировать требования заказчика, это позволит вам сразу увидеть и подсветить риски, уточнения и т.п.
7. Все требования заказчика должны проходить через принцип почему зачем. Этот вопрос должен звучать при каждой сессии сбора требований. Необходимо его задавать до тех пор, пока вы не дойдете до корневой проблемы, которую хочет решить заказчик.
8. Фиксируйте договоренности. Каждый диалог (в жизни, на созвоне, в чате) с заказчиком и командой, который привел к каким-либо договоренностям, должен быть зафиксирован в общем пространстве.

4. Артефакты

На старте проекта, на основе имеющихся вводных артефактов (ТЗ, FL, договор и т.п.), а также на основе первых проведенных с заказчиком интервью, составьте следующие артефакты:

- Бизнес-требования. Помним, что БТ могут быть описаны как Job stories, User Stories, Use cases или в свободном формате, но не должны при этом опускаться до уровня клиент-серверного взаимодействия.
- Контекстную диаграмму. Это позволит любому члену команды быстро понять границы системы.
- Концептуальную модель данных. Это позволит любому члену команды предварительно понять с чем предстоит иметь дело.
- HLD диаграмму, если это не было сделано во время предпроектного анализа.
- Диаграмму состояний, если в проекте есть ключевые сущности со своей статусной моделью;
- CRUD матрицу по ключевым сущностям и ролям системы.

И также ответьте на вопросы:
1. Все ли операции над всеми объектами учтены?
2. Все ли требования учтены?
3. Установлены ли все связи с экранами, отчетами, внешними системами?
4. Все проверки, исключения и альтернативы описаны?

Основной инструментарий системного аналитика

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

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

• Swagger (сейчас OpenAPI)/Stoplight. Эти инструменты позволяют управлять контрактами API, предоставляя понятный интерфейс для их чтения и редактирования. В начале можно создать простые спецификации, а потом перейти к сложным. С помощью Stoplight также можно поднять собственный мок-сервер, в который можно отправлять запросы API и получать моковые данные в ответ.

• PlantUML - текстовый редактор, создающий по определенным командам диаграммы автоматически. Есть документация на русском языке. Чуть сложнее, чем визуальные редакторы. Но когда нужно будет править большие диаграммы изменением всего одной строчки, вы оцените инструмент по достоинству.

• BPMN (Business Process Model and Notation) - помогает моделировать бизнес-процессы, визуализируя их и делая их более понятными для всех участников.

• draw.io (diagrams.net) - это универсальный инструмент для моделирования, который позволяет создавать различные виды диаграмм, включая UML, BPMN и блок-схемы.

• Postman, при помощи него можно отправлять запросы, проверять ответы и автоматизировать тестирование API.

• Git - это система контроля версий, которая позволяет отслеживать изменения в коде и документации.

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

Напоминаем, что эти инструменты вы также можете освоить в нашем Симуляторе системного анализа.