Анализ и проектирование

Записаться

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

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

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

В этом модуле мы сосредоточимся на анализе требований. Обратимся к лучшим практикам, которые есть в этом виде деятельности, – они помогут нам не блуждать в самостоятельном поиске лучшего решения для конкретной практической задачи, а выбрать то, которое наиболее нам подходит. Затем мы рассмотрим проектирование и методы, используемые для исполнения процесса проектирования, а также технологии, которые сопровождают этот процесс с самого начала до момента его окончания. Этот момент характеризуется созданием архитектуры, которая является отражением созданного продукта и позволяет сфокусироваться на наиболее значимых атрибутах создаваемой системы. Архитектура в своей основе использует требования. Лучшим на сегодняшний день подходом и инструментом работы с требованиями является UML – унифицированный язык моделирования. Это лучшая практика в визуализации и представлении требований в едином архитектурном решении. Наиболее известный подход к описанию архитектуры называется 4 + 1. О нем мы тоже подробно поговорим.

Итак, анализ требований. Вернее, если отталкиваться от наиболее корректных и точных переводов, то мы говорим о сфере инженерии требований, которая накопила определенный багаж практик. Часть из них еще сильно не стандартизированы, но другая часть уже зафиксирована в международных стандартах, описывающих разные аспекты создания информационных систем. Инженерия требований, как самодостаточная область деятельности, содержит этапы и аспекты, которые необходимо помнить и выполнять для достижения запланированного результата. Разделим их на три категории. Это управление, работа над требованиями и дополнительные активности – ядро. Основная производственная категория – это работа над требованиями. Немного неграмотно с точки зрения русского языка, но наиболее точно с точки зрения сути – это требования к тому, какими должны быть требования. Первый ГОСТ – ИСО 29148 – описывает, какими характеристиками должны обладать требования. Следующий ГОСТ – ИСО 241765, он регламентирует то, как использовать требования для создания информационных продуктов. И последний – ИСО 25010. Он помогает выделить атрибуты и аспекты информационных систем, которые нужно учитывать при разработке и управлении требованиями. На этом с первой категорией все. Следующая категория – управление. Тут два основных ГОСТа. Первый – ИСО 15288. Это жизненный цикл создания требований. Он описывает, из каких этапов должна состоять работа с требованиями. Второй, более практичный, – ИСО 26702. Он объединяет различные этапы работы над требованиями в набор различных процессов, каждый из которых нужно использовать в заданных условиях и ограничениях. И последняя категория – дополнительные. Эта стартовая категория для всех активностей, которые нельзя отнести к основной или управленческой категория. Постепенно, когда она расширится, из нее выделятся другие категории, объединенные единым смыслом. В дополнительных находится ГОСТ 24766. Это инструментарий работы с требованиями, объясняющий, какими инструментами необходимо пользоваться в зависимости от выбранных подходов, этапов и процесса работы над требованиями. Все ГОСТ и ИСО содержат только проверенную на большом массиве практических задач и проектов информацию, но, когда на практике сталкиваются с новой проблемой, для которой не подходит ГОСТовое решение, у специалистов вырабатываются и развиваются навыки, помогающие в решении конкретной профильной задачи. На этом этапе появляются лучшие практики, или, как говорят, best practice. В работе над требованиями такие есть. Это своды знаний (Body of Knowledge), которые описывают проверенный и хорошо себя зарекомендовавший опыт, который выражается в подходах, методиках и используемых инструментах. Для инженерии требований есть два основных Body of Knowledge. Один из них описывает работу с людьми и извлечение из них самым эффективным образом наиболее ценных требований – это BABOK (Business Analysis Body of Knowledge). Бизнес-анализ Body of Knowledge. О техниках и методах, сосредоточенных в нем, у нас будет отдельная лекция. Следующий – SWEBOK (Software Engineering Body of Knowledge). Он описывает требования создания информационных систем, то, как нужно классифицировать, учитывать, трассировать разные требования для достижения запланированных результатов. Эти своды знаний описывают, как работать над разными перспективами одной системы. Оба труда являются очень ценными, востребованными и развиваются профессиональными сообществами заинтересованных профессионалов. Ну и третий свод знаний, который является стандартом, но включен здесь, – ИСО 15288. Мы говорили о нем ранее. Этот ГОСТ описывает этапы инженерии требований. Он позволяет связать различные техники и инструменты, используемые в BABOK и SWEBOK, в единый производственный процесс – процесс, который приводит к формированию требований, запускающих процесс проектирования.

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

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

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

Перечислим самые известные и распространенные на сегодняшний день методы. ГОСТ 34 – это типичный и наиболее известный представитель канонического проектирования. Этот метод многие годы был единственным методом проектирования в нашей стране, что привело к его вышколенности на большом количестве практических проектов. Его критикуют, и за дело, но он приносит результат. Следующий метод – MSF (Microsoft Solutions Framework), который развился за счет продвижения компанией Microsoft для внедрения и развития своих продуктов. Это архитектурная методология, которая разбивает проект на ряды групп практик, каждая из которых выполняется для достижения результатов. Следующий метод – RUP (Rational Unified Process), отработанный процесс, который в основе использует юнифицированный язык моделирования технических артефактов. Этот метод развился из-за его продвижения компанией IBM, и развился настолько сильно, что UML фактически считается стандартом для визуализации требований. Ничего лучше предложено не было, но этот метод не используется  повсеместно из-за его высокой сложности. Следующий метод – TOGAF (The Open Group Architecture Framework). TOGAF в своей основе имеет методику ADM. Это методика выработки и принятия решений на каждом уровне экспертизы, опоясывающей компанию. Это сложный, распространенный и эффективный метод. На есть и разные другие методы, которые либо не получили известность из-за своей сложности и затратности, как квадрант Захмана, либо еще развиваются и им предстоит доказать свою уникальность. В своей основе методы используют инструменты.

Самый популярный и хорошо себя зарекомендовавший инструмент – UML (Unified Modeling Language). Этот целое семейство диаграмм, каждая из которых описывает свой контекст системы. В полной версии UML включает в себя 17 разных диаграмм, но практическую ценность несут лишь некоторые из них, а точнее, пять. Другие диаграммы важны и полезны, но их использование на практике не так распространено. В своей практической деятельности в процессе выполнения более чем 50 проектов я видел не более семи разных типов диаграмм. Так что это за диаграммы и почему используются именно они?

Мы подошли к архитектурному подходу 4+1. Этот подход предложен Филиппом Крутченом в 1995 году. Данная методика позиционировалась как способ описания архитектуры систем, основанных на активном использовании программного обеспечения. 4+1 предлагает использование пяти различных представлений для описания архитектуры сложных систем. Она основывается на объектно-ориентированной парадигме проектирования и исключает другие.

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

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

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

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