Стандартизация, сертификация и управление качеством программного обеспечения

 

Лекция 2.

 

Тема лекции: «Стандартизация и метрология в разработке программного обеспечения».

1. Стандартизация показателей качества программных средств.

2. Оценка качества создания программного обеспечения.

3. Метрики качества программного обеспечения.

 

 

1. СТАНДАРТИЗАЦИЯ ПОКАЗАТЕЛЕЙ КАЧЕСТВА ПРОГРАММНЫХ СРЕДСТВ.

 

1.1.               Стандартизация в области информационных технологий.

1.1.

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. № 184-ФЗ «О техническом регулировании», а правила применения национальных стандартов Российской Федерации - ГОСТ Р 1.0-2004 «Стандартизация в Российской Федерации. Основные положения».

 

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

 

Работы по стандартизации в России осуществляются на основе принятого Федерального закона «О техническом регулировании» от 27 декабря 2002 года № 184-ФЗ.  Распоряжением Правительства Российской Федерации от 24 сентября 2012 года № 1762-р одобрена Концепция развития национальной системы стандартизации Российской Федерации на период до 2020 года.

 

 Целями стандартизации являются:

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

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

    - содействие соблюдению требований технических регламентов;

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

 

Стандартизация осуществляется в соответствии с принципами:

    - добровольного применения документов в области стандартизации;

    - максимального учета при разработке стандартов законных интересов заинтересованных лиц;

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

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

    - недопустимости установления таких стандартов, которые противоречат техническим регламентам;

    - обеспечения условий для единообразного применения стандартов.

 

К документам в области стандартизации, используемым на территории Российской Федерации, относятся:

    - национальные стандарты;

    - правила стандартизации, нормы и рекомендации в области стандартизации;

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

    - стандарты организаций;

    - своды правил;

    - международные стандарты, региональные стандарты, региональные своды правил, стандарты иностранных государств и своды правил иностранных государств, зарегистрированные в Федеральном информационном фонде технических регламентов и стандартов;

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

    - предварительные национальные стандарты.

 

Постановлением Правительства Российской Федерации от 17 июня 2004 года № 294 «О Федеральном агентстве по техническому регулированию и метрологии» на Агентство возложены функции национального органа Российской Федерации по стандартизации. При подаче заявок для формирования программы разработки национальных стандартов технические комитеты по стандартизации руководствуются федеральным законом «О техническом регулировании» (глава 3), Приоритетными направлениями развития науки, технологий и техники в Российской Федерации и Перечнем критических технологий Российской Федерации. Экспертиза проектов общероссийских классификаторов и вносимых в них изменений осуществляется ФГУП "СТАНДАРТИНФОРМ" и техническим комитетом по общероссийским классификаторам.

 

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

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

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

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

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

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

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

 

1.2.               Международные организации, разрабатывающие стандарты.

 

Международная организация по стандартизации (ИСО).

 

Международная организация по стандартизации создана в 1946 г. двадцатью пятью национальными организациями по стандартизации. При создании организации и выборе ее названия учитывалась необходимость того, чтобы аббревиатура наименования звучала одинаково на всех языках. Для этого было решено использовать греческое слово «isos» — равный. Вот почему на всех языках мира Международная организация по стандартизации имеет краткое название ISO (ИСО).

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

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

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

 

Международная электротехническая комиссия (МЭК).

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

Объединенный технический комитет (JTC1)

В 1987 г. ИСО и МЭК объединили свою деятельность в области стандартизации информационных технологий (ИТ), создав единый орган JTC1 (Joint Technical Committee 1 — Объединенный технический комитет 1), предназначенный для формирования всеобъемлющей системы базовых стандартов в области ИТ и их расширений для конкретных сфер деятельности.

 

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

Работа над стандартами ИТ в JTC1 тематически распределена по подкомитетам (Subcommittees — SC). В дополнение создана специальная группа по функциональным стандартам (Special Group on Functional Standards — SGFS) для обработки предложений по международным стандартизованным профилям (International Standardized Profiles — ISPs), представляющим определения профилей ИТ.

Ниже перечислены подкомитеты и группы JTC1, связанные с разработкой стандартов ИТ, относящихся к окружению открытых систем (Open Systems Environment — OSE):

C2 — Символьные наборы и кодирование информации;

SC6 — Телекоммуникация и информационный обмен между системами;

SC7 — Разработка программного обеспечения и системная документация;

SC18 — Текстовые и офисные системы;

SC21 — Открытая распределенная обработка (Open Distributed Processing — ODP), управление данными (Data Management — DM) и взаимосвязь открытых систем (OSI);

