Традиционный процесс разработки программных изделий с первых дней его существования был таким:

• программирование,
• устранение дефектов,
• доводка.

С развитием высоких технологий и выдвижением на первый план проблемы взаимодействия пользователя с изделием этот процесс модифицируется: в него включается дополнительная форма тестирования – юзабилити-тестирование.

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

Рис. 2.2. Место проектирования в общем процессе разработки

По сравнению с традиционной эта схема означает коренные перемены в процессе разработки ПО, поэтому, несмотря на признанную необходимость таких перемен, традиционная последовательность сохраняет свои позиции. Причины здесь следующие:

• стремление к сохранению привычного порядка действий (о чем уже упоминалось);

• неприятие программистами проектирования перед программированием как угрозы важности их роли (что не соответствует действительности, поскольку проектирование не подменяет программирования);

• миф о непредсказуемости рынка, из которого следует, что проектирование просто бесполезно.

И, наконец, на примере компании Microsoft Купер рассматривает итеративный процесс разработки ПО как стратегию, основанную на изморе, но подаваемую как средство достижения качественного взаимодействия. Слабым местом такой стратегии как раз является следование схеме, ставящей программирование перед проектированием взаимодействия. Резюме. Высокое качество интерфейса может быть достигнуто в первую очередь тщательным проектированием. Проектирование должно предшествовать программированию и выполняться специалистами по взаимодействию.· Конечная цель проектирования интерфейса состоит в том, чтобы выявить характеристики взаимодействия, поддающиеся достаточно строгому описанию, и заложить нужные свойства в проект. Для этого необходимо знание:

• специфических особенностей восприятия и обработки информации человеком;

• специфических особенностей взаимодействия человека с компьютерными продуктами;

• общих принципов и методов проектирования (применимых к любой области).

Реализация интерфейса предполагает также:

• знание возможностей и умение использовать существующие инструменты разработки;
• умение реализовывать собственные, нестандартные элементы.

Но несмотря на все эти проблемы, тенденции развития высоких технологий выводят проектирование на первый план и ставят его в процессе разработки проектирования перед программированием.

Что может заменить проектирование? В кн. Алана Купера проведен достаточно детальный анализ видов и форм деятельности, претендующих на роль проектирования, и убедительно показана необоснованность претензий. Иначе говоря, этап проектирования должен быть самим собой и выполняться в соответствии со своей спецификой. Здесь очень кратко приведем описание упомянутых видов деятельности и результаты их анализа. Это:

юзабилити-тестирование:

• постфактум – не может сильно повлиять на продукт;
• до программирования – скорее чистое исследование;
• интегрированное в проектирование – может быть полезным, но не заменяет
• проектирования;
• многопрофильные команды – неэффективны из-за различия целей участников;
• проектирующие программисты – обладают иной культурой, не соответствующей решению задач взаимодействия; в итоге проект отображает прежде всего культуру программирования и индивидуальность самого программиста;
• руководства по стилю – могут помочь, но не решают проблем взаимодействия; реально такие руководства являются скрытой формой принуждения к соблюдению стандарта, навязываемого владельцами платформ (Microsoft и Apple)
• фокус-группы [1] – не годятся для оценки программных продуктов из-за консервативности;
  
• визуальное проектирование как доминирующая форма взаимодействия с компьютером - визуализация и проектирование интерфейса дизайнером не решает проблем проектирования взаимодействия;
• промышленный дизайн - имеет иную задачу и нацелен на иные, отличные от программных объекты;
• собственно технологии – каждая новая технология (распознавания голоса, рукописного текста) лишь углубляет проблему взаимодействия человека с компьютером, поскольку требует создания новых программных систем.

  ---

  [1] Метод фокус группы применяется для проведения качественных маркетинговых исследований. Он основан на особой форме глубинного интервью, в ходе которого участники фокус-группы под руководством ведущего (как правила, опытного психолога или маркетолога)обмениваются мнениями о том или ином продукте или услуге. – http://www.siora.ru/marketing/focus_group.aspого текста) лишь углубляет проблему взаимодействия человека с компьютером, поскольку требует создания новых программных систем

Особенности обработки информации человеком и особенностей взаимодействия человека с компьютерным продуктами тесно взаимосвязаны. Различие здесь состоит в том, психологические характеристики процессов восприятия, запоминания и обработки информации в случае проектирования компьютерных продуктов выступают как данность. Эти характеристики надо знать и учитывать. Если же речь идет о взаимодействии, то характеристики и качество последнего определяются степенью соответствия «компьютерной стороны» «человеческой», т.е. данностью уже не являются и определяются качеством проекта, степенью учета психологических характеристик (вкупе с целями человека). Так, развитие информационных технологий пошло по тому пути, который мы имеем, и речь может идти только о специфике взаимодействия человека с компьютерными продуктами такими, как они есть. Другое дело, что коль скоро речь об этом идет, это взаимодействие нас не устраивает и исследуется с целью его улучшения. Методы проектирования в кратком изложении базируются на определении классов пользователей и анализе их целей. Здесь подходы различных авторитетов практически едины (об этом неоднократно упоминалось). Ориентиром может служить язык UML как средство описания анализа проблемной области (прежде всего Use Case Diagrams). Рассмотрение любых положений, касающихся разработки, должно идти в русле проектирования.

Приведенные в списке требования перечислены в том порядке, в котором далее будет вестись их рассмотрение.