Одно известное исключение из этого правила служит примером, где стандартизация работала относительно хорошо для поставочного агентства. «Стандартная шина» NASA предусматривает набор программных пакетов стандартной подсистемы и составляющих, касающихся управления ориентацией, двигательной установки, связи, мощности, тепла, электроники и даже в какой-то части конструкции. Несколько программ NASA были способны «простить» недостатки характеристик (типа мощности и ограничений на ширину полосы частот) и веса, чтобы использовать преимущества стандартного оборудования в стоимости, производительности и удобстве использования. Аналогично были успешно стандартизированы некоторые аспекты управления миссией, включая операционные системы, станционное программное обеспечение, наземные коммуникации и проектирование средств. Каждая программа должна исследовать альтернативы между риском разработки и развертывания и потенциальными преимуществами в стоимости, производительности и удобстве использования.
Я повторил много раз в этой главе, что мы не можем предписывать способы по установлению требований. "Шаги", описанные в табл. 4-4, - это руководящие принципы установления концепции задания требований в приблизительно последовательном порядке. Мы должны видеть эти шаги как часть сложной системы обратной связи и управления. Когда программа успешна, система управления устойчива и проект сходится. Некоторые шаги в этом процессе в значительной степени предопределены, в частности, новая спутниковая система требовала использования существующих наземных средств NASA. Начальные результаты этих шагов в программе будут изменяться, иногда драматично, но это не имеет большого значения, и являются фактически ожидаемым аспектом процесса.
Кроме того, требования должны быть распознаваемы из документов, в которых они написаны (спецификации). Стандарт MIL-STD-490A имеет ограниченное значение, пока мы анализируем и утверждаем требования программы. Мы должны задокументировать критические требования, проконтролировать их на ранней стадии и держать их действующими, точными, и доступными как общий эталон программы. Поддержка в общественном представлении какого-либо требования, которое специфический сегмент считает ошибочным, пробудит инженерную мысль, поэтому мы не должны быть озабоченными стандартами, которые диктуют формат на ранней стадии программы. Вместо этого у нас должен быть такой подход: документация должна удовлетворять программу и сосредотачивается только на критических требованиях.
В шагах, которые касаются определения требований, каждое требование должно иметь три компонента. Во-первых, мы определяем "что" должно быть выполнено (функция - function). Во-вторых, мы определяем "как хорошо" функция должна быть выполнена (требование характеристики – performancerequirement). Наконец, мы определяем, как требование должно быть проверено (проверка - verification). Для этого последнего компонента разработчики часто только решают, проверять ли осмотром, анализом, испытанием, или демонстрацией. Но это упрощенное действие может вызвать много проблем в характеристиках программы. Вместо этого проверка означает две основных вещи. Во-первых, требование должно быть написано так, чтобы кто-то мог интерпретировать и проверить его. Во-вторых, на ранней стадии действия по проверке правильности необходимы для выработки условий и методов, которые в конечном счете определят, что проект выполняет критические требования характеристик.
В табл. 4-4 приведены семнадцать шагов по установлению концептуальной основы требований на ранней стадии разработки программы. Другими словами, таблица подчеркивает действия, относящиеся к анализу и подтверждению системных требований для проектов сегментов, подсистем или компонентов. Эти действия создают иерархическую основу требований, которые ведут к набору сегментов, составляющих систему.
Таблица 4-4
Шаги по разработке концептуальной основы требований. См. текст для обсуждения
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.