Кому принадлежит написанное ПО юридически

[Jackson]

Как в таком случае быть с гарантией?

Да элементарно: с ней быть так как написано в РЭ и договоре. В РЭ должно быть в главе 1 написано, для чего предназначена установка, а глава 5 должна называться "использование по назначению", ГОСТ есть на содержание РЭ. А в договоре должно быть написано что-то типа того, что последствия использования установки не по назначению гарантией не покрываются (но и это уже избыточно - предыдущего достаточно).

То есть всё что не перечислено в главах 1 и 5 РЭ гарантией не покрывается автоматически, если главы 1 и 5 РЭ написаны правильно.

А если господа инженеры забыли это всё написать а господа коммерсанты и в договоре этим не озаботились - тогда несите ответственность по полной схеме, даже если контроллером двери подпирали, а на АРМах порно с торрентов качали и в сервер складывали.

Если кто-то очень переживает за целостность именно софта в ПЛК - тогда весь контроллер с софтом объявляется закрытым ПТК, исходники не передаются, передаётся только уже скомпилированный для загрузки пакет, и факт замены софта пользователем в пределах гарантийного срока считается основанием для снятия с гарантии (грузить тот же самый софт - сколько угодно, хоть каждый день пока флешка не умрёт). Это нормально, мы и такие системы поставляем, вопросов нет.

Отправлено спустя 4 минуты 6 секунд:
Исходно тут был вопрос про то что вроде как обязаны всё передать включая исходники, но в случае закрытого ПТК для обслуживания достаточно передать просто номер телефона производителя.

Короче как в документации напишете - так и быть с гарантией. Так что Вы не у форума ответ на Ваш вопрос спрашивайте, а в собственной документации его ищите - ответ там. Как сами написали - такой и ответ будет.

[Jackson]

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

Секундочку. "Так сложилось" или "так полагается"?
Когда до жареного доходит, то юристов "обычаи" и "традиции" мало интересуют.

[petr2off]

Состав документации определяется действующим ГОСТ 34. Просто раньше к нему еще СПшки были, которые подробно расписывали - что конкретно в каждом документе должно быть (регламентировался содержание разхделов ). Примерно год назад их отменили, должны были заменить на тех. регламент. Но какая то несостыковочка вышла и сейчас СП нет. Но ГОСТ остался. И я думаю, новый тех. регламент будет в той или иной мере реинкарнацией отменённых СПшек. Как показывает практика, тех. регламенты - которые приходят на замену СПшка - еще более навороченные. И кстати, Юрист, какой бы он неграмотный не был, отрицать требования действующего ГОСТ не будет.

Отправлено спустя 15 минут 40 секунд:
Я имею в виду отмененный РД50-34.

[Jackson]

Я имею в виду отмененный РД50-34.

Так в этом РД в главе 6 "требования к содержанию описания программного обеспечения" (предоставляется на этапе ТП) - там нет ни исходников ни листингов. Далее я тоже не встретил нигде ничего близкого. Остаётся только на этапе ввода эксплуатации (последним пунктом) во время ПНР проверить комплектность документов, ЗИП и материалов, но и там в явном виде про ПО нет упоминаний. То бишь какие могут быть исходники на этапе ТП когда железа ещё нет? Нет их и дальше. И к тому же этот РД отменён.
Требования по исходникам разве что привели в начале этой дискуссии, но опять не в явном виде.

Юрист, какой бы он неграмотный не был, отрицать требования действующего ГОСТ не будет

Не будет. Но и содержание этих требований он прочтёт внимательно, и применимость требований ГОСТ тоже оценит. А в этих двух пунктах всё очень неоднозначно.

Мы сейчас о чём? Найти основания для передачи исходников или найти основания их не передавать? :) По-моему, и то и другое можно сделать.

Всё решают формулировки в договоре всё-таки - так получается. Или не так и я что-то пропустил?

Есть ещё мат.обеспечение и инф.обеспечение.

Я ж не спорю ради спора - я пытаюсь ответ найти чёткий и внятный.

[Looker]

Мне кажется область АСУ ТП несколько отличается от 1С.

Несколько - слишком слабо.

Если вышло из строя вообще все, порядок действий тот же - сравнение версий (или вообще хешей) с изначальными и назначение виноватых.

На больших проектах в моей практике такого не было, но причина другая - не оплата последнего этапа работ, какие претензии после этого?
Один из них: Объект еще не сдан, а график выработки электроэнергии уже в наличии. Там про тепло - наглое вранье, потребителей нет - атмосферу греют.

На мелких - даже намеков не было.

