Целесообразность оценки надежности программного обеспечения

← →
Kostafey © (2007-10-17 19:17) [0]

Скоро у нас будет утверждение тем диссертаций.
Не углуюляясь в подробности скажу, что я буду исследовать
вопросы надежности автоматизированных систем.
В общих чертах надежность АСУ включает в себя 3 составляющих:
1. аппаратная надежность
2. программная надежность
3. надежность человеко-машинного взимодействия

Хочу узнать ваше мнение по вопросу надежности программной части.

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

Но будет ли хоть какая-то практическая польза от использования
одной из них, или как вариант, новой основанной на сиснтезе существующих?

Сейчас, как я вижу все внимание нацелено на устранение обнаруженных ошибок,
а не на оценку возможного числа ошибок и определение количественных характеристик
надежности ПО.
Например: http://delphimaster.net/view/15-1192433128/

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

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

← →
oldman © (2007-10-17 19:23) [1]

"проще надо быть и люди к тебе потянутся" (СамЗнаешьКто ©)

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

Вот и все, собственно.
Ах, да...
Забыл вставить ИМХО!!!

← →
Kostafey © (2007-10-17 19:30) [2]

> [1] oldman © (17.10.07 19:23)

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

← →
isasa © (2007-10-17 19:39) [3]

oldman © (17.10.07 19:23) [1]
Ну не скажи.
Микрософт, например, для оценки качества кода использует формулу разработанную Институтом Карнеги ...
Так там, даже log2(... есть. Учитываются около 5 интегральных параметров.
Вчера показывали(формулу), но я не запомнил :). Будет в Visual Studio 2008 (серверной части).

← →
Правильный_Вася (2007-10-17 19:41) [4]

ПО делает то, что задумано
ПО не делает того, что не задумано
ПО делает, как задумано
ПО не делает, как не задумано

← →
Сергей Суровцев © (2007-10-17 19:42) [5]

>Kostafey © (17.10.07 19:30) [2]
>Сложо спорить, но когда от надежности
>работы человекомашинной системы зависят
>жизни и материальные ценности хочется
>иметь достаточно точный математический
>аппарат ее оценки.

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

Если бы такой универсальный аппарат был, его бы использовали на ура повсеместно. А так - головой, ручками, тестами и опытной эксплуатацией.

← →
Kostafey © (2007-10-17 20:30) [6]

> [5] Сергей Суровцев © (17.10.07 19:42)

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

С этим не спорю, это почти исходные данные :)

> Если бы такой универсальный аппарат был, его бы использовали
> на ура повсеместно. А так - головой, ручками, тестами и
> опытной эксплуатацией.

Но существует ряд более или менее применимых методик.
Даже простой выбор оптимальной из них и автоматизация ее использования
были бы уже весьма полезны. Или нет?

> [3] isasa © (17.10.07 19:39)

Можно поподробнее про этот момент желательно
со ссылкой на первоисточник?

> [4] Правильный_Вася (17.10.07 19:41)
> ПО делает то, что задумано
> ПО не делает того, что не задумано
> ПО делает, как задумано
> ПО не делает, как не задумано

Но есть ошибки в коде программ и
информационном обеспечении (т.е. базе данных).

← →
Правильный_Вася (2007-10-17 21:33) [7]

ошибка в ПО - это противоречие хоть одному пункту из [4]

> простой выбор оптимальной из них

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

← →
Kostafey © (2007-10-17 21:45) [8]

> [7] Правильный_Вася (17.10.07 21:33)
> ошибка в ПО - это противоречие хоть одному пункту из [4]

Гм. Кхм. Оригинальное определение :)

> выбор не бывает простым,

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

> и для каждого условия оптимальность, увы, своя

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

← →
31512 (2007-10-18 07:48) [9]

> Kostafey © (17.10.07 19:17)

Если хочешь, могу тебе рассказать об этой системе. Что из себя представляет, где используется. И хотя ветка, указанная тобой скатилась до простого обсуждения работы с сокетами на то есть 2 причины:
1. Я не указывал сути ПО дабы, чтобы разъяснить проблему более конкретно
2. К этому времени я уже проводил тесты и знал где собака порылась.

А требования по надёжности там очень крутые.

← →
31512 (2007-10-18 07:53) [10]

> Kostafey © (17.10.07 19:17)

И вот ещё что. Мне нужен был опыт тестирования такого рода ПО. Пришлось изобретать велосипед, поскольку изучать элементарно не было времени.
Если интерисует ICQ 336305157

← →
31512 (2007-10-18 08:10) [11]

> Kostafey © (17.10.07 21:45) [8]

