Что такое гарантийный случай для программного продукта

ГОСТ Р ИСО/МЭК 15026-1-2016
Системная и программная инженерия. Гарантирование систем и программного обеспечения. Часть 1. Понятия и словарь

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

Идентичен ISO/IEC 15026-1:2013

Дата введения	01.06.2017
Добавлен в базу	01.02.2017
Актуализация	01.01.2021

26.04.2016	Утвержден	Федеральное агентство по техническому регулированию и метрологии	291-ст
Разработан	ООО ИАВЦ
Издан	Стандартинформ	2016 г.

ГОСТ Р исо/мэк

15026-1—

СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ

Гарантирование систем и программного обеспечения

Понятия и словарь

(ISO/IEC 15026-1:2013, ЮТ)

Предисловие

1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ) на основе собственного перевода на русский язык англоязычной версии международного стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 26 апреля 2016 г. №281-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 15026-1:2013 «Системная и программная инженерия. Гарантирование систем и программного обеспечения. Часть 1. Понятия и словарь» (ISO/IEC 15026-1:2013 «Systems and software engineering — Systems and software assurance — Part 1: Concepts and vocabulary», IDT).

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

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

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

ГОСТ Р ИСО/МЭК 15026-1—2016

5.5.1 Свойства как поведение

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

— ограничение на разрешенные состояния системы (иногда называемое «свойством безопасности»);

— состояния системы, которые должны быть достигнуты и требуют прогресса или завершения («свойство живучести»);

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

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

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

5.6 Неопределенность и уверенность

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

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

5.7 Условия и инициирующие события

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

Исторически сложилось так, что одним из условий, считающимся самым важным, является системный отказ. Системному отказу посвящено множество инструкций, практик и публикаций (например, [2], [71] и [14, глава 18, с. 475—524]).Несмотря на то что преимущественно эти разработки были сделаны в сообществах, занимающихся безопасностью, защитой или человеческими ошибками, системный отказ может привести к снижению достижения положительного свойства или последствиям, а также может стать причиной отрицательных свойств или убытков.

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

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

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

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

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

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

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

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

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

В нескольких стандартах и отчетах рассматриваются последствия, относящиеся к системам в определенных предметных областях. Такими стандартами являются ИСО 14620 [79], ИСО 19706 [81] и ИСО/ТС 25238 [121]. Кроме того, в стандартах менеджмента рисков также рассматриваются последствия, например в ИСО/МЭК 16085 [91] и ИСО 31000.

6 Применение нескольких частей ИСО/МЭК 15026

ИСО/МЭК 15026 или его части могут использоваться сами по себе либо совместно с другими стандартами или руководствами. Части ИСО/МЭК 15026 могут быть распространены на большинство стандартов жизненного цикла, и в них можно использовать любой из наборов строго определенных качеств или свойств.

6.2 Начальное руководство по использованию

При использовании ИСО/МЭК 15026 выбор свойств и/или требований полностью лежит на пользователе стандарта в соответствии с потребностями и требованиями заинтересованных сторон системы. Для гарантийного случая может быть выбрано любое свойство или любое требование независимо от его важности или связанногос ним риска. Однако ИСО/МЭК 15026ориентирован прежде всего на свойства, которые считаются критически важными с точки зрения одной или нескольких основных заинтересованных сторон. В ИСО/МЭК 15026-4 термин «критические свойства» используется именно для таких приоритетов и требований заинтересованной стороны.

В то время как ИСО/МЭК 15026-3 в общем случае совместим «сверху вниз» с ИСО/МЭК 15026:1998, переход к ИСО/МЭК 15026-3 имеет некоторые особенности. ИСО/МЭК 15026-3 открывает новые возможности инженерии и принятия решений, так как он дает не только автономную концепцию, но также и ту, в которую включены соответствующие гарантийному случаю уровни целостности. ИСО/МЭК 15026-3 концентрируется больше на самой системе и ее уровнях целостности, а не на внешнем анализе рисков. Кроме того, в нем также рассмотрено создание уровней целостности. Уровни целостности рассмотрены в разделе 8 настоящего стандарта.

ГОСТ Р ИСО/МЭК 15026-1—2016

