Клочков / lek_rista_ob5

Глава

Изучив этой вы сможете:

результаты и

и «Первое

описать проектной группы на стадии «Разработка»;

на отсутствие

на стадии

описать на качество программного продукта;

У в отслеживания

Особенности стадии «Разработка»

«Разработка» — третья из четырех стадий модели Она следует за которая завершается одобрением плана проекта. До сих пор проектная группа занималась в основном концепцией, архитектурой продукта и планированием. На

стадии «Разработка» основная задача — выполнение проекта.

разработки

Выпуск промежуточной версии

Выпуск версии

Выпуск промежуточной версии 2

Выпуск версии 1

Рис. 12.1. Стадия «Разработка»

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

Как показано на рис. стадия «Разработка» завершается напи% санием кода и выпуском первой версии приложения. Результаты эта% па «Завершение разработки» таковы:

•все необходимые функциональные возможности приложения ре% ализованы (хотя, вероятно, и не самым оптимальным образом);

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

•проектная группа и другие участники проекта согласны с тем, что все реализованные возможности отвечают концеп% ции и функциональным спецификациям, и реализованы успешно;

•завершена подготовка к тестированию производительности про% дукта и его стабилизации.

Фаза «Разработка» во многом схожа с другими стадиями модели процесса разработки MSF. Например, как вы помните, фаза «Плани% рование» завершается подготовкой функциональных спецификаций, плана и графика проекта, а также сводного документа оценки рис% ков. Эти документы, означающие достижение этапа «Одобрение пла% на проекта», становятся исходными для стадии «Разработка». Кроме того, они необходимы для оценки различных характеристик процес% са разработки. Помните, что эти документы не остаются неизменны% ми — они вполне могут изменения по мере выполнения стадии Эта стадия завершается, когда подготовлены пересмотренные варианты этих документов, а также:

•исходный код и исполняемые модули проекта;

•результаты исследования производительности;

•основные составляющие процесса тестирования.

Вэтой главе мы обсудим, как применять результаты фазы «Про% ектирование» на стадии «Разработка» для создания продукта и дости% жения этапа «Завершение разработки», а также промежуточные эта% пы этой стадии.

Стадию «Разработка» программисты часто называют «настоящей работой». Действительно, основная ее задача — создание работающе% го продукта.

фаз «Проектирование» и «Разработка»

Проектирование архитектуры продукта на «Проектирование» определяет успех его реализации на стадии «Разработка». Стив Мак% в своей книге «Software Project Survival Guide» описывает связь этих стадий, сравнивая их с против течения реки и по течению. Разработка архитектуры на стадии «Планирование», счи% тает он, похожа на движение вверх по течению — чем выше вы забе% ретесь, тем проще будет сплавляться вниз на стадии «Разработка». Этот процесс, начинающийся по завершении стадии проектирования

и заканчивающийся выпуском продукта, будет тем успешнее и про%

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

Например, отдельный элемент архитектуры решения по мере пе%

а затем — в сотни строк кода. При переходе от проектирова% ния к кодированию проектная группа не способна сразу создать код всех сервисов и объектов — что это делается после% довательно. По мере завершения кодирования отдельные фрагменты связывают друг с другом, создавая приложение.

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

Основные этапы стадии «Разработка»

Основная цель стадии «Разработка» модели процесса разработки MSF согласие всех участников проекта с тем, что реализованы все за%

функциональные возможности продукта. Кроме того. заказчик и проектная группа должны принять решение о том, что реализация всех элементов и продукта в целом завершена.

Распределение обязанностей на стадии разработки

На стадии «Разработка» все участники проектной группы выполняют свои функции, а также выявляют риски и управляют ими. Каждый член группы выполняет свои обязанности, что в сочетании обеспечи% вает успешное выполнение стадии «Разработка»,

•Менеджер продукта — отвечает за выполнение требований заказ% чика, информирует заказчика и других участников проекта о со%

стоянии и продукта, готовит пользователей к выпуску аль% фа% и бета%версий.

•Менеджер программы — отвечает за связь всех подгрупп проект% ной группы, координирует выполнение промежуточных этапов отвечает за подготовку итоговых документов фазы «Раз%

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

• Разработчики — пишут код, все запланированные функциональные возможности выполняют тельное тестирование кода и возможностей, от% вечают создание альфа% и бета%версий а также первой окончательной версии в конце этапа «Завершение разработки».

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

•Группа тестирования — разрабатывает при% меры использования и сценарии для выполнения первого этапа

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

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

