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

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ им. Н.Э. БАУМАНА

КАФЕДРА САПР

Волосатова Т.М. Родионов С.В. Романова Т.Н. Методическое пособие по использованию стандартов, обеспечивающих разработку интерфейсов пользователей с операционной средой.

Москва

Современная индустрия программного обеспечения (ПО) характеризуется очень высокой степенью конкуренции. Для успешной работы на этом рынке компания должна разрабатывать, внедрять и сопровождать программное обеспечение быстро, в срок и с удовлетворительным качеством. Поэтому многие компании вкладывают деньги в улучшение качества процесса, памятуя о том, что подобное вложение денег обязательно окупается, - изучение документированных случаев улучшения процессов разработки ПО показывает, что в успешных случаях наблюдается существенное улучшение производительности и качества со средним уровнем возврата вложений от 5:1 до 8:1 [1]. Существуют десятки различных подходов к обеспечению качества ПО, и у всех есть свои преимущества. Одной из первых моделей качества стал стандарт ISO (Международной организации по стандартизации) серии 9000, первая версия которого была выпущена в 1987 году. С тех пор сертификаты ISO серии 9000 сохраняют неизменную популярность и признаются во всем мире. Однако время не стоит на месте, и методики, положенные в основу стандартов серии ISO 9000, постепенно устаревают. Выделим наиболее существенные недостатки: • • недостаточная подробность стандарта, возможность самых различных его толкований в зависимости от представлений аудитора; • • неточность оценки качества процессов, задействованных при создании и внедрении программного обеспечения; • • отсутствие в стандарте механизмов, способствующих улучшению существующих процессов. Перечисленные проблемы заставили экспертов разрабатывать более совершенные решения в области обеспечения качества, что привело к созданию в начале 90-х годов целого ряда новых стандартов и методологий. Опишем два наиболее удачных и содержательных стандарта – Capability Maturity Model (CMM) и ISO/IEC 15504 (SPICE). Существуют и другие достаточно развитые методологии, но, к сожалению, невозможно осветить все перспективные направления данной области. Поэтому мы ограничимся упоминанием того, что за рамками данного обзора остались такие стандарты, как Bootstrap , во многом схожий с рассматриваемыми стандартами CMM и SPICE, Trillium, ориентированный на разработку продуктов в области телекоммуникаций, и ISO 12207, посвященный жизненному циклу программного обеспечения. Будем проводить параллели между двумя рассматриваемыми стандартами и ISO 9001, чтобы подчеркнуть сходство и различия между ними. СММ Официальная история CMM (Capability Maturity Model, что обычно переводят как «модель зрелости процесса разработки ПО», хотя более верным по смыслу был бы перевод «модель совершенствования возможностей») начинается в 1991 году, когда американский институт SEI (Software Engineering Institute – Институт системного программирования при университете Карнеги-Меллон) опубликовал первую версию этого стандарта. Изначальной целью разработки стандарта было создание методики, позволяющей крупным правительственным организациям США выбирать наилучших поставщиков ПО. Для этого предполагалось создать исчерпывающее описание способов оценки процессов разработки ПО и методики их дальнейшего усовершенствования. В результате авторам удалось добиться такой степени подробности и детализации, что стандарт оказался пригодным и для обычных компаний-разработчиков, желающих улучшить существующие процессы. Главным понятием стандарта является зрелость организации. Незрелой считается организация, в которой процесс разработки программного обеспечения зависит только от конкретных исполнителей и менеджеров и решения зачастую просто импровизируются «на ходу». В этом случае велика вероятность превышения бюджета или заваливания сроков сдачи проекта, и потому менеджеры вынуждены заниматься только разрешением ближайших проблем. С другой стороны, в зрелой организации имеются четко определенные процедуры создания программных продуктов и управления проектами. Эти процедуры по мере необходимости уточняются и совершенствуются в пилотных проектах или с помощью анализа «стоимость/прибыль». Оценки времени и стоимости выполнения работ основываются на накопленном опыте и достаточно точны. Наконец, в компании существуют стандарты на процессы разработки, тестирования и внедрения ПО, правила оформления конечного программного кода, компонентов, интерфейсов и т. д. Все это составляет инфраструктуру и корпоративную культуру, поддерживающую процесс разработки программного обеспечения. Таковы базовые посылки стандарта СММ. Можно сказать, что стандарт в целом состоит из критериев оценки зрелости организации и рецептов улучшения существующих процессов. В этом наблюдается принципиальное различие с моделью, принятой в ISO 9001, так как в ISO 9001 сформулированы только необходимые условия для достижения некоторого минимального уровня организованности процесса и не дается никаких рекомендаций по дальнейшему существованию процессов. В модели СММ определено пять уровней зрелости организаций. В результате аттестации компании присваивается определенный уровень, который в дальнейшем может повышаться или (теоретически)

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

Рис.1. Пять уровней зрелости в модели СММ Начальный уровень (initial level) описан в стандарте в качестве основы для сравнения со следующими уровнями. На предприятии начального уровня организации не существует стабильных условий для созданий качественного программного обеспечения. Результат любого проекта целиком и полностью зависит от личных качеств менеджера и опыта программистов, причем успех одного проекта может быть повторен только в случае назначения тех же менеджеров и программистов на следующий проект. Более того, если такие менеджеры или программисты уходят с предприятия, то с их уходом резко падает качество производимых программных продуктов. В стрессовых ситуациях процесс разработки сводится к написанию кода и его минимальному тестированию. Для достижения повторяемого уровня (repeatable level) на предприятии должны быть внедрены технологии управления проектами. При этом планирование проектами основывается на накопленном опыте, существую стандарты на разрабатываемое программное обеспечение (причем обеспечивается следование этим стандартам) и существует специальная группа обеспечения качества. В случае необходимости организация может воздействовать с субподрядчиками. В критических условиях процесс имеет тенденцию скатываться на начальный уровень. Далее следует определенный уровень (defined level), который характеризуется тем, что стандартный процесс создания и сопровождения программного обеспечения задокументирован (включая и разработку ПО, и управление проектами). Подразумевается, что в процессе стандартизации происходит переход на наиболее эффективные практики и технологии. Для создания и поддерживания стандарта в организации должна быть создана специальная группа. Наконец, обязательным условием для достижения данного уровня является наличие на предприятии программы постоянного повышения квалификации и обучения сотрудников. Начиная с этого уровня, организация перестает зависеть от качеств конкретных разработчиков и не имеет тенденции скатываться на уровень ниже в стрессовых ситуациях. На управляемом уровне (manager level) в организации устанавливаются количественные показатели качества – как на программные продукты, так и на продукты в целом. Таким образом, более совершенное управление проектами достигается за счет уменьшения отклонений различных показателей проекта. При этом осмысленные вариации в производительности процесса можно отличить от случайных вариаций (шума), особенно в хорошо освоенных областях. Наконец, оптимизирующий уровень (optimizing level) характеризуется тем, что мероприятия по улучшению применяются не только к существующим процессам, но и для оценки эффективности ввода новых технологий. Основной задачей всей организации на этом уровне является постоянное улучшение

