Черновик технического задания

Хорошо, раскроем карты

Под решением video-over-IP понимается вот что:
http://www.netris.ru/ru/solutions/

Вообще это называется "Программно-аппаратный комплекс по предоставлению услуг Video-Over-IP".

Система, входящая, в его состав, на которую есть документация, называется "Подсистема управления услугами Video-over-IP".
http://www.netris.ru/ru/products/ivision.html

ЭД Заказчику не предоставляется, пока не подписан договор. Есть документ "Общее описание Системы" - полумаркетинговый, полутехнический. Там описаны все возможности.

Не совсем понял что понимается под первым, вторым и третьим вариантом.

Заказчику будет представлено ТЗ, написанное на основании черновика, но с учетом его пожеланий.

Следующему Заказчику - также на основе черновика, в который будут включены дополнения уже под этого Заказчика.

По мере развития Подсистемы управления услугами Video-over-IP черновик также будет дорабатываться.

Предложение по терминологии:
если под решением video-over-IP понимается это http://www.cybersecurity.ru/net/6836.html
то назвал бы это системой или комплексом (если в состав входит несколько систем). И далее "В состав системы (комплекс) video-over-IP входит подсистема (система) предоставления услуг Video-over-IP...).

Я так понимаю, что систему video-over-IP нельзя просто купить и эксплуатировать, необходимо провести комплекс работ (монтаж, настройка итд). Покупателя (заказчика) мучает вопрос, чем эта ляпота отличается от всей остальной мути. При детальном изучении документации (например, ЭД) на систему video-over-IP он выявляет, что подсистема предоставления услуг Video-over-IP отличная подсистема, но .... И тут выплывает необходимость модификации или модернизации. Под модернизацию необходимо ТЗ. Вот есть проект ТЗ (рыба, черновик), разработанная на основе ЭД по подсистеме (если нет ничего, то считаю нормально).

Вопрос возникает. Следующему заказчику какой вариант будет представлен (первый, второй или третий, которого нет)?

Давайте еще раз обрисую задачу в общих чертах.

Дано:

1) Есть система предоставления услуг Video-over-IP (далее Система), которая документирована. Она работает с программными и аппаратными средствами в составе решения video-over-IP (далее Решение) и выполняет все задачи по организации предоставления услуг (чтобы клиент смог посмотреть ТВ с приставки) и учета услуг (посчитать денежки и списать их со счета).

2) В ЭД к Системе ПОЛНОСТЬЮ описана настройка Системы в составе Решения, а также возможности, которые будут предоставляться.

3) Каждый проект включает в себя либо установку решения video-over-IP "под ключ", либо настройку Системы в составе существующего Решения. Исходя из п.1, Решение без нашей Системы бессмысленно.

Таким образом, требования к Решению на 80% включают в себя требования к функционалу, масштабируемости, отказоустойчивости, производительности и т.п., которые реализуются к Системе, а на 20% - требования, реализуемые остальными программными и аппаратными средствами в составе Решения.

Поэтому и назрела идея слепить "шаблон" ТЗ (ранее "черновик"), который будет правиться под конкретного Заказчика в соответствии с его требованиями в будущих проектах. Наиболее понятный путь - брать функционал из ЭД.

В результате существенно сократится время на разработку ТЗ, а также будет обеспечено соответствие ТЗ и ЭД.

Я извиняюсь за косноязычность, просто совсем недавно с головой погрузился в проектную документацию, ранее занимался только эксплуатационной. Будем нарабатывать опыт

Если все делать по-военному - такая фишка может не пройти. Меня заставляли всегда писать полное содержание пункта требования ТЗ и под ним полностью расписывать, как это требование реализуется.

Это было погано, поскольку single source тогда еще и не пахло, а просто на пункты ТЗ и ЭД ссылаться запрещали. Сейчас все просто

Это не так, поскольку ЭД — часть КД, и к окончанию стадии разработки РКД она предъявляется заказчику вместе со всей КД. Только что сдал ТУ, где в разделе «Методы испытаний» ссылаюсь на пункты РЭ .

Разработать ТЗ (или черновик) на основании можно, если это основание известно только Вам. А ссылаться, УКАЗЫВАТЬ ЭД, как основание - это действительно абсурд. И в ПМ тоже ссылаться на ЭД нельзя. Это противоречит не просто чьей-то непонятной логике, а невозможности путешествия во времени , т.к. ПМ создается на этапе рабочей документации, а ЭД - на этапе эксплуатации.

Если у вас задача дорабатывать несуществующее ТЗ (какой-то-там-черновик), то почему бы вам не сделать нормально - создать новое ТЗ на ДОРАБОТКУ системы? То есть система уже есть, ее можно описать в ТЗ, а далее прописать требования заказчика. Что-то типа того - "в дополнение к существующим в системе операциям требуется разработать... блаблабла"
А уже далее по ходу и ПМ нормальное разработать - по требованиям НОРМАЛЬНОГО ТЗ, а не каких-то включений в какой-то черновик???

