Разработка архитектуры программного обеспечения. Аналитический синтез информации

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

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

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

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

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

• Всеми видами требований;
• Функциональными и нефункциональными процессами;
• Результатами;
• Необходимой отчетностью;

Оптимально выстроенный процесс трассирования должен ясно и однозначно позволять понять что (?), откуда (?), каким образом (?) вышло, и куда (?), и в каком виде (?) поступило.

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

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

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

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

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

При выполнении тестирования должны быть решены 2 основные задачи:

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

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

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

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

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

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

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

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

Риски реализации архитектуры и методы управления ими

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

Риск – это потенциальная возможность наступления вероятного события/явления или их совокупности, которые могут вызывать определенное влияние (негативное или позитивное) на осуществляемую деятельность или реализуемый продукт.

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

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

• Попытка создания оптимальной архитектуры на основе уже существующей, но не удовлетворяющей ожидания заказчиков;

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

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

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

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

• Риск смены разработчика;
• Риск ошибочно принятого архитектурного решения;

Эти риски сильно влияют на предсказуемость процессов перепроектирования и разработки программного продукта. Что характерно, наступление первого усиливает вероятность наступления второго.

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

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

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

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

Этот метод позволяет подойти к необходимым доработкам с позиции необходимых и достаточных трудозатрат и не тратить ценные ресурсы на "холостые ходы".

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

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

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

Поэтому важно контролировать:

• Детали реализации архитектуры и функциональности информационной системы;
• Влияние принятых изменений:
  • Не только на сам продукт, но и на величину ресурсов, необходимых для разработки и сопровождения (как бизнес, так и технических) принятых изменений;
• Ограничения, которые сопровождают:
  • Разработку программного продукта;
  • Жизненный цикл программного продукта с момента его выхода на рынок;

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

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

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

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

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