существующих процессов. При этом улучшение процессов в идеале должно помогать предупреждать возможные ошибки или дефекты. Кроме того, должны вестись работы по уменьшению стоимости разработки программного обеспечения, например, с помощью создания и повторного использования компонентов. При сертификации проводится оценка соответствия всех ключевых областей по 10-балльной шкале. Для успешной квалификации данной ключевой области необходимо набрать не менее 6 баллов. Оценка ключевой области производится по следующим показателям: 1. 1. Заинтересованность руководства в данной области (планируется ли практическое внедрение данной ключевой области, существует ли понимание у руководства необходимости данной области и т. д.). 2. 2. Насколько широко данная область применяется в организации (например, оценке 4 балла соответствует фрагментное применение). 3. 3. Успешность использования данной области на практике (например, оценке 0 баллов соответствует полное отсутствие какого-либо эффекта, а оценка 8 баллов выставляется при наличии систематического и измеримого положительного результата практически по всей организации). В принципе, можно сертифицировать только один процесс или подразделение организации; например: подразделение разработки программного обеспечения компании IBM сертифицировано на пятый уровень. Кстати, в мире существует совсем немного компаний, которые могут похвастаться наличием у них пятого уровня СММ хотя бы на одном из подразделений,– таких всего 50. С другой стороны, насчитывается несколько тысяч компаний, сертифицированных по 3-му или 4-му уровню, то есть существует колоссальный разрыв между оптимизированным уровнем зрелости и предыдущими уровнями. Однако еще больший разрыв наблюдается между количеством организаций начального уровня и числом их более продвинутых собратьев – по некоторым оценкам, свыше 70% всех компаний-разработчиков находятся на первом уровне СММ [2]. Интересен вопрос о соотношении уровней СММ со стандартом ISO 9001: на каком уровне СММ должна находиться организация, чтобы получить сертификат соответствия ISO 9001? На первый взгляд, для этого необходимо иметь минимум 3-й или 4-й уровень СММ. Тем не менее, существуют примеры организаций 1-го уровня, имеющих сертификат ISO 9001. Одной из причин возникновения подобных несуразиц является высокий уровень абстракции ISO 9001 и связанная с этим свобода его интерпретации аудитором. Иногда, как это ни странно, аудиторам не хватает элементарного знакомства с реальной практикой разработки программ. Более подробный отчет о соотношении ISO 9001 и СММ приведен в статье [3]. Некоторые важные вопросы, например отбор, повышение квалификации и сохранение компетентных сотрудников, остались за рамками СММ. Тем не менее, эти вопросы исключительно важны, ибо, как замечено в статье [4], «…и 20-30 лет назад было известно, что два программиста, сидящих за соседними столами и получающих одинаковую зарплату, могут писать программы, отличающиеся по скорости счета, скажем, в 10 раз». Кстати, ситуация в России еще сложнее по сравнению с западными странами – российские программисты могут не только перейти на другую работу, но и переехать в другую страну с более высоким уровнем зарплаты! Естественно, особенно важен подбор сотрудников для организаций первого уровня, так как сотрудники для них являются естественной гарантией качества. Но и на более высоких уровнях зрелости «человеческий фактор» сохраняет свою значимость. Поэтому в 1995 году был опубликован стандарт People CMM, являющийся дополнением к Software CMM и имеющий, в целом, похожую структуру. Внедрение этого стандарта параллельно с обычным СММ обеспечивает организацию целым набором процедур по оценке и развитию всей системы найма, обучения и сохранения квалифицированных сотрудников. В интересной, хотя и несколько эксцентричной форме идеи People CMM сформулированы одним из ее ведущих авторов в статье [5]. Кроме People CMM, возникло еще несколько моделей, дополняющих СММ, например, в приобретении ПО или разработке крупных систем. В целях полной интеграции этих моделей и снижении общих затрат по их внедрению был предпринят проект СММ Integration (ради его выполнения в 1998 году был даже отменен выпуск СММ версии 2.0). К сожалению, использование СММ затрудняет следующие проблемы: стандарт СММ является собственностью Software Engineering Institute и не является • • общедоступным (в частности, дальнейшая разработка стандарта ведется самим институтом, без заметного влияния остальной части программистского сообщества); • • оценка качества процессов организаций может проводиться только специалистами, прошедшими специальное обучение и аккредитованными SEI; стандарт ориентирован на применение в относительно крупных компаниях. • • С некоторыми свободно распространяемыми материалами по СММ можно познакомиться на сайте Software Engineering Institute (http://www.sei.cmu.edu/cmm) или в статье [1].

SPICE В 1991 году Международная организация по стандартизации инициировала работу по созданию единого стандарта оценки программных процессов. Стандарт получил имя SPICE (сокращение от Software Process Improvement and Capability dEtermination – определение возможностей и улучшение процесса создания программного обеспечения). Официально стандарт называется «ISO/IEC 15504: Information Technology – Software Process Assessment» и на данный момент существует в качестве рабочей версии, последний выпуск который состоялся в мае 1998 года. Задачей SPICE является создание международного стандарта, в котором был бы учтен весь накопленный опыт в области разработки ПО. На рис. 2 показаны наиболее значительные стандарты, идеи которых были использованы при создании SPICE.

Рис.2. Предшественники стандарта SPICE Итак, стандарт SPICE унаследовал многие черты более ранних стандартов, в том числе и уже упоминавшихся ISO 9001 и СММ. Для этого пришлось прибегнуть к повышению уровня детализации стандарта. Следствием такого основательного подхода является большой объем стандарта: документация к нему содержит около 500 страниц! Больше всего SPICE напоминает СММ. Точно так же, как и в СММ, основной задачей организации является постоянное улучшение процесса разработки ПО. Кроме того, в SPICE тоже используется схема с различными уровнями возможностей (в SPICE определено 6 различных уровней), но эти уровни применяются не только к организации в целом, но и к отдельно взятым процессам. В табл. 1 приведены список уровней способностей модели SPICE и характерные для них процедуры управления. Отметим, что на данный момент не существует русского перевода стандарта SPICE, поэтому использованные термины не являются общепринятыми или официально зарегистрированными. Уровни Уровень 0 Уровень 1 1.1 Уровень 2 2.1 2.2 Уровень 3 3.1 3.2 Уровень 4 4.1 4.2 Уровень 5

Название Процесс не выполняется Выполняемый процесс Измерение производительности процесса Управляемый процесс Управление производительностью Управление созданием продуктов Установленный процесс Документирование процесса Отслеживание ресурсов процесса Предсказуемый процесс Измерение процесса Управление процессом Оптимизирующий процесс

5.1 5.2

Изменение процесса Постоянное совершенствование

Таблица 1. Уровни способностей процесса в стандарте SPICE Таким образом, процессы в модели SPICE могут быть представлены следующим образом (рис. 3).

Рис.3. Упрощенная модель оценки процессов в стандарте SPICE Поэтому иногда говорят, что модель SPICE является двухмерной – на одной оси откладываются процессы, а на другой оси – достигнутый уровень возможностей для этих процессов. Во время оценки и улучшения качества процессов выполняются следующие задачи (рис. 4):

Рис. 4. Основные элементы стандарта SPICE 1. 1. Оценка процесса – происходит путем сравнения процесса разработки ПО, существующего в данной организации, с описанной в стандарте моделью. Анализ результатов, полученных на этом этапе, помогает определить сильные и слабые стороны процесса, а также внутренние риски, присущие данному процессу. Это помогает оценить эффективность процессов, определить причины ухудшения качества и связанные с этим издержки во времени или стоимости. 2. 2. Определение возможностей процесса – позволяет оценить возможности улучшения данного процесса. Очень часто определение возможностей процесса производится компанией-поставщиком, чтобы убедить существующих или потенциальных заказчиков в своей способности достичь заданных показателей. 3. 3. В результате предыдущих шагов в организации может появиться понимание необходимости улучшения того или иного процесса. К этому моменту цели совершенствования процесса уже четко сформулированы и остается только техническая реализация поставленных задач. После этого весь цикл работ начинается сначала. Скажем несколько строк о структуре документации по стандарту SPICE. Набор документов по SPICE состоит из 9 частей. Первая часть «Введение и основные концепции» и девятая часть «Словарь» носят чисто информационный характер. Самым важным элементом SPICE является наибольшая часть документов, а именно: части со второй по шестую. Например, вторая часть стандарта содержит так называемую

эталонную модель (reference model), которая описывает процессы. Практически, это модель процессов из ISO 12297, хотя, к сожалению, эти модели не полностью идентичны. Результаты оценки процессов с помощью SPICE выглядят достаточно сложно и потому требуют некоторого упрощения для понимания неподготовленным человеком (например, такое упрощение было проделано при создании рис. 3). Остальные части стандарта – седьмая и восьмая – посвящены соответственно, улучшению процесса и определению возможностей процесса. Одним из важных достоинств SPICE является его открытость и свободное распространение. В отличие от большинства прочих стандартов, полный текст SPICE можно получить на официальном сайте SPICE: http://www.sqi.gu.edu.au/spice. В табл. 2 кратко сформулированы преимущества SPICE по сравнению с ISO 9001. SPICE Объемный и подробный документ Детальная модель Улучшение процесса и определение возможностей Шесть уровней возможностей процесса Требования к оценке процесса, руководство по применению Дополняет ISO 9001

ISO 9001 Краткий документ Абстрактная модель Только сертификация Сертификация/отказ Только модель

Может быть детализирован с помощью SPICE Таблица 2. Сравнение стандартов SPICE и ISO 9001 SPICE предоставляет более полный набор средств по обеспечению качества и улучшению процессов, чем ISO 9001. Поэтому для обеспечения качества процессов разработки ПО мы рекомендуем использовать именно SPICE. Это поможет организации заметно улучшить существующие процессы, а затем при необходимости получить и сертификат ISO 9001. Накопленный опыт решения проблемы качества по такой схеме отражен в статье [6] (в частности, в ней сформулирован набор минимальных требований к различным процессам в организации согласно модели SPICE, достаточный для получения сертификата ISO 9001). Использовать SPICE можно и в небольших компаниях – об этом свидетельствуют результаты работы проекта SPIRE, в рамках которого проводилось внедрение процессов улучшения качества в малых (менее 50 человек) компаниях из различных стран Европы. Как показал опыт, и при небольших денежных вложениях в мелких компаниях можно добиться существенного увеличения производительности труда и улучшения качества производственных продуктов. Результаты исследований, проведенных в рамках проекта SPIRE, можно найти по адресу: http://www.cse.dsu.ie/spire. В связи со своей открытостью стандарт SPICE популярен и по нему существует много свободно доступных материалов. Например, на официальном сайте SPICE любая организация может зарегистрироваться для участия в SPICE Trials (пробных применениях). На сайте группы пользователей SPICE (см. http://www.iese.fhg.de/SPICE) собрано большое количество информации о самом стандарте, доступных ресурсах и его применении на практике. С августа 1999 года выходит журнал SPICE.World, целиком посвященный SPICE (существует электронная версия этого журнала – см. http://www.spiceworld.htm). В России стандарт SPICE пока еще делает только самые первые шаги. В октябре 1997 года в СанктПетербурге состоялся первый семинар, посвященный SPICE. Его организатором выступили финские компании SEC Oy и STTF Oy. С тех пор семинары по SPICE в Санкт-Петербурге проводятся этими компаниями не реже двух раз в год.

Стандарты, поддерживающие создание мобильных программ в информационных системах Стандарты, регламентирующие интерфейсы приложений с операционной средой По функциональному назначению документы POSIX можно разделить на четыре группы стандартов (рис. 5): — базовые, определяющие общие принципы построения, директивы, основы реализации и методологию тестирования интерфейсов мобильных приложений, а также общее административное управление программами и данными (IEEE 1003.1; -2;-3; -4; -7); — конкретизирующие интерфейсы с операционной платформой прикладных программ, разрабатываемых на трех базовых языках программирования -- Си, Фортран и Ада (IEEE 1003.5; -9;-16; -19; -20); — определяющие взаимодействие в распределенных открытых системах, телекоммуникацию в сетях, а также защиту информации (IEEE 1003.6; -8; -12; -15; -17); — регламентирующие процессы создания, основные компоненты и структуру профилей прикладного окружения для:

интерактивного взаимодействия с пользователями; мультипроцессорных систем; суперкомпьютеров; систем реального времени (IEEE 1003.10; -11; -13; -14; -18). Параллельно с подготовкой новых стандартов группы POSIX из этого списка, разрабатываются фрагменты и проекты международных стандартов, углубляющих возможности создания мобильных приложений. В стандарт ISO 9945-2 внесено Изменение 1 — Расширение для мобильности пользователя. Проектами в этой области являются стандарты: — ISO 14252. -— Руководство по функциональной среде открытых систем POSIX;

Рис 5. Классификация комплекса стандартов интерфейсов открытых систем POSIX

Идеология и модель создания мобильных программных средств изложена в документе IEEE 1003.0 — POSIX Guide — руководство по POSIX окружению открытых систем (OSE), которое детализирует для пользователей модель комплекса стандартов POSIX, а также взаимодействующих с ними стандартов де-юре и де-факто и спецификаций, необходимых для создания переносимых приложений. Модель отражает принципы построения интерфейсов прикладных программ с платформой — операционной системой, через которую осуществляется взаимодействие с компонентами внешнего окружения. Прикладные программы непосредственно не взаимодействуют с внешним окружением, а связаны с ним только через операционную систему. Таким образом, определяющими являются два интерфейса между тремя базовыми компонентами: между прикладными программами и платформой — операционной системой (API) и между платформой и внешним окружением (EEI). Определены общие функции — услуги платформы для этих взаимодействий. Внешнее окружение включает компоненты человеко-машинного взаимодействия с пользователями, компоненты информационного взаимодействия с внешними устройствами ЭВМ и с компонентами, обеспечивающими коммуникацию. Эти интерфейсы и услуги более детально должны быть формализованы соответствующими частными стандартами POSIX. Документ включает также общие принципы и руководство по формированию и описанию сложных согласованных профилей и по обеспечению непротиворечивости их интерфейсов с внешним окружением. Понятие профиль в соответствии с ISO 10000 и IEEE 1003.0, определяет документ, который предписывает состав, комплектацию, взаимосвязь и применение нескольких стандартов де-юре и де-факто с указанием параметров и директив, необходимых для построения сложных информационных систем или при реализации специальных функций информационных технологий. Детализация интерфейсов начинается в стандарте IEEE 1003.1 — Интерфейсы систем прикладных программ (язык Си) System Application program interface (API)(C language), в котором уточняется. концепция переносимости и принципы ее обеспечения путем унификации интерфейсов прикладных программ с операционными системами. Доработанная версия концептуального стандарта утверждена Международной

организацией по стандартизации (ISO 9945-1) и аннотирована ниже. Основные команды управления и сервисные программы, обеспечивающие переносимость, изложены в стандарте IEEE 1003.2 (Shell and utilities), который послужил базой одноименного стандарта ISO 9945-2. Таким образом, эти два стандарта являются основными в нормативной базе, поддерживающей перенос программ в операционной среде [7, 8, 9]. Развитие и конкретизация методов и средств, обеспечивающих мобильность прикладных программ, излагается в совокупности из 18, поддерживающих стандартов группы POSIX IEEE 1003.3 20, содержание которых изложено ниже. Разработка стандартов организована по фазам: IEEE – SC22 – JTC1 – ISO [10, 11], каждая из которых продолжительность полгода – год. Фазу разработки и утверждения этими организациями каждого из них в данный момент трудно установить и реально действуют как международные стандарты только два отмеченных выше. Остальные стандарты аннотированы далее в утвердительной форме как завершенные разработки, однако некоторые из них не вышли из стадии первоначальных проектов IEEE. В 1991 году рабочая группа IEEE POSIX совместно с ISO/JTC1/SC22/WG15 подготовила план-график работ по этим стандартам до 1998 года. По всем стандартам возможны и пока проводятся дополнения и изменения. В стандартах POSIX (IEEE 1003.5; -9; -16; -19; 20) конкретизируются интерфейсы прикладных программ, разрабатываемых на стандартизированных языках программирования: Си (ISO 9899), Ада (ISO 8652), Фортран (ISO 1359, 7846). В базовых стандартах упоминаются некоторые особенности интерфейсов приложений на языках программирования Паскаль (ISO 7185), Кобол (ISO 1989). Рекомендуется применение языков в виде современных модернизированных и дополнительных версий и использование для трансляции программ компиляторов, аттестованных авторитетными международными организациями. В части взаимодействия мобильных прикладных программ и операционных систем с внешней средой стандарты POSIX, ориентируются на международные стандарты взаимосвязи открытых систем – ВОС (OSI), в которые входят группы стандартов [12, 13]: − − поддерживающие непосредственное взаимодействие прикладных программ с пользователями и регламентирующие интерфейсы с виртуальными терминалами и графические системы; − − обеспечивающие административное управление файловыми системами и различными, в том числе, распределенными базами данных; − − регламентирующие телекоммуникацию и обмен данными на верхних уровнях эталонной модели ВОС; обеспечивающие аттестацию и безопасность применения информационных технологий, − − программ и данных в соответствии со стандартами ВОС и криптографии. Пять стандартов POSIX посвящены профилям прикладного окружения, взаимодействующего с операционной средой. Они базируются на активном использовании международного стандарта по таксономии профилей (ISO 1000-1,2,3), стандартов взаимосвязи открытых систем коммуникации (OSI), а также множества других стандартов де-юре и де-факто. Основы профилей представлены в документе IEEE 1003.18, в котором изложены профили интерфейсов приложений в интерактивных, распределенных, многопользовательских прикладных платформах. Стандарты IEEE 1003.11; -13; и –14 формализуют профили взаимодействия соответственно для диалоговой обработки заданий, для информационных систем реального времени и для мультипроцессорных вычислительных систем. NIST разработал комплект аттестационных тестов и обеспечивает тестирование в аккредитованных на соответствие POSIX испытательных лабораториях, а также выдает сертификаты проверки. Каталог проверенных программных средств публикуется в специальном издании.

Стандарты, обеспечивающие интерфейсы пользователей с операционной средой Задачи взаимодействия пользователей с операционной средой. Мобильность информационных систем включает унификацию и сохранение технологии взаимодействия и всех деталей интерфейса пользователей с приложениями при изменении аппаратных и операционных платформ — мобильность пользователей. Тем самым пользователь не должен переучиваться при переносе определенных прикладных программ и данных на иные платформы и сохраняет опыт и технологию взаимодействия с ними. В результате сокращаются затраты на освоение новых платформ и предотвращаются многие ошибки при использовании приложений [14,15,8]. Парк терминалов для пользователей информационных систем непрерывно совершенствуется по своим функциональным характеристикам и аппаратным реализациям. Для сохранения применяемых операционных систем, прикладных программ и баз данных и обеспечения возможности их переноса на иные платформы необходимо выделение и унификация интерфейсных компонентов, организующих их взаимодействие с различными аппаратно-программными реализациями терминалов. Эти интерфейсные компоненты должны согласовывать терминальные методы доступа к функциональным приложениям разнородных средств распределенных информационных систем, отличающихся между собой и использующих различные принципы отображения информации. Для этого необходима унификация концепции, архитектуры, функций и методов визуализации пользовательского интерфейса. Задача обеспечения мобильности пользовательского интерфейса включает стандартизацию: — визуализации и непосредственного взаимодействия пользователей с различными типами терминалов;

— интерфейсов прикладных программных средств, обеспечивающих визуализацию, с операционной системой; — интерфейсов программных средств визуализации с приложениями; — интерфейсов прикладных программных средств и баз данных с операционной системой (API). Программные средства визуализации и взаимодействия с пользователями по отношению к операционной системе выступают как прикладные программы и их интерфейсы с ней должны соответствовать стандартам API POSIX и в частности стандарту IEEE 1003.4 для систем реального времени. Стандартизация визуализации и непосредственного взаимодействия пользователей с различными типами терминалов затруднена широким спектром функционального назначения и особенностей отображаемой информации и классов информационных систем. Однако при переносе на иные платформы программ и данных определенного назначения их визуализация должна сохраняться на уровне стандартов де-факто. Наибольшие успехи достигнуты в международной стандартизации архитектуры интерфейсов программных средств визуализации с операционными системами. Применение этих стандартов значительно облегчает переносимость пользовательского интерфейса и приложений на иные платформы. Основная совокупность стандартов поддерживает графические пользовательские интерфейсы (Graphical User Interfaces - GUI). По своему функциональному назначению GUI является альтернативой вводу данных через командную строку. Ключевой проблемой остается выработка единой методологии создания программ графических систем [15,16,17,18]. Графический пользовательский интерфейс делает компьютер более легким и удобным для использования. Для этого он должен быть "дружественным" по отношению к пользователю, предусматривать возможные нужды и функции определенного класса пользователей, предупреждать их от ошибок при работе и защищать от разрушения системы. Он позволяет заменить командное управление с учетом сложного синтаксиса операционной системы, на манипулирование окнами и элементами изображения (иконами) пользовательских интерфейсов. Интерфейс с пользователем должен быть логичным и согласованным, не создавать неожиданные или тупиковые ситуации при любых действиях пользователей в соответствии с инструкциями, иметь соответствующие учебники и руководства для помощи при работе и для предотвращения ошибок. При переносе GUI на иные платформы должна полностью сохраняться визуализация на экране дисплея и функциональные возможности взаимодействия пользователя с графической системой. Основой GUI являются наборы графических элементов и допустимых операций над ними, меню и области окон для прокрутки изображений. Прикладной программный интерфейс (API) реализует программно-языковые функции для взаимодействия разработчиков приложений с графическими интерфейсами. Для этого программист выбирает и компонует наборы элементов и функций (окон, меню, операций над изображениями, икон), необходимых для создания конкретных информационных систем. Для поддержки экономного и эффективного переноса программных средств, обеспечивающих отображение различных графических образов, применяются стандарты де-факто и де-юре. Стандарты де-факто созданы несколькими рабочими группами фирм и IEEE и имеют целью унифицировать непосредственное формирование изображения на экране дисплея, управление окнами и графическими образами. Проектирование интерфейсов пользователей состоит в разработке интегрированного набора средств, помогающих разработчику в создании и управлении различными интерфейсами пользователей. Основу пользовательского интерфейса составляют наборы графических элементов и действий над ними, представляемые как меню и системы окон для манипулирования с изображениями. При этом ставится задача отделить процесс создания интерфейса пользователей от разработки прикладных программ, которые не должны связываться с конечными пользователями напрямую. Основные особенности современного интерфейса с пользователями состоят в следующем [19,20,21]: — наличие механизмов управления окнами; — использование готовых графических символов (икон) для отображения управляемых объектов; — непосредственное манипулирование графическими объектами и окнами посредством "мыши"; — объектно- и проблемно-ориентированное проектирование диалоговых систем. Для реализации интерфейсов создаются и используются библиотеки технологических интерактивных программ, позволяющих использовать устройства ввода команд управления и графических элементов при наличии обратной связи, отображающей на дисплее результаты манипулирования ими. Для этого разрабатываются модели, методы и языки проектирования интерфейсов пользователей, которые должны соответствовать проблемной области информационной системы. Их можно отнести к компонентам языков четвертого поколения. Разработка систем построения и управления интерфейсами пользователей ведется многими фирмами послойно с частичным учетом стандартов открытых систем и постепенной выработкой ряда стандартов де-факто. Модели графического пользовательского интерфейса. Разработан ряд моделей графического пользовательского интерфейса, из которых ниже рассматриваются три. Первая —концептуальная модель может быть детализирована введением пяти уровней взаимодействия пользователей с информационными системами: физического; концептуального; лингвистического; визуального; функционального. Физический уровень определяет состав технических средств и общетехнические требования к ним,

например, расположение клавиш на клавиатуре, характеристики устройств автоматического ввода информации, характеристики мониторов. Физический уровень взаимодействия соответствует нижнему уровню интерфейса пользователя в концептуальной модели ИС. Концептуальный уровень определяет способ отображения состояния среды, с которой взаимодействует пользователь. Он базируется на некотором представлении объектов среды через объекты интерфейса, связываемые между собой в программной среде. Лингвистический уровень определяет все, что связано с обработкой текстовой информации: сообщения программной среды, ввод текстовых команд пользователя, редактирование текста и т.д. Возможности интерфейса в использовании различных языков, а также то, как он использует свои языковые возможности, — все это относится к лингвистическому уровню взаимодействия. Визуальный уровень конкретизирует отображение концептуальных объектов. Способ отображения концептуальных объектов, их взаиморасположение, возможности пользователя в управлении этим отображением, удобство восприятия и т.п. — все это относится к визуальным аспектам. Концептуальный, лингвистический и визуальный уровни относятся к двум уровням программных средств среды (уровню операционных систем и уровню программных средств общего назначения). Функциональный уровень рассматривает взаимодействие пользователя с системой при решении прикладных задач, то есть типы воздействия пользователя на систему через функции пользовательского интерфейса и способы представления результатов в ответ на эти воздействия. Функциональный уровень относится к верхнему уровню концептуальной модели, на котором представлены прикладные программы ИС. Вторая модель, реализующая графические пользовательские интерфейсы, представляет собой многоуровневую совокупность компонентов, в которой верхний уровень занимают прикладные программы, а нижние уровни — операционная система и процессор (рис.4.2). Модель начинается с компонентов связи с прикладными программами, содержащих множество точек, через которые пользователь контактирует с системой и элементами, такими как меню и иконы. Основные уровни модели не предназначены для выполнения функциональных или программных операций. Они используются только для выбора графических интерфейсов. В дополнении к прикладным программам, операционной системе и процессору, эта модель между ними имеет пять базовых уровней. Объектная модель располагается на высшем уровне GUI, но может быть не единственной. Объектная модель отражает реакции и взаимодействие приложений с внешней средой и между собой. Она определяет характер реализуемых прикладных функций, их использование, управление и построение объектов. Прикладные программные интерфейсы (API) выполняют программно-языковые функции для связи пользовательских приложений с GUI. Программист может специфицировать функции (окна, меню, процессы отображения, иконы), которые необходимы для соответствующих прикладных программ. API включает средства, используемые разработчиками программ при создании GUI для конкретных приложений. Ядро графического пользовательского интерфейса сосредоточивает экранные функции и элементы. В таких системах, как OpenLook и Motif— это полное средство обеспечения пользовательского интерфейса. В системе Microsoft Windows в ядре содержится только часть функций GUI.Оконная система выделяется в некоторых случаях для повышения гибкости развития всего GUI. Так, например, Х Windows первоначально создавалась только как оконная система, а не весь графический пользовательский интерфейс. Однако системы функционально быстро развиваются, и оконные системы сливаются с ядром GUI. Модели изображения формируются для различных пользовательских интерфейсов с помощью графических средств, в том числе Х Windows. Для унификации интерфейсов могут применяться международные стандарты GKS (ISO 7942), PHIGS (ISO 9592) и другие. Реализации представленной этой многоуровневой модели графических пользовательских интерфейсов весьма разнообразны и, в той или иной степени, ориентированы на аппаратные и операционные платформы. Однако общие тенденции состоят в стремлении обеспечить их,

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

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

процедур, которые он может выполнять. Эти функции обеспечиваются прикладными программами. Для реализации такого взаимодействия компоненты клиентской части среды, относящиеся к группе функций пользовательского интерфейса, обеспечивают средства работы с документами (текстами), механизмы управления окнами, готовые примитивы символов (алфавитно-цифровые и графические примитивы) для формирования нужных объектов, непосредственное манипулирование объектами на экране. Наконец, физический уровень взаимодействия пользователя с системой обеспечивают устройства ввода-вывода информации, входящие в состав автоматизированных рабочих мест. Таким образом, средства, поддерживающие функции интерфейсов пользователя, размещаются на трех уровнях ИС: уровне прикладных программ, уровне программных средств среды, уровне технических средств среды. Система международных стандартов графических пользовательских интерфейсов. Особенностью пользовательского интерфейса как архитектурного компонента среды ИС является необходимость высокой согласованности всех функциональных элементов интерфейса. В связи с этим организации по стандартизации и промышленные консорциумы разрабатывают спецификации пользовательского интерфейса в виде гармонизированных профилей на основе базовых стандартов. Однако, на настоящий момент не существует подобного рода спецификации, которая охватывала бы все аспекты пользовательского интерфейса. Традиционно такие профили описывают либо структуру графического оконного интерфейса в целом, либо архитектуру построения распределенных приложений. Для построения профилей интерфейсов пользователя должны использоваться базовые стандарты, относящиеся к следующим классам объектов стандартизации: — типовые формы документов и процедуры работы с ними; — элементы взаимодействия пользователя с алфавитно-цифровым интерфейсом; — элементы взаимодействия пользователя с графическим интерфейсом; — структура распределенных приложений в части средств, поддерживающих интерфейсы пользователя. Типовые формы документов и процедуры работы с ними, рассматриваемые как объекты стандартизации, относятся к функциональному уровню взаимодействия пользователей с информационными системами. Объектами стандартизации, соответствующими процедурам из этого перечня являются элементы интерфейса пользователя, определяющие возможность начала соответствующей операции, ее ход и результат. Должна быть предусмотрена идентификация ошибочных действий и стандартизирована форма сообщения об ошибках. В связи с жестким регламентом выполнения процедур, средства настройки интерфейса пользователя на большинстве АРМов этих систем должны быть весьма ограничены либо отсутствовать. Для информационно-аналитических и административно-вспомогательных систем в настоящее время типовые процедуры не определены. В этих документах должны быть описаны: — соответствие между элементами интерфейсов пользователя (экранными формами) и типовыми процедурами; — последовательность допустимых операций и переходы между экранными формами; — форма идентификации ошибочных действий и/или ситуаций; — формы входных и выходных документов. Большинство приложений, использующих алфавитно-цифровой интерфейс, предоставляют либо вариант интерфейса, разработанного специально в составе приложения, либо интерфейс, который может быть сконструирован при помощи средства разработки этого приложения. Существуют фирменные стандарты, определяющие построение алфавитно-цифровых интерфейсов. Деятельность в области графических систем возглавляется и координируется 24-м подкомитетом ISO/IEC JTC1/SC24 при активном участии NIST, IEEE и ряда крупных программистских фирм. При создании графических стандартов используется принцип виртуальных ресурсов и разделения графической системы на несколько уровней (см. выше). Уровни могут использовать информацию нижних уровней и взаимодействовать с другими подсистемами посредством стандартизированных программных интерфейсов, а также с помощью стандартизированных файлов или протоколов. Для этого выделены три направления стандартизации: — базисные графические системы; — интерфейсы виртуальных устройств; — форматы обмена графическими данными. Стандарты базисных систем направлены на унификацию визуализации графических объектов. Интерфейсы виртуальных устройств разделяют аппаратно-зависимую и аппаратно-независимую части графических систем. При этом важную роль сыграло развитие растровых дисплеев и принтеров. Первоначально растровые файлы содержали только статические изображения. Появились проекты стандартов на форматы динамических (анимационных) изображений. На международном уровне упорядочена система непосредственного графического взаимодействия пользователей с базовыми средствами манипулирования графическими образами, которые стандартизированы де-юре ISO: 1. 1. ISO 9040:1990. СОИ. ВОС. Услуги виртуального терминала. Базовый класс. 2. 2. ISO 9041:1990. СОИ. ВОС. Протокол виртуального терминала. Базовый класс. 3. 3. ISO 7942:1985. СОИ. МГ. Функциональное описание ядра графической системы (GKS). Приложение 1:1991.

4.

4. ISO 8651-1-4:1988. СОИ. МГ. Языковые связи ядра графической системы (GKS). Ч.1:Фортран. Ч.2:Паскаль. Ч.З: Ада.Ч.4: Си. 5. 5. ISO 8805:1988. СОИ. МГ. Функциональное описание трехмерного ядра графической системы (GKS-3D). 6. 6. ISO 8806-1-4:1991. СОИ. МГ. Языковые связи трехмерного ядра графической системы (GKS3D). 4.1: Фортран. 4.2: Паскаль. 4.3: Ада. 4.4: Си. 7. 7. ISO 8632-1-4:1992. СОИ. МГ. Метафайл для хранения и передачи информации, описывающей изображение (CGM). 4.1: Функциональные требования. Дополнение 1:1990. 4.2: Символьное кодирование. Дополнение 1:1990. 4.3: Двоичное кодирование. Дополнение 1:1990. 4.4: Кодирование открытого текста. Дополнение 1:1990. 8. 8. ISO 9281-1,2:1990. ИТ. Методы кодирования изображения. 4.1: Обозначение. 4.2: Процедуры для регистрации. 9. 9. ISO 9282-1:1988. ИТ. Кодированные представления изображений. 4.1: Принципы кодирования для представления изображения в 7- и 8-битной среде. 10. 10. ISO 9592-1-3:1989. СОИ. МГ. Иерархическая интерактивная графическая система программиста (PHIGS). 4.1: Функциональное описание. 4.2: Формат архивного файла. 4.3: Открыто-текстовое кодирование архивного файла. 11. 11. ISO 9593-1-4:1990. СОИ. МГ. Языковые связи иерархической интерактивной графической системы программиста (PHIGS). 4.1: Фортран. 4.2: Расширенный Паскаль. 4. 3: Ада. 4.4: Си. 12. 12. ISO 9636-1-6:1991. ИТ. МГ. Методы сопряжения для диалогов с графическими устройствами. Функциональные требования. 4.1: Обзор, профили и согласованность. 4.2: Контроль. 4.3: Вывод. 4.4: Сегменты. 4.5: Ввод и отображение. 4.6: Растр. 13. 13. ISO 9638-1-4:1991. ИТ. МГ. Методы интерфейса для диалогов с графическими устройствами. Языки библиотек CGI. 4.1: Фортран. 4.2: Паскаль. 4.3: Ада. 4.4: Си. 14. 14. ISO 9973:1988. ТО. СОИ. Процедуры для регистрации графических элементов. 15. 15. IEEE-X Window — стандарт де-факто. Многооконная графическая система. 16. 16. ISO 11072:1992. ИТ. МГ. Компьютерная графика справочная модель. 17. 17. ISO 13719-1,2,3:1995. Среда интеграции инструментальных средств (РСТЕ) на рабочих станциях — ориентированы на приложения разработчика программного обеспечения. Услуги, регламентируемые представленной группой стандартов виртуальных терминалов и графики (GUI), определяют способы взаимодействия прикладных интерактивных систем, ориентированных на терминальную связь, в терминах передачи и манипулирования абстрагированными графическими образами. В базовой эталонной модели ВОС виртуальные терминалы и графика организуются на прикладном уровне и используют сервис представительского уровня. Базовый класс GUI организует образы, состоящие из блочно-символьных графических элементов, организованных в одно-, двух- / или трехмерные структуры. Услуги базового класса виртуальных терминалов позволяют [15,17,13] — устанавливать соединение между двумя пользователями; — запрашивать и согласовывать подмножества услуг и сервисных параметров; — передавать и манипулировать структурированными данными, независимо от способа внутреннего представления их информации, используемого каждым пользователем GUI; — управлять целостностью взаимодействия с пользователем GUI; — завершать взаимодействие пользователей согласованно и односторонне. Стандарты GUI регламентируют процедуры управления диалогом на основе механизма права доступа и ряда правил упорядочения примитивов услуг. Для согласования параметров образуется ассоциация — соединение между прикладными объектами. Стандарты предусматривают операции двух типов: синхронные и асинхронные. Синхронные обеспечивают попеременный, взаимоисключающий обмен со стороны различных объектов, а асинхронные — назначают определенным объектам право доступа на все время их существования. Семантика диалогов пользователей определяется в стандартах в терминах манипуляции над абстрактными объектами и типов самих объектов, к которым имеют доступ оба пользователя. Они совместно используют концептуальную область взаимодействия. Для описания операций сервиса GUI используются абстрактные объекты: концептуальная область взаимодействия и интерпретатор команд. Концептуальная область взаимодействия содержит память данных: одного или нескольких дисплейных объектов; управления, сигнализации и статуса; управления доступом; описаний дисплейных объектов, дополнительных устройств, объектов управления и т.п. Для обеспечения мобильности прикладных программ и данных их взаимодействие с пользователями целесообразно организовывать по принципам и моделям, заложенным в международных стандартах графических систем. Однако развитие программных средств графических систем происходит очень динамично. В результате разработка стандартов де-юре в этой области не поспевает за реальной практикой совершенствования функциональных возможностей диалога пользователей и аппаратных графических устройств. Это приводит к появлению и массовому использованию в этой области стандартов де-факто [15,22,9]. Их формализация на международном уровне может быть не всегда целесообразна, так как ограничено время их существования вследствие интенсивного развития функций и изменения аппаратуры

диалоговых средств. Стандарт ISO 9040 абстрактным образом определяет внешние услуги базового класса виртуального терминала (ВТ) внутри прикладного уровня ВОС путем задания модели взаимодействия между пользователями этих услуг и связанных с ними событий, в зависимости от параметров, содержащихся в каждом примитиве и взаимосвязи последовательностей примитивов. Услуги обеспечиваются с использованием общего прикладного сервисного элемента, а также услуг уровня представления и могут использоваться пользователем. Услуги ВТ применяются для реализации интерактивных прикладных процессов, требующих обмена информацией с пользователем и ориентированных на терминал, т.е. для передачи и манипуляции графических образов, состоящих из дискретных графических элементов, организованных в одно-, двух- или трехмерную структуру, которые могут иметь атрибуты, задающие способ их отображения. Стандарт определяет синхронный и асинхронный режим работы, профили и функциональную среду ВТ. В приложении А определены два рекомендуемых профиля: для асинхронного и синхронного режима работы. В остальных приложениях содержатся некоторые профили ВТ, а также дополнительная информация о стандарте. Стандарт ISO 9041 конкретизирует процедуры передачи данных и управляющей информации, ориентированные на соединение, между протокольными автоматами, реализующими функции поставщика услуг базового класса виртуального терминала (ВТ), определенные в ISO 9040. Процедуры определены в терминах: взаимодействий между протокольными автоматами, осуществляемых элементами ВТ, и взаимодействий протокольного автомата с поставщиком услуг уровня представления путем обмена сервисными примитивами. Определены две категории систем ВТ: простые и способные к форматированию. Обе разновидности систем обеспечивают позначное взаимодействие пользователей, однако различаются возможностями удаленной системы обрабатывать данные, вводимые пользователями. Установлена структура протокольного блока данных, определены три подмножества процедур и способы согласования необходимого подмножества. Заданы аттестационные требования. В обязательных приложениях приведены таблицы переходов состояний для протокольного автомата ВТ и дан список стандартизованных имен, идентифицирующих объекты данного стандарта. Информационного приложение содержит примеры кодирования протокольных блоков данных в ASNI. Стандарт ISO 7942 определяет набор функций для программирования машинной графики — Систему графического ядра (GKS). GKS [16] является основой графической системы для приложений, которые создают двумерное машинное изображение на устройствах вывода построчной или растровой графики. Она поддерживает вывод и интерактивный режим путем обеспечения основных функций вывода и сегментации изображения, позволяет сохранять и динамически модифицировать изображение. Основой GKS является концепция графической рабочей станции, являющейся абстракцией физического устройства и состоящей из ряда устройств ввода и единственного устройства вывода. Несколько станций могут использоваться одновременно. Функции управления GKS обеспечивают работу с несколькими логическими рабочими станциями. Для построения изображений в системе используется три системы координат: мировая; нормированная и система координат устройства. Прикладной программист использует мировую систему координат, GKS переводит данные в нормированную систему, а устройство вывода выдает их на отображение в системе координат устройства. Поддержан вывод с изменением атрибутов шести примитивов: ломаная линия; набор маркеров; заполненная область; текст; массив ячеек и обобщенный графический примитив. Стандарт охватывает конструкции и библиотечные вызовы двумерного изображения, в принципе, любого вида. Прикладные программы позволяют адаптировать режимы GKS на рабочую станцию для расширения ее возможностей. Стандарт включает функции, для хранения и передачи внешнего графического файла. GKS определяет языково-независимое ядро графической системы. Для включения в язык программирования, GKS имеет встроенный языковозависимый уровень. N 1ST лицензирован комплект аттестационных тестов для GKS и организована сертификация соответствия ему графических систем. Разработано несколько десятков пакетов, реализующих стандарт на различных языках программирования и на различных аппаратных платформах. Стандарт ISO 8651-1-4 из четырех частей формализует внесение в языки программирования Фортран, Паскаль, Ада, Си ядра графической системы (GKS), которое встраивается на языковозависимом уровне, подчиняясь требованиям данного языка. Стандарт ISO 8805 определяет набор функций для программирования машинной графики трехмерного ядра графической системы (GKS-3D). GKS-3D является основной графической системой для приложений, создающих трехмерные изображения на устройствах. графического вывода. Обеспечивается работа режимов ввода и интерактивного, путем представления основных функций, графического вывода и сегментации изображения. Поддерживается хранение и динамическая модификация изображения. Основой GKS-3D является концепция рабочей станции, состоящей из ряда устройств ввода и единственного устройства вывода. Несколько станций могут использоваться одновременно. Центральным является понятие видового конвейера, который поддерживает только трехмерные конструкции и рассматривает двумерные операции как частный случай трехмерных. Допускается адаптация прикладных программ к станции для повышения ее возможностей. Определены прикладные программы с возможностью отображения графических примитивов при использовании трехмерных координат и обеспечиваются функции для генерации этих примитивов. Могут использоваться функции из стандарта ISO 7942. Функции

вывода генерируют примеры трехмерных примитивов, которые ограничиваются для размещения на плоскости. GKS-3D определяет языковонезависимое ядро графических систем. Для вхождения в язык программирования, GKS-3D встраивается на языковозависимом уровне. Стандарт из четырех частей ISO 8806-1-4 формализует внесение в языки программирования Фортран, Паскаль, Ада, Си трехмерного ядра графической системы (GKS-3D), которое встраивается на языковозависимом уровне, подчиняясь требованиям данного языка. Привязка графического стандарта к языку программирования определяет отображение абстрактных типов данных, используемых в описании стандарта, на реальные типы данных конкретного базового языка. Привязка определяет также представление абстрактных имен функций и списков параметров средствами конкретного языка программирования с учетом всех налагаемых ограничений. Задачи стандартов, регламентирующих взаимодействие пользователей с данными. Стремление эффективно использовать память и производительность ЭВМ при различном объеме, содержании и взаимосвязи данных привело к разработке различных методов их структурирования и организации. Соответственно с организацией данных изменялись методы, средства и интерфейсы манипулирования ими со стороны пользователей, обеспечения их целостности, сохранности и защиты. При этом значительную роль играла необходимость обеспечения возможности экономного по трудоемкости переноса больших объемов информации на различные аппаратные и операционные платформы. Основная задача стандартов взаимодействия пользователей с данными состоит в упорядочении и регламентировании ими: накопления, хранения, изменения и транспортировки для эффективного их использования. В результате для управления и использования относительно небольших объемов слабо структурированных данных развиты методы и стандарты файловых систем, а для манипулирования сложными, взаимосвязанными данными созданы и развиваются методы и стандарты управления базами данных. Между данными, характеризующими объекты, могут существовать связи, имеющие различный содержательный смысл и степень сложности. Для эффективной работы с разнообразными по структуре и содержанию данными необходимо учитывать эти особенности, что привело к созданию многих типов систем управления базами данных (СУБД). Основными из них являются сетевые, иерархические и реляционные, которые в свою очередь делятся на локальные и распределенные [23,24,25,26]. Существующие международные стандарты отражают проблемы по организации, разработке и переносу БД частично и фрагментарно, что приводит к необходимости создавать ряд дополнительных нормативных документов при создании и организации конкретных БД. Стандарты по описанию языков баз данных содержат компоненты программного, организационно-методического и информационного обеспечения, которые являются руководствами для разработчиков и пользователей различных БД. Внимание разработчиков БД направлено на достижение такой ясности и дружественности интерфейса пользователей ЭВМ, которые позволила бы создавать базы данных без специальных знаний из области СУБД. Одним из результатов является предпочтение многими разработчиками и пользователями реляционной модели данных перед сетевой или иерархической. Другой результат — создание объектноориентированного интерфейса конечного пользователя с использованием техники меню и окон для выполнения основных функций. Наряду с ориентацией на прикладного пользователя, большинство СУБД учитывает и потребности пользователя-программиста, предоставляя ему встроенный язык программирования. Используя этот язык, программист может реализовать нетривиальные приложения по обработке данных, ориентированные на конкретные потребности. При создании или выборе распределенных СУБД в общем случае требуется найти способ организации баз данных, который обеспечивал бы высокую надежность хранения данных, необходимую эффективность при доступе к данным из любого узла сети и необходимую целостность баз данных при их совместном обновлении из разных узлов. Подходы к решению этой задачи различны для территориальных и локальных СУБД. Эти различия объясняются в первую очередь разницей в пропускных способностях каналов связи к данным. Высокая скорость доступа к данным не может быть обеспечена в территориальных сетях с их трудно предсказуемыми задержками при передаче данных, если не предпринять специальные меры для обеспечения копий данных в нескольких (или всех) узлах размещения БД. В распределенных СУБД способов выполнения запросов становится значительно больше, чем в централизованных, поэтому поиск наиболее дешевого способа, выбор правильных критериев оценок систем становятся очень сложными задачами. Почти во всех случаях важнейшими показателями качества СУБД являются функциональные и временные характеристики процессов доступа к данным и представления результатов пользователям БД, а также формирования и изменения информационного наполнения БД администраторами. Качество интерфейса специалистов с БД, обеспечиваемого средствами СУБД, оценивается, в значительной степени, субъективно, однако имеется ряд характеристик, которые можно оценивать достаточно корректно. Различия требований к показателям качества привели к весьма широкому спектру локальных, специализированных и распределенных СУБД. Специализированные СУБД характеризуются относительно узкой сферой применения и более четким выделением доминирующей группы показателей качества. В универсальных СУБД спектр показателей качества шире, что позволяет соответственно расширять сферу применения конкретного типа СУБД. Однако и для них существуют области наиболее эффективного использования [27,28,24].

Международные стандарты, определяющие построение сетевых, реляционных и распределенных файловых систем и баз данных, исторически вошли в разные разделы системы мёждународных стандартов (системы обработки информации — СОИ, информационные технологии — ИТ, взаимосвязь открытых систем —ВОС), однако тематически весьма близки. Среди этих стандартов наиболее известны и активно используются базовые стандарты построения файловых систем (FTAM) и стандарты, регламентирующие описания реляционных баз данных (SQL). Учитывая их большое, принципиальное значение для систем обработки данных, более подробно ниже представлены концептуальные основы этих стандартов. Остальные стандарты имеют более узкое функциональное назначение и их содержание изложено относительно кратко. 1. 1. ISO 9007:1987. СОИ. Понятия и терминология для концептуальной модели базы данных. 2. 2. ISO 8211:1994. СОИ. ВОС. Спецификация описательного файла данных для обмена информацией. 3. 3. ISO 8571-1-5:1988. СОИ. ВОС. Передача файлов, доступ к файлам, управление системами файлов. Ч.1: Общее введение. Ч.2: Определение виртуального хранилища файлов. Ч.3: Определение услуг. Ч.4: Спецификация протокола. 4. 4. ISO 8907:1987. СОИ. Язык описания сетевой базы данных (NDL). 5. 5. ISO 9075:1989. СОИ. Язык описания реляционной базы данных (SQL). Дополнение 1:1992. 6. 6. ISO 9579:1991. ИТ. ВОС. Доступ к удаленной базе данных (RDA).4.1: Общая модель, услуги и протокол. 4.2: Спецификация SQL. Для эффективного использования международных стандартов в отечественной практике необходимо учитывать возможные расхождения в понятиях, терминологии и принципах испытаний информационных систем. При разработке и применении файловых систем, СУБД и БД может потребоваться дополнительная работа по логической, текстуальной и технической увязке, а также по согласованию требований, выдвигаемых международными и отечественными стандартами, а также ведомственными нормативно — техническими документами. Содержание стандартов файловых систем и баз данных. Стандарт ISO 9007 — вводит понятие информационной системы (ИС) и предлагает трехуровневую архитектуру ИС, которая содержит: концептуальный уровень; внешний уровень; внутренний уровень. В этой модели концептуальный уровень соответствует прикладному уровню базовой модели ВОС, а внешний уровень — уровню представления ВОС. Именно на этих уровнях реализуется общение пользователей с БД. В соответствии с этими представлениями концептуальный уровень ИС состоит из концептуальной схемы, информационной базы и информационного процессора. Под концептуальной схемой понимается описание возможных состояний связей, действующих между объектами в предметной области. Информационная база — это совокупность описаний объектов в предметной области и текущих состояний их связей. Информационный процессор — это механизм, нарушающий статичность концептуальной схемы и информационной базы в ответ на внешние команды. Внешний уровень информационной системы включает внешнюю схему, внешнюю базу данных и внешний процессор. Внешняя схема представляет описание связей с точки зрения пользователей и прикладных программ. Во внешней базе данных информация представляется в соответствии с описаниями внешней схемы. Внешний процессор отражает связь пользователя и прикладных программ с данными. На внутреннем уровне описываются внутренние и физически представления информации. Информационная база отражает конкретное физическое представление описания предметной области. Внутренний процессор реализует физическое преобразование ин формации в соответствии с концептуальной схемой. Понятие СУБД в концепции абстрагируется от понятия базы данных и рассматривается как средство для реализации внешнего и внутреннего уровне информационных систем. Подчеркивается, что концептуальная схема, в общем случае, может быть построена вне зависимости от конкретной СУБД. Для построения совместимых, переносимых, распределенных систем работы с файлами предназначена группа стандартов FTAM (File Transfer, Access and Management). Они обеспечивают унификации методов, взаимодействия с файлами на основе модели виртуальной файлохранилища. Поддерживаются возможности: организации не делимых транзакций взаимодействия с данными, усложнения структур используемых данных и применения механизма восстановление при сбоях и искажениях данных. Модель регламентирует согласование различий в файлохранилищах реальных систем, не изменяя каждого из них. Для идентификации файлов в модели используется со ставной адрес, содержащий имя файлохранилища и имя в файлохранилище. Файл кроме имени характеризуется атрибутами общих свойств файла, атрибутами, определяющими его логическую структуру, и дополнительными данными о содержании файла. Для доступа к элементам данных используются атрибуты, определяющие логическую структуру файла. Определен набор операций, позволяющие изменять состояние файлохранилища и манипулировать элементами данных с учетом структуры доступа. Для этого используются примитивы сервиса FTAM над целыми файлами и над их элементами Важную роль при работе с файлами имеют регламентированные процедуры восстановления. В стандарте ISO 8211 определены форматы данных, которые регламентируют и упрощают перемещение файлов и их частей между вычислительными системами. Общая структура файлов охватывает

широкое разнообразие типов и архитектур данных пользователей. Определены иерархия, средства и способы описания содержимого данных, которые предлагается использовать для транспортировки данных совместно с их описаниями, а также правила использования набора кодированных знаков. Передаваться могут как структуры данных общего пользования (векторы, массивы, иерархии), так и структуры данных пользователя (последовательная, иерархическая, реляционная). Определены форматы обмена, обобщенная структура файлов, описания записей данных и три уровня обмена в зависимости от сложности структуры данных. Сформулированы аттестационные требования для проверки соответствия стандарту файлов и их описаний, а также изложена взаимосвязь стандарта с другими из группы стандартов по открытым системам. Приводятся примеры описания данных. Стандарт ISO 8571 — состоит из пяти частей. Определены общие концепции передачи, доступа и управления файлами (FTAM), особенности услуг по передаче файлов и выполняемые при этом функции, поставщики услуг, принципы организации и модель виртуальной памяти файлов, структуры файлов и налагаемые на них ограничения. Приведено общее описание каждой из девяти фаз, на которые разбивается процесс использования услуг файла: инициализация режима FTAM, управление памятью файлов, выбор файла, управление файлом, открытие файла, доступ к данным, закрытие файла, закрытие выбора файла и окончание режима FTAM Определены общие протокольные процедуры и механизмы, группирование протокольных блоков данных, диагностика и восстановление после ошибок. Часть 2 содержит абстрактную модель хранилища файлов (взаимосвязь файлов, атрибутов и ассоциаций, абстрактная, структура файлов, действия над файлами), набор действий, доступные для манипулирования элементами модели, включая действия над полными файлами (создание, выбор, открытие, закрытие, удаление файла, чтение и изменение атрибута) и действия при доступе к содержанию файла (чтение, вставка, замена, расширение, стирание). Приведены определения и описание атрибутов (файловых атрибутов, активных атрибутов, групп атрибутов). В двух обязательных приложениях приведены наборы ограничений на общую структуру файлов и определения документов общего типа, необходимых для обеспечения взаимодействия различных реализации FTAM. В приложениях приведены примеры элементов различных структур файлов, примеры способов модификации структурированных файлов. В части 3 сосредоточены описания наборов услуг для различных режимов FTAM: — установление режима, упорядоченное завершение режима и завершение режима по прерыванию; — для режима выбора FTAM: выбор файла, завершение выбора файла, создание файла и вычеркивание файла; — для процедур управления файла: чтение атрибутов и изменение атрибутов; — для режима открытия файла: открытие файла и закрытие файла; — для процедуры управления группированием: начало группирования и конец группирования. Кроме того, определены наборы дополнительных услуг для процедур доступа к содержимому файла, передачи массивов данных и восстановления после ошибок. Для каждой услуги определен набор сервисных примитивов и параметров, а также последовательности действий, связанных с этими примитивами. В приложении определены значения параметров диагностики, отношения атрибутов к примитивам, передача файлов и управление разделением, диаграммы переходов состояний Представлен базовый протокол передачи данных и базовый протокол передачи массивов данных, которые обеспечивают внутреннее обслуживание файлов; протокол восстановления после ошибок, который обеспечивает внешнее обслуживание файлов; абстрактный синтаксис для передачи протокольной информации FTAM и аттестационные требования к реализациям. Протоколы определены в понятиях действий, выполняемых при получении сервисных примитивов от поставщика услуг и при выдаче сервисных примитивов пользователю услуг. В приложениях приведены таблицы переходов состояний протокола или конструкции для определения протокольных блоков FTAM. В стандарте ISO 8907 определены синтаксис и семантика трех языков сетевой базы данных: — язык описания схемы для определения структуры и условий целостности сетевой базы данных (СБД), — язык описания подсхемы для определения пользовательской структуры базы данных; — язык манипулирования данными для определения процедур базы данных и исполнительных операторов в конкретной прикладной программе, работающей с СБД. Заданы логические структуры данных и базовые операции для СБД. Стандарт обеспечивает переносимость определений баз данных и прикладных программ между аттестованными реализациями языка. Установлены два уровня языка, причем уровень 1 является подмножеством полного языка (уровень 2). Определены коды возврата. В трех информационных приложениях приведены примеры применения языка. В стандарте ISO 9075 представлен язык SQL. Язык SQL служит для удобного и понятного пользователям формулирования обращений к реляционным БД и манипулирования данными. Язык обеспечивает общее управление данными в приложениях, где требуется гибкость структур данных и маршрутов доступа, специфическое манипулирование данными и изменение степени ограничения доступа [23,29]. Внимание акцентировано на обеспечении свойства целостности данных, т.е. глубокой взаимосвязи данных, в которой наибольшее значение имеет функциональная зависимость, что отличает их от набора независимых, совместно используемых файлов. Особенно полно механизм контроля целостности

формализован на основе произвольных логических утверждений. Версия стандарта на язык SQL 1989 года во многих частях имеет весьма общий характер и допускает широкое толкование, что привело к появлению его диалектов. В нем отсутствует ряд важных разделов, например, манипулирование схемой БД и динамический SQL. В 1992 году завершена работа над второй, значительно более полной версией стандарта ISO 9075:1992 (SQL-2). Она охватывает практически все аспекты, необходимые для реализации взаимодействия с БД: манипулирование схемой БД; управление транзакциями, с использованием точек сохранения, и сессиями — последовательностями транзакций; а также динамический SQL и общие механизмы контроля целостности л основе произвольных логических утверждений. Версия SQL-92 включает также все аспекты распределенной обработки данных и объектноориентированные возможности с языком Си++. Предполагается, что следующая версия стандарта будет содержать механизм триггеров и возможности применения абстрактных типов данных [23,17]. NIST обеспечивает формализованные услуги по тестированию реализации языка SQL на базе комплекта тестов, который является общедоступным. Он содержит проверки обязательных и факультативных функций. При положительных результатах тестирования обязательных функций NIST выдает аттестационные сертификаты. Ведутся работы по расширению номенклатуры аттестационных тестов в соответствии с развитием языка SQL и сокращением доли факультативных тестов. Язык SQL, в основном, является языком запросов и манипулирования данными, однако его функции и возможности значительно шире [29,25,18]. Он обеспечивает построение эффективных диалоговых систем обработки транзакций со стандартизированными наборами параметризируемых запросов. В языке имеются средства: — определения и манипулирования схемой БД; — определения ограничений и контроля целостности; — определения и уничтожения структур физического уровня для эффективной реализации транзакций; — авторизации и защиты доступа к данным; — использования точек сохранения транзакций и откатов при сбоях; — средства динамической компиляции запросов, на базе которых возможна диалоговая их обработка. Язык имеет строгую математическую основу на базе предикатов первого порядка. Группы по стандартизации и разработчики СУБД обеспечивают совместимость версий языка снизу вверх в последовательных расширениях языка. Стандартизированы синтаксис и семантика операторов выборки и манипулирования данными. Имеется возможность указания в запросе потребности группирования отношения — результата по указанным полям с поддержкой условий выборки на всю группу целиком. При этом необязательно удаление кортежей дубликатов в окончательном или промежуточных отношениях — результатах. Формализованы средства ограничения целостности БД, включающие возможность определения первичных и внешних ключей отношений и проверочных ограничений целостности. В случае нарушения ограничений целостности предусмотрен откат транзакций в точку, непосредственно предшествующую операции манипулирования данными, или полный откат транзакции к ее началу. Динамический SQL обеспечивает включение операторов, позволяющих в процессе выполнения транзакций откомпилировать и выполнить любой оператор этого языка. Имеются специальные операторы, поддерживающие встраивание операторов SQL в традиционные языки программирования и, прежде всего, в тексты программ на языке Си. При этом осуществляется последующая компиляция операторов SQL в текст программы на чистом языке Си. Предусмотрена параметризация операторов SQL значениями переменных, входящих в прикладную программу. В языке обеспечена защита доступа к данным средствами самого языка. С каждой транзакцией неявно связывается идентификатор пользователя, от имени которого она выполняется. После создания нового отношения все 'привилегии, связанные с этим отношением, принадлежат только пользователю — создателю отношения. Проверка полномочности доступа к данным происходит на основе информации о полномочиях, существующих во время компиляции соответствующего оператора SQL. Стандарт определяет синтаксис и семантику двух компонентов языка реляционной базы данных: языка описания схемы для задания структуры и условий целостности реляционной базы данных (РБД) и языка манипулирования данными для определения базы данных и исполнительных операторов в конкретной прикладной программе, работающей с РБД. Заданы логические структуры данных и базовые операции для РБД. Язык обеспечивает функциональные возможности для разработки, доступа, сохранения, управления и защиты базы данных. Стандарт обеспечивает переносимость определений баз данных и прикладных программ между аттестованными реализациями языка. Установлены два уровня языка, причем уровень 1 является подмножеством полного языка (уровень 2). В информационных приложениях определен встроенный синтаксис для включения операторов языка манипулирования данными в стандартные прикладные программы, в т.ч. Си, Кобол, Паскаль и ПЛ-1. Такой встроенный синтаксис является сокращенной записью для стандартизированной прикладной программы, в которой встроенные операторы SQL заменены в явной форме вызовами процедур БД, которые содержат операторы SQL. Стандарт применяется для реализации в среде, которая может включать языки прикладных программ, языки запросов конечных пользователей, системы генерирования сообщений, системы библиотек программ и системы распределенной связи, а также различные средства для создания баз данных и организации обработки данных.

Таким образом, описания SQL являются фактическими руководствами, которые регламентируют действия пользователей различных уровней: – – пользователей, создающих базу данных и программистов; – – конечных пользователей информации из базы данных. Кроме интерфейса с пользователями SQL может играть роль интерфейса между различными СУБД. В этих случаях в СУБД должны встраиваться средства формирования запросов к другим СУБД на языке SQL. Язык SQL реализован в большинстве популярных коммерческих СУБД, однако, версии реализованного языка и степень соответствия определенному стандарту несколько различаются. Отсутствие полного корректного описания языка затрудняет анализ диалектов, применяемых в различных СУБД, и оценку соответствия стандарту. Поэтому перенос информации баз данных на новые аппаратные платформы целесообразно и наиболее просто проводить совместно с той же СУБД. Стандарт ISO 9579 регламентирует доступ к удаленной базе данных (RDA). Он предназначен для унификации установления дистанционного соединения между клиентом, действующим по запросу прикладной программы или администратора данных, и сервером, который управляет обменом данными с базой данных. Это обеспечивает взаимодействие систем управления базами данных в гетерогенной информационной среде. Услуги RDA охватывают: — административное управление диалогом между клиентом и сервером; — управление ассоциацией; — управление ресурсами; — языки доступа к данным между отдельным клиентом и отдельным сервером. Стандарт состоит из двух частей. Часть 1 определяет обобщенную модель доступа к удаленной базе данных и частную модель для доступа к базам данных с использованием языка баз данных SQL, а также операции над моделью базы данных в виде абстрактного взаимодействия между источником запроса и средством обслуживания базы данных. Приведены основные концепции .RDA. В стандарте определяются услуги RDA, предоставляющие пользователю возможности управления транзакцией и манипулирования данными. Описан протокол, обеспечивающий эти услуги. Операторы SQL передаются в виде символьной строки с отдельным списком входных параметров с описанием особых случаев. Услуги управления транзакциями включены как в однофазовые, так и в двухфазовые протоколы. Показано отображение услуг RDA на соответствующие элементы процедур. Часть 2 определяет специализацию удаленного доступа к базам данных с использованием языка баз данных SQL, операции над моделью данных в виде абстрактного взаимодействия между источником запроса и средством обслуживания базы данных. Определяются услуги RDA, предоставляющие пользователю возможности управления ассоциацией, управления ресурсом, управления транзакцией и манипулирования данными. Описан протокол, обеспечивающий эти услуги. Показано отображение услуг RDA на соответствующие элементы процедур. Приведены аттестационные требования к реализациям протокола. Разрабатывается расширение стандарта по управлению распределенной базой данных для различных реализации SQL. Стандарты, регламентирующие административное управление в информационных системах Задачи стандартов административного управления в открытых системах. Сложность переноса приложений на иные платформы в значительной степени зависит от концептуальной и протокольной унификации логики и интерфейсов управления ими со стороны внешнего окружения. Поэтому в группе POSIX выделен специальный стандарт IEEE 1003.7, посвященный целиком административному управлению мобильными программными средствами. Он ориентирован на совокупность стандартов открытых систем коммуникации — OSI и некоторые дополнения, которые совместно служат для унифицированного запуска заданий, контроля процессов их выполнения и получения результатов исполнения заданий. Основы стандартизации управления в открытых системах коммуникации изложены в части 4 стандарта Базовая эталонная модель взаимосвязи открытых систем (ВОС), в Обзоре системного управления и в Структуре прикладного уровня, а также в приведенной ниже группе стандартов [30,17]: 1. 1. ISO 7498-4:1989. СОИ. ВОС. Базовая эталонная модель. Ч. 4. Основы управления. 2. 2. ISO 8649:1988. СОИ. ВОС. Определение услуг для сервисного элемента управления ассоциацией. Дополнение 1.1990. Подтверждение подлинности равноправных логических объектов. Изменение 2. 1991. Услуги сервисного элемента управления ассоциацией в режиме без установления соединения. 3. 3. ISO 8650:1988. СОИ. ВОС. Спецификация протокола для сервисного элемента управления ассоциацией. Дополнение 1.1990. Подтверждение подлинности равноправных логических объектов. 4. 4. ISO 8831:1992. СОИ. ВОС. Передача и обработка заданий. Концепции и услуги. 5. 5. ISO 8832:1992. СОИ. ВОС. Передача и обработка заданий. Спецификация базового класса протокола. Изменение 1. Расширение для спецификации полного протокола. 6. 6. ISO 9804:1990. ИТ. ВОС. Определение услуг для сервисного элемента "Исполнение, совмещение и восстановление". 7. 7. ISO 9805:1990. ИТ. ВОС. Спецификация протокола для сервисного элемента "Исполнение, совмещение и восстановление"

8.

8. ISO 9834-1-6. ИТ. ВОС. Процедуры регистрационной службы ВОС. Ч.1. Общие процедуры. Ч.2. Процедуры регистрации типов документов ВОС. Ч.3. Регистрация значений компонентов идентификатора объекта для совместного использования ИСО — МККТТ. Ч.4. Регистр профилей виртуальных терминалов. Ч.5. Регистр определений управляющих объектов виртуальных терминалов. Ч.6. Регистрация файлов и названий логических объектов. 9. 9. ISO 10040:1990. ИТ. ВОС. Обзор системного управления. 10. 10. ISO 10026-1-6. ИТ. ВОС. Распределенная обработка заданий. Ч.1. Модель. Изменение 1. Оптимизация исполнения. Ч.2: Определение услуг. Ч.3: Спецификация протокола. Ч.4. Форма заявки о соответствии реализации протоколу. Ч.5. Форма прикладного контекста и руководство по использованию заданий в ВОС. Ч.6. Передача неструктурированных данных. 11. 11. ISO 10164-1-16. ИТ. ВОС. Административное управление системой. 12. 12. ISO 10165-1-5. ИТ. ВОС. Структура информации административного управления.

Стандарты, регламентирующие тестирование компонентов программных средств Задачи стандартов тестирования программ. Вследствие своей относительной простоты их тестирования наиболее доступно стандартизации, однако, в основном, на национальном (ANSI) или отраслевом уровне (DOD). Некоторые из этих стандартов частично касаются принципов тестирования сложных комплексов программ в части общих требований и методов. Также как системный анализ и проектирование сложных информационных систем, их тестирование, отладка и испытания являются функционально очень разнообразными и принципиально творческими процессами. Высокая сложность и различие функций современных крупных комплексов программ не позволяет глубоко унифицировать методы, технологию и средства автоматизации их тестирования, испытаний и сертификации. Вследствие чего отсутствуют международные стандарты, регламентирующие эти процессы. Реализация мобильных ПС и БД без упорядоченного тестирования, а также без учета требований и рекомендаций международных стандартов приводит к большим потерям технических и финансовых ресурсов из-за несовместимости технических и программных средств, необходимости доработки (адаптации) импортируемой продукции, увеличения длительности проектирования и производства вновь создаваемых и перспективных средств информатизации. Таким образом, при создании профилей и конкретных проблемно-ориентированных методик, регламентирующих нормативное обеспечение жизненного цикла и тестирования ИС, существуют проблемы стандартизации наиболее творческих начальных этапов ЖЦ и этапов интегрирования, тестирования и испытания ПС и БД. Накопленный опыт и многочисленные публикации [19,32,33,34] создания сложных проблемно-ориентированных ИС, в особенности для автоматизации систем вооружения, привели к разработке ряда конкретных фирменных методик и систем автоматизации тестирования и испытаний таких ИС. Их унификация возможна только на общеметодическом уровне, основы которой выделены в п.3.3. Эти обстоятельства определяют также практическое отсутствие коммерческих пакетов прикладных программ для тестирования и испытаний сложных программных комплексов реального времени. Системы тестирования и отладки таких комплексов программ разрабатываются для конкретных проблемноориентированных целей, обычно являются уникальными и не предназначены для тиражирования и широкой продажи. Для гарантированной, реализации протоколов ВОС в конкретных проектах, ряд западных фирм создал распределенную глобальную вычислительную сеть тестирования протоколов ВОС — OSINET [35,36,9]. Эта сеть позволяет разработчикам, заказчикам и третьим сторонам использовать апробированные сетевые средства для аттестационного тестирования своих систем на соответствие стандартам и спецификациям ВОС. В Европе Комитет управления информационной технологией (ITSTC) разработал предложения по организации тестирования и сертификации ИТ. Входящие в него национальные координирующие органы, объединены в Европейский комитет по тестированию и сертификации в области информационной технологии (ECITC), в котором действуют два органа: − − Консорциум по тестированию открытых систем (OSTC), который обеспечивает сертификационные испытания систем обработки сообщений, доступа к файлам, передачи и управления файлами, протоколов транспортного и сеансового уровней, глобальных вычислительных сетей; − − Европейская служба по тестированию и сертификации протоколов для учреждений и промышленных предприятий (ЕТСОМ), которая предназначена для проверки реализации спецификаций производственных сообщений, справочных служб, а также протоколов нижних уровней ВОС для локальных вычислительных сетей. Стандарты, регламентирующие тестирование и аттестацию в информационных системах. В последние годы значительное внимание уделяется стандартизации жизненного цикла ПС, в результате чего разработаны и утверждены достаточно совершенные международные стандарты ISO 12207:1995 и ISO 09000-3:1991, а также отраслевой стандарт министерства обороны США DOD STD-2167 А. Относительно слабая непосредственная поддержка в этих стандартах тестирования и отладки ПС частично объясняется интенсивным развитием и совершенствованием современных технологий их разработки, внедрением языков четвертого поколения и CASE-технологий. В результате этого появился ряд стандартов де-факто, которые за время их активного жизненного цикла не успевают доработать и формализовать в стандарты де-юре. Кроме

того, широкое разнообразие типов и функций, создаваемых ПС и БД препятствует унификации процессов и технологий их тестирования. Приведенные в п.3.3 принципы тестирования и аттестации ПС обобщены и конкретизированы в группе стандартов, посвященных тестированию и испытаниям прикладных программ и их интерфейсов в информационных системах: 1. 1. ISO 12207:1995. Процессы жизненного цикла программных средств. 2. 2. ISO 9000-3:1991. Общее руководство качеством и стандарты по обеспечению качества. Ч.3: Руководящие указания по применению ISO 9001 при разработке, поставке и обслуживании программного обеспечения. 3. 3. DOD-STD-2167 А: 1988. Разработка программных средств для систем военного назначения. 4. 4. ISO 09646-1-6:1991. ИТ. ВОС. Методология и основы аттестационного тестирования ВОС. 5. 5. IEEE 1003.3. Методы тестирования для определения соответствия стандартам POSIX. 6. 6. ISO 13210:1994. ИТ. Методы тестирования для измерения соответствия стандартам POSIX. 7. 7. ANSI/IEEE 829-1983 (ред. 1991). Документация при тестировании программ. 8. 9.

8. ANSI/IEEE 1008-1986 (ред. 1993). Тестирование программных модулей и компонент ПС. 9. ANSI/IEEE 1012-1986 (ред. 1992). Планирование проверки (оценки) (verification) и подтверждения достоверности (validation) программных средств. 10. 10. ISO 12119: 1994. ИТ. Требования к качеству и тестирование. Наиболее полно ЖЦ, технология разработки, тестирования и обеспечения качества сложных программных средств отражены в стандарте ISO 12207:1995 — Процессы жизненного цикла программных средств (см.п.1.5). Рекомендуется при формировании характеристик качества ПС руководствоваться стандартом ISO 9126 и предложенной в нем номенклатурой показателей. Обеспечение гарантий качества представлено работами, которые включают использование планирования, методологии, процедур и стандартов обеспечения качества в соответствии с контрактом с учетом доступных ресурсов. Рекомендуется обеспечивать качество конечного продукта в соответствии с документацией, путем планирования и выполнения специальных работ в процессе всего жизненного цикла ПС. Верификация ПС отражена работами, которые включают организацию, планирование и техническое обеспечение верификации. Представлена структура контракта на верификацию, содержание процесса, состав требований, проектирование процесса верификации, обобщение и документирование результатов. Валидация — удостоверение правильности (аттестация) представлена работами, которые должны гарантировать полное соответствие спецификациям, требованиям и документации на ПС и возможность его безопасного и надежного применения пользователем. Рекомендует ее выполнять путем тестирования во всех возможных ситуациях исходных данных и проводить независимыми специалистами. По существу, этот процесс аналогичен сертификации, которая в стандарте не упоминается. В стандарте DOD-STD-2167 А процесс испытаний регламентируется рядом документов, а также определено содержание отчетов, завершающих частные процессы проверок. Подчеркивается необходимость привлечения независимых специалистов для проведения официальных квалификационных испытаний на каждой фазе ЖЦ ПС. Этому должно предшествовать тестирование программ разработчиками, подтверждающее их готовность к официальным (сертификационным) проверкам, а также подготавливаться средства автоматизации тестирования, методики испытаний и анализа результатов. В части тестирования стандарт систематизирует описания тестов, план и набор тестов проверки интегрированной системы, описания процедур тестирования компонентов и ПС в целом, методику выполнения корректировок ПС. В стандарте DOD-STD-2167 А около 30% требований, документов и соответствующих им процессов непосредственно связаны с тестированием и испытаниями программ. Отдельный раздел в стандарте регламентирует процедуры испытаний интегрированной системы, включающей кроме программ весь комплекс реальных технических средств. Тестирование должно завершаться отчетом и актом о результатах комплексных приемо-сдаточных испытаний заказчиком. В стандарте не используется термин "сертификация", однако регламентированные официальные квалификационные испытания ПС в системе, независимыми от разработчика специалистами, контролируемыми заказчиком, по существу соответствуют понятию сертификации в области разработки оборонных систем. Стандарты — ISO 9646 —-1-6 регламентируют проверку функциональных возможностей и поведения испытываемой реализации ИС относительно требований и рекомендаций ISO, а также заявлений и документации разработчиков о функциональных возможностях данной реализации. Цель аттестационного тестирования — снизить вероятность несовместимости различных компонентов, в которых реализованы протоколы ВОС. Часть 1 содержит вводный материал стандарта ISO 09646, поясняющий цели, основные требования и общую схему аттестационного тестирования. Выделены три методические стадии аттестационного тестирования: спецификация абстрактных тестовых комплектов для конкретных протоколов ВОС; реализация процесса тестирования на заданных тестовых комплектах; процесс оценки соответствия, выполняемый испытательной лабораторией, и составление отчета по результатам тестирования. Рекомендуются методы, последовательность применения и структура тестовых комплектов. Классифицированы и описаны методы локального, распределенного, скоординированного и удаленного

тестирования, а также особенности их применения к протоколам различных уровней ВОС. Значительное внимание уделено методике анализа результатов тестирования — обеспечению их достоверности, повторяемости, сравнимости и наглядности. Часть 2 обеспечивает общий подход к специфицированию аттестационных тестов на абстрактном уровне и независимому их выполнению. Определены аттестационные требования к стандартам ВОС и бланкамзаявкам протокольных реализации, подлежащих тестированию. Описаны процессы разработки и генерации абстрактных тестовых комплектов, соответствующих аттестационному тестированию, их структура и спецификация. Формализованы заявка о проверке соответствия реализации протоколу, процедуры управления тестированием и использование спецификаций абстрактных тестовых комплектов. В части 3 стандарта описаны рекомендации по формированию спецификаций комплектов абстрактных тестов. Часть 4 устанавливает процедуры и порядок выполнения тестов на основе стандартизированных в специальных документах абстрактных тестовых комплектов. Определены основные способы планирования выполнимых тестовых последовательностей, включения дополнительных тестов, повышения эффективности процедур тестирования. Сформулированы требования к созданию комплекта выполнимых тестов, обеспечивающие их соответствие эталонному стандартному комплекту абстрактных тестов, и способы образования их подмножеств. Изложены дополнительные руководящие материалы по реализации тестов и по процессу оформления основных документов тестирования. Часть 5 устанавливает требования к проведению аттестационного тестирования, необходимые для обеспечения сопоставимости результатов тестирования подобных изделий, выполненных в различных испытательных лабораториях. Рассмотрены задачи подготовки к тестированию, операции его проведения и составление отчетов по результатам тестирования. Подробно изложены роли и распределение ответственности между испытательной лабораторией и клиентами в процессе выбора и параметризации тестов, при проведении тестирования и согласовании его результатов, а также при разработке отчета о завершенном аттестационном тестировании системы и конкретного протокола. В приложениях приведены рекомендуемые формы отчетов испытательных лабораторий по результатам тестирования информационной системы и протоколов, а также форма дополнительной информации о реализации тестирования. В части 6 установлены требования к разработке спецификаций для аттестационного тестирования протоколов ВОС. Определены требования к тестированию статического и динамического соответствия каждого протокола и каждого информационного объекта, входящего в состав профиля. Представлена сводка спецификаций тестирования профилей и процесс разработки спецификаций тестов.

Стандарты, регламентирующие сопровождение и управление конфигурацией сложных программных средств Стандарты, поддерживающие управление версиями в жизненном цикле сложных программных средств. Эти стандарты являются фрагментами базовых стандартов, призванные обеспечить управляемое и контролируемое развитие структуры, состава компонентов и функций сложных высококачественных информационных систем в течение всего их жизненного цикла. Они позволяют упорядочить поток изменений в программах, тем самым резко повысить качество ПС, а также сократить затраты ресурсов и длительность реализации предложений по их улучшению. Для этого необходима точная и достоверная информация о состояниях системы и ее компонентов, всех предполагаемых и выполненных изменениях. Регламентируют сопровождение и конфигурационное управление стандарты: 1. 1. ISO 12207:1995 — Процессы жизненного цикла программного обеспечения. 2. 2. ISO 12207-2 — Процессы жизненного цикла программного обеспечения. Часть 2. Процессы конфигурационного управления (проект) 3. 3. ISO 9000-3:1991 — Общее руководство качеством и стандарты по обеспечению качества. Ч.3: Руководящие указания по применению ISO 9001 при разработке, поставке и обслуживании программного обеспечения. 4. 4. ISO 687:1983. ИТ. Управление конфигурацией программного обеспечения. 5. 5. ANSI/IEEE 828 — 1990. Планирование управления конфигурацией программного обеспечения. 6. 6. ANSI/IEEE 1042 — 1987 (ред. 1993). Руководство по планированию управления конфигурацией программного обеспечения. 7. 7. ANSI/IEEE 1219 — 1992. Сопровождение программного обеспечения. Стандарт ISO 12207 — является основным международным нормативным документом, регламентирующим жизненный цикл и, в частности, сопровождение и конфигурационное управление программными средствами. В стандарте эти процессы детализированы соответствующими действиями — процедурами, для которых определены основные работы и их результаты (см. п. 1.5). В этом стандарте непосредственно к задачам сопровождения относятся три процесса: 5.5. Процесс сопровождения в составе Основных процессов; 6.8. Процесс решения проблем — устранения дефектов и 6.2. Процесс конфигурационного управления в составе Вспомогательных процессов.

Ниже эти разделы изложены подробно в полном соответствии с текстом стандарта. Работы, обеспечивающие сопровождение ПС представлены в разделе 5.5 стандарта (24 работы). Предполагается, что работы по сопровождению и развитию версий ПС могут выполняться специалистами, которые не вели разработку ПС на предыдущих этапах. 5.5. Содержание процессов и действий по сопровождению. 5.5.1. Реализация процесса. Эти действия состоят из следующих задач: 5.5.1.1. Персонал сопровождения должен разработать, документировать и выполнить планы и процедуры для задач Процесса сопровождения. 5.5.1.2. Персонал сопровождения должен устанавливать процедуры для получения, записи и сообщений о трекинговых дефектах и модификационных запросах от пользователей и обеспечение обратной связи пользователям. Всякий раз, когда проблемы возникают, они должны быть записаны и введены в Процесс Решения Проблем (6.8). 5.5.1.3. Персонал сопровождения должен выполнять или устанавливать функциональную связь с Процессом Управления Конфигурацией (6.2) для руководства модификацией существующей системы. 5.5.2. Анализ дефектов и модификаций. Эта деятельность включает в себя следующие задачи: 5.5.2.1.Персонал сопровождения должен анализировать проблемное сообщение или модификационный запрос для их воздействия на организацию, существующую систему и интерфейсные системы для оценки: — Печати, корректив, усовершенствований, профилактики или адаптации к новой среде; — Возможностей; например, размер модификации, стоимость, время на модификацию, чтобы ее осуществить; — Риска; например, влияние на выполнение, надежность или защиту; 5.5.2.2. Персонал сопровождения должен повторять или проверять дефект. 5.5.2.3. Базируясь на анализе, персонал обслуживания должен разрабатывать примеры для выполнения модификаций. 5.5.2.4. Персонал сопровождения должен документировать проблемный или модификационный запрос, результаты анализа и примеры реализации. 5.5.2.5.Персонал сопровождения должен получить утверждение на отобранный пример модификации согласно контракту. 5.5.3. Реализация модификации. Эта деятельность состоит из следующих задач: 5.5.3.1. Персонал сопровождения должен проводить анализ и определять, какие: документация, единицы программного обеспечения и версии должны измениться. Это должно быть документировано. 5.5.3.2. Персонал сопровождения должен войти в Процесс Разработки (5.3), чтобы выполнить модификации. Требования Процесса Разработки должны быть дополнены следующим образом: а) Испытание и критерий оценки для тестирования и оценивания модифицированных и немодифицированных частей (единиц программного обеспечения, компонентов и единиц конфигурации) системы должны быть определены и документированы. б) Полная и правильная реализация новых и модифицированных требований должна быть гарантирована. Также должно быть гарантировано, что первоначальные немодифицированные требования были не эффективными. Результаты испытаний должны быть документированы. 5.5.4. Оценка и принятие результатов сопровождения. Эти действия состоят из следующих задач: 5.5.4.1. Персонал сопровождения должен проводить оценки изменений совместно с организацией, разрешающей модификацию, чтобы определить целостность модифицированной системы. 5.5.4.2. Персонал сопровождения должен получить утверждение на удовлетворительное завершение модификации, как определено в контракте. 5.5.5. Перенос на иную платформу. Эта деятельность состоит из следующих задач: 5.5.5.1. Если система или программы (включая данные) перемещаются из старой в новую операционную среду, должно быть гарантировано, что любой программный продукт или данные, произведенные или измененные в течение миграции, согласуются с этим Международным Стандартом. 5.5.5.2. Миграционный план должен быть разработан, документирован и выполнен. Действия планирования должны включать участие пользователей. Пункты в плане должны включать следующее:

