СОСТАВЛЕНИЕ СМЕТЫ ЗАТРАТ НА РАЗРАБОТКУ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ - Студопедия

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

· материалы и комплектующие (М);

· заработная плата исполнителей, основная (Зо) и дополнительная (Зд);

· отчисления на социальные нужды (Осн);

· амортизация основных средств и нематериальных активов (А);

· расходы на спецоборудование (Рс);

1. Расходы по статье «Материалы» (М) определяются на основании сметы затрат, разрабатываемой на ПО с учетом действующих нормативов. По статье «Материалы» отражаются расходы на магнитные носители, бумагу, красящие ленты и другие материалы, необходимые для разработки ПО. Нормы расхода материалов в суммарном выражении (Нм) определяются в расчете на 100 строк исходного кода (приложение 1) или по нормативу в процентах к фонду основной заработной платы разработчиков (Нмз), который устанавливается организацией (3-5 %). Сумма затрат на расходные материалы рассчитывается

где Нм - норма расхода материалов в расчете на 100 строк исходного кода ПО (д.е.);

Voi - общий объем ПО (строк исходного кода) на конкретное ПО.

где Нмз - норма расхода материалов от основной заработной платы (%)

На статью «материалы» относят затраты на материалы и принадлежности, необходимые для проведения НИР. Затраты определяют по действующим отпускным ценам. Результаты сводятся в таблицу 1.1

Таблица 1.1 - Стоимость материалов, необходимых для разработки программного обеспечения

Разработка программного обеспечения - Форум сметчиков - Ценообразование в строительстве - Сметчик ру - Сметный портал - Все для сметчика

200?'200px':''+(this.scrollHeight+5)+'px');"> ПО разработано по СБЦ9 - АСУТП из тамбовской базы 2001 года

- СБЦ АСУТП - один на всю страну - Утвержден Министерством промышленности Российской Федерации
14 марта 1997г. по представлению Министерства строительства Российской Федерации
(письмо от 27.01.97 г. №9-4/8). (если не брать в расчет еще Московские сборники. )
Т.е. он Тамбовским быть не может.

200?'200px':''+(this.scrollHeight+5)+'px');"> вопросы.
в лимитированных затратах есть глава 12 - проектные и изыскательские работы. или, все же, лучше включить в главу 9

200?'200px':''+(this.scrollHeight+5)+'px');"> обязательно ли следует подавать ОТДЕЛЬНУЮ смету на разработку ПО?

- разработка ПО может быть включена в смету на АСУТП, одним из элементов.

200?'200px':''+(this.scrollHeight+5)+'px');"> СБЦ в базе 2001 года

- у вас СБЦ в базе 95 г.

200?'200px':''+(this.scrollHeight+5)+'px');"> насколько корректно использовать в одной смете две базы?

- вы наверное имели в виду в ССР - если да, то можно.

ПОДСЧЕТ ЗАТРАТ И РАЗРАБОТКА СМЕТ

Накладные расходы проекта.

3: Общие и административные накладные расходы.

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

Прямые расходы напрямую связаны с пакетом работ. На прямые расходы могут влиять управляющий проектом, проектная команда, а также отдельные работники, выполняющие пакет работ. Эти затраты представляют собой реальные расходы наличности и должны выплачиваться по мере выполнения работ над проектом; следовательно, прямые расходы обычно отделяют от накладных расходов. «Сворачивание» проекта на нижнем уровне обычно включает только прямые расходы.

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

Общие и административные накладные расходы представляют собой организационные расходы, никак не связанные с каким-либо проектом, поэтому их еще называют постоянными расходами. Хотя эти расходы не оплачиваются немедленно из кармана, они реальны и в конечном счете должны быть покрыты, если фирма хочет существовать и дальше. Эти затраты имеют место на протяжении всего проекта. Ассигнование общих и административных расходов различно в разных организациях, Обычно они рассчитываются, как процент от общих прямых расходов. Например, если иищие прямые расходы составляют $400 ООО, то будет добавлена общая норма для общих и административных расходов в 50%, и общая сумма расходов на проект составит $600 000.

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

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

Методы оценки затрат.

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

