Критические проблемы критических систем

Вводная заметка номера называется «Эволюционирующие критические системы» (Evolving Critical Systems), а ее авторы – приглашенные редакторы Лоркан Койл (Lorcan Coyle), Майк Хинчи (Mike Hinchey), Башар Нузейбех (Bashar Nuseibeh) и Хосе Луис Фиадейро (Jose Luiz Fiadeiro).

Сообщество программной инженерии должно сконцентрировать усилия на совершенствовании методов, методологий и инструментальных средств для разработки, реализации и поддержки критических программных систем, способных к успешному эволюционированию. Важность эволюционирующих критических систем (evolving critical systems, ECS) подчеркивается масштабными изменениями, происходящими в программной инженерии, наиболее существенные из которых можно охарактеризовать следующим образом:

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

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

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

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

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

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

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

Первая статья тематической подборки представлена Габором Карсаи (Gabor Karsai), Фабио Массаччи (Fabio Massacci), Леоном Остервейлом (Leon Osterweil) и Иной Шифердекер (Ina Schieferdecker) и называется «Эволюционирующие встраиваемые системы» (Evolving Embedded Systems).

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

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

Авторами статьи «Эволюционирующие описания программной архитектуры критических систем» (Evolving Software Architecture Descriptions of Critical Systems) являются Том Менс (Tom Mens), Джеф Меджи (Jeff Magee) и Бернхард Румпе (Bernhard Rumpe).

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

В стандарте IEEE 1471-2000, который также стал международным стандартом ISO/IEC 42010:2007, рекомендуется обеспечивать архитектурные описания систем с интенсивным использованием программного обеспечения, чтобы можно было справляться с их возрастающей сложностью и уменьшать риски, возникающие при конструировании и развитии этих систем. Как показано на рис. 1, в соответствии с этим стандартом каждая система выполняет в среде своего обитания некоторую конкретную миссию, и имеется круг заинтересованных лиц, у которых есть проблемы, связанные с этой системой или ее миссией. Проблемы определяются как «потребности, которые влияют на разработку системы, ее функционирование или другие аспекты, критически важные в некотором другом отношении для одного или нескольких заинтересованных лиц». К проблемам времени выполнения относятся производительность, надежность, безопасность и т.д., а основные проблемы разработки связаны с сопровождением, в частности с обеспечением эволюционирования.

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

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

Следующая статья называется «Эволюция в связи с управлением рисками и доверием» (Evolution in Relation to Risk and Trust Management) и написана Массом Солдалом Лундом (Mass Soldal Lund), Бьернаром Солхаугом (Bjшrnar Solhaug) и Кетилом Столеном (Ketil Stolen).

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

