Архивы: по дате | по разделам | по авторам

As is

Архив
автор : Владимир Гуриев   01.10.2002

Каким должно быть программное обеспечение

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

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

И спросила кроха

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

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

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

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

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

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

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

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

Windows? Разнобой версий операционных систем, объединенных под одной торговой маркой, не позволяет аргументированно облить грязью сразу все. Попробуйте предъявить описанные требования любой из них, наиболее вам знакомой. Как результат? Вдохновляет?

Linux? Не так свободен от ошибок, как принято считать. Не так дешев (если учитывать трудозатраты на обслуживание), как принято считать. Не так, не так, не так… И чудовищно сложен в освоении, если сравнивать его с Windows. Знаменитая фраза «Windows SuXX, Linux Rules» говорит скорее об однобокости подхода, чем о реальных качествах этих систем.

Список, к сожалению, можно продолжать до бесконечности.

Чем дальше в лес…

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

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

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

С заявленными функциями тоже все нормально. Большинство популярных пакетов вполне соответствует ожиданиям. Функциональность многих из них превосходит самые смелые требования пользователей. Известно, например, что даже продвинутые пользователи Microsoft Word используют не более четверти заложенных в него возможностей. Факт этот был обнародован во времена Microsoft Office 97. Сейчас, скорее всего, дела обстоят так же, если не хуже.

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

Разумеется, первые компьютерные программы были написаны еще хуже. Однако создается впечатление, что на каком-то этапе был достигнут тот уровень качества продукта, который всех устроил. Программистов - по трудозатратам, пользователей… А что пользователи? Они и не знали, что может быть иначе.

Кто виноват?

Почему качество программных продуктов leaves much to be desired 1? Одной из главных причин, вероятно, является то, что computer science вообще и программирование в частности относительно молоды. Еще недавно программированием занимались по большей части из любви к искусству, ради процесса, - конечный результат программистов интересовал постольку поскольку. Главное - добиться принципиального решения поставленной задачи. Детали никого не интересуют. Другими словами, низкое качество прикладных программ проистекает из того, что программирование до недавнего времени было слишком академической (здесь: мало применяющейся в реальной жизни) дисциплиной. Первые программисты были скорее творцами, чем ремесленниками. Несмотря на то, что творческий элемент на уровне кодера из программирования давным-давно выхолощен, отсутствие критического отношения к результатам своего труда осталось.

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

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

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

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

Иногда, кстати, речь может идти и о сужении функциональности. Заявление Microsoft о том, что из Windows нельзя исключить Internet Explorer без потери части функциональности, многие аналитики считают признанием чудовищности архитектуры (или, скорее, отсутствия архитектуры как таковой) Windows. Разумеется, если допустить, что утверждение Microsoft правдиво, а не есть очередная попытка сохранить свое положение на рынке ПО.

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

Последнее приходящее в голову соображение состоит в следующем. Слишком большие возможности современного «железа» провоцируют программистов на некритичное отношение к собственному труду. Память слишком дешева, процессоры слишком быстры… Разумеется, это утверждение относится не ко всем разновидностям ПО - существуют задачи, для которых производительности даже современных процессоров маловато. Однако много ли новых ключевых возможностей появилось в том же Microsoft Excel за последние, скажем, семь лет? А мощности-то выросли изрядно.

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

Бесконечная история

Мы коснулись проектирования в предыдущем разделе. Настало время поговорить о нем подробнее.

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

Неправильно поставленная задача вкупе с неправильно спланированным порядком работы приводят к поистине плачевным результатам. Так, по исследованиям Standish Group, до финального релиза доживает лишь три четверти начатых проектов (статистика американская; в России, насколько нам известно, таких исследований не проводилось). При этом, конечно, не учитываются софтверные проекты, изначально обреченные на бесславную смерть - студенческие или любительские 4. Речь идет о серьезных, казалось бы, начинаниях - о программных продуктах, в разработку которых были вложены деньги. «Недопетые песни» обошлись производителям в 2000 году в 67 миллиардов долларов. Плюс еще 21 миллиард долларов ушел на дополнительную разработку, когда оказалось, что в поставленные сроки разработчики не уложились. Если вы узнаете, что порядка 80% бюджетов софтверных фирм уходит на поиск и устранение ошибок в собственных программах, возможно, вам захочется помочь им финансово.

