T-FLEX

[Klocska 1]

Согласен с вами, IBV. Только беда в том, что если это будет госпрограмма, то деньги врят-ли дойдут до разработчиков :). Слишком много несчастных голодных чиновников.

Для Nikolas: Microsoft - монополист и все мы на себе это ощущаем. Слава богу, что там хоть кто-то хоть как-то ему противодействует, а то бы нам совсем плохо было.

А с ядрами - вы думаете Parasolid ощущает хоть сколько-нибудь значимое беспокойство от существования ядра у Аскона? Мне кажется, что нет. Слишком вес разный. Это все равно, что ежу сами знаете чем угрожать :).

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

[Nikolas 0]

Ну если Parasolid такой хороший, то почему Аскон не использует его?

ACIS пока еще может конкурировать, а вот асконовское , по вашим словам, - нет.

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

[IBV 112]

2 Klocska

"Только беда в том, что если это будет госпрограмма, то деньги врят-ли дойдут до разработчиков"

Вот, вот... И я про то же. :)

2 Nikolas

"Ну если Parasolid такой хороший, то почему Аскон не использует его?"

Потому, что каждый сам выбирает свой путь. Голиков & Co. выбрали путь по создании своего ядра. Только время покажет были ли они правы. Ведь мы не знаем какими идеями они вдохновлялись принимая такое решение. Вряд ли только финансовыми...

[AlexP 1]

ТопСистемы уже третий год работают с Парасолидом, у них свой параметризатор не хуже, а кое в чем и лучше западных, наработки в 3D параметрическом проектировании большие и догнать их сложно. Аскон в настоящий момент берет хорошими характеристиками в 2D НЕПАРАМЕТРИЧЕСКОМ черчении, и активной (иногда агрессивной) рекламой.  Если Аскон перейдет на Parasolid, то он будет вторым, догоняющим, после T-FlexCAD. Переход в новую нишу, без своих наработок - всегда проблема. Оставаться на 2D движке ACIS нехочется, 3D движок Parasolid уже занят, разрабатывать параметризатор сложно, опять ТопСистемы обогнали лет на 8. Поэтому возникла идея попробовать себя в оригинальном 3D движке. Благо идей ходит полно. Дорого? Но в любом случае система будет мощнее, чем на ACIS. Сохранятся библиотеки, интерфейс, характеристики системы улучшатся за счет 3D графики, моделирования, дальше можно добавить параметризации и т.д.. В результате система вроде как развивается, шансы потерять нишу уменьшаются. А что бы народ не побежал на более мощную систему, можно усилить рекламу - "поддержим первое российское 3D ядро", добавить PR (у других дела настолько плохие, что просятся к нам по дешовке, но не берем), и т.д.  

[Гость sapr2000]

Klocska

---------------

Касательно RR.

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

Диаграмма классов, где четко видны все классы(вместе с атрибутами и методами) и

их взаимосвязи, а также диаграмма сотрудничества или тот же "студенческий" use-case ставят любого программиста на его заслуженное место. Вот тебе класс, вот три его атрибута и три метода. Ты, программист, должен решить очень локальную  проблему - написать реализацию данного класса. Все. Программист не должен думать- зачем этот класс и почему в нем только три метода. Он просто кодировщик. Ему и платят, как простому "попке-кодировщику", те самые 200-250 баксов.

Далее сейчас неочевидное, но часто встречаемое. Уволился программист из конторы. Заглянем в его код. Комментариев нет.  Куча кода. Если ООП, то еще хуже. Надо понять взаимосвязь классов.  Еще в сто раз хуже, если софт исторически писался на процедурном паскале, С или что не удивительно Фортране, а затем встроили эту процедурщину в  реализации ООп, например, при помощи VS C++ или творения Инпрайза. Здесь уже просто гремучая смесь. Где читать логику? В этом хаосе кода, процедур и реализаций классов? Где постановщик? Может он объяснит? Да нет, постановщиком был сам программист. Ну тот, который уволился. Что он оставил в тумбочке? Три затертых до дыр и потерявших актуальность блок-схемы и пара листков прошлогодних

устаревших спецификаций. Знакомо? Думаю, да. Больно? Думаю сильно. От того и платим программисту-постановщику 400-700$ чтобы он не дай бог не ушел из конторы. А зачем?

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

