CC BY
285
Программные продукты и системы /Software & Systems
№ 4 (108), 2014
УДК 681.3 Дата подачи статьи: 25.07.2014
DOI: 10.15827/0236-235X.108.229-233
МЕТОДЫ ВЕРИФИКАЦИИ И ВАЛИДАЦИИ СЛОЖНЫХ ПРОГРАММНЫХ СИСТЕМ
А.А. Демин, ассистент, [email protected];
А.А. Карпунин, ассистент, [email protected];
Ю.М. Ганев, лаборант-исследователь, [email protected] (Московский государственный технический университет им. Н.Э. Баумана, ул. 2-я Бауманская, 5, г. Москва, 105005, Россия)
В работе рассмотрены проблемы разработки широкомасштабных программных комплексов. Показана необходимость использования специализированных систем для контроля качества конечного продукта. Предложен алгоритм проверки на соответствие эталонам и нормам, а также на выполнение пользовательских требований в условиях совместного проектирования и разработки программного изделия. Представлены основные преимущества специальных программных средств для проведения валидации и верификации перед остальными методами оценки и проверки на соответствие стандартам программных систем.
Материал статьи ориентирован в первую очередь на разработчиков программного обеспечения и руководителей производственных подразделений, желающих автоматизировать процесс обзора и проверки кода в рамках командной работы над ним. Также он будет полезен специалистам отдела обеспечения качества, стремящимся сократить трудозатраты на этапе тестирования, находить ошибки в программном коде на самых ранних этапах жизненного цикла систем. Актуальность статьи обусловлена использованием современных методов обеспечения гибкости и прозрачности процесса разработки программного кода, позволяющих сократить сроки разработки, повысить качество и надежность процесса, снизить издержки, привести весь программный код к единому стилевому оформлению и усовершенствовать механизмы взаимодействия внутри команды, способствуя развитию взаимодоверия членов групп разработки и тестирования.
Ключевые слова: качество программных изделий, технологии совместного проектирования и разработки, автоматизация процесса проверки кода.
С усложнением проектируемых систем инспекция, или обзор кода, приобретает все большее значение для программистов, менеджеров и заказчиков. При разработке сложных систем, задействующих большое количество ресурсов, качество программного кода оказывает большое влияние на качество проектируемой системы [1]. Применительно к управлению качеством зачастую используются термины «верификация» - подтверждение соответствия нормам, стандартам и «валидация» -проверка на соответствие требованиям и нуждам заказчика [1-4].
Классификация методов верификации кода представлена на рисунке 1.
Инспекция с помощью специальных средств появилась относительно недавно, однако активно развивается и внедряется различными компаниями. Среди методов управления и инспекции можно отметить визуальные методы [5-7], методы реинжиниринга кода и его сертификации [8, 9].
Одним из таких специальных средств является инструмент фирмы Atlassian - Crucible, а также FishEye.
В данной статье описана работа системы Atlassian Crucible. Code review - это процесс анализа и проверки кода, проводимый с целью выявления ошибок в его написании, стилевых недочетов, а также соответствия написанного кода поставленной задаче. Часто Code Review выполняется старшими разработчиками для контроля за работами по написанию кода. Использование спе-
циальных средств для проведения обзора кода делает процесс более гибким и надежным.
Code Review помогает привести весь код к единому стилевому оформлению, позволяет быстро выявить опечатки, совершенствует навыки командной работы, что очень полезно для начинающих разработчиков [2].
Анализ системы Atlassian Crucible
Пакет Crucible предлагает разработчикам удобные и эффективные инструменты для взаимного рецензирования кода. В новой версии пакета реализована концепция так называемого итера-
Формальные Парное
инспекции Способы верификации программи- рование
кода
Инспекция через плечо \ Верификация кода
1 Г с помощью e-mail
Инспекция
с помощью специальных средств
Рис. 1. Классификация методов верификации кода Fig. 1. Code verification methods classification
229
Программные продукты и системы /Software & Systems
№ 4 (108), 2014
тивного рецензирования (iterative code review), когда один и тот же участок кода подвергается многократному рецензированию и переработке. С помощью Crucible процедура рецензирования всегда останется простой и действенной, несмотря на постоянные изменения в условиях разработки.
Веб-интерфейс пакета Crucible предлагает простые и быстрые инструменты для создания новых заметок к коду. Для дополнительного удобства поддерживаются навигация в заметках с помощью клавиатуры, изменение параметров отображения и вставка комментариев напрямую в код. Для интеграции с существующими процедурами комментирования кода пакет Crucible поддерживает загрузку уже созданных замечаний к коду из таких систем управления версиями, как Subversion, Perforce, Git и ClearCase. Синхронизация новых замечаний (Pre-commit) поддерживается абсолютно для всех платформ. Кроме всего прочего, пакет Crucible отлично интегрируется со вспомогательными инструментами разработчика FishEye и JIRA, со средами разработки Eclipse и IntelliJ, а также с любыми другими инструментами, поддерживающими интерфейс REST (Representational State Transfer) API с четырьмя базовыми операциями (GET, PUT, POST и DELETE) или работу с плагинами.
Рассмотрим работу в Crucible более подробно. В большинстве случаев разработка какого-либо продукта проходит три базовые стадии (рис. 2). Однако в последнее время все чаще разработчики добавляют еще одну стадию, которая называется Review (рис. 3).
To do \
Новое задание, не принятое в работу
In progress'
Задача находится в разработке
Done
Задача выполнена
Рис. 2. Базовые стадии работы Crucible Fig. 2. Basic stages of Crucible work
I
To do
~In piogiesS^_^ Review^ ^ Done ^
Рис. 3. Расширенные стадии работы Crucible Fig. 3. Extended stages of Crucible work
Смысл ее в том, что перед окончанием определенного задания или какого-либо компонента кода как минимум еще один член команды должен просмотреть всю сделанную работу. В случае обнаружения ошибок задание возвращается на стадию In progress. Таким образом, качество кода заметно улучшается.
Анализ основных операций системы Atlassian Crucible
С помощью инструмента Crucible над кодом можно совершить три различные операции. Рассмотрим каждую из них.
Обзор части кода (snippet review) - это простая операция, позволяющая вставить в специальное поле какой-либо код и тут же обсудить его с коллегами. Комментарии будут привязаны к строкам фрагмента кода (см. http://www.swsys.ru/up-loaded/image/2014-4-dop/4.jpg).
В данном режиме имеется возможность комментировать каждую строчку кода. Такой способ удобен для выбора и поиска какого-либо оптимального программного решения.
Дискуссия вокруг ревизии (changeset discussion) - функция, позволяющая кому угодно из команды комментировать любую ревизию из репозитория. Авторы и другие члены команды тут же получат уведомления о новых комментариях (http://www.swsys.ru/uploaded/image/2014-4-dop/5.jpg). На форме слева показаны комментарии и общая информация, а справа - все изменения, которые были сделаны во всех измененных файлах. На экран выводятся только изменения. Также доступна общая информация о ревизии.
Подробный анализ кода (formal code review) - это основная функция Crucible. Для создания review необходимо указать одного или нескольких участников обзора (ревьюеры, reviewers), дату окончания обзора (дэдлайн), объект просмотра ревьюерами.
Каждый ревьювер должен просмотреть все указанные файлы и после этого закрыть review, иначе автор обзора не сможет завершить его. На форме (http://www. swsys.ru/uploaded/image/2014-4-dop/6.jpg) слева находится список всех файлов, которые изменил автор в рамках данной ревизии. Reviewer может оставить комментарий ко всему обзору (general comment), к одному определенному файлу или к строке кода.
Пакет FishEye представляет собой инструмент для удобной навигации в репозитории исходного кода. Инструменты пакета FishEye помогают отслеживать все действия пользователей, вносящих свой код в репозиторий. Например, можно отследить и сравнить активность отдельных пользователей, оценить объем кода, каждый день попадающего в репозиторий, а также исследовать сам код внутри репозитория с учетом информации об авторе, времени внесения и других атрибутов.
Пользователь пакета FishEye может с помощью любого стандартного веб-браузера вступить в активноe взаимодействие с участниками своего проекта. Веб-интерфейс FishEye позволяет обмениваться кодом, а также открывает доступ к дополнительным инструментам для оценки кода. Данная система часто используется совместно с Crucible.
230
Программные продукты и системы /Software & Systems
№ 4 (108), 2014
Маршрут разработки программного модуля для системы Atlassian Crucible
Для сверки скриптов из различных веток репозитория проекта с возможностью выбора источника сверки при создании новой задачи Code Review используется модуль Crucible. Он обеспечивает ведение переписки изменений и доработок по скриптам проекта в единой системе Code Review,
позволяет осуществлять выгрузку задачам Code Review (рис. 4). статистики
Rev 4 Branch
Rev_1 Rev 2 / Rev 5 Trunk
\ \ Rev_3 Branch_
Рис. 4. Ответвления от рабочей версии программы Fig. 4. Program run-time version branching-off
На данный момент при использовании компонентов Crucible и FishEye разработчики не могут сравнивать изменения ответвления (branch) с текущей рабочей версией программы (trunk). Это лишает возможности проводить полный цикл Code Review непосредственно в рамках системы Crucible. Ответственному за Code Review приходится дополнительно сверять branch и trunk с использованием отдельной системы контроля версий и вести переписку с использованием почты с группой разработчиков.
Все описанные действия не позволяют автоматизировать сбор статистики по задачам Code Review, проследить количество затраченного времени и оценить качество проведения Code Review ответственной группой. Следует отметить основные возможности программы:
- сравнение версий скриптов различных веток репозитория;
- добавление комментариев по замечаниям, возникшим при Code Review, между разработчиком и ответственным за Code Review непосредственно в задаче;
- автоматизация выбора эталонной ветки (trunk) на этапе создания/изменения проекта и прикрепление к нему определенного репозитория;
- выбор альтернативной ветки проекта (branch) для проведения сверки между двумя различными проектами, разрабатываемыми в едином репозитории;
- оповещение участников Code Review об изменениях по электронной почте.
При выборе репозитория и эталонной версии программы (trunk) после заполнения поля Repository становится доступным список файлов, относящихся к репозиторию (дерево репозитория) (http://www.swsys.ru/uploaded/image/2014-4-dop/7.jpg).
Далее постановщик может добавить дополнительные скрипты к уже заведенной задаче. При этом все скрипты и действия, проведенные с ними в процессе Code Review, должны остаться без изменений. После окончания процесса добавления скриптов открывается интерфейс задачи, в который вносятся правки (схематично примеры приведены на рис. 5-7).
Список параметров репозитория
Дерево репозитория Настройки ревизии выбранного скрипта
Done Cancel
Рис. 5. Выбор репозитория и эталонной версии программы
Fig. 5. Choosing a repository and a program master version
Номер задачи и проект
Время, затраченное на задачу
Элементы интерфейса для дополнения списка скриптов Описание параметров задачи
Дерево скриптов, добавленных к Code Review
Таблица скриптов, отобранных для Code Review с помощью плагина
Рис. 6. Интерфейс задачи Fig. 6. Task interface
При завершении редактирования можно выполнить операцию сравнения выбранных веток.
Таким образом, появляется возможность сравнения двух скриптов, относящихся к разным веткам программы, чего не позволял сделать стандартный функционал продукта Atlassian Crucible.
Рассматривая вопросы качества программного обеспечения, необходимо не ограничиваться рамками отдельных процессов жизненного цикла. Качество программного обеспечения является постоянным объектом внимания программной инженерии и обсуждается во многих областях знаний [10-12].
В ходе анализа инструментов для совместного проектирования и разработки сложных программных комплексов Atlassian Crucible и Atlassian
231
Программные продукты и системы /Software & Systems
№ 4 (108), 2014
Полное название скрипта Полное название проверяемого
бражение факта наличия расхождений эталона с указанием адреса скрипта с указанием адреса
и ревизии и номера ревизии
Информация о состоянии Информация о состоянии
скрипта скрипта
Номера строк I Текст скрипта Скролл вертикальный | Номера строк | Текст скрипта Скролл вертикальный |
6
Скролл горизонтальный Скролл горизонтальный
Окно комментариев
Рис. 7. Сравнение ответвлений программного продукта
Fig. 7. Comparing software product branches
FishEye продемонстрированы их основные возможности и проведен их сравнительный анализ. Рассмотрена проблема отсутствия функционала для сравнения нескольких версий одной программы, относящихся к различным веткам проектирования, и предложено ее решение. Данный механизм призван автоматизировать и упростить процесс верификации и валидации программного кода, что является немаловажным плюсом для любой команды разработчиков сложной программной системы.
Литература
1. Блэк Р. Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование. М.: Лори, 2006. 566 с.
2. Вигерс К. Разработка требований к программному обеспечению; [пер. с англ.]. М.: Русская редакция, 2004. 576 с.
3. Иванов А.М., Власов А.И. Верификация программных моделей коммуникационных сетей // Наука и образование: электронное научно-техническое издание. 2012. № 10. С. 24.
4. Власов А.И., Лыткин С.Л., Яковлев В.Л. Краткое практическое руководство разработчика по языку PL/SQL. М.: Машиностроение. 2000. Т. 2. 64 с. (Библиотека журн. «Информационные технологии»).
5. Власов А.И. Пространственная модель оценки эволюции методов визуального проектирования сложных систем // Датчики и системы. 2013. N° 9. С. 10-28.
6. Власов А.И., Цыганов И.Г. Адаптивная фильтрация информационных потоков в корпоративных системах на основе механизма голосования пользователей // Информационные технологии. 2004. № 9. С. 12-19.
7. Власов А.И., Цыганов И.Г. Архитектура корпоративной многоагентной автоматизированной системы фильтрации информационных потоков // Информационные технологии. 2005. № 1. С. 34-41.
8. Doar M. Practical Development Environments. USA, O'Reilly Media Publ., 2005, 330 p.
9. Бритов Г.С. Верификация, валидация и тестирование компьютерных моделей линейных динамических систем // Ин-формационно-управляющие системы. 2013. Вып. 2 (63). С. 75-83.
10. Власов А.И. Системный анализ технологических процессов производства сложных технических систем с использованием визуальных моделей // Междунар. науч.-исслед. журнал. 2013. № 10-2 (17). С. 17-26.
11. Власов А.И., Журавлева Л.В. Визуализация творческих стратегий с использованием ментальных карт // Прикаспийский журнал: управление и высокие технологии. 2013. № 1. С. 133-140.
12. Зворыкин Н.М. Реализация процессного подхода на промышленном предприятии // Методы менеджмента качества. 2004. № 1. С. 35-40.
DOI: 10.15827/0236-235X.108.229-233 Received 25.07.2014
VERIFICATION AND VALIDATION METHODS FOR COMPLEX SOFTWARE SYSTEMS
Demin A.A., Assistant, [email protected]; Karpunin A.A., Assistant, [email protected];
Ganev Yu.M., Laboratory Researcher, [email protected] (Bauman Moscow State Technical University, 2nd Baumanskaya St. 5, Moscow, 105005, Russian Federation)
Abstract. The paper discusses the problems of the large-scale software systems development. It shows the necessity of using specialized quality control systems for the final product. It also suggests an algorithm for discipline review, as well as user requirements review in terms of joint design and software products development. There are the main advantages of special software means for validation and verification comparing to other software systems estimation and compliance testing methods.
The article is primarily oriented at software developers and production managers wanting to automate the collaborative code review and verification process. It is also useful for quality assurance engineers eager to reduce labor costs at the testing stage, to detect errors in the program code at the earliest stages of system’s lifecycle. Relevance of the article is determined by the usage of contemporary and comprehensive methods to ensure software code development’s flexibility and transparency. They allow reducing development deadlines, improving the quality and reliability of the process, reducing costs, bringing all the code to a common styling and refining the mechanisms of interaction within the team, contributing to the evolution of mutual trust between the members of development and testing teams.
Keywords: software products quality, collaborative design and development technology, code verification process automation.
232
Программные продукты и системы /Software & Systems
№ 4 (108), 2014
References
1. Black R. Critical Testing Processes: Plan, Prepare, Perform, Perfect. Addison-Wesley Professional Publ., 2003, 608 p. (Russ. ed.: Lori Publ., 2006, 566 p.).
2. Wiegers K.E. Software Requirements. Microsoft Press, 1999 (Russ. ed.: Russkaya Redaktsiya Publ., 2004, 576 p.).
3. Ivanov A.M., Vlasov A.I. Verification of software models of communications networks. Nauka i obrazovanie: elektronnoe nauchno-tekhnicheskoe izdanie [Science and Education: Electronic Scientific and Technical Journ.]. 2012, no. 10, pp. 24 (in Russ.).
4. Vlasov A.I., Lytkin S.L., Jakovlev V.L. Kratkoe prakticheskoe rukovodstvo razrabotchika po yazyku PL/SQL [A Quick Manual of a PL/SQL Developer]. Moscow, Mashinostroenie Publ., 2000, vol. 2, 64 p.
5. Vlasov A.I. A spacial model of complex systems visual design metods evolution estimation. Datchiki & Systemi [Sensors & Systems]. 2013, no. 9, pp. 10-28 (in Russ.).
6. Vlasov A.I., Tsyganov I.G. The adaptive filtering of the information streams in corporate systems on the user voting basis. Informatsionnye tekhnologii [Information Technologies]. 2004, no. 9, pp. 12-19 (in Russ.).
7. Vlasov A.I., Tsyganov I.G. Multiagent Architecture of an Automated System for Corporative Information Stream Filtering. Informatsionnye tekhnologii [Information Technologies]. 2005, no. 1, pp. 34-41 (in Russ.).
8. Doar M. Practical Development Environments. O'Reilly Media Publ., 2005, 297 p.
9. Britov G.S. Verification, validation and testing of computer models of linear dynamic systems. Informatsionno-upravlyayushchie sistemy [Information and Control Systems]. 2013, vol. 2 (63), pp. 75-83 (in Russ.).
10. Vlasov A.I. System analysis of technological processes of producing complex technical systems using visual models. Mezhdunar. nauchno-issled. zhurnal [International Science and Research Journ.]. 2013, no. 10-2 (17), pp. 1726 (in Russ.).
11. Vlasov A.I., Zhuravleva L.V. Visualization of Creative Strategies: Application of Mental Maps. Prikasp. zhurn.: upravlenie i vysokie tekhnologii [Caspian Journ. Management and High Technologies]. 2013, no. 1, pp. 133140 (in Russ.).
12. Zvorykin N.M. Implementation of process approach in industrial enterprise. Metody menedzhmenta kachestva [Quality Management Methods]. 2004, no. 1, pp. 35-40 (in Russ.).
Вниманию читателей!
Журнал «Программные продукты и системы» знакомит читателей с работами ученых и специалистов России и зарубежных стран, стремится дать ответы на вопросы практического использования вычислительной техники в различных отраслях народного хозяйства, анализирует состояние программно-технических средств на сегодняшний день и прогнозирует их дальнейшее развитие.
Проводимая редакцией политика открытого доступа к научным публикациям способствует повышению цитируемости работ наших авторов и, соответственно, результативности их научной деятельности. Наше издание всеми доступными средствами пытается помочь российским ученым интегрироваться в международное научное сообщество.
В работе над статьями редакция стремится максимально учесть пожелания не только авторов, но и читателей.
Обращаем ваше внимание на то, что в электронной версии журнала, с которой можно ознакомиться на нашем сайте www.swsys.ru, по техническим причинам не всегда отражено все так, как задумал автор, в частности, это касается формул и рисунков. В случае возникновения проблем можно бесплатно открыть pdf-версию журнала. Кроме того, корректное представление рисунков можно увидеть и при клике мышкой по самой картинке.
Редакция
233