а) Анализ требований и определение характеристик переноса — миграции; б) Разработка миграционных инструментальных средств; в) Изменение программного продукта и данных; г) Выполнение переноса; д) Проверка переноса; е) Поддержка для старой окружающей среды в будущем. 5.5.5.3. Пользователям должно быть дано уведомление о планах и действиях по переносу. Уведомления должны включать следующее: а) Заявление, почему старая среда не может больше поддерживаться; б) Описание новой среды с ее датой доступности; в) Описание других имеющихся в распоряжении примеров поддержки, если только поддержка для старой среды ликвидирована. 5.5.5.4. Параллельные операции старой и новой окружающих сред могут проводиться для гладкого перехода к новой среде. В течение этого периода должно быть обеспечено необходимое обучение как определено в контракте. 5.5.5.5. Когда запланированный перенос завершается, уведомление должно быть послано всем заинтересованным лицам. Вся связанная со старой окружающей средой документация, файлы, журналы регистрации и коды должны быть помещены в архивы. 5.5.5.6. Послеоперационный обзор должен быть выполнен для оценки влияния изменений в окружающей среде. Результаты обзора должны быть посланы соответствующим уполномоченным властям и специалистам для информации, руководства и действия. 5.5.5.7. Данные, используемые и связанные со старой окружающей средой должны быть доступны согласно требованиям контракта для защиты данных и ревизии, применимой к данным. 5.5.6. Ликвидация сопровождения программного средства. Эти действия состоят из следующих задач: Примечание: программный продукт может быть ликвидирован (снят с сопровождения) только по запросу владельца. 5.5.6.1. План для прекращения активной поддержки эксплуатирующими и сопровождающими организациями должен быть разработан и документирован. Действия планирования должны учитывать пользователей. План должен обращаться к пунктам, опубликованным ниже. План должен быть выполнен. а) Прекращение полной или частичной поддержки после определенного периода времени; б) Архивирование программного продукта и связанной с ним документации; в) Определение ответственности за любые будущие остаточные результаты поддержки; г) Переход к новому программному продукту, если применим; д) Определение доступности архивных копий данных. 5.5.6.2. Пользователь должен получить уведомление о планах и действиях прекращения сопровождения. Уведомления должны включать следующее: а) Описание замены или расширения (модернизации) с датой ее доступности; б) Заявление, почему программный продукт не может больше поддерживаться; в) Описание других имеющихся в распоряжении вариантов обеспечения, раз сопровождение ликвидировано. 5.5.6.3. Параллельные действия ликвидации старого и введения нового программного продукта должны быть проведены для плавного перехода к новой системе. В течение этого периода должно быть обеспечено обучение пользователя как определено в контракте. 5.5.6.4. Когда наступает запланированное прекращение сопровождения, должно быть послано уведомление всем заинтересованным лицам. Вся связанная с разработкой документация, файлы, журналы регистрации и коды должны быть размещены в архивах. 5.5.6.5. Данные, используемые и связанные с прекращенным сопровождением программным продуктом должны быть доступны согласно требованиям контракта для защиты данных и ревизии, применимой к данным. Раздел 6 стандарта — Конфигурационное управление (п.6.2) включает план, как часть общего плана управления проектом, рекомендации по конфигурационной идентификации, контролю, учету, отчетности и развитию конфигурации версий ПС. 6.2. Процесс управления конфигурацией. 6.2.1. Реализация процесса. Эта деятельность решает следующую задачу:

