Введение

Решения для электронного бизнеса представляют собой Internet-приложения, применяемые для автоматизации бизнес-процессов. Хотя в этом сегменте наиболее распространены приложения для торговли через Internet, автоматизировать можно практически любые процессы деятельности организации.

Системы для электронного бизнеса можно разделить на несколько поколений:

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

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

Операции, выполняемые на начальном этапе

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

Среда

Операция: Подготовка среды к выполнению итерации

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

Настроение сайта - сайт может быть серьезным, игривым и т.д. Ваш сайт будет консервативным или молодежным?

Как пользователи будут обращаться к сайту, например, какова будет скорость соединения? Заложена ли в проекте минимальная скорость обмена данными между сайтом и пользователем?

Степень интерактивности (взаимодействия с пользователем) - например, будет ли сайт только информировать пользователей или же обмениваться информацией с ними (двусторонняя связь)? Будет ли приложение одинаково работать со всеми пользователями?

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

Будут ли применяться фреймы.

Ограничения на цветовую гамму сайта.

Требования к графическому оформлению (включая корпоративные логотипы и графические схемы).

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

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

Требования

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

Операция: Анализ сложности

Эта операция не входит в число первоочередных. Большинство сложностей должны были быть обнаружены при моделировании бизнеса.

Операция: Анализ потребностей заинтересованных лиц

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

Операция: Создание определения системы

Эта операция не входит в число первоочередных. Рамки системы определяются рамками бизнеса, поскольку система точнее отражает суть бизнеса, чем традиционные приложения (в некотором смысле система и есть бизнес).

Анализ и проектирование

Операция: Анализ поведения

В ходе выполнения задачи Задача: Проектирование пользовательского интерфейса создается Схема навигации. Схема навигации - это представление Web-решения, характеризующее то, как пользователи будут перемещаться по сайту, например, в форме иерархического дерева. На каждом уровне диаграммы показано количество щелчков мышью, которое нужно сделать для перехода в соответствующее окно или на соответствующую страницу. Желательно разместить важнейшие области сайта на расстоянии "одного щелчка" от первой страницы (которую часто называют "начальной" или "домашней" страницей). Схема навигации по сути представляет собой множество раскадровок, задающих основные окна сайта для каждого из вариантов использования и способы перехода из одних окон в другие.

Операции, выполняемые на этапе уточнения

Применяется стандартный поток операций этапа уточнения со следующими дополнениями и изменениями.

Операция: Определение предполагаемой архитектуры
Выполнение задачи Задача: анализ архитектуры упрощается за счет того, что у Web-приложений в целом довольно стабильная архитектура, в которой применяется набор стандартных механизмов (браузеры, аплеты и сервлеты Java, ASP и JSP и т.п.). Как правило, в разделе Концепция: слои описывается простая многослойная структура, и этого достаточно для большинства простых сред разработки приложений. Довольно часто можно приобрести готовую архитектуру или позаимствовать ее у одного из предыдущих проектов. Инфраструктуры Web-приложений, например IBM WebSphere или Microsoft Windows DNA, снабжены разнообразными шаблонами подобного плана.

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

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

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

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

Задача: Анализ вариантов использования остается практически неизменной - за исключением того, что нужно помнить не только о поведении графического интерфейса, но и о логике бизнес-приложения, которое будет выполняться либо на Web-сервере, либо на сервере приложений. В противном случае можно упустить из виду важнейшую часть поведения системы. Web-страницы как таковые обычно представлены классами "границы", элементы данных - классами "объектов", а поведение сервера (например, страницы ASP, сервлеты и т.п.) - "управляющими" объектами.

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

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

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

