Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Обучение от Mail.Ru Group.
Онлайн-университет
для программистов с
гарантией трудоустройства.
Набор открыт!
2010 г.

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

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

Обзор майского, 2010 г. номера журнала Computer (IEEE Computer Society, V. 43, No 5, May 2010).

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

Темой майского номера журнала в этом году являются критические программные системы. Приглашенными редакторами номера являются Лоркан Койл, Майк Хинчи, Башар Нузейбех и Хосе Луис Фиадейро (Lorcan Coyle, Mike Hinchey, Bashar Nuseibeh, Lero—the Irish Software Engineering Research Centre, José Luiz Fiadeiro, University of Leicester). Их вводная заметка называется «Эволюционирующие критические системы» (Evolving Critical Systems).

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

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

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

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

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

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

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

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

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

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

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

Все эти факторы могут привести к нескольким техническим проблемам в области встраиваемых систем:

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

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

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

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

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

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

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

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

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

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

В 1996 г. Мэтт Блейз (Matt Blaze) ввел термин «управление доверием», назвав так систематический подход к управлению политиками безопасности, полномочиями и доверительными отношениями, касающимися авторизации и делегирования решений, критичных для безопасности. С тех пор управлению доверием уделялось все возрастающее внимание, и сегодня на нем основываются разнообразные подходы. Авторы расценивают управление доверием как управление рисками с большей ориентацией на понимание влияния на фактические риски целевой системы доверительных отношений внутри самой системы и между ней и ее средой. Методологии управления доверием свойственны те же недостатки, что и управлению рисками, причем возникают дополнительные проблемы, связанные со сложностью и динамической природой доверительных отношений.

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

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

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

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

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

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

Вне тематической подборки опубликованы две большие статьи. Статью «Что следует за шопботом?» («What’s Next for Shopbots?») написали Юн Ван и Ганг Пенг (Yun Wan, University of Houston—Victoria, Texas, Gang Peng, Youngstown State University, Ohio). 30 июня 1995 г. исследователи компаний Andersen Consulting и Smart Store Center объявили о доступности интеллектуального программного агента BargainFinder, демонстрирующего возможности «сравнительных покупок» («comparison shopping»). Хотя в том же году появились и другие шопботы, сенсацию вызвал именно BargainFinder, поскольку в раскрутке этого средства участвовали известная компания и средства массовой коммуникации. На первых порах, возможность поиска лучших цен на интересующие продукты с помощью одного щелчка мыши казалась публике просто волшебством.

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

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

Скриншот BargainFinder

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

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

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

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

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

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

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

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

До следующей встречи, Сергей Кузнецов.

Новости мира IT:

Архив новостей

Последние комментарии:

Релиз ядра Linux 4.14  (9)
Среда 22.11, 19:04
Loading

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2015 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...