Web-проектирование и испытание

Web-проектирование

Анализ процесса проектирования.

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

Документирование процесса разработки.

Чтобы документировать технологический процесс разработки Web-сайта, вы должны следовать адаптивному процессу, в котором переходы между стадиями разработки обеспечивают общую эффективность всего процесса проектирования. Один из таких процессов известен как Spiral Model (спиральная модель). Согласно этой модели, вы начинаете проектирование с выработки требований к сайту, а затем попеременно переходите к стадиям разработки и тестирования. Когда разработчик находит ошибку или задумывает внести какое-нибудь улучшение, процесс откатывается назад, к стадии определения требований, для внесения дополнительных требований, либо разрешения проблемы. Использование спиральной модели (Spiral Model) предполагает создание сайта из модулей. Иными словами, разрабатывайте свой сайт по частям, начиная от ядра сайта, и по ходу работы вносите усовершенствования. Сначала задайте группу требований к какой-либо части сайта, разработайте эту часть, протестируйте ее, пересмотрите требования в соответствии с результатами тестирования, а затем переработайте. Этот процесс следует по «спирали» вплоть до истечения жизненного цикла Web-сайта (когда ему уже не требуются улучшения и решения проблем, и разработка завершена, и сайт можно за 20 минут выгрузить в сеть). Этапы процесса совершенствования по уровню эффективности SEI разделяет компании, разрабатывающие программное обеспечение, на пять уровней. Эти уровни соответствуют модели завершенности возможностей СММ. В настоящее время большинство компаний работают на уровне 1, и всего несколько - на более продвинутом уровне 3. Что символизирует каждый уровень?
• Уровень 1: Первоначальный - компания вообще не использует технологический процесс. Все операции выполняются спустя рукава, и только благодаря героическим усилиям нескольких сотрудников компания укладывается в отведенные сроки или требования заказчиков.
• Уровень 2: Повторяемый - компания использует технологический процесс, выработанный практикой, однако этот процесс не документирован. Кроме того, ключевые моменты процесса затрагивают в основном стоимость и текущие вопросы, но не фактический продукт.
• Уровень 3: Определенный - процесс документирован, стандартизован и охватывает почти все области деятельности компании, а не только один проект.
• Уровень 4: Управляемый - кроме документирования процесса, компания реализует сбор показателей работы - рассчитывает стоимость, время, долю успешных попыток, и так далее и использует эту информацию, чтобы точно учесть потребности и спланировать работу до запуска проекта.
• Уровень 5: Оптимальный - процесс документирования, принятый в компании, постоянно оптимизируется. В процесс вносятся усовершенствования, определяемые на основании результатов измерений эффективности. В спиральном процессе вы должны начать с разработки документа, определяющего требования к сайту. Определите, что должен делать ваш сайт. Далее подготовьте проектную документацию. В этой документации вы должны разработать подробный план сайта и его реализации. После тестирования сайта, но до его выгрузки на сервер, создайте пользовательскую документацию. Последняя должна содержать политики защиты конфиденциальности и безопасности, раздел «О нас», а также раздел часто задаваемых вопросов (FAQ), которая дает ответы на вопросы о сайте. Либо вы можете подготовить подробный документ с пошаговыми инструкциями по выполнению различных задач на сайте.

Спиральная модель процесса разработки сайта.

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

Документация с техническими требованиями.

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

Если в Web существует сайт, который делает то же самое, на что нацеливаетесь вы, спросите пользователей, что в нем желательно улучшить. Спросите у них, что они предпочитают. Например, вы можете включить в список общих требований к сайту создание он-лайнового сообщества. Какие конкретные требования нужно реализовать в сообществе? Будет ли сообщество общедоступным? Или же вы заставите пользователей загружать с вашего сайта специальную программу? Какие средства нужно предоставить сообществу? Будет ли сообщество ограничено доской объявлений, или вы включите в него чат, работающий в режиме реального времени? Возможно, у вас есть требования к внешнему виду сайта или его системе навигации, определяемые общими потребностями клиентов. Может быть, в вашей аудитории есть пользователи со слабым зрением, и вам нужно использовать на страницах крупный шрифт, либо даже звуковые файлы, чтобы «читать» содержимое для пользователей? А может быть, все страницы на сайтах вашей компании должны иметь особую структуру или цветовую схему? Далее вы должны прикинуть несколько показателей оценки работы сайта. Какие инструменты нужны для реализации этих общих требований?Какие технологии должна знать или освоить ваша проектная группа? Во что обойдутся эти инструменты, обучение людей и т.д.? Насколько детальными должны быть ваши требования на этом этапе? Да настолько, насколько это возможно. Чтобы выполнить работу эффективно, на этом этапе вы должны сами подготовиться к проектированию, подобрать группу программистов, и оценить свои потребности. Документация, которую вы подготовите на этом этапе, послужит отправной точкой для последующего внесения в сайт дополнений и изменений, гарантирующих его эффективность. Тогда, после роспуска первоначальной группы проектировщиков, новая группа сможет легко разобраться в конструкции и проектных требованиях к сайту.

