Задача по созданию ПО состояла в разработке трех различных программных систем с общим объемом более одного миллиона строк исходного кода. В данном практическом примере основное внимание уделяется программной системе, разрабатывавшейся в первую очередь. Она называлась Подсистемой общего назначения, для ее создания потребовалось написать около 355 ООО строк исходного кода. В результате создания.

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

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

D.1 ОБЩИЕ ПОЛОЖЕНИЯ ДЛЯ ДАННОГО ПРАКТИЧЕСКОГО ПРИМЕРА.

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

Я попытался представить точную картину проекта CCPDS-R. Все данные являются в основном историческим фактом, а вот субъективные комментарии и оценки значимости принадлежат мне. В качестве источников данных использовались опубликованные статьи, руководства для внутреннего пользования компании TRW, поставляемая в соответствии с контрактом документация — все это можно было извлечь из реальных рабочих продуктов по проекту CCPDS-R — и мой собственный практический опыт. В некоторых случаях я редактировал данные, чтобы избавиться от ненужной точности и исключить противоречия в исходных документах, которые разрабатывались на различных стадиях жизненного цикла. Моей целью являлось создание относительно непротиворечивого описания, поэтому мне пришлось исключить некоторые детали, для которых потребовались бы не относящиеся к предмету пояснения.

В индустрии ПО существует много успешных проектов (недостаточно, но много), однако хорошие практические примеры отсутствуют. Имеется небольшое количество тщательно документированных проектов с объективным описанием того, что было сделано, чего не было сделано и.

почему. Это являлось одним из главных моих побудительных мотивов для той степени подробности, с которой написано приложение. В него включены специфичные подробности, подходы и результаты по трем причинам:.

1.

Написание этого практического примера не потребовало большого труда. Проект CCPDS-R уникален в своем подходе к тщательности и автоматизации работы с метриками. Все данные были получены непосредственно из реальных «исторических» рабочих продуктов, созданных в процессе выполнения проекта.

2.

Данная разновидность объективных практических примеров является точным индикатором зрелости организации и зрелости процесса выполнения проекта. Абсолютные «исторические» цифры могут иметь весьма ограниченное применение. Однако тенденции, извлеченные уроки и относительная важность приоритетов являются отличительными особенностями любой успешной разработки ПО.

3.

В предшествующих главах многие технические и управленческие подходы обсуждались в общем. Данное приложение предоставляет по крайней мере одну практическую точку отсчета для оценки работы.

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

D.2 ОБЩИЙ ОБЗОР ПОДСИСТЕМ.

В результате осуществления проекта CCPDS-R была создана крупномасштабная высоконадежная система командования и контроля, которая обеспечивала Национальный Командный Центр информацией о запусках ракет. В качестве посредника выступало подразделение электронных систем Главного штаба военно-воздушных сил, расположенного на военно-воздушной базе в Хэнскоме, штат Массачусетс. Главным пользователем являлось космическое командование США, а контракт на полномасштабную разработку был заключен с TRW’s Systems Integration Group в 1987 г. Контракт по созданию CCPDS-R предусматривал разработку трех подсистем:.

1. Подсистема общего назначения являлась главной системой оповещения о запусках ракет в рамках программы Cheyenne Mountain Upgrade. Для ее создания потребовалось написать около 355 ООО строк исходного кода, срок ее разработки составлял 48 месяцев, и она являлась основой для подсистем, которые разрабатывались позже (повторно используемые компоненты, инструментарий, среда, процесс, процедуры). Подсистема общего назначения была рассчитана на основную установку в Cheyenne Mountain, дублирующая подсистема устанавливалась на базе военно-воздушных сил в Оффутте, штат Небраска.

2.

Подсистема обработки и вывода (Processing and Display Subsystem, PDS) была уменьшенным вариантом системы вывода оповещения о запусках ракет, которая предназначалась для всех командующих, ответственных за пуск ядерных ракет. ПО PDS (около 250 ООО SLOC) устанавливалось на удаленных, работающих в режиме «только чтение» рабочих станциях, разбросанных по всему миру.

3.

Подсистема STRATCOM (около 450 ООО SLOC) обеспечивала как оповещение о запусках ракет, так и возможность принудительного управления для запасного центра оповещения о запусках ракет в командном центре Стратегического командования.

Общий процесс создания ПО.

Создание ПО в рамках проекта CCPDS-R состояло из двух отдельных стадий: определения концепции (ОК) и полномасштабной разработки (ПМР). На контракт на выполнение стадии ОК претендовали пять компаний, были заключены два контракта с фиксированной суммой в $2 млн. каждый. Фирмы, получившие контракты, должны были вложить также собственные ресурсы по своему усмотрению на то, чтобы определиться с самым выгодным предложением для стадии ПМР. На рис. D.1 показаны общий процесс создания и продукты, полученные на каждой стадии.

