Стандартизация жизненного цикла сложных программных средств за рубежом
Липаев В.В.

Рассматриваются цели создания и основные особенности моделей жизненного цикла (ЖЦ) сложных программных средств (ПС) для систем управления. Анализируются четыре направления, по которым за рубежом развивается стандартизация моделей ЖЦ и основных технологических процессов разработки, сопровождения и поддержки эксплуатации ПС. Изложено содержание ЖЦ ПС в стандартах 1SO/1ЕС, АNSI/IЕЕЕ и DOD. Отмечены основные особенности этих стандартов и целесообразные области их применения.

Основные особенности моделей жизненного цикла программных средств. В современных информационных технологиях важнейшей компонентой являются программные средства (ПС), которые определяют процессы решения функциональных и вспомогательных задач на ЭВМ при использовании таких технологий. За два последних десятилетия в разных странах и фирмах отработан естественный процесс создания, развития и применения программ для ЭВМ. Этот процесс принято описывать моделями жизненного цикла (ЖЦ) программ различных классов и назначения. В моделях жизненный цикл структурируется рядом крупных фаз или этапов, каждый из которых характеризуется достаточно определенными целями и результатами. Так как основные промежуточные и конечные цели создания и применения программ всегда тождественны или очень близки, то .и модели ЖЦ для аналогичных типов ПС в значительной степени подобны. Основные различия опубликованных за рубежом моделей [ 1—8] определяются выделением наиболее важных (с позиции авторов) процессов, а также способами их группирования и отображения. При этом важную роль играют классы и параметры программ, которые иногда неявно определяли первоначальное формирование моделей ЖЦ. Кроме того, модели несколько отличаются терминологией и графическим представлением этапов и их взаимодействием.

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

Такими базовыми этапами-процессами являются:

инициализация, системный анализ и первоначальная разработка спецификации требований на ПС;

предварительное (эскизное) и детальное (техническое) проектирование ПС;

разработка программных компонент, их комплексирование и отладка ПС в целом;

испытания, опытная эксплуатация и распространение ПС;

регулярная эксплуатация ПС, ее поддержка и анализ результатов;

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

Графическое представление моделей ЖЦ позволяет наглядно выделить их особенности и некоторые свойства процессов. Первоначально [ 1] была создана каскадная модель ЖЦ, в которой крупные этапы (в среднем около.8—10) располагались, последовательно снижаясь, символически представляя переливание результатов работ предшествующих этапов на следующие за ними. Между этапами имелись обратные связи, которые отображали итерационный процесс совершенствования и повышения качества ПС. Опубликовано множество разновидностей каскадной модели, различающихся числом и группированием процессов, и она пока остается наиболее популярной [ 2, 3].

Среди моделей ЖЦ ПС наиболее специфической является спиральная [ 4]. В этой модели внимание концентрируется на итерационном процессе начальных этапов проектирования. На этих этапах последовательно создаются концепции, спецификации требований, предварительный и детальный проект. Каждый этап отображается соответствующим витком расширяющейся спирали. На очередном витке уточняется содержание проектируемого ПС, определяется его качество, анализируется риск продолжения разработки, увеличивается ее стоимость и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта ПС.

В большинстве опубликованных моделей ЖЦ ПС детализация ограничивается 8—10 крупными процессами или этапами. Для практического применения моделей при реальном планировании и управлении проектами необходима более подробная информация о содержании процессов. В подобных описаниях должны быть представлены исходные данные, содержание работ и ожидаемые результаты их выполнения, а также структура и содержание документов, сопутствующих их реализации. Обычно такая детализация на 50—100 частных работ производится при формировании технологии разработки, поддержки эксплуатации и сопровождения конкретных ПС фирмами-разработчиками. Некоторые варианты таких детализаций моделей ЖЦ ПС представлены в зарубежных стандартах и методических материалах фирм.

При применении детальных моделей ЖЦ для конкретных проектов ПС их необходимо адаптировать в соответствии с характеристиками объектов, среды разработки и использования ПС. Адаптация обычно сводится к дополнению или исключению некоторых работ, а также к корректировке их характеристик. Детализация и адаптация позволяет отработать рабочие графики создания и поддержки применения ПС определенного назначения в течение всего ЖЦ. Кроме того, подобные графики являются методической базой для выбора и применения современных САSЕ (Computer – Aided Software Engineering) средств автоматизации всего технологического процесса и отдельных работ ЖЦ ПС.

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

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

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

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

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

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

Первое, наиболее широкое для использования, направление организуется и стимулируется международной организацией стандартизации (International Standarts Organization - ISO) и международной комиссией по электротехнике (International Electrotechnical Commission - IEC). На этом уровне осуществляется стандартизация наиболее общих технологических методов и процессов, имеющих значение для международной кооперации и разделения труда. Особое внимание уделено стандартам, гарантирующим качество ПС и возможность их широкого применения.

