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