Как писать техническое задание на сайт?

Как писать техническое задание на сайт?

Гарьят мартьеновские пьечи,

Каторый год гарьят аньи...

© Тото Кутуньо (Toto Cutugno)

«Мы не пашем, не сеем, не строим - мы гордимся общественным строем!» Промышленное производство продукции два десятка лет как дышит на ладан, страна живет услугами и торговлей. Продвижение на рынках товаров и услуг немыслимо без рекламы, - «Вести бизнес без рекламы - все равно, что подмигивать девушкам в темноте...» © Брит Стюарт Хендерсон. Наиболее доступная и относительно эффективная реклама (в частности, колы ) - реклама в сети Интернет, чем и обусловлен рост потребности в Интернет-ресурсах, в их разработке и документировании. Это первое.

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

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

• первоочередная - разобраться с терминологией и определиться с классификацией web-ресурсов;
• последующая - показать наполнение основных разделов техзадания на web-ресурсы в зависимости от их классификации.

Терминология, применимая к web-ресурсам

Поскольку речь идет о техническом задании на сайт, следует скорейшим образом определиться с терминологией. К сожалению, термин «web-сайт» в солидных изданиях, подобных толковому словарю Ожегова и Шведовой (по понятным причинам), отсутствует. Но «на безрыбье и поросенок - соловей», поэтому пришлось обратиться к не менее солидному интернет-изданию - википедии. Итак, web-сайт с точки зрения википедии:

О как! Благодарим безымянный авторский коллектив за глубокую проработку вопроса...

Что же в реальности? Имеется физический сервер (средство технического обеспечения), на котором установлена операционная система (общее программное обеспечение), «поверх» которой выполняется web-сервер Apache (nginx и т.п.) - «технологическое» программное обеспечение. На жестких дисках физического сервера размещается та самая «совокупность документов частного лица или организации» в виде файлов формата HTML (часть информационного обеспечения). Это «серверная» часть вопроса.

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

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

Серверная часть ожидает запроса со стороны пользователя. Пользователь с помощью web-браузера формирует запрос по протоколу HTTP, запрос поступает на серверную часть, после чего серверная часть формирует ответ, передавая пользовательскому браузеру HTML-страницу посредством протокола HTTP.

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

1. серверная и клиентская стороны оснащены средствами технического обеспечения (физический сервер и пользовательский компьютер);
2. обе стороны применяют общее и «технологическое» программное обеспечение (операционные системы и т.д.);
3. на серверной части имеет место быть информационное обеспечение - «совокупность документов частного лица или организации»;
4. пользователь (а имеется еще и пользователь) получает информацию с сервера на одном или нескольких языках - признаки лингвистического обеспечения;
5. кто-то же создает и заливает на сервер «совокупность документов частного лица или организации»? Все признаки организационного обеспечения;
6. и т. д...

Обратимся к первоисточникам.

Налицо персонал, комплекс средств автоматизации, перечисленные виды обеспечения - компоненты АС и т.д. Таким образом, клиентская и серверная стороны обладают всеми признаками автоматизированной системы.

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

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

Классификация web-сайтов

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

• посещаемость сайта и, как следствие;
• суточный (месячный и т.д.) объем трафика, передаваемого от сайта пользователям.

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

Для ресурсов с невысокой посещаемостью - 500 хостов, 2000 хитов и «текстовым» трафиком - достаточно виртуального хостинга с бюджетным тарифным планом, а из персонала - редактора и администратора в одном лице. Для ресурсов, подобных порталу sportbox.ru, на который единовременно заходят десятки и сотни тысяч посетителей, просматривающих прямые телевизионные трансляции, необходимы десятки кластеризованных физических серверов, каналы связи с гигабитной (и выше) пропускной способностью, команда круглосуточно дежурящих администраторов, программистов, верстальщиков и редакторов в полсотни человек.

В первом случае финансовые затраты составят примерно 3 тыс. рублей в год за хостинг плюс зарплата редактора-админа. Во втором случае десятки миллионов рублей пойдут на закупку серверного и иного оборудования, а уж зряплаты творческого коллектива портала в совокупности составят от трех до пяти миллионов рублей ежемесячно.

Таким образом, указанные выше критерии можно считать основополагающими, первичными «половыми признаками», а изложенные в википедии - вторичными.

Разделы технического задания на сайт

