📚 Наш курс "Системный анализ для всех"

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

• Основы системного анализа. Изучаем базовые понятия и инструменты.

• Углубленные техники. Погружаемся в сложные кейсы и реальные проекты.

• Интеграция систем и API. Осваиваем практические аспекты интеграции.

• Управление проектами. Учимся методам Agile, Scrum и Kanban.

Наш курс разработан так, чтобы подготовить вас к успешной карьере в IT.

👉 Подробнее о курсе

#SCHOOL

🌟 Почему наш курс системного анализа №1

🎥 Живые лекции в ZOOM. Наши занятия проходят в режиме реального времени, что позволяет студентам активно взаимодействовать с преподавателями и получать ответы на все вопросы.

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

🧑‍🏫 Опытные преподаватели. Наши курсы ведут исключительно практикующие специалисты уровня middle+ / senior и системные архитекторы, что обеспечивает высокое качество обучения.

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

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

👉 Посмотреть курс

#SCHOOL

💼 Зарплата системного аналитика
Зарплата системного аналитика зависит от уровня опыта и квалификации:

- Junior: Начинающие специалисты получают от 90 000 рублей в месяц.
- Middle: Аналитики среднего уровня зарабатывают около 200 000 рублей в месяц.
- Senior: Опытные аналитики могут получать от 300 000 до 450 000 рублей в месяц.

💰 В крупных IT-компаниях, таких как Тинькофф, Яндекс и Сбер, зарплата может достигать 450 000 рублей в месяц.

Системные аналитики также могут рассчитывать на дополнительные бонусы и льготы, такие как ДМС, гибкий график работы, возможность удаленной работы и корпоративное обучение.

👉 Подробнее узнать о зарплатах можно на GetMatch и Habr Career.

#MONEY

📊 Бизнес-аналитик vs Системный аналитик. Кто есть кто?

🔍 Объект исследования
• Бизнес-аналитик (БА) анализирует бизнес-процессы, потребности пользователей и рыночные условия.
• Системный аналитик (СА) фокусируется на информационных системах и их соответствии бизнес-задачам.

🤝 Взаимодействие
• БА общается с бизнес-пользователями, менеджерами и другими заинтересованными сторонами для определения требований.
• СА взаимодействует с БА, командой разработки, архитекторами.

🛠 Задачи
• БА определяет и формулирует бизнес-требования, разрабатывает стратегии оптимизации бизнес-процессов.
• СА работает над проектированием архитектуры, интеграций, созданием и поддержкой информационных систем.

📘 Методологии
• БА использует BABOK, BPMN.
• СА использует UML и методологии для разработчиков.

👁 Фокус
• БА ориентирован на бизнес-цели и выгоды для организации.
• СА сконцентрирован на разработке информационных систем.

🧠 Навыки
• БА анализ бизнес-процессов, управление требованиями, коммуникация.
• СА глубокие знания в IT, базах данных, системном проектировании.

📄 Результаты работы
• БА создает документацию бизнес-требований, отчеты, стратегии развития.
• СА разрабатывает технические спецификации, диаграммы потоков данных, архитектуру информационных систем.

🌀 Уровень абстракции
• БА высокий уровень абстракции, сосредоточен на бизнес-процессах.
• СА низкий уровень абстракции, детали функциональности и технические аспекты.

📋 Роли и ответственности
• БА формулирует стратегии бизнес-развития, определяет цели проекта.
• СА создает архитектуру информационной системы, управляет техническими требованиями.

🎯 Цель работы
• БА оптимизация бизнес-процессов, обеспечение эффективности и конкурентоспособности организации.
• СА создание и поддержка информационных систем, удовлетворяющих потребности бизнес-пользователей.

🚀 Карьера
• БА вырастает до менеджера проектов, продакт-менеджера, деливери-менеджера.
• СА вырастает до системного архитектора, технического продукт-оунера, технического проджект-менеджера.

#REQUIREMENTS

Всё о REST API

🔎 Что такое REST API?

REST (Representational State Transfer) API — это архитектурный стиль для взаимодействия между компонентами веб-сервисов. Если проще, это способ, которым программы "общаются" друг с другом через интернет.

⚙️ Как это работает?

