Lecture02 (1133559), страница 4
Текст из файла (страница 4)
Ход разработки, предлагаемый в статье [13].Среди разработчиков и исследователей, имевших дело с разработкой сложного ПО,практически с самого зарождения индустрии производства программ (см., например, [14])большую популярность имели модели эволюционных или итеративных процессов, поскольку ониобладают большей гибкостью и способностью работать в меняющемся окружении.Итеративные или инкрементальные модели (известно несколько таких моделей)предполагают разбиение создаваемой системы на набор кусков, которые разрабатываются спомощью нескольких последовательных проходов всех работ или их части.На первой итерации разрабатывается кусок системы, не зависящий от других.
При этомбольшая часть или даже полный цикл работ проходится на нем, затем оцениваются результаты ина следующей итерации либо первый кусок переделывается, либо разрабатывается следующий,который может зависеть от первого, либо как-то совмещается доработка первого куска сдобавлением новых функций. В результате на каждой итерации можно анализироватьпромежуточные результаты работ и реакцию на них всех заинтересованных лиц, включаяпользователей, и вносить корректирующие изменения на следующих итерациях.
Каждая итерацияможет содержать полный набор видов деятельности от анализа требований, до ввода вэксплуатацию очередной части ПО.Анализ требованийАнализ требованийПроектированиеПроектированиеКодированиеТестированиеКодированиеТестированиеРазвертываниеПроектированиеКодированиеТестированиеРазвертываниеЭксплуатация1-я итерация2-я итерация3-я итерацияРисунок 5. Возможный ход работ по итеративной модели.Каскадная модель с возможностью возвращения на предшествующий шаг при необходимостипересмотреть его результаты, становится итеративной.Итеративный процесс предполагает, что разные виды деятельности не привязаны намертво копределенным этапам разработки, а выполняются по мере необходимости, иногда повторяются, дотех пор, пока не будет получен нужный результат.Вместе с гибкостью и возможностью быстро реагировать на изменения, итеративные моделипривносят дополнительные сложности в управление проектом и отслеживание его хода.
Прииспользовании итеративного подхода значительно сложнее становится адекватно оценить текущеесостояние проекта и спланировать долгосрочное развитие событий, а также предсказать сроки иресурсы, необходимые для обеспечения определенного качества результата.Развитием идеи итераций является спиральная модель жизненного цикла ПО, предложеннаяБоэмом (Boehm) в [15].
Она предлагает каждую итерацию начинать с выделения целей ипланирования очередной итерации, определения основных альтернатив и ограничений при еевыполнении, их оценки, а также оценки возникающих рисков и определения способов избавленияот них, а заканчивать итерацию оценкой результатов проведенных в ее рамках работ.Основным ее новым элементом является общая структура действий на каждой итерации —планирование, определение задач, ограничений и вариантов решений, оценка предложенныхрешений и рисков, выполнение основных работ итерации и оценка их результатов.Название спиральной эта модель получила из-за изображения хода работ в «полярныхкоординатах», в которых угол соответствует выполняемому этапу в рамках общей структурыитераций, а удаление от начала координат — затраченным ресурсам.СовокупнаястоимостьХод работОпределение задач,альтернатив,ограниченийОценка альтернатив,выделение рисков испособов борьбы снимиАнализ рисковАнализ рисковАнализ рисковФиксациярезультатовПрототипЭкспертизыПлан жизненногоцикла и работы с Концепциятребованиями продуктаМоделиРабочийпрототипПрототипМоделиНаборы тестовРазработка ивалидациятребованийПланразработкиПроектированиеПроектированиемодулейКодированиеПлан интеграциии тестированияПланированиеследующихитерацийВерификация ивалидация проектаРазвертываниеТестированиемодулейИнтеграция итестированиесистемыПриемочноеРазработка итестированиеверификацияочередной частипродуктаРисунок 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.[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..
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
