Об ответственности софтверного производителя

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

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

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

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

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

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

Вадим СТАНКЕВИЧ

Версия для печатиВерсия для печати

Номер: 

35 за 2009 год

Рубрика: 

Software
Заметили ошибку? Выделите ее мышкой и нажмите Ctrl+Enter!

Комментарии

Страницы

Аватар пользователя Логик
Narthex >Если весь функционал покрыт тестами (несколько тысяч), то проект не сбилдится, если хоть один тест (Unit тест) упадет.

Это верно.

>А тесты проверят все - от входных данных до времени выполнения куска кода.

Это НЕ верно. Тесты НЕ могут проверить ВСЕ! - Помнится мне у Exсel был баг - он с некоторым числом (и это число не нуль) не мог корректно производить арифметическую операцию - но не будешь же ВСЕ числа прогонять через тесты?

Типа такого: "Пару дней назад в одной из программ пакета Microsoft Offece 2007 (а именно отличился всеми любимый без сарказма Excel 2007) была найдена ошибка, проявляющаяся в неправильном отображении числа 65535. Во всяком случае, официальное объяснение Microsoft в своём блоге дала именно такое - некорректное отображение. И пару доказательств, мол если ввести формулу =77.1*850, то результат будет вывведен как 100000. Однако если рядом ввести =E1*2, то результат окажется верным - 131070.

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

Аватар пользователя Логик
Narthex > в данном случае возможно полное отсутствие багов(для небольших приложений). Это как пример формализации задачи уменьшения багов, причем вполне успешной.

Верно, что можно сказать, что в этом случае багов станет МЕНЬШЕ! - Но ведь НЕИЗВЕСТНО СКОЛЬКО ИХ ОСТАЛОСЬ ТО?! -

О том, сколько же багов осталось нельзя сказать, как бы ты не покрывал свой код и сколько бы тестов не написал!!!

Аватар пользователя НЕ программист
Логик

12 сентября 2009 года, 23:13

Стоимость труда определяется спросом - как и любого другого товара - СПРОСОМ И ПРЕДЛОЖЕНИЕМ.

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

Если простой НЕ программист выпускает автомобили, которые можно условно назвать автомобилями или которые НИКТО не покупает - то этого простого НЕ программиста только жаль.

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

Аватар пользователя mike
>Стоимость труда определяется спросом

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

хехе! Учи основы экономики, "НЕ программист".

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

А если РЫНКА нет - как уже ДАВНО производят типа ЛАДА типа "авто"?!

Аватар пользователя Логик
НЕ программист > Слесарь не виноват в проблемах автомобильного завода.

Но и покупатель НЕ виноват, что он НЕ хочет приобретать "нечто", что выпускает ЭТОТ НЕВИНОВНЫЙ слесарь!

Аватар пользователя Логик
mike (old student) > путаем стоимость труда и цену.

Хорошо - ВЕЛИЧИНА ЗАРПЛАТЫ ОПРЕДЕЛЯЕТСЯ СПРОСОМ И ПРЕДЛОЖЕНИЕМ НА РЫНКЕ ТРУДА!

пойдет? ;-)

Аватар пользователя НЕ программист
Да, вполне логично:-)
Аватар пользователя Логик
"Пока вся страна, запасшись попкорном следит за событиями на АВТОВАЗе, где объявлено о планах сократить до конца года 36 000 работников, попытаемся взглятуть на проблему качества продукта отечественного автопрома и конкурентоспособности с другой стороны, со стороны простого рабочего

Ну пока я, простой рабочий с вазовского конвейера, оказался без работы, то на вынужденном досуге опишу завод. Как мы дошли до такой жизни. Текст сырой и сумбурный. Так, что терпите."

http://community.livejournal.com/rusrep/31739.html

Страницы