Как меняется стоимость кода в зависимости от требований к его надёжности?

чем больше надёжности, тем дороже

Это ясно, а в цифрах? Где-то были цифры про NASA, но как-то не гуглятся.

Open Source на 3 порядка меньше ошибок на 1000 строк, чем в коммерческих программа

???

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

Это оказалось враньём и по ходу дела нашлись цифры и о плотности ошибок, и о стоимости программы.

???

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

таких цифр нет (если есть то они очевидно не имеют никакого смысла и нужны только маганерам без мозгов)

код обновляется КАЖДЫЙ ДЕНЬ, меняются используемые библиотеки, меняется железо и компиляторы…

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

чем больше надёжности, тем дороже

+1. Но обратное в общем случае неверно %)

меньше ошибок на 1000 строк

Что такое ошибки?

Код делает не то, что планировалось изначально?

Или код помимо того, что планировалось изначально, может делать что-то ещё?

Или анализатор кода вроде пивас, насчитал какое-то количество учасков кода, которые он считает ошибочными?

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

Open Source… , чем в коммерческих программах.

Противопоставление теплого с мягким. Опенсорс может быть и коммерческим, как и наоброт

нашлись цифры и о плотности ошибок, и о стоимости программы.

Непроверяемые и бездоказательные, или в процессе проверки продукт стал открытым?

Как бы их не меряли

В том то и дело, что можно насчитать много ошибок там, где на самом деле их нет. Всё зависит от того, как считать.

чем больше надёжности, тем дороже

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

Я помню, что это была какая-то книга, автор как-то там собирал. Что он понимал под Open Source и коммерческим - тоже написано именно там. Видимо, имелся в виду всё же «закрытый», а не «коммерческий». Возможно, что сведения о некоторых видах проприетарного кода можно получить из каких-то отчётов, когда организация A проверяет организацию Б. Или же поверить на слово представителям организации - автора закрытого кода.

Вордпресс (ядро) надежнее высеров провинциальный говностудий - это точно.

О, вот один хвостик нашёл:

https://companies.dev.by/news/issledovanie-kachestvo-koda-otkrytyh-produktov-ne-huzhe-kommercheskih

В рамках совместного проекта компании Coverity и Министерства внутренней безопасности США был проведен анализ кода открытого и проприетарного программного обеспечения. После проверки миллионов строк кода был сделан вывод, о котором давно подозревают многие инженеры-программисты: качество открытых программных продуктов не уступает закрытому коду коммерческих. В частности, было проверено более 37 млн. строк активных проектов с открытым исходным кодом и более 300 млн. строк кода актуальных проприетарных решений. Среднее число ошибок составило 0,45 на тысячу строк для открытого кода и 0,64 для закрытых продуктов.

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

когда организация A проверяет организацию Б

то наблюдатель В не при делах, и выводы бессмысленны, как минимум ненаучны

Нашёл, кстати, фразу:

Исследование исходного кода Linux имеет 0.17 ошибок на 1000 строк кода, в то время как несвободные программы обычно оценивают 20-30 ошибок на 1000 строк.

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

Вот тут пишут - наценка для соответствия MISRA - порядка 10%

https://stackoverflow.com/questions/62946/misra-standard-for-embedded-software

^ всерьез еще и пишет lol lul проорал в голосину

что если этот чел какойто HR или еще хуже «глава отдела кадров» который пытается высрать задание для HR-ов

и будет «опираться» на эту статистику при отборе кандидатов - типо у кандидатов спрашивать «а сколько у вас опенсурс репов и приватных продакшен кода» делить одно на другое и считать среднее количество ошибок исходя из этого

и таким образом выводить «качество кода этого кандидата»… я много бреда конечно видел на собеседованиях, связянного с бредовой оценкой кандидатов, но такого еще нет 🤣🤣🤣

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

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

Все относительно, короче говоря

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

Мне нужна оценка снизу, поскольку я как раз пытаюсь обосновать, что надёжность стоит дорого. Приведи любые другие оценки из более-менее нормальных источников - приму к рассмотрению. Есть ведь и другая сторона - конторы на госзаказах склонны пилить в любой стране. Они обоснуют, что надёжность стоит, скажем, 100x, за 10x сделают что смогут, 90x украдут. Равно как и любой опытный разработчик на автомате умеет обосновывать, что задача офигеть какая сложная и нужно офигеть сколько времени на её решение, и, соответственно, распилит отведённое время.

обосновать, что надёжность стоит дорого

Как только дадут определение «надежность». И тут вдруг окажется, что само определение «надежности», окажется реализации «надежности».

Как с микроядрами с доказанной корректностью. Само ядро несколько килострок, а проверка - сотни килострок.

определение «надежности» окажется сложнее реализации «надежности».

Низкоуровневого — идет круто вверх; высокоуровневого — сразу в бесконечность.

Вот как ответить на твой вопрос? Там, где нужна надежность, там нет вариантов делать без нее от слова совсем. Не то что на ненадежную АЭС или машину — на ненадежную libc тебе уже ценника не будет. А для всякого фуфла она равна себе нулю и равна, и поднять ее на 10% стоит 0 рублей соответственно.

Если мы говорим про программы для NASA или тому подобных контор (ESA или там Роскосмос), то там жизнь чуть иная. Плотють не за количество строк кода или, прости Господи, новые версии библиотек, а натурально за то, чтобы ты как разработчик и разрабатываемое тобой ПО разрабатывалось строго по стандартам.

