Форум режимщиков

Куча сумбурных мыслей:1. Если логически развивать идею с Dll в результате можно прийти к такой системе как Анарес (если у меня правильное представление о нем).Встает вопрос. Зачем делать dll для растра?3. О развитии программного обеспечения.Неплохо было бы если ПО режимщиков имело следующую структуру.Модуль отображения результатов расчета УРМодуль отображения результатов расчета динамической устойчивостиМодуль расчета УРМодуль ОцениванияМодуль расчета динамикиМодуль утяжеленияи т.д.Имелось бы четкая спецификация на каждый модуль. Имелись бы описания протоколов обмена между модулями.Любой из модулей может подключаться к любым другим.ПО составлялось бы из модулей, которые могут делать и продавать любые разработчики. СО проверяет модули на соответствие требованиям и сертифицирует модули.Суть в том что Иванов, который занимается динамикой не надо делать расчет УР. Он везьмет его у Нейумина. А графику для УР которую он так и не доделал у другого разработчика и будет спокойно заниматься своим любимым делом - динамикой.Проблемы с переносом и потерей информации отпадают. СО задает спецификацию на программу. Ничего лишнего в модулях реализовывать не надо, т.к. будет невозможно этим воспользоваться. Программа отображения и ввода данных разрабатывается посторонним разработчиком и хотелки в ней отобразить будет невозможно.Если придумали что-то новое например в УР учитывать Р-Q диаграммы, СО выпускает новую спецификацию версии 1.1 и тд. Разработчики клепают модули. сертифицируют. СО выделяет деньги на обновление ПО.Все довольны.

Цитата:

Куча сумбурных мыслей:1. Если логически развивать идею с Dll в результате можно прийти к такой системе как Анарес (если у меня правильное представление о нем).Встает вопрос. Зачем делать dll для растра?

Делать ничего не надо = насколько я помню беседы с ВЛ, внутри Марса его dll  со считалкой и лежит. Думаю Марс-2 ничем отличаться не будет.

Цитата:

3. О развитии программного обеспечения.Неплохо было бы если ПО режимщиков имело следующую структуру.Модуль отображения результатов расчета УРМодуль отображения результатов расчета динамической устойчивостиМодуль расчета УРМодуль ОцениванияМодуль расчета динамикиМодуль утяжеленияи т.д.Имелось бы четкая спецификация на каждый модуль. Имелись бы описания протоколов обмена между модулями.Любой из модулей может подключаться к любым другим.ПО составлялось бы из модулей, которые могут делать и продавать любые разработчики. СО проверяет модули на соответствие требованиям и сертифицирует модули.Суть в том что Иванов, который занимается динамикой не надо делать расчет УР. Он везьмет его у Нейумина. А графику для УР которую он так и не доделал у другого разработчика и будет спокойно заниматься своим любимым делом - динамикой.Проблемы с переносом и потерей информации отпадают. СО задает спецификацию на программу. Ничего лишнего в модулях реализовывать не надо, т.к. будет невозможно этим воспользоваться. Программа отображения и ввода данных разрабатывается посторонним разработчиком и хотелки в ней отобразить будет невозможно.Если придумали что-то новое например в УР учитывать Р-Q диаграммы, СО выпускает новую спецификацию версии 1.1 и тд. Разработчики клепают модули. сертифицируют. СО выделяет деньги на обновление ПО.Все довольны.

Мысли правильные.  Можно развить:- открытая база - считалки без пользовательского интерфейса, работают только с базой- пользовательский интерфейс, работает только с базой (таблицы, деревья, однолинейные схемы  итд)- некий супервизор, который не делает ничего, только управляетПри реализации возникают сложности. Например мы широко используем COM для межпрограммных связей. Кто-то использует только dllКто-то уже добрался до  COA. Наконец вспоминаем CIM/XML и тут же перемещаемся с ветку "Совместимость"

Цитата:

При реализации возникают сложности. Например мы широко используем COM для межпрограммных связей. Кто-то использует только dllКто-то уже добрался до  COA. Наконец вспоминаем CIM/XML и тут же перемещаемся с ветку "Совместимость"

Сложности преодолимые.Самое главное это грамотное построение концепции этой системы. Для этого нужно нанять профессионалов. Не тех которые Марс делали и не тех которые это ТЗ писали, а тех кто уже имеет реальный опыт создания серьезных программных комплексов. Они грамотно вплетут и сом и dll и COA с CIM/XML. Создадут ядро системы. Разработчикам останется толко создать фунциональные модули и привязаться к ядру используя хорошо документированные функции.Вот это будет грамотный подход. Программисты создают систему. Инженеры программируют математику зарабатывают деньги. Дизайнеры делают интерфейс. СО управляет процессом модернизации программного комплекса и платит деньги. Пользователи получают удовольствие от работы в современном программном комплексе с большими возможностями и прекрасным интерфейсом.Все прекрасно разбивается на обозримые этапы и плавно вытекает друг из друга. Каждый этап выполняют соответствующие профессионалы. Ни у кого не больт голова. Все знают за что платят и получают деньги.

