Проектирование и управление разработкой сайта на платформе «1С-Битрикс: Управление сайтом»

Авторы: Камнев Артем, Максим Месилов, 1С-Рарус.

Информационная архитектура сайта

Как правило, сайт – это, в первую очередь, средство представления информации.

Информация, особенно в больших объёмах, нуждается в структурировании, классифицировании.

	САЙТ = ИНФОРМАЦИЯ + ПРЕДСТАВЛЕНИЕ

Информация, особенно в больших объёмах, нуждается в структурировании, классифицировании.

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

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

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

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

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

Моделирование данных совместно с заказчиком

Большинство IT-специалистов в ВУЗе слушали курс Основы баз данных (ОБД). Однако многие не придавали ему значение, кому-то не повезло с преподавателем, а кто-то не смог пробраться сквозь академические дебри реляционной теории.

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

Участие заказчика в проектировании

В книгах по самосовершенствованию для руководителей проектов нередко пишут что-то вроде «определитесь с целями, определитесь с наградами и прочими мотивациями – и это уже полдела». Оптимисты!

Да, бриф – это очень важно. Но с созданием брифа работа с заказчиком не заканчивается, а только начинается.

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

Предстоит сделать самое сложное – вместе с заказчиком построить инфологическую, а потом и даталогическую модели сайта (о них чуть ниже).

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

Умерьте свой оптимизм: вне зависимости от уровня вашей квалификации вы не создадите информационную архитектуру сайта без плотного участия заказчика. Это означает буквально следующее: вы вместе с заказчиком садитесь поудобнее около достаточно большого монитора (хотя бы 20 дюймов), запускаете MS Visio – и рисуете.

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

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

Разумеется, чтобы заказчик не заскучал, вы должны владеть Visio в совершенстве. Благо, для рисования ER-диаграмм не требуется слишком много навыков рисования (зато потребуется отличное знание реляционной теории). В данной главе мы рассмотрим её основы.

Согласны, убедить заказчика в необходимости совместного рисования ER-диаграммы ох как непросто. Считается, что в идеале от заказчика должно быть получено объёмистое ТЗ, где как раз и будут перечислены все сущности и связи. А уже по этому ТЗ проектировщик должен самостоятельно нарисовать ER. Осмелимся утверждать, что это неверно, и вот почему:

• никто не способен построить ER-диаграмму «в голове», чтобы перенести потом её в текстовом виде в ТЗ (и тем более не способен ваш заказчик);
• в ТЗ без должной модерации процесса со стороны технического специалиста обычно попадает масса незначительных связок, деталей, «бантиков» – и упускаются самые основные связи и атрибуты (заказчик может интуитивно понимать, например, кратности связей между сущностями, однако словами выразить их, вероятно, не сможет);
• при самостоятельном составлении ER-модели информационный архитектор, не будучи специалистом в предметной области заказчика, нарисует красивую, стройную модель, которая, увы, будет далека от реалий;
• даже если предположить, что заказчик напишет толковое ТЗ, всё равно его придётся переносить в структуру базы данных – при этом наверняка появится масса разночтений, тогда как ER-модель практически на сто процентов читается однозначно.

При проектировании традиционных приложений, связанных с использованием баз данных, обычно не возникает вопроса о необходимости создания ER-модели. К величайшему сожалению, в web-индустрии (включая сообщество Битрикс-разработчиков) с этим дела обстоят весьма печально. Возможно, это связано с тем, что web-программисты в гораздо большей степени «визуалы», тогда как традиционные программисты – в основном, «абстракционщики».

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

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

Нередко проектировщики всё же создают некоторое подобие ER-диаграммы. При этом они выносят на неё лишь самые основные сущности (то есть те, что заказчик, не являясь специалистом в этой области, отметил в ТЗ) и не удосуживаются отрисовать полностью все возможные атрибуты и связи. Мотивируют они это тем, что по мере работы над проектом диаграмма непрерывно будет изменяться.

Это утверждение абсолютно верно. Как сказал Антуан де Сент-Экзюпери, «достроенный город – мёртвый город». Проект – живой организм, и только по окончании проекта известны все требования – и от этого никуда не деться.

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

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

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

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

	IDEF1X - это одна из методологий семейства IDEF, применяющаяся для построения информационной модели предметной области.

Страница 1 - 1 из 12
Начало | Пред. | 1 2 3 4 5 | След. | Конец