Перспективы и проблемы программной инженерии в XXI веке

Автор первой статьи тематической подборки, «Изменения к лучшему в век программного обеспечения» (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). Автор начинает статью с того, что ему очень повезло родиться в 30-е годы и участвовать в создании совершенно новой дисциплины — инженерии программного обеспечения. У тех, кто только сейчас начинает заниматься программной инженерией, имеются еще более захватывающие перспективы. Следующие несколько десятилетий сделают XXI век веком программного обеспечения. Программное обеспечение станет основным элементом, обеспечивающим людям требуемые возможности и качество жизни, и специалисты, знающие, как лучше всего разрабатывать программные системы, получат шанс изменить мир к лучшему, однако на этих специалистов ляжет огромная ответственность за обеспечение должного качества разрабатываемых программных систем и предоставляемых ими сервисов. Как считает Боем, основными проблемами, с которыми столкнутся в XXI веке специалисты в области программной инженерии, являются постоянное ускорение изменений, наличие неопределенных и непредвиденных ситуаций, функциональная надежность, диверсификация и взаимозависимость.

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

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

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

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

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

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

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

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

Статью «Определение влияния на практику исследований в области программной инженерии» (Determining the Impact of Software Engineering Research on Practice) представили Леон Остервейл, Карло Гецци, Джеф Креймер и Александер Волф. Программная инженерия стала активной исследовательской областью в 1968 году, когда на знаменательной конференции NATO (www.europrog.ru/book/nato1968e.pdf ) в Гармише (Германия) участники обосновали научную и практическую важность этой дисциплины. С 1975 года стали регулярно проводиться международные конференции по программной инженерии International Conference on Software Engineering, на которые сейчас поступает более 400 заявок на доклады и которые собирают более 1000 участников. С 1982 году к ним прибавились еще и международные симпозиумы по основам программной инженерии обеспечения ACM SIGSOFT International Symposium on the Foundations of Software Engineering. Исследователи считают эти конференции лучшими в данной области. Наряду с трудами конференций распространению результатов исследований способствуют журнальные публикации. К числу ведущих журналов, специализирующихся на тематике программной инженерии, относятся ACM Transactions on Software Engineering and Methodology (tosem.acm.org) и IEEE Transactions on Software Engineering (www.computer.org/tse ).

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

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

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

Последняя статья тематической подборки представлена Лорином Хохштейном и Виктором Базили и называется «Проекты ASC-Alliance: пример крупномасштабной разработки параллельного научного кода» (The ASC-Alliance Projects: A Case Study of Large-Scale Parallel Scientific Code Development). Ученые используют компьютеры для моделирования физических явлений в ситуациях, в которых эксперименты были бы чрезмерно дороги или невозможны. Научные исследования зависят от продуктивности разработки требуемого программного обеспечения, однако процесс разработки в этой области отличается от других областей. Так, для научных программ требуются вычислительные возможности суперкомпьютеров, разработки программного обеспечения для которых порождают уникальные проблемы. Чтобы больше узнать о разработке программного обеспечения для таких систем, авторы исследовали пять проектов, выполненные в разных исследовательских центрах альянса по развитому моделированию и вычислениям ASC Alliance (Advanced Simulation and Computing Alliance). В каждом из этих проектов решалась отдельная проблема и у каждого центра имелся доступ к крупномасштабным системам в различных суперкомпьютерных центрах. Авторы интервьюировали основных участников проектов альянса, связанных с управлением, архитектурой программного обеспечения и интеграцией программного обеспечения с целью выяснить проблемы, с которыми пришлось столкнуться ученым, а также определения основных характеристик конечного продукта, организации проекта и процесса разработки программного обеспечения.

