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

Хотя успех каждой программы зависит от характеристик, стоимости и графика, стоимость обычно наиболее ограничивающий фактор. Реакция на силу стоимостного фактора – так называемая спецификация проектирования с учетом заданной стоимости (design-to-cost specification), в которой установленное количество долларов ограничивает возможный проект. Я не знаю никакой большой космической программы, которая стала бы жертвой этого подхода, но некоторые меньшие программы использовали его успешно (см. главу 22). Для этих менее сложных систем или для простых модификаций стоимость – это не оставляющее сомнений требование. Не обращаясь к этой спецификации для более сложных систем, мы, тем не менее, можем много сделать по управлеию стоимости программы при анализе требований. В прошлом разработчики часто переразмеривали требования, чтобы быть в "безопасности", но складывание 2s-сводок на 2s-сводки часто приводило к чрезмерному проектному запасу при большой стоимости. В некоторых случаях, таких как слишком большой запас в линии связи, этот процесс мог бы также ухудшать выходные характеристики. Как обсуждено ранее, определение требований без того, чтобы проявлять внимание к производству и эксплуатационной поддержке, также дорогостояще. Чтобы сражаться с этими проблемами, в каждом важном решении должна быть проведена оценка того, какой вариант характеристики удовлетворяет основным требованиям при минимизации стоимости.

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

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

Управление стоимостью здесь крайне важно. Немного уместных решений по ограничению стоимости (например, спецификация проектирования с учетом заданной стоимости, навязанная стандартизация) работают для сложных космических систем. Фактически, многие из этих подходов с хорошими намерениями на ранней стадии проектного цикла могут позже кончаться серьезным ростом стоимости и проекта, и эксплуатации. Но эта трудность в управлении стоимостью не подразумевает, что мы должны быть безразличными к стоимости. Наоборот. Рост стоимости от ранних оценок, выполненных при разработке концепции, обычно управляется несколькими контролируемыми факторами. Во-первых, неполный расчет всех элементов стоимости в этих ранних оценках. Часто недостаток консультации с проектировщиками и изготовителями, которые разрабатывают систему, и операторами, которые будут управлять системой, приводит к преуменьшению стоимости или потере элементов стоимости. Во-вторых, чрезмерная определенность системы запрещает трейды, которые могут быть сосредоточены на сокращении стоимости. Наконец (и, вероятно, наиболее распространенный фактор), многочисленные и неконтролируемые изменения в требованиях, когда система проходит через последние стадии проекта, могут приводить к росту стоимости из-за постоянного перепроектирования и материальных потерь. Худший вариант и потенциально очень дорогостоящий – когда потеря полностью понятой основы системы становится вероятной на последних стадиях программы. Процесс определения и распределения требований воздействует на стоимость как никакая другая деятельность по программе.