Современных систем ПО

Индустрия ПО начала зарождаться в середине 50-х годов XIX в., однако почти до конца 60-х ей не уделялось серьезного внимания, поскольку ее доля в компьютерном бизнесе была слишком мала. В 1970 г. годовой оборот всех фирм-разработчиков ПО в США не превышал 1/2 млрд долл. - около 3,7% всего оборота компьютерного бизнеса. Серьезный рост начался в 70-х годах XX в., начиная с принятого фирмой IBM в 1969 г. решения о развязывании цен (раздельном назначении цен на аппаратуру, ПО и услуги), и продолжился до конца декады и появления персонального компьютера. К1979 г. годовой объем продаж фирм-разработчиков ПО в США составлял около $2 млрд. В 80-х годах рост составлял 20% в год и более, таким образом, годовые доходы фирм выросли до $10 млрд. к 1982 г. и $25 млрд. к 1985 г. Сегодня общий объем продаж ПО превышает $100 млрд. Производство ПО сегодня — крупнейшая отрасль мировой экономики, в которой занято около трех миллионов специалистов, называющих себя программистами, разработчиками ПО и т.п. Еще несколько миллионов человек занимают рабочие места, напрямую зависящие от благополучия корпоративных информационных подразделений либо от производителей ПО, таких, как корпорации Microsoft или IBM.

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

Чтобы понять принципиальные отличия сложного ПО от обычной программы, рассмотрим рис. В.1[1].

В левом верхнем углу рисунка находится программа. Она является завершенным продуктом, пригодным для запуска только своим автором и только в той системе, где она была разработана.

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

Рис. В.1. Отличие комплексного программного продукта от программы

Такую программу нужно тщательно протестировать, чтобы быть уверенным в ее надежности. Для этого нужно подготовить достаточное количество конт-

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

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

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

В 1975 г. Фредерик Брукс, проанализировав свой уникальный по тем временам опыт руководства крупнейшим проектом разработки операционной системы OS/360, определил перечень неотъемлемых свойств ПО: сложность, согласованность, изменяемость и незримость.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Современные крупномасштабные проекты программных систем характеризуются, как правило, особенностями, представленными на рис. В. 2.

Характеристики объекта внедрения:

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

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

· информационная сложность (большое количество источников и потребителей информации (министерства и ведомства, местные органы власти, организации-партнеры), разнообразные формы и форматы представления информации, сложная информационная модель объекта — большое количество информационных сущностей и сложные взаимосвязи между ними), сложная технология прохождения документов;

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

Рис. В.2. Особенности современных крупномасштабных проектов программных систем

Технические характеристики проектов создания ПО:

· различная степень унифицированности проектных решений в рамках одного проекта;

· высокая техническая сложность, определяемая наличием совокупности тесно взаимодействующих компонентов (подсистем), имеющих свои локальные задачи и цели функционирования (транзакционных приложений, предъявляющих повышенные требования к надежности, безопасности и производительности, и приложений аналитической обработки (систем поддержки принятия решений), использующих нерегламентированные запросы к данным большого объема);

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

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

· большое количество локальных объектов внедрения, территориально распределенная и неоднородная среда функционирования (СУБД, операционные системы, аппаратные платформы);

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

Организационные характеристики проектов создания ПО:

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

· большое количество участников проекта как со стороны заказчиков (с разнородными требованиями), так и со стороны разработчиков (более 100 человек), разобщенность и разнородность отдельных групп разработчиков по уровню квалификации, сложившимся традициям и опыту использования тех или иных инструментальных средств;

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

· высокие требования со стороны заказчика к уровню технологической зрелости организаций-разработчиков (наличие сертификации в соответствии с международными и отечественными стандартами).