Владимир Липаев
Цели стандартизации жизненного цикла сложных программных средств. В стандартах, регламентирующих жизненный цикл (ЖЦ) программных средств (ПС), обобщаются опыт и результаты исследований множества специалистов и рекомендуются наиболее эффективные современные методы и процессы создания и развития комплексов программ. В результате таких обобщений оттачиваются технологические процессы и приемы разработки, а также методическая база для их автоматизации [1, 2]. ЖЦ ПС в стандартах представляет собой набор этапов, частных работ и операций в последовательности их выполнения и взаимосвязи, регламентирующих ведение работ от подготовки технического задания до завершения испытаний ряда версий и окончания эксплуатации ПС или информационной системы (ИС).
Стандарты включают правила описания исходной информации, способов и методов выполнения операций, устанавливают правила контроля технологических процессов, требования к оформлению их результатов, а также регламентируют содержание технологических и эксплуатационных документов на комплексы программ. Они определяют организационную структуру коллектива, обеспечивают распределение и планирование заданий, а также контроль за ходом создания ПС.
В России разработка и испытания автоматизированных систем (АС), в частности ПС, регламентированы ГОСТ 34.601 - 90. Стадии создания АС, ГОСТ 34.602 - 89. ТЗ на создание АС, ГОСТ 34.603 - 92. Виды испытаний АС. Однако создание, сопровождение и развитие прикладных ПС для нынешних информационных систем в этих стандартах отражены недостаточно, а отдельные их положения устарели с точки зрения построения современных распределенных комплексов прикладных программ высокого качества в системах управления и обработки данных с различной архитектурой. Поэтому целесообразно выбирать и использовать апробированные зарубежные стандарты в этой области. Основные современные зарубежные стандарты ориентированы на описание ЖЦ сложных ПС обработки информации и управления в реальном времени. К таким ПС предъявляются наиболее высокие требования по качеству функционирования, они создаются большими коллективами специалистов в течение длительного времени [3, 4].
Представленные ниже шесть стандартов ЖЦ ПС отличаются по структуре, терминологии и графическому представлению этапов и их взаимодействию. В большинстве стандартов детализация ЖЦ ПС ограничивается 8 - 10 крупными этапами или процессами. Для практического применения стандартов при реальном планировании и управлении проектами необходима более подробная информация о содержании процессов. В подобных руководствах должны быть представлены исходные данные, содержание частных работ и ожидаемые результаты, а также структура и содержание документов, сопутствующих их реализации. Обычно такая детализация на 50 - 100 частных процессов производится в фирменных инструкциях и руководящих документах при формировании технологии и комплекса инструментальных средств поддержки разработки, сопровождения и эксплуатации конкретных ПС.
Содержание стандартов, регламентирующих ЖЦ ПС. Впервые формализованный и утвержденный стандарт жизненного цикла был утвержден в 1985 г. (уточнен в 1988 г.) для проектирования ПС систем военного назначения по заказам Министерства обороны США - стандарт DOD-STD-2167 А. Этим документом регламентированы 8 фаз (этапов) при создании сложных критических ПС и около 250 типовых обязательных требований к процессам и объектам проектирования на этих этапах.
ПС рассматриваются как часть специализированных информационных систем военного назначения. Поэтому начальные этапы проектирования и заключительные этапы испытаний и сдачи заказчику объединены в совместный анализ программных и аппаратных средств цельной системы вооружения, полностью решающей поставленные функциональные задачи. В стандарте DOD представлена часть ЖЦ ПС, отражающая только непосредственно создание программ. Отсутствуют этапы эксплуатации и сопровождения, а также не полностью раскрыты процессы управления разработкой и интегральные процессы технологической поддержки ЖЦ ПС.
В начале стандарта DOD-STD-2167 A определена область его действия и общие условия применения. Приведены базовый перечень ссылочных документов и определения понятий, терминов и аббревиатур. Основная совокупность требований изложена в двух крупных разделах: наиболее общие требования ко всему процессу создания ПС и детальные требования к каждому его этапу.
Общие требования касаются планирования и управления разработкой ПС, правил взаимодействия с субподрядчиками и испытателями, а также документирования результатов. Изложены общие требования к технологии и средствам автоматизации создания программ, к структуре и организации комплекса программ и поддерживающей его БД. Специальный раздел посвящен требованиям к квалификационным испытаниям, средствам и организации тестирования программ на всех этапах. Изложены требования к организации, выполнению и документированию оценок качества программной продукции, а также требования к конфигурационному управлению ПС. Завершаются общие требования правилами перехода к сопровождению ПС, к организации и документированию этого процесса.
Детальные требования распределены по восьми этапам разработки. В этом стандарте после того, как сформулированы концепция и общие требования к системе (этап 1), выделяются и детализируются требования к ПС (этап 2). Далее начинается собственно процесс создания программ (этапы 3 - 6). Названия, последовательность и содержание этапов предварительного (этап 3) и детального (этап 4) проектирования, а также разработки компонентов (этап 5) и их интеграции (комплексирования) и тестирования (этап 6) достаточно близки к соответствующим процессам в стандартах ISO (см. ниже). По окончании этапов 3 - 6 проводятся тестирование ПС на реализующей (объектной) ЭВМ (этап 7), интегрирование и испытание ПС в составе системы (этап 8). Для всех этапов детальные требования имеют одинаковую структуру разделов. В них для каждого этапа конкретизируются разделы общих требований и отражены требования к управлению проектом, технологии, официальным квалификационным испытаниям, оценке качества программной продукции и к конфигурационному управлению.
Весь процесс создания ПС поддерживается комплектом из 30 частных документов и 7 сводных отчетов (обзоров) по этапам. Наиболее полно раскрыты этапы предварительного (эскизного) и детального (технического) проектирования, каждый из которых состоит из 6 - 7 процессов. В результате представленную схему можно использовать как базу для планирования, организации и автоматизации процессов разработки критических ПС.
Для замены стандартов DOD-STD-2167 A, 7935 A, 1703 Министерством обороны США в декабре 1994 г. утвержден Военный стандарт MIL-STD-498. Разработка и документирование программного обеспечения. Он предназначен для применения всеми организациями и предприятиями, получающими заказы Министерства обороны США. Этот стандарт базируется на процессах и документах, представленных в стандарте ISO 12207 и предшествующих военных стандартах. Общая структура стандарта близка к структуре DOD-STD-2167 A, однако детальные требования пятого раздела изложены значительно глубже и шире в 19 подразделах. Кроме того, число приложений увеличено до девяти. В 1996 г. утверждено очень подробное (407 стр.) руководство “Применение и рекомендации к стандарту MIL-STD-498”. Основную часть пятого раздела составляют 75 подразделов - рекомендаций по обеспечению и реализации процессов ЖЦ сложных критических ПС высокого качества и надежности, функционирующих в реальном времени.
Наиболее полно и подробно ЖЦ, технология создания и обеспечения качества сложных ПС отражены в двух представленных ниже стандартах ISO. Стандарт ISO 12207:1995. Процессы жизненного цикла программных средств. Регламентирует архитектуру, процессы, разделы и подразделы ЖЦ ПС, а также перечень базовых работ и детализирует содержание каждой из них. Архитектура ЖЦ ПС в стандарте строится на трех крупных компонентах:
- основы жизненного цикла ПС и определяющие работы;
- процессы, поддерживающие жизненный цикл ПС;
4готавливается проект контракта. Организуется отслеживание проекта, его приемка и завершение. В подразделе 5.2. детализируются 23 процесса организации последующей подготовки к поставке ПС. Оцениваются отзывы фирм о проекте, заключается контракт, планируется ЖЦ, организуются поддержка разработки отчетами и обеспечение развития, а также процессы сдачи и завершения проекта.
Основные 55 работ по созданию сложного комплекса программ представлены в подразделе 5.3. Подготовка проекта начинается с определения состава сопровождающих документов, выбора средств конфигурационного управления и обеспечения качества, а также выбора методов и средств технологического обеспечения всей ИС. Анализируются и формализуются функциональные, коммерческие, пользовательские, системные требования и критерии качества ПС: защищенность, интерфейсы с внешней средой, сопровождаемость и т. д. На этой базе проектируется архитектура всей ИС, выделяются и анализируются требования к программным средствам. При формировании характеристик качества ПС рекомендуется руководствоваться стандартом ISO 9126 и предложенной в нем номенклатурой показателей. Все эти работы отражаются в документах, на каждый компонент проекта отслеживается их взаимодействие и связи с внешней средой в ИС. Кодирование и тестирование каждого компонента ПС должно быть оформлено комплексом документов, удостоверяющих соответствие первичной спецификации, содержащих тесты и результаты тестирования.
Для интеграции компонентов рекомендуется подготавливать план работ, включающий их комплексирование, тестирование по всем требованиям и показателям качества, а также документирование плана, результатов интеграции, использованных тестов, критериев оценки и полученных результатов. Затем ПС необходимо подвергнуть квалификационному (аттестационному) тестированию по всем разделам требований, при широком варьировании тестов и значений критериев, а также протестировать адекватность программам и полноту технической и пользовательской документации. Проверенный таким образом комплекс программ интегрируется с вычислительными средствами ИС, средствами визуализации и телекоммуникации. После объединения всех средств ИС система подвергается квалификационному тестированию и испытаниям на всю совокупность требований к системе, а также производится оформление и проверка полного комплекта документации. При этом рекомендуется использовать методы и средства поддержки ЖЦ ПС, изложенные в шестом разделе. Далее следует создать план установки программного продукта в соответствии с контрактом и производить инсталляции, результаты которых документируются. Должна быть обеспечена поддержка разработчиком поставки ПС.
Подраздел 5.4 состоит из 9 работ и посвящен поддержке эксплуатации. Подготовленный оператор должен освоить все процедуры применения ИС, в том числе тестирования ПС на соответствие критериям оперативного использования, указанным в документации. Поддержка пользователей подразумевает оказание помощи и консультационных услуг при обнаружении дефектов или ошибок при применении ПС в составе информационной системы.
Эти работы взаимодействуют с описанными в подразделе 5.5, обеспечивающими сопровождение ПС (24 работы). Предполагается, что сопровождение может выполняться другими специалистами, не теми, кто создавал ПС на предыдущих этапах. Они анализируют сообщения об ошибках и предложения о модификации ПС, селектируют их на соответствие требованиям контракта и оценивают целесообразность проведения изменений. Подготовленные изменения тестируют и проверяют по критериям, определенным в документации. При подтверждении необходимости изменений в программах производится корректировка документации. Далее планируется распространение внесенных изменений или новой версии пользователям, которым была поставлена предшествующая версия. Рекомендуется учитывать возможность одновременного использования клиентами версий ПС с разным составом проведенных модификаций. Некоторые версии с определенной совокупностью изменений планируются для ликвидации.
В разделе 6 представлено около 70 технологических работ, поддерживающих ЖЦ ПС. Процессы документирования ПС (6.1) охватывают планирование и регламентирование документирования, рекомендации по стандартизации, проектированию и разработке, а также по производству, конфигурационному управлению и сопровождению комплекта документации на ПС. Конфигурационное управление (6.2) включает план реализации версий как часть общего плана управления проектом, рекомендации по конфигурационной идентификации, контролю, учету, отчетности и развитию конфигурации. Обеспечение гарантий качества (6.3) включает использование планирования, методологии, процедур и стандартов качества в соответствии с контрактом и учетом доступных ресурсов. Рекомендуется обеспечивать качество конечного продукта в соответствии с документацией путем планирования и выполнения специальных работ в процессе всего ЖЦ ПС, а также на основе положений стандарта ISO 9001. Верификация ПС (6.4) включает организацию, планирование и техническое обеспечение. Представлена структура контракта на верификацию, содержание процесса, состав требований, проектирование процесса верификации, обобщение и документирование результатов. Валидация (6.5) - удостоверение правильности (аттестация) - должна гарантировать полное соответствие спецификациям, требованиям и документации на ПС и возможность его безопасного и надежного применения пользователем. Рекомендуется ее выполнение независимыми специалистами путем тестирования во всех возможных ситуациях исходных данных. По существу, этот процесс аналогичен сертификации, которая в стандарте не упоминается.
Управление проектом (6.6) подразумевает в основном подготовку и обеспечение планирования и управления ресурсами, персоналом, аппаратурой, программными средствами и инструментарием. Общий контроль проекта должен учитывать состояние доступных ресурсов и возможность изменения плана проектирования, а также систематические технические отчеты. Процессы ревизии - аудит (6.7) - служат для установления соответствия реальных работ и отчетов требованиям, планам и контракту. Ревизоры должны быть независимыми от проектировщиков ПС, они определяют состояние работ, использование ресурсов, соответствие документации спецификациям и стандартам, корректность тестирования. В процессе устранения дефектов и ошибок (6.8) решаются проблемы обеспечения последующего применения ПС и их функционирования. Каждый дефект или ошибка должны быть определены, идентифицированы, описаны, проанализированы и исправлены в процессе сопровождения в соответствии с контрактом.
Раздел 7 посвящен процессам организации ЖЦ ПС (25 работ). Процессы управления (7.1) включают основные работы по управлению проектом, производством и средствами для обеспечения прикладных процессов по созданию, эксплуатации, сопровождению ПС и поддерживающим процессам. Они охватывают подготовку концепции управления, планирование, реализацию планов и контроль, отчетность и развитие проекта, а также его завершение. Процессы образования инфраструктуры (7.2) включают выбор и установление аппаратных и программных средств, технологии, стандартов и способов обслуживания, используемых для разработки, сопровождения и обеспечения эксплуатации ПС. Инфраструктура должна модифицироваться и сопровождаться в соответствии с изменениями требований к проекту и подлежит конфигурационному управлению. Совершенствование ЖЦ ПС (7.3) подразумевает установление, оценку, измерение, контроль и корректировку процессов ЖЦ. Оно должно учитывать требования пользователей и развитие определенной технологии. Процессы обучения (7.4) определяются требованиями к проекту, должны учитывать необходимые ресурсы, управление и технические средства. Необходимо разработать и представить пользователю материалы, облегчающие обучение по соответствующему плану.
В приложении А (нормативное) изложены основы преобразования и обобщения базовой структуры этого международного стандарта для конкретного проекта. Следует подчеркнуть необходимость реализации двух важнейших вариантов адаптации положений и рекомендаций стандарта: на особенности создания потенциально мобильных ПС и на особенности ПС с использованием мобильных компонентов. Приложение В (информационное) содержит руководство по процессам адаптации и преобразования ЖЦ ПС для конкретного проекта, а также рекомендации по возможным изменениям ряда работ из разделов 5 и 6 стандарта в зависимости от характеристик объекта.
Технология обеспечения качества в ЖЦ ПС представлена в стандарте ISO 9000-3:1991. Руководящие указания предназначены для унификации описания методов разработки и поставки ПС, а также способов контроля их качества, отвечающих требованиям заказчика. Этой унификации предлагается добиваться, предотвращая отклонения от стандарта на всех этапах ЖЦ - от начала разработки до технического обслуживания и ремонта. Предполагается, что в контракте будут особо оговорены важнейшие компоненты технологии проектирования и требования к техническим характеристикам ПС, иначе это делается в процессе разработки. Поставщик должен документально оформить цели, технологию и свои обязательства по обеспечению качества ПС. Необходимо определить ответственность, полномочия и взаимодействие всего руководящего, исполняющего работы и контролирующего персонала, который влияет на качество, надежность и безопасность применения создаваемого комплекса программ. Обеспечение и проверка качества проводится персоналом поставщика, независимым от специалистов, непосредственно ответственных за выполнение работ и создание изделий. Покупатель-заказчик назначает своего представителя, ответственного за сотрудничество с поставщиком в процессе создания ПС по данному контракту. В стандарте определена структура системы обеспечения качества и ее функции в жизненном цикле ПС. Эта деятельность предусматривает:
- анализ содержания контракта, поддержанного методиками, обеспечивающими качество ПС;
- специфицирование требований заказчика, включающих все функциональные и технические характеристики, необходимые для удовлетворения запросов заказчика;
- планирование процесса создания ПС, включающее формализацию этапов, графика, ресурсов, методов и средств разработки, а также контроля и способов проверки результатов по всем этапам;
- планирование обеспечения качества компонентов, а также ПС в целом, которое должно актуализироваться и конкретизироваться по мере проведения разработки;
- проектирование и реализацию проекта, для чего определяются методология и средства проведения соответствующих работ, а также анализируются результаты обеспечения выполнения требований технического задания;
- измерения характеристик продукции и процессов ее создания, а также регистрацию данных о достигнутом качестве ПС и их компонентов;
- испытания, которые включают планирование, реализацию, оценку результатов и документирование испытаний и сертификации;
- приемку и испытания заказчиком для завершения контракта по разработке, инсталляции или обслуживанию ПС.
Кроме того, рекомендуется по согласованию с заказчиком регламентировать правила и технологию копирования, поставки, инсталляции, технического обслуживания и ремонта ПС. Независимо от этапов работ в технологии и системе качества должна быть определена деятельность по:
- формализации состава, содержания и процессам утверждения документации;
- управлению конфигурацией версий ПС и проведению изменений в программах и данных.
Стандарт IEEE 1074-1995. Процессы жизненного цикла для развития программного обеспечения. Охватывает полный жизненный цикл ПС, в котором выделяются шесть крупных базовых процессов. Эти процессы детализируются 16 частными процессами. В последних имеется еще более мелкая детализация в совокупности на 65 процессов-работ. Содержание каждого частного процесса начинается с описания общих его функций и задач и перечня действий - работ при последующей детализации. Для каждого процесса в стандарте представлена входная и результирующая информация о его выполнении и краткое описание сущности процесса. В стандарте внимание сосредоточено преимущественно на непосредственном создании ПС и на процессах предварительного проектирования. В приложении представлены четыре варианта адаптации максимального состава компонентов ЖЦ ПС к конкретным особенностям типовых проектов. Хотя основные процессы близки к описанным в стандарте ISO 12207, общая архитектура и детализация частных процессов и работ в данном стандарте значительно отличается. Процессы непосредственного создания ПС и его поддержки в стандарте представлены наибольшим числом частных процессов (около 70%), начинающимся с разработки требований к ПС и завершающимся приемо-сдаточными испытаниями, проводимыми заказчиком или пользователем.
Возрастающая роль применения комплексов программ в бортовых системах, используемых на самолетах и других объектах для управления в реальном времени, привела в начале 80-х к необходимости разработки нормативных документов и руководств, обеспечивающих высокое качество, надежность и безопасность ПС в таких системах. Для этого в США был создан документ DO-178 В “Соглашение по сертификации бортовых систем и оборудования в части программного обеспечения”, пересмотренный и развитый в дальнейшем с учетом накопленного опыта, который следует рассматривать как стандарт в этой области. Цель этого документа состоит в том, чтобы обеспечить руководящие принципы и методологию разработки ПС для бортовых систем, которые выполняют функции с высоким уровнем доверия в обеспечении безопасности, соответствующим авиационным требованиям. Этот документ ориентирован на регламентирование процессов удовлетворения ПС требованиям авиационной сертификации.
За основу представления в документе процессов разработки и сертификации принят жизненный цикл системы и его связь с ЖЦ ПС. В разделе 2 приведена информация, необходимая для понимания взаимодействия между ЖЦ системы и ЖЦ ПС. Раздел 3 является иллюстративным описанием ЖЦ ПС. Как определено в подпараграфе 2.2.2, этот документ определяет задачи для высоких уровней критичности ПС, т. е. для комплексов программ высокой надежности и безопасности применения. Разделы 4 и 5 посвящены процессам планирования и разработки ПС. Интегральные процессы - верификация, управление конфигурацией, обеспечение качества и сертификационное сопровождение - представлены в разделах 6 - 9. Раздел 11 содержит рекомендации по структуре документов, создаваемых главным образом для обеспечения сертификации ПС. В разделе 12 обсуждаются дополнительные соглашения, включая руководство по использованию ранее разработанных ПС, сертификации инструментальных средств и применению альтернативных методов для тех задач, которые обсуждаются в разделах 2 - 11. Раздел необязательно использовать при сертификации всех видов ПС. Таблицы процессов ЖЦ для вариантов уровней критичности ПС, содержащиеся в приложении А, являются нормативной частью этого документа.
Адаптация процессов и работ в стандартах жизненного цикла программных средств к характеристикам конкретных проектов. Не бывает двух одинаковых проектов. Вариации в организационных службах и процедурах, методах и стратегиях приобретения, размере и сложности проекта, требованиях системы и методах разработки среди прочего влияют на способ создания, применения и сопровождения ПС. Используемые реально в фирмах жизненные циклы ПС в последнее время зачастую отличаются от приведенных в стандартах в связи с развитием и внедрением объектно-ориентированного анализа и проектирования, а также методов быстрой разработки прикладных программ, CASE-систем и языков четвертого поколения. В новых технологиях сокращаются стадии непосредственного создания программных и информационных компонентов и детализируются процессы системного анализа и проектирования ПС в целом. Кроме того, возрастает роль и конкретизация работ по технологической поддержке и графической визуализации проектирования, а также по стандартизации интерфейсов компонентов в создаваемых приложениях. Особое внимание уделяется детализации процессов ЖЦ, обеспечивающих высокое качество создаваемых ПС и возможности их эффективного итерационного развития длительное время в многочисленных версиях [1].
Отечественные разработчики и пользователи современных инструментальных средств создания программ, как правило, не знают и не учитывают опыт, формализованный и отраженный в зарубежных стандартах на ЖЦ ПС. Технологические комплексы собираются из отдельных, относительно слабо связанных инструментальных пакетов прикладных программ, решающих частные задачи автоматизации без анализа и учета всего ЖЦ ПС. В результате технология и процессы разработки формируются не системно - с позиции достижения наивысших показателей эффективности и качества всего жизненного цикла конкретного ПС, а с позиции скорейшего достижения видимых для заказчика результатов проекта. В случае критических ПС это сказывается впоследствии на их низкой надежности функционирования и безопасности применения, а также затрудняет модернизацию и развитие версий.
Альтернативой является выбор и формирование комплекса инструментальных средств под технологию, формализованную на базе одного из адаптированных стандартов ЖЦ ПС. Для снижения затрат и обеспечения качества выбранный стандарт ЖЦ следует адаптировать к индивидуальному проекту ПС. Должны быть определены характеристики окружения проекта, которые могут воздействовать на адаптацию. Этими характеристиками могут быть: функции ЖЦ информационной системы; требования системы и ПО; организационные основы коллективов специалистов, процедуры и стратегии их работы; размер, критичность и типы системы; число задействованного персонала и сторон-участников.
В стандартах на ЖЦ ПС отражено содержание этапов работ и результирующих документов на методологическом и концептуальном уровне. Методы и средства реализации каждой работы в этих стандартах не раскрываются и адресуются к специальным, детализирующим нормативным документам различного уровня. Однако ряд характерных особенностей этапов принципиально не позволяет создать полную гамму международных стандартов, поддерживающих все этапы и процессы ЖЦ ПС. Например, быстро оснащающиеся различными методами и инструментальными средствами этапы системного анализа, моделирования и предварительного проектирования не позволяют стабилизировать основу этих процессов, достаточную для формализации на уровне международных стандартов, для подготовки которых требуется несколько лет. Поэтому для этих этапов создаются нормативные документы на уровне стандартов де-факто, руководств фирм или сопровождающей документации конкретных инструментальных средств.
1. Sommerville I. Software engineering. Addison - Wesley. LancasterUniversity,1992.
2. Cargill C.F. Information technologie stangardisation. Digital Press, 1989.
3. Липаев В. В., Филинов Е. Н. Мобильность программ и данных в открытых информационных системах. М., РФФИ, 1997.
4. Щербо В. К., Козлов В. А. Функциональные стандарты в открытых системах. Ч. 1. Концепция открытых систем. М., МЦНТИ, 1997.
С автором статьи можно связаться по телефону: (095) 196-6365.
