Как только первый цикл взаимодействий между системой и сегментами установил самую управляемую оценку этих ключевых бюджетов характеристик, мы должны испытывать и затем испытывать еще больше, пока проект разрабатывается. Здесь испытание не означает формальную интеграцию и приемочное испытание, выполненное в конечной стадии проекта. Вместо этого мы должны обеспечивать подтверждение в ранней стадии проекта, используя опытный образец и модели сегментов, связанные в логические, если не физические, испытательные конфигурации. Все системы и сегменты требуют разработки этих опытных образцов, чтобы поддержать процесс проектирования, будут ли они компьютерным кодом, собранными эксплуатационными данными или аппаратными средствами. Многие разработчики должны будут создать их на ранних стадиях разработки технологии или концепции проекта. Иногда разработчики уклоняются от этих упражнений по ранней проверке правильности из-за стоимости опытных образцов и беспокойства, что системный инженер и другие будет пробовать "проектировать" сегмент. Но имеются огромные преимущества для каждого вовлеченного. Эти ранние упражнения в интеграции системы развивают согласие, которое продолжается всю начальную стадию проекта.
Основная линия общих требований должна всегда поддерживать процесс анализа и оценки требований характеристик, взаимодействия и ведения переговоров с разработчиками сегментов и подтверждения ключевых драйверов характеристик на ранней стадии проектирования. Упражнения по проверке правильности используют много определенных сценариев или точечных ситуаций, чтобы оценить характеристики. Выполнение бюджетов характеристик в этих точечных ситуациях успокаивает, но не достаточно. Сценарии, предназначенные для того, чтобы подчеркнуть один аспект характеристики системы, не будут подчеркивать другие аспекты. Сходящиеся, управляемые требования системы, зафиксированные в документах требований, интерфейсах и стандартах - единственная ссылка для функций и характеристик. Документация требований должна соответствовать завершающей стадии разработки системы, но она должна всегда отражать результаты исследований, обсуждений бюджетов характеристик и упражнений по проверке правильности - искренне, открыто и быстро.
Люди, которые разрабатывают космические системы, реагируют по-разному на термин "спецификация". Многие представляют в своем воображении Библиотеку Конгресса, полную громоздких и часто чрезмерно уточняющих деталей, наложенных на проектирование систем. Конечно, коммерческое развивающееся сообщество рассматривает правительственные поставки именно таким образом - и часто они абсолютно правы. Но многие коммерческие спутниковые программы, в предпринимательском духе работы с риском, документируют и измеряют их системы так мало, что их подход не будет работать для программ с ограниченными скоростями развертывания или высокими инвестициями. Многие ожидают твердое и полное определение системы, готовое быть переданным подрядчикам разработки, которые затем автономно проектируют и производят систему. Менеджеры программы действуют так, как если бы этот подход заставлял их терять контроль над разработкой и вынуждал стать заложниками жадных подрядчиков, когда они предлагают любое изменение в спецификации. Подрядчик разработки ожидает спецификацию с ликованием, но она всегда запоздалая и всегда нуждается в изменении, потому что она не была определена правильно вначале. К счастью, эти представления преувеличены и наивны, но опыт иногда показывает, что это неприятно, но близко к истине.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.