Цель: мы планируем подвести итоги рассмотрения области требований и их таксономии, подытожив их комплексной информацией по данной активности.
Изложенная информация будет являться базисом для тех коллег, которые затем изъявят желание расширить свои компетенции в направлении инженерии требований.
Сегодняшняя лекция будет способствовать развитию навыков, которые обеспечат будущим системным архитекторам и заинтересованным коллегам необходимые профессиональные качества для управления процессами создания обоснованных и оптимальных архитектур программных продуктов.
Сегодняшняя тема выдвигает особые требования к содержанию лекции. С одной стороны, надлежащее представление обозначенного содержания является довольно трудной и амбициозной задачей, но с другой, ради поставленных целей, каждому из нас придется соответствующим образом взглянуть на имеющийся у него информационный багаж, профессиональные навыки и, при необходимости, переосмыслить и пересмотреть их.
Что же планируем изучить?
На сегодня мы накопили определенный объем данных, который должен быть использован на благо домену информационных технологий в области проектирования и разработки архитектур программных продуктов (а может и не только). Но, пока что мы рассуждали только о различных активностях, объектах, связях по отдельности.
Настала стадия курса, когда накопленная информация должна перейти на качественно новый виток. Под этим переходом подразумевается возможность и желание взглянуть на имеющиеся данные с точки зрения их комплексного рассмотрения в виде единой системы неразрывных причинно-следственных связей, каждая из которых оказывает определенное влияние не только на смежные с ней части информационной системы, а на архитектуру в целом.
Подобное "рабочее" мировоззрение формирует не только целостно-комплексное отношение к любой задаче, но и делает возможным профессионально, с адекватными экспертными оценками, выполнять управление соответствующей деятельностью.
Как мы отмечали ранее, документирование архитектуры - это не просто формальная активность в процессах создания программных продуктов, а направление, в ходе которого создаются артефакты программного продукта, позволяющие сопровождать весь жизненный цикл программного продукта и создавать архитектуру и функциональность заданного качества, в соответствии с ресурсами, выделенными на это. Надлежащее документирование информационных систем является определенным показателем продуманности, а соответственно и эффективности по сравнению с недокументированными решениями в силу того, что сам процесс документирования архитектуры ведет к комплексному обдумыванию того, что находится в фокусе работы.
Если программная архитектура не подкреплена актуальными документами, а её реальные характеристики существуют только в виде "устных преданьев", то доказать адекватность характеристик, разработанных на базе требований, представляется затруднительным и неблагодарным трудом.
Осмысленная разработка программных продуктов - комплексное понятие, состоящее из множества высокоинтеллектуальных и взаимосвязанных процессов, таких как:
Каждая из обозначенных активностей должна основываться на базе соответствующих стандартов и лучших практик. Дело в том, что подобный тип документов создается на основе наиболее успешного опыта применения специфического вида деятельности, рабочей технологии или артефактов, эталонное описание которых он содержит. Стандарт концентрирует все лучшее и наиболее эффективное, с точки зрения практического достижения конечного результата, подтвержденного массивом статистических данных.
Перед тем как внедрять стандарты в процессы конкретной организации, следует соответствующим образом адаптировать их под реалии конкретной организации.
Должны быть учтены такие аспекты, как:
Если тема применения и использования стандартов в целях повышения эффективности деятельности Вас заинтересовала, то мы рекомендуем обратиться к моделям зрелости CMMI, методологии SPICE и другим подобным документам. В настоящей лекции мы больше к данному аспекту, влияющему на качество архитектуры и архитектурного проектирования, возвращаться не будем.
Перечень стандартов и их содержание на конкретном предприятии должно определяться на стадии планирования.
В момент планирования перечня стандартов, который действительно необходим, целесообразно руководствоваться принципом "золотой середины". Чрезмерное количество внедряемых стандартов требует достаточно большого количества ресурсов. Следует осознавать – внедрение стандарта делает процесс более унифицированным и качественным за счет его регламентации, но при этом, в отдельных аспектах, понижает степень его гибкости. Если компания пришла к пониманию необходимости внедрения определенной практики или стандарта эволюционным путем, то это облегчает и упрощает процесс внедрения и использования соответствующего регламента. Если изменения носят революционный характер, то попытка привнести в организацию избыточное количество стандартов может носить катастрофический характер и остаться "на бумаге", что не является целью их внедрения.
Стандартизация должна обеспечить постепенное повышение качества конкретных процессов (анализ, документирование, кодирование и т.д.), обеспечить прозрачность, однозначность и не противоречивость процессов, минимизацию или устранение появления возможных ошибок при разработке архитектур и программных продуктов.
В качестве отступления мы приведем следующий пример.
Требования к процедуре сертификации авиационных продуктов предусматривают, что в процессе разработки специфического (для авиационных нужд) программного обеспечения, должны использоваться как минимум три стандарта:
Должен описывать методы, правила и инструменты, применяемые для сбора, разработки и управления требованиями, их возможные форматы и нотации.
Содержит правила, формирующие архитектуру программного продукта, приемлемые и неприемлемые методы её разработки, описывает возможные функциональные и не функциональные ограничения (запрет на использование рекурсии или максимальная вложенность вызовов).
Регламентирует исходный код программы, ссылки на описания используемого языка программирования, его синтаксис, ограничение, желательные и нежелательные конструкции языка и прочие правила, касающиеся разработки кода программы;
Стандарты определяют рабочие принципы, которые должны действовать на всем протяжении жизненного цикла программного продукта. Например, если в стандарте зафиксировано, что нельзя вставлять комментарии в программный код (комментарии следует располагать в строго определенном месте) то, все комментарии, расположенные не в соответствии с этим правилом, должны быть перенесены или удалены. Несоответствие принятым стандартам грозит возникновением потенциальных ошибок. Если стандарт по каким-то причинам не соблюдается, то все "нарушения" должны устраняться. Если стандарт требует доработок в связи с изменившимися первоначальными предпосылками его создания, то его необходимо либо дорабатывать, либо менять. Слепое следование стандартам губительно, так же, как и постоянные попытки обойти их по необоснованным причинам.
Проектирование архитектуры программных продуктов - это одна из активностей, для которых должны быть приняты определенные стандарты деятельности. При этом, современные требования к архитектурам предусматривают создание достаточно гибких и адаптивных архитектур.
Первое, "верхнеуровневое" проектирование, должно удовлетворять цели достаточно свободной и абстрактной реализации архитектуры, но при этом учитывать жесткие требования стандартов. Поэтому требования к программным продуктам принято делить на 2 типа критичности – высокоуровневые (функциональные) и низкоуровневые (нефункциональные) требования. Гибкость архитектур реализуется за счет разной степени принципиальности учета требований и их последующей реализации в программном коде будущих информационных систем. Требования к нефункциональным характеристикам должны быть более четкими и однозначными.
Типы требований мы уже немного обсуждали ранее и будем продолжать это делать по ходу нашего курса, изучая различные аспекты архитектур и архитектурного проектирования. Сейчас отметим, что подход к работе с ним должен быть также соответствующим образом стандартизован. За счет стандартов важно достичь согласованности между типами требований в момент их согласования друг с другом в виде отдельных компонентов архитектуры или программного продукта. Это позволит добиться непротиворечивого результата, в виде оптимальной архитектуры и эффективного программного обеспечения.
Большинство современных стандартов, описывающих работу с требованиями, выдвигают следующие характеристики, которым должен отвечать каждый из них:
На сегодняшний день существует множество программных продуктов, которые позволяют автоматизировать и унифицировать процесс разработки и последующего отслеживания требований. Применение специализированного инструментария, поддерживающего принятые стандарты, в большинстве случаев, положительно сказывается на качестве процессов архитектурного проектирования, разрабатываемых архитектурах и программных продуктов в целом, за счет того, что их использование позволяет выявить те программные компоненты и детали, которые подвержены изменениям меньше остальных. Именно они и составят основу разрабатываемых архитектур, которая будет наименее гибкой, а те требования, которые чаще других изменяются, будут лежать в основе достаточно гибкой функциональности.
Но изменения, иногда вносятся и в "скелет".
Принципиальное следование всем принятым стандартам возможно только тогда, когда речь идет об устоявшихся отлаженных процессах архитектурного проектирования и разработки информационных систем, которые достигли своей наивысшей точки качественного развития. Утопия.
Принципы и темп развития современного мира определяют его черты.
Программные продукты, как часть этих черт должны быть в состоянии поддерживать соответствующую динамику и темпы. Элементы информационных систем и их архитектура предназначены для удовлетворения требований к разрабатываемым продуктам. Стоит понимать, что требования не только могут изменяться, но и качественно трансформироваться, переходя из категории нефункциональных в функциональные и наоборот.
Можно привести следующий пример:
В случае, если речь идет о стадии внедрения ПО, то такая характеристика как сопровождаемость воспринимается пользователями, как некритичная и не значимая с их точки зрения, но как только начинается стадия промышленной эксплуатации программного продукта, затраты на его поддержку и развития сразу дают о себе знать. Хорошо, если компания имеет достаточный для этого ресурс, но если это не так, то поддержка процессов и соответствующего для их выполнения уровня данных "кочует" на плечи бизнес пользователей и сразу переходит в разряд функциональных.
Все вышесказанное явно свидетельствует о значимости и необходимости стандартизированного подхода к созданию новых, инновационных, прорывных информационных продуктов, которые в своей основе будут иметь надежные, качественные, производительные и масштабируемые архитектуры, которые позволят создавать функционально гибкие продукты.
Без четких, ясных требований к выполняемым функциям создать программное обеспечение невозможно. Требования – фундамент каждой разработки.
Процессы разработки должны начинаться с процесса разработки требований и вестись в соответствии с планом, корректируемым по "ходу".
Для перехода от набора требований, порой разрозненных, к стройной и логичной архитектуре программного продукта, нужно использовать специализированный инструментарий. В нашем случае это специальные технологические средства разработки и моделирования процессов, на основе выявленных требований, которые позволят создать единое видение разрабатываемой архитектуры, с учетом определенных правил представления информации, принятой для конкретного проекта по созданию программного продукта или процесса архитектурного проектирования.
Тему правил, методов, методологий, в соответствии с которыми разрабатывается архитектура программных продуктов, мы будем подробно рассматривать в лекции №4.
Как было отмечено ранее, архитектурное проектирование информационных систем - это область деятельности, которая имеет много общего с архитектурным проектированием в строительстве.
"Строительство" - старший собрат информационных технологий. Поэтому было бы оптимально, для процессов создания программных продуктов многое необходимое для развития данной профессиональной области, почерпнуть, поинтересовавшись тем, как в строительстве успешно решались схожие задачи. В гражданском и промышленном строительстве языком описания архитектуры являются архитектурно-строительные чертежи, объемные прототипы и модели, текстовые описания возводимых объектов. Младший собрат поступил правильно и перенял необходимый опыт у старшего. В качестве средств разработки и моделирования характеристик информационных продуктов, в архитектурном проектировании используются различные языки, которые принято называть нотациями, а инструментами, которые поддерживают работу с нотациями - CASE средствами.
Из современных нотаций можно выделить следующие:
Данный тип схем (графических моделей) визуализирует разрабатываемые алгоритмы или процессы. В описании блок-схем принято отдельные стадии процессов изображать в виде блоков (отсюда и соответствующее название данной нотации). Блоки различаются в зависимости от семантики, содержащейся в представляемой ими форме. Отображаемые блоки соединены между собой линиями, имеющими направление и определенную алгоритмами последовательность.
В широком значении термина "блок-схемы" он является метанотацией. Различные спецификации "блок-схем" получили свое определенное назначение и форму представления необходимой информации, в зависимости от специфики каждой конкретной нотации, но при этом общие правила построения моделей наследуются от правил построения "блок-схем".
DFD – это нотация структурного анализа.
В данной нотации принято описывать внешние, по отношению к разрабатываемому продукту:
Диаграмма потоков данных - это один из первых и основных инструментов структурного анализа и проектирования верхнеуровневой архитектуры программных продуктов, существовавших до последующего широкого распространения UML.
В основе данной нотации находится методология проектирования и метод построения модели потоков данных проектируемой информационной системы. В соответствии с соответствующей методологией проектирования модель системы идентифицируется как иерархия диаграмм потоков данных, которые представляют собой последовательный процесс преобразования данных, с момента их поступления в систему, до момента представления информации конечному (или псевдоконечному) пользователю.
Диаграммы потоков данных разработаны для определения основных процессов или модулей программного продукта. Далее, в целях комплексного представления разрабатываемой архитектуры, они детализируются диаграммами нижних уровней представления информации (DFD) и процессов (IDEF). Подобный принцип отображения данных продолжается, реализуя многоуровневую иерархию подчиненных и взаимосвязанных диаграмм. В результате будет достигнут нужный уровень декомпозиции, на котором процессы становятся абсолютно понятными и прозрачными.
В современных процессах разработки программного обеспечения подобный подход к проектированию программных продуктов практически не применяется, по причине смещения акцентов создания информационных систем от структурного к объектно-ориентированному подходу.
Данная методология анализа и проектирования на сегодняшний день эффективно используется в бизнес-анализе и соответствующих дисциплинах, по причине ее наглядности и понятности для стэйкхолдеров.
ER – это тип нотации, задача которой состоит в создании формальной конструкции, описывающей и визуализирующей верхнеуровневое представление бизнес объектов будущей системы, их атрибуты и связь между ними, в виде основных элементов, которые будут использоваться в качестве фундамента для проектирования таблиц будущей базы данных программного продукта. Таким образом, ER-диаграмма представляется как концептуальная модель создаваемой информационной системы, в терминах конкретной предметной области. Данный тип диаграмм помогает выделить ключевые сущности и определить связи между ними. На сегодняшний день существует достаточно мощный инструментарий, который может позволить выполнить преобразование созданной ER-диаграммы в конкретную схему базы данных на основе выбранной модели данных.
Событийная цепочка процессов – это тип нотации, задача которой заключается в создании моделей бизнес процессов. Она используется для моделирования, анализа и реорганизации бизнес-процессов. Ее отличие, от ранее рассмотренных, состоит в том, что EPC применяют для создания функциональных моделей, имитирующих конкретные процессы, реализуемые в определенном программном продукте.
История развития данного типа диаграмм связана с разработкой одноименного метода в рамках работ по созданию методологии ARIS (Architecture of Integrated Information Systems - Архитектура интегрированных информационных систем).
Диаграмма EPC оформляется в виде упорядоченной последовательности событий и функций. Каждая функция при этом должна определяться начальными и конечными событиями, могут быть указаны участники, исполнители, материальные и информационные потоки, сопровождающие отдельные функции. Дополнительную ценность диаграммам EPC придает тот факт, что она может использоваться для настройки программных продуктов типа ERP, в части создания или улучшения бизнес-процессов.
Один из самых распространенных типов нотаций на сегодняшний день – это BPMN (Business Process Model and Notation).
EPC, ER, BPMN - это не просто нотации, а методы реализации конкретных моделей процессов. BPMN по своему назначению более уместно сравнивать c диаграммами EPC. Причина этого заключается в том, что они имеют схожую цель – функциональное моделирование бизнес процессов. Рассматриваемая диаграмма самый новый, из приведенных в обзоре, принятый стандарт моделирования бизнес процессов. Главное позиционируемое преимущество диаграммы BPMN – понятная всем стэйкхолдерам разрабатываемой архитектуры и программного продукта визуализация моделируемых процессов.
Нотация имеет достаточно ясный инструментарий, позволяющий моделировать как относительно простые, так и сложные бизнес-процессы. Это достигается за счет применения двух групп элементов:
Подобная преемственность инструментария групп BPMN позволяет удовлетворять требованиям комплексной нотации и управлять более сложными ситуациями моделирования.
Оптимально смоделированные диаграммы BPMN могут применяться для настройки, рефакторинга и реинжиниринга бизнес процессов во многих современных информационных системах класса ECM.
UML (Unified Modeling Language) - не просто нотация или группа нотаций, а язык графического описания для объектного моделирования.
UML - это язык широкого профиля, который создан для формирования серии нотаций, поддерживающих полный цикл разработки, как архитектуры, так и функциональности программных продуктов, реализуемых по принципам объектно-ориентируемого программирования.
Широкая распространенность и повсеместное применение данного языка привели к тому, что он стал открытым стандартом, использующим графические обозначения для создания моделей систем, которые принято называть UML-моделями. Специфика UML не предполагает ориентацию на описание архитектуры, так как основное его назначение заключается в определении, визуализации, проектировании, документировании, преимущественно программных продуктов, бизнес процессов и структур данных.
Язык UML получил популярность за счет жесткой связки с популярной и распространенной методологией разработки и внедрения программных продуктов RUP, в соответствии с которой организована работа многих консалтинговых и производственных компаний отрасли информационных технологий. Не смотря на множество преимуществ, UML не является панацеей и абсолютным универсумом в процессах проектирования архитектур и программных продуктов.
Применять и разбираться в диаграммах UML могут только узкоспециализированные специалисты области проектирования программных систем. Вовлечь в обсуждение и согласование разрабатываемой архитектуры информационного продукта, задокументированного на UML, стэйкхолдеров, представителей не направления информационных технологий, будет достаточно сложно.
UML, в отличие от ER и BPMN диаграмм, поддерживает генерацию не просто отдельной функциональности, привязанной к специфичным типам информационных систем, а целостного программного кода на основании сформированных UML-моделей.
Самая специфичная и наименее распространенная нотация из всех рассматриваемых в данной лекции.
EIP (Enterprise Integration Patterns) диаграммы - это набор из 65 шаблонов диаграмм, которые предназначены для описания специализированных процессов взаимодействия между программными продуктами. Специфика данной нотации состоит в том, что она разработана для описания конкретных процессов, обеспечивающих интеграционное взаимодействие между приложениями и функциональность программных продуктов, ориентированных на обмен сообщениями между информационными системами.
Шаблоны интеграции приложений и необходимая функциональность, описание которых поддерживают EIP диаграммы, встроены в множество современных специализированных открытых программных продуктов и доступны для применения в специализированных интеграционных процессах.
На сегодняшний день, в силу своей специфичности, данный вид нотации не имеет широкого распространения, но, учитывая темпы роста популярности интеграционных процессов, можно спрогнозировать, что в ближайшее время интерес к EIP-диаграммам вырастет.
Модели, как таковые, не являются нотациями, а представляют собой набор необходимых для реализаций процессов/подпроцессов, представленных в виде нескольких взаимодополняющих друг друга нотаций, с целью моделирования конечного результата. Говоря о модели, со структурной точки зрения, корректно будет сказать, что это "метанотация", включающая в себя несколько основных нотаций, реализация диаграмм которых запланирована для качественной разработки конкретной архитектуры.
Таким образом, модель – это абстракция, которая фокусирует субъект, работающий с ней на основных, критичных для реализации, характеристиках конечного продукта. Из примеров CASE средств, способных реализовать и представить нотации в виде модели можно выделить ARIS, UML.
Так же возможна схема, когда исполнитель разработает необходимые диаграммы в разных CASE средствах, после чего компилирует модель самостоятельно. В таких случаях дальнейшее сопровождение и развитие модели затруднительно (сложность сопровождения, развития, управления моделью) и целиком и полностью лежит на "плечах" ответственных за это специалистов.
Когда мы говорили о моделях, то отметили, что модель - это следующий, качественный шаг вперед к реализации программного обеспечения, по сравнению с диаграммами, реализуемыми нотациями.
После того, как реализованы несколько моделей требований, можно приступать к реализации прототипов, если это предусмотрено и спланировано в проекте разработки программного продукта.
Прототип представляет собой "черновой" вариант конечной реализации программного продукта или его компонента, разработанного с учетом определенных ограничений для демонстрации заинтересованным сторонам на определенной стадии разработки только архитектуры или программного продукта в целом.
Цель разработки прототипа – подтвердить ожидания стэйкхолдеров от реализации конечного продукта и согласовать её функциональность. Прототипы принято реализовывать в специализированном программном коде, поэтому их следует воспринимать как часть процесса разработки, но при этом не рассчитывать на то, что прототип будет являться частью будущей архитектуры или информационной системы.
Прототипы, как правило, разрабатываются достаточно быстро с помощью специализированного инструментария, освоение которого требует гораздо меньше времени и сил, чем освоение определенного языка программирования.
Жизненный цикл прототипа заканчивается в тот момент, когда ожидания стэйкхолдеров подтверждены и разработанный облик (не более) будущего продукта запланирован к реализации.
Работа по созданию интерфейсов - это отдельная область разработки программных продуктов, которая не определяет архитектуры, но в большинстве случаев зависит от неё. Именно поэтому мы решили упомянуть её в конце списка, факультативно.
Эта область требует к себе довольно много внимания и сил. Она определяет многие функциональные характеристики программных продуктов (эргономика, дизайн интерфейсов, воспринимаемость и удобство работы с информацией и т.д.).
Значимость корректных и эффективных интерфейсов все больше и больше растет для разнообразных программных продуктов. Интерфейс представляет собой "верхушку", с помощью которой пользователь будет взаимодействовать с "нутром" программного продукта.
Важно, чтобы уже на ранних стадиях разработки интерфейсов пользователь имел представление о том, с чем и каким образом ему придется работать и постепенно привыкал, при возможности корректируя его или свои ожидания от него.
На текущий момент есть множество инструментов для создания интерфейсов разной степени сложности и детальности. Мы выделим следующие Balsamiq mockup, Axure RP и пр.
Каждый крупный программный продукт или его модуль, который состоит из совокупности компонентов и связей между ними, должен быть детально описан в соответствующий момент процесса архитектурного проектирования. Описание должно быть выполнено по стандартизированным правилам организации или проекта, с использованием необходимых нотаций, для данного конкретного случая.
По принципам программной инженерии и здравой логики, которая находится в основе процессов разработки информационных систем, любая подсистема или компонент в дальнейшем может выступать в качестве составного элемента более масштабной системы. Поэтому, в архитектурном проектировании должно обязательно содержаться подробное описание укрупнённых частей системы, выполненных с помощью CASE средств и нотаций, согласованных друг с другом и обеспечивающих последующую преемственность.
Важно, чтобы выбранная нотация или серия нотаций поддерживали существующий процесс архитектурного проектирования, способствовали его развитию и совершенствованию и были "в силах" поддержать соответствующую фиксацию функциональных, нефункциональных и прочих требований к разрабатываемой архитектуре и программному продукту в целом.
Необходимо осознавать, что нет единой нотации или языка проектирования, который мог бы быть решением всех поставленных задач процесса проектирования. Сегодня существует достаточное количество универсальных инструментов и средств, но ни один из них не может обеспечить весь спектр возникающих задач проектирования.
Для того, чтобы создать достаточно комплексную и взаимосвязанную среду проектирования архитектур, моделей и функциональности программных продуктов нужно использовать инструменты и диаграммы, которые смогут поддержать процессы разработки, в зависимости от специфики конкретной задачи, но при этом должен существовать минимальный набор необходимых диаграмм, который должен присутствовать в каждом проекте по разработке программного продукта не смотря на его масштабы и значимость.
Обсуждение различных типов и видов требований мы начали в предыдущей лекции.
В этой части мы уделим больше внимания рассмотрению функциональных и нефункциональных требований к архитектуре программного обеспечения.
Принято думать, что архитектура формируется под воздействием, прежде всего, нефункциональных требований, которые, в большинстве случаев, отсутствуют в проектируемых функциональных и бизнес моделях систем, но начинают свой жизненный цикл в процессе реализации программных продуктов. Попробуем обосновать, что это не совсем верно.
Многие современные ученые области инженерии требований высказывают мнение о том, что не бывает нефункциональных требований.
Нефункциональные требования - это абсолютно функциональные требования, которые описывают функции системы с точки зрения "каких-то" стэйкхолдеров, о которых забыли в процессе сбора и анализа требований. Вы знаете какое-нибудь программное обеспечение, в процессе разработки которого активно участвовали будущие специалисты групп сопровождения, тестирования, развития его архитектуры и функциональности? Как часто проектируя программные продукты о многих его характеристиках, не значимых на первый взгляд для бизнес стейкхолдеров, но критичных для других пользователей, просто забывают или намеренно игнорируют, считая их не значимыми и второстепенными.
Ранее мы показали, что члены группы поддержки, тестирования, системные администраторы и некоторые другие технические специалисты являются такими же стэйкхолдерами, как и будущие основные бизнес пользователи системы. Игнорирование их требований может привести к тому, что фаза внедрения пройдет достаточно успешно, но вот последующее сопровождение и развитие системы может быть достаточно проблематичным.
Основная задача заключается в том, что для современного бизнес мира "последующее" значит то, о чем можно забыть сегодня и не вспоминать до тех пор, пока забытое не напомнит о себе. В случае с нефункциональными требованиями такой подход к работе может оказаться слишком дорогостоящим. Как только информационный продукт перейдет в стадию промышленной эксплуатации и над ним начнут работать группы специалистов, которые должны будут поддерживать достаточно высокий уровень сервисной поддержки и развития системы, может оказаться, что его реализация не включает в себя множество разнообразных технических аспектов. Ведь именно от таких аспектов зависит качество продукта, обеспечивающее оптимальность бизнес процессов, моделей и данных. Довольно распространенная ситуация, когда на ранних фазах создания программных продуктов о таких характеристиках как надежность, быстродействие, безопасность многие специалисты и стэйкхолдеры, вовлеченные в процесс проектирования архитектуры и функциональности просто не задумываются, отдавая их на дальнейшую проработку и реализацию разработчикам. Все бы хорошо, но для разработчиков существует множество факторов, в соответствии с которыми, модели программных компонентов, которые не имеют четких требований будут реализованы не так как задумывалось при составлении специализированных документов, а так, как разработчик "сможет". Это "сможет" будет определяться квалификацией, инструментарием и, конечно же тем количеством времени, которое у него/них будет в наличии, а его, как известно, практически всегда не хватает. Таким образом, получается следующий парадокс – качество продукта будет напрямую зависеть не от стэйкхолдеров, а от специалистов, для которых важность продукта, который они разрабатывают, не очевидна. Стэйкхолдерам важно получить законченную функциональность в сроки согласованных работ, а иногда даже намного, намного ранее и получить дополнительное время на реализацию качественных атрибутов, значимость которых определяется только в процессе разработки. Именно поэтому многие характеристики разрабатываемого программного продукта и его архитектуры, скрытые от внимательного взора руководства, необходимо обозначать в активностях, предваряющих стадии проектирования и разработки. Многое на этой стадии зависит от опыта и мастерства системного архитектора и его команды, от профессионализма которых будет зависеть стратегический успех информационной системы, разрабатываемой для бизнес необходимостей конкретной организации.
Этим вступлением мы постарались показать то, что требования не бывают второстепенными или незначимыми. Незначимое сегодня окажется жизненнонеобходимым завтра. Рамки работ над требованиями должны быть спланированы и ясно понятны всем стэйкхолдерам, участвующим в проекте.
После того, как мы определились с тем, что для создания качественной архитектуры не должно быть разного отношения к функциональным и не функциональным требованиям. Все требования необходимо рассматривать с точки зрения их критичности по отношению к архитектуре программного продукта.
Высокоуровневое назначение программного продукта - приносить выгоду его владельцу за счет автоматизации труда (интеллектуального, физического, монотонного и т.д. ) человека, а в идеале за счет полной замены человеческого ресурса и фактора, если это возможно.
Здесь будет уместно сравнение со строением человека, в котором есть множество органов, каждый из которых отвечает за определенную функцию и каждый развивается не только как самостоятельная единица, но и как часть целого. В тот момент, когда определенный орган дает сбой и не может поддерживать свою целевую функциональность, при условии что это не отражается на деятельности всего организма, то можно считать, что это не критично, но если весь организм выходит из строя на определенный период, то важно понять в чем состоит источник проблемы и устранить его, а если подойти системно, то не допустить подобной возможности. Таким образом, те элементы органов, которые влияют на их полную функциональность и взаимосвязаны с другими, являются наиболее приоритетными для исследования и оптимального содержания и развития. Подобными компонентами в программном продукте являются компоненты, наиболее критичные для рассмотрения с точки зрения архитектуры и сбора требования.
Но при разработке определенной информационной системы, классификация требований необходима для целей дальнейшей их трассировки и управления ими. Традиционно выделяют 2 основные группы описание которых и более подробную литературу по работе с которыми наши коллеги найдут в соответствующей литературе.
Сначала мы рассмотрим функциональные требования.
Функциональные требования описывают "поведение" системы и информацию, с которой система будет работать. Они описывают возможности системы в терминах поведения или выполняемых операций
Цель использования данной группы требований (как следует из названия) заключается в регламентации возможностей и соответствующем им поведении разрабатываемого программного продукта.
Функциональные требования должны отвечать на вопрос - каким образом должны быть алгоритмизированы процессы информационного продукта, чтобы взаимодействие между пользователем и системой удовлетворяло потребности стэйкхолдеров?
Именно с помощью функциональных требований, в большинстве случаев, определяются рамки работ по процессам, сопровождающим цикл создания программных продуктов. Данный тип требований устанавливает:
На сегодняшний день существует множество подходов к разработке и фиксации функциональных требований. Кратко рассмотрим наиболее популярные из них:
Суть классического подхода состоит в разработке требований с помощью итеративной работы с верхнеуровневыми требованиями стэйкхолдеров, и постепенной детализации до уровня понятного разработчикам. Это наиболее изученный и популярный подход, который подробно описан в современной литературе. Мы можем порекомендовать для изучения книги К. Вигерса, которые уже упоминались нами ранее.
Дополнительно отметим, что в подобном подходе основная тяжесть создания полноценного документа, охватывающего весь программный продукт, ложится на сотрудника, ответственного за сбор, анализ и синтез информации. При современной динамике изменений бизнес процессов и данных, поступающих от внешних и внутренних аспектов бизнеса, непосредственно влияющих на требования стэйкхолдеров, классический подход становится наименее эффективным. Именно поэтому в последнее время водопадные модели разработки программного обеспечения заменяются "гибкими" подходами (agile), цель которых в быстром и эффективном решении возникающих задач, даже если следующая будет противоречить предыдущей.
В этом подходе функциональные требования записываются с помощью системы специализированных правил, которые, к примеру, должны фиксироваться следующим образом: "программный продукт должен обеспечить учетчику возможность формирования акта выдачи бланков строгой отчетности".
Если определить максимальное количество возможных вариантов использования разрабатываемого программного продукта предполагаемыми целевыми пользователями, то мы получим достаточно полные функциональные требования.
Но, при попытке тотального применения к работе над функциональными требованиями этого подхода существует вероятность того, что отдельные, незначимые для определенных стэйкхолдеров, потребности будут не учтены. В этом случае существует вероятность упустить суть конкретных функциональных требований, которые, как правило, скрыты от постороннего взгляда. Чтобы этого не произошло, важно использовать в обработке зафиксированных use cases классический подход, в рамках которого должен быть проведен анализ, систематизация и синтез информации. Это поможет выявить истинное назначение предполагаемого к реализации функционала и не разрешить отдельных деталей.
Нефункциональные требования, в дополнение к функциональным, направленны на обеспечение технической целостности разрабатываемого функционала и поддержку характеристик реализуемого программного обеспечения, которые необходимы для создания оптимальной архитектуры.
Они регламентируют внутренние и внешние условия функционирования программного продукта. Выделяют следующие основные группы нефункциональных требований:
Нефункциональные требования описывают условия, которые не относятся к поведению и функциональности системы, но обеспечивают их на уровне компонентов архитектуры программного продукта.
Ранее описанная методология use cases может быть применена для сбора и анализа нефункциональных требований. При взаимодействии со стэйкхолдерами необходимо фиксацию каждого правила подытоживать фиксацией нефункциональных требований, выраженную в виде количественной характеристики определенного параметра: "программный продукт должен обеспечить учетчику возможность формирования акта выдачи бланков строгой отчетности за время не более 0,5 с после того, как поступила соответствующая команда"
В этой части нашего курса мы постарались достаточно подробно рассказать о требованиях, которые оказывают свое влияние на архитектуру и функциональность программных продуктов, в том числе достаточно подробно рассмотрели функциональные и нефункциональные требования. Но предложенный объем является необходимым и достаточным только для того, чтобы у наших коллег сложилось понимание того, какую роль играют требования в процессах проектирования архитектуры и реализации программных продуктов. Более основательное изучение темы инженерии требований изложены в специализированых курсах и литературе, к которым мы и рекомендуем Вам обратиться.
Любое предприятие, которое осознанно пришло к необходимости создания или применения программного продукта, обладающего оптимальной архитектурой, для определенных условий и аспектов деятельности, можно считать сложной организационно-технической системой, которая имеет определенные цели и реализует конкретные функциональные задачи. При предпосылках использования программных продуктов в условиях организационного управления, процесс исполнения каждой задачи нуждается в конкретных ресурсах для реализации цели функционирования предприятия.
Сложная организационно-программная система состоит из иерархических уровней и поддерживающих их программных структур (исполнители бизнес процессов и необходимые программные продукты), каждый из которых постоянно расширяется и развивается. Из этого следует, что развитие каждого отдельного элемента (новая версия информационной системы с исправленными ошибками и дополнительными функциональными возможностями или развитие конкретного исполнителя) будет приводить к улучшению характеристик программного продукта, используемого на конкретном предприятии. Но целенаправленное развитие можно будет обеспечить только при условии соблюдения требования взаимодействия всех составных компонентов организации.
Запланированное функционирование бизнес процессов, поддерживаемых архитектурой программных продуктов, необходимо обеспечить требованиями к ресурсам, которые могут быть кратко выражены следующими аспектами:
Время на обучение пользователей, стабилизацию реализованных и внедренных принципов работы, поддерживающих достижение целей бизнес процессов, время на осознание организацией "хозяйнических" инстинктов по отношению к программному продукту
Финансовые ресурсы должны обеспечить необходимый уровень поддержки, выраженные в оптимальном количестве квалифицированных исполнителей их профессиональной мотивации, требуемом уровне технической оснащенности и пр.
Для того, чтобы результат деятельности соответствовал ожиданиям стейкхолдеров требуются данные надлежащего качества, на основе которых стало бы возможным достижение поставленных целей и качественной трансформации данных в значимую для бизнеса информацию. В дальнейшем повторное использование подобной информации позволит повысить уровень ценности тактических и стратегических процессов и способствовать повышению уровня экспертности и зрелости компании в целом.
Если перейти от организационных требований к реализации архитектуры программных продуктов, общая специфика большинства современных практик процессов создания архитектур, то можно выявить ряд общих особенностей, которые заключаются в:
После детального и компетентного изучения специализированных методик (с которыми мы познакомимся чуть позднее ) результатом их осмысления можно сформулировать следующие требования к процессам проектирования и реализации архитектуры, в частности, и программных продуктов в целом:
В практике создания программных продуктов, каждая реализуемая информационная система имеет собственную специфику, выраженную определенными условиями и факторами, которые имеют различную природу возникновения и силу влияния на архитектуру и функциональность. Часть из них мы рассмотрели в предыдущей лекции, часть из них мы будем рассматривать в следующей.
Активность инженерии требований, которая ставит своей целью работу с требованиями – это отдельная область, которая нуждается в подробном рассмотрении. Если Вас заинтересовало данное направление отрасли информационных технологий, вы сможете самостоятельно приступить к ее изучению, используя общедоступные источники информации.
Мы же далее будем рассматривать только те аспекты, которые оказывают достаточно сильное влияние на предмет нашего курса.
После того, как мы определились с основными видами требований, которые необходимо фиксировать, формализовывать и реализовывать в процессах проектирования и разработки для целей реализации архитектуры и функциональности программных продуктов, стоит задуматься о соблюдении целостности архитектуры, необходимой для:
Каждое требование, зафиксированное в целях создания информационной системы, по ходу стадий проектирования, разработки, тестирования и внедрения программного продукта должно быть трансформировано в определенный программный модуль, тестовую процедуру, пункт инструкции пользователя и т.д. – это один из основных постулатов создания качественного и адекватного программного продукта, который называется трассирование (трассировка).
Трассирование представляет собой процесс или атрибут в рамках реализации информационный системы, который обеспечивает связь между его элементами и функциональными процессами. Трассировка должна способствовать установлению связи между:
Оптимально выстроенный процесс трассирования должен ясно и однозначно позволять понять что (?), откуда (?), каким образом (?) вышло, и куда (?), и в каком виде (?) поступило.
К примеру можно привести стандарты создания программных продуктов для авиационной промышленности. В них зафиксировано, что команда, задействованная в разработке программного продукта должна в любой момент времени жизненного цикла программного продукта уметь отследить цепочку от результатов тестирования, к самим тестам, от тестов к бинарному коду, от бинарного кода к исходному коду, от исходного кода к низкоуровневым требованиям, от низкоуровневых требований к архитектуре, от архитектуры к высокоуровневым требованиям, от высокоуровневых требований к системным требованиям и в обратную сторону. Но, как правило, в стандартах не определяется способ трассирования. Это оставляет системным архитекторам или другим специалистам, ответственным за создание информационных систем, определенную свободу действий, регламентированную принципами здравого смысла и необходимостью получения оптимального результата для конкретных заданных условий.
Когда мы говорим о трассируемости документов, содержащих требования к разрабатываемому продукту, то вполне достаточно обеспечить начальную связность на первых этапах разработки за счет ссылочности создаваемых документов и уникальной идентификации каждого конкретного требования. Если же мы начнем обсуждать непосредственно процессы проектирования, разработки требований и кода программного обеспечения, то необходимо осветить процессы валидации, верификации и тестирования.
Под валидацией понимается процесс, направленный на доказательство того, что верхнеуровневые требования стэйкхолдеров будут полностью удовлетворены и покрыты в разработанной функциональности программного обеспечения.
Верификация является активностью процесса валидации, цель которой проверка и последующее достижение соответствия между требованием и реализованными архитектурой и функциональность программного обеспечения.
Тестирование представляет собой "сугуботехническую" часть активности верификации, направленную на испытание программного продукта.
При выполнении тестирования должны быть решены 2 основные задачи:
Необходимо четко представлять, что ни один из представленных процессов, сам по себе, не обеспечит качественной трассируемости требований с момента их фиксации до момента промышленной эксплуатации программного продукта. Даже наиболее развитый и формализованный процесс тестирования программного обеспечения не позволяет однозначно, точно и полностью выявить все несоответствия и установить адекватную функциональность, необходимую для достижения поставленных результатов. Причины этого заключаются в множестве разнообразных факторов, основной из которых это пресловутый человеческий фактор, к более подробному рассмотрению которого мы периодически возвращаемся в процессе изучения нашего курса.
Только в совокупности, используя свойства, порожденные эффектом эмерджентности, можно добиться достижения системных результатов от процессов трассировки.
При выполнении каждой стадии работы над требованиями и разрабатываемой архитектуры и функциональности информационной системы, в процессы проектирования и реализации должны быть вовлечены все стэйкхолдеры, которые при необходимости смогут прояснить проблемную ситуацию, в рамках зафиксированных требований. Относительно частая связь между разработчиками и стэйкхолдерами будет способствовать:
Эти факторы в совокупности приведут к повышению степени доверия между исполнителями и заказчиками и, как следствие, будут позитивно влиять на степень удовлетворенности пользователей и эффективность разрабатываемого программного продукта.
Тема трассирования, как многие рассматриваемые в нашем курсе, является полноценной областью сферы информационных технологий, для успешного изучения которых требуется затратить определенное время, при этом уже обладая определенным багажом знаний и опыта, полученного во время практической работы над созданием информационных продуктов.
Те аспекты, которые мы осветили, являются основными и позволят нашим коллегам быть готовым к необходимости создания и участия в процессах трассировки.
На текущий момент, когда в процессе изучения нашего курса мы подошли к стадии обсуждения рисков, важно немного более подробно рассказать о том, что именно мы будем понимать под рисками реализации архитектуры.
Риск – это потенциальная возможность наступления вероятного события/явления или их совокупности, которые могут вызывать определенное влияние (негативное или позитивное) на осуществляемую деятельность или реализуемый продукт.
Под рисками реализации архитектуры мы будем понимать совокупность факторов, управленческих решений и других аспектов, которые могут оказать влияние на конечный результат разработки архитектуры и функциональности программных продуктов. Мы не ставим себе целью предложить Вам способ или инструмент, который позволит справиться с рисковой составляющей, но опишем то, как стоит воспринимать конкретный риск и что надо сделать, чтобы быть готовым к работе с ним.
Как правило, риски реализации архитектуры можно ассоциировать со следующими причинами их возникновения:
Довольно популярная ситуация, складывается в процессе вынужденного реинжиниринга, когда без обоснованного анализа причинно-следственных связей, разработчик или архитектор спонтанно принимают решение о переделке какого-то компонента. В данном случае риск заключается в том, что идея не перешла на стадию "выдержанного" предложения, а сразу начала претворяться в код. Через какое-то время становится понятно, что какой-то элемент остался недостаточно проработан. В таком случае, достаточно "благостном", приходится отказываться от реализации, но если какие-то части уже внедрены в функционирование и ждут своих доработок, то приходится в режиме пожарника искать "обходные" варианты и усугублять имеющуюся информационную систему в целом
В том случае, когда новые члены команды, приступающие к работе над архитектурой и функциональностью программного продукта первым делом, не изучив причин реализации и их следствия, начинают недоумевать по поводу выбранного способа реализации. Им кажется, что все сделано не оптимально, не очевидно, слишком сложно. После того, как выполнены определенные доработки, в процессе тестирования начинают появляться дыры в уже разработанном решении и архитектура из целостного монолита становится "костыльной". В итоге систему требуется переделать почти полностью. Чем старше система, тем таких ситуаций больше
Описанные ситуации, как и множество других, особенно выделяются в длительных проектах.
На текущий день, в области создания информационных систем накоплен достаточно большой опыт, на основе которого возможно снижение, локализация или устранение вероятности наступления подобных ситуаций. Среди рисков реализации архитектуры следует выделить следующие, на которых мы сконцентрируемся в дальнейшем:
Эти риски сильно влияют на предсказуемость процессов перепроектирования и разработки программного продукта. Что характерно, наступление первого усиливает вероятность наступления второго.
Риск смены разработчика связан с потерей ключевой информации об архитектуре и функциональности по причинам изменения ключевого лица. Многие мысли, воплощенные в коде, которые не нашли отражение на бумаге, не всегда понятны тому, кто не является их автором. Подобных рисков можно избежать полным документированием выбранных решений до того момента, как они будут применены. Это позволит относительно безболезненно единовременно выдержать смену любых участников команды. Ключевым фактором успеха становится поддержка системности процессов документирования.
Причины рисков ошибочно принятых архитектурных решений заключаются в недостаточной трассируемости требований от стадии сбора информации, к стадии проектирования или же в недостаточной компетенции лиц, принимающих важные технические решения.
Для того, чтобы максимально обезопасить программный продукт от подобного рода рисков, необходимо как можно более комплексно подойти к решению некоторых вопросов еще на уровне формирования идеи. Все важные решения, связанные с проектированием, разработкой и последующим изменением архитектуры и функциональности программного продукта необходимо мысленно приостанавливать и стремиться задокументировать в виде концептуально проработанного предложения. Подобный подход помогает не только в принятии обоснованного и согласованного, с уже созданными компонентами информационно системы, решения, но и является своего рода дополнительной тренировкой аналитических способностей.
После того как идея получает свою материализацию на бумаге, в большинстве случаев, она может немного трансформироваться и становится более обдуманной и обоснованной.
Этот метод позволяет подойти к необходимым доработкам с позиции необходимых и достаточных трудозатрат и не тратить ценные ресурсы на "холостые ходы".
Каждое зафиксированное изменение в последующей стадии анализа и проектирования должно быть соотнесено с уже существующей архитектурой с помощью активности анализа влияния. Для этого есть множество разнообразных инструментов от общения с ответственными разработчиками, до построения диаграммы причинно следственных связей, на которых должно быть продемонстрировано то, как предлагаемое изменение будет влиять на программный продукт в целом. Если конструктивных моментов больше и изменение будет влиять положительно, то незамедлительно стоит переходить к его реализации, в противном случае имеет смысл отложить её или поискать более выигрышные варианты изменений.
В процессе работы над рисками важно помнить первоначальные цели, достижение которых является главным результатом нашей деятельности. Иногда бывает, что увлекшись поиском обходных решений и пытаясь минимизировать величину возможного ущерба, проектная команда, занятая поиском наиболее выигрышных ответов, отклоняется в сторону, и архитектура становится расплывчатой и слишком гибкой, что впоследствии отражается на её характеристиках и функциональности программного продукта. Кроме того, необходимо учитывать имеющиеся ресурсы, технологии и возможности бизнеса. Программный продукт в процессе своего функционирования должен поддерживаться и обеспечиваться в соответствии с тем количеством ресурсов, которое предусматривается для конкретной стадии его использования.
В том случае, если по ходу разработки программного продукта первоначальные предпосылки его создания изменились, подобная ситуация является возможностью для появления или увеличения количества и степени проявления всевозможных рисков (не только архитектурных, но и бизнес, операционных и т.д.).
Поэтому важно контролировать:
В предыдущей лекции мы начали рассматривать требования, необходимые для создания архитектуры программного продукта, которая была в силе поддерживать заданную, для достижения бизнес целей функциональность.
Большую часть сегодняшней лекции мы уделили подробному изучению различных типов требований, рассматривать и учитывать которые необходимо для создания полноценного программного продукта. Также нами был приведен подробный обзор современного инструментария разработки и моделирования требований к бизнес процессам, приведено влияние современных стандартов на процессы архитектурного проектирования, описаны риски и их влияние, которое необходимо знать и учитывать при разработке архитектуры информационной системы.
В следующий раз мы приступим к детальному изучению уровней архитектуры программного обеспечения, посмотрим на существующие подходы к созданию и документированию архитектуры, которые определяют её актуальное состояние, выберем оптимальные методики документирования архитектуры и изучим ещё множество интересных и важных аспектов, влияющих на реализацию архитектуры программного обеспечения.
Надеемся, что нам удалось передать Вам всю значимость направления инженерии требований и выявить то, как оно влияет на разработку качественной и надежной информационной системы.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.