6.3 Взаимосвязь частей ИСО/МЭК 15026

ИСО/МЭК 15026 состоит из следующих частей:

— ИСО/МЭК 15026-1 «Понятия и словарь», в которой объясняются понятия и термины, базисные для всех частей этого стандарта;

— ИСО/МЭК 15026-2 «Гарантийный случай», в которой рассмотрены требования к содержанию и структуре гарантийного случая;

— ИСО/МЭК 15026-3 «Уровни целостности системы», которая связывает уровни целостности с гарантийным случаем и включает в себя требования использования уровней целостности с гарантийным случаем и без него (пересмотр ИСО/МЭК 15026:1998);

ИСО/МЭК 15026-4 «Гарантии жизненного цикла», в которой приводятся указания и рекомендации по конкретным, связанным с гарантией действиям для всех процессов жизненного цикла систем и программного обеспечения.

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

Гарантийный случай в большей или меньшей степени рассматривается во всех частях, однако в ИСО/МЭК 15026-4 обсуждаются достижение выполнения требований, свидетельство выполнения требований и то, содержит ли артефакт, называемый «гарантийным случаем», такое свидетельство.

ИСО/МЭК 15026-2 концентрируется на содержании и структуре гарантийного случая. ИСО/МЭК 15026-3 связывает уровни целостности и гарантийные случаи. В ней описано, как уровни целостности и гарантийные случаи могут взаимодействовать, особенно при определении спецификаций для уровней целостности или при использовании уровней целостности в пределах области гарантийного случая. Эта взаимосвязь определяется уровнем риска и зависимостями в системе.

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

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

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

6.4 Ответственные

Во всехчастях ИСО/МЭК 15026 используется термин «ответственный», определенный в разделе 3 «Термины и определения» настоящего стандарта. Например, в ИСО/МЭК 15026-3 входит заключение соглашения между ответственным проектировщиком и ответственным за обеспечение целостности. Кроме того, для новой системы нужен ответственный за приобретение, который возьмет на себя ответственность за анализ процесса создания гарантийных случаев совместно с ответственным проектировщиком и ответственным за обеспечение целостности со стороны поставщика.

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

7 ИСО/МЭК 15026 и гарантийный случай

ИСО/МЭК 15026-2 раскрывает структуру и содержание гарантийного случая. Здесь описаны пять основных компонентов гарантийного случая: требования, параметры, доказательство, обоснования и предположения. Цель гарантийного случая состоит в улучшении обратной связи с заинтересованной стороной, обеспечив ее информацией, необходимой для принятия решений, и предоставив обоснование для необходимой уверенности заинтересованной стороны. В общем случае гарантийный случай должен предоставить гарантию свойств системы сторонам, не вовлеченным тесно в процессы технического развития системы. Такими сторонами могут быть стороны, привлеченные для сертификации системы, ее настройки, приобретения или аудита. Как правило, гарантийный случай рассматривает причины ожидания и подтверждения успешного изготовления системы, а также возможности и риски, идентифицированные как трудности или препятствия при разработке и поддержке этой системы.

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

Примечание — В случае если требования верхнего уровня относятся к безопасности, защищенности, надежности или RAM (надежность, готовность и сопровождаемость), то гарантийные случаи, связанные с этими требованиями, называют случаями безопасности, случаями защищенности, случаями надежности или случаями RAM соответственно. См. элемент «Библиография»: [139], [142], [143], [146], [154], [155], [168], [74], [22], [23], [24].

Гарантийный случай, рассматриваемый как артефакт, наделен такими относящимися к качеству аспектами, как природа содержания, его форма или структура (например, метод аргументации или модульности), семантическими аспектами, такими как полнота, создание и обслуживание, включая поддержку инструментальных средств, удобство использования и презентабельность, целостность, законность, понятность и наличие четких заключений с явными степенями неопределенности. В одной из статей [164] приведен достаточно полный перечень относящихся к качеству характеристик для гарантийных случаев. Относящиеся к качеству аспекты гарантийного случая не покрываются ни ИСО/МЭК 15026-2, ни другими частями ИСО/МЭК 15026.

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

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

