Почему старые модели оценки надёжности не работают

Вот напомнила о себе старая добрая модель Миллса для оценки количества ошибок в программе. Простая и эффективная как гвоздь она была весьма хороша для своего времени. Как и модели роста надёжности. Сегодня же со всеми этими моделями одна и та же проблема — они не работают.

Причина лежит на поверхности. Эти модели создавались исходя из реалий своего времени, а в семидесятые годы прошлого века программное обеспечение разрабатывалось несколько иначе нежели это делается сегодня. Тогда в эпоху больших ЭВМ и языков программирования низкого уровня разработка почти всегда проходила по одному и тому же сценарию: постановка задачи, типа проектирование, кодирование, тестирование, эксплуатация. Для такой, с позволения сказать, «методологии» даже придумали название: модель водопада. На большее в то время никого не хватало. Оно и понятно! Какие уж там методологии, когда каждый байт памяти на счету, а уровень надёжности элементной базы аппаратуры делает процессы эксплуатации и ремонта оборудования фактически неразделимыми?! Если программное обеспечение разрабатывается таким образом, то почти все предположения моделей роста надёжности более или менее выполняются, и применить модель Миллса несложно, посредством внесения искусственных ошибок перед началом фазы тестирования.

А потом всё изменилось. На смену старым негибким методологиям пришли гибкие такие как, например, экстремальное программирование. Их особенность в том, что программное обеспечение разрабатывается на протяжении ряда итераций. Такие итерации могут быть короткими (пара недель) и не очень (от одной версии до следующей). В течение каждой итерации разрабатывается относительно небольшой кусок функциональности, и разработка эта проходит всё те же этапы: проектирование, кодирование, тестирование, но в меньшем масштабе. Вот и получается, что применение старых моделей к таким проектам порождает слишком много вопросов без ответов. Когда вносить искусственные ошибки, применяя модель Миллса? В конце итерации? Делать ли это каждую итерацию? Как быть если не обнаружены все искусственные ошибки, а сроки итерации чётко регламентированы? Тоже с моделями роста надёжности. Ошибки вносятся и исправляются каждую итерацию, а значит функция роста надёжности будет иметь ступенчатый вид. Под такую экспоненту или логарифм уже не подогнать. И что остаётся делать? Использовать сложную функцию с десятью параметрами, каждый из которых ещё и оценивать как-то надо?! Да кому это нужно?! Научное сообщество дружно решило, что проще придумать новые модели, чем переделывать старые. Так появились регрессионные модели и за последние годы столько всего написано на эту тему, что про старые модели уже почти никто и не вспоминает.

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