Построение модели предметной области это задача бизнес архитектора

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

Решение — подход DDD, Domain Driven Design, было предложено Эриком Эвансом в 2003. Но прежде, чем о нем говорить, необходимо немного углубиться в историю развития разработки софта как такового.

Решение дали объектные языки программирования, начиная с C++, который на рубеже 1980-х дал первую эффективную реализацию Объектно-ориентированного программирования, ООП. Уменьшение сложности достигается за счет инкапсуляции в объекты структур данных и связанных с ними алгоритмов обработки, с методами наследования и полиморфизма объектов, и это в целом структурирует системы: мы отдельно рассматриваем устройство каждого объекта и взаимодействие между разными объектами.

Основы бизнес-архитектуры // Демо-занятие курса «Enterprise Architect»

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

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

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

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

Основы бизнес-архитектуры // Демо-занятие курса «Enterprise Architect»

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

На рисунке мы видим описание бизнес-процессов в виде activity diagram, диаграмму классов для документов и диаграмму состояний документов, которые и реализуют бизнес-процесс. Но при этом все три модели — на едином языке и с прозрачной связью между ними. И принципы DDD говорят, что в коде информационной системы должны присутствовать те же самые объекты, а не какая-то другая реализация.

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

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

Еще одно важное изменение, которое принес DDD, — признание, что единую непротиворечивую модель предметной области построить невозможно, а значит и не стоит браться за эту задачу. Ведь это получается антипаттерн Big Object, когда всю логику пробуют реализовать в одном объекте. Вместо этого предложено предметную область делить на ограниченные контексты, в рамках каждого из которых строить свою модель, сопрягая их теми же способами, которыми в объектном подходе сопрягаются разные системы или фрагменты системы: через выделение общего ядра с наследованием, создание специальных прослоек-переводчиков или иным образом.

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

DDD актуален и сейчас, только в современных распределенных системах способы отражения в код изменились. Вместо простого шаблона Business Objects для каждого бизнес-объекта в коде создают несколько: транспортный объект без логики, контроллеры, реализующие логику на сервере и на клиенте, и так далее. Важно, что это отражение является единообразным, бизнес-объекты по-прежнему можно проследить в коде.

Правда, сейчас есть сложность с современной архитектурой, в которой системы реализуют активные сервисы, асинхронно взаимодействующие через очереди. Классические объекты с обработкой через вызовы методов плохо отражают такую архитектуру, ик требуются другие методы представления устройства софта, понятные бизнесу. Такой модели посвящена моя серия докладов «Акторная модель». Активные сервисы представляются гномиками, работающими и взаимодействующими для обработки запросов к системе. Для иллюстрации — схема интернет-магазина в таком представлении.

На этом я завершаю статью, посвященную моделям. Продолжение следует…

Источник: habr.com

Моделирование предметной области на UML

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

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

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

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

Для создания АИС разрабатываются две модели:

— объектная модель предметной области (UML-ПрО);

— объектная модель системы (UML-АИС).

Для моделирования ПрО и создаваемой системы в рамках OOAD широко используется язык UML.

Унифицированный язык моделирования (Unified Modeling Language, UML) – это универсальный язык визуального моделирования систем.

Будущее UML, по предложению OMG, ориентация на архитектуру системы, управляемую моделью (Model Driven Architecture, MDA).

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

В UML-модели отражаются два аспекта:

— статическая структура – описывает, какие типы объектов важны для моделирования системы и как они взаимосвязаны.

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

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

Структура UML включает:

— строительные блоки – основные элементы, отношения и диаграммы UML-модели;

— общие механизмы – общие UML-пути достижения определенных целей;

— архитектура – UML представление архитектуры системы.

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

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

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

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

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

Типы диаграмм UML

Структурные диаграммы

Диаграммы поведения

Диаграммы взаимодействия

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

Основными задачами при моделировании предметной области являются описание:

— действующих лиц бизнес-процессов и их функций, подлежащих автоматизации в привязке к структуре автоматизируемого предприятия;

— сценариев выполнения бизнес-функций, подлежащих автоматизации;

Основные аспекты предметной области отображаются в следующих UML-диаграммах.

В целом UML-модель предметной области имеет следующий вид:

При моделировании бизнес-процессов в UML-диаграммах используют следующие элементы.

UML-диаграмма	Расширение	Обозначение
Package	Пакеты предметных областей управления или видов деятельности. Стереотип – «Business System»
Package	Пакеты организационных единиц (структурных подразделений). Стереотип – «Organization Unit»
Class	Бизнес-сущности, обозначающие владельцев бизнес-процессов. Стереотип – «Business Actor»
Class	Бизнес-сущности, обозначающие деловых работников (исполнителей). Стереотип – «Business Worker»
Class	Бизнес-сущности, обозначающие объект учёта. Стереотип – «Business Object»
Class	Бизнес-сущности, обозначающие субъекты учёта. Стереотип — «Business Subject»
Class	Бизнес-сущности, обозначающие первичные документы. Стереотип – «Document» (розовый)
Class	Бизнес-сущности, обозначающие учётные регистры. Стереотип – «Registration» (желтый)
Class	Бизнес-сущности, обозначающие отчёты. Стереотип – «Report» (голубой)
Use-Case	Бизнес-процесс (функция). Стереотип – «Business Precess»
Activity	Бизнес-транзакция (операция). Стереотип – «Business Transaction»

