Проектирование бд и почему важен sql для системного аналитика

Разработка API: ключевые принципы и рекомендации

Разработка хорошего API требует особого внимания к деталям и соблюдения ключевых принципов программирования прикладных интерфейсов. Поэтому важно, чтобы у разработчиков были необходимые знания. Меня зовут Анастасия Иванова, я работаю в МТТ (входит в экосистему МТС) техническим писателем МТС Exolve.

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

Общие рекомендации

Вот ещё больше рекомендаций по созданию API. Может быть, вам также пригодится Google JSON Style Guide.

Советы по созданию удобного API

Существуют различия в номенклатуре и стилях. Точки доступа и входные/выходные параметры можно написать различными способами: camelcase, дефис, символ подчёркивания. При создании API стоит выбрать один стиль написания.

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

Версии

Довольно часто API‑интерфейсы меняются после первого выпуска. Разработчики добавляют новые функции в сервис, появляются новые методы и точки доступа. Также разработчики делают улучшения в уже существующих методах, которые пользователи могли использовать в своих проектах. Если вы знаете, что ваш API‑интерфейс будет меняться, стоит изначально использовать версии. Один из часто используемых способов — использовать латинскую букву V (v + номер версии) в точке доступа.

Обратите внимание, что вам стоит оповестить своих пользователей о переходе на новую версию. Также стоит какое‑то время поддерживать работу предыдущей версии API‑интерфейса, чтобы проекты ваших пользователей продолжали работать, пока они переходят на новую версию.

Используйте коды состояния HTTP

Ценной функцией, доступной в HTTP, является статус. Он возвращается в ответе сервера в зависимости от результата действия, отправленного в запросе. Есть несколько типов статуса: 200 OK (успешный запрос) и ошибка (код 400, 401, 500 и другие). Если запрос успешный, вашему API стоит отдавать 200 OK статус. Если нет, то стоит отдавать статус ошибки и пояснения, чтобы пользователь понял, что было не так в его запросе.

Используйте пагинацию и фильтрацию для удобства конечного пользователя

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

Используйте кеширование API, чтобы увеличить производительность

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

Таблица с примерами статусов HTTP

Список ссылок

• Google JSON Style Guide
• Документация по кодам ответа HTTP от Mozilla

### Использование кеша

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

### Пример кода на Python

Пример кода на Python с использованием библиотеки Flask‑Caching и Redis в качестве внешнего кеша:

