Глава 19

Конструирование, тестирование

и развертывание продукта

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

Этап реализации называют по-разному — сборкой, программированием, конструи­рованием и, помимо прочего, разработкой. Здесь используется термин "конструирова­ние". Рамки этапа конструирования охватывают проект реализации, реализацию, тес­тирование компонент, системное тестирование и другие виды тестов, пользователь­ские приемочные испытания, а также окончательную оценку продукта на предмет удовлетворения требований (рис. 19.1)

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

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

• Обеспечение плавного перехода от проектирования к этапу конструирования.

• Проект реализации, программирование и тестирование компонент.

• Системное и другие виды тестирования.

• Трудности, решения и уроки

• Уступки, компромиссы и неожиданности.

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

• Конструирование продукта согласно проекта.

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

Обеспечение плавного перехода от

проектирования к этапу конструирования

Требования находят свое воплощение в документации и конкретных проектные решениях. Конкретные проектные решения материализуются в виде спецификаций макетов, раскадровки, прототипов и информации, все еще находящейся в голова: участников проектной бригады. Объем работ по созданию ЕЙ может изменяться о^г 30 до 50% от общего объема работ по программному продукту в зависимости от тип; продукта, его аппаратной и программной архитектуры, а также от инфраструктуры Разработчики программных продуктов обычно сталкиваются с большими объемам! программирования ПИ, строгими требованиями к ПИ, ограничениями на сроки или ограниченными профессиональными ресурсами, которые влияют на продуктивность конструирования ПИ.

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

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

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

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

Полезное правило. ПО пользовательского интерфейса аналогично любому другому ПО — только сложнее.

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

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

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

• Прототип спроектирован, но еще не реализован каким-либо способом.

• Прототип реализован как имитационная модель ПИ, но даже приблизительно не похож на подход к реализации ПИ.

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

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

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

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

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

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

Полезное правило. В течение этапа конструирования проектировщиков сле­дует держать поблизости.

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

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

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

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

• Избегайте идти на компромисс в отношении целостности проекта и требо­ваний.

Проект реализации, программирование и тестирование компонент

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

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

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

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

Полезное правило. Чтобы удовлетворить требования, исследуйте альтернати­вы и осуществляйте итерации.

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

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

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

• Открытие, установка состояния и закрытие экрана или окна.

• Размещение экрана или окна по отношению к другому экрану или окну.

• Установка фокуса и установка состояния выбора.

• Инициализация элемента управления.

• Проверка допустимости значения поля (для ввода и вывода данных).

• Тестирование содержимого элементов управления.

• Разблокирование и блокирование элементов управления.

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

• Обратная связь с пользователями, обработка ошибок и сообщения.

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

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

• Чтобы удовлетворить требования, исследуйте альтернативы и осуществляйте итерации.

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

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

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

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

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

Тестирование компонент. Точное определение компонентного тестиро­вания (иногда называемого также блочным или модульным тестированием) гласит, что это тестирование, которое требует сквозной проверки в предполагаемой среде использования корректности таких возможностей продукта, как функции продукта, ПИ, доступ к базе данных, API (Application Programming Interface — интерфейс при­кладного программирования) и т.д. При этом необходима интеграция со всеми аспек­тами программного пакета или системы. В действительности требуется продемонст­рировать, что конкретная функция работает в соответствии с ее спецификацией и/или так, как предполагается и требуется.

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

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

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

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

Полезное правило. Выявляйте и разрешайте проблемы по ходу разработки, в особенности это касается предполагаемой пользовательской среды. Если проблему не удается решить сразу, документируйте ее и вновь вернитесь к ней позднее.

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

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

• и все возможности ПИ работают на уровне компонентных тестов (т.е. функции выполняются корректно с точки зрения лучшего разработчика и его коллеги – тестировщика)

• и доступ к помощи/обучению/EPS (Electronic Publishing System — электронная издательская система) интегрирован в систему и работает корректно (спра­вочная и другая пользовательская информация доступна и корректна)

• и увеличение дефектов минимально (отсутствие известных дефектов неза­висимо от серьезности)

• и наращивание программного кода минимально и обусловлено только исправ­лением дефектов (программы не разрастаются без видимой причины)

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

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

• и разработчик уверен, что ПО готово к началу системного тестирования (раз­работчик и его коллега-тестировщик не могут больше обнаружить дефектов в программном коде)

• и время, выделенное на программирование, истекло (в противном случае все оборачивается улучшением/уточнением кода без необходимости).

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

• Фокус клавиатуры не устанавливается именно в тех местах экрана, в которых требуется пользователю.

• Использование клавиши табуляции приводит к потере фокуса клавиатуры на экране (иногда он больше не возвращается).

• Упущена обратная связь по времени отклика (песочные часы) или индикация хода процесса.

• Нестандартное поведение для клавиши <Enter> или указателя мыши при двойном щелчке.

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

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

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

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

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