Впроцессе разработки следует придерживаться трехэтапного под% хода, который мы упоминали при обсуждении стадии «Концептуаль% ное проектирование». Эти этапы не надо считать обязательными % это, скорее, рекомендации. Их названия также в достаточной мере условны.

Первый этап: анализ и рационализация

На этом этапе проектная группа уже располагает достаточно кон% кретным планом разработки, так что особой нужды в дополнитель% ном исследовании нет. Единственное, что следует проанализировать на этом этапе, — текущий проект продукта.

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

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

Сотрудники группы тестирования анализируют проект приложения

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

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

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

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

Второй этап: реализация

Второй этап — «золотое время» разработчиков: начинается реализа% ция проекта приложения. Однако для достижения этапа ние разработки» недостаточно написать код приложения, мо еще подготовить соответствующие документы. Группа обучения пользователей готовит материалы, необходимые для обучения и тех% нической поддержки пользователей и для сопровождения ния, — эти материалы гарантируют успешное развертывание закон% ченного продукта, Хотя обычно основное внимание уделяется тради% ционным руководствам пользователя и инструкциям по установке, группе обучения иногда приходится готовить и дополнительные ма% териалы — обучающие программы и комплект мастеров, упрощаю%

работу пользователей.

Третий этап: аттестация

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

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

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

Управление рисками

Процесс управления рисками начинается на стадии концептуального проектирования и продолжается до конца жизненного цикла про% граммного продукта. Сводный документ оценки рисков, который ляется одним из результатов фазы «Планирование», на всех следую% щих стадиях постоянно уточняется. Процесс уточнения, состоящий из пяти шагов, проиллюстрирован на рис. 12.2. Очевидно, что проект% ная группа продолжает определять статус различных рисков, выяв% ленных на стадии и перечисленных в сводном доку% менте. Как и прежде, рассматривая каждый риск, проектная группа должна на следующие вопросы.

•Что сделано для снижения риска?

•Изменился ли риск под действием внешних факторов?

•Изменились ли вероятность или последствия какого%либо из ков под действием внешних факторов или в результате деятельно%

сти группы? Если да, как изменилась вероятность реализации рис% ка и его приоритет?

•Исключены ли какие%либо факторы риска?

•Какие действия следует предпринять с учетом ответов на эти воп% росы?

Исключенный риск

Рис. 12.2. Повторный анализ рисков

Мы вновь хотим подчеркнуть важность управления рисками для успешного завершения проекта. Проектная группа должна постоян% но заниматься этой работой. Более это важнейшая составная часть управления проектом в рамках MSF. На стадии «Разработка»

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

Этап «Завершение разработки» и его результаты

Основная цель стадии — завершение разработки, о чем свидетельствуют результаты.

•Пересмотренные функциональные спецификации — в этом докумен%

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

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

•Пересмотренный график проекта — в пересмотренный график вклю% чается время, необходимое для стабилизации продукта. Как и пе% ресмотренный план проекта, график отражает все вне% сенные на стадии «Разработка».

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

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

та. Этот выпуск завершении разработки и имеет статус вереи

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

Тестовые материалы — методы аттестации приложения и список элементов, тестируемых на стадии «Стабилизация». Это планы тестирования, тестов, схемы и сценарии, обеспе% чивающие тестирование всего набора функциональных возмож% ностей продукта. Группа тестирования должна создать набор томатизированных тестовых сценариев для использования на ста% дии стабилизации.

Промежуточные этапы

Для успешной реализации целей проекта следует разбить стадию «Разработка» на несколько промежуточных этапов разумного разме% ра. Этот способ позволяет сосредоточиться на необходимости выпус% ка продукта. Хотя группа может добавить свои промежуточные эта% пы, обычно стадию «Разработка» подразделяют на выпуск промежу% точной за которым следуют выпуск альфа% и бета%версий, свидетельствующий о достижении этапа «Завершение разработки».

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

Обычная частота промежуточных выпусков для проектов средне% го размера — раз в 1%3 месяца; для больших проектов ее можно умень% шить до одного выпуска в 2%4 месяца. Число и частота промежуточ% ных выпусков зависит от размера и продолжительности проекта,

Группа должна стремиться как можно раньше добиться создания стабильных версий пользовательского интерфейса и базы данных. Хотя они и не включены в список формальных промежуточных эта% пов стадии «Разработка», их лучше закончить как можно быстрее. Дело в том, что многие другие работы — например, создание обучаю% щих материалов — в значительной степени зависят от степени завер% шенности пользовательского интерфейса. Важно и определиться со базы данных, поскольку она диктует компоновку различ% ных функциональных возможностей продукта, а эти решения также принимаются на ранней стадии разработки. Таким образом, чем раньше завершена разработка пользовательского интерфейса и струк% туры БД, тем меньше изменений придется вносить в код и докумен% тацию на этапах работы.

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

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

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

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

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

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