1) требуемые ограничения на последствия;

2) функциональность и свойства самой системы (например, требования обязательности функциональности).

Показатели качества, определенные в ряде стандартов серии ИСО/МЭК 25000, включают в себя также показатели качества, связанные с функциональностью и ограничениями. С обеих точек зрения интерес представляет работа «Общие Критерии v.3.1 Пересмотр 2» [30].

7.2 Обоснование метода доказательства

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

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

ГОСТ Р ИСО/МЭК 15026-1—2016

В методы доказательств входят: количественные:

— детерминированные (например, формальные доказательства);

— недетерминированные формальные системы доказательства:

b) теоретико-игровые (например, минимакс),

c) другие основанные на неопределенности формальные системы доказательств (например, нечеткие множества);

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

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

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

7.3 Средства получения доказательств и управления ими

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

Доказательная база может стать довольно большой, быть организованной и управляться некоторой структурой, обеспечивающей неизменность и отслеживаемость доказательства, для того чтобы обеспечить пользователю уверенность в ее источнике, содержании и правильности. В источнике [150] указано следующее:

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

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

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

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

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

7.4 Сертификации и аккредитации

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

Авиационная и атомная промышленность имеют длинную историю стандартов и сертификаций, а сообщество безопасности в подкомитете ИСО/МЭКСТК 1/Подкомитет 27 работало над темой гарантии на протяжении многих лет. Базой для сертификации операционных систем системы менеджмента информационной безопасности (ISMS) являются: Общие Критерии, FIPS 140 для криптологии, ИСО/МЭК27002 «Информационные технологии. Свод правил для менеджмента информационной безопасности» в сочетании с ИСО/МЭК 27001 (ранее британский стандарт BS 7799-2:2002). Министерство обороны Великобритании и Управление гражданской авиации также разработали эффективные стандарты, включая рассматривающие гарантийные случаи стандарты для надежности, сопровождаемости и безопасности, например [139], [142], [143], [22] и [23]. В библиографии указаны и другие стандарты.

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

8 ИСО/МЭК 15026 и уровни целостности

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

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

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

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

Примечание — Уровни целостности и связанные с ними стандарты, особенно в области безопасности, имеют богатую историю. Уровни целостности в стандартах, связанныхс безопасностью, определены в виде многоуровневых наборов, относящихся к различным степеням строгости и/или неопределенности в их достижении более высоких уровней, обеспечивающих более высокую строгость и более низкую неопределенность. В качестве примера можно рассмотреть стандарт безопасности МЭК 61508 «Функциональная безопасность электрических/элек-тронных/программируемых электронных связанных с безопасностью систем» [70]. В других источниках подобные схемы используются в рамках другой терминологии, например «классы соответствия».

8.2 Анализ рисков

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

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

Например, МЭК 61508 [70] и МЭК 31010, редакция 1.0 (2009-11-27) «Менеджмент рисков. Методы менеджмента рисков», описывают подходы канализу рисков. В МЭК 300-3-9 используется специфичная

ГОСТ Р ИСО/МЭК 15026-1—2016

для безопасности терминология, поэтому термины «опасность» (hazard)n «вред» (harm) должны быть интерпретированы как «опасное условие» (dangerous condition) и «негативное последствие» (adverse consequence) соответственно. Общее представление дается и в МЭК 60300 «Менеджмент надежности» [64].

Другие специализированные стандарты и документы применимы в различных областях: ИС0 13849 [78] — для машинного оборудования, ИС014620 [79] — в космических системах, ИС019706 [81] — в пожарном деле, ИСО/ТС 25238 [121] — в медицинской информатике, ИСО/МЭК27005[1Ю] — в области информационной безопасности, UK САР 760760 [24] — на воздушном транспорте и в аэропортах. Возможный интерес могут представить более общие стандарты менеджмента рисков ИСО/МЭК 16085[91] и ИСО 31000.

9 ИСО/МЭК 15026 и жизненный цикл

9.1 Введение

