Темой мартовского номера журнала Computer является инженерия программного обеспечения, вернее, проблемы, с которыми специалистам в этой области придется столкнуться в XXI веке. Этой теме посвящены три большие статьи номера.

Автор первой статьи тематической подборки – Барри Боем (Barry Boehm, University of Southern California). Статья называется «Изменения к лучшему в век программного обеспечения» («Making a Difference in the Software Century»). Она основана на материалах других статей Боема, опубликованных в книге «Software Engineering: Barry W. Boehm’s Lifetime Contributions to Software Development, Management, and Research» (IEEE CS Press-John Wiley & Sons., 2007), и доступна на странице Боема на сайте университета Южной Калифорнии.

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

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

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

Имеется масса противоречий между людьми и организациями, быстро приспосабливающимися к изменениям, и теми, кто предпочитает не делать этого. Хорошим современным примером являются затруднения разработчиков программного обеспечения, пытающихся приспосабливаться к изменениям при соблюдении фиксированной структуры спецификационного контракта на разработку программного обеспечения. Такого рода контракты определяются администраторами, придерживающимися принципа THWADI (That’s How We’ve Always Done It – «мы всегда так делаем»). В коммерческом мире разрабатываются более совершенные структуры контрактов, основанные, например, на модели «общей участи» («shared destiny»). Применение усовершенствованных и общепринятых видов контрактов будет способствовать успешной разработке программного обеспечения при наличии частых изменений.

Многие источники изменений являются относительно непредсказуемыми, например, те, которые связаны с возникновением новых технологий. Часто, когда пользователей просят заранее специфицировать желательный для них способ взаимодействия с новым приложением, они отвечают «IKIWISI» (I’ll Know It When I See It, «это будет понятно, когда мы его увидим»). В таких случаях использование последовательной каскадной модели, в которой сначала специфицируются все требования, скорее всего, приведет к созданию неповоротливой системы, требующей большого объема работ для внесения изменений.

Для сокращения объема неопределенности лучше всего использовать стратегию BITAR (Buy Information To Avoid Risk, «чтобы избежать риска, покупайте информацию»). Эта стратегия предполагает расходование дополнительных средств на прототипирование, имитационное моделирование, эталонное тестирование, анализ тенденций рынка и т.д. для сокращения уровня неопределенности и рисков. Кроме того, важно организовывать будущие проекты таким образом, чтобы оставалась возможность приспособиться к появлению новых источников непредвиденных изменений. Это предполагает наличие способности к быстрым изменениям в коллективе разработчиков, в их организации, в архитектуре программного продукта и процессе его разработки.

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

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

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

«Безразмерное» (one-size-uniformly-fits-all, OSUFA) определение функциональной надежности в терминах времени безотказной работы систем часто устраивает не все заинтересованные стороны. Заключение о непригодности подхода OSUFA становится еще более явным при наличии тенденции к глобализации, охватывающей разные культуры. Например, из-за различий в культуре страны только 17 из 380 софтверных компаний Таиланда решилось использовать разработанную в США модель CMM.

Подход OSUFA и стандартизация процессов разработки особенно плохо соответствуют еще одной тенденции XXI века – появлению крупных, преимущественно программных систем, строящихся из существующих систем (software-intensive systems of systems, SISOS). Эта тенденция означает наличие требования масштабирования при решении проблемы одновременного обеспечения возможности быстрых изменений и функциональной надежности. Некоторые альтернативы подходу OSUFA предлагаются в статье Барри Боема, опубликованной в этом же сборнике и также доступной на сайте университета Южной Калифорнии.

Статью «Определение влияния на практику исследований в области инженерии программного обеспечения» («Determining the Impact of Software Engineering Research on Practice») представили Леон Остервейл, Карло Гецци, Джеф Креймер и Александер Волф (Leon J. Osterweil, University of Massachusetts, Amherst, Carlo Ghezzi, Politecnico di Milano, Jeff Kramer , Alexander L. Wolf, Imperial College London).