Если проект походит на предыдущие, то цифры затрат на предыдущие проекты можно использовать, как исходную точку для нового. Нужно учесть отличия нового проекта и откорректировать старые цифры соответственно этим отличиям. Например, фирма по ремонту кораблей в сухих доках имеет набор стандартных проектов ремонта (например, проекты ремонта паровых котлов), которые используются, как исходная точка расчета стоимости и сроков выполнения каждого нового проекта. Для стандартных проектов отличиями считаются сроки, затраты и ресурсы, и соответственно им в стандартный проект вносятся изменения. Такой подход позволяет фирме за короткий промежуток времени разработать потенциальный график работ, рассчитать затраты и составить смету. К сожалению, такой подход применим к очень незначительному количеству проектов.

Типичным для этого подхода является желание иметь 95% вероятности совпадения расчетов времени и затрат. Конечно, прошлый опыт — это хорошая исходная точка для расчетов. Но, чтобы достичь 95%-го уровня вероятности, в расчетах с использованием прошлого опыта нужно учитывать другие соображения. Нужно учесть особенности нового проекта, работников, внешние факторы и на основе этого повысить качество расчетов времени и затрат на новый проект.

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

Человеческий фактор тоже может быть источником ошибки при расчетах. То, насколько работники обладают необходимой для выполнения задачи квалификацией, повлияет на производительность и время приобретения ими опыта. Оценки того, как люди работают — на ставку или полставки, показывают, что те, кто работает на полную ставк г, работают более производительно. Близость членов команды к организационной инфраструктуре повлияет на обмен информацией и, таким образом, на расчеты (то есть, они могут повлиять на то, сколько времени требуется для принятия решений). Иногда такой фактор, как текучесть кадров, может повлиять на расчеты.

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

Наиболее надежный способ произвести расчеты — обратиться к ответственным за работу. Эти люди по опыту знают, где найти информацию, позволяющую рассчитать затраты на пакеты работ Когда есть значительная неуверенность в цифре затрат, необходимых для выполнения пакета работ, самое разумное — сделать три типа расчетов затрат: оптимальнонизких, средних и высоких. В табл. 3-2 представлен гипотетический пример использования трех типов расчетов для набора работ. Такой подход дает возможность управляющему проектом и владельцу оценить риски, связанные с затратами на проект Такой подход помогает оценить возможность неприятных сюрпризов по мере работы над проектом. Также он создает основу для определения фонда непредвиденных обстоятельств (в главе 5 об этом будет рассказано подробно).

Табл. 3-2. ОЦЕНКА ЗАТРАТ НА ПАКЕТ РАБОТ ПО ДИЗАЙНУ СЧИТЫВАЮЩЕГО/ЗАПИСЫВАЮЩЕГО УСТРОЙСТВА

Сметы по периодам времени.

Оценки затрат еще не являются сметой. Сметой они становятся тогда, когда распределены по временным периодам. Например, смета проекта может составлять $500 ООО. Деньги распределяют, когда проект выполняется. Необходима процедура, определяющая, когда деньги должны быть в наличии. Каждый расчет набора работ делает необходимым наличие сметы по периодам времени. На рис. 3-6 срок выполнения проекта работ составляет три недели, и на этом этапе никак нельзя узнать, когда будут иметь место расходы определенного по периодам времени набора работ. Продолжительность этого и других наборов работ используется для разработки сетевого графика проекта, который определяет расписание начала и окончания наборов работ. Затем сметы по периодам времени для наб jpoB работ накладывают на периоды работ по графикам для определения финансовых потребностей для каждого периода в течение существования всего проекта.

Различные пользователи по-разному понимают затраты и сметы. Управляющий проектом должен знать об этих различиях при составлении сметы проекта, и тогда он информирует об этих различиях других. На рис. 3-8 представлены три различных понимания. Левая линия обозначает фонды, выделенные до того, как их стали использовать в проекте. Например, размещение заказа на большой насос для нефтепровода может произойти за.

полгода до того, как он понадобится, но заказ размещен, и вы по закону обязаны заплатить, когда он будет готов к транспортировке и использованию в проекте. В этом случае связь между выделенными средствами не отражает денежного потока по графику проекта. Эта информация ценна для финансового управляющего организации при прогнозировании будущих расходов наличности. Средняя линия, смета по графику, обозначает запланированные прямые расходы так, как их ожидают. Линия фактических расходов обозначает фактические прямые расходы так, как они происходят по мере выполнения проекта. Расчеты всех трех типов полезны для прогноза и предвидения будущих потребностей в финансах (наличности), измерения графика проекта и возможности проследить за фактическими различиями в затратах.

