Кризис программирования и способы выхода из него реферат

Обновлено: 17.05.2024

Кризис парадигмы программирования

Из дискусии на компютерном форуме, затеянной анонимным автором.

18 октября 2005 г.

"Всё нет так ребята, всё не так!". Когда начинаешь анализировать, что же не так, то получается, что, для того, чтобы сделать "как надо" систему исполнения, надо изменить систему программирования, а для этого систему проектирования, а для этого и всего предыдущего - также и ОС. В общем, вроде менять надо всё. То есть, как мне кажется, наступает кризис основ, парадигмы программирования.

Часть 2. Кризис.

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

Это кризис системный, кризис парадигмы.

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

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

- работа программиста за 50 лет практически не изменилась, оставаясь преимущественно ручным трудом. Проблема эта осознавалась давно, было много разных попыток её решить, но ни инструментальные средства (CASE), ни методологии и языки (структурное программирование, ООП, компонентное программирование и т.п.) проблему не решили, в лучшем случае лишь ослабили её. Аналогичная ситуация с проблемой, связанной с данной: проблемой переносимости и повторного использования кода. Поэтому до сих пор программист может надеяться в основном на мощь и объем своего мозга, как ремесленник домашинной эпохи - на свои руки.

- даже член группы разработчиков достаточно большого проекта не знает его детально целиком. Тем более посторонний, скажем, эксплуатирующий программист. А если программ несколько? Да еще ОС, СУБД и пр.? Ни один системный администратор не знает до конца, что делается в подопечных компьютерах. И не имеет практической возможности узнать. Тем более изменить все, что посчитает нужным, и как посчитает нужным. Что говорить о простом пользователе? Как он всему этому может доверять?

Небольшое автобиографическое отступление.

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

Ладно, говорит, нам тут надо кое-что в этой программе поменять, сможешь? Надо посмотреть, отвечаю, но, скорее всего, вряд ли, если она для этого не приспособлена. Он опять: как так - есть программист, есть программа, почему первый не может починить вторую? Я опять про технологию программирования, про исходные и исполняемые коды и т.д.

В общем, не договорились мы тогда (не больно-то и хотелось). Теперь все стали умнее - мы так глупо не отвечаем, они таких глупых вопросов не задают.

Но много позже я подумал: а почему собственно? Почему я не могу сделать всего этого, что хочет от меня пользователь? Может это как раз тот случай, когда устами младенца (то бишь пользователя) глаголет истина?

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

В чем состоит это кризис, каковы его причины?

Сложно достаточно четко и полно ответить на этот вопрос. Но очертить контуры попытаюсь.

Если проанализировать различные признаки этого кризиса, то можно сделать следующие выводы:

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

Она уже подошла к пределу возможностей мозга среднестатистического разработчика.

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

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

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

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

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

- это приводит ко всё возрастающей потребности в программистах. Где-то я читал, что это одна из самых быстрорастущих по численности профессий. Но еще Брукс указывал, что при увеличении числа разработчиков сверх определенного предела управляемость проектом, и, следовательно, качество продукта падает ("мифический человеко-месяц"). Хотя это говорилось о группе разработчиков, но, похоже, это действительно и для всего программистского сообщества. Лет 15 назад Дж. Мартин, если не ошибаюсь, в одной из своих статей уже касался этого вопроса. Тогда он сравнивал ситуацию с разработкой ПО с ситуацией роста телефонизации в начале 20 века. Тогда пресса писала: еще немного, и половина населения сядет за коммутаторы. Но этого не случилось - изобрели АТС. Вот и в сфере разработки ПО что-нибудь изобретут, и не надо будет всем становится программистами - на такой оптимистической ноте он заканчивал статью. Однако "воз и ныне там".

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

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

Каковы пути выхода из кризиса?

Дополнения:

Прочитал про Mozart-Oz. По диагонали, конечно, пунктирно.

Первое впечатление: попытка сделать новый язык-оболочку, "на всё, про всё". Как про него где-то написали: "новый PL/1". Там, конечно, есть интересные детали, но всё базируется на существующей технологии.

Так что погоды он не сделает.

Попутно "открыл для себя" другие интересные вещи.

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

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

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

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

Конечно, всё было написано несколько спонтанно, но, наверно, естественно для большинства людей:

1 - я вижу глобальную проблему;

2 - это я её один вижу, или кто-то ещё?

Если один - надо принять что-нибудь успокоительное: может быть, полегчает;

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

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

Вот и всё.

Вот, например, такая мысль:

Весь жизненный цикл программной системы (включая эксплуатацию) - это процесс создания и последовательной декомпозиции моделей объекта. При этом получается многоуровневая иерархия моделей, где каждый уровень является декомпозицией предидущего. И это при любой технологии, методике. Разница в том, какие уровни, где и в каком виде формируются. Может, только в голове у проектировщика/программиста; может, в виде документа; а может, в каком-либо "электронном" виде.

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

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

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

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

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

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