SC22 — Языки программирования, их окружение и интерфейсы системного программного обеспечения;

SC24 — Компьютерная графика;

SC27 — Общие методы безопасности для ИТ-приложений;

SGFS — Специальная группа по функциональным стандартам,

 

1.4.  Национальные организации, разрабатывающие стандарты.

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

 

Это Федеральное агентство по техническому регулированию и метрологии  (РОССТАНДАРТ)  и  Американский национальный институт стандартов и технологии (ANSI).

 

Федеральное агентство по техническому регулированию и метрологии (РОССТАНДАРТ).

 

1991 г. Указом Президента Российской Федерации от 18 декабря № 304 Госстандарт РСФСР определен правопреемником Госстандарта СССР в области стандартизации, метрологии и сертификации на территории Российской Федерации.

 

1992 г. Указом Президента Российской Федерации от 30 сентября № 1148 Государственный комитет РСФСР по стандартизации, метрологии и сертификации реорганизован в Комитет Российской Федерации по стандартизации, метрологии и сертификации

 

1999 г. Постановлением Правительства Российской Федерации от 7 мая № 498 утверждено Положение о Государственном комитете Российской Федерации по стандартизации и метрологии. Данным документом определена сфера ведения Госстандарта России.

 

2004 г. Указом Президента Российской Федерации от 9 марта № 314 на базе Госстандарта России была создана Федеральная служба по техническому регулированию и метрологии.

 

2004 г. Указом Президента Российской Федерации от 20 мая № 649 Федеральная служба по техническому регулированию и метрологии преобразована в Федеральное агентство по техническому регулированию и метрологии (Ростехрегулирование).  Постановлением Правительства Российской Федерации от 9 июня 2010 г. № 408 краткое наименование Федерального агентства «Ростехрегулирование» заменено на «Росстандарт».

 

Федеральное агентство по техническому регулированию и метрологии (РОССТАНДАРТ) входит в систему федеральных органов исполнительной власти Российской Федерации и находится в ведении Министерства промышленности и торговли Российской Федерации.  Оно образовано в соответствии с Указом Президента Российской Федерации от 20 мая 2004 г. № 649 «Вопросы структуры федеральных органов исполнительной власти».

 

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

 

Федеральное агентство по техническому регулированию и метрологии ведет свою деятельность в соответствии с Положением, утвержденным постановлением Правительства Российской Федерации от 17 июня 2004 г. № 294.

 

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

 

Американский национальный институт стандартов (ANSI).

 

Американский национальный институт стандартов ANSI (American National Standards Institute)  – объединение американских промышленных и деловых групп, разрабатывающее торговые и коммуникационные стандарты. Входит в организации ISO и IEC, представляя там интересы США.

 

19 октября 1918 года был создан «Американский комитет инженерных стандартов» (AESC). В 1928 году комитет стал называться «Американской ассоциацией стандартов» (ASA), а после реорганизации 1966 года — «Институтом стандартов США» (USASI). Нынешнее имя принято в 1969 году. Членами ANSI являются американские корпорации, службы правительства, международные организации и частные лица. Официальный сайт ANSI (American National Standards Institute). 

 

Национальный институт стандартов и технологий США (NIST)

 

Национальный институт стандартов и технологий США NIST (National Institute of Standards and Technology) – подразделение Управления по технологиям США, одного из агентств Министерства торговли США.  С 1901 по 1988 годы назывался Национальное бюро стандартов США. Официальный сайт NIST (National Institute of Standards and Technology).

 

Миссия NIST «продвигать» инновационную и индустриальную конкурентоспособность США путём развития наук об измерениях, стандартизации и технологий с целью повышения экономической безопасности и улучшения качества жизни.

 

Национальный институт стандартов и технологии NIST (США), вместе с Американским национальным институтом стандартов (ANSI) участвует в разработке стандартов и спецификаций к программным решениям, используемым как в государственном секторе США, так и имеющим коммерческое применение.

 

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

 

С 1 марта 2012 года (взамен ГОСТ Р ИСО/МЭК 12207-99)  введен в действие национальный  стандарт  РФ ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств» (Утвержден  приказом Федерального агентства по техническому регулированию и метрологии от 30 ноября 2010 г. № 631-ст).

 

Стандарт ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств»  идентичен международному стандарту ISO/IEC 12207:2008 «System and software engineering — Software life cycle processes».

 

 

Стандарт ISO/IEC 12207 определил не только основные процессы ЖЦ разработки ПС, но и организационные и дополнительные процессы, которые регламентируют инженерию, планирования и управления качеством ПС.

 

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

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

 

