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

Создание будущего

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

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

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

Как профессиональный разработчик программного обеспечения, я считаю такую позицию безответственной; как человека, живущего в мире, наполненном программным обеспечением, используемым повсеместно, меня такое положение дел пугает, учитывая, что все большая часть моей работы, незаметно для меня, выполняется с помощью программного обеспечения сомнительного качества. В письме ко мне Джералд Котониа писал: «Никто не сомневается в том, что программная инженерия с момента своего возникновения в конце 60-х стала значительно совершеннее. Однако мы до сих пор выпускаем ненадежное и изобилующее ошибками программное обеспечение. Хуже того, наши пользователи не считают ошибочное программное обеспечение чем-то из ряда вон выходящим».

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

В 2000 году я рассказывал о будущем программного обеспечения на Международной конференции по программной инженерии в Лимерике (Ирландия). Алан Кей как-то заметил: «лучший способ предсказать будущее — это создать его», поэтому, чтобы лучше представить себе будущее компьютерной отрасли, я опросил около 700 профессионалов, начиная от лауреатов премии Тьюринга и заканчивая директорами по технологическим вопросам различных компаний. Меня поразило, как часто люди, с которыми я беседовал, затрагивали вопросы самого процесса работы. Дик Файерли, наверное, высказался красноречивее других: «Я вижу, что проявляется некая двойственность или, возможно, осознаю, что эта двойственность стала реальностью. С одной стороны, если говорить прямо, предпринимательство эпохи Internet будет по-прежнему развиваться. С другой стороны, сертификация программных инженеров, в том виде, как оно юридически закреплено в штате Техас и теперь формализуется IEEE Computer Society, также будет укрепляться. Поэтому у нас есть афиняне (предприниматели) и спартанцы (дисциплинированные программные инженеры)».

Это разделение на афинян и спартанцев, возможно, ярче всего проявляется среди так называемых Internet-компаний. Как писал Питер Савьер: «С моей точки зрения, одна из самых сложных задач — представить, как можно примирить качественное программное обеспечение с ограниченными ресурсами и очень динамичными рынками. Другими словами, как небольшие, только что созданные компании могут развиваться сами и развивать свои продукты, учитывая, что компаниям приходится добиваться их внедрения и стремиться к тому, чтобы они были лучшими в своем классе. Для многих таких организаций вполне приемлемые базовые решения — документирование спецификаций, анализ и тестовые планы — приносятся в жертву сиюминутным потребностям, определяемым временем выхода на рынок и другими ограничениями». В результате своих наблюдений Савьер пришел к выводу, что «возможно, нам необходимо смириться с тем, что компетентные молодые компании могут добиться приемлемого качества, при этом по-прежнему руководствуясь в своем развитии спросом на конкретные продукты. Если мы согласимся с этим, мы можем понять, как помочь им постепенно реализовывать решения, позволяющие выпускать качественные продукты, которые требуют сначала значительных накладных расходов, но окупаются с лихвой по мере того, как компания становится все крупнее, по мере развития продуктов компании и по мере использования этих решений для создания многочисленных продуктов и вариантов».

Возможно, что это одна из причин того, почему процессы, которые используются сторонниками свободно распространяемого программного обеспечения и приверженцами экстремального программирования, оказываются столь притягательными. Как заметил Тим О?Рейли: «Свободно распространяемое программное обеспечение важно, в частности, потому, что оно представляет собой первую стадию того, что, в конечном счете, превратится в значительно более широкое движение: разделяемые проекты, выполняемые по Internet специалистами, находящимися в разных географических местах и не связанных между собой организационно».

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

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

Наконец, Том Демарко писал: «Я думаю, что самая устойчивая тенденция в работе — это стремление к «легкой» методологии. К этому классу я отношу Lite Буча, XP Кента Бека, SCRUM, DSDM, Crystal Methods Элистера Кокберна и Adaptive Development Джима Хайсмита. Вероятно, самым заметным из них является экстремальное программирование. Это лучший из нового поколения подходов, которые превосходят CMM и другие формы фундаментализма. Необходимо сосредотачиваться на формировании навыков в людях, а не на регламентации процессов. Большого ума не надо, чтобы понять, что в эту эпоху каждый должен двигаться быстрее. Вы не сможете двигаться быстрее, будучи обременены тяжеловесной методологией; чтобы двигаться быстрее, необходимо стремится к более простой методологии. CMM заставляет нас задумываться над тем, что бы еще добавить. Более простые методологии ставят иной вопрос: «Что мы можем еще убрать?»

Станем ли мы в будущем свидетелями радикальных усовершенствований в процессе программной инженерии? Эл Ахо сомневается в этом (и я горячо поддерживаю его точку зрения): «Поскольку программное обеспечение включает в себя людей, процесс и технологию, мы можем как-то усовершенствовать последние два, но первое остается неизменным. Поэтому я считаю, что нам вряд ли удастся наращивать производительность и качество программного обеспечения теми темпами, которые закон Мура обещает для процессоров, оптики и беспроводных технологий». Что же касается людей, то все руководители проектов, с которыми мне довелось беседовать, жалуются на отсутствие достаточно квалифицированных разработчиков. Как отметил Брайан Рид: «Когда я был еще юношей, в начале 60-х, в мире было не так уж много программистов. Теперь программистом должен быть каждый». В результате случится то, что случилось с телефонными сетями общего пользования: каждый пользователь стал оператором. Таким образом, скорее всего число пользователей-программистов будет расти. Кроме того, как заметил Барри Боэм, «через десять лет в мире будет 100 млн. пользователей-программистов, и 44% их программ по-прежнему будут содержать критически важные ошибки. Нам крайне необходимо создать для пользователей-программистов эквивалент ремней безопасности и воздушных подушек, которые давно изобрели для автолюбителей компании, производящие автомобили».

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

Предсказание будущего — занятие сомнительное: вы можете либо экстраполировать ближайшее будущее, опираясь на происходящие сейчас события (в этом случае крайне трудно ошибиться), либо строить прогнозы, относящиеся к далекой перспективе (в этом случае все, кому доведется ознакомиться с вашими прогнозами в момент их создания, уже умрут, так что никто не выскажет вам своего недовольства, если ваши предсказания окажутся ошибочными). Так что я, возможно, не прав, повторяя прошлое. Комментируя мою презентацию на конференции в Лимерике, Дейв Парнас заметил, что мои заключительные утверждения могли быть сделаны на первых конференциях по программной инженерии, состоявшихся в 1967 и 1970 годах. Он также заметил, что «по прошествии всех этих лет подобные утверждения нам нужны только потому, что слишком много людей предлагают «простые решения» сложных проблем».

Но для решения задачи создания качественного и одновременно сложного программного обеспечения простых решений не существует. Но при этом все будущее программной инженерии связано с поиском таких решений. В частности, мне представляется перспективной деятельность Software Engineering Body of Knowledge (www.swebok.org).

Гради Буч (egb@rational.com) — ведущий научный сотрудник компании Rational Software.

Права принадлежат автору, 2001. Право на перевод с английского языка принадлежит издательству «Открытые системы».

Grady Booch, Developing the Future. Communications of the ACM, March of 2001, vol. 44, no. 3