Оглавление

Роль системного аналитика...............................................................................................2

Нормальные формы БД........................................................................................................3
ESB..........................................................................................................................................4
Плюсы и минусы сервисной шины данных..........................................................................6
Сравнение ESB-систем | Ключевые отличия от брокеров сообщений | kt.team.............6
Интеграция систем без разработки модулей на примере Talend | Enterprise Service Bus
| kt.team................................................................................................................................7
Agile / Waterfall.....................................................................................................................8
Waterfall или Agile: как выбрать методологию управления проектом?.......................12
Краткий ликбез по Waterfall..............................................................................................12
Семейство Agile-методологий: в чем главная особенность..........................................13
Преимущества и недостатки Waterfall и гибких методологий....................................15
Сравнение Scrum и Kanban..................................................................................................17
Различия REST и SOAP..........................................................................................................19
REST ограничения:...............................................................................................................20
1. Приведение архитектуры к модели клиент-сервер................................................................................20
2. Отсутствие состояния...................................................................................................................................20
3. Кэширование.................................................................................................................................................21
4. Единообразие интерфейса..........................................................................................................................21
5. Слои................................................................................................................................................................21
6. Код по требованию (необязательное ограничение)................................................................................21

Различия микросервиса и монолита.................................................................................22

сравнения между Microservice и Monolithic.......................................................................24
"Микросервисная архитектура теория и практика" - Иван Быков (Backend)..............26
очереди сообщений в микросервисной архитектуре......................................................30
Способы интеграции систем.............................................................................................31
Протоколы..........................................................................................................................32
Header-ы http.....................................................................................................................................................33

Методы HTTP запроса (Глаголы).......................................................................................35

методы авторизации........................................................................................................39
Аутентификация на основе сессий (каждый раз проверяется session id)...................................41
Аутентификация на основе токенов (не хранятся на сервере, это удобно)................................41
Беспарольная аутентификация (если забыл пароль – не надо его восстанавливать)................42
Единая точка входа (Single Sign On, SSO).......................................................................................42
Двухфакторная аутентификация (2FA)..........................................................................................42
Типы баз данных.................................................................................................................43
1
 Виды нереляционных баз данных................................................................................................43
Ключ-значение..................................................................................................................................................43
Документоориентированные СУБД...............................................................................................................43
Колоночные.......................................................................................................................................................44
Графовые...........................................................................................................................................................45

Виды требований к ПО.......................................................................................................46

Функциональные требования..........................................................................................................................46
Нефункциональные требования......................................................................................................................46
Бизнес vs Функциональные требования.......................................................................................47
Структура технического задания....................................................................................48
Типы диаграмм...................................................................................................................49

2
Роль системного аналитика
Разработка проектов (мобильные приложения iOS, Android) от стадии идеи до запуска.
- Исследование рынка, анализ прямых и косвенных конкурентов, сбор требований к
продукту, проведение интервью с пользователями.
- Создание прототипов (InVision, Marvel), переработка интерфейса мобильных
приложений (Figma, Sketch).
- Проектирование и тестирование API (Postman, SoapUI, Swagger, Charles),
проектирование базы данных (Postgre, MS SQL Server), взаимодействие с командой
разработчиков и дизайнеров. Описание требований в Jira для команды разработки.
- Интеграция со сторонними сервисами через REST API.
Планирование времени по задачам
Тестирование готового продукта

Госкорпорация Росатом
Внедрение ERP-системы.
Описание требований.
Написание ТЗ.
Проектирование структуры БД.

ОАО "Сбербанк России"

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

Что делает системный аналитик:

 собирает и анализирует требования исходных программ, проводит интервью с

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

3
Нормальные формы БД

4
ESB

5
6
7
Плюсы и минусы сервисной шины
данных I Enterprise service bus (ESB) I kt.team
https://www.youtube.com/watch?v=mBC00xcYrFw

Интеграция напрямую – при большом количестве систем и отсутствии логирования очень

сложно быстро обнаружить проблемы (поломался канал связи, пришли обновления, )
Если систем мало и они коробочные и мы знаем что их больше не будет – то есть смысл
делать интеграцию напрямую.
Вся очередь сообщений, правила логирования, правила конвертации, т.е. вся логика – в
ESB.
Минусы ESB: это отдельная система, за ней надо следить. Она требовательна к ресурсам.
ESB: Talend, Rabbit, Kafka, RedHat Fuse

различия Active mq и kafka

https://www.youtube.com/watch?v=GsZ3ihu7nlc
kafka – гарантирует доставку сообщений в правильном порядке
Active mq - гарантирует доставку сообщений, но не гарантирует правильный порядок

https://www.youtube.com/watch?v=UXlVXZ9walw

Сравнение ESB-систем | Ключевые

отличия от брокеров сообщений | kt.team
ESB = брокер сообщений + студия (джобы) + логирование + мониторинг + хостинг
ESB: Talend Mule WSO2 Fuse
брокер сообщений: Rabbit Kafka

8
Интеграция систем без разработки
модулей на примере Talend | Enterprise
Service Bus | kt.team
https://www.youtube.com/watch?v=BooC1bf1SS8

минусы интеграции напрямую:

разработка => поддержка
велосипед (уже было решено)
нет систем контроля (самостоятельно придумываем логирование и мониторинг)
cicd (хостинг)

публикация в шину – лучше чем запросы от ESB к системам (нет лишних запросов)
ESB может сама что-то делать (в отличие от брокера сообщений)