Стандарт ISO/IEC 12207 определил не только основные процессы ЖЦ разработки ПС, но и организационные и дополнительные процессы, которые регламентируют инженерию, планирования и управления качеством ПС. Согласно этому стандарту на этапах ЖЦ должен проводиться контроль качества ПО:

 

- проверка соответствия требований проектируемому продукту и критериев их достижения;

 

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

 

- тестирование готовых ПС, сбор данных об отказах, дефектах и других ошибках, обнаруженных в системе;

 

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

 

1.4.               Основные аспекты качества ПО.

 

Формализации показателей качества программных средств посвящена группа нормативных документов.

 

Государственный стандарт РФ ГОСТ  Р   ИСО/МЭК   9126—93 « Информационная технология. ОЦЕНКА ПРОГРАММНОЙ  ПРОДУКЦИИ.  Характеристики качества и руководства по их применению» подготовлен на основе аутентичного текста международного стандарта ИСО/МЭК 9126—91 «Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению».

 

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

 

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

 

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

 

В стандарте ГОСТ  Р   ИСО/МЭК   9126—93 « Информационная технология. ОЦЕНКА ПРОГРАММНОЙ  ПРОДУКЦИИ.  Характеристики качества и руководства по их применению» применяются следующие термины.

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

 

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

Примечание. Примеры признаков включают длину маршрута, мо­дульность, структуру программы и комментарии.

 

Программно-аппаратные средства (firm­-ware)  - технические средства, содержащие    компьютерную программу и данные, которые не могут изменяться средствами пользователя.   Компьютерная программа и данные,   входящие в программно-аппаратные средства, классифицируются как программ­ное обеспечение; схемы, содержащие компьютерную программу и данные, классифицируются как технические средства.

 

Уровень качества функционирования  (level of performance)  - степень, в которой удовлетворяются потребности, представленные    конкретным набором значений для характе­ристик качества.

 

Измерение (measurement) - действие по применению показателя качества программного обеспечения к конкретной про-граммной продукции.

 

Качество (quality) - весь объем   признаков и характеристик продукции или услуги, который относится к их способности удовлетворять   установленным или предполагаемым потребностям (ИСО 8402).

 

Ранжирование  (рейтинг)  (rating) — действие по отнесению измеренного значения к соответствующему    уровню ран­жирования.   Используется для определения уровня ранжирования программного   обеспечения по конкретной   характеристике   качества.

 

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

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

 

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

 

Качество программного обеспечения (soft­ware quality) - весь объем признаков и характеристик программ­ной продукции, который относится к ее способности удовлетворять установленным или предполагаемым потребностям.

 

Критерий оценки  качества программного обеспечения (software  quality assessment criteria) -набор определенных и задокументированных правил и условий, которые используются для решения о приемлемости общего   качества конкретной  программной продукции.  Качество представляется набором установленных уровней, связанных   с   программной продук­цией.

 

Характеристики качества программного обеспечения  (software quality characteristics)  - набор свойств (атрибутов) программной продукции, по которым ее качество описывается и оценивается. Характеристики качества программно­го обеспечения могут быть уточнены на множестве уровней комплексных показателей (подхарактеристик).         

 

Метрика качества программного обеспечения (software quality metric) - количественный масштаб и  метод, которые могут быть использованы   для определения значе­ния признака, принятого для конкретной программной продукции.

 

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

 

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

 

В стандарте ГОСТ  Р   ИСО/МЭК   9126—93 « Информационная технология. ОЦЕНКА ПРОГРАММНОЙ  ПРОДУКЦИИ.  Характеристики качества и руководства по их применению» приведены следующие характеристики   качества  программного обеспечения.

КАЧЕСТВО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МОЖЕТ БЫТЬ ОЦЕНЕНО СЛЕ­ДУЮЩИМИ ХАРАКТЕРИСТИКАМИ.

Функциональные возможности (Functionality). Набор атрибутов, относящихся к сути    набора функций и их конкретным свойствам.    Функциями являются те, которые реали­зуют установленные или предполагаемые потребности:

Примечания.

1. Данный набор  атрибутов характеризует то, что  программное обеспечение
выполняет для удовлетворения потребностей, тогда как другие наборы, главным
образом, характеризуют, когда и как это выполняется.

2.  В данной характеристике для установленных и  предполагаемых потреб­ностей учитывают примечание к определению качества.

 

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

Примечания.

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

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

 

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

Примечания.

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

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

 

 

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

 

