Интеграция: синхронное, асинхронное и реактивное взаимодействие, консистентность и транзакции

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

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

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

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

• легкость и простота использования;
• легкость перемещения;
• целостность;
• эффективность и устойчивость к сбоям;
• внешние взаимодействия между системой и внешним миром;
• ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта.

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

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

Стандартные формы для специфицирования функциональных требований:

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

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».

Процесс управления изменениями

Анализ проблем изменения спецификации. Процесс начинается с определения проблем в требованиях или с прямого предложения внесения изменений. На этой стадии проблема или предложенные изменения анализируются для проверки их обоснованности. Затем могут быть сделаны более определённые предложения относительно изменений в требованиях.
Анализ осуществимости и расчёт их стоимости. Эффект от внесения предложенного изменения оценивается с использованием оперативного контроля. Стоимость изменений оценивается двумя показателями: стоимостью внесения изменения в спецификацию и стоимостью внесения изменений в структуру системы и непосредственно в программный код. По окончании этого этапа принимается решение, продолжать или нет внесение изменений в систему.
Реализация изменений. Реализация изменений в системной спецификации, структуре системы и программном коде.

Кто читает документацию

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

Как правильно сформулировать и контролировать цель проекта?

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

При определении целей по совершенствованию процессов нужно иметь в виду два обстоятельства.

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

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

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

Документы процесса разработки и управления требованиями (по Вигерсу)

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

Характеристики

Отказоустойчивая система отличается наличием избыточных элементов. Условно они относятся к следующим типам:

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

Яркий пример — схема кластеризации на основе Veritas Cluster Module. Если один элемент выходит из строя, приложение отключают его из кластера и перераспределяет нагрузку на остальные.

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

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

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

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

Первым такое ПО создала компания NetAPP, известная своими технологическими новинками в сфере систем хранения данных. Вендор разработал продукт MetroCluster, который полностью резервирует все компоненты ЦОДа на удаленной площадке. Даже если полностью отключится один из ЦОДов, то второй полностью восстановится в течение нескольких секунд.

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

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

Что такое валидность?

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

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

Есть два типа действия:

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

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

Пользователь — Требования пользователя

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

Проблемы при формировании пользовательских требований

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

Требования

Основные характеристики отказоустойчивости требуют:

1. Отсутствие единой точки отказа — если в системе происходит сбой, она должна продолжать работать без перебоев в процессе ремонта.
2. Изоляция неисправности для отказавшего компонента — при возникновении отказа система должна быть способна изолировать отказ от неисправного компонента. Это требует добавления специальных механизмов обнаружения отказов, которые существуют только для локализации отказов. Восстановление после неисправности требует классификации неисправности или отказавшего компонента. Национальный институт стандартов и технологии (NIST) классифицируют неисправности на основе местности, причины, продолжительность и эффект.
3. Сдерживание отказов для предотвращения распространения отказа — некоторые механизмы отказа могут вызвать отказ системы, распространяя отказ на остальную часть системы. Примером такого отказа является «мошеннический передатчик», который может заблокировать законную связь в системе и вызвать общий отказ системы. Требуются межсетевые экраны или другие механизмы, которые изолируют несанкционированный передатчик или отказавший компонент для защиты системы.
4. Наличие режимов реверсии

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

Отказоустойчивые системы обычно основаны на концепции избыточности.

Надежность гибридных ЦОД

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

Согласно данным исследования систем восстановления после сбоев и прогнозу на 2018 – 2025 гг. (Disaster Recovery Solutions Market Size, Share & Trends, 2018 – 2025), в 2016 г. гибридное облако доминировало на рынке при развертывании новых систем, и сответствующий рынок оценивался в 763,4 млн. долл. Популярность этой схемы объясняется, в первую очередь, тем, что развертывание решений для аварийного восстановления через гибридное облако дает возможность использовать программное и аппаратное обеспечение на локальной площадке, а службы восстановления — в облаке. Она также позволяет использовать сочетание виртуальных облачных серверов и выделенной инфраструктуры хостинга. Это позволяет организациям значительно сократить расходы, связанные с установкой решений для аварийного восстановления.

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