В картине риска обычно учитывается конфигурация системы в некоторый конкретный момент времени, однако система и ее окружение, а также знания экспертов эволюционируют во времени, и оказывается, что современные методологии управления рисками вообще и оценки рисков в частности недостаточно пригодны для учета такой эволюции. В стандарте управления рисками ISO 310001 предписывается выявление изменений и связанных с ними рисков, однако отсутствует какие-либо руководство. В важной методологии оценки рисков OCTAVE (http://www.cert.org/octave/octavemethod.html) рекомендуется пересматривать оценки рисков и активов, но ничего не говорится о том, каким образом следует оценивать риски.

В 1996 году Мэтт Блейз ввел термин «управление доверием» (http://citeseerx.ist.psu.edu/viewdoc/download?doi#.1.1.100.9510&rep=rep1&type=pdf), назвав так систематический подход к управлению политиками безопасности, полномочиями и доверительными отношениями, касающимися авторизации и делегирования решений, критичных для безопасности. С тех пор управлению доверием уделялось все больше внимания, и авторы применяют его для управления рисками с ориентацией на выявление влияния целевой системы доверительных отношений внутри системы и с ее средой. Методологии управления доверием свойственны те же недостатки, что и управлению рисками, причем возникают дополнительные проблемы, связанные со сложностью и динамической природой доверительных отношений.

Последняя статья тематической подборки – «Почему критическим системам требуется помощь в эволюции?» (Why Critical Systems Need Help to Evolve) – написана Бернардом Коэном (Bernard Cohen) и Филипом Боксером (Philip Boxer).

В соответствии с отчетом ортопедических служб Великобритании (http://www.bapo.org/docs/latest/yorkreport.pdf),  более 1,2 млн пациентов с диагнозами от диабета до нарушения нейромышечной деятельности рассчитывают, что такие службы позволят им полноценно работать и жить. В отчете отмечается, что в 2005 году расходы на ортопедические службы составили около 128 млн долл., и с тех пор потребность в них росла в соответствии с общим процессом старения населения и сложностью заболеваний. Но, несмотря на это, отсутствует общее понимание в объемах финансирования.

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

В отчете 2009 года указывается, что на каждом долларе, потраченном на ортопедические службы, Национальная служба здравоохранения экономит 4 долл. При общих затратах на обеспечение ортопедической помощи, составляющих сегодня 150 млн долл., экономия должна составить примерно 600 млн. И тем не менее в отчете устанавливается, что из-за недостаточного финансирования экспериментальные пункты ортопедической помощи, потенциально способные предоставлять услуги повышенного уровня, не могут нормально функционировать. Для организации ортопедической службы в больнице требуется специальное финансирование Трастового медицинского фонда (Primary Care Trust).

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

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

Вне тематической подборки опубликованы две большие статьи. Статью «Что следует за шопботом?» (What’s Next for Shopbots?) написали Юн Ван (Yun Wan) и Ганг Пенг (Gang Peng).

30 июня 1995 года исследователи компаний Andersen Consulting и Smart Store Center объявили о доступности интеллектуального программного агента BargainFinder, демонстрирующего возможности «сравнительных покупок» (comparison shopping). Хотя в том же году появились и другие шопботы, сенсацию вызвал именно BargainFinder, поскольку в его раскрутке участвовали известная компания и средства массовой коммуникации. На первых порах возможность поиска лучших цен на интересующие продукты с помощью одного щелчка мыши казалась публике просто волшебством.

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

BargainFinder изначально замышлялся как шопбот для поиска и сравнения цен на музыкальные компакт-диски, и по сравнению с сегодняшними шопботами его интерефейс был довольно тривиальным — в центре экрана размещались два окошка ввода текста, в которых пользователи вводили имя исполнителя и название альбома, а справа имелись две кнопки для инициации поиска и очистки полей ввода (рис. 2). Результаты поиска интегрировались и выдавались пользователю.

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

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

Наконец, последняя большая статья майского номера представлена Вильямом Робинсоном (William N. Robinson) и называется «Перспективный план развития полного мониторинга требований» (A Roadmap for Comprehensive Requirements Monitoring).

Сегодня миллиарды тратятся на повышение уровня прозрачности программных систем. Средства мониторинга бизнес-операций (business activity monitoring, BAM) позволяют в реальном времени отслеживать бизнес-цели программных систем, такие как сокращение числа непредвиденных ситуаций, сокращение времени цикла производства и повышение уровня доходности. В небольших масштабах обеспечивается режим непрерывной валидации, когда удовлетворение целей пользователей отслеживается при использовании программного обеспечения. Адаптивные софтверные компании постоянно следят за своими заказчиками через фокус-группы, бета-версии программного обеспечения и т.д., стремясь к тому, чтобы их программное обеспечение соответствовало потребностям заказчиков. Кроме того, наличие средств мониторинга в уже поставленном заказчикам программном обеспечении позволит получить информацию об их предпочтениях и общем поведении. Эта информация может использоваться разработчиками для дальнейшего совершенствования программного обеспечения.

Совместно используя внутренний анализ своих систем, сообщения пользователей об ошибках и данные от фокус-групп, разработчики формируют представление о качестве системы, организуя информационную панель (dashboard) с информацией о серьезности, месте и числе ошибок. На основе анализа информационной панели планируется производство патчей и их доставка пользователям. Примером является Windows Update.

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

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