при вашем стиле разработки.

Вы говорите, что RUP не применим к продукции ТОП-ов? Очень может быть и да. Трудно разгребать конюшни. Легче при помощи RUP изменить весь подход в работе софтверной компании при реализации нового проекта. И только потом понять, зачем это сделано и что это дало конторе. Понимаете, я не хочу и не буду с вами спорить по поводу RR. Я то же этого не понимал, до тех пор, пока отсутствие опыта работы в RR стало одной из причин появления кислой мины у работодателя (кстати, руководителя отдела разработки в CAD/CAM фирме) на моем интервью в Канаде в 2000 году. Он сказал, что мы с вами будем разговаривать на разных языках. У нас без RR ни один серъезный проект никто делать не будет.

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

Не используют RR в России. Широко не используют. Почему? Во-первых, из 100 опрошенных программеров, аналитиков или руководителей проектов 99 челов даже названия такого не слышали. А во вторых, кто нас учил правильному методу проектирования программных систем? Какой из Вузов выпускает менеждеров проектов? в третьих, вы сами тут недавно считали, складывали, нули к баксам прикладывали.

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

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

проекта. Понимаем, кто в проекте участвует, что делает каждый актер и система в каждом случае, включая альтернативные и исключительные ситуации. Постепенно переходим к языку классов, проектируем классы, их атрибуты и методы, рисуем взамодействие классов. Затем переходим к описанию бизнес процессов, это по сути описание поведения системы! После чего садимся за компьютер, тупо кодируем на ООП и тестируем той же RR. Даже по прошествии двух лет, для исправления ошибки или введения дополнения я не лезу в код. Мне глубого плевать, что написал уволившийся программист в прошлом году.  Я открываю use-case диаграмму и вижу, что нужна еще одна веточка...далее смотрю в диаграмму классов и вижу- вот он искомый класс, поведение конкретного метода которого я и должен исправить за программста Васю. Открываю его проект в С++, в инспекторе классов нахожу класс и нужный метод. Наследую его, меняю поведение и все. Я ни минуты не копался в исходниках, что бы понять, где ошибка!!! Извините, классов в нашем проекте больше 200 и примерно столько же хранимых процедур на SQL сервере. И разобраться, где ошибка без программиста ее сделавшего очень непросто. Но RR и RUP нам помогает.

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

и как тестеру в автоматизации банковсой деятельности. Как помогает и моим коллегам по этой  работе. Это наш второй(после русского) язык общения, а уж потом С или Паскаль! Удивительно, но даже моя жена стала применять RR при проектировании системы бэкофиса в процессинге платиковых карт. А я умудряюсь описывать и проектировать новые модули при помощи RR в своем проекте САМ-системы(10 млн.строчек кода).

-----

Спросите у Топов сколько у них в разработке сообщений от _ИХ_ тестировщиков - может ответят.

-----

Не понял. Это вы к тому, что у них нет ошибок или наоборот, пруд пруди?

-----

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

--------

Да бог с вами, не держите тестировщиков вообще. Я вам свое мнение не навязываю. Программист, выполняющий попутно обязанности постановщика, тестировщика, документатора,внедренца и документатора такого напишет... Сами догадываетесь. И в какие сроки.

[Гость Gutt]

2Nikolas//

Ведь если подумать то работа всех CADсистем на едином ядре решит многие вопросы передачи данных, заморочек будет меньше

Пардон, но держите карман шире.

Побочный результат "ядерной" конфронтации - "аграмадные" бабки, которые эти ребята гребут именно на "заморочках". Это и встроенные трансляторы "среднего" (минус версия, две) радиуса перевода. Это и группы программ класса Feature recognize. Загляните из чисто спортивного интереса на <noindex>http://www.delcam.com/exchange/exchange.htm</noindex> Вы думаете, что они добровольно откажутся от этой вкуснятины?!

Всё так и останется на уровне болтологии: "STEP вперёд, и два назад" до тех пор, пока конкурентная борьба не <b>вынудит</b> (ну и тд...) Так что пусть будет много ядер разных и хороших!

А пока будем утешаться другой цитатой: "Белые пришли - грабють. Красные пришли - грабють."

