Вспомнил еще пару вещей.
Если всё же лженаука, то есть ли какие-то "научные" эквиваленты в области программирования - архитектура, проектирование информационных систем и т.д. и как оно называется в целом?
Именно научных эквивалентов нет. ИТ - область довольно новая, большинство людей, кто в ней хорошо работает, обычно не уходит в исследовательскую работу. В России-то точно, может, на западе что-то такое есть, но я сомневаюсь. Пока существующий порядок вещей такой - бери больше, кидай дальше. Времени теоретизировать нет.
Есть методологии разработки. Они есть разные. С достоинствами и недостатками, как обычно. Исторически первой методологией был
водопад, насколько я понимаю. Был еще немного похожий на него RUP, и другие были, но сейчас все эти бизоны 20-го века (почти) вымерли. В моде в основном всякие "гибкие" (Agile, Scrum) и "бережливые" (Lean, kanban) методологии. А так же их произвольные гибриды. Есть еще такая штука, как
PMBoK. Сам не читал, отзывы слышал противоречивые. Ну уж точно не хуже всех этих "системщиков".
Пожалуй, порекомендую еще почитать книгу "Дао Toyota". Это не про ИТ, а про автомобильный завод, но тоже интересно. Грубо говоря, в компании Тойота выработали некий набор правил (тех самых теоретических методик), которые помогают добиваться результатов. Книга рассказывает о том, как эти правила вырабатывались и как они применяются на практике. Методология канбан - это как раз оттуда.
Если говорить о том, чем занимаются в ИТ "системные инженеры" Левенчука, то в миру их обычно называют архитекторами. Это самый близкий аналог. Но на очень больших проектах очень редко есть один человек, отвечающий за всё. А когда есть, он обычно не технарь, потому что "техники" на таком уровне уже не остается. В методологии scrum часть похожей работы берет на себя Product owner - это человек, который "представляет интересы пользователей". Нечто похожее также иногда называется выражением Quality Assurance.
ведь ООП частично основан на системном подходе
С этого места поподробнее хотелось бы услышать. Потому что насколько я знаю, основная идея ООП - из каши "куча кода и куча данных" выделить куски вида "немного данных и методов для из обработки". Чисто техническая вещь для организации кода, придуманная в далеком 1962-м. "Системщики" там и рядом не стояли. А уже потом, к 90-ым, ООП вошло в моду и его объявили (возможно, те самые "системщики") серебряной пулей. А потом оказалось, что пуля-то не серебряная, и маятник начал качаться назад.
Не буду приводить цитаты известных людей, но дело обстоит так, что есть именитые товарищи, которые высказываются резко негативно против ООП. От меня лично это далеко, мне ООП фактически не нужно.
От меня тоже далеко и мне не нужно, но все же, если не секрет, киньте ссылку. Я когда-то давно читал статью
Объектная парадигма провалилась. Сегодня перечитал еще раз... Забавно, хоть автор и прав по-своему, но прошло 16 лет, и что-то поменялось... Для решения части проблем, описанных в статье, появились решения в рамках ООП. (См. Мартин Фаулер, "Рефакторинг. Улучшение существующего кода", Джошуа Кириевски, "Рефакторинг с использованием шаблонов").
Что касается определения системы, то тут надо понимать, что это собирательное понятие. Такие понятия осваиваются через тренинг
Какова ценность фразы "этому мы вас научим на нашем платном тренинге" выше уже объясняли.
Здесь простыми словами о том, зачем нужен системный инженер в дополнение к обычному инженеру и менеджерам.
https://youtube.com/watch?v=XBFVTFeh7P0Ну-ну. Организовано Общероссийским народным фронтом. Одни пустозвоны пришли в гости к другим пустозвонам. Дальше можно не смотреть.
Вот когда этих "системно мыслящих" ребят будут звать на ведущие отраслевые конференции (Highload++, Joker, JBreak, и т. д.) с докладами - тогда и поговорим.