REST API использует HTTP запросы для выполнения операций. Например, чтобы получить данные, отправляется запрос GET. Чтобы создать новый ресурс, используется запрос POST. Таким образом, разработчики могут легко интегрировать разные системы.

🌟 Почему это круто?

• Простота и гибкость. REST использует стандартные HTTP методы (GET, POST, PUT, DELETE), что делает его понятным даже для начинающих.
• Масштабируемость. Подходит для больших систем, позволяя легко добавлять новые функции.
• Кроссплатформенность. Работает с любыми языками программирования и платформами.

📊 Пример из жизни

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

#ARCHITECTURE

🌐 Основные различия GET и POST

🔍 Что такое GET и POST?

GET и POST — это методы HTTP-запросов, которые помогают вашему браузеру и серверу общаться между собой. У каждого метода есть свои особенности и области применения.

📬 GET запрос

• Передача данных в URL строке
• Низкая безопасность, данные передаются в открытом виде
• Кеширование браузером, что может привести к утечке данных
• Можно добавлять в закладки браузера
• Используется для получения данных от сервера
• Более высокая скорость, данные передаются в URL строке
• Подходит только для простых данных (строки, цифры)
• Не подходит для сложных данных
• Легко отслеживается и логируется сервером
• Сохраняется в истории браузера
• Идемпотентный

📨 POST запрос

• Передача данных в теле запроса
• Нет ограничений по объему данных (может быть ограничено сервером)
• Более высокая безопасность, данные передаются скрыто
• Не кешируется браузером
• Нельзя сохранять в закладки
• Используется для отправки данных на сервер
• Может быть медленнее, данные передаются в теле запроса
• Подходит для любых типов данных (файлы, изображения и т.д.)
• Подходит для сложных данных
• Менее прозрачен и сложнее отследить
• Не сохраняется в истории браузера
• Неидемпотентный

💡 Когда использовать?

• Используйте GET для получения данных
• Используйте POST для отправки данных, особенно если это конфиденциальная информация или большие объемы данных

#INTEGRATION

🔍 SOA vs MSA : Ключевые Отличия

🔹 Определение
• SOA: Модульный подход к разработке ПО, основанный на стандартизированных протоколах для удаленного использования слабо связанных компонентов (сервисов) с стандартизированными интерфейсами.
• MSA (Микросервисы): Вариант SOA, фокусирующийся на взаимодействии небольших, легко изменяемых модулей, популярный с середины 2010-х благодаря гибкой разработке и DevOps.

🔹 Размер сервисов
• SOA: Крупные сервисы, включающие несколько бизнес-функций.
• MSA: Мелкие сервисы, реализующие одну конкретную функцию.

🔹 Коммуникация
• SOA: Использует сложные протоколы (SOAP, WS-*).
• MSA: Легковесные протоколы (REST, gRPC).

🔹 Управление состоянием
• SOA: Может использовать состояние между вызовами.
• MSA: Предпочитают безсостояние (stateless).

🔹 Использование сервисов
• SOA: Ориентирован на повторное использование служб.
• MSA: Повторное использование может создать новый сервис.

🔹 Управление версиями
• SOA: Сложное управление версиями сервисов.
• MSA: Легче управлять версиями.

🔹 Разработка и развертывание
• SOA: Требует сложной инфраструктуры и процессов.
• MSA: Частые и независимые развертывания.

🔹 Технологический стек
• SOA: Единый стек для всех сервисов.
• MSA: Разные технологии для каждого сервиса.

🔹 Мониторинг и логирование
• SOA: Централизованный мониторинг, но сложный.
• MSA: Требует распределённого мониторинга.

🔹 Управление данными
• SOA: Общая база данных.
• MSA: Собственная база данных для каждого сервиса.

🔹 Безопасность
• SOA: Безопасность на уровне сервиса.
• MSA: Детализированный подход к безопасности.

🔹 Тестирование
• SOA: Сложное тестирование.
• MSA: Легче тестировать.

🔹 Сложность
• SOA: Более сложная из-за множества стандартов.
• MSA: Проще для понимания и реализации.

🔹 Координация команд
• SOA: Требует тесной координации.
• MSA: Независимая работа команд.

