Если бы автомобиль создавали так же, как компьютер, то «роллс-ройс» сейчас бы стоил 100 долл., мог бы проехать миллион миль на одном галлоне бензина и взрывался бы раз в год, убивая всех, кто находился в тот момент внутри. Мы смотрим в зеркало заднего вида, чтобы видеть, что нас окружает, что происходит в данный момент и что может нас обогнать — точно так же следует оценивать прошлые программные технологии для того, чтобы лучше и быстрее развивать новые направления.

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

Зная, какие программные технологии оказали самое сильное влияние за последние 25 лет, можно оценить их по количеству опубликованных научных статей или выяснить, например, сколько времени продолжалась поднятая вокруг них шумиха. С другой стороны, мы можем судить о них так, как это делает опытный водитель, оценивая, чего, с точки зрения пользователя, удалось добиться по сравнению с тем, что предварительно было обещано. В этой статье я хочу остановиться на том, какие ключевые программные технологии появились за четверть века и получили ли они массовое распространение на соответствующих рынках. Конечно, многие кардинальные изменения в сфере технологий произошли и до 1984 года — IBM OS/360, микропроцессор и многие до сих пор используемые методы программной инженерия были созданы значительно раньше [1,2]. Так в чем же уникальность последних 25 лет?

Во-первых, программное обеспечение перестало быть прерогативой нескольких компаний и стало частью повседневной жизни практически каждого жителя нашей планеты: ПК, Internet и мобильные телефоны — вот свидетельства этой грандиозной эволюции. Во-вторых, теперь принято опираться на эмпирические оценки, а не на мнения. Мери Шоу, описывая ситуацию в 1980-х годах прошлого века, заметила: «Программная инженерия пока еще не стала настоящей дисциплиной, но имеет необходимый потенциал для того, чтобы ею стать» [3]. В то время многие технологии только-только создавались и предлагались вниманию публики, но еще с 80-х годов инженеры анализировали и эмпирически оценивали новинки для того, чтобы судить об их влиянии.

Через зеркало заднего вида

На рис. 1 показаны программные технологии и периоды, когда они достигли важнейших этапов своего развития. Эта таблица построена исходя из структуры, предложенной Сэмом Редвайном и Вильямом Риддлом [1]. Для простоты я различаю только три этапа развития: основы — когда проведены базовые исследования и созданы краеугольные концепции, ограниченное использование — когда эти концепции были взяты на вооружение некоторыми компаниями и пользователями, широкое использование — когда технология стала применяться примерно третьей частью целевого рынка.

С чего начать? Журналы и Internet-ресурсы за последние 25 лет кардинально изменились. До 1980 года для практиков основным источником сведений о программных технологиях был Datamation, а сейчас существует несколько таких источников, например IEEE Software, а также онлайновые ресурсы вроде Slashdot, которые тоже дают представление о последних шагах в эволюции технологий. Поэтому я собрал материал из множества отдельных источников данных, которые нашел в различных обзорах и wiki в программном мире. Для объективности я также обратился к своим коллегам из советов IEEE Software, поинтересовавшись их представлением о технологиях, появившихся за последние 25 лет. На самом деле точно определить время перехода на новый этап просто невозможно. Возьмем, например, объектно-ориентированную разработку, которая активно используется с 1990-х годов, но до сих пор не нашла своего применения в некоторых отраслях.

Итак, на рис. 1 показаны три основные группы программных технологий. Базовые технологии по мере своего развития влияют на массовые тенденции и дисциплины, и они применяются во всех областях и направлениях программной разработки. Большинство из известных нам сейчас таких технологий существуют последние 25 лет. Технологические концепции и методологии объединяют базовые методики, которые используются во многих различных отраслях и продуктах. Консолидированные технологии опираются на концепции и предоставляют готовые технические решения. В тех случаях, когда технологии принадлежат двум таким группам, я относил их к более общей группе.

Основные тенденции