С уважением, Павел-II

[Гость sapr2000]

<b>Klocska </b>

---------------

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

Никто не запрещает вам в RUP в некоторый момент сильно продвинуться сначала в реализации кода, т.е. сначала самостоятельно создать классы и сделать их реализацию, а потом методом reverse-engineering внести эти изменения в модель(например, в class diagram:LogicalView). Ровно, как и описывать в use-case уже существующую модель взаимодействия пользователя с CAD/CAM-системой. А на этой основе строить диаграммы взаимодействия или активности. Вы можете документировать ваш проект на любом этапе его жизненного цикла - разработки или

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

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

Далее, еще проектировании. Я хорошо по себе знаю, что проектирование новой функции CAD/CAM-системы, которое ведется методом добавления графической кнопки в меню или очередной формы - это не есть правильно. Неправильно проектировать продукт, сидя за компом в окне транслятора C или Паскаль.  Как правило, такой поспешный и широко применяемый в России стиль проектирования и затем реализации, позволяют реализовать только видимую часть проблемы. Боковые, альтернативные и исключительные ситуации в поведении пользователя

или реакции на них CAD/CAM-системы при таком методе проектирования просто невозможно, негде и нечем охватить. Позже именно эти "клопы" и вылезают потом в проекте, доставляя  мучение пользователям и создают очередной повод для  "свиста" со стороны конкурирующих команд. Более того, такой метод проектирования возвеличивает роль программиста. Ибо он один,без проектировщика, знает суть проблемы и ее реализацию. Автоматически создается ореол славы и недосягаемости такого "ценного кадра". Разделите эти функции и вы увидите, что программист уже не "так крут", а суть проблемы и способы ее решения лежат в разных головах, но сходятся в одной точке - а именно в модели объекта в терминах RR, да и по сути любого CASE-средства. Теперь суть проблемы и ее реализация не в голове программера или на обрывке распечатки кода, она(суть) зафиксирована и общедоступна для других участников проекта. Это позволит обсуждать проблему широким кругом людей, вносить изменения и фиксировать

результат. И еще - не переплачивать программисту и не зависеть от его прихотей.

Ровно, как и проектировщиков.

Теперь о тестировании. Наличие диаграммы use-case, диаграмм swimlanes или activity дают тестеру все данные для тестирования. Он знает - что дается на вход CAD/CAM системы и как она должна реагировать на каждый "чих" пользователя. Применение дополнительных инструментов RR, созданных именно для тестеров, готовые и общедоступные образцы журналов для отражения результатов тестирования(в виде word) дают основу для проведения независимого  глубокого

исследования работы программного продукта, причем любой сложности.

Безусловно, об этом продукте (я имею в виду RR) можно говорить много и долго. Я бы хотел закончить обсуждение этой темы в данном топике(если хотите давайте переместимся в "Флейм").

В конце  концов, топик посвящен системе "ТФЛЕКС" и столь неожиданное перемещение канвы в сторону вопросов тестирования, а затем мой "уход" в сторону Rational Rose обусловлен крайне эмоциональной оценкой качества T-Flex, сделанной HayMayak.  Откуда идет это недовольство пользователя мне сложно сказать и я не берусь быть судьей.

Я хотел лишь подчеркнуть, что забвение общемирового, уже ставшего стандартом CASE-подхода к проектированию, реализации, тестировнию и документированию

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

приобретенных ими как в своих ПТУ для программеров, а также в процессе работы в западных фирмах по H1B контрактам. Кстати, русских программистов работало по этим визам всего 3% от 195.000 человек. Не задумались почему? Не только из-за слабого английского....

[Klocska 1]

Уважаемый Admin.

Прочитал внимательно ваши замечания. Поймите правильно, и Брукса я читал, и Буча. И в аспектах управления коллективом программистов / разработчиков слава богу разбираюсь. И не один я. И про RR достаточно хорошо знаю и пытался им пользоваться (см. выше). И даже, что самое удивительное, моя "жена" тоже некогда с удовольствием пользовалась RR в своих проектах.

Беда в том, что, наколько я понял, Вы работаете в несколько другой области. RR действительно хорошо работает в проектах БД объемом 200-300 классов. Там где задачу можно раскидать на проектировщиков и дешевых кодеров.

