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

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

"Все аспекты производства ПО". Программная инженерия занимается не только техническими вопросами производства ПО, но и управлением программных проектов, а также разработкой средств, методов и теорий для поддержки процесса производства ПО.

Программные инженеры применяют систематичные и организованные подходы к работе для достижения максимальной эффективности и качества ПО. Общепринято мнение, что неправильно выбранный подход должен отрицательно сказаться на качестве и сроках сдачи системы. Но подход надо выбирать с умом - во многих случаях неформальные, "легкие" процессы могут оказаться значительно эффективнее (например, в таких задачах, как написание web-based applications или e-commerce systems).

Разработка ПО без учета требований программной инженерии может привести к краху всего проекта.

Что такое методы программной инженерии?

Метод программной инженерии - это структурный подход к созданию ПО, нацеленный на создание эффективного продукта наиболее прибыльным (рентабельным, cost-effective) путем.

Тема развивается с 1970х: структурный анализ Тома ДеМарко (1978), JSD Джексона (1983). Эти и другие методы тех времен были ориентированы на идентификацию основных функций системы; функционально-ориентированные методы до сих пор популярны. Как это ни смешно, очень часто их применяют неосознанно.

В 1980х гг. эти методы были дополнены всякой объектностью: Буч (1994), Рамбо (1991). Со временем эти методы были объединены в UML (до хрена книжек начиная с 1997 г).

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

Описание моделей системы и их нотаций (например, объектные модели, конечно-автоматные модели и т.д.)

Правила, накладывающие ограничения на использование моделей в системе (например, "поймают-обругают" в Real)

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

Руководство к действию (наставление, process guidance) - описание действий, которым можно следовать во время создания моделей и последующего их использования (все атрибуты должны быть задокументированы до определения операций, связанных с этим объектом)

Нет идеальных методов, все они применимы только для тех или иных случаев. (Следующая фраза выписана специально для Терехова-ст.) Например, ОО-методы хороши для интерактивных систем, но не для систем с жестким реальным временем.