Программная инженерия как дисциплина........................................
SWEBOK: Руководство к своду знаний по программной инженерии
Структура и содержание SWEBOK . Перевод SWEBOK на русский язык.
Введение
В конце 90-х годов прошлого века знания и опыт, которые были накоплены в индустрии программного обеспечения за предшествующие 30-35 лет, а также более чем 15-летних попыток применения различных моделей разработки, все это, наконец, оформилось в то, что принято называть дисциплиной программной инженерии - Software Engineering. В какой-то мере, такое формирование дисциплины на основе широко распространенного практического опыта напоминает те процессы, которые происходили в управлении проектами. Возникали и развивались профессиональные ассоциации, специализированные институты, комитеты по стандартизации и другие образования, которые, в конце концов, пришли к общему мнению о необходимости сведения профессиональных знаний по соответствующим областям и стандартизации соответствующих программ обучения.
Программная инженерия как дисциплина
В 1958 всемирно известный статистик Джон Тьюкей (John Tukey) впервые ввел термин software - программное обеспечение. В 1972 году IEEE[1] выпустил первый номер Transactions on Software Engineering - Труды по Программной Инженерии. Первый целостный взгляд на эту область профессиональной деятельности появился 1979 году, когда Компьютерное Общество IEEE подготовило стандарт IEEE Std 730 по качеству программного обеспечения. После 7 лет напряженной работы, в 1986 году IEEE выпустило IEEE Std 1002 “Taxonomy of Software Engineering Standards”.
Наконец, в 1990 году началось планирование всеобъемлющих международных стандартов, в основу которых легли концепции и взгляды стандарта IEEE Std 1074 и результатов работы образованной в 1987 году совместной комиссии ISO/IEC JTC 1[2]. В 1995 году группа этой комиссии SC7 “Software Engineering” выпустила первую версию международного стандарта ISO/IEC 12207 “Software Lifecycle Processes”. Этот стандарт стал первым опытом создания единого общего взгляда на программную инженерию. Соответствующий национальный стандарт России - ГОСТ Р ИСО/МЭК 12207-99 [ГОСТ 12207, 1999] содержит полный аутентичный перевод текста международного стандарта ISO/IEC 12207-95 (1995 года).
В свою очередь, IEEE и ACM [3], начав совместные работы еще в 1993 году с кодекса этики и профессиональной практики в данной области (ACM/IEEE-CS Code of Ethics and Professional Practice), к 2004 году сформулировали два ключевых описания того, что сегодня мы и называем основами программной инженерии - Software Engineering:
1. Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE 2004 Version - Руководство к Своду Знаний по Программной Инженерии, в дальнейшем просто “SWEBOK” [SWEBOK, 2004];
2. Software Engineering 2004. Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering - Учебный План для Преподавания Программной Инженерии в ВУЗах* (данное название на русском языке представлено в вольном смысловом переводе автора книги) [SE, 2004].
*** ACM - Association of Computer Machinery
Оба стандарта стали результатом консенсуса ведущих представителей индустрии и признанных авторитетов в области программной инженерии - по аналогии с тем, как был создан PMI PMBOK. Так мы пришли к сегодняшнему состоянию Software Engineering как дисциплины.
SWEBOK: Руководство к своду знаний по программной инженерии
C 1993 года IEEE и ACM координируют свои работы в рамках специального совместного комитета
- Software Engineering Coordinating Committee (SWECC - http://www.computer.org/tab/swecc ). Проект SWEBOK был инициирован этим комитетом в 1998 году. Оцененный предположительный объем содержания SWEBOK и другие факторы привели к тому, что было рекомендовано проводить работы по реализации проекта не только силами добровольцев из рядов экспертов индустрии и представителей крупнейших потребителей и производителей программного обеспечения, но и на основе принципа “полной занятости”. Базовый комплекс работ, в соответствии со специальным контрактом, был передан в Software Engineering Management Research Laboratory Университета Квебек в Монреале (Universite du Quebec a Montreal). Среди компаний, поддержавших этот уникальный проект были Boeing, MITRE, Raytheon, SAP. В результате проекта, оcуществленного при финансовой поддержке этих и других компаний и организаций, а также с учетом его значимости для индустрии, SWEBOK Advisory Committee (SWAC) принял решение сделать SWEBOK общедоступным * - http://www.swebok.org. В перспективе, если удастся обеспечить соответствующий уровень финансирования, SWAC считает необходимым законченную версию SWEBOK 2008 сделать также свободно доступной на Web-сайте проекта. Сегодняшняя “публичность” (общедоступность) результатов проекта стала возможна, в первую очередь, именно благодаря поддержке SWEBOK Industrial Advisory Board (IAB) - структуры, объединяющей представителей компаний, поддержавших проект.
Copyright and Reprint Permissions: This document may be copied, in whole or in part, in any form or by any means, as is, or with alterations, provided that (1) alterations are clearly marked as alterations and (2) this copyright notice is included unmodified in any copy.
Проект SWEBOK планировался в виде трех фаз: Strawman (“соломенный человек”), Stoneman (“каменный человек”) и Ironman (“железный человек”). К 2004 году была выпущена версия Руководства по Своду Знаний 3-ей фазы - Ironman, то есть максимально приближенная к окончательному варианту и одобренная IEEE в феврале 2005 года к публикации в качестве Trial- версии. Основная цель текущей “пробной” версии SWEBOK - улучшить представление, целостность и полезность материала руководства на основе сбора и анализа откликов на данную версию с тем, чтобы выпустить финальную редакцию документа в 2008 году.
По ряду обоснованных причин, “SWEBOK является достаточно консервативным” [SWEBOK, 2004, aB-2]. После 6 лет непосредственных работ над документом, SWEBOK включает “лишь” 10 областей знаний (knowledge areas, KA). При этом, что справедливо и для PMBOK, добавление новых областей знаний в SWEBOK достаточно прозрачно. Все, что для этого необходимо, зрелость (или, по крайней мере, явный и быстрый процесс достижения зрелости) и общепринятость* соответствующей области знаний, если это не приведет к серьезному усложнению SWEBOK.
* концепция “общепринятости” - generally accepted - определена в IEEE Std 1490-1998, Adoption of PMI Standard — A Guide to the Project Management Body of Knowledge
Важно понимать, что программная инженерия является развивающейся дисциплиной. Более того, данная дисциплина не касается вопросов конкретизации применения тех или иных языков программирования, архитектурных решений или, тем более, рекомендаций, касающихся более или менее распространенных или развивающихся с той или иной степенью активности /заметности технологий (например, web-служб). Руководство к своду знаний, каковым является SWEBOK, включает базовое определение и описание областей знаний (например, конфигурационное управление - configuration management) и, безусловно, является недостаточным для охвата всех вопросов, относящихся к вопросам создания программного обеспечения, но, в то же время необходимым для их понимания.
Необходимо отметить, что одной из важнейших целей SWEBOK является именно определение тех аспектов деятельности, которые составляют суть профессии инженера-программиста.
Структура и содержание SWEBOK
Описание областей знаний в SWEBOK построено по иерархическому принципу, как результат структурной декомпозиции. Такое иерархическое построение обычно насчитывает два -три уровня детализации, принятых для идентификации тех или иных общепризнанных аспектов программной инженерии. При этом, структура декомпозиции областей знаний детализирована только до того уровня, который необходим для понимания природы соответствующих тем и возможности нахождения источников компетенции и других справочных данных и материалов. В принципе, считается, что как таковой “свод знаний” по программной инженерии представлен не в обсуждаемом руководстве (SWEBOK), а в первоисточниках (как указанных в нем, так и представленных за его рамками) [SWEBOK, 2004, с.1-2].
SWEBOK описывает 10 областей знаний:
• Software requirements - программные требования
• Software design - дизайн (архитектура)
• Software construction - конструирование программного обеспечения
• Software testing - тестирование
• Software maintenance - эксплуатация (поддержка) программного обеспечения
• Software configuration management - конфигурационное управление
• Software engineering management - управление в программной инженерии
• Software engineering process - процессы программной инженерии
• Software engineering tools and methods - инструменты и методы
• Software quality - качество программного обеспечения
В дополнение к ним, SWEBOK также включает обзор смежных дисциплин, связь с которыми представлена как фундаментальная, важная и обоснованная для программной инженерии:
• Computer engineering
• Computer science
• Management
• Mathematics
• Project management
• Quality management
• Systems engineering
Стоит отметить, что принятые разграничения между областями знаний, их компонентами (subareas) и другими элементами достаточно произвольны. При этом, в отличие от PMBOK, области знаний SWEBOK не включают “входы” и “выходы”. В определенной степени такая декомпозиция связаны с тем, что SWEBOK не ассоциирован с той или иной моделью (например, жизненного цикла) или методом. Хотя на первый взгляд первые пять областей знаний в SWEBOK представлены в традиционной последовательной (каскадной - waterfall) модели, это не более чем следование принятой последовательности освещения соответствующих тем. Остальные области и структура декомпозиции областей представлены в алфавитном порядке.
Для каждой области знаний SWEBOK описывает ключевые акронимы, представляет область в виде “подобластей” (subareas) или как их часто называют в самом SWEBOK - “секций” и дает декомпозицию каждой секции в форме списка тем (topics) с их описанием.
Учитывая, что существует ряд неоднозначностей и фактически отсутствует консенсус по соответствующей терминологии на русском языке, далее в книге будут использоваться как оригинальные термины на английском языке, так и те их представления по-русски, которые кажутся автору наиболее адекватными в соответствующем контексте.
На рисунке 1 -а представлены первые пять областей знаний на английском языке, на рисунке 1 -б изображены те же пять областей на русском языке.
Рисунок 1-а. Первые пять областей знаний [SWEBOK, 2004, с.1-8, рис. 2]
Рисунок 1-б. Первые пять областей знаний на русском языке [SWEBOK, 2004, с.1-8, рис. 2]
Насколько автор в курсе, попыток перевода SWEBOK на русский язык не предпринималось а значимость его для индустрии программного обеспечения сложно переоценить, дальнейший рассказ о Руководстве к своду знаний по программной инженерии необходимо рассматривать как авторский перевод (с комментариями) ключевых положений SWEBOK. Такой подход ни в коем случае не подменяет оригинального SWEBOK и является всего лишь авторским прочтением последнего. В этом плане сделанный автором перевод SWEBOK* никак не заменяет перво исто чника.
Рисунок 2-а. Вторые пять областей знаний [SWEBOK, 2004, с.1-9, рис. 3]
Рисунок 2-б. Вторые пять областей знаний на русском языке [SWEBOK, 2004, с.1-9, рис. 3]
Рисунок 3. Связанные дисциплины [SWEBOK, 2004, с.1-9, рис. 3]
Лекция 2. Программная инженерия
Программные требования (Software equirements)
Лекция базируется на IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK®, 2004. Содержит перевод описания области знаний SWEBOK® “Software Requirements”, с комментариями и замечаниями.
"Основы программной инженерии" разработаны на базе IEEE Guide to SWEBOK® 2004 в соответствии с IEEE SWEBOK 2004 Oopyright and Reprint Permissions: "This document may be copied, in whole or in part, in any form or by any means, as is, or with alterations provided that (1) alterations are clearly marked as alterations and (2) this copyright notice is included unmodified in any copy."
Программные требования (Software Requirements)
Программные требования (Software Requirements).............................................................................. 2
1. Основы программных требований (Software Requirements Fundamentals)................................ 4
1.1 Определение требований (Definition of a Software Requirement)........................................... 4
1.2 Требования к продукту и процессу (Product and Process Requirements)............................... 4
1.3 Функциональные и нефункциональные требования (Functional and Non-functional
Программные требования - Software Requirements - свойства программного обеспечения, которые должны быть надлежащим образом представлены в нём для решения конкретных практических задач. Данная область знаний касается вопросов извлечения (сбора), анализа, специфицирования и утверждения требований.
Опыт индустрии информационных технологий однозначно показывает, что вопросы, связанные с управлением требованиями, оказывают критически-важное влияние на программные проекты, в определенной степени - на сам факт возможности успешного завершения проектов. Только систематичная работа с требованиями позволяет корректным образом обеспечить моделирование задач реального мира и формулирование необходимых приемочных тестов для того, чтобы убедиться в соответствии создаваемых программных систем критериям, заданным реальными практическими потребностями.
На практике часто применяется подход, используемый в различных методологиях разработки ПО и базирующийся на определении групп требований к продукту. Такой подход обычно включает группы (типы, категории) требований, например: системные, программные, функциональные, нефункциональные (в частности, атрибуты качества) и т.п. Классический пример (см. рисунок 1)
высокоуровневого структурирования групп требований как требований к продукту описан в работах одного из классиков дисциплины управления требованиями - Карла Вигерса.
Рисунок 1. Уровни требований по Вигерсу [Вигерс, 2003, с.8, рис. 1-1]
SWEBOK охватывает не только вопросы структурирования и систематизации требований, но и различных процессов этапов и процессов работы с требованиями, а также некоторые практические соображения.
Рисунок 2. Область знаний “Программные требования” [SWEBOK, 2004, с.2-2, рис. 1]
Сама же структура обсуждаемой области знаний в большой степени совместима со стандартами IEEE 12207.x, ISO/IEC, ГОСТ Р ИСО/МЭК 12207 (структура стандарта будет рассмотрена позднее). Такая структура построена исходя из идеи выделения ключевых групп вопросов дисциплины.
Область знаний управления требованиями включает 7 секций, каждая из которых представлена в виде ключевых тем (см. рисунок 2). Кроме того, данная область знаний тесно связана со следующими областями:
• Software Design
• Software Testing
• Software Maintenance
• Software Configuration Management
• Software Engineering Management
• Software Engineering Process
• Software Quality
1. Основы программных требований (Software Requirements Fundamentals)
Эта секция включает определение программных требований как таковых и описывает основные типы требований и их отличия: к продукту и процессу, функциональные и нефункциональные требования и т.п.
Темы данной секции:
1.1 Определение требований (Definition of a Software Requirement) - в данном случае подразумевается не процесс определения (извлечения, сбора, формирования, формулирования) требований, а дается само понятие “требования”, как такового, и отмечаются его основные характеристики, например, верифицируемость (проверяемость) требования.
По мнению авторов, необходимо обратить внимание на следующие определения понятия “требование” (на основе работ Вигерса и стандарта IEEE Standard Glossary of Software Engineering Terminology, 1990):
• Условие или возможность, требуемая пользователем для решения задач или достижения целей.
• Условие или возможность, которые должны удовлетворяться системой/компонентом системы или которыми система/компонент системы должна обладать для обеспечения условий контракта, стандартов, спецификаций или др. регулирующими документами.
• Документальная репрезентация (зафиксированное представление, определение, описание) условий или возможностей, перечисленных в предыдущих пунктах.
1.2 Требования к продукту и процессу (Product and Process Requirements) - проводится разграничение соответствующих требований как свойств продукта, который необходимо получить, и процесса, с помощью которого продукт будет создаваться; отмечается, что ряд требований может быть заложен неявно и программные требования могут порождать требования к процессу, например: работа в режиме 24x7 (как бизнес-требование) наверняка приведет к ограничению выбора тех или иных программных средств, платформ развертывания и архитектурных решений; в свою очередь, выбор платформы J2EE (Java 2 Enterprise Edition) и ее реализации в виде конкретного сервера приложений практически наверняка потребует применения модульного тестирования (Unit testing) как практики процесса разработки и JUnit, как инструмента реализации этой практики.
1.3 Функциональные и нефункциональные требования (Functional and Non-functional Requirements) - функциональные требования задают “что” система должна делать; нефункциональные - с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции)
По мнению авторов, в определенной степени, систематизируя работы Вигерса, Лефингвелла и Видрига, Коберна, а также других экспертов, необходимо привести классификацию различных категорий (видов) требований и связанных с ними понятий, важнейших с точки зрения их понимания и дальнейшего практического применения:
• Группа функциональных требований
о Бизнес-требования (Business Requirements) - определяют высокоуровневые цели организации или клиента (потребителя) - заказчика разрабатываемого программного обеспечения.
о Пользовательские требования (User Requirements) - описывают цели/задачи
пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases).
о Функциональные требования (Functional Requirements) - определяют
функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.
• Группа нефункциональных требований (Non-Functional Requirements)
о Бизнес-правила (Business Rules) - включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и т.д. На самом деле, достаточно часто можно видеть недостаточное внимание такого рода требованиям со стороны сотрудников ИТ-департаментов и, в частности, технических специалистов, вовлеченных в проект. Business Rules Group дает понимание бизнес-правила, как “положения, которые определяют или ограничивают некоторые аспекты бизнеса. Они подразумевают организацию структуры бизнеса, контролируют или влияют на поведение бизнеса”. Бизнес-правила часто определяют распределение ответственности в системе, отвечая на вопрос “кто будет осуществлять конкретный вариант, сценарий использования” или диктуют появление некоторых функциональных требований.
В контексте дисциплины управления проектами (уже вне проекта разработки программного обеспечения, но выполнения бизнес-проектов и бизнес-процессов) такие правила обладают высокой значимостью и, именно они, часто определяют ограничения бизнес-проектов, для автоматизации которых создается соответствующее программное обеспечение.
о Внешние интерфейсы (External Interfaces) - часто подменяются “пользовательским интерфейсом”. На самом деле вопросы организации пользовательского интерфейса безусловно важны в данной категории требований, однако, конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями мониторинга при эксплуатации - все это не столько функциональные требования (к которым ошибочно приписывают иногда такие характеристики), сколько вопросы интерфейсов, так как функциональные требования связаны непосредственно с функциональностью системы, направленной на решение бизнес-потребностей.
о Атрибуты качества (Quality Attributes) - описывают дополнительные характеристики продукта в различных “измерениях”, важных для пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п.
о Ограничения (Constraints) - формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, ...), которые, в свою очередь, могут относиться, например, к внешним интерфейсам.
Программная инженерия Введение
Рисунок 1-а. Первые пять областей знаний [SWEBOK, 2004, с.1-8, рис. 2]
Рисунок 2-а. Вторые пять областей знаний [SWEBOK, 2004, с.1-9, рис. 3]
Рисунок 1. Уровни требований по Вигерсу [Вигерс, 2003, с.8, рис. 1-1]
Рисунок 2. Область знаний “Программные требования” [SWEBOK, 2004, с.2-2, рис. 1]