Примечание.  Ресурсы могут включать другие программные продукты, технические средства, материалы (например, бумага для печати, гибкие диски) и услуги эксплуатирующего, сопровождающего или обслуживающего персонала.

 

Сопровождаемость (Maintainability).  Набор атрибутов, относящихся к объему работ, требуемых для проведения конкретных изменений (модификаций).

 

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

 

Мобильность (Portability). Набор атрибутов, относящихся к способности программного обеспечения быть перенесенным из одного окружения в другое.

 

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

 

 

Модель качества ПО  имеет следующие четыре уровня представления.

 

Первый уровень соответствует определению характеристик (показателей) качества ПО, каждая из которых отражает отдельную точку зрения пользователя на качество.

 

Согласно стандарту в модель качества входит шесть характеристик или шесть показателей качества:

1. функциональность (functionality);
2. надежность (realibility);
3. практичность (удобство) (usability);
4. эффективность (efficiency);
5. сопровождаемость (maitainnability);
6. мобильность (переносимость) (portability).

 

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

 

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

 

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

 

Выбранные атрибуты и их приоритеты отражаются в требованиях на разработку систем либо используется соответствующие приоритеты эталона класса ПО, к которому это ПО относится.

 

ФУНКЦИОНАЛЬНОСТЬ - совокупность свойств, определяющих способность ПО выполнять перечень функций в заданной среде и в соответствии с требованиями к обработке и общесистемным средствам. Под функцией понимается некоторая упорядоченная последовательность действий для удовлетворения потребительских свойств. Функции бывают целевые (основные) и вспомогательные.

 

К атрибутам функциональности относятся:

 

функциональная полнота - свойство компонента, которое показывает степень достаточности основных функций для решения задач в соответствии с назначением ПО;

правильность (точность) - атрибут, который показывает степень достижения правильных результатов;

 

интероперабельность - атрибут, который показывает возможность взаимодействовать на ПО специальными системами и средами (ОС, сеть);

 

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

 

НАДЕЖНОСТЬ - совокупность атрибутов, которые определяют способность ПО преобразовывать исходные данные в результаты при условиях, зависящих от периода времени жизни (износ и его старение не учитываются). Снижение надежности ПО происходит из-за ошибок в требованиях, проектировании и выполнении. Отказы и ошибки в программах появляются на заданном промежутке времени.

 

К подхарактеристикам надежности ПО относятся:

 

безотказность - атрибут, который определяет способность ПО функционировать без отказов (как программы, так и оборудования);

 

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

 

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

 

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

 

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

 

К факторам, влияющим на надежность ПО, относятся:

 

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

 

- угроза как проявление нарушения безопасности системы;

 

- целостность как способность системы сохранять устойчивость работы и не иметь риска.

 

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

 

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

 

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

 

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

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

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

 

Новое направление - инженерия программной надежности (Software reliability engineering) - ориентировано на количественное изучение операционного поведения компонентов системы по отношению к пользователю, ожидающему надежную работу системы,  и включает:

 

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

 

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

 

- применение современных методов инспектирования, верификации, валидации  тестирования при разработке систем, а также при эксплуатации.

 

Верификация применяется для определения соответствия готового ПО установленным спецификациям, а валидация - для установления соответствия системы требованиям пользователя, которые были предъявлены заказчиком.

 

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

 

- готовность к использованию (availability);

 

- готовностью к непрерывному функционированию (reliability);

 

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

 

- секретность и сохранность информации (сonfidential);

 

- способность к сохранению системы и устойчивости к самопроизвольному ее изменению (integrity);

 

- способность к эксплуатации ПО, простота выполнения операций обслуживания, а также устранения ошибок, восстановление системы после их устранения и т.п. (maintainability);

 

- готовность и сохранность информации (security) и др.

 

Достижение надежности системы обеспечивается предотвращением отказа (fault prevention), его устранением (removal fault), а также оценкой возможности появления новых отказов и мер борьбы с ними с применением методов теории вероятности.

 

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

 

 

УДОБСТВО ПРИМЕНЕНИЯ  характеризуется множеством атрибутов, которые показывают на необходимые и пригодные условия использования (диалоговое или не диалоговое) ПО заданным кругом пользователей для получения соответствующих результатов.

 

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

 

К подхарактеристиками удобства применения относятся:

 

понимаемость - атрибут, который определяет усилия, затрачиваемые на распознавание логических концепций и условий применения ПО;

 

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

 

оперативность - атрибут, который показывает на реакцию системы при выполнении операций и операционного контроля;

 

