Напишу вам как практикующий ОВшник, перепробовавший достаточное количество программ для проектирования своего раздела, мои личные ожидания от идеальной программы для проектирования раздела отопление. Впрочем почти по всем пунктам эти требования можно смело применять не только к разделу отопление, но и почти к любому другому. Этакий сферический конь в вакууме.
а) Управление проектом и настройками проекта. Здесь должно быть все что позволяет пользователю максимально гибко настроить работу с текущим проектом под себя и свои задачи от настроек пользовательских стилей: слои, цвета, шрифты, размерности, базы подключаемые к текущему проекту, критерии расчетов, управление этажами, выбор места строительства с тем чтобы все сопутствующие данные которые будут участвовать в расчетах автоматом подгружались в проект с минимальным пользовательским участием. Ну в общем полная описательная часть, чтобы можно было выжать все из технологии BIM. В идеале в проекте должен сохраняться лог изменений, чтобы можно было проследить историю развития и расчетов, возможно просто сделать эту функцию опциональной, то есть кому надо включает ее, кому не надо просто не пользуется;
б) Расчеты. Без расчетов никуда, без расчетов любая даже самая удобная рисовалка останется лишь рисовалкой и не будет до конца серьезно восприниматься. Для раздела отопление соответственно это будет расчет теплопотерь и гидравлический, причем гидравлический не просто для каких-то отдельных, пусть возможно и наиболее распостраненных случаев, но все возможные расчеты которые бывают в отоплении: однотрубные и двухтрубные вертикальные и горизонтальные системы, теплый пол и обогрев поверхностей, системы лучистого и воздушного отопления, мастер расчета тепловой изоляции;
в) Работа в 1D/2D/3D режимах при том таким образом чтобы переключение между режимами происходило моментально, а не с помощью костылей, когда условному объекту на плане сопоставляется трехмерный аналог. То есть каждый элемент изначально должен содержать в себе несколько представлений: условное упрощенное, реалистичное 3Д, ну и может какое-то промежуточное, хотя в отоплении как правило хватает и двух;
г) Внятный и продуманный формат баз объектов и мастер пополнения этих баз пользователем. Элементы в базах должны обладать возможностью содержать в себе максимальное описание от технических характеристик, которые будут участвовать в расчетах, до вспомогательных данных типа веса элемента, артикула и цены с потенциальным заделом на будущее возможности обновления и синхронизации всех параметров с облачным хранилищем на сервере разработчика. Условно говоря пользователям должна предоставляться возможность всем миром пополнять общую базу и получать регулярные обновления. В качестве защиты от ошибок разумеется должна иметься какая-то модерация на стороне разработчика. Что касается графического изображения элементов, то у пользователя должна быть возможность создания собственных параметрических моделей и собственных условных обозначений, которые будут использоваться в 2Д планах и для генерации аксонометрических схем;
д) Конкретно для раздела отопления должен быть 1 толковый мастер отрисовки трубопроводной сети в 3Д (сами трубопроводы при этом могут чертиться как в 1 линию, так и сразу в трехмерке) и несколько мастеров отрисовки элементов: гребенки, распределительные шкафы, емкости, мастера генерации 3Д элементов. Трубопроводная сеть должна быть взаимосвязанной, то есть при перемещении элементов и участков в доступных степенях свободы сопутствующие подключенные элементы сети должны растягиваться/сжиматься/перемещаться. В мастере трубопроводной сети и мастере элементов оборудования должна иметься возможность быстрой замены одних видов оборудования на другое;
е) Инструмент для создания принципиальных тепловых схем. Хоть это имеет большее отношение к разделу ТМ, тем не менее как правило схемы узлов управления и тепловых узлов всегда содержатся в разделе "отопление";
ж) Инструменты для образмеривания и оформления чертежей должны позволять надписать любой элемент любой информацией, содержащейся в описании объекта. При том это должны быть не только стандартные полки выноски, а по-максимуму настраиваемые информационные блоки: полки, указатели, таблицы, позиционные маркеры и т.п.;
з) Мастер анализа, коллизий и ошибок. То есть после создания проекта хочется иметь возможность не просто получить спецификацию оборудования, но и проводить анализ принятых решений - получать всевозможные удельные показатели, строить диаграммы и графики, генерировать отчеты, но тут основные завязки конечно будут на расчетный модуль. Все расчеты и описание систем должны сохраняться в файле проекта.


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

