Идентификация руководящих требований. Анализ миссии, страница 35

Содержание документов интерфейса значительно изменяется со стандартами и методами приобретающего агентства, а также организации в пределах агентства. Приверженцы стандарта МIL-STD-490A считают, что в объединенном документе могут быть определены только статические характеристики интерфейса. Они ограничивают проект по любую сторону интерфейса до спецификации сегмента или до документов более низких уровней, независимо от того, должны ли обе стороны иметь информацию по обеспечению работы интерфейса. Я нашел, что строгое применение этого многоцелевого стандарта для космических миссий в лучшем случае неуклюже и часто является катастрофическим. Связи соединителя и форматы сообщения должны быть четко определены в документах интерфейса, чтобы они понимались и контролировались. Но характеристики дрейфа гироскопа и характеристики звездного датчика (типа нелинейности функции преобразования, привязки выходной оси или шума звездного датчика) нуждаются в том же самом определении, чтобы наземная станция могла правильно калибровать их. Беспечная приверженность к стандарту MIL-STD-490A приводит к тому, что информация в спецификациях сегмента обычно находится вне взаимного видения и контроля. Большинство организаций NASA и некоторые другие разрабатывающие агентства, не члены DOD, принимают более правильную точку зрения относительно документации интерфейса и контроля. Они пишут в документ интерфейса любые требования, которые должны быть определены, чтобы закрыть интерфейс физически, функционально или процедурно. Я нашел этот подход гораздо более эффективным. Во всех случаях мы должны следовать стандарту так, чтобы выполнить программу.

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

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

Мы должны осторожно применять системные стандарты к изделиям стандартизованной разработки (компонентам аппаратных средств и программного обеспечения). Стандартизованная разработка (common development) изделий индивидуальной конфигурации или компонентов может уменьшить стоимость системы, помочь производству и улучшить эксплуатацию. Но эта практика несет многочисленные риски. Во-первых, разработчик теряет гибкость и поэтому может действовать хуже. Во-вторых, разработчик сегмента может указывать на навязанную стандартизованную разработку как на оправдание за невыполнение требований проекта. Вместо этого стандарты должны указывать на приемлемый набор опций, из которых можно выбирать, такие как семейства процессоров или модули стандартного программного обеспечения. До настоящего времени выгоды от стандартизованности были весьма преувеличены, потому что разработка компонентов имеет тенденцию быть гораздо более определенно-прикладной, чем рекламируемая, и риски часто превышают экономию денег.