Основной диаграммной в UML-модели ПрО являются Activity-диаграмм (деятельности), раскрывающие методический аспект бизнес-процессов. Каждая бизнес-операция есть полная или частичная реализация некоторой управленческой функции, результатом выполнения которой есть значимый на том или ином уровне управления результат. Для достижения данного результата при выполнении бизнес-операций используются некоторые материальные, информационные и иные объекты (бизнес-сущности), идентифицированные на Class-диаграммах (классов); выполнение той или иной бизнес-оператции закрепляется за определенным исполнителем, также идентифицированном на Class-диаграмме (классов) из пакета со стереотипом «Organization Unit» (структурное подразделение). Бизнес-сущности в ходе выполнения той или иной бизнес-операции могут менять своё внутреннее состояние, что также находит своё отражение на Activity-диаграммах (деятельности), а полная карта состояний и переходов между ними – на соответствующих той или иной бизнес-сущности State Machine diagram-диаграммах (конечного автомата). Кроме того каждая бизнес-операция или состояние могут быть детализованы, т.е. отражены на вложенных Activity- (деятельности) и State Machine diagram-диаграммах (конечного автомата) соответственно.

Вследствие этого Activity-диаграммы (деятельности), отражая реализацию бизнес-процесса, выступают как связующее звено между другими диаграммами и элементами UML-модели ПрО.

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

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

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

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

Рассмотрим задачу, подлежащую автоматизации: “Оприходование товара на складе предприятия от продавца”.

На рис. 1 представлен пример описания бизнес-процессов с использованием диаграммы деятельности (activity diagram).

Рис. 1. Описание работы склада при оприходовании товара от продавца

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

При этом целесообразно выделить виды деятельности, подлежащие автоматизации. На рис. 1 автоматизируемые виды деятельности выделены цветом:

1. Выписывает доверенность;

2. Выписывает приемный акт в двух экземплярах;

3. Регистрирует товар в картотеке;

4. Передает экземпляр акта в бухгалтерию;

5. Получает приходный акт.

Моделирование бизнес-процессов с помощью диаграмм деятельности имеет следующие преимущества перед другими видами моделирования:

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

2. Четкое ролевое выражение ответственностей за ту или иную деятельность.

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

4. Развитая нотация описания состояний бизнес-сущностей (при использовании объектов).

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

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

На основе этой модели строится модель функций системы.

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

На рис. 2-7 представлены модель структуры предприятия, построенная с использованием диаграммы функций UML (use case diagram).

Рис. 2. Автоматизируемое предприятие

Рис. 3. Автоматизируемые отделы предприятия

Рис. 4. Сотрудники склада и документы склада

Рис. 5. Роли на складе

рис. 6. Задачи кладовщика

Рис. 7. Функции кладовщика по задаче “Оприходование товара на складе от продавца” (цветом помечены выходные документы)

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

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

Цель моделирования документов – описать атрибуты документов, их типы, значения и правила формирования для:

1. Проектирования пользовательского интерфейса системы.

2. Проектирования базы данных системы.

3. Формирования альбома выходных форм системы.

Рис. 8. Пример модели документа “Приемный акт” разработанный с использованием диаграммы классов (class diagram) языка UML

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

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

На рис. 9 представлен пример сценария работы кладовщика с карточкой товара и накладной, описанного с использованием диаграммы последовательности действий UML (sequence diagram), а на рис. 10 пример диаграммы состояний приемного акта, описанного с использование диаграммы (State Machine diagram).

Рис. 9. Сценарий работы кладовщика с карточкой товара и накладной

Рис. 10. Пример диаграммы состояний (state diagramm) с описанием состояний приемного акта

При описании предметной области не следует забывать о моделировании бизнес-правил. Модели бизнес-правил предметной области будут являться основой для моделирования правил программной системы. Для моделирования бизнес-правил могут использоваться диаграммы деятельностей (activity diagram) и диаграммы классов (class diagram). Диаграммы деятельностей (activity diagram) могут использоваться для моделирования например, алгоритмически описываемых правил, диаграммы классов (class diagram) – для моделирования структурных правил.

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

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

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

— Модель структуры предприятия используется для отражения действующих лиц предприятия, их автоматизируемых функций в привязке к подразделениям, в которых эти функции выполняются. На основе модели структуры предприятия разрабатывается модель функций системы;

— Модели документов, бизнес-сущностей используется при проектировании пользовательского интерфейса, БД, формирования альбома выходных форм системы;

— Модели сценариев реализации бизнес-функций используются при проектировании сценариев пользовательского интерфейса;

— Модели состояний бизнес-сущностей используются при проектировании пользовательского интерфейса и БД системы.

— Модели бизнес-правил используются при моделировании правил программной системы.

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

