Для самых маленьких - Как писать техническое задание!?

Вера, повнимательнее, повнимательнее надо

спасибо! обычно в гостах вначале указывается как оформить, вот и просмотрела

Ну, как же ничего не говорится?

Господа разработчики ТЗ, подскажите, пожалуйста, новичку, как правильно оформлять ТЗ на АС.
Дело в том, что в ГОСТ 34.602-89 ни говорится ничего про титульный лист и оформление разделов. А вот в ГОСТ 19.201-78 сказано использовать ГОСТ 19.106-78. Могу ли я руководствоваться при оформлении ТЗ на АС гостом 19.106-78 (он же по идее относится к программе, а не АС)?

Понято.
Приемочные испытания (в промышленную эксплуатацию) еще не проводились. Были испытания для опытной эксплуатации.
До промышленной еще - как до Марса пешком.
Спасибо! Чуток прояснилось.

ЗАКОН СУРОВ, НО ОН — ЗАКОН!
Все всегда забывают о ГОСТ 15 — Система разработки и постановки на производство промышленной продукции, в котором четко прописаны стадии этого процесса. Если продукт прошел приемочные испытания, его разработка окончена, и никакие изменения в ТЗ (ЧТЗ) по данному договору вноситься не могут. Модернизация продукта выполняется по другому договору и по новому ТЗ (ЧТЗ) на модернизацию. В конце этого процесса проводят новые приемочные испытания на соответствие продукта новому ТЗ, причем результаты старых испытаний могут быть приняты в зачет.

А если сделать, как я описала, то можно ПМ именно к новому "ЧТЗ", объединяющие старые "ЧТЗ"... там же все изменения прописаны сразу в одном документе...

А если сделать, как я описала, то можно ПМ именно к новому "ЧТЗ", объединяющие старые "ЧТЗ"... там же все изменения прописаны сразу в одном документе...

Да, ПМ было бы удобнее сделать к общему ТЗ, но куски сдаются в опытную эксплуатацию, и "для порядка" требуются отдельные ПМ. Хотя, мне кажется, только путаница плодится.

До ПМ у нас в похожей ситуации не дошло. Все изменения проводились на стадии подписанных и неподписанных ТЗ.

А насчет подписанных. Мне было в свое время легче сделать еще одно, как Вы называете, "ЧТЗ" - оно объединяло все старые "ЧТЗ" (например, старые "ЧТЗ" были на блок 1, на блок 2... 3... 4, а новое ЧТЗ было одно на БЛОКИ 1,2,3,4) там я прописала, что ПО соответствует ЧТЗ1, ЧТЗ2..., а далее описала все дополнения и СВЯЗИ. И с ПМ тогда было просто - ПМ разрабатывалось по общему ТЗ...

Но. Тогда это делалось не по букве ГОСТ, а по наитию + все тот же приницип бритвы Оккама Так что не знаю, может, этот путь неправомерен.
Вадим, а что Вы скажете?

Спасибо!

Подписанные, сданные в архив...

Есть еще вопрос: если вносить изменения в ЧТЗ, что делать с ПМИ на данную подсистему? Она-то написана по "старым" требованиям.
Тоже изменять и еще раз проводить испытания?

Маленький совет. Если есть подписанные и неподписанные ЧТЗ, изменения делайте только для подписанных, а с неподписанными поступайте, как считаете нужным. Дабы не умножать сущности сверх необходимости

Глупый вопрос, конечно. Надо исправлять свои косяки.
Изучаю порядок внесения изменений.

Спасибо большое, Vadim!

"Так, пожалуй, будет проще всего"

Так, наверное, будет правильнее, но совсем не проще. Наверное, без изменений останутся только заголовки.
Вообще получается, что я пишу общее ТЗ "задним числом". Т.е. когда модуль уже разработан, частично испытан, откорректирован, описываю то, что получилось, как требования. А ЧТЗ оставляю, как есть.
Это совсем неправильно? Если кто-нибудь захочет потом "поднять" отдельные ЧТЗ, а там нет изменений, побьют?

