ТЗ на WAN с нуля - прошу помощи
- Войдите на сайт для отправки комментариев
Зравствуйте, уважаемые писатели!
Давно читал этот форум, и вот настала пора попросить помощи. Если после первого поста не выгонят - будет очень хорошо. :roll:
У меня есть опыт написания "ТЗ". В кавычках потому, что хоть структура тех опусов, что я писал, и была близка с стандарту, но заполнение разделов было, мягко говоря, недостаточно грамотным.
Сейчас мне предстоит составить ТЗ на некую систему, причем составить его хочется грамотно, образцово-показательно.
Ну, вооружился я стандартами, перечитал по нескольку раз статьи на сайте - безусловно, хорошие статьи, направляют поток мыслей в правильно направлении. Составил себе документик со структурой ТЗ.
Но вот с чем я столкнулся в первую очередь - это с пониманием терминов... Но, обо всем по порядку.
Есть заказчик, у заказчика есть несколько офисов, расположеных в разных городах. Заказчик решил объединить все офисы в единую сеть. При этом, некий оператор предоставляет ему каналы передачи данных точка-точка, а наша задача - подобрать, поставить и настроить оборудование (на самом деле все уже подобрано и поставлено, но еще не настроено). Оборудование - маршрутизаторы. Пока дальше углубляться не буду.
Муки творчества начались с самого первого раздела...
1.1. Полное наименование системы и ее условное обозначение.
Как назвать эту систему - ума не приложу. Можно, конечно, назвать системой обработки и передачи информации, но это не совсем корректная формулировка из-за ширины понимания термина "информация". И как то мне интуитивно это название не очень нравится - само по себе оно достаточно широкое.
1.6 Сведения об источниках и порядке финансирования работ.
Не могу понять, что тут следовало бы указать, и стоит ли делать детализацию.
В одном ТЗ в этом пункте видел единственную фразу "Источники финансирования - собственные".
1.7 Порядок оформления и предъявления заказчику результатов работ по созданию системы.
В случае, если все оформление заключается в подписании бухгалтерских документов - может стоит удалить этот раздел?
Да и предъявление - звонок заказчику и уведомление - сделали, работает, проверяйте.
2.1 Назначение системы
2.2 Цели создания системы
Всегда путал назначение и цели.
По ГОСТ в п.2.1 "указывают вид автоматизируемой деятельности (управление, проектирование и т.п.)..." Загвоздка в том, что мы тут вроде как ничего и не автоматизируем. В том смысле, иначе, кроме как автоматически, пакеты информации по сети бегать и выбирать себе маршруты не могут. Можно притянуть за уши что-то типа "управление маршрутами передачи информации, полосой пропускания" и т.д. и т.п. Можно, но не нужно. Потому, что мы-то заказчику объединяем сети, а не передаем пакеты информации.
Аналогично по целям - "требуемые значения технических, технологических, производственно-экономических или других показателей". Какие могут быть "показатели"? Хотя, это следовало бы рассмотреть когда определюсь с назначением.
3 Характеристика объектов автоматизации
Что следовало бы считать объектом автоматизации? Территориально разнесенные ЛВС, которые объединяются? Или офисы в разных городах? Опять же, тут зависит от того, что автоматизируем.
Думаю, для первого поста хватит, хотя вопросов еще масса.
ТЗ на модернизацию - помнится по СРПП ВТ (давно это было) - пишут так же - как и на разработку системы (комплекса, устройства). Коль нет системы и ТУ на нее, то и ТЗ на ее модернизацию "не имеет места быть". В самом начале работ необходимо определить и объект, и предмет.
Еще вот такой вопрос - где мне разместить в ТЗ конкретные модели оборудования, интерфейсы подключения, размещение по офисам? Думаю, что в Требованиях по видам обеспечения, но не уверен.
И можно ли где-либо разместить схему (структурную)?
Фух, мозги сохнут.
Уважаемые, посмотрите, что получается...
4 Требования к модернизации системы
4.1 Требования к модернизации системы в целом
4.1.1 Требования к структуре и функционированию системы
4.1.1.1 Перечень подсистем, их назначение и основные характеристики, требования к числу уровней иерархии и степени централизации системы
4.1.1.1.1 Перечень подсистем, их назначение и основные характеристики
В результате модернизации Система должна включать в себя перечисленные ниже дополнительные подсистемы:
• подсистему каналов связи;
• подсистему оборудования связи.
Подсистема каналов связи предназначена для обеспечения связи между территориально–распределенными частями подсистемы оборудования связи. Характеристики подсистемы каналов связи должны быть определены заказчиком самостоятельно.
Подсистема оборудования связи предназначена для обеспечения информационного обмена между территориально-распределенными ЛВС. Подсистема оборудования связи должна обладать следующими основными характеристиками:
•
4.1.1.1.2 Требования к числу уровней иерархии
В результате модернизации Система должна обладать иерархической структурой, и включать в себя перечисленные ниже дополнительные уровни иерархии:
• уровень связи территориально-распределенных ЛВС.
4.1.1.1.3 Требования к степени централизации системы
Требования не предъявляются
4.1.1.2 Требования к способам и средствам связи для информационного обмена между компонентами системы
Связь между компонентами системы должна осуществляться автоматическим способом.
В системе должны применяться современные средства связи, удовлетворяющие требованиям национальных и международных нормативных документов.
4.1.1.3 Требования к режимам функционирования системы
Система должна обеспечивать возможность функционирования в круглосуточном режиме.4.1.2 Требования к численности и квалификации персонала системы и режиму его работы
4.1.2.1 Требования к численности персонала
Требования к численности персонала определяются заказчиком самостоятельно.
4.1.2.2 Требования к квалификации персонала, порядку его подготовки и контроля знаний и навыков
Квалификация персонала должна обеспечивать эффективное функционирование технических и программных средств системы во всех режимах работы системы.
4.1.2.3 Требуемый режим работы персонала АС
Режим работы персонала определяются заказчиком самостоятельно.4.1.3 Требования безопасности
При монтаже, эксплуатации, обслуживании и ремонте технических средств системы должны выполнятся требования следующих нормативных документов:
• Правила устройства электроустановок.
• ДНАОП 5.2.30-1.08-96 Правила безпеки при роботах на телефонних і телеграфних станціях.
• ДНАОП 0.00-1.31-99 Правила охорони праці під час експлуатації електронно-обчислювальних машин.
• ДСанПіН 3.3.6.096-2002 Державні санітарні норми і правила при роботі з джерелами електромагнітних полів.
• НАПБ А.01.001-2004 Правила пожежної безпеки в Україні.4.1.4 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
4.1.4.1 Условия и режим эксплуатации
Компоненты системы должны обеспечивать круглосуточный режим эксплуатации при соблюдении условий эксплуатации, приведенных в п.3.2.
4.1.4.2 Предварительные требования к допустимым площадям для размещения персонала и ТС системы
Технические средства подсистемы оборудования связи должны быть размещены в существующих аппаратных.
Требования к допустимым площадям для размещения персонала определяются заказчиком самостоятельно.
4.1.4.3 Требования по количеству, квалификации обслуживающего персонала и режимам его работы
Требования по количеству, квалификации обслуживающего персонала и режимам его работы определяются заказчиком самостоятельно.
4.1.4.4 Требования к регламенту обслуживания
Требования к регламенту обслуживания не предъявляются.4.2 Требования к функциям, выполняемым подсистемой оборудования связи
4.2.1 Перечень функций, подлежащих автоматизации
Подсистема оборудования связи должна обеспечивать выполнение следующих функций:
• функция обеспечения информационного обмена между территориально-распределенными ЛВС;
• функция обеспечения приема, обработки и передачи аудиоинформации.4.2.2 Временной регламент реализации каждой функции
Функции должны внедрятся поэтапно, по мере подключения офисов заказчика к каналам передачи данных оператором связи.
В самом приложении работы описаны как: "Работы по настройке и конфигурированию оборудования Cisco"
Вот и пишите задание не под заголовком «Техническое задание на модернизацию системы...», а под заголовком «Техническое задание на поставку и выполнение работ по настройке и конфигурированию оборудования Cisco для системы...».
Vadim, этого как раз и опасаюсь, поэтому и куча вопросов. Если бы я составлял ТЗ на строящуюся СКС, например, то и вопросов было бы меньше. И по подсистемам, и по уровням иерархии, и пр.
Договор уже подписан, и частично выполнен. :?
Просто ТЗ подписывается, как неоттъемлимая часть договора.
А в договоре:
1. Передача оборудования и выполнение работ осуществляются ИСПОЛНИТЕЛЕМ на протяжении сроков указанных в Приложениях, являющихся неотъемлемой частью настоящего Договора.
2. В самом приложении работы описаны как: "Работы по настройке и конфигурированию оборудования Cisco". И примечание "Выполнение работ по настройке и конфигурированию оборудования Cisco осуществляются ИСПОЛНИТЕЛЕМ на протяжении 7 календарных дней, при наличии каналов передачи данных." И все. Да, есть засада, наверное.
surgeon, про качество мы обычно в актах упоминаем. Типа, "качественно и в срок выполнил работы такие-то". Обычно подписывают без проблем.
Только про качество упоминать не стал бы Критерий должен быть, а без критерия это понятие весьма и весьма растяжимое.
ТЗ будет на модернизацию
Будьте осторожны! Важно предусмотреть в договоре, что Вы за модернизированную систему не в ответе, а отвечаете только за качественное и своевременное выполнение работ по модернизации системы в соответствии с требованиями ТЗ, иначе не оберетесь головной боли. И ТЗ нужно составлять таким образом, чтобы Вы обеспечивали выполнение только тех технических характеристик, которые зависят от результатов Вашей работы, а не от характеристик модернизируемой Вами системы.
В результате модернизации система должна включать в себя перечисленные ниже дополнительные подсистемы...
Подскажите оборот.
В пункте ТЗ
4.1.1.1.1 Перечень подсистем, их назначение и основные характеристики
следовало бы написать:
В результате модернизации Система будет состоять из следующих подсистем: - подсистема раз; - подсистема два.
или
Модернизированная Система будет состоять из следующих подсистем: - подсистема раз; - подсистема два.
или третий вариант - заменить слово "будет" на "должна".
Главный вопрос у меня в том, как сюда приплести "модернизацию". :?
И вот парой уровней выше заголовок:
4.1.1 Требования к структуре и функционированию системы
или:
4.1.1 Требования к структуре и функционированию модернизированной системы
или
4.1.1 Требования к структуре и функционированию системы в результате модернизации
Не хочется как-то писать требования к "системе" - как бы потом отвечать не пришлось.
И как я раньше не додумался... :?
В который раз убеждаюсь, что думать нужно вслух. Или на бумаге.
P.S. Не додумался наверное потому, что я не писатель - я разработчик.
Да, ТЗ на модернизацию дешевле обойдется
Это опять же вопрос терминологии.
В тексте ТЗ:
Система информационного обмена между территориально разнесенными локальными вычислительными сетями (далее по тексту Система).
Я таким образом попытался намеренно вынести локалки за рамки Системы , потому, что если я пишу ТЗ на Систему..... о, а какая мне замечательная только что мысль пришла - пусть оно будет Системой, но ТЗ будет на модернизацию! Если так, то тогда я могу ТЗ построить таким образом, что Система дополняется подсистемами каналов передачи данных и оборудования передачи информации, и в4 разделе я могу уже писать только о своей подсистеме, без дальнейшего дробления.
Только вот про уровни предложенное деление не подходит. Т.к. Система (в терминах конкретного ТЗ) включает только маршрутизаторы. А каналы и сетки - это, так сказать, смежные системы.
Ну, т.е. раз каналы есть, и локалки тоже, то и требования к ним предъявлять представляется нелогичным - наоборот - вот каналы, вот локалки, это все нужно связать в кучу. То, что вяжет это в кучу и есть Система.
Не Все, что связано в кучу - и есть система. Они - ее составляющие (компоненты или подсистемы). Каналы - вообще не системы, а некое "железо" физического уровня модели OSI - витая пара, оптика и т.д. Маршрутизаторы, конечно, покруче. Ближе к системам. Тем не менее - просто железо, если не программные типа FreeSCO.
Все понял, буду трудится.
Только вот про уровни предложенное деление не подходит. Т.к. Система (в терминах конкретного ТЗ) включает только маршрутизаторы. А каналы и сетки - это, так сказать, смежные системы.
Ну, т.е. раз каналы есть, и локалки тоже, то и требования к ним предъявлять представляется нелогичным - наоборот - вот каналы, вот локалки, это все нужно связать в кучу. То, что вяжет это в кучу и есть Система.
Есть ГОСТы на локальные сети, серию не помню, но в них все уровни модели OSI расписаны. Буржуйские RFC можно указать, спецификацию протокола H323 включить.
Про уровни иерархии:
- 1 уровень - собственно каналы связи (внешние);
- 2 уровень - каналообразующая аппаратура - всякие маршрутизаторы, что в мир смотрят;
- 3 уровень - локальная сетка, объединяюшая АРМ пользователей.
Модель OSI привести в качестве требований к обмену информацией между подсистемами.
Персонал бывает разный - оперативный (тупые юзеры), эксплуатационный (админы и железячники), ремонтный.
Способы и средства связи - автоматический, автоматизированный, ручной, по телефону и т.д. Каналы связи и каналообразующая аппаратура - модемы, маршрутизаторы, сетевые карты и проч.
Занимаюсь сейчас заполнением раздела "4 Требования к системе".
Тут нужен взгляд со стороны.
4.1.1.1 Перечень подсистем, их назначение и основные характеристики, требования к числу уровней иерархии и степени централизации системы
Вот что можно написать в указанном подразделе технического задания?
:roll:
Особенно учитывая то, что Система состоит из нескольких одинаковых железок. Каналы связи между железками заказчику предоставляет другая организация.
Можно ли написать, например, так:
Система не имеет подсистем. Требования к числу уровней иерархии и степени централизации системы не выдвигаются.
С другой стороны, можно описать все 7 уровней сетевой модели OSI. Например (текст пока без обработки):
Физический уровень (Physical layer) Самый нижний уровень модели, предназначен непосредственно для передачи потока данных. Осуществляет передачу электрических или оптических сигналов в кабель и соответственно их приём и преобразование в биты данных в соответствии с методами кодирования цифровых сигналов.Канальный уровень (Data Link layer)
Этот уровень предназначен для обеспечения взаимодействия сетей на физическом уровне и контроля за ошибками, которые могут возникнуть. Полученные с физического уровня данные он упаковывает в кадры данных, проверяет на целостность, если нужно исправляет ошибки и отправляет на сетевой уровень. Канальный уровень может взаимодействовать с одним или несколькими физическими уровнями, контролируя и управляя этим взаимодействием.Сетевой уровень (Network layer)
3-й уровень сетевой модели OSI, предназначен для определения пути передачи данных. Отвечает за трансляцию логических адресов и имён в физические, определение кратчайших маршрутов, коммутацию и маршрутизацию пакетов, отслеживание неполадок и заторов в сети.Транспортный уровень (Transport layer)
4-й уровень модели, предназначен для доставки данных без ошибок, потерь и дублирования в той последовательности, как они были переданы.
Наконец я понял, во что уперся - в определение критериев разделения системы на подсистемы (и, в первую очередь, в определение необходимости такого деления).
Далее, не могу понять, чем отличается "персонал системы" от "обслуживающего персонала".
требования к способам и средствам связи для информационного обмена между компонентами системы
Какой смысл вкладывает ГОСТ в "способы и средства". Способы - это ethernet/frame relay, или автомат/полуавтомат. И средства - тоже не ясно. А если у меня компоненты системы сами являются средствами связи?
1.3 - и их реквизиты - ИНН, КПП, и прочее (из Договора);
В тексте будут все реквизиты, это я условно указал.
1.4 - а соотвествующие ГОСТ где?
Вроде бы нет ГОСТов на WAN'ы. Хотя, могу и ошибаться - поищу.
Или Вы имели ввиду 34 серию?
Поразмыслив, подумал, что скорее всего таки 34-ю. Хм, подумаю, какие из ГОСТов можно безболезненно включить.
2.2 - без методов. Снижение издержек на междугородние переговоры.
Методы включил потому, что одна из задач - видеоконференции. Это для заказчика нововведение.
Я помню про положительную динамику целей, просто сформулировать иначе не смог. Вернее, смог, но писать не рискнул, а то бы мы никогда внедрение не закончили.
1.1 - территориально-распределенными.
1.3 - и их реквизиты - ИНН, КПП, и прочее (из Договора);
1.4 - а соотвествующие ГОСТ где?
2.1 - территориально-распределенными.
2.2 - без методов. Снижение издержек на междугородние переговоры.
3.2 - град - с точкой, метры - без точки. Час - просто ч
Нормально.
Первая попытка:
1 Общие сведения
1.1 Полное наименование системы и ее условное обозначение
Система информационного обмена между территориально разнесенными локальными вычислительными сетями (далее по тексту Система).1.2 Номер договора
Договор № xxxx (далее по тексту Договор).1.3 Наименование предприятий разработчика и заказчика системы и их реквизиты
Разработчик: <Название>.
Заказчик <Название>.1.4 Перечень документов, на основании которых создается система, кем и когда утверждены эти документы
Система создается на основании Договора и настоящего Технического задания.1.5 Сведения об источниках и порядке финансирования работ
Финансирование работ осуществляется в соответствии с Договором.1.6 Порядок оформления и предъявления заказчику результатов работ по созданию системы
Оформление и предъявление заказчику результатов работ осуществляется в соответствии с договором.2 Назначение и цели создания системы
2.1 Назначение системы
Система предназначена для обеспечения информационного обмена между территориально разнесенными локальными вычислительными сетями (далее по тексту ЛВС).2.2 Цели создания системы
Целями создания системы являются:
• повышение скорости информационного обмена между ЛВС;
• улучшение методов организационного взаимодействия между подразделениями заказчика;
• уменьшение издержек на междугородние разговоры между подразделениями заказчика.3 Характеристика объектов автоматизации
3.1 Краткие сведения об объектах автоматизации.
Объекты автоматизации представляют собой не связанные ЛВС, построенные в соответствии с требованиями стандарта ISO/IEC 11801:2002 ed.2.
В целом объекты автоматизации характеризуются:
• территориальной распределенностью;
• широким перечнем средств связи, способов информационного и организационного взаимодействия;
• наличием определенной программно-аппаратной инфраструктуры, в том числе средств сетевого и межсетевого взаимодействия;
• применением информационных систем для автоматизации отдельных видов производственной деятельности;
• централизованной иерархической структурой управления;
• наличием штата эксплуатационного и технического персонала, ответственного за обеспечение функционирования информационных систем.
Перечень объектов автоматизации приведен в Таблице 1.
Таблица 1
№ п/п Название объекта Дополнительные сведения
1 ЛВС в офисе по адресу xxxxxxxx IP-адрес ЛВС: xxx.xxx.xxx.xxx/xx Тип мини-АТС: Panasonic TDA-500
2 ЛВС в офисе по адресу xxxxxxxx IP-адрес ЛВС: xxx.xxx.xxx.xxx/xx Тип мини-АТС: Meridian 11C mini
3 ЛВС в офисе по адресу xxxxxxxx IP-адрес ЛВС: xxx.xxx.xxx.xxx/xx Тип мини-АТС: Panasonic KX-TD 1232
4 ЛВС в офисе по адресу xxxxxxxx IP-адрес ЛВС: xxx.xxx.xxx.xxx/xx Тип мини-АТС: Panasonic KX-TD 1232
5 ЛВС в офисе по адресу xxxxxxxx IP-адрес ЛВС: xxx.xxx.xxx.xxx/xx Тип мини-АТС: Panasonic TDA-2003.2 Сведения об условиях эксплуатации объектов автоматизации и характеристиках окружающей среды
Технические средства объектов автоматизации эксплуатируются в помещениях административного типа.
В помещениях поддерживаются следующие условия эксплуатации:
• температура воздуха находится в пределах от 18 до 24 град С при изменении на высоте 1,5 м. от уровня пола. Скорость изменения температуры не превышает 3°С в час;
• влажность воздуха находится в пределах от 30 до 55% без конденсации влаги при измерении на высоте 1,5 м. от уровня пола. Скорость изменения влажности воздуха не превышает 6% в час;
• освещенность не менее 540 люкс при измерении на высоте 1 метра от уровня пола на свободном от оборудования пространстве;
• уровень вибрации в диапазоне частот 5-22 Гц – максимальное ускорение не превышает 2,5 м/с2;
• напряженность электромагнитного поля не превышает 3 В/м во всём спектре частот.
Жду критику.
P.S. Сейчас мне раздадут... :roll:
Как назвать эту систему - ума не приложу.
Что-то вроде "единой корпоративной системой информационного обмена между удаленными офисами"
1.6 Сведения об источниках и порядке финансирования работ.
Это все должно быть в Договоре.
1.7 Порядок оформления и предъявления заказчику результатов работ по созданию системы.
Тоже должно быть предусмотрено Договором. Если нет, то берите вот это целиком - http://authorit.ru/?c=3&b=8 И добавьте Требования к документированию, пропишите в нем требуемые документы по ГОСТ 34.201-89. Чтобы их было как можно меньше.
вид автоматизируемой деятельности
Автоматизированная деятельность в данном случае - информационный обмен. Взамен поездок с дискетами, флешками и т.д. из офиса в офис.
Показатели - надежность, функциональная полнота, защищенность от НСД - все, что угодно. Лучше меньше
3 Характеристика объектов автоматизации
В целом объекты автоматизации характеризуются:
- территориальной распределенностью подразделений и размещения технических средств;
- широким перечнем средств связи, способов информационного и организационного взаимодействия;
- наличием определенной программно-аппаратной инфраструктуры, в том числе средств сетевого и межсетевого взаимодействия;
применением информационных систем для автоматизации отдельных видов производственной деятельности;
- потребностью в унифицированном взаимодействии объекта автоматизации с внешними управляющими и информационными системами;
- потребностью в непрерывном функционировании;
- централизованной иерархической структурой управления;
- динамичностью развития организационно-функциональной структуры;
- наличием штата эксплуатационного и технического персонала, ответственного за обеспечение функционирования информационных систем.
Что-то в этом духе.
- Войдите на сайт для отправки комментариев
У военных особые требования, это да.
Модели оборудования и интерфейсы - в Требованиях к техническому обеспечению. Про размещение в ТЗ тоже есть соответствующий подраздел. Схему структурную - в Требованиях к структуре и функционированию системы.