Вследствие возникновения кризисных явлений, причинами которых были рост сложности программных систем, рост важности программного обеспечения как составляющего общего программно-аппаратного решения и уроки зачастую неудачных предыдущих проектов, и явилась программная инженерия. Программная инженерия появилась как ответ кризису. И идея была в том, что некоторые подходы, нельзя сказать, что копируются, но во многом заимствуются или разрабатываются на основе, на концептуальной основе, связанной с инженерией материальных продуктов. Проще говоря, возник вопрос: нельзя ли использовать те же методы, те же подходы, те же принципы разработки программных систем, которые мы используем в крупных нематериальных системах, в крупных и сложных нематериальных системах, таких, как скажем, мосты или крупные архитектурные сооружения. Можно представить себе, что мост представляет собой достаточно большое количество разнообразных фрагментов, которые, вообще говоря, требуют совершенно разных технологий, подходов и специалистов, которые курируют разные предметные области. Это и архитектура, это и гидродинамика, и аэродинамика. Известно, что мосты коллапсируют под воздействием, скажем, ураганного ветра или ветра определенного направления, зачастую. Т. е. это не только воздействие воды. Это может быть воздействие каких-то внешних факторов, как например, недавний случай с турецким судном, которое повредило буйки того моста, который строился через Керченский пролив, и тому подобные вещи. Это, конечно, нагрузка на мост, это резонансные явления при движении известно, скажем, колонны солдат по мосту. Тоже может возникнуть резонанс, и мост может разрушиться и так далее. С другой стороны это большое количество различных видов материалов. Здесь мы применяем технологии сварки, технологии, связанные скажем с железобетонным производством и сборкой конструкций соответствующего вида технологий, связанных с дорожным покрытием, наверное, каких-то коммуникаций. Никто не мешает нам построить, скажем, интернет-связь через мост, пробросить, естественно, электрические каналы, которые дают нам возможность и подсветки, и информационных предупреждений, для, предположим, судов, которые плывут по каналу, который перегораживает или соединяет два берега мост, и так далее. Речь идет о том в итоге, что должны работать большие или сложные команды, которые состоят, возможно, каждая из которых состоит из целого ряда подразделений, из целого ряда подкоманд, и каждая из этих команд координирует на самом деле свою область деятельности. Примерно так же работают и крупномасштабные команды разработки программных систем, в том числе корпоративных. Вот такая аналогия пришла в голову специалистам, которые собрались на исторической конференции НАСО 68-го года в Германии, и представляли разные страны — это, прежде всего, Соединенные Штаты Америки и ряд стран Западной Европы. Вот такой вопрос у них возник: нельзя ли использовать те же самые принципы и методы. Как выяснилось принципы некоторые использовать можно, отдельные методы тоже, но в целом жизненный цикл программных систем существенно отличается от жизненного цикла материальных объектов, особенно в части, касающейся промышленной эксплуатации или сопровождения. И в этой связи возникла та самая научно-техническая дисциплина, которая получила название программной инженерии и которая специально направлена на то, чтобы оптимизировать жизненный цикл программных систем и преодолевать кризисные явления.