А нафига оно нужно без расчетов? Просто как рисовалка и считалка спецификации? Оно конечно тоже неплохо, но получается ненамного вперед шагнуло от блоков с атрибутами, а это значит что программу еще пилить и пилить. Хотя конечно если это только начало, то уже неплохо, хотя бы есть от чего плясать.
Разработчикам очень серьезно рекомендую изучить пользовательский опыт и подход, который применяют их зарубежные коллеги из Progman Oy в их программе MagiCAD. Если вы сумеете на первых порах и в ближайшей обозримой перспективе предложить хотя бы частично сопоставимую функциональность и возможности по расширению и допиливанию функциональности пользовательскими силами (я в первую очередь про создание собственных баз оборудования, а также плагинов для тех кто эти плагины будет в силах написать), тогда успех вашему продукту если не гарантирован, то ожидаем с высокой степенью вероятности. Я не предлагаю полностью передрать весь функционал магикада и переложить его на отечественные рельсы, тем более что не уверен что Нанософт обладает для этого достаточными ресурсами, но взять все лучшее из идеологии и концепции этого продукта было бы очень полезно.

need_help, лови
http://rapidshare.com/files/117706137/allplan_ft_17.0__Nekrasov_A.V.djvu

Народ, вы кажется опять дураками прикидываться пытаетесь. О какой материальной ответственности за использование некачественного ПО сейчас идет речь можно поконкретнее определиться? Такое чувство что каждый опять хочет снять ответственность с себя и переложить ее на кого-то другого, в данном случае на гипотетическую рассматриваемую софтовую контору. Как правило весь инженерный софт так или иначе используемый нами делится на расчетный, графический и расчетно-графический. В случае с голым автокад - это чисто графический пакет. И о какой материальной ответственности автодеск может идти речь? Если девочка или мальчик, или тетенька, или дяденька которому поручен выпуск проекта не умеет профессионально пользоваться данным пакетом, вследствие чего чертит медленно и коряво, а еще хуже в рабочее время сидит на одноклассниках.ру или трещит по аське, сорвет срок выпуска проекта, то кому прикажете претензии предъявлять автодеск? В общем с этим кажется все ясно. Теперь о расчетных и расчетно-графических программах тут палка о двух концах - программисты, которые пишут код и расчетное ядро пользуются теми же самыми формулами и физическими законами, которые мы с вами вручную допустим в качестве считалочек-экселек забиваем. Да разумеется программисты тоже люди и могут ошибиться, коэффициенты где-нибудь неправильно поставить, запятую не в том месте, и т.п. и на такой вот случай как вы верно настаиваете, и я с этим согласен, должно быть лицензирование и сертификация расчетного модуля программ, на предмет правильности выдаваемого результата. Хорошо если будет указано по какой матмодели происходит расчет и какие физические законы в него заложены. Соответственно считаем если некий подобный сертификат у продукта есть, то значит программисты реализовали все алгоритмы правильно и программа считает и оперирует той матмоделью, которую в нее заложили, делая это правильно. Едем далее. Попадает такой расчетно-графический продукт в руки не особо вдумчивого пользователя, который не до конца понимает что подразумевают под собой все исходные параметры и условия которые необходимо задать программе для того чтобы она выдала адекватный результат, ну как самый банальный пример возьмём - не додумался пользователь систему единиц с Imperial на Metric переключить, или еще какие-то условия недозадал, либо наоборот задал необдуманно. Как результат - продукт считает, выдает правильный с точки зрения математики результат, но разумеется неправильный с точки зрения жизни. И кто в таком случае несет ответственность? Объект построен, определенные его системы или параметры не работают, либо работают неверно, либо, что не дай бог, несут угрозу для жизни. Ущерб на лицо. Кто виноват? Ответ вроде бы очевиден, и не похоже на то что это производитель софта. Вот и приходим что ответственность нести необходимо, и сертификация необходима, но для разработчика и продавца эта ответственность будет в основном сосредоточена в правильности расчетного математического движка, а все остальное - явно надумано. Я не говорю про явные критические ошибки - если продукт вылетает без объяснения причин каждые 5 минут и не сохраняет при этом результат работы пользователя это ужасно, но неужели это встречается сплошь и рядом, что набило всем оскомину? Как раз нет. Как правило для обкатки и существуюит бета-версии, есть люди бета-тестеры, либо ими являются оф.пользователи, но их предупреждают о возможных ошибках и если они станут работать в такой версии программы, то видимо осознанно из желания участвовать в благородном деле развития софта и помощи разрабам, которая в конечном итоге на этих пользователей и устремлена. Кстати во многих серьезных продуктах сейчас имеется опция отправить сообщение об ошибке разработчику - опять же о качестве продукта заботятся. Я не скажу что финальные релизы того софта который мне приходится пользовать страдают повышенной падучестью. Некритические ошибки встречаются в любом ПО и для этого у нормальных разработчиков на официальном сайте как правило сущетсвет раздел Support > Download с всевозможными заплатками и сервис-паками. И за критические апдейты безопасности, либо производительности ни 1 разработчик не берет денег, т.к. за продукт уже заплачено, а подобные апдейты не несут в себе расширения фукнционала, лишь устраняют ошибки безопасности, совместимости с железом и проч. А вот деньги как раз просят за следующие версии, если хотите за следующее поколение продукта. Это по вашему ненормально? Или товарищи из майкрософт в нагрузку к честно купившим в 90х годах Windows 95-98 должны давать возможность бесплатно пользоваться всеми последующими версиями?
Вот и объясните мне теперь что подразумевается для программных продуктов под словами "производительность, наработка на отказ и т.п."

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