согласованность - атрибут, который показывает соответствие разработки требованиям стандартов, соглашений, правил, законов и предписаний.

 

ЭФФЕКТИВНОСТЬ - множество атрибутов, которые определяют взаимосвязь уровней выполнения ПО, использования ресурсов (средства, аппаратура, материалы - бумага для печатающего устройства и др.) и услуг, выполняемых штатным обслуживающим персоналом и др.

 

К подхарактеристикам эффективности ПО относятся:

 

реактивность - атрибут, который показывает время отклика, обработки и выполнения функций;

 

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

 

согласованность - атрибут, который показывает соответствие данного атрибута с заданными стандартами, правилами и предписаниями.

 

СОПРОВОЖДАЕМОСТЬ - множество свойств, которые показывают на усилия, которые надо затратить на проведение модификаций, включающих корректировку, усовершенствование и адаптацию ПО при изменении среды, требований или функциональных спецификаций.

 

Cопровождаемость включает подхарактеристики:

 

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

 

изменяемость - атрибут, который определяет удаление ошибок в ПО или внесение изменений для их устранения, а также введение новых возможностей в ПО или в среду функционирования;

 

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

 

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

 

согласованность - атрибут, который показывает соответствие данного атрибута соглашениям, правилам и предписаниям стандарта.

 

ПЕРЕНОСИМОСТЬ (мобильность)  - множество показателей, указывающих на способность ПО адаптироваться к работе в новых условиях среды выполнения. Среда может быть организационной, аппаратной и программной. Поэтому перенос ПО в новую среду выполнения может быть связан с совокупностью действий, направленных на обеспечение его функционирования в среде, отличной от той среды, в которой оно создавалось с учетом новых программных, организационных и технических возможностей.

 

Переносимость (мобильность) включает подхарактеристики:

 

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

 

настраиваемость (простота инсталляции) - атрибут, который определяет необходимые усилия для запуска данного ПО в специальной среде;

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

 

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

 

согласованность - атрибут, который показывает на соответствие стандартам или соглашениями по обеспечению переноса ПО.

 

2. ОЦЕНКА КАЧЕСТВА СОЗДАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

 

2.1. Качество программного обеспечения.

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

2.2. Принципы менеджмента качества.

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

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

1. Ориентация на потребителя.  Организации зависят от своих потребителей и поэтому должны понимать их текущие и будущие потребности, выполнять их требования и стремиться превзойти их ожидания.
3. Лидерство руководителя.  Руководители обеспечивают единство цели и направления деятельности организации. Им следует создавать и поддерживать внутреннюю среду, в которой работники могут быть полностью вовлечены в решение задач организации.
5. Вовлечение работников.  Работники всех уровней составляют основу организации, поэтому их полное вовлечение в решение задач дает возможность организации с выгодой использовать их способности.
7. Процессный подход.  Желаемый результат достигается эффективнее, когда деятельностью и соответствующими ресурсами управляют как процессом.
9. Системный подход к менеджменту.  Выявление, понимание и менеджмент взаимосвязанных процессов как системы содействуют повышению результативности и эффективности организации при достижении ее целей.
11. Постоянное улучшение.  Постоянное улучшение деятельности организации в целом следует рассматривать как ее неизменную цель.
13. Принятие решений, основанное на фактах.  Эффективные решения должны основываться на анализе данных и информации.
15. Взаимовыгодные отношения с поставщиками.  Организация и ее поставщики взаимозависимы, поэтому отношения взаимной выгоды повышают способность обеих сторон создавать ценности.

Эти восемь принципов менеджмента качества были взяты за основу при разработке стандартов на системы менеджмента качества, входящих в семейство стандартов ISO 9000.

 

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

- ISO 9000 описывает основные положения систем менеджмента качества и устанавливает терминологию для систем менеджмента качества;

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

- ISO 9004 содержит рекомендации по повышению результативности и эффективности системы менеджмента качества и предназначен для улучшения деятельности организации и повышения удовлетворенности потребителей и других заинтересованных сторон;

ISO 19011 содержит методические указания по проведению аудита (проверки) систем менеджмента качества и охраны окружающей среды.

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

Кратко охарактеризуем некоторые из стандартов семейства ISO 9000.

 

Межгосударственный стандарт ГОСТ ISO 9000-2011. СИСТЕМЫ МЕНЕДЖМЕНТА КАЧЕСТВА.  Основные положения и словарь.