Внутренние версии создаются в течение всей стадии «Разработ% ка». Каждый следующий выпуск должен расширять функциональные возможности предыдущего, как показано на рис. 12.3. Это способ позволяет рассматривать отдельные выпуски как независимые про% дукты, ориентируя группу на достижение поставленных целей. Ана% лиз промежуточных выпусков — обязательный элемент самообучения проектной группы, позволяющий ей расширять арсенал удачных ре% шений и избегать повторения ошибок.

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

время которой группа «подтягивает» ее к принятым стандартам каче% ства и практикуется в стабилизации продукта.

Рис. 12.3. Внутренние версии продукта на стадии

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

Промежуточные версии для внешнего пользования

Хотя это и не предусмотрено моделью MSF, мы рекомендуем на ста% дии «Разработка» создавать и промежуточные версии для внешнего пользования. Они помогают синхронизировать процесс кодирования и усилия разных подгрупп. Кроме того, их появление демонстрирует заказчику, пользователям и другим участникам проекта, что группа движется к поставленной

Как правило, альфа%выпуск (или выпуски) продукта не содержат всех функциональных возможностей. Его цель в другом — отработать выпуск продукта и проверку других материалов, которые должны быть подготовлены на стадии «Разработка» (например, справочные и учебные материалы).

Бета%версия по своим функциональным возможностям очень близ% ка к окончательному варианту продукта, однако, как правило, не оп% тимизирована.

Пересмотренные функциональные спецификации

Функциональные спецификации считаются основным результатом фазы «Планирование» и являются основой стадии «Разработка». Это своего рода компас, определяющий направление разработки проек% та. Продолжая скажем, что проектная группа не может «точно проложить курс» до самого пункта назначения, однако функ%

спецификации служат ей ориентиром.

этапы фазы «Разработка» — те инструменты, которые помогут вам воплотить в жизнь.

Анализ и пересмотр функциональных спецификаций

Пересмотренные спецификации не обязательно должны быть полностью взаимосвязаны с промежуточными этапами фазы «Разработка». Тем не менее в них необходимо отразить все раз% между проектом приложения, описанным в специ% фикациях, и состоянием продукта на этапе «Завершение

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

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

Табл. Причина пересмотра функциональных

Роль

В качестве примера пересмотра функциональных спецификаций рассмотрим разработку системы управления с которой вы познакомились на практикумах. На стадии разработки были обнару% жены проблемы с Web%клиента, отсоединенных объектов ADO Recordset и средств зашиты Windows NT. Проблема заключалась в том, что при использовании отсоединенных объектов Recordset идентификатор системы защиты текущего пользователя передавался бизнес%объектам промежуточного слоя некоррект% но. Проектной группе пришлось пойти на изменение архитектуры приложения. Хотя и Web%клиент, и отсоединенные объекты ADO Recordset были протестированы на стадии реализуемости концепции, интеграция средств зашиты Windows NT ускользнула от внимания группы. В результате проблема архитектуры осталась не% выявленной до начала разработки. К счастью, в конце стадии «Разра% ботка» появились пересмотренные версии системного ПО, в которых проблема устранена, однако группа не успела воспользоваться ими в первой версии приложения. Устранение проблемы с соответствую% щим изменением архитектуры включено в план выпуска следующей версии продукта.

Пересмотренный план проекта

План проекта также надо пересмотреть с учетом различий между про% ектом приложения и тем, что удалось реализовать, Хотя план проекта

и ее результаты

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

По мере выполнения проекта планы группы и ее подгрупп претво% ряются в жизнь и в соответствие с замыслом проекта. Со% ставление и выполнение основного плана проекта относится к компе% тенции менеджеров Каждая подгруппа свой план

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

Пересмотренный график проекта

Основной график проекта включает сроки выполнения этапов:

•разработка;

•выпуск внутренних и внешних версий продукта;

•тестирование;

•подготовка пользователей;

•сопровождение;

•информирование участников проекта;

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

На этой стадии главным считается график разработки, поэтому все прочие графики надо привести в соответствие с фактическим графи% ком работ группы Любое изменение графика выполне% ния перечисленных работ необходимо отразить в основном гра% фике проекта.

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

Пересмотренный сводный документ оценки рисков

Сводный документ оценки рисков разрабатывается на стадии ботки концепции. Его созданием и ведением, включая проверку пол%

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

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

Сводный документ оценки рисков позволяет синхронизировать выявление и анализ факторов риска разными подгруппами проектной группы и помогает правильно расставить их по приорите% ту. Управление рисками по%прежнему возложено на подгруппы, к

