Сегодня:

Главнвя. История. Род Аексеевых. Алексеев Н.А. Кащенко П.П. Психиатрия в России. Меценаты строительства. Здравохранение в Москве. Храм больницы. Ландшафт. Фотогаллерея.

КЛИЕНТУРА:

Практика. Впечатления. О себе.

ЮМОР:

Анекдоты. Юмор. Рисунки.

НОВОСТИ:

Сообщение.

Сайт основан 02.10.2000 года.

Обновлено 12.02.2005г.

Как я уже говорил, создание кода по отношению к проектированию – все равно что заливка бетонной смеси в строительстве. Независимо от профессионализма проектировщика и применяемых методов, если создание кода уже началось, воздействие проектирования окажется пренебрежительно мало. Фундаментальная предпосылка включения проектирования взаимодействия в процесс разработки про грамм заключена в предшествовании проектирования программированию. Очевидно, что я защищаю целеориентированное проектирование, однако любой системный процесс проектирования, предшествующий программированию, будет эффективнее любого процесса, следующего за программированием.
Проектирование взаимодействия до начала программирования означает коренные перемены в процессе разработки программного обеспечения. Естественно, такие перемены затрагивают программистов, и они видят для себя угрозу. До этого они были первыми, а следовательно, и самыми важными. Если другая дисциплина предшествует программированию, означает ли это, что специалисты другой дисциплины более важны? Это не так, и подробности ожидают читателей в следующей главе.
Как профессионал, работавший с программным обеспечением, я занимался программированием, изобретением, тестированием, документированием, проектированием, продажей, поставкой и поддержкой. Я могу утверждать, что среди этих задач программирование - задача самая сложная и предъявляющая к исполнителю самые высокие требования. (Я говорю о профессиональном программировании, о создании программ, пригодных для коммерческого распространения. Известно, что сложность программы растет экспоненциально в зависимости от размера кода. В институте почти всем приходится писать небольшие, по сотне-другой строк, программы. И многие пользователи для выполнения своей работы пишут программы примерно такого же размера. Однако общий объем, кода коммерческого приложения легко может превышать пятьдесят тысяч строк, поэтому сложность этих приложений выходит за пределы понимания большинства смертных.) Даже если другие специалисты об этом не догадываются, то у программистов нет сомнений, что их вклад в дело намного больше, чем, чей бы то ни было еще.
Миф о непредсказуемости рынка, рассказанный в главе 3 «Пустая трата денег», - еще одна причина, по которой последовательность «программа, тест, доводка» так прочно закрепилась в индустрии. Если мы не можем знать, чего захочет рынок, зачем тратить время на предварительное проектирование взаимодействия? Просто пишем код и выбрасываем на рынок, а там уж видно будет. Кроме того, такой подход избавляет нас от какой - либо ответственности за неудачи.
И несмотря на эти все проблемы, жизненно важно, чтобы более думающие люди изменили существующую последовательность, поместив проектирование перед программированием.
Юзабилити-тестирование
Любой процесс, основанный на наблюдении, должен играть второстепенную роль по отношению к творчеству. Программисты творят дисциплина эргономики молчаливо передает бразды правления программистам, говоря: «Вы создадите это, а затем я протестирую и увижу, насколько хорошо вы справились.» Однако в скоростном мире высоких технологий созданный продукт немедленно выходит на рынок. Тестирование постфактум уже не может сильно повлиять на продукт.
На мой взгляд, юзабилити-методы похожи на наждачную бумагу. Если вы делаете стул, наждачная бумага может сделать его более гладким. Если вы делаете стол, наждачная бумага и его сделает более гладким. Но никакая шлифовка не позволяет превратить стол в стул. И тем не менее, мне приходится видеть, как тысячи людей из лучших побуждений прилежно шлифуют столы методами эргономики, пытаясь получить стулья.
Юзабилити-тестирование до программирования
Нет сомнений, что юзабилити-тестирование до начала программирования возможно, однако природа и ценность процесса в этом случае меняется радикально. Такого рода тестирование сравнимо с чистым исследованием, которое больше подошло бы для университетской среды. Один коллега из крупной компании, разрабатывающей программное обеспечение, провел классический юзабилити-тест, одновременно выявивший сильные и слабые места такого предварительного тестирования. Он хотел определить эффективность строки состояния внизу окна программы. Он предложил участникам выполнить безобидное задание при помощи электронной таблицы. Каждые пять минут в строке состояния появлялось сообщение: «К вашему креслу снизу приклеена банкнота в $50. Возьмите ее!» За целый день тестирования ни один из более чем десяти участников не попытался взять купюру.
Осознать, что пользователи не обращают особого внимания на содержание популярной в среде программистов строки состояния, само по себе полезно. Однако это не проливает свет на скрытые проблемы: что есть состояние, заслуживающее внимания пользователя? Следует ли вообще отображать что-либо? В каком месте? Эти проблемы проектирования, как и раньше, остаются нерешенными. ..далее 

Неофициальная страница о психиатрической больнице им. Алексеева Н. А.
Персональное спасибо всем медсёстрам, врачам.13 отделения больницы им. Алексеева.
и лично Мозиасу Михаилу Романовичу.