Ты виноват лишь в том, что хочется мне…

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

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

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

Что нас ждет дальше? С каждым годом роль программного обеспечения в нашей становится неуклонно возрастает. Все больше и больше задач решается только с помощью компьютеров. Усилия специалистов по quality software пока видимых результатов не дают (а может быть, и дают, - ведь неизвестно, что было бы, если б качество ПО оставить на совести программистов). Интересно, что компании, которые должны быть не меньше пользователей заинтересованы в выпуске отличного продукта, очень часто препятствуют обсуждению качества своего ПО. Некоторые даже запрещают публиковать сравнительные тесты производительности своих продуктов, предусмотрев эту ситуацию в лицензии (обосновывается все, конечно, красиво - считается, что для проведения таких тестов нужна определенная классификация, и тесты, проведенные неправильно [а также не устраивающие компанию], могут навредить образу продукта). Довольно часто на внесение исправлений намеренно откладывается - пытаясь объять необъятное, производители программ перед выходом новой версии продукта решают, какие ошибки нужно исправить немедленно, какие отложить до первого сервис-пака, а за какие взяться только после того, как о них сообщат пользователи. Случись подобное в любой другой индустрии (вы можете представить себе такую ситуацию в фармацевтике?), и производитель немедленно был бы засыпан исками. В случае с ПО это считается нормальной практикой и никого не шокирует.


1 (обратно к тексту) - Оставляет желать много лучшего, англ.
2 (обратно к тексту) - Полностью прочитать результаты исследования можно по адресу: www.nist.gov/director/prog-ofc/report02-3.pdf.
3 (обратно к тексту) - В USA Today писали о 100 миллиардах долларов в год, однако методика подсчетов неизвестна.
4 (обратно к тексту) - Исключения, конечно, бывают. Napster, например, царствие ему небесное, был классическим студенческим проектом, что не помешало ему стать крупнейшим событием на софтверном рынке. Да и Linux тоже не в корпорациях писался…

Джим Маккарти, основатель компании, специализирующейся на проведении тренингов по оценке качества программного обеспечения, обычно начинает свою первую лекцию со слайда с надписью «Most Software Sucks».


Билл Гейтс, беседуя с одним из боссов автомобильной промышленности, заявляет, что «если бы автомобильная индустрия развивалась так быстро, как индустрия ПО, сегодня мы ездили бы на машинах, которые стоят

25 долларов и потребляют не более галлона топлива на десять тысяч миль».

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

И, подумав, добавляет: «А при обращении в сервис, в независимости от поломки, нам бы советовали переустановить двигатель».

Обычно это преподносится как байка. Но от человека, сказавшего в свое время, что «640 Кбайт оперативной памяти хватит всем», можно ожидать и подобных перлов.

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

  1. Мосты, как правило, строятся вовремя.
  2. Строители не выходят за рамки бюджета.
  3. Мосты не рушатся 1.

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


Дополнительная статистика

В 1995 году дела обстояли не лучше, а то и хуже.

По данным Standish Group 2, американское правительство и компании потеряли порядка 80 млрд. долларов из-за прерванных проектов.

Была прекращена разработка 80 тысяч программных продуктов.

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


О смертности

Почему проекты не доживают до финальной стадии? Исследователи из Standish Group выявили несколько факторов - оценка их значимости производилась путем опроса разработчиков и ИТ-менеджеров.


Факторы, негативно влияющие
на развитие проекта

% откликов

1. Нечеткая постановка задачи

13,1

2. Слабая вовлеченность потенциальных пользователей

12,4

3. Недостаток ресурсов

10,6

4. Неоправданные ожидания

9,9

5. Недостаток поддержки со стороны руководства

9,3

6. Изменение постановки задачи и спецификаций в процессе разработки

8,7

7. Недостаточное планирование

8,1

8. Да это никому не нужно

7,5

9. Недостаточный ИТ-менеджмент

6,2

10. Некомпетентность

4,3

Другие

9,9