Не базами данными едино сыт человече. Существует масса задач с высокоми требованиями по надёжности без всяких БД. Так, что, я бы, не ограничивался только этим. Мне думается, нужно ориентироваться на промышленное ПО.

← →
isasa © (2007-10-18 08:56) [12]

Kostafey © (17.10.07 20:30) [6]

> [3] isasa © (17.10.07 19:39)

Можно поподробнее про этот момент желательно
со ссылкой на первоисточник?

Было на "Дни разработчика 2007" Микрософт, Киев. Слушал в пол уха.
Можно поискать по теме новые возможности Visual Studio 2008.
Позиционировали, как внутренний инструмент по оценке качества кода, предоставленный разработчикам ...

← →
isasa © (2007-10-18 08:58) [13]

... как внутренний инструмент по оценке качества кода,... ->
... как внутренний инструмент Микрософт по оценке качества кода,...

Сорри, не проснулся.

← →
Игорь Шевченко © (2007-10-18 09:04) [14]

Кистате об ошибках - в свое время Майкл Кузумано выступал на Sec(R) (Software engineering conference) в 2005 году, так он провел интересное исследование:
В Японии, например, программисты стараются делать минимальное количество ошибок (менталитет такой), соотвественно, код долго вылизывается.
В Индии наоборот, лишь бы быстрее выдать результат, а какого качество - "это мы потом разберемся"
В Европе и Америке - где-то посередине, ошибок стараются делать поменьше, чем в Индии, но не вылизывают код так, как в Японии.

По выхлопу подход Европы и Америки - самый оптимальный получается.
Так что ошибки были, есть и будут есть. Когда их немного :)

← →
isasa © (2007-10-18 09:12) [15]

Игорь Шевченко © (18.10.07 09:04) [14]
:)
Так последняя идея, не опрределить кол-во ошибок, а по коду, его построению(сколько switch), уровню "иерархичности"(сколько у классов предков, много - плохо :) ) определить вероятность появления ошибок...

← →
boriskb © (2007-10-18 09:14) [16]

> Но будет ли хоть какая-то практическая польза от использования
> одной из них, или как вариант, новой основанной на сиснтезе
> существующих?

На мой взгляд:
1) Сейчас это больше похоже на фундаментальную науку. Методики хоть и существуют, но пользоваться эфективно ими практически нет возможности.
2) Заниматься этим надо даже предвидя, что практического выхлопа возможно не будет. Сейчас может и не будет, но в будущем, вполне вероятно
ну и
3) :) Как чаще всего бывает, мое мнение составлено еще лет 15-20 назад, когда я этой проблемой интересовался. С современным состоянием дел знаком не вполне.

← →
31512 (2007-10-18 09:22) [17]

> Игорь Шевченко © (18.10.07 09:04) [14]

> Так что ошибки были, есть и будут есть. Когда их немного

Как бы это донести до наших заказчиков - конкретнее тем из них, которых называют промышленниками.
Сейчас ситуация складывается таким образом, что ПО наше работает стабильно около 20 часов точно. Просто на большее времени не хватает тестировать. Через 20 часов останавливаем тесты. На объектах смены по 8 часов и программа работает стабильно. Постоянно анализируем логи. Поскольку я руководитель проекта, то постоянно выслушиваю: "если ваша программа хоть раз свалится, то мы платить дальше не будем".
А недавно у меня произошёл забавный случай. Все, наверное знаю что такое терминалы платежей. Я решил пополнить свой Яндекс.Кошелёк. Ввёл номер, всё хорошо. Даю ему 100 рублей. Принял. Даю Следуюшие 100 рублей. И замечаю, что купюроприёмник не жужжит. Пытаюсь скормит ему купюру. Без толку. Думаю, ну хоть 100 рублей провести. Нажимаю "Принять". Висит. И примерно через 20 секунд - СИНИЙ ЭКРАН СМЕРТИ! Меня это развеселило. Говорю охраннику: "Звони им". А он мне: "Она чейчас сама перезагрузится". Я говорю: "Не перезагрузится, точно знаю, звони". Не стал он звонит. На следующий день прихожу опять к этому терминалу. Ситуация не изменилась. Всё тот же экран смерти. Только на мониторе записка висит: "Не работает". :-))))) Так я подарил фирме ЯрПлат 100 рублей на тестирование ПО. :-)))

← →
31512 (2007-10-18 09:30) [18]

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

← →
Игорь Шевченко © (2007-10-18 09:34) [19]

isasa © (18.10.07 09:12) [15]

