RC1, RC2, RC3, alpha, beta vs Версионность софта. Часть 2

11.11.2007

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

Как мне тут верно подсказали, под всеми этими RC1 или RC2 есть некие математические и логические основания. Например, если количество сообщений об ошибках падает на 50% и нет ни одной найденной критической ошибки – можно выпускать RC1. И так далее. Вроде бы все логично. И по сути никакой разницы в нумерациях:

  • RC1 1.5, RC1 1.6, RC1 1.7 …
  • 1.1.12, 1.1.13, 1.1.14 …

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

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

А раз нельзя применять какие-то умные выкладки по теории нахождения ошибок, то нужно просто нумеровать. Как – не важно. Я уже приводил пример линукса в прошлой заметке.


Комментирование этой статьи закрыто

Комментарии [4]

  1. Ноя 14, 22:25 , Black Ice

    Ты правильно заметил, количество ошибок часто разниться “от смены к смене”, но каждый сам использует свою нумерологию, либо заказчика-программиста.

  2. Ноя 22, 21:33 , RuX

    Ну это только по очень слабой идее. В действительности же процесс нахождения ошибок отнюдь не случаен и даже закономерен, если не говорить о тестировании софта конечными пользователями.
    Практически в любой компании по разработке софта (даже бесплатного) присутствует целый отдел тестирования, оснащенный достаточным количеством машин с различными ОС. У меня знакомый работет уже около 8 лет в области тестирования различных программных продуктов и постоянно развивается, изучая новейшие алгоритмы и специализированный софт по выявлению различного рода ошибок. Существуют целые теории с “умными выкладками” и целые системы универсальные, приминяемые в различных сферах для выявления ошибок. В некоторых случаях разрабатываются специальные алгоритмы для специфических .
    Так что нумерация вполне оправдана, и если кол-во обнаруживаемых ошибок подает на 50% (цифра немаленькая), то это о многом говорит.

  3. Ноя 22, 22:35 , Dead Krolik

    RuX цифра действительно большая, и теории есть. Я даже книжки какие-то видел в сети.

    Я даже согласен признать себя чайником. Я ничего в тестировании софта не понимаю.

    Но блин, ну не верю что может быть закономерность. По идее проги и теории вычисляют только типичные ошибки, но сколько же нетипичных. И причем одна нетипичная может легко перекрыть по важности все что нашли до нее. Ну а вдруг? А уже RC1 выпустили. Не знаю, может и правда я чайник :)

  4. Мар 3, 03:25 , kossmoss

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

    В ядерной физике есть понятие периода полураспада – так вот оно как раз сравнимо с величиной этих совокупных усилий тестеров.

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

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

Комментирование этой статьи закрыто

Кто я


Возраст: 23
Профессия: заяц


Категории


Полезные ссылки


Стишок

Зайчик-зайчик, скок-поскок!
Н-нна тебе дробину в бок!
Не с капустой же мы будем
Жрать на Новый год пирог...

eu-shestakov.livejournal.com