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