Техническое задание на сайт: понятие веб–сайта, классификация веб–сайтов, веб–сайт как фронтальная часть автоматизированной системы или системы обработки информации, методика заполнения разделов техзадания на разработку сайтов. Функциональная часть изложена в статье Как писать техническое задание для сайта на Drupal? Редакция от 09.12.2024.
Создан 04.01.2009 16:59:54
«Мы не пашем, не сеем, не строим — мы гордимся общественным строем!» Промышленное производство продукции два десятка лет как дышит на ладан, страна живет услугами и торговлей. Продвижение товаров и услуг немыслимо без рекламы. Наиболее доступная и относительно эффективная реклама — баннерная реклама в сети Интернет, чем и обусловлен рост потребности в Интернет–ресурсах, в их разработке и документировании. Это первое.
Второе. В моде (и финансируются государством) всевозможные портальные решения различного уровня сложности в рамках программ «Электронная Россия», «Электронная Москва», «Электронное правительство» и т.д. Сей факт открывает оперативный простор для разработчиков технической документации, поскольку разработки портальных решений проводятся по государственным контрактам, а документирование необходимо вести согласно требованиям ГОСТов.
В сети имеется множество материалов на тему «как написать хорошее ТЗ на сайт?», освещающих вопрос не слишком широко и всенародно. В этой связи основная цель данной статьи — «расширить и углУбить», дополнить, внести ясность в вопросы разработки технических заданий на сайты и портальные решения. Задачи:
- первоочередная — разобраться с терминологией и определиться с классификацией веб–ресурсов;
- последующая — показать наполнение основных разделов техзадания на веб–ресурсы в зависимости от их классификации.
Терминология, применимая к веб–ресурсам
Поскольку речь идет о техническом задании на сайт, следует скорейшим образом определиться с терминологией. К сожалению, термин «веб–сайт» в солидных изданиях отсутствует, поэтому пришлось обратиться к отсылочной базе данных — Педевикии. Итак, веб–сайт с точки зрения Педевикии:
Глубокая проработка вопроса...
Примечание от 22.08.2014 г. — Совсем недавно был введен в действие ГОСТ Р 52872–2012 Интернет–ресурсы. Требования доступности для инвалидов по зрению. В нем приведена кривенькая и очень–очень спорная терминология, но ГОСТ есть ГОСТ и придется пользоваться именно им.
Что же в реальности? Имеется физический сервер (средство технического обеспечения), на котором установлена операционная система (общее программное обеспечение), «поверх» которой выполняется веб–сервер Apache (nginx и т.п.) — «технологическое» программное обеспечение. На жестких (или SSD) дисках физического сервера размещается та самая «совокупность документов частного лица или организации» в виде файлов формата HTML (часть информационного обеспечения). Это «серверная» часть вопроса.
Имеет место и «клиентская» часть: пользовательский компьютер (или автоматизированное рабочее место), установленная на нем операционная система (общее программное обеспечение), выполняющийся под ее управлением веб–браузер клиента (пользователя).
Клиентская и серверная части взаимодействуют между собой посредством канала связи — неважно, какого именно — сетевые карты пользовательского компьютера и сервера можно просто соединить кросс–кабелем, а то и вовсе установить клиентское и серверное ПО на одном компьютере.
Серверная часть ожидает запроса со стороны пользователя. Пользователь с помощью веб–браузера формирует запрос по протоколу HTTP, запрос поступает на серверную часть, после чего серверная часть формирует ответ, передавая пользовательскому браузеру веб–страницу посредством протокола HTTP.
Простенькая схема взаимодействия до слез понятна даже младенцу, но приведена она не ради проведения разъяснительной работы среди скучающих домохозяек, а с совершенно иной целью. Итак:
- серверная и клиентская стороны оснащены средствами технического обеспечения (физический сервер и пользовательский компьютер);
- обе стороны применяют общее и «технологическое» программное обеспечение (операционные системы и т.д.);
- на серверной части имеет место быть информационное обеспечение — «совокупность документов частного лица или организации»;
- пользователь (а имеется еще и пользователь) получает информацию с сервера на одном или нескольких языках — признаки лингвистического обеспечения;
- кто–то же создает и заливает на сервер «совокупность документов частного лица или организации»? Все признаки организационного обеспечения;
- и т. д...
Обратимся к первоисточникам. Автоматизированная система — это «Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций [из 1.1 ГОСТ 34.003–90]»
Налицо персонал, комплекс средств автоматизации, перечисленные виды обеспечения — компоненты АС и т.д. Таким образом, клиентская и серверная стороны обладают всеми признаками автоматизированной системы.
Немножко о ролях. Для посетителя сайта, использующего результаты функционирования автоматизированной системы, сам сайт является всего лишь графическим пользовательским интерфейсом автоматизированной системы — ее фронтальной частью. Для лица, участвующего в функционировании системы — администратора, прикручивающего сервер в стойку, поддерживающего работоспособность ПО, для редактора, набивающего сайт содержимым — важна тыловая часть автоматизированной системы.
Таким образом, веб–сайт является всего лишь пользовательским интерфейсом — фронтальной частью автоматизированной системы, обеспечивающей доступность информационного обеспечения системы конечному пользователю — посетителю — посредством пользовательского интерфейса. Наверное, подобное определение будет более точным, нежели то, что приведено в Педевикии.
Классификация веб–сайтов
Классификация веб–сайтов также раскрыта в Педевикии не должным образом, поскольку рассмотрена исключительно с точки зрения пользователя и выглядит довольно однобоко. В качестве основных классификационных признаков следовало бы использовать, как минимум:
- посещаемость сайта и, как следствие;
- суточный (месячный и т.д.) объем трафика, передаваемого от сайта пользователям.
От перечисленных выше взаимосвязанных классификационных признаков крайне сильно зависят требования к техническому и программному обеспечению автоматизированной системы, поддерживающей функционирование и доступность посетителю своей фронтальной части — собственно, сайта. И «пиастры, пиастры»...
Для ресурсов с невысокой посещаемостью — 500 хостов, 2000 хитов и «текстовым» трафиком — достаточно виртуального хостинга с бюджетным тарифным планом, а из персонала — редактора и администратора в одном лице. Для ресурсов, подобных порталу sportbox.ru, на который единовременно заходят десятки и сотни тысяч посетителей, просматривающих прямые телевизионные трансляции, необходимы десятки кластеризованных физических серверов, каналы связи с гигабитной (и выше) пропускной способностью, команда круглосуточно дежурящих администраторов, программистов, верстальщиков и редакторов в полсотни человек.
В первом случае финансовые затраты составят примерно 3 тыс. рублей в год за хостинг плюс зарплата редактора–админа. Во втором случае десятки миллионов рублей пойдут на закупку серверного и иного оборудования, а уж зряплаты творческого коллектива портала в совокупности составят от трех до пяти миллионов рублей ежемесячно.
Таким образом, указанные выше критерии можно считать основополагающими, первичными «половыми признаками», а изложенные в Педевикии — вторичными.
Разделы технического задания на сайт
Коль скоро выяснилось, что веб–сайт является фронтальной частью автоматизированной системы, имеет смысл сдуть пыль с ГОСТ 34.602–89 и углубиться в его изучение. Далее будет рассмотрено наполнение содержанием основных разделов технического задания по ГОСТ 34.602–89.
Назначение и цели создания системы
Следует напомнить, что собственно сайт — всего лишь некая завлекуха для посетителя, а автоматизированная система сайта обеспечивает функционирование и доступность посетителю этой самой завлекухи. Таким образом, цели и задачи, как и все, имеет смысл «взять и поделить»: мухи — отдельно, котлеты — отдельно. В итоге получится четыре подраздела — назначение сайта, назначение системы, цели создания сайта и цели создания системы.
Далее: |
Назначение сайта
Сайт предназначен для решения перечисленных ниже задач:
- задачи создания (на основе информационных технологий) единого информационного пространства, обеспечивающего возможности:
- предоставления жителям города комплексного доступа к информационным материалам (статьям, новостям, видео и другим формам представления информации), связанным с актуальными вопросами городской жизни, решением социально–значимых проблем, таких как поиск работы, получение правовых консультаций, развитие профессиональных навыков и т.п.;
- организации интерактивного взаимодействия пользователей (жителей) округов города между собой и с представителями государственной и муниципальной власти путем предоставления комплекса бесплатных интерактивных услуг группового общения и обмена информацией, возможности публикации собственного мнения о наиболее актуальных событиях и проблемах жизнедеятельности города (ведение персональных и групповых страниц членов сообществ, сетевых дневников (блогов), индивидуальных и групповых форумов, сервисов обмена фото– и видеофайлами, сервисов проведения опросов и интерактивных голосований (в том числе с использованием средств мобильной связи);
- получения неформальной информации о состоянии общественных настроений по наиболее актуальным для города проблемам и формирования на ее основе статистически достоверной информации;
- организации эффективного взаимодействия между различными уровнями государственной и муниципальной власти в ходе выполнения ими своих служебных обязанностей;
- для представителей бизнеса — предоставление возможностей для использования ресурсов сайта как средства независимой диагностики общественно–политических и социально–экономических условий для своего потенциального участия в реализации городских проектов и программ.
- задачи окупаемости сайта и получения прибыли от контекстной рекламы, голосований на основе sms–сообщений, а также коммерческой реализации экспортируемых во внешние (негосударственные) системы информационных продуктов и услуг.
Назначение АС сайта
АС сайта предназначена для решения перечисленных ниже задач:
- задачи обеспечения надежного функционирования сайта;
- задачи обеспечения адаптивности к изменяющимся требованиям пользователей сайта за счет увеличения числа и качественных показателей предоставляемых сайтом услуг;
- задачи обеспечения единого унифицированного механизма поиска по всем информационным объектам сайта, включая индексацию и поиск объектов, используемых в рамках подсистемы «...», а также сервисов публикации мультимедийной информации;
- задачи обеспечения единого механизма регистрации, авторизации и аутентификации пользователей в рамках всех персонифицированных сервисов, предоставляемых сайтом (Форум, Вопрос–Ответ и т.п.);
- задачи обеспечения единого механизма сбора, хранения, анализа и предоставления статистических данных о востребованности публикуемых индивидуальных страниц сайта, а также информационных и сервисных разделов внешнего интерфейса сайта;
- задачи обеспечения доступности сайта для конечных пользователей и партнеров;
- задачи обеспечения масштабирования как сайта, так и АС сайта в целом.
Цели создания сайта
Целями создания сайта являются:
- повышение информированности жителей города по актуальным вопросами городской жизни;
- улучшение информационного взаимодействия между властью и обществом;
- повышение эффективности информационного мониторинга и управления состоянием общественного мнения за счет повышения достоверности статистической информации, характеризующей состояние общественного мнения по наиболее актуальным социальным и управленческим аспектам жизнедеятельности города;
- повышение эффективности взаимодействия между различными уровнями государственной и муниципальной власти в ходе выполнения ими своих служебных обязанностей;
- повышение сбалансированности управленческих и хозяйственных решений.
Цели создания АС сайта
Целями создания АС сайта являются:
- повышение надежности функционирования сайта до значения не менее 99,99 % (24 часа 7 дней в неделю 365 дней в году);
- повышение доступности сайта для конечных пользователей и партнеров;
- повышение адаптивности к изменяющимся требованиям пользователей сервисов сайта;
- повышение комплексности подачи информации в рамках интересующей пользователя проблемной области, т.е. повышения уровня «проблемной» ориентированности публикуемых индивидуальных страниц сайта, заключающейся в предоставлении по запросу пользователей максимально возможного количества аннотированных информационных объектов различных типов;
- повышение эффективности предоставляемых административных средств обратной связи с аудиторией сайта, в частности, создание административных средств оперативного автоматизированного анализа и предоставления динамических аналитических (служебных) отчетов о востребованности пользователями той или иной публикуемой информации и (или) предоставляемой услуги;
- дальнейшее развитие функциональных возможностей информационно–аналитической системы и повышение эффективности ее использования в текущей работе сотрудников;
- повышение производительности, позволяющей масштабировать сервисы сайта в широких пределах;
- повышение масштабируемости подсистем за счет увеличения количества серверов в них;
- повышение масштабируемости всей АС сайта за счет увеличения количества подсистем (наращивание предоставляемых АС сайта сервисов).
Выводы
В статье использовались фрагменты «боевого» технического задания на автоматизированную систему одного из московских городских порталов. Понятно, что назначение и цели создания сайта–визитки или крутейшего порносайта с бешеной посещаемостью будут несколько отличаться, но все они пронизаны искренней заботой о нуждах простых граждан. В чем и состоит их единство.
Хочется надеяться, что приведенный выше пример наглядно иллюстрирует смысл разделения назначения и целей создания сайта и автоматизированной системы сайта. При этом — обратите внимание — цели и задачи «бьются», как бухгалтерская отчетность, т.е. для достижения цели 1 должна быть решена задача 1 — все конкретно, никакой воды.
Требования к структуре и функционированию системы
Какие требования к структуре и функционированию системы можно придумать для сайта–визитки, состоящего из страничек «Новости», «О нас», «Услуги» и «Контакты»? Да никаких... Странички сливаются на виртуальный хостинг через файловый менеджер в виде веб–формы, указывается вид стартового файла index.htm (html, php, asp), и на этом все заканчивается. Решение иных вопросов на свои хрупкие плечи возлагает хостинг–провайдер. А как быть с аналогичными требованиями к серьезному порталу? На рисунке ниже приведено определение интернет–портала, представляющееся автору более–менее обоснованным. Обычный сайт отличается от портала только тем, что не предоставляет посетителю возможностей интерактивного взаимодействия.
Начнем с контента (информационного обеспечения). Контент может быть как статический (файлы HTML и т.д), так и динамический (извлекаемый из базы данных). Следовательно, в структуру системы войдут уже целых две подсистемы — подсистема хранения данных (файловое хранилище) и подсистема баз данных (реляционное хранилище динамического контента).
А как балансировать пользовательские запросы? Созданием подсистемы балансировки запросов. А если налетят злобные хакеры? Придется создать подсистему безопасности...
А как работать с удаленным персоналом? Организацией подсистемы удаленного доступа: точки входа для админов, точки входа для программеров, точки входа для редакторов, тестеров, техписов (прости, господи!) и т.д.
А как тестировать систему? Созданием тестовых серверов и подсистемы прототипирования.
А как вообще все это увязать промеж себя? Организацией подсистемы сетевой инфраструктуры. И так далее...
В сухом остатке:
- подсистема хранения данных;
- подсистема баз данных;
- подсистема балансировки запросов;
- подсистема безопасности;
- подсистема удаленного доступа;
- подсистема прототипирования;
- подсистема сетевой инфраструктуры;
- и многие другие...
Подсистема — это тоже система, только маленькая. Она еще входит в состав системы в целом. Таким образом, структура системы уже вырисовывается. Ниже придется указать назначение и состав каждой из подсистем.
Требования к способам и средствам связи для информационного обмена между компонентами системы
Очевидно, что компоненты системы — в данном случае они представлены также и подсистемами — должны как–то между собой взаимодействовать. И совсем уж очевидно, что подобное взаимодействие может быть организовано посредством каналов связи.
Физически каналы связи могут быть выполнены как угодно: оптикой (ВОЛС), Ethernet и т.д. На практике широко применяется стандарт IEEE 802.x. Для сайтов–визиток формулировать в техническом задании требования данного раздела не имеет никакого смысла, поскольку указанные вопросы решаются хостинг–провайдером.
Требования к характеристикам взаимосвязей со смежными системами
И сайт–визитка, и серьезный портал могут взаимодействовать со смежными системами путем закачки и отображения информации с других сайтов. Модно (хотя и пОшло) размещать на сайтах информацию о погоде, о курсе валют, анонсы новостей и т.д. Таким образом, в техническом задании на сайт придется рассказать о добыче указанной информации:
- привести источники информации;
- указать способы получения информации из этих источников (RSS и прочее);
- возможно, и регламент связи.
Требования к совместимости со смежными системами
Требования к совместимости со смежными системами реализуются:
- применением развитых телекоммуникационных сетей;
- применением широкораспространенных сетевых протоколов, включая: (...);
- применением широкораспространенных форматов обмена данными.
Здесь речь идет как о технической, так и о информационной совместимостях астоматизированных систем.
Указания о способах обмена информацией
Подраздел говорит сам за себя — автоматически, вручную и т.д.
Требования к режимам функционирования системы
Требования к режимам функционирования системы:
- штатный режим;
- сервисный режим (для проведения обслуживания, реконфигурации и пополнения новыми компонентами);
- автономный режим с ограничением функций;
- тестовый режим;
- ремонтный режим.
Режимов можно выдумать много. Сайт–визитка всегда должен работать в штатном режиме, за исключением, быть может, времени перезаливки информации на хостинг. Серьезный портал, несмотря на все опасности, его подстерегающие, не должен надолго выпадать из штатного режима, поскольку в его функционировании задействована уйма персонала, готового в кратчайшие сроки устранить неполадки (сбои, отказы), провести обслуживание, диагностику и т.д.
Перспективы развития, модернизации системы
Перспективы развития, модернизации системы:
- возможность увеличения числа пользователей;
- возможность подключения новых каналов связи;
- возможность модернизации технических и программных средств (в части расширения функциональности) без вывода из постоянной эксплуатации и без потери данных;
- возможность расширения состава информации.
Для сайтов–визиток перечисленные возможности определяются тарифным планом хостинг–провайдера.
Требования к численности и квалификации персонала и режиму его работы
Численность персонала системы должна удовлетворять перечисленным ниже требованиям:
- быть достаточной для выполнения обязанностей по эксплуатации системы с учетом коэффициента готовности и времени восстановления;
- обеспечивать полную занятость персонала при выполнении обязанностей по эксплуатации системы.
Квалификация зависит от категории персонала: пользователь должен уметь работать с браузером и возить мышкой по столу, редактор должен уметь то же самое, что и пользователь, но еще редактировать материалы портала (информационное обеспечение), администратор — то же, что пользователь и редактор, но и еще много чего.
Режим работы для персонала серьезного портала, как правило, сменный круглосуточный.
Требования к надежности
Серьезные порталы, как и несерьезные сайты–визитки, должны быть доступны посетителю 365 дней в году, 7 дней в неделю и 24 часа в сутки. Надежность визиток берет на себя хостинг–провайдер, поэтому данный пункт требований для них неактуален. Надежность же серьезного портала должна быть выражена через коэффициент готовности, время восстановления и прочие показатели, регламентируемые ГОСТ 27.002–89, такие как показатели надежности, безотказности, долговечности, ремонтопригодности, сохраняемости и т.д. (для технических средств).
Для программного обеспечения портала стоит привести:
- показатели надежности;
- показатели корректности;
- показатели сопровождения;
- показатели удобства применения;
- показатели универсальности;
- показатели эффективности.
На первый взгляд приведенные показатели как бы не в тему, но именно они (в совокупности) и определяют надежность автоматизированной системы портала и доступность самого портала.
Требования безопасности
Требования безопасности актуальны лишь в том случае, если технические средства размещены непосредственно на площадях заказчика и их техническим обслуживанием и ремонтом занят персонал заказчика. Как обеспечена безопасность при обслуживании ТС в дата–центрах и у хостинг–провайдера — забота их руководителей. Стоит упомянуть о том, что квалификационная группа по электробезопасности для персонала, обслуживающего технические средства, должна быть не ниже III, для редакторов и прочих, работающих исключительно с компьютерами — не ниже II.
Требования по допустимым уровням освещенности, вибрационных и шумовых нагрузок
Актуальны для серьезных порталов, ТС которых размещены на площадях заказчика, особенно в тех случаях, когда под площадкой проходит неглубоко залегающая ветка метрополитена — земля буквально дрожит под ногами. Нормативы: СанПин 2.2.2.542–96, ГОСТ 12.1.012–90, ГОСТ 12.1.003–83, ГОСТ 12.1.036–81, ГОСТ 27818 и ГОСТ 26329 (имеет смысл проверить на изменения).
Требования к эргономике и технической эстетике
Для серьезных порталов. Нормативы: ГОСТ 12.2.049, ГОСТ 30.001, ГОСТ 20.39.108, ГОСТ 21958 и ГОСТ 50948 (для видеомониторов с ЭЛТ).
Примечание от 23.01.2022 – В стародавние времена подготовки настоящей статьи не был еще принят и введен в действие ГОСТ Р ИСО 9241–151–2014 Эргономика взаимодействия человек–система. Часть 151. Руководство по проектированию пользовательских интерфейсов сети Интернет. Ergonomics of human–system interaction. В нем хорошо и подробно все расписано.
Комфортность условий работы персонала
Для серьезных порталов. Нормативы: ГОСТ 21958, ГОСТ 12.2.049, ГОСТ 20.39.108.
Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
Виды и периодичность обслуживания ТС системы или допустимость работы без обслуживания
Для серьезных порталов. Виды обслуживания могут включать в себя периодического техническое обслуживание:
- ежедневное техническое обслуживание (ТО–1 или ЕТО);
- ежемесячное техническое обслуживание (ТО–2);
- полугодовое техническое обслуживание (ТО–3).
Предварительные требования к допустимым площадям для размещения персонала и ТС системы
Согласно СанПиН 2.2.2.542–96.
Требования к параметрам сетей энергоснабжения
Согласно ГОСТ 13109–97.
Требования к защите информации от несанкционированного доступа
Кому не лень, тот поднимет руководящие документы ФСТЭК (бывш. Гостехкомиссия), классифицирует автоматизированную систему и распишет требования по защите от НСД согласно вида АС.
Требования по сохранности информации при авариях
Система в целом должна обеспечивать сохранность, целостность и корректность информации:
- процедурой восстановления требуемого объема информации по всем уровням иерархии после восстановления;
- резервным копированием содержимого баз данных на внешние носители информации.
Требования к защите от влияния внешних воздействий
Для серьезных порталов следует определить класс оборудования согласно ГОСТ Р 51318.22, а также требования к стойкости, устойчивости и прочности к воздействию внешних факторов. А ВВФ много — в одном только ГОСТ 26883–86 дано целых 56 терминов и определений. Наиболее актуальные из них (в части технических средств портала, размещаемых в специально оборудованных помещениях):
- из механических ВВФ:
- из климатических ВВФ:
- из термических ВВФ:
- а также воздействующие факторы электромагнитных полей.
Требования к функциям (задачам), выполняемым системой
Здесь все сугубо индивидуально, поскольку функционал веб–сайтов может существенно отличаться. Форумы, галереи, блоги, опросы, чаты и т.д. — функционал у каждого свой. Для сайтов на Drupal функциональная часть расписана в статье
Требования к видам обеспечения
Требования к информационному обеспечению
В данном разделе речь пойдет о той самой «совокупности документов частного лица или организации». Очевидно, что «документы» должны быть структурированы — сайт должен иметь некую структуру разделов, схему навигации и т.д. На рисунке ниже показан макет структуры разделов (через главное меню) портала tdocs.su.
При разработке технической документации для серьезных порталов часто прибегают к термину «информационный объект». К информационным объектам можно причислить структуру разделов портала, систему навигации, собственно контент — статьи, новости, анонсы, аудио–видеоконтент и многое другое — дело вкуса. Информационные объекты в своей совокупности составляют информационное обеспечение системы.
Вопрос представления информационного обеспечения затруднений не вызывает: можно «разрисовать» ИО в виде структуры каталогов, в табличном или любом ином удобочитаемом виде. Но не следует забывать, что ИО хранится не только в базе данных или в файловой системе — ИО также представлено регламентами, инструкциями и иными бумажными документами, составляющими нормативно–справочную информацию машинной и внемашинной информационных баз.
Требования к лингвистическому обеспечению
Помимо языковых требований лингвистическое обеспечение должно обеспечивать:
- текстовый и графический способы представление информации пользователям;
- диалоговый режим взаимодействия пользователей с комплексом средств автоматизации с возможностью конфигурирования диалогов человек–машина, включая:
- удобство расположения и представления (удобство использования) часто используемых элементов интерфейса, способов ввода данных и др.;
- наличие «горячих» клавиш, меню, кнопок;
- адаптируемость к различным текстурам шрифтов, режимам текстового и графического представления, различным форматам даты, способам ввода/вывода (экранным формам и форматам), изменениям в методологии (изменениям графических нотаций, правил, свойств и состава предопределенных объектов), способам работы с помощью клавиатуры, мыши и др.;
- возможность сохранения однажды сделанных настроек;
- минимизацию трудовых и временнЫх затрат на освоение;
- полную локализацию;
- унифицированность;
- онлайновые подсказки.
- формирование запросов с пользовательского компьютера;
- защиту от ошибок и некорректных действий пользователей (форматно–логический контроль).
Все идет к пользовательскому интерфейсу — вот где раздолье для дизайнеров и верстальщиков! Самое время сформулировать требования к интерфейсу пользователя, включив в них всякие картинки, менюшки, кнопочки — юзабилистская братва разбирается в данных вопросах куда лучше автора.
Требования к программному обеспечению
К визиткам не предъявляется. К серьезным порталам — требования самые серьезные. Общеизвестно, что ОПО, производимое конторой нашего американского друга Билла, малопригодно для порталов с большим трафиком, требующим, к тому же, высокого уровня информационной безопасности. Таким образом, лучший путь — решения open source.
Из личного опыта автора: пока сайт authorit.ru «висел» на NT–хостинге, он и «висел» в буквальном смысле слова. Не было ни дня, чтобы сайт был полностью доступен, а уж в выходные достучаться до него (и техподдержки) было и вовсе невозможно. Когда окончательно надоела ежедневная ругань со службой техподдержки хостинг–провайдера, был совершен переход на UNIX–хостинг и все проблемы исчезли сами собой.
Раскрывать секреты мастерства админов автор не вправе, но рекомендовать решения на основе OpenVZ, MySQL, PostgreSQL и Drupal (для порталов) вправе.
Требования к техническому обеспечению
Относятся к серьезным порталам. Предварительно следует оценить объемы хранения данных и объемы трафика — на их основе требования к техническим средствам хранения данных и к ТС каналообразования родятся сами собой. Ну и, разумеется, к производительности серверного оборудования. Какую либо конкретику для данного раздела привести трудно, но в АС портала sportbox.ru задействовано свыше 40 блейд–серверов от HP.
Требования к организационному обеспечению
Самый сложный раздел технического задания на сайт, поскольку связан с персоналом. Самое разумное решение — поделить персонал на категории: пользователи, редакторы (контента), программисты, тестировщики и администраторы. Из категорий автоматически проистечет структура (или изменение в существующей структуре) подразделений, со скрипом будут обозначены должностные обязанности каждой из категорий персонала. В техническом задании лучше всего ограничиться перечисленным и отодвинуть принятие решений по организационному обеспечению на стадию технического проекта.
Состав и содержание работ по созданию системы
Данный и нижележащие разделы детально приведены в документах:
- «Как писать раздел ТЗ «Состав и содержание работ по созданию системы» по ГОСТ 34.602–89?»;
- «Как писать раздел ТЗ «Порядок контроля и приемки системы» по ГОСТ 34.602–89?»;
- «Как писать раздел ТЗ «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие» по ГОСТ 34.602–89?».
Итоги
Цели, как всегда, достигнуты, задачи решены. С терминологией и классификацией веб–ресурсов определились, расширили и углУбили, внесли ясность, чем заполнять разделы технического задания на сайт в зависимости от вида Интернет–ресурса.
Удачи!