> Так последняя идея, не опрределить кол-во ошибок, а по коду,
> его построению(сколько switch), уровню "иерархичности"(сколько
> у классов предков, много - плохо :) ) определить вероятность
> появления ошибок...

Хорошая штука, называется Code Quality, в BDS2006 есть. Полезно очень.

31512 (18.10.07 09:22) [17]

> Как бы это донести до наших заказчиков - конкретнее тем
> из них, которых называют промышленниками.

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

← →
31512 (2007-10-18 09:40) [20]

> Игорь Шевченко © (18.10.07 09:34) [19]

Это и понятно. Но ситуация там не столь сложна, чтобы так заявлять.
А что касается

> ПО управления реактором атомной станции

Если бы я за такое взялся, то выставил бы и цену сооветветсвующую...
А поскольку стоимость проекта весьма скромная, при условии достаточно жёстких требований, я и так работаю на 150%. Престиж терять не хоцца.
Во всяком случае сейчас всё хорошо.

← →
31512 (2007-10-18 10:04) [21]

http://www.rsdn.ru/article/testing/SoftwareTesting.xml
Это классно.
Катастрофа Ariane 5

4 июня 1996 года через 40 секунд после запуска ракеты-носителя Ariane 5 произошёл автоподрыв 50-метровой ракеты в районе космодрома во Французской Гвиане. Находившееся на борту научное оборудование потянуло на полмиллиарда долларов, не говоря об астрономических цифрах “упущенной выгоды” от несостоявшихся коммерческих запусков и потере репутации надежного перевозчика. Причиной катастрофы послужил некорректный перенос спецификации программного модуля (ПМ), осуществляющего преобразование из восьмибайтового вещественного в двухбайтовый целый тип данных (double > WORD) из ПО ракеты-носителя Ariane 4 в ПО Ariane 5. Небезынтересно отметить, что предыдущая модель, ракета Ariane 4, успешно запускалась более 100 раз.

← →
Kostafey © (2007-10-18 10:37) [22]

> Не базами данными едино сыт человече. Существует масса задач
> с высокоми требованиями по надёжности без всяких БД. Так,
> что, я бы, не ограничивался только этим. Мне думается,
> нужно ориентироваться на промышленное ПО.

Промышленное ПО - задача смежная. Я буду это учитывать.
При тестировании прошлого проекта 90% ошибок было в информационном
обеспечении. В классичеких книжках по теории надежности ПО
про БД вообще практически ни слова, поэтому этот вопрос очень интересен.

> [14] Игорь Шевченко © (18.10.07 09:04)
> Кистате об ошибках...

Интересная информация. Спасибо.

> [15] isasa © (18.10.07 09:12)
> Игорь Шевченко © (18.10.07 09:04) [14]
> :)
> Так последняя идея, не опрределить кол-во ошибок, а по коду,
> его построению(сколько switch), уровню "иерархичности"(сколько
> у классов предков, много - плохо :) ) определить вероятность
> появления ошибок...

А что-то подобное в упрощенном виде по-моему уже реализовано в одной из методик

> [16] boriskb © (18.10.07 09:14)

> На мой взгляд:
> 1) Сейчас это больше похоже на фундаментальную науку. Методики
> хоть и существуют, но пользоваться эфективно ими практически
> нет возможности.

Да, так мне это и предствляется.

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

Понял, спасибо.

> 3) :) Как чаще всего бывает, мое мнение составлено еще лет
> 15-20 назад, когда я этой проблемой интересовался. С современным
> состоянием дел знаком не вполне.

За это время ничего, ровным счетом ничего не изменилось.
Все серьезные работы в этой области закончились в начале 80-х.
После этого только отдельные статьи и переписывание старого.

> [18] 31512 (18.10.07 09:30)
> И хотя это был, скорее всего, аппаратный сбой, вывод можно
> сделать один - тестирование ПО всегда комплексная задача
> и, как следствие, методика должна это предусматривать

Я об этом первом посте (т.е. нулевом :)) писал

← →
Kostafey © (2007-10-18 10:53) [23]

> [21] 31512 (18.10.07 10:04)
> http://www.rsdn.ru/article/testing/SoftwareTesting.xml

Классная статья!
Не понимаю как я на нее не наткнулся раньше?
Спасибо!

← →
Jeer © (2007-10-18 11:11) [24]

Легенда о торпеде

Ранние конструкции торпед предполагали самоуничтожение в случае разворота торпеды на 180°, так чтобы торпеда не смогла уничтожить выпустившую её лодку. Легенда гласит, что однажды подобная торпеда застряла в пусковой камере и экипаж не смог её удалить. Капитан решил вернуть лодку в порт для проведения ремонта. Как только подводная лодка развернулась на 180°, торпеда взорвалась и потопила лодку.

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

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

