Автор: Пользователь скрыл имя, 28 Сентября 2011 в 22:47, курсовая работа
Сегодня развитие программного обеспечения происходит в сторону увеличения и усложнения систем. Это связано отчасти с тем, что компьютеры с каждым годом становятся все мощнее, что побуждает пользователей ожидать от них все большего. Эта тенденция также связана с возрастающим использованием Интернета для обмена всеми видами информации — от простого текста до форматированного текста, изображений, диаграмм и мультимедиа. Наши аппетиты в отношении более продвинутого программного обеспечения растут по мере того, как мы начинаем понимать с выходом каждого следующего выпуска, как еще можно улучшить этот продукт. Мы желаем иметь программное обеспечение, еще лучше приспособленное для наших нужд, а это, в свою очередь, приводит к усложнению программ. Короче говоря, мы желаем большего.
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
Кроме того, часто имеется существующая система, которая исполняет некоторые из функций проектируемой системы. Определение того, что делает эта система, при минимуме документации или вообще без нее, и решение вопроса о том, какую часть унаследованного кода разработчики могли бы использовать повторно, добавляет разработке сложности.
Мы нуждаемся в архитектуре для того, чтобы:
Уточним, как происходит этот процесс, рассмотрев сначала, что оказывает влияние на архитектуру (рис. 4.1), а затем — какие факторы влияют на варианты использования.
Варианты использования — это направляющие для архитектуры. В конце концов, мы хотим иметь архитектуру, которая является подходящей для осуществления наших вариантов использования. На ранних итерациях мы выбираем несколько вариантов использования, которые, как мы полагаем, позволят нам наилучшим образом разработать архитектуру. Эти важные для создания архитектуры варианты использования будут включать те, которые необходимы клиентам в текущем выпуске и, возможно, в последующих выпусках.
Однако на архитектуру будут влиять не только важные для архитектуры варианты использования, но и другие факторы:
Разработка архитектуры происходит на итерациях фазы проектирования. Упрощенный, немного наивный подход — мысленная модель — осуществляется следующим образом. Мы начинаем с определения типа архитектуры, например послойной архитектуры После этого в течение нескольких билдов первой итерации мы создаем архитектуру.
В первом билде мы работаем с частями общего уровня приложений
которые являются общими для предметной области и не специфичны для системы, которую мы собираемся разрабатывать. Имеется в виду, что мы выбираем системное программное обеспечение, средний уровень, наследуемые системы, используемые стандарты и правила. Мы решаем, какие узлы будут присутствовать в нашей модели развертывания и как они должны взаимодействовать друг с другом. Мы решаем, как удовлетворить общие нефункциональные требования, например требования по доступности. На этом первом проходе достаточно будет добиться общего понимания приложения.
Во втором билде мы работаем с архитектурой специфического уровня приложения. Мы выбираем комплект архитектурно значимых вариантов использования, определяем требования, анализируем их, проводим проектирование, реализуем и тестируем их. Результатом будут новые подсистемы, реализованные в виде компонентов. Они создаются для поддержки выбранных нами вариантов использования. Кроме того, теперь, рассмотрев систему в понятиях вариантов использования, мы можем захотеть внести некоторые изменения в архитектурно значимые компоненты, выбранные во время первого билда. Для реализации вариантов использования создаются новые компоненты и изменяются старые. Таким образом мы адаптируем архитектуру для лучшего удовлетворения вариантам использования. Затем мы делаем следующий билд, затем еще и еще, пока не закончим итерацию. Когда фаза проектирования заканчивается, архитектура должна быть стабилизирована.
После того, как мы создали устойчивую архитектуру, мы можем вводить в систему полный список функциональных возможностей, реализуя в ходе фазы построения оставшиеся варианты использования. Варианты использования, реализуемые в течение фазы построения, обычно разрабатываются с использованием в качестве исходных данных требований пользователей и клиентов (рис. 4.2). Варианты использования также находятся под влиянием архитектуры, выбранной на фазе проектирования.
Чтобы лучше определять новые варианты использования, мы применяем наше знание архитектуры. Когда мы оцениваем ценность каждого предложенного варианта использования и затраты на него, мы делаем это применительно к существующей архитектуре. Некоторые варианты использования будут легко осуществимы, в то время как осуществить другие будет затруднительно.
Базовый уровень архитектуры, разработанный во время фазы проектирования, сохраняется, в форме описания архитектуры. Описание архитектуры — это выдержка или, как мы говорим, набор представлений — возможно, аккуратно приведенный в удобный для чтения вид моделей базового уровня архитектуры. Представления моделей содержат существенные для архитектуры элементы. Множество элементов моделей, входящих в базовый уровень архитектуры, разумеется, войдет также и в описание архитектуры. Однако в описание архитектуры войдут не все элементы базового уровня, потому что для получения работающего базового уровня мы вынуждены были разработать некоторые элементы моделей, не существенные для архитектуры, но необходимые для создания исполняемого кода. Так как базовый уровень архитектуры используется не только для разработки архитектуры, но и для определения требований к системе на таком уровне, когда возможно создание детального плана, модель варианта использования этого базового уровня также может содержать не только те варианты использования, которые важны для построения архитектуры.
Описание
архитектуры будет
перестройку структуры
процесса.
Достижение
правильного баланса между
В трех словах: программы получаются лучше. Немного более развернуто: чтобы пройти главные и вспомогательные вехи, по которым мы контролируем ход разработки. И еще более развернуто.
Риск — это проектный фактор, который подвергает проект опасности. Это «вероятность того, что проект может столкнуться с нежелательной ситуацией, такой, как отставание от плана, перерасход средств или прекращение работ»
Мы идентифицируем, расставляем по приоритетам и выполняем итерации, основываясь на рисках и их опасности. Это так, когда мы реализуем новые технологии. Когда мы выполняем требования клиентов, не важно, функциональные они или нет. Когда на ранних стадиях мы создаем устойчивую архитектуру, то имеем в виду такую, которая может приспосабливаться к изменениям с малым риском того, что появится необходимость что-либо перепроектировать. Да, мы организуем итерации для того, чтобы уменьшить риски. Другие серьезные риски связаны с вопросами производительности (скорость, мощность, точность), надежности, доступности, целостности системных интерфейсов, адаптируемости и переносимости. Многие из этих рисков не могут быть обнаружены до реализации и начала тестирования программного обеспечения, которое осуществляет основные функции системы. Именно поэтому уже в фазах анализа и определения требований и проектирования следует предусмотреть итерации реализации и тестирования, в ходе которых изучались бы риски. Наша цель определить риски на ранних итерациях.
Интересно отметить, что в принципе все технические риски можно спроецировать на вариант использования или сценарий варианта использования. В данном случае «спроецировать» означает, что после реализации варианта использования с его функциональными и нефункциональными требованиями риск будет снижен. Это верно не только для тех рисков, которые относятся к требованиям и архитектуре, но и для рисков, связанных с базовыми программными и аппаратными средствами. Тщательно выбирая варианты использования, мы можем осуществить все функции базовой архитектуры.
Снижение рисков — это основная задача итераций, которые мы делаем в фазах анализа и определения требований и проектирования. Позже, в фазе построения, риски в основном уже уменьшены до приемлемого уровня, а значит, на первый план выходят стандартные методы разработки. Мы стараемся планировать итерации так, чтобы каждая следующая итерация была основана на предыдущей. В этой фазе мы стараемся, в частности, уйти от опасности того, что мы не сможем правильно определить порядок итераций, и нам придется переделывать несколько предыдущих итераций.
Как
мы могли заметить, итерации на разных
фазах цикла разработки сильно отличаются
друг от друга. Это происходит потому,
что различны задачи, с которыми разработчики
сталкиваются на разных фазах разработки.
В этом пункте мы намерены представить
концепцию итерации на базовом уровне:
что это такое, как ее планировать и каким
должен быть результат итерации.
Прежде всего Унифицированный
процесс есть процесс разработки
программного обеспечения. Процесс
разработки программного обеспечения
— это сумма различных видов
деятельности, необходимых для преобразования
требований пользователей в программную
систему. Однако Унифицированный процесс
— это больше чем единичный процесс, это
обобщенный каркас процесса, который может
быть специализирован для широкого круга
программных систем, различных областей
применения, уровней компетенции и размеров
проекта.
Информация о работе Унифицированный процесс разработки программного обеспесчения