ИСО/МЭК 15026-4 «Гарантии жизненного цикла» представляет процессы для гарантирования систем и программного обеспечения в виде информации о целях и результатах, подходящих для целей гарантирования систем и программного обеспечения. Понятие представления процесса сформулировано и описано в приложении к стандарту ИСО/МЭК 15288 «Системная и программная инженерия. Процессы жизненного цикла систем». Описание представления процесса содержит информацию о целях и результатах процесса. В отличие от самого процесса описание представления процесса не включает в себя действия и задачи. Вместо этого описание содержит руководство и рекомендации, объясняющие, каким образом могут быть достигнуты результаты с использованием действий и задач различных процессов, описанных в ИСО/МЭК 15288 и ИСО/МЭК 12207 «Системная и программная инженерия. Процессы жизненного цикла программного обеспечения».

В ИСО/МЭК 15288 и ИСО/МЭК 12207описаны все процессы жизненного цикла, несмотря на то, что в ИСО/МЭК 12207 процессы специализированы к программному обеспечению и, в некоторых случаях, имеют отличные наименования, отражающие такую специализацию. В ИСО/МЭК 12207 входят процессы, не включенные в ИСО/МЭК 15288, связанный с процессами реализации программного обеспечения: процессы поддержки и процессы повторного использования.

Все процессы, действия, задачи, методические материалы и рекомендации должны быть представлены в контексте модели жизненного цикла. Состоящий из нескольких частей технический отчет ИСО/МЭК ТО 24748 «Системная и программная инженерия. Менеджмент жизненного цикла» предназначен для того, чтобы упростить для описания процесса совместное использование содержания двух стандартов процесса жизненного цикла. ИСО/МЭК ТО 24748 обеспечивает объединенное и консолидированное руководство по менеджменту жизненного цикла систем и программного обеспечения. Его цель состоит в том, чтобы обеспечить непротиворечивость в концепциях системы и понятиях жизненного цикла, моделях, этапах, процессах, приложениях процесса, итерации и рекурсии процессов во время жизненного цикла, ключевых понятиях представления, адаптации и использовании в различных областях. ИСО/МЭК 24748-1 показывает применение модели жизненного цикла для систем в контексте ИСО/МЭК 15288 и приводит соответствующий пример использования модели жизненного цикла для программного обеспечения в контексте ИСО/МЭК 12207.

ИСО/МЭК 15026-4 дает пользователю свободу выбора: использовать ли специфический артефакт, называемый «гарантийный случай», или оформить относящуюся к гарантии информацию в виде иного документа. Суть заключается в удовлетворении требований верхнего уровня и последующем доказательстве удовлетворения требования к значению критического для соответствующей заинтересованной стороны свойства. Необходимо, чтобы процессы жизненного цикла, действия и задачи отражали как реализацию надлежащей системы, так и уверенность в том, что система соответствует доказательству достижения уровня уверенности, требуемого заинтересованными сторонами.

Пользователям ИСО/МЭК 15026-4 могут потребоваться оценка степени риска и менеджмент рисков, измерения и требования к процессам, разработанные более досконально, чем это предоставлено в ИСО/МЭК 15288 и ИСО/МЭК 12207. Для обеспечения большего числа деталей этих трех процессов совместно со стандартами ИСО/МЭК 15288 и ИСО/МЭК 12207 можно использовать три международных стандарта: ИСО/МЭК 16085 «Менеджмент рисков», ИСО/МЭК 15939 «Измерение» и

ИСО/МЭК/ИИЭР 29148 «Инженерия требований». Другими стандартами, в которых представлены полезные требования и методические материалы по специфическим процессам, является ИСО/МЭК/ИИЭР 15289 для документирования результатов выполнения процессов жизненного цикла и ИСО/МЭК/ИИЭР 16326 для процесса управления проектами.

ИСО/МЭК 15026 совместим с этими стандартами процессов жизненного цикла. Цели гарантии, выбор гарантируемых требований, относящееся к гарантии планирование, разработка и обслуживание гарантийных случаев взаимозависимы во всех процессах жизненного цикла.

9.2 Мероприятия гарантии в жизненном цикле