Рис. 3-8. Три точки зрения на затраты УРОВЕНЬ ДЕТАЛИЗАЦИИ.

Уровень детализации различен для разных уровней управления. На любом уровне детализация не должна быть больше, чем это необходимо и достаточно. Верхний уровень управления обычно интересует проект в целом и основные события, обозначающие основные достижения, например, «строительство нефтяной платформы в Северном море» или «закончить работу над образцом». Средний уровень управления обычно интересует один из участков проекта или одно из основных событий. Интересы уп-.

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

Управляющие проектами — практики выступают за минимальный уровень детализации. Но всему есть пределы. Одна из наиболее часто допускаемых новыми управляющими проектами ошибок состоит в том, что они забывают то, что расчет времени на выполнение задания будет использован для контроля за графиком и стоимостью работ. Эмпирическое правило, которым пользуются управляющие проектом-практики, говорит о том, что время выполнения задания не должно превышать пяти или, в крайнем случае, десяти дней, если рабочие дни — это блоки времени, используемые для проекта. Такое правило, вероятно, приведет к еще более детализированной сети, но дополнительная детализация будет полезна для контроля за графиком и расходами по мере работы над проектом. Предположим, что задача состоит в создании образца управляемой компьютером конвейерной линии за 40 рабочих дней и со сметой в $300 ООО. Для целей контроля может быть лучше разделить задание на семь-восемь более мелких заданий. Если с выполнением одного из заданий запаздывают либо изза трудностей, либо из-за неправильно рассчитанного времени, то можно быстро внести коррективы и избежать опозданий в выполнении последующих заданий и проекта в целом. Если же речь идет о выполнении одного задания в течение 40 дней, то есть опасность того, что вплоть до сорокового дня в jounce не будут вноситься никакие коррективы, так как многие люди склонны сидеть и дожидаться не исправится ли все само-собой, или они просто не признают, что отстают от графика, и это приведет к тому, что проект в целом отстанет от графика более, чем на 5 дней. Пятидневное или десятидневное эмпирическое правило касается расходов и целей выполнения. Аналогичная проверка необходима для затрат и целей выполнения через короткие промежутки времени, чтобы не выпустить все из-под контроля.

Если следующее эмпирическое правило всего лишь предложило результаты в слишком большом количестве сетевых заданий, то возможна альтернатива, но при определенных условиях. Срок можно продлить больше, чем на 5—10 дней, если можно определить точки контроля за выполнением части задания так, чтобы можно было четко определить, на сколько процентов выполнена работа. Эта информация бесценна при контроле за графиком выполнения работ и расходами. Например, выплаты за работу по контракту производят по «проценту выполнения». Определение задания с указанием точки начала и окончания и промежуточными точками повышает возможность раннего выявления проблем, корр

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

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

Если структура отражает чрезмерную детализацию, появляется тенденция разбить работу на задания отделам. Эта тенденция может стать препятствием на пути к успеху, так как акцент будет сделан скорее на результатах работы отделов, а не на промежуточных результатах. Чрезмерная детализация также означает увеличение непродуктивной бумажной работы. Отметим, что если уровень СРРПЭ увеличивается на 1, то количество счетов издержек может расти в геометрической прогресс ии С фугой стороны, если уровень детализации недостаточен, то структура может не оправдать ожиданий. К счастью, СРРПЭ присуща гибкость. Участвующие организационные единицы могут расширять свою часть структуры, если это нужно. Например, технический отдел может разбить свою работу над промежуточным результативным продуктом на более мелкие пакеты: электрик, гражданское строительс!ВО, механика.

Методика определения стоимости разработки программного обеспечения для госорганизации?

Существует ли официально принятая методика определения стоимости разработки программного обеспечения для госорганизации?
Проект техзадания на разработку автоматизированной системы по ГОСТ 34.602-89 существует.
Собираемся публиковать его на gz-spb.ru.
Но для этого должны обосновать цену.

Re: Методика определения стоимости разработки программного обеспечения для госорганизации? [new]

Откуда: Питер FM
Сообщений: 608

Навскидку единственное что видел

______________________________________________________
Давайте считать обступившее нас со всех строн коричневое море шоколадным

Откуда:
Сообщений: 136

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

Re: Методика определения стоимости разработки программного обеспечения для госорганизации? [new]