9
Agile / Waterfall
https://vc.ru/flood/42084-agile-ili-waterfall-sravnenie-metodologiy-veb-razrabotki

Способ разработки выбирается исходя из задач бизнеса, объема работ, времени и

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

Waterfall – это четко запланированный и детализированный подход, где исполнитель

придерживается плану. Agile – прямая противоположность, которая предполагает
гибкость разработки с возможностью внесения изменений на каждом этапе проекта.

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

Agile

Agile – система, основанная на принципе «гибкого» управления проектами. Сюда относят

методики Scrum, FDD, Kanban, Экстремальное программирование (XP), Lean и т.д.
Ключевая особенность такого подхода - создание проекта в несколько циклов (итераций),
в конце каждого виден конкретный результат, который позволяет понять, по какому пути
двигаться дальше.

Гибкие методологии строятся на принципе итераций. Создание нового продукта делится

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

Главные принципы Agile:

 Эффективное взаимодействие в команде важнее процессов и технологий. Цель –

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

Наиболее популярные методики Agile:

Scrum – система гибкой разработки проектов, основанная на принципе спринта. От 1

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

10
Экстремальное программирование (XP) – методика, при которой важно взаимодействие
с клиентом на каждом этапе. Благодаря такому подходу, выявляются недостатки
предыдущих этапов, определяется необходимый функционал продукта и другие
параметры.

Lean – базируется на системе управления производством. Главное отличие – принцип

постоянного совершенствования продукта на всех уровнях организации процесса.

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

Waterfall

Waterfall (с англ. – «водопад») – предполагает последовательный переход к каждому этапу

разработки и невозможностью вернуться на шаг назад. Внести какие-либо изменения
будет возможно только после релиза проекта.

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

Выделяют следующие стадии разработки в Waterfall:

 Анализ системных и программных требований, которые закреплены в документе

(Word или PDF).
 Планирование всех этапов разработки. Важный пункт, так как вся последующая
работа будет четко следовать составленному плану.
 Проектирование. Разрабатывается внутренняя архитектура проекта, его внешний
вид, структура, рассматриваются варианты реализации.
 Реализация дизайна, верстки, программного продукта.
 Интеграция. Проводятся необходимые работы по обмену данных и пишется код
программы.
 Тестирование. Готовый продукт проверяется на наличие программных ошибок,
также выявляются недочеты функционала. После этого идет исправление нужных
багов.
 Выпуск продукта. Релиз готового проекта и окончание разработки. Возможна
также работа по адаптации проекта к иным видам систем.
 Техническая поддержка. Поддержание работоспособности ресурса и оперативное
реагирование на возникающие вопросы или проблемы в системе.

Востребованные методики Waterfal:

Сашими – одна из самых популярных моделей Waterfal. Представляет собой

наслаивающиеся друг на друга этапы, которые перекрываются по времени.

11
Waterfall с субпроектами – методика работы с тремя крупными стадиями: разработка
концепции, проектирование и структурирование продукта. Каждый из этих блоков имеет
свои этапы разработки. По окончании работ в каждой стадии проводится их интеграция.

Модель снижения риска – проект разделяется на более мелкие проекты, которые

направлены на выявление недочетов до релиза программного продукта.

Ключевая особенность Waterfall – невозможность сделать шаг назад или перепрыгнуть

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

Преимущества методологий

Agile:

 Внесение необходимых изменений и внедрение нового функционала может

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

Waterfall

 Стоимость и сроки выполнения понятны ещё до начала работ. Поэтому заказчик

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

Недостатки методологий

Agile:

 Рассчитать конечные затраты практически невозможно – требования могут

постоянно меняться в зависимости от особенностей проекта. Сложность
заключается в том, что они могут противоречить уже существующей структуре.
12
  Agile требует большой вовлеченности в процесс и полному погружению в него, что
бывает сложно, особенно для молодых подрядчиков.
 Возможность частого внесения правок может обернуться риском в бесконечном
совершенствовании проекта. Здесь также возможна и обратная сторона – снижение
качества продукта.

Waterfall:

 Требования к проекту закрепляются в начале и не могут меняться до окончания

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

Применение методологий

Agile используется:

 Когда перечень требований окончательно не определен, а изменения должны

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

Waterfall подойдет, если:

 Проектные требования тщательно продуманы и неизменны. У заказчика есть четко

сформулированная концепция продукта.
 Технологии и инструменты известны заранее.
 Разрабатываемый продукт сложный и требует больших затрат.
 Приоритетом является качество продукта. Временные и денежные траты имеют
второстепенное значение.
 Заказчик не планирует принимать участие в проекте. Он видит только готовый
продукт. Проект полностью разрабатывается на аутсортинге.
 Клиенту важно знать точные сроки выполнения всех работ над проектом.
Исполнитель полностью несет ответственность за срыв сроков и
незапланированное увеличение бюджета.
 Реализация аналогичного проекта, с которым уже сталкивались разработчики.

Что из этого следует?

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

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

Гибкая модель требует высокого профессионализма от исполнителя и идеально подходит

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

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

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

https://club.cnews.ru/blogs/entry/
waterfall_ili_agile_kak_vybrat_metodologiyu_upravleniya_proektom_-2020-09-02

Waterfall или Agile: как выбрать

