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

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

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

Третья, очень важная часть оценки — проверка соответствия разработанного решения поставленной цели. Как мы говорили, алгоритмы существуют для людей. Они должны работать так, чтобы мы могли их использовать, что уже обсуждалось при рассмотрении алгоритмического дизайна. Следовательно, вам необходимо оценить, насколько легко пользоваться программами, системами и решениями и какие впечатления останутся у пользователей. Вы же не хотите, чтобы у пользователей получались ошибочные результаты, они разочаровывались и злились? В ходе оценки вы, по сути, задаете вопрос: «Хорошо ли это работает, если учесть особенности людей? Учтены ли в разработанном решении наши сильные стороны и ограничены ли проблемы, связанные со слабыми сторонами?»

Предположим, вы разрабатываете медицинский прибор, который будет вводить пациентам обезболивающее. Медсестра настраивает дозу, включает подачу, и прибор в течение нескольких часов проводит внутривенное вливание лекарства. Конечно же, вам нужна функциональная корректность. Если по рецепту необходимо вводить 15,5 мг в час в течение шести часов и медсестра это запрограммировала, то прибор должен точно выполнять задачу. Кроме того, он должен работать быстро. Если медсестре придется ждать начала работы несколько минут после введения значений дозы, так дело не пойдет. Что еще важнее, он должен быть легким в использовании, уметь предотвращать ошибки и ликвидировать последствия. Если медсестра по ошибке вводит 155 мг вместо 15,5, что является опасным объемом, то аппарат должен по крайней мере предупредить медсестру и дать возможность исправить ошибку. Еще лучше, если он будет сконструирован так, чтобы вероятность таких ошибок изначально снижалась.

При оценке используются самые разные приемы и навыки. Прежде всего подразумевается строгое тестирование — очень хорошо организованная проверка алгоритма или программы в действии, которая позволяет понять, работает ли она вообще. Это предполагает проведение большого количества тестов, а не одного-двух. Кроме того, для тестирования надо выбирать хорошо продуманные ситуации, чтобы избежать сюрпризов в будущем. Для этого требуется логическое мышление, с помощью которого будет легче определить, что необходимо проверить для полного учета всех возможностей.

Существует еще и комплементарный подход к тестированию, который сводится к строгому аргументу. Вместо того чтобы запустить программу и смотреть, работает ли она, можно использовать право на аргумент. Для этого нужно с помощью логических рассуждений доказать, почему определенные тесты гарантируют, что система работает правильно. Крайнее проявление этого метода — использование только логических доказательств, являющихся разновидностью математических доказательств. Когда вы создаете алгоритм или программу, вы представляете себе причины, в соответствии с которыми, с вашей точки зрения, они должны работать. На стадии оценки вы проверяете эти причины и смотрите, не пропустили ли вы какие-то детали. Часто такие доказательства делаются при абстракции системы. Это означает, что неважные детали игнорируются, что облегчает поиски доказательства. Однако необходимо различать, когда результаты тестирования применимы к модели системы, а когда — к самой системе. Если модель правильная, это не всегда значит, что правильна и система.

Кроме того, можно оценивать части решения по отдельности. При этом используется метод декомпозиции, а проблема или система рассматривается как набор более простых элементов, с которыми работают отдельно. Поскольку части меньше самой системы, то и делать это проще. Оценка не всегда проводится, когда решение готово, — ее нужно делать и в процессе разработки решения, алгоритмов, программ и их интерфейсов. Если вы работаете над решением и создаете первые прототипы, их надо оценивать в процессе создания с разных сторон и по ходу дела решать возникающие проблемы. Здесь реально помогает декомпозиция, так как позволяет оценить каждую малую часть индивидуально сразу же по завершении. С ее помощью проверяют, работает ли каждый элемент, и исправляют ошибки еще до того, как придется думать о том, работает ли программа в целом.

Когда дело доходит до оценки соответствия решений целевому назначению, используют методы, немного похожие на тестирование, — методы наблюдения. Разница здесь в том, что для такого рода оценки нужны обычные пользователи оцениваемой системы. Эксперимент можно провести в лабораторных условиях — в сущности, это будет научный эксперимент. Другой способ — «выйти в поле» и посмотреть, как систему используют в обычной жизни. В обоих случаях мы смотрим, не пойдет ли что-нибудь не так, не столкнутся ли люди с какими-то трудностями, и все время задаем себе вопрос, можно ли изменить систему, чтобы людям стало проще с ней работать.

И опять мы используем аналитические методы и логические рассуждения. В принципе, для этого нужно привлечь специалистов, которые хорошо знают особенности людей, понимают, что делает дизайн плохим или хорошим, и могут организованно оценить системы. Их цель — предсказать потенциальные проблемы, то есть те особенности, которые могут привести к трудностям. Например, эксперты могут взять какую-то задачу и на каждом этапе спросить: «Может ли человек неправильно понять, что здесь нужно делать и как?» Эксперты используют особые принципы, например: «В случае ошибки необходимо, чтобы всегда можно было отменить последний шаг». Если они обнаруживают ситуацию, где такая отмена невозможна, то сообщают об этом как о проблеме, требующей решения.