Вместо приветствия

Традиционное доброе время суток Вам, уважаемые коллеги!

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

Именно подобные инструменты мы и обсудим сегодня.

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

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

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

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

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

Из современных нотаций можно выделить следующие:

• Блок-схемы (схемы алгоритмов)

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

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

• DFD-диаграмма (диаграмма потоков данных)

DFD – это нотация структурного анализа.

В данной нотации принято описывать внешние, по отношению к разрабатываемому продукту:

• Источники данных;
• Адресаты данных;
• Логические функции;
• Потоки данных;
• Хранилища данных.

Диаграмма потоков данных - это один из первых и основных инструментов структурного анализа и проектирования верхнеуровневой архитектуры программных продуктов, существовавших до последующего широкого распространения UML.

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

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

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

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

• ER-диаграмма (диаграмма сущность-связь)

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

• EPC-диаграмма (диаграмма событийной цепочки процессов)

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

История развития данного типа диаграмм связана с разработкой одноименного метода в рамках работ по созданию методологии ARIS (Architecture of Integrated Information Systems - Архитектура интегрированных информационных систем.

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

• BPMN-диаграммы

Один из самых распространенных типов нотаций на сегодняшний день – это BPMN (Business Process Model and Notation).

EPC, ER, BPMN - это не просто нотации, а методы реализации конкретных моделей процессов. BPMN по своему назначению более уместно сравнивать c диаграммами EPC. Причина этого заключается в том, что они имеют схожую цель – функциональное моделирование бизнес процессов. Рассматриваемая диаграмма самый новый, из приведенных в обзоре, принятый стандарт моделирования бизнес процессов. Главное позиционируемое преимущество диаграммы BPMN – понятная всем стэйкхолдерам разрабатываемой архитектуры и программного продукта визуализация моделируемых процессов.

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

• Первая группа (simple notation) состоит из основных элементов BPMN, которые удовлетворяют требованиям создания простой графической нотации. Подавляющее большинство бизнес-процессов моделируются с использованием элементов данной группы.
• Вторая группа (powerful notation) содержит полный «пакет» элементов BPMN. В него кроме основных блоков входят специфические комплексные модули, представляющие различные типы и виды элементов, необходимых для моделирования самых сложных процессов.

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

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

• UML- диаграммы

UML (Unified Modeling Language) - не просто нотация или группа нотаций, а язык графического описания для объектного моделирования.

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

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

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

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

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

• EIP - диаграммы

Самая специфичная и наименее распространенная нотация из всех рассматриваемых в сегодня.

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

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

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

• Модели компонентов, программных продуктов и функциональных процессов

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

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

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

• Прототипы

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

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

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

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

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

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

• Интерфейсы

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

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

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

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

На текущий момент есть множество инструментов для создания интерфейсов разной степени сложности и детальности. Мы выделим следующие Balsamiq mockup, Axure RP и пр.

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

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

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

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

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

О функциональных и нефункциональных требованиях к архитектуре и функциональности программного обеспечения

Обсуждение различных типов и видов требований мы начали в предыдущей ранее.

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

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

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

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

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

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

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

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

Высокоуровневое назначение программного продукта - приносить выгоду его владельцу за счет автоматизации труда (интеллектуального, физического, монотонного и т.д. ) человека, а в идеале за счет полной замены человеческого ресурса и фактора, если это возможно.

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

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

Сначала мы рассмотрим функциональные требования.

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

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

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

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

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

• Классический подход

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

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

• Use cases (Варианты использования)

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

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

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

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

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

• Атрибуты качества;
  • Безопасность;
  • Надежность;
  • Производительность;
  • Скорость и время отклика приложения;
  • Пропускная способность workflow;
  • Количество необходимой оперативной памяти;
• Ограничения;
  • Платформа реализации архитектуры и программного продукта;
  • Тип используемого сервера приложений;

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

Ранее описанная методология use cases может быть применена для сбора и анализа нефункциональных требований. При взаимодействии с стэйкхолдерами необходимо фиксацию каждого правила подытоживать фиксацией нефункциональных требований, выраженную в виде количественной характеристики определенного параметра: «программный продукт должен обеспечить учетчику возможность формирования акта выдачи бланков строгой отчетности за время не более 0,5 с, после того, как поступила соответствующая команда»

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

Выводы

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

Надеемся статья получилась комплексной и цельной.

До следующей встречи!

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

Иван Никитин

Михаил Цулая