В.В. Кулямин - Технологии программирования. Компонентный подход (1133554), страница 11
Текст из файла (страница 11)
Второй уровень названуправляемым (managed), а четвертый — управляемым на основе метрик (quantitativelymanaged).o Набор выделяемых областей процесса и практик значительно изменился.Все области процесса делятся на 4 категории. В приводимом ниже списке областипроцесса помечены номером уровня, начиная с которого они должны поддерживатьсясогласно CMMI. Управление процессом.Включает выработку и поддержку процесса (3), контроль соблюдения процесса (3),обучение (3), измерение показателей процесса (4), внедрение инноваций (5). Управление проектом.Включает планирование проектов (2), контроль хода проекта (2), управлениесоглашениями с поставщиками (2), интегрированное управление проектами (3),управление рисками (3), построение команд (3), управление поставщиками (3) иизмерение показателей результативности и хода проекта (4). Технические.Включают выработку требований (3), управление требованиями (2), выработкутехнических решений (3), интеграцию продуктов (3), верификацию (3) ивалидацию (3). Поддерживающие.Включают управление конфигурацией (2), обеспечение качества продуктов ипроцессов (2), проведение измерений и анализ их результатов (2), управлениеокружением (3), анализ и принятие решений (3), анализ, разрешение ипредотвращение проблем (5).В целом перечисленные стандарты связаны так, как показано на Рис.
2 (сплошные стрелкиуказывают направления исторического развития, жирная стрелка обозначает идентичность,пунктирные стрелки показывают влияние одних стандартов на другие).MIL-STD-498(не действует)Стандарты министерстваобороны и промышленностиСШАJ-Std-016-1995(не действует)IEEE 1074IEEE/EIA 12207ISO/IEC 12207CMMISO/IEC 15504 (SPICE)CMMIСтандарты IEEEСтандарты ISOСтандарты SEI, принятыеминистерством обороныСША в настоящее времяРисунок 2. Стандарты, описывающие структуру жизненного цикла ПО.Стандарты являются суммой опыта, который был накоплен экспертами в инженерии ПО наоснове огромного количества проектов, проводившихся в рамках коммерческих структур США и29Европы и в рамках военных контрактов.
Большая часть стандартов создавалась как наборкритериев отбора поставщиков программного обеспечения для министерства обороны США, и этузадачу они решают достаточно успешно.Все рассмотренные стандарты определяют некоторый набор видов деятельности, из которыхдолжен состоять процесс разработки, и задают ту или иную структуру на этих видах деятельности,выделяя их элементы. Вместе с тем, как можно заметить, они не могут быть сведены безсущественных изменений в единую модель жизненного цикла ПО.
В целом имеющиеся стандартыслабо согласованы между собой. Так что на сегодняшний день (2005 год) нет согласованногокомплекта стандартов, покрывающего всю данную область, и в ближайшие несколько лет он врядли появится, хотя работа по согласованию различных стандартов ведется.Кроме того, данные стандарты не предписывают четких и однозначных схем построенияжизненного цикла ПО, в частности, связей между отдельными деятельностями. Это сделанонамеренно, поскольку ранее действовавшие стандарты типа DoD-Std-2167, были достаточножестко привязаны к каскадной модели жизненного цикла (см.
ниже) и тем самым препятствовалииспользованию более прогрессивных технологий разработки. Современные стандарты стараютсямаксимально общим образом определить набор видов деятельности, которые должны бытьпредставлены в рамках жизненного цикла (с учетом целей отдельных проектов — т.е. проект, нестремящийся достичь каких-то целей, может не включать деятельностей, связанных с ихдостижением), и описать их при помощи наборов входных документов и результатов.Стоит заметить, что стандарты могут достаточно сильно разойтись с реальной разработкой,если в ней используются новейшие методы автоматизации разработки и сопровождения ПО.Стандарты организаций ISO и IEEE построены на основе имеющегося эмпирического опытаразработки, полученного в рамках распространенных некоторое время назад парадигм иинструментальных средств. Это не значит, что они устарели, поскольку их авторы имеютдостаточно хорошее представление о новых методах и технологиях разработки и пыталисьсмотреть вперед.
Но при использовании новаторских технологий в создании ПО часть требованийстандарта может обеспечиваться совершенно иными способами, чем это предусмотрено в нем, ачасть артефактов может отсутствовать в рамках данной технологии, исчезнув внутриавтоматизированных процессов.Модели жизненного циклаВсе обсуждаемые стандарты так или иначе пытаются описать, как должен выглядеть любойпроцесс разработки ПО. При этом они вынуждены вводить слишком общие модели жизненногоцикла ПО, которые тяжело использовать при организации конкретного проекта.В рамках специфических моделей жизненного цикла, которые предписывают правилаорганизации разработки ПО в рамках данной отрасли или организации, определяются болееконкретные процессы разработки.
Отличаются они от стандартов, прежде всего, большейдетальностью и четким описанием связей между отдельными видами деятельности, определениемпотоков данных (документов и артефактов) в ходе жизненного цикла. Таких моделей довольномного, ведь фактически каждый раз, когда некоторая организация определяет собственныйпроцесс разработки, в качестве основы этого процесса разрабатывается некоторая модельжизненного цикла ПО. В рамках данной лекции мы рассмотрим лишь несколько моделей. Ксожалению, очень тяжело выбрать критерии, по которым можно было бы дать хоть скольконибудь полезную классификацию известных моделей жизненного цикла.Наиболее широко известной и применяемой долгое время оставалась так называемаякаскадная или водопадная (waterfall) модель жизненного цикла, которая, как считается, былавпервые четко сформулирована в работе [13] и впоследствии запечатлена в стандартахминистерства обороны США в семидесятых-восьмидесятых годах XX века.
Эта модельпредполагает последовательное выполнение различных видов деятельности, начиная с выработкитребований и заканчивая сопровождением, с четким определением границ между этапами, накоторых набор документов, созданный на предыдущей стадии, передается в качестве входныхданных для следующей. Таким образом, каждый вид деятельности выполняется на какой-то однойфазе жизненного цикла. Предлагаемая в статье [13] последовательность шагов разработки30показана на Рис.
3. «Классическая» каскадная модель предполагает только движение вперед поэтой схеме: все необходимое для проведения очередной деятельности должно быть подготовленов ходе предшествующих работ.Выработка системныхтребованийВыработкатребований к ПОАнализПроектированиеКодированиеТестированиеЭксплуатацияРисунок 3.
Последовательность разработки согласно «классической» каскадной модели.Однако, если внимательно прочитать статью [13], оказывается, что она не предписываетследование именно этому порядку работ, а, скорее, представляет модель итеративного процесса(см. Рис. 4) — в ее последовательном виде эта модель закрепилась, по-видимому, в представлениичиновников из министерств и управленцев компаний, работающих с этими министерствами поконтрактам.
При реальной работе в соответствии с моделью, допускающей движение только водну сторону, обычно возникают проблемы при обнаружении недоработок и ошибок, сделанныхна ранних этапах. Но еще более тяжело иметь дело с изменениями окружения, в которомразрабатывается ПО (это могут быть изменения требований, смена подрядчиков, измененияполитик разрабатывающей или эксплуатирующей организации, изменения отраслевых стандартов,появление конкурирующих продуктов и пр.).Работать в соответствии с этой моделью можно, только если удается предвидеть заранеевозможные перипетии хода проекта и тщательно собирать и интегрировать информацию напервых этапах, с тем, чтобы впоследствии можно было пользоваться их результатами без оглядкина возможные изменения.Выработка системныхтребованийВыработкатребований к ПОАнализПроектированиеКодированиеТестированиеЭксплуатацияРисунок 4. Ход разработки, предлагаемый в статье [13].Среди разработчиков и исследователей, имевших дело с разработкой сложного ПО,практически с самого зарождения индустрии производства программ (см., например, [14])31большую популярность имели модели эволюционных или итеративных процессов, поскольку ониобладают большей гибкостью и способностью работать в меняющемся окружении.Итеративные или инкрементальные модели (известно несколько таких моделей)предполагают разбиение создаваемой системы на набор кусков, которые разрабатываются спомощью нескольких последовательных проходов всех работ или их части.На первой итерации разрабатывается кусок системы, не зависящий от других.
При этомбольшая часть или даже полный цикл работ проходится на нем, затем оцениваются результаты ина следующей итерации либо первый кусок переделывается, либо разрабатывается следующий,который может зависеть от первого, либо как-то совмещается доработка первого куска сдобавлением новых функций. В результате на каждой итерации можно анализироватьпромежуточные результаты работ и реакцию на них всех заинтересованных лиц, включаяпользователей, и вносить корректирующие изменения на следующих итерациях.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