Межгосударственный стандарт ГОСТ ISO 9000-2011 «Системы менеджмента качества. Основные положения и словарь»  введен в действие в качестве национального стандарта Российской Федерации с 1 января 2013 года. Настоящий стандарт идентичен международному стандарту ISO 9000:2005 «Quality management systems. Fundamentals and vocabulary».   

 

Межгосударственный стандарт ГОСТ ISO 9000-2011 «Системы менеджмента качества. Основные положения и словарь» устанавливает основные положения систем менеджмента качества, являющихся объектом стандартов семейства ISO 9000, и определяет соответствующие термины.

Одним из основных положений  систем менеджмента качества является ПРОЦЕССНЫЙ ПОДХОД.

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

Назначение настоящего стандарта — побуждать к принятию процессного подхода к менеджменту организации.

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

Рисунок 1. Модель системы менеджмента качества, основанной на процессном подходе.

 

Межгосударственный стандарт ГОСТ ISO 9001–2011 «Системы менеджмента качества. Требования» введен  в действие в качестве национального стандарта Российской Федерации с 1 января 2013 года. Настоящий стандарт идентичен международному стандарту ISO 9001:2008 «Quality management systems — Requirements».

 

При разработке настоящего стандарта были учтены принципы менеджмента качества, установленные ISO 9000 и ISO 9004.

 

Межгосударственный стандарт ГОСТ ISO 9001–2011 «Системы менеджмента качества. Требования» направлен на применение «процессного подхода» при разработке, внедрении и улучшении результативности системы менеджмента качества в целях повышения удовлетворенности потребителей путем выполнения их требований.

Рисунок 2. Модель системы менеджмента качества, основанной на процессном подходе

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

Примечание.  Кроме того, ко всем процессам может быть применен цикл «Plan — Do — Check — Act» (PDCA). Цикл PDCA можно кратко описать так:

- планирование (plan) — разработка целей и процессов, необходимых для достижения результатов в соответствии с требованиями потребителей и политикой организации;

- осуществление (do) — внедрение процессов;

- проверка (check) — постоянные контроль и измерение процессов и продукции в сравнении с политикой, целями и требованиями на продукцию и сообщение о результатах;

- действие (act) — принятие действий по постоянному улучшению показателей процессов.

 

 

ISO 9001 и ISO 9004 являются стандартами на системы менеджмента качества, которые дополняют друг друга, но их можно применять также независимо.

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

Семейство стандартов ISO 9000 проводит различие между требованиями к системам менеджмента качества и требованиями к продукции.

Требования к системам менеджмента качества установлены в ISO 9001 и являются общими и применимыми к организациям в любых секторах промышленности или экономики независимо от категории продукции. ISO 9001 не устанавливает требований к продукции.

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

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

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

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

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

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

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

Современная техника управления качеством (например, концепция Total Quality Management (TQM)) базируется именно на управлении качеством. На современном этапе уже недостаточно иметь только методы оценки качества произведенного и используемого программного средства (выходной контроль), необходимо иметь возможность планировать качество, измерять его на всех этапах жизненного цикла программного средства и корректировать процесс производства программного обеспечения для улучшения качества.

 

Международные стандарты серии ISO 9000 регламентируют создание системы управления качеством. Однако они являются общими, лишь рекомендательными. Каждая компания, производящая программное обеспечение и желающая внедрить у себя действенную систему управления качеством на основе стандартов ISO 9000-й серии, должна учесть специфику своей отрасли и разработать систему показателей качества, которая бы отражала реальное влияние факторов качества на программный продукт.

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

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

 

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

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

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

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

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

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

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

МЕРОПРИЯТИЯ, ОБЕСПЕЧИВАЮЩИЕ ПРИЕМЛЕМЫЙ УРОВЕНЬ КАЧЕСТВА ПРОГРАММНОГО СРЕДСТВА, МОЖНО УСЛОВНО РАЗДЕЛИТЬ НА АДМИНИСТРАТИВНЫЕ И ТЕХНОЛОГИЧЕСКИЕ.

 

К административным можно отнести следующие мероприятия.

1. Проведение обучения персонала, переподготовки.

2. Тщательное документирование всех изменений в структуре программного средства. Для этого используются средства поддержки версионности.

3. Назначение ответственных лиц за каждую доработку программного средства.

4. Уделение внимания текущему контролю качества и заключительному контролю качества.

5. Обеспечение мониторинга качества, например, фиксирование ошибок, поступивших от пользователя программного средства. Использование систематических испытательных методов, где испытания будут разработаны параллельно с разработкой программы.

6. Введение внутренних стандартов. Такие стандарты обычно содержат соглашения о именовании переменных в программном коде, наименовании файлов данных, процедур и функций.

