Написание программы для мониторинга ДГУ

Для того что бы чтото оценить надо понимать что требуется.
Из приведенного описания можно заключить что работы примерно на 2-3 месяца. Бюджет приблизительно $7К - но это весьма приблизительная оценка и может колебаться как в одну так и в другую сторону.

Требуется запрашивать с определенной периодичностью с удаленных устройств (в нашем случае контроллер ДГУ) около 20 аналоговых параметров (напряжения, токи и пр.) и около 20 состояний (аварийных событий), сохранять их в БД или лог-файле и отображать последние измеренные результаты в интерфейсе программы. Также нужно реализовать возможность управления, т.е.отправки определенных команд на контроллер устройства по нажатию соответствующей кнопки в интерфейсе (реализуется командами аналогичными командам опроса). Еще необходимо 2 или 3 уровня пользователей (админ, "кто имеет право запускать ДГУ" и "кто может только посмотреть") и сохранять все важные действия пользователей в лог. Соответственно авторизация тоже необходима. 2-3 отчета по событиям или параметрам. Конечно же нужно реализовать процесс добавления новых устройств к имеющимся.
Ну вроде бы все описал...при необходимости дополню описание.

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

Уважаемый kot_ по срокам написал все верно. А вот для расчета деньг есть вопросы: сколько человек, зарплата, отсюда налоги, наличие или отсутствие стенда и т.д. если они предполагаются :)

Спасибо за ответ!
Не совсем понимаю как я могу сказать сколько человек, какая зп и прочее не разбираясь в этом?
Я могу максимум указать желаемый для меня срок решения задачи и саму задачу:
Сделать мониторинг, управление, допустим даже без БД: 20 аналоговых параметров, порядка 20 дискретных состояний (есть, нет), отображение всего этого на информативной картинке-мнемосхеме + несколько активных кнопок при нажатии на которых будет задаваться вопрос "вы действительно хотите ....." и при нажатии "Да" отправляется управляющая команда, картинка оперативно отрисовывает изменения параметров. Ну и команды управления хотя бы пишутся в лог.
И еще важный момент, это не для одного устройства, а для нескольких десятков (если все хорошо пойдет), соответственно нужен механизм добавления новых объектов, их настроек (IP, название и пр.).
Это необходимый минимум. Все остальное: авторизация, БД, расширение на другие виды устройств подождет.
Стенд не проблема.

Добрый день !
Я так понимаю, что раз Вы данной темой еще интересуетесь она актуальна...

Теперь по поводу расчета стоимости. Тут все зависит от типа участия в разработке.

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

Вариант 2: Вы поставляете железо и софт. Но софт пишут сторонние разработчики. Сумму выставляют они. А вы либо соглашаетесь либо ищете других. Включение стоимости аналогично Варианту 1.

Вариант 3: Железо поставляет кто-то. Вы пишете софт разово с передачей кода и исходников. Расходы на зарплату, налоги и т.д. + чай, кофе, плюшки и скоротать время до следующего проекта, который подвернется. Как эту сумму будет отбивать заказчик, вам все равно. Вы свое получили.

Вариант 4: Железо поставляет кто-то. Вы пишите софт, развиваете и поддерживаете. Разбиваете сумму на часть разработки. После сдачи ее получаете. Новый договор на поддержку и/или развитие.

Вариант 5: Вы поставляете железо. Но софт продается как опция. Аналогично предыдущим вариантам.

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

Вариант 6: Заказчику надо было их освить. Отделу заработать. Соответственно сошлись на приемлемой для обоих сторон сумме и все.
Заказчик не вырос из 90х. Именно так и делалось, и мной лично в те годы, когда была своя софтверная компашка:)

У Вас какой тип участия ?

Ну или Вариант 7: пишете все в свободное от работы время. Тут на сколько хватит наглости :)

Спасибо что так подробно расписали!
Вариант или 2 или 4, но с тем нюансом что я представитель заказчика =) Прошу прощения что сразу не огласил этот факт.
Точнее, железо стоит на объектах и сейчас возникло желание иметь с них данные по их состоянию и управлять ими.

Я так понимаю идея "Обрушения" из 4 крепкого орешка оставила неизгладимое впечатление :)))

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

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

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