Преамбула

Доброго времени, Уважаемые коллеги!

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

Влияние внешних событий и атрибутов на архитектуру программного обеспечения

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

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

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

Факторы «контекста», которые являются внешними событиями и атрибутами по отношению к архитектуре программного обеспечения, это:

• Миссия бизнеса, которую будет поддерживать архитектура программного продукта;

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

• Цели и задачи бизнеса;

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

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

• Заинтересованные в успешном функционировании системы лица/стороны;

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

Ранее мы затрагивали тему стэйкхолдеров, когда рассуждали о требованиях, необходимых для создания аналитической архитектуры программного обеспечения;

• Внутренние технические ограничения;

Существуют «внешние» технические ограничения, которые связаны c конкретной технологией создания, сопровождения, развития программного продукта (язык программирования, его новизна и темпы развития, применяемая технология хранения данных, и т.п.), игнорировать и не учитывать влияние которые не представляется возможным.

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

• Внешние ограничения;

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

Для примера можно привести:

1. Необходимость взаимодействовать с внешней системой;
2. Соответствие внешним регулятивным нормам (законам и постановлениям правительства, отраслевым стандартам).

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

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

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

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

Необходимый и достаточный набор и объем документации для создания и развития архитектуры программного обеспечения

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

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

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

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

От согласованного масштаба программного продукта зависят:

• Ресурсы для документирования;

Целесообразно создавать в реальных проектах только те шаблоны документов, использование и развитие которых экономически целесообразно;

• Масштаб проекта и спецификация требований;

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

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

• Разработчики:
  • Формируют представление о сложности, размере, характеристиках создаваемой системы;
• Аналитики:
  • Получают информацию, необходимую для создания различных видов спецификаций требований к программному продукту, валидируют соответствие системы требованиям к существующим законам и постановлениям;
• Руководство проекта:
  • Основание для расчета содержания работ над спецификациями и необходимых ресурсах;
• Тестировщики:
  • Создают планы тестирования, варианты испытаний, процедуры проверок;
• Системные администраторы;
  • Получают представление о функциональности каждой составной части продукта;
• Целевые бизнес пользователи;
  • Формируют конечное представление о программном продукте, изучат его;
• Специалисты, ответственные за обучение персонала:
  • Получат спецификации требований и документацию для разработки обучающих материалов;

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

Вместо прощанья

Не прощаемся. Обрываемся на полуслове….

Встреча будет скорая!

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

Иван Никитин

Михаил Цулая