Стандарты в области промышленного обеспечения.

В Толковом словаре по информатике В.И. Першикова и В.М. Савинкова [52] понятие стандартизация определяется как принятие соглашения по спецификации, производству и исполь­зованию аппаратных и программных средств вычислительной тех­ники; установление и применение стандартов, норм, правил и т.п.

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

Такие стандарты регламентируют взаимодействие между раз­личными программами. Для этого предназначены стандарты меж­программного интерфейса, например OLE (Object Linking and Embedding — связывание и встраивание объектов). Без таких стандартов программные продукты были бы «закрытыми» друг для друга.

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

Все компании-разработчики должны обеспечить приемлемый уровень качества выпускаемого программного обеспечения (ПО). Для этих целей предназначены стандарты качества программно­го обеспечения или отдельные разделы в стандартах разработки программного обеспечения, посвященные требованиям к качеству программного обеспечения.

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

Необходимость стандартизации разработки программного обеспечения наиболее удачно описана во введении в стандарт ISO/ IEC 12207: «Программное обеспечение является неотъемлемой частью информационных технологий и традиционных систем, таких, как транспортные, военные, медицинские и финансовые. Имеется множество разнообразных стандартов, процедур, мето­дов, инструментальных средств и типов операционной среды для разработки и управления программным обеспечением. Это раз­нообразие создает трудности при проектировании и управлении программным обеспечением, особенно при объединении про­граммных продуктов и сервисных программ. Стратегия разра­ботки программного обеспечения требует перехода от этого мно­жества к общему порядку, который позволит специалистам, прак­тикующимся в программном обеспечении, «говорить на одном языке» при разработке и управлении программным обеспечени­ем. Этот международный стандарт обеспечивает такой общий порядок».

Попробуем внести порядок в многообразие стандартов, дей­ствующих в сфере ИТ, и классифицировать их (рис. 1.3).

Как видно, верхняя часть классификации напоминает указан­ные выше виды стандартов. Однако здесь появляются и свои осо­бенности. Это относится прежде всего к стандартам «де-юре» и «де-факто». Давайте сразу определим эти понятия.

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

Одна из главных причин значимости современной програм­мы стандартизации — осознание опасности злоупотребления стандартами «де-факто». В 60-е и 70-е годы XX века создание стандартов «де-факто» ставило пользователей в зависимое от про­изводителей положение при использовании основных средств об­работки данных и телекоммуникаций. Важный аспект сегодняш­ней работы по стандартизации — преодоление этой зависимости через продвижение стандартных интерфейсов. Долгое время та кими стандартами были SQL (Structured Query Language) и язык диаграмм Д. Росса SADT (Structured Analysis and Design Technique).

Стандарт «де-юре» создается формально признанной стандар­тизующей организацией. Он разрабатывается при соблюдении пра­вил консенсуса в процессе открытой дискуссии, в которой каждый имеет шанс принять участие. Ни одна группа не может действовать независимо, создавая стандарты для промышленности. Если какая-либо группа поставщиков создаст стандарт, не учитывающий тре­бования пользователей, она потерпит неудачу. То же самое проис­ходит, если пользователи создают стандарт, с которым не могут или не будут соглашаться поставщики, — этот стандарт также не будет успешным. Стандарты «де-юре» не могут быть изменены, не пройдя процесс согласования под контролем организации, разра­батывающей стандарты. Стандарты OSI (Open Systems Inter­connection reference model), Ethernet, POSIX, SQL и большинство стандартов языков — примеры такого рода стандартов.

В качестве примера перехода стандарта «де-факто» в стандарт «де-юре» рассмотрим историю развития и стандартизации языка SQL.

Работы по созданию языка SQL были начаты в 70-х годах прошлого столетия в исследовательских лабораториях компании IBM. В настоящее время он стал одним из главных стандартов в области информационных систем и обеспечил технологию базо­вого языка для целого поколения СУБД, основанных на реляци­онной модели. Несмотря на то, что он был коммерчески реализо­ван в начале 80-х годов лишь для небольшой группы программ­ных продуктов, SQL, бесспорно, получил признание с принятием ANSI и ISO стандарта SQL-86. Позднее, при подготовке стан­дарта SQL-89, в язык был включен ряд дополнительных возмож­ностей.

Истоки SQL следует отнести к периоду рождения реляцион­ной модели данных (описанной в статье Э.Ф. Кодда) [65]. По­скольку в течение нескольких последующих лет не появилось ни­каких языков, подобных SQL, в исследовательских проектах, ини­циированных компанией IBM после публикации статьи Э.Ф. Кодда, придавалось особое значение необходимости создания языков интерфейса создаваемых СУБД для проверки возможнос­тей реляционной модели. Историю разработки языка SQL иллю­стрирует рис. 1.4.