Стадия OK по своим задачам близка к начальной стадии. Ее главными продуктами являются спецификации системы (документ с общей концепцией), предложение по стадии ПМР (бизнес-план, включающий в себя описание технического подхода, фиксированную сумму прибыли и предложение по общей стоимости контракта) и план разработки ПО. Стадия ОК включает в себя также обзор проекта системы, технические совещания для обмена информацией с заинтересованными сторонами от правительства (заказчик и пользователь) и некоторые оговоренные в контракте документы. Эти действия и продукты позволяют произвести исходную оценку Г1МР, основанную как на работе, продемонстрированной предложенной подрядчиком командой, так и на предложениях; по ПМР.

С точки зрения ПО появляется еще один дополнительный критерий для исходного выбора, который включен в работы по подготовке предложений по ПМР, — опытная разработка ПО. Это был уникальный, но эффективный подход для оценки возможностей двух конкурирующих между собой подрядчиков по осуществлению разработки ПО. Военно-воздушные силы чрезвычайно интересовал общий риск данного проекта: от предыдущих проектов сложилась весьма унылая картина. Ответственные за закупку ПО в военно-воздушных силах испытывали также сильное разочарование в таких ситуациях, когда первоклассная команда по разработке предложений оказывалась вовсе не той командой, которой предстояло выполнять контракт после его заключения, а предложения подрядчика обычно приукрашивали его подходы или возможности по сравнению с тем, что он мог реально осуществить.

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

Опытная разработка ПО началась немедленно после рассмотрения предложений по ПМР. Заказчик предоставил обоим соискателям спецификации несложного «эмулятора для оповещения о запуске ракет» на двух страницах. Этот эмулятор должен был удовлетворять некоторым фундаментальным требованиям из числа предъявляемых к полномасштабной системе CCPDS-R, включая распределенную архитектуру, гибкий пользовательский интерфейс и основные сценарии обработки потока событий CCPDS-R, связанного с оповещением о запуске ракет. Требования к опытной разработке включали в себя следующее:.

■ Использование предложенной команды разработчиков ПО.

■ Применение для разработки ПО предложенных методов и инструментов.

■ Использование содержащегося в предложениях по ПМР плана разработки ПО.

■ Предоставление заказчику макетного обзора проекта через 23 дня после получения спецификаций.

Опытная разработка ПО должна была дать объективную характеристику пригодности предложенных каждым из подрядчиков подходов к разработке ПО.

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

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

■ Были созданы и продемонстрированы четыре основных варианта использования.

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

■ Было разработано и написано 4163 исходных строк для прототипов компонентов. В демонстрационную версию было включено также несколько повторно используемых компонентов общим объемом в несколько тысяч строк.

■ Были пройдены три контрольные точки и разрешено более 30 рабочих проблем.

■ Создание 11 документов (в соответствии с предложенными рабочими продуктами) продемонстрировало уровень автоматизации, присущий средствам документирования.

■ Были использованы средства Digital Equipment Corporation VAX/VMS, среда Rational R1000, шаблоны документов LaTeX и несколько специально созданных инструментов.

■ Были определены некоторые усовершенствования процесса и инструментов, которые необходимо произвести. Концепция изменения плана, требований, процесса, проекта и среды в каждой основной контрольной точке была признана потенциально рискованной, тем не менее была реализована посредством строгого управления изменениями.

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

Опытная разработка ПО служила тем же целям, что и оценка возможностей по созданию ПО (SEI Software Capability Evaluation), рассмотренная 8 приложении Е. В предложении каждого из конкурентов содержался план разработки ПО — та часть организации процесса, в которой расписывалось, что надо делать. Опытная разработка продемонстрировала, что предлагаемая организация в состоянии работать так, как обэтом объявлено.

.

D.3 ОРГАНИЗАЦИЯ ПРОЕКТА.

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

■ Проанализировать и определить требования проекта.

■ Определить и разработать архитектуру самого верхнего уровня.

■ Распланировать различные виды деятельности по разработке ПО в течение стадии ПМР.

■ Сконфигурировать процесс и среду разработки.

■ Установить доверительные и направленные на достижение успеха отношения между заинтересованными сторонами.

Команда на стадии ОК была небольшой и высококвалифицированной, а иерархия внутри команды была малозаметной, если вообще была. Одним из ее исключительных атрибутов явился полный набор талантов. Были представлены все необходимые квалификации, а конкуренция между сотрудниками практически полностью отсутствовала.

Команда для стадии ПМР была сформирована путем перевода многих членов команды, работавшей на стадии ОК, на руководящие должности и.

увеличения числа сотрудников до уровня, необходимого для проведения полномасштабной разработки.

На рис. D.2 показаны эволюция организации создания ПО и распределение ответственности в процессе ПМР.

Организационная структура и распределение обязанностей для проекта

D.4 ОБЗОР ПОДСИСТЕМЫ ОБЩЕГО НАЗНАЧЕНИЯ.

ПО, называемое Подсистемой общего назначения, охватывает шесть объектов управления конфигурацией (computer software configuration item, CSCI). (CSCI является жаргоном заказчиков из правительства и употребляется для обозначения набора компонентов, которые управляются, конфигурируются и документируются как единое целое и разработка которых поручается одной команде разработчиков.) CSCI определены и описаны в стандарте Министерства обороны DOD-STD-2167A [DOD, 1988]. К CSCI относятся следующие объекты:.

1.

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

2.

Системные службы (СС). Охватывает скелетную архитектуру, распределение данных в режиме реального времени, глобальные типы данных и интерфейс для взаимодействия с оператором компьютерной системы.

3.

Координация вывода (КВ). В этот CSCI входят управление пользовательским интерфейсом, форматы вывода и распределение вывода по дисплеям.

4.

Тестирование и эмуляция (ТИЭ). Охватывает создание сценариев тестирования, ввод тестовых сообщений, сохранение результатов тестирования и выполнение сценариев.

5.

Основная обработка данных (ООД). Охватывает различные алгоритмы оповещения о запуске ракет по ранним сообщениям, получаемым от радаров, ядерной детонации и со спутников.

6.

Внешнее взаимодействие (ВВД). Охватывает внешние интерфейсы взаимодействия с другими системами, а также ввод, вывод и управление протоколом.

Определяющие характеристики каждого CSCI сведены в таблицу D.I.

Рис. D.2. Организация стадии полномасштабной разработки проекта.

Таблица D.l.

Итоговая таблица по CSCI

Скелетная архитектура ПО.

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

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

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

■ Все главные программы на языке Ada.

■ Все задачи, написанные на языке Ada, и их атрибуты.

■ Все межпрограммные интерфейсы (для асинхронного взаимодействия между задачами), атрибуты этих интерфейсов и соединения с другими интерфейсами.

■ Типы данных для объектов, обмен которыми производится через межпрограммные интерфейсы.

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

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

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

На рис. D.3 показана архитектура ПО с точки зрения ее стабильности. Из графиков видно, что архитектура подвергалась значительным изменениям на протяжении первых 20 месяцев выполнения проекта, после чего стабилизировалась. Большой пик в районе пятого месяца на графиках процессов и задач соответствует попытке обращения к более распределенному подходу. Как только эти эксперименты в области архитектуры завершились принятием соглашений, касающихся стратегий распределения, разработка САПО вернулась к исходному числу процессов. А вот разработка на уровне отдельных задач САПО стабилизировалась на новом более высоком числе задач. Основными проблемами, изучавшимися командой по разработке архитектуры, были достижение соглашений в области параллельного выполнения, накладные расходы на операционную систему, накладные расходы на создание динамических библиотек, разбиение на страницы, переключение контекстов и смешанный обмен сообщениями между процессами, задачами и узлами. Сложность этих взаимодействий в процессе выполнения привела к тому, что моделирование и эмуляция оказались неэффективными. Лишь благодаря демонстрациям на ранних этапах множества вариантов распределения позволили команде, занимающейся разработкой архитектуры, прийти к пониманию того, какие соглашения необходимы для выбора адекватного решения. Если изменения в структуру распределения вносятся на поздних стадиях проекта, последствия могут оказаться непредсказуемыми. Поскольку вносить изменения в межпрограммные интерфейсы и сообщения было легко, а сами интерфейсы и сообщения относились к прикладным интерфейсам более низкого уровня, количество таких изменений постоянно оставалось на невысоком уровне на протяжении всей контрольной точки критического обзора проекта (КОП).

Свобода экспериментов с архитектурой доказала свою ценность с точки зрения возможности получения адекватной базовой архитектуры на ранних стадиях жизненного цикла. Это оказалось возможным прежде всего благодаря гибкости CSCIСАС.

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

D.5 ОБЗОР ПРОЦЕССА.

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

Для управления этой огромной работой по созданию ПО было определено шесть последовательных версий. На рис. D.4 представлены содержание версий и их перекрытие, а индивидуальные параметры версий и микропроцесс более подробно описываются в разделе D.5.I. Завершение каждой версии соответствует новой базовой версии Подсистемы общего назначения. С точки зрения макропроцесса на начальных контрольных точках основное внимание уделяется созданию базовой архитектуры. ПОП требует трех больших итераций по архитектуре, завершение которых совпадает с контрольными точками обзора требований к ПО (ОТПО), промежуточного ПОП (ППОП) и ПОП:.

1.

ОТПО-демонстрация: начальная реализуемость основных компонентов, а также базовые варианты использования для инициализации и взаимодействия между процессами.

2.

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

• Пиковая нагрузка сценария оповещения о запусках ракет данными в случае внезапной массовой ракетной атаки Советского Союза.

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

3.

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

Рис. D.4. Макропроцесс, контрольные точки и сроки проекта CCPDS-R.

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

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