Путь от частного к общему, называемый дедукцией, не лучший и совсем не самый легкий путь, в отличие от альтернативы, называемой индукцией. И совсем плохо, когда исполнитель по устной договоренности с заказчиком делает совсем не то, что прописано в ЧТЗ, — потом не найдешь концов.
Но, уж, раз события развиваются именно так, могу посоветовать: всё, что делается по факту, фиксировать соответствующими изменениями исходных ЧТЗ. Потом, когда будет составляться основное ТЗ, в нем можно будет прописать лишь основополагающие позиции, а по частностям сослаться на согласованные и утвержденные ЧТЗ с вовремя внесенными изменениями. Так, пожалуй, будет проще всего.

Наимудрейшие! Нужна помощь.
Есть большая программулина, которая разрабатывается, и будет еще долго разрабатываться. На каждую подсистему я пишу ЧТЗ. Это первый опыт. Поэтому с каждым новым ЧТЗ я понимаю, что предыдущее было полной лажей. К тому же, разработчик не дремлет и много чего меняет в программе (по устному согласованию с заказчиком).
Скажите, когда я буду сливать это все в единое целое, насколько точно общее ТЗ должно повторять ЧТЗ на подсистемы?
Можно будет сделать общее ТЗ, сильно отличное от всех ЧТЗ? При условии, что заказчика оно устроит?

Тогда да, выгоднее вынести функциональные требования Приложением к ТЗ.

Чего только не сделаешь для выполнения желаний Заказчика.

Тогда да, выгоднее вынести функциональные требования Приложением к ТЗ.

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

ТЗ не на АСКУЭ, а на информационную систему верхнего уровня. Заказчик долго не подписывал ТЗ и менял функционал со скоростью звука. Труднее всего оказалось программистам. Полностью написать (запрограммировать) функционал так и не удалось.

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

Правильное решение. Многие так и делают.
У меня в приложения вылетели описание объекта автоматизации, перечни схем, форм и даже функции по этапам разработки.

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

Если говорить об аскуёшных проектах, то Приложение А "весит", как правило, раза в два-три больше самого ТЗ по объему страниц. Правда, все зависит от числа энергообъектов и числа точек учета.

ГОСТ 2.105 рекомендует указывать перечень в конце документа. И это правильно.
Однако, из-за наличия большого количества приложений к ТЗ, принял решение указывать ПЕРЕЧЕНЬ СОКРАЩЕНИЙ, УСЛОВНЫХ ОБОЗНАЧЕНИЙ И ТЕРМИНОВ в начале документа. В последнее время количество страниц в ТЗ меняется быстрее, чем думает Заказчик.

А я по старинке, в самом конце, поблизости с "Источниками разработки"

Лично я уже около года, по просьбе Заказчика, перед первым разделом вставляю ПЕРЕЧЕНЬ СОКРАЩЕНИЙ, УСЛОВНЫХ ОБОЗНАЧЕНИЙ И ТЕРМИНОВ.

По удобству читающего, это да удобнее в начале

ГОСТ 2.105

Спасибо. Значит, не только у меня эта проблема.
Следовательно, она существует, а не кажется.
Интересно, почему НЕ БЫЛО этого пунка в ГОСТ? Неужели в ТЕ ВРЕМЕНА терминология была ПРОЗРАЧНА??? Или потому что не было такого многообразия ПО?
Полностью согласна с названием "Список терминов и сокращений" - кстати, название БЛИЖЕ ПО СТИЛЮ к остальным названиям по ГОСТ - понятно, это чистое "сибаРИТство", но все-таки...
А вот насчет того, чтобы этот список вынести в Приложение - не думаю. Я же СПЕЦИАЛЬНО ставлю В САМОМ начале этот список - до появления в документе ПЕРВОГО ТЕРМИНА, который может оказаться спорным. Не писать же в самом первом пункте: см. приложение... Как-то так.
Насчет того, что терминология предметной области может быть обширной - тоже согласна. Задача ОПРЕДЕЛИТЬ НЕОБХОДИМОЕ И ДОСТАТОЧНОЕ количество терминов для создания ПО. О как.

Я новичок в этом деле, но полностью согласна, что необходимо использовать Термины и сокращения, да еще в виде приложения

Хотя я всех тонкостей могу не знать :roll:

