В.В. Кулямин - Технологии программирования. Компонентный подход (1133554), страница 12
Текст из файла (страница 12)
Каждая итерацияможет содержать полный набор видов деятельности от анализа требований, до ввода вэксплуатацию очередной части ПО.Анализ требованийАнализ требованийПроектированиеПроектированиеКодированиеТестированиеКодированиеТестированиеРазвертываниеПроектированиеКодированиеТестированиеРазвертываниеЭксплуатация1-я итерация2-я итерация3-я итерацияРисунок 5.
Возможный ход работ по итеративной модели.Каскадная модель с возможностью возвращения на предшествующий шаг при необходимостипересмотреть его результаты, становится итеративной.Итеративный процесс предполагает, что разные виды деятельности не привязаны намертво копределенным этапам разработки, а выполняются по мере необходимости, иногда повторяются, дотех пор, пока не будет получен нужный результат.Вместе с гибкостью и возможностью быстро реагировать на изменения, итеративные моделипривносят дополнительные сложности в управление проектом и отслеживание его хода.
Прииспользовании итеративного подхода значительно сложнее становится адекватно оценить текущеесостояние проекта и спланировать долгосрочное развитие событий, а также предсказать сроки иресурсы, необходимые для обеспечения определенного качества результата.Развитием идеи итераций является спиральная модель жизненного цикла ПО, предложеннаяБоэмом (Boehm) в [15]. Она предлагает каждую итерацию начинать с выделения целей ипланирования очередной итерации, определения основных альтернатив и ограничений при еевыполнении, их оценки, а также оценки возникающих рисков и определения способов избавленияот них, а заканчивать итерацию оценкой результатов проведенных в ее рамках работ.Основным ее новым элементом является общая структура действий на каждой итерации —планирование, определение задач, ограничений и вариантов решений, оценка предложенныхрешений и рисков, выполнение основных работ итерации и оценка их результатов.Название спиральной эта модель получила из-за изображения хода работ в «полярныхкоординатах», в которых угол соответствует выполняемому этапу в рамках общей структурыитераций, а удаление от начала координат — затраченным ресурсам.32СовокупнаястоимостьХод работОпределение задач,альтернатив,ограниченийОценка альтернатив,выделение рисков испособов борьбы снимиАнализ рисковАнализ рисковАнализ рисковФиксациярезультатовПрототипЭкспертизыПлан жизненногоцикла и работы с Концепциятребованиями продуктаМоделиРабочийпрототипПрототипМоделиНаборы тестовРазработка ивалидациятребованийПланразработкиПроектированиеПроектированиемодулейКодированиеПлан интеграциии тестированияПланированиеследующихитерацийВерификация ивалидация проектаРазвертываниеТестированиемодулейИнтеграция итестированиесистемыПриемочноеРазработка итестированиеверификацияочередной частипродуктаРисунок 6.
Изображение хода работ по спиральной модели согласно [15].Рис. 6 показывает возможное развитие проекта по спиральной модели. Количество витков, атакже расположение и набор видов деятельности в правом нижнем квадранте могут изменяться взависимости от результатов планирования и анализа рисков, проводимых на предыдущих этапах.На следующей лекции мы рассмотрим в деталях два современных итеративных процессаразработки — унифицированный процесс разработки Rational и экстремальное программирование.Литература к Лекции 2[1] ISO/IEC 12207:1995, Information Technology — Software life cycle processes, 1995.Amendments 2002, 2004.[2] ГОСТ Р-1999.
ИТ. Процессы жизненного цикла программных средств.[3] ISO/IEC 15288:2002, Systems engineering — System life cycle processes, 2002.[4] ISO/IEC 15504-1-9, Information technology — Process assessment, Parts 1-9.15504-1,3,4:2004, 15504-2:2003/Cor 1:2004, TR 15504-5:2004.[5] IEEE 1074-1997 IEEE Standard for Developing Software Life Cycle Processes, 1997.[6] IEEE/EIA 12207.0-1996 Industry Implementation of International Standard ISO/IEC 12207:1995,New York, Mar. 1998.33[7] IEEE/EIA 12207.1-1997 Industry Implementation of International Standard ISO/IEC 12207:1995Software Life Cycle Processes — Life Cycle Data, New York, Apr.
1998.[8] IEEE/EIA 12207.2-1997 Industry Implementation of Int'l Standard ISO/IEC 12207:1995 SoftwareLife Cycle Processes — Implementation Considerations, New York, Apr. 1998.[9] M. C. Paulk, B. Curtis, M. B. Chrissis, and C. V. Weber. Capability Maturity Model for Software,Version 1.1, SEI Technical Report CMU/SEI-93-TR-024, Software Engineering Institute,Pittsburgh, Feb. 1993.http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr24.93.pdf[10] M. C. Paulk, C. V. Weber, S. M. Garcia, M. B. Chrissis, and M. Bush.
Key Practices of theCapability Maturity Model, Version 1.1, SEI Technical Report CMU/SEI-93-TR-025, SoftwareEngineering Institute, Pittsburgh, Feb. 1993.http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr25.93.pdf[11] Capability Maturity Model Integration (CMMI), Version 1.1. CMMI for Systems Engineering,Software Engineering, Integrated Product and Process Development, and Supplier Sourcing(CMMI-SE/SW/IPPD/SS, V1.1).
Continuous Representation. SEI Technical Report CMU/SEI2002-TR-011, Software Engineering Institute, Pittsburgh, March 2002.http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr011.pdf[12] Capability Maturity Model Integration (CMMI), Version 1.1. CMMI for Systems Engineering,Software Engineering, Integrated Product and Process Development, and Supplier Sourcing(CMMI-SE/SW/IPPD/SS, V1.1). Staged Representation. SEI Technical Report CMU/SEI-2002TR-012, Software Engineering Institute, Pittsburgh, March 2002.http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr012.pdf[13] W. W. Royce.
Managing the Development of Large Software Systems. Proceedings of IEEEWESCON, pp. 1–9, August 1970.Переиздана: Proceedings of the 9th International Software Engineering Conference, ComputerSociety Press, pp. 328–338, 1987.[14] B. Randell, F. W. Zurcher. Iterative Multi-Level Modeling: A Methodology for ComputerSystem Design. Proc. IFIP, IEEE CS Press, 1968.[15] B.
Boehm. A Spiral Model of Software Development and Enhancement. Computer, May 1988,pp. 61-72.[16] И. Соммервилл. Инженерия программного обеспечения. М.: Вильямс, 2002.[17] У. Ройс. Управление проектами по созданию программного обеспечения. М.: Лори, 2002.[18] Э. Дж. Брауде. Технология разработки программного обеспечения. СПб.: Питер, 2004.34Лекция 3.
Унифицированный процесс разработки и экстремальноепрограммированиеАннотацияРассматриваются в деталях модели разработки ПО, предлагаемые в рамках унифицированногопроцесса разработки Rational (RUP) и экстремального программирования (XP).Ключевые слова«Тяжелые» процессы разработки, «живые» методы разработки, унифицированный процессRational, экстремальное программирование, модели ПО.Текст лекции«Тяжелые» и «легкие» процессы разработкиВ этой лекции мы рассмотрим детально два процесса разработки — унифицированный процессRational (Rational Unified Process, RUP) и экстремальное программирование (ExtremeProgramming, XP). Оба они являются примерами итеративных процессов, но построены на основеразличных предположений о природе разработки программного обеспечения и, соответственно,достаточно сильно отличаются.RUP является примером так называемого «тяжелого» процесса, детально описанного ипредполагающего поддержку собственно разработки исходного кода ПО большим количествомвспомогательных действий.
Примерами подобных действий являются разработка планов,технических заданий, многочисленных проектных моделей, проектной документации, и пр.Основная цель такого процесса — отделить успешные практики разработки и сопровождения ПОот конкретных людей, умеющих их применять. Многочисленные вспомогательные действия даютнадежду сделать возможным успешное решение задач по конструированию и поддержке сложныхсистем с помощью имеющихся работников, не обязательно являющихся суперпрофессионалами.Для достижения этого выполняется иерархическое пошаговое детальное описаниепредпринимаемых в той или иной ситуации действий, чтобы можно было научить обычногоработника действовать аналогичным образом.
В ходе проекта создается много промежуточныхдокументов, позволяющих разработчикам последовательно разбивать стоящие перед ними задачина более простые. Эти же документы служат для проверки правильности решений, принимаемыхна каждом шаге, а также отслеживания общего хода работ и уточнения оценок ресурсов,необходимых для получения желаемых результатов.Экстремальное программирование, наоборот, представляет так называемые «живые» (agile)методы разработки, называемые также «легкими» процессами.
Они делают упор на использованиихороших разработчиков, а не хорошо отлаженных процессов разработки. Живые методы избегаютфиксации четких схем действий, чтобы обеспечить большую гибкость в каждом конкретномпроекте, а также выступают против разработки дополнительных документов, не вносящихнепосредственного вклада в получение готовой работающей программы.Унифицированный процесс RationalRUP [1,2] является довольно сложной, детально проработанной итеративной модельюжизненного цикла ПО.Исторически RUP является развитием модели процесса разработки, принятой в компанииEricsson в 70-х–80-х годах XX века.
Эта модель была создана Джекобсоном (Ivar Jacobson),впоследствии, в 1987, основавшим собственную компанию Objectory AB именно для развитиятехнологического процесса разработки ПО как отдельного продукта, который можно было быпереносить в другие организации. После вливания Objectory в Rational в 1995 разработкиДжекобсона были интегрированы с работами Ройса (Walker Royce, сын автора «классической»каскадной модели), Крухтена (Philippe Kruchten) и Буча (Grady Booch), а также с развивавшимсяпараллельно универсальным языком моделирования (Unified Modeling Language, UML).35RUP основан на трех ключевых идеях.• Весь ход работ направляется итоговыми целями проекта, выраженными в виде вариантовиспользования (use cases) — сценариев взаимодействия результирующей программнойсистемы с пользователями или другими системами, при выполнении которых пользователиполучают значимые для них результаты и услуги.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
