Сложность программного обеспечения

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

- системы с обратной связью, которые управляют или сами управляются событиями физического мира и для которых ресурсы времени и памяти ограничены;

- задачи поддержания целостности информации объемом в сотни тысяч записей при параллельном доступе к ней с обновлениями и запросами;

- системы управления и контроля за реальными процессами (например, диспетчеризация воздушного или железнодорожного транспорта);

- среды разработки, которые упрощают создание приложений в конкретных областях;

- программы, которые имитируют определенные стороны человеческого интеллекта.

Существенная черта промышленной программы - уровень сложности: один разработчик практически не в состоянии охватить все аспекты такой системы. Иначе говоря, сложность промышленных программ превышает возможности человеческого интеллекта. Избавиться от этой сложности нельзя, но ее можно преодолеть.

Сложность ПО вызывается четырьмя основными причинами:

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

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

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

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

Первая причина обусловлена следующими факторами:

- Сложность задачи порождает сложность программного продукта. Достаточно трудно понять, даже в общих чертах, как работает электронная система многомоторного самолета или сотовой телефонной коммутаторной система.

- Прибавьте к этому дополнительные требования: удобство, производительность, стоимость, надежность.

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

- Дополнительные сложности возникают в результате изменений требований к программной системе уже в процессе разработки. В основном требования корректируются из-за того, что само осуществление программного проекта часто изменяет проблему.

Вторая причина обусловлена:

- Ростом числа строк программного кода.

- Необходимостью в коллективной разработке.

- Необходимостью в координации и согласовании работ отдельных исполнителей и при этом сохранения целостности основной идеи.

Третья причина - обеспечение гибкости программного продукта.

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

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

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

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

⇐ Предыдущая9101112131415161718Следующая ⇒

Поделиться: