первоочередное внимание, благодаря итерационному процессу, благодаря просвещенному и открытому для сотрудничества заказчику, а также благодаря применению современных среды, языков и инструментария.

В целом за счет Подсистемы общего назначения был выполнен большой объем черновой работы для подсистем PDS и STRATCOM, например: определение процесса, создание инструментария и повторно используемых примитивов архитектуры. Отдача от этих затрат в виде возросших продуктивности и качества была получена при создании последующих подсистем. Все это результат зрелого процесса по созданию ПО, такого, который был разработан и усовершенствован в рамках проекта CCPDS-R.

CCPDS-R был жестко регламентирован стандартом DOD-STD-2167A Министерства обороны, и в результате его выполнения были переданы все указанные в контракте документы по Подсистеме общего назначения. По мере того как заинтересованные стороны набирались опыта в осуществлении нового итерационного процесса и обзоров, основанных на демонстрациях, их давление на разработчиков с целью получения неэффективной документации начинало ослабевать. Заказчик и пользователь становились более осведомленными в вопросе расширения возможностей, чем это было при работе с бумагами.

Одним из самых главных (и тонких) улучшений, сделанных в результате применения такого подхода к разработке ПО в рамках CCPDS-R, явилась совместная работа заказчика, пользователя и подрядчика. Постоянный обмен информацией, переговоры и интерпретация результатов выполнения контракта оказались весьма продуктивными в смысле достижения реального прогресса и получения гарантий того, что каждая стадия жизненного цикла приводила к ситуации, полностью удовлетворяющей каждую заинтересованную сторону.

Уровень изменчивости требований был умеренным, но с бесконечными изменениями пользовательского интерфейса, алгоритмов оповещения о ракетных запусках и других аспектов, к которым приходилось приноравливаться в процессе выполнения проекта. Компании TRW также пришлось вносить изменения в архитектуру, в технологию и учитывать другие отклонения — касающиеся разработки — от первоначального технического задания. Требования постоянно менялись в процессе разработки и стабилизировались только после принятия КОП в качестве основы, подлежащей тестированию. Однако в конце выполнения проекта произошло еще одно существенное изменение рамок контракта, которое поменяло большую часть приведенных в настоящем практическом примере данных с целью получения более удобочитаемого представления. Эти изменения произошли на 35-ом месяце выполнения контракта, и касались они полного пересмотра формата входных сообщений для всей системы. Поскольку повышенное внимание уделялось производительности, большинство компонентов было создано с жесткой привязкой к формату входных сообщений. В отличие от других изменений архитектуры, алгоритмов и вывода такой вид изменений не был предусмотрен. Соответственно, в процессе разработки определенная легкость внесения изменений в формат сообщений была принесена в жертву для улучшения работоспособности. Дефект, явившийся следствием этого изменения, не был настолько локализован, насколько этого хотелось, однако он был ис~ правлен с предсказуемыми затратами. Поздний всплеск в объеме доработок (изменения при сопровождении, показанные на рис. D.14) явился результатом реализации этого существенного нововведения. Все заинтересованные стороны были удовлетворены окончательным решением.

Таблица D.15.

Улучшение технологии в рамках проекта CCPDS-R

Описанная выше степень изменчивости требований привела бы к краху большинства проектов, использующих традиционный подход к управлению. Процесс выполнения проекта CCPDS-R поддерживался на должном уровне и при сохранении неантагонистических отношений между заинтересованными сторонами на протяжении всего жизненного цикла, сопровождающегося умеренным уровнем изменчивости требований. Хотя это трудно описать количественно и качественно, я думаю, что это является наиболее значительным достижением всего проекта.

Как обсуждалось в главе 15, успешные проекты имеют тенденцию сохранять баланс между всеми необходимыми технологиями. Чрезмерное внимание, уделяемое какой-либо одной технологии, никогда не приводит к успеху. Взвешенный подход к технологиям необходим для успешного завершения большого проекта. В этом смысле проект CCPDS-R является хорошим примером. Были произведены значительные затраты на разработку правильного процесса, на интегрирование инструментария в эффективную среду и на разработку тех компонентов архитектуры, которые были необходимы для реализации подхода, основанного на демонстрациях. Все заинтересованные стороны (разработчики, менеджеры, заказчики и пользователи) были вовлечены в неантагонистические отношения и трудились во имя общих целей.

Команда проекта CCPDS-R была успешной на протяжении всего выполнения проекта. Многие люди и целые организации внесли свой вклад в успешное осуществление проекта, однако следующие специалисты оказали наибольшее влияние на общий подход к управлению проектом: Том Бостлаар, Чарльз Гролинг, Том Херман, Терри Крупп, Стив Петэй, Пэтти Шишидо и Майк Спрингмен (все из компании TRW); Джерри Лакруа (компания Mitre); Пол Харткист и Билл Веннингер (военно-воздушные силы США). Навыки управления проектами Дона Андреса (компания TRW) оказались очень важными для осуществления нового процесса по созданию ПО с огромным количеством здравых идей и для достижения успеха в боевых условиях широкомасштабного проекта государственной важности под пристальным вниманием со стороны множества правительственных организаций.