Внутренние стимулы
♦ Все новые функции, которые вводятся в продукт, следует проверять на предмет соответствия области действия линейки. В случае соответствия их можно конструировать на основе базовых средств. В противном случае необходимо принять одно из двух решений: 1) об отделении модернизированного продукта от существующей линейки продуктов и его самостоятельном развитии; 2) о расширении фонда базовых средств в расчете на новый продукт. Если новая функциональность имеет серьезные шансы быть задействованной в последующих продуктах, есть смысл обновить линейку продуктов; следует, впрочем, иметь в виду, что такое решение сопряжено с необходимостью выделения временных ресурсов на обновление базовых средств. ♦ При внесении в линейку продуктов изменений возникает необходимость в замене устаревших продуктов новыми, построенными на основе новейшей версии фонда базовых средств; это не является непреодолимым препятствием, и отказываться от линейки продуктов в таких случаях не стоит. На поддержание совместимости продуктов с линейкой требуются дополнительные временные и трудовые ресурсы, однако эти вложения оправдываются за счет сокращения продолжительности последующих операций по модернизации. Для того чтобы отражать в новых продуктах свежие функции, введенные в линейку, их необходимо привести в соответствие друг другу.
Организационная структура Относительно фонда базовых средств, на котором основываются продукты — участники линейки, но который в то же время развивается по собственному сценарию, руководство компании должно принять ряд решений, касающихся управления самим фондом и разработкой продуктов. Изучив организационные модели различных линеек продуктов, Ян Бош (Jan Bosch) в своей работе [Bosch 00b] предложил делить их на четыре типа. ♦ Выделение отдела разработки. Все процессы, связанные с разработкой программного обеспечения, сосредоточиваются в одном подразделении. Предполагается, что все числящиеся в нем сотрудники обладают недюжинным опытом работы с линейками продуктов и, в зависимости от ситуации, могут переключаться от инженерии предметной области к прикладной инженерии. Такая модель характерна для небольших компаний, а также организации, предоставляющих консультационные услуги. Несмотря на удобство и краткость каналов взаимодействия, методика концентрации всех функций в рамках одного подразделения отличается рядом серьезных недостатков. По мнению Боша, действенным этот подход оказывается лишь в тех случаях, когда численность подразделения не превышает 30 человек (с нашей точки зрения, это довольно большая цифра). Таким образом, в мелких компаниях, занимающихся разработкой ограниченных по масштабу линеек продуктов, он весьма полезен. ♦ Выделение нескольких отделов разработки. Каждый из них ответствен за то или иное подмножество систем в рамках семейства продуктов, выделяемое по признаку общности. Совместно используемые средства создаются теми подразделениями, которые испытывают потребность в их наличии, после чего предоставляются в пользование всем коллегам; не исключается также сотрудничество отделов для разработки новых средств. У этой модели несколько разновидностей, отражающих различные степени гибкости отделов по части разработки (или модификации) совместно используемых средств. В отсутствие каких-либо ограничений продукты обычно расходятся индивидуальными путями, ниспровергая таким образом саму методику линеек продуктов. Ответственность за конкретные средства распределяется между отделами, которые должны поддерживать собственные средства в согласии с линейкой продуктов в целом. Остальные отделы берут на себя обязательства по использованию этих средств. По оценкам Боша, рассматриваемая модель подходит для компаний, в которых штат насчитывает от 30 до 100 сотрудников. К сожалению, во многих подобных случаях отделы концентрируются исключительно на выделенных им продуктах, в результате чего задачи линейки отходят на второй план. ♦ Деятельность в рамках отдела инженерии предметных областей. За разработку и сопровождение фонда базовых средств в данном случае отвечает специальное подразделение компании; результатами его работы при конструировании продуктов пользуются все остальные отделы. По мнению Боша, когда численность штата компании переваливает за 100 сотрудников, каналы взаимодействия между подразделениями теряют практичность и, таким образом, делают очевидной потребность во введении магистрального канала к фонду совместно используемых средств. Центральную роль в рамках этой модели играет четкий и ясный процесс, направленный, с одной стороны, на координацию обмена информацией, а с другой — на принуждение всех участников к первоочередному соблюдению интересов линейки. ♦ Иерархически выстроенные отделы инженерии предметных областей. Очень крупные и/или очень сложные линейки продуктов имеет смысл структурировать согласно некоей иерархии. Если, к примеру, некоторые (входящие в линейку продуктов) подгруппы схожи друг с другом в большей степени, чем с остальными участниками линейки продуктов, имеет смысл орг анизовать два подразделения: одно будет заниматься инженерией предметной области для совместно используемых средств линейки в целом, а другое — средствами, применяемыми в рамках специализированной подгруппы. Несмотря на то что в этом примере мы показали лишь два иерархических уровня, по большому счету, возможности расширения — если, к примеру, в рамках подгрупп выделяются специализированные подгруппы более низкого уровня и т. д. — ничем не ограничены. Иерархически организованные подразделения по предметным областям применимы лишь к самым крупным линейкам продуктов, разрабатываемым в больших компаниях. Их главный недостаток — это тенденция к разрастанию, при котором оперативность реагирования компании на вновь возникающие потребности снижается. 14.6. Заключение Итак, в настоящей главе мы рассмотрели архитектурную парадигму разработки линеек программных продуктов. По мере того как все больше компаний убеждаются в том, что по части стоимости, времени и качества эта методика предоставляет самые что ни на есть солидные выгоды, она приобретает значительную популярность. Впрочем, как и любая другая новая технология, методика линеек продуктов готовит для новичков некоторые сюрпризы. С точки зрения архитектуры основной упор делается на выявление общности и вариативности, а также управление ими; в то же время учитываются и некоторые нетехнические проблемы — механизм внедрения модели в компании, ее структура и способ поддержания внешних интерфейсов. 14.7. Дополнительная литература В работе [Anastasopoulos 00] приводится вполне добротный перечень методик реализации изменчивости. Аналогичные перечни есть в публикациях [Jacobson 97] и [Svahnberg 00]. Комплексное исследование линеек программных продуктов проведено в издании [Clements 02а]. Анализ практических областей линеек продуктов в нем перемежается с конкретными примерами. Организационные модели рассматриваются в работе [Bosch 00b]. Сведения по процессу FAST мы почерпнули из издания [Weiss 00], а по компании Philips — из [America 00]. Наконец, материалы для примера компании GM Powertrain взяты из труда [Bass 00]. 14.8. Дискуссионный вопрос Предположим, что, имея в своем распоряжении обширный набор общих средств (включая архитектуру), некая компания конструирует две схожие системы. Очевидно, что они составляют линейку продуктов. А было бы правомерно признать их линейкой, если бы общность исчерпывалась архитектурой? Допустим, что у них один общий элемент; что общность распространяется на операционную систему и оперативные библиотеки языка программирования; что за их разработку отвечает одна и та же группа разработчиков. Можно ли в трех указанных случаях включать эти продукты в одну линейку? Глава 15 CelsiusTech. Конкретный пример разработки линейки продуктов (в соавторстве с Лайзой Браунсуорд) Лайза Браунсуорд (Lisa Brownswortl) — научный сотрудник Института программной инженерии при Университете Карпеги-Мсллои. Мы неустанно учились, но каждый раз, объединяясь в группы, сталкивались с необходимостью перестройки. Позже, исходя из собственного опыта, я осознал, что на каждую новую ситуацию мы отвечаем реорганизацией; эта система, создавая иллюзию прогресса, на деле приводит лишь к путанице, несостоятельности и падению духа. Петроний Арбитр [Petronius Arbiter], 210 В настоящей главе мы расскажем о наработках компании CelsiusTech АВ — разработчика систем для шведских ВМС, сумевшего успешно внедрить методику построения линеек сложных, преимущественно программных, продуктов. Названная Ship System 2000 (SS2000), линейка продуктов этой компании включает в себя судовые системы для военных ведомств государств Скандинавии, Ближнего Востока и южнотихоокеанского региона. Данный конкретный пример иллюстрирует архитектурно-экономический цикл (Architecture Business Cycle, ABC) в целом и выход CelsiusTech с методикой построения линеек продуктов на новые коммерческие рубежи в частности. Роли лиц, заинтересованных в прохождении архитектурно-экономического цикла, в контексте опыта Celsius изображены на рис. 15.1. Рис. 15.1. Архитектурно-экономический цикл в CelsiusTech
15.1. Связь с архитектурноэкономическим циклом Компания CelsiusTech уже довольно давно приобрела статус ведущего шведского поставщика систем командования и управления. Она входит в крупнейшую в Швеции (и одну из крупнейших в Европе) оборонно-промышленную группу, в которой, помимо нее, участвуют Bofors, Kuckums, FFV Aerotech и Telub. В период разработки рассматриваемых в настоящей главе систем в CelsiusTech входили три компании: CelsiusTech Systems (сложные программные системы), CelsiusTech Electronics (электронная техника для оборонной отрасли) и CelsiusTech IT (информационно-технологические системы). Их штат тогда насчитывал около 2000 специалистов, а годовой оборот — 300 миллионов американских долларов. Штаб-квартира компании находится в предместье Стокгольма, а дочерние компании — в Сингапуре, Новой Зеландии и Австралии. Рис. 15.2. Этапы развития компании CelsiusTech Systems Мы намерены рассмотреть лишь подразделение CclsiusTech Systems (для краткости будем называть его CelsiusTech), занимающееся изготовлением систем командования, управления и связи, систем управления огнем, систем радиолокационного подавления для флота, сухопутных и воздушных войск. Начиная с 1985 года эта организация сменила несколько владельцев и имен (рис. 15.2). Первоначально называвшаяся Philips Elektronikindustrier АВ, в 1989 году она была куплена компанией Bofots Electronics ЛВ, а в 1991 реорганизована под новым именем NobelTech АВ. Наконец, в 1993 году ее приобрела компания CelsiusTech. В то время как все перечисленные сделки сопровождались сменой топ-менеджеров, большая часть управленцев нижнего и среднего звена, равно как и технические специалисты, оставались на своих местах, демонстрируя тем самым известную преемственность и стабильность. Ship System 2000: линейка продуктов для ВМС Линейка продуктов CelsiusTech для ВМС под названием Ship System 2000 (внутреннее название — Мk3) представляет собой интегрированную систему, объединяющую все устанавливаемые на военных судах системы вооружений, командования, управления и связи. Ее стандартные конфигурации состоят из 1-1,5 миллиона строк кода на языке Ada, распределяемых в локальной сети (local area network, LAN) с 30-70 микропроцессорами. В рамках одной линейки продуктов сконструированы (и до сих пор конструируются) многочисленные системы для подводного и надводного флота ВМС. Среди них — системы вооружений, командования, управления и связи для следующих боевых единиц: ♦ шведские корветы береговой обороны (KKV) класса Goteborg (380 тонн); ♦ датские многоцелевые патрульные суда SF300 (300 тонн); ♦ финские ракетные катера (FAC) класса Rauma (200 тонн); ♦ австралийские/новозеландские фрегаты ANZAC (3225 тонн); ♦ датские океанские патрульные суда класса Thetis (2700 тонн); ♦ шведские подводные лодки класса Gotland А19 (1330 тонн); ♦ пакистанские фрегаты класса Туре 21; ♦ оманские патрульные суда; ♦ датские корветы класса Niels Juel. Подразделению военно-морских систем удалось продать более 50 своих продуктов в 7 странах. На рис. 15.3 изображен многоцелевой корвет королевских ВМС Швеции класса Goteborg, зашедший в стокгольмскую гавань. Над ним возвышается антенна диапазона С/Х обзорной РЛС обзора и индикации цели. Спереди и сзади от этой антенны, поверх надпалубных сооружений, расположены два разработанных в компании CelsiusTech, полностью укомплектованных устройства, состоящих из РЛС и оптико-электронного блока управления огнем. Рис. 15.3. Шведский многоцелевой корвет класса GOteborg с системой управления и контроля от CelsiusTech1
1 Фотография заимствована из фондов Studio FJK; перепечатывается с разрешения правообладателя. Системы, конструируемые в рамках рассматриваемой линейки продуктов, сильно различаются по размеру, функциям и вооружению. В частности, в зависимости от страны-заказчика операторские дисплеи строятся на основе разных аппаратных средств и приспосабливаются к выводу информации на разных языках. Не меньше различий между датчиками, системами вооружений и их программными интерфейсами. Требования, предъявляемые к подводным лодкам, отличаются от требований, предъявляемых к надводным судам. Среди платформ, применяемых в данной линейке, — 68020, 68040, RS/6000 и DEC Alpha. Что касается операционных систем, то здесь возможны варианты в диапазоне от OS2000 (это собственная разработка CelsiusTech) до IBM AIX, POSIX, Digital Ultrix и некоторых других. Поддержка столь широкого круга систем обеспечивается в линейке продуктов SS2000 посредством единой архитектуры, единого фонда базовых средств и в рамках одной организации. Экономика линеек продуктов: обзор результатов, достигнутых CelsiusTech В этом разделе мы обсудим результаты, достигнутые компанией CelsiusTech но части конструирования преимущественно программных систем. Сокращение графика На рис. 15.4 приводится состояние и графики разработки позднейших систем из линейки продуктов CelsiusTech. Контракты на разработку систем для судов А и В были подписаны примерно в одно и то же время, что и подвигло CelsiusTech на переход к линейке продуктов. Основой для ее построения послужила система А. Разработка проекта А продлилась почти десять лет — несмотря даже на то, что уже к концу 1989 года на судне были установлены первые функциональные версии системы. Система В — второй из двух оригинальных продуктов, демонстрирующий заметное сходство с предыдущей системой Мк2.5, существовавшей вне линейки продуктов, — разрабатывалась около семи лет. Работа над ней велась параллельно с разработкой системы А, что поспособствовало утверждению новой линейки продуктов. Взятые по отдельности, эти системы не отличались особой продуктивностью, но, несмотря на это обстоятельство, CelsiusTech удалось Рис. 15.4. Графики по продуктам
завершить обе (имеете с линейкой продуктов) силами специалистом, которых обычно хватает на один проект. Когда на горизонте появились системы С и D, значительная часть линейки уже существовала; отсюда — заметное сокращение сроков завершения их разработки. Системы Е и F, полностью опиравшиеся на средства линейки продуктов, демонстрируют еще более поразительное ускорение. По словам представителей CelsiusTech, три новейшие системы уверенно укладывались в график.
|