Обязанности системного инженера:

Краткое пособие для системного инженера,
участвующего в проекте создания микроспутника
Перевод С. Карпенко
Обязанности системного инженера:
-
рутинные взаимодействия с заказчиком (5%);
периодические отчеты для заказчика, оформление документов (15%);
взаимодействие с менеджерами более высокого уровня (5%);
встречи и совещания с рабочими группами (5%);
рутинный контроль за выполнением программы с использованием
доступных средств и инструментов (10%);
формулирование технических требований, анализ проекта, анализ
производительности (15%);
контроль за тем, чтобы нужные люди обладали правильной информацией, и
соответствующие механизмы выполняли те задачи, для которых были
предназначены (45%);
Основные критерии эффективности работы системного инженера (Systems
Engineering Metrics):
Стоимость:
- неповторяемость (non-recurring engineering, NRE), т.е умение использовать
готовые разработки;
- Стоимость единицы продукции;
- Стоимость материалов;
- Субконтракты;
- Командировки.
Организация работы:
-
Ведение документации;
сроки поставок;
сроки получения комплектующих;
основные «контрольные точки» проекта;
Технические характеристики проекта:
-
Основные ТТХ;
Надежность;
Срок эксплуатации;
Два из трех критериев всегда могут быть оптимизированы в ущерб третьему.
С чего начинается технический проект в области космоса на Западе:
1. Заказчик выдает «Запрос на предложения» (Request for proposal, RFP). В нем
указываются:
- цели и принципы проекта (proposal gudelines);
- эскиз (набросок) плана работ над проектом (draft statement of works);
- набросок спецификации – техн требований к изделию, которое надо
спроектировать
2. RFP рассматривается подрядчиком;
3. Подрядчик принимает решение об участии в проекте;
4. Подрядчик формирует пилотную группу, которая формирует документ - т.н.
Mini-Project (Proposal Document), в котором отражены:
- а) общий график работ, предварительный бюджет, рабочая структура групп участники и менеджеры;
- б) предварительный технический анализ проекта;
- в) обзор возможностей подразделений компании, которые планируется
привлечь в участию в проекте
5. Mini-project предоставляется заказчику;
6. Заказчик выбирает наиболее подходящий вариант;
7. Заказчик ведет переговоры с выбранным подрядчиком, предметом которых
являются:
- объем выполняемых подрядчиком работ;
- стоимость работ;
- вид оплаты (каждый месяц по завершении каждого этапа по готовности
всего изделия);
- оговариваются условия (terms & conditions);
8. Подписывается контракт;
9. Проводится итоговая встреча сторон.
Планирование проекта на первых стадиях:
Основная цель системного инженера – т.н. Integrated Product Development, т.е.
систематическое
стремление
к
организации
интегрированного,
стандартизованного процесса разработки продукции и связанных с ним
процессов. «Интегрированный» - значит увязка этапов инициализация+анализ
проекта+планирование+разработка
инструментария+планировапние
производства/испытаний. Базовый принцип системного инженера: активное
вовлечение в проект на ранних этапах разработки и создания всех тех, кто в
конечном счете обеспечит успех проекта. Основные критерии работы
системного инженера: качество продукции, минимизация ее стоимости,
эффективность планирования, производительность.
Базируясь на этих идеях, системный инженер после подписания контракта:
1. выполняет общее планирование работ (ОПР). Это документ, в который
должны входить:
- формулировка целей проекта;
- технические требования к проекту;
- схема организации рабочих групп;
- график работ, костяком которого являются т.н. «вехи», или «контрольные
точки»
2. организует передачу ОПР в рабочие группы;
3. выполняет выявление потенциальных проблем, могущих возникнуть при
работе над проектом;
4. составляет список источников этих проблем;
5. организовывает внутренний документооборот и отчетность;
6. ведет контроль за эффективностью работы рабочих групп;
7. стремится при этом упростить связи между группами;
- контролируя их производительность и соблюдение ими графика;
- ведя листок «Полученные уроки» - фактически это ведение списка из п. 3
Принцип ведения работы в группах:
1. Максимальное использование имеющихся материалов и данных;
2. Отсутствие каких-либо секретов или барьеров между группами;
3. умение выслушивать друг друга;
4. помощь друг другу;
5. получение удовольствия от общения друг с другом;
6. эмоциональная устойчивость участников;
7. участники должны относиться друг к другу:
а) с достоинством;
б) с уважением;
в) благожелательно;
г) справедливо;
д) с доверием.
Создание графика работы над проектом
График работ основывается на контрактных сроках, объемах работ, требований
спецификации (технического задания), списке всех задач, которые необходимо
выполнить для завершения проекта, базовых вехах (контрольных точках) и
сроках отчетности. На входе должны быть:
- список решаемых специальных задач;
- имеющиеся ресурсы (ответственные за выполнение задач);
- бюджет времени.
Достоинства такого планирования:
- как показывает опыт, это самый верный способ построения графика
работ;
- меньше шансов «забыть» про ту или иную важную задачу;
- является основой для планирования работ и финансирования
Недостатки:
- требует времени для составления, т.е. достаточно трудоемка.
Типичные «контрольные точки», на которых базируется график работ:
1. Отчет по концепции проекта (Conceptual Design Review CoDR);
2. Отчет с предварительными определениями требований к облику проекта –
Requirements Review (RR) – для заказчика;
3. Предварительный отчет по проекту (Preliminary Design Review, PDR);
4. Конечный отчет по проекту – (Critical Design Review, CDR);
5. завершение квалификационных испытаний;
6. получение полетных систем.
Типичные «вехи», или контрольные точки:
7. завершение этапа разработки анализа;
8. завершение испытаний или процедур изготовления;
9. квалификация узлов;
10. завершение моделирования (Development testing);
11. завершение анализа температурных режимов;
12. завершение или начало испытаний отдельных узлов или систем.
Рекомендации по составлению плана работ:
-
составить список событий, а также всех задач, и распределить список
участникам рабочих групп (без сроков);
участники совместно вырабатывают предложения по срокам;
составляется итоговый график работ;
назначаются ответственные по направлениям.
Замечания:
1.
2.
3.
4.
5.
В итоговом графике не должно быть неуказанных дат!
Длительные этапы должны быть максимально проработаны;
Задачам должны быть указаны приоритеты;
Должны быть указаны критические участки проекта;
Должны быть отображены все критические события, важные как для
заказчика так и для внутренних групп.
Хороший график работ обеспечивает:
1. Понимание влияния тех или иных задержек в выполнении одной из частных
задач на ход проекта в целом;
2. Четкое видение критических участков проекта;
3. Оценку в любой момент времени, насколько в % он близок к завершению.
Управление проектными рисками;
Постулаты:
1. Сбои и неожиданные трудности будут возникать независимо от качества
планирования!
2. В этом случае необходимо по возможности удерживаться в рамках
финансирования и графика работ;
3. Цель системного инженера – оценка всех возможных источников риска и
такое управление, чтобы риски из разряда высоких и средних снизились до
низкого.
4. Наиболее простой способ их оценки – составление списка источников риска;
5. Он может быть составлен как для всего проекта в целом, так и для
отдельных задач;
6. Положение риска в списке определяется уровнем приоритета, а также
этапом, когда он имеет место. Первыми указываются:
- требующие немедленного внимания и решения; ставящие под угрозой весь
график работ или его стоимость;
- требующих решения за ограниченный период времени и ставящих под
угрозу график работ над проектом;
- требующие контроля, поскольку в принципе могут повлиять на ход всего
проекта;
- могущие сказаться на выполнении отдельной задачи проекта.
По завершении проекта из списка рисков формируется в отчет «Полученные
уроки»
Как сформулировать требования к тем или иным системам (ТЗ)
Правильная формулировка иерархии требований, а также установление связей
между ними – один из важнейших аспектов, необходимых для успешного
выполнения проекта в области создания космической техники. Оно, это
разделение требований, обеспечивает:
1. Создание оптимальной конструкции, удовлетворяющей требованиям ТЗ и
квалификационным требованиям;
2. Совместимость физических интерфейсов систем;
3. Разграничение независимых проектных ограничений, и проистекающих из
них требований к тем или иным системам, что важно для проектного
анализа
4. Позволяет избежать повторяющихся, или пересекающихся исследований
5. Соглашение по контрактной ответственности. (resolution of contractual
liability)
6. Формирует подход к «перетряске» проекта в случае проектных изменений
Основные этапы проектирования и анализа проекта
1.
2.
3.
4.
5.
6.
7.
8.
Формулирование целей проекта и требований к системам;
Определение конечных целей проекта, промежуточных задач;
Определение внешних объективных проектных ограничений;
Оценка ключевых требований на уровне систем и подсистем,
проистекающие из этих ограничений, а также накладываемые ПН. В итоге
получаем документ – CoDR
Характеристики концепций построения систем;
Проработка нескольких концепций построения систем подсистем;
Выявление определяющих требований и особенностей проектирования
Составление предварительной сводки масс, энергопотреблений, точности
ориентации и т.д.;
9. Формирование отчета по системными требованиям (System Requirements
Review, SRR);
7. Выбор базовой концепции;
10. Оценка параметров систем подсистем на основе ключевых требований,
стоимости, эффективности, сроков;
11. Формулирование детальных технических требований;
12. Оценка параметров принятых за базовый вариант систем подсистем путем
проектирования, анализа, создания прототипов; уточнение ТТХ к ним.
13. Создание отчета PDR;
14. Завершение этапа системного проектирования;
15. Выполнение финального комплексного системного анализа;
16. Выполнение проектных прототипных испытаний с целью понижения риска;
17. Завершение создания конструкторской документации, разработки
технологических операций, программы испытаний;
18. Создание отчета CDR;
19. Создание и испытания «железа»;
20. Изготовление, сборка и проведение квалификационных испытаний систем;
21. Завершение программы квалификационных испытаний;
22. Запуск и эксплуатация системы;
23. упаковка и доставка на космодром
24. интеграция КА с РН и предстартовая подготовка
25. проверка КА на орбите
26. начало основной программы эксплуатации
Типы системных требований:
- накладываемые ограничениями на проект в целом:
1. условия эксплуатации (вакуум, температурные перепады, радиация и т.д.)
2. «законы физики» (гравитация…)
3. требуемая характеристическая скорость
4. время существования
5. требования со стороны РН (суммарная масса, габариты, вибрации при
старте, ударные нагрузки при разделении, интерфейсы)
- «производные» требований – функциональные и относящиеся к управлению:
1. тяга ДУ;
2. диапазоны рабочих температур;
3. компоновка безопасность эксплуатации;
4. точность ориентации КА;
5. требования к объему бортовой памяти, скорости бортового процессора;
6. диаграмма команд управления, характеристики ТМ-каналов сбора
информации;
Разница между этими типами требований – первый набор существует
независимо и всегда; состав второго может меняться в зависимости,
например, от предлагаемой конструкции
Источники требований:
А) контрактные документы
1. контракт;
2. RFP;
3. Эскиз технической спецификации;
Б) стандарты
1.
2.
3.
4.
5.
на используемые в космосе материалы;
на условия безопасности эксплуатации;
условия интеграции с РН;
форматы данных (борт, борт-Земля…);
частоты и т.д.;
В) коммерческие и международные стандарты:
1. ISO 9001 на качество;
2. AMS 5570 (CRES Tubing);
Г) внутренние стандарты компаний;
Д) рекомендации, выработанные при проектировании;
Содержание составляемой спецификации:
1.
2.
3.
4.
5.
6.
7.
физическим интерфейсам систем;
ТТХ (perfomance requirements);
требования к узлам, материалам, процессам;
требования к качеству;
требования к испытаниям;
требования к перевозке и упаковке;
«матрица совместимостей» (compliance matrix).