SWEBOK — ориентир программной инженерии | Открытые системы. СУБД

В 1998 году ассоциации IEEE Computer Society и Association for Computing Machinery инициировали проект SWEBOK (The Guide to the Software Engineering Body of Knowledge), а в 2004 году появилась первая версия руководства [1]. Свод знаний направлен на определение содержания дисциплины программной инженерии; формирование единообразия ее понимания в профессиональном сообществе; определение границ программной инженерии по отношению к другим дисциплинам; формирование основы для учебных материалов и курсов; поддержку процессов сертификации и лицензирования инженеров-программистов. Из этого вытекают и принципы, лежащие в основе проекта: прозрачность — процесс разработки руководства документирован и открыт широкой общественности для обсуждения; консенсус — работа ведется на основе достижения полного консенсуса профессионалов отрасли, академических кругов и органов по стандартизации; распространение — свод знаний находится в свободном доступе.

Целевая аудитория SWEBOK:

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

Новая редакция развивающегося массива знаний SWEBOK v4.0 [2] направлена на лучшее согласование смежных дисциплин путем реорганизации и переименования контента в различных областях знаний (Knowledge areas, KA, см. Таблицу). Со времени выхода SWEBOK v3 в 2014 году в отрасли произошло много изменений.

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

Появляются новые точки зрения на совокупность знаний в области программной инженерии, такие, например, как в экзамене IEEE CS Certified Software Development Professional (CSDP), которые требуется учитывать и согласовать в SWEBOK. В этой связи логично установить базовый набор общих ссылок на первоисточники в альтернативных программах сертификации.

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

Четвертая версия SWEBOK вводит новые темы, актуализирует существующие и удаляет устаревшие. В обновленный перечень областей знаний программной инженерии, содержащий требования к знаниям и описания ее процессов, практик, входов, выходов, инструментов и методов, в четвертой версии были наконец-то интегрированы понятия Agile [3] и DevOps [4], что отражает широкое распространение этих технологий с момента выхода третьей версии и является ответом критикам на игнорирование этих методов в предыдущих версиях руководства [1], ставшего в 2015 году стандартом ISO/IEC TR 19759. Например, для KA «Software Requirements»в рамках жизненного цикла Agile предполагается, что требования к ПО будут постоянно меняться, масштабироваться и корректироваться, вплоть до момента завершения проекта создания ПО. В KA 'Software Testing' отмечается, что регрессионное тестирование — это основа разработки по Agile и DevOps, обычно выполняемое после интеграционного тестирования и перед развертыванием ПО в производстве или эксплуатации. Кроме того, в основу ряда областей знаний были включены новые платформы и технологии: искусственный интеллект, машинное обучение и Интернет вещей [5]. В частности, отмечается, что ИИ получает широкое распространение при тестировании и выявлении ошибок в ПО.

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

В новой версии SWEBOK появились три новые области знаний, отражающие современные реалии программной инженерии: «Архитектура программного обеспечения» (Software Architecture); «Операции программной инженерии» (Software Engineering Operations); «Безопасность ПО» (Software Security).

Архитектура программного обеспечения

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

В программной инженерии имеется много взглядов на понятие «архитектура». Во-первых, ее часто относят к искусству и науке построения вещей — в данном случае систем на базе ПО, что включает в себя концепции, принципы, процессы и методы, принятые сообществом. Во-вторых, «архитектура» относится и к различным процессам — архитектура программного обеспечения считается частью проектирования ПО. В-третьих, «архитектура» относится и к разработке структур программных систем. Однако наиболее точное, по версии SWEBOK, определение архитектуры лежит в контексте взаимосвязи фундаментальных компонентов программной системы. Архитектура — это то, что является фундаментальным для программной системы, причем не каждый элемент, взаимосвязь или интерфейс можно считать фундаментальным. Архитектура рассматривает программную систему в ее среде — подобно строительной архитектуре, программная смотрит вовне, рассматривая контекст системы за ее пределами, включая людей, организации, собственно ПО, оборудование и другие устройства, с которыми взаимодействует программная система. Таким образом, программная архитектура — это набор структур (программные элементы, отношения между ними, свойства), необходимых для описания системы.

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

