Программная инженерия и смежные дисциплины

Сергей Кузнецов

Обзор октябрьского, 2011 г. номера журнала Computer (IEEE Computer Society, V. 44, No 10, октябрь 2011).

Авторская редакция.
Также обзор опубликован в журнале «Открытые системы»

Октябрьский номер журнала Computer посвящен вопросам взаимодействия области программной инженерии с другими областями computer science. У тематической подборки, включающей шесть полноформатных статей, имеются приглашенные редакторы: Карл Чанг, Дэвид Вейсс и Майк Хинчи (Carl K. Chang, David M. Weiss, Iowa State University, Mike Hinchey, Lero—the Irish Software Engineering Research Centre). Их вводная заметка называется «Там, где программная инженерия соприкасается с ...» («Where Software Engineering Meets ...»).

Программная инженерия является относительно молодой областью. Ко времени первого использования термина software engineering (SE) в 1968 г. многие другие инженерные дисциплины существовали уже многие годы. С тех пор программная инженерия проникла практически во все аспекты современной жизни людей и становится все более практичной и развитой областью.

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

Какие же другие области исследований оказывают основное воздействие на развитие принципов и практических методик применения SE? C 1968 года на SE больше всего влияли инженерные дисциплины. Многие авторитетные специалисты, являющиеся сторонниками превращения SE в истинно инженерную дисциплину, полагают, что при разработке сложных и непременно надежных программных систем необходимо правильно понимать и точно применять надлежащие инженерные принципы и практические методики. Многие исследователи, такие как Харлан Миллс (Harlan Mills) и его коллеги, предложившие концепцию «чистой комнаты» для разработки надежного программного обеспечения (Cleanroom software engineering), и Барри Боем (Barry Boehm), подчеркивающий важность процессов и экономических моделей SE, были единодушны в том, что дисциплине SE следует прагматически перенять многие инженерные термины и методы.

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

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

Первую регулярную статью тематической подборки под названием «Могут ли практики пренебрегать теорией, а теоретики – практикой» («Can Practitioners Neglect Theory and Theoreticians Neglect Practice?») представил (Manfred Broy, Technical University of Munich, Germany).

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

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

Автором статьи «Программное обеспечение с открытыми исходными текстами: связь с методами программной инженерии» («Open Source Software: Lessons from and for Software Engineering») является Брайана Фитцджеральд (Brian Fitzgerald, Lero—the Irish Software Engineering Research Centre).

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

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

Следующая статья называется «Программная инженерия и эволюционные вычисления» («Software Engineering Meets Evolutionary Computation») и написана Марком Харманом (Mark Harman, University College London).

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

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

В компьютерных науках эволюционные вычисления используются для оптимизации разработки артефактов и процессов в самых разнообразных инженерных областях. Однако, как это ни странно, до конца прошлого века сравнительно мало исследований посвящалось применению эволюционных вычислений (и других методов поисковой оптимизации) в области инженерии программного обеспечения. Это привело к образованию новой области исследований, называемой поисковой инженерией программного обеспечения (search-based software engineering, SBSE), которая посвящена применению методов поисковой оптимизации для решения проблем программной инженерии.

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

Рост числа публикаций по тематике SBSE, сопутствующий рост числа публикаций, посвященных применению эволюционных вычислений в инженерии программного обеспечения

Нет причин, по которым SBSE должна была бы опираться только на эволюционные вычисления; можно использовать и другие алгоритмы оптимизации, и они действительно используются. Например, в июне 2011 г. в 587 из 830 публикаций по тематике SBSE, собранных в репозитории SBSE, использовался, по крайней мере, один метод оптимизации. В 9,0% статей использовались какие-либо эволюционные алгоритмы (evolutionary algorithm), в 45,5% – генетические алгоритмы (genetic algorithm), в 13,5% – генетическое программирование (genetic programming), в 0,6% – эволюционные стратегии (evolution strategy), в 1,8% – метод роя частиц (particle swarm optimization), в 1,4% – алгоритмы оценки распределений (estimation of distribution algorithm) и в 0,8% – рассеянный поиск (scatter search). Однако эволюционные вычисления использовались в 71% всех статей по тематике SBSE, и это единственный метод оптимизации, применимый в любом направлении инженерии программного обеспечения.