Инженерия программного обеспечения стала активной исследовательской областью в 1968 г., когда на знаменательной конференции NATO, проходившей в Гармише (Garmisch), Германия, участники обосновали научную и практическую важность этой дисциплины. С 1975 г. стали регулярно проводиться Международные конференции по инженерии программного обеспечения (International Conference on Software Engineering), на которые в последние годы поступает более 400 заявок на доклады, и которые собирают более 1000 участников, а с 1982 г. еще и Международные симпозиумы ACM SIGSOFT по основам инженерии программного обеспечения (ACM SIGSOFT International Symposium on the Foundations of Software Engineering). Исследователи считают эти конференции лучшими в области инженерии программного обеспечения. Технические мероприятия, посвященные программной инженерии, регулярно проходят в Европе, Азии, Индии, Южной Америке, странах Тихоокеанского бассейна и многих других регионах. Проводятся бесчисленные более мелкие мероприятия, часто посвящаемые специальным направлениям программной инженерии.

Наряду с трудами конференций, распространению результатов исследований способствуют журнальные публикации. К числу ведущих журналов, специализирующихся на тематике программной инженерии, относятся ACM Transactions on Software Engineering and Methodology и IEEE Transactions on Software Engineering. Последний из этих журналов издается с 1975 г. Программной инженерии посвящаются и многочисленные другие периодические издания.

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

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

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

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

Последняя статья тематической подборки представлена Лорином Хохштейном и Виктором Базили (Lorin Hochstein, University of Nebraska-Lincoln, Victor R. Basili, University of Maryland) и называется «Проекты ASC-Alliance: пример крупномасштабной разработки параллельного научного кода» («The ASC-Alliance Projects: A Case Study of Large-Scale Parallel Scientific Code Development»).

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

Чтобы больше узнать о разработке программного обеспечения для HEC-систем, авторы исследовали пять софтверных проектов, в которых разрабатывались такие компьютерные программы, называемые в сообществе HEC кодами. Эти проекты выполнялись в пяти исследовательских центрах Альянса по развитому моделированию и вычислениям (Advanced Simulation and Computing-Alliance, ASC-Alliance). В каждом из этих проектов решалась отдельная проблема вычислительных наук, и у каждого центра имелся доступ к крупномасштабным системам в различных суперкомпьютерных центрах.

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

Вне тематической подборки в журнале также опубликованы три большие статьи. Авторами статьи «Модель процесса разработки, ориентированная на содержательный материал» («A Content-Centric Development Process Model») являются Пабло Морено-Гер, Иван Мартинез-Ортиз, Хосе Луис Сиерра и Балтазар Фернандез-Маньон (Pablo Moreno-Ger, Iván Martínez-Ortiz, José Luis Sierra, Baltasar Fernández-Manjón, Complutense University of Madrid).

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

Однако обучать во время развлечений нелегко. Нельзя просто встроить в игру какую-нибудь математику и назвать ее образовательной, как и нельзя назвать развлечением действие, во время которого урок ведет говорящее животное, а студент решает дурацкие головоломки. Словами профессора литературы Генри Дженкинса (Henry Jenkins), требуется «продвигаться за пределы текущего состояния образовательно-развлекательных (edutainment) продуктов, в которых объединяется развлекательная ценность плохой лекции с образовательной ценностью плохой игры».

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

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

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

Статью «Аутентификация пользователей с учетом сессий в среде использования протоколов SSL/TLS»(«SSL/TLS Session-Aware User Authentication») написали Рольф Опплигер, Ральф Хаузер и Дэвид Бэзин (Rolf Oppliger, eSECURITY Technologies, Ralf Hauser, PrivaSphere AG, David Basin, ETH Zurich).

В большинстве сегодняшних приложений электронной коммерции для аутентификации сервера и криптографической защиты коммуникационного канала между клиентом и сервером используются протоколы Secure Sockets Layer (SSL) или Transport Layer Security (TLS). Хотя в протоколах SSL/TLS обеспечивается поддержка аутентификации пользователей на основе сертификатов с открытыми ключами, на практике, из-за медленного внедрения этих сертификатов, аутентификация пользователей обычно производится на прикладном уровне. Здесь имеется много вариантов: персональные идентификационные номера (personal identification number, PIN), пароли, парольные фразы (passphrase) и механизмы строгой аутентификации, такие как одноразовые пароли (one-time password, OTP) и системы, основанные на схеме «вопрос-ответ» (challenge-response, C/R).