Для описания программных архитектур используются предметно-ориентированные языки ADL (Architecture description language) [6], ориентированные на отдельную область применения или архитектурный стиль. Например, язык MetaH применяется для описания систем реального времени в авионике, а ArchiMate для описания ИТ-ландшафта предприятия. В качестве ADL часто используется язык UML из-за его широкого распространения для проектирования ПО.

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

Учитывая многозадачность и мультидисциплинарную природу архитектуры ПО, имеется множество мнений на то, что делает ее «хорошей». Например, римский архитектор Витрувий утверждал, что все здания должны обладать такими свойствами, как прочность, полезность и красота (лат. firmitas, utilitas, venustas). В этой связи к программной системе и ее архитектуре можно задать следующие вопросы: Является ли она надежной в течение своего срока службы и возможной эволюции? Подходит ли она для предполагаемого использования? Насколько целесообразно и экономически эффективно создание программных систем с использованием именно этой архитектуры? Является ли она если не красивой, то, по крайней мере, ясной и понятной тем, кто должен создавать, использовать и поддерживать программное обеспечение?

Операции программной инженерии

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

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

В этом контексте резко меняется роль инженеров-программистов, работающих в условиях появления таких практик, как инфраструктура как код (Infrastructure as Code, IaC), платформа как код (Platform as Code, PaC), гибкая инфраструктура, программно-конфигурируемые архитектуры/системы и инфраструктура как сервис (IaaS). Задачи, традиционно выполняемые инженерами ИТ-инфраструктуры, все чаще автоматизируются и становятся доступны по запросу в качестве услуги, что позволяет разработчикам приложений полностью сосредоточиться на выполнении своих задач. Например, разработчики приложений во многих организациях теперь могут напрямую использовать IaaS и PaaS для развертывания приложений в конкретных производственных средах, а также мониторинга функционирования этих приложений без привлечения инженеров по эксплуатации.

С инженерной точки зрения важным моментом является то, что почти все, что напрямую или косвенно влияет на программный продукт, теперь следует рассматривать как представляемое в виде кода. Для выполнения задач по разработке ПО, повышения производительности и качества программ некоторые организации используют концепцию обеспечения бесперебойной работы высоконагруженных сервисов SRE (Site Reliability Engineering). Согласно SRE предполагается, что надежные системы изначально проектируются и эксплуатируются с учетом того, что люди (программисты, инженеры службы эксплуатации и пр.) всегда ошибаются. Здесь в SWEBOK возникает понятие платформ самообслуживания, которые могут использоваться инженерами-программистами для разработки, развертывания и эксплуатации приложений. С другой стороны, роль SRE заключается в мониторинге, автоматизации и улучшении операций ПО применительно к его аспектам, не связанным с функциональностью: доступность, производительность, задержки и безопасность. Кроме этого платформы SRE отвечают за управление изменениями, реагирование на чрезвычайные ситуации, планирование ресурсов и общую эффективность программных систем. В этом контексте в SWEBOK выделяются две основные роли инженеров ПО, связанные с операциями: инженер по эксплуатации отвечает за разработку операционных сервисов, предоставляемых по запросу и доступных через интерфейс прикладного программирования; инженер по программному обеспечению, который может использовать результирующие операционные услуги, также доступные по запросу для независимого развертывания и управления приложениями без непосредственного привлечения специалистов по ИТ-операциям.

Безопасность ПО

Безопасность стала сегодня серьезной проблемой в разработке программного обеспечения как из-за потенциально неправильного использования ПО, так и роста вредоносной активности, направленной на компьютерные системы.

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

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

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

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

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

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

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

Тестирование безопасности гарантирует, что реализованное программное обеспечение соответствует требованиям безопасности и проверяет, что реализация ПО не содержит известных уязвимостей. С этой задачей справляются как общие методы тестирования программного обеспечения [7, 8], так и специфические методы тестирования безопасности.

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

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

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