Отвечаю сам себе. Мне ведь надо обосновать цену работы до конкурса и утвердить это обоснование. Только тогда госконтора может выйти на конкурс с "техзаданием" и обоснованием цены.
Мы сами нарыли вот это:
ОСТ 4.071.030 Отраслевой стандарт "Автоматизированная система управления предприятием. Создание системы. Нормативы трудоемкости."

В результате получаем человеко-часы. Цену человеко-часа программера нашли в общедоступной базе данных Госкомстата.

Кто нибудь ходил таким путем? Какие сложности вероятны?

Re: Учет средств СВТ [new]

Откуда: СПб
Сообщений: 855

Кто нибудь ходил таким путем?

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

Re: Методика определения стоимости разработки программного обеспечения для госорганизации? [new]

Откуда: Питер FM
Сообщений: 608

Кто нибудь ходил таким путем? Какие сложности вероятны?

1) Не найти исполнителя
2) Работать по отмененному стандарту
3) Ошибиться в расчете сроков
4) Не учесть косвенные расходы например на написание тех. документации, конвертацию данных и т.д

______________________________________________________
Давайте считать обступившее нас со всех строн коричневое море шоколадным

Re: Методика определения стоимости разработки программного обеспечения для госорганизации? [new]

Откуда:
Сообщений: 136

В результате получаем человеко-часы. Цену человеко-часа программера нашли в общедоступной базе данных Госкомстата.

Не забывайте, что разработка ПО это не только человеко-часы "программеров". Это еще и время аналитиков, менеджеров, тестеров, техписателей и т.п.
Кстати, интересно, какая там ставка у Госкомстата. )

В остальном согласен с shelsoft

Re: Методика определения стоимости разработки программного обеспечения для госорганизации? [new]

1).Для обоснования начала работ в направлении любой госконторе нужно в принципе определить порядок затрат.

2).Обоснование лимита конкурсной закупки может быть экстраполировано с подобной работы или рассчитано по нормативам. Далее наша заявка с конкурсной документацией и обоснованием должна быть утверждена финансовой администрацией субъекта. Вот тут меня первый раз и слили, предложив не высасывать из пальца. Требуют точных рассчетов.

3).Применение упомянутого отмененного стандарта оказалось успешным. В конце концов он учитывает трудозатраты и на обследование, и на принятие решений, и на подготовку документации, и на внедрение.
Далеко не только работу кодера.

4).А по ценнику Росстата человек, занимающийся написанием программного обеспечения, стоил нанимателю из совместного предприятия около 50 тыс. рублей в мес. в 2007 г. (в Москве и Питере).
Просто усреденно по разным предприятиям 23-25 тыс.

Re: Методика определения стоимости разработки программного обеспечения для госорганизации? [new]

Откуда: Питер FM
Сообщений: 608

1) Применение упомянутого отмененного стандарта оказалось успешным.
2).А по ценнику Росстата

1) Упаси вас от его упоминания :)
2) За это искренее спасибо

______________________________________________________
Давайте считать обступившее нас со всех строн коричневое море шоколадным

Re: Методика определения стоимости разработки программного обеспечения для госорганизации? [new]

Откуда:
Сообщений: 136

4).А по ценнику Росстата человек, занимающийся написанием программного обеспечения, стоил нанимателю из совместного предприятия около 50 тыс. рублей в мес. в 2007 г. (в Москве и Питере).
Просто усреденно по разным предприятиям 23-25 тыс.

Спасибо за инфу. Среднюю з.п. ИТ-специалиста в Москве и Питере вы можете посмотреть на форуме Работа, подфоруме "Вакансии". Это где-то 60-70 тыс. р. на руки в месяц. Нанимателю такой человек обойдется где-то в 100 тыс. в месяц. Теперь умножьте эту цифру на 2 или 3 и вы поймете за сколько денег компании продают время своих работников. 1 млн. рублей, это работа команды из 4-5 человек в течении одного месяца. Отталкивайтесь от этих цифр, и, возможно, на Ваш тендер откликнутся не только любители попилить деньги за откаты. )

Re: Методика определения стоимости разработки программного обеспечения для госорганизации? [new]

Откуда: Санкт Петербург
Сообщений: 582

Автору :
Не воспринимайте критику. ИМХО идете в правильном направлении.
ВАм нужно именно обоснование по документам. а не честный расчет.