Чтобы обеспечить основание для уверенности в свойствах системы, необходимо выполнить запланированную и систематическую совокупность гарантийных мероприятий. Такая совокупность действий разработана для обеспечения соответствия процессов и систем требованиям к ним, стандартам, методическим материалам и определенным процедурам [145].«Процессы» в данном контексте включают в себя все действия, связанные с проектированием, разработкой и техническим обслуживанием системы. Для программного обеспечения понятие «программный продукт» включает в себя само программное обеспечение, связанные с ним данные, его документацию, поддерживающие и отчетные документы, произведенные как часть программного процесса (например, результаты испытаний и аргументы гарантии), а также все то, что необходимо для завершения гарантийного случая. «Требования» включают в себя требования к свойствам, которые должны быть доказаны, в конечном счете на основе требований, направленных на ограничение, уменьшение или управление связанными со свойством затратами и убытками. «Стандарты, методические материалы» могут быть как техническими, определяющими технологию для использования в системе или программном обеспечении, так и нетехническими, определяющими аспекты процесса, которые далее очерчены «процедурами», обеспечивающими возможность удовлетворения требований к системе.

Управление действиями жизненного цикла включает в себя обработку как действий, непосредственно связанных с относящейся к гарантии качества информацией, таки того влияния, которое относящаяся к гарантии качества информация оказывает на другие действия. Успешное управление лучше всего осуществляется в случае, если требования верхнего уровня рассматриваются с самого начала разработки концепции, когда они влияют на все последующие действия и системы и становятся неотъемлемой частью полного процесса разработки (см.[140] и [22, приложение В]). Все это возможно лишь тогда, когда одновременно разрабатывается система и информационный блок, показывающий удовлетворение требований.

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

10 Заключение

Цель настоящего стандарта — обеспечить пользователей всех частей ИСО/МЭК 15026 объяснением соответствующих понятий и терминов, используемых в ИСО/МЭК 15026, которые ранее не были общепринятыми в разных сообществах. Объяснения того, что изложено в каждой из частей ИСО/МЭК 15026, должно обеспечить возможность для выбора и использования этих частей, а также обоснование выбора других стандартов, не принадлежащих к серии ИСО/МЭК 15026.

Приложение ДА (справочное)

Сведения о соответствии ссылочных международных стандартов национальным стандартам

Гарантии качества программного обеспечения. Кто за это отвечает?

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

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

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

Но даже если Вы приобретаете компьютерную игрушку для вашего отпрыска или другую программу некоммерческого назначения, когда данные действия подпадают под действие Закона о защите прав потребителя, следует обратить внимание на следующее. С соответствии с п.1 статьи 4 данного закона «Продавец (исполнитель) обязан передать потребителю товар (выполнить работу, оказать услугу), качество которого соответствует договору». Кстати, пункт 1 статьи 469 части второй Гражданского кодекса практически слово в слово повторяет приведенную выше цитату. Итак, качество приобретаемого товара может быть определено договором. В случае с программным обеспечением таким договором, как правило, является Лицензионное соглашение, поставляемое вместе с приобретаемым программным продуктом.

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

«УСТАНАВЛИВАЯ, КОПИРУЯ ИЛИ ИНЫМ ОБРАЗОМ ИСПОЛЬЗУЯ ПРОДУКТ, ВЫ СОГЛАШАЕТЕСЬ С УСЛОВИЯМИ НАСТОЯЩЕГО ЛИЦЕНЗИОННОГО СОГЛАШЕНИЯ. ЕСЛИ ВЫ НЕ СОГЛАСНЫ С УСЛОВИЯМИ, ТО НЕ УСТАНАВЛИВАЙТЕ И НЕ ИСПОЛЬЗУЙТЕ ДАННЫЙ ПРОДУКТ. ВЫ ВПРАВЕ ВЕРНУТЬ ЕГО ПРОДАВЦУ И ПОЛУЧИТЬ УПЛАЧЕННЫЕ ВАМИ ДЕНЬГИ В ПОЛНОМ ОБЪЕМЕ».

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

