CC BY
15ВЫЧИСЛИТЕЛЬНЫЕ СИСТЕМЫ
УДК 004.052.2
Модуль оценки реализации требований к специальному программному обеспечению
Ли Ю.Е., Васильев Н.В., Горбачев И.М., Прокопович Ю.В., Раков ИВ.
Аннотация. Постановка задачи: современные специальные автоматизированные системы представляют собой сложные аппаратно-программные комплексы, создание которых сопряжено с высокой нагрузкой на персонал не только на этапах проектирования и разработки, но и развертывания и ввода в эксплуатацию. Основным фактором высокой нагрузки являются ошибки, допускаемые на стадиях проектирования и разработки. Для автоматизации процессов контроля исправления ошибок широкое распространение получили системы автоматизации тестирования, баг-трекинга и управления процессом разработки. Однако, большинство указанных инструментов являются инструментами разработчиков и руководителей нижнего звена. Инструменты интегральной оценки степени зрелости специального программного обеспечения отсутствуют, хотя польза подобного рода программных средств несомненна. Цель работы: разработка прототипа модуля для оценки реализации требований к специальному программному обеспечению. Используемые методы: в основу модуля были положены методики международного стандарта ISO, уточненного требованиями, предъявляемыми к специальному программному обеспечению. Новизна и практический результат: состоит в автоматизации процесса экспертной оценки качества специального программного обеспечения как с точки зрения разработчиков, так и с точки зрения конечных пользователей. Предлагаемый модуль позволяет повысить степень соответствия защищенных программных продуктов предъявляемым функциональным требованиям.
Ключевые слова: качество программного обеспечения, модели оценки качества программного обеспечения, метрики оценки качества программного обеспечения, Redmine.
Актуальность
Качество программного обеспечения (ПО) является критически важным в системах специального и двойного назначения, в которых ущерб от ошибок может быть весьма велик. Под термином «специальное программное обеспечение» (СПО) в данной работе понимается ПО, обеспечивающее поддержку повседневной и боевой деятельности силовых ведомств Российской Федерации. Безопасность и надежность такого ПО, помимо стандартных процедур авторизации и аутентификации, дополняется процедурами обеспечения изолированного хранения и обработки данных группами пользователей, обладающих различными правами.
В настоящее время [1-3] автоматизация процесса разработки ПО базируется на системах контроля исполнения задач, системах контроля версий, системах управления ошибками (баг-трекинг), системах управления тестированием и системах сборки и развертывания программного обеспечения. В ПАО «Интелтех» для управления проектами и задачами используется система с открытым исходным кодом Redmine, которая относится к системам постановки и контроля исполнения задач. Проведенный авторами анализ рынка средств управления разработкой [4], [5] программного обеспечения, в частности расширений (плагинов) для Redmine, показывает отсутствие средств анализа уровня зрелости ПО, что обуславливает актуальность задачи разработки и реализации такого модуля.
Постановка задачи
Рассмотрим основные особенности системы Redmine и возможности ее использования на предприятии. Жизненный цикл задач в ПАО «Интелтех» в терминологии Redmine приведен на рис. 1.
Рис. 1. Схема жизненного цикла задачи в системе Яейште, используемая ПАО «Интелтех»
На основании спецификации требований руководитель проекта создает задачи вида (трекера) «Функционал». Разработчики-исполнители, реализовав задачу, выставляют статус «Решена» (рис. 2).
в 230 Функционал Новая Низкий Добавить отладочную информацию на DCS сервер Иван Горбачёв 10 06.2019 15:38 ...
в 227 Функционал Решена Нормальный Рефакторинг взаимодействия с подсистемой CRM Павел Иванов 10 06.2019 13:40 ...
в 215 Функционал Новая Нормальный Разработка документации и описания компонента CRM Павел Иванов 22 05.2019 17:40 ...
Рис. 2. Примеры задач с трекером «Функционал»
По мере реализации функционала производится тестирование. В спецификации требований указывается перечень необходимых для проверки тестовых наборов. Тестовый набор (test case), представляет собой список необходимых действий, ожидаемый и фактический результат. Тесты также оформляются в виде задач трекера «Тест». Задача считается исполненной, когда соответствующий тест пройден. Если тестовый набор не пройден, то создается новая задача с трекером «Ошибка». После чего проверяется ее исправление. Все тестовые наборы запускаются каждый раз при необходимости проверки нового функционала. Зачастую пройденный тестовый набор при внесении или изменении функционала может указывать на появление дефектов. В этом случае ошибка, которая уже была исправлена, повторно открывается, т. е. в отношении её устанавливается статус «Открыта повторно».
Как было указано, Redmine в типичном варианте развертывания является инструментом контроля исполнительской дисциплины. Задача интегральной оценки степени зрелости программного обеспечения, решаемая средним и верхним звеном управления, коробочной версией Redmine не решается. Однако гибкая, настраиваемая архитектура системы позволяет создавать модули-расширения Redmine для решения указанной задачи.
Разработка прототипа модуля
В рамках прототипа модуля были реализованы группы внутренних и внешних метрик надежности стандарта ISO 9126 [6-10] (см. табл.1).
Таблица 1 - Примеры внутренних и внешних метрик надежности
Виды метрик Формула расчета Исходные данные
Внутренние метрики Адекватность теста X = А/В А = Число тест-кейсов, разработанных в тест-плане. В = Количество требуемых по спецификации требований тест-кейсов (согласно со спецификацией требований).
Коэффициент отказов X = А/В А = Число исключений, явно предотвращенных сначала на этапе проектирования, потом на этапе разработки. В = Общее число исключений, которое необходимо учитывать (согласно со спецификацией требований).
Способность к предотвращению некорректных действий X = А/В А = Число некорректных действий, заранее разработанных для предотвращения. В = Число задач, которые должны быть разработаны для предотвращения некорректных действий (согласно со спецификацией требований).
Восстанавливаемость X = А/В А = Число гвМогаЬПИу (восстанавливаемости) тестов, которые были решены. В = Общее число гв&1огаЬШ(у (восстанавливаемости) тестов, которые были прописаны в спецификации требований (согласно со спецификацией требований).
Соответствие надежности X = А/В А = Количество правил, которые соблюдаются. В = Количество общих правил, стандартов и конвенций, которые применяются к системе (согласно со спецификацией требований).
Внешние метрики Оцениваемая плотность скрытых ошибок X = К" М В А1 = Планируемое количество ошибок. А2 = Количество реально обнаруженных ошибок. В = Количество строк кода.
Плотность ошибок по отношению к тест-кейсам X = А1/А2 А1 = Количество обнаруженных ошибок во время выполнения тест-кейсов. А2 = Количество выполненных тест-кейсов.
Внешние метрики Плотность ошибок X = А1/В А1 = Количество обнаруженных ошибок. В = Количество строк кода.
Разрешение отказов X = а1/А2 А1 = Количество отказов, которые удалось разрешить, и они больше никогда не появлялись. А2 = Общее количество фактически обнаруженных ошибок.
Обнаружение ошибок X = А/В А = Число обнаруженных ошибок. В = Планируемое число ошибок (вводит менеджер проекта в паспорт проекта).
Устранение ошибок X = А/В А = Число устранённых ошибок на этапах проектирования и реализации. В = Число ошибок, найденных во время проверки ПО.
Тестовое покрытие X = А/В А = Количество фактически выполненных тестов, которые отображают сценарий эксплуатации во время испытаний. В = Количество тестов, которые необходимо выполнить, чтобы удовлетворить требованиям.
Завершенность испытаний X = А/В А = Количество пройденных во время испытаний или эксплуатации тестовых примеров. В = Количество тестовых примеров, которые необходимо выполнить, чтобы удовлетворить требованиям.
Коэффициент аварийных отказов X = 1 - А/В А = Количество аварийных отказов. В = Количество отказов.
Коэффициент отказов X = А/В А = Количество случаев критических и серьезных отказов, которых удалось избежать, в сравнении с тестовыми наборами, направленными на проверку типовых ошибок. В = Количество выполненных тестовых наборов, направленных на проверку типовых ошибок, которые могут привести к отказам.
Способность к предотвращению некорректных действий X = А/В А = Количество случаев критических и серьезных отказов, которых удалось избежать. В = Количество выполненных тестовых наборов, направленных на проверку некорректных действий, которые могут привести к отказам.
Архитектура модуля, реализующего приведенный набор метрик, показана на рис. 3. Пользователям модуля соответствуют роли с назначенными правами в системе Redmine. Авторизация и аутентификация пользователей решается средствами службы каталогов LDAP. Графический интерфейс модуля предоставляет пользователям функции выбора проектов для оценки, расчета метрик, формирования отчётов и поддержки принятия решений по оценке степени зрелости программного продукта. Ядро обработки является связующим звеном между всеми частями модуля. Он получает запрос на вывод рассчитанных метрик, посылает запрос в базу данных (БД) Redmine, пересылает данные в Сервер расчета метрик и представляет результаты обработки пользователю. Сервер расчета метрик хранит перечень метрик и осуществляет их расчет: получив на вход данные по проектам и настройки метрик, он рассчитывает выбранные метрики и передает результаты расчетов ядру обработки. В БД локальных параметров хранятся данные по проектам, которых нет в Redmine и их необходимо вводить вручную. Примерами таких параметров являются: количество строк кода и предполагаемое количество ошибок.
Рис. 3. Схема архитектуры решения
Как уже говорилось ранее, для прототипа модуля были выбраны метрики оценки надежности специального программного обеспечения. Помимо надежности, ISO 9126 включает в себя еще 5 типов метрик: функциональность, удобство использования, производительность, удобство сопровождения и переносимость. В сумме все эти типы составляют более 80 метрик. Для упрощения добавления в будущем новых метрик, было принято решение использовать компонентный подход в разработке. При таком подходе каждая метрика является отдельным компонентом. На рис. 4 приведена схема сервера расчета метрик. На данном этапе прототип модуля не предусматривает такого пользователя, как администратор, но в будущем планируется его добавить.
Администратор сможет добавлять новые метрики через клиентское приложение пополнения репозиториев. Новая метрика обрабатывается компонентом «Менеджер пополнения репозиториев» и добавляется в репозиторий метрик. В клиентском и серверном компонентах происходит взаимодействие с помощью сервера расчёта метрик с внешними подсистемами, хранящими данные по проектам. Данными системами являются Redmine, TestLink, Github и прочие. Клиентский компонент отправляет запрос на вывод списка метрик на серверный компонент, а также вызывает отдельные метрики. Серверный компонент взаимодействует с компонентом «планировщик задач», отправляя ему идентификатор метрики и ее параметры, взамен получая результаты расчёта. Планировщик задач узнает способ расчета метрики в репозитории и запускает у себя ее расчет.
Рис. 4. Схема сервера расчета метрик
Выводы
По результатам пробной эксплуатации прототипа модуля сделаны следующие выводы:
1) модуль является полезным инструментом в случае аккуратного описания постановок задач и достаточно высокой исполнительской дисциплины в системе управления задачами и проектами Redmine;
2) перечень реализуемых метрик охватывает только стадию проектирования и разработки СПО. Оценка зрелости на стадии развертывания и эксплуатации требует интеграции с системой управления пользовательскими заявками и системами мониторинга локальных сетей.
Примеры экранных форм разработанного прототипа можно увидеть на рис. 5.
PeiyT*r*ppou»« Ф*ф««»иут( г--.. " Восстанавливаемость 4»
Оцпмыпш ПЛС ттность скрытых ошибок Внутренние метрики МЯИ»«ЛЖЧ ♦
Плотность ошибок отношению к тест-кейсам Внешние метрики 06м4руже»М* ошибок —
_____ устранение ошибок —
1ZZZZZ—»
Коэффициент огкаюя
Предог«р*мет« «корр. действий -
Рис. 5. Примеры работы модуля
Литература
1. Pitterman B. Telcordia technologies: the journey to high maturity. IEEE Softw. 2000.
2. Yamamura G. Software process satisfied employees. IEEE Softw, no September/October. 1999.
3. Sommerville I. Software Engineering. 9th ed. UK: Addison Wesley. 2010.
4. Staples M, Niazi M. Systematic review of organizational motivations for adopting CMM-based SPI. Inform Softw Tech J. 2008.
5. CMMI® for Development, Version 2.0, 2018.
6. Zahran S. Software Process Improvement: Practical Guidelines for Business Success. USA: Addison-Wesley Professional; 1998.
7. Paulk MC. The Capability Maturity Model: Guidelines for Improving the Software Process (SEI Series in Software Engineering). USA: Addison-Wesley Pub. Co. 1995.
8. Honda N, Yamada S. Empirical analysis for high quality software development. Am J Oper Res. 2012.
9. Maibaum T, Wassyng A. A product-focused approach to software certification. Computer. 2008.
10. Rodriguez M, Oviedo JR, Piattini M. Evaluation of software product functional suitability: a case study. Software Quality Professional; Milwaukee. 2016.
Статья поступила 15 июля 2019 г.
Информация об авторах
Ли Юлия Евгеньевна - Инженер-программист ПАО «Интелтех». Область научных интересов: мониторинг информационных ресурсов; сбор и обработка информации. Тел.: +7 (812) 295-50-69. E-mail: [email protected].
Васильев Николай Владимирович - Начальник сектора ПАО «Интелтех». К.т.н. Область научных интересов: корпоративные информационные системы; распределенные системы обработки информации и управления. Тел.: +79111202622. E-mail: [email protected].
Горбачев Иван Михайлович - Начальник сектора ПАО «Интелтех». Область научных интересов: специальные системы обработки информации и управления. Тел.: +7 (812) 295-50-69. E-mail: [email protected].
Прокопович Юлия Владимировна - Начальник сектора ПАО «Интелтех». Область научных интересов: специальные системы обработки информации и управления. Тел.: +7 (812) 295-50-69. E-mail: [email protected].
Раков Игорь Васильевч - Начальник научно-исследовательского отделения ПАО «Интелтех». К.т.н. Область научных интересов: корпоративные информационные системы; управление качеством разработки информационных систем. Тел.: +7 (812) 295-50-69. E-mail: [email protected].
Адрес: 197342, г. Санкт-Петербург, ул. Кантемировская, д.8.
Module for evaluating the implementation of special software requirements
Y.E. Li, N.V. Vasiliev, I.M. Gorbachev, Y.V. Prokopovich, I.V. Rakov
Annotation. Problem statement: Modern special automated systems are complex hardware and software systems, the creation of which is associated with a high workload for personnel not only at the design and development stages, but also during deployment and commissioning. The main factor of high load are errors made at the design and development stages. To automate control processes for fixing bugs, systems for testing automation, bug tracking and development process control are widely used. However, most of these tools are tools of developers and lower managers. There are no tools for integrated assessment of the degree of maturity of special software, although the usefulness of such software is undoubted. Objective: to develop a prototype module for evaluating the implementation of requirements for special software. Used methods: The module was based on the methods of the international standard ISO, specified by the requirements for special software. Novelty and practical result: consists in automating the process of expert evaluation of the quality of open source software both from the point of view of developers and from the point of view of end users. The proposed module allows you to increase the degree of compliance ofprotected software products with the functional requirements.
Keywords: software quality, software quality assessment models, software quality assessment metrics.
Information about Authors
Li Y.E. - Software engineer of PJSC «Inteltech». Research interests: monitoring of information resources; collection and processing of information. Tel.: +7 (812) 295-50-69. E-mail: [email protected].
Vasiliev N.V. - Head of Sector of PJSC «Inteltech». Ph.D. Research interests: corporate information systems; distributed information processing and management systems. Tel.: +79111202622. E-mail: [email protected].
Gorbachev I.M. - Head of Sector of PJSC «Inteltech». Research interests: special information processing and management systems. Tel.: +7 (812) 295-50-69. E-mail: [email protected].
Prokopovich Y.V. - Head of the sector of PJSC «Inteltech». Research interests: special information processing and management systems. Tel.: +7(812)295-50-69. E-mail: [email protected].
Rakov I.V. - Head of Research and Development of PJSC «Inteltech». Ph.D. Research interests: corporate information systems; quality management of the development of information systems. Tel.: +7(812)295-50-69. E-mail: [email protected].
Address: 197342, St. Petersburg, ul. Kantemirovskaya, 8.
Для цитирования: Ли Ю.Е., Васильев Н.В., Горбачев ИМ., Прокопович Ю.В., Раков ИВ. Модуль оценки реализации требований к специальному программному обеспечению // Техника средств связи. 2019. № 4 (148). С. 45-50.
For citation: Li Y.E., Vasiliev N.V., Gorbachev I.M., Prokopovich Y.V., Rakov I.V. Module for evaluating the implementation of special software requirements // Means communication equipment. 2019. № 4 (148). P. 45-50. (In Russian).