6.2.1.1. План управления конфигурацией должен быть разработан. План должен описывать: деятельность по управлению конфигурацией; процедуры и программы (планы, графики) выполнения этой деятельности; организацию (организации), ответственную за выполнение этой деятельности и их связь с другими организациями, такими как разработчики программного обеспечения или сопровождения. План должен быть документирован и выполнен. Примечание: — План может быть частью плана управления конфигурацией системы. 6.2.2. Идентификация конфигурации. Эта деятельность решает следующую задачу: 6.2.2.1. Схема должна быть установлена для идентификации единиц программного обеспечения и их версий, которые контролируются (управляются) в проекте. Для каждой единицы программного обеспечения и ее версий должно быть определено следующее: — документация, которая устанавливает нижнюю базовую линию; — справки, ссылки версии; — другие детали идентификации. 6.2.3. Управление конфигурацией. Эти действия решают следующую задачу: 6.2.3.1. Должно быть выполнено следующее: — идентификация и запись запросов изменения; — анализ о оценка изменений; — утверждение или неутверждение запроса; — реализация, верификация и выпуск модифицированной единицы программного обеспечения. Контрольный след должен существовать, посредством чего каждая модификация, причина для модификации и разрешение модификации может быть прослежена. Должна быть выполнена проверка всех документов к управляемым единицам программного обеспечения, которые обеспечивают надежность или критические функции защиты. 6.2.4. Отчеты соответствия конфигурации. Эта деятельность решает следующую задачу: 6.2.4.1. Протоколы управления и отчеты о состоянии, которые демонстрируют состояние и историю управляемых единиц программного обеспечения, включая базовые, должны быть приготовлены. Отчеты о состоянии должны включать число изменений для проекта, последние версии единицы программного обеспечения, выпуск идентификаторов, количество версий и сравнения версий. 6.2.5. Оценка конфигурации. Эта деятельность решает следующую задачу: 6.2.5.1. Должно быть определено и гарантировано следующее: функциональная законченность каждой единицы программного обеспечения в соответствии с их требованиями и физическая завершенность единиц программного обеспечения (отражает ли их проект и код программ новейшее техническое описание). 6.2.6. Управление выпуском и поставкой. Эта деятельность решает следующую задачу: 6.2.6.1. Выпуск и поставка программных продуктов и документации должна (официально, формально, соответственно правилам) управляться. Мастер-копии кода и документации должны быть сохранены в течение жизни программного продукта. Коды и документация, которые обеспечивают надежность или критические функции защиты должны обрабатываться, сохраняться, упаковываться и поставляться согласно политике включенных организаций. 6.8. Решения проблем — ликвидации дефектов в программах. 6.8.1. Реализация процесса. Эта деятельность решает следующие задачи: 6.8.1.1. Процесс решения проблем должен быть проведен для обработки всех дефектов (включая несоответствия), обнаруженных в программных продуктах и действиях. Процесс должен выполнять следующие требования: а) процесс должен быть замкнутым циклом, гарантирующим, что все обнаруженные дефекты быстро сообщены и введены в Процесс Решения Проблем, воздействие инициализировано на них, релевантные стороны извещены о существующих дефектах, причины идентифицированы, проанализированы и, где возможно, устранены, решение и диспозиция достигнуты, состояние отслежено и сообщено, и проблемные отчеты сохранены как предусмотрено в контракте; б) процесс должен содержать схему для классификации и определения приоритетов проблем. Каждая проблема должна быть классифицирована категорией и приоритетом, чтобы облегчить анализ тенденции и решение проблемы; в) анализ должен быть выполнен для обнаружения тенденций в сообщенных дефектах; г) проблемные решения и диспозиции должны быть оценены по критериям: какие проблемы решены, неблагоприятные тенденции изменены и изменения выполнены правильно в соответствующих программных продуктах и действиях, и определить введены ли дополнительные дефекты. 6.8.2. Решение проблем. Эта деятельность решает следующую задачу: 6.8.2.1. Когда дефекты (включая несоответствия) определены в программном продукте или деятельности, проблемное сообщение должно быть приготовлено для описания каждого обнаруженного дефекта. Проблемное сообщение должно использоваться как часть процесса замкнутого цикла, описанного выше: от определения дефекта, через исследование, анализ и решение проблемы и ее причины и до определения тенденции через проблемы.

