Процесс создания систем

Этапы процесса создания системы показаны на рис. 2.4. Эти этапы оказывают большое влияние на процесс разработки программного обеспечения в соответствии с каскадной моделью, которая описывается в главе 3.

Рис. 2.4. Процесс создания системы

Опишем основные отличия между процессом создания систем и процессом разработки программного обеспечения.

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

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

В команду разработчиков систем неизбежно включаются специалисты разных профилей. Команда разработчиков должна обладать широким кругом знаний, чтобы всесторонне рассмотреть все системные возможности при принятии каких-либо решений. Рассмотрим систему управления полетом (СУП), в которой используется радиолокационная или какая-нибудь другая сенсорная система для определения местонахождения самолетов (см. рис. 2.3). На рис. 2.5 схематично показаны те инженерные дисциплины, которыми должны владеть члены команды разработчиков системы.

Рис. 2.5. Инженерные дисциплины, вовлекаемые в процесс системотехники

Для многих систем существует практически бесконечное количество способов декомпозиции (разбиения) системы на подсистемы. При этом специалисты разных профилей могут предлагать различные варианты структурной модели системы, которые будут содержать разные функциональные компоненты. Тем самым возможен широчайший диапазон альтернативных моделей. Выбор определенной модели не обязательно основывается только на технических аргументах. Пусть, например, одной из альтернатив в разработке СУП является установка новой радиолокационной системы вместо модернизации существующей. Если в команду разработчиков входят строители, то они могут настоять именно на этом варианте создания СУП, так как он обеспечит работой и их, и строительные подразделения, которые они представляют. При этом для обоснования нужного варианта могут, конечно, привлекаться и технические аргументы.

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

Перед специалистами по программному обеспечению часто ставятся задачи, которые необходимо решать без увеличения стоимости аппаратных средств. Поэтому многие так называемые программные ошибки не являются следствием каких-либо "врожденных" черт или свойств ПО. Они могут быть результатом попытки модернизировать программное обеспечение в соответствии с изменениями требований, предъявляемых к создаваемой системе. Хорошим примером такой ошибки может служить сбой в системе управления багажом в аэропорту Денвера [329].