В "моих" проектах, пишущихся большими коллективами, классов, по скромным оценкам, больше на порядок, а задачу невозможно раскидать на кодеров, поскольку это приведет к падению эффективности. (Ну не возможно, к примеру,задачу нахождения пересечения поверхностей выполнить силами проектировщика и кодеров. Просто они будут друг другу мешать и на взаимодействие уйдет львиная доля нервов и ресурсов, а отладка вообще превратиться в ад.) Поверьте, у буржуев это тоже так. Кодеры начинаются там, где разрабатывается интерфейс итп. В наукоемких областях работать с кодерами себе дороже. Особенно с дешевыми. А RR "зашивается" на проектах подобной величины. Поверьте, пробовали сами, мы не ретрограды какие-нибудь и руководства читать умеем :). Кстати, моя "жена" - профессиональный проектировщик с высшим образованием (ИУ-7 МГТУ им Баумана), со мной в этом плане вполне согласна :)

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

Простите за оффтопик. Про RR больше в этой конфе писать ничего не буду :).

Про T-Flex. Про ошибки я предлагал спросить в том плане, чтобы, в случае если бы топы ответили, мы могди бы оценить объем работы внутренних тестеров. Точнее людей, которые выполняют и эти функции. Врят-ли, еще раз повторюсь, Флексы тестируют все лишь на простейших моделях. Иначе бы с ними никто дела не имел вообще. А алгоритмы они, порой, реализуют достаточно сложные. Посмотрите последний САПР и Графика. Про версию 7.2. Если вы думаете, что они только к парасолиду "диалоги" пристроили, вы наверняка ошибаетесь.

Еще раз обращаю Ваше внимание, я никого не хочу обидеть. Просто мы работаем чуть-чуть в разных отраслях.

С уважением к Админу и конференции.

[Гость sapr2000]

Klocska Хотя в ваших суждениях много спорного, я все же найду в себе силы не продолжать  диалог o RR и RUP в данном топике. Давайте оставим его для ТФЛЕКС.

А вас приглашаю в раздел Флейм. Там я далл ответы на ваши суждения.

[Klocska 1]

Кстати, на Флексовском форуме обсуждается анонс восьмой версии. Это я к тому, что про wildFire и R9 все говорят вокруг, а про TF8 - нет :(, а там обещают тоже много нового.

[Гость sapr2000]

Klocska

К сожалению,  в вышеозначенном  форуме (в ветке о TF8) ничего путнего не обнаружил. Идет продолжение разборок между разработчиками, пользователями TF и "незарегенными прохожими".

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

Сегодня "гонка вооружений" среди российских САПР-ких команд приводит к появлению сырых, недоведенных версий. Второе. Как известно, апгрейды - это один из механизмов финансовой подпитки контор-разработчиков(любой апгрейд, как правило, платный). Спешный выпуск апгрейдов и их продажа клиентам (как источник для  получения з/п разработчикам САПР) приводят к появлению "сырца" и бесконечной критики, в том числе на TF-форуме, да чего стоит  недавняя перепалка на www.cad.ru. Третье. Сложность российских САПР (а именно объем ПО, объем классов его реализуюших, платформ или ядер  визуализации) превысил некий опасный порог. Любые апгрейды будут кроме новых решений приводить к новым ошибкам. Это, увы, неизбежно. Разработчики САПР должны серъезно подумать о новых технологиях в проектировании продукта, автоматизации тестирования, организации своей работы.

[Klocska 1]

Мы думаем, вы не волнуйтесь. Можно мы с Вами, уважаемый Admin, не будем опять затевать длительный спор с известным результатом?  Все таки нам есть чем заняться кроме. :)

Насколько я знаю, у TF апгрейды бесплатные, также как и обновления версий в пределах первой цифры. То есть человек, купивший 7.0 может получить 7.1, а, в перспективе, 7.2  бесплатно, за 8 уже придется платить.

Конечно, топик в форуме T-Flex опять был обезображен ужасной дракой, которая стала его подлинным украшением (анекдот цитирую :) ), но первые два-три сообщения заслуживают внимания. Речь идет о функциональности, которой раньше в системе не было и которая, с ее появлением, может подвести систему очень близко к пакетам SW и SE. Не для всех задач, конечно, но для многих.