Стандарт ISO 12207-2 — Процессы жизненного цикла программного обеспечения. Часть 2. Процессы конфигурационного управления (проект) — полностью посвящен сопровождению и конфигурационному управлению сложных ПС. В стандарте развиваются и детализируются процессы представленные в первой части стандарта, изложенные выше. Его основные положения использованы в п.3.4. Стандарт ISO 9000-3:1991 — Общее руководство качеством и стандарты по обеспечению качества. Ч.3: Руководящие указания по применению ISO 9001 при разработке, поставке и обслуживании программного обеспечения. Эта часть 3 базового стандарта по качеству ISO 9000 призвана оказать методическую помощь в случаях, когда по контракту требуется, чтобы поставщик мог продемонстрировать реальную возможность создания ПС с заданным качеством. Непосредственно к задачам сопровождения и конфигурационного управления относится раздел 6.1. 6.1. Общее руководство конфигурацией. 6.1.1 Общие положения Общее руководство конфигурацией обеспечивает механизм идентификации, управления и слежения за версиями каждого изделия программного обеспечения. Во многих случаях предшествующие версии, которые все еще используются, должны также содержаться в рабочем состоянии и управляться. Система общего руководства конфигурацией должна: a) a) однозначно идентифицировать версии каждого изделия программного обеспечения; идентифицировать версии каждого элемента программного обеспечения, которые в b) b) совокупности составляют конкретную версию законченной продукции; c) c) идентифицировать конструкционно-монтажный статус продукции программного обеспечения, находящейся на этапах разработки или поставки и монтажа; d) d) осуществлять управление одновременной актуализацией данного изделия программного обеспечения двумя и более программистами; e) e) обеспечивать координацию актуализации сложной продукции на одном или нескольких участках, в зависимости от потребности; f) f) идентифицировать и прослеживать все действия и изменения, вытекающие из запроса на изменение, начиная с внесения предложения и кончая выпуском продукции. 6.1.2. План общего руководства конфигурацией. Поставщик должен разработать и осуществить план общего руководства конфигурацией, включающий следующее: a) организации, участвующие в общем руководстве конфигурацией и обязанности, вложенные на каждую из них; b) предстоящая деятельность по общему руководству конфигурацией; c) средства, методы и методологии, которые будут использоваться при общем руководстве конфигурацией, d) этапы, на которых изделия должны подпадать под управление конфигурацией. 6.1.3. Деятельность по общему руководству конфигурацией 6.1.3.1. Идентификацию конфигурации и ее прослеживаемость должен Поставщик установить и поддерживать в рабочем состоянии процедуры идентификации изделий программного обеспечения на протяжении всех этапов, начиная с технических условий и кончая разработкой, копированием и поставкой; В случаях, предусмотренных контрактом, эти процедуры могут также применяться после поставки продукции. Каждое отдельное изделие программного обеспечения должно иметь свою собственную идентификацию. Процедуры должны применяться для обеспечения того, чтобы приведенные ниже пункты могли быть идентифицированы для каждой версии изделия программного обеспечения: а) функциональные и технические характеристики; b) все средства разработки, влияющие на функциональные и технические характеристики; c) все интерфейсы к другим изделиям программного обеспечения и оборудованию; d) все документы и массивы данных ЭВМ, относящиеся к изделию программного обеспечения. Идентификация изделия программного обеспечения должна осуществляться таким образом, чтобы можно было продемонстрировать взаимосвязь между этим изделием и конкретными требованиями. Для выпущенной продукции следует установить процедуры, облегчающие прослеживаемость изделия программного обеспечения или продукты программного обеспечения. 6.1.3.2. Управление изменениями Поставщик должен установить и поддерживать в рабочем состоянии процедуры идентификации, документации, анализа и утверждения любых изменений, относящихся к изделиям программного обеспечения в рамках общего руководства конфигурацией. Все изменения, вносимые в изделия программного обеспечения, следует осуществлять в соответствии с этими процедурами. До принятия изменения его законная сила должна быть подтверждена, а воздействия на другие изделия — идентифицированы и исследованы. Следует предусмотреть методы уведомления об изменениях заинтересованных лиц и обеспечить демонстрацию прослеживаемости между изменениями и модифицированными частями изделий