D.5.1 Управление рисками: содержание версии.

Планирование содержания и сроков создания версий Подсистемы общего назначения привело к получению полезного и точного общего плана управления рисками. Необходимость в наличии подробного плана версии хорошо осознавалась командой управления, поэтому он был тщательно продуман еще на начальной стадии. Команда управления определяла ожидаемое реальное содержание версии по мере прохождения жизненного цикла, что давало более точные оценки сложности, риска, персона ла и проектных решений. Такой эволюционирующий план был чрезвычайно важен, он позволял вносить некоторые коррективы в содержание версии и в сроки ее реализации по мере того, как первоначальные догадки становились объективными фактами.

На рис. D.5 подробно показаны сроки и содержание CSCI Подсистемы общего назначения. Рассмотрим детально содержание версий:.

■ Версия 0. Включает в себя основные компоненты, необходимые для построения скелетной архитектуры ПО. В нее входят разработка взаимодействия между задачами/процессами, выполнение общих задач и процессов, а также общие компоненты сообщений об ошибках. Версия 0 является также завершением исследований и разработки проекта, выполнявшихся параллельно стадии ОК (начальной стадии). САС-компоненты представляют собой краеугольные камни архитектуры и спроектированы таким образом, чтобы их можно было повторно использовать во всех трех подсистемах CCPDS-R. Это очень сложные компоненты с высоким риском, к ним предъявляются жесткие требования по производительности, надежности и возможности повторного использования.

■ Версия 1. Посвящена собственно «архитектуре». В нее входят полный набор задач (300 штук), процессов (70 штук), различных видов взаимодействия (1000 видов), состояний и переходов состояний,

Рис. D.5. Версии Подсистемы общего назначения.

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

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

■ Версия 2. Это была первая версия, в рамках которой создавались компоненты, критичные для работы системы в целом, а также достигалась первоначальная возможность исполнения сценариев реальных заданий. Тремя основными рисками в сценариях выполнения задания являлись своевременность распределения базы данных для вывода, производительность (потребляемые ресурсы и точность) алгоритмов обработки данных, поступающих с радаров оповещения о запусках ракет, и реализация пользовательского интерфейса для некоторых сложных случаев вывода. По завершении версии 2 появлялась возможность исполнения некоторых практических вариантов, ориентированных на выполнение задания, включая поток обработки данных в самом плохом случае и управляющий поток в наихудшем случае (переключение с основного на дублирующий).

■ Версия 3. Содержит наибольший объем кода, включая определение формата вывода, определения глобальных типов, спецификации представления, необходимые для обеспечения правильного исполнения операций, связанных с внешними интерфейсами. Большая часть кода создана автоматически «по рецептам» путем создания инструментов для генерации кода. К остальным компонентам, входящим в версию 3, относятся поддержка протокола интерфейса внешних взаимодействий, полный пользовательский интерфейс для операторов, пользовательский интерфейс для компьютеризованных рабочих мест, системные службы для реконфигурации заданий, восстановление баз данных, предварительная обработка данных в режиме оффлайн и алгоритмы обработки данных о ядерных взрывах. Изначально планировавшаяся в качестве одной большой версии, эта часть разработки позже разбивается на две более управляемые версии 3-1 и 3-2.

■ Версия 4. Обеспечивает окончательную установку алгоритмов оповещения для спутниковых систем раннего обнаружения, окончательную установку средств вывода, позволяющих управлять заданием и получать информацию о его состоянии, а также окончательную установку процедуры обработки интерфейсов внешних взаимодействий.

■ Версия 5. По ходу работы над Подсистемой общего назначения была добавлена версия 5 для обеспечения совместимости с некоторым внешним интерфейсом (созданным в результате выполнения другого контракта), поскольку сроки этой работы совершенно не укладывались в рамки изначально спланированной версии (версии 4). Это привело к тому, что создание внешнего интерфейса было выделено в абсолютно новую версию.

Последовательность версий, определенная для проекта CCPDS-R, является хорошим примером типичной последовательности версий, рекомендуемой в разделе 10.4.

D.5.2 Пошаговый процесс проектирования

Отдельные контрольные точки в рамках каждого этапа включали в себя предварительный сквозной контроль проекта (ПСКП), критический сквозной контроль проекта (КСКП) и повторное рассмотрение (ПР). Сроки достижения этих контрольных точек определялись в зависимости от сроков достижения контрольных точек более высокого уровня данного проекта (ОТПО, ППОП, ПОП и КОП) и объединялись с ними. На рис. D.6 показан общий вид жизненного цикла отдельной версии и то, на что направлялись основные усилия.

Рис. D.6. Основные виды деятельности в рамках отдельной версии.

