Дисциплине программного обеспечения едва исполнилось 50 лет, но она уже успела пройти через один хорошо известный кризис — «Программный кризис 1.0», который случился в 60-х годах, когда разработка ПО, как правило, занимала дольше времени и обходилась дороже, чем изначально планировалось, а готовые программы работали не так, как требовалось. Тем не менее программное обеспечение остается одной из крупнейших «историй успеха» компьютерной революции, благодаря которой в повседневной жизни людей произошли колоссальные изменения.
Аппаратное обеспечение, в отличие от программного, развивалось в этот же период гигантскими шагами — одновременно со стремительным падением цен на оборудование не менее впечатляющими темпами росла мощность процессоров и расширялся масштаб применения компьютеров. Кроме того, от повсеместных датчиков, приложений и онлайн-сервисов непрерывно сегодня поступают нескончаемые потоки данных.
В дополнение к этим «подталкивающим факторам» возникает еще один весомый «фактор-тягач» в лице детей цифровой эпохи — пользователей, не представляющих себе жизни без ИТ и проявляющих неистощимый аппетит к техническим новинкам. Благодаря достижениям в области аппаратных средств и огромным объемам доступных данных, открываются поистине колоссальные возможности для индивидуумов, предприятий и общества в целом.
К сожалению, разработка программного обеспечения аналогичным уровнем развития похвастаться не может, вследствие чего сейчас происходит то, что можно назвать «Программным кризисом 2.0». Отдельные инициативы по борьбе с этим кризисом — проекты в области анализа Больших Данных, параллельной обработки, новых методов разработки, облачных сервисов и т. д. — не согласованы между собой и вряд ли порознь способны обеспечить необходимый темп развития способов создания программного обеспечения.
Больной скорее жив…
Cовременные программы чудовищно большие, хотя на первых ЭВМ вполне обходились памятью в 4–6 Кбайт и проводили расчеты ядерного оружия с необходимой точностью, а сейчас на это требуются терабайты памяти. Слухи о программном кризисе ходят уже давно, и первый раз об этом у нас еще в середине 70-х годов говорил Юрий Баяковский, но и сегодня я не слышал о том, что «Кризис программирования 1.0» закончился, — наоборот, утверждалось, что проблемы разработки ПО будут с нами всегда, так же как зрение, которое ухудшается с годами и которое надо лечить. Если измерять «здоровье» ПО плотностью ошибок в исходном коде, то приемлемый показатель сегодня — это 2–3 ошибки на тысячу строк (0–1 — отлично, а 10–15 — еще терпимо). Тот факт, что индустрия мирится с такими показателями, это, вероятно, тоже признаки кризиса?
А что такое кризис? Может быть, мы навешиваем ярлыки, не вдумываясь в смысл? В Новом энциклопедическом словаре (М.: Большая Российская энциклопедия, «РИПОЛ классик», 2004) термин «кризис» (от греч. krisis — решение, поворотный пункт, исход) определяется как резкий, крутой перелом в чем-либо, тяжелое переходное состояние либо острое затруднение с чем-либо (сбытом, производством). «Резкого крутого поворота» в программировании не было ни в 70-е годы, ни в последнее десятилетие, и, похоже, не видно реальных предпосылок к такому повороту и в обозримом будущем. Что можно сказать об «остром затруднении» с производством и сбытом? Гиганты программной индустрии и продвижения сервисов устойчиво процветают, сбыт растет, а число пользователей ПО неуклонно увеличивается. Получается, что кризиса в его «энциклопедическом» понимании, скорее, нет.
Cамый любимый способ оценки прогресса в разработке аппаратуры — это число вентилей в микропроцессоре (характеристика, понятная производителям и ничего не говорящая пользователям), но почему бы тогда не измерять производительность программистов объемом бинарного кода их приложений? В этом случае программисты в темпах роста точно не уступят конструкторам аппаратуры. То же можно сказать и про измерения прогресса на основе тактовой частоты процессоров, метрик сложности HDL-моделей и т. д. На самом деле технологии разработки и аппаратуры, и программ активно развиваются, но при этом в обеих отраслях революций не происходит, и считать одних лидерами, а других аутсайдерами оснований нет.
Программные проекты часто выходят за плановые сроки и бюджеты, причем многие программы ложатся на полку, но, с другой стороны, затяжка сроков и превышение бюджетов у программистов — это лишь невинные шалости по сравнению с потерями, которые наблюдаются в проектах «зрелых» отраслей экономики, например в дорожном строительстве.
Идут ли большая производительность и расширенная функциональность приложений в ногу со все увеличивающимися запросами на вычислительные ресурсы? Может быть, и нет, но если слегка переформулировать риторический вопрос Никлауса Вирта «Идет ли развитие технологий программирования в ногу со все увеличивающимися запросами пользователей?», то ответ будет скорее положительным. Действительно, финансовые обороты в софтверной отрасли постоянно наращиваются; размеры систем (возможности технологий, позволяющих справляться со все более сложными системами) растут, и нет сомнений, что суперзадача — «Интернет вещей» — будет решена; число рабочих мест в отрасли увеличивается, а это означает, что уровень технологичности повышается, позволяя не очень квалифицированным программистам создавать огромные системы, работающие с заданными показателями качества.
Прогаммные проекты часто обвиняют в том, что их инициативы не связаны между собой, но, во-первых, список инициатив часто напоминает винегрет из достаточно старых и не получивших серьезного развития идей. Во-вторых, современные инициативы как раз пытаются консолидироваться на основе новых возможностей, которые дает аппаратура.
Главная «страшилка» «Кризиса программирования 2.0» — размер программ растет. Да, а почему бы и нет? Кто готов инвестировать в обуздание этого роста? Сегодня это устраивает и производителей, и пользователей — вкладывать деньги в сокращение размеров программ пока никто не собирается. С другой стороны, а есть ли здесь технически непреодолимые проблемы, способные инициировать кризис 2.0? Как подойти к их решению? Эдсгер Дейкстра предлагал вычитать стоимость перфокарт из зарплаты программистов, а Энтони Хоар говорил: «Дайте мне меньше места, и я буду кодировать мельче». Иначе говоря, программисты уверены, что задача сокращения размеров программ вполне реальна, но где социальный заказ на эту работу?
Суммируя могу сказать, что до очередного кризиса программирования еще далеко, а обсуждаемые в связи с этим проблемы не выглядят устрашающими как для ИТ-специалистов, так и для сообщества потребителей. Насколько продуктивна сама постановка вопроса о кризисе, помогает ли обсуждение кризиса найти новые ориентиры в развитии технологий программирования? Более правильный способ выстраивания стратегии технологического развития — формулировка задач, решение которых будет служить локомотивом развития программирования. В оценке приоритетов и реалистичности решения этих задач нужно опираться на все имеющиеся ресурсы, а потребители ПО внесут свои коррективы и ограничения, определяющие ресурсы на решения задач.
Кроме этого, вероятно, надо бы рассмотреть вопрос о том, как понятие «кризис» трактуется в западных словарях. Например, в Merriam-Webster (An Encyclopedia Britannica Company) приводится еще одно определение: «Кризис — трудная или опасная ситуация, требующая серьезного внимания». В этом контексте с тезисом о надвигающемся «кризисе программирования» можно согласиться — безусловно, развитие программирования и цивилизации в целом, в той мере, в которой она опирается на прогресс в программировании, требует самого серьезного внимания.
Александр Петренко (ispras.ru/~petrenko) — заведующий отделом технологий программирования ИСП РАН (Москва).
Программный кризис 1.0
Термин software появился в 1958 году, а уже через 10 лет начали говорить о кризисе программного обеспечения — это словосочетание впервые прозвучало в 1968 году в докладе Питера Наура и Брайана Рэнделла «Программная инженерия», зачитанном на конференции Научного комитета НАТО.
На протяжении десятков лет появился целый ряд публикаций, посвященных Программному кризису 1.0. По оценке Пера Флаттена и его коллег, приведенной в докладе от 1989 года, в среднем на осуществление проекта разработки ПО уходило по 18 месяцев. Это консервативная оценка, если учесть, что в 1988 году авторы статьи в Business Week этот показатель назвали равным трем годам, а в 1982-м аналитики указывали, что на программные проекты уходит по пять лет.
В 1994 году в отчете об исследовании, проведенном специалистами IBM, утверждалось. что 68% всех программных проектов отстают от графика. Там же приводились сведения о том, что превышение бюджетов проектов разработки достигает 65%. Для обозначения программных систем, выпущенных, но неиспользуемых, даже придумали термин shelfware — «ПО на полку».
Эксперты компании Standish Group в докладе CHAOS Manifesto, выпущенном в 2011 году, сетуют на высокую долю провальных проектов, правда, применяемые ими методологию анализа и выводы подвергали сомнению. Программный кризис 1.0, похоже, уже прошел, и благодаря многочисленным инкрементальным усовершенствованиям процесса разработки ПО ситуация все-таки изменилась к лучшему. Практические перемены в конечном итоге привели к тому, что сегодня ПО, как правило, разрабатывается в пределах бюджета и отвечает техническим требованиям. К сожалению, теперь надвигается кризис 2.0, и, как показано на рисунке, его первопричина — неспособность создания ПО, эффективно использующего колоссальные объемы данных, которые появились за последние 50 лет, а также учитывающего возросшие технические характеристики устройств и требования их пользователей.
А был ли мальчик?
Магия цифр «2.0» неистребима — к чему только не присовокупляли эту комбинацию, а теперь дело дошло и до программирования, в котором время от времени возникали те или иные затруднения: оператор goto, панацеей от которого стало структурное программирование; объектно-ориентированный подход, устранивший проблему конструирования больших программных систем и т. п. Однако можно ли назвать все это кризисными явлениями или речь идет о вполне естественных процессах?
Почему аппаратные технологии развиваются быстро и динамично? Это связано не с созданием новых архитектурных решений, а с совершенствованием технологий — архитектура процессоров остается практически неизменной. Вместе с тем, и с аппаратным обеспечением не всегда все обстояло гладко: провал проекта ЭВМ пятого поколения в 80-х годах; прогнозы скорой кончины CISС-систем и монопольного рассвета RISC и т. п. Эти застойные явления также надо характеризовать как кризис?
Разработка программного обеспечения во многом связана с реализацией требований, определяемых предметной областью, но не всегда эти требования четко определены, что не позволяет точно спланировать весь процесс. В отличие от традиционных индустрий, в программировании часто заняты люди, квалификация которых лежит в широком диапазоне. Решение новых наукоемких задач, к которым можно отнести и обработку Больших Данных, требует опоры на результаты серьезных фундаментальных исследований в разнообразных областях, не связанных непосредственно с программированием. Однако это не означает кризиса программирования в целом.
Существенно и то, насколько разработки в конкретной предметной области привели к созданию предметно-ориентированных инструментальных средств. Положение улучшается, когда та или иная задача предметной области становится массовой, что инициирует разработку различных средств инструментальной поддержки. В этом случае со временем разработка из нечетко определенного процесса превращается в шаблонное конструирование, как это произошло, например, с разработкой сайтов, еще совсем недавно проводившейся индивидуально.
Появление новой аппаратуры не означает мгновенного появления адаптированного под нее программного обеспечения — необходимо время для создания соответствующей инфраструктуры в виде инструментальных средств, повышающих эффективность процесса разработки. Наличие временного разрыва может породить иллюзию кризиса, что особенно ярко видно сегодня в области создания параллельных систем. Программирование для кластерных систем отличается от написания кода для многоядерных процессоров с общей памятью, которое, в свою очередь, имеет мало общего с разработкой программ для графических ускорителей. Необходимо время для того, чтобы системное и инструментальное программное обеспечение адаптировалось к новым архитектурам и появились программисты, знакомые с новыми методами программирования. Вряд ли здесь стоит говорить о кризисе, скорее всего, речь идет о естественном замедлении, связанном с освоением новых знаний, а также о формировании новых инструментальных средств и прикладных моделей.
Процесс развития программирования можно сопоставить с развитием, например, транспорта — от момента появления новых способов перемещения тела человека в пространстве до их эффективной эксплуатации проходят годы и столетия, необходимые для формирования соответствующей инфраструктуры. И в этом нет ничего удивительного, если сравнить размеры, сложность и стоимость вспомогательных систем, поддерживающих безопасную и экономически оправданную эксплуатацию новинок. В этом контексте программирование ничем не отличается от других отраслей.
Александр Легалов (legalov@mail.ru) — профессор кафедры вычислительной техники Сибирского федерального университета (Красноярск).
Приход Больших Данных и детей цифровой эпохи
Огромные достижения в области аппаратного обеспечения за последние полвека хорошо иллюстрирует статистика: если бы вы инвестировали всего один доллар, когда Гордон Мур сделал свое знаменитое пророчество, и если бы окупаемость вашего вклада возрастала аналогично числу транзисторов на кристалле, то сейчас бы ваш капитал превышал квадриллион долларов. Похожие «законы» существуют для емкости систем хранения (закон Крайдера) и пропускной способности сетей (закон Баттера). Всегда, когда развитие оборудования, казалось бы, остановливалось ввиду непреодолимых препятствий (например, из-за фундаментальных ограничений, налагаемых законами физики), появлялись новые разработки, которые позволяли преодолеть эти препятствия.
Количественно оценить объем существующих цифровых данных крайне трудно, однако он, вне всякого сомнения, растет стремительными темпами. В 2005 году Эрик Шмидт, в то время генеральный директор Google, предположил, что объем доступных электронным способом данных составляет 5 млн Тбайт, из которых Google проиндексировала только 0,04%. Шмидт предсказал также, что объем данных будет удваиваться каждые пять лет.
В 2010 году Дейв Эванс, главный евангелист Cisco Systems, высказал оценку, согласно которой к Интернету было подключено 35 млрд устройств — то есть впятеро больше, чем все население Земли. По прогнозам, к 2020 году подключенных устройств будет уже 100 млрд, и тогда получит реальное воплощение концепция Интернета вещей — виртуальной репрезентации уникально идентифицируемых объектов, объединенных в интернетоподобную структуру. Пример проекта в области Интернета вещей — план компании HP по рассредоточению по всему миру триллиона интеллектуальных датчиков, которые станут частью всемирной сетевой инфраструктуры. Такие датчики смогут определять целый ряд показателей, включая движение, вибрацию, свет, температуру, атмосферное давление, влажность, силу ветра и т. д., и получат очевидные применения в отраслях транспортных перевозок, здравоохранения, энергетики и автоматизации зданий.
Усман Хак в рамках проекта Pachube предложил расширить концепцию Интернета вещей путем создания «экосистемы сред» — сервиса, который позволит потребителям всего мира делиться поступающими в реальном времени показаниями всевозможных датчиков, фиксированных и размещенных на предметах. Важность роли, которую играют дети цифровой эпохи, видна на примере успеха инноваций, реализуемых по инициативе пользователей и крупномасштабных краудсорсинговых проектов по решению сложных исследовательских задач для NASA и других организаций. К двадцати годам «сетевой стаж» детей цифровой эпохи уже достигает 20 тыс. часов, но они не только не протестуют против информационной перегрузки, но и приветствуют ее, отмечается в статье Digital Natives and Ubiquitous Information Systems. Дети цифровой эпохи не просто не сопротивляются технологиям, они проявляют ненасытную тягу к техническим новшествам. К 2012 году число действующих контрактов на мобильную связь достигло почти 6 млрд. Конечно, они распределены по миру неравномерно, но это уже почти 90% населения земного шара.
Исследовательские инициативы
Попытки преодоления кризиса программирования 2.0 предпринимаются в рамках различных исследовательских инициатив. Ранние проекты в области CASE-средств были нацелены на автоматизацию разработки ПО, но им не удалось решить данную задачу. Аналогично, инициативы в области программных архитектур, шаблонов, многократного использования и т. п. были направлены на совершенствование ранее разработанных подходов. Исследователи также предложили модель зрелости возможностей создания ПО и другие концепции, например инженерию методов.
Ряд инициатив рассчитан на поддержку аппаратных достижений в сфере многоядерной обработки и параллельных вычислений. В последнее время начались исследования по тематике автономных вычислений, направленные на создание адаптируемых систем, способных автоматически эволюционировать. Этим исследованиям предшествовали проекты в области искусственного интеллекта, например связанные с генетическими алгоритмами. Попытки решения проблемы Больших Данных предпринимались в рамках проектов в области Semantic Web и онтологий.
|
Долой «жирные» программы
Идут ли большая производительность и расширенная функциональность приложений в ногу со все увеличивающимися запросами на вычислительные ресурсы? Нет. Никлаус Вирт |
Учитывая колоссально возросшие сегодня мощности аппаратного обеспечения и объемы данных, даже удивительно, что до сих пор так и не найдено «волшебное средство», которое бы обеспечило хотя бы умеренное — всего на порядок — повышение продуктивности разработки ПО. Трудно вообразить, в каком мире мы бы жили, если бы разработка ПО эволюционировала такими же темпами, как оборудование и данные. Но темпы эволюции в области ПО и оборудования хорошо описаны законом Вирта 1995 года: «Программы становятся более медленными быстрее, чем растет быстродействие оборудования».
***
Казалось бы, наступила эпоха, когда по идее уже не должно быть никаких ограничений, мешающих воспользоваться достижениями последних 50 лет для решения трудноразрешимых проблем здравоохранения, энергетики, управления климатом и т. п. Но, к сожалению, это не так. И первый шаг к решению любой проблемы — это признать ее наличие. Более сложными будут последующие шаги, начиная с разработки программы действий, направленных на решение проблемы.
Брайан Фитцжеральд ( bf@ul.ie ) — сотрудник Лимерикского университета.
Brian Fitzgerald, Software Crisis 2.0, IEEE Computer, April 2012, IEEE Computer Society. All rights reserved. Reprinted with permission.