Советую также предварительно выслать ТЗ для оценки ряду контор полуофициально, чтобы получить порядок цены. В ответ можно этим конторам что то пообещать, например своевременно и честно их информировать о тендере :-)

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

Re: Методика определения стоимости разработки программного обеспечения для госорганизации? [new]

Спасибо за инфу. Среднюю з.п. ИТ-специалиста в Москве и Питере вы можете посмотреть на форуме Работа, подфоруме "Вакансии". Это где-то 60-70 тыс. р. на руки в месяц. Нанимателю такой человек обойдется где-то в 100 тыс. в месяц. Теперь умножьте эту цифру на 2 или 3 и вы поймете за сколько денег компании продают время своих работников. 1 млн. рублей, это работа команды из 4-5 человек в течении одного месяца. Отталкивайтесь от этих цифр, и, возможно, на Ваш тендер откликнутся не только любители попилить деньги за откаты. )

Реальный ценник на реальном рынке мы знаем. Вопрос в том, как госконторе, у которой финансовые проверки одна уходит-другая приходит, и так постоянно, обосновать цену, не выходя из имеющегося законодательного поля. По аналогии - не верят.

Рыночный механизм - это сам конкурс и есть. Мы и раньше писали, что нужно не цену определить, а лимит финансирования, на который народ придет и будет бороться за заказ.

Есть еще один фактор.
Это качественное техзадание - единственный способ отбиться от демпингующих откатчиков.

Re: Методика определения стоимости разработки программного обеспечения для госорганизации? [new]

1) Упаси вас от его упоминания :)
2) За это искренее спасибо

Мы нашли этот ОСТ, копаясь на GZ-SPB.ru.
Там к конкурсу прикрепляются пакеты документации. В нескольких пакетах, например Метрополитена и Пенсионного Фонда, этот ОСТ использовался.
Нашли - сделали вывод, что Комитет конкурсные пакеты с упоминанием этого документа допустил к публикации.

Так в чем проблема? Нельзя ли поподробней?

Re: Методика определения стоимости разработки программного обеспечения для госорганизации? [new]

Откуда: Питер FM
Сообщений: 608

Так в чем проблема? Нельзя ли поподробней?

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

Это качественное техзадание - единственный способ отбиться от демпингующих откатчиков.

Да один из способов :))

______________________________________________________
Давайте считать обступившее нас со всех строн коричневое море шоколадным

Смета на разработку программного обеспечения образец

Определение стоимости разработки технических заданий на создание АСУ ТП и документации по общесистемным решениям, организационному, информационному, техническому, математическому и программному обеспечению АСУТП осуществляется с применением «Справочника базовых цен на разработку технической документации на автоматизированные системы управления технологическими процессами (АСУТП)». Цены в Справочнике установлены по состоянию на 1 января 1995 г. Подробнее, что такое АСУ ТП >>>

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

Цены в Справочнике учитывают все затраты на разработку технической документации на АСУТП, включаемые в себестоимость в соответствии с «Положением о составе затрат по производству и реализации продукции (работ, услуг), включаемых в себестоимость продукции (работ, услуг), и о порядке формирования финансовых результатов, учитываемых при налогообложении прибыли», утвержденным постановлением Правительства РФ от 5 августа 1992 г. №552, с изменениями и дополнениями (кроме затрат на приобретение спецоборудования и служебные командировки – эти затраты мы можем учитывать дополнительно).

Цены в Справочнике установлены на разработку технических заданий (ТЗ) на создание АСУТП и разработку проектной документации на АСУТП в объеме технических проектов (по СНиП 11-01-95 - проектов) и рабочей документации. При этом цены установлены отдельно на разработку каждой из следующих частей проектной документации на АСУТП:

• общесистемные решения (ОР);
• организационное обеспечение (ОО);
• информационное обеспечение (ИО);
• техническое обеспечение (ТО);
• математическое обеспечение (МО);
• программное обеспечение (ПО).

Цены в Справочнике установлены в зависимости от трудоемкости работ, оцениваемой по основным факторам и выраженной в баллах (согласно таблицам 2 и 4 Справочника). Данные таблицы ориентированы на впервые разрабатываемые АСУ ТП с учетом «базовых» факторов и условий их создания.

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

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

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

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