методологию управления проектом?
Привет! Я менеджер проектов в компании Azoft. Занимаюсь управлением проектов
больше 8 лет. По моему опыту, выбор методологии управления проектом часто лидирует
в списке холиварных вопросов клиента и команды. В этой статье поделюсь с вами своими
мыслями на эту тему, без купюр и фаворитизма.

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

Краткий ликбез по Waterfall

Waterfall (каскадная) – это методология ведения проекта, когда фазы работ идут
последовательно. Следующая фаза начинается только после завершения предыдущей.
Наглядно это выглядит так:

14
Этапы методологии Waterfall

Получается, план такой: 

1. Установили и прояснили требования заказчика и согласовали их с командой;

2. Подготовили весь дизайн проекта; 
3. Разработали программное обеспечение целиком по заданным технологиям;
4. Протестировали проект на наличие багов;
5. И только после всех предыдущих, последовательных этапов —запустили в
эксплуатацию.

В Waterfall можно управлять изменениями требований и рисками, но это скорее

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

Семейство Agile-методологий: в чем

главная особенность
Agile (гибкие) – это семейство методологий, объединенных ценностями и
принципами Agile-манифеста. 

Ценности Agile:

 Люди и взаимодействие важнее процессов и инструментов.

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

15
Agile стал основой для целого ряда гибких методик, среди которых наиболее известны
Scrum, Lean и экстремальное программирование.

В основном это фреймворки, предполагающие итерационную работу над проектом, то

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

Схема работы по методологии Scrum

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

Получается, что итерационные методологии отличаются тем, что результатом каждой

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

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

16
Преимущества и недостатки Waterfall и
гибких методологий
Waterfall, Scrum и другие гибкие методологии управления проектами имеют
преимущества и недостатки. Каждая из методологий хорошо подходит для решения
определенных задач и сложнее адаптируется к другим. 

Характеристики
проектов,
подходящих под
разные
Waterfall Гибкие методологии В чем подвох
методологии
можно обозначить
так: 
 Характеристики
В Waterfall этап
аналитики
предполагает
полное прояснение
всех требований и
учет ограничений
на ранней стадии
проекта.
Скоуп и Понятны и меняться не Меняются по ходу Последующие
требования будут работы изменения
требований сложнее
с т.з. процессов и
потребует
дополнительных
затрат, чтобы
исправить
реализованный
ранее функционал.
В новой для себя
области гораздо
Похожая задача уже Для проще упустить
решалась заказчика/исполнителя что-то важное. Для
Новизна задачи заказчиком/исполнителем, это качественно новая Waterfall будет
продукт не задача, либо продукт сложнее вносить
инновационный инновационный изменения в
исходные
требования.
Управление Требования к проекту в Планируется По аналогии с
требованиями процессе работы не будут применять Customer первыми пунктами
значительно меняться development – здесь все
(тестирование идеи упирается в
или прототипа потребность гибко
будущего продукта на управлять
потенциальных требованиями. Если
17
 потребителях),
тестировать гипотезы
нет такой
на рынке, в процессе
потребности –
проекта управлять
Waterfall ваш
приоритетами,
вариант.
опираясь на фокус-
группы
Если в Waterfall все
идет по плану, то
бюджет и срок
проекта можно
определить после
этапа аналитики по
проекту. При этом
Можно варьировать в
Бюджет Жестко ограничен бюджет первичен, и
заданных рамках
после завершения
аналитики он будет
определять срок. То
есть
последовательность
такая: бюджет →
аналитика → срок. 
Отличительная
особенность гибких
методологий –
результат каждой
итерации в виде
Жестко ограничен и работающего
Срок определен до этапа Может варьироваться продукта. После
аналитики завершения этапа
аналитики можно
достаточно точно
оценить срок
завершения
Waterfall-проекта.

18
Сравнение Scrum и Kanban
Scrum Kanban
Регулярные спринты с фиксированной
График продолжительностью (например, Непрерывный процесс
2 недели)
Подходы к
В конце каждого спринта Непрерывная поставка
релизу
Владелец продукта, scrum-мастер,
Роли Обязательных ролей нет
команда разработчиков
Время выполнения, время
Ключевые
Скорость цикла, объем незавершенной
показатели
работы (WIP)
Отношение к В ходе спринта команды не должны Изменение может произойти в
изменениям вносить изменения. любой момент

Давайте проанализируем каждую конкретную тему Scrum и отличия от Канбана:

 В Scrum вы разделяете свою организацию на небольшие, кросс-функциональные,

самоорганизующиеся команды. В Канбане нет жесткого требования про кросс-
функциональные команды
 В Scrum есть особенные роли, а для Канбана подойдут обычные
 В Scrum ежедневное стендап-собрание — это сердечный ритм проекта. В Канбане
планерки проводить жестко не требуются
 В Scrum вы должны разделить свою работу на список небольших конкретных
результатов. В Канбане достаточно разделить работу на части, написать каждую
часть на стикер и повесить его на стену. Они не должны быть результатами.
 В Scrum вы должны разбить время на короткие итерации фиксированной длины (1-
4 недели), с разными версиями минимально-работоспособного продукта (MVP),
которые вы будете демонстрировать после каждой итерации. В Канбане же работа
непрерывная, а не итеративная.
 В Scrum вы должны отсортировать список поставляемых результатов по
приоритету и оценить необходимые усилия для каждого элемента. В Канбане нет
жесткого требования оценивать работу.
 В Scrum, основываясь на информации, полученной на проверке релиза после