[Klocska 1]

Да, кстати, в некотором роде расширенное подтверждение того, что я писал здесь о разработки ядер можно найти в Июньском номере САПР и ГРАФИКА. На стр. 111 опубликована статья Леонида Баранова "Место и роль геометрического ядра в современной САПР". Почитайте, если кто не успел, мысли там интересные высказаны.

[avargano 0]

Уважаемый Klocska, ближе к началу у Вас проскользнуло, что к ТОп-Системам каким-то боком еще и 50 человек из EDS относятся. Не могли бы Вы это дело прояснить и откомментировать? А то очень уж я любознательный :-)

[GPN 3]

sapr2000

Картинки к "Отправлено: 9:24 - 10 Июля, 2002"

Всё абсолютно верно. Только чем один TF провинился? (Я - лицо незаинтересованное и, надеюсь, морда - достаточно объективная).

Всё то о чём Вы пишите - "мировая практика". Из древнего, лично-наболевшего: ACAD13, которым два года "багали" весь белый свет, а число "апдейтцов" (!) перевалило за десятку. Из совсем недавнего: Симатроновский нерастворимый Еlite (в версии для двоечников).

Что делать...

люди гибнут за металл

Камовских юзеров это не должно удивлять - сами такие. А опыт говорит, что не надо сильно "расстраиваться". Пока АутоДески резвились с 13-ым, создавали трескучие Designer и Autosurf, грозились превратить Desktop в ПиСи-стандарт для механиков и тп., тихо вышли на рынок SW и SE. И сегодня я спрашиваю себя: "А был ли MDT?"

К чему это я?

Вся надежда на нас, родимых. Проголосуем ногами, и ку-ку!

С уважением,

[Klocska 1]

Про 50 человек из EDS я писал в том смысле, что в конторе, разрабатывающей свое ядро, будь то UG, АСКОН или народный герой Шелофаст всегда присутствуют люди, которые занимаються лишь этим самым ядром и в другую работу практически не лезут, поскольку загружены этим самым ядром выше крыши. То есть таким образом, если смотреть количество людей, вовлеченных в разработку, скажем, в Асконе и в Топ-Системах, на лицо неоднородность получается. Поскольку и там и там есть люди, решающие прикладные задачи на базе ядра, но вот в Асконе есть еще люди, это ядро пишущие. То есть, таким образом, для корректного сравнения численности занятых, надо либо у Аскона не учитывать пишущих ядро, что не совсем правильно, поскольку ядра не одинаковые, либо к Топам прибавить 50 человек из EDS, выполняющих работу по ядру. Собственно все, что я имел в виду. Надеюсь, любопытство удовлетворено? ;)

[avargano 0]

Упс, не совсем, насчет ядра я как-то смутно даже догадался, бывают и у меня проблески :-) А забыл спросить вот что - EDS это EDS PLM Solutions или другое какое?

By the way, не переключился на английский и тупо нажимал на клавиши E - D - S, как результат получилось УВЫ   :-)

[Nikolas 0]

Пока АутоДески резвились с 13-ым, создавали трескучие Designer и Autosurf, грозились превратить Desktop в ПиСи-стандарт для механиков и тп., тихо вышли на рынок SW и SE. И сегодня я спрашиваю себя: "А был ли MDT?"

Вы забываете про Inventor. Его AutoDesk выпустила чуть позже SW (годика на 1,5)

[GPN 3]

Nikolas

Вы забываете про Inventor. Его AutoDesk выпустила чуть позже SW (годика на 1,5)

1. Помнится был (?) SW95. А SW97 вышел оччень ничего для своего времени и (!) цены.

2. Inventor "товарно" родился с №3 в 2000.

3. И ваще. Вы "за или "против"? А то я сочиняю филиппику в адрес lexcam на  

<noindex>http://www.sapr2000.ru/cgi-bin....tart=20</noindex> и хочется знать заранее: стрелять ли пушкам обоих бортов?

Склерозом непобедимый

[Klocska 1]

2 avargano

>EDS это EDS PLM Solutions или другое какое

Ну в общем, типа того :)

Там "на ядре" как раз чуть больше 50 человек "сидит".