Проектирование архитектуры информационных систем

3.9.9 Безопасность эксплуатации

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

3.9.10 Дополнительные группы нефункциональных требований

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

3.10 Взаимосвязь требований и архитектуры

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

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

Полнота требований не означает максимально возможное количество положений. Она означает наличие требований, необходимых для определения и приемки системы. Необходимо проверить наличие целей, границ, пользователей, функций, данных, интерфейсов, характеристик качества, условий эксплуатации, безопасности, сопровождения и ограничений. Следует проверить, описаны ли основные и исключительные сценарии, обработка ошибок, права пользователей и взаимодействие с внешними системами. Необходимо проверить согласованность единиц измерения, терминов, ролей и состояний объектов. Если в одном разделе используется термин «клиент», а в другом — «покупатель», необходимо установить, являются ли они одним участником или различными ролями. Требования должны быть согласованы с моделями. Если диаграмма процесса предусматривает согласование руководителем, соответствующая функция и роль должны присутствовать в требованиях. Необходимо проверить реализуемость и стоимость. Некоторые требования могут быть технически возможны, но экономически неоправданны. Например, требование абсолютной доступности без перерывов невозможно выполнить буквально. Даже резервированные системы имеют вероятность отказа. Следует установить измеримый допустимый уровень. Необходимо проверить возможность приемки. Если критерий выполнения отсутствует, между заказчиком и разработчиком может возникнуть спор. Грамотно сформированная система требований обеспечивает основу архитектуры, разработки, тестирования, внедрения и сопровождения. Недостатки требований распространяются на все последующие стадии. Ошибка в программном коде обычно затрагивает отдельную функцию, тогда как ошибка в базовом требовании может привести к созданию системы, которая в целом не решает задачу пользователя. Стандартизация процессов и требований позволяет уменьшить этот риск. Отечественные стандарты определяют стадии создания автоматизированных систем, состав технического задания и содержание документов. Международные и гармонизированные стандарты формируют общую систему процессов жизненного цикла, инженерии требований, архитектурного описания и качества программного продукта. Пользовательские требования описывают цели и задачи пользователей. Системные требования преобразуют эти потребности в технически точное описание системы. Функциональные требования определяют операции и поведение. Нефункциональные требования устанавливают характеристики качества и ограничения. Документирование обеспечивает однозначность, проверяемость, прослеживаемость и управляемость изменений. Архитектура информационной системы должна формироваться не на основе случайного выбора технологий, а на основе согласованной системы требований. Именно требования объясняют, почему выделены определенные компоненты, каким образом организованы данные, зачем применяются механизмы резервирования, какие интерфейсы необходимы и какими характеристиками должна обладать система в процессе эксплуатации.

4. Методологии проектирования информационных систем