3. Полное и детальное описание предметной области крайне удобно производить в CASE-средстве, поддерживающем язык моделирования UML.

Описание предметной области с использованием UML хорошо воспринимается экспертами предметной области и не требует от них никакой специальной подготовки для понимания представленных им на рассмотрение моделей.

3.3. Анализ предметной области и
построение модели “как должно быть”

— анализ модели ПрО и реинжиниринг бизнес-процессов;

— назначение, задачи и методы анализа ПрО;

— назначение, задачи и методы реинжиниринга бизнес-процессов;

— техническое задание на разработку автоматизированной системы.

Построение UML-модели ПрО “как есть” (AS-IS) позволяет понять, что собой представляет реально существующий объект (предприятие, определенная деятельность отдельного человека или некоторого коллектива людей), как он функционирует и как он связан с внешним миром. Однако для создания АС, реализующей определенную функциональность и встраиваемой в объект (ПрО), этого недостаточно.

Разработка АС осуществляется в соответствии с техническим заданием (ТЗ), которое должно отражать как будет функционировать объект при наличии АС. Поэтому необходимо выполнить анализ ПрО и определить место создаваемой АС существующем объекте.

Анализ ПрО производится в два этапа:

— анализ модели ПрО “как есть”;

— построение модели ПрО “как должно быть”.

На основании модели ПрО “как должно быть” разрабатывается ТЗ на создание АС.

Источник: cyberpedia.su

Единственный в мире Музей Смайликов

Самая яркая достопримечательность Крыма

Скачать 21.25 Kb.

1. Рамки … определяют функциональность разрабатываемого ПО и его возможности Тип ответа: Одиночный выбор

1. это определение потребностей участников проекта в коммуникации и информации

Планирование коммуникаций

A. Пилотный проект

C. Параллельная стратегия

D. прежняя система работала еще сегодня, а завтра начали работать по новой системе для ограниченного числа процессов

E. прежняя система работала еще сегодня, а завтра начали работать по новой системе

F. одновременно работают старая (ручная) и новая система, и их выходные

1. Функциональная спецификация является результатом фазы …

планирования

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

Иерархическая структура работ

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

1. Временной интервал между моментом начала и окончания проекта называется … проекта

жизненным циклом

1. Построение модели предметной области – это задача …

бизнес-аналитика

1. Концептуальное проектирование описывает систему с точки зрения …

разработчиков

1. Крайне нежелательно совмещать роли …

руководителя проекта и системного аналитика

1. Проектирование, реализация и отладка отдельных модулей системы – это задача …

бизнес-аналитика

бизнес-архитектора

разработчика

1. В соответствии со стандартом ISO/IEC 15288 выделяют такую группу процессов жизненного цикла ИС, как «…»

Технические процессы

Процессы соглашения

Процессы предприятия

1. Риск проекта – это …

всякое событие или условие, которое может оказать позитивное либо негативное влияние на итоги проекта

мера возможности того, что последствие риска, описанное в его формулировке, действительно наступит

1. Классическая методология управления проектами предполагает ведение деятельности в рамках ограничений по … информационного проекта

качеству, срокам и бюджету

1. … – это жизненный цикл процесса проектирования, созданный для достижения более высоких скорости разработки и качества ПО

1. Информационный проект – это …

продолжающийся во времени и повторяющийся процесс, направленный на получение прибыли

краткосрочное усилие по созданию уникального программного продукта, сервиса или среды

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

Программный продукт

1. Соотнесите понятия с их определениями:

A. Рамки решения

B. Рамки проекта

C. Процессы проектирования

D. определяют функциональность решения и его возможности

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

F. определяют способ продвижения от абстрактных концепций к конкретным техническим деталям

1. Управление информационными проектами – это …

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

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

1. … – это процесс разработки, разделенный на фиксированные отрезки времени для придачи процессу разработки предсказуемости и гибкости

Традиционное управление проектами

1. Физическое проектирование описывает систему с точки зрения …

разработчиков

1. Соотнесите этапы проектирования и их результаты:

A. Концептуальный дизайн

B. Логический дизайн

C. Физический дизайн

D. функциональная спецификация

E. эскизный проект пользовательского интерфейса

F. схема базы данных

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

Быстрая разработка приложений

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

1. Окончательный продукт информационного проекта является результатом фазы …

1. Логическое проектирование описывает систему с точки зрения …

разработчиков

1. Процесс проектирования – это …

извлечение, документирование и сопровождение требований к продукту

систематический способ продвижения от абстрактных концепций к конкретным техническим деталям

1. Соотнесите процессы с группами, к которым (по стандарту ГОСТ Р ИСО/МЭК 12207-2010) эти процессы относятся:

A. Процесс верификации

B. Процесс реализации

C. Процесс менеджмента проекта

D. группа процессов поддержки программных средств

E. группа технических процессов

F. группа процессов планирования

1. Ожидаемая величина риска показывает …

вероятность появления рисковых событий

возможность управления риском

1. Под прототипом понимается …

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

сложная система ПО, которая является целью большинства программных проектов

Источник: topuch.com