Разработка подсистем

На этом этапе реализуются те подсистемы, которые были определены на этапе проектирования системы. Для отдельных подсистем этап разработки может потребовать включения различных процессов системотехники. Так, если подсистема является программной системой, этап разработки будет включать процессы формализации требований, проектирования, создания и т.д.

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

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

Сборка системы

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

Процесс последовательной сборки считается более подходящим для системной интеграции по двум причинам.

1. Обычно невозможно составить такой график работ, при котором у всех подсистем этап разработки заканчивается одновременно.

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

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