Что имеют в виду, когда говорят, что программная технология «оказывает влияние»? Задавая этот вопрос разным людям, можно получить множество ответов, отражающих точку зрения конкретного собеседника. Профессор будет оценивать репутацию и исследовательские гранты и то, как технология поможет добиться этих целей. Ученый сформулирует свой ответ, учитывая инновационный потенциал. Менеджера производства в первую очередь интересуют рентабельность, воплощение и инновационные продукты. Программный инженер будет иметь в виду полезность и эффективность при решении той проблемы, которой он занимается. Типичный потребитель, скорее всего, будет судить о технологии по тому, насколько ее можно использовать в повседневной жизни и как она помогает выполнять работу, а дети — как не отстать от своих ровесников. Эти две последние потребительские группы — повседневные пользователи программного обеспечения — не только численно превосходят другие, но они также совсем иначе судят о программных технологиях и продуктах. Они обращают внимание на то, насколько незаметным, удобным в использовании и встроенным является программное обеспечение. Другими словами, насколько незаметно, но эффективно оно помогает решить значимую для них задачу.

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

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

Каждая из этих тенденций оказывает серьезное влияние на инженерные продукты и на формирование программной отрасли.

Влияние на продукты и отрасли

Microsoft с Windows или Sun с Java — пример того, как отдельная компания определяет развитие технологии, но технологии от этих производителей добились успеха благодаря тому, что они создавались и широко распространялись в отраслях. Мы не можем даже представить себе Windows без Intel и всей экосистемы поставщиков и провайдеров сервисов. Точно так же банки создали банкоматы и разработали множество связанных с ними программных технологий, таких как распределенная и защищенная обработка транзакций. Компании розничной торговли стимулировали разработку кассовых аппаратов и необходимого программного обеспечения для поддержки цепочки поставки, в том числе штрих-коды и средства радиочастотной идентификации (RFID).

Некоторые технологии прошли очень долгий период развития либо никогда не были полностью разработаны. График их перехода к широкому использованию напоминает синусоиду, что свойственно инновациям, которые переходят от этапа начальных исследований и опытных эксплуатаций к широкому отраслевому применению, а затем все повторяется снова [4, 5]. Это объясняет, почему успешные компании практически в одночасье могут потерпеть крах просто потому, что они своевременно не предложили определенную технологию. Программные менеджеры также часто склонны к стабилизации, а не к росту, — их интересует эффективность, и они недооценивают экспериментирование и инновации. Как заметил один старший вице-президент по инженерии: «Многие годы они получали вознаграждение за то, что делали правильные вещи. Теперь же им может понадобиться определенное время для того, чтобы понять, что у вас есть новый путь и они должны поставить свою карьеру в зависимость от него» [6].

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

Безопасность впервые была признана ключевой технологией в ИТ-инфраструктурах в конце 1980-х годов, когда вирус Jerusalem и червь Morris, по-существу, парализовали Internet-трафик. Инциденты продолжались в 1990-х годах, поскольку технология применялась только как особая мера и без тщательного архитектурного анализа. Сейчас, по прошествии двадцати лет, вместе с новыми ИТ-продуктами наконец стали реализовывать базовые принципы обеспечения безопасности. То же самое повторяется в отрасли телекоммуникаций — как показывают атаки в сфере IP-телефонии, здесь опять пока лишь создаются заплатки на особый случай, но без реального контроля. Промышленная автоматизация и другие предметные области еще больше отстают с внедрением инженерии обеспечения безопасности, как это продемонстрировал червь Slammer.

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

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

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

Оценка и участие

