Проектирование АСУТП

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

А насчет сроков и "непонятного объема работ" - есть срок окончания монтажа, на последних этапах (подписание всяких актов приемки, "прозвонки" земли и пр.) вполне можно попытаться отладить те 10-20 %.

К сожалению, частенько видывал такую картину: монтаж окончен, прибывает наладчик ПО и садится читать мануалы по контроллеру, датчикам, протоколам...

Первоначально опубликовано Kulagin Первоначально опубликовано Владимир Е. Зюбин Про виртуальные объекты автоматизации можно частично почитать на http://reflex-language.narod.ru/articles/articles.htm (приводятся статьи с описанием, как использовать виртуальные объекты при обучении программированию задач автоматизации, и только идея, но все применимо и для разработки). фактически необходимо писать программу проекта, потом писать программу виртуального отладочного комплекса и виртуально отлаживать сначала ошибки виртуального отладочного комплекта, а потом на базе отлаженном виртуальном стенде отлаживать основную программу. По сравнению с отладкой на физических объектах двойная работа и ошибок все одно не избежать.

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

При использовании виртуальных объектов управления мы эти вещи исключаем: 1) с первых недель появляется площадка для отладки программы, программисты работают, 2) Весь текущий проект имеется и у заказчика, что позволяет вовлечь его в процесс разработки, говорить на одном языке, исключить ошибки по п.3, упростить передачу ПО, т.к. заказчик с ним уже знаком 3) На объект мы приезжаем с готовой на 99% программой, минимизация сроков пребывания в командировке и минимизация вероятности получить большую аварию (вспомним, например, С-Ш ГЭС).

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

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

Посмотрите, что Vald пишет: написание софта начинается во время приезда на объект(!). А ведь это очень близко к истине. У нас, практически, так дело и было: очень тяжело сподвигнуть программиста к работе, пока не готово "железо"... и изменить это положение без ВОУ невозможно. У нас не получалось.

Сделать какой-то РЕАЛЬНЫЙ расчет стоимости прогаммирования на основе нормативных документов просто невозможно. Можно сляпать что-то для контролирующих чиновников: сначала исходя из правдоподбия задаться какой-то суммой, а под нее уже подогнать обоснование с умными словами,т.к. существующие методики резиновые.