Стадии концептуального проектирования

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

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

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

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

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

Цели концептуального проектирования:

• проект, учитывающий реальные требования пользователей

• ясное, целостное представление о

• достаточный уровень абстракции и классификации

• согласие заказчика, пользователей и проектной

• согласованное мнение группы о проекте

• проверка архитектуры приложения

• открытое общение группы

Концептуальное проектирование состоит из трех этапов: исследования, анализа и реализации.

На стадии исследования происходит:

• поиск ответов на основные вопросы;

• выявление основных бизнес-процессов и видов деятельности;

• определение приоритетов процессов и видов деятельности;

• изучение пользователей и создание профилей.

На стадии анализа выполняется:

• более глубокое исследование пользователей и бизнеса;

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

На стадии реализации:

• оптимизируются технологические процессы и поддерживающие их решения;

• проверяется и тестируется пересмотренный проект,

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

------------Первый этап: исследование

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

потребностей организации. Для этого надо составить:

• детальное описание основных бизнес-процессов, их границ и функциональных элементов;

• подробный перечень бизнес-операций в рамках этих процессов;

• описание заказчиков и пользователей.

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

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

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

Основной процесс:

• составляет суть бизнеса;

• определяет стратегические направления развития и конкурентоспособность компании;

• его владельцы и клиенты известны;

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

• практически не зависит от остальных основных процессов.

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

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

пользователей с процессами и видами деятельности.

Исследование завершено, если решены следующие задачи:

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

• собраны необходимые данные — бизнес-требования и пожелания пользователей.

----------------------------------Второй этап: анализ

Первая задача анализа — проверить результаты исследования

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

Такие модели бывают двух типов: схемы использования и сценарии.

Типичные схемы использования

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

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

Схемы использования позволяют:

• выявлять бизнес-процессы и виды деятельности от начала и до конца;

• документировать контекст;

• отслеживать связи между условиями бизнеса и требованиями пользователей;

• описывать требования в соответствующем контексте;

• уточнить выполняемую задачу.

Проанализировав схему использования, вы сможете:

• связать требования бизнеса и пользователей;

• понять приложение «в общем и целом»;

• определить основу для создания сценариев «пользователь — процесс»;

• объективно и логически оценить предложения пользователей;

• сформировать функциональные спецификации;

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

///////////Сценарии

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

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

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

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

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

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

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

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

достоинства сценариев:

• задают ориентиры для разработки;

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

• позволяют выявить дополнительные причины необходимости создания новой системы;

• помогают уяснить межсистемные зависимости.

Недостатки сценариев:

• для их разработки требуется много времени, ресурсов и средств;

• невыгодны, если решение — небольшое, или всем хорошо понятное, или не является критическим;

• иногда имеют весьма далекое отношение к проекту.

Стадия анализа завершена, если решены следующие задачи.

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

• Созданы сценарии, которые проектная группа считает приемлемыми.

-----------------------------Третий этап: рационализация

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

Что же стоит оптимизировать?

Первым делом попытайтесь отказаться от:

• непроизводительных операций;

• «узких» мест и ненужных работ;

• избыточных и неэффективных методов и процессов;

• ненужной бумажной работы;

• неконструктивных правил;

• потерь времени.

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

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

• создать прототип системы:

• представить проект пользовательского интерфейса;

• получить от пользователей предложения по усовершенствованию

системы:

• повторить все сначала, пока пользователи и заказчики не останутся довольны.

Рационализация завершена, если решены следующие задачи:

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

тенденции развития;

• сценарии проверены и уточнена информационная архитектура.

2.2.Стадия логического проектирования

Логическое проектирование — это процесс описания решения в терминах организации,структуры, синтаксиса и взаимодействие его частей с точки зрения проектной группы.

Его цель — применить принципы модели MSF и изучить структуру приложения и взаимодействие его частей.

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

На стадии логического проектирования:

• приложение упрощается благодаря определению его структуры,

описанию частей системы и их взаимодействия;

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

• выявляются все ошибки и несообразности концептуального проекта;

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

• закладывается фундамент физического проекта;

• улучшается работа различных частей приложения и приложения в целом;

• все члены группы приходят к единому мнению относительно проекта приложения.

логический проект не зависит от его физической реализации.

Он описывает, как должна работать система.

Логическое проектирование состоит из двух этапов:

•анализа

•рационализации.

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

На стадии анализа: • выявляются бизнес-объекты и сервисы; • определяются их атрибуты и взаимосвязи.

На стадии рационализации:• бизнес-объекты проверяются;• выявляются неявно использованные или дополнительные бизнес-объекты и сценарии.

Первый этап: анализ

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

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

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

• действия (выражаются глаголами) — это сервисы:

• субъекты и объекты (выражаются существительными) — это бизнес-объекты;

• атрибуты — то, как они связаны со свойствами:

• взаимосвязи, которые определяются свойствами.

Кроме того, важный источник информации — текущая ситуация и физическая среда.

Сервис — это элементарная единица приложения, реализующая операцию, функцию или преобразование. Бизнес-объект инкапсулирует сервисы и данные, используемые при составлении и упрощении решения. Такие объекты — люди или веши.

