LINUX.ORG.RU
ФорумTalks

[Качество ПО][Анализ]Анализ качества ПО

 


0

0

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

N^a * P^b / {cos((t-6)/12*%pi)+1}^c / exp(d*x) = const

где N - число глюков, P - производительность t - время суток в 24-ти часовом формате x - время до сдачи ИДЗ (РГЗ, курсового и т.п.). a, b, c, d - эмпирически определяемые константы.

Буду рад конструктивной критике и дополнениям.

Реквестирую в тред ведро столичного, для полного взаимопонимания с топик-стартером

reliktt
()
Ответ на: комментарий от Nixopatolog

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

wfrr ★★☆
()
Ответ на: комментарий от anotheranonymous

Ну а в чём же ещё?!

PS А я не умею проводить арифмитические операции над временем "в 24-ти часовом формате". А уж потом и косинус этого брать... брррр...

narayan
()

> a, b, c, d - эмпирически определяемые константы.

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

Terrens
()
Ответ на: комментарий от igels

>откуда косинус

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

> дробь трехэтажная

Нет, с чего бы это? Просто поделить, потом ещё раз подеоить. Порядок действий...

Nixopatolog
() автор топика
Ответ на: комментарий от narayan

>в 24-ти часовом формате

Согласен, криво. Имелось ввиду "количество часов от последней полуночи".

Nixopatolog
() автор топика
Ответ на: комментарий от Terrens

Эти константы определяются для каждой отдельной пары ПРОГРАММА-USER из результатов экспериментов.

Nixopatolog
() автор топика
Ответ на: комментарий от Nixopatolog

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

может у вас глюки и от фазы луны зависят?

есть какое-нибудь теоретическое обоснование этой формулы?

cvb
()
Ответ на: комментарий от cvb

Чувствую нет, ибо формула, видимо, была создана в процессе набивания поста :D

fukazzz
()
Ответ на: комментарий от cvb

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

>может у вас глюки и от фазы луны зависят?

Вполне возможно. От солнечной активности тоже наверяка зависит. Только эти зависимости малы и крайне мало будут влиять на общий результат. Ещё великий Ландау говорил: "Главное в физике — это умение пренебрегать!"

Nixopatolog
() автор топика
Ответ на: комментарий от Nixopatolog

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

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

>Ещё великий Ландау говорил: "Главное в физике — это умение пренебрегать!"

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

cvb
()
Ответ на: комментарий от Nixopatolog

>знаний о работоспособности ПО. 
твои познания отсутствуют.
[контекс := пост автора]
качество := производительность и число глюков
производительность := эмпирическая оценка автора
число глюков := эмпирическая оценка автора
анализ := пустое множество
------------------------вычисляем----------------
[Качество ПО][Анализ]Анализ качества ПО => [эмпирическая оценка автора & эмпирическая оценка автора ПО][{}]{}эмпирическая оценка автора & эмпирическая оценка автора ПО => эмпирическая оценка автора ПО

итого: ничем не обоснованные рассуждения автора по теме, в которой он не шарит

dimon555 ★★★★★
()
Ответ на: комментарий от dimon555

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

Nixopatolog
() автор топика
Ответ на: комментарий от cvb

>а вы все никак не поделитесь с сообществом выводом своей формулы

Хотите обоснования - чтож, вы их получите на конкретном примере: что качается первой части формулы - рассмотрим любую операционную систему: это может быть что угодно, начиная Windows и заканчивая Ubuntu: в каждой новой версии исправляются ошибки: это бесспорно, при этом производительность обычно заметно падает падает. Потом производят какое-нибудь вливание свежего кода (непременно несущее новые ошибки), и скорость вновь поднимается. Всё это станет вам ясным как божий день: стоит только задуматься. Далее: концентрация внимания пользователя на протяжении суток непостоянна: она снижается в ночные часы. Естественно, чем невнимательнее пользователь, тем более неожиданные результаты выдаёт программа. Это отражается гармонической функцией с максимумом в ночные часы и минимумом в вечерние. Что касается экспоненты - если бы вы учились в ВУЗе, то знали бы, что когда приходит срок сдачи и необходимо срочно что-то сделать, вся баги просыпаются и как по команде всплывают на поверхность.

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

Nixopatolog
() автор топика
Ответ на: комментарий от Nixopatolog

Кстати, пример применения формулы в студию, pls.

igels
()
Ответ на: комментарий от Nixopatolog

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

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

