Другие журналы

научное издание МГТУ им. Н.Э. Баумана

НАУКА и ОБРАЗОВАНИЕ

Издатель ФГБОУ ВПО "МГТУ им. Н.Э. Баумана". Эл № ФС 77 - 48211.  ISSN 1994-0408

Стандарты, регламентирующие жизненный цикл сложных комплексов программ информационных систем

#7 июль 2006

В. В. Липаев, д-р техн. наук, Институт системного программирования РАН

 

Стандарты, регламентирующие жизненный цикл сложных комплексов программ информационных систем

 

Изложены цели стандартизации жизненного цикла сложных программных средств и особенности содержания шести стандартов в этой области. Рассмотрены принципы адаптации процессов и работ, представленных в стандартах, к характеристикам конкретных проектов комплексов программ.

 

Цели стандартизации жизненного цикла сложных программных средств

 

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

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

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

В России создание и испытания автоматизированных систем (АС), которые включают, в частности, ПС, регламентированы ГОСТ 34.601-90 (Стадии создания АС), ГОСТ 34.602—89 (ТЗ на создание АС), ГОСТ 34.603-92 (Виды испытаний АС). Однако создание, сопровождение и развитие прикладных программных средств для современных информационных систем в этих стандартах отражены недостаточно, а отдельные их положения устарели с точки зрения построения современных распределенных комплексов прикладных программ высокого качества в системах управления и обработки данных с различной архитектурой. В результате для каждого серьезного проекта приходится создавать комплекты нормативных и методических документов, регламентирующих процессы, этапы, работы и документы конкретного проекта прикладного программного средства, поэтому в отечественных разработках целесообразно выбирать и использовать отработанные зарубежные стандарты в этой области.

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

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

 

Содержание стандартов, регламентирующих жизненный цикл программных средств

 

Впервые формализованный и утвержденный стандарт жизненного цикла был разработан в 1985г. (уточнен в 1988г.) для проектирования ПС систем военного назначения по заказам Министерства обороны США — стандарт DOD-STD-2167 А. Этим документом регламентированы восемь фаз (этапов) в процессе создания сложных критических ПС и около 250 типовых обязательных требований к процессам и объектам проектирования на всех этапах разработки.

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

В начале стандарта DOD-STD-2167 А определена область его действия и общие условия применения. Приводятся базовый перечень ссылочных документов и определения основных понятий, терминов и аббревиатур. Основная совокупность требований изложена в двух крупных разделах: наиболее общие требования ко всему процессу разработки и детальные требования к каждому этапу разработки.

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

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

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

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

Для замены стандартов DOD-STD-2167 A, 7935 А, 1703 Министерством обороны США в декабре 1994 года утвержден Военный стандарт MIL-STD-498 "Разработка и документирование программного обеспечения". Стандарт предназначен для применения всеми организациями и предприятиями, работающими по заказам Министерства обороны США. Отмечается, что этот стандарт базируется на процессах и документах, представленных в стандарте ISO 12207 и предшествовавших военных стандартах. Общая структура стандарта близка к структуре DOD-STD-2167 А, однако детальные требования в разделе 5 изложены значительно глубже и шире в 19 подразделах. Кроме того, число приложений увеличено до девяти. В них, в частности, представлены рекомендации по переходу при разработке программных средств со стандарта DOD-STD-2167 А на этот стандарт. Отдельным документом в 1996 году утверждено очень подробное (407 стр.) руководство "Применение и рекомендации к стандарту MIL-STD-498". Его основной объем в разделе 5 составляют 75 подразделов — рекомендаций по обеспечению и реализации процессов жизненного цикла сложных, критических программных средств высокого качества и надежности, функционирующих в реальном времени.

Наиболее полно и подробно ЖЦ, технология разработки и обеспечения качества сложных программных средств отражены в двух представленных ниже стандартах ISO. Стандарт ISO 12207:1995 "Процессы жизненного цикла программных средств" определяет архитектуру, процессы, разделы и подразделы ЖЦ ПС, а также перечень базовых работ и детализирует содержание каждой из них. Архитектура ЖЦ ПС в стандарте базируется на трех крупных компонентах:

·        основы жизненного цикла ПС и определяющие работы;

·        процессы и работы, поддерживающие жизненный цикл ПС;

·        организация и управление жизненным циклом ПС.

Стандарт состоит из семи разделов и четырех приложений. Разделы 1—4 являются вводными. В разделе 1 сформулированы цели стандарта, области его применения, подчеркнуты его гибкость и ограничения при использовании. В разделе 2 приведены нормативные ссылки на некоторые общие стандарты, поддерживающие разработку и качество ПС и их компонентов, а также терминологию. В разделе 3 аннотированы основные термины, ис­пользуемые в дальнейшем. Общая структура основных разделов (5—7) и их краткое содержание изложено в разделе 4. Последующие — разделы 5, 6, 7 стандарта состоят из ряда подразделов, в которых подробно раскрывается содержание каждой работы и комментируются особенности их выполнения. Такие комментарии каждого подраздела состоят в среднем из 3—6 процессов — работ. Общее число работ и комментариев к ним в стандарте свыше 220.