Второе направление активно развивается в США Институтом инженеров электротехники и радиоэлектроники (Institute of Electrotechnical and Electronic Engineers – IEEE) совместно с Американским национальным институтом стандартизации (American National Standarts Institute - ANSI). По этому направлению разработано наибольшее число стандартов в рассматриваемой области. В этой группе процессы ЖЦ ПС отражены в следующих стандартах:

терминология в области проектирования программного обеспечения (729—1983);

процессы планирования и управления разработкой сложных ПС (1058—1987);

конфигурационное управление при разработке и сопровождении ПС (828—1983; 1042-1987);

показатели и методы гарантирования качества и надежности ПС (730—1983;

982-198'8; 983-1986; 1061-198Х);

тестирование, отладка и испытания ПС (829-1983; 1008-1986; 1012-1986;

1044-198Х);

документирование процессов и результатов разработки ПС (830—1984;

1063-1987).

Во многих случах они служат базой для последующего создания стандартов уровня 180/1ЕС). Стандарты 150/1ЕС и АМ81/1ЕЕЕ в основном имеют рекомендательный характер.

Третье направление стимулируется министерством обороны США (Department of Defense - DOD). Создаваемые по этому направлению стандарты имеют во многих случаях характер обязательных для фирм, работающих по заказам Министерства обороны США. Для разработки критических ПС наибольшее значение получил стандарт DOD-STD-2167, регламентирующий процессы и документы от анализа требований к системе (включающей ПС) до завершения ее испытаний.

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

Стандарты жизненного цикла программных средств. Разработаны два проекта стандартов, подробно описывающих жизненный цикл критических программных средств. Первый проект, назовем его (П-1), подготовлен рабочей группой JTC1/SC7 [5], второй - (П-2) - рабочей группой IЕЕЕ [б]. Жизненный цикл ПС в обоих проектах, по существу, одинаковый и различается акцентами при детализации, количеством выделяемых и описываемых процессов, а также их компоновкой в основные этапы. В обоих проектах охватывается полный жизненный цикл ПС, в котором выделяются 6 крупных процессов (рис. 1 и 2). Эти процессы в последующем детализируются в П-1 серией из тридцати шести частных процессов, в П-2 - восемнадцатью частными процессами. В последних имеется еще более мелкая детализация в совокупности на 68 процессов (см. приложение).

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

В проекте стандарта П-1 более детально представлены процессы формализации заказа на разработку (совместно с заказчиком) на начальном этапе, а также эксплуатация и сопровождение ПС.

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

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

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

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

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

Первый процесс в П-2 — выбор модели жизненного цикла, состоит из двух частных процессов. При этом формализуются характеристики проектируемого ПС, выделяются возможные варианты моделей жизненного цикла, из которых выбирается наиболее под ходящая модель. Второй процесс — предразработка, включает исследование концепций проектируемой системы и распределение функций между аппаратурой и программным средством. Эти два частных процесса подразделяются еще на 8 более мелких процессов. Они завершаются созданием предварительной архитектуры системы и первоначальных вариантов спецификаций функциональных требований к аппаратуре, программам и интерфейсам. Наиболее подробно в П-2 представлен третий процесс — разработка ПС. В нем выделены 3 частных процесса, которые в свою очередь детализируются пятнадцатью более мелкими. В крупные процессы выделено создание требований, проектирование и разработка программ (разработка рабочего проекта). Завершается этот процесс комплексированием синтаксически отлаженных компонент полного проекта ПС. В четвертом процессе - постразработка ПС, объединены 4 частных процесса, включающие:

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

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

Основные процессы проектирования, эксплуатации и сопровождения в обоих проектах обеспечиваются и поддерживаются двумя, по существу, одинаковыми процессами:

организации проекта и интегральными процессами (см. рис. 1 и 2). При похожих названиях составы частных процессов в П-1 и П-2 заметно различаются, хотя имеют некоторые общие компоненты. В процессах организации и управления проектом тремя общими компонентами являются: процессы инициирования проектирования, контроля и управления ходом проектирования, а также управления и гарантирования качества ПС. В П-1 в этой группе представлены 9 частных процессов. Кроме перечисленных дополнительно выделяются: управление субподрядчиками по разработке, взаимодействие с организациями, осуществляющими тестирование и сертификацию ПС, взаимодействие с заказчиком, а также предъявление на испытания. В П-2 три названных частных процесса расшифровываются тринадцатью более мелкими процессами, часть которых может быть отнесена к процессу предразработки.