Вопрос в том, чтобы разработать ЧЕРНОВИК ТЗ на основании ЭД.

При использовании системы в проекте этот черновик будет браться за основу и в него будут "по ходу пьесы" включаться требования, озвученные Заказчиком. в результате чего будет сформировано окончательное ТЗ.

Вот в чем цель.

Думал, что в ПМ можно написать так:

Действия: операции 1-4, описанные в разделе таком-то документа такого-то (ссылка на ЭД).
Результат: такой-то.

Будем знать

:oops:
Все, все, все, поднимаю кверху лапки!!!
Вам дай только слабинку, ну забьете же... бедную несчастную девушку (старую больную тетеньку)

А я, честно говоря, пользовалась обычно п. 1.3.1 - таблицей 2, т.к. там КОНКРЕТНЫЕ ДОКУМЕНТЫ и их обозначения.
И, я уже писала, что для себя я уяснила (если нет указаний свыше), когда разрабатывать ТЗ, а когда ТУ. У меня все зависит от отношения программых и аппаратных компонетов. Ну, и САМОЕ ГЛАВНОЕ - от ТРЕБОВАНИЙ СВЫШЕ (особенно, если нет противоречия с ГОСТ).

Задачи бывают всякие, не только по сертификации продукции. А как, кто и по каким документам сертифицируют АС, для меня до сих пор тайна.
Но все-таки мне приходилось
1. Переделывать ТЗ (на АС) на ТУ - как раз при сертификации...
2. Разрабатывать ПМ так, чтобы испытания АС соответствовали именно ТЗ, а не ТУ! Это нужно было для сдачи в эксплуатацию АС - сдали, успешно эксплуатируется.
В общем и целом я согласна с SHA, но! Все-таки, если требуют свыше ТЗ, а не ТУ (и это вполне соответствует ГОСТам), стоит ли спорить?

А как же пунктик 2.3 ГОСТика 34.201-89.

Во, сразу не заметил. Вот это неправильно. Приемочные испытания проводятся с целью проверки соответствия изделия и разработанной ЭД требованиям, заявленным в ТЗ. В ПМ может быть предусмотрена проверка ЭД, но ссылаться на ЭД как на основание для проведения некоторого этапа испытаний нельзя, ибо это противоречит всякой логике.

Согласен с Сергеем - зачем писать ТЗ задним числом? Для той же сертификации оно нафик не нужно, ибо там прописываются требования, которым ДОЛЖНО В БУДУЩЕМ соответствовать разрабатываемая система. А вот ТУ - это реальные требования, которым обязано соответствовать реальное изделие.

Не предусмотрено то оно не предусмотрено, однако та же сертификация проходит путем проверки на соответствие заявленных в ТУ характеристик и РКД нормативным актам отрасли. У нас контора штампует цифровые АТС - АС в чистом виде - отродясь никто не писал ТЗ, а на сертификацию отправляют ТУ и рабочий (УЧТЕННЫЙ!!!) комплект документации.

Но уж если и появилась такая дикая необходимость (хотя подозреваю, что она обусловленна похмельным синдромом руководства), то правильной дорогой идете, товарисч:). ТЗ писать на основе ЭД - милое дело и, главное, ни одна сволочь не полезет с бесконечными изменениями:).

Ваще-та логика должна присутствовать независимо от типа документа
Для себя-то я уже уяснила, когда разрабатывать ТЗ, когда ТУ, а когда и то и другое. И пока меня не переубедят, буду так и поступать. А товарышшшу, по-моему, все-таки нужно ТЗ. Т.к. ГОСТами 19 и 34 -ой серии ТУ не предусмотрено, а зачем умножать сущности без надобности?

Так сделайте ТУ и псё. Закрываете и ТЗ, и ПМИ, и логика присутствует.

Ну этого-то сплошь и рядом... Система первоначально разработана "по понятиям", для своих (или чьих-то, кто не требует НОРМАЛЬНОГО продукта) нужд. И вот фирма доросла, чтобы ее сертифицировать-продавать или еще что-то делать... А документации-то НЕТ!!! Сделаю ТЗ, подпишут задним числом - и в дело
Это как раз и будет ИДЕАЛЬНОЕ ТЗ, то есть такое, какому система полностью соответствует. Разрабатывать его мождно как из ЭД, так тестированием самой системы. И то, что она выполняет, записывать как "должна выполнять..." Разработка такого ТЗ - это же просто мечта.

Возникает вопрос, если есть система, то зачем ТЗ?
ЗЫ. Ох, эти уши с финтами. ОбЫрвал бы.

Наверное, все же ошибся разделом.

Просьба перенести туда, куда надо.