Проектная документация

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

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

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

Пользовательская документация

Пользовательская документация предназначена для того, чтобы помочь посетителям работать с сайтом. В сети Web, пользовательская документация обычно включает в себя раздел FAQ (Frequently Asked Questions - часто задаваемые вопросы), а также политики и инструкции, регламентирующие работу посетителей. Как известно любому Web-путешественнику, раздел FAQ используется на сайтах Web для предоставления ответов на вопросы, которые наиболее часто задаются посетителями сайта. Какие вопросы можно включить в этот раздел?
Попытайтесь сформулировать вопросы, относящиеся к выполнению конкретных задач на вашем сайте.
Включите в перечень вопросы о том, где можно найти важную информацию или как связаться с вашей компанией.
Поместите в раздел FAQ все вопросы, которые всплывали на стадии тестирования сайта. Далее мы обсудим, что нужно включать в документ каждого указанного типа. Список, который мы используем для анализа вашей документации, может послужить отправной точкой для вашего раздела FAQ. Продумайте целесообразность включения в сайт нескольких разделов FAQ.
У пользователей могут появляться вопросы на самые разные темы, от навигации по Web-сайту, до сведений о продуктах, а формат раздела FAQ довольно прост и популярен.
А как быть с политиками?
Какого типа политики вы должны включить в сайт? Это зависит от назначения вашего сайта, но в настоящее время чаще всего в сайты включают политики защиты конфиденциальности, безопасности, платежей и доставки.
Политика защиты конфиденциальности должна подробно описывать, какую личную информацию о посетителях сайта вы собираете, и как намерены ее использовать. Вы можете также указать, каким образом вы защищаете собранную информацию кто, кроме вас, сможет ее просматривать, и как эта третья сторона сможет ее использовать. Создаваемая вами политика безопасности должна содержать более полную информацию, чем вы можете опубликовать. Вам совсем не нужно, чтобы каждый знал, каков будет ваш ответ на его попытки взлома вашего сайта. С другой стороны, вы должны уверить своих заказчиков, что сделали все, что в ваших силах, для защиты своего сайта и их информации. Ваша политика защиты должна также служить и как предупреждение взломщикам, что вы будете преследовать их в судебном порядке и не дадите спуску любой злонамеренной атаке на сайт. Политики платежей и отправки являются просто двумя потенциальными разделами документа, посвященного обслуживанию заказчиков. Вы можете также предусмотреть политику защиты авторских прав, призванную оградить вас или ваших заказчиков от нарушения авторских прав. И опять же, разрабатывая политики для пользователей, решите, насколько они соответствуют потребностям вашей компании.

Подготовка списков вопросов для контроля хода проектирования

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