каждой итерации, оптимизируется план выпуска и обновляются приоритеты вместе
с заказчиком. В Канбане этого не происходит.
 В Scrum у вас есть фиксированные события, такие как начало, планирование, обзор
и ретроспектива. В Канбане же есть задающие ритм каденции.
 В Scrum рабочий процесс всегда должен оптимизироваться после каждой
проведенной ретроспективы. В Канбане же это не обязательно, но можно провести
в каденциях.
 В Scrum должен быть список невыполненных работ по продукту и график сгорания
задач, чего в Канбане нет и в помине.

19
Итак, что же находится в Канбане? Давайте посмотрим на контраст со Scrum:

 Канбан фокусируется на представлении рабочего процесса команды, давая им

возможность визуализировать его и улучшить как можно скорее. Scrum имеет
фиксированный процесс и церемонии.
 Канбан позволяет использовать любые именованные столбцы в вашей доске, чтобы
проиллюстрировать, где находится каждый элемент, продукт или услуга в рабочем
процессе. Scrum фокусируется на результатах с конкретными столбцами: “бэклог”,
“бэклог спринта”, “работа в процессе” и “выполненная работа”.
 Канбан ограничивает “работу в процессе» WIP-лимитом. В Канбане необходимо
установить ограничения на количество работ, которые могут выполняться в
каждом столбце рабочего процесса. В Scrum нет никаких правил на этот счет.
 Одна из самых важных вещей в Канбане — это измерение среднего времени
выполнения одного элемента, называемое “временем цикла”. Это очень важно,
потому что это дает вам возможность оптимизировать процесс, чтобы сделать
работу как можно короче и предсказуемее.
 В Канбан можно вносить изменения по мере необходимости. В Scrum изменения не
должны прерывать спринт (хотя, по нашему мнению, это вполне возможно –
примечание редактора).

20
---------------------------------

Различия REST и SOAP

SOAP – строгий протокол
REST – свод рекомендаций (существование без состояния и использование кодов
состояния ответов http)

Определение:
SOAP – формат обмена данными. С SOAP это всегда SOAP-XML
REST – это архитектурный подход, ориентированный на использование HTTP в качестве
транспортного протокола.

Формат обмена сообщениями

В SOAP вы используете формат SOAP XML для запросов и ответов. SOAP XML
представляет собой XML, включающий:
— Envelope (конверт) – корневой элемент, который определяет сообщение и пространство
имен, использованное в документе,
— Header (заголовок) – содержит атрибуты сообщения, например: информация о
безопасности или о сетевой маршрутизации,
— Body (тело) – содержит сообщение, которым обмениваются приложения,
— Fault – необязательный элемент, который предоставляет информацию об ошибках,
которые произошли при обработке сообщений. И запрос, и ответ должны соответствовать
структуре SOAP.

В REST такого фиксированного формата нет. Вы можете обмениваться сообщениями на

основе XML, JSON или любого другого удобного формата. JSON является самым
популярным среди используемых форматов.

Определения услуг

 SOAP использует WSDL (Web Services Description Language) — язык описания

веб-сервисов и доступа к ним, основанный на языке XML.
 REST не имеет стандартного языка определения сервиса. Несмотря на то, что
WADL был одним из первых предложенных стандартов, он не очень популярен.
Более популярно использование Swagger или Open API.

Транспорт

SOAP не накладывает никаких ограничений на тип транспортного протокола. Вы можете

использовать либо Web протокол HTTP, либо MQ.
REST подразумевает наилучшее использование транспортного протокола HTTP

Простота реализации

RESTFful веб-сервисы, как правило, гораздо проще реализовать, чем веб-сервисы на

основе SOAP.

21
  REST обычно использует JSON, который легче анализировать и обрабатывать. В
дополнение к этому, REST не требует наличия определения службы для
предоставления веб-службы.
 Однако в случае SOAP вам необходимо определить свой сервис с использованием
WSDL, и при обработке и анализе сообщений SOAP-XML возникают большие
накладные расходы.

https://www.youtube.com/watch?v=hPqg8gqLu8g
Почему Rest лучше
1) Soap – только xml, Rest может использовать Json
2) Rest предоставляется многими сторонними web-сервисами (google, amazon,…)
3) Rest быстрее

Почему SOAP лучше

1) Строгий формат лучше для безопастости

Проверка валидности:
Soap – обязательно (медленнее), rest (json) - необязательно

https://www.youtube.com/watch?v=lYjm2w8-ERI&t=122s

REST ограничения:
1. Приведение архитектуры к модели клиент-сервер

В основе данного ограничения лежит разграничение потребностей. Необходимо отделять

потребности клиентского интерфейса от потребностей сервера, хранящего данные. Данное
22
ограничение повышает переносимость клиентского кода на другие платформы, а
упрощение серверной части улучшает масштабируемость системы. Само разграничение
на “клиент” и “сервер” позволяет им развиваться независимо друг от друга.

2. Отсутствие состояния

Архитектура REST требует соблюдения следующего условия. В период между запросами

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

3. Кэширование

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

4. Единообразие интерфейса

К фундаментальным требованиям REST архитектуры относится и унифицированный,

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

5. Слои

Под слоями подразумевается иерархическая структура сетей. Иногда клиент может

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

6. Код по требованию (необязательное ограничение)

Данное ограничение подразумевает, что клиент может расширять свою