для проектной документации на АСУ ТП - техническому заданию на создание АСУ ТП, а в случае недостаточности данных, содержащихся в ТЗ, - другим документам, разработка которых предшествовала разработке технического или технорабочего проекта (по СНиП 11-01-95 - соответственно проекта или рабочего проекта) АСУ ТП.

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

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

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

Цбаз = S x SБ x К

S - ценностной множитель (млн. руб.);

SБ - сумма баллов;

К - общий поправочный коэффициент.

Общая базовая цена разработки проектной документации на АСУ ТП (Цпд) определяется по формуле:

Цпд = Цор + Цоо + Цио + Цто + Цмо + Цпо,

Цор - цена разработки документации общесистемных решений;

Цоо - цена разработки документации по организационному обеспечению;

Рис.3-2. Окно для выбора
характеристик по фактору
«Характер протекания
управляемого технологического
процесса во времени»

Цио - цена разработки документации по информационному обеспечению;

Цто - цена разработки документации по техническому обеспечению;

Цмо - цена разработки документации по математическому обеспечению;

Цпо - цена разработки документации по программному обеспечению.

Рассмотрим пример расчета стоимости разработки технического задания и проектной документации АСУ ТП в программе Строительные Технологии – СМЕТА ПИР. В окне «Структура проекта» выполняем последовательность команд на панели инструментов «Добавить» - «Смета на АСУТП». В открывшемся окне вводим номер и наименование сметы.

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

Для редактирования сметы переходим на вкладку «Смета ПИР» (рис.2). Редактирование расценок в смете на АСУ ТП реализовано в виде своеобразного конструктора. Для каждого из факторов необходимо выбрать соответствующие данные из предлагаемых перечней (примеры на рис.3-1 и рис.3-2) или внести количество технологических операций или переменных (по соответствующим исходным данным) – рис.4.

После ввода всех исходных данных необходимо применить поправочные коэффициенты согласно таблице 1 Справочника, значения которых должны быть согласованы с заказчиком. На панели инструментов нажимаем кнопку «Коэффициенты», в открывшемся окне переходим на вкладку «Техчасть (АСУТП)» (рис.5) и применим коэффициенты «1. АСУТП является повторно-применяемой» - значение коэффициента может быть в пределах от 0,3 до 0,9 – согласованное значение для нашего примера – 0,4; «6. АСУТП создается с использованием зарубежных средств» - значение в пределах от 1,05 до 1,25 – согласовали значение – 1,1.

Применяем коэффициенты и на одноименной вкладке в нижней части окна «Смета ПИР» устанавливаем согласованные с заказчиком значения (рис.6).

Для второй сметы выбираем раздел Разработка проектной документации на АСУ ТП (рис.7).

Расчет стоимости разработки проектной документации АСУТП происходит аналогичным образом, в окне «Смета ПИР» выбираем характеристики из предлагаемых перечней или вводим данные по всем семи факторам (рис.8). На вкладке «Расчет раздела» приводится расчет стоимости по всем частям проектной документации.

Трудоемкость разработки каждой из частей проектной документации на АСУТП рассчитана для двухстадийной разработки.

Ориентировочное распределение базовой цены двухстадийной разработки проектной документации на АСУ ТП по стадиям установлено на основании таблицы 6 Справочника. Распределение базовой цены по стадиям осуществляется разработчиком по согласованию с заказчиком (в пределах цены двухстадийной разработки).

При одностадийной разработке проектной документации на АСУ ТП базовая цена принимается с понижающим коэффициентом Кст = 0,8.

В нашем примере мы учитываем только стадию «Технический проект», поэтому на вкладке «Стадии раздела» отключаем стадию «Рабочая документация» (рис.9).

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

После отключения стадии «Рабочая документация» и применения поправочных коэффициентов, формулы расчета стоимости имеют следующий вид – см. рис.10.

Если не предусматривается выполнение какой-то из частей проектной документации АСУ ТП, например, не выполняется «Математическое обеспечение» и «Программное обеспечение», то на вкладке «Стадии раздела» обнуляем соответствующие проценты, и расчет по этим частям не будет учтен в общей стоимости (рис.11).

Печать сметы осуществляется из окна «Структура проекта». Для вывода сметы на предварительный просмотр нажимаем кнопку «Печать» на панели инструментов.

Из окна предварительного просмотра смету можно вывести непосредственно на принтер или экспортировать в любой из предложенных форматов (PDF, HTML, MS Excel или Word, Open Office Calc или Writer) – см. рис.12.