```python
from flask import Flask
from flask_caching import Cache

app = Flask(__name__)
cache = Cache(app, config={CACHE_TYPE: redis})

@app.route(/api/data)
@cache.cached(timeout=60)
def get_data():
    # Check if data is in cache
    data = cache.get(data)
    if data is not None:
        return data
    else:
        # Make request to external API
        data = requests.get(https://api.example.com/data).json()
        cache.set(data, data, timeout=60)
        return data

Напишите понятную документацию

Написание хорошей документации имеет важное значение при разработке любого API, поэтому это один из ключевых компонентов нашего SMS API.

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

Ссылки на руководства по созданию API

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

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

Моделирование процессов

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

Что такое карта процесса?

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

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

## Карты и моделирование бизнес-процессов

По сути своей карты и есть модели бизнес-процессов, схематично которые можно выполнить на каком-то носителе, включая лист бумаги или доску. Но если мы говорим о создании цифровой объемной модели и ее автоматизации, то без специального программного обеспечения не обойтись. Наиболее удобным и востребованным цифровым инструментом для проектирования бизнес-процессов сегодня является SILA Union.

### Методы моделирования процессов

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

#### Схема модели бизнес-процесса в нотации BPMN

Нотация BPMN является наиболее часто используемой методологией отображения бизнес-процессов от начала до конца в виде блок—схемы. BPMN – ключевой инструмент управления бизнесом, так как последовательно и наглядно отображает операции и информационные потоки, необходимые для реализации процесса.

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

Основные графические элементы в языке моделирования BPMN – “Пулы или бассейны”, “Действия”, “Шлюзы/Развилки”, “События”, “Потоки”овалы для начальной и конечной точки, прямоугольники для задач/шагов, ромбы для точек принятия решений и стрелки для обозначения направления процесса.

#### Карта потока создания ценности (VSM)

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

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

#### Диаграмма “поставщик-вход-процесс-выход-клиент” (SIPOC)

## Диаграмма SIPOC - ключ к пониманию процессов

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

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

## Блок-схема

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

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

## Модели процессов верхнего уровня

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

## Подробные карты процесса

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

### Как наилучшим образом моделировать процессы

Универсального способа отображения бизнес-процесса не существует, поэтому выбирайте методологию, исходя из требуемого уровня детализации.

В некоторых случаях модели процессов могут дополнять друг друга - используйте методологию VSM, чтобы понять общую картину и ценность, предоставляемую клиентам; нотацию BPMN, если нужны функциональные блок-схемы и понимание того, откуда поступает и куда уходит информация; и диаграмму SIPOC для детального представления входных и выходных данных.

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

В специальном инструменте для моделирования и управления бизнес-процессами SILA Union вы можете описать процессы компании любым вышеперечисленным методом моделирования процессов - SILA Union поддерживает более 200 моделей и нотаций описания деятельности организации.

## Зачем бизнесу нужна карта процессов?

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

### Как создать модель процесса

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

Определите процесс

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

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

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

Сбор информации

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

Определите и упорядочьте необходимые действия

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

Определите последовательность шагов

Возьмите подготовленный список задач и расположите их в правильном порядке. Что должно произойти в первую очередь? Можно ли выполнять некоторые задачи одновременно? Какие задачи зависят от других? Когда процесс будет завершен? Некоторые задачи могут быть необходимы только при выполнении определенного условия – обязательно зафиксируйте эти моменты.

Визуализируйте процесс

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

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

Задокументируйте процесс

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

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

Адаптируйте карту процесса к меняющимся условиям

Компании и, следовательно, бизнес-процессы подвержены постоянным изменениям, вызванным как внутренними, так и внешними факторами. Поэтому может потребоваться время от времени пересматривать и обновлять карту процесса. Модельпроцесса всегда должна отображать текущее состояние “как есть”.

Советы при составлении карты процессов

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

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

Моделирование процесса с дальнейшими улучшениями с помощью SILA Union

Разработка карт процессов имеет много преимуществ, но у вас могут возникнуть вопросы: А что дальше? Как поделиться подготовленной информацией и взаимодействовать со всеми сотрудниками? Достаточно ли описать процессы, чтобы гарантировать реализацию по разработанным стандартам? Как извлечь данные из процесса?

По этой причине моделирование процессов подразумевает использование специального программного обеспечения для управления управления бизнес-процессами (BPM), такого как SILA Union.

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

На базе карт процессов в SILA Union вы можете анализировать и совершенствовать свои бизнес-процессы, используя встроенные инструменты анализа и оптимизации, а также отслеживать ключевые показатели эффективности, стандартизировать и автоматизировать бизнес-процессы.

9 сент. 2023 г. Время чтения: Около 6 мин.

Пайплайны в разработке

Применение пайплайнов помогает компаниям быстрее и качественнее разрабатывать программные продукты. Давайте поближе познакомимся с основными характеристиками и преимуществами пайплайнов для IT мира.

Пайплайн (от англ. pipeline — трубопровод) — это последовательность действий или процессов, которые выполняются для достижения заданной цели. Такой метод управления проектом состоит из этапов, на каждом из которых выполняется определенная задача или набор задач. Каждый этап имеет свои входные и выходные данные, условия запуска и завершения, зависимости от других этапов. Пайплайны бывают разными по сложности и длительности, в зависимости от типа и масштаба проекта, используемых технологий и инструментов, требований к качеству и безопасности продукта.

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

Основные характеристики

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

DevOps

DevOps — это методология разработки программного обеспечения, которая объединяет процессы разработки (Dev) и эксплуатации (Ops) в единую цепочку. Цель DevOps — обеспечить непрерывную поставку (Continuous Delivery) качественного и безопасного продукта с минимальными затратами времени и ресурсов.

Разработка ПО

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

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

Что может понадобиться для реализации пайплайнов при разработке ПО?

Веб-сайты и приложения

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

Gamedev

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

Пример пайплайна для Gamedev на Unity

Для того, чтобы показать, как выглядит пайплайн для Gamedev на практике, давайте рассмотрим пример одного из популярных игровых движков — Unity. Unity — это кроссплатформенный движок для разработки игр для разных устройств и платформ, таких как ПК, мобильные телефоны, консоли, VR и AR. Unity предоставляет разработчикам инструменты и ресурсы для создания игр, например: графический редактор, физический движок, анимационная система, звуковая система и скриптовый язык C#.

Инструменты и технологии:

Контроль выполнения

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

Преимущества перед традиционными методами разработки

Давайте сначала обозначим, что мы понимаем под традиционными методами обработки — старые и морально устаревшие методы (но, к сожалению, еще использующиеся), которые имеют общие черты:

Вместо этого пайплайн предлагает вам:

Берём в работу новую задачу или проект. Начинаем со сбора бизнес-требований. Затем переходим к проработке функциональных и нефункциональных требований. Потом архитектура системы и влияние требований на нее, БД, API, интеграции. И вот, в процессе разработки выясняется, что в требованиях опять что-то не учли. Что может быть хуже?

Может, коллеги! Когда через пол года вам же приходится возвращаться к задаче и вы понимаете, что требования к развитию системы по словам разработчиков нереализуемы. Или реализуемы, но они кривят лица: мы этого не ожидали, проще всё с нуля переделать, либо "костылями подопрем".

Меня, как начинающего системного аналитика, это выводило из себя. Как так?! Элементарная же задача! А потом мне показывают БД. И тут я всё понимаю. Да, действительно, пришло время делать выбор: дорого переделывать или "костыли" подойдут.

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

В этой статье:

"Костылями" подпираем или переделываем?

Главное отличие системного аналитика от других участников проекта заключается в его способности смотреть широко. Работая над конкретной задачей, аналитик видит не только её, но и весь проект в целом, как он функционирует сейчас и как будет развиваться в будущем.

1. Рассмотрим ситуацию с хранением ФИО в системе.

Изначально было решено хранить ФИО одной строкой.

Прошло время. Появилась необходимость интегрироваться с системами электронного документооборота (ЭДО), в которых по единому информционному протоколу это всегда три отдельных поля: имя, отчество и фамилия.

Кажется, что всё просто. Но нет.

Это простое изменение породило множество сложностей:

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

2. Еще один пример – думали, что у машины может быть только один владелец в автосервисе.

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

Структура БД меняется: для правильного поддержания процесса нужна связь "многие ко многим". И в одну задачу это изменение не сделать.

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

Простые изменения и требования? Да, если подумать логически, на верхнем уровне. Но из-за того, что "под капотом" системы огромный мир данных и механизмов по их хранению, получению и обработке, то иногда мы попадаем на серьезные работы по развитию.

Так и получается, что мы с разработчиками садимся обсуждать: проще сделать "костыли" или лучше переделать с нуля сейчас, чтобы через год опять не пожалеть о принятом решении.

Важно учиться искать баланс и на старте работ найти грань: не допустить овер-инжиниринга, и при этом сделать модель БД гибкой. Это нужно постигать.

База данных – фундамент системы

БД — это фундамент системы, который влияет на реализацию всех требований. Все бизнес-процессы и функции сводятся к одному – обработке данных.

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

Пример про медицинскую систему

Рассмотрим медицинскую информационную систему для частной поликлиники.

Мы, как аналитики, должны продумать все сценарии, связанные с записью пациента к врачу.

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

В результате прочтения требований к медицинской системе, получаю список сущностей и свойств – основа для логической модели БД.

Прежде чем смотреть что получилось, попробуйте сами быстро выделить список сущностей и свойств. Совпадём?

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

Проверка требований на полноту и непротиворечивость с помощью проектирования БД

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

Системный аналитик должен смотреть на систему в трех измерениях: – как работает сейчас (AS IS), – что просят сделать (текущие требования на разработку), – во что это может перерасти в будущем (потенциальное развитие).Это поможет сделать разработку качественной.

Екатерина Ананьева 🙂

Что получилось после чтения требований? Логическая модель базы данных, связанной с задачей. На её основе ставлю задачи на разработчиков Backend, а также разработчикам мобильных и десктоп приложений, когда нужно сделать локальную базу данных, например, на SQLite.

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

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

Этап проектирования БД важен для системных и бизнес-аналитиков. Не игнорируйте его.