функциональность, за счет загрузки кода с сервера в виде апплетов или сценариев.

23
Различия микросервиса и монолита
https://www.youtube.com/watch?v=mKp7-hWPJb4

https://www.youtube.com/watch?v=PmIrrFqOfn8

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

Минусы монолита
Сложность внедрения новых технологий (нужно переписывать)
Громоздкий код, высокий порог вхождения в проект
Масштабируемость (не факт что получится масштабировать отдельные функции)
24
Сервис-ориентированная архитектура

Микросервисы

Независимый набор технологий

Независимость (deploy, масштабирование)
Децентрализованное управление данными (своя БД)
Безопасность на уровне сервиса
Независимость команд (не мешают друг другу)

Недостатки
Сложность разработки и проектирования (нужно продумывать взаимодействие
микросервисов)
Сложность устранения неполадок (кто виноват? Нужно правильное логирование)
Сложность тестирования связки микросервисов

25
https://ru.photo-555.com/1235570-microservice-vs-monolithic

В таблице ниже приведены

сравнения между Microservice и Monolithic

категория Микросервисная архитектура Монолитная архитектура
Каждый сервис может быть
Полностью разработан на
независимо разработан с
язык одном языке
использованием разных языков
программирования.
программирования.
Он имеет федеративную модель
данных, позволяющую каждой Имеет централизованную
Модель данных
службе использовать свою модель данных.
собственную модель данных.
Он имеет несколько кодовых баз.
Он имеет только одну
Codebase Каждый сервис имеет отдельную
кодовую базу.
кодовую базу для них.
Он имеет высокую понятность и Это очень сложно понять и
Понятность
очень прост в обслуживании. сбить с толку.
Разработка и Возможна непрерывная Непрерывная разработка и
внедрение разработка и внедрение. внедрение очень сложны.
Запуск сервиса Быстрый запуск сервиса. Запуск службы времени.
Масштабирование приложений
Масштабирование
очень просто, поскольку каждый
Масштабирование приложения очень сложно, так
сервис может масштабироваться
приложений как все приложение должно
отдельно без масштабирования
масштабироваться.
всего приложения.
Сравнительно менее
последовательный и
Согласованность и Очень последовательный и легко
доступный, поскольку любое
доступность доступный.
обновление потребует
процесса разработки с нуля.
Deploy, безопасность,
логирование, поиск
неисправностей

26
https://www.youtube.com/watch?v=3W0lJTNwrFE

"Микросервисная архитектура теория и

практика" - Иван Быков (Backend)
Проще разработка
Сложнее взаимосвязи
Сложнее деплой
Безопасность самостоятельно
Выше живучесть (можно сделать дублирование данных)

27
28
Синхронное общение между сервисами:

Сервисы в этом случае зависят друг от друга (один упал – второй ждёт), что убивает саму
идею микросервисов.

Асинхронное общение между сервисами:

1) Через любой messaging provider, например Rabbit MQ, Azure Service Bus,
Raddis
Не нужно ждать ответа, но нужно знать о существовании другого сервиса (сильная
связанность сервисов)

29
 2) Через шину сообщений (Event Bus, шина сообщений)
Сервисы подписываются на события

30
очереди сообщений в микросервисной
архитектуре
https://mcs.mail.ru/blog/zachem-nuzhny-ocheredi-soobshcheniy-v-mikroservisnoy-arkhitekture

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

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

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

31
https://www.youtube.com/watch?v=Bw8f1Dd6Wr4

Способы интеграции систем

32
Протоколы
http – не шифрует данные
https – шифрует данные. Нужен SSL-сертификат на сервере.
web sockets – двунаправленный протокол (не запрос-ответ как у http, передача идет в обе
стороны)
FTP (File Transfer Protocol) – протокол передачи файлов
https://habr.com/ru/post/111241/
Отличительной его особенностью является использование двух соединений между
сервером и клиентом. Одно соединение (командное или управляющее) используется для
передачи команд серверу, а так же приема ответов на эти команды. Второе соединение
(соединение данных) используется непосредственно для приема или передачи данных.
Управляющее соединение всегда происходит со стороны клиента на порт сервера 21 и
остается на протяжении всего сеанса работы открытым. Соединение данных открывается
и закрывается по мере необходимости в приеме или получении данных.
SFTP предполагает, что он работает по защищенному каналу, например SSH, что сервер
уже аутентифицировал клиента и что протоколу доступна информация пользователя.

33
Header-ы http
Запрос Ответ
Заголовок GH Появление* Назначение Пример
RqH EH RsH EH
Список допустимых форматов
Accept Нет Да Нет Нет Нет HTTP/1.0 Accept: text/plain
ресурса.
Accept-
Перечень поддерживаемых
Charset
Нет Да Нет Нет Нет HTTP/1.0 кодировок для предоставления Accept-Charset: utf-8
пользователю.
Перечень поддерживаемых
Accept- способов кодирования Accept-Encoding: <compress | gzip | deflate |
Нет Да Нет Нет Нет HTTP/1.0
Encoding содержимого сущности при sdch | identity>
передаче.
Accept- Список поддерживаемых
Нет Да Нет Нет Нет HTTP/1.0 Accept-Language: ru
Language естественных языков.
Указание на альтернативные
Alternates Нет Нет Нет Да Нет HTTP/1.1
способы представления ресурса.
Authorization: Basic
Authorization Нет Да Нет Нет Нет HTTP-Auth Данные для авторизации. QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: max-age=3600
Основные директивы для Cache-Control: max-stale=0
Cache-Control Да Нет Нет Нет Нет HTTP/1.1 Cache-Control: min-fresh=0
управления кэшированием.
Cache-Control: no-transform
Cache-Control: only-if-cached
Cache-Control: cache-extension
Формат и способ представления
Content-Type Нет Нет Да Нет Да HTTP/1.0 Content-Type: text/html;charset=utf-8
сущности.
Date Да Нет Нет Нет Нет HTTP/1.0 Дата генерации отклика. Date: Tue, 15 Nov 1994 08:12:31 GMT
URI ресурса, после которого Referer:
Referer Нет Да Нет Нет Нет HTTP/1.0
клиент сделал текущий запрос. http://en.wikipedia.org/wiki/Main_Page
Server Нет Нет Нет Да Нет HTTP/1.0 Список названий и версий веб- Server: Apache/2.2.17 (Win32) PHP/5.3.5