🔹 Производительность
• SOA: Задержки из-за сложных взаимодействий.
• MSA: Высокая производительность.

🔹 Подход к масштабированию
• SOA: Централизованное масштабирование.
• MSA: Независимое масштабирование сервисов.

🔹 Требования к инфраструктуре
• SOA: Требует мощной инфраструктуры.
• MSA: Облачные решения и контейнеризация.

🔹 Обновления и поддержка
• SOA: Обновления затрагивают многие компоненты.
• MSA: Изолированные обновления для каждого сервиса.

🔹 Подход к интеграции
• SOA: Интеграция через ESB.
• MSA: Интеграция через API и прямые вызовы.

🔹 Фокус на бизнес-логике
• SOA: Интеграция бизнес-процессов.
• MSA: Разработка отдельных бизнес-функций.

#ARCHITECTURE

📝 Почему системному аналитику важно знать требования к ПО?

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

🔄 Интерпретация: Системный аналитик должен уметь правильно интерпретировать требования заказчика и переводить их на язык разработчиков, способствуя эффективной коммуникации между всеми участниками проекта.

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

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

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

🔧 Оптимизация разработки: Знание требований способствует оптимизации процессов разработки и снижению вероятности ошибок, повышая качество конечного продукта и сокращая затраты на исправление дефектов.

🤝 Взаимодействие с бизнес-аналитиком: Знание требований помогает системному аналитику эффективно взаимодействовать с бизнес-аналитиком, что важно для согласования бизнес-целей и технических возможностей.

#REQUIREMENTS

Функции корпоративной сервисной шины (ESB)

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

🔄 Преобразование данных
Сервисная шина позволяет преобразовывать данные из одного формата в другой, обеспечивая согласованность данных между различными системами.

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

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

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

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

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

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

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

#BROKER

🌐 Мифы о длине запросов: GET vs POST

На просторах интернета часто встречается утверждение, что длина GET-запроса ограничена 2048 символами, в то время как POST-запросы могут передавать данные без каких-либо ограничений. Но так ли это на самом деле? 🤔

📜 Спецификация RFC 2616, "Протокол передачи гипертекстов — HTTP/1.1", не устанавливает строгих требований к длине URL-адреса. Дело в том, что ограничение в 2048 символов скорее связано с особенностями браузера Internet Explorer, который имеет именно такую максимальную длину пути.

🔍 В GET-запросах данные передаются в URL, и именно поэтому мы сталкиваемся с этими лимитами. А вот в POST-запросах информация отправляется в теле запроса, что позволяет передавать значительно больше данных.

💻 Интересный факт: браузер Firefox может обрабатывать URL длиной до 10 000 символов- как пишут, что проверено! А так Firefox, Safari и Opera вообще не устанавливают жестких ограничений.

🎯 Однако, если вам нужно передать большие объемы данных, всегда лучше использовать метод POST для надежности и удобства.

📚Источник данного исследования: GitHub

#INTEGRATION

📚Давайте напомним вам список категорий нефункциональных требований по BABOK⬇️⬇️⬇️

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

🌳 Совместимость
Степень успешности взаимодействия решения с другими компонентами своего окружения. Например, взаимодействие одного процесса с другим.

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

🥀 Ремонтопригодность
Легкость изменения решения или компонента для исправления ошибок, улучшения производительности или других атрибутов, либо для адаптации к изменениям окружения.

🍁 Эффективность работы
Способность решения или компонента выполнять свои целевые функции с минимальным потреблением ресурсов. Может определяться исходя из контекста или периода, например, пиковое, среднее и минимальное использование.

🌵 Переносимость
Легкость переноса решения или компонента из одной среды в другую.

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

🌿 Масштабируемость
Способность решения расти или развиваться, чтобы справиться с растущими объемами работы.

🌸 Безопасность
Аспекты решения, защищающие содержимое или компоненты решения от случайного или злонамеренного доступа, использования, разрушения или раскрытия.

🌼 Удобство использования
Легкость, с которой пользователь может научиться использовать решение.

🌻 Сертификация
Ограничения решения, которые необходимо удовлетворить для соответствия стандартам или отраслевым соглашениям.

🌹 Соответствие
Нормативные, финансовые или правовые ограничения, которые могут варьироваться в зависимости от контекста или юрисдикции.

