Карта уставок и Алгоритмы работы

[ZETs]

Здравствуйте.

Исходные данные:
Организации А необходимо построить объект с автоматизацией некоторых процессов. Разделы АТХ делали разные организации, как бы то ни было опишу как есть.

Суть проблемы:
1. Отдел кап. строя связался с конторой "рога и копыта 1" и они сделали раздел ПД. Взаимодействия были сложными.
2. Отдел кап. строя связался с новой конторой "рога и копыта 2" и они сделали раздел РД. Взаимодействия тоже не на высоте.
3. Контора "Б" взялась за строительство объекта. Эта контора изготовила шкафы автоматизации но у них нет программиста.
4. Контора "Б" заключает договор с конторой "С" на разработку ПО.
5. Контора "С" говорит мы выполним эту работу НО. Предоставьте описание контуров, алгоритмов работы и карты уставок. Утверждая что их должна делать организация разрабатывающая РД. По факту они запросили блок схемы.
Так как договора заключены коряво разбираться можно долго и нудно а то время.

Кап. строй меня попросили помочь добрым советом но я сам в недоумении.

Я в своей практике с таким не сталкивался, вопросов никогда не возникало. Кто писал ПО тот и прорабатывал алгоритмы блокировки, а уставки корректировали в ПНР. В РД как правило карта уставок присутствует а вот описание алгоритмов и блок схем видел 1 раз.
В идеале теперь всегда буду указывать в ТЗ и требовать подобные документы от тех кто делает РД.

Были ли у вас вопросы от суб. подрядчиков на блок схемы, алгоритмы и уставки?
Как часто встречали в ПД или РД блок схемы, алгоритмы и уставки?
Поделитесь опытом требуете ли вы в ПД или РД блок схемы?

[muZZy]

Ааахахаааа!!! Чтобы избежать обсценной лексики пожелаю кап.строю и всей вашей орденоносной конторе «Удачи! Здоровья!! Хорошего настроения!!!»

«Программистам» удачи и не ошибиться на следующих этапах.

Касательно Ваших вопросов:
Вы нас за идиотов держите?!!! Или Вы действительно не понимаете, что происходит?

[ZETs]

По ГОСТ 34.601 тот кто делает РД тот делает и ПО.
Я не совсем корректно сформулировал вопрос. Если одна организация 1 делает РД, а организация 2 выполняет работы на основе ранее разработанной РД, прикладываются ли к ней алгоритмы уставки?

Как правило всегда работаем "под ключ", но в данной ситуации я очень удивлен.

[Jackson]

Кап. строй меня попросили помочь добрым советом но я сам в недоумении.

Что тут недоумевать?
За спрос денег не берут, есть ГОСТ, согласно которому делается всё правильно. Остальное - отсебятина.

Как правило всегда работаем "под ключ

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

[olexsa]

Были ли у вас вопросы от суб. подрядчиков на блок схемы, алгоритмы и уставки?

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

[ZETs]

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

Согласен. В ТЗ я всегда указывал разработка ПО на основе РД.

[alex45]

Контора "С" говорит мы выполним эту работу НО. Предоставьте описание контуров, алгоритмов работы и карты уставок. Утверждая что их должна делать организация разрабатывающая РД.

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

Как часто встречали в ПД или РД блок схемы, алгоритмы и уставки?

Я работал в нескольких проектных организациях, везде в составе РД выдавали алгоритмы и уставки. Алгоритмы могут быть в разном виде. Блок-схемы - это одно из представлений. В последней организации, где я работал, алгоритмы выдавали в виде обширного текстового описания, которое прикладывалось к схемам автоматизации.

[Jackson]

Согласен. В ТЗ я всегда указывал разработка ПО на основе РД.

Не верю. Как Станиславский. Потому что при наличии ТЗ, написанного по ГОСТ 34.602-2020, подобных вопросов в принципе не должно возникнуть - неоткуда.

Отправлено спустя 6 минут 16 секунд:

Правильно утверждает. Откуда программисты могут знать

Совершенно верно. Вот из ТЗ и могут узнать. А если такового не существует, то его написать и согласовать может кто угодно: заказчик, подрядчик, субподрядчик, дядя Вася сосед. Естественно не за бесплатно.
И абсолютно без разницы для кого его писать: для себя самого, если всё под ключ делаешь, или для пяти смежных контор - один чёрт все эти вопросы всё равно возникнут и их надо будет решать и описывать решение, даже для себя же (иначе пройдёт год со сдачи и уже никто не вспомнит что там и зачем накручено). А нормальное ТЗ - это практически и РЭ и ТУ (если попросят) и ПЗ.