34
 сервера и его компонентов с
комментариями. Для прокси-
серверов поле Via.
Список названий и версий User-Agent: Mozilla/5.0 (X11; Linux i686;
User-Agent Нет Да Нет Нет Нет HTTP/1.0 клиента и его компонентов с rv:2.0.1) Gecko/20100101 Firefox/4.0.1
комментариями.
*
Значения в колонке «Появление»:

35
Методы HTTP запроса (Глаголы)
HTTP определяет множество методов запроса, которые указывают, какое желаемое
действие выполнится для данного ресурса. Несмотря на то, что их названия могут быть
существительными, эти методы запроса иногда называются HTTP глаголами.

CRUD — (англ. create read update delete — «Создание чтение обновление удаление»)
сокращённое именование 4 базовых функций при работе с персистентными хранилищами
данных — создание, чтение, редактирование и удаление. 

Операция
Создание (Create)
Чтение (Read)
Редактирование (Update)
Удаление (Delete)

Идемпотентность - это свойство объекта или операции при повторном применении

операции к объекту давать тот же результат, что и при первом.
Идемпотентные методы - GET, HEAD, OPTIONS, TRACE, +(Небезопасные PUT или
DELETE).

Каждый реализует свою семантику, но каждая группа команд разделяет общие свойства:
так, методы могут быть безопасными (не изменяют состояния сервера – GET, HEAD,
OPTIONS), идемпотентными (возвращают один и тот же результат на идентичный запрос
– GET, HEAD, PUT, DELETE) или кэшируемыми.

Методы HTTP запроса: 

GET - запрашивает представление ресурса. Запросы с использованием этого метода могут

только извлекать данные. Не имеет тела.

POST - используется для отправки сущностей к определённому ресурсу. Часто вызывает

изменение состояния или какие-то побочные эффекты на сервере. Имеет тело.

PUT - заменяет все текущие представления ресурса данными запроса.

DELETE - удаляет указанный ресурс.

PATCH - используется для частичного изменения ресурса.

POST запрос.

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

блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму,
после чего они передаются серверу методом POST и он помещает их на страницу. При
этом передаваемые данные (в примере с блогами — текст комментария) включаются в
36
тело запроса. Аналогично с помощью метода POST обычно загружаются файлы на сервер.
Сообщение ответа сервера на выполнение метода POST не кэшируется.

Отличие GET от POST

GET отсылает запрос на получение данных, POST отправляет данные. GET. Добавляется в

закладки. Кэшируется. История остается в закладках браузера. Есть ограничения по по
символам, так как данные передаются в URL, то должен ограничиваться в 2048 символах
(мах строка символов в URL). По типу данных допускается использование только
символов ASCII. Менее безопасный, так как передоваемые в URL данные, видны
пользователю. Данные в URL доступны всем.

Разница между PUT и POST

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

Все безопасные методы являются также идемпотентными, как и некоторые другие, но при
этом небезопасные, такие как PUT или DELETE.

Структура HTTP запроса:

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

Зачем нужны Header?

Для того чтобы компьютер мог понимать с каким ресурсом работать:

Заголовок-сущность Content-Type используется для того, чтобы определить MIME тип

ресурса.
MIME тип:

Content-Type (text/html; charset=utf-8)

Клиент может установить Accept в application/json, если он запрашивает ответ в JSON.

И наоборот, когда отправляются данные, установленный Content-Type в application/xml

говорит клиенту, что данные были отправлены в XML форме.

37
 

Пример запрос-ответ по протоколу HTTP:

38
 

39
методы авторизации
https://habr.com/ru/company/dataart/blog/262817/

 Идентификация — это заявление о том, кем вы являетесь. В зависимости от

ситуации, это может быть имя, адрес электронной почты, номер учетной записи,
итд.
 Аутентификация — предоставление доказательств, что вы на самом деле есть тот,
кем идентифицировались (от слова “authentic” — истинный, подлинный).
 Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.

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

Аналогично эти термины применяются в компьютерных системах, где традиционно под

идентификацией понимают получение вашей учетной записи (identity) по username или
email; под аутентификацией — проверку, что вы знаете пароль от этой учетной записи, а
под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа
к запрошенной странице или ресурсу.

https://www.youtube.com/watch?v=q0u4yRUSDzI

40
41
https://zen.yandex.ru/media/habr/kak-ty-realizuesh-autentifikaciiu-priiatel-
5ec4cc1e033b1f6bec4ce836