Билл Гейтс в 1981 году говорил, что 640  Кбайт должно хватить каждому, а что произошло на самом деле — известно. Способность компаний быстро оценивать новые технологии, эффективно интегрировать и создавать из них инновационные процессы и продукты — вот залог успеха на будущее. Хороших идей, модных решений и неапробированных технологий более чем достаточно (www.gartner.com/it/products/hc/hc.jsp), но им нужна глубокая и выразительная оценка. Приведем 10 правил, которые помогут оценить и прогнозировать перспективы новых программных технологий.

  • Не поддавайтесь шумихе. Большинство программных технологий никогда ее не вызывают — жизнь слишком коротка, а бюджеты слишком ограничены, чтобы кидаться за всем, о чем вам довелось услышать на конференции или прочитать в статьях.
  • Не влюбляйтесь в свою технологию. Постоянно спрашивайте себя, как можно улучшить ситуацию. Не ограничивайте себя в поиске приемлемых решений. Позволяйте своим клиентам заменять ваши продукты на более новые ваши же технологии. Если у вас их нет, то вместо вас их предложат ваши конкуренты.
  • Сначала подумайте, затем внедряйте новую технологию. Определите конкретные потребности и установите приоритеты, которые должны быть удовлетворены. Определите, кто в этом заинтересован среди руководства, и выработайте общую точку зрения. Держите в курсе этих людей, чтобы избежать внезапных противодействий или отказов.
  • Оцените пользу и установите конкретные, измеримые цели и этапы. Спокойно относитесь к небольшим убыткам при оценке технологий для того, чтобы время от времени добиваться большого выигрыша. Типичные критерии в этом случае — эффективность, денежные потоки и время до получения прибыли. Не все инновации заранее должны иметь точную отдачу от инвестиций, поскольку это убьет творчество. Однако в любой данный момент времени они должны приносить пользу или исчезнуть.
  • Избегайте шумных анонсов технологии. Не рискуйте крупно, рискуйте часто. Предлагайте технологии постепенно и смотрите, как они распространяются на рынке через ваши продукты и сервисы.
  • Отделяйте функциональность (пользу для клиента) от программной технологии. Если вы выделите функцию из своей реализации, то сможете подумать о том, как реализовать ее кардинально иным способом.
  • Обучайте инженеров и менеджеров новым технологиям, не заставляя немедленно использовать продукт. Знание программных технологий имеет «период полураспада» менее двух лет, поэтому вам неизбежно придется интересоваться чем-то еще помимо того, что вы уже знаете.
  • Никогда не рассчитывайте на то, что ваша группа или коллеги обладают именно теми технологиями и навыками, которые вам нужны. Все это уже в прошлом. Набирайте людей со свежими мозгами и перемещайте людей с должности на должность, чтобы они не самоуспокаивались.
  • Подумайте об управлении изменениями. Новые технологии влияют на продукты, процессы и людей. Подготовьте план, описывающий, как будет представлена технология. Имейте запасную стратегию на тот случай, если эти обещания не будут выполнены.
  • Периодически согласовывайте свои портфели продуктов со своими технологическими планами. Определите сроки выпуска новых технологий и синхронизируйте их с потребностями рынка и разработкой продуктов. Имейте смелость отказаться от продуктов и технологий, если они не оправдывают возложенных на них ожиданий.

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

***

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

Литература

  1. S. Redwine and W. Riddle, “Software Technology Maturation,” Proc. 8th Int’l Conf. Software Eng. (ICSE 85), IEEE CS Press, 1985.
  2. B. Boehm, “A View of 20th and 21st Century Software Engineering,” Proc. 28th Int’l Conf. Software Eng. (ICSE 06), ACM Press, 2006.
  3. M. Shaw, “Prospects for an Engineering Discipline of Software,” IEEE Software, vol. 7, no. 6, 1990.
  4. G. Hamel, Leading the Revolution, Harvard Business School Press, 2000.
  5. C. Ebert and R. Dumke, Software Measurement, Springer, 2007.
  6. H. Krasner, “Bottlenecks in the Transfer of Engineering Technology,” Proc. 28th Ann. Hawaii Int’l Conf. Systems Sciences, IEEE CS Press, 1995.

Кристофер Эберт (christof.ebert@vector-consulting.de) — управляющий директор компании Vector Consulting Services.

Christof Ebert, a Brief history of Software technology, IEEE Software, November/December, 2008. IEEE Computer Society, 2008. All rights reserved. Reprinted with permission.

Рис. 1. Развитие программных технологий за последние 25 лет. Цветом показано, как развивалась и постепенно распространялась на рынке конкретная технология

Рис. 2. Безопасность ИТ и этапы развития в разных отраслях. Технологии сталкиваются с различными трудностями и, в зависимости от прикладной области, распространяются разными темпами