«11. ОТКАЗ ОТ ДРУГИХ ГАРАНТИЙ. ПРИВЕДЕННАЯ НИЖЕ ОГРАНИЧЕННАЯ ГАРАНТИЯ СОВЕРШЕННО ИСЧЕРПЫВАЕТ ПРЕДОСТАВЛЯЕМЫЕ ВАМ ЯВНО ГАРАНТИИ… КОРПОРАЦИЯ МАЙКРОСОФТ И ЕЕ ПОСТАВЩИКИ ПРЕДОСТАВЛЯЮТ ПРОДУКТ И (ЕСЛИ ТАКОВЫЕ ПРЕДОСТАВЛЯЮТСЯ) УСЛУГИ ПО ПОДДЕРЖКЕ НА УСЛОВИЯХ "КАК ЕСТЬ", СО ВСЕМИ НЕИСПРАВНОСТЯМИ, И ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ДРУГИХ ЯВНЫХ, ПОДРАЗУМЕВАЕМЫХ ИЛИ ПРЕДУСМОТРЕННЫХ ЗАКОНОДАТЕЛЬСТВОМ ГАРАНТИЙ И УСЛОВИЙ (выделено автором), ВКЛЮЧАЯ (НО НЕ ОГРАНИЧИВАЯСЬ ТОЛЬКО ИМИ) ОТКАЗ ОТ ПОДРАЗУМЕВАЕМОЙ ГАРАНТИИ, ОБЯЗАТЕЛЬСТВ ИЛИ УСЛОВИЙ ПРИГОДНОСТИ ДЛЯ ПРОДАЖИ И ПРИМЕНИМОСТИ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ, ТОЧНОСТИ ИЛИ ПОЛНОТЫ ОТВЕТОВ ИЛИ РЕЗУЛЬТАТОВ РАБОТЫ, ГАРАНТИИ ВЫСОКОЙ КВАЛИФИКАЦИИ, ОТСУТСТВИЯ ВИРУСОВ, ОТСУТСТВИЯ НЕБРЕЖНОСТИ ПРИ ИЗГОТОВЛЕНИИ ПРОДУКТА, А ТАКЖЕ ПРЕДОСТАВЛЕНИЯ ИЛИ НЕПРЕДОСТАВЛЕНИЯ УСЛУГ ПО ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ. КРОМЕ ТОГО, ПО ОТНОШЕНИЮ К ДАННОМУ ПРОДУКТУ НЕ ОБУСЛАВЛИВАЮТСЯ И НЕ ПРЕДОСТАВЛЯЮТСЯ ГАРАНТИИ ПРАВА СОБСТВЕННОСТИ, СПОКОЙНОГО ВЛАДЕНИЯ И ПОЛЬЗОВАНИЯ, СООТВЕТСТВИЯ ОПИСАНИЮ ИЛИ НЕНАРУШЕНИЯ АВТОРСКИХ ПРАВ».

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

«12. … НИ ПРИ КАКИХ ОБСТОЯТЕЛЬСТВАХ КОРПОРАЦИЯ МАЙКРОСОФТ И ЕЕ ПОСТАВЩИКИ НЕ НЕСУТ ОТВЕТСТВЕННОСТЬ ЗА КАКОЙ-ЛИБО… УЩЕРБ ИЛИ УБЫТКИ. ВОЗНИКАЮЩИЕ В СВЯЗИ С ИСПОЛЬЗОВАНИЕМ ИЛИ НЕВОЗМОЖНОСТЬЮ ИСПОЛЬЗОВАНИЯ ПРОДУКТА, ИЛИ ПРЕДОСТАВЛЕНИЕМ ИЛИ НЕПРЕДОСТАВЛЕНИЕМ УСЛУГ ПО ПОДДЕРЖКЕ…».

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

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

Вот выдержка из лицензионного соглашения компании Hewlett Packard, ведущего производителя компьютерной и офисной техники:

«HP SOFTWARE LICENCE AGREEMENT. ЛИЦЕНЗИЯ НА ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ И АВТОРСКИЕ ПРАВА.

