Стоимость работ по диспетчеризации.

[10em]

День добрый.
Подскажите по каким формулам и критериям ведется расчет стоимости робот по диспетчеризации?

[10em]

Неужели никто не занимается диспетчеризацией?

[Jackson]

Кто ей сейчас только не занимается. :)

[Dmitriy Chukichev]

Если нужна смета для бюджетного заказчика - ищите Справочник базовых цен на разработку техдокументации на АСУТП, в инете выкладывался на многих ресурсах.

[10em]

Согласен, что многие. Соответственно есть критерии по которым происходит перерасчет работ.
На своем опыте встречал два варианта.
1-й по количеству точек.
2-й по количеству трудочасов программиста.

[10em]

Если нужна смета для бюджетного заказчика - ищите Справочник базовых цен на разработку техдокументации на АСУТП, в инете выкладывался на многих ресурсах.

Мне не нужна схема расчета сметы на разработку техдокументации по АСУТП, мне нужна схема расчета сметы на разработку программирования диспетчеризации по АСУТП. :)

[Вован]

В принципе, разработка ПО входит в состав проектной документации. И осмечивается по той же схеме, что и ТП. Ну, а по большому счету, осмечивай по любому подходящему прямо или косвенно действующему сборнику, только заранее согласуй с Заказчиком - примут ли от тебя сметы по этому сборнику. Это из опыта.

[10em]

В принципе, разработка ПО входит в состав проектной документации. И осмечивается по той же схеме, что и ТП. Ну, а по большому счету, осмечивай по любому подходящему прямо или косвенно действующему сборнику, только заранее согласуй с Заказчиком - примут ли от тебя сметы по этому сборнику. Это из опыта.

Спасибо, теперь попробую провести простые расчеты.

[Dmitriy Chukichev]

Вот неоформленный окончательно шаблон сметки на ПО по упомянутому выше СБЦ

Смета на ПО.xls

[Вован]

Dmitriy Chukichev. Мне жаль, но Ваш вариант не пройдет ни одно СДО (сметно-договорной). Не вводите людей в заблуждение плиз.

[Dmitriy Chukichev]

Никого в заблуждение не ввожу. Уже несколько раз эти расчеты проходили через СДО, когда Заказчик принимает расчет по этому СБЦ. Лично сам защищал.

Если Заказчику не нравится СБЦ - тогда индивидуальная калькуляция на основе трудозатрат. Только тут же возникнет вопрос относительно обоснованности самих трудозатрат.

[Dmitriy Chukichev]

Вот еще ссылка по теме - http://tdocs.ru/node/70

[Вован]

Dmitriy Chukichev. Прошу прощения. Действительно, СБЦ действует. Я и сам его применяю. Просто "болванка" очень сырая, неаккуратно оформленная... Вот я и оплошал.

[10em]

Спасибо за разрешения вопроса :D . Сейчас становится более понятно как идет расчет работ по диспетчеризации. Если есть возможность, немогли бы вы дать, как пример, расчет какого либо объекта по диспетчеризации?

[Dmitriy Chukichev]

Вован, нет проблем, со всеми бывает. Я когда выкладывал ее, так и написАл, что шаблон неоформлен окончательно. К тому же он придумывался на коленке, в 35 -м МДС под этот справочник БЦ нет, ИМХО, подходящей формы.
А вообще, Вы правильно сказали, что сначала надо с Заказчиком согласовать применяемую сметно-нормативную базу, чтоб время зря не терять.

[Evgeny]

Вот еще ссылка по теме - http://tdocs.ru/node/70

Подскажите, пожалуйста, что значит "количество показателей" при определении трудоемкости разработки ТЗ? Это таблица 5 по ссылке.

[T_Vlad]

При расчёте инжиниринговых работ последние 3 года у нас стали обсчитывать количество переменных и команд в программе. Суммы получаются приличные.

[leon78]

При расчёте инжиниринговых работ последние 3 года у нас стали обсчитывать количество переменных и команд в программе. Суммы получаются приличные.

Прикольно.. Лучше тогда проще делать - цену за килобайт ПО писать.. "Взвесте мне 100кБ программы".
А если серьезно - большая программа и хорошая программа разные вещи. Часто написать хорошую компактную программу сложнее и дольше, чем плохую и большую.

[T_Vlad]

Прикольно.. Лучше тогда проще делать - цену за килобайт ПО писать..

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

[Evgeny]

При расчёте инжиниринговых работ последние 3 года у нас стали обсчитывать количество переменных и команд в программе. Суммы получаются приличные.

Я так и догадывался. Только, честно говоря, непонятно, каким образом количество переменных влияет на сложность разработки ТЗ, в котором они просто приводятся в виде списка... :? Ну будем считать, что как-то опосредованно влияет.

[T_Vlad]

влияет на сложность разработки ТЗ, в котором они просто приводятся в виде списка... :

Причём здесь разработка ТЗ? Я о доработке программы.
Тема - диспетчеризация.
Может я что то не допонимаю. У меня под диспетчеризацией понимается автоматизация установок и объединение их в единую систему с выводом всей информации (полной информации) и даже отдельных элементов управленя диспетчеру цеха и даже руководству цеха.

[Никита]

Evgeny, а чем вариант, предложенный Дмитрием Чукичевым Вас не устраивает? Там устоявшаяся нормативная база, индексы выходят до сих пор и все просто и понятно. И практически все заказчики принимали это как основу. Там еще и волшебный договорной коэффициент объема есть :)

[Evgeny]

влияет на сложность разработки ТЗ, в котором они просто приводятся в виде списка... :

Причём здесь разработка ТЗ? Я о доработке программы.
Тема - диспетчеризация.
Может я что то не допонимаю. У меня под диспетчеризацией понимается автоматизация установок и объединение их в единую систему с выводом всей информации (полной информации) и даже отдельных элементов управленя диспетчеру цеха и даже руководству цеха.

А при чем здесь доработка ПО, если вопрос был задан вполне конкретно по разработке ТЗ, стоимость которого также включается в "Стоимость работ по диспетчеризации". С остальным мне и так всё понятно.
Могу процитировать еще раз:

Вот еще ссылка по теме - http://tdocs.ru/node/70

Подскажите, пожалуйста, что значит "количество показателей" при определении трудоемкости разработки ТЗ? Это таблица 5 по ссылке.

[Evgeny]

Evgeny, а чем вариант, предложенный Дмитрием Чукичевым Вас не устраивает? Там устоявшаяся нормативная база, индексы выходят до сих пор и все просто и понятно. И практически все заказчики принимали это как основу. Там еще и волшебный договорной коэффициент объема есть :)

Я разве сказал, что меня что-то не устраивает? Я просто спросил, что означает конкретная строка в таблице - что используют опытные люди в качестве "количества показателей" при определении трудоёмкости разработки ТЗ. Насколько я понял из последовавшего ответа, так же, как и для остальных документов, за основу берётся количество тегов в проекте. Либо мне ответили не на тот вопрос, который я задавал :)

[Никита]

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