Основные работы по подготовке, разработке, эксплуатации и сопровождению программных средств изложены в разделе 5. Процесс приобретения или подготовки к созданию ПС (подраздел 5.1) отражается 23 работами и начинается с инициализации проекта, анализа концепции и рынка продуктов, выработки требований и состава поддерживающих документов, создания предварительного плана действий. Далее анализируются предложения возможных исполнителей на разработку и подготовляется проект контракта. Организуется отслеживание разработки, ее приемки и завершения. В подразделе 5.2 детализируются 23 процесса организации последующей подготовки к поставке ПС. Оцениваются отклики фирм на предложение по созданию проекта, заключается контракт, планируется жизненный цикл, организуются поддержка разработки отчетами и обеспечение развития, а также процессы сдачи и завершения проекта.

Основные 55 работ по созданию сложного комплекса программ представлены в подразделе 5.3. Подготовка проекта начинается с создания состава сопровождающих документов, выбора средств конфигурационного управления и обеспечения качества, а также выбора методов и средств технологического обеспечения разработки всей информационной системы. Анализируются и формализуются системные требования и критерии качества ПС: функциональные, коммерческие, пользовательские, защищенности, интерфейсов с внешней средой, сопровождаемое и т. д. На этой базе проектируется архитектура всей ИС, выделяются и анализируются требования к программным средствам. Рекомендуется при формировании характеристик качества ПС руководствоваться стандартом ISO 9126 и предложенной в нем номенклатурой показателей. Все эти работы отражаются совокупностью документов на каждый компонент проекта, их взаимодействие и связи с внешней средой в ИС. Кодирование и тестирование каждого компонента ПС должно быть оформлено совокупностью документов, удостоверяющих соответствие первичной спецификации, содержащих тесты и результаты тестирования.

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

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

Эти работы взаимодействуют с работами подраздела 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 и б стандарта в зависимости от характеристик объекта разработки.

Технология обеспечения качества в жизненном цикле ПС развивается в стандарте ISO 9000-3:1991. Руководящие указания предназначены для унификации описания методов разработки и поставки ПС, а также способов контроля их качества, отвечающих требованиям заказчика. Это предлагается достигать посредством предотвращения отклонений от стандарта на всех этапах ЖЦ от начала разработки до технического обслуживания и ремонта. Предполагается, что контрактом особо оговариваются важнейшие компоненты технологии проектирования и требования к техническим характеристикам ПС или их предстоит установить в процессе разработки. Руководство поставщика должно документально оформить цели, технологию и свои обязательства по обеспечению качества ПС. Должны быть определены ответственность, полномочия и взаимодействие всего руководящего, исполняющего работы и контролирующего персонала, который влияет на качество, надежность и безопасность применения создаваемого комплекса программ.

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

В стандарте определена структура системы обеспечения качества и ее функции в жизненном цикле ПС. Эта деятельность предусматривает:

·        анализ содержания контракта, поддержанного методиками, обеспечивающими качество ПС;

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

·        планирование процесса разработки, включающее формализацию этапов, графика, ресурсов, методов и средств разработки, а также контроля и способов проверки результатов по этапам работ;

·        планирование обеспечения качества компонентов, а также ПС в целом, которое должно актуализироваться и конкретизироваться по мере проведения разработки;

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

·        измерения характеристик продукции и процессов ее создания, а также регистрацию данных о достигнутом качестве ПС и их компонентов;

·        испытания, которые включают планирование, реализацию, оценку результатов и документирование испытаний и сертификации;

·        приемку и испытания заказчиком для завершения контракта по разработке, инсталляции или обслуживанию ПС.

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

·        формализации состава, содержания и процессам утверждения документации;

·        управлению конфигурацией версий ПС и проведению изменений в программах и данных.

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

Стандарт IEEE 1074-1995 "Процессы жизненного цикла для развития программного обеспечения" охватывает полный жизненный цикл ПС, в котором выделяются шесть крупных базовых процессов. Эти процессы детализируются 16 частными процессами. В последних имеется еще более мелкая детализация в совокупности на 65 процессов — работ. Содержание каждого частного процесса начинается с описания общих его функций и задач и перечня действий — работ при последующей детализации. Для каждой работы в стандарте представлена входная и результирующая информация при ее выполнении и краткое описание сущности процесса. В стандарте внимание сосредоточено преимущественно на непосредственной разработке ПС и на процессах предварительного проектирования. В приложении представлены четыре варианта адаптации максимального состава работ ЖЦ ПС к конкретным особенностям типовых проектов.

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

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

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