В рамках каждой версии существует четко определенная последовательность процедур сквозного контроля проекта. Такой контроль являлся неформальным детальным техническим инспектированием промежуточных продуктов разработки. В нем принимали участие все, кто был в этом заинтересован, включая других разработчиков, ответственных за тестирование и даже лиц из сторонних заинтересованных организаций (заказчиков, пользователей и персонала, ответственного за проектирование систем). Это участие обычно ограничивалось небольшим числом компетентных людей, обычно 10 — 20 человек. Самое серьезное внимание при таком контроле уделялось наиболее важным компонентам, интерфейсам архитектуры и основным вопросам, иными словами, тщательного рассмотрения заслуживало приблизительно 20% от всего ПО. В охвате всех требований и всех компонентов необходимости не было.

Сквозной контроль проекта был неформальным и сопровождался интенсивным обменом мнениями, для него была характерна открытая критика. При этом удавалось обходиться без всяких скучных мероприятий. Технические проблемы принимались как руководство к действию и отслеживались до полного разрешения. Процедуры ПСКП и КСКП длились один-два дня, в каждой из них принимали участие менеджеры по различным CSCI, ответственные за представление соответствующих материалов.

Предварительный сквозной контроль проекта.

Первоначальные создание прототипов и разработка завершались ПСКП и демонстрацией основных возможностей. Главное внимание при таком контроле уделялось атрибутам структуры тех компонентов, которые разрабатывались на данном этапе. Повестка дня в основном была для каждой версии своя, однако в общем случае в нее включались следующие темы для каждого CSCI:.

■ Обзор: обзор CSCI, интерфейсы, компоненты и метрики.

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

■ Демонстрация: основное внимание сосредоточивалось на проверке управляющих интерфейсов всех компонентов в рамках интегрированной архитектуры.

Критический сквозной контроль проекта.

Работа в рамках проектирования конкретной версии заканчивалась процедурой КСКП и демонстрацией возможностей, которая позволяла увидеть ключевые параметры работоспособности компонентов, созданных в данной версии. В то время как ПСКП сосредоточивался на описательной стороне разработки, при КСКП главное внимание уделялось законченности компонентов и тому, как их поведение при использовании будет соотноситься с заранее определенными требованиями к работоспособности. Повестка дня в основном была для каждой версии своя, однако в общем случае в нее включались следующие темы для каждого CSCI:.

■ Обзор CSCI: интерфейсы, компоненты и параметры; сводка изменений, внесенных со времени проведения ПСКП; решение всех проблем, возникших при ПСКП; сценарии интеграционного тестирования версии.

■ Компоненты: сквозной контроль каждого основного компонента, демонстрирующий интерфейс их исходного кода, распределение требований к СТПО, текущие метрики, рабочая концепция для ключевых сценариев использования, план проведения независимого тестирования, а также условия возникновения и реакции на ошибки.

■ Демонстрация: основное внимание сосредоточивалось на проверке выполнения критических потоков управления.

Сквозной контроль кода.

Тщательный сквозной контроль кода использовался также для распространения знаний и опыта на весь проект и для того, чтобы способствовать созданию самодокументируемого исходного кода. Некоторые авторы писали исходный код, который оказывался настолько удобочитаемым, что удостаивался оценки «самодокументируемый». Менеджеры по CSCI и главный разработчик ПО занимались координацией необходимого контроля кода и его распределением между различными авторами, при этом преследовались такие цели:.

■ Более широкое распространение «самодокументируемого» стиля написания программ.

■ Обнаружение ошибок в программах, которые не всегда могут быть выловлены компиляторами и инструментами для анализа кода.

• Наименования объектов, стиль программирования и стиль комментариев: являются ли они удобочитаемыми?.

• Неоправданно усложненные объекты или методы: не существует ли более простых подходов?.

• Повторное использование: не создавалось ли ПО на заказ там, где имеются повторно используемые компоненты?.

• Потенциальные проблемы с производительностью: существуют ли потенциально неэффективные реализации?.

■ Уменьшение объема исходного кода, подлежащего рассмотрению при сквозном контроле проекта на более высоком уровне.

■ Знакомство неопытных сотрудников с продуктами, созданными экспертами, и наоборот.

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

Повторные рассмотрения.

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

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

D.5.3 Эволюция компонентов.

В проекте CCPDS-R в качестве унифицированного формата для ведения проекта на протяжении всего жизненного цикла использовался язык программирования Ada. Такая унификация позволяла получать значения метрик, определяющих прогресс в разработке ПО, непосредственно из исходных файлов. Применение Ada в качестве языка разработки базировалось на специальном пакете разработки, содержащем объекты, чьи названия имели префикс TBD (to be defined — подлежащие определению в дальнейшем). Пакет TBD-объектов включал в себя TBD-типы, TBD-константы, TBD-значения и TBD-процедуру, отображающую строки исходного кода и связанные с ними комментарии, которые совместно друг с другом могли быть использованы как «заполнители» (placeholders), зарезервированные для пока еще ненаписанных сегментов программы. Процедура объявлялась следующим образом:.

