Унифицированный процесс разработки программного обеспесчения

Оглавление

1 Унифицированный процесс: управляемый вариантами использования, архитектурно- ориентированный, итеративный и инкрементный 2

1.1 Введение 2

1.2 Унифицированный процесс в двух словах 3

1.3 Унифицированный процесс управляется вариантами использования 5

1.4 Унифицированный процесс ориентирован на архитектуру 6

1.5 Унифицированный процесс является интеративным и инкрементным 9

1.6 Жизненный цикл Унифицированного процесса 12

1.6.1 Продукт 12

1.6.2 Разделение цикла на фазы 15

1.7 Интегрированный процесс 19

2 Процесс, направляемый вариантами использования 20

2.1 Введение в разработку управляемую вариантами использования 22

2.2 Необходимость вариантов использования 26

2.3 Определение вариантов использования 27

2.4 Анализ, проектирование и разработка при реализации варианта использования 27

2.4.1 Создание по вариантам использования аналитической модели 28

2.5 Тестирование вариантов использования 29

2.6 Резюме 32

3 Архитектурно-центрированный процесс 33

3.1 Введение в архитектуру 33

3.2 Необходимость архитектуры 35

3.3 Варианты использования и архитектура 36

3.4 Описание архитектуры 40

4 Интеративный и инкрементный процесс 42

4.1 Введение в итеративность и инкрементность 42

4.2 Необходимость использования итеративной и инкрементной разработки 42

4.3 Итеративный подход управляемый рисками 43

4.4 Обобщенная итерация 44

5 Заключение 46

6 Список использованной литературы 47

1. Унифицированный процесс: управляемый  вариантами использования, архитектурно- ориентированный, итеративный и инкрементный

1. Введение

 

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

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

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

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

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

 

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

2. Унифицированный процесс в двух словах

 

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

     Унифицированный процесс компонентно-ориентирован. Это означает, что создаваемая программная система строится на основе программных компонентов, связанных хорошо определенными интерфейсами.

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

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

 

3. Унифицированный процесс управляется  вариантами использования

 

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

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

     Взаимодействие  такого рода  называется вариантом использования. Вариант использования — это часть функциональности системы, необходимая для получения пользователем значимого для него, ощутимого и измеримого результата. Варианты использования обеспечивают функциональные требования. Сумма всех вариантов использования составляет модель вариантов использования которая описывает полную функциональность системы. Эта модель заменяет традиционное описание функций системы. Считается, что описание функций может ответить на вопрос: что система предположительно делает? Подход вариантов использования может быть охарактеризован добавкой трех слов в конец этого вопроса: для каждого пользователя? Эти три слова представляют собой очень важное дополнение. Они побуждают нас думать в понятиях результата, значимого для пользователя, а не только в понятиях функций, которые хорошо бы иметь. Однако варианты использования — это не только средство описания требований к системе. Они также направляют ее проектирование, реализацию и тестирование, то есть они направляют процесс разработки. Основываясь на модели вариантов использования, разработчики создают серию моделей проектирования и реализации, которые осуществляют варианты использования. Тестеры тестируют реализацию для того, чтобы гарантировать, что компоненты модели реализации правильно выполняют варианты использования. Таким образом, варианты использования не только инициируют процесс разработки, но и служат для связи отдельных его частей. Управляемый вариантами использования означает, что процесс разработки проходит серии рабочих процессов, порожденных вариантами использования. Варианты использования определяются, варианты использования проектируются, и, в конце концов, варианты использования служат исходными данными, по которым тестеры создают тестовые примеры.

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

4. Унифицированный процесс ориентирован на архитектуру

 

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

     Понятие архитектуры  программы включает в себя наиболее важные статические  и динамические аспекты системы. Архитектура вырастает из требований к результату, в том виде, как  их понимают пользователи и другие заинтересованные лица. Эти требования отражаются в вариантах использования. Однако они также зависят от множества  других факторов, таких, как выбор  платформы для работы программы (то есть компьютерной архитектуры, операционной системы, СУБД, сетевых протоколов), доступность готовых блоков многократного  использования, (например, каркаса графического интерфейса пользователя),соображения развертывания, унаследованные системы и нефункциональные требования (например, производительность и надежность). Архитектура — это представление всего проекта с выделением важных характеристик и затушевыванием деталей. Поскольку важность той или иной характеристики зависит, в частности, от правильности суждения, приходящей с опытом, результат построения архитектуры определяется людьми, которым поручена эта задача. Однако процесс помогает архитектору сконцентрироваться на правильных целях, таких, как понятность, легкость внесения изменений и возможность повторного использования.

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