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

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

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

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

Введение

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

Что же планируем изучить?

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

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

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

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

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

Влияние стандартов на процессы архитектурного проектирования

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

• Анализ требований;
• Проектирование;
• Кодирование;
• Тестирование;
• И т. д;

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

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

Должны быть учтены такие аспекты, как:

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

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

Перечень стандартов и их содержание на конкретном предприятии должно определяться на стадии планирования.

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

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

В качестве отступления мы приведем следующий пример.

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

• Стандарт на работу с требованиями;

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

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

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

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

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

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

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

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

• Конкретность/измеримость;
• Корректность/обоснованность;
• Соответствие функциональности программного продукта;
• Возможность последующей верификации;
• Уникальность;
• Последовательность;
• Непротиворечивость;
• Возможность декомпозиции;
• Изменяемость с минимальными затратами;
• Трассируемость;

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

Но изменения, иногда вносятся и в "скелет".

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

Принципы и темп развития современного мира определяют его черты.

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

Можно привести следующий пример:

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

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

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

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