Вне тематической подборки опубликованы три большие статьи. Авторы статьи «Модель процесса разработки, ориентированная на содержательный материал» (A Content-Centric Development Process Model) — Пабло Морено-Гер, Иван Мартинез-Ортиз, Хосе Луис Сиерра и Балтазар Фернандез-Маньон. Обучающий потенциал компьютеров и видеоигр огромен, поскольку на них легко фиксируется внимание обучающихся. Распространенная точка зрения, что дети не способны сосредотачиваться на чем-то одном в течение достаточно долгого промежутка времени, расходится с тем, что они могут проводить часы за играми не теряя концентрации. При должном подходе время, затрачиваемое на игры, может служить на пользу образованию, и здесь становится уместным обучение на основе игр.

Однако обучать во время развлечений нелегко. Нельзя просто встроить в игру какую-нибудь математику и назвать ее образовательной, как и нельзя назвать развлечением действие, во время которого урок ведет говорящее животное, а студент решает дурацкие головоломки. Говоря словами профессора литературы Генри Дженкинса, требуется «продвигаться за пределы текущего состояния образовательно-развлекательных (edutainment) продуктов, в которых объединяется развлекательная ценность плохой лекции с образовательной ценностью плохой игры» (icampus.mit.edu/projects/GamesToTeach.shtml). По мнению авторов, управляемые мышью приключенческие игры, такие как саги Monkey Island и King’s Quest, содержат все компоненты, требуемые для достижения баланса между выдачей содержательного материала и развлечением. Игры этого типа оцениваются в терминах качества их раскадровки и ритма в отличие от типичных черт видеоигр других типов, таких как погружение игроков в проблемные ситуации, повышающие уровень адреналина в их крови и требующие молниеносной реакции.

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

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

Статью «Аутентификация пользователей с учетом сессий в среде использования протоколов SSL/TLS»(SSL/TLS Session-Aware User Authentication) написали Рольф Опплигер, Ральф Хаузер и Дэвид Бэзин. В большинстве сегодняшних приложений электронной коммерции для аутентификации сервера и криптографической защиты коммуникационного канала между клиентом и сервером используются протоколы Secure Sockets Layer (SSL) или Transport Layer Security (TLS). Хотя в протоколах SSL/TLS обеспечивается поддержка аутентификации пользователей на основе сертификатов с открытыми ключами, на практике, из-за медленного внедрения этих сертификатов, аутентификация пользователей обычно производится на прикладном уровне. Здесь имеется много вариантов: персональные идентификационные номера, пароли, парольные фразы и механизмы строгой аутентификации, такие как одноразовые пароли и системы, основанные на схеме «вопрос-ответ».

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

В литературе имеется удивительно мало работ, посвященных технологиям и методам защиты от атак вида «человек посередине» приложений электронной коммерции, основанных на SSL/TLS. Авторами предложен технологический подход к аутентификации пользователей с учетом сессий в среде протоколов SSL/TLS (TLS-SA, www.inf.ethz.ch/personal/basin/pubs/mitm-cc.pdf ), который может закрыть эту брешь и обеспечить легковесную альтернативу внедрению сертификатов с открытыми ключами на стороне клиентов. Наряду с базовым подходом предлагается вариант реализации TLS-SA, основанный на внедрении обезличенных аутентификационных токенов.

Последняя большая статья номера — «Модельно-предсказательное управление обратной связью для гарантированного обеспечения качества обслуживания в Web-серверах» «Model Predictive Feedback Control for QoS Assurance in Webservers) — написана Ченг Жонг Ксу, Боджин Лиу и Джианбин Вей. Internet-серверам, конфигурируемым на основе анализа усредненных данных о требуемых ресурсах, свойственно образование узких мест вследствие динамических изменений трафика. Управление ресурсами с учетом требуемого качества обслуживания (Quality-of-Service, QoS) обеспечивает координированное выделение ресурсов в соответствии с запросами клиентов, гарантируя должное качество обслуживания привилегированным клиентам и обеспечивая другим клиентам справедливое и плавное снижение производительности при перегрузке сервера.

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

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

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

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

До встречи в следующем месяце, Сергей Кузнецов (kuzloc@ispras.ru ).