Методология проектирования информационной системы представляет собой организованную совокупность принципов, методов, моделей, процессов, ролей, правил, документов и инструментальных средств, применяемых для создания, развития и сопровождения информационной системы. Методология определяет не только последовательность выполнения работ, но и способы принятия решений, распределения ответственности, взаимодействия участников, управления требованиями, контроля качества и оценки полученных результатов. Проектирование информационной системы является сложной коллективной деятельностью. В нем участвуют заказчики, пользователи, владельцы бизнес-процессов, аналитики, архитекторы, разработчики, тестировщики, специалисты по данным, администраторы, инженеры по эксплуатации и информационной безопасности. Без согласованной методологии каждый участник может организовывать работу по собственному усмотрению. Аналитик будет формировать требования в одной форме, архитектор — разрабатывать модели в другой, разработчик — принимать самостоятельные технические решения, а тестировщик — проверять систему без ясных критериев приемки. В результате увеличиваются сроки, стоимость, количество дефектов и риск создания системы, не соответствующей потребностям организации. Методология устанавливает общий порядок перехода от потребности к работающей информационной системе. В ее рамках определяются способы обследования предметной области, выявления требований, моделирования процессов, проектирования архитектуры, выбора технологий, разработки программного обеспечения, проведения испытаний, внедрения и сопровождения. Необходимо различать понятия методологии, метода, процесса, практики, архитектурного подхода и инструмента. Методология охватывает систему организации деятельности в целом. Метод определяет способ решения определенного класса задач. Процесс представляет собой последовательность взаимосвязанных действий, преобразующих входные данные в результат. Практика является регулярно применяемым приемом работы. Архитектурный подход определяет принципы структурирования системы. Инструмент представляет собой программное или техническое средство, поддерживающее выполнение работы. Например, гибкая разработка, или Agile, является системой ценностей и принципов. Скрам, или Scrum, является каркасом организации работы над сложным продуктом. Канбан, или Kanban, является методом управления потоком работ и эволюционного совершенствования процессов. DevOps представляет собой культурный и инженерный подход, объединяющий разработку и эксплуатацию. Система управления задачами, среда моделирования или сервер непрерывной интеграции являются инструментами, но сами по себе не образуют методологию. Использование современной программы для управления задачами не делает процесс гибким. Команда может вести доску задач, но продолжать работать крупными партиями, редко показывать результат пользователям и запрещать изменение требований. Аналогично применение контейнеров и системы автоматизированного развертывания не означает полноценного внедрения DevOps, если разработчики не отвечают за эксплуатационные характеристики продукта, а обновления по-прежнему передаются между изолированными подразделениями вручную. Методология должна соответствовать особенностям проекта. Для информационной системы с устойчивыми требованиями и обязательной формальной приемкой может использоваться стадийная модель с подробной документацией. Для цифрового продукта, требования к которому меняются на основе поведения пользователей, необходимы короткие циклы, экспериментальная проверка гипотез и регулярная поставка новых версий. Для критической системы требуется сочетание гибкости с формальными проверками, управлением рисками, прослеживаемостью требований и подтверждением безопасности. Современные методологии развиваются в направлении сокращения длительности обратной связи. Чем быстрее участники получают информацию об ошибке требования, архитектурного решения, программного компонента или эксплуатационной настройки, тем дешевле исправление. Поэтому в современных подходах анализ, проектирование, разработка, тестирование, развертывание и наблюдение за работой системы стремятся объединить в непрерывный управляемый цикл.

4.1 Понятие гибкой разработки информационных систем