Мдя... что-то получается как в анекдоте.Все кроме 11 человек знают как надо играть в футбол.

Цитата:

Куча сумбурных мыслей:1. Если логически развивать идею с Dll в результате можно прийти к такой системе как Анарес (если у меня правильное представление о нем).Встает вопрос. Зачем делать dll для растра?

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

Цитата:

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

Эта идея всем понятна.Есть следующие трудности:1) Нужно описать всё. Написать спецификации, ТЗ и т.д. Почему этого нет: просто нет людей. Виктор Карлович их либо уволил, либо сделал так, что они уволились сами.2) Нужна база данных всего оборудования. Не только режимщикам.Почему этого нет: см. предыдущий ответ.3) Какое предложено комплексное решение: SCADA/EMS от Siemens. Ждёмс!!!!

Цитата:

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

Вопросы:1) Что вы имеет ввиду под СО?2) Может, возьмётесь? Сначала скелет, выложите тут, обсудим, добавим "мяса" и т.д.Если квалификации хватит.Тот, кто обладает квалификацей - желает продавать комплекс + сопровождение.Это дороже и более надёжно в долгосрочной перспективе.Фредерик Брукс так пишет в своей книге "Мифический человеко-месяц"(октябрь 1974 г.): программа (расчётный модуль) - это затраты величиной в  Х, программный комплекс (интерфейсы, интеграция) - это в три раза больше, 3Х, программный продукт (тестирование, документирование, сопровождение) - тоже в три раза больше, 3Х. Если вы хотите иметь программный продукт в виде программного комплекса - умножайте затраты на разработку пробраммы на 9 - это будет первое приближение, так как эти слова относятся к развитому рынку софта. Нынешнее состояние "рынка" ПО для электроэнергетики не может претендовать на звание "развитый". Значит надо брать 15 - что показывает опыт разработки МАРСа, так как ТЗ появилось не от хорошей жизни, просто кончились денег и их надо теперь надо взять в другом кармане...  

Цитата:

Если придумали что-то новое например в УР учитывать Р-Q диаграммы, СО выпускает новую спецификацию версии 1.1 и тд. Разработчики клепают модули. сертифицируют. СО выделяет деньги на обновление ПО.Все довольны.

Конструкция отличная.Мы к ней придём.Но не все, так как долго придётся ждать...

Цитата:

Мдя... что-то получается как в анекдоте.Все кроме 11 человек знают как надо играть в футбол.

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

Цитата:

Самое главное это грамотное построение концепции этой системы. Для этого нужно нанять профессионалов. Не тех которые Марс делали и не тех которые это ТЗ писали, а тех кто уже имеет реальный опыт создания серьезных программных комплексов. Они грамотно вплетут и сом и dll и COA с CIM/XML. Создадут ядро системы. Разработчикам останется толко создать фунциональные модули и привязаться к ядру используя хорошо документированные функции.Вот это будет грамотный подход. Программисты создают систему. Инженеры программируют математику зарабатывают деньги. Дизайнеры делают интерфейс. СО управляет процессом модернизации программного комплекса и платит деньги. Пользователи получают удовольствие от работы в современном программном комплексе с большими возможностями и прекрасным интерфейсом.Все прекрасно разбивается на обозримые этапы и плавно вытекает друг из друга. Каждый этап выполняют соответствующие профессионалы. Ни у кого не больт голова. Все знают за что платят и получают деньги.

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

Чувствуется разговор пошел...  :)От одного риторического вопроса "что делать?" мы плавно подходим к другому "кто виноват?"

Цитата:

Смотрю я на написанное и понимаю: проблемы одинаковые в автомобильной промышленности и в IT. Везде фиговый менеджемент. Все думают только о сиюминутной выгоде и не хотят смотреть вдаль. И так всё в нашем нынешнем государстве...

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

Цитата:

1. Если логически развивать идею с Dll в результате можно прийти к такой системе как Анарес (если у меня правильное представление о нем).Встает вопрос. Зачем делать dll для растра?Лицензии на Растр уже куплены (или почти куплены), народ освоил (есть исключеия)- зачем покупать заново Анарэс всем?Или я не понял вопрос?Прочитал ответ В.Г. - совершенно верно, dll уже готова.Нет интерфейса.

Ну прикрутят dll к растру, а циклическое и иерархическое оценивание как? Останется так как есть?

Цитата:

1) Что вы имеет ввиду под СО?2) Может, возьмётесь? Сначала скелет, выложите тут, обсудим, добавим "мяса" и т.д.Если квалификации хватит.

1) CO - это что то далекое, высокое находится в Москве (СО-ЦДУ).  ;D2) Неее. Я представляю что это такое. И заниматься на общественных началах этим не собираюсь. Есть другие места куда силы приложить. Например есть идея написать каталогизатор файлов режимов для хранения файлов растра мустанга и выявления отличий в расчетных моделях. Сделать его наподобие CVS (средст коллективной разработки). Но это всего лишь одна их хотелок и не факт что она будет реализована.