СОДЕРЖАЩАЯСЯ В НАСТОЯЩЕМ ДОКУМЕНТЕ ИНФОРМАЦИЯ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПОСТАВЛЯЮТСЯ НА ОСНОВЕ "КАК ЕСТЬ" БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ . КОМПАНИЯ HP И ЕЕ ПОСТАВЩИКИ НЕ ДАЮТ ЯВНЫХ ГАРАНТИЙ КАК В УСТНОЙ, ТАК И В ПИСЬМЕННОЙ ФОРМЕ В ОТНОШЕНИИ ДАННОГО ИЗДЕЛИЯ. КРОМЕ ТОГО, КОМПАНИЯ HP И ЕЕ ПОСТАВЩИКИ ОТКАЗЫВАЮТСЯ ОТ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ИСПОЛЬЗОВАНИЯ В КАКОЙ-ЛИБО КОНКРЕТНОЙ ЦЕЛИ…»

И далее, почти как у Microsoft:

«КОМПАНИЯ HP ИЛИ ПОСТАВЩИКИ HP НИ ПРИ КАКИХ ОБСТОЯТЕЛЬСТВАХ НЕ НЕСУТ ОТВЕТСТВЕННОСТИ ЗА ПРЯМОЙ, КОСВЕННЫЙ, ОСОБЫЙ, СОПУТСТВУЮЩИЙ ИЛИ ОПОСРЕДОВАННЫЙ УЩЕРБ (ВКЛЮЧАЯ УПУЩЕННЫЕ ПРИБЫЛИ И УТРАЧЕННЫЕ ДАННЫЕ), ПОДРАЗУМЕВАЕМЫЙ ПОЛОЖЕНИЯМИ ГАРАНТИИ, ДОГОВОРА, ФАКТОМ ГРАЖДАНСКО-ПРАВОВОГО НАРУШЕНИЯ ИЛИ ИНЫМИ ПРАВОВЫМИ НОРМАМИ».

Практически то же самое мы читаем в лицензионном соглашении компании Adobe (перевод автора):

«4. ГАРАНТИИ НЕ ПРЕДОСТАВЛЯЮТСЯ. ДАННОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПОСТАВЛЯЕТСЯ НА УСЛОВИЯХ «КАК ЕСТЬ» И КОМПАНИЯ ADOBE НЕ ДАЕТ НИКАКИХ ГАРАНТИЙ В СВЯЗИ С ЕГО ИСПОЛЬЗОВАНИЕМ…». А вот выдержка из лицензионного соглашения на программу «Windows Commander» (перевод автора): «МЫ ПОСТАРАЛИСЬ ПРЕДОСТАВИТЬ ПРОГРАММУ СВОБОДНУЮ ОТ ОШИБОК, НАСКОЛЬКО ЭТО ВОЗМОЖНО. ОДНАКО, СУЩЕСТВУЕТ ОБЩЕЕ ПРАВИЛО (ЗАКОН МЕРФИ), ЧТО В ПРИРОДЕ НЕТ ПРОГРАММ БЕЗ ОШИБОК, И ИХ ЧИСЛО ВОЗРАСТАЕТ ПРОПОРЦИОНАЛЬНО СЛОЖНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. ПОЭТОМУ МЫ НЕ МОЖЕМ ГАРАНТИРОВАТЬ, ЧТО ЭТО ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ БУДЕТ РАБОТАТЬ НА ЛЮБОМ ОБОРУДОВАНИИ, НА ЛЮБОМ WINDOWS-СОВМЕСТИМОМ КОМПЬЮТЕРЕ ВМЕСТЕ С ДРУГИМИ ПРИЛОЖЕНИЯМИ БЕЗ ОШИБОК…ПОЖАЛУЙСТА ПРОТЕСТИРУЙТЕ ЭТУ ПРОГРАММУ С ПОМОЩЬЮ НЕ КРИТИЧЕСКИХ ДАННЫХ. МЫ НЕ ГАРАНТИРУЕМ БЕЗОПАСНОСТЬ ВАШИХ ДАННЫХ, ОСОБЕННО НА НОВЫХ ОПЕРАЦИОННЫХ СИСТЕМАХ ТАКИХ КАК WINDOWS NT ИЛИ OS/2. ВЫ МОЖЕТЕ ВЫЯВИТЬ ОШИБКИ ПЕРЕД РЕГИСТРАЦИЕЙ ПРОГРАММЫ И ПРИНЯТЬ ИХ. ЛЮБЫЕ ОПИСАНИЯ ОШИБОК БУДУТ НАМИ ПРИНИМАТЬСЯ, ОДНАКО МЫ НЕ МОЖЕМ ГАРАНТИРОВАТЬ, ЧТО ОНИ БУДУТ ИСПРАВЛЕНЫ…»

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

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

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

