БЕСЕДЫ О ПРОГРАММИРОВАНИИ
В прошлой колонке я рассказывал об эффекте Хоторна, указав, что данные получены в результате исследований, проведенных в 50-х годах в Калифорнии. В статье, из которой я почерпнул эти исторические сведения, как оказалось, была приведена ошибочная информация: эксперименты на самом деле имели место тридцатью годами раньше и не в Калифорнии, а в Иллинойсе. Я сожалею, что моя предыдущая публикация теперь стала еще одним источником неверной информации в общей базе данных.
В той статье основное внимание уделялось проблемам, возникающим в ходе исследований из-за воздействия человеческого фактора. Теперь давайте взглянем на другие проблемы, которые возникают даже в тех случаях, когда система не предусматривает участия одушевленного пользователя. К примеру, тестирование "холодной" загрузки дает воспроизводимые результаты, однако не имеет смысла для круглосуточно работающих систем. Такие системы работают в одном устоявшемся режиме, и все наиболее используемые ресурсы находятся под рукой в буферах разного типа.
Чтобы тесты были реальными, испытатель должен определить рабочий цикл приложения - как долго приложение остается в одних условиях, прежде чем адаптируется к новым требованиям? И как решить, какую единицу измерения скорости следует избрать? Если мы создаем систему не на базе одной многократно повторяющейся задачи, тогда получится несколько оценок, и все их нужно как-то скомбинировать, превратив в единый общий показатель. В подобном случае недостаток статистических данных может быть хуже, чем их отсутствие.
Если вы ничего не знаете о статистических методах, вам придется расположить результаты всех тестов для каждого варианта рядом. Тому, кто принимает решение, останется связать все имеющиеся детали воедино, чтобы сделать выбор. Это не добавит вам популярности, зато может избавить от неприятностей.
Если вы знаете достаточно, для того чтобы рискнуть, вы выведете некое среднее. А что, если система А выполняет одну задачу, грубо говоря, мгновенно, поскольку специально оптимизирована для нее, и при этом требует на 20% больше времени, чем система В на выполнение каждой из четырех оставшихся? Простой подсчет покажет, что система А в среднем на 4% быстрее. Более полное заключение сведется к тому, что система А медленнее выполняет четыре из пяти типичных запросов. Если вы знаете чуть больше, вы определите дисперсию, а также оценку среднего (последнее -академическое выражение для обозначения средних величин, срединного значения и т.п.). Самой распространенной единицей измерения дисперсии стал параметр с предостерегающим названием "стандартное отклонение", который легко рассчитывают миллионы калькуляторов и электронных таблиц.
Больше всего я люблю рассчитывать стандартное отклонение для оценок, которые были придуманы для наших знаменитых "чемпионатов Тестового центра PC Week Labs". Обычно во время такого мероприятия, занимающего не один день, мы собираем несколько десятков оценочных показателей от нескольких десятков судей и стараемся решить, какой продукт должен получить звание абсолютного победителя.
В случаях, когда один продукт заслуживал самых высоких и самых низких оценок, а другой был более-менее удовлетворителен для всех, я всегда ненавидел саму идею о том, чтобы утверждать, что один продукт превосходит другой на основании более высокого среднего балла. Мы решаем эту проблему, отнимая от среднего значения каждого измерения по 0,4314 стандартного отклонения. Теоретически это соответствует ситуации, когда на каждого судью, который дал бы более низкую оценку, приходится два, которые дали бы более высокую. В принципе такую технику можно применить при подсчете пропускной способности или к другим показателям. Я говорю "в принципе", поскольку эта система подсчетов требует большого допущения: разброс данных должен соответствовать нормальному распределению Гаусса. Это допущение работает для наборов данных из нескольких десятков величин, однако не подходит для наборов меньшего размера. В следующий раз мы поговорим о работе с ограниченным набором данных.
Связаться с Питером Коффи можно через MCI Mail по адресу: 357-1756 или через CompuServe по адресу: 72631,113.
Питер Коффи