Интернет вещей объединяет различные системы, включая и встроенные, изначально не имеющие средств защиты от злонамеренных проникновений. Злоумышленники, получающие доступ к бизнес-платформам, например через уязвимости браузера, потенциально могут взломать и слабо защищенные промышленные устройства Интернета вещей. Это может привести к серьезному ущербу, включая и инциденты безопасности — множество обычно почти не защищенных конечных потребительских или промышленных устройств создают благодатную почву для организации вторжений. Укрепление конечных точек и обеспечение безопасных коммуникаций между устройствами, которые для разработчиков ПО обычно представляются в виде черных ящиков, добавляет новые проблемы обеспечения безопасности программных систем. Для платформ Интернета вещей необходимы комплексные методы анализа рисков и угроз, а также соответствующие инструменты управления.

Машинное обучение сегодня широко используется во многих системах, однако оно несет в себе определенную уязвимость и злоумышленники могут скомпрометировать его модели. Существует два вида атак: отравление моделей, которое атакует обучающие данные, и уклонение, которое атакует входные данные обученных моделей [11].

***

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

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

Проект SWEBOK V4.0 — предстоящий этап следующей версии SWEBOK 5.0, которая продолжит процесс переосмысления как уже общепринятых знаний в сфере программной инженерии, так и введения новых направлений.

Литература

1. Наталья Дубова. Знакомьтесь: SWEBOK // Открытые системы.СУБД. — 2006. — № 7. — С. 62–69. URL: https://www.osp.ru/os/2006/07/3290839 (дата обращения: 31.12.2024).

2. Guide to the Software Engineering Body of Knowledge v4.0 // IEEE Computer Society Ed. Hironori Washizaki, Waseda University, 2024. URL: https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf (дата обращения 31.12.2024).

3. Бертран Мейер. Об Agile по гамбургскому счету // Открытые системы.СУБД. — 2018. — № 2. — С. 23–25. URL: https://www.osp.ru/os/2018/2/13054179 (дата обращения: 31.12.2024).

4. Олег Скрынник. Истоки DevOps // Открытые системы.СУБД. — 2017. — № 3. — С. 18–19. URL: https://www.osp.ru/os/2017/03/13052656 (дата обращения: 31.12.2024).

5. Антеро Тайвалсаари, Томми Микконен. Особенности создания ПО в эпоху Интернета вещей // Открытые системы.СУБД. — 2017. — № 2. — С. 21–25. URL: https://www.osp.ru/os/2017/02/13052220 (дата обращения: 31.12.2024).

6. Дмитрий Волков. Открытая архитектура информационных систем // Открытые системы.СУБД. — 2015. — № 1. — С. 25–27. URL: https://www.osp.ru/os/ 2015/01/13045323 (дата обращения: 31.12.2024).

7. Моисес Родригес, Марио Пьяттини, Кристофер Эберт. Верификация и валидация ПО: технологии и инструменты // Открытые системы.СУБД. — 2019. — № 2. — С. 17–23. URL: https://www.osp.ru/os/2019/02/13054964 (дата обращения: 31.12.2024).

8. Кристофер Эберт, Дивит Баджадж, Микаэль Вейрих. Тестирование программных систем // Открытые системы.СУБД. — 2022. — № 3. — С. 12–17. URL: https://www.osp.ru/os/2022/03/13056303 (дата обращения: 31.12.2024).

9. Максим Чернышев, Зубэр Бейг, Шерали Зидэлли. Безопасность облачных приложений // Открытые системы.СУБД. — 2022. — № 1. — С. 23–28. URL: https://www.osp.ru/os/2022/01/13056139 (дата обращения: 31.12.2024).

10. Александр Барабанов, Алексей Марков, Андрей Фадин. Сертификация программ без исходных текстов // Открытые системы.СУБД. — 2011. — № 4. — С. 38–41. URL: https://www.osp.ru/os/2011/04/13008784 (дата обращения: 31.12.2024).

11. Сяо Ин Линь, Баттиста Биджио. Вредоносное машинное обучение: атаки из лабораторий в реальный мир // Открытые системы.СУБД. — 2021. — № 3. — С. 37–39. URL: https://www.osp.ru/os/2021/03/13055994 (дата обращения: 31.12.2024).

Дмитрий Волков (vlk@keldysh.ru) — старший научный сотрудник ИПМ им. М. В. Келдыша РАН (Москва).

DOI: 10.51793/OS.2024.14.91.003