Роман Овчинников - Корпоративный веб-сайт на 100%. Требуйте от сайта большего!
Документооборот как вид функциональности обычно «зашивается» внутрь системы управления контентом. Основная задача такого модуля – поддержать многоэтапный процесс редактирования и согласования информационного наполнения сайта. В корпоративной системе документооборота могут быть предусмотрены следующие возможности:
♦ Настройки произвольного количества маршрутов или статусов при движении документа
♦ Настройка прав и правил движения документа (например, право перехода из статуса «черновик» в статус «согласовано» имеют только пользователи ролей «главный редактор» и «администратор»)
♦ Синхронизация и, наоборот, блокировка работы над документами
♦ Поддержка различных кодировок (например, Win-1251, UTF-8 и др.)
♦ Сохранение истории всех изменений
♦ Настройка различных правил документооборота для разных типов данных (статей, файлов) или разных разделов данных (о компании, каталог продукции)
♦ Поддержка системы оповещения о различных действиях над документом (например, «о внесении изменений», «о факте публикации»)
♦ Автоматическое создание версий документа на установленных этапах, возможность отката документа к определенному состоянию
♦ Использование специальных поисковых инструментов
74. Документация
Предоставление документации по использованию и администрированию веб-сайта на сегодняшний день не является в России общераспространенной практикой. Как правило, выдается только набор руководств по работе с системой управления контентом и/или открывается доступ к соответствующему разделу сайта компании – разработчика такой системы.
Документы на стадии разработки
Обратите внимание, что еще при заказе веб-сайта вам должны быть предоставлены:
♦ Договор на разработку веб-системы
♦ Календарный план
♦ Бюджет
♦ Техническое задание
♦ Договор на поставку (лицензирование) программного обеспечения
Ключевыми являются два документа – договор и техническое задание.
...Отдельные компании предлагают Клиентам набор полезных материалов (например, методику выбора подрядчика) уже на предпроектной стадии
Договор на разработку должен фиксировать все основные аспекты взаимодействия подрядчика и заказчика и может иметь следующую структуру:
♦ Предмет договора (наименование предоставляемой услуги, перечень приложений, условия вступления договора в силу и т. д.)
♦ Прочие условия (максимально возмещаемый ущерб, параметры использования электронных коммуникаций и т. д.)
♦ Ответственность сторон и регламент (условия выплаты неустоек, механизмы пролонгации, условия расторжения договора и т. д.)
♦ Форс-мажор
♦ Стоимость и условия оплаты (стоимость исполнения работ, схема оплаты и т. д.)
♦ Терминология
♦ Права и обязанности сторон (указание исполняемых работ, условия привлечения сторонних подрядчиков, правила обмена проектной информацией, распределение авторских прав и т. д.)
♦ Конфиденциальность информации (условия соблюдения конфиденциальности, способы защиты информации, срок действия режима конфиденциальности и т. д.)
♦ Реквизиты и подписи сторон
...Вся истина в ТЗ
Техническое задание (ТЗ) на разработку веб-системы обычно оформляется как приложение к основному договору. Объем ТЗ, составляемого серьезным разработчиком, может доходить до 60–80 листов и включать несколько сотен параметров.
Подготовка технического задания – это всегда итерационный процесс, в котором участвуют как представители заказчика, так и специалисты со стороны разработчика.
Структура технического задания может выглядеть следующим образом:
♦ Общая информация
• Общая информация о заказчике
• Общая информация о проекте
• Общие вопросы обслуживания
♦ Требования к информационной инфраструктуре
• Общее устройство системы
• Роли
• Доменные имена
• Карта фронт-офиса
• Объемы и форматы информации
• Многоязычность
• Учет требований поисковых систем
♦ Календарный план выполнения работ с указанием ответственности сторон
♦ Требования к технической инфраструктуре
• Требования к программноаппаратной платформе
• Требования к используемым технологиям
• Требования к хостинговой площадке
• Требования к производительности
• Требования к безопасности
♦ Требования к интерфейсу
• Требования к дизайнерскому решению
• Предоставляемые заказчиком визуальные компоненты
• Требования к навигации, шрифтам, сетке форматирования
♦ Требования к мультимедийным элементам
• Перечень
• Формат
• Условия работы
♦ Регламент выполнения работ на этапах проектирования, разработки, тестирования, документирования и обучения, запуска веб-сайта и гарантийного обслуживания
♦ Требования к функциональности веб-сайта : полный перечень сервисов, предоставляемых системой, – каталоги товаров, системы регистрации-авторизации, форумы, подписки, рассылки. По каждому сервису должны быть определены: его вид на сайте, логика работы, управляемость, невидимые составляющие – интеграция, почта и т. п.
Документация на стадии поддержки и развития
Документированию подлежит не только стадия разработки, но и стадия поддержки и развития. На ней обычно поставляются:
♦ Договор о поддержке , определяющий условия предоставления соответствующей услуги
♦ Документ о передаче логинов и паролей
♦ Руководство по администрированию (документ, фиксирующий требования к программно-технологическим аспектам системы, – таким, как режимы работы серверов, настройки шлюзов, протоколы обмена данными и т. д.)
♦ Руководство разработчика (документ, описывающий программные составляющие системы – классы, функции, бизнес-логика и т. п.)
♦ Стандарты оформления (документ может включать правила использования шрифтов, цветовые схемы, принципы оформления гиперссылок, требования к верстке контента и стилистике изложения, описание типовых ошибок в публикации и дизайне, примеры адаптации стандартов Руководства по фирменному стилю к веб-среде и т. д.)