Подготовка рекомендаций осуществляется в связке с разработкой начального прототипа интерфейса Web-сайта. На выходе пользователи получают руководство по оформлению сайта. В этом руководстве, среди прочих вещей, будет указано, как и когда должны использоваться элементы оформления, какими должны быть палитра, шрифты и стили CSS, а также как должны быть расположены и как должны работать элементы навигации.
Операция: Уточнение определения архитектуры
В задаче Задача: Идентификация механизмов проекта основное внимание уделяется созданию соответствия между нефункциональными требованиями к системе и механизмами инфраструктуры разработки Web-приложений; при этом нужно будет определить, какие механизмы отсутствуют в инфраструктуре (если инфраструктура существует), и найти альтернативные способы реализации этих механизмов.

В задаче Задача: Описание архитектуры выполнения основное внимание уделяется уровням сервера приложений и Web-сервера (см. Концепция: Шаблоны распределения), а также процессам и нитям, применяемым для управления параллелизмом. Как правило, если система вообще обладает влиянием на работу клиентской части, это влияние минимально.

В задаче Задача: Описание распределения основное внимание смещается с вопроса о том, "какие потребуются виды узлов серверов", на вопрос "сколько серверов каждого вида нам понадобится". Обычно инфраструктура разработки Web-приложений поддерживает ограниченное количество типов серверов (например, Web-серверы, серверы приложений, серверы почты, серверы CGO) со сравнительно четко определенными функциональными границами. В результате архитектор программного обеспечения концентрируется на вопросах масштабируемости и отказоустойчивости, решая их путем подбора нужного количества серверов каждого типа. Помимо этого, нужно разработать методику измерений, позволяющую установить, когда потребуются дополнительные серверы.
Операция: Определите цели оценки
При планировании основное внимание уделяется тестированию производительности для проверки способности приложения поддерживать большое количество пользователей, одновременно работающих с системой. В результате операции Проверка подхода к тестированию, Тестирование и оценка, Разработка приемлемых целей и Оптимизация ресурсов тестирования также будут сфокусированы в первую очередь на тестировании производительности и обеспечении масштабируемости архитектуры.

Другие важные типы тестирования - тестирование удобства работы и тестирование структуры. Для того чтобы убедиться в том, что структура Web-приложения удобна для пользователей,нужно протестировать взаимодействие приложения с пользователями. Довольно часто приложение бывает обязано находиться в Internet, и в таких случаях появляется удобная возможность изучения особенностей работы пользователей с приложением.

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

Операции этапа построения

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

Операция: Создание плана интеграции
При выполнении задач Задача: Создание плана интеграции подсистем и Задача: Создание плана интеграции систем нужно исследовать различные виды элементов реализации, созданных на этапе построения системы.
Операция: Реализация компонентов
В задаче Задача: Реализация элементов проекта основное внимание уделяется следующим видам элементов:
- Web-страницы, аплеты, сценарии, графические объекты и другие элементы, "выполняемые" в среде браузера
- Серверные страницы (SSP), сценарии, сервлеты и другие элементы, "выполняемые" на стороне сервера
- Расширения исполняемого кода для старых приложений
- Таблицы баз данных, триггеры, хранимые процедуры и другие элементы, выполняемые в системе управления базами данных
В силу наличия различий между инструментами и технологиями развертывания разных видов элементов аналогичные вариации будут присутствовать и в задаче Задача: Реализация элементов проекта. Все вышесказанное относится и к операциям Операция: Интегрирование всех подсистем и Операция: Интегрирование системы.
Операция: Определите цели оценки
При планировании тестирования основное внимание по-прежнему уделяется тестированию производительности, однако все более важным становится функциональное тестирование. Для тестирования каждого вида элементов, образующих Web-приложение, требуется собственный подход. По этим же причинам в операциях Проверка подхода к тестированию, Тестирование и оценка, Разработка приемлемых целей и Оптимизация ресурсов тестирования внимание также будет смещаться от архитектурного тестирования производительности к функциональному тестированию, позволяющему проверить правильность поведения системы.

Операции этапа внедрения

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

В разработке этой страницы принимала участие компания Context Integration.