3. Руководство к Своду знаний по программной инженерии (Guide to the Software Engineering Body of Knowledge –swebok)

Руководство к Своду Знаний по Программной Инженерии – «SWEBOK» [SWEBOK, 2004] было издано в 2004 году и включает базовые определения и описания областей знаний, которые составляют суть профессии инженера-программиста. [10]

Описание областей знаний в SWEBOK построено по иерархическому принципу, как результат структурной декомпозиции и включает 10 областей знаний которые условно можно разбить на две группы:

1. Знания, конкретизирующие жизненный цикл разработки программных продуктов:

• определение требований;

• проектирование, конструирование;

• тестирование, эксплуатация (поддержка).

2. Знания, раскрывающие содержание методов и инструментария разработки программных продуктов:

• конфигурационное управление;

• управление инженерной деятельностью;

• процессы инженерной деятельности;

• инструменты и методы программной инженерии;

• качество программного обеспечения.

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

Остановимся в дальнейшем более подробно на описании содержания областей знаний конкретизирующих основные этапы жизненного цикла разработки программных продуктов (рис. 15) [1].

Рис. 15. Содержание этапов жизненного цикла программных продуктов

1. Определение требований

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

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

Рис. 16. Состав раздела «Определение требований»

Основы программных требований.

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

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

Нефункциональные требования определяют условия и среду выполнения функций (например, защита и доступ к БД, взаимодействие компонентов и др.).

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

Следует отметить, что в российских стандартах излагается несколько другой подход к составу требований. Так, например, в серии стандартов ГОСТ 34.602–89 «Информационная технология. Техническое задание на создание автоматизированных систем» приводится следующий состав требований:

• Требования к функциям (задачам), выполняемым системой.

• Требования к структуре и режимам функционирования системы.

• Требования к видам обеспечения: математическое обеспечение; информационное обеспечение; программное обеспечение; техническое обеспечение; организационное обеспечение.

• Общие требования к приемке работ по стадиям, порядок согласования и утверждения приемочной документации.

• Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие.

• Требования к документированию системы.

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

Участниками процесса работы с требованиями являются:

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

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

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

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

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

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

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

• процессы изучения потребностей и целей пользователей;

• классификацию требований и их преобразование к требованиям программного обеспечения;

• общесистемному аппаратно-программному обеспечению;

• установление и разрешение конфликтов между требованиями;

• определение их приоритетов;

• принципов взаимодействия со средой функционирования.

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

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

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

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