Я могу ответственно говорить только о той части работ, которую выполняет наша компания. Как уже сообщалось в печати, ЛЕДАСу, c учетом нашей компетенции и опыта, в проекте «3D-ядро» поручен сектор работ, связанных с разработкой особо сложных вычислительных алгоритмов. В их числе, например, задача построения пересечения NURBS-поверхностей и кривых с высокой точностью. Это — одна из ключевых задач геометрического моделирования, и, могу без ложной скромности сказать, что можно по пальцам пересчитать имеющиеся в мире группы, которые способны решить эту задачу в индустриальном стиле и в запланированные сроки.

Среди успешно выполненных компанией ЛЕДАС проектов — интервальный решатель для работы с инженерными знаниями; решатель геометрических и размерных ограничений для параметрического черчения, проектирования сборок, кинематической анимации и прямого моделирования; модули для работы с полигональными сетками в режиме реального времени (преобразование сетки в поверхность подразделения, развертка сетки на плоскость, вычисление минимальных расстояний и определение пересечений сеток); модули трансляции инженерных данных. Интересно, что при работе в проекте РГЯ нам оказались полезными технологические знания, полученные практически во всех перечисленных выше областях. Общий объем выполненных компанией ЛЕДАС проектов по разработке математических программных компонент САПР насчитывает сотни человеко-лет. Кстати, совсем недавно мы привели в относительный порядок данные о наших клиентах и партнерах в разделе сайте ledas.com «Success stories: customers, partners, and friends (1999 — 2012)». К сожалению, некоторые очень крупные или просто престижные заказчики не разрешили нам упоминать проведенные для них работы...

В нашей группе — десять человек. В нее входят как очень опытные разработчики, так и молодые сотрудники. При этом надо учитывать, что попасть на работу в компанию ЛЕДАС совсем не просто: кандидат подвергается по-настоящему серьезным испытаниям, причем, Алексей Ершов такие испытания всегда проводит сам. С другой стороны, мы регулярно привлекаем к конкретным рабочим консультациям любое необходимое количество наших ведущих экспертов.

Сейчас работы идут полным ходом. Мы используем все подходы и процедуры, освоенные нами в многолетних проектах с лидерами мирового рынка. Не буду здесь описывать или напоминать конкретные приемы по-настоящему индустриальной разработки для чрезвычайно требовательного заказчика... Лишь замечу, что самая тщательная проработка алгоритмов и архитектуры программ еще до стадии кодирования, работа с огромной и технологично поддерживаемой тестовой базой, максимальное документирование проекта, эффективное, технологичное и постоянное взаимодействие с заказчиком и т.д. — все это для нас давно стало не внешним требованием, а второй натурой... Случается, что на начальной стадии выполнения работ мы инициативно требуем такой организации проекта от наших заказчиков: бывает, что они даже сопротивляются, но, в конечном счете, всегда высоко оценивают подобную необходимость.

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

На мой взгляд, в России имеется несколько научных и инженерных школ, уходящих корнями еще в советское прошлое, которые вполне могут потягаться с ведущими мировыми R&D центрами. В частности, наличие в России экспертов и специалистов мирового класса в области разработки наукоемких приложений CAD/CAM/CAE очевидным образом подтверждается успехами российских компаний АСКОН, Топ Системы, ЛЕДАС, ТЕСИС и др., в некотором смысле являющихся наследниками соответствующих советских научных центров. Кроме того, в России есть несколько очень сильных университетских центров с подготовкой в области математики и системного программирования на хорошем мировом уровне. Кстати, замечу, что проект с таким уровнем наукоемкости, технологичности и системной полноты как проект РГЯ — это уникальная возможность подготовки кадров самой высокой квалификации: с моей точки зрения, уже одно это делает инвестиции в проект стратегически оправданными для страны, желающей эффективно развиваться в постиндустриальном направлении.

В работе почти всех наших российских коллективов пока еще присутствуют недостатки маркетинговой составляющей, что препятствует должному наращиванию их присутствия на мировом рынке, но сомневаться в научно-технологической компетенции этих групп не приходится: без всякого сомнения, они могут составить конкуренцию мировым поставщикам любых наукоемких решений, в т.ч. — геометрических ядер. Кстати, в возможностях российских разработчиков уже давно не сомневаются крупнейшие зарубежные ИТ-фирмы, постоянно открывающие и расширяющие в России свои R&D подразделения, а также размещающие здесь свои самые ответственные и сложные заказы.

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

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

В науке без (фактически — исчерпывающего) изучения своей темы просто нельзя обойтись. Но там все построено на системе полных публикаций обо всех результатах. Причем, как правило, авторы этих публикаций умеют представить свои результаты, и, в первую очередь, сами заинтересованы в максимальной внятности и полноте публикаций. Ведь в науке, чаще всего, если результат не опубликован, то он и не существует. В области ПО появлению полноценных публикаций препятствуют не только соображения коммерческой конкуренции, но и фактическое отсутствие традиций и умений составления высококачественного описания софтвера. Впрочем, имеются открытые, иногда — классические, научные статьи с описанием фундаментальных основ элементов вычислительной геометрии и релевантных смежных разделов математики. Повторю, что осознание необходимости изучения таких работ и способность их понимания — это обязательный компонент квалификации разработчиков сложных наукоемких проектов.

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

Вообще, что касается сопровождения сложных ответственных продуктов, мой опыт говорит о следующем. Нужно быть большим и важным клиентом, чтобы запрос стал обрабатываться сразу же; хорошо известны обратные случаи, когда небольшие клиенты ждут месяцами и годами ответа на запросы о разработке дополнительного функционала. (Между прочим, несколько лет назад некое серьезное промышленное предприятие обратилось с предложением о контракте к ЛЕДАСу именно потому, что соответствующий вендор не прогнозировал выполнения в обозримом будущем заказа, остро актуального для этого клиента.) Более того, некоторые проблемы, возникающие в работе пользователей со сложной наукоемкой программой (каковой в высшей степени является геометрического ядро), являются отражением глубоких нерешенных проблем вычислительной математики. Для их исправления нередко необходимо разрабатывать новые специфические алгоритмы, что требует существенных временных затрат.

Прежде всего, необходимо понимать, что создание классических ядер (20-25 лет назад) велось параллельно со становлением и начальным развитием — как области геометрического моделирования, так и самой индустрии САПР. Такая параллельность неизбежно приводила к тому, что каждая новая функциональность создаваемого ядра требовала:

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

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

Давайте осознаем, что геометрическое ядро — это хороший пример продукта, относительно которого вообще не вполне корректно говорить о том, что «его разработка будет завершена к такому-то числу или месяцу». Да, можно и необходимо говорить о вводе в эксплуатацию начальной версии, о параллельном функционировании в приложениях нового и старого ядра, об эффективном использовании постепенно вводимых в разнообразные программные обстановки и приложения тех или иных компонентов создаваемой системы. Вместе с тем, геометрическое ядро по своей сути проходит длительный жизненный цикл развития и внедрения с весьма существенной обратной связью со стороны использующих его приложений. Длительный цикл развития ядра на основе такой обратной связи никак нельзя трактовать как устранение недоработок или как обычную отладку: напротив, к программным системам такого уровня сложности должна быть сознательно и в полной мере применима методология и технология управления жизненным циклом программного продукта (Application Lifecycle Management, ALM), по смыслу вполне сопоставимая с PLM.