Часть 4

Завершение

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

Глава 20. Итоги и перспективы

Глава 20

Итоги и перспективы

Итак, какого результата мы достигли и как к нему пришли?

Итоги

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

Применяемое с усердием и трудолюбием проектирование, ориентированное на пользователя (так называемый UCD-подход), позволяет создавать продукты, которые удовлетворяют требованиям пользователей или даже превосходят их. Мы также предприняли попытку сделать краткий и общий обзор всего цикла проектирования, направленного на разработку ПО с ориентацией на пользователя, как показано на рис. 20.1.

Принципы. Мы рассмотрели принципы ориентированного на пользователя проектирования.

• Привлекайте пользователей к участию в проекте на всем протяжении его жизненного цикла.

• Ставьте измеримые цели.

• Проектные решения и прототип должны быть рассчитаны на полную ком­петентность пользователя.

• Постоянно оценивайте все решения.

• Повторяйте итерации до тех пор, пока требования к продукту не будут удов­летворены.

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

Задачи UCD - Подхода. Задачи проектирования, ориентированного на поль­зователя, рассматривались и применялись в контексте до некоторой степени тради­ционного процесса разработки ПО.

• Традиционная организация-разработчик со многими присущими ей деловыми и человеческими проблемами разрабатывает ПО.

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

• Проектные ограничения по времени и ресурсам носят довольно расп­ространенный характер.

Даже в рамках традиционных и ограниченных сред задачи UCD-подхода могут вы­полняться значительно чаще и быстрее для проектов продолжительностью 90-120 дней, эти же задачи могут выполняться очень часто и очень быстро для многолетнего проекта, связанного с выпуском многочисленных версий. Если верить истории боль­шинства проектов, то около половины календарного времени проекта уходит на планирование вплоть до заверения проектирования. Другая половина календарного времени проекта тратится на реализацию и тестирование.

Мы выполнили беглый обзор следующих задач, вытекающих из UCD-подхода.

• Планирование.

• Анализ пользователей, задач и сред.

• Осмысление требований.

• Проектирование.

• Материализация проектных решений (имитация, прототип, спецификация).

• Оценка проектных решений и отклики пользователей.

• Анализ откликов пользователей.

• Итерации.

• Реализация.

• Тестирование.

• Развертывание.

Ключевым аспектом общего подхода является планирование процесса UCD для объединения в единое целое участия пользователей в проекте, измеримых критериев, оценки и итеративного повторения цикла выработки проектных решений до тех пор, пока не будут удовлетворены требования к продукту. Помимо реализации ключевых принципов UCD в рамках проектного плана, более явное освещение получили многие детали технологии ПИ. Мы пытались дать верное понимание таких аспектов проек­тирования, как планирование, составление план-графиков, навыки, выполнение про­екта, отслеживание состояния, а также способы избежания риска, связанного с наи­более распространенными проблемами. Для каждого проекта характерен свой уни­кальный риск.

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

Стиль ПИ. В процессе разработки нашего проекта-примера были рассмотре­ны три основных стиля ПИ, входящие в состав современных платформ ОС, что бы­ло вызвано требованиями кросс платформенной реализации. Проблемы, связанные

с созданием ПИ, были рассмотрены применительно к GUI- и Web-интерфейсам, а также карманным устройствам. Кроме того, мы исследовали понятие прикладного стиля ПИ. К общему стилю ПИ применимо любое количество прикладных моделей. Вы, конечно, могли заметить некоторые особенности, относящиеся к нашему проекту.

• Требования к проекту могли бы удовлетворить многие решения, касающиеся ПИ.

• Имея возможность выбора, пользователи, вероятнее всего, предпочтут одно из решений остальным.

• Ни одно из отдельно взятых решений не безупречно.

• Большая часть решений отличается наличием нескольких уникальных и весьма популярных возможностей и подходов, большинство из этих возможностей трудно интегрировать в выбранное решение.

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

Средства выполнения Проекта. Вследствие сложного характера про­граммного ПИ и задач UCD, для выполнения работы проектная бригада нуждается в большом количестве разнообразных средств. Средства выполнения проекта включа­ют программное и аппаратное обеспечение, материалы, оборудование и нормативно-техническую информацию. Кроме того, для повышения продуктивности и достиже­ния согласованности необходимо иметь в своем распоряжении библиотеки примеров и повторно используемых компонент. Проектная бригада должна бережно относить­ся к средствам и осваивать их в самом начале жизненного цикла проекта.