Коль скоро выяснилось, что web-сайт является фронтальной частью автоматизированной системы, имеет смысл сдуть пыль с ГОСТ 34.602-89 и углубиться в его изучение. Далее будет рассмотрено содержание основных разделов технического задания по ГОСТ 34.602-89.

Назначение и цели создания системы

Следует напомнить, что собственно сайт - всего лишь некая завлекуха для посетителя, а автоматизированная система сайта обеспечивает функционирование и доступность посетителю этой самой завлекухи. Таким образом, цели и задачи, как и все, имеет смысл «взять и поделить»: мухи - отдельно, котлеты - отдельно. В итоге получится четыре подраздела - назначение сайта, назначение системы, цели создания сайта и цели создания системы.

Назначение сайта

Сайт предназначен для решения перечисленных ниже задач:

1. задачи создания (на основе информационных технологий) единого информационного пространства, обеспечивающего возможности:
   1. предоставления жителям города комплексного доступа к информационным материалам (статьям, новостям, видео и другим формам представления информации), связанным с актуальными вопросами городской жизни, решением социально-значимых проблем, таких как поиск работы, получение правовых консультаций, развитие профессиональных навыков и т.п.;
   2. организации интерактивного взаимодействия пользователей (жителей) округов города между собой и с представителями государственной и муниципальной власти путем предоставления комплекса бесплатных интерактивных услуг группового общения и обмена информацией, возможности публикации собственного мнения о наиболее актуальных событиях и проблемах жизнедеятельности города (ведение персональных и групповых страниц членов сообществ, сетевых дневников (блогов), индивидуальных и групповых форумов, сервисов обмена фото- и видеофайлами, сервисов проведения опросов и интерактивных голосований (в том числе с использованием средств мобильной связи);
   3. получения неформальной информации о состоянии общественных настроений по наиболее актуальным для города проблемам и формирования на ее основе статистически достоверной информации;
   4. организации эффективного взаимодействия между различными уровнями государственной и муниципальной власти в ходе выполнения ими своих служебных обязанностей;
   5. для представителей бизнеса - предоставление возможностей для использования ресурсов сайта как средства независимой диагностики общественно-политических и социально-экономических условий для своего потенциального участия в реализации городских проектов и программ.
2. задачи окупаемости сайта и получения прибыли от контекстной рекламы, голосований на основе sms-сообщений, а также коммерческой реализации экспортируемых во внешние (негосударственные) системы информационных продуктов и услуг.

Назначение АС сайта

АС сайта предназначена для решения перечисленных ниже задач:

1. задачи обеспечения надежного функционирования сайта;
2. задачи обеспечения адаптивности к изменяющимся требованиям пользователей сайта за счет увеличения числа и качественных показателей предоставляемых сайтом услуг;
3. задачи обеспечения единого унифицированного механизма поиска по всем информационным объектам сайта, включая индексацию и поиск объектов, используемых в рамках подсистемы «...», а также сервисов публикации мультимедийной информации;
4. задачи обеспечения единого механизма регистрации, авторизации и аутентификации пользователей в рамках всех персонифицированных сервисов, предоставляемых сайтом (Форум, Вопрос-Ответ и т.п.);
5. задачи обеспечения единого механизма сбора, хранения, анализа и предоставления статистических данных о востребованности публикуемых индивидуальных страниц сайта, а также информационных и сервисных разделов внешнего интерфейса сайта;
6. задачи обеспечения доступности сайта для конечных пользователей и партнеров;
7. задачи обеспечения масштабирования как сайта, так и АС сайта в целом.

Цели создания сайта

Целями создания сайта являются:

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

Цели создания АС сайта

Целями создания АС сайта являются:

1. повышение надежности функционирования сайта до значения не менее 99,99 % (24 часа 7 дней в неделю 365 дней в году);
2. повышение доступности сайта для конечных пользователей и партнеров;
3. повышение адаптивности к изменяющимся требованиям пользователей сервисов сайта;
4. повышение комплексности подачи информации в рамках интересующей пользователя проблемной области, т.е. повышения уровня «проблемной» ориентированности публикуемых индивидуальных страниц сайта, заключающейся в предоставлении по запросу пользователей максимально возможного количества аннотированных информационных объектов различных типов;
5. повышение эффективности предоставляемых административных средств обратной связи с аудиторией сайта, в частности, создание административных средств оперативного автоматизированного анализа и предоставления динамических аналитических (служебных) отчетов о востребованности пользователями той или иной публикуемой информации и/или предоставляемой услуги;
6. дальнейшее развитие функциональных возможностей информационно-аналитической системы и повышение эффективности ее использования в текущей работе сотрудников;
7. повышение производительности, позволяющей масштабировать сервисы сайта в широких пределах;
8. повышение масштабируемости подсистем за счет увеличения количества серверов в них;
9. повышение масштабируемости всей АС сайта за счет увеличения количества подсистем (наращивание предоставляемых АС сайта сервисов).

Выводы

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

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

Требования к структуре и функционированию системы

Какие требования к структуре и функционированию системы можно придумать для сайта-визиточки, состоящего из страничек «Новости», «О нас», «Услуги» и «Контакты»? Да никаких... Странички сливаются на виртуальный хостинг через файловый менеджер в виде web-формы, указывается вид стартового файла index (html, php, asp), и на этом все заканчивается. Решение иных вопросов на свои хрупкие плечи возлагает хостинг-провайдер. А как быть с аналогичными требованиями к серьезному порталу? На рисунке (ниже) приведено определение интернет-портала, представляющееся автору более-менее обоснованным. Обычный сайт отличается от портала только тем, что не предоставляет посетителю возможностей интерактивного взаимодействия.

Начнем с контента (информационного обеспечения). Контент может быть как статический (файлы htm и т.д), так и динамический (извлекаемый скриптами из базы данных). Следовательно, в структуру системы войдут уже целых две подсистемы - подсистема хранения данных (файловое хранилище) и подсистема баз данных (реляционное хранилище динамического контента).

А как балансировать пользовательские запросы? Созданием подсистемы балансировки запросов. А если налетят злобные хакеры? Придется создать подсистему безопасности...

А как работать с удаленным персоналом? Организацией подсистемы удаленного доступа: точки входа для админов, точки входа для программеров, точки входа для редакторов, тестеров, техписов (прости, господи!) и т.д.

А как тестировать систему? Созданием тестовых серверов и подсистемы прототипирования.

А как вообще все это увязать промеж себя? Организацией подсистемы сетевой инфраструктуры. И так далее...

В сухом остатке:

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

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

Требования к способам и средствам связи для информационного обмена между компонентами системы

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

Физически каналы связи могут быть выполнены как угодно: оптикой (ВОЛС), 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 (для видеомониторов с ЭЛТ).

Комфортность условий работы персонала

Для серьезных порталов. Нормативы: ГОСТ 21958, ГОСТ 12.2.049, ГОСТ 20.39.108.

Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

Виды и периодичность обслуживания ТС системы или допустимость работы без обслуживания

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

• ежедневное техническое обслуживание (ТО-1 или ЕТО);
• ежемесячное техническое обслуживание (ТО-2);
• полугодовое техническое обслуживание (ТО-3).

Предварительные требования к допустимым площадям для размещения персонала и ТС системы

Согласно СанПиН 2.2.2.542-96.

Требования к параметрам сетей энергоснабжения

Согласно ГОСТ 13109-97.

Требования к защите информации от несанкционированного доступа

Кому не лень, тот поднимет руководящие документы ФСТЭК (бывш. Гостехкомиссия), классифицирует автоматизированную систему и распишет требования по защите от НСД согласно вида АС.

Требования по сохранности информации при авариях

Система в целом должна обеспечивать сохранность, целостность и корректность информации:

• процедурой восстановления требуемого объема информации по всем уровням иерархии после восстановления;
• резервным копированием содержимого баз данных на внешние носители информации.

Требования к защите от влияния внешних воздействий

Для серьезных порталов следует определить класс оборудования согласно ГОСТ Р 51318.22, а также требования к стойкости, устойчивости и прочности к воздействию внешних факторов. А ВВФ много - в одном только ГОСТ 26883-86 дано целых 56 терминов и определений. Наиболее актуальные из них (в части технических средств портала, размещаемых в специально оборудованных помещениях):

• из механических ВВФ:
  • шум;
  • механический удар;
  • сейсмическое воздействие;
  • механические колебания;
  • вибрация.
• из климатических ВВФ:
  • динамическая и статическая пыль (песок);
  • интегральное солнечное излучение.
• из термических ВВФ:
  • электрическое разогревание;
  • ультразвуковое разогревание.
• а также воздействующие факторы электромагнитных полей.

Требования к функциям (задачам), выполняемым системой

Здесь все сугубо индивидуально, поскольку функционал web-сайтов может существенно отличаться. Форумы, галереи, блоги, опросы, чаты и т.д. - функционал у каждого свой.

Требования к видам обеспечения

Требования к информационному обеспечению

В данном разделе речь пойдет о той самой «совокупности документов частного лица или организации». Очевидно, что «документы» должны быть структурированы - сайт должен иметь некую структуру разделов, схему навигации и т.д. На рисунке (ниже) показан макет структуры разделов (через главное меню) портала tdocs.su.

При разработке технической документации для серьезных порталов часто прибегают к термину «информационный объект». К информационным объектам можно причислить структуру разделов портала, систему навигации, собственно контент - статьи, новости, анонсы, аудио-видеоконтент и многое другое - дело вкуса. Информационные объекты в своей совокупности составляют информационное обеспечение системы.

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

Требования к лингвистическому обеспечению

Помимо языковых требований лингвистическое обеспечение должно обеспечивать:

• текстовый и графический способы представление информации пользователям;
• диалоговый режим взаимодействия пользователей с комплексом средств автоматизации с возможностью конфигурирования диалогов человек-машина, включая:
  1. удобство расположения и представления (удобство использования) часто используемых элементов интерфейса, способов ввода данных и др.;
  2. наличие «горячих» клавиш, меню, кнопок;
  3. адаптируемость к различным текстурам шрифтов, режимам текстового и графического представления, различным форматам даты, способам ввода/вывода (экранным формам и форматам), изменениям в методологии (изменениям графических нотаций, правил, свойств и состава предопределенных объектов), способам работы с помощью клавиатуры, мыши и др.;
  4. возможность сохранения однажды сделанных настроек;
  5. минимизацию трудовых и временнЫх затрат на освоение;
  6. полную локализацию;
  7. унифицированность;
  8. онлайновые подсказки.
• формирование запросов с пользовательского компьютера;
• защиту от ошибок и некорректных действий пользователей (форматно-логический контроль).

Все идет к пользовательскому интерфейсу - вот где раздолье для дизайнеров и верстальщиков! Самое время сформулировать требования к интерфейсу пользователя, включив в них всякие картинки, менюшки, кнопочки - юзабилистская братва разбирается в данных вопросах куда лучше автора.

Требования к программному обеспечению

К визиткам не предъявляется. К серьезным порталам - требования самые серьезные. Общеизвестно, что ОПО, производимое конторой нашего американского друга Билла, малопригодно для порталов с большим трафиком, требующим, к тому же, высокого уровня информационной безопасности. Таким образом, лучший путь - решения open source.

Из личного опыта автора: пока сайт authorit.ru «висел» на NT-хостинге, он и «висел» в буквальном смысле слова. Не было ни дня, чтобы сайт был полностью доступен, а уж в выходные достучаться до него (и техподдержки) было и вовсе невозможно. Когда окончательно надоела ежедневная ругань со службой техподдержки хостинг-провайдера, был совершен переход на UNIX-хостинг и все проблемы исчезли сами собой.

Раскрывать секреты мастерства админов автор не вправе, но рекомендовать решения на основе OpenVZ, MySQL, PostgreSQL и Drupal (для порталов) вправе.

Требования к техническому обеспечению

Относятся к серьезным порталам. Предварительно следует оценить объемы хранения данных и объемы трафика - на их основе требования к техническим средствам хранения данных и к ТС каналообразования родятся сами собой. Ну и, разумеется, к производительности серверного оборудования. Какую либо конкретику для данного раздела привести трудно, но в АС портала sportbox.ru задействовано свыше 40 блейд-серверов от HP.

Требования к организационному обеспечению

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

Состав и содержание работ по созданию системы

Данный и нижележащие разделы детально приведены в документах:

• «Как писать раздел ТЗ «Состав и содержание работ по созданию системы» по ГОСТ 34.602-89?»;
• «Как писать раздел ТЗ «Порядок контроля и приемки системы» по ГОСТ 34.602-89?»;
• «Как писать раздел ТЗ «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие» по ГОСТ 34.602-89?».

Итоги

Цели, как всегда, достигнуты, задачи решены. С терминологией и классификацией web-ресурсов определились, расширили и углУбили, внесли ясность, чем заполнять разделы технического задания на сайт в зависимости от вида web-ресурса.

Удачи!

Заказать услуги, установить контакты со специалистами компании можно по электронной почте admin собака tdocs точка su, по ICQ UIN 481-726-610 или с помощью формы «Контакты». Вопросы некоммерческого характера могут быть заданы в Форуме проектировщиков и разработчиков технической документации.