Главная картинка статьи №37

Еще немного о требованиях и соответствующих им архитектурных рисках


И снова мы :)

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

Продолжаем …

Прочие виды требований

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

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

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

  • Время:

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

  • Финансы:

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

  • Данные и информация:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

Авторы статьи

Иван Никитин

Михаил Цулая