← →
Игорь Шевченко © (2007-10-18 11:14) [25]

Kostafey © (18.10.07 10:53) [23]

> Классная статья!

Я конечно извиняюсь, но Кент Бек пишет про тестирование гораздо занимательнее и понятнее :)

← →
31512 (2007-10-18 11:16) [26]

> Игорь Шевченко © (18.10.07 11:14) [25]

Ссылочку бы.

← →
Jeer © (2007-10-18 11:16) [27]

> Игорь Шевченко © (18.10.07 11:14) [25]

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

← →
Jeer © (2007-10-18 11:21) [28]

http://www.lenta.ru/news/2007/10/17/gun/

Там явно поработал индус над ПО для бортового компутера.

> [27] Jeer © (18.10.07 11:16)
>
> > Игорь Шевченко © (18.10.07 11:14) [25]
>
> Этим всегда страдали отечественные авторы "псевдо"-научных
> статей: чем больше абстракций и тумана - тем меньше вероятность,
> что кто-то захочет примерить на себе платье дурака.

Хорошо сказать о сложном просто,
хорошо сказать о простом сложно :)

наукообразие, панимашь! :)

← →
31512 (2007-10-18 11:29) [30]

> Jeer © (18.10.07 11:21) [28]

Третьего дня у нас был иностранный гость Ланс. Индус по происхождению. Бывший программист. Приехал в Красноярск с целью поиска разработчиков среди выпускников вузов и отрытия филиала в России. По планам заказы на ПО должны распределяться по России, Китаю, Индии, США и Англии.
Он сетовал на то, что индийские программисты стали очень дорого по оплате труда. А по поводу багов сказал, что баги недопустипы - это приведёт к разрыву всяких отношений. Смотрел наши разработки и удивлялся, как можно сделать в такой маленькой компании такие большие и сложные АСУ.

> 31512 (18.10.07 11:29) [30]

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

> Kostafey © (17.10.07 19:17)

от http://www.intuit.ru/department/se/testing/
до http://carnegiequality.com/
+
http://it4business.ru/forum/index.php?showforum=109

31512 (18.10.07 11:16) [26]

> Ссылочку бы.

Ссылочку - это пожалуйста, ссылочек нам не жалко.

http://www.rsdn.ru/res/book/prog/beck.xml?print

← →
31512 (2007-10-18 11:58) [34]

> Jeer © (18.10.07 11:33) [31]

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

Еще по теме:
"Вычисление" или прогнозирование надежности ПО очевидно возникло по аналогии с производством чего угодно. В промышленности такие системы действуют давно, в разных областях и успешно.
Так вот: пока прогаммирование не станет (а станет?) "производством", конвеером в чистом виде, до тех пор и не приживутся в нем такие системы.
То есть надо из программирования убрать даже намеки на оригинальность.
"Смотри как я исхитрился!", "красиво решил" - подобные фразы постоянны сейчас в написание систем.
Отсюда и невозможность оценки надежности.

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

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

> [32] Jeer © (18.10.07 11:36)
>
> > Kostafey © (17.10.07 19:17)
>
>
> от http://www.intuit.ru/department/se/testing/
> до http://carnegiequality.com/
> +
> http://it4business.ru/forum/index.php?showforum=109

Пасибо, посмотрим.

> [33] Игорь Шевченко © (18.10.07 11:52)

> Ссылочку - это пожалуйста, ссылочек нам не жалко.
> http://www.rsdn.ru/res/book/prog/beck.xml?print

О, да она и в электронном виде имеется. Совсем хорошо.

> [35] boriskb © (18.10.07 11:59)

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

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

Главное, чтоб результаты не в ящик.

> Если рассматривать программу как черный ящик, то это
> роли не играет.

Ух ты!
А так можно? Не анализируя содержимое, говорить о надежности?
Есть такие методики?
Тогда я сильно отстал.

> [37] Jeer © (18.10.07 17:25)
> Главное, чтоб результаты не в ящик.

Опасаясь именно этого я написал ветку.

> [38] boriskb © (18.10.07 17:29)
> > Если рассматривать программу как черный ящик, то это
> > роли не играет.
>
> Ух ты!
> А так можно? Не анализируя содержимое, говорить о надежности?
>
> Есть такие методики?

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

> Они основываются на анлизе результатов тестирования.
> Далее включается статистика, математика, etc.

Фиии, так не интересно.
Как говорили классики:
"Тестирование не может говорить об отстутсвии ошибок. Оно может лишь сказать, что ошибки пока не обнаружены" (с)

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