программного обеспечения. 6.1.3.3. Отчет о статусе конфигурации Поставщик должен установить и поддерживать в рабочем состоянии процедуры регистрации данных, управления и сообщения о статусе изделий программного обеспечения, запросах об изменениях и регистрации одобренных изменений. Стандарты, непосредственно регламентирующие конфигурационное управление программными средствами. В стандарте ISO 687 отражены наиболее общие принципы и рекомендации конфигурационного учета, планирования и управления версиями сложных программных средств. Стандарт ANSI/IEEE 828 регламентирует общие требования к конфигурационной идентификации, конфигурационным контролю, учету, отчетности и проверкам. Рекомендуется их применять ко всем компонентам ПС и соблюдать в течение всего жизненного цикла ПС. Руководство по управлению конфигурацией ANSI/IEEE 1042 развивает положения предыдущего стандарта и подробно раскрывает методы решения задач по планированию и управлению конфигурацией программных средств (рис.4.4). В стандарте для каждого раздела этого Плана приводятся обширные комментарии и рекомендации по его содержанию и реализации. Почти 60% объема стандарта посвящены приложениям, в которых изложены 4 примера Планов управления конфигурацией (ПУК) ПС различных классов и назначения. На примерах показана практическая модификация рекомендуемого базового ПУК ПС в зависимости от характеристик объекта и среды разработки Основная часть стандарта состоит из трех крупных разделов, которые содержат введение в проблему, описывают дисциплину, методы и средства управления конфигурацией, а также структуру и содержание ПУК ПС (используемая далее рубрикация соответствует стандарту) 1. Во введении изложены цели управления конфигурацией особенности типовых примеров его применения, которые подробно раскрываются в приложениях. Приводится интерпретация применяемых терминов и аббревиатур, а также перечень используемых стандартов. 2. Дисциплина управления конфигурацией в процессе разработки или сопровождения ПС включает базовые понятия, функции, методы и средства, применяемые в этой области. В качестве функций

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