Хотя разработчики считают протоколы SSL и TLS надежными и безопасными на практике, подавляющее большинство приложений электронной коммерции, основанных на SSL/TLS и использующих аутентификацию на прикладном уровне, уязвимо для фишинга, Web-спуфинга и, самое главное, для атак вида «человек посередине» (man-in-the-middle, MITM). Если при атаке типа MITM злоумышленник сможет разместиться где-то между клиентом и сервером, он может сыграть роль ретранслятора и аутентифицировать себя серверу вместо пользователя. Если же злоумышленник функционирует в реальном масштабе времени, то может быть разрушено или искажено большинство механизмов аутентификации пользователей (отделенных во времени от образования сессий SSL/TLS). Этим обычно пренебрегают, когда речь идет о воспринимаемой безопасности приложений электронной коммерции, основанных на SSL/TLS, таких как банковское обслуживание через Internet или голосование через Internet в удаленном режиме.

В литературе имеется удивительно мало работ, посвященных технологиям и методам защиты от MITM-атак приложений электронной коммерции, основанных на SSL/TLS. Авторами предложен технологический подход к аутентификации пользователей с учетом сессий в среде протоколов SSL/TLS (TLS-SA), который может закрыть эту брешь и обеспечить легковесную альтернативу внедрению сертификатов с открытыми ключами на стороне клиентов. Наряду с базовым подходом предлагается вариант реализации TLS-SA, основанный на внедрении обезличенных аутентификационных токенов.

Последняя большая статья мартовского номера – «Модельно-предсказательное управление обратной связью для гарантированного обеспечения качества обслуживания в Web-серверах» («Model Predictive Feedback Control for QoS Assurance in Webservers») – написана Ченг-Жонг Ксу, Боджин Лиу и Джианбин Вей (Cheng-Zhong Xu, Bojin Liu, Wayne State University, Jianbin Wei, Yahoo!).

Internet-серверам, конфигурируемым на основе анализа усредненных данных о требуемых ресурсах, свойственно образование узких мест вследствие динамических изменений трафика. Управление ресурсами с учетом требуемого качества обслуживания (quality-of-service, QOS) обеспечивает координированное выделение ресурсов в соответствии с запросами клиентов, гарантируя должное качество обслуживания привилегированным клиентам и обеспечивая другим клиентам справедливое и плавное снижение производительности при перегрузке сервера.

В отличие от распространенной сегодня модели наилучшего возможного уровня обслуживания (best-effort service model), архитектура QoS создает возможность реализации дифференцированной структуры цен в службах Internet следующего поколения. Даже на Web-сайтах, в которых не устанавливаются статические различия между разными пользователями, эта архитектура может обеспечить разную производительность обработки запросов, поступающих от разных пользователей или прокси-серверов. Путем снижения качества обработки запросов архитектура QoS контролирует поведение чрезмерно активных пользователей и обеспечивает справедливое совместное использование ресурсов клиентами и прокси-серверами. Гарантированная справедливость автоматически приводит к построению защитного экрана от агрессивных клиентов и защищает сервер от распределенных атак типа «мгновенной толпы» (flash-crowd) с целью возникновения отказов в обслуживании (denial-of-service).

Концепция дифференциации пользователей и гарантирования качества обслуживания берет свое начало в ранних исследованиях планирования пакетов и управления перегрузкой с учетом качества обслуживания для дифференцированного обслуживания (Differentiated Services, DiffServ) и интегрального обслуживания (Integrated Services, IntServ) в ядре сети. Сама сеть не может обеспечить существенную поддержку дифференциации гарантирования качества обслуживания на прикладном уровне. В ранних работах по анализу критических маршрутов в транзакциях TCP было установлено, что при наличии мелких запросов и высокого уровня загрузки сервера задержки на стороне сервера составляют более 80% задержки, наблюдаемой на стороне клиента. В последнее десятилетие обеспечение избыточной пропускной способности (overprovisioning) сетей привело к тому, что нарушения качества обслуживания в ядре сети редко возникают даже при обработке крупных запросов. Все более важными факторами гарантированного сквозного (end-to-end) качества обслуживания становятся задержки при обработке очередей запросов и удлиненное время обработки этих запросов в перегруженных серверах.

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

В предлагаемой авторами инфраструктуре обеспечения сквозного качества обслуживания (end-to-end QoS provisioning framework, eQoS) производится отслеживание и контроль качества обслуживания с учетом времени отображения запрашиваемых страниц на стороне клиента. При разработке контроллеров обратной связи серьезной проблемой является задержка от момента принятия решения до момента, в который наблюдается эффект управления. В теории управления эту задержку часто называют временем простоя (dead time) или задержкой обработки (process delay), и чрезмерно долгое время простоя приводит к неустойчивости работы контроллера.

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