Расскажу историю. Два года назад подписали мы ТЗ, по которому сделали систему, недавно прошедшую госиспытания. Сейчас идет корректировка документации на систему для присвоения ей литеры О1 (серийная продукция). Так вот, когда подписывали ТЗ, было неловко упрекать Заказчика в терминологических неточностях.

Сейчас, при корректировке ТД и ее нормоконтроле, расхлебываем эти неточности в полной мере. Нормоконтроль делает замечание. Мы — а так в ТЗ. Нормоконтроль — а должно быть так, и в нос ГОСТ, прописанный в том же ТЗ. Получается, что надо корректировать не только ТД, но и ТЗ, а это — новая морока.

Так что предложенный раздел приветствуется . И еще. В конце ТЗ полезно сделать перечень нормативных документов, на которых есть ссылки в ТЗ. Очень полезный перечень .

Рикки, приветствую!
Я сталкивался недавно с подобным. Всё ж, наверное, не "Терминология предметной области" - она может быть совершенно необъятной. Лучше (да и правильней) давать перечень используемых (и только используемых) терминов и сокращений.

На прошлом месте работы можно было писать МАКСИМАЛЬНО ПРИБЛИЖЕНО к ГОСТ, но если нужны другие разделы - РАДИ БОГА. ГОСТ НЕ ЗАПРЕЩАЕТ, даже позволяет кое-где менять и добавлять разделы.
Но те разделы, которые были добавлены в ТЗ на старой работе, были весьма фривольны и похоже на "БУРЖУИНСКИЕ". Это "глоссарий", "бизнес-процессы" (так не любимые Surgeon-ом), много другого.
Ныне ситуация изменилась, хочется МИНИМУМ фривольности. Но считаю глоссарии ПРОСТО НЕОБХОДИМЫМ (хотя СуперСпецы обходятся без них) для более полного понимания задачи исполнителем.
Поэтому первым пунктом во "Введении" у меня будет все равно "Терминология предметной области". Кто что по этому поводу думает?

Действительно! Спасибо, видимо, читала невнимательно... :?

Из ГОСТ 34.602-89

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

А если писать про ТЗ по модернизации системы, то корректно ли ссылаться на ГОСТ 34.***, ведь в них весде речь о создании системы: стадии создания, документация на выходе каждой стадии создания. Тот же ГОСТ по порядку и методике испытаний говорит об предварительных испытаниях, которые проходят при создании системы на тестовом образце и.т.д. А мне кажется, если тать ссылку на этот ГОСТ, потом предется все эти документы предоставлять?

По ГОСТ 34.602-89, но не на создание, а на модернизацию.

Вряд ли мне пришло бы в голову отказаться от ТЗ. Не помню, честно говоря.

Скажите, а где можно посмотреть как пишется ТЗ на адаптацию АСУ под конкретный объект? Покупался готовый продукт, а топом адаптировался под имеющийся объект управлнеия. Сейсас для приемки должно иметь место ТЗ на систему...но ТЗ на создание - это наверное не совсем то, так как система уже была готова...она только адаптировалась. Как быть в таких случаях? И еще, уважаемый surgeon! я где-то в форуме встречала, что вы говорили о каком-то законе о документировании (кажется). Вроде если им руководствоваться, то ТЗ вообще можно избежать...Как он точно называется еще раз напишите пожалуйста!

Если настаивает - то никак не отвертеться. Если нет, то на усмотрение разработчика.

А эти критерии оценки должны присутсвовать в ТЗ в обязательном порядке? Во всяком случае Заказчик на этом настаивает...

Надо не "повышение эффективности бизнес-процессов", а, скорее, "повышение эффективности деятельности предприятия в целом" (путем оптимизации бизнес-процессов).

Здесь надо конкретику. Оптимизирован бизнес-процесс, сократилось время его реализации, количество вовлеченных в него сотрудников - вот и количественный критерий.
"Значениями параметров, характеризующих степень соответствия ее назначению, являются значения периодичности выполнения функций (задач) по назначению ."

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

Вроде везде менял, нет-нет - и выползают старые ссылки. Наткнетесь на старую ссылку - меняйте ergd.ru/HTML на authorit.ru - все будет работать.

а обновите, пожалуйста, ссылочку.
Стало сейчас актуальным.
Спасибо.