(репозиторий) библиотеки. В технологии проектирования ПС планы должны четко отражать требования и операции по изменению конфигурации, поддерживать управление процессами выполнения и регистрации изменений, гарантировать правильность и завершенность их реализации в каждой версии ПС. 3. План управления конфигурацией описан в шести подразделах, составляющих основную и наибольшую часть стандарта. В первом, вводном, подразделе определяются цели, сфера действия, понятия и состав рекомендаций, излагаемых в Плане управления конфигурацией ПС. Второй подраздел посвящен конкретизации задач управления конфигурацией. Каждая задача конкретизируется общей постановкой и серией вопросов, на которые рекомендуется подробно ответить в Плане. Третий подраздел в стандарте — наибольший из всех и содержит детальные рекомендации по отражению в Плане задач, сформулированных в предыдущем подразделе. Детализируются принципы конфигурационной идентификации и ее представление в документах. Особое внимание уделено отражению в Плане методов конфигурационного контроля: уровням полномочий специалистов; процессам изменений; совету конфигурационного управления; взаимодействию с другими советами по управлению конфигурацией; поддержке его функций программными средствами автоматизации, отчетам о состоянии конфигурации ПС. Предлагается включать в План тесты, методы испытаний и состав отчетов, а также описание процесса выпуска и внедрения очередной конфигурации ПС. В четвертом подразделе Плана рекомендуется отразить средства автоматизации, технику и методологию, применяемые при проектировании ПС, в частности планы разработки проекта в виде графиков Ганта и ПЕРТ [37,38,39]. В пятом подразделе предлагается, как сделать эффективнее конфигурационный контроль ПС за счет технических средств, которые к нему непосредственно не относятся, и оценивать рентабельность их применения. Шестой подраздел посвящен выделению, накоплению и сохранению необходимого минимума дополнительной информации из Плана управления конфигурацией, которая не регистрировалась в предыдущих разделах. Подобные данные могут быть полезны для анализа и прогнозирования экономических характеристик аналогичных проектов, а также при исследовании эффективности применяемых методов и средств. Стандарт ANSI/IEEE 1219 формализует основные процессы сопровождения комплексов программ. Описан итерационный процесс управления и реализации действий при сопровождении сложных, критических прикладных программных продуктов, а также в более простых случаях. В первом разделе содержится введение с изложением цели стандарта, ссылки на нормативные документы (только IEEE), терминология и структурная схема представления каждой фазы. Определения и сокращения сосредоточены во втором разделе. Третий раздел является основным и содержит основные рекомендации по сопровождению сложных ПС. Он предписывает требования к базисным компонентам при планировании, управлении, реализации и документировании сопровождения ПС. Все фазы сопровождения представляются унифицированной моделью базисных компонентов, включающей описания: исходных данных фазы; основные процессы их преобразования; результирующие данные; процессы контроля действий и результатов на данной фазе. Далее в соответствии с моделью представлены следующие семь фаз: идентификация, классификация и установление приоритетов исправления дефектов и − − выполнения модификаций программ, а также предварительный анализ развития процесса сопровождения; − − анализ реализации изменений, включающий анализ их осуществимости и детальный анализ реализации; − − проектирование изменений компонентов программ с использованием методов конфигурационного управления: модулей, документации, модификации регрессионных тестов, модернизации всей системы и применения ее пользователями; реализация корректировок программ: программирование и тестирование модулей, их − − интеграция, анализ риска и готовности тестов; − − тестирование системы: функциональное системное тестирование, тестирование интерфейсов с внешней средой, регрессионное тестирование всей системы, оценка полноты тестирования; − − приемо-сдаточное тестирование: полные испытания для всех функциональных компонентов, тестирование взаимодействия с внешней средой, регрессионное тестирование; − − поставка версии ПС пользователям: контроль физического состояния конфигураций версий ПС, регистрация пользовательского интерфейса, архивация поставляемых версий, подготовка инструкций и обучение пользователей и заказчиков. Приложение А содержит руководящие указания и детализацию содержания компонентов базовой модели для каждой фазы сопровождения. Дополнительно изложены требования и рекомендации по верификации и валидации, обеспечению качества, анализу риска, защите. Конфигурационное управление представлено в соответствии с фазами процесса сопровождения и стандартом IEEE 1042. Приводятся рекомендации по оценке сложности программ и выполняемых корректировок. Приложение В посвящено краткому изложению современных технологий и инструментальных средств поддержки сопровождения: реинженерингу, реверсной инженерии, повторному использованию программных компонентов. Приложения (все информационные) занимают более половины текста стандарта.

Стандарты, регламентирующие документирование программных средств и баз данных Задачи стандартизации документирования программ и данных. Создание и применение прикладных ПС сложных информационных систем сопровождается документированием этих объектов и процессов их жизненного цикла для обеспечения интерфейса с пользователями, а также для обеспечения возможности освоения и развития функций программных средств и баз данных на любых стадиях проекта ПС. В стандартах и публикациях по моделям жизненного цикла ПС с различной глубиной определено содержание этапов и частных работ при создании и модификации ПС и БД и их компонентов. Для планирования и управления проектами эти модели служат структурной базой объектов и процессов при детализации требований к ожидаемым результатам и формируемым документам. По своему назначению и ориентации на определенные задачи и группы пользователей, документацию ПС можно разделить на: − − технологическую документацию разработки, подготавливаемую для специалистов, ведущих проектирование, разработку, сопровождение и перенос ПС и БД, обеспечивающую возможность детального освоения, развития и корректировки ими программ и данных на всем жизненном цикле ПС; − − эксплуатационную документацию объекта разработки, создаваемую для конечных пользователей ПС и позволяющую им осваивать и квалифицированно применять эти средства для решения конкретных функциональных задач ИС; исследовательскую документацию, предназначенную для анализа характеристик, − − эффективности и качества технологий и объектов проектирования с целью совершенствования методов и средств автоматизации разработки, сопровождения и переноса ПС и БД. Общие требования к составу и содержанию документов на ПС и БД представлены в ряде стандартов разного ранга и в фирменных описаниях технологий создания комплексов программ. Состав документов широко варьируется в зависимости от класса и характеристик объекта разработки, а также в зависимости от используемой технологии. Наиболее сложному случаю разработки критических ПС высокого качества соответствует самая широкая номенклатура применяемых документов. Такой перечень документов может быть использован как базовый для формирования из него состава документов в остальных более простых случаях [40,18]. Технологическая документация, непосредственно и в наибольшей степени должна отражать объекты и процессы ЖЦ прикладных программ и данных. Стандарты регламентируют требования к документам, сопровождающим весь жизненный цикл ПС. В комплекте должны содержаться стандарты и руководства, регламентирующие процессы разработки и обеспечения качества, требования к формализации функций ПС, к показателям качества ПС и его компонентов, методы и средства их достижения, реальные значения достигнутых показателей качества. Для контроля возможных изменений целесообразно предусмотреть и согласовать с заказчиком специальный документ, регламентирующий правила применения и корректировки результатов документирования разработки ПС, а также состав и содержание поддерживающей его документации. Необходимое качество объектов формируется, документируется и обеспечивается при выполнении частных работ каждого этапа ЖЦ и окончательно удостоверяется документами при его завершении. Измерения объектов разработки сводятся к регулярной, поэтапной регистрации и документированию характерных для данного объекта показателей качества, а также к сопоставлению их с заданными требованиями. При обнаружении отклонений от требований принимаются меры либо для улучшения реальных показателей, либо по корректировке требований к показателям для данного компонента на контролируемом этапе. Измерения в процессе разработки состоят в контроле запланированного графика работ, принятой технологии и использования ресурсов. Это должно обеспечивать предотвращение дефектов и ошибок или их по возможности раннее обнаружение. В плане управления проектированием для каждого этапа работ необходимо документально фиксировать. − − исходные данные, требующиеся для успешного выполнения данного этапа; контролируемые, результирующие данные о состоянии объекта и процесса разработки, − − регистрируемые после завершения этапа; − − содержание процедур контроля состояния проекта в процессе выполнения работ этапа; критерии оценки результатов выполненных работ при завершении этапа; − − состав и содержание отчетных документов, представляемых для оценки состояния проекта и − − результатов завершенного этапа для использования на следующем этапе. − − По функциональному назначению содержание профиля технологического документирования ПС (см.п.1.7) целесообразно разделить на следующие группы. − − базовые документы, определяющие цели и методологию применения конкретной версии ЖЦ ПС; − − ссылочные документы на руководства по организации подобных разработок, включая

общесистемные стандарты и нормативные документы различных уровней; − − стандарты, непосредственно регламентирующие работы и документы жизненного цикла программ, планирование и технологию разработки документации, состав и описание инструментальных средств автоматизации разработки; − − стандарты и нормативные документы, непосредственно используемые при разработке, переносе, тестировании и испытаниях программ на различных этапах. Профиль стандартов документирования объектов — прикладных ПС и их компонентов должен определять: логическую структуру программных и информационных компонентов и базы данных − − проекта ПС; − − спецификации на внутренние межмодульные интерфейсы компонентов прикладных ПС и на интерфейсы со средой ИС; − − язык и правила программирования, идентификации компонентов, комментирования текстов программ и описаний данных; − − структуру и содержание исходных и отчетных документов по этапам разработки и тестирования ПС. Состав и содержание этих документов тесно связаны с планом и перечнем работ, выполняемых на соответствующих этапах. Некоторые документы уточняются и конкретизируются на последовательных этапах. Формализация структуры и типового содержания каждого документа должна позволять четко контролировать результаты этапа и качество выполненных работ. Каждый документ должен иметь: — сформулированные назначение; — область действия документа; — категории специалистов, для которых он предназначен и кем он разрабатывается; — этапы работ, на которых следует его применять; — функциональную, содержательную часть в соответствии с его назначением. Типовую структуру каждого документа целесообразно разрабатывать каждой фирмой в соответствии с ее традициями, используемой технологией и особенностями проектируемого ПС. Эксплуатационная документация должна обеспечивать отчуждаемость ПС и БД от их первичных разработчиков и возможность эффективного применения достаточно квалифицированными специалистами. Ее состав и содержание не зависят от метода создания ПС или БД: путем переноса или полной разработки. Однако при переносе может использоваться прототип эксплуатационной документации, сопровождающей переносимые средства, что резко сокращает затраты на ее создание. Состав этой документации формируется выборкой из технологических документов с учетом требований заказчиков или потенциальных пользователей, а также приведенных ниже международных стандартов. Эксплуатационные документы должны исключать возможность некорректного использования ПС и БД за пределами условий эксплуатации, при которых документами гарантируются определенные показатели качества функционирования ИС. Профили документирования прикладных ПС, кроме базовых стандартов жизненного цикла должны использовать и применять ряд стандартов де-факто и ведомственных нормативных документов. Программная эксплуатационная документация должна содержать следующие элементы: краткую аннотацию и описания решаемых задач и алгоритмов; − − описание структуры и функций программы, иерархии модулей программы, межмодульных − − интерфейсов; описание пользовательских интерфейсов; − − описание входных и выходных данных; − − − − указание конкретной среды функционирования ПС, способов проверки работоспособности программы и контрольные задачи. Поставляться эксплуатационная документация может на традиционных бумажных носителях или на стандартных магнитных носителях для ЭВМ. В последнем случае она используется пользователями визуализацией на дисплеях или после распечатки на бумажные носители. Коммерческие пакеты прикладных ПС целесообразно снабжать документами в соответствии со стандартом ISO 9127 (см. ниже). Исследовательская документация имеет экспериментальный характер, зависящий от возможных целей исследований. Основная ее задача состоит в фиксировании и обобщении характеристик и процессов разработки и всего жизненного цикла ПС и БД. Этой документацией пользуются в основном руководители, разработчики и исследователи проектов при анализе технологий, планировании новых разработок ИС или их переноса на иные платформы. Из-за разнообразия исследовательских задач этот тип документации практически всегда имеет оригинальный состав и содержание и пока не стандартизируется. Остальные типы документов активно стандартизируются, прежде всего, для обеспечения высокого качества создания и применения информационных систем. Стандарты, регламентирующие документирование программ и данных. Общие требования к составу и содержанию документов, поддерживающих создание ПС и БД, представлены в ряде стандартов разного ранга, в фирменных описаниях технологий и в публикациях по управлению проектами. В стандартах DOD

