Системная инженерия программного обеспечения: введение

Программные системы становятся все больше и сложнее. Классический пример — Microsoft Word, который 20 лет назад умещался на дискете на 360 Кбайт, а теперь для него необходим компакт-диск емкостью 600 Мбайт.

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

Реализация подавляющего большинства крупных программных систем не укладывается в запланированные сроки, выходит за рамки сметы, и при этом не вполне оправдывает ожидания заказчика. Этот феномен хорошо известен как «кризис программного обеспечения» [1]. Чтобы разрешить этот кризис, разработчики программного обеспечения используют при создании продуктов различные инженерные методики.

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

Применение принципов системной инженерии к разработке программной системы выявляет операции, задачи и процедуры, называемые системной инженерией программного обеспечения: (software system engineering — SwSE). Многие считают SwSE специфичным случаем системной инженерии, а другие относят ее к программной инженерии. Однако я могу утверждать, что SwSE — совсем иной мощный инструментарий, используемый для управления технической разработкой крупных программных проектов.

В этой статье определения и процессы из стандартов IEEE на программную инженерию [2] интегрируются в процесс SwSE. Более подробное изложение этого материала, включая детальное пошаговое описание развертывания SwSE, содержится в [3].

Системы и системная инженерия

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

Стандарт IEEE Std. 1220-1998 описывает процесс системной инженерии и ее применение на протяжении всего цикла жизни изделия [4]. Системная инженерия порождает документы, а не оборудование. Документы связывают процессы разработки с циклом жизни проекта. Они определяют предполагаемые окружения процессов, интерфейсы и инструменты управления рисками в рамках всего проекта.

Системная инженерия включает в себя пять функций.

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

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

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

Что такое системная инженерия ПО?

Термин «системная инженерия программного обеспечения» появился в начале 80-х годов, и его приписывают Уинстону Ройсу [5]. SwSE отвечает за общее техническое управление системой и подтверждение корректности окончательных системных продуктов. Как и системная инженерия, SwSE порождает документы, а не компоненты. В этом она отличается от программной инженерии (software engineering — SwE), порождающей компьютерные программы и руководства пользователей.

SwSE начинается, когда системные требования разделены на аппаратные и программные подсистемы. SwSE формирует основу для всей разработки программного обеспечения в проекте и, как и SwE, представляет собой одновременно и технический и управленческий процесс. Технический процесс SwSE — аналитическая работа, необходимая для преобразования операционных требований в:

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

SwSE не является описанием работ. Это процесс, который выполняют многие люди и организации: системные инженеры, менеджеры, программные инженеры, программисты и, не стоит забывать пользователи.

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

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

SwSE и программная инженерия

И SwSE, и SwE — это технические и управленческие процессы, однако SwE порождает программные компоненты и описывающую их документацию. Более строго, программная инженерия включает в себя следующее.

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

Рис. 1 иллюстрирует связи между системной инженерией, SwSE и SwE. Традиционная системная инженерия выполняет первоначальный анализ и проектирование, а также интеграцию и тестирование окончательной системы.

Рис. 1. Инженерные связи между системной инженерией, системной инженерией программного обеспечения (SwSE) и программной инженерией

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

SwSE и управление проектом

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

Рис. 2. Управленческие связи между системной инженерией программного обеспечения, программной инженерией и проектным менеджментом

Рис. 2 иллюстрирует управленческие связи между проектным менеджментом, SwSE и SwE. Руководство проектом включает в себя общее управление распределением работ в проекте и полномочия предоставления ресурсов. SwSE определяет технический подход, принимает технические решения, взаимодействует с техническими представителями заказчика, а также одобряет и принимает конечный программный продукт. SwE отвечает за разработку программного дизайна, кодирование и разработку программных компонентов.

Функции SwSE

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

Таблица 1. Функции системной инженерии, коррелирующие с системной инженерией ПО

Анализ требований

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

Программные требования можно классифицировать следующим образом [8].

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

Анализ программных требований начинается после того, как системная инженерия определила системные требования заказчика. В его функции входят указание всех (или максимального числа) требований к программной системе, и завершение анализа означает формирование утвержденных базовых требований [2].

Дизайн программного обеспечения

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

Дизайн программного обеспечения традиционно разделяется на две части.

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

Предложенная в статье методология архитектурный дизайн относит к SwSE, а детальный дизайн — к SwE.

Планирование процессов

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