42
Аутентификация на основе сессий (каждый раз проверяется session id)
Аутентификация на основе токенов (не хранятся на сервере, это удобно)

 Пользователь вводит имя и пароль.

 Сервер проверяет их и возвращает токен (JWT), который может содержать
метаданные вроде user_id, разрешений и т. д.
 Токен хранится на клиентской стороне, чаще всего в локальном хранилище, но
может лежать и в хранилище сессий или кук.
 Последующие запросы к серверу обычно содержат этот токен в качестве
дополнительного заголовка авторизации в виде Bearer {JWT}. Ещё токен может
пересылаться в теле POST-запроса и даже как параметр запроса.
 Сервер расшифровывает JWT, если токен верный, сервер обрабатывает запрос.
 Когда пользователь выходит из системы, токен на клиентской стороне
уничтожается, с сервером взаимодействовать не нужно.

Каждый токен самодостаточен, содержит все необходимые для проверки данные

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

Единая точка входа (Single Sign On, SSO)

 Пользователь входит в один из сервисов Google.

 Пользователь получает сгенерированную в Google Accounts куку.
 Пользователь идёт в другой продукт Google.
 Пользователь снова перенаправляется в Google Accounts.
 Google Accounts видит, что пользователю уже присвоена кука, и перенаправляет
пользователя в запрошенный продукт.

Двухфакторная аутентификация (2FA)

Биометрия

43
Типы баз данных
Реляционные БД - набор таблиц и связей между ними
Нормализованы (недопустимо дублирование данных)

Виды нереляционных баз данных

Базы NoSQL делятся на четыре основные категории (в зависимости от решаемых

с их помощью задач).

Ключ-значение

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

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

Например:

user1 {Кузнецов В., отдел маркетинга}

user2 {name:Лена, position:секретарь}
user3 {ООО «Вектор»}
user4 {Трофимова Таня, отд.2, дизайнер}
user5 {Галина Николаевна, гл. бух.}
user6 {65,84,236}

Базы «ключ-значение» часто используют для кэширования данных и организации

очередей.

Их достоинства — быстрый поиск и простое масштабирование.

Их недостаток — нельзя производить операции со значениями. Например — сортировать

их или анализировать.

Базы «ключ-значение» применяют в поисковой системе Google, «Википедии»,

«Фейсбуке», интернет-магазине Amazon.

Одна из самых популярных — Redis. Её используют Uber, Slack, Stack Overflow, сайты
гостиниц и туристические, социальная сеть Twitter.

Документоориентированные СУБД

В таких данные хранятся в виде иерархических структур (документов) с произвольным

набором полей и их значений. Документы объединяются в коллекции.

44
Если провести аналогию с реляционными СУБД, то коллекциям соответствуют таблицы,
а документам — строки в них.

Например, фрагмент документа с информацией о фильмах:

[
{
"year" : 2020,
"title" : "Душа!",
"produced" : "Pixar Animation Studios",
"directors" : [ "Пит Доктер", " Кемп Пауэрс"],
"tagline" : "Everybody has a soul. Joe Gardner is about to find his",
"rating" : 8.3,
"genres" : ["Мультфильм", "Комедия"]
},
{
"year": 2020,
"title": "Ход королевы",
"created" : "Allan Scott",
"book" : "Уолтер Тевис",
"actors" : ["Аня Тейлор-Джой", "Мариэль Хеллер", "Моусес Ингрэм"],
"rating" : 8.4,
"genres" : ["Драма", "Спорт"]
},
{
"year": 1972,
"title": "Зита и Гита",
"рroduced" : "Sippy Films",
"actors" : ["Хема Малини", "Санджив Кумар"],
"genres" : ["Драма", “Мюзикл”, "Мелодрама"]
}
]

Документоориентированные базы используют в системах управления содержимым

(CMS) — для хранения каталогов и пользовательских профилей.

Одна из самых популярных — MongoDB (там можно создавать процедуры на JavaScript).

Колоночные

Эти базы отличаются от реляционных лишь способом хранения данных на накопителе.

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

Например, если реляционная таблица выглядит так:

name color property

волк серый зубастый
коза белая рогатая
капуста зелёная

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

name волк коза капуста

color серый белая зелёная
45
property зубастый рогатая

Что это даёт? Представьте, что вам нужны только названия объектов, а их свойства вас
не интересуют.

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

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

Колоночные базы применяются в различных каталогах и архивах данных, работа

с которыми основана на подобных выборках.

Одна из самых популярных СУБД такого типа — Apache Cassandra.

Графовые

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

их хранения лучше всего подходят графовые базы.

Вершины (или узлы графа) — это объекты (сущности), а рёбра графа — взаимосвязи
между ними.

Например, информация о друзьях в социальных сетях просто идеальна для представления

в виде графа:

Графовые базы применяют в социальных сетях, сервисах рекомендаций, системах

выявления мошенничества и им подобных.

Одна из популярнейших графовых СУБД с открытым кодом и собственным языком

запросов — это Neo4j.

46
Виды требований к ПО
Функциональные требования

Функциональные требования объясняют, что должно быть сделано. Они идентифицируют

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

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

Функциональные требования.

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

Пример функциональных требований – сценарии использования (Use cases), в которых

описывается всё, что должна выполнять система.

Нефункциональные требования

С ними немного сложнее, поскольку в здесь нужно описать те дополнительные

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