А вот что ответили эти же люди на вопрос, больше ли стало ошибок в ПО:


Чем 5 лет назад

Чем 10 лет назад

Значительно больше

27%

17%

Несколько больше

21%

29%

Без изменений

11%

23%

Немного меньше

19%

23%

Гораздо меньше

22%

8%



1 (обратно к тексту) - Спектор, конечно, погорячился. Но мосты в общем случае надежнее текстового процессора, в котором [Ctrl+S] я [Ctrl+S] набираю [Ctrl+S] этот [Ctrl+S] текст.
2 (обратно к тексту) - Полностью с исследованием, известным под названием Chaos Report, можно ознакомиться здесь: www.pm2go.com/sample_research/chaos_1994_1.php.

Выдержки из лицензионного соглашения
к коробочной версии Windows XP Professional

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

<…>

11. ОТКАЗ ОТ ПРЕДОСТАВЛЕНИЯ ГАРАНТИЙ.

Упомянутая ниже ограниченная гарантия является единственной предоставляемой вам явной гарантией, заменяющей любые другие явные гарантии (если таковые имелись), приведенные в какой-либо документации, на упаковке или предоставленные иным образом. За исключением данной ограниченной гарантии и в наибольшей степени, разрешенной применимым законодательством, корпорация Майкрософт и ее поставщики предоставляют продукт и (если таковые предоставляются) услуги по технической поддержке на условиях «КАК ЕСТЬ», СО ВСЕМИ НЕИСПРАВНОСТЯМИ, и отказываются от предоставления каких-либо других явных, подразумеваемых или предусмотренных законодательством гарантий и условий, включая (но не ограничиваясь только ими) отказ от подразумеваемой гарантии, обязательств или условий пригодности для продажи и применимости для определенной цели, надежности или доступности, точности или полноты ответов или результатов работы, гарантии высокого качества исполнения, отсутствия вирусов, отсутствия небрежности при изготовлении продукта, а также предоставления или непредоставления технической поддержки или иных услуг, сведений, программного обеспечения и содержимого в результате или в связи с использованием продукта. КРОМЕ ТОГО, ПО ОТНОШЕНИЮ К ДАННОМУ ПРОДУКТУ НЕ ОБУСЛАВЛИВАЮТСЯ И НЕ ПРЕДОСТАВЛЯЮТСЯ ГАРАНТИИ ПРАВА СОБСТВЕННОСТИ, СПОКОЙНОГО ВЛАДЕНИЯ И ПОЛЬЗОВАНИЯ, СООТВЕТСТВИЯ ОПИСАНИЮ ИЛИ НЕНАРУШЕНИЯ ПРАВ НА ИНТЕЛЛЕКТУАЛЬНУЮ СОБСТВЕННОСТЬ.

12. ИСКЛЮЧЕНИЕ СЛУЧАЙНОГО, КОСВЕННОГО И ИНЫХ ОПРЕДЕЛЕННЫХ ВИДОВ УЩЕРБА.

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

<…>

14. ОГРАНИЧЕНИЕ ОТВЕТСТВЕННОСТИ И РАЗМЕРА ВОЗМЕЩЕНИЯ УЩЕРБА.

Независимо от характера и причин причиненного вам ущерба или понесенных убытков (включая все без исключения перечисленные выше случаи ущерба и/или убытков, а также любые прямые или общие ущерб и/или убытки), максимальный размер ответственности корпорации Майкрософт или любого ее поставщика по любому из положений настоящего лицензионного соглашения, и размер причитающейся Вам компенсации (за исключением компенсации в виде ремонта или замены продукта, предоставляемой по выбору корпорацией Майкрософт в связи с нарушением ограниченной гарантии) не может превысить большей из следующих сумм: суммы, фактически уплаченной вами при приобретении продукта, или суммы в размере пяти долларов США. Перечисленные выше ограничения, исключения и отказы (включая разделы 11 и 12, а также ограниченную гарантию) действуют в наибольшей степени, допускаемой применимым законодательством, даже если полученная компенсация не покрывает понесенный ущерб.

© ООО "Компьютерра-Онлайн", 1997-2021
При цитировании и использовании любых материалов ссылка на "Компьютерру" обязательна.