Стандартизация (стр. 3 )

Международная организация по стандартизации (International Standards Organization, ISO) в рамках технического комитета ТС97 (называемого теперь как ISO/IEC JTC1) также вела работу по созданию стандарта языков реляционных баз данных. В середине 80-х годов как ANSI, так и ISO одобрили стандарты SQL (ANSI — в 1986 г., а ISO — в начале 1987 г.).

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

Однако еще до 1989 г. как в ANSI, так и в ISO началась работа по радикальным расширениям SQL. Эта работа, первоначально идентифицированная как «SQL2», началась в 1987 г., и ее результаты были спустя пять лет приняты в качестве стандарта SQL-92.

Добавляет путаницы еще и то обстоятельство, что работа над SQL2 перекрывалась работой над SQL3, новой версией стандарта SQL, которая еще до сих пор находится в стадии разработки. Работа над SQL3 началась еще в 1990 г. параллельно с SQL2, главным образом как над «запасным резервуаром» для возможностей, которые предполагалось не включать по тем или иным причинам в SQL2. SQL3 включает объектно-ориентированные расширения языка, а также дополнительные реляционные возможности, которым не нашлось места в SQL2.

Проиллюстрируем на рисунке с привязкой к оси времени процесс разработки различных стандартов SQL.

Рис. Схема истории стандартизации SQL

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

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

Недостаток этого подхода состоит в том, что стандартом становится не самое сильное, а самое массовое коммерческое решение.

В качестве еще одного примера появления стандарта можно привести появление ныне популярного UML — Unified Modeling Language. Основные разработки по методам объектно-ориентированного анализа и проектирования появились между 1988 и 1992 гг. К 1994 г. было большое количество неформальных лидеров разработчиков-практиков (около полутора десятков), которые продвигали свои методологии. Все их методы были схожи, при этом зачастую отличия между ними заключались во второстепенных деталях. Назревал разговор о стандартизации. Команда из OMG пыталась рассмотреть проблему стандартизации, но в ответ получила открытое письмо с протестом от всех авторов. В 1996 г. три ведущих специалиста в области объектно-ориентированного анализа и проектирования Джеймс Рамбо (James Rumbaugh), Гради Буч (Grady Booch), Ивар Якобсон (Ivar Jacobson) объединились, и появился на свет Унифицированный метод версии 0.8, в 1996 г. «трое друзей» работали над своим методом, который получил название Unified Modeling Language. В январе 1997 г. различные организации представили свои предложения по стандартизации методов, предусматривающие в первую очередь возможность обмена информацией между различными моделями. В результате сейчас имеется единственное предложение — стандарт UML.

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

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

Слова «жизненный цикл системы» или «жизненный цикл программного средства» часто появляются в статьях и звучат в разговорах разработчиков, по крайней мере руководителей проектов и подразделений. Всем понятно, что относятся они к тому, что и в какой последовательности должно делаться при создании и эксплуатации систем. Но прежде чем две организации или два специалиста договорятся о том, что конкретно входит или не входит в ЖЦ, проходит значительное время. А позже вполне может обнаружиться, что эти двое (две «стороны») все-таки по-разному понимают, какие работы будут входить в ЖЦ, а какие — нет, какие проверки будут планироваться, когда и т. д. Естественно, общие принципы организации работ описаны давно, но что делать сторонам в конкретном проекте — это каждый раз приходится решать заново.

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

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

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

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

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

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

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

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

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

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