которых относится фактор риска.

Код и исполняемые модули

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

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

Избежать снижения качества кода помогают стандарты; они:

•вынуждают разработчиков придерживаться единого подхода к ко% дированию в любых условиях;

•постоянно напоминают разработчикам о важности качества кода.

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

Традиционно стандарты кодирования охватывают следующие об% ласти кодирования:

именование;

•структура;

•комментарии;

конкретные требования и запреты.

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

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

Еше одна цель традиционных стандартов кодирования — повы% шение надежности кода. Этой цели служат конкретные требования и запреты, например, обработки ошибок или запрет ис% пользования оператора GoTo. Элементы программы, файлы, функ% ции, переменные и константы должны отвечать правилам именова% ния; часто применяются и дополнительные соглашения специально% го характера (скажем, применение венгерской нотации для префикс% ного указания типа переменной в ее имени). Соблюдение подобных стандартов управление проектом.

Средства повышения эффективности работы пользователей и сопроводительные материалы

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

Вот что пишет Стив Магуайр в своей книге «Debugging the Deve% lopment Process»:

«Если, читая документацию, пользователь не испытывает затруд

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

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

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

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

Сводное тестирование промежуточных версий

Без тестирования можно обойтись л и ш ь при «Стабилизации» — во всех остальных случаях это неотъемлемая часть процесса разработки. На этапе одобрения плана проекта проектная группа намечает гра% фик тестирования и детально прорабатывает спецификации тестиро% вания отдельных функциональных возможностей продукта.

Создание спецификации тестов надо завершить к этапу «Заверше% ние разработки», поскольку на этом этапе функциональные возмож% ности продукта фиксируются, а их расширение возможно лишь в сле% версиях. Реализацию продукта на этапе «Завершение разра% ботки» следует рассматривать как альфа%версию для стадии «Стаби% лизация». Не следует путать эту альфа%версию с альфа% и бета%тести% рованием промежуточных версий на стадии «Разработка». Отметим, что часть операций по тестированию промежуточных версий на ста% дии «Разработка» повторится на стадии «Стабилизация».

С точки зрения тестирования переход от стадии к стадии «Стабилизация» — это переход от тестирования наличия фун% кций к проверке их работоспособности и эффективности. Приведем некоторые примеры методов тестирования, применяемых на стадии «Разработка».

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

•Функциональные тесты — проверка наличия конкретных функций приложения и их работоспособности.

•Тесты перед сдачей версии модуля — это простые автоматизирован% ные тесты, которые выполняются перед сдачей новой версии мо% дуля в базы данных исходных текстов проекта.

Иногда используются и другие методы тестирования.

•Проверка сборки — обычно выполняется после ежедневной сбор% ки приложения, чтобы удостовериться, что она прошла успешно.

•Регрессионное тестирование — автоматизированный тест, прово% димый после ежедневной сборки для проверки работоспособнос%

ти всех функций предыдущей сборки в новой версии.

Теперь рассмотрим примеры характерных для стадии «Стабилизация».

• Тестирование конфигурации — проверяет работоспособность про% дукта на аппаратно%программной платформе.

•Тестирование совместимости — проверка корректности взаимодей% ствия приложения с другими программами.

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

•Тестирование производительности — исследование производитель% ности приложения; взаимосвязано с тестированием под нагрузкой,

•Проверка и справочной системы — выявление оши% бок и несоответствий в документации и справочных материалах.

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

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

серьезность проблемы (влияние неисправленной ошибки на работу приложения) и ее приоритет (важность исправления ошибки для со% хранения стабильности приложения). Наличие ошибок со степенью серьезности или приоритетом 1 (они определены в главе 10) следует рассматривать как препятствие выпуску текущей версии приложения,

Ориентация на отсутствие дефектов

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

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

Основное достоинство этого способа — высокий приоритет каче% ства продукта при его разработке. Поскольку высокое качество — ос%

Разработка

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

Ежедневная сборка Хотя ежедневная сборка приложения — хлопотное дело, она очень

полезна. Это просто компиляция и сборка всего кода приложения к исполняемый модуль (или модули). Как следует из названия, эта про% цедура выполняется ежедневно. На практике обычно сборка прово% дится через три%четыре дня не реже). В своей книге «Dynamics of Software Development» Джим Маккарти отмечает:

«Разрабатывая программное легко попасть под влияние

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

По образному сравнению Джима Маккарти из цитированной выше книги, ежедневная сборка — сердцебиение проекта:

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

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

усилий всех членов проектной группы,

Резюме

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