Таким образом, программа будет содержать все уровни иерархии моделей.

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

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

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

Из комментариев:

1.Цель работы: научиться осуществлять подбор необходимой литературы, вычленять из нее главное, систематизировать имеющийся материал; углубить знания по изучаемой теме.

2.Ход работы:

В среде профессиональных программистов существует понятие перманентного “кризиса программирования”, который проявляется в следующем:

1. Большие проекты выполняются с отставанием от графика.

2. Большие проекты выполняются с превышением сметы расходов.

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

4. Производительность разработанного продукта низка.

5. Качество разработанного продукта не удовлетворяет пользователя.

Основными причинами существования кризиса программирования являются:

Сложность. Одна из проблем определяется природой человеческого интеллекта и состоит в неспособности им обрабатывать сложность. Само понятие “сложность” следует рассматривать в виде двух аспектов:

1. Сложность программ . Данная составляющая является существенным, а не второстепенным свойством. По этой причине при описании программных объектов зачастую применяются приём абстрагирования от их сложности, а то и, вообще, от их сущности.

2. Сложность администрирования . Трудность осуществления надзора за исполнителями влечёт ослабление концептуальной целостности.

Согласованность. Значительная часть сложности относится к решению проблемы согласования различных интерфейсов.

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

Незримость. Реальность программного обеспечения (ПО) не встраивается естественным образом в пространство. У ПО сверхсложное геометрическое представление – как правило, большое количество неориентированных графов, наложенных один на другой.

Разрыв между теорией и практикой во многих областях программирования оказывает существенное влияние на кризис программирования.

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

Невозможность проанализировать и обобщить действия великих программистов за работой . Давно возникло понимание того, что некоторые программисты на порядок, а то и на несколько порядков, более полезны, чем остальные.

Невозможность менеджера правильно сформировать проектную команду .

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

помогите с рефератом. Можно коротко но ясно:) Предмет Технология разработки программного обеспечения.

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

Эпоха становления программирования когда Б. Гейтс, П. Нортон, Вирт и др. работали лично над каждой мелочью и в считанные месяцы в одиночку создавали операционные системы, почти идеальные языки и трансляторы, быстро закончилась. Гении быстро стали миллиардерами и ушли из программирования в руководство и в экспертное дело. А на их место прибежал молодняк. Уже 5-я версия Norton Commander, несмотря на полезные новшества и достоинства, содержала такие вещи, которые шли вразрез с первоначальным стилем и идеями Нортона. Уже проглядывалось, что программисты начав переделку программы, не до конца её изучили. Через 3-4 года эти же люди уже ушли в руководство или собственные проекты, а на их место приходят новые, а программы усложняются и предыдущие версии изучить ещё сложнее. Конечно программа Нортона остановилась в развитии, и только Ghisler вдохновился ею и создал браузер полный, идеальный, безошибочный.
Microsoft аналогично большим коллективом долгие годы с 1995 латал Windows и Office, не умея уже создать систему изначально, завязнув в поддержке старых идей. Но к 2003 г Microsoft сумела всё-таки преодолеть кризис, и создала гениальные версии Windows XP и Оffice 2003, лишь Word страдал мелкими недоделками и плохим Help. Эти версии вершина Microsoft, и когда Microsoft стала падать, все покатились вслед, копируя её прибамбасы. Эпоха 2003 была отмечена заменой синего заголовка программ на цветной градиентный. И это был первый шаг в пустоту мыслей. Вместо работы над алгоритмами многие программисты мира, вслед за Microsoft стали "художественно" переоформлять программы, выдавая из за новые достижения. Сегодня уже с огромным трудом можно на экране найти, какое же окно из десятка открытых является текущим, чтобы именно в нем работать клавиатурой. Безумной затеей явилось создание "Ленты" в интерфейсе, когда исчезло нормальные привычные быстрые на изучение, создание и доступ
кнопки панелей инструментов, обеспечивающих между прочим включение в них собственных кнопок и макросов. Все самые необходимые вещи, которые были сконцентрированы в меню, разбросаны в хаосе ленты, а многое исчезло, и чтобы что-то найти нужно просмотреть весь список команд, который НЕПОЛОН.
Word и Excel просто разрушены в 2007 версии. Если раньше новичок мог самостоятельно разобраться в том, что он видит в меню, сегодня он не сможет этого, потому что не видит, а не видит, не имея под рукой, значит не изучает.
Ещё более трагичным является интернет с его возможностями внедряться как реклама в личную жизнь. Огромные потоки рекламы и порнухи скачиваются по поводу и без повода, и за этот трафик все платят огромные деньги.
Никто против этой системы не протестует, и нравственное падение ускоряется и становится необратимым. Вместо того, чтобы стремиться к профессиональному росту, развивать алгоритмическое и системное мышление, "программисты" создают баннеры, рекламную мишуру, всяческие помехи чтению с экрана. Все попытки "заработать" оборачиваются ограблением. Люди теряют не только
деньги но и жизнь, личное время. Неизвестно ещё, как отразится на генетике непрерывное пребывание всех людей в среде высокочастотных колебаний. Информационный мусор наверняка составляет свыше 95% трафика.
Одним решением можно было бы этот мусор убрать, но никто не готов к этому.
Нравственный кризис захлестывает всех. В результате возникает угроза терроризма, а ответом на неё должно стать глобальное прослушивание и запись всех

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

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