Планирование. Применительно к программному ПИ UCD-подход отличается сложностью и обилием деталей, он требует тщательного планирования. Для надле­жащего отслеживания и формирования отчетов о состоянии проекта необходимо со­ставление поддающихся измерению календарных планов, в особенности при плани­ровании итеративного процесса проектирования. Здесь могут потребоваться два или три уровня календарного планирования (например, с точки зрения проекта в целом, 90-дневной и двухнедельной перспективы). Детали, связанные с ПИ, могут быть по­ложены на ресурсы и время таким образом, чтобы избежать их недооценки.

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

Пользователи, среды и задачи. Проектная бригада анализирует детали, относящиеся к характеристике пользователей, физической и социальной рабочей среде. Программный ПИ должен обеспечивать потребности пользователей в контек­сте физических и социальных потребностей. Для правильного понимания этих во­просов служат разнообразные методы. Анализ соответствующей информации способ­ствует уяснению проектной бригадой характера предполагаемых пользователей, сред и задач.

Проектирование. Проектирование — это процесс уточнения. Речь здесь, ес­тественно, идет об уточнении проектных решений. Мы рассмотрели три основных этапа выработки проектных решений, касающихся ПИ и практичности: концептуаль­ное, высокоуровневое и низкоуровневое проектирование. Концептуальный проект за­дает направление проектных решений и архитектуру ПИ. Высокоуровневый проект развивает концептуальные проектные решения и определяет все основные возмож­ности, экраны и схемы взаимодействия пользователя с системой. Низкоуровневый проект в еще большей мере уточняет проектные решения и завершает определение всех возможностей и методов. На каждом этапе участие пользователей способствует оформлению проектных решений.

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

Макеты, имитационные модели и прототипы. Материализация проектных решений, как и проектирование, — это процесс уточнения. Лучшим прак­тическим подходом здесь является формирование наглядных представлений проект­ных решений на этапах выработки требований или проектирования. Существуют раз­личные методы визуализации (например, макеты, имитационные модели и прототи­пы различной природы). Методы вовлечения пользователей в проект, оценки про­ектных решений и итеративной разработки используются в сочетании с методами ви­зуализации для получения проектных решений, которые удовлетворяют требованиям и устраивают пользователей. Напомним, что эти методы можно использовать на эта­пе конструирования для решения проблем, выявленных на более поздних стадиях цикла разработки.

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

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

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

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

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

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

Продолжение обсуждения проекта:

"посмертный" анализ

После завершения проекта всегда полезно вернуться назад и определить, что прошло хорошо, а что можно улучшить. Завтра утром менеджер проекта и высшее ру­ководство требуют провести "посмертный" анализ проекта. Для того чтобы подгото­виться, в вашем распоряжении не более двух часов. Высшие руководители по досто­инству оценили проделанную вами работу и предлагают вам возглавить другую про­ектную бригаду для нового захватывающего проекта, который стартует сразу после "посмертного" анализа. Предполагается, что один из участников текущего проекта возьмет на себя ваши обязанности по поставке следующей версии продукта.

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

Что бы вы могли сделать теперь по-иному с точки зрения программного проекта и процесса проектирования?

Вопросы?

Перспективы

Технология, связанная с созданием ПИ и обеспечением практичности, развивает­ся, хоть и не так быстро, как другие технологии. Тем не менее, она не стоит на месте. Проектная бригада должна продолжать поиск более совершенных методов. Сущест­вующие методы должны быть проанализированы, усвоены и модифицированы при­менительно к проекту и индивидуальным потребностям. Необходимо исследовать и адаптировать методы других дисциплин, таких как строительство, психология, со­циология и теория вычислительных машин и систем. Методы следует расширить та­ким образом, чтобы они удовлетворяли требованиям в отношении ПИ, информаци­онного обеспечения и практичности.

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

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

Общие перспективы. Прогресс во многих областях движется не так быст­ро, как ожидалось. Однако некоторые технологии удивляют своей популярностью и тем, насколько быстро они получили широкое признание. Можно назвать следующие основные факторы, влияющие на признание технологии со стороны пользователей.

• Затраты в сравнении с выгодами.

• Обоснованные требования в отношении необходимого аппаратного и прог­раммного обеспечения.

• Общая скорость.

• Легкость в изучении и использовании.

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

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

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

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

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