В исследовательских лабораториях IBM в начале 70-х годов 20 века одновременно с работой над будущим языком SQL раз­рабатывались и другие проекты по созданию и эксперименталь­ной реализации реляционных языков. Вероятно, наиболее извес­тным из них является созданный М. Злуфом из лаборатории IBM в Йорктаун-Хейтс примерно в одно и то же время с SEQUEL (ранней версией SQL) реляционный язык Query-By-Example (QBE). Этот язык используется в настоящее время во многих коммерчес­ких программных продуктах наряду с SQL.

В 1974 г. Дональд Д. Чамберлин из Исследовательской лабо­ратории IBM в Сан-Хосе предложил спецификации реляционно­го языка, названного SEQUEL (Structured English QUEry Language). Пересмотренная версия этого языка (SEQUEL/2) была разработана в 1976—1977 годах, и он приобрел свое окончатель­ное название — SQL (Structured Query Language).

Еще перед тем, как коммерческие продукты IBM в начале 80-х годов 20 века вышли на рынок программного обеспечения, ком­пания Relation Software Inc. (называющаяся теперь Oracle Corporation) объявила о выпуске реляционной СУБД, основан­ной на языке SQL. Эта система в результате ее эволюции стала одной из доминирующих коммерческих систем и носит название ORACLE.

Продукт ORACLE с его языком SQL столкнулся с конкурен­цией в сфере средних ЭВМ и мини-ЭВМ со стороны продуктов ряда других разработчиков, в частности СУБД Ingres с языком QUEL компании Relation Technology Inc., а также продукта Rdb/ VMS с языком RDML компании Digital Equipment Corporation.

Одной из причин преуспевания SQL послужило формирование Американским национальным институтом стандартов (American National Standards Institute, ANSI) комитета ХЗН2, учрежденного для разработки стандартов языков баз данных. Представитель IBM предложил использовать в качестве предварительных специфика­ций реляционного языка результаты ранее проведенной IBM ра­боты над SEQUEL/2, и разработчики стандарта приступили к ра­боте. Документ, озаглавленный «SQL», представлял собой по боль­шей части трактат о различных формах SQL, используемых в коммерческих программных продуктах.

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

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

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

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

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

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

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

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

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

СЕРТИФИКАЦИЯ ПО.

Для удостоверения качества, надежности и безопасности применение сложных, критических ИС используемые в них ПС следует подвергать обязательной сертификации аттестованными, проблемно-ориентированными испытательными лаборатория»» Такие испытания необходимо проводить, когда программы управляют сложными процессами или обрабатывают столь важную информацию, что дефекты в них или недостаточное качество м> гут нанести значительный ущерб. Сертификационные испытания должны устанавливать соответствие комплексов программно* документации и допускать их к эксплуатации в пределах измене­ния параметров внешней среды, исследованных при проведении проверках. Эти виды испытаний характеризуются наибольшее строгостью и глубиной проверок и должны проводиться специалистами, не зависимыми от разработчиков и заказчиков (пользо­вателей). Испытания ПС должны опираться на стандарты, фор­мализованные методики и нормативные документы разных уров­ней. Множество видов испытаний целесообразно упорядочивать и проводить поэтапно в процессе разработки для сокращения затрат на завершающихся сертификационных испытаниях.

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

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

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

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

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

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

Особенности обеспечения надежности функционирования им­портных программных средств. При использовании зарубежных ПС в принципе в них возможны как злоумышленные, так и случайные, непредумышленные искажения вычислительного процес­са, программ и данных, отражающиеся на надежности их функ­ционирования. Злоумышленные вирусы и «закладки», хотя и мало­вероятны в серийных, широко тиражируемых в мире ПС, тем не менее требуют особых методов и средств целенаправленного ил обнаружения и устранения. Зарубежным специалистам свойственно ошибаться так же, как и отечественным, однако более высоких качество используемых технологий разработки и современ­ен проектировочная культура позволяют значительно снижать уровень дефектов в изделиях, поступающих на рынок и в эксплу-1~±шпо. Тем не менее в любых сложных импортных ПС всегда не гарантировано полное, абсолютное отсутствие случайных ошибок, которые остаются важнейшими дестабилизирующими фак­торами. Их применение в критических отечественных ПС требует соответствующего дополнительного контроля качества и спе-114альных работ по обеспечению надежности при эксплуатации.

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

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

