Russian Federation
Russian Federation
Russian Federation
Russian Federation
This paper analyzes methods and tools for identifying and forming non-functional requirements for software that provides delivery of banking products in Russia.
System analysis, requirements, non-functional requirements, reliability, workload, courier services
В связи с очень быстрым развитием информационных технологий в финансовом секторе нашей страны, в банковской отрасли идёт конкуренция за каждого клиента. Сейчас любое физическое лицо может стать клиентом банка, буквально, за несколько минут, при помощи мобильного приложения. Помимо условий, которые предлагает кредитно-финансовое учреждение, клиенты банка обращают большое внимание на такие факторы, как удобство использования сайта или приложения, скорость обработки финансовых транзакций или запросов, надёжность за хранения персональных данных и т.п. Все эти факторы описывают нефункциональные требования к программному обеспечению. Разработка программного обеспечения для доставки банковских продуктов является актуальной задачей, требующей учета множества нефункциональных требований.
Нефункциональные требования или атрибуты качества - это определенные свойства программного обеспечения, которые описывают то, как, с какими нагрузками, производительностью и качеством должен работать разрабатываемый программный продукт. Ошибочная или неточная реализация нефункциональных требований может принести компании существенные финансовые убытки.
Целью данной статьи является рассмотрение методов и инструментов, предназначенных для выявления и проектирования нефункциональных требований к ПО, реализующему доставку банковских продуктов. В работе будут рассмотрены различные подходы к определению требований к качеству, а также примеры их реализации в банковских системах.
Способы выявления нефункциональных требований
На начальном этапе разработки программного обеспечения (ПО), системный аналитик выявляет нефункциональные требования путём проведения интервью, фокус-групп или опросов. Данные критерии качества являются исходными, и не гарантируют бесперебойной работы системы.Однако на данной стадии проектирования системы может быть не сразу понятно точное количество пользователей, которые будут пользоваться функционалом. Только после того, как готовый продукт выпускается в продуктовую среду, для тестирования ограниченным количеством реальных пользователей, нефункциональные требования могут быть скорректированы, для удовлетворения потребностей всех клиентов банка.
Также, в последние годы, финансовые организации выпускают сезонные фичи и продукты, например, кредит на образование. Данный функционал активно используется клиентами не весь год, поэтому компании могут корректировать нефункциональные требования к ПО, чтобы использовать дополнительные ресурсы только тогда, когда это необходимо.
Виды нефункциональных требований
Доступность характеризует процент от всего времен работы информационной системы, в течение, которого она должна работать без технических проблем и сбоев. Другими словами, доступность системы рассчитывается как процентное соотношение времени, когда система работает стабильно, к временному интервалу, в течении которого происходят инциденты. В финансовой отрасли уровень доступности того или иного программного обеспечения зависит от критичности продукта. Например, сервис, который обрабатывает финансовые транзакции или переводы должен быть доступен, почти, девяносто девять процентов всего времени. В то время, как сервис по предоставлению информации всех отделений банка, может иметь доступность в девяносто семь процентов.
Надёжность — это требование к качеству ИС, описывающее процесс восстановления работоспособности систем после инцидента, сбоя или аварии.
Под надёжностью понимается автоматическое переключение основного потока входящих запросов на рабочих ноды кластера, в котором развёрнут сервис, автоматический перезапуск системы после падения системы или сохранение данных в случае аварийных ситуаций. Также необходимо учитывать дублирование критичных данных, которые могут быть потеряны, в случае падения сервиса. Для обеспечения своевременного обеспечения надёжности и доступности программного обеспечения, в ходе системного анализа и проектирования ИС настраиваются алерты или оповещения группы сопровождения. Оповещения в информационной системе — это уведомления или предупреждения, которые отправляются при возникновении события или состояния, требующего внимания. Эти оповещения могут быть вызваны различными причинами, такими как системные ошибки, угрозы безопасности или проблемы с производительностью. Для дублирования данных могут использоваться базы данных или другие виды хранилищ, информация из которых, после восстановления системы, должна реплицироваться в основной источник, для поддержания консистентности данных.
Масштабируемость — это способность или возможность информационной системы обрабатывать большее количество транзакций, или работать с большей нагрузкой. Масштабируемость может быть достигнута двумя способами: с помощью вертикального масштабирования, когда система увеличивает или уменьшает свою производительность путем изменения количества ресурсов на одном сервере, или горизонтальной, когда производительность увеличивается или уменьшается путем добавления или удаления серверов.
Вертикальное масштабирование предназначено для более быстрой адаптации программного обеспечения под увеличивающиеся потребности со стороны пользователей или бизнеса. Это достигается путём увеличения ресурсов и производительности на уже имеющимся оборудовании. Данный вариант масштабирования имеет несколько узких мест, а именно:
- При достижении лимита производительности, всё равно придётся применять горизонтальное масштабирование.
- Необходимо тщательно контролировать нагрузку и балансировку входящих запросов, во избежание падения сервисов.
Горизонтальное масштабирование позволяет увеличить качество и производительность работы системы при помощи добавления новых узлов и инстансов серверов, т.е. добавлением железа. У горизонтального масштабирования есть множество преимуществ, в сравнении с вертикальным:
- При падении или сбое на одном узле, весь входной поток запросов переправляется на другой узел, без потери данных.
- Отсутствует необходимость в миграции инфраструктуры.
- В данном случае не требуется дорогое оборудование, для бесперебойной обработки данных при пиковых нагрузках.
Производительность информационной системы определяет количество обрабатываемых операций или запросов за определённый промежуток времени. Производительность связана с такими характеристиками программного обеспечения, как пропускная способность и задержка. Пропускная способность показывает сколько одновременно получаемых на входе запросов может обработать система за определённый промежуток времени. Задержка, наоборот, демонстрирует среднее время исполнения одного запроса. Увеличение качества производительности может быть достигнуто с помощью оптимизации кодовой базы, перераспределения
нагрузки на другие инстансы или кэширования часто используемых данных.
Для того, чтобы определить уровень производительности информационной системы, необходимо рассчитать количество успешно обрабатываемых операций или запросов за определённый промежуток времени, обычно, за секунду.
Удобство использования — это требование к качеству программного обеспечения, которое предполагает удовлетворение всех требований основного пользователя. Оно заключается в создании качественного функционала клиентской части программного обеспечения и подразумевает понятный интерфейс, позволяющий клиенту легко использовать весь функционал без проблем и инструкций. Чтобы понять, насколько качественно проработан дизайн приложения или сайта, необходимо проанализировать отзывы клиентов и обращения в службу поддержки.
Безопасность – характеристика системы, которая очень важна в современном мире. В финансовом секторе предъявляются очень жёсткие требования и правила реализации информационной безопасности. Почти все банковские сервисы хранят или проксируют через себя персональные данные потенциальных и действующих клиентов, которые в любой момент могут быть скомпрометированы злоумышленниками.
Для обеспечения безопасности ПО необходимо учитывать следующие принципы для предотвращения любых несанкционированных попыток получения персональных данных клиента:
- Использование надежных паролей и методов аутентификации;
- Шифрование и маскирование данных при передаче и хранении;
- Использование ролевой модели, при работе ПО;
- Мониторинг, логирование и аудит действий пользователей.
Уровень текущей безопасности ПО можно оценить количеством неуспешных атак на систему.
В заключении следует отметить, что нефункциональные требования описывают не то, «что» система должна делать, для удовлетворения основных потребностей пользователя, а «как» система должна выполнять те или иные операции. Учет этих требований на ранних этапах проектирования позволяет создать более эффективную и надежную систему, которая сможет адаптироваться к изменяющимся требованиям и условиям эксплуатации, а также сократить убытки в ходе эксплуатации программного обеспечения.
1. Lavlinskiy, V.V. Teoreticheskie osnovy formirovaniya modeley i metodov vzaimodeystviya informacionnyh processov / V. V. Lavlinskiy, I. I. Strukov // Modelirovanie sistem i processov. – 2018. – T. 11, № 2. – S. 31-37.
2. Harakterizaciya i modelirovanie signalov v SAPR / V. A. Sklyar, V. K. Zol'nikov, A. I. Yan'kov [i dr.] // Modelirovanie sistem i processov. – 2018. – T. 11, № 1. – S. 62-67.
3. Nasyrov, R. V. Sistemnyy analiz problem nauchno-tehnicheskogo napravleniya «Medicinskie sistemy avtomatizirovannogo proektirovaniya» / R. V. Nasyrov, O. S. Tiunov, I. S. Tiunov // Modelirovanie sistem i processov. – 2020. – T. 13, № 4. – S. 38-52.
4. Suhanov, V. V. Analiticheskoe obespechenie organizacii dannyh v raspredelennyh informacionnyh sistemah kriticheskogo primeneniya / V. V. Suhanov // Modelirovanie sistem i processov. – 2021. – T. 14, № 3. – S. 60-67. – DOI:https://doi.org/10.12737/2219-0767-2021-14-3-60-67.
5. Vigers, K. Razrabotka trebovaniĭ k programmnomu obespecheniyu. – 3-e izd., dopolnennoe / K. Vigers, Dzh. Bitti / per. s angl. – SPb. : BHV-Peterburg, 2014. – 736 s.
6. Eliferov V. G. Biznes-processy: reglamentaciya i upravlenie : uchebnik / V. G. Eliferov, V.V. Repin. – M. : INFRA-M, 2017. – 319 s.
7. K voprosu o raspredelenii resursov v informacionnoy sisteme / M. A. Ivanovskiy, N. G. Shahov, Yu. V. Kulakov, V. V. Sevenyuk // Modelirovanie sistem i processov. – 2018. – T. 11, № 2. – S. 16-24.
8. Utkin, D. M. Ocenka nadezhnosti programmno-tehnicheskih kompleksov special'nogo naznacheniya / D. M. Utkin, V. K. Zol'nikov // Modelirovanie sistem i processov. – 2018. – T. 11, № 2. – S. 78-84.
9. Poluektov A. V., Makarenko F. V., Yagodkin A. S. Ispol'zovanie storonnih bibliotek pri napisanii programm dlya obrabotki statisticheskih dannyh // Modelirovanie sistem i processov. – 2022. – T. 15, № 2. – S. 33-41.