Гибкая разработка, обозначаемая международным термином Agile, представляет собой подход к созданию программных продуктов, основанный на итерационном развитии, тесном взаимодействии участников, регулярной поставке работающего результата и готовности изменять планы по мере появления новой информации. Agile не является одной конкретной методологией. Это система ценностей и принципов, на основе которой существуют различные методы и организационные каркасы. К гибким подходам относятся Scrum, Kanban, экстремальное программирование, разработка, управляемая функциональностью, семейство методов Crystal и другие подходы. Основой гибкой разработки является Манифест гибкой разработки программного обеспечения, сформулированный в 2001 году. Он устанавливает четыре ценностных приоритета: люди и взаимодействие важнее процессов и инструментов; работающий программный продукт важнее исчерпывающей документации; сотрудничество с заказчиком важнее формального согласования условий договора; готовность к изменениям важнее строгого следования первоначальному плану. Правая часть каждого сопоставления также признается важной, однако при конфликте приоритет отдается левой части. Данные ценности иногда толкуются неправильно. Agile не отрицает процессы, инструменты, документы, договоры и планирование. Он требует, чтобы они поддерживали создание полезного результата, а не становились самостоятельной целью. Документ, который необходим для эксплуатации, безопасности или передачи знаний, должен быть подготовлен. Однако создание сотен страниц документации, которая не используется и быстро устаревает, не создает ценности. Гибкая разработка основана на итерационности и инкрементности. Итерационность означает многократное уточнение продукта. Команда не пытается сразу создать окончательное решение, а последовательно развивает его на основе полученных результатов и обратной связи. Инкрементность означает создание системы функциональными приращениями. Каждое приращение добавляет определенную полезную возможность. Например, разработка медицинской информационной системы может быть разделена на несколько приращений. Сначала реализуется регистрация пациента и ведение расписания, затем электронная медицинская карта, после этого обмен результатами лабораторных исследований, электронные назначения и аналитическая отчетность. Каждое приращение должно быть интегрировано с уже созданной системой и пригодно для проверки. Итерационность не означает бесконечное переделывание. Каждая итерация должна давать новую информацию и приближать продукт к цели. Если команда постоянно изменяет одни и те же функции без оценки результата и ясной цели, это свидетельствует не о гибкости, а о слабом управлении требованиями. Одним из центральных понятий Agile является ценность продукта. Работа оценивается не только по количеству написанного программного кода, подготовленных документов или закрытых задач, но и по тому, насколько созданная возможность решает проблему пользователя и способствует достижению целей организации. Например, команда может реализовать сложный отчет, который формально соответствует требованиям, но практически не используется руководителями. С точки зрения объема выполненной работы функция завершена, однако ее полезная ценность ограничена. Гибкий подход требует регулярно проверять не только создание функции, но и ее фактическую востребованность. Следующим принципом является ранняя и регулярная поставка работающего результата. Чем дольше система существует только в виде требований, моделей и программного кода отдельных компонентов, тем выше риск позднего обнаружения неправильных решений. Работающая версия позволяет проверить интерфейс, бизнес-логику, производительность, интеграции и пользовательские сценарии. Работающий результат не обязательно сразу передается всем пользователям. Он может демонстрироваться представителям заказчика, проходить внутреннее тестирование, использоваться ограниченной пилотной группой или размещаться в опытной среде. Главное заключается в том, что результат должен быть интегрированным и проверяемым. Гибкая разработка предусматривает непрерывное уточнение требований. В традиционной модели требования стараются полностью определить до начала реализации. В Agile признается, что часть требований становится понятной только в процессе взаимодействия с продуктом. Это не означает отсутствия исходного анализа. До начала разработки необходимо определить проблему, цели, границы продукта, ключевых пользователей, основные риски и архитектурные ограничения. Однако детальная проработка всех функций на несколько лет вперед может оказаться неэффективной, поскольку часть предположений изменится раньше, чем функции будут реализованы. Одним из инструментов организации требований является перечень работ продукта, или бэклог продукта. Он содержит упорядоченные функции, изменения, исправления, исследования и технические работы, необходимые для развития продукта. Порядок элементов отражает их относительную важность и очередность рассмотрения. Бэклог не должен превращаться в неконтролируемое хранилище пожеланий. Его элементы должны регулярно анализироваться, объединяться, разделяться, уточняться, переоцениваться и удаляться, если они больше не соответствуют целям продукта. Для описания пользовательской потребности часто применяется пользовательская история. Она может быть сформулирована по схеме: «Как определенный пользователь, я хочу выполнить определенное действие, чтобы получить определенную пользу». Например: «Как заведующий складом, я хочу видеть товары с критически низким остатком, чтобы своевременно сформировать заказ поставщику». Пользовательская история не является полной спецификацией. Она представляет краткое описание потребности и основание для дальнейшего обсуждения. К ней добавляются критерии приемки, бизнес-правила, модели данных, макеты интерфейса и другие сведения, необходимые для реализации и проверки. Критерии приемки устанавливают условия, при выполнении которых функция считается соответствующей ожиданиям. Например, для истории о низком остатке критерии могут определять способ расчета порога, перечень отображаемых полей, правила фильтрации и частоту обновления сведений. Гибкая разработка использует приоритизацию требований. Не все функции имеют одинаковую ценность и срочность. Приоритет может определяться влиянием на цели продукта, риском, стоимостью задержки, обязательностью, зависимостями и трудоемкостью. Распространенной ошибкой является объявление всех задач критически важными. Если каждый элемент имеет высший приоритет, реальная приоритизация отсутствует. Необходимо принимать решения о том, какие функции создаются раньше, а какие могут быть отложены или исключены. Для оценки объема работы могут использоваться относительные единицы. Команда сравнивает задачи между собой по сложности, неопределенности и объему. Одним из методов является планирование с использованием карточек оценивания, при котором участники независимо предлагают оценки, а затем обсуждают различия. Относительная оценка не является точным измерением времени. Она помогает сравнивать задачи и планировать доступный объем работы, но не должна использоваться для оценки индивидуальной производительности сотрудников. В гибких командах применяется понятие скорости выполнения, показывающее объем работы, завершенный командой за определенный период. Скорость может использоваться для внутреннего прогнозирования, но сравнивать по ней разные команды некорректно. Различные команды используют разные шкалы, имеют разный состав работ и различную техническую среду. Важным инструментом является минимально жизнеспособный продукт. Он представляет собой минимальный вариант решения, достаточный для проверки ключевого предположения и получения содержательной обратной связи. Минимально жизнеспособный продукт не должен быть некачественным или небезопасным. Минимальность относится к объему функций, а не к обязательным характеристикам качества. Например, перед разработкой полной системы электронного согласования документов организация может создать решение для одного типа заявления и одного подразделения. Его использование покажет, соответствует ли выбранная схема согласования реальному процессу. Другим инструментом является техническое исследование, иногда называемое исследовательской задачей. Оно используется, когда команда не может достоверно оценить технологическое решение. В ходе ограниченного по времени исследования создается прототип, выполняется эксперимент или анализируется документация. Например, до выбора технологии распознавания документов можно проверить точность нескольких решений на реальном наборе материалов. Результатом исследования являются знания и решение, а не обязательно готовая функция. Гибкая разработка основывается на коротких циклах обратной связи. Обратная связь поступает от пользователей, тестов, эксплуатации, аналитики, мониторинга и других участников. Чем быстрее команда узнает о проблеме, тем меньше объем работы, построенной на неверном предположении. К гибким инструментам относятся демонстрации продукта, ретроспективы, ежедневная координация, автоматические тесты, анализ пользовательского поведения, ограниченные эксперименты и регулярное уточнение бэклога. Ретроспектива направлена на улучшение способа работы команды. Участники анализируют, что помогало достижению результата, какие препятствия возникли и какое изменение процесса следует проверить в следующем периоде. Ретроспектива не должна становиться формальным обсуждением без последующих действий. Ее результатом должно быть одно или несколько конкретных улучшений. Например, команда может изменить порядок проверки кода, сократить размер задач, автоматизировать тестирование или уточнить правила взаимодействия с заказчиком. Гибкость требует дисциплины. Чем чаще изменяется продукт, тем важнее автоматизация тестирования, управление версиями, модульная архитектура, качественный программный код и актуальная документация. Без этих условий каждое изменение становится опасным и дорогостоящим.