Пример договора на разработку ПО для Windows

Пару недель назад столкнулся с проблемой. Нужен типовой договор на разработку ПО, но в архивах такого не нашлось. В первых результатах поисковик выдает пару десятков договоров на разаработку сайта, а вот на десктопное приложение пример нашелся с трудом. Возможно пригодиться кому то еще:

на разработку Программного обеспечения «____________________»

г. Смоленск «___» ____________ 20__ г.

___________________________________________, именуемое в дальнейшем Заказчик, в лице директора ________________________________, действующего на основании Устава, с одной стороны, и Общество с ограниченной ответственностью Х-СОФТ, именуемое в дальнейшем Исполнитель в лице директора _________________________________, действующего на основании Устава, с другой стороны, а вместе именуемые стороны, заключили настоящий договор о нижеследующем:

1.1. Заказчик поручает, а Исполнитель принимает на себя обязательства по разработке и передаче Заказчику программного обеспечения «____________» (далее – Программное обеспечение), а Заказчик обязуется принять и оплатить его в соответствии с условиями настоящего Договора.

1.2. Требования к разрабатываемому Программному обеспечению указаны в Приложении №1, являющемся неотъемлемой частью настоящего Договора.

1.3. Правообладателем на разработанное по настоящему Договору Программное обеспечение становится Заказчик, авторские права остаются за исполнителем.

2. ПРАВА И ОБЯЗАННОСТИ СТОРОН

2.1. Заказчик обязуется:

2.1.1. Предоставить Исполнителю Техническое задание на разработку Программного обеспечения (Приложение №1 настоящего Договора)

2.1.2.Выплачивать Исполнителю вознаграждение в соответствии с условиями настоящего Договора

2.2. Исполнитель обязуется:

2.2.1. Выполнить работы, указанные в Техническом задании (Приложение №1), в сроки, установленные в п. 4.2. настоящего Договором.

2.2.2. Устранить недостатки и дефекты, выявленные при приемке работ.

2.3. Заказчик имеет право менять по своему усмотрению программный код разработанного программного обеспечения.

2.4. Заказчик имеет право на тиражирование, распространение в т.ч. в коммерческих целях разработанного Программного обеспечения

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

2.6. Право выбора технологии программирования и алгоритмов работы остается за Исполнителем.

3. СТОИМОСТЬ РАБОТ И ПОРЯДОК ОПЛАТЫ

3.1. Общий размер вознаграждения Исполнителя за выполнение услуг, указанных в п. 1.1. настоящего Договора, составляет __________ .

3.2. Оплата услуг осуществляется тремя платежами:

3.2.1. Первый (авансовый) платеж в размере __________ осуществляется в течение 3 (трех) рабочих дней с момента подписания настоящего Договора.

3.2.2. Второй платеж в размере _____________ производится в течение 3 (трех) рабочих рабочей дней после подписания акта приема-сдачи работ(Приложение №2) на выполнения работ в объема половины Технического задания (Приложение №1).

3.2.3. Третий платеж в размере _______________ производится в течение 3 (трех) рабочих дней после подписания акта приема-сдачи работ на выполнения всех работ по Техническому заданию (Приложение №1).

3.3. Оплата стоимости услуг по настоящему Договору может производиться в ином порядке по письменному согласованию Сторон.

3.4. Расходы на оборудования, требуемые для выполнения работ по данному договору оплачивает заказчик в размере _________________ в течение 3 (трех) рабочих рабочей дней после подписания настоящего договора.

4. СРОК ИСПОЛНЕНИЯ ДОГОВОРА

4.1. Настоящий Договор вступает в силу с даты подписания и действует до исполнения Сторонами своих обязательств, вытекающих из существа настоящего Договора.

4.2. Исполнитель обязуется разработать и передать Заказчику Программное обеспечение, указанное в п. 1.1. настоящего договора, в срок в 3(три) календарных месяца с момента подписания настоящего Договора.

5. ПОРЯДОК ПРИЕМКИ РАБОТ

5.1. Исполнитель по результатам оказания услуг направляет заказчику Акт сдачи-приемки оказанных услуг, подписанный со своей стороны. В течение пяти рабочих дней после получения Акта от Исполнителя Заказчик обязан либо подписать Акт и направить Исполнителю подписанный экземпляр Акта, либо предоставить мотивированный отказ от приемки с приложением подписанного со стороны заказчика скорректированного Акта.