Четвертый процесс — разработка ПС — представлен наиболее подробно. В нем выделены три частных процесса, которые, в свою очередь, детализируются 14 работами. В крупные процессы выделены создание требований, проектирование и разработка программ (разработка рабочего проекта). Завершается этот процесс комплексированием синтаксически отлаженных компонентов полного проекта ПС.

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

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

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

Возрастающая роль применения комплексов программ в бортовых системах, используемых на самолетах и других объектах для управления в реальном времени, привела в начале 1980-х годов к необходимости разработки нормативных документов и руководств, обеспечивающих высокое качество, надежность и безопасность ПС в таких системах. Для этого в США был создан документ DO-178 В "Соглашение по сертификации бортовых систем и оборудования в части программного обеспечения", пересмотренный и развитый в дальнейшем с учетом накопленного опыта, который следует рассматривать как стандарт в этой области. Цель этого документа состоит в том, чтобы обеспечить руководящие принципы и методологию разработки ПС для бортовых систем, которые выполняют предназначенные функции с высоким уровнем доверия в обеспечении безопасности, соответствующим авиационным требованиям. Этот документ ориентирован на регламентирование процессов удовлетворения требований авиационной сертификации, к которым относятся ПС, используемые на самолетах.

Чтобы представить в документе процесс разработки и сертификации, за основу принят жизненный цикл системы и его связь с жизненным циклом ПС. Раздел 2 обеспечивает информацию, необходимую для понимания взаимодействия между жизненным циклом системы и жизненным циклом ПС. Точно так же раздел 3 является иллюстративным описанием жизненного цикла ПС. Как определено в подпараграфе 2.2.2, этот документ определяет задачи для высоких уровней критичности ПС, т. е. для комплексов программ высокой надежности и безопасности применения. Разделы 4 и 5 посвящены процессам планирования и разработки ПС. Интегральные процессы — верификация, управление конфигурацией, обеспечение качества и сертификационное сопровождение — представлены в разделах 6—9. Раздел 11 содержит рекомендации по структуре документов, создаваемых главным образом для обеспечения процесса сертификации ПС. В разделе 12 обсуждаются дополнительные соглашения, включая руководство по использованию ранее разработанных ПС, сертификации инструментальных средств и использованию альтернативных методов для тех задач, кото­рые обсуждаются в разделах 2—11. Раздел необязательно использовать при сертификации всех видов ПС. Таблицы процессов ЖЦ для вариантов уровней критичности ПС, содержащиеся в приложении А, являются нормативной частью этого документа.

 

Адаптация процессов и работ в стандартах жизненного цикла программных средств к характеристикам конкретных проектов

 

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

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

Альтернативой является выбор и формирование комплекса инструментальных средств под технологию, формализованную на базе одного из адаптированных стандартов ЖЦ ПС. Для сокращения стоимости и обеспечения качества выбранный стандарт ЖЦ следует адаптировать к индивидуальному проекту ПС. Должны быть определены характеристики окружения проекта, которые могут воздействовать на адаптацию. Этими характеристиками могут быть: функции ЖЦ информационной системы; требования системы и программного обеспечения; организационные основы коллективов специалистов, процедуры и стратегии их работы; размер, критичность и типы системы; число задействованного персонала и сторон-участников.

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

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

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

 

Список литературы

1. Sommcrville I. Software engineering. Addison — Wesley. Lancaster University. 1992.

2. Cargill C. F. Information technologie stangardisation. Digital Press. 1989.

3. Липаев В. В., Филинов Е. Н. Мобильность программ и данных в открытых информационных системах. М.: РФФИ. 1997. 368 с.

4. Щербо В. К., Козлов В. А. Функциональные стандарты в открытых системах. Часть 1. Концепция открытых систем. М.: Изд. МЦНТИ. 1997.

5. Калянов Г. Н. Консалтинг при автоматизации предприятий. Подходы, методы, средства. М.: СИНТЕГ. 1997.

 

ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ, № 9, 1998

ОБЩИЕ ВОПРОСЫ ИНФОРМАТИЗАЦИИ

 

 

Поделиться:
 
ПОИСК
 
elibrary crossref ulrichsweb neicon rusycon
 
ЮБИЛЕИ
ФОТОРЕПОРТАЖИ
 
СОБЫТИЯ
 
НОВОСТНАЯ ЛЕНТА



Авторы
Пресс-релизы
Библиотека
Конференции
Выставки
О проекте
Rambler's Top100
Телефон: +7 (915) 336-07-65 (строго: среда; пятница c 11-00 до 17-00)
  RSS
© 2003-2024 «Наука и образование»
Перепечатка материалов журнала без согласования с редакцией запрещена
 Тел.: +7 (915) 336-07-65 (строго: среда; пятница c 11-00 до 17-00)