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