6. ОТВЕТСТВЕННОСТЬ СТОРОН И ПОРЯДОК РАЗРЕШЕНИЯ СПОРОВ

6.1. В случае просрочки оплаты работ Исполнителю против сроков, указанных в условиях настоящего Договора, Исполнитель имеет право потребовать неустойку в размере 0,1% (ноль целых одна десятая процента) за каждый день просрочки, но не более чем 10% от суммы вознаграждения за подлежащие оплате услуги.

6.2. В случае несоблюдения Исполнителем срока оказания услуг, установленного в п. 4.2 настоящего Договора, Заказчик имеет право потребовать неустойку в размере 0.1% (ноль целых одна десятая процента) за каждый день просрочки, но не более чем 10% от суммы вознаграждения за подлежащие оплате услуги.

6.3. Неустойка полагается к уплате в случае выставления соответствующего счета и считается признанной с момента оплаты такого счета.

6.4. Штрафы и неустойки выплачиваются стороной, нарушившей обязательства, в течение 5 (пяти) банковских дней с момента выставления соответствующего требования.

6.5. Споры и разногласия между Сторонами по данному Договору разрешаются путем переговоров и соглашений, а в случае невозможности достижения взаимоприемлемого решения в соответствии с действующим законодательством Российской Федерации.

7. НЕПРЕОДОЛИМАЯ СИЛА (ФОРС-МАЖОРНЫЕ ОБСТОЯТЕЛЬСТВА)

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

7.2. Стороны несут ответственность за частичное или полное неисполнение обязательств по настоящему Договору при наличии вины только в случаях, предусмотренных законом или настоящим Договором.

8.1. Настоящий Договор составлен в двух экземплярах, имеющих равную юридическую силу, по одному для каждой из сторон.

8.2. Ни одна из Сторон не вправе передавать свои права и обязанности по настоящему договору третьим лицам без письменного согласия на то другой Стороны.

8.3. Вся корреспонденция, включая необходимые письменные уведомления, претензии и заявления, по настоящему Договору будет считаться доставленной Стороне Договора, если они будут доставлены в письменном виде любым способом, предусмотренным Российским законодательством по следующему адресу:

Для Заказчика: адрес для почтовой корреспонденции совпадает с адресом проживания.

Для Исполнителя: адрес для почтовой корреспонденции совпадает с адресом проживания.

8.4. Исполнитель гарантирует, что:

8.5.1. результаты оказания услуг, передаваемые им Заказчику по настоящему Договору, свободны от любых прав третьих лиц;

8.5.2. при оказании услуг по настоящему Договору Исполнитель не нарушает авторских и смежных прав третьих лиц;

8.5.3. Исполнитель обладает всеми необходимыми правомочиями для передачи их Заказчику на условиях настоящего Договора.

8.6. Исполнитель обязуется возместить Заказчику убытки в полном объеме, в том случае, если к Заказчику будут предъявлен третьими лицами иск(и) в любой судебной инстанции, связанный с нарушением авторских или иных прав третьих лиц в связи с исполнением настоящего Договора, и решение судебной инстанции, вступившее в законную силу, удовлетворит вышеуказанный иск. В свою очередь Заказчик обязуется информировать Исполнителя о любых исках третьих лиц, предъявленных к нему в связи или на основании настоящего Договора.

8.7. В случае неисполнения Исполнителем своих обязательств по Договору, Заказчик оставляет за собой право организовать судебное разбирательство по данному вопросу. При этом данное судебное разбирательство должно происходить по месту жительства Заказчика.

8.8. Все изменения и дополнения к настоящему Договору производятся путем составления дополнительных двусторонних соглашений, которые подписываются Сторонами и являются неотъемлемыми частями настоящего Договора.

8.9. Каждая из Сторон обязуется письменно уведомить другую сторону об изменении своего местонахождения или банковских реквизитов не позднее 3-х дней после наступления изменений.

8.10. Исполнитель гарантирует работу программного обеспечения в соответствии с требованиями, изложенными в техническом задании (Приложение №1). Дальнейшая модификация и добавление функций и возможностей, не предусмотренных в техническом задании, являются предметом отдельного Договора.

9. РЕКВИЗИТЫ И ПОДПИСИ СТОРОН