>Далее: концентрация внимания пользователя на протяжении суток непостоянна: она снижается в ночные часы. Естественно, чем невнимательнее пользователь, тем более неожиданные результаты выдаёт программа.

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

>Что касается экспоненты - если бы вы учились в ВУЗе, то знали бы, что когда приходит срок сдачи и необходимо срочно что-то сделать, вся баги просыпаются и как по команде всплывают на поверхность.

ну так это плохой менеджмент проекта, опять же нельзя распротранить на весь софт

так а формальное доказательтво будет?

cvb
()

>N^a * P^b / {cos((t-6)/12*%pi)+1}^c / exp(d*x) = const

где N - число глюков, P - производительность t - время суток в 24-ти часовом формате x - время до сдачи ИДЗ (РГЗ, курсового и т.п.). a, b, c, d - эмпирически определяемые константы.

Ну хорошо, N - число глюков. За какой период? С какими последствиями? Летальные для работы, или так, чудит себе прога и фиг с ней?

Опять же, производительность - в каких единицах? Как определяется?

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

igels
()
Ответ на: комментарий от cvb

Поясняю ещё раз: рассматривается не какая-то формальная программа в идеальных условиях, а вполне конкретная система ПРОГРАММА-ПОЛЬЗОВАТЕЛЬ. Под глюками понимаются факты получения пользователем неожиданных результатов (то, что пользователь воспринимает как глюк)

Формула действительно не претендует на полноту: я это написал в самом начале

>не все пользователи работают днем

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

>ну так это плохой менеджмент проекта

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

>так а формальное доказательтво будет?

Не будет - те тот предмет. Откройте для себя области знаний, где формальные доказательства просто невозможны. Возможна лишь проверка опытом и здравым смыслом. С последним, ИМХО, в формуле всё впорядке.

Nixopatolog
() автор топика
Ответ на: комментарий от igels

>лучше приплести какие-нибудь характеристики железа

О! Спасибо за отличную идею. Думаю, ещё обязательно надо учесть время, прошедеше от последнего релиза программы.

>ВАХ блока питания

А это как прикажете измерять? И что это даст? Лучше уж передаточные характеристики.

>Опять же, производительность - в каких единицах? Как определяется?

Ну для графических приложений - в FPS (кстати, история с драйверами Intel в новой Ubuntu вполне вписывается в мою формулу). Для ООо - во времени загрузки. Вот те коэффициенты, стоящие в степени именно для того и нужны, чтобы дать возможность использовать различные показатели производительности.

>N - число глюков. За какой период?

За определённый конечный. Формула в общем виде.

>Летальные для работы, или так, чудит себе прога и фиг с ней?

А вот это уже хорошая идея: т.е. глюки надо измерять не в штуках, а в чем-то отражающем их критичность. Можно на пример измерять в BSOD'ах. Можно даже условные кратные единицы ввести: Выход из строя железа - КилоБСОД, Вылет ООо = 1 милиБСОД, ошибка отрисовки = 1 микроБСОД, аська глючит = 1 наноБСОД.

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

Nixopatolog
() автор топика
Ответ на: комментарий от Black_Shadow

>Там надо ещё на количество литров помножить.

Мне кажется зависимость будет нелинейной с ярко выраженным изломом на некотором уровне.

Nixopatolog
() автор топика
Ответ на: комментарий от Nixopatolog

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

Ага, куча мелких глюков может испортить нервов не хуже одного BSOD (кстати, *никсы рассматриваем?:)))

igels
()
Ответ на: комментарий от Nixopatolog

Кстати, куда приложить вот такую штуку - документ, сделанный в NeoOffice, сохранённый в odt, некорректно отображается в MSWord (совсем не отображается), сохранённый в его формате (doc) - таблицы разъезжаются - чей косяк? По какой проге считать глючность?

igels
()
Ответ на: комментарий от Nixopatolog

>А вот это уже хорошая идея: т.е. глюки надо измерять не в штуках, а в чем-то отражающем их критичность. Можно на пример измерять в BSOD'ах. Можно даже условные кратные единицы ввести: Выход из строя железа - КилоБСОД, Вылет ООо = 1 милиБСОД, ошибка отрисовки = 1 микроБСОД, аська глючит = 1 наноБСОД.

всё давно украдено ищи по надёжность программного обеспечения, там есть и классификация ошибок и всё такое прочее.

dimon555 ★★★★★
()

> t - время суток в 24-ти часовом формате

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

gods-little-toy ★★★
()

ваша формула говно. вы ничего не понимаете в карме тестировщика

vostrik ★★★☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.