В документе с требованиями к сайту вы должны ответить на следующие вопросы:
•Выработайте терминологию, которую будут однозначно интерпретировать все участники проекта. Например, определите термин «сообщество». Что входит в это сообщество?
• Задайте параметры. Например, укажите пропускную способность линии связи или оптимальное время загрузки ресурсов сайта.
•Определите, как посетители будут использовать сайт. Что они смогут делать на вашем сайте?
•Определите глубину логической структуры сайта. Например, сколько страниц, начиная с главной страницы сайта, должны пролистать посетители, чтобы достичь нужной им области сайта.
•Сколько разделов должно быть в сайте? Будете ли вы варьировать внешний вид этих разделов, чтобы как-то выделить их? Просмотрите любой портальный сайт, например, Yahoo!. В нем есть различные разделы для электронной почты, аукционов и карт.
•Какое программное обеспечение нужно для создания этих сайтов? Какие программы вам понадобятся для создания и сопровождения графики? Нужен ли вам инструмент управления версиями?
•От каких факторов зависит ваш выбор компоновки и структуры сайта и его страниц? Проектная документация Ваша проектная документация, независимо от степени ее конкретизации, должна быть достаточно подробной, чтобы вы могли немедленно приступить к реализации проекта. Она должна включать следующие пункты:
•Какова конечная цель Web-сайта (краткий вывод из технических требований)?
•Какие разделы должен содержать Web-сайт? Например, нужен ли вам раздел Community Services (Службы сообщества)? Область Products (Товары)? Область Research (Исследования)? Техническая поддержка? Определитесь с содержимым этих областей.
•Какие эстетические или конструктивные элементы используются для «сшивки» разделов сайта?
• Какую цветовую схему вы используете?
•Какими соображениями и правилами вы руководствуетесь при работе с графикой? С текстом? При определении внешнего вида страниц?
• Какую структуру сайта вы используете?
•Как вы разделите информацию? Иными словами, какую используете логическую структуру сайта?
•Какую физическую структуру сайта вы намерены использовать для размещения файлов своего сайта?
•Какую технологию вы используете?
•Как вы свяжете страницы ссылками?
•Как будут пользователи получать доступ к различным разделам вашего сайта? Понадобятся ли им специальные инструкции или программы?
•Как вы собираетесь сопровождать свой сайт? Пользовательская документация Известно множество типов пользовательской документации, которую необходимо включить в Web-сайт. Поэтому здесь мы рассмотрим их только в общих чертах. Ниже приведен список вопросов, на которые эта документация должна давать ответ, причем, если явно не указано обратное, они равно применимы к документации любого типа.
•Каким образом пользователи могут получать доступ к сайту?
•Нужны ли для доступа к сайту специальные инструменты, программы, оборудование и т.д.?
•Где пользователи могут найти информацию о сайте (заполните форму запроса)
•Опишите разные задачи, которые должны будут решать пользователи, и опишите, как их следует решать.
• Как могут пользователи связаться с компанией, чтобы получить техническую поддержку? С отделом обслуживания заказчиков? Узнать о распродажах? Внести предложения? Сбор результатов измерений по мере тестирования и реализации сайта вам придется собирать данные о результатах его работы. Это позволит определить практическую пригодность сайта и уточнить затраты времени и денег на дальнейшее развертывание сайта. Данные о работе сайта полезно собирать и тогда, когда сайт уже разработан, реализован и привлекает тысячи посетителей.
С чего вы должны начать? Начните с определения параметров работы сайта, которые пригодятся в дальнейшем для тестирования и реализации сайта. Хотите ли вы знать число уникальных посетителей сайта? А число посетителей каждой страницы сайта? А как часто они заходят на сайт? Помимо оценки своих трудов по созданию каждой страницы или сайта в целом, вы должны также измерять объем ресурсов, которые вы затрачиваете на каждой стадии процесса разработки. Сколько времени ушло на создание прототипа страницы? Во что обошлись реализация и тестирование сайта? Сколько ошибок вы обнаружили по ходу тестирования и после него? В процессе совершенствования сайта вы должны повторно проходить через стадии выработки технических требований к сайту, разработки его страниц и дополнительного тестирования. Зарегистрируйте время, которое занимает каждая их этих стадий доработки сайта. Определите объем ресурсов, необходимых для внесения усовершенствований. Установите, как эти доработки влияют на эффективность, эстетичность, навигационные возможности и другие характеристики вашего сайта. Эти данные помогут вам точно оценить ресурсы, которые понадобятся при последующих реализациях проекта. Массу полезной информации, в том числе IP-адреса (Internet Protocol - Протокол Интернета) посетителей, ошибки, которые встретились во время посещений, типыфайлов, которые запрашивали посетители, и т.д. можно найти в журналах вашего сервера Web. Если вам потребуется дополнительная информация, можно прибегнуть к другим методикам ее сбора. Чтобы собрать информацию, вы можете сами опрашивать посетителей, требуя регистрации при входе. Создавая и используя журналы сеансов, вы можете установить время пребывания посетителей на сайте, либо на каждой его странице, узнать, что им понравилось.

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

Контроль исходного кода сайта

