Глава 2. Приоритеты определяются на базе ряда критериев, самый важный из которых — ожидаемый эффект от планируемых рабочих характеристик2.2.9. Приоритеты Приоритеты определяются на базе ряда критериев, самый важный из которых — ожидаемый эффект от планируемых рабочих характеристик, так как этот эффект более всего заботит проектировщика. Другой критерий — отсутствие нежелательных побочных эффектов. Например, выбранный проект может обеспечить наилучшие рабочие характеристики, но вытекающие из него требования к надежности слишком высоки. В принимаемом проекте должно быть исключено перепроектирование каких-либо подсистем или элементов, потому что это вызвало бы отсрочку запуска системы. Если это возможно, рекомендации разработчика не должны выходить за пределы традиционных приемов проектирования, но должны давать способ наиболее приемлемого для данной системы решения. И если все требования удовлетворяются, ввод проекта не должен вызвать затруднений. 2.2.10. Соответствие Подразумевается, что вклад ИЧФ в проект будет значимым п том случае, если он приемл«м для конкретных производственных возможностей. При прочих равных условиях наиболее подходящими окажутся те данные по ЧФ, которые касаются -не только персонала (например, профотбор, подготовка персонала, форма техдокументации), но и технических и программных средств или даже процедурных аспектов системы. Следовательно, решающее значение приобретают методы ЧФ, непосредственно относящиеся к разработке системы. Соответствие проекта требованиям, предъявляемым к системе, определяет ценность подходов к ЧФ, выработанных при проектировании. 2.2.11. Рецензирование проекта Главный проектировщик работает в составе проектировочной группы, но его решения, которые принимаются после консультаций с другими членами группы, являются окончательными, даже если они иногда и отменяются вышестоящими инстанциями. Проектные решения периодически рецензируются на соответствие срокам, и это единственная возможность для ИЧФ, который почувствовал, что ему отпущен слишком короткий срок, повлиять на решения главного проектировщика. Из того, что было изложено, можно заключить, что разработка системы является логичным, строгим, рациональным процессом интеллектуальных открытий и творчества; однако этот идеал искажается далеко не интеллектуальными влияниями, та- _______ Проектирование, разработка н нспытанне систем ____________63 кими, например, как нереальная стоимость, неприемлемый график работ, организационная путаница, отсутствие общения между проектировщиками и, что немаловажно, тем предубеждением, с которым относятся к ЧФ другие специалисты. 2.3. Требования к операторской деятельности Во время проектирования ИЧФ не раз выдвигает требования, касающиеся деятельности оператора. Требования могут быть четырех типов (слово «могут» указывает на то, что ИЧФ может оказаться не в состоянии предъявить эти требования, а может случиться, что они и не понадобятся): 1. Требования, касающиеся отбора и набора персонала, обслуживающего систему, т. е. определение численности персонала, а также описание работ и навыков операторов вместе с требованиями к уровню подготовки персонала. 2. Требования, касающиеся обучения персонала, т.е. учебного плана, количества обучающихся, технических средств обучения (например, тренажеров, моделей, установок) и инструкторов. 3. Требования, непосредственно влияющие на проект технических средств, программного и процедурного обеспечения системы таким образом, чтобы конечный продукт хотя бы в минимальной степени удовлетворял стандартам ЧФ: проект и/или рецензия/оценка интерфейсов человек — машина (обычно дисплеев и пультов управления); проект и/или рецензия/оценка компьютерного программного обеспечения; проект и/или рецеи-аия/оценка рабочих процедур; рецензия технических данных; перечень требуемых характеристик окружающей среды (например, освещение, оборудование рабочих мест); прогнозирование производственных показателей персонала. 4. Требования, касающиеся проверки персонала, обслуживающего систему, и оценка эффективности его работы: написание программы испытаний, включающей перечень критериев и измерений производительности труда; статистические и экспериментальные проекты; проект, анализ и отработка сценария проверки; анализ результатов испытаний, выработка заключений и написание отчетов об испытаниях. 2.4. Действия правительственной администрации 2.4,1. Введение Разработка системы протекает по двум параллельным направлениям, которые частично совпадают. Предположим, что система разрабатывается по поручению правительства. Тогда оно 64 Глава 2 предпринимает ряд мер, важнейшими из которых являются плакирование системы, контроль за ее разработкой после заключения контракта и оценка конечного продукта. За редкими исключениями, правительственные органы сами, не проектируют систем (правильнее сказать, что они не ведут проект на протяжении всего Цикла разработки, включая производство, хотя некоторые подключаются к проектированию на очень ранних стадиях). Иногда, во время аванпроекта, правительство заключает контракт иа производство опытно-конструкторских работ, по завершении которых проводятся испытания опытного образца системы, после чего она сдается правительству для заключительного испытания. В этом разделе описывается правительственная деятельность, связанная с управлением процессом разработки систем. Основанием для того, чтобы раскрыть читателю некоторые стороны функционирования (в основном) Министерства обороны (МО), является то обстоятельство, что многие ИЧФ, разрабатывая новые системы для военных, прямо или косвенно сталкиваются с этой проблемой. Имеются, конечно, и исключения. Например, ИЧФ. работающие для иных отраслей и ведомств, а не для МО. или ИЧФ, разрабатывающие коммерческие системы, такие, как рейсовые самолеты. Но этот рынок для ИЧФ довольно невелик, вследствие чего ИЧФ должны быть осведомлены о деятельности правительственных органов, влияющей на системы, над которыми они работают. Правительственный план управления разработкой систем Частично совпадает с актуальными направлениями разработки технических и Программных средств. Документация, определяющей такое управление, дает лишь слабое представление о деятельности ИЧФ вО время проектирования; эта тема рассматривается в последующих разделах. Действия правительства, описываемые ниже, по существу создают ситуацию, при которой заказчик системы или руководитель проекта должен постоянно оправДыбать разработку системы в ответ на заявления правительственных органов о том, что без системы можно обойтись. За системами, разрабатываемыми полностью для коммерческого использования, правительственного надзора не произво-дитсй. Однако если система разрабатывается по крайней мере отчасти с ориентацией на правительственные (наряду с коммерческими) нужды, то разработчик должен иметь в виду, что его система должна удовлетворять требованиям правительственных Заказов. ЭТапЫ разработки системы могут частично перекрывать друг Друга. Они включают планирование системы, аванпроект, детальный проект, испытание и оценку, производство н, когда Сиетема передана заказчику или подрядчику, эксплуатацию. Проектирование, разработка я испытание систем65 МО, которое является главным правительственным заказчиком новых систем, использует процедуру рецензирования на каждом из этих этапов. Среди элементов, подлежащих рецензированию, находятся и факторы, относящиеся к персоналу. Описание этого процесса и отношения поведенческих факторов к различным этапам разработки рассмотрены в работах [16, 28, 29, 45, 48]. Правительство применяет следующую классификацию этапов разработки: I. Запинание программы. Требуется, чтобы необходимость разработки была подтверждена в документе, называемом «обоснование необходимости основных составляющих задания» (ОНОСЗ). II. Обоснование и утверждение. Зависит от рекомендаций, сделанных в документе согласования решений (ДСР). III. Полномасштабная инженерная разработка. Основывается на окончательных вариантах ДСР. ША. Производство и развертывание. То же, что III. Директива МО 5000.1 [5] устанавливает, что человеческие факторы должны быть включены как ограничивающие элементы в проектирование системы (обратите внимание на отрицательное значение термина), начиная с этапа формулирования концепций и кончая вводом в эксплуатацию. Директива МО 5000.2 [6] учреждает совет по рецензированию оборонительных систем (СРОС) и отдельные службы СРОС, ответственные за рецензирование ДСР, для выработки рекомендаций по руководству программой. Холсхаузер [16] и Мейстер [28] перечисляют вопросы, на которые нужно дать ответ на каждом этапе работы СРОС. На рис. 2.1 показаны различные этапы разработки, пункты контроля СРОС и предложения, которые ИЧФ вносит на каждом этапе. Директива МО 5000.3 [7] требует, чтобы все системы испы-тывались и оценивались (И и О), И и О начинались как можно раньше и продолжались в течение всего проектирования и планы закупки техники соответствовали И и О. Некоторые правительственные органы могут выдвигать свои собственные требования. Например, военно-морское интендантство, которое отвечает за приобретение всех военно-морских систем, выпустило инструкцию 3900.9А, которая предписывает обязательное выполнение программы по ЧФ на всех этапах разработки системы [39]. Все эти директивы и инструкции имеют силу закона. Однако на практике из-за негативного отношения проектировщиков к ЧФ пункты, касающиеся ЧФ, часто обходят или выполняют весьма неохотно. Контроль со стороны МО часто носит формальный характер, с акцентом на соответствие расходов смете. О подобном регу- 66 Глава 2
Рис. 2.1. Этапы создания военной системы [48]. 1 — назначение системы/анализ этапов; 2 — анализ функций — функциональные блок-схемы; 3 — схемы решение/действие; 4 — распределение функций; 5 — графики выполнения; 6 — распределение последовательности операций; 7 — описание задач; 8 — анализ рабочей нагрузки; 9 — анализ задач; 10 — макетирование; 11 — анализ связей человек—машина; 12 — рабочее испытание. лировании коммерческих проектов ничего не известно, хотя н для них оно было бы целесообразным. Исследования н анализы на различных этапах военных программ повторяются; документы постоянно обновляются, расширяются и пересматриваются на каждом этапе. Поэтому предложения по поведенческим характеристикам, подготовленные для этих документов, также должны постоянно обновляться. Перечень организационных единиц, используемых военно-морским ведомством при рецензировании различных документов, см. в работах [28, 29]. 2.4.2. Этап анализа возможностей На этом этапе требуется большой объем работы для идентификации и определения необходимости задания. Обоснованием такой необходимости является либо конкретная угроза (требуется отдельная техническая разработка), либо стратегическая или Проектирование, разработка и испытание систем тактическая угроза (требуется разработка новой системы орут жия). Необходимость задания анализируется в ОНОСЗ или в рабочем требовании (РТ). В ОНОСЗ описываются частные задачи, оценивается предполагаемая угроза, анализируются возможности выполнения задания, указываются ограничения проекта (например, стоимость и время), обсуждаются перспективы создания альтернативных систем. Хотя из перечисленного следует, что в ОНОСЗ не учитываются поведенческие характеристики, однако одним из ограничений при решении задачи может быть отсутствие персонала и ресурсов для его подготовки (хотя это вряд ли может остановить планирующие органы правительства). ОНОСЗ следует пересмотреть и включить в него требования к персоналу с учетом достигнутого в настоящее время уровня подготовки. 2.4.3. Этап зачинания программы (аванпроект) Основными процедурами на этом этапе являются 1) подтверждение необходимости задания, 2) обзор имеющейся техники для определения образцов, не отвечающих техническим требованиям системы, 3) первоначальная стратегия приобретения системы и 4) подготовка и выпуск документации, необходимой для принятия решений на этапе I. В ходе аванпроекта подготавливаются три важных документа: 1. Предложения по разработке (ПР) вырабатываются организацией, приобретающей систему. В этом документе представляются альтернативные варианты (чтобы расширить возможности системы). Он служит основой для ДСР, являющегося самым важным документом, на основании которого принимаются решения. 2. В ДСР формулируется окончательный вариант программы, стратегия приобретений, альтернативные варианты системы и дополнительные требования, исходящие только от исполнительного совета по закупкам. 3. В генеральном плане испытаний (ГПИ) описывается программа испытаний. Отметим, что все документы разрабатываются для системы в целом; ЧФ играют в них лишь второстепенную роль. С точки зрения человеческих факторов ПР рецензируются для того, чтобы гарантировать точность в оценке человеческих ресурсов, связанных с альтернативными вариантами, и удостовериться в возможности обеспечения подготовки персонала и его содержания.
|
