ППОП-демонстрация

ППОП-демонстрация

Промежуточная ПОП-демонстрация Подсистемы общего назначения по достижении основной контрольной точки имела три важные цели:.
1.
Реальная оценка целостности разрабатываемой архитектуры ПО посредством создания САПО-прототипа.
2.
Реальная оценка понимания критичных требований посредством создания наихудшего возможного сценария оповещения о ракетных запусках.
3.
Выявление архитектурных рисков при пиковых нагрузках в сценарии оповещения о ракетных запусках (работоспособность при обработке данных в наихудшем случае, соответствующем массовой ракетной атаке Советского Союза) и в сценарии обнаружения сбоя и последующего восстановления (наихудший случай при управлении обработкой, связанный со сбоем в основном потоке обработки и с переключением в реальном времени на дублирующий процесс обработки, находящийся в «горячем» резерве).
Для культуры создания ПО в рамках проекта CCPDS-R эти цели являются очевидными. Демонстрации не были показухой, предназначенной для того, чтобы произвести впечатление на заказчика отличными результатами и минимальным количеством нерешенных проблем. (Для этого не были предназначены ни сквозной контроль, ни рассмотрения состояния проекта руководством, ни основные контрольные точки.) Демонстрации всегда были честной инженерной деятельностью с честолюбивыми целями, с открытым обсуждением компромиссов и с открытым подходом к обоснованию оценок, касающихся прогресса и качества. По результатам демонстраций обычно производились изменения в требованиях, планах и разработке в одинаковой степени; все эти три аспекта подвергались изменениям на протяжении жизненного цикла.
Работы по подготовке демонстраций обычно охватывали шестимесячный период, при этом основное внимание в течение первых трех месяцев уделялось планированию. Весьма немногие представители коллективов заинтересованных сторон принимали участие в определении формальных критериев оценки. На рис. D.8 показано общее расписание ППОП-демонстрации; подробно представлен также период интенсивной интеграции, длившийся два месяца перед началом демонстрации.
Первые три месяца планирования, которые включали в себя создание чернового плана, рассмотрение этого плана правительством и его комментарии, а также создание окончательного плана, могли бы быть завершены за одну неделю правильно подобранной командой с участием всех заинтересованных сторон. Последовательность рассмотрений, которая происходила на самом деле, определялась требованиями контракта. Поскольку и компания TRW, и заказчик впервые столкнулись с подходом, основанным на демонстрациях, обе стороны не представляли, как наилучшим образом организовать процесс, и согласились на консервативный подход. Эта демонстрация явилась первой попыткой создания
Рис. D.8. Работы и сроки их выполнения для первой демонстрации в рамках проекта CCPDS-R.
полномасштабной САПО. Соответственно, это была первая (и самая неудачная) попытка выполнения общей интеграции Подсистемы общего назначения. Последующие демонстрации обычно характеризовались менее продолжительными при равной интенсивности работами по интеграции, длящимися 4 — 5 недель.
Область действия ППОП-демонстрации.
Основная область действия ППОП-демонстрации определялась положением о выполнении работ по проекту CCPDS-R:.
Подрядчик обязан продемонстрировать следующие возможности NORAD. Демонстрация 1: вспомогательные функции системы, инициализация системы, поведение при сбое и восстановление системы, реконфигурация системы, ввод тестовых сообщений и регистрация данных.
.
Эти возможности были понятны и заказчику, и компании TRW. Они представляли ключевые компоненты и варианты использования, необходимые для достижения целей.
1. Вспомогательные функции системы — это компоненты ПО САС общего назначения, предназначенные для повторного использования во всех трех подсистемах. Эти компоненты составляли основу архитектуры. Они включали в себя службы взаимодействий между процессами, общий контроль за приложениями (диспетчеры задач и.
процессов), САС-утилиты (списки, службы имен и последовательностей) и общие службы мониторинга и сообщений об ошибках. Этих компонентов оказалось достаточно для того, чтобы продемонстрировать любой выполняемый поток управления.
2.
Регистрация данных (СС CSCI). Эта возможность необходима для обработки некоторых результатов и связана с производительностью.
3.
Компоненты, отвечающие за ввод тестовых сообщений (ТИЭ CSCI), позволяли вводить сообщения в любой объект системы таким образом, что тому придавались свойства общего тестового драйвера.
4.
Инициализация системы являлась основным вариантом использования (на рис. D.8 это Стадия 1), который мог продемонстрировать существование согласованной скелетной архитектуры ПО и безошибочную работу значительной части служб системы. Один из рисков, связанных с производительностью, заключался в требовании инициализировать ПО большого объема с распределенной архитектурой, содержащее как сделанные на заказ, так и коммерческие компоненты, в течение заданного времени.
5.
Второй сценарий (Стадия 2) предназначался для формирования пиковой нагрузки по передаче сообщений, которая бы вызывала внутреннюю передачу сообщений по всей системе некоторым реальным образом. Для выполнения этого сценария требовалось, чтобы для всех программных объектов были «смоделированы» правильные, но простые заглушки для обработки сообщений. Эти простые программы на языке Ada завершали выполнение потока обменом фиктивными сообщениями, читая и отправляя сообщения таким образом, каким это должно было осуществляться при пиковых нагрузках. ПО для обработки сообщений прототипов предназначалось для приема входящих сообщений и передачи их далее по компонентам, составляющим САПО. Сюда включался весь сколько-нибудь значимый обмен сообщениями, начиная от получения сообщений от внешних датчиков и заканчивая обновлением выходных сообщений о ракетных запусках, как для основного, так и для дублирующего потоков. Кроме того, сюда же был включен обмен всеми вспомогательными сообщениями, связанными с мониторингом состояния, сообщениями об ошибках, мониторингом производительности и регистрацией данных.
6.
Одним из наиболее рискованных сценариев являлся сценарий сбоя и восстановления системы (Стадия 3), поскольку для его осуществления требовалось выполнение весьма изощренного набора интерфейсов, контролирующих управление состояниями и переход из одного состояния в другое, в логической сети, состоящей из сотен программных объектов. Основной задачей такого варианта использования было создание искусственного сбоя в рабочем объекте основного потока управления с целью вызова всей последующей цепочки.
событий: обнаружение сбоя, уведомление о сбое, полностью оформленный переход от основного потока к дублирующему, закрытие основного потока. Все эти изменения состояний в сети должны были происходить без прекращения обслуживания операторов оповещения о ракетных запусках. Реконфигурация в данном конкретном случае означала восстановление режима после сбоя. При сбое системы дублирующий поток должен инициализироваться таким образом, чтобы влияние разовых сбоев было минимальным. В готовой системе восстановление происходило немедленно вслед за сбоем.
Критерии оценки ППОП-демонстрации .
Основные критерии оценки ППОП формировались на основании требований, оценки рисков и соглашений относительно разработки:.
■ Для всех стадий:.
• Не должно происходить критичных ошибок.
■ Стадия 1:.
• Система должна инициализироваться не более чем за 10 мин.
• Инициализация системы должна выполняться с единственного терминала.
• После инициализации число процессов, задач и межпрограммных интерфейсов обязано в точности совпадать с тем, которое должно быть в текущей базовой версии САПО.
■ Стадия 2:.
• Средняя загрузка процессора каждого узла в наихудший момент сценария с 20-минутной пиковой нагрузкой не должна превышать 30%.
• Не должно быть ошибок, связанных с дублированием или потерей сообщений.
• Все выводимые данные должны быть получены не позднее, чем через одну секунду после их ввода.
• Процесс приема сообщений должен поддерживать такую интенсивность ввода, которая соответствует предполагаемому для данного сценария уровню.
• Регистрация данных не должна приводить к неожиданным изменениям состояния или к сообщениям об ошибках, при этом должны быть зарегистрированы все введенные сообщения.
■ Стадия 3:.
• Оператор должен иметь возможность имитации сбоя в любом объекте.
• Сообщение об ошибке должно быть получено в течение 2 секунд с момента сбоя.
• Переключение с основного потока на дублирующий должно завершаться не более чем через 2 секунды после сбоя без потери данных.
• Закрытие основного потока после сбоя и его повторная инициализация в качестве дублирующего потока должны завершаться не позднее чем через 5 минут после сбоя.
• Зарегистрированные данные должны соответствовать ожидаемым изменениям состояния без фатальных ошибок, кроме специально сымитированного сбоя.
Кроме того, существовало еще 23 критерия оценки для рассмотрения менее важных частных возможностей и промежуточных результатов. Здесь они не приводятся.
Результаты ППОП-демонстрации.
Результаты ППОП-демонстрации оказались весьма плодотворными. Соответствие 31-му критерию оценки из 37-ми было признано удовлетворительным. Шесть критериев не были реализованы, среди них — три важных критерия из тех, что обсуждались выше. Это было расценено как очень серьезная проблема, которая требовала немедленного проведения новой разработки и повторной демонстрации. Наиболее серьезной проблемой оказалась чрезмерная загрузка процессора при выполнении сценария пиковой нагрузки. Хотя пороговое значение было определено как 30%, реальная загрузка составляла 54%. Это свидетельствовало о существенных непроизводительных издержках архитектуры, операционной системы и сетевого ПО. Поскольку этот риск всегда осознавался при разработке системного ПО для проекта CCPDS-R, данной проблеме было уделено самое серьезное внимание. Для анализа производительности были созданы пять различных задач, а также была поставлена цель продемонстрировать улучшение производительности в процессе следующего обзора управления проектом после того, как эти пять задач будут решены.
В упрощенном виде эти пять задач формулируются следующим образом:.
1. Изменение сценария. Текущий сценарий тестирования фактически задавал пиковую нагрузку на 33% хуже, чем реальная пиковая нагрузка. Процессы обмена внутренними сообщениями оказались хуже, чем самый плохой из реальных вариантов (например, каждое сообщение приводило к «сигналу тревоги», результатом чего был чрезмерный и ненужный обмен информацией). ППОП-демонстрация заставила компанию TRW, заказчика и пользователя уточнить описание сценария для самого трудного задания в конкретных и объективных терминах. Это привело также к тому, что команда разработчиков архитектуры стала лучше понимать порядок движения сообщений и соглашения, касающиеся оптимизации. Отдача от выполнения этих работ никогда не определялась количественно, но она наверняка была значительной.
2.
Настройка параметров буферизации взаимодействий между процессами (ВМП). САС-компоненты имеют множество опций для оптимизации работоспособности. Несмотря на то, что за тот месяц, который завершал работы по интеграции, было сделано множество локальных оптимизаций, существовала определенная необходимость в более глобальном анализе с целью извлечения уроков из различных примеров обмена сообщениями.
3.
Расширение сетевых транзакций. Обмен сообщениями между двумя узлами, очевидно, являлся узким местом, поскольку в текущей версии операционной системы (DEC VMS 4.7) никак ije использовалась возможность симметричной многопроцессорной обработки процессорами VAX. Переход на VMS 5.0 обеспечивал существенное повышение общей производительности за счет данного компонента.
4.
Улучшение работоспособности ВМП-компонента. Очевидное узкое место в компоненте, отвечающем за САС-взаимодействие между процессами, оказывало существенное влияние на одну из возможностей оптимизации. Группа, отвечающая за демонстрацию, расценила это как порок разработки, нуждающийся в переделке. (Предварительное решение уже находилось в разработке.).
5.
Повышение надежности ВМП-компонента. ППОП-демонстрация позволила выявить еще один серьезный недостаток: внезапное резкое повышение числа сообщений могло приводить к возникновению ошибок в работе. Чрезвычайно жесткий сценарий сделал этот порок очевидным. Для системы с такими жесткими ограничениями по надежности, какие накладывались на CCPDS-R, этот недостаток обязательно следовало зафиксировать, хотя при эксплуатации системы он мог бы никогда не проявиться. Фиксация такого рода проблем в тот момент могла пройти безболезненно, однако незамеченный до поздних этапов выполнения проекта этот недостаток мог привести к значительному браку и огромному объему дефектов и доработок.
Описанные пять задач в точности соответствовали критичным проблемам, остававшимся нерешенными на момент демонстрации. Это вызвало сильную тревогу как у руководства компании TRW, так и у заказчика; обе стороны надеялись на то, что демонстрация не выявит нерешенных проблем. Несмотря на это, обеим сторонам понравились процесс демонстрации и то беспрецедентно глубокое знакомство с реальным прогрессом разработки и с соглашениями по разработке, понимание требований и оценка рисков, которые они смогли получить. Общий уровень беспокойства заинтересованных сторон снизился после выполнения поставленных задач и повторной демонстрации, которая была проведена приблизительно через месяц после ППОП-демонстрации. Хотя изначальная цель — загрузка процессора не более чем на 30% — не была достигнута, команда показала гибкость архитектуры и наличие возможностей для оптимизации: ей удалось снизить общую загруженность процессора с 54% до 35%. Благодаря такой позитивной тенденции все успокоились по поводу того, что требования к работоспособности будут непременно выполнены за счет непосредственной оптимизации разработки и перехода на более новые версии операционной системы.
Результаты ППОП-демонстрации можно разделить на видимые и формальные. В качестве руководителя, ответственного за процесс, архитектуру и данную демонстрацию, я видел множество незаметных результатов. За период ночных работ по интеграции и тестированию, который длился 8 недель и в течение которого были расставлены многие приоритеты, разрешены многие вопросы, произведен мозговой штурм целого ряда проблем, заинтересованные стороны постоянно получали отчеты о состоянии работ, команды разработчиков обрели мотивацию для решения амбициозных задач, удалось извлечь множество полезных уроков:.
1.
За этот период времени удалось эффективно проанализировать разработку. Демонстрация явилась результатом рассмотрения, выполненного командой разработчиков и представленного заинтересованным сторонам в качестве осязаемого свидетельства прогресса. После ее завершения осталось всего пять нерешенных проблем. За этот восьминедельный период было обнаружено, решено и закрыто не менее 50 проблем, касающихся разработки. Такое раннее устранение дефектов, содержащихся в требованиях, процессе, инструментарии и в самой разработке, имело документально не подтвержденную, но существенную отдачу в виде отсутствия огромного количества дефектов на более поздних этапах, которые бы обязательно всплыли, не реши мы их в период ранней демонстрации.
2.
Благодаря ежедневному участию в этой работе, мне удалось понять, в чем заключаются слабые и сильные стороны разработки и почему. Например, когда мы сталкивались с какими-либо проблемами в компонентах, ответственному разработчику хватало нескольких часов, чтобы найти соответствующее решение. Другие компоненты не поддавались так легко, и поиск решения зачастую требовал нескольких дней. К моменту завершения работ по проведению демонстрации мне было известно, где внесение изменений оказалось простым делом (что обычно свидетельствовало о хорошей разработке компонентов), а где представляло определенные сложности (по очень многим причинам). Такая информация помогала при определении структуры рисков для перспективного планирования, при распределении сотрудников и установке приоритетов для тестирования.
3.
Демонстрация в большой степени способствовала созданию работоспособной команды, поскольку имела вполне конкретную цель, а разработчики могли трудиться в удобном для них режиме: материал для работы всегда имелся в наличии.
4.
Детальное понимание технических аспектов и объективное обсуждение соглашений по разработке оказались бесценными для установления доверительных отношений со всеми заинтересованными сторонами, включая заказчика, пользователя и руководство компании TRW. Мы были вооружены фактами и цифрами, а не субъективными спекуляциями.
Реакция правительства на ППОП-демонстрацию.
Формальная ППОП-демонстрация представляла собой значительную смену парадигмы по сравнению с традиционной процедурой рассмотрения проекта. Соответственно, между компанией TRW и военно-воздушными силами существовали большая напряженность и беспокойство по поводу подробных критериев оценки для этой демонстрации. Следующие абзацы, выделенные курсивом, заимствованы из окончательного плана, утвержденного компанией TRW. Это хорошая подборка вопросов, которые вероятнее всего будут выделяться среди остальных при использовании организацией такого процесса в первый раз. Она позволяет также проникнуться духом демонстраций.
После тщательного изучения комментариев к правительственному предварительному плану Демонстрации 1 были сформулированы следующие замечания, которые подводят итог утверждению плана Демонстрации 1 и изменений, внесенных по сравнению с предыдущей версией:.
1.
Из утверждаемого плана исключены все упоминания о требованиях для того, чтобы избежать намеков на намерение соответствовать, подтверждать или демонстрировать любые требования. Проверка на соответствие этим требованиям выполняется строгим и регламентированным способом специальной организацией, ответственной за тестирование. Работы по проведению демонстрации должны быть направлены на интенсификацию разработки, выполняться с минимальным количеством документации с целью раннего понимания осуществимости разработки и ее прогресса. Компания TRW намеревается максимизировать пользу от демонстрации как от одного из видов деятельности по разработке и хотела бы избежать ее превращения в менее полезную деятельность по интенсивной разработке документации.
2.
В некоторых правительственных комментариях говорилось о необходимости дальнейшей детализации требований, разработки и т.д. Эта информация не нужна для плана демонстрации. Она либо повторяет сведения, содержащиеся в других документах (СТПО, ОПС, пакетах по проверке разработки), либо была предоставлена двумя неделями ранее демонстрации при проведении процедуры неформального тестирования. Включение большего количества информации в один документ (и это справедливо для любого документа), возможно, и облегчит работу проверяющему, однако это будет излишним, потребует дополнительных затрат времени и усложнит создание документа, уменьшая тем самым техническое содержимое рассматриваемого продукта, находящегося в разработке.
3.
В свете подхода правительства к связи между требованиями и демонстрацией, критерии оценки, представленные в данном плане, должны быть тщательно изучены. Мы считаем, что критерии оценки являются точными и глубокими в смысле определения осуществимости разработки, особенно на столь раннем этапе жизненного цикла. Хотя мы.
остаемся открытыми для внесения в эти критерии оценки конструктивных изменений, мы считаем, что их изменение с целью более точного соответствия Спецификациям системы является в данном случае неподходящим. Точка зрения требований и точка зрения данной демонстрации различны и плохо соотносятся между собой.
4. Исходный код демонстрируемых компонентов не поставлялся вместе с планом, как того требует положение о работе. Общий объем продемонстрированных компонентов составляет половину от общего объема, и это соотношение постоянно и быстро меняется. Вместо того чтобы поставлять весь исходный код, тем, кто заинтересован в просмотре того или иного кода, была предоставлена возможность запросить конкретные компоненты на рассмотрение. Весь исходный код доступен для просмотра в организации-разработчике в процессе демонстрации.
Как уже упоминалось ранее, общая реакция правительства на ППОГТдемонстрацию была весьма позитивной, несмотря на выявление пяти серьезных проблем. Когда по истечении одного месяца компания TRW продемонстрировала решение всех этих задач, реакция правительства стала более чем позитивной. Объективные представления, открытая дискуссия относительно соглашений и понятность проблем в разработке, требованиях и функционировании системы привели к установлению исключительных отношений между заинтересованными сторонами. Представители заказчика и пользователей потребовали проведения дополнительной демонстрации для своего высшего руководства, а среди заинтересованных сторон витал дух успеха, разделяемый всеми. Это событие доказало свою важность: с этого момента все стремились поддерживать репутацию данного проекта как флагмана, с которого следует брать пример того, как правильно создавать ПО.