Помимо разработки документации, важным элементом улучшения процесса проектирования является контроль исходного кода сайта. Возможно, вы сочтете, что эта задача далека от процесса проектирования; однако контроль исходного кода жизненно важен для любого зрелого проекта или группы проектов. Почему? Прежде чем ответить на этот вопрос, давайте исследуем эту концепцию. Что такое контроль исходного кола? Для начала рассмотрим тему контроля исходного кода в контексте Web-дизайна. Инструменты контроля исходного кода способствуют улучшению процесса проектирования в нескольких отношениях. Во-первых, эти инструменты облегчают измерение параметров работы сайта. Эти инструменты записывают число редактирований файла до того, как он стал частью «реализации» (конечной конструкции, если хотите). Информация в записи каждой версии файлов позволит определить средний период времени, нужный для создания файла, и эти данные пригодятся в дальнейшем для оценки трудозатрат на подготовку новой версии файла. Далее, инструменты контроля исходного кода помогут вам поддерживать в порядке документацию. Каждый раз, когда вы записываете новую версию файла, эти инструменты предлагают вам описать изменения, которые вы вносите в файл. Это побуждает вас до- кументировать работу и оценивать процесс проектирования с точки зрения объема предстоящего тестирования и отладки, необходимых для завершения проекта. Наконец, эти инструменты позволяют надежно сохранить копии ваших файлов, а это повышает эффективность разработки. Почему? Да просто вам будет спокойнее работать, если вы будете знать, что всегда можете вернуться к последней версии файла, который пытаетесь улучшить. Кроме того, контроль исходного кода предполагает, что вы используете управление конфигурацией. Управление конфигурацией позволяет отделить контроль кода (или управление версиями) от разработки кода. Такое разделение способствует совершенствованию процесса проектирования, поскольку распространяет этот процесс туда, где ранее он не применялся. Действительно, управление конфигурацией предполагает наблюдение за целостностью кода, в данном случае - кода Web-сайта. Кроме того, эта система следит за документированием процесса, объединяет отладку с результатами тестирования (или планирует отладку в соответствии с этими результатами), а также обеспечивает окончательное сведение в единый пакет конечного продукта. Тем самым управление конфигурацией стимулирует расширение процесса проектирования. Каким образом? Управление конфигурацией устанавливает стадии разработки, а после того как эти стадии четко определены и документированы, вы и получаете рабочий процесс. Иногда контроль исходного кода называют «контролем ревизий» или «управлением версиями», «контролем конфигураций», «управлением конфигурацией» и т.п. Теперь, когда вы знаете, что такое контроль исходного кода и как он реализуется, вы должны выбрать способ реализации этого контроля. Выбор программы для контроля исходного кода зависит от операционной системы, используемой вами для Web-проектирования. Рассмотрим несколько вариантов выбора.

Для защиты ваших страниц и их кода на время разработки можно использовать несколько инструментов:

•Программа Rational ClearCase - предназначена для электронного бизнеса и пригодна для платформ Windows и UNIX, а также поддерживается Web-серверами Apache, Netscape и Microsoft IIS Web Server (http://www.rational.com/products/clearcase/idex.jsp).

•Программ RCS (Revision Control System - Система управления ревизиями) пригодна для систем UNIX с помощью GNU Project, хотя в настоящее время имеются и три версии для платформ Windows (http://www.gnu.org/software/rcs/rcs.es.html).

•Программа CVS (Concurrent Versions Systems - Система конкурирующих версий) работает на платформах UNIX и Windows (http://www.cvshome.org).

• MKS Web Integrity - http://www.mks.com/products/wi/

•Microsoft Visual SourceSafe - Если вы разрабатываете свой сайт с помощью любого инструмента Microsoft Visual, программа SourceSafe является лучшим средством контроля исходного кода (http://msdn.microsoft.com/ssafe/).

•Программа Continuus/WebSynergy - совмещает процесс Web-дизайна с управлением версиями (http://www.continuus.com). Ресурсы Ниже перечислены ресурсы, которые облегчат вам совершенствование процесса проектирования.

•Software Engineering Institute (Институт прикладного программирования) по адресу: http://www.sei.cmu.edu

•Статья «Inability to Maintain» (Невозможность сопровождения) на сайте Webcrisis.com по адресу: http://www.mks.com/press/coverage/wi/crisis.htm. Превосходная статья, в которой подробно описываются скрытые проблемы, ожидающие тех разработчиков, которые пренебрегают процессом управления конфигурацией в своих Web-разработках.

Заключение

Как утверждается институтом SEI (Software Engineering Institute - институт прикладного программирования), чтобы сохранить контроль над своей Web-разработкой, вы должны создать и использовать процесс проектирования. Реализация этого процесса позволит вам сэкономить деньги и ускорить работу ваших дизайнеров при проектировании и совершенствовании сайта. Небрежение этим процессом нередко ведет к хаосу, который может длиться неделями и закончиться сердечным приступом. Как следует из этой главы, сердцевиной процесса проектирования является документирование и управление конфигурацией создаваемого кода. Они жизненно важны для успешной работы проектировщиков и самого процесса проектирования.