Исходники во всех случаях отдаю.

[Jackson]

Хотя, извиняюсь,

Комплектность документации на программные средства вычислительной техники - по ГОСТ 19.101.

И вот там есть

2.1. К программным относят документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программ.
2.2. Виды программных документов и их содержание приведены в табл. 2.

Текст программы Запись программы с необходимыми комментариями

А также

2.5. Виды программных документов, разрабатываемых на разных стадиях, и их коды приведены в табл. 4.

И тут я вижу:

1. "на разных стадиях" - согласно этой таблице листинг нужен только на этапе Р и не раньше. На этапе ТП можно забить.
2. Для компонентов это обязательно. А вот для комплексов - "необходимость составления документа определяется на этапе разработки и утверждения технического задания". То есть Если поставляется комплекс, а не ПЛК отдельно взятый - а так обычно и бывает, сам по себе ПЛК повешенный в воздухе кому нужен? - то как в договоре/задании написано - так и будет. Никак не написано - каждая сторона вольна трактовать в свою пользу. Получается что всё-таки ответ в договоре/ТЗ надо искать. Компонент - это ПЛК с софтом отдельно взятый, который потом подключат и запустят в составе объекта.

И это только документация. А сами исходники в виде файлов проектов или хотя бы txt - я пока не нашел их явного упоминания, давайте дальше искать.

[Jackson]

Вот и пришли к случаю автора. В договоре/ТЗ о передаче исходников ничего не сказано. в ГОСТ 19.101 сказано "для комплексов - смотри ТЗ", при этом по договору поставляется комплекс, перечислено кол-во единиц, назначение и состав документации (в этом списке нет ни исходников ни ЕСПД в явном виде).
Результат: Заказчик заказывал систему - он получил систему. Для проведения ТО и штатной эксплуатации исходники нужны? Нет, они для этого не применяются. Выходит "к пуговицам претензии есть?" (с)

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

Сейчас по-другому делается. В составе комплекса стоит контроллер, который также объявлен комплексом с закрытым ПО, по договору поставляется он и скомпилированный готовый к загрузке софт. ПНР и отладка - отдельным договором. Изменения после ввода в эксплуатацию - это изменение исходного ТЗ, отдельная работа, отдельный договор, если надо ещё и повторные ПНР - ещё отдельный договор на ПНР. Опять же всех устраивает. С самого начала во всех документах сказано что изделия закрытые, софт для изменения пользователем не предназначен. То есть ситуация автора. И никому в голову не приходит самостоятельно копаться в софте. Дело видимо в том что сфера применения несколько отличается от привычного многим АСУТП. Хотя и в составе обычных АСУТП это все тоже поставляется и применяется - тоже обычно не возникает вопросов "где исходники". Изначально все предупреждены что это так. Хотите по-другому - добро пожаловать на рынок, других исполнителей полно.

Так что пока - получается что раз явного требования нет - так и дарить это никто не обязан. Не в пользу автора вопроса пока что.

[petr2off]

Там еще,кроме главы 6 есть глава 7. В частности:
"7.1.7. В разделе «Алгоритм решения» следует приводить:
1) описание логики алгоритма и способа формирования результатов решения с указанием
последовательности этапов счета, расчетных и (или) логических формул, используемых в алгоритме.­
2) указания о точности вычисления (при необходимости);
3) соотношения, необходимые для контроля достоверности вычислений;
4) описание связей между частями и операциями алгоритма;
5) указания о порядке расположения значений или строк в выходных документах (например
по возрастанию значений кодов объектов, по группам объектов и т. д.)."
А теперь давайте взглянем на это дело с точки зрения разработчика.
Практически, крайне редко, прорабатываются алгоритмы с использованием ромбиков и квадратиков, потому как в целом, используемые в АСУ ТП языки представляют описание алгоритма (FDB, LD, SFC). IL - конечно исключение. Есть еще ST, но в целом при правильной записи кода - он тоже есть запись некоторого алгоритма.
Поэтому по факту, никто не будет замарачиваться с переложением кода FDB на схему алгоритма с ромбиками и квадратиками. Хотя в нашей практике, мы для описания алгоритмов защит используем графические средства описания, более расширенные конечно. Вместо ромбиков используем логические блоки (И, ИЛИ, НЕ).
Но проще, в качестве описания привести код модуля.

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

[Sergy6661]

Всех с прошедшими.

В АСУ ТП (так сложилось) программный код есть составная часть проектной документации

