Тот факт, что система ПО является компонентом информационной системы, подразумевает, что программная инженерия – лишь часть более широкой дисциплины – системной инженерии, о чем уже было сказано ранее. Следовательно, инженер ПО должен понимать требования всей системы и должен быть компетентен в ее предметной области, чтобы проектировать интерфейсы, которыми ПО должно снабдить внешние устройства системы. Инженер ПО должен также понимать, что получение некоторых данных или обработку информации лучше реализовать с помощью аппаратных средств ЭВМ, чем с помощью ПО, и что некоторую обработку не нужно автоматизировать вообще.

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

С программными продуктами дело обстоит иначе. ПО нематериально по природе. Классические математические модели применяются к некоторым, но не ко всем аспектам ПО. ПО определено в нечетких терминах – «хороший», «плохой», «приемлемый», «удовлетворяющий требованиям пользователя» и т. д. Подобные качества используются в области обслуживания, где качество связано с нечеткими терминами типа «хорошее обслуживание», «удобство клиента», «компетентность», «знание работы» и т. д. Программная инженерия может заниматься «нечеткими» проблемами, но это не подразумевает, что они должны быть менее строгими или недоказуемыми. Очевидно, что программная инженерия должна использовать различные области математики, типа нечеткой логики или нечетких множеств, обеспечивающие строгость и доказательность.

Программная инженерия не должна быть бедной падчерицей традиционной инженерии. Это совсем другое. Никто в традиционной инженерии не ожидает, что мост, построенный по математическим моделям, разрушится. Точно так же «хорошее» ПО, «удовлетворяющее требованиям пользователя», не должно терпеть неудачу. Однако имеется одно «но» – все это при условии, что тем временем решительно не изменятся требования и ожидания пользователя или внешние обстоятельства.

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

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

Каждая система ПО уникальна, и процесс ее создания уникален. В отличие от традиционных технических дисциплин прикладной программный продукт не производится, он реализуется (превращается в реальность). Эго — не автомобиль или рефрижератор. Программный продукт должен быть реализован, чтобы приспособить его к окружающей среде. Каждый случай системы ПО уникален: либо она построена на пустом месте, либо переделана из имеющегося в наличии коммерческого пакета программ (COTS — commercial off-the-shelf software — коммерческие коробочные программные продукты). Только системное ПО и инструментальные средства ПО, типа операционных систем (ОС) и текстовых процессоров, были когда-то произведены в широком масштабе. Прикладное ПО, реализуется, а не производится.