Если кто-то думает что забив на ТЗ он сэкономит время - блажен кто верует. Но я такой экономии в своей жизни ещё не видел ни разу. Убытки только видел.

[ZETs]

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

То что ПО может разрабатывать кто угодно это понятно. Просто я имел ввиду всегда есть тот с кого спрос.

Не верю. Как Станиславский. Потому что при наличии ТЗ, написанного по ГОСТ 34.602-2020, подобных вопросов в принципе не должно возникнуть - неоткуда.

Все, выяснили.... Кап. стройщики ТЗ составляли сами, а про ГОСТ 34.602 они и слухам не слыхивали. Вот итог.

Меня больше интересовал вопрос с алгоритмами и уставками если проекты реализуются разными организациями. Для себя я тоже выводы сделал.

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

Если кто-то думает что забив на ТЗ он сэкономит время - блажен кто верует. Но я такой экономии в своей жизни ещё не видел ни разу. Убытки только видел.

Огромное спасибо за развернутый ответ.

Всем спасибо...

[olexsa]

Кап. стройщики ТЗ составляли сами, а про ГОСТ 34.602 они и слухам не слыхивали. Вот итог.

Проблема не в кап. стройщиках, и не в ГОСТ, и не в Вас. Проблема у организации. Если руководство утверждает ТЗ без согласования со всеми службами (механики, энергетики, АСУТП, охрана труда, пожарная безопасность, и прочая прочая прочая), то проблемы будут и в дальнейшем. Вне зависимости от выводов Ваших (ну если то Вы - не руководитель этой организации).

[Jackson]

Все, выяснили.... Кап. стройщики ТЗ составляли сами, а про ГОСТ 34.602 они и слухам не слыхивали. Вот итог.

Не беда. Берите шаблон ТЗ по ГОСТ (он тут на форуме даже есть) и решите, кто его заполнит и кто ему за это заплатит.
Лично я как подрядчик при таких разговорах "Кто пишет ТЗ?" - "Ну, Вы напишите, Вам же делать" - "Ок.". И всё. А стоимость раб.времени просто включается в стоимость поставки, даже отдельной строкой может там не фигурировать. Даже озвучивать это нет необходимости.

Хотя, по ГОСТ 34.601, где описана вся последовательность создания любой АСУ, этап создания ТЗ входит в общий объём работ и, следовательно, входит в смету и оплачивается. Это если будут вдруг вопросы "а что, за это ещё и платить?" - да, а что вы всей конторой собрались чтобы бесплатно время проводить от нечего делать? Работа должна быть оплачена.

Проблема не в кап. стройщиках, и не в ГОСТ, и не в Вас. Проблема у организации.

Именно!

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

Именно.
Просто должно быть понимание того, что и Ваше руководство, и Вы, и Ваш программист, и монтажник, и дворник - вы все в одной конторе, значит в одной лодке. Схалтурил один - проблемы у всех вас. Что дворник, что директор - без разницы. Потом можно указывать пальцем и назначать виновных - конечно, можно и нужно - но это потом, когда проблема уже есть и вы все её уже огребли. Как этого избежать? Да просто не халтурить. Раз кто-то ошибается - его лучше поправить пока дело не дошло до проблемы. В одной же лодке все.

А спрос, как Вы говорите, всегда есть с кого - в случае с кривым ТЗ спрос с того, кто под ним подпись и поставил. А не с тех кто это ТЗ пытается выполнить.
Потому что в нормальной конторе ТЗ не руководство пишет. Руководство только удостоверяется в том, что ТЗ полностью охватывает задачу. А это достигается просто соблюдением ГОСТ 34.602. Обратите внимание, что в этом ГОСТ говорится: если требования какого-либо пункта ТЗ к конкретному объекту не применимы и поэтому пункт бесполезный, то этот пункт из ТЗ не удаляется - этот пункт по прежнему присутствует, но состоит всего из трёх слов: "требования не предъявляются". А это, в свою очередь означает, что при создании ТЗ человек дочитал до этого пункта, продумал его и решил не предъявлять таких требований. Ключевые слова - "продумал" и "решил". То есть он ещё до начала работы уже решил эти вопросы. Вот почему говорится, что хорошее ТЗ - это 30-40% уже сделанной работы.

[+] фольклор про ТЗ

Слушать с 2:29. :) Хотя можно и сначала, парни дело говорят.

https://www.youtube.com/watch?v=FfgPjRb5UTE&t=149s

[ZETs]

Подняли ТЗ а там всего три строчки про автоматизацию. (((

фольклор про ТЗ -Слушать с 2:29. :)

)))

Как говорится "На такое ТЗ результат ХЗ"

Спасибо за Шаблон )))

[Jackson]

Весёлые инструкции сюда уехали: viewtopic.php?t=19062