Существует ошибочное предположение, что проектный менеджмент выполняет все действия по планированию проекта. На самом же деле, планирование проекта состоит из двух составляющих — одна относится к проектному менеджменту, а другая — к SwSE, причем основная часть выполняется именно в рамках SwSE. (Это вовсе не означает, что менеджеры проекта не могут выполнять обе функции.)

В таблице 2 показан пример разделения функций планирования для проекта программной системы.

Таблица 2. Планирование процессов и планирование проекта

Контроль процессов

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

Контроль процессов — система обратной связи, необходимая для того, чтобы определить, как движется проект. Контроль процессов предполагает ответы на следующие вопросы. Есть ли потенциальные проблемы, способные привести к задержке с выполнением конкретного требования в указанные сроки и в рамках имеющегося бюджета? Есть ли риск, что такие проблемы станут реальными? Выполним ли подход к проектированию?

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

Таблица 3. Контроль процессов и контроль проекта

Верификация, подтверждение и тестирование

Процесс верификации, подтверждения и тестирования (verification, validation and testing — VV&T) определяет, корректен ли процесс инженерии, и соответствуют ли продукты предъявляемым требованиям [10].

• Верификация определяет, соответствуют ли продукты на данном этапе цикла разработки программного обеспечения требованиям, утвержденным во время предыдущего этапа. Дает ответ на вопрос: "Так ли я создаю продукт?"
• Подтверждение определяет соответствие окончательной программы или программного обеспечения требованиям и нуждам пользователя. Дает ответ на вопрос: "Тот ли я создаю продукт?"
• Тестирование - это выполнение программы или части программы с известными входными и выходными данными, которые известны заранее и которые можно проверить, что позволяет обнаружить ошибки. Тестирование часто считается частью верификации.

VV&T — это непрерывный процесс мониторинга операций системной инженерии, SwSE, SwE и проектного менеджмента с целью убедиться, что они следуют техническим и управленческим планам, спецификациям, стандартам и процедурам. Кроме того, VV&T оценивает промежуточные и окончательные продукты проекта SwE. Промежуточные продукты включают в себя спецификации требований, описание архитектуры, планы тестирования и оценку результатов. К окончательным продуктам относятся программное обеспечение, руководства пользователей, учебные материалы и т.д.

SwSE использует методы и инструментарий VV&T для оценки требований спецификаций, описания архитектуры и других промежуточных продуктов. Тестирование выполняется для того, чтобы определить, соответствует ли окончательный продукт спецификациям требований данного проекта.

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

Системная инженерия и SwSE — дисциплины, используемые в первую очередь для технического планирования «на входе» жизненного цикла системы и для проверки того, что к окончанию проекта все планы были выполнены. К сожалению, в реальных проектах эти дисциплины часто игнорируются.

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

Литература

1. W.W. Gibbs, «Software’s Chronic Crisis», Scientific Am., 1994, Sept.

2. IEEE, Software Engineering Standards Collection, vols. 1-4, IEEE Press, Piscataway, N.J., 1999

3. R.H. Thayer, «Software System Engineering: A Tutorial», Software Engineering Volume 1: The Development Process, 2nd ed., R.H. Thayer and M. Dorfman, eds., IEEE CS Press, Los Alamitos, Calif., 2002

4. IEEE Std. 1220-1998, Standard for Application and Management of the System Engineering Process, IEEE Press, Piscataway, N.J., 1998

5. W.W. Royce, «Software Systems Engineering», seminar presented as part of the course titled Management of Software Acquisition, Defense Systems Management College, Fort Belvoir, Va., 1981-1988

6. IEEE Std. 1058-1998, Standard for Software Project Management Plans, IEEE Press, Piscataway, N.J., 1998

7. IEEE Std. 610.12-1990, Standard Glossary of Software Engineering Terminology, IEEE Press, Piscataway, N.J., 1990

8. IEEE Std. 830-1998, Recommended Practice for Software Requirements Specifications, IEEE Press, Piscataway, N.J., 1998

9. IEEE Std. 1016-1998, Recommended Practice for Software Design Descriptions, IEEE Press, Piscataway, N.J., 1998

10. IEEE Std. 1012-1998, Standard for Software Verification and Validation, IEEE Press, Piscataway, N.J., 1998

Ричард Тэйер (r.thayer@computer.org) — почетный профессор программной инженерии Калифорнийского университета в Сакраменто, консультирует по программной инженерии и управлению проектами, ведет исследования и читает лекции в Университете Стречклайда (Глазго, Шотландия).

Richard H. Thayer. Software System Engineering: A Tutorial. IEEE Computer, April 2002. Copyright 2002, IEEE Computer Society. Translated and reprinted with permission.