Без заголовка

Рад узнать, что частности интересны. Я слежу больше за университетами, потому что их проекты проще всего изучить детально: в отличие от коммерческих предприятий, они довольно охотно делятся ноу-хау и теми самыми кишками. Заметна и тенденция к project-based learning, где люди задумываются не просто о "быстрее сделать", но о том, как совершенно разных специалистов научить работать друг с другом для быстрого получения качественного и недорогого результата. Странно, но я не замечаю впрямую ссылок на практики системной инженерии. Наоборот, иногда встречается непонимание разницы между просто system engineering и software system engineering. Не только у нас. К слову о деталях. Посмотрите на досуге сайт проекта E.D.W.A.R.D.. Товарищи довольно аккуратно собирают в одном месте отчеты и публикации по проекту. Насчет средств работы (инструментов - не техник): разбираясь в различных историях и текущих проблемах компаний, я заметил, что проекты иногда упираются в языки вроде Python. Тот же пример с квадрокоптером, облетающим препятствия: когда речь заходит о масштабировании задачи на семейство квадрокоптеров, выполняющих какую-то функцию совместно (к примеру), компания начинает искать средство программирования более высокого уровня абстракции - каузальные исполняемые блок-схемы или акаузальные физические сети. Эта проблема возникает не из-за плохого содержания старых наработок и невнедрения практик, а из-за трудности применения этих самых практик для языков с относительно низким уровнем абстракции, для различных инструментов между различными отделами. В этом случае единство среды разработки и относительно высокий уровень абстракции языков программирования (блок-схемы, акаузальное моделирование) мне видится хорошим решением. Понятно, что это упирается в свои ограничения, но думать о том, как бы обеспечить работу отделов - разработчиков механических железок, алгоритмистов и программистов микроконтроллеров - приходится заметно меньше. То есть, резюмируя, мне думается, это неплохо, когда единая среда разработки частично решает хотя бы проблему обмена информацией между несколькими отделами. И ей можно прощать относительную закрытость. P.S.: ну и, чтобы два раза не вставать - небольшой оффтоп. Мы однажды беседовали об акаузальных средствах моделирования, и вы замечали, что у нас уж очень мало кто знает о Modelica, особенно в конструкторских бюро (в тех, оставшихся со старых времен). Спешу обрадовать: в одном самарском авиастроительном предприятии OpenModelica используется по назначению и приносит хорошие результаты. Конечно, в масштабах отдельных представителей отдела (это ни разу не стандарт предприятия), но всё равно неплохо. А началось всё с записей ваших лекций.