Робин Лац (Robyn Lutz, Iowa State University and Jet Propulsion Laboratory, California Institute of Technology) представил статью «Применение инженерии программного обеспечения в области исследований космического пространства» («Software Engineering for Space Exploration»).

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

В этом году NASA осуществило или подготовило космические экспедиции для составления карты гравитационного поля Луны (программа изучения гравитационного поля и внутреннего строения Луны, Gravity Recovery and Interior Laboratory, GRAIL), исследования того, как сформировался Юпитер и другие гигантские планеты (Juno), а также запустило программу Mars Science Laboratory (MSL), в рамках которой на Марс будет доставлен автоматический марсоход Curiosity, предназначенный для исследования марсианской среды.

Эволюция марсоходов. Слева направо: один из двух марсоходов 2004 года – Spirit и Opportunity; марсоход Pathfinder 1997 года и марсоход Curiosity 2011 года (фотография NASA/JPL-Caltech)

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

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

Инженерия программного обеспечения играет жизненно-важную роль для обеспечения инструментальных средств, методов и систематических подходов к разработке и поддержке многих видов программного обеспечения, требуемого в космических исследованиях. Применение разработки программного обеспечения на основе моделей (model-based software development), формальной верификации и разработки линеек продуктов (product-line development) обеспечивает соответствие возможностям программного обеспечения потребностям космических исследований, надежное и корректное функционирование космических аппаратов.

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

В центре внимания автора находятся автоматические космические аппараты, разработанные в Лаборатории реактивных двигателей NASA (Jet Propulsion Laboratory. JPL), но программное обеспечение экспедиций по исследованию космоса разрабатывается и в других подразделения NASA, а также в международных космических агентствах, коммерческих организациях и исследовательских институтах. Ограниченность бюджета, наличие различного уровня подготовки, стремление к распределению рисков и потенциальные преимущества совместной работы стимулируют сотрудничество нескольких организаций для решения задач, которые ни одна из них не могла бы решить в одиночку. Международное сотрудничество стало отличительной чертой области исследования космоса.

Статья «Инженерия программного обеспечения, сервис-ориентированные архитектуры и “облачные” вычисления» («Software Engineering Meets Services and Cloud Computing») написана Стивеном Яу и Хо Эном (Stephen S. Yau, Ho G. An, Arizona State University).

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

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

Сервис-ориентированная инженерия программного обеспечения (service-oriented software engineering, SOSE) объединяет лучшие черты этих парадигм. Изначально SOSE основывалась на сервис-ориентированном компьютинге, но впоследствии стала затрагивать и «облачный» компьютинг. В SOSE сервис-ориентированная архитектура обеспечивает архитектурный стиль, стандартные протоколы и интерфейсы, требуемые для разработки приложений, а «облачная» инфраструктура используется для доставки пользователям требуемых сервисов за счет виртуализации и применения пулов ресурсов. Соединение сервис-ориентированного и «облачного» компьютинга в инфраструктуре программной инженерии может помочь разработчикам и поставщикам сервисов справиться с проблемами каждой из этих парадигм.

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

Последняя статья тематической подборки написана Дэвидом Лорджем Парнасом (David Lorge Parnas, Middle Road Software) и называется «Инженерия программного обеспечения – без вести пропавшая: личная точка зрения» («Software Engineering – Missing in Action: A Personal Perspective»).

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

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

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

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

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

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

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

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

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

Вне тематической подборки в октябрьском номере опубликована статья «Управление питанием дисплея с выявлением намерений пользователей» («Display Power Management That Detects User Intent»), авторами которой являются Джей Мин Ким, Миньен Ким, Джунго Конг, Хиюнг Беом Джанг, Сун Ву Чунг (Jae Min Kim, Minyong Kim, Joonho Kong, Hyung Beom Jang, Sung Woo Chung, Korea University).

Расширение областей применения компьютеров приводит к тому, что все чаще люди используют лаптопы, а не настольные компьютеры. Соответственно, возрастает и актуальность проблемы продления времени работы аккумуляторных батарей на счет продуманного управления питанием дисплеев (display power management, DPM).

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

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

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

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

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

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

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