Персонал в 1992-1998-х годах

К концу 1991 года полным ходом шла работа над четырьмя клиентскими систе­мами. Значительное число созданных повторно используемых модулей уже на­шли применение в двух первоначальных системах. Ядро линейки продуктов де­монстрировало быстрое развитие, и теперь практика компоновки новых систем из существующих модулей была вполне распространена. По мере сокращения потребности в труде проектировщиков они переводились на другие выполняв­шиеся компанией проекты. С другой стороны, прирост клиентских проектов, про­рабатывавшихся одновременно, привел к повышению потребности в сборщиках — на каждую клиентскую систему их стабильно привлекалось от трех до пяти. Бла­годаря тому, что в рассматриваемый период компания стала получать больше подрядов, численность руководящего состава не сократилась.

В период с 1994 по 1998 год профиль кадрового обеспечения претерпел зна­чительные изменения. Благодаря развитию линейки продуктов и навыков ее при­менения к работе над двумя последними в этот период клиентскими системами компании удалось привлечь меньше, чем обычно, проектировщиков, разработчи­ков и сборщиков. Потребность в проектировщиках неизменно продолжала па­дать, что приводило к переходу этих специалистов из одного подразделения в дру­гое. В наибольшей степени эта тенденция затронула сборщиков — что характерно, бюджеты CelsiusTech предусматривали участие в разработке каждой системы не более одного-двух специалистов этой направленности. Постоянные попытки оп­тимизировать композицию систем — в частности, проект «базовая конфигурация SS2000» — были направлены на дальнейшее снижение уровня кадрового обеспе­чения разработки. С другой стороны, учитывая неизменное распространение прак­тики одновременного проведения нескольких клиентских проектов, которых, кста­ти, становилось все больше, уровень руководящего состава, как и раньше, оставался стабильным.

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

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

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

15.2. Требования и атрибуты качества

Для того чтобы из репозитария компании можно было вывести новые продукты, их структура должна быть ориентирована на совместное использование модулей. На материале главы 14 вы убедились в том, что такая структура предполагает наличие стандартного набора модулей и соглашений по поводу обязанностей, поведения, производительности, интерфейсов, локальности функционирования, механизмов передачи данных и координации, а также других свойств каждого из этих модулей. Эта структура, распространяющаяся на всех членов семейства, со­держащиеся в ней модули, а также их свойства, общие для всей линейки, состав­ляют архитектуру линейки продуктов (product line architecture).

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

· Производительность. Системы командования и управления должны в ре­альном времени реагировать на постоянно поступающие входные показа­ния датчиков и контролировать вооружения в предельно сжатые строки.

· Модифицируемость. Архитектура должна демонстрировать робастность во всем, что касается вычислительных платформ, операционных систем, вве­дения или замены систем считывания и управления вооружением, требова­ний к человеко-машинным интерфейсам, протоколов передачи данных и многого другого.

· Безопасность, надежность и готовность. Система должна находиться в со­стоянии постоянной готовности, предоставлять системам управления воо­ружениям правильные данные и команды и открывать огонь только в опре­деленных условиях.

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

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