С какого перепугу! Где написано? Описание "Системного ПО" это не исходники. Алгоритмы и их описание тоже не исходники, даже распечатки кода тоже не исходники!
Мы передаем исходники всегда, НО!!! по истечении гарантийного срока, с соответствующим актом.
Для проведения пусконаладки исходники ПО не нужны, если это не предусмотрено самим разработчиком системы.
Это типа что-то без какого-либо HMI и для проверки надо подключаться ПК с софтом и проектом, но это частный случай.
Или вы что считаете что пусконаладчики компрессоров(да чего угодно) какого-нибудь Ингерсола(любого другого брэнда) разъезжают с исходниками???
А если по сути вопроса то...если нет в договоре пункта о передаче исходников, то разработчик в праве их не отдавать...если не хочет.

[Jackson]

Там еще,кроме главы 6 есть глава 7. В частности:
"7.1.7. В разделе «Алгоритм решения» следует приводить:

Это да. Но всё это включено в программную документацию, которая на комплекс - по согласованию. И это только документация, рассказ о том как работает алгоритм, а не сам листинг, и никак не сами исходники. А где они - вот вопрос.

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

И оговаривается специальным образом в задании/договоре. Разве нет? Мне кажется, передача исходников и комплекта документации - будь то рабочей, эскизной, программной, эксплуатационной (любой) - в любом случае оговаривается в договоре/задании независимо от того, что требуется нормативами. Прямо списком. Для любого изделия: серийного или штучного. Для серийного изделия этот список в ТУ может быть внесён (о которых кстати в ГОСТ 34 тоже упомянуто). А если оговорить просто "документация - согласно действующим нормативам" - то вот и получится ситуация, как у автора. Или как у Вас со шкафами управления насосами ДанФос: Вы не спросили - Вам и не предоставили.

Так? Я ищу, может я где-то не прав всё-таки....

[+]

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

[petr2off]

Не оговаривается. Если это разработка АСУ ТП, то такой документ должен быть. А вот его содержание теперь (пока не сделали тех. регламент) оговариваться может (хотя наши заказчики по этому поводу не замарачиваются, вставляют в тз ссылку на РД-50.34) и все.
Ну а далее - проще текст FDB отдать, чем делать полное описание алгоритма, которое по факту эквивалентно коду, без которого пусконаладку провести не реально.
Скажем в случае о котором я рассказывал, ну да можно было завернуть код проектировщикам, которые должны в таком случае сделать изменения в проекте, переподписать их (а в нашем случае этот код делал эксплутационный персонал). Ну и далее следствие:
Просахачены сроки сдачи проекта - получи штрафные санкции.
Круто испорчены отношения с эксплуатацией, которая подписывает приемку системы.
Но мы немного отклонились от темы прав на ПО. Смысл который я попытался донести - мир АСУ ТП отличается от мира 1С например. Точнее можно (и наверно даже нужно) говорить о правах на ПО, когда ты продаешь законченное изделие. Давайте другой пример приведу - Пункт подготовки газа. Блок-модуль, разделенные на 2 части, в первой технологическая начинка (трубы, фильтры, задвижки, приборы). Во второй стойки, с контроллером 1200, коммутаторами, блоками питания. В контроллер залито ПО, с которым можно общаться по Modbus RTU. Но в данном случае в договоре поставки, оно даже не фигурирует, как и не фигурирует контроллер. Продается модуль. И комплект документации к нему не попадает и не соответствует ГОСТ 34. Он отдельно даже как правило не оценивается.
А если предмет договора АСУ ТП полного цикла, то велком - ГОСТ 34. И фактически оплачивается создание этого комплекта документов. И его нужно сдать и подписать у заказчика. При этом как минимум доказать, что прописанные алгоритмы соответствуют реализованным в Вашем ПО. В этом процессе наверно юрист сможет помочь очень мало. Проще предоставить в качестве описания алгоритмов коды ПО, и тогда задача становится решаемой. При этом идея застолбить свою интелектуальную собственность на ПО выглядит немного смешной. Потому как даже у типовых объектов идентичное ПО бывает очень редко (еще раз, я не имею в виду законченное изделие), всегда нужно что то подпилить. Что кстати очень часто и в процессе эксплуатации происходит.

[Sergy6661]

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

А зачем нам юрист? Нам юрист не нужен, нужен инженер пусконаладочных работ, который на этапе пусконаладки "Проверка работы системы в режиме холодного пуска" доказывает и показывает соответствие работы ПО и алгоритмов Т.З.
А юрист так документы по титульникам посчитал и все...

[petr2off]

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

Отправлено спустя 1 минуту 59 секунд:
Пардон, я имел ввиду выполняются разными организациями.