🪴 Локализация
Требования, касающиеся местных языков, законов, валют, культур, правописания и других характеристик пользователей, требующих внимания к контексту.

🪻 Соглашения об уровне обслуживания (SLA)
Ограничения обслуживаемой решением организации, официально утвержденные как поставщиком, так и пользователем решения.

🌻 Расширяемость
Способность решения включать новую функциональность.

✨ Не пропусти! Далее будем публиковать примеры каждого требования.

#REQUIREMENTS

⚠️ Для удобства и навигации постов в канале мы публикуем темы с тегами:

🏗 Архитектура ПО #ARCHITECTURE
Темы по шаблонам и типам архитектуры

🔗 Интеграция #INTEGRATION
Темы по описанию типов интеграций, протоколов, DevOps

📐 UML #UML
Темы по UML диаграммам, их применению

📊 BPMN #BPMN
Темы по BPMN диаграммам, их применению

🗄 Базы данных #DBMS
Темы, охватывающие проектирование баз данных, SQL и NoSQL

🛡 Кибербезопасность #SECURITY
Темы по сбору требований по информационной безопасности ИТ-систем

🛠 Проектирование ИТ-систем #SYSTEMDESIGN
Темы и кейсы по проектированию информационных систем

📜 Требования #REQUIREMENTS
Темы, которые охватывают типы требований, техники, стандарты

🔍 Тестирование #TESTING
Темы по тестированию ПО, роль аналитика в тестировании

🎓 Подготовка к собеседованию #INTERVIEW
Разбор вопросов и задач, как проходит собеседование

💼 Интеграционная шина и брокеры сообщений #BROKER
Темы по интеграционной шине и брокерам сообщений

📚 Прочее #OTHER
Все темы технические темы, что не вошли в предыдущие разделы

Напоминаем основные UML диаграммы и их назначение

📊 Диаграмма компонентов (Component Diagram) описывает иерархию компонентов системы.

🏗 Диаграмма развертывания или размещения (Deployment Diagram) описывает физическую архитектуру системы.

🏛 Диаграмма классов (Class Diagram) описывает статическую структуру классов системы и связи между ними.

🔗 Диаграмма объектов (Object Diagram) описывает связи между объектами, являясь частным случаем диаграммы классов.

🧩 Диаграмма композитной/составной структуры (Composite Structure Diagram) демонстрирует внутреннюю структуру классов и взаимодействие элементов внутренней структуры класса.

🛍 Диаграмма пакетов (Package Diagram) структурирует содержимое системы, отображая пакеты и отношения между ними.

🎨 Диаграмма профилей (Profile Diagram) описывает пользовательские стереотипы и ограничения, применяемые к моделям.

🎭 Диаграмма прецедентов (Use Case Diagram) описывает набор функциональности, доступной акторам (внешним для системы сущностям, таким как пользователи).

⚙️ Диаграмма деятельности (Activity Diagram) описывает рабочий процесс внутри каждого прецедента.

🔄 Диаграмма состояний (State Machine Diagram) описывает состояния, в которых может находиться объект, и правила перехода между ними.

📈 Диаграмма последовательности (Sequence Diagram) описывает логику взаимодействия и обмена данными между объектами в рамках прецедента в хронологическом порядке.

💬 Диаграмма коммуникации (Communication Diagram) описывает логику взаимодействия и обмена данными между объектами, не раскрывая хронологического порядка.

⏱ Временная диаграмма (Timing Diagram) показывает, как объекты ведут себя на временной шкале, не отображая взаимосвязей между объектами.

📝 Далее будем публиковать примеры, описания и разбор каждой диаграммы. Следите за обновлениями!

#UML

📚 Атрибуты качества по Карлу Вигерсу

Атрибуты качества — это вид нефункциональных требований, которые описывают характеристики сервиса или производительность продукта.

🔍 Как они классифицируются?
Один из способов классификации атрибутов качества основан на разделении на внешние и внутренние характеристики.

🌐 Внешние характеристики важны для пользователей и проявляются в процессе использования продукта.

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

⏳ Скоро мы опубликуем список внешних и внутренних атрибутов качества с их описанием и примерами. Не пропустите!

#REQUIREMENTS