За последние пару лет мы и заказчики Softline на себе оценили важность гео-распределенных площадок из-за разных ситуаций с ЦОД, в которых мы строим свои решения, например, происходили пожары, отключение сетей и т.д.,- рассказывает Юрий Новиков, руководитель направления развития облачных технологий Softline.- Гео-распределенная инфраструктура позволила нам обеспечить бесперебойность пользования облаками.

У компании Softline –портфель решений, который дает возможность делать back-up и решения уровня disaster recovery при использовании глобальных облаков.

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

Резервирование

Избыточность — это предоставление функциональных возможностей, которые не нужны в безотказной среде. Он может состоять из компонентов резервного копирования, которые автоматически «включаются» при выходе из строя одного из компонентов. Например, большие грузовые автомобили могут потерять шину без каких-либо серьезных последствий. У них много шин, и ни одна из них не является критичной (за исключением передних шин, которые используются для управления, но обычно несут меньшую нагрузку каждая и в целом, чем остальные четыре — 16, поэтому вероятность выхода из строя ниже. ). Идея включения избыточности для повышения надежности системы была впервые предложена Джоном фон Нейманом в 1950-х годах.

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

Требования к интеграции

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

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

Интеграция через ESB

Интеграция через ESB (Enterprise Service Bus, «Сервисная шина предприятия») применяется для обеспечения информационных систем возможностями для взаимодействия с сервисами. Использование этого метода интеграции приложений обеспечивает слабую связанность между информационными системами, так как системы взаимодействуют не напрямую, а через сервисы, размещенные на сервисной шине предприятия.Основными функциями ESB являются:

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

Интеграция точка-точка

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

Интеграция данных

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

Задачи интеграции данных:

• Передачи больших объемов данных, включающая логику преобразования данных.
• Синхронизация (репликация) данных информационных систем

Интеграция ETL
Интеграция ETL характеризуется следующим сценарием:
На платформе ETL пишется процесс, который
1) С помощью средств доступа к БД 1ой системы забирает из таблиц 1ой системы данные
2) С помощью средств и ресурсов БД 1ой или 2й системы или своих собственных механизмов осуществляет преобразование к структурам таблиц 2й системы
3) Загружает данные в таблицы БД 2й системы.

Файловый обмен
Файловый обмен характеризуется следующим сценарием:
1) Приложение, которому требуется передать данные другому приложению, сохра¬няет их в файле.
2) Разрабатывается интеграционное решение, которое преобразует формат файла в формат, требуемый другим приложением. (В частном случае для этого дорабатывается одна из интегрируемых систем)
3) Приложение которому нужны данные, загружает подготовленный файл.

Как они рассчитываются

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

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

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

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

Как собираются функциональные и нефункциональные требования?

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

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

Функциональные требования можно разделить на три группы:

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

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

• удобство использования — определяет, насколько легко пользователь может взаимодействовать с интерфейсом приложения, например, цвет экрана, размер кнопок и т. д.;
• доступность — гарантирует, что приложение будет стабильно работать в течение определенного периода времени, например, редкие простои в течение года 24/7;
• надежность — определяет, что приложение будет работать в определенной среде или в течение определенного периода времени без сбоев;
• восстанавливаемость — гарантирует, что приложение сможет восстановить все данные после сбоя системы или восстановить систему до определенных параметров;
• масштабируемость — определяет, что приложение будет продолжать работать должным образом после изменения его размера или объема;
• производительность — оценивает, насколько быстро работает приложение;
• возможность поддержки — определяет, легко ли поддерживать и поддерживать приложение на протяжении всего его жизненного цикла, и какая поддержка ему требуется, например,
• собственная команда или удаленная поддержка;
• безопасность — определяет, насколько безопасным должно быть приложение, например, FinTech и банковские приложения должны соответствовать международным и региональным стандартам безопасности;
• емкость — оценивает объем данных или служб, которые может обрабатывать приложение.