Глава 15

Итеративная разработка

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

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

В данной главе рассматриваются следующие темы.

• Предпосылки.

• Определение главного звена.

• Дефекты, "фиксаторы" и компромиссы — методы и диагностика.

• Краткосрочные и долгосрочные следствия.

• Последующий анализ.

• Быстрый цикл разработки и оптимизация.

• Организационные и технические аспекты.

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

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

Мотивация. Если копию коммерческого программного продукта приобретает миллион пользователей, это, конечно, большая удача. Однако если 5% из миллиона покупателей оказываются неудовлетворенными, в итоге это составляет 50 000 пользо­вателей! Это огромное количество расстроенных людей, многие из них выражают недовольство и требуют особого подхода. Для Web-узла Internet (среди миллионов подобных узлов) неудовлетворенность может вылиться в игнорирование пользовате­лями этого Web-узла. Проектная бригада стремится избежать подобной ситуации.

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

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

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

Полезное правило. На протяжении итерации помните обо всех предыдущих методах разработки (методы совместной разработки, эвристический анализ и т.д.). Эти методы полезны при классификации решений проблем и потенциальных усовершенствований.

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

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

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

• Возможности (предметная область и пользовательский интерфейс).

• ПИ (внешний вид, поведение, пользовательское взаимодействие).

• Производительность (время отклика).

• Надежность (общее качество).

• Инсталляция.

• Помощь пользователям (поддержка эксплуатации, справочная система, обуче­ние и печатная документация).

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

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

• Обеспечение тщательного причинного анализа реально существующих и потенциальных проблем.

• Решение реальных или потенциальных ключевых проблем.

• Определение других областей потенциально значимых усовершенствований.

• Сохранение удовлетворительных возможностей в неизменном виде.

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

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

Объект

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

Отыскать главное звено

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

Предположения. Введем следующие предположения.

• Оценка практичности осмыслена проектной бригадой.

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

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

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

• Уровень удовлетворенности пользователей.

• Продуктивность работы пользователей.

• Недовольство пользователей (подразумевается снижение уровня удовлетво­ренности).

• Конкурентоспособность.

• Удовлетворение других критериев и целей.

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

Дефекты, "фиксаторы" и компромиссы —

методы и диагностика

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

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

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

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

Полезное правило.

1. Помните, что практичность— это функция возможностей, ПИ, производи­тельности, документации и других факторов.

2. Стремитесь понять реальную причину проблемы, прежде чем исправлять что-либо, что может быть не стоит "ломать". Вы можете исправить симптом, внести новые проблемы и вновь оказаться перед проблемой, требующей разрешения.

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

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

Серьёзность и частота проблем. Если вначале обычно нет недостатка в проблемах, над которыми приходится работать, позднее, вполне вероятно, будет ощущаться переизбыток проблем. Существует настоятельная потребность в оценке риска, связанного с индивидуальными и коллективными проблемами.

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

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

• Малозначительная проблема, которая, однако, доставляет большие неудобства и встречается довольно часто, должна быть внесена в перечень проблем, подлежащих коррекции.

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

• Какие системные и прикладные навыки применимы (новичок, случайный • пользователь, эксперт).

• Чего хочет добиться пользователь в реальном мире с помощью продукта.

• Каким образом пользователь стремится выполнить работу с использованием ПО.

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

Краткосрочные и долгосрочные

следствия

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

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

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

• Пользователь тратит слишком много времени, пытаясь обратиться к конк­ретному экрану или элементу управления.

• В работе пользователя встречаются ошибки или он постоянно требует помощи касательно конкретного экрана или элемента управления.

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

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

уверенность при работе с основными элементами GUI-, WUI- и HUI-стиля. Однако что касается приложения, проектная бригада способна контролировать процесс приобретения пользователем навыков работы с содержимым приложения.

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

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

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

Серьезные, долговременные проблемы должны быть исправлены, если цель продукта — добиться признания. При долговременном использовании могут проявиться факторы – помехи которые сами по себе не исчезают (например, печально известная, но очень распространенная проблема "слишком много окон и слишком много действий) Несогласованность по отношению к широко используемым и стандартным свойствам ПИ, например, некорректные комбинации клавиш или некорректное расположение элементов меню Edit (Правка), таких как Cut (Вырезать), Сору (Копировать), Paste (Вставить), представляет собой долговременную проблему.

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

FUPRID-факторы. Уровень удовлетворенности и практичности является функцией возможностей системы (Feature), производительности (Performance), надежности (Reliability), легкости инсталляции (Installability) и документации, включая все формы помощи пользователям и поддержки качества функционирования (Documentation). Складывая первые буквы названий этих факторов, получаем аббревиатуру FUPRID. Помимо разграничения на краткосрочные и долгосрочные, проблемы также разделяются на категории в соответствии с FUPRID-факторами.

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

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

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

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

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

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

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