3. Проблемы разработки сложных программных систем

Большинство программных систем объективно очень сложны. «Сложность программного обеспечения – отнюдь не случайное его свойство», писал Брукс [3], она вызывается четырьмя основными причинами [5]:

• сложностью реальной предметной области, из которой исходит заказ на разработку;

• трудностью управления процессом разработки;

• необходимостью обеспечить достаточную гибкость программы;

• неудовлетворительными способами описания поведения больших дискретных систем.

Сложность реальной предметной области. Индустрия программного и информационного обеспечения непрерывно расширяет области применения ПС в отраслях народного хозяйства, в науке, в быту, функциональные возможности программ постоянно расширяются, расширяется и круг пользователей, растет их влияние на использование программных продуктов. К программам предъявляется множество различных, порой взаимоисключающих требований (часто не формулируемых явно), такие как удобство, производительность, стоимость, выживаемость и надежность. Сложность задачи и порождает ту сложность программного продукта, о которой пишет Брукс [3].

Эта внешняя сложность обычно возникает из-за «нестыковки» между пользователями системы и ее разработчиками: разработчики ПС не являются специалистами в автоматизируемых предметных областях, а специалист предметной области (пользователь, заказчик) не может, как правило, сформулировать проблему в нужном ракурсе. У пользователей и разработчиков разные взгляды на сущность проблемы, и они делают различные выводы о возможных путях ее решения.

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

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

Большая ПС – это крупное капиталовложение, и при изменении внешних требований в системе должны быть предусмотрены возможности для внесения необходимых изменений (см. п.2.2), опыт показывает, что существенный процент затрат на разработку программных систем тратится именно на сопровождение.

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

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

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

Основной способ проектирования системы – когда она разделяется на части так, чтобы одна часть минимально воздействовала на другую. Однако каждое событие, внешнее по отношению к ПС, может перевести систему в новое состояние, и, более того, переход из одного состояния в другое не всегда детерминирован. При неблагоприятных условиях внешнее событие может нарушить текущее состояние системы из-за того, что ее разработчики не смогли предусмотреть все возможные варианты, в дискретных системах любое внешнее событие может повлиять на любую часть внутреннего состояния системы. Это является главной причиной обязательного тестирования наших систем; но дело в том, что всеобъемлющее тестирование таких программ провести невозможно. Пока в распоряжении разработчиков нет ни математических инструментов, ни интеллектуальных возможностей для полного моделирования поведения больших дискретных систем, они должны удовлетвориться разумным уровнем уверенности в их правильности. Универсальный язык моделирования UML (Unified Modeling Language) хотя и решает большую часть проблем и является хорошим средством коммуникации в рамках проекта, но не все.