Интегральные процессы в обоих проектах включают конфигурационное управление и документирование, а также процессы оценки и подтверждения (verification and validation), которые далее участвуют в описаниях основных процессов разработки. Кроме того, в оба проекта входит процесс обучения, который в П-2 представлен четырьмя детальными процессами. В проекте П-1 большое внимание уделено системе формализованных отчетов и документальному оформлению результатов при завершении частных процессов ЖЦ. В проекте П-2 интегральные процессы расшифровываются семнадцатью детальными процессами. В частности, оценка и подтверждение отражены шестью детальными процессами, связанными с тестированием, отладкой и испытаниями на всех уровнях разработки.

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

Для проектирования ПС систем военного назначения Министерством обороны США разработан и утвержден стандарт ООВ-8ТО-2167 [7]. Этим стандартом регламентированы 9 фаз (этапов) и около 30 отчетных документов в процессе создания критических ПС. Сформулировано около 250 типовых обязательных требований к процессам и объектам проектирования.

Создание ПС рассматривается как часть процесса разработки информационных технологий специальных систем военного назначения. Поэтому начальные этапы проектирования и заключительные этапы испытаний и сдачи заказчику объединены в совместный анализ программных и аппаратных средств цельной системы, полностью решающей заданные функциональные задачи. В отличие от рассмотренных стандартов ISO/IEC и АNSI/IЕЕЕ в стандарте DOD представлена только часть жизненного цикла ПС. Отсутствуют этапы эксплуатации и сопровождения, а также не полностью раскрыты процессы управления разработкой и интегральные процессы поддержки жизненного цикла ПС.

В стандарте ВОВ, после того как отработаны концепции и требования к системе (этапы 1 и 2), из них выделяются и детализируются требования к ПС (этап 3). Далее начинается самостоятельный процесс разработки программ. Процесс представлен четырьмя этапами (4-7). Названия и последовательность этапов предварительного (этап 4) и детального (этап 5) проектирования, а также разработки компонент (этап 6) и их интеграции (комплексирования) (этап 7) достаточно близки к соответствующим процессам в стандартах ISO/IEC и АNSI/IЕЕЕ. После этого проводится тестирование ПС на реализующей ЭВМ (этап 8), интегрирование и испытание ПС в составе системы (этапы 9).

Весь процесс разработки поддерживается комплектом из 30 частных документов и семи сводных отчетов (обзоров). Наиболее полно раскрыты этапы предварительного (эскизного) и детального (технического) проектирования, каждый из которых отражен 6—7 процессами. Таким образом, представленную схему можно использовать как базу для планирования, организации и автоматизации процессов разработки критических ПС. В стандарте DOD-STD-2167 регламентировано также структурное построение комплексов программ военного назначения. Рекомендовано структуру ПС строить иерархически из компонент трех уровней интеграции: модули или блоки, компоненты нижнего уровня и компоненты верхнего уровня. Компоненты верхнего уровня могут быть полным программным средством для системы или решать крупные функциональные задачи.

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

Примером подобной фирменной модели ЖЦ может служить используемая в методологии Stradis фирмы McDonnel Douglas [8]. Эта модель ориентирована на создание и применение информационных систем и ПС организационного назначения. В них большое значение имеет системный анализ объектов автоматизации и начальные этапы проектирования. Разработка ПС базируется преимущественно на повторно используемых и стандартизированных компонентах, вследствие чего процедурное программирование и непосредственная разработка оригинальных программных и информационных компонент становится второстепенной. Подчеркивается роль САSЕ-средств, обеспечивающих системный анализ и предварительное проектирование, а также конфигурационное управление множеством версий ПС. В данном случае методологию и ЖЦ поддерживают конкретные САSЕ-средства. Стратегическое планирование, анализ, проектирование и разработку ПС для организационных систем обеспечивают средства автоматизации ProKit Workbench. Для последующих этапов разработки, внедрения, поддержки эксплуатации и сопровождения рекомендуются средства РRO-1У. Детализация ЖЦ ПС, представленная в рекламных проспектах фирмы, менее полная, чем в проектах стандартов ISO/IEC и АNSI/IЕЕЕ, однако уточнения модели ЖЦ содержатся в рекламных и пользовательских описаниях средств автоматизации.

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

ЛИТЕРАТУРА

1. Rosove P.E. Developing computer-based information systems.John Wiley & Sons, 1967.

2. Боэм Б.У. Инженерное проектирование программного обеспечения. Пер. с англ. / Под ред. А.А.Красилова. М.: Радио и связь, 1985.

3. Гантер Р. Методы управления проектированием программного обеспечения. Пер. с англ. / Под ред Е.А. Масловского. М., Мир, 1985.

4, Boehm B.W. Understanding and controlling software cost. Proceedings IFIP Congress 1986. North Holland, 1986, pp. 703-714.

5, ISO/IEC JTC1/SC7 N801.ISO Standart for software life-cycle process. (Project 7.21), 1990.

___________________________________________

В. В. Липаев - д-р техн. наук, профессор