Ознакомительная версия. Доступно 11 страниц из 53
Еще можно оценить производительность в плане скорости. Насколько быстро работает ваш алгоритм? Есть ли другие, которые справятся с задачей быстрее? Есть ли конкретные ситуации, когда алгоритм будет работать медленно? Насколько важны эти ситуации? Например, алгоритм быстрой сортировки quicksort обычно работает очень быстро. Однако, если одной из его версий заказать сортировку уже отсортированных позиций, работа будет идти до абсурдного медленно. То есть процесс сортировки уже расположенных по порядку позиций займет больше времени, чем сортировка бессистемно собранных позиций. Это отличный алгоритм, но было бы глупо использовать его, если вы знаете, что у вас почти все расположено по порядку. Ситуация, когда подходит один-единственный алгоритм, встречается редко. И нужно обязательно проверить, насколько он подходит для конкретного случая.
Третья, очень важная часть оценки — проверка соответствия разработанного решения поставленной цели. Как мы говорили, алгоритмы существуют для людей. Они должны работать так, чтобы мы могли их использовать, что уже обсуждалось при рассмотрении алгоритмического дизайна. Следовательно, вам необходимо оценить, насколько легко пользоваться программами, системами и решениями и какие впечатления останутся у пользователей. Вы же не хотите, чтобы у пользователей получались ошибочные результаты, они разочаровывались и злились? В ходе оценки вы, по сути, задаете вопрос: «Хорошо ли это работает, если учесть особенности людей? Учтены ли в разработанном решении наши сильные стороны и ограничены ли проблемы, связанные со слабыми сторонами?»
Предположим, вы разрабатываете медицинский прибор, который будет вводить пациентам обезболивающее. Медсестра настраивает дозу, включает подачу, и прибор в течение нескольких часов проводит внутривенное вливание лекарства. Конечно же, вам нужна функциональная корректность. Если по рецепту необходимо вводить 15,5 мг в час в течение шести часов и медсестра это запрограммировала, то прибор должен точно выполнять задачу. Кроме того, он должен работать быстро. Если медсестре придется ждать начала работы несколько минут после введения значений дозы, так дело не пойдет. Что еще важнее, он должен быть легким в использовании, уметь предотвращать ошибки и ликвидировать последствия. Если медсестра по ошибке вводит 155 мг вместо 15,5, что является опасным объемом, то аппарат должен по крайней мере предупредить медсестру и дать возможность исправить ошибку. Еще лучше, если он будет сконструирован так, чтобы вероятность таких ошибок изначально снижалась.
При оценке используются самые разные приемы и навыки. Прежде всего подразумевается строгое тестирование — очень хорошо организованная проверка алгоритма или программы в действии, которая позволяет понять, работает ли она вообще. Это предполагает проведение большого количества тестов, а не одного-двух. Кроме того, для тестирования надо выбирать хорошо продуманные ситуации, чтобы избежать сюрпризов в будущем. Для этого требуется логическое мышление, с помощью которого будет легче определить, что необходимо проверить для полного учета всех возможностей.
Существует еще и комплементарный подход к тестированию, который сводится к строгому аргументу. Вместо того чтобы запустить программу и смотреть, работает ли она, можно использовать право на аргумент. Для этого нужно с помощью логических рассуждений доказать, почему определенные тесты гарантируют, что система работает правильно. Крайнее проявление этого метода — использование только логических доказательств, являющихся разновидностью математических доказательств. Когда вы создаете алгоритм или программу, вы представляете себе причины, в соответствии с которыми, с вашей точки зрения, они должны работать. На стадии оценки вы проверяете эти причины и смотрите, не пропустили ли вы какие-то детали. Часто такие доказательства делаются при абстракции системы. Это означает, что неважные детали игнорируются, что облегчает поиски доказательства. Однако необходимо различать, когда результаты тестирования применимы к модели системы, а когда — к самой системе. Если модель правильная, это не всегда значит, что правильна и система.
Кроме того, можно оценивать части решения по отдельности. При этом используется метод декомпозиции, а проблема или система рассматривается как набор более простых элементов, с которыми работают отдельно. Поскольку части меньше самой системы, то и делать это проще. Оценка не всегда проводится, когда решение готово, — ее нужно делать и в процессе разработки решения, алгоритмов, программ и их интерфейсов. Если вы работаете над решением и создаете первые прототипы, их надо оценивать в процессе создания с разных сторон и по ходу дела решать возникающие проблемы. Здесь реально помогает декомпозиция, так как позволяет оценить каждую малую часть индивидуально сразу же по завершении. С ее помощью проверяют, работает ли каждый элемент, и исправляют ошибки еще до того, как придется думать о том, работает ли программа в целом.
Когда дело доходит до оценки соответствия решений целевому назначению, используют методы, немного похожие на тестирование, — методы наблюдения. Разница здесь в том, что для такого рода оценки нужны обычные пользователи оцениваемой системы. Эксперимент можно провести в лабораторных условиях — в сущности, это будет научный эксперимент. Другой способ — «выйти в поле» и посмотреть, как систему используют в обычной жизни. В обоих случаях мы смотрим, не пойдет ли что-нибудь не так, не столкнутся ли люди с какими-то трудностями, и все время задаем себе вопрос, можно ли изменить систему, чтобы людям стало проще с ней работать.
И опять мы используем аналитические методы и логические рассуждения. В принципе, для этого нужно привлечь специалистов, которые хорошо знают особенности людей, понимают, что делает дизайн плохим или хорошим, и могут организованно оценить системы. Их цель — предсказать потенциальные проблемы, то есть те особенности, которые могут привести к трудностям. Например, эксперты могут взять какую-то задачу и на каждом этапе спросить: «Может ли человек неправильно понять, что здесь нужно делать и как?» Эксперты используют особые принципы, например: «В случае ошибки необходимо, чтобы всегда можно было отменить последний шаг». Если они обнаруживают ситуацию, где такая отмена невозможна, то сообщают об этом как о проблеме, требующей решения.
Креативность
Создание алгоритмов — процесс творческий, и поэтому с ним тесно связан навыккреативности. Конечно же, можно продвигаться очень медленно и использовать хорошо известные приемы — так начинает большинство. Однако блестящие программисты придумывают совершенно новые алгоритмы либо для старых, либо для совершенно новых задач. Они видят возможности там, где никто их не заметил. Идеи по реализации этих концептов, конечно же, тоже требуют творческого подхода. Другие элементы вычислительного мышления также связаны с креативностью. При абстрагировании креативность помогает выделить частности, которые лучше скрыть, чтобы значительно облегчить задачу. Подобным образом для обобщения и сопоставления с образцом порой нужны творческие озарения, которые позволяют увидеть связь между совершенно разными с виду ситуациями. Как оценить, насколько легко пользоваться мобильным приложением в реальных ситуациях? В лаборатории можно проследить за всем, что делают пользователи. Вне стен лаборатории это нереально... или реально?
Ознакомительная версия. Доступно 11 страниц из 53
