Эволюционные характеристики процесса разработки

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

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

Предшествующая система влияет на разработку новой системы тремя способами:

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

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

Материализация системы

Шаги разработки новой системы можно рассматривать как постепенную «материализацию» системы - постепенный переход от абстрактной потребности к сборке и монтажу пригодных к работе компонентов, совместно выполняющих сложные функции ради удовлетворения данной потребности. Для иллюстрации этого процесса в табл. 4.1 прослеживается, как система материализуется на различных этапах жизненного цикла проекта. Строки таблицы соответствуют различным уровням детализации - от системы в целом в верхней строке до деталей в нижней. В столбцах представлены последовательные этапы жизненного цикла. На пересечении строк и столбцов показаны основные действия и вклад, который они вносят в воплощение системы. Заштрихованные области обозначают место приложения основных усилий на каждом этапе.

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

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

Глядя на табл. 4.1, важно отметить, что хотя детальный проект системы нельзя считать завершенным до конца разработки, его общие характеристики должны быть наглядно представлены на очень ранних этапах. Это можно объяснить тем, что для выбора конкретной концепции системы необходимо иметь реалистичную оценку затрат на ее разработку и производство, что в свою очередь требует хотя бы общего представления о физической реализации и функциональных возможностях. На самом деле такое общее видение физического воплощения функций системы необходимо уже на самых ранних этапах анализа технической осуществимости. Разумеется, эти ранние визуальные представления будут во многом отличаться от окончательной материализации, но не настолько сильно, чтобы обесценить выводы о ее практичности.

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

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

Участники

В большом проекте участвуют не только десятки или сотни людей, но и различные организации. Конечный пользователь может быть или не быть активным участником проекта, но в любом случае играет важную роль в появлении системы на свет, а в дальнейшем - в ее жизни по мере эксплуатации. Наиболее распространены две ситуации: 1) приобретателем и пользователем системы является государство, а главный подрядчик нанимает субподрядчиков в качестве разработчиков и изготовителей; 2) за приобретение системы отвечает коммерческая компания, она же является разработчиком и изготовителем. 

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

На рис. 4.6 показано типичное распределение участников разработки аэрокосмической системы. Высота колонок отражает относительное число привлеченных инженерных работников. В ячейках представлены типы работников, преобладающих на каждом этапе. По рисунку видно, что состав участников меняется от одного этапа к другому, а системные инженеры обеспечивают преемственность.

На ранних этапах основными участниками являются аналитики и архитекторы (система и ее функционирование/рынок). Работа на этапе определения концепции выполняется, как правило, силами совместной группы, в которой представлены все специалисты, необходимые для выявления и документирования наиболее экономически эффективной концепции системы, отвечающей установленным требованиям.

На этапе эскизного проектирования обычно подключается группа проектировщиков, которая будет вести проект от стадии разработки инженерно-технических решений вплоть до начала производства. Ее возглавляют системные инженеры, которых поддерживают инженеры, занятые проектированием и испытаниями. Их привлекают к разработке необходимых компонентов и подсистем.

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

Требования к системе и документация

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

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

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

Необходимость агрегирования формальных требований и документации, созданных в процессе успешной разработки системы, проще понять, если вспомнить, о чем говорилось в разделе «Участники», и обратиться к рис. 4.6. В процессе разработки принимает участие множество различных групп, причем состав участников меняется при переходе от одного этапа к другому. Поэтому необходимо располагать полным и актуальным описанием, проясняющим, что должна делать система и - в той мере, в какой это уже известно, - как она должна это делать.

Документы с описанием системы не только закладывают основу для последующего этапа разработки системы, но они также определяют, каким образом следует проверять результаты проделанной работы на соответствие требованиям. Эти документы составляют информационную базу, которая пригодится при разработке, с одной стороны, оснастки и инструментов, необходимых для производства, а с другой стороны - приборов и оборудования для контроля и диагностики продукции, изготовляемой на следующем этапе.

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