Системный подход к управлению высокотехнологичными проектами. 2-е издание, переработанное и дополненное

• Разработчики смартфонов ставили своей целью улучшить технику для телефонных звонков. Однако пользователи стали выбирать смартфоны по опции связи и мультимедиа в мессенджерах и качеству снимков фотокамеры, т.е. по ранее вспомогательным критериям.

• После проектирования системы пожаротушения в Таганском туннеле 3-го транспортного кольца Москвы было проведено ее опробование. Оказалось, что после срабатывания системы огонь успешно ликвидируется, но восстановить движение по туннелю невозможно, так как пену нечем удалять (рис. 9). Видимо, предполагалось, что она будет сливаться в водостоки. Пришлось вносить в систему доработки.

На практике нередко встречаются отклонения от требований. Для дальнейшего продвижения в проекте необходимо указать причины отклонений. Как правило, это следствие отсутствия части информации. В документах встречаются места, оставленные для заполнения в дальнейшем. В документах на английском языке используют пометки типа TBA (to be agreed – необходимо согласовать), TBC (to be complete – необходимо завершить), TBD (to be decided – необходимо принять решение). Однако при «заморозке требований» весь набор пустых ячеек для требований должен быть заполнен. Важно знать при формулировке раздела требований в англоязычных контрактах, что слово «Compliance» является единственным вариантом подтверждения строгого соответствия исполнителя требованиям контракта.

Рис. 9. Срабатывание системы пожаротушения

Также на этапе разработки требований необходимо определить методы их верификации. С целью безусловного выполнения требований проекта необходимо организовать поэтапную верификацию исполнения требований к системе, начиная с момента появления предварительного облика разрабатываемой системы (на контрольном рубеже с обзором предварительного проекта системы).

Валидация требований часто входит в один из этапов ворот принятия решений. Проверка требования включает четыре типовых вопроса.

•Правильная ли сформулирована проблема?

• Смогли ли указанные требования отразить проблему?

• Верно ли сформулированы эти требования?

• Соответствуют ли требования установленным границам системы и ограничениям?

В процессе валидации требуется проверить, что системные требования полны, непротиворечивы и каждое требование достижимо и проверяемо. Валидацию требований проводят эксперты по конкретным вопросам, организация-разработчик и уполномоченные представители Заказчика.

В результате процесса разработки формируется набор требований к системе, который должен быть выполнен при создании продукта или системы. Он содержится в документах контракта, спецификациях или технических заданиях на выполнение работ. Характеристики этого набора требований будут идентичны вышеописанным характеристикам отдельных требований и удовлетворяют двум условиям. Набор должен быть полным (т.е. не нуждается в дополнительных пунктах требований). Входящие в него требования должны быть согласованными (т.е. не содержат противоречий, дублирований и др). Далее на всех этапах разработки системы выполняется процесс управления требованиями (см. раздел 3.4).

На основании требований системного уровня выполняется функциональный анализ системы, то есть разработка функционального описания системы, которое послужит основой для определения ресурсов, необходимых системе для достижения ее целей. Функцией называют конкретное или дискретное действие (или их серию), необходимое для выполнения системой своей задачи, или действие по техническому обслуживанию, необходимое для восстановления работоспособности системы.

Функциональный анализ включает итеративный процесс разбиения требований от уровня системы до подсистем и вниз по иерархической структуре, насколько это необходимо для определения входных критериев проектирования и ограничений для различных элементов системы. Требования верхнего уровня идентифицируют, разделяют на второй и далее уровни вниз до глубины, необходимой для целей определения элементов системы.

Одной из целей функционального анализа является обеспечение прослеживаемости от требований верхнего уровня системы до требований к рабочему проектированию. Учитывая конкретные требования к оборудованию, можно двигаться «вверх» для обоснования этого требования. Функциональный анализ должен обеспечить механизм прослеживаемости «снизу вверх».

При оценке каждого функционального требования альтернативы могут включать выбор ПКИ, количество различных источников поставок, и элементы разработки, для которых требуется какая-то новая конструкция.

Функциональный анализ, в частности, формирует основу для разработки:

a) электрического и механического проектирования компонентов мониторинга состояния и средств диагностики;

b) моделей надежности;

c) анализа характера, последствий и критичности отказов;

d) анализа технического обслуживания, ориентированного на надежность;

e) анализа ремонтопригодности;

f) анализа человеческого фактора;

g) анализа безопасности и рисков системы;

h) логистического анализа (анализа цепочки поставок).

2.5. Принятие проектных решений

Следующим этапом процесса разработки является синтез системы, в ходе которого конструктор переводит функциональную архитектуру системы в физическую. Процесс сопровождается принятием множества проектных решений, где конструктор должен проявить как творческую сторону деятельности, так и профессиональный прагматизм. Термин сбалансированное решение означает, что проведено обсуждение общих рисков системы, стоимости, технической зрелости и надежности для каждой комбинации подсистем.

Основные принципы проектирования изделий можно свести к краткому перечню.

•Лучше продвигаться по проекту, имея несколько «сомнительных» решений, чем опоздать с решениями в поисках «совершенного» варианта. Лучшее – враг хорошего.

• В проекте надо использовать принцип «сделай это проще», чтобы снизить риски и стоимость и обеспечить легкую реализацию и эксплуатацию.

• Излишние опции в проекте должны быть определены на ранней стадии (и удалены из целей системы), при этом влияние на характеристики продукта, вытекающие из осуществления этих опций, должно быть понятным.

• В проекте обязательны независимые обзоры промежуточных результатов для всестороннего обсуждения вопросов разработки.

Важно принимать во внимание информацию о том, что основные затраты на этапе разработки связаны с передачей в производство образцов и закупками ПКИ, тогда как уровень этих затрат определяется на раннем этапе, при разработке конструкторской документации. Т.е. принятые на ранней стадии решения являются ключевыми и определяют стоимость программы на последующих этапах ЖЦ.

Ниже суммированы некоторые полезные рекомендации, приносившие успешные результаты при проектировании изделий и систем. Каждый читатель может привнести в них свой уровень детализации, создавая базу уникальных шагов для нового проекта:

1) использовать модели для проектирования систем;

2) использовать иерархический дизайн сверху вниз;

3) сначала выполняется работа с высокорисковыми компонентами;

4) конструировать минимум интерфейсов, разделяя их на механические, электрические, программные;

5) применять в альтернативах проекта удовлетворительные конструкции;

6) рекомендуется не проводить оптимизации на ранней стадии работ, пока нет уверенности, что база оптимизации выбрана достаточно обоснованно;

7) свои ошибки нужно находить самим, т.е. определить, что не так в очередном варианте;

8) полезно перечислить функциональные требования в случае использования системы;

9) выделить каждую функцию для только одного компонента;

10) категорически нельзя использовать недокументированные функции;

11) полезно применять быстрое прототипирование (варианты аддитивных технологий);

12) разрабатывать несколько итераций и сразу тестировать результат;

13) создавать библиотеки повторно используемых субъектов;

14) написать глоссарий соответствующих терминов;

15) удобно использовать создание конструктивных резервов (запасы);

16) следует проектировать компоненты с возможностью тестирования;