CC BY
147
ЗАРУБЕЖНЫЙ ОПЫТ
УДК 338.24.01: 65.011.56
модели структуры программ
приобретения продукции в соединенных штатах америки
и их применение при разработке программного обеспечения
л.ю. судакова,
ведущий консультант отдела решений для управления эффективностью бизнеса E-mail: avocadus@gmail.com ООО «Энвижн-Консалтинг», Москва
В статье обобщены материалы американских публикаций и официальных документов по вопросам приобретения программного обеспечения (ПО). Рассматриваются принятые в США модели разработки программного обеспечения: «водопадная», спиральная, спирально-круговая, производства линейки программных продуктов, гибкой разработки ПО, — во взаимосвязи с моделями структуры программ приобретения продукции (традиционная, эволюционная, разработки по итерациям и приращениям, гибридная) с дифференциацией применительно к использованию в коммерческом и в государственном секторах.
Представлены результаты применения указанных моделей при разработках ПО. Как показывает опыт работы коммерческих фирм, сокращения затрат и сроков реализации разработки и поставок ПО для ИТ-систем можно добиться за счет применения передовых моделей и методологий разработки и структуризации программ приобретения. Программное обеспечение для коммерческого рынка разрабатывается преимущественно в соответствии с моделью разработки по итерациям и приращениям, которая предусматривает поставки ПО в релизах с постепенным расширением его функциональных возможностей.
Программное обеспечение для федеральных нужд в США, как правило, разрабатывалось в соответствии с традиционной моделью структуры
программ приобретения, которая характеризуется детальной разработкой системных требований и технического задания, а также выполнением работ в точном соответствии с ними. Это стало одной из главных причин того, что к 2010 г. большие ИТ-программы, например в министерстве обороны США, реализовывались в течение 6-8-летнего цикла при примерно 18-месячном цикле развития коммерческих технологий. Это, в конечном счете, отражалось на качестве и моральном старении разработок. Проведен анализ того, каким образом федеральные агентства собираются использовать передовой опыт коммерческого сектора по разработке ПО.
Ключевые слова: разработка программного обеспечения, разработка программного обеспечения по приращениям, гибкая разработка программного обеспечения, управление программой, программа приобретения информационных технологий
Введение
В отечественной литературе вопросы управления проектами разработки программного обеспечения (ПО) с привязкой к порядку их финансирования освещены недостаточно полно. В зарубежной же литературе, наоборот, имеется широкий круг публикаций по данной тематике, что связано, вероятно,
с уже традиционной необходимостью выполнения требований системы менеджмента качества выпускаемой продукции промышленными фирмами. Попытки поделиться в этом свете передовым опытом, в силу особой природы объекта рассмотрения, во многом оказываются многословными, причем с трудом воспринимаются как заинтересованными читателями, так и профильными специалистами. В результате формируется упрощенное представление о «раскладке» программ разработки продукции по задачам, срокам и ресурсам, а также о характере деятельности и роли программных менеджеров в процессе разработок ПО, в том числе и у них самих. Это становится одной из главных причин неудачных проектов, срыва сроков проведения работ и роста затрат на них.
В данном исследовании сделана попытка обобщить материалы американских публикаций и официальных документов по вопросам приобретения ПО и сделать их изложение системным, т.е. более кратким, информационно емким и доступным для восприятия. Знакомство с имеющимися российскими публикациями в рассматриваемой области, главным образом, на специализированных форумах в сети Интернет1, показало, что их авторы неплохо осведомлены о профиле работы и творчески подходят, например, к формированию гибридных моделей структуры проектов разработки ПО на основе своего практического опыта. Однако, как показывает опыт прямого общения со специалистами, отличия моделей друг от друга, области, детали и нюансы их использования чаще всего остаются «за кадром», в результате чего управление разработками во многом вновь и вновь катится по традиционным путям без извлечения преимуществ передовых наработок.
Исходя из сказанного, в статье будут рассмотрены, во-первых, модели разработки продукции, а, во-вторых — модели структуры программ приобретения продукции применительно к использованию в коммерческом и в государственном секторах. Сразу же следует отметить, что программа приобретения продукции в американской терминологии охватывает всю совокупность этапов ее жизненного цикла — от определения концепции и разработки продукта (образца, системы) до его производства,
1 Два протокола управления проектами. URL: http:// splaniroval.ru/blog/lifecycle-methodology/2010/19; Переход от каскадной разработки к итеративной. URL: http://splaniroval. ru/blog/lifecycle-methodology/2008/1515; Компания Informicus: разработчик CRM-систем. URL: http://informicus.ru.
технической поддержки в процессе эксплуатации и утилизации. Затем будут представлены результаты применения всех этих моделей при разработках ПО. Причем для наглядности особенности разработки ПО подчеркиваются на фоне разработки материальных продуктов (изделий).
Модели разработки продукции (образцов и систем)
Рассмотрим 4 модели разработки, существовавшие до начала 2000-х гг.:
1) «водопадная» (Waterfall model);
2) спиральная (Spiral model — в виде плоской спирали);
3) спирально-круговая (Spiral-to-circle model);
4) линейки продуктов ПО (Software product line model) [4].
Следует отметить, что в начале 2000-х гг. появился комбинированный подход гибкой разработки ПО.
«Водопадная» модель предусматривает последовательное выполнение преимущественно неизменяемых шагов, особенно типичных для приобретения материальных продуктов [например, аппаратные средства (АС) и производственные мощности]. Такими шагами могут быть, в частности: анализ корпоративных потребностей и ресурсов; моделирование; системная разработка; подготовка экспериментальных производственных мощностей; строительство производственных мощностей; сертификация; производство; техобслуживание и поддержка; реконфигурация; адаптация; прекращение производства.
В отношении линейки выпускаемых продуктов может выполняться следующая последовательность: анализ потребностей и ресурсов пользователей; разработка концепции и модели; описание интерфейсов; системная разработка; производство; сертификация; эксплуатация и диагностика; оценка и адаптация. По инерции данная модель достаточно часто переносится на приобретение систем с большой долей ПО, что будет показано ниже. Ход работ в водопадной модели достаточно жестко регламентируется заблаговременно разработанными документами, по последовательной реализации положений которых можно формально судить о степени успешности выполняемой программы приобретения. В результате «водопадную» модель целесообразно применять, когда облик разрабатываемого продукта четко определен, требования к нему и техническое задание на разработку утверждаются заранее и остаются неизменными.
- 1 (286) - 2015 -
Модель плоской спирали представляет итеративный процесс разработки ПО. Ее автором считается Б. Боэм (1988) [7], который, работая в компании TRW, разработал и использовал эту модель при реализации госконтрактов по большим проектам ПО. В этой модели каждый виток расходящейся плоской спирали проходит через 4 этапа: 1) определение требований; 2) проектирование; 3) разработка; 4) испытание и оценка. Разрабатываемые на каждом витке версии ПО базируются на уроках, полученных на предыдущих витках. В итеративном процессе при планировании и в ходе дальнейших работ надо более строго учитывать существующие и прогнозируемые риски. Ведь при применении спиральной модели каждый виток начинается с определения главных задач той части программного продукта, которая разрабатывается детально (по характеристикам, функциональным возможностям, способности адаптироваться к изменениям и др.), анализа альтернативных средств реализации этой части продукта (вариант А или вариант Б, существует ли возможность использования ПО многократного применения либо закупки готовых коммерческих продуктов и др.), исследования ограничений, налагаемых на применение альтернатив (по затратам, календарным срокам, интерфейсам и др.). На последующих шагах оцениваются альтернативы, выявляются риски и находятся решения по их снижению, проводятся разработка и испытания программного продукта новой версии, планируются следующие фазы.
Спирально-круговая модель [7] приспособлена к процессам разработки как АС, так и ПО. Она базируется на следующем эвристическом положении: «При существовании стабильных промежуточных форм своего состояния сложные системы могли бы разрабатываться и развиваться в рамках общей архитектуры намного быстрее, чем в условиях отсутствия таких форм». При разработке АС модель подразумевает запланированные остановки работ в конце каждого шага в их последовательности для оценки проведенной разработки и определения того, что целостность системной концепции не была нарушена (все, что необходимо, сделано, и ничего ненужного не добавлено).
При разработке ПО эта модель предусматривает последовательные паузы каждый раз после прохождения ряда ее витков путем перевода очередного витка спирали в замкнутый круг для создания стабильной версии ПО. Поскольку это единая модель, она подразумевает, что промежуточная
форма является не только стабильной, но и может очень долго использоваться (с учетом достижения приемлемых границ по бюджету ее эксплуатации или реализации потребностей пользователей). Кроме того, могут проводиться разработки и создание прототипов на этом круге до принятия решения на переход к следующей спирали для получения новых функциональных возможностей и форм.
Спирально-круговая модель также может быть полезным инструментом административного управления там, где требуется интегрировать аппаратные и программные компоненты в одной и той же системе. При объединенной разработке АС и ПО переход в замкнутый круг может производиться для проведения испытаний и исследования целесообразности и масштабов развертывания полученных стабильных конфигураций АС и ПО. Модель применима и к системам с большой долей аппаратных средств, которые разрабатывались с использованием методологии приобретения на основе имитационных процессов. Кроме того, модель должна быть полезным инструментом интеграции, когда коммерческие или другие готовые компоненты используются вместо разработки новых компонентов [4].
Модель линейки продуктов ПО предусматривает получение программных систем, в которых совместно используется набор общих атрибутов (например, функциональные возможности, архитектура, проект, компоненты/ модули, процессы разработки/ обслуживания). Если такие атрибуты лежат в их основе, могут создаваться системы, удовлетворяющие специфическим требованиям заказчиков. В качестве прототипа она начала использоваться в 1990-х гг. в программе Управления перспективных исследовательских проектов министерства обороны США «Технология программного обеспечения для адаптивных, надежных систем» (STARS — software technology for adaptable, reliable systems).
Экспериментальные работы успешно продемонстрировали выгоды разработки общих архитектуры и стандартов по направлениям разработки ПО (например, прикладного для автоматизированных систем управления и их интеграции или системного для больших инфраструктурных проектов) и последующего использования этой базы в интересах значительного сокращения времени проектирования, разработки и тестирования последующих приложений этого направления. Вероятно, работы такого рода легли в основу сервис-ориентированных архитектур, реализация которых стала возможной после появления в начале 2000-х гг. аппаратных ре-
- 1 (286) - 2015 -
сурсов нового поколения, обладающих достаточной для организации совместной работы программных компонентов многоразового использования производительностью.
Модели структуры программ приобретения
С учетом указанных моделей разработки созданы так называемые модели структуры программ приобретения. Структура любой программы составляет базовую часть стратегии приобретения, под которой подразумевают установленные для этой программы фазы процесса и рубежи принятия органами надзора решений. От нее зависит порядок финансирования проводимых фаз и этапов. Эти модели, в свою очередь, усложняются в случае проведения разработок для государственных нужд, поскольку требуют привязки к процессу разработки, планирования, программирования и исполнения государственного бюджета с осуществлением дополнительных надзорных процедур за целевым расходованием денежных средств. Основными из моделей структуры программ приобретения являются традиционная, большого проекта, приращений возможностей и эволюционная [4].
Традиционная модель, применяемая, например, министерством обороны США (МО) при проведении наиболее дорогостоящих программ приобретения [8], в настоящее время отражает последовательный пятифазный процесс с рядом точек принятия промежуточных решений и тремя контрольными рубежами принятия инвестиционных решений в отношении продолжения программ и их перевода в следующую фазу. Первая (анализ материального решения) и вторая фазы (исследование зрелости технологии и снижения рисков программы) относятся к подготовительной части программы. С третьей фазы (разработка продукта, включая его изготовление, испытания по итогам разработки и оценки его применимости, подготовку производства) начинается собственно процесс приобретения. При ее успешном завершении принимается решение о финансировании четвертой фазы начального производства и развертывания продукта, а также проведения начальных эксплуатационных испытаний и оценок для малой партии произведенного продукта. Наконец, после окончательной доработки продукта в интересах предоставления им наиболее полных функциональных возможностей и последующего принятия решения о его полномасштабном производстве осуществляется переход к
пятой фазе эксплуатации и поддержки продукта, по завершении которой производится утилизация его образцов.
Модель большого проекта характеризуется приобретением, разработками и развертыванием образцов продукции в рамках одного цикла разработки. Она применяется в тех редких случаях, когда облик будущего продукта четко определен, причем его дальнейшее совершенствование не считается необходимым. При этом требования пользователей абсолютно понятны, четко сформулированы и, самое главное, остаются неизменными. Одновременно проводимая оценка других факторов (например, рисков, финансирования, календарных сроков, сроков отдачи инвестиций) также должна ясно подтвердить, что пофазный подход не требуется.
Модель приращений возможностей характеризуется приобретением, разработками и развертыванием образцов продукции, периодически совершенствуемых с каждым последующим циклом разработки. В циклах реализуются четко заданные приращения возможностей продуктов (образцов, систем), которые не зависят друг от друга и являются самодостаточными. Число, масштаб и разбивка приращений по привязанным к календарным срокам фазам, проведение которых требуется для удовлетворения всего объема сформулированных требований пользователей, должны определяться программным менеджером, в том числе на основе результатов консультаций с пользователями продукции. Модель наиболее применима, когда требования пользователей абсолютно понятны и четко сформулированы, а оценка других факторов (например, риски, финансирование, календарные сроки, масштаб программы или сроки реализации выгод) показывают, что пофазный подход наиболее целесообразен или выгоден. Вместе с тем характерная для множества программ приобретения неопределенность в требованиях к программному обеспечению, используемому в продукте, вынуждает адаптировать способы применения этой модели.
Эволюционная модель характеризуется проектированием, разработкой и развертыванием прототипов на основе использования существующей технологии и механизмов с дальнейшим их эволюционным совершенствованием по мере определения новых требований и созревания новых технологий. Другими словами, если на основе имеющихся технологий можно создавать систему с необходимым, хотя и неполным, набором функциональных возможностей, ее разработка может запускаться,
- 1 (286) - 2015 -
но при условии приемлемости рисков, связанных с дозреванием новых технологий, которые в будущем позволят реализовывать и остальные требуемые наборы возможностей. Тем самым общее время разработки при применении такого эволюционного подхода снижается. Эволюционная модель отличается от модели приращений тем, что вначале определяется лишь базовый вариант облика системы с базовыми функциональными возможностями.
По мере совершенствования продукта (по факту — прототипа), исходя из достигнутых результатов и степени созревания используемых технологий, набор требований к нему расширяется в рамках возможностей их реализации. Эволюционная модель предлагает альтернативу традиционной модели для тех программ, реализация которых хотя и не связана с технологическими прорывами, но требует определенного периода созревания технологий и допускает использование временных решений с дальнейшим проведением циклов их совершенствования. Отметим, что в США проводимые демонстрации концепций перспективных технологий и разработки с использованием эволюционной модели характеризуются некоторой аналогичностью в том, что у них короткое время цикла и общие цели по разработке и внедрению новейших технологий. Демонстрации, однако, ориентированы на разработку концепций применимости таких технологий и далеко не всегда ведут к развертыванию производства. Эволюционные модели, наоборот, ориентированы на производство с самого начала.
Все четыре вышеописанные модели могут корректироваться для поддержки использования коммерческих и готовых решений.
Совершенствование процессов разработки ПО для государственного сектора
Рассмотрение процессов приобретения для государственного сектора будет проводиться на примере мирового лидера в информационных технологиях (ИТ) — США. Следует подчеркнуть, что доля министерства обороны (МО) США в ИТ-расходах среди 27 министерств и ведомств страны является наибольшей: в финансовом 2010/11 г. — 48% [9]. В финансовом 2015/16 г. планируется некоторое ее снижение до 45% [20].
С 1950-х гг. ПО разрабатывалось аналогично разработке материальных продуктов (изделий). Сначала процесс шел по принципу «написал код и устранил неполадки». Но по мере усложнения ПО
неупорядоченное устранение неполадок стало требовать слишком больших ресурсов. Стало ясно, что до разработки кода необходимо проведение этапов разработки требований, проектирования ПО и подготовки к его тестированию. В результате во второй половине 1950-х гг. появилась «каскадная» модель, а в 1970-х гг. — ее несколько усовершенствованный вариант — «водопадная» модель, содержащая обратные связи между текущим и предыдущим последовательными этапами [6].
«Водопадная» модель — это последовательный процесс разработки ПО, в которой проект сверху вниз проходит через последовательность фаз — концептуальную, запуска, анализа, проектирования, разработки, испытаний и поддержки, эксплуатации. Многие из применяемых в настоящее время процедур приобретения ПО опираются на предположение, что можно заранее установить требования к системе, утвердить цену за ее разработку, разработать за эту цену, а затем произвести ее тиражирование и инсталляцию на объектах развертывания. На самом деле это неправильно, поскольку многие проблемы приобретения ПО возникают именно из-за этого самообмана [10].
Согласно мнению экспертов [11], «водопадная» модель структуризации и упорядочивания процесса разработки ПО официально была принята в 1990-х гг., хотя применялась и ранее. До этого она представляла итеративный процесс, сфокусированный на поиске и устранении «слабых мест» в ПО, по возможности, как можно раньше в ходе разработки. Однако далее он был не совсем правильно истолкован как чисто последовательный подход, который и был закреплен в стандартах по заключению государственных контрактов. В итоге процесс в значительной степени утерял признаки итеративности ввиду ослабления обратных связей между текущим и предыдущим этапами. Он стал начинаться с изучения осуществимости проекта, составления и официального утверждения технического задания (спецификации). Далее следовал запрос на предложение цены контракта, за которым шли конкурсная процедура заключения контракта, блочная и детальная разработка проекта (алгоритмов) ПО согласно спецификации, собственно написание кода, тестирование компонентов ПО, системные тестирование, отладка и интеграция, поставка, инсталляция и поддержка программной системы.
Вероятной причиной такой трансформации в виде чисто последовательного подхода стало
согласование «водопадной» модели разработки ПО с традиционной моделью структуры программ приобретения, которая часто применяется в процессах приобретений для государственных нужд и в максимальной степени упрощает осуществление формального надзора за выполнением программ, соблюдением сроков и расходованием ресурсов в соответствии с жесткими бюджетными назначениями. В ней раскладка на фазы и рубежи принятия решений обычно тесно увязывается с установленными законами и регламентами требованиями в отношении строгого соблюдения бюджетной дисциплины [18, 19]. При ее использовании процесс приобретения материальных продуктов и ПО одинаков и в меньшей степени вызывает затруднения у лиц, принимающих решения, и законодателей, утверждающих бюджетные ассигнования на программы.
В сложившихся условиях многолетние, с начала 2000-х гг., призывы использовать, например, модель приращений в отношении разработки ПО так и не находили отклика у законодателей США. Не исключено, что свою роль в этом сыграла применявшаяся с 2000 г. эволюционная модель, на которую возлагались надежды достичь существенного сокращения сроков проведения разработок и которую часто путали с моделью приращений из-за применения в ней спиральной разработки. Ее главное отличие от модели приращений состоит в том, что применение эволюционного подхода мотивируется необходимостью созревания технологий. Если первые приращения в модели базируются на зрелых технологиях, то последующие могут даже притормаживаться, чтобы необходимые технологии дозрели. Но в целом за счет применения такого порядка разработка ПО должна была ускоряться — первые этапы уже реализуются, когда для вторых технологии все еще разрабатываются.
В эволюционной модели структуры программ приобретения использовалась модель на основе ряда доставляемых приращений и ряда спиральных циклов в пределах каждого доставляемого приращения возможностей (инструкция МО США DODI 5000.2 от 2000 г.), но главной ошибкой в ее применении опять же стало стремление руководящего эшелона упростить для себя надзор за процессом проведения работ (сохранить его одинаковым при разработке как материальных продуктов, так и ПО). В данной модели время запуска очередного приращения зависит от достижения установленного заранее уровня зрелости разрабатываемой техноло-
гии, на основе которой создается новый требуемый набор функциональных возможностей продукта. Поэтому в каждом приращении повторяются 3 фазы — разработки технологии, системно-технической разработки продукта, производства и развертывания (либо тиражирования и развертывания для ПО) со всем набором контрольных рубежей и точек принятия решений. Это значит, что в каждом цикле эволюционного приобретения требовалось разрабатывать массу отчетных документов для представления лицам, принимающим решения, и органам надзора.
Соответственно, можно представить себе отношение к такой реализации эволюционной модели со стороны лиц, ответственных за достижение целей программы — объем отчетности увеличивался в размере, кратном числу приращений! К тому же ситуация могла усугубляться целесообразностью помодульной разработки и тестирования ПО в нескольких итерациях в рамках каждого приращения, поскольку по каждой итерации также предусматривалась определенная отчетность. В итоге они чаще всего делали все для того, чтобы ужаться в модель, подобную водопадной (в рамках каждого приращения), и сократить число самих приращений. А это приводило к резкому росту рисков достижения установленных уровней зрелости требуемых технологий, следствием чего являлись несвоевременный запуск очередных приращений, срывы выполнения календарных планов реализуемых программ и рост расходов.
Таким образом, «тяжеловесные» для разработки ПО процедуры надзора, принятые в США, влекут за собой инерционность применения традиционной модели. Последовательное проведение работ в соответствии с запланированными сроками их реализации в пределах четко спланированных этапов очень удобно для лиц, принимающих решения. Отклонения от утвержденной последовательности работ воспринимаются ими как основа для переработки базового варианта проведения программы или даже ее прекращения [16]. Подобная переработка влечет за собой необходимость проведения полной переоценки программы сверху донизу [13]. В результате на сторону принимающих решения лиц переходят и программные менеджеры, поскольку в противном случае их деятельность становится куда более беспокойной. Разумная инициатива «внизу» оказывается подавленной, а редкие попытки перехода к другим моделям вызывают внутренний протест у надзорных органов и у законодателей из-за
- 1 (286) - 2015 -
усложнения контроля за расходованием бюджетных средств. Любое представление законодателям логических доказательств необходимости корректировок «тонет» в согласованиях и обсуждениях. В итоге недопустимо увеличиваются затраты и время разработки ПО.
Вместе с тем в США к 2010 г. эффективность разработки программного обеспечения по федеральным программам упала настолько, что дело все же начало сдвигаться с мертвой точки, хотя и с большим «скрипом» [9]. Так, например, применительно к МО США, впервые в разделе 804 Акта по санкционированию расходов на военные нужды в финансовом 2010/11 г. (National Defense Authorization Act for Fiscal Year 2010) [13] указывалось, что министр обороны вправе ежегодно назначать до 10 ИТ-программ, полностью обеспеченных финансированием, для включения в демонстрацию альтернативного процесса приобретения в интересах ускоренного приобретения ИТ-возможностей в период 2010-2015 гг. При этом предусматривалось предоставление к 1 марта каждого года подробных отчетов по этим программам, содержащих: 1) описание каждой ИТ-программы в демонстрации, включая цели, финансирование и распорядителей бюджетных средств; 2) описание методов измерения эффективности альтернативного процесса приобретения для каждой ИТ-программы в демонстрации; 3) любые выявленные серьезные системные или процессные вопросы, препятствующие эффективному проведению альтернативного процесса приобретения.
Наконец, 25.11.2013 вышла в свет новая временная инструкция МО США № 5000.02 «Функционирование системы приобретения МО США» [14]. Если ранее действовавшая инструкция 2008 г. предусматривала применение и содержала описание лишь 2 базовых моделей структуры программ приобретения (традиционной и эволюционной), то в новой временной инструкции их число увеличено до 6, причем 5 из них привязаны к типам приобретаемых продуктов, а одна — к ускоренному приобретению.
Первая базовая модель (рис. 1) может применяться для приобретения материальных (аппаратных) продуктов, в которых программное обеспечение не используется. Именно она соответствует традиционной модели, отражающей общую методологию работы системы приобретения МО США и вплоть до 2014 г. использовавшейся, наряду с эволюционной моделью, для всех случаев в жизни без разделения приобретения материальных продуктов и приобретения ПО. Ей соответствует процесс, включающий ряд фаз (разделяются пунктиром), точки принятия решений (отображены в виде ромбов) и контрольные рубежи A, B, C (отображены в виде треугольников).
Ключевые решения (Milestone Decision) по реализации программы приобретения принимаются уполномоченным на то высокопоставленным лицом, принимающим решения на контрольных рубежах A, B, C (Milestones A, B, C) по результатам оценки содержания отчетных документов, а также в
Источник: инструкция МО США DODI 5000.2 от 2013 г. С. 9.
Рис. 1. Модель структуры программы приобретения материального (аппаратного) продукта (компьютерное отображение)
точках принятия решений (Decision Points) о переходе к следующим этапам работ с учетом содержимого ключевых документов.
Первая фаза (подготовка к приобретению) начинается с принятия решения на материальную разработку (Material Development Decision) по итогам рассмотрения требований пользователей к продукту (образцу, системе), сформулированных в документе по начальным возможностям. Далее проводится ее первый этап — анализ материального решения (Material Solution Analysis) и его выбор из альтернативных вариантов с принятием инвестиционного решения на контрольном рубеже A, после чего начинается второй этап фазы - созревания технологий и снижения рисков (Technology Maturation & Risk Reduction).
В ходе второго этапа формулируется документ по разработке возможностей (Capability Development Document, CDD), устанавливающий параметры характеристик для планируемого к разработке продукта. Основные положения документа проходят процедуру проверки и подтверждения (Validation) с принятием соответствующего решения. Далее готовится запрос на предложения по разработке продукта от промышленности (Development Request for Proposal, RFP) и принимается решение на его выдачу (Release Decision).
Первая фаза завершается контрольным рубежом B, на котором принимается инвестиционное решение о финансировании работ второй фазы — разработки, изготовления, испытаний по итогам разработки продукта и подготовки его производства (Engineering and Manufacturing Development). Конечная цель этой фазы — показать заказчикам, что разработанный в ходе второй фазы продукт удовлетворяет всем предъявленным требованиям.
На контрольном рубеже C принимается инвестиционное решение о финансировании третьей фазы — производства и развертывания (Production & Deployment). В начале этой фазы осуществляется производство малой партии продукта (Low-Rate Initial Production, LRIP) с проведением его оперативных испытаний и оценок (Operational Test and Estimate, OT&E). Если испытания прошли успешно, после накопления опыта эксплуатации малой партии продукта и устранения выявленных недостатков может приниматься решение о полномасштабном производстве продукта (Full-Rate Production Decision, FRP). Фактически это означает, что заказчики получили продукт, обладающий начальными оперативными возможностями (Initial Operational
Capability, IOC), обеспечивающими возможность его использования по предназначению.
Со временем по мере развертывания продукта производится его доработка до достижения полных оперативных возможностей (Full Operational Capability, FOC). Эти работы могут выполняться также и в ходе четвертой фазы — эксплуатации и поддержки (Operation and Support) продукта, которая, в свою очередь, делится на 2 этапа: длительный — обеспечения ресурсами и поддержки (sustainment) образцов продукта в ходе эксплуатации; короткий — утилизации (Disposal) образцов продукта после его снятия с эксплуатации.
На рис. 2 показана модель структуры программы приобретения специального программного обеспечения. В ней ввиду свойств ПО вместо понятий «производство малой партии продукта», «производство и развертывание», «решение о полномасштабном производстве», «полные оперативные возможности» используются соответственно понятия «ограниченное развертывание» (Limited Deployment), «развертывание» (Deployment), «решение о полномасштабном развертывании» (Full Deployment Decision, FDD), «полномасштабное развертывание» (Full Deployment). Такое ПО разрабатывается путем проведения набора итераций (Build 1.1, ..., Build 1.N) с различным перекрытием на шкале времени, а также завершающей итерации по интеграции ПО (Build 2.1*). Только после того, как будет разработано, интегрировано, отлажено, протестировано и испытано при проведении оперативных испытаний и оценок (OT&E) это ПО, формируется его стабильная и сертифицированная (при необходимости) версия для развертывания по предназначению, а затем и для полномасштабного тиражирования и развертывания. Здесь в спланированных итерациях создается серия тесто-пригодных, интегрируемых компонентов общих возможностей. Итерации, как правило, являются взаимозависимыми. Такая взаимозависимость ведет к необходимости одновременного проведения работ с разной степенью перекрытия во времени.
В качестве примеров ПО, разрабатываемого согласно модели, представленной на рис. 2, называются ПО для систем управления, работающих в реальном масштабе времени, специальное ПО для модернизации сложных узкопрофильных систем, ПО автоматизации технологических процессов и пр.
От правильности разбивки работ по итерациям зависит успешность разработки, ведь это позволяет грамотно распределять финансовые и материальные
- 1 (286) - 2015 -
Источник, инструкция МО США DODI 5000.2 от 2013 г. С. 10.
Рис. 2. Модель структуры программы приобретения специального программного обеспечения (компьютерное отображение)
ресурсы, гладко и эффективно управлять использованием высококвалифицированных разработчиков, не допуская их простоя и перегрузки, снижать риски превышения запланированного финансирования и срыва сроков работ.
На рис. 3 представлена модель разработки и развертывания ПО по приращениям (Increment 1, Increment 2, ..., Increment N) возможностей, которая, как правило, применима к ПО корпоративных систем управления, обеспечивающих автоматизированную поддержку бизнес-процессов (системы управления предприятиями, учетные системы, системы обеспечения жизнедеятельности предприятий — финансовые, транспортно-складские и т.п.), а также для модернизации некоторых специальных систем с циклом эволюционного совершенствования их характеристик 1-2 года.
Из анализа данных рис. 3 очевидно, что в рамках каждого приращения ПО разрабатывается по итерациям, как и в модели на рис. 2. Характерно, что эти итерации стараются делать независимыми друг от друга. Следовательно, они проводятся, как правило, последовательно, без перекрытия во времени. Соответственно, процесс проведения оперативных испытаний и оценок распределяется во времени. Данная модель, таким образом, отличается от модели на рис. 2 фазой быстрой поставки возможностей путем проведения нескольких ограниченных развертываний с принятием соответствующих решений (Limited Deployment Decision, LDD) вместо
одноразового проведения работ по результатам принятия решений на контрольных рубежах B и C с последующим одним полным развертыванием.
Каждое ограниченное развертывание обусловлено результатами работ в конкретной итерации, в конце которой пользователи получают зрелые и испытанные компоненты общих возможностей. Несколько итераций и развертываний, как правило, будут необходимы для удовлетворения утвержденных требований к конкретному приращению возможностей. Определение и разработка технических решений, необходимых для последующего расширения возможностей, происходят с некоторой степенью параллелизма, что позволяет ускорять запуск и выполнение работ по последующим приращениям. Обратим внимание, что в приращениях разработка технологии не проводится, она уже является зрелой для разработки ПО с начала первой итерации. Зато в начале каждого приращения проводятся мероприятия по снижению рисков для дальнейших работ по итогам каждого предыдущего приращения. Все итерации в рамках каждого приращения реализуются в ходе одной совмещенной фазы разработки ПО и его развертывания (Development and Fielding), т.е. развертывание начинается после завершения последней итерации.
Данная модель может использоваться в случаях, когда в приобретаемом для корпоративных нужд готовом коммерческом ПО с рядом модульных возможностей предусматривается доработка применительно
Источник: инструкция МО США DODI 5000.2 от 2013 г С. 11.
Рис. 3. Модель структуры программы приобретения для разработки и развертывания ПО по приращениям возможностей (компьютерное отображение)
к требованиям к ПО для государственных нужд (по информационной устойчивости, надежности, бесперебойному функционированию и пр.). Вместе с тем рекомендуется избегать такой структуризации программы, при которой она перенасыщается частыми контрольными рубежами или точками принятия решений по развертыванию, поскольку им сопутствует обязательное утверждение проведенных оценок. Для предотвращения этого принятие решений может производиться по результатам сразу нескольких мероприятий и итераций при условии адекватного планирования, наличия четко заданных критериев успешного окончания текущей фазы и наглядной демонстрации достигнутого прогресса. Заблаговременное решение по выбору содержания работ в ходе каждого из последующих приращений (от 2-го до Л-го) будет способствовать ускорению запуска мероприятий, связанных с этими приращениями. Для разработки требуемых возможностей, как правило, необходимо проведение нескольких приращений.
Модель на рис. 4 применяется для ускоренного приобретения возможностей в сжатые сроки, в частности в целях достижения технологической внезапности для конкурентов, что обусловливает увеличение допустимых уровней риска превышения запланированных затрат и технического риска. В данной модели типовые фазы процесса приобретения либо сжимаются во времени, либо исключаются целиком. Работы по такой программе могут завершаться, например, в течение 2 лет. Так, модель на рис. 4 предусматривает одновременное проведение фазы созревания технологии и снижения риска и фазы разработки (Concurrent Technology Maturation, Risk Réduction and Development) с одновременными производством и развертыванием продукта (Concurrent Production and Deployment). При этом совмещаются контрольные рубежи A и B, а также проводится предварительная оценка проекта (Preliminary Design Review).
Источник: инструкция МО США БОБ1 5000.2 от 2013 г. С. 12.
Рис. 4. Модель структуры программы ускоренного приобретения возможностей (компьютерное отображение)
На рис. 5 показан пример структуры программы гибридного приобретения, в которой преобладает разработка материальной (аппаратной) части продукта в сравнении с разработкой ПО для него. При этом разработка материальной части продукта проводится по типовым фазам. График работ по итеративной разработке ПО должен координироваться и согласовываться с точками принятия решений по разработке материальной системы, ведь именно она диктует темп выполнения программы.
В гибридной модели, представленной на рис. 5, разработку ПО предусматривается ор-
ганизовывать в серию итераций по созданию тестопригодных программных компонентов и их интеграции. По завершении процесса появляются возможности, удовлетворяющие требованиям к программе и достижению начальных оперативных возможностей. Итерации структурируются так, чтобы синхронизировать завершение работ по ним с началом работ по интеграции и проведению испытаний (по итогам разработки и оперативных) прототипов создаваемого материального продукта. Подготовка решений на контрольных рубежах B (переход к системной разработке, испытаниям
Источник: инструкция МО США БОБ1 5000.2 от 2013 г. С. 13.
Рис. 5. Модель структуры программы гибридного приобретения, в которой преобладает разработка материальной
(аппаратной) части продукта (компьютерное отображение)
и подготовке производства) и С (переход к производству и развертыванию) должна включать представление документов по критериям оценки зрелости разрабатываемых программных функциональных возможностей, а также демонстрацию достижения установленных значений критериев успешного окончания текущей фазы по техническим характеристикам.
Вторая гибридная модель структуры программы приобретения отражает процесс приобретения продукта с преобладающей долей ПО. По сути она является гибридом эволюционной модели (описанной в предыдущем издании инструкции МО США DODI 5000.2 от 2008 г.) и модели разработки ПО по приращениям с проведением в каждом из них серии итераций (см. рис. 3). Обратим внимание, что эволюционность модели достигается включением «полновесной» фазы созревания технологии в дополнение к этапу снижения рисков в ходе этой фазы, проводимому в обычной модели структуры программы приобретения для разработки и развертывания ПО по приращениям возможностей. Вторая гибридная модель характеризуется высокой сложностью для планирования и реализации, однако одним из условий успешности ее применения является упрощение процедур надзора и принятия
решений для сокращения отчетности. Вторая гибридная модель представлена на рис. 6.
Таким образом, законодателям в Конгрессе США и органам регламентации проведения программ по разработке ИТ-систем и программных продуктов различного назначения для государственных нужд понадобилось порядка 12-14 лет, чтобы создать твердую основу для перехода к достаточно прогрессивным методам разработки ПО, длительное время уже применявшимся в разработках для коммерческого сектора. Главная цель — ускорить проведение работ. Достаточно ли будет проведенных мероприятий — покажет ближайшее время, поскольку жизнь не стоит на месте.
Совершенствование процессов разработки ПО для коммерческого сектора
Сразу следует отметить коренные отличия разработки ПО, предназначенного не для государственного, а коммерческого сектора:
1) заказчики сами решают, как им расходовать собственные денежные средства, вследствие чего функции надзора уходят на второй план;
2) расходовать выделенные ассигнования в условиях соблюдения жесткой финансовой дисцип-
Источник: инструкция МО США ЭОЭ1 5000.2 от 2013 г. С. 14.
Рис. 6. Модель структуры программы гибридного приобретения материального продукта с преобладающей долей ПО (компьютерное отображение)
лины, например до окончания финансового года, нет необходимости. Это позволяет более гибко планировать, определять интенсивность, проводить и оплачивать работы по мере накопления финансовых ресурсов.
Кроме того, в реальной жизни техническое задание на разработку ПО часто корректируется в ходе работ, в результате чего многие планы рушатся. К тому же значительную часть недостатков ИТ-систем можно обнаружить только в процессе эксплуатации.
Вследствие указанных факторов «водопадная» модель при разработке ПО для коммерческого сектора большого распространения так и не получила. Она может рассматриваться лишь как одна из альтернатив при подготовке к разработке системы и использоваться лишь в узком сегменте работ.
Для ускорения разработки ПО коммерческие фирмы примерно с начала 1990-х гг. широко используют модели плоской спирали и спирально-круговую, с которыми хорошо согласуется выше-рассмотренная модель приращений для структуры программ приобретения. В них делается упор на общесистемные требования на ранних этапах разработок, тесное взаимодействие с пользователями при формулировке и уточнении детальных требований, тесную интеграцию заводских и оперативных испытаний и оценок в цикл разработки, разделение программы на циклы приращений возможностей [10]. При пошаговом расширении функциональных возможностей системы, то есть создании возможностей по приращениям, легче устранять выявляемые в процессе реальной эксплуатации недостатки системы.
Результативность модели приращений перевешивает ее главный недостаток — усложнение управления программой. Так, проведение итеративных приращений, как уже упоминалось, усложняет процесс управления финансированием программы. Для обеспечения его результативности требуется четко определять главные задачи и разрабатывать порядок (методологию) инвестирования, предусматривать разумные разбивку работ по приращениям и ограничение их масштаба, чтобы получаемые наборы ПО могли быть разработаны в установленные сроки и сразу же применяться по предназначению, реализуя полезные функции. Важно также понимать необходимость обеспечения стабильного финансирования работ. В противном случае возникают предпосылки для ненамеренного и неосознанного применения порочной в отношении разработки ПО
«водопадной» модели, только ужимаемой каждый раз в рамки приращений без четкого планирования последующих мероприятий.
Вместе с тем стремление повысить эффективность разработок ПО предопределило появление в коммерческом секторе в 2000-х гг. ряда начальных версий методологий гибкой разработки ПО (Agile software development, ASD), которые ознаменовали сдвиг от ведения разработки ПО по заранее утвержденному плану в сторону такой организации работ, когда процесс разработки определяется ценностью создаваемого по итерациям с коротким циклом и приращениям элементов ПО. Они являются разновидностями более широкого подхода, реализуемого через модель структуры программы приобретения ПО по приращениям. В 2001 г. группа специалистов опубликовала документ, широко известный как «Манифест по гибкой разработке ПО» [15], в котором описан набор положений и руководящих принципов, закладывающих единую основу для различных методологий в этой области. Этот набор подчеркивает более высокую ценность:
1) отдельных лиц и их взаимодействий, а не процессов и инструментов;
2) работающего ПО, а не подробной документации;
3) сотрудничества с заказчиком, а не переговоров по контрактам;
4) быстрого реагирования на изменения, а не неукоснительного следования принятому ранее плану.
Авторы манифеста подкрепляют эти положения следующими 12 принципами гибкой разработки ПО, смысл которых сводится к следующему:
1) наивысший приоритет следует отдавать удовлетворению потребностей заказчика за счет ускоренной и непрерывной поставки ценного ПО;
2) корректировка требований допускается даже в конце разработки — гибкие процессы обеспечивают реализацию корректировок в интересах создания у заказчика возможностей для достижения конкурентных преимуществ;
3) поставки работающего ПО производятся через интервалы от 2-3 недель до 2-3 мес., причем предпочтение отдается укороченным временным интервалам;
4) бизнес-персонал и разработчики должны в течение проекта ежедневно работать вместе;
5) проекты структурируются прежде всего вокруг заинтересованных в их реализации лиц, при этом для успешного выполнения работ должны
- 1 (286) - 2015 -
выделяться необходимые ресурсы и создаваться атмосфера доверия к разработчикам;
6) наиболее эффективным и результативным методом обмена информацией в команде разработчиков является общение лицом к лицу;
7) работающее ПО — основной критерий прогресса;
8) гибкие процессы способствуют эффективной разработке — заказчики, разработчики и пользователи должны находиться в таком состоянии, чтобы поддерживать постоянным установленный ритм работ вплоть до завершения проекта;
9) для разработки грамотно выстраиваемых проектов с гибкой разработкой ПО необходимо постоянно уделять внимание совершенствованию технических знаний и навыков;
10) существенное значение имеет простота как искусство предотвращения выполнения ненужных работ;
11) наилучшие архитектуры, требования и проекты рождаются в самоорганизующихся командах;
12) командам разработчиков необходимо через регулярные интервалы оценивать возможности повышения эффективности в работе, после чего соответствующим образом корректировать организацию и ход выполнения работ.
Гибкая разработка ПО — это метод организации работ по разработке ПО одной небольшой командой специалистов с использованием разбивки процесса разработки по итерациям и приращениям (либо их сжатым во времени аналогам — «сприн-там» и «релизам»). Работы проводятся в рамках утвержденного до запуска программы руководящего документа (например, в аппарате начальника федеральной информационной службы (НФИС) США он называется Product Vision — «Перспективный облик продукта»), описывающего лишь в общих чертах основные требования, главные свойства и желаемые функциональные возможности продукта. При необходимости в ходе первой, «бумажной» итерации может определяться проект базового продукта, который имеет минимальный набор возможностей, но уже способен использоваться пользователями. Тогда аналитики-консультанты и разработчики ПО из состава команды вступают в дело на второй и последующих итерациях, а пользователи продукта — начиная с третьей.
В начальных итерациях удовлетворяются наиболее ценные для заказчика требования. По завершении каждой итерации или приращения у
конечного продукта появляются новые функциональные возможности, которые после интеграции с ранее разработанными частями ПО и тестирования сразу же проходят апробацию на практике его будущими пользователями. Исходя из своих впечатлений от работы с продуктом, пользователи выдают множество предложений по его совершенствованию (user stories). Данные предложения проверяются на предмет того, не выходят ли они за установленные в перспективном облике продукта границы, на бесконфликтность, возможность и целесообразность реализации, фильтруются, проходят процедуру утверждения (это необходимо для согласования объема работ с располагаемым бюджетом программы) и включаются в план работ на последующих итерациях.
Постоянная обратная связь с пользователями определяет гибкость разработки ПО и быстроту реагирования на их предложения. В итоге функциональные части приложения поставляются по мере их готовности к использованию в привязке к календарному плану в ходе итеративного процесса поставок частей ПО продукта. При этом пользователи получают ПО, которое лучше удовлетворяет их потребности (как по функциональным возможностям, так и по удобству эксплуатации) без пустой траты денег и времени на разработку ПО, реализующего неиспользуемые или неудобные для использования качества продукта. Одновременно проводится оформление, как правило, коллективных прав собственности на программный код.
Считается, что проведение работ небольшой командой позволяет сократить затраты до того времени, когда с новым ПО начнут работать первые пользователи, а также появится ясность в отношении формулировок детализированных требований. Короткие циклы итераций позволяют быстро реагировать на отзывы пользователей и учитывать их при дальнейшей разработке ПО. Если проект окажется неудачным, его можно приостановить, пока затраты все еще остаются небольшими, и использовать другие технические решения, лучше удовлетворяющие потребности пользователей.
Наиболее распространенными методологиями гибкой разработки ПО являются методологии Scrum (с долей 40-55%), гибрид Scrum и экстремального программирования (методология XP) (18-24%), собственно XP (3-5%), Lean Development (2-3%) [11]. Более детально с каждой из них можно ознакомиться через Интернет, набрав в строке поисковой системы соответствующее название.
- 1 (286) - 2015 -
Общими для упомянутых методологий являются повышенные требования к командам специалистов. Короткий цикл разработки по итерациям требует, чтобы члены команды глубоко понимали все фазы жизненного цикла ПО. Целесообразно проведение между итерациями совещаний и тренингов для обмена опытом и дополнительного обучения разработчиков. Способность писать работающее, полностью протестированное ПО за короткое время (как правило, 1-6 недель) требует обширных знаний в областях компьютерных технологий, стандартов программирования, методов тестирования, управления проектами. В отличие от традиционных методологий разработки ПО, в которых результаты работ каждой фазы жизненного цикла последовательно используются для организации работ в следующей фазе, при гибкой разработке ПО выполнение этих фаз (анализ требований, проектирование, разработка кода, тестирование, разработка документации и передача продукта с расширенным функционалом пользователям) зачастую происходит параллельно, что ужесточает требования к синхронности работы и дисциплине в команде.
Перспективы использования
гибкой разработки ПО для государственных нужд
Начальники информационных служб министерств и ведомств США примерно с 2010 г. внимательно изучают вопрос использования гибкой разработки ПО в интересах повышения качества заказанных продуктов (систем), снижения расходов и сокращения сроков реализации ИТ-программ. В частности, в 2010 г. появились 2 исследовательские работы, в которых обосновывалась возможность применения гибкой разработки ПО в интересах МО США [11, 16]. Тогда же в документе [21] был четко обозначен путь к использованию модели приращений на федеральном уровне. В его развитие в 2014 г. аппарат начальника федеральной информационной службы США разработал проект официального документа, который мог бы заложить основы для широкого применения методологий гибкой разработки ПО в отношении ИТ-систем для государственных нужд [17]. Довольно беглое знакомство с ним показало, что данный проект является «сырым» и, вероятно, будет дорабатываться еще длительное время. Создавалось впечатление, что его авторы создают не руководство к действию, а документ, содержащий юридические отговорки персонала управления ИТ-программами с гибкой разработ-
кой ПО от возможных претензий органов надзора, находящихся в постоянном поиске нецелевого расходования финансовых средств при проведении надзорных мероприятий по программам.
На самом деле проведение такой работы в рамках функционирующей в США забюрократизированной системы приобретения не лишено смысла. Ведь методологии гибкого программирования следует использовать с осторожностью: часто они, например, не предусматривают детального документирования исходного кода или проведения этапа разработки архитектуры, что для больших систем неприемлемо. Напрямую (в рамках соблюдения всех 12 принципов) эти методологии не стоит применять в области создания критичного к обеспечению безопасности ПО, отказ в котором может привести к серьезному физическому ущербу или смерти. Для такого ПО требуется проведение обширного анализа на начальном этапе и серьезное отношение к вопросам обеспечения надежности ПО. Значительно дешевле выполнять эту работу до разработки кода вследствие высокой стоимости и большой продолжительности его написания. Например, в данной ситуации вряд ли применима методология Lean Software быстрого написания кода без подготовки, в которой упор делается на минимизацию работы, имеющей меньшую ценность. В то же время методология Scrum (методология управления проектом итеративной разработки по приращениям) может оказаться вполне применимой при условии, что разработчики используют первые циклы («спринты») для анализа альтернатив, разработки архитектурных документов и проектирования структуры ПО [11].
В целом при всем понимании ценностей и преимуществ гибкой разработки ПО в краткосрочной перспективе (3-5 лет) следует ожидать появления в США утвержденных документов, регламентирующих ее применение в государственном секторе, по всей вероятности, временных, и проведения экспериментальных проектов, в которых на практике должна быть доказана ее ценность. Накопленный опыт будет использоваться для корректировки регламентов и дополнительного обучения персонала.
Таким образом, сокращения затрат и сроков реализации разработки и поставок программного обеспечения для ИТ-систем, как показывает опыт работы коммерческих фирм, можно добиться за счет применения передовых моделей и методологий разработки и структуризации программ приобретения ПО. Если в США за последнее десятилетие в коммерческом
- 1 (286) - 2015 -
секторе выстроены и широко применяются методологии итеративной (в том числе гибкой) разработки программного обеспечения по приращениям, то в государственном секторе преимущественно продолжалось применение традиционной модели структуры программ приобретения на основе последовательной («водопадной») модели, широко применяемой при разработке и поставках материальных (аппаратных) продуктов. Это стало одной из главных причин того, что к 2010 г. большие ИТ-программы, например в МО США, реализовывались в течение 6-8-летнего цикла при примерно 18-месячном цикле развития коммерческих технологий, что отражалось на качестве и моральном старении разработок.
Перелом наступил к 2014 г. с выходом в свет новой ведомственной временной инструкции МО США 5000.02 от 25.11.2013 «Функционирование системы приобретения МО США», зафиксировавшей 6 моделей структуры программ приобретения продукции. Это ознаменовало возможность практического перевода разработок ПО для государственных нужд в плоскость применения передовых наработок коммерческого сектора. Мало того, все шире раздаются призывы к использованию методологий гибкой разработки ПО. На очереди создание механизмов их адаптации к ИТ-программам государственных структур и их закрепление в регламентирующих документах. Однако очевидно, что этот процесс далеко не простой. Он находится лишь в начале своего развития и требует отдельного рассмотрения.
Список литературы
1. Андреева Г.М. Социальная психология. М.: Аспект Пресс, 2001. 384 с.
2. Вигерс К.И. Разработка требований к программному обеспечению / пер. с англ. М.: Русская редакция, 2004. 576 с.
3. Либин А.В. Дифференциальная психология: на пересечении европейских, российских и американских традиций. М.: Смысл, 1999. 532 с.
4. Судакова Л. Эффективность разработок информационных технологий по федеральным программам (на примере министерства обороны США) // Национальные интересы: приоритеты и безопасность. 2011. № 44. С. 62-71.
5. Шихирев П.Н. Современная социальная психология. М.: Академический проект, 1999. 448 с.
6. Margaret E. Myers. An investment-based approach for managing software-intensive systems // Acquisition Review Quarterly. Winter 1999. P. 61-78.
7. Boehm B. A spiral model of software development and enhancement IEEE Software, May 1988.
8. Rechtin E., Maier M. The art of systems architecting // Boca Raton, FL: CRC Press, 1997.
9. SchwartzM. Defense Acquisitions: How DOD Acquires Weapon Systems and Recent Efforts to Reform the Process // Congressional Research Service 7-5700. URL: www.crs.gov. RL34026. July 10, 2009; May 23, 2014.
10. Achieving Effective Acquisition of Information Technology in the Department of Defense / National Research Council, Committee on Improving Processes and Policies for the Acquisition and Test of Information Technologies in the Department of Defense // The National Academies Press. Washington D.C., 2010. URL: http: //www.nap .edu/c atalog .php?record_ id=12823.
11. Northern C., Mayfield K., Benito R., Casagni M. Handbook for Implementing Agile in Department of Defense Information Technology Acquisition (technical report MTR 100489). Bedford, MA. The MITRE Corporation.
12. Report of the Defense Science Board Task Force on Department of Defense Policies and Procedures for the Acquisition of Information Technology // Office of the Under Secretary of Defense for Acquisition, Technology, and Logistics Washington, D.C. 203013140. March 2009.
13. 111th Congress, 1st Session, H.R. 2647 (public Law 11-84) [Report No. 111-166] 2009 (Акт по санкционированию расходов на военные нужды в финансовом 2010/11 г.).
14. Operation of the Defense Acquisition System // Interim DoD Instruction 5000.02. November 25, 2013.
15. Agilemanifesto.org: Statistics and Analysis. Agile Methodologies, Agile Development Process, Manifesto For Agile Software Development related sites. URL: http://agilemanifesto.org.
16. Lapham M., Williams R., Hammons C., Burton D., Schenker A. Considerations for Using Agile in DoD Acquisition // Software Engineering Institute. April 2010.
17. TechFAR Handbook for Procuring Digital Services Using Agile Processes. URL: www.cio.gov. 2014.
18. DoDD № 5000.01. May 12, 2003. The Defense Acquisition System.
19. Defense Acquisition Guidebook. Production Date: May 15, 2013. Defense Acquisition University.
20. President's IT Budget for FY 2015. Summary chart. URL: http://www.whitehouse.gov.
21. Kundra V. 25 Point Implementation Plan to Reform Federal Information Technology Management. The White House, Washington. US Chief Information Officer. December 9, 2010.
22. Andrews R., Cooper J., Ellsworth B., Sestak J., ConawayM., Hunter D., Coffman M. The House Armed Services Committee Panel on Defense Acquisition Reform: Findings and Recommendations. March 23, 2010. P. 14-19.
23. Committee on Improving Processes and Policies for the Acquisition and Test of Information Technologies in the Department of Defense; National Research Council. Achieving Effective Acquisition of Information Technology in the Department of Defense. The National Academies Press. Washington, D.C. 2009.
24. BENS-DISA Cooperative Review (BENS — Business Executives for National Security). Final Report. August 2008.
National interests: priorities and security Foreign experience
ISSN 2311-875X (Online) ISSN 2073-2872 (Print)
MODELS OF THE STRUCTURE OF PROGRAMS FOR PRODUCT ACQUISITION IN THE USA AND THEIR APPLICATION FOR SOFTWARE DEVELOPMENT
Lyudmila Yu. SUDAKOVA Abstract
The article generalizes the US publications and official documents on software acquisition. The author considers the models of software development adopted in the USA, i.e. "waterfall', spiral, spiral-to-circle, software product line, agile software development. The author analyzes the models in conjunction with the models of the structure of product acquisition programs (traditional, evolutionary, iterative and incremental developments and hybrid ones) differentiating them by application in commercial and government sectors. The article includes the results of using the said models for software development. The operational experience of commercial sector shows that it is possible to reduce cost and term of software development and delivery for IT systems by applying advanced models and techniques of development and structuring of software acquisition. Software for commercial market is developed predominately in accordance with the iterative and incremental development model, which envisages software deliveries in releases with progressive expanding its compatibility options. Software for the US Federal needs, as a rule, has been developed under the traditional model of program acquisition structure, which is characterized by detail development of system requirements and requirements specification, as well as by work implementation exactly as expected by the requirements. This was one of the main reasons why by 2010 large IT programs, for example, in the US
Department of Defense, have been implemented over 6-8-year cycle with approximately 18-month cycle of commercial technologies development. This ultimately affected the quality and moral ageing of the development. The author analyzes how Federal agencies are planning to use the commercial sector's best practices to develop software.
Keywords: software development, increment, agile software, program management, information technology acquisition program
References
1. Andreeva G.M. Sotsial 'naya psikhologiya [Social psychology]. Moscow, Aspekt Press Publ., 2001, 384 p.
2. Vigers K.I. Razrabotka trebovanii kprogram-mnomu obespecheniyu [Development of software requirements]. Moscow, Russkaya redaktsiya Publ., 2004, 576 p.
3. Libin A.V. Differentsial'nayapsikhologiya: na peresechenii evropeiskikh, rossiiskikh i amerikanskikh traditsii [Differential psychology: at the crossroads of European, Russian and American traditions]. Moscow, Smysl Publ., 1999, 532 p.
4. Sudakova L. Effektivnost' razrabotok informat-sionnykh tekhnologii po federal'nym programmam (na primere ministerstva oborony SShA) [The efficiency of the information technology development under Federal Programs (the US Department of Defense case)].
Natsional'nye interesy: prioritety i bezopasnost' = National interests: priorities and security, 2011, no. 44, pp. 62-71.
5. Shikhirev P.N. Sovremennaya sotsial'naya psikhologiya [Modern social psychology]. Moscow, Akademicheskii proekt Publ., 1999, 448 p.
6. Margaret E. Myers. An investment-based approach for managing software-intensive systems. Acquisition Review Quarterly, Winter 1999, pp. 61-78.
7. Boehm B. A spiral model of software development and enhancement. IEEE Software, May 1988.
8. Rechtin E., Maier M. The Art of Systems Archi-tecting. Boca Raton, FL, CRC Press, 1997.
9. Schwartz M. Defense Acquisitions: How DoD Acquires Weapon Systems and Recent Efforts to Reform the Process. Congressional Research Service 7-5700. Available at: www.crs.gov. RL34026. July 10, 2009; May 23, 2014.
10. Achieving Effective Acquisition of Information Technology in the Department of Defense. National Research Council, Committee on Improving Processes and Policies for the Acquisition and Test of Information Technologies in the Department of Defense. The National Academies Press. Washington D.C., 2010. Available at: http://www.nap.edu/catalog. php?record_id=12823.
11. Northern C., Mayfield K., Benito R., Casag-ni M. Handbook for Implementing Agile in Department of Defense Information Technology Acquisition (technical report MTR 100489). Bedford, MA, The MITRE Corporation.
12. Report of the Defense Science Board Task Force on Department of Defense Policies and Procedures for the Acquisition of Information Technology. Office of the Under Secretary of Defense for Acquisition, Technology and Logistics. Washington, D.C. 20301-3140. March, 2009.
13. 111th Congress, 1st Session, H.R. 2647 (Public Law 11-84). Report No. 111-166. 2009 (Act to authorize military spending in 2010 financial year).
14. Operation of the Defense Acquisition System. Interim DoD Instruction 5000.02, November 25, 2013.
15. Manifesto for Agile Software Development. Agile Methodologies, Agile Development Process, Manifesto for Agile Software Development related sites. Available at: http://agilemanifesto.org.
16. Lapham M., Williams R., Hammons C., Burton D., Schenker A. Considerations for Using Agile in DoD Acquisition. Software Engineering Institute, April 2010.
17. TechFAR Handbook for Procuring Digital Services Using Agile Processes. Available at: www. cio.gov. 2014.
18. DoDD, NO. 5000.01, May 12, 2003. The Defense Acquisition System.
19. Defense Acquisition Guidebook. Production Date, May 15, 2013. Defense Acquisition University.
20. President's IT Budget for FY 2015. Summary chart. Available at: http://www.whitehouse.gov.
21. Kundra V. 25 Point Implementation Plan to Reform Federal Information Technology Management. The White House, Washington. US Chief Information Officer. December 9, 2010.
22. Andrews R., Cooper J., Ellsworth B., Sestak J., Conaway M., Hunter D., Coffman M. The House Armed Services Committee Panel on Defense Acquisition Reform: Findings and Recommendations. March 23, 2010,pp. 14-19.
23. Committee on Improving Processes and Policies for the Acquisition and Test of Information Technologies in the Department of Defense; National Research Council. Achieving Effective Acquisition of Information Technology in the Department of Defense. Washington, D.C., The National Academies Press, 2009.
24. BENS-DISA Cooperative Review (BENS — Business Executives for National Security). Final Report. August 2008.
Lyudmila Yu. SUDAKOVA
OOO NVision Consulting, Moscow, Russian Federation avocadus@gmail.com