Для ESA, как например, есть стандарт ECSS-E-ST-40-бла-бла. Для российских реалий ГОСТы, номера которых я запамятовал уже. Они определяют порядок работы. В России должны быть сначала аванпроект, потом техзадание, потом что-то еще, выпуск документации. В ЕСА-вских стандартах это называется Phase A, Phase B и т.д. На каждом этапе разработчик ПО должен написать кое-какие официальные документы (вплоть до перечня организационных работ в в военное или около-военное время), согласовать их со всеми участниками, потом проводить испытания ПО и сдавать его. Эта вся тягомотина, хотя и выглядит почти полностью бесполезной и по факту таковой и является, одним человеком совершенно невыполнима. Поэтому ПО, которое например куда-то там летит в ракете делается организацией где по факту код писать может полтора-два человека, а вовлечено людей будет вагон.

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

То есть, тебе нужна не столько сама оценка, сколько ее обоснование перед контрагентом? Это уже совсем другая задача! Здесь многое зависит уже от контрагента, от его личностных особенностей. Впрочем, я все равно ничего в этих цифрах с потолка не понимаю. Поэтому советов никаких давать не буду)

Не то что на ненадежную АЭС или машину — на ненадежную libc тебе уже ценника не будет.

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

Нет, мне нужна честная оценка.

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

И как выражать цену «надежности»? В мешках риса?

Придумал ещё один способ оценки - в отдельных областях применяется трёхкратное резервирование.

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

Если серьезно, открытость ПО ортогональна его качеству. Это если одним предложением.

Если более развернуто, вот подсказка: какие такие новые инструменты/модели/методологии/стандарты появились в опенсорс, которых не было в проприетарном софте, и которые могли принципиально повлиять на соотношение цена/качество создаваемого продукта?

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

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

Там и ПО реализуется (пишется) разными командами, так что надёжность реально повышается.

Если серьезно, открытость ПО ортогональна его качеству. Это если одним предложением.

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

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

Всё можно рассмотреть с разных сторон. Во-первых, кто эти люди, которых порабощают и о которых ты говоришь?

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

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

И как выражать цену «надежности»? В мешках риса?

По разному можно. Меня интересуют примеры. Я знаю немного про сертификацию от Пентагона, от ФСТЭК (но не расскажу), немножко про MISRA, немножко про правила кодирования в NASA, вот про российские АЭС немного знаю. Какие-то цифры (цифру x3) здесь можно извлечь только из примера с АЭС. Вот знаю оценку по статическому анализу от coverity (весьма паршивая метрика). Могу свою предложить: количество найденных уязвимостей за год на страницу руководства пользователя или на 1000 строк кода. Для самолётов - количество аварий на километр пролёта (но тут опять же нужно всё это уравнивать по классам самолётов, условиям эксплуатации и т.п). Для электростанций - можно померять по количеству заболевших раком на кВт*ч (но поди ещё докажи, что они заболели именно от АЭС, там пиарщики и юристы такие, что сам окажешься заражателем). Для банков - да, можно мерять по количеству украденных мешков риса. Статистика по банкам, кстати, не особо: они возмещают ЕМНИП только 1/7 денег, украденных мошенниками у клиентов. Но это всё не системные знания. А где-то такие знания есть.

Экс-кроссоверец написал:

Applied Software Management, Capers Jones

Как меняется стоимость кода в зависимости от требований к его надёжности?

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

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

Если чесТно хз, но думаю от 100Круб в зависимости от пафосности бумажки и объёма кода.

пс. тыкнул в первую попавшуюся ссылку там, примерно, такие же цифры - https://rtmtech.ru/services/audit-programmnogo-koda/

пс2 рассчитать достаточно просто - навешиваешь на себя такую задачу, примерно оцениваешЪ, сколько у тебя она займёт, умножаешь на твою ставку и умножаешь на коэффициент сисекЪ.

Сколько стоит типичный финансовый аудит по сравнению с годовым доходом?

Этот вопрос, где есть типичность. А какая типичность в разработке ПО?

Ну как, типичность вполне есть. Есть классы приложений, и в каждом классе десятки - миллионы экземпляров.

Ну там написано «от». Автомобили в салоне тоже «от», но в реальности цифры другие :) Но спасибо всё равно.

Уменьшение количества ошибок в 2 раза увеличивает стоимость на порядок

Откуда такая оценка?

Классы приложений

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

Что сложнее: реализовать «надежность» или определить «надежность»?

Это не оценка, это - условие договора

ядро/дырявые плагины

Ну, у надёжности два разных интересующих меня направления:

• Чтобы АЭС не взорвалась сама по себе
• Чтобы АЭС не взорвалась из-за закладки в ПО

Спасибо! Вот мне и нужна оценка того, насколько это дороже выходит. Если «два человека» и «вагон», то в вагоне 54 места, значит, в 26 раз дороже.

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

Вы наверно не поняли, в чём моя претензия к изначальному вопросу.

Вот для примера:

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

В данном случае, стат. анализатор покажет, что есть 2 ошибки:

1. Кусок кода закоментирован.

2. В коде есть функция, которая никогда не вызывается.

Действительно ли это 2 ошибки? или ошибок на самом деле нет?

Я тоже так делаю, часто. Говорю себе: «это временно». Но это, как минимум, одна ошибка. Можно ли закомментировать код - это вопрос соглашения, а вот невызывающихся функций быть в коде не должно. К надёжности самой проги это, впрочем, отношения не имеет. Здесь уже возникает изъян в постижимости данной программы, поскольку не вызывающаяся функция может вводить в заблуждение. Я сформулировал вопрос намеренно широко, потому что мне нужны любые более-менее подходящие ответы. Единственное, что про открытость-закрытость кода к вопросу не относится, но я думал, вдруг кто вспомнит прошлое обсуждение.

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