Этому же может способствовать применение разработчика­ми ИС той же CASE-технологии, которая использовалась зару­бежными решателями применяемых ПС. Для этого, в частности, наиболее популярные СУБД при продаже комплектуются сред­ствами соответствующей CASE-технологии. Поставки приклад­ных программ различного назначения могут содержать рекомен­дации по использованию определенных CASE-технологий при комплексировании импортных компонентов в составе конкрет­ной ИС. Применение той же CASE-технологии позволяет более полно понимать функциональные и технические возможности закупленных ПС в процессе их комплексирования в проблемно-ориентированной ИС. Это предотвращает наиболее сложные си­стемные ошибки при использовании и интегрировании импорт­ных ПС. Таким образом, хотя непосредственное предотвраще­ние и исправление ошибок импортных ПС отечественными потребителями в процессе разработки ИС затруднительны, при соответствующем взаимодействии с конкретными зарубежными фирмами надежность ИС при использовании зарубежных прог­раммных продуктов можно поставить под достаточно жесткий контроль.

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

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

Оперативные методы повышения надежности функционирова­ния ПС предусматриваются в некоторых зарубежных изделиях и, в частности, в механизмах обеспечения целостности информации баз данных в реляционных СУБД. Однако разнообразие условий функционирования импортных ПС в сложных отечественных ИС не позволяет удовлетвориться только штатными методами опе­ративного обнаружения аномалий и восстановления вычисли­тельного процесса, программ и данных. Методы и средства для этого могут быть в ряде случаев достаточно автономными и ори­ентированными на оперативное повышение надежности конкрет­ной ИС в целом, а не только отдельных используемых ПС. Эти специализированные методы и средства могут разрабатываться отечественными специалистами для обеспечения комплексной на дежности с использованием всех импортных компонентов. Та­кой подход позволяет обеспечить комплексирование разнород­ных ПС различных зарубежных поставщиков и специализирован­ной отечественной системы оперативной защиты в едином комп­лексе программ. При этом важно использовать концепцию и стандарты открытых систем при взаимодействии между как заку­паемыми, так и вновь разрабатываемыми компонентами ПС, а также при их взаимодействии с внешней средой. Применение стан­дартизированных интерфейсов открытых систем между приклад­ными программами и CASE-технологией является эффективным современным методом повышения надежности информационных систем при наличии разнородных поставщиков компонентов.

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

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

• при наличии в составе поставляемой документации исходных текстов программ на языке программирования и описаний ал­горитмов обработки информации;

• при наличии только эксплуатационной документации, недостаточной для анализа содержания и текстов программ.

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

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

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

ЗАКЛЮЧЕНИЕ.

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

Существует множество определений качества, в основе поня­тия качества продукта или услуги лежит идея об удовлетворении потребностей конечного пользователя — реального или потен­циального потребителя. Вот определение этого понятия в соот­ветствии со стандартом ISO 8402:1994.

Качество — совокупность характеристик объекта, относящих­ся к его способности удовлетворить установленные и предпола­гаемые потребности.

Можно выделить три большие группы факторов, влияющих на качество программного обеспечения:

• функциональная — связана с полнотой и удобством использо­вания реализованных функций программного средства;

• административная — связана с квалификацией персонала, орга­низационной структурой и управлением персоналом;

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

Современная техника управления качеством (например, кон­цепция Total Quality Management (TQM)) базируется именно на управлении качеством. На современном этапе уже недостаточно иметь только методы оценки качества произведенного и использу­емого программного средства (выходной контроль), необходимо иметь возможность планировать качество, измерять его на всех этапах жизненного цикла программного средства и корректиро­вать процесс производства программного обеспечения для улуч­шения качества. Международные стандарты серии ISO 9000 регла­ментируют создание системы управления качеством. Однако они являются общими, лишь рекомендательными. Каждая компания, производящая программное обеспечение и желающая внедрить у себя действенную систему управления качеством на основе стан­дартов ISO 9000-й серии, должна учесть специфику своей отрасли и разработать систему показателей качества, которая бы отража­ла реальное влияние факторов качества на программный продукт.

Программное обеспечение как продукт имеет некоторые от­личия от других промышленных продуктов:

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

• большие ресурсы затрачиваются на стадии планирования, реа­лизации и тестирования;

• сильное влияние человеческого фактора на производство про­граммного продукта, так как производство программного про­дукта — интеллектуальная и творческая деятельность;

• в жизненном цикле программного продукта, как правило, от­сутствует этап утилизации;

• программный продукт не подвержен физическому старению, а только моральному.

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

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

При построении системы качества могут быть использованы математические методы: методы корреляционного анализа (для выяснения выявления зависимости и тесноты свя