2167 А и DOD 2168 требования к документации предписываются как обязательные, а в остальных случаях имеют преимущественно рекомендательный характер. Состав документов широко варьируется в зависимости от класса и характеристик объекта разработки, а также в зависимости от используемой технологии. Наиболее сложному случаю разработки критических ПС высокого качества соответствует самая широкая номенклатура документов. Такой перечень документов может быть использован как базовый для формирования из него состава документов в остальных более простых случаях. Документирование проектов и результатов тестирования комплексов программ и их компонентов наиболее полно представлено в стандарте ANSI/IEEE 829, который целесообразно также использовать как основу разработке мобильных ПС. Всю документацию, обеспечивающую проектирование ПС и БД, можно разделить на обобщающую, охватывающую функциональное назначение ИС, и на детализирующую результаты отдельных этапов разработки. В базовых стандартах жизненного цикла ПС ISO 12207 и ISO 9000-3 различной глубиной определено содержание этапов и частных работ при создании и модификации ПС и их компонентов. Для планирования и управления проектами ПС эти стандарты служат структурной базой объектов и работ при детализации требований в профиле документирования, в который могут входить стандарты: 1. ISO 6592:1985. ОИ. Руководство по документации для вычислительных систем. 2. ISO 9294:1990-TO. ИТ. Руководство по управлению документированием программного обеспечения. 3. ISO 9127:1988. СОИ. Пользовательская и рекламная документация на пакеты программ. 4. ANSI/IEEE 1063:1987 (ред. 1993). Пользовательская документация на программные средства. Кроме перечисленных имеется свыше двадцати отечественных ГОСТов и РД (руководящих документов), регламентирующих документирование автоматизированных систем (АС). Большинство из них утверждено в начале 80-х годов и в значительной степени устарело. Интерес представляет ГОСТ 34.201-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначения документов при создании автоматизированных систем. В этом головном стандарте перечислен ряд ГОСТов, детализирующих требования к составу и содержанию отдельных документов на программ и данные ИС. При создании и применении мобильных ПС и БД целесообразно выбирать и применять некоторые из них с учетом особенностей проекта. Однако в основном следует ориентироваться на международные стандарты. Главная цель стандарта ISO 6592 — состоит в установлении базисной структуры документации, на основе которой возможно для любого проекта обеспечить эффективное совершенствование и реализацию информационной системы, ПС и БД. В стандарте установлены руководящие принципы создания документов для информационных систем. Эти принципы разработаны с целями обеспечения: эффективного взаимодействия всех разработчиков прикладной ИС; создания хорошо спланированной, стандартной документации системы; адекватной модификации документации на ПС и БД, параллельно с их совершенствованием. Указывается, что хорошо определенные правила документирования процесса совершенствования ИС упростят: подготовку самой документации; оценку времени и затрат ресурсов для реализации проекта; обмен информацией между разработчиками системы, что приведет к выбору достижимых целей ИС и более обоснованному функциональному проектированию; принятие решений и консультации с персоналом во время работы по совершенствованию системы. Документация, разработанная по руководящим указаниям стандарта, обеспечивает: — оперативный контроль руководства за процессом развития и совершенствования системы; — позволяет пользователям эффективно и правильно использовать ИС, ПС и БД; — позволяет операторам вычислительных машин составлять график работы и работать на системе; — помогает диагностировать и корректировать аномалии и ошибки; — предоставляет информацию о состоянии ПС и БД для поддержки их эксплуатации. Отдельный документ или его раздел может быть бесполезным для одной системы, но важным для другой, и поэтому допускается корректировка состава документации. Рекомендуется применять таблицу контрольных проверок соответствия реальной документации на ИС международному стандарту. Это гарантирует, что пропуск некоторой информации в документах будет лишь намеренным, после принятия решения, а не в результате просмотра. В стандарте идентифицированы два базисных типа информации: административная и техническая. Административная информация поступает от средств управления системой и руководства в виде записей — приказов и выполненных заданий. Рекомендуется сохранять эту информацию, но ее не обязательно обновлять, если реализация системы завершена. В техническую информацию входят описания всех аспектов ИС в настоящий момент времени, в том числе аппаратных и программных средств и данных. Существенно, что техническая информация все время обновляется в течение жизненного цикла ИС. Руководящие указания описываемого стандарта структурированы, что позволяет поставить в соответствие этапам развития и совершенствования проекта необходимую документацию. Основные этапы проекта последовательны во времени, но отдельные этапы и подготовка некоторых документов перекрываются; например подготовку руководств поддержки системы следует начать на этапе проектирования и внедрения ИС. У различных приложений варьируется как количество этапов, так и количество документов; в руководстве дан список наиболее общих компонент в генерируемых документах

на каждом этапе процесса создания и совершенствования системы. Технический отчет ISO 9294 представляет руководство по документированию ПС для руководителей, отвечающих за создание программной продукции. Руководство предназначено для помощи в управлении разработкой и эффективном документировании программных проектов. Отчет отражает рекомендуемые стратегии, стандарты, процедуры, ресурсы и планы, которыми должны заниматься сами руководители в целях эффективного управления документированием ПС и БД. Охвачены все типы программной документации на всех стадиях жизненного цикла ИС. Рекомендуемые принципы управления документированием ПС и БД для проектов любого объема и сложности одни и те же. Детализированы функции документации, обеспечивающей: информацию для управления разработкой ИС; связь между задачами в комплексе программ; достижение заданного качества программ; сопровождение программных средств; исторические справки. В процессе установление стратегии, стандартов и руководств по документированию рекомендуется осуществлять: — выбор модели жизненного цикла ПС и БД; — определение типов и содержания каждого документа; — определение необходимого качества документа; — определение форматов и системы обозначения документов; — установление процедур документирования. Обращается внимание на необходимость тщательного распределения ресурсов для документирования: персонала; технических средств; финансов, а также на планирование документирования. Стандарт ISO 9127 отражает пользовательскую документацию и описание применения, которые должны поставляться на рынок вместе с потребительским пакетом ПС. Для защиты собственных интересов разработчики обычно не публикуют для потребителей системную и программную документацию, требуемую для сопровождения и улучшения ПС, которая детально описывает содержимое программ. Производители выпускают данную документацию отдельно для того, чтобы адекватно сопровождать ПС. Потребительские пакеты ПС — это готовые пакеты, предназначенные для продажи потребителю. Обычно ПС продается предварительно упакованным со своей пользовательской документацией. Стандарт не дает руководства о том, как, в какой форме или в каком стиле должна быть представлена информация, а только предлагает порядок подачи информации и расположение содержимого информации в документации отдельного пакета. Пользовательская документация — инструкция по эксплуатации содержит описание, в котором заключена вся информация, необходимая пользователю для установки, запуска и применения ПС. Обычно эта документация представляет собой одно или более руководств, заключенных вместе с носителями ПС внутри упаковки. В результате пользователи не могут ознакомиться с руководством до тех пор, пока пакет не куплен. Состав пользовательской документации описан в разделе 1 данного стандарта. Описание целей и области применения публикуется на внешней упаковке пакета ПС. Его задачей является дать возможность будущему покупателю оценить применимость ПС к своим потребностям. Структура этой информации представлена в разделе 2 данного стандарта. Стандарт ANSI/IEEE 1063 содержит минимальные требования к структуре и содержанию комплекта документов для пользователей программных продуктов. Стандарт ориентирован на документы, применяемые при инсталляции, эксплуатации и поставке ПС любого размера и назначения, но без права изменения программ. Он не применим для технологической документации, используемой при проектировании, разработке, тестировании, испытаниях и сопровождении ПС, а также для оформления коммерческих пакетов прикладных программ (см.ISO 9127). Использование стандарта не должно препятствовать применению более строгих и широких требований к документам, а также собственных стандартов организаций по стилю изложения документов. Стандарт состоит из семи разделов. В первых двух разделах представлено назначение, ограничения для применения и определения основных терминов. В третьем разделе рекомендуется начинать планирование разработки документации с определения: потенциальных пользователей и их взаимодействия с документами; − − комплектации и ориентации каждого документа на определенную сферу применения; − − − − способов использовавших документов: инструктивных для обучения, применению и основным операциям по − − эксплуатации, диагностике и инсталляции ПС − − и справочных, детально представляющих всю необходимую информацию при применении и функционировании программ. В четвертом разделе представлены требования составу (структуре) единого пользовательского документа. Две таблицы, отражают рекомендуемую структуру документа и варианты его модификации. В первой таблице перечислены названия подразделов, рекомендуемого типового пользовательского документа на ПС. Во второй таблице состав этих подразделов адаптирован для документирования небольших, относительно простых программ и для сложных комплексов программ с многотомной документацией. Пятый раздел посвящен подробному изложению требований и рекомендаций к содержанию каждого из 12-ти подразделов пользовательского документа на программное средство. Начинается документ с титульного листа, оформляемого по правилам фирмы с учетом требований заказчика. Второй подраздел

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

Заключение И СММ и SPICE начинались как средства решения одной частной задачи – выбора наилучшего поставщика ПО. Однако эти модели переросли свои исходные предпосылки и успешно прошли путь от исследовательских разработок до мировых стандартов. На сегодняшний день они представляют собой наиболее развитые модели качества, прошедшие применение на практике. Описанные стандарты уже сегодня являются серьезной альтернативой для ISO 9000-9004, привлекая своими возможностями усовершенствования сертифицируемых процессов все новых и новых сторонников. Таким образом, соответствие стандарту перестает быть простым свидетельством достижения некоторого уровня качества и становится способом реального улучшения существующих на предприятии процессов.

Литература: 1. M. C. Paulk, B. Curtis, M. B. Chrissis, C. V. Weber. Capability Maturity Model, Version 1.1 // IEEE Software. 1993. July. P. 18-27. 2. Аншина М. Страсти по качеству ПО // Открытые системы. 1998. №6 3. Paulk M. C. How ISO 9001 Compares With CMM // IEEE Software. 1995. January. P. 74-83. 4. Терехов А. Н. Программирование плюс… что? // Read. Me. 1995. №7-8. 5. Куртис В. Программисты и профессиональные спортсмены // Открытые системы. 1998. №1. 6. Andres, P. Ferrer, P. A. Gutierrez, G. Satriani. ISO 9000 Sertification as a Business Driver. The SPICE Road // Second International Conference on ISO 9000 and TQM. 1997. April. Джонс Д. Проверка соответствия прикладных систем стандарту POSIX1.Открытые системы. 7. 1992. Вып.1. С. 7-13. 8. Edmonds E.A. The separate user interface. Academic Press. 1992. UNIX & OPEN systems service. DataPRO, McGrow-Hill, England, 1993. 9. 10. Система сертификации Советской ассоциации качества. Сборник руководящих документов. М.: Изд. ВНИИКИ, 1992. Cargill C.F. Information technologie stangardisation. Digital Press. 1989. 11. 12. Замулин А.В. Системы программирования баз данных и знаний. Новосибирск. Наука. 1990. 13. Quarterman J.S., Wilhelm S. Unix, Posix and open systems: The open standards puzzle. N.Y., AddisonWesley. 1993. 14. Арсено Ж., Тиман М., Хенкель-Уоллес Д.В. Переносимость программного обеспечения.GNU Открытые системы. 1993. Вып. 2. С.29-35. 15. Кочин В.Н. Эволюция графических стандартов. Открытые системы, 1995, вып.4. С.51-56. 16. Эндерле Г., Кэнси К., Пфафф Г. Программные средства машинной графики. Международный стандарт GKS. Пер. с англ. Под ред. С.М.Ковтуненко. М.: Радио и связь, 1988. 17. АРР — Application Portability Profile. The U.S. Government open system environment profile OSE/1 Version 2.0. NIST. Washington. 1993. 18. Sommerville I. Software engineering. Addison-Wesley. Lancaster University. 1992. 19. Computing Architecture for the 90-s. Computer Associates International Inc. — 1990. 20. Gilb T. Principles of software engineering management. Wokingham, England: Addison-Wesley, 1988. 21. Simons G. Introducing software Engineering. N.Y., Prentice-Hall. 1987. 22. Stradis.Product description. McDonnell Douglas Information Systems, 1991. 23. Кузнецов С.Д. Реляционные системы управления базами данных: введение. Открытые системы. 1993. Вып.4. С. 17-27. 24. А.Г.Мамиконов, В.В.Кулъба, C.A-Косяченко, И.А.Ужастов Оптимизация структур распределенных баз данных в АСУ. М.: Наука,1990. 25. Система баз и банков данных: Нормативно-методические материалы. М.: ВИМИ, 1992. 26. NgP.A., Yeh R.T. ed. Modem software engineering. Foundations and current perspectives. N.Y.: Van Nostrand Reinhold, 1990. 27. Антопольский А.Б., Ауссем В.И.,Вигурский К.В., Кристальный Б.В. Учет, регистрация и сертификация баз данных. НТИ .- Сер. 1.1993. № 7. С.30-32. 28. Дейт К. Введение в системы баз данных. Пер. с англ./М.: Наука. 1980. 29. Кузнецов С.Д. Стандарты языка реляционных баз данных SQL:краткий обзор. СУБД №2.1996. стр. 636 30. П. Ладыженский Г. Технология "клиент-сервис" и мониторы транзакций. Открытые системы. 1994. Вып.7. С.4-11. 31. Dunham J.R. Verification and validation in next decade. IEEE Software. - 1989.-May.'P.47-53. 32. Howden W.E. Functional program testing and analysis. N. Y.: McGraw-Hill, 1987. 33. Pamas D.L. Software aspects of strategic defence systems. Communications of the ACM. - 1985. V.28, № 12. P.1326-1335. 34. Valrand C.B. et al. Performance verification of space-shuttle on boord software. 4-th AIAA/IEEE Digital Avionics Systems Conference. 1981.P.446-458. 35. Испытательные центры за рубежом. М.: Изд. стандартов, 1989. 36. Щербо В.К. Международная стандартизация в области информационной технологии. Проблемы информатизации. — М.: 1992. №4. С.47-51. 37. Гантер Р. Методы управления проектированием программного обеспечения. Пер. с англ. /Под ред. Е.К. Масловского. — М.:Мир, 1981. 38. Кофман А., Дебазей Г. Сетевые методы планирования и управления: Пер. с франц. — М.: Прогресс, 1968. 39. Fersko-Weis H. High-end project managers make the plans. PC Magazine. - 1989. May, 16. P.155-195. 40. Липаев В.В. Управление разработкой программных средств. Методы, стандарты, технология. М.: Финансы и статистика, 1993.