9. Рабочие процессы

Рациональный Унифицированный Процесс состоит из девяти рабочих процессов:

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

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

анализ и проектирование - описываются различные виды архитектуры системы;

реализация - собственно разработка программ, автономное тестирование и интеграция;

тестирование - описываются тестовые сценарии, процедуры и метрики для измерения числа ошибок;

развертывание - охватывает конфигурирование поставляемой системы;

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

управление проектом - описывает разные стратегии работы с итеративным процессом;

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

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

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

10. Артефакты

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

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

Модели

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

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

модель предметной области - формализует контекст системы;

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

аналитическая модель (необязательная) - формализует идею проекта;

проектная модель - формализует словарь предметной области и области решения;

модель процессов (необязательная) - формализует механизмы параллелизма и синхронизации в системе;

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

модель реализации - описывает части, из которых собирается физическая система;

модель тестирования - формализует способы проверки и приемки системы.

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

Другие артефакты

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

группа требований - описывает, что система должна делать;

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

группа реализации - описывает сборку разработанных программных компонентов;

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

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

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

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

11. Стадии анализа

12. Стандарты семейства IDEF

Стадия анализа (analysis) состоит в исследовании проблемы, а не в поисках ее решения. Например, при разработке новой экономической информационной системы необходимо описать экономические процессы, связанные с ее использованием.

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

В реальной жизни программные проекты чаще всего достаточно сложны, и их декомпозиция (по принципу "разделяй и властвуй") - это основная и, наверное, единственная стратегия борьбы со сложностью. Она состоит в разбиении проблемы на мелкие управляемые элементы. До появления объектно-ориентированного подхода во времена господства парадигмы структурного программирования наиболее популярной методологией декомпозиции являлись структурный анализ и проектирование (structured analysis and design). Этот подход заключается в декомпозиции задачи на функции или процессы, приводящий к созданию иерархии процессов и подпроцессов. Существовали и существуют и другие методы декомпозиции. В следующем разделе мы рассмотрим наиболее известные и часто применяемые методики анализа, позволяющие минимизировать риски и решать ключевые проблемы, возникающие на различных этапах жизненного цикла.

Стадия анализа

Стандарты семейства IDEF

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

IDEF0 - стандарт функционального моделирования (принят).

IDEF1 (X) - стандарт информационного моделирования (принят), хорошо известен еще и под названием "ER- диаграммы".

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

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

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

DFD "Data flow diagram", "диаграммы потоков данных" - широко распространенная методология моделирования процессо-ориентированного типа.

"Моделирование в терминах системы" - одной из существенных проблем при использовании "универсальных" методологий моделирования является дальнейшее использование результатов в практической работе, например при внедрении или создании корпоративной информационной системы. Часто оказывается (особенно до создания методологии IDEF 3), что применить результаты длительной работы достаточно сложно. Поэтому неудивительно, что все крупнейшие поставщики интегрированных программных систем озаботились созданием специализированных систем моделирования, адекватных применяемой системе. Наиболее интересная методология "моделирования в терминах системы" создана усилиями специалистов BAA