Уважаемые, у меня складывается впечатление что большинство отписавшихся здесь пытаются убедить разработчика MC2007, что воровать - это нормально и воруем(ют) у нас только потому что так делают все и во многом потому что все равно сворованный продукт не соответствует той цене, которую за него просят, а об адекватной техподдержке и говорить нечего.
Но ведь это неправильно! MC2007 прав в том что есть законы и их следует соблюдать, не зависимо от того хорошие ои или плохие. А если уж человек или организация нарушает эти законы, то как говорится сиди и помалкивай в тряпочку. У нас же наоборот будут с пеной у рта пытаться убедить разработчика честно глядя ему в глаза в том что он не прав, что продукт его посредственен и несовершенен и за него просят абсолютно неадекватные деньги, при этом будут исправно продолжать пользоваться этим продуктом.
Я не буду спорить насчет качества многого из продаваемых на рынке инженерного ПО, в том числе и насчет качества сервиса (за который в цивилизованных зарубежных странах где население и бизнес уважает закон также принято платить деньги вполне сопоставимые со стоимостью самого ПО). И вполне понимаю состояние IT-специалистов уровня Luka, у которых есть мешочек с ключами и стеллажи с коробками лицензионного неиспользуемого софта. Но ведь с другой стороны это в какой-то мере и их проблема. Поговорку "без лоха жизнь плоха" все знают и если вам кто-то сможет впарить некачественный осязаемый товар, который уже не будет возможности вернуть, то значит вам с таким же успехом впаривают и подобное ПО. Вопрос кто вам мешает как специалистам IT провести этот самый аутсорсинг (модное словечно какое), пригласить представителя разработчика в свой офис, выжать из него все соки и всю возможную информацию о том что может и чего все таки не может рассматриваемый продукт (грамотно составленный список вопросов многое может прояснить), а еще лучше поставить перед приехавшим представителем ряд типично выполняемых действий которые организация желала бы оптимизировать и выполнять в ином качественном ключе и попросить этого представителя продемонстрировать как это будет выглядеть в жизни. В конце концов если есть сомнения в обоснованности подобных капиталовложений попросить полнофункциональную пробную версию продукта на тот реальный срок, который даст представление (месяца триала зачастую бывает мало, если специалисты сильно загружены и на опробирование нового просто нет времени). Я думаю даже если разработчик откажется предоставить полнофункциональную версию более чем на официальный срок пробного пользования, то можно договориться о некоей форме лизинга на определенный срок. Если всего этого не удается узнать, осуществить, организовать, то выходит что продукт действительно не стоит своих денег, поддержка никакая и нет смысла морочить себе голову с его дальнейшим внедрением. Кстати, насчет организовать посещение вашего офиса представителем разработчика - я вовсе не имею в виду исключительно Москву или Питер. Если потенциальный объем закупаемого софта будет существенным, то отправят в командировку своего представителя хоть на Чукотку не за ваш счет разумеется.

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

P.S. Весьма рад что MC2007 философски отнесся к появлению последней версии MagiCAD в сети и все таки не плюнул на все, а продолжил диалог с людьми на этом и других ресурсах. Я думаю это верное решение.

http://rapidshare.com/files/101318495/ASVIC.rar.html

запаковал все что у меня было в папке с названием ASVIC (3 дистра для разных версий акада и пилюлька от радуги_фб с описаловом)

от себя: zvyagaaa можешь не тратить время на эту прогу. насколько я знаю ты работаешь в магике, а после него любой софт подобного рода будет казаться жутким отстоем и прошлым тысячелетием (речь о MECH-Q).

Совсем забыл - пасс см. подпись у Luka