Опубликован: 03.02.2016 | Доступ: свободный | Студентов: 1608 / 338 | Длительность: 07:40:00
Лекция 5:

Сопровождение и развитие созданных архитектур программного обеспечения

< Лекция 4 || Лекция 5: 12

Процессы мониторинга

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

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

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

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

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

  • Построения комплексной единой информационной структуры;
  • Cогласованного результата процесса мониторинга по программным продуктам компании.

Возможны несколько подходов к построению системы мониторинга:

  • Сверху вниз

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

  • Снизу вверх

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

  • Комбинированный подход

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

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

  • Работоспособность составляющих ее частей;
  • Оперативную настройку и изменение систем мониторинга.

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

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

Процессы сопровождения

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

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

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

  • Оптимизация преждевременна

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

  • Оптимизация необходима

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

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

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

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

  • Удобства ее дальнейшего сопровождения;
  • Возможности повторного использования уже реализованных компонентов;
  • Простоты интеграции с другими системами.

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

Возможности и пути развития архитектуры

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

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

Большинство профессионалов в сфере разработки архитектуры программного обеспечения и бизнес процессов, по складу своего мышления, являются людьми достаточно консервативными. Они неоднозначно относятся к постоянной смене пути, но реалии бизнес условий современного мира демонстрируют, что строгая и тщательно продуманная архитектура, разработанная до начала создания программного продукта, не всегда работает хорошо в проектах по разработке программного обеспечения и может приводить к увеличению ресурсов, необходимых для из реализации. Это ознаменовало начало "agile" эры в разработке программных продуктов. Основные идеи этой эры сформулированы и продемонстрированы Мартином Фаулером в его работах. Он предложил начинать возводить архитектуру с реализации наиболее простых требований к решению, этот принцип получил название "YAGNI".

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

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

Выводы по изученной лекции

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

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

Итоги курса

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

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

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

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

< Лекция 4 || Лекция 5: 12