[Sergy6661]

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

[petr2off]

Еще раз по пунктам. Есть законодательные особенности РФ в области АСУ ТП. Одной из них, является то, что создание проекта и пуска-наладка разнесены. Это не я придумал, поэтому не надо меня за советскую власть агитировать. Я за все хорошее, против всего плохого.
И согласно нему, код программы считается проектным документом и относится к разработке проекта. Т.е. формально должен выполнятся на этапе, когда еще только формируется смета проекта, которая будет выставлена на торги.
Я когда это узнал, некоторое время истерил, потому как в АСУ ТП я пришел с АСУ П, с нормального программирования. И у меня в голове не укладывалось (да и сейчас не укладывается) как можно разделять процесс написания и отладки ПО. Но тем не менее, имеем что имеем. Тут где то на форуме есть - мои поиски эмулятора Modbus. Это не от хорошей жизни, мне нужно как то делать проектную документацию.
Конечно, возможен вариант, когда по договору все это в одном флаконе. Более того, бывает случаи, когда вменяемый заказчик попадается, который понимает - что на этапе проекта получить реально работающее ПО часто затруднительно. Но это не означает, что ты должен отказываться от работы, только потому что она не по твоему феншую. Тут кстати есть полезная фишка, даже если тына все подписался. Появляется основание бить работу на этапы, и по этап проектирования оплачивать отдельно и раньше.

[winb]

Хорошая система должна работать (и все этапы жизни своей, наладки там, ремонты, нормальная эксплуатация проходить) так, чтобы не было никогда необходимости лезть к ПЛК с софтом и исходным кодом!

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

[Jackson]

то такой документ должен быть

Какой именно?

аши заказчики по этому поводу не замарачиваются, вставляют в тз ссылку на РД-50.34

Имеют право. Заказчик платит и выставляет условия. Правильно делает.

Ну а далее - проще текст FDB отдать

В каком именно документе из числа перечисленных в 50-34 и и в смежных стандартах должен содержаться листинг? Название документа. Я не нашёл такого.

[Sergy6661]

Есть законодательные особенности РФ в области АСУ ТП. Одной из них, является то, что создание проекта и пуска-наладка разнесены. Это не я придумал, поэтому не надо меня за советскую власть агитировать. Я за все хорошее, против всего плохого.

Законодательство это одно, а весьма вольная и расширенная трактовка это совсем другое.

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

Сначала проект 1...n месяцев, потом написание ПО 1...m месяцев...где торги? не прошли еще?
В любом случае в к смыслу темы эти рассуждения отношения имеют мало, т.к Обязательного законодательного требования Обязательного предоставления исходников в виде файлов проекта для передачи (да еще и с целью расширения функционала) нет!

И РД это РД-50.34 носило рекомендательный характер, но... кто платит тот и требования пишет, если требования подписал, изволь соответствовать.

[petr2off]

Какой именно?

Все должны быть, которые перечислены в ГОСТ 34.201-89.
Что касается ПО это в первую очередь:
Описание программного обеспечения и
Описание алгоритма (проектной процедуры)
Но есть еще и другие.

[VADR]

Или вы что считаете что пусконаладчики компрессоров(да чего угодно) какого-нибудь Ингерсола(любого другого брэнда) разъезжают с исходниками???

Так это всё серийные установки, там уже софт вылизан на тысячах инсталяций, работа наладчика по месту сводится к параметрированию готового софта. А что, если установок произведено в лучшем случае десятки штук? Да ещё каждая - со своими особенностями? У меня один такой объект есть - там запарились разработчиков пинать для исправления очевидных косяков. К примеру:
1. Один из узлов установки при возникновении технологической блокировки и возврата в нормальное состояние не хотел из этой блокировки выходить. Решалось только перезагрузкой контроллера.
2. Из установки есть две линии подачи сырья на разные участки. Линии независимы друг от друга, но при блокировке с любого из направлений вставали обе линии. Технологически неправильное поведение системы.
И то, и другое - косяки в реализации алгоритмов. Оба случая могли быть легко раскручены при наличии исходников проекта. Но проект - тайна за семью печатями, ноу-хау и всё такое. На исправление косяков тогда ушла уйма времени и нервов.
И есть другой объект, находится рядом, на базе таких же контроллеров, другой проектировщик/поставщик. С тем всё решилось намного проще: на наш запрос они потребовали:
1. Чтобы к системе подключались только обученные и сертифицированные специалисты (да, мы предъявляли свои сертификаты от Сименса)
2. Чтобы в период гарантийного срока мы не вносили никаких изменений без согласования с ними.
Оба условия мы соблюли, исходники нам передали, никаких проблем. Косяков на этом объекте было не меньше, но выявлялись они намного проще. А теперь - внимание, вопрос (риторический): у кого из указанных поставщиков выше вероятность дальнейшего сотрудничества?