Ключевые слова / keywords:
Мнение
Opinion
Программная инженерия

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

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

Больной скорее жив…

Cамый любимый способ оценки прогресса в разработке аппаратуры — это число вентилей в микропроцессоре (характеристика, понятная производителям и ничего не говорящая пользователям), но почему бы тогда не измерять производительность программистов объемом бинарного кода их приложений? В этом случае программисты в темпах роста точно не уступят конструкторам аппаратуры. То же можно сказать и про измерения прогресса на основе тактовой частоты процессоров, метрик сложности HDL-моделей и т. д. На самом деле технологии разработки и аппаратуры, и программ активно развиваются, но при этом в обеих отраслях революций не происходит, и считать одних лидерами, а других аутсайдерами оснований нет.

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

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

Программный кризис 1.0

На протяжении десятков лет появился целый ряд публикаций, посвященных Программному кризису 1.0. По оценке Пера Флаттена и его коллег, приведенной в докладе от 1989 года, в среднем на осуществление проекта разработки ПО уходило по 18 месяцев. Это консервативная оценка, если учесть, что в 1988 году авторы статьи в Business Week этот показатель назвали равным трем годам, а в 1982-м аналитики указывали, что на программные проекты уходит по пять лет.

Эксперты компании Standish Group в докладе CHAOS Manifesto, выпущенном в 2011 году, сетуют на высокую долю провальных проектов, правда, применяемые ими методологию анализа и выводы подвергали сомнению. Программный кризис 1.0, похоже, уже прошел, и благодаря многочисленным инкрементальным усовершенствованиям процесса разработки ПО ситуация все-таки изменилась к лучшему. Практические перемены в конечном итоге привели к тому, что сегодня ПО, как правило, разрабатывается в пределах бюджета и отвечает техническим требованиям. К сожалению, теперь надвигается кризис 2.0, и, как показано на рисунке, его первопричина — неспособность создания ПО, эффективно использующего колоссальные объемы данных, которые появились за последние 50 лет, а также учитывающего возросшие технические характеристики устройств и требования их пользователей.

А был ли мальчик?

Почему аппаратные технологии развиваются быстро и динамично? Это связано не с созданием новых архитектурных решений, а с совершенствованием технологий — архитектура процессоров остается практически неизменной. Вместе с тем, и с аппаратным обеспечением не всегда все обстояло гладко: провал проекта ЭВМ пятого поколения в 80-х годах; прогнозы скорой кончины CISС-систем и монопольного рассвета RISC и т. п. Эти застойные явления также надо характеризовать как кризис?

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

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

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

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

Приход Больших Данных и детей цифровой эпохи

Количественно оценить объем существующих цифровых данных крайне трудно, однако он, вне всякого сомнения, растет стремительными темпами. В 2005 году Эрик Шмидт, в то время генеральный директор Google, предположил, что объем доступных электронным способом данных составляет 5 млн Тбайт, из которых Google проиндексировала только 0,04%. Шмидт предсказал также, что объем данных будет удваиваться каждые пять лет.

В 2010 году Дейв Эванс, главный евангелист Cisco Systems, высказал оценку, согласно которой к Интернету было подключено 35 млрд устройств — то есть впятеро больше, чем все население Земли. По прогнозам, к 2020 году подключенных устройств будет уже 100 млрд, и тогда получит реальное воплощение концепция Интернета вещей — виртуальной репрезентации уникально идентифицируемых объектов, объединенных в интернетоподобную структуру. Пример проекта в области Интернета вещей — план компании HP по рассредоточению по всему миру триллиона интеллектуальных датчиков, которые станут частью всемирной сетевой инфраструктуры. Такие датчики смогут определять целый ряд показателей, включая движение, вибрацию, свет, температуру, атмосферное давление, влажность, силу ветра и т. д., и получат очевидные применения в отраслях транспортных перевозок, здравоохранения, энергетики и автоматизации зданий.

Исследовательские инициативы

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

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

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

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

Брайан Фитцжеральд ( bf@ul.ie ) — сотрудник Лимерикского университета.

Читайте также: