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

Первая статья написана знаменитым Никлаусом Виртом (Niklaus Wirth, ETH Zurich). Статья называется "Хорошие идеи: взгляд из Зазеркалья" "Good Ideas, through the Looking Glass". Как и все известные мне творения Вирта - это блестящая статья, для полного понимания которой требуется глубокая подготовка в области computer science. На сайте CITForum.ru опубликован полный перевод этой статьи, поэтому я не буду останавливаться на ней в этом обзоре.

Следующая статья называется "Десять заповедей формальных методов ... Десять лет спустя". Авторы статьи - Джонотан Боуен и Майкл Хинчи (Jonathan P. Bowen , London South Bank University, Michael G. Hinchey, NASA Software Engineering Laboratory). В статье "Десять заповедей формальных методов" (Computer, Apr. 1995, pp. 56-63, http://www.jpbowen.com/pub/10cs.pdf), опубликованной более десяти лет тому назад, авторы приводили практическое руководство по применению формальных методов в софтверных проектах. Эта статья, основанная на знакомстве авторов с успешными производственными проектами, многократно цитировалась и вызвала большую положительную реакцию. Однако, несмотря на этот очевидный энтузиазм, формальные методы не стали использоваться существенно более интенсивно, и продолжают звучать те же доводы, что и 10 лет назад, о невозможности их применения.

В 1995 г. во время дискуссии, организованной редакцией журнала Computer (Computer, Aug. 1995, pp. 20-32) Бертран Мейер заявил, что для совершенствования программного обеспечения требуются формальные методы. Аналогично, приверженцы формальных методов полагают, что введение большей строгости усовершенствует процесс разработки программного обеспечения и принесет программному обеспечению улучшенную структуру, большие возможности сопровождения, меньшее число ошибок. Но в то время как многие признают существование формальных методов и их продолжающееся применение в инженерии программного обеспечения, сообщество софтверной инженерии в целом остается не убежденным в их полезности.

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

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

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

Обновленный набор включает следующие заповеди:
(1) Выбирай надлежащую нотацию.
(2) Формализуй, но не чрезмерно.
(3) Оценивай затраты.
(4) Имей возможность обратиться к гуру по формальным методам
(5) Не отказывайся от своих традиционных методов разработки.
(6) Документируй в достаточной мере.
(7) Не подвергай риску свои стандарты качества.
(8) Не будь догматиком.
(9) Тестируй, тестируй и снова тестируй.
(10) Используй повторно.

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

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

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

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

Материал "Хроники Pentium: введение" ("The Pentium Chronicles: Introduction") написал Роберт Колвелл (Robert P. Colwell, Intel's chief IA32 architect through the Pentium II, III, and 4). Этот материал является главой из книги Роберта Колвелла "The Pentium Chronicles: The People, Passion, and Politics Behind the Landmark Chips" (Wiley-IEEE Computer Society Press, 2006).

В июне 1990 г. автор поступил на работу в компанию Intel, в новое подразделение Oregon проектирования микропроцессоров в качестве старшего разработчика архитектуры микропроцессоров в новом проекте P6. Это подразделение должно было в конце концов включать тысячи человек, но в тот момент содержало только одного Колвелла. Первый день в компании он провел погруженным в формы, выбирая основного поставщика медицинских услуг (health-care provider) и руководствуясь при этом привлекательностью названий компаний. На второй день в офис Колвелла засунул голову его босс и сказал, что задача Колвелла состоит в том, чтобы повысить производительность чипа P5 в два раза при той же технологии. "Есть ли вопросы?",- спросил он. У Колвелла возникли три вопроса. Что такое P5? Можно ли что-нибудь узнать о планах Intel по развитию технологии? Где здесь туалет?

Оказалось, что P5 - это чип, разрабатываемый проектной группой Intel в Санта-Клара, группой, создавшей очень успешные чипы 386 и 486. P5 стал первым процессором Pentium в 1993 г., но в июне 1990 г. это было не намного большее, чем буква и цифра. Проект P6 должен был следовать за P5 с интервалом в два года. В соответствии с законом Мура, процессор P6 должен был содержать от восьми до десяти миллионов транзисторов и мог стать продуктом в конце 1994 г. Работа Колвелла и группы, которую он должен был помочь собрать, состояла в том, чтобы понять, что делать с этими транзисторами, и сделать это.

Летом 1992 г. Колвелл был назначен менеджером архитектуры и в этом качестве руководил разработками архитектуры линии IA-32 с 1992 по 2000 гг. К некоторому удивлению автора, проект по разработке P6 стал переломным событие в истории компьютерной индустрии и Internet; он смог не отстать от наиболее быстрых производственных чипов, в особенности тех, которые были основаны на архитектуре RISC, и обладал достаточной гибкостью, чтобы его можно было использовать в качестве основы будущих производственных разработок. Проект также обеспечил компании Intel устойчивую позицию на рынке рабочих станций и позволил ей занять нишу на рынке серверов, поскольку в Internet требовались недорогие Web-серверы.

В результате в проект P6 оказалось вовлечено более 400 инженеров. Для доведения процессора до производственного уровня потребовалось 4,5 года. Но эти громадные инвестиции окупились. P6 стал микропроцессором Pentium Pro, затем на его основе были созданы Pentium II и Pentium III, а еще позже образована линия Centrino. От основной разработки отпочковались многочисленные варианты Xeon и Celeron. Коротко говоря, P6 стал наиболее удачным процессором общего назначения из всех, которые когда-либо производились. Были произведены и проданы сотни миллионов таких чипов. Книга автора представляет его собственную оценку этого проекта, а также содержит некоторые отступления в сторону Pentium 4.

Джозеф Роттман (Joseph W. Rottman, University of Missouri-St. Louis) представил статью "Успешный аутсорсинг разработки встроенного программного обеспечения" ("Successfully Outsourcing Embedded Software Development").

По оценке, приведенной в отчете аналитической компании Gartner IT в 2005 г., 50% проектов, которые основываются на офшорном аутсорсинге, заканчиваются провалом. В одном из предыдущих независимых исследований, результаты которого были опубликованы в 2001 г., отмечалось, что удовлетворительные результаты приносят только 33% таких проектов. Тем не менее, консалтинговая компания Meta Group IT предсказывает продолжение возрастания объема офшорного аутсорсинга на 20% в год с достижением объема в 20 миллиардов долларов в 2005 г.

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

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

В исследовании офшорного аутсорсинга Соединенных Штатов участвовали около 30 компаний из США, Канады и Индии, в том числе, одна компания, входящая в Fortune 100 (автор статьи условно называет ее UIC - Universal Industrial Consortium, Всемирная производственная компания), являющаяся производителем производственного оборудования и включающая более 75000 служащих в 20 странах; 13 компаний категории Fortune 500; 2 частных компании; 3 офшорных компании-посредники; 7 юридических компаний, специализирующихся в области контактов офшорного аутсорсинга; и 8 компаний, являющихся офшорными провайдерами.

Несмотря на то, что все 15 компаний из США демонстрируют стратегическую заинтересованость в офшорном аутсорсинге, UIC все еще ощущает последствия своей неудачной первой попытки офшорного аутсорсинга. Деятельность по аутсорсингу в компании UIC управляется ее софтверным центром (Software Center of Excellence, SCE) Six Sigma. С работниками SCE были проведены многочасовые интервью. Кроме того, опрашивались работники индийской компании, являвшейся офшорным партнером UIC. В SCE работает около 150 человек, и ежегодный бюджет на IT-разработки Центра составляет примерно 32 миллиона долларов. Работники SCE разрабатывают и внедряют встроенные программные системы, тесно интегрированные с производством и функционированием основных продуктов UIC.

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

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

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

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

В своей второй попытке компания UIC выбрала три индийских компании, ранее работавших со втроенным программным обеспечением. Эти три компании выполнили работу на 3,4 миллиона долларов, что составляет 10% ежегодного бюджета SCE. В работе участвовали 15 служащих внутри SCE и 35 - вне нее. Объем работ и число работников продолжает возрастать.

Авторами статьи "Программа исследований NASA и инженерия возможностей" ("NASA's Exploration Agenda and Capability Engineering") являются Дэниел Кук, Мэтт Бэрри, Майкл Лоури и Корделл Грин (Daniel E. Cook, Texas Tech University, Matt Barry, Jet Propulsion Laboratory, Michael Lowry, Cordell Green, Kestrel Institute).

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

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

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

Министерство обороны США недавно опубликовало данные, показывающие, что доля функций самолета, поддерживаемых программным обеспечением, возросла с 8% в F-4 в 1960-е гг до 80% в F-22 в 2000 г. Хотя технологии разработки программного обеспечения бортовых систем за последние 45 лет существенно усовершенствовались, остается сомнительным, что скорость развития технологии отвечает возрастающим потребностям и сложности, проистекающим из требований к расширению набора функций программного обеспечения. При использовании текущих возможностей для внесения изменений в программное обеспечение бортовой системы требуются месяцы или даже годы интенсивной дорогостоящей работы.

Это остается в силе даже для специалистов, разрабатывающих и поддерживающих программное обеспечение Международной космической станции (МКС), которые пытаются найти способы уменьшения этих временных и денежных расходов. В аэрокосмических приложениях интенсивно используется прототипирование на основе моделей. В частности, разработчики часто протипируют управляющие приложения к коммерческих средах, таких как Matlab/ Simulink, а затем валидируют их в средах имитационного моделирования. Эти среды прототипирования на основе моделей широко распространены, в частности, потому, что они обеспечивают для аэрокосмических инженеров интуитивный языковой интерфейс. Такой интерфейс часто обеспечивает формат ввода на основе блоков и стрелок, похожий на традиционную нотацию блочных диаграмм, которая используется в инженерной деятельности.

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

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

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

К сожалению, ограничения технологии не позволили автокодированию оправдать эти ожидания. Для разработки интерфейсной части прграммного обеспечения выбранный коммерческий автокодер предоставлял возможности, аналогичные возможностям Matlab, в том числе, интуитивную нотацию для ввода. Однако генерируемый кода обладал рядом недостатков, которые вызывали трудности на этапе сопровождения, по-прежнему требуемого для МКС.
(1) Инженерам оказалось трудно осуществлять навигацию в сгенерированном коде с одного иерархического уровня на другой для нахождения требуемой функции. По причине большой глубины вложенности им было трудно найти в коде даже входные и выходные параметры.
(2) Сопровождение оказалось особенно затруднительным. Время модификации кода через автокодер оказалось в пять раз большим, чем обновление функций, написанных на Ada вручную.
(3) Автокодер производил объемный неоптимизированный код, в три раза длиннее кода, написанного вручную, что является специфической проблемой для космических приложений.

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

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

Наконец, последняя статья номера называется "Слоистая архитектура программного обеспечения для инструментов разработки квантовых компьютеров" ("A Layered Software Architecture for Quantum Computing Design Tools"). Ее авторы - Криста Сво, Альфред Ахо, Эндрю Кросс, Исаак Чуанг и Игорь Марков (Krysta M. Svore, Alfred V. Aho, Columbia University, Andrew W. Cross, Isaac Chuang, Massachusetts Institute of Technology, Igor L. Markov, University of Michigan).

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

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

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

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

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

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