4.1.1 Бережливый подход Lean

Lean, или бережливый подход, представляет собой систему мышления и управления, направленную на создание необходимой потребителю ценности с использованием меньшего количества ресурсов и с сокращением потерь. Lean рассматривается не как разовый проект оптимизации, а как постоянная практика экспериментального улучшения процессов. Исторически идеи Lean развивались в промышленном производстве, однако впоследствии были адаптированы для управления услугами, разработкой продуктов и информационными технологиями. В проектировании информационных систем Lean помогает рассматривать весь поток создания ценности — от появления потребности до предоставления работающей функции пользователю. Центральным понятием Lean является ценность. Ценность определяется не разработчиком и не количеством выполненных действий, а потребностью конечного пользователя или заказчика. Работа, которая не способствует достижению требуемого результата и не является необходимой для обеспечения качества, безопасности или нормативного соответствия, должна рассматриваться как потенциальная потеря. Например, ручное копирование данных между несколькими системами не создает самостоятельной ценности для клиента. Оно может быть временно необходимым из-за отсутствия интеграции, но должно рассматриваться как потеря, подлежащая устранению. Следующим понятием является поток создания ценности. Он включает все действия от формирования потребности до получения пользователем результата. При анализе потока учитываются не только непосредственные операции разработки, но и ожидание, согласования, передачи между подразделениями, повторная работа и исправление дефектов. Например, создание небольшой функции может занимать два дня программирования, но три месяца проходить через согласование, распределение ресурсов, тестирование и ожидание выпуска. Оптимизация только скорости программирования почти не изменит общий срок. Lean требует анализировать весь поток. Для изображения потока применяется карта потока создания ценности. На ней отражаются стадии прохождения работы, длительность активной обработки, время ожидания, очереди, передачи и возвраты. Карта позволяет определить, где возникает основная задержка. Одним из принципов Lean является обеспечение непрерывного потока. Работа должна по возможности равномерно перемещаться через систему без длительных остановок, больших очередей и повторных передач. В программной разработке поток нарушается, когда аналитики создают огромный пакет требований, затем передают его проектировщикам, проектировщики формируют крупный пакет документации, а разработчики получают результаты через несколько месяцев. Ошибки и вопросы накапливаются, а обратная связь появляется поздно. Другим принципом является вытягивающая система. Новая работа начинается тогда, когда у исполнителя имеется возможность ее выполнить, а не просто потому, что задача была поставлена. Это позволяет ограничивать объем одновременно начатой работы. Если каждый сотрудник начинает множество задач, формально все задачи находятся «в работе», но ни одна не завершается. Ограничение незавершенной работы способствует концентрации и сокращает время прохождения задачи. Lean использует идею непрерывного совершенствования, часто обозначаемую термином кайдзен. Улучшение рассматривается как регулярная деятельность всех участников, а не исключительно управленческая инициатива. Небольшое изменение, сокращающее ручную операцию на несколько минут, может показаться незначительным. Однако если операция выполняется сотни раз, эффект становится существенным. Непрерывное совершенствование складывается из множества таких изменений. Важным принципом является уважение к людям. Исполнители, непосредственно выполняющие работу, обладают знаниями о реальных проблемах процесса. Поэтому изменения не должны полностью разрабатываться внешней группой и навязываться сверху. Сотрудники должны участвовать в анализе и улучшении собственного процесса. В программной разработке к потерям относят незавершенную работу, создание ненужных функций, ожидание, лишние передачи между участниками, повторное получение уже имевшихся знаний, постоянное переключение между задачами и дефекты. Незавершенная работа включает требования, модели, программные компоненты и функции, которые были начаты, но еще не приносят пользу. Она требует учета, устаревает и создает дополнительные зависимости. Избыточные функции являются возможностями, созданными без подтвержденной потребности. Каждая такая функция требует проектирования, тестирования, документирования, поддержки и обеспечения безопасности. Ожидание возникает при согласовании, передаче задачи, недоступности тестовой среды, длительной проверке кода или ожидании решения заказчика. Передачи создают риск потери контекста. Если аналитик передает документ архитектору, архитектор — разработчику, разработчик — тестировщику, а тестировщик — эксплуатационной группе, каждая передача требует объяснения и может привести к искажению смысла. Переключение между задачами снижает концентрацию и увеличивает время завершения. Сотрудник вынужден восстанавливать контекст каждой задачи. Дефекты требуют повторной работы. Особенно дорого обходятся дефекты требований и архитектуры, обнаруженные на поздней стадии. Lean не требует полного устранения всех вспомогательных действий. Некоторые из них не создают прямой пользовательской ценности, но необходимы. Например, резервное копирование, проверка безопасности и документирование могут быть обязательными для надежной эксплуатации. Задача заключается в том, чтобы выполнять необходимые действия эффективно и исключать необоснованные. Одним из инструментов Lean является метод «пять почему». При возникновении проблемы последовательно задается вопрос о ее причине, чтобы перейти от непосредственного проявления к корневому фактору. Например, выпуск системы задержался, потому что интеграционное тестирование началось поздно. Тестирование началось поздно, потому что среда не была подготовлена. Среда не была подготовлена, потому что ее создание выполнялось вручную. Ручной порядок сохранялся, потому что инфраструктура не была описана программно. В результате улучшение должно быть направлено не только на ускорение тестировщиков, но и на автоматизацию подготовки среды. Другим инструментом является стандартизированная работа. Для повторяющихся действий определяется лучший известный на текущий момент способ выполнения. Стандарт не является неизменным правилом: он служит исходной точкой для дальнейшего улучшения. В информационных технологиях стандартизироваться могут правила проверки кода, выпуск версии, обработка инцидента, создание нового сервиса, оформление архитектурного решения и настройка мониторинга. Lean тесно связан с уменьшением размера партии. Небольшие изменения проще анализировать, тестировать и выпускать. При возникновении ошибки легче определить ее источник и выполнить откат. Например, выпуск одной версии, содержащей двести изменений, создает высокий риск и требует сложного тестирования. Регулярные небольшие выпуски позволяют быстрее получать обратную связь и уменьшают объем потенциально ошибочной работы. Bережливый подход не следует смешивать с простым сокращением затрат. Увольнение сотрудников или отказ от тестирования может временно уменьшить расходы, но увеличить потери, дефекты и длительность работы. Lean направлен на устранение причин неэффективности, а не на механическое сокращение ресурсов.