Каждое требование системы должно быть разложено (decomposed) на постепенно более низкие уровни проекта путем определения функций более никого уровня и определением того, как хорошо каждая функция должна быть выполнена. Распределение (allocation) назначает функцию и связанное с ней требование для элемента более низкого уровня проектирования. Проведение разложения и распределения начинается на системном уровне, где требования вытекают непосредственно из нужд миссии, и продолжается через сегмент, подсистему и элемент проекта. Этот процесс должен также гарантировать смыкание в следующем более высоком уровне. Смыкание (closure) означает, что удовлетворение требований более низкого уровня гарантирует характеристики в следующем более высоком уровне, и что мы можем прослеживать все требования назад вплоть до потребностей, удовлетворяющих миссию.
Рис. 4-1 показывает, как единственная потребность миссии - ошибка местоположения спутника FireSat - проходит через многие уровни проекта. Ошибки в заключительных данных миссии зависят от многих источников ошибок в космосе, в управлении миссии и в наземных сегментах обработки данных миссии.
Рис. 4-1. Распределение от требований миссии до проектирования составляющих.
Необходимо понимание источников, вносящих вклад в требования верхнего уровня
Должны быть сделаны два важных наблюдения. Во-первых, система охватывает не только один космический аппарат, и ошибки исходят из многочисленных сегментов. Точность местоположения объекта на снимке спутника FireSat определяется намного большим, чем способностью прицеливания космического аппарата. Во-вторых, хотя число источников ошибки большое, не все они равноценны. Многие предсказуемы и относительно постоянны - звездные каталоги и оценки земного эллипсоида. Другие более изменчивы, но малы и не существенно управляют технологией или стоимостью. Остающиеся ошибки - те, которые являются наиболее поддающимися к трейдам типа "стоимость - характеристики - риск", они нуждаются в самом большом уровне внимания при распределении и проверке правильности требований.
Практика установления функциональных потоков вызвала и пренебрежение, и лесть. Те, кто анализировал требования, используя карандаши и логарифмические линейки (помните логарифмические линейки?), часто с пренебрежением смотрят на инструменты CASE (Computer-Aided Systems Engineering – Автоматизация Проектирования Систем), которые они рассматривают как игрушки программного обеспечения. Но, фактически, документирование функциональных потоков при помощи компьютерных средств просто делает явным неявное, а длительный умственный процесс и прослеживаемость, требуемые для сложных систем, делает их весьма необходимыми. С другой стороны, культ поклонения этим компьютерным средствам и методы схематического изображения могут затенить окончательную цель - создать последовательные и прослеживаемые технические спецификации, которые сформируют законное основание для приобретения системы. Функциональное представление помогает разработать и разъяснить требования, но спецификации - истинное конечное изделие.
Самый простой способ представления функции - блок-схема функционального потока - является наиболее пригодной исходной точкой. Как показывает рис. 4-2, мы определяем сначала самые важные функции. Цель состоит в том, чтобы быть уверенными в работе системы на каждом уровне перед переходом на более низкие уровни, чтобы не пропустить существенное взаимовлияние. Например, чтобы адресовать рассогласование датчика в функциональном потоке на три уровня вниз (функция 4.4.4 на рис. 4-2), мы должны рассмотреть стадии производства (1.0) и интеграции (2.0), которые требуют изготовления и проверки правильности в пределах разумных допусков.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.