7. Организация отдела тестирования как самостоятельного подразделения.

8. Проведение совместных аттестаций с пользователем.

9. Обращение внимания на уровень и простоту обслуживаемости программного обеспечения. Здесь речь идет как о решении проблем, возникших у пользователя, так и о простоте и надежности внесения изменений в программное обеспечение. Даже если очень надежный кусок программного обеспечения был разработан, он может вскоре стать ненадежным, если сложно сделать изменения в программе. Часто изменения должны быть выполнены вследствие новых потребностей внешней среды, например вследствие изменений в законодательстве или требований заказчика.

К технологическим относятся следующие мероприятия.

1. Выбор стандарта качества и четкое следование ему на всех этапах. Создание модели проекта с регулярными проверками, которые будут выполняться независимыми командами экспертизы. Такая модель может быть построена, например, на основе стандартов качества (например, ISO 9000).

 

2. Единая среда разработки. Лучшие результаты дают программные продукты разработки, которые поддерживают несколько или все этапы жизненного цикла программного обеспечения.

3. Использовать формальный язык спецификаций.

4. Выбор надежной СУБД (если программное средство работает с массивами информации и использование СУБД оправдано).

5. Тщательное тестирование программного обеспечения.

6. Широкое внедрение автоматизации тестирования.

7. Использование полностью проверенной программной среды окружения (ОС) и языка программирования, которые минимизируют опасность внесения ошибки.

8. Использование статистических методов для сбора информации о качестве ПС.

9. Изучение результатов испытаний (тестов) и ошибок для использования в постоянном усовершенствовании программы.

Источник в случае возникновения отказа должен быть найден и устранен. Недостаточно найти ошибку в программном обеспечении и исправить ее. Изменения должны быть сделаны в процессе разработки ПО.

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

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

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

 

3. МЕТРИКИ КАЧЕСТВА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

 

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

 

Система измерения включает метрики и модели измерений, которые используются для количественной оценки качества ПО.

 

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

 

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

 

Остановимся на классификации метрик ПО,  правилах для проведения метрического анализа и процесса их измерения.

 

3.1.               Типы метрик.

 

Существует три типа метрик:

 

метрики программного продукта, которые используются при измерении его характеристик - свойств;

 

метрики процесса, которые используются при измерении свойства процесса ЖЦ создания продукта.

 

метрики использования.

 

 

МЕТРИКИ ПРОГРАММНОГО ПРОДУКТА включают:

 

- внешние метрики, обозначающие свойства продукта, видимые пользователю;

 

- внутренние метрики, обозначающие свойства, видимые только команде разработчиков.

 

 

ВНЕШНИЕ МЕТРИКИ ПРОДУКТА - это метрики:

 

- надежности продукта, которые служат для определения числа дефектов;

 

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

 

- сопровождения, с помощью которых измеряются ресурсы продукта (скорость, память, среда);

 

- применимости продукта, которые способствуют определению степени доступности для изучения и использования;

 

- стоимости, которыми определяется стоимость созданного продукта.

 

ВНУТРЕННИЕ МЕТРИКИ ПРОДУКТА включают:

 

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

 

- метрики сложности, необходимые для определения сложности продукта;

 

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

 

Внутренние метрики позволяют определить производительность продукта и являются релевантными по отношению к внешним метрикам.

 

Внешние и внутренние метрики задаются на этапе формирования требований к ПО и являются предметом планирования и управления достижением качества конечного программного продукта.

 

Метрики продукта часто описываются комплексом моделей для установки различных свойств, значений модели качества или прогнозирования.  Измерения проводятся, как правило, после калибровки метрик на ранних этапах проекта.

 

Стандарт ISO/IEC 9126-2 определяет следующие типы мер:

 

- мера размера ПО в разных единицах измерения (число функций, строк в программе, размер дисковой памяти и др.);

 

- мера времени (функционирования системы, выполнения компонента и др.);

 

- мера усилий (производительность труда, трудоемкость и др.);

 

- мера учета (количество ошибок, число отказов, ответов системы и др.).

 

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

 

ПРИМЕРЫ МЕТРИК.

 

1)   общее число объектов и число повторно используемых;

2)   общее число операций, повторно используемых и новых операций;

3)   число классов, наследующих специфические операции;

4)   число классов, от которых зависит данный класс;

5)   число пользователей класса или операций и др.

 

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

 

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

 

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

 

В качестве МЕТРИК ПРОЦЕССА могут быть время разработки, число ошибок, найденных на этапе тестирования и др.

 

Практически используются следующие МЕТРИКИ ПРОЦЕССА:

 

- общее время разработки и отдельно время для каждой стадии;

 

- время модификации моделей;

 

- время выполнения работ на процессе;

 

- число найденных ошибок при инспектировании;

 

- стоимость проверки качества;

 

- стоимость процесса разработки.

 

МЕТРИКИ ИСПОЛЬЗОВАНИЯ служат для измерения степени удовлетворения потребностей пользователя при решении его задач. Они помогают оценить не свойства самой программы, а результаты ее эксплуатации - эксплуатационное качество.

 

Примером метрики использования может служить:

 

- точность и полнота реализации задач пользователя, а также затраченные ресурсы (трудозатраты, производительность и др.) на эффективное решение задач пользователя.

 

Оценка требований пользователя проводится с помощью внешних метрик.

 

3.2.                Стандартная оценка значений показателей качества.

 

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

 

По определению стандарта ISO/IES 9126-2 метрика качества ПО представляет собой «МОДЕЛЬ ИЗМЕРЕНИЯ АТРИБУТА, СВЯЗЫВАЕМОГО С ПОКАЗАТЕЛЕМ ЕГО КАЧЕСТВА».

 

При измерении показателей качества данный стандарт позволяет определять следующие типы мер:

 

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

 

меры времени - периоды реального, процессорного или календарного времени (время функционирования системы, время выполнения компонента, время использования и др.);

 

меры усилий - продуктивное время, затраченное на реализацию проекта (производительность труда отдельных участников проекта, коллективная трудоемкость и др.);

 

меры интервалов между событиями, например, время между последовательными отказами;

 

счетные меры - счетчики для определения количества обнаруженных ошибок, структурной сложности программы, числа несовместимых элементов, числа изменений (например, число обнаруженных отказов и др.).

 

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

 

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

 

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

 

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

 

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

 

Все метрики  -атрибута суммируются и образуют  -показатель качества.

 

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

 

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

 

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

 

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

 

Регистрационный метод используется при подсчете времени, числа сбоев или отказов, начала и конца работы ПО в процессе его выполнения.

 

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

 

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

 

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

 

- шкала метрическая (1.1 - абсолютная, 1.2 - относительная, 1.3 - интегральная);

 

- шкала порядковая (ранговая), позволяющая ранжировать характеристики путем сравнения с опорными;

 

- классификационная шкала, характеризующая наличие или отсутствие рассматриваемого свойства у оцениваемого программного обеспечения.

 

Показатели, которые вычисляются с помощью метрических шкал, называются количественные, а определяемые с помощью порядковых и классификационных шкал - качественные.

 

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

 

Для правильного использования результатов измерений каждая мера идентифицируется шкалой измерений.

 

Стандарт ISO/IES 9126-2 рекомендует применять 5 видов шкал измерения значений, которые упорядочены от менее строгой к более строгой:

 

номинальная шкала отражает категории свойств оцениваемого объекта без их упорядочения;

 

порядковая шкала служит для упорядочивания характеристики по возрастанию или убыванию путем сравнения их с базовыми значениями;

 

интервальная шкала задает существенные свойства объекта (например, календарная дата);

 

относительная шкала задает некоторое значение относительно выбранной единицы;

 

абсолютная шкала указывает на фактическое значение величины (например, число ошибок в программе равно 10).

 

3.3.               Методы сертификации качества программного обеспечения.

 

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

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

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

 

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

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

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

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

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

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

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

 

СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ.

 

[1] Благодатских В.А., Волнин В.А., Поскакалов К.Ф. Стандартизация разработки программных средств. Учебное пособие /Под ред. О.С. Разумова. М.: Финансы и статистика, 2005. – 288 с., ил.

 

[2] Брауде Э. Технология разработки программного обеспечения. СПб.: Питер, 2004. – 655 с.: ил.

[3] Вигерс К. Разработка требований к программному обеспечению /Пер. с англ. – М.: ИТД «Русская Редакция», 2004. – 576.: ил. 

 

[4] Гагарина Л.Г., Кокорева Е.В., Виснадул Б.Д. Технология разработки программного обеспечения. Учебное пособие /Под ред. Л.Г. Гагариной. – М.: ИД «Форум»: ИНФРА-М, 2008. – 400 с.: ил. – (Высшее образование).

 

[5] Котов С.Л., Палюх Б.В., Федченко С.Л. Разработка, стандартизация и сертификация программных средств и информационных технологий и систем. Учебное пособие. Тверь.: ТГТУ, 2006. – 104 с.