Отправлено спустя 10 минут 43 секунды:
Да, и кстати: наверняка наладчики того же Ингерсола на свои первые компрессора ездили с исходниками, пока софт не вылизали.

[Jackson]

Все должны быть, которые перечислены в ГОСТ 34.201-89.

Во-1-х не все - я выше привёл пункты, там есть таблицы содержания документов, согласно ним - не все. Это первое. А второе - мой вопрос звучит так: как называется документ, который должен содержать листинг программы? Я такого документа в этих ГОСТ не нашёл. Если кто-то найдёт - будет хорошо.

Что касается ПО это в первую очередь:
Описание программного обеспечения и
Описание алгоритма (проектной процедуры)

Да, там целый раздел по программным документам с разъяснением содержания каждого из них. Так вот в каком из них листинг должен быть?

У меня один такой объект есть - там запарились разработчиков пинать для исправления очевидных косяков.

Саш, так это понятно. И разработчики разные бывают и ПНРят они по-разному. А дальше - вопрос бизнеса.

А теперь - внимание, вопрос (риторический): у кого из указанных поставщиков выше вероятность дальнейшего сотрудничества?

А вот поверь на слово - никак эта репутация не влияет на перспективы. Вот совсем. Это вашей службе явно лучше работать со вторым чем с первым. Но сотрудничать Вы будете с тем, кому заплатит руководство независимо от ваших предпочтений - ведь так?

[Sergy6661]

А теперь - внимание, вопрос (риторический): у кого из указанных поставщиков выше вероятность дальнейшего сотрудничества?

Ну первого вы пинали, а он работал-исправлял, устранял все норм.
А второй что-то с вас потребовал, понтов наколотил, исходники отдал-исправляйте сами, хлопцы.
Конечно надо первый вариант выбирать...

[VADR]

Ну первого вы пинали, а он работал-исправлял, устранял все норм.

Два очевидных косяка за полгода? А остальное кто будет делать? Система до сих пор работает через пень-колоду, разработчик уверен в своей абсолютной непогрешимости, доказать его неправоту без исходников - невозможно.

А второй что-то с вас потребовал, понтов наколотил, исходники отдал-исправляйте сами, хлопцы.

Почему? Основное они сами вычистили. Но косяки после сдачи объекта остаются всегда. В 100% случаев. В этом я убедился на своём 20-летнем опыте в АСУТП. Кроме того, технология время от времени меняется, оборудование через несколько лет выходит из строя, оказывается снятым с производства и требует замены на пришеднее ему на замену, и для решения всех этих проблем нужны исходники проекта.

А вот поверь на слово - никак эта репутация не влияет на перспективы. Вот совсем. Это вашей службе явно лучше работать со вторым чем с первым. Но сотрудничать Вы будете с тем, кому заплатит руководство независимо от ваших предпочтений - ведь так?

Без моего согласования? Агасчазд.

[Jackson]

доказать его неправоту без исходников - невозможно

Саш, точно невозможно? Сколько помню своего опыта, мне указывают на косяки, даже очень хитрые, иногда даже не подозревая о том что тут крутится какой-то софт. Да, порой бывает нужно ставить какие-то даталоггеры или ловить их другим особым способом, но именно лезть в исходники и даже в алгоритм никто не пытается. Если комплекс работает неправильно, то это видно.
ИМХО конечно.

Почему? Основное они сами вычистили.

Это был сарказм, Саш. :)

Но косяки после сдачи объекта остаются всегда.

В любой программе есть ошибки. Ошибки неисчерпаемы, как и атом. Это аксиома.

Без моего согласования? Агасчазд.

Смотря кто и сколько заплатит. :)

Отправлено спустя 1 минуту 54 секунды:
Ну ладно. А теперь - к вопросу. Кто-нибудь может найти какое-то нормативное требование о том, что поставщик ПТК обязан передать заказчику исходники или хотя бы листинги разработанного им софта? Я такого не нашёл по сей день.

[leon78]

Ну ладно. А теперь - к вопросу. Кто-нибудь может найти какое-то нормативное требование о том, что поставщик ПТК обязан передать заказчику исходники или хотя бы листинги разработанного им софта? Я такого не нашёл по сей день.

В нормативной документации конкретного заказчика. Цитаты приводил выше в теме