Согласно К. Вигерсу, можно выделить 3 группы нефункциональных требований:

 Внешние интерфейсы
 Атрибуты качества
 Ограничения 

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

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

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

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

Бизнес vs Функциональные требования

В техническом задании регистрируются как бизнес-требования к системе, так и

функциональные требования:

— Бизнес-требования представляют собой описание того, ЧТО должна делать

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

— Функциональные требования представляют собой описание того, КАК те или

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

Пример бизнес-требования:

1) Автоматизация сбора данных по заказам, поступавшим в кофейню, за установленный

руководством кофейни период.

2) Автоматизация процедуры формирования отчета по поступившим заказам в форматы

*.xlsx, *.pdf на основе собранных данных.

3) Автоматизация отправки отчета по поступавшим заказам на email руководства кофейни

в установленное время.

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

Пример функционального требования:

1. Пользователь должен иметь возможность проводить поиск необходимых ему книг и

документов или по всему множеству доступных каталожных баз данных или по
определенному их подмножеству.

2. Система должна предоставлять пользователю подходящее средство просмотра

библиотечных документов.

3. Каждый заказ должен быть снабжен уникальным идентификатором (ORDER_ID),

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

48
«Для решения этой задачи [какой – см. выше] предполагается использовать внешний
сервис, к которому баннерные сервера будут обращаться при каждом показе баннера.
Поскольку данный сервис является точкой отказа, баннерные сервера должны корректно
обрабатывать ситуацию когда внешний сервис недоступен или отвечает с задержками».

Структура технического задания

Согласно ГОСТ 34.602-89, основными разделами ТЗ являются:
1. Общие сведения.
2. Назначение и цели создания (развития) системы.
3. Характеристика объектов автоматизации.
4. Требования к системе.
5. Состав и содержание работ по созданию системы.
6. Порядок контроля и приемки системы.
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к
вводу системы в действие.
8. Требования к документированию.
9. Источники разработки.

https://www.sekretariat.ru/article/95445-struktura-tehnicheskogo-zadaniya

бизнес-правила
бизнес-проверки
валидация
мапинг
сериализация

49
Типы диаграмм
https://habr.com/ru/post/508710/

Структурные диаграммы показывают статическую структуру системы и ее частей на

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

Диаграммы поведения показывают динамическое поведение объектов в системе, которое

можно описать, как серию изменений в системе с течением времени. А к диаграммам
поведения относятся:

ER-диаграммы
UML: диаграмма классов, диаграмма последовательностей, USE-CASE диаграмма
(=диаграмма прецедентов, вариантов использования)

50
https://habr.com/ru/company/trinion/blog/245615/

Интеграция программного обеспечения.

Описание процесса от бизнес
консультанта
Лично я делю процесс интеграции на такие этапы:

1. изучить программный продукт.

2. Определяем, какой продукт является источником, какой – приемником.
3. Сопоставляем объекты между источником и приемником.
4. Выбираем протокол для интеграции
5. Проводим постобработку данных (после переноса в одну из сторон)

Важно: при интеграции различных программных решений нужно хорошо понимать

их функционал.

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

Выбираем источник и приемник

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

Сопоставление объектов (данных)

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

И здесь возникает проблема: требуются правила сопоставления.

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

правилах необходимо оповестить ваших клиентов.

1. Обязательно оставляю клиенту подробно описанные правила сопоставления и

пояснения, какие параметры и данные менять недопустимо.
2. Предусматриваю варианты оповещения об ошибке. Т.е. не только фиксирую
проблему в логе ошибок, но и оповещаю пользователя о сбое каким-то образом:
при помощи SMS, письмом на email, всплывающими уведомлениями в 1С. А
иногда всеми этими способами сразу.

Самые распространенные решения:

51
 1. При помощи смс, электронного письма, всплывающих уведомлений в 1С
информацию о сбое должен получить человек, который занимается обработкой
заказов.
2. Для контроля аналогичное уведомление (чаще всего на email) отправляется
руководителю отдела или директору компании.
3. Обязательно ведется лог-файл ошибок для того, чтобы специалист смог
просмотреть все подробности.

Обмен данными: писать самому или применять типовое решение?

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

Метод подключения: REST API, SOAP или прямое подключение к базе приемника

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

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

Вопросы клиентского доступа: почему не работает обмен?

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

Вы внедрили интеграцию, все проверили, протестировали, убедились, что система

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

Самые распространенные ситуации:

 Ограничение доступа по IP.

 Ограничение прав пользователя.
 Ограничение по количеству обращений к источнику или приемнику

Формат выгрузки

Для обмена данными используются самые разные форматы. Это может быть JSON, XML,
CSV, TXT, прямой доступ к базе и т.д. У меня в этом вопросе нет каких-то определенных
предпочтений. Я считаю, что здесь нужно исходить из рациональных требований проекта.

Постобработка

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

52
для пользователя, для того, чтобы ему было удобно.

Для интернет магазинов при интеграции чаще всего требуются:

 Оповещение менеджера о поступлении заказа, например, при помощи sms

 Уведомление пользователей о поступлении новых заказов или другой актуальной
информации по email
 Звуковой сигнал и/или всплывающее окно в 1С с напоминанием о том, что
появились новые запросы или заявки

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

Тестирование интеграции

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

53
Use Case VS User Story. Выбираем подход к
специфицированию требований
https://www.youtube.com/watch?v=9dOFSY5PoNo

54