Техническое задание на сайт: понятие веб-сайта, классификация веб-сайтов, веб-сайт как фронтальная часть автоматизированной системы или системы обработки информации, методика заполнения разделов техзадания на разработку сайтов. Функциональная часть изложена в статье Как писать техническое задание для сайта на Drupal? Редакция от 08.12.2023.
Создан 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?».
Итоги
Цели, как всегда, достигнуты, задачи решены. С терминологией и классификацией веб-ресурсов определились, расширили и углУбили, внесли ясность, чем заполнять разделы технического задания на сайт в зависимости от вида Интернет-ресурса.
Удачи!