Стадия анализа завершена, когда решены следующие задачи:

• выявлены сервисы и подготовлен их список;

• выявлены объекты и подготовлен их список;

• определены атрибуты и подготовлен их список;

• определены взаимосвязи и подготовлен их список.

Второй этап: рационализация

Главная задача рационализации — создать те сервисы и объекты, которых не было на предыдущих стадиях проектирования. Они нужны, потому что предполагается их существование или они потребовались для контроля. Затем проектная группа «вычищает» и проверяет проект.

--уточнить сервисы и объекты

Дополнительные сервисы и объекты

На этом этапе создаются объекты и сервисы, которых не было на предыдущих стадиях проектирования.

Контроль

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

----------- «Очистка» проекта от мусора

После создания объектов нужно «очистить» проект от «мусора*:

• уничтожить объекты, не относящиеся к поставленной задаче;

• объединить избыточные объекты;

• выявить неявно используемые объекты;

• разделить атрибуты и объекты;

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

• отделить роли и их исполнителей от объектов.

Проверка

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

-------------Выявление неявности

2.3.Стадия физического проектирования

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

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

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

Задачи: на стадии физического проектирования проектная группа:

• классифицирует требования и полностью разъясняет их разработчикам;

• связывает логический проект и его реализацию, описывая решение в терминах реализации;

• оценивает разные варианты реализации;

• создает гибкий проект на основе сервисов;

• добивается совместимости с производственной архитектурой;

• проверяет соответствие логического проекта схемам использования и сценариям.

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

Физическое проектирование завершаетсяв тот момент, когда собрано достаточно информации для начала разработки или развертывания. Поэтому эти процессы начинаются до завершения физического проектирования; более того, физическое проектирование может продолжаться и в начале стадии «Разработка», что дает дополнительные преимущества в «очистке» проекта. Единственное условие — окончательный проект должен быть утвержден до стабилизации решения.

Стадия физического проектирования в модели MSF состоит из четырех этапов:

исследования, анализа, рационализации и реализации,

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

На стадии исследования:

• определяются физические ограничения инфраструктуры;

• определяются физические требования к решению;

• изучаются риски, возникающие в результате конфликта между

требованиями и физическими ограничениями.

На стадии анализа:

• выбираются возможные технологии реализации;

• создается эскиз модели развертывания, включающий сетевые и

компонентные технологии, а также технологии данных.

На стадии рационализации:

• определяется способ комплектации и развертывания;

• выполняется декомпозиция объектов на компоненты и сервисы;

• компоненты распределяются в соответствии с топологией;

• происходит «очистка» плана комплектации и развертывания.

На стадии реализации:

• выбирается программная модель;

• определяется интерфейс компонентов;

• компоненты описываются на языке разработки;

• изучается структура компонентов.

Результат исследования, анализа, рационализации и реализации —

базовый физический проект, включающий основные спецификации.

Шаг 1: исследование

Цель исследования:

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

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

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

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

Стадия исследования завершена, когда выполнены следующие задачи:

• выявлены ограничения и условия работы;

• определены топологии сети,данных и компонентов, а также физические требования приложения;

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

• риски оценены и составлен план их сокращения.

Шаг 2: анализ

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

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

К вопросам бизнеса относятся:

• возможности — действительно ли данная технология удовлетворяет потребностям бизнеса;

• стоимость продукта — полная стоимость продукта ;

• квалификация пользователей;

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

• сопровождение .

К вопросам производственной архитектуры относятся:

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

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

• возможности роста — масштабируемость приложения следует рассматривать как с точки зрения положения на рынке, так и с точки зрения увеличения сегмента рынка, занятого данным продуктом. При этом, возможно, разрастется и сама компания;

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

К технологическим вопросам относятся:

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

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

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

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

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

методы доступа к их сервисам,

Стадия анализа завершена, когда решены следующие задачи:

• составлен список используемых технологий;

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

Шаг 3: рационализация

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

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

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

Это может быть:• тип сервиса;• масштабируемость;• производительность:• управляемость;• возможность повторного использования;• бизнес-контекст;

• степень детализации.

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

Этот процесс — интерактивный, так как на данном этапе модель программирования еще не ясна.

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

Стадия рационализации завершается, когда решены следующие задачи:

• определена стратегия комплектации и развертывания;

• в рамках создания компонентной модели объекты преобразованы в компоненты, основанные на сервисах,

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

• уточнены модели комплектации и развертывания.

Шаг 4: реализация

На последнем этапе физического проектирования — этапе реализации

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

Модель программирования:

• описывает способы использования выбранных технологий;

• учитывает некоторые особенности спецификаций компонентов, что помогает в дальнейшем согласованно работать над проектом;

• конкретизирует различные элементы решения.

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

Этап реализации завершается, когда решены следующие задачи:

• выбрана программная модель;

• определены внешние структуры компонентов, в том числе интерфейсы, атрибуты и сервисы;

• определены внутренние структуры компонентов.////////баланс компромисного треугольника