Гарантия на программное обеспечение или техническая поддержка

Заказчики разработки программного обеспечения часто сталкиваются с проблемой обслуживания готового продукта. С одной стороны, статья 470 ГК РФ предусматривает гарантию на программное обеспечение, с другой, — размер гарантийных обязательств, распространяющихся на продукт по закону, не всегда в полной мере удовлетворяет потребности покупателей.

Гарантийные обязательства

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

01	Документально подтвержденное свидетельство наличия сбоя.
02	Подтверждение того, что сбой произошел по вине разработчика.
03	Корректная эксплуатация программного обеспечения в соответствии с инструкцией.
04	Отсутствие самостоятельного вмешательства заказчика в устройство программного обеспечения.
05	Соответствие претензии заказчика требованиям технического задания.

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

Техническая поддержка

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

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

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

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

Гарантии на установку программного обеспечения

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

Компьютерная помощь

не принимал участия в ее разработке

и не может знать о том, как и при каких условиях будет использоваться это программное обеспечение?

компьютерный специалист

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

Получается так, что на протяжении срока действия гарантии, можно не использовать антивирусную защиту, посещать сайты с любым контентом, инсталлировать неизвестные и возможно вредоносные приложения, удалять «лишние и ненужные» системные файлы. а если программа внезапно перестанет работать, просто вызвать мастера, который исправит все бесплатно!

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

компьютерный мастер

забыл разъяснить вам некоторые подробности и детали

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

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

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

Основные причины отказа в гарантийном обслуживании установленного программного обеспечения:

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

Но почему же вам не разъяснили самые важные аспекты гарантии?
Может быть потому, что вы спрашивали только о наличии гарантии и подробности вас совершенно не интересовали?
Кроме этого, если некоторые детали гарантийного обслуживания малопривлекательны — лучше о них ничего не рассказывать 🙂

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

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

Что такое гарантийный случай для программного продукта

ГОСТ Р ИСО/МЭК 15026-1-2016 Системная и программная инженерия. Гарантирование систем и программного обеспечения. Часть 1. Понятия и словарь

Оглавление

Этот ГОСТ находится в:

Организации:

Systems and software engineering. Systems and software assurance. Part 1. Concepts and vocabulary

ГОСТ Р исо/мэк

15026-1—

СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ

Гарантирование систем и программного обеспечения

Понятия и словарь

Предисловие

ГОСТ Р ИСО/МЭК 15026-1—2016

5.5.1 Свойства как поведение

5.6 Неопределенность и уверенность

5.7 Условия и инициирующие события

6 Применение нескольких частей ИСО/МЭК 15026

ГОСТ Р ИСО/МЭК 15026-1—2016

6.3 Взаимосвязь частей ИСО/МЭК 15026

6.4 Ответственные

7 ИСО/МЭК 15026 и гарантийный случай

ГОСТ Р ИСО/МЭК 15026-1—2016

7.3 Средства получения доказательств и управления ими

7.4 Сертификации и аккредитации

8 ИСО/МЭК 15026 и уровни целостности

ГОСТ Р ИСО/МЭК 15026-1—2016

9 ИСО/МЭК 15026 и жизненный цикл

9.1 Введение

9.2 Мероприятия гарантии в жизненном цикле

10 Заключение

Гарантии качества программного обеспечения. Кто за это отвечает?

Гарантия на программное обеспечение или техническая поддержка

Гарантийные обязательства

Техническая поддержка

Гарантии на установку программного обеспечения

Компьютерная помощь

не принимал участия в ее разработке

компьютерный специалист

компьютерный мастер

забыл разъяснить вам некоторые подробности и детали

Добавить комментарий Отменить ответ

ГОСТ Р ИСО/МЭК 15026-1-2016
Системная и программная инженерия. Гарантирование систем и программного обеспечения. Часть 1. Понятия и словарь