TBD_Statements (Number_Of_Statements: In Integer);.

Такое объявление требовало, чтобы параметр, определяющий число операторов и приблизительно вычисленный для данного сегмента программы, был описан в соответствующих комментариях. Строки исходного кода с обращениями к TBD-объектам рассматривались как строки ADL (Ada design language — язык разработки Ada); строки, не имеющие ссылок на TBD, рассматривались как исходные строки на языке Ada. В таблице D.2 дается пример типичной эволюции компонента.

Таблица D.2.

Типичная эволюция компонента от создания до повторного рассмотрения

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

■ На момент создания только интерфейс (в части его спецификации) определяется посредством исходных строк на языке Ada и соответствующих комментариев. Оценочное количество SLOC для всего компонента обычно задается в виде значения строки TBD_Statements.

■ К моменту проведения ПСКП внутренняя структура компонента постепенно заполняется описаниями данного компонента и оценками размеров программных модулей более низких уровней с.

использованием множественных обращений к TBD_Statements. В этот момент времени 30% SLOC компонента обычно бывают написаны на языке Ada и 70% — на ADL.

■ К моменту КСКП большинство интерфейсов программных модулей и описаний полностью написано на языке Ada, хотя некоторая детальная обработка по-прежнему использует TBD_Statements в качестве заполнителей. Вообще говоря, компоненты на уровне КСКП обычно состоят на 70% из строк на языке Ada и на 30% из строк на ADL. Существует правило, гласящее, что к моменту КСКП не должно быть обращений к TBD_StatementS со значениями, большими 25.

■ К моменту повторного рассмотрения строка TBD не должна появляться где бы то ни было в исходных файлах. Это соответствует завершению реализации.

Иногда эти правила нарушались, однако эволюция большинства компонентов следовала данному образцу весьма точно. Кроме того, использовались подробные стандарты стиля, которые формировали основу для сквозного контроля кода на ранних этапах, и требования к автоматическому аудитору кода, который выполнял проверки на соответствие бесчисленным стандартам до начала повторного рассмотрения.

Одним из побочных следствий применения Ada в качестве языка разработки проекта CCPDS-R являлось то, что изменяющиеся исходные файлы всегда имели унифицированный формат представления, который позволял с легкостью получать информацию об объеме выполненной {исходные строки на языке Ada) и незаконченной (TBD_Statements) на данный момент работы. Хотя исходные строки, написанные на языке Ada, необязательно были завершены — постольку поскольку в ходе дальнейшей разработки в них могли вноситься изменения — они давали относительно точную оценку объема выполненной работы. Полный комплект файлов, касающихся разработки, по всем командам разработчиков мог быть подвергнут анализу в любой момент с целью получения ясности относительно общего прогресса работ. Был создан измерительный инструмент, позволяющий сканировать исходные файлы на языке Ada и собирать статистику о количестве завершенных строк на языке Ada и о количестве TBD_Statements. В качестве выходных получались данные, аналогичные представленным в таблице D.3.

Этот измерительный инструмент и стандарты написания программ для проекта CCPDS-R обеспечили сбор значений метрик по CSCI и по этапам так, что прогресс мог отслеживаться с нескольких точек зрения. Метрики прогресса разработки, описанные в разделе D.7.1, определялись ежемесячно на основании выходных данных, получаемых в результате работы этого инструмента, и представлялись при сквозном контроле проекта каждым разработчиком компонентов для определения суммарных метрик и для обсуждения иерархии компонентов.

Таблица D.3.

Итоговая статистика по параметрам ТИЭ CSCI на 10-ом месяце

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

D.5.4 Процесс пошагового тестирования.

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

Поскольку на протяжении всего жизненного цикла в качестве главного формата применялась компилируемая форма языка Ada, большинство проблем, связанных с интеграцией, таких как непротиворечивость типов данных, устаревание программных модулей и взаимозависимость программных модулей, выявлялось и разрешалось на этапе компиляции.

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

1.

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

компонентов более низкого уровня) в независимой среде. Этот уровень тестирования соответствует тестированию завершенности и соблюдению граничных условий в степени, максимально возможной для НТ.

2.

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

• Ранее продемонстрированные потоки управления могут быть успешно повторены.

• Ранее определенные недостатки устранены.

• Интерфейсы межкомпонентного взаимодействия протестированы полностью.

• Базовая версия является достаточно стабильной для того, чтобы тестирование на соответствие требованиям оказалось эффективным.

3.

Тестирование надежности. В результате выполнения ИТВ и повторной проверки получалась стабильная базовая версия, которая подвергалась широкому тестированию в неурочное время с максимальной нагрузкой в течение длительных промежутков времени по случайным, но реалистичным сценариям. Этот вид тестирования был разработан для выявления рутинных непостоянных ошибок основного хода разработки. Тестирование надежности проводится в течение максимально возможного времени и обычно тогда, когда ресурсы не заняты ничем другим (по ночам и выходным).

4.

Функциональное тестирование (ФТ). Основное внимание уделяется проверке на соответствие определенным подмножествам требований по многим CSCI посредством демонстраций и тестирования реализаций различных вариантов использования (называемых функциональными потоками управления).

5.

Окончательное квалификационное тестирование (ОКТ). Эти тесты эквивалентны ФТ за исключением того, что они производят проверку соответствия тем требованиям, для которых это может быть.

сделано, только если имеется вся система. Например, требование наличия 50%-ного резерва пропускной способности не может быть проверено, пока система не будет функционировать как единое целое.

Общий план построения подсистемы определялся распределением всех критичных по надежности компонентов (компонентов, которые могут приводить к ошибкам типа 0) по версиям 0, 1 и 2. На рис. D.7 показаны общий ход работ по тестированию и базовые версии, подвергавшиеся тестированию в соответствии с планом. Такая последовательность построения базовых версий давала максимум времени для того, чтобы созданные на ранних этапах компоненты критичных потоков управления успевали приобрести законченный вид. Эти компоненты подвергались также более полному тестированию, что повышало уверенность в их готовности к фактическому использованию. На тестирование выделялось время, необходимое для получения эмпирического значения среднего времени наработки ПО на отказ (MTBF), которое демонстрировалось и принималось заказчиком. Например, первые версии Подсистемы общего назначения содержали все необходимые компоненты для управления состоянием потока обработки, для выявления сбоев, восстановления после сбоев, интерфейсов взаимодействия с операционной системой и для распределения данных в режиме реального времени. Одним словом, в них было включено 90% компонентов из тех, что способны привести систему к критичным сбоям, не позволяющим выполнить задание.

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

D.5.5 Рабочие продукты, регламентированные стандартом DOD-STD-2167A Министерства обороны.

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

1.

Применение исходных файлов на языке Ada в качестве единственного однородного формата проекта на протяжении всего жизненного цикла и самодокументируемое изменение этих файлов. Тексты на языке Ada удобочитаемы, и исключалась лишняя работа для подготовки отдельных подробных описаний проекта, которые с неизбежностью отдалялись от реализации.

2.

Организация последовательности тестирования и выходной документации, касающихся содержания данной версии, определялась подмножеством вариантов использования (которые называют последовательностями рабочих операций и сценариями), а не CSCI. Тестирование, основанное на этих сценариях, охватывало компоненты из нескольких CSCI. Оно организовывалось для каждой версии посредством плана тестирования ПО, процедуры тестирования ПО и последовательности отчетных документов о тестировании. Последовательности документов определялись для каждого ИТВ (по одной для каждой версии), для каждого ФТ (для версий 2, 3 и 4) и для ОКТ (одна завершающая всеобъемлющая последовательность тестов). В каждую последовательность тестов вовлекались компоненты из нескольких (незавершенных) CSCI, поскольку процесс интеграции шел постоянно.

3.

Создание документации по тестированию независимых модулей в виде самодокументируемого однотипного ПО. Это обеспечение рассматривалось так же, как и остальной рабочий исходный код с тем, чтобы оно имело тот же формат и можно было регулярно обновлять его для автоматизированного выполнения регрессионного тестирования. Такая же концепция использовалась при проведении тестирования по ИТВ- и ФТ-сценариям: вместо того чтобы разрабатывать.

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

В таблице D.4 представлена вся документация, которая возникла в результате адаптации стандарта 2167А и соответствующих рабочих продуктов (см. главу 6). Подход, содержащийся в стандарте 2167А, был абсолютно неэффективен, даже с учетом адаптации (хотя он оказался намного эффективнее, чем тот подход, который использовался в большинстве традиционных проектов). С самого начала было ясно, что бремя создания документации непомерно, однако отход от традиционного процесса был признан чересчур рискованным. В таблицу D.4 включена только документация ПО; в нее не вошли документы, касающиеся инженерных аспектов систем (безопасность, человеческий фактор, надежность) и сообщества пользователей (план освоения, материально-техническое обеспечение, обучение). Эти документы также требуют затрат от организации-разработчика на создание и сопровождение, даже с учетом того, что в рамках проекта CCPDS-R основная ответственность за них была возложена на других.

Таблица D.4.

Программные рабочие продукты проекта CCPDS-R

Таблица D.4. (продолжение).

Программные рабочие продукты проекта CCPDS-R

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

Таблица D.5.

Эволюция файла разработки ПО

Таблица D.5. (продолжение) Эволюция файла разработки ПО

Подход к рабочим продуктам в проекте CCPDS-R был преобразован и стал напоминать подход, представленный в главе б. Изначально большинство рабочих продуктов было на бумаге. По мере того как заказчик начал проявлять больший интерес к демонстрируемым рабочим продуктам и базовым версиям компонентов продукта, потребность в бумажных документах снизилась — недостаточно, но хоть в какой-то степени. Большим достижением явился переход на полностью электронный ФРПО, для которого стандарты по разработке и кодированию поддерживали самодокументирование рабочих продуктов. Отдельные рабочие продукты для документирования проекта и кодирования больше не требовались. Одной из застарелых проблем CCPDS-R была необходимость графического описания проекта на высоком уровне. Она обеспечивалась в документации системного проекта и в проектных документах ПО самого высокого уровня за счет применения специализированного текста и графики. Подобные представления были неоднозначными, зачастую неактуальными и сложными для понимания. Использование нотации языка Unified Modeling Language, подхода к архитектуре, описанного в главе 7, средств визуального моделирования и поддержки «круговой» разработки позволило бы существенно усовершенствовать подход к представлению проекта и избежать большого количества бессмысленной работы.

D.6 ОЦЕНКА, ОСНОВАННАЯ НА ДЕМОНСТРАЦИИ.

Традиционные обзоры разработок определяют стандартные темы таким образом, что это приводит к чрезмерно обширным обзорам, только небольшая часть которых оказывается по-настоящему важной или доступной для понимания всем участникам. Например, рассмотрение всех требований с равной степенью детализации является неэффективным и непродуктивным. Требования не равны; одни являются критичными для.

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

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

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

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

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

При проведении демонстраций в рамках проекта CCPDS-R были извлечены следующие уроки:.

■ Раннее создание сценариев тестирования способствует высокому ROI. Инвестирование в создание некоторых критичных сценариев тестирования на ранних этапах служит двум целям. Во-первых, это способствует тому, что некоторое важное подмножество требований «оформляется» во вполне осязаемом виде. Сценарии тестирования являются побудительным мотивом определенных контактов и переговоров с пользователями, которые способствуют улучшению понимания требований на ранних этапах жизненного цикла. Во-вторых, выполнение этих работ вовлекает команду, ответственную за тестирование, в создание среды для демонстраций и тестирования на ранних стадиях, что обеспечивает чрезвычайную зрелость среды к тому моменту, когда проект достигает этапа полномасштабного тестирования.

■ Планирование и проведение демонстраций выявляет важные риски. Переговоры, касающиеся содержания каждой демонстрации и связанных с ней критериев оценки, служат для того, чтобы сфокусировать внимание команды по разработке архитектуры, команды управления и внешних заинтересованных сторон на критичных требованиях на ранних этапах и при выполнении работ по созданию архитектуры. Вместо того чтобы иметь дело с полным детальным проектированием и трассировкой всех 2000 требований, команда сосредоточивается на 20-ти или около того ведущих требованиях к проекту.

■ Инфраструктура, инструментальное оснащение и вспомогательное ПО для демонстраций имеют высокий ROI. В начале проекта казалось, что эти демонстрации потребуют значительных вложений в компоненты, которые могут быть использованы только для демонстраций. В большинстве случаев очень незначительная часть этой работы оказывалась пригодной только для демонстраций. Большая часть работы приводила к созданию компонентов, которые затем повторно использовались в последующем при независимом тестировании, интеграционном тестировании версии или.

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

■ Работы по подготовке демонстраций приводят к достижению соглашений по проекту. Интеграция для последующей демонстрации обеспечивает установление своевременной обратной связи по вопросам, касающимся важных атрибутов проекта и его уровня зрелости. Работы по подготовке демонстраций обычно требовали участия от 10 до 12 разработчиков для интеграцки компонентов в единую архитектуру. Они сталкивались с множеством препятствий, переделок, и им пришлось несколько раз вносить изменения как в компоненты, так и в архитектуру. Эта работа осуществлялась на протяжении месяца по большей части поздно вечером. Что на самом деле происходило в процессе всенощных интеграций-отладок-переделок-изменений, так это подробное, чрезвычайно эффективное рассмотрение проекта. Координируя работы, мне удавалось получать из первых рук информацию о том, каковы сильные и слабые стороны архитектуры, какие компоненты уже созрели, а какие пока еще сырые, как следует расставить приоритеты в работе, которую предстоит выполнить после окончания демонстрации.

■ Проблемы в работоспособности, обнаруженные на ранних этапах, приводят к ранним улучшениям архитектуры. Первые две демонстрации охватывали большое число функциональных возможностей и в процессе выполнения имели более низкую работоспособность, чем требовалось. Критерии оценки демонстраций не сильно отличались от окончательных требований к работоспособности. Оглядываясь назад, можно сказать, что это было контрпродуктивно, поскольку приводило к тому, что определенная часть наблюдавших за ходом выполнения контракта ожидала, что критерии оценки демонстрации и требования будут схожи. Заказчик и руководство компании TRW были изначально обеспокоены такой ситуацией, однако простые решения и существенный прогресс, достигнутый в последовательно проводившихся демонстрациях, привели к улучшению понимания.

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