Затраты 9 страница

Любой клиент Amazon.com может рассчитывать на индивидуальное обслуживание — - в частности, на предложения книг, сходных с теми, которые он купил или просто просмотрел.

Такие возможности Amazon предоставляет исключительно за счет мощнейшей информаци­онно-технологической инфраструктуры и возможностей анализа данных.

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

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

На сегодняшний день Amazon.com, обслуживающий клиентов более чем в 220 странах, претендует на статус крупнейшего сетевого магазина в мире. В его активе — пять междуна­родных веб-сайтов и примерно 20 миллионов зарегистрированных покупателей (немногим меньше, чем население Канады!). Процент повторных сделок достигает 70 % — традицион­ные предприятия розничной торговли могут лишь мечтать о таком показателе. На момент написания этих строк Amazon не удалось закрыть год с положительным балансом, но руко­водство магазина рассчитывает получать прибыль начиная с 2003 года.

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

-RК

13.8. Дополнительная литература

Читателям, желающим поподробнее узнать о концепции гипертекста, мы реко­мендуем ознакомиться с работой [Bush 45] и специализированным выпуском САСМ [САСМ 88].

Информации об истории и развитии Всемирной паутины больше всего в са­мой Всемирной паутине. Среди наших источников — [Berners-Lee 96а], [Gray (http://www.mit.edu/people/mkgray/net)] и [Zakon (http://www.zakon.com/robert/internet/timeline)].

Обширная информация о lib WWW содержится в справочной библиотеке W3C, расположенной по адресу http://www.w3.org/pub/WWW/Library.

Добротное исследование по проблемам сетевой безопасности и криптографии, включая все аспекты защиты во Всемирной паутине, содержится в работе [Stal­lings 99]. Вопросы производительности в системах электронной коммерции хо­рошо освещены в издании [Menasce 00].

Архитектурному стилю, характерному для веб-приложений, посвящена рабо­та [Fielding 96]. Сравнение образцов современных веб-серверов приводится в [Hassan 00]; именно оттуда мы заимствовали (и переработали) схему клиент- серверной архитектуры, показанную на рис. 13.5.

Результаты исследования по употреблению веб-серверов, проведенного в мае 2001 года компанией Netcraft, опубликованы по адресу http://www.netcraft.com/survey /.

13.9. Дискуссионные вопросы

1. Мы обозначили ряд атрибутов качества, реализация которых в WWW сде­лала возможным ее ошеломляющий успех: способность к взаимодействию, переносимость, удаленный доступ, расширяемость и масштабируемость. Какое из них, по вашему мнению, оказало на развитие Паутины решающее влияние? Если бы одним из этих качеств пришлось пожертвовать, смогла бы она стать настолько же успешной? Какие компромиссные решения в ар­хитектуре приложений на основе libWWW приходится принимать вслед­ствие сочетания названных задач по качеству?

2. Производительности не оказалось в списке первоначальных задач по каче­ству, которые следовало реализовать во Всемирной паутине. Для успешной системы это довольно необычно. Как вы считаете, почему успех ее все-таки настиг? Можно ли из этого сделать какие-то выводы относительно будуще­го развития вычислительной техники?

3. Какие образцы и тактики прослеживаются в элементах архитектуры, пока­занных на рис. 13.4, 13.5 и 13.7?

Часть 4

ОТ ОДНОЙ СИСТЕМЫ К МНОЖЕСТВУ

В четвертой части мы продолжаем разговор об архитектурно-экономическом цикле. На протяжении первой, второй и третьей частей мы плавно перемещались от характеристики архитектора к проверке архитектуры. Четвертая часть, посвя­щенная вопросам конструирования на основе архитектуры множества систем, содержит также примеры линеек системных продуктов. Проблема подвергается анализу с позиций: 1) базовой технологии линейки продуктов; 2) отдельной ком­пании-производителя систем управления огнем для военных кораблей; 3) обще­отраслевой архитектуры; 4) компании, разрабатывающей продукты на основе общеотраслевой архитектуры, и 5) организации, которая при проектировании своих систем прибегает к использованию коммерческих компонентов.

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

В главе 15 приводится первый в этой части конкретный пример. Объектом нашего внимания станет шведская компания CelsiusTech, создавшая линейку си­стем управления огнем для военных судов. Помимо собственно архитектуры мы обсудим то, каким образом в результате ориентации на линейку продуктов пре­терпела изменения организационная структура и культура компании.

Впрочем, CelsiusTech практикует создание архитектуры в расчете на произ­водство нескольких продуктов. Существуют также архитектуры, ориентирован­ные на целые отрасли промышленности. К примеру, корпоративная архитектура Java 2/система корпоративных JavaBeans (Java 2 Enterprise Edition/Enterprise JavaBeans, J2EE/EJB) — архитектурная спецификация для информационных веб­-систем — исполняет роль базовой архитектуры продуктов, разрабатываемых раз­ными компаниями. Архитектурные решения, характерные для J2EE/EJB, и воз­можные в ее контексте компромиссы рассматриваются в главе 16.

Inmedius — одна из компаний, обращающихся к архитектуре J2LE/EJB, — спе­циализируется на решениях для квалифицированных рабочих (в частности, для техников по обслуживанию), которые, не имея возможности пользоваться на­стольными компьютерами и лишь изредка добираясь до ноутбуков, плотно рабо­тают с разнообразными мобильными платформами. О том, как Inmedius удалось разработать решение, основанное на беспроводной технологии, переносимых и руч­ных (handheld) компьютерах, рассказывается в главе 17,

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

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

Глава 14

Линейки программных продуктов. Повторное использование архитектурных средств

(в соавторстве с Линдой Нортроп)

Первым на необходимость повсеместного введения практики многократного использования программных компонентов указал Макилрой. Было это в 1969 году. С тех пор сообщество разработчиков ПО беспрерывно бьется над осуществлением этой задачи. Отсюда зако­номерный вопрос: если преимущества повторно исполь­зуемых программных компонентов настолько ошелом­ляющи, почему они еще не шествуют по компьютерным наукам победным маршем?

Грэди Буч [Booch 94]

14.1. Обзор

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

Речь в настоящей главе пойдет о явном, планируемом повторном использовании программной архитектуры (равно как и других активов) в рамках семейства родственных систем. Разработка нескольких сходных систем на основе одной архитектуры (а также элементов, связанных с этой архитектурой) создает для компании значительные преимущества — конкретнее, снижает стоимость конст­руирования и сокращает время выхода на рынок. Именно этим объясняется при­влекательность линейки программных продуктов (software product line), опреде­ляемой как:

Набор преимущественно программных систем с общим контролируемым множе­ством характеристик, которые удовлетворяют конкретные потребности определен­ного сегмента рынка или выполняют определенную задачу и разрабатываются п уста­новленном порядке на основе общего набора базовых средств. [Clements 02b, 5]

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

После успешного запуска линейки продуктов все повторно используемые сред­ства — те, которые можно применить в нескольких системах и которые дешевле сохранить, чем разработать заново, — заносятся в фонд базовых средств (core asset base). В идеале, в базовых средствах следует предусматривать изменяемые пара­метры — точки, в которых возможно быстрое запланированное приспособление. Конструирование систем в рамках успешной линейки продуктов сводится к об­ращению к нужным средствам, их приспособлению согласно потребностям теку­щей системы и, наконец, ее сборке. Если даже для отдельных продуктов линейки и потребуется разработка дополнительного программного обеспечения, его удель­ный вес вряд ли превысит 20 %. Интеграция и тестирование в таком случае ста­новятся основными операциями, вытесняя с этой позиции проектирование и ко­дирование.

Линейки продуктов в промышленном производстве не есть нововведение. Многие историки утверждают, что концепция эта появилась в самом начале XIX века, когда Эли Уитни (Eli Whitney) начал собирать винтовки из взаимозаменяемых частей; впрочем, есть и более ранние примеры. Сегодня линейки продуктов есть в компаниях Boeing, Ford, Dell и даже McDonald’s. Каждый из этих производите­лей извлекает из общности свои выгоды. К примеру, модели Boeing 757 и 767 разрабатывались одновременно, и, несмотря на то, что эти два воздушных судна сильно отличаются друг от друга, их узлы совпадают примерно на 60 %.

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

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

♦ Благодаря методике линеек продуктов Nokia производит от 25 до 30 моде­лей сотовых телефонов в год (хотя раньше за аналогичный период удава­лось создать всего 4 модели).

♦ Компании Cummins, Inc. удалось сократить сроки производства программ­ного обеспечения для дизельных двигателей с года до недели.

♦ Со своим семейством пейджеров Motorola добилась 400-ироцентного при­роста продуктивности.

♦ По сведениям компании Hewlett-Packard, сроки выхода на рынок в рамках ее семейства печатных систем сократились в семь раз, а продуктивность увеличилась в шесть раз.

♦ На разработку первого продукта в рамках заказанного Национальным уи- раапением воздушно-космической разведки США семейства наземных стан­ций системы спутниковой связи потребовалось всего 10 % от запланиро­ванного числа разработчиков, а количество дефектов снизилось на 90 %.

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

14.2. За счет чего работают линейки программных продуктов?

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

♦ Требования. Требования по большей части достаются в наследство от пре­дыдущих систем, а потому допускают повторное использование. И тем не менее необходимость в проведении анализа требований остается.

♦ Архитектурное проектирование. На разработку архитектуры программной системы компании вынуждены направлять своих лучших сотрудников, которые прикладывают к достижению этой цели серьезные усилия. Как вы уже знаете, сформулированные для системы задачи по атрибутам качества — производительности, надежности, модифицируемости и т. д. – к мо­менту завершения работы над архитектурой и основном решаются или, напротив, отклоняются. Ошибки в архитектуре приводят к печальным для системы последствиям. Если же речь идет о новом продукте в рамках ли­нейки, этот важнейший этап проектирования можно пропустить за счет введения готового решения.

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

♦ Моделирование и анализ. Модели производительности, анализ возможно­сти планирования, проблемы распределенных систем (например, испыта­ния на предмет взаимоблокировок), распределение процессов между про­цессорами, схемы отказоустойчивости, политики сетевой нагрузки — все эти элементы переходят от одного продукта к другому. По сведениям ком­ИИ CelsiusTech (см. главу 15), ей почти полностью удалось устранить одну из основных проблем, характерных для распределенных систем ре­ального времени, разработкой которых она занимается. Создавая в рам­ках линейки очередной продукт, ее сотрудники уверены, что все проблемы с соблюдением временных требований уже решены, а ошибки, связанные с распределенной обработкой данных — синхронизацией, загрузкой сети и взаимоблокировкой, — устранены.

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

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

♦ Процессы, методы и инструменты. Процедуры и средства управления конфигурациями, планы документирования и процессы утверждения, ин­струментальная среда, процедуры генерации и распределения системы, стан­дарты кодирования и множество других повседневных инженерных операций

♦ вспомогательного характера — все они переносятся из одного продукта и дру­гой. В наличии имеется и процесс программной разработки и целом.

♦ Специалисты. Общность практической деятельности позволяет без труда перебрасывать сотрудников из одного проекта в другой, согласно текущей ситуации. Знания, которыми обладают специалисты, применимы в масш­табах всей линейки.

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

♦ Устранение дефектов. Линейки продуктов способствуют повышению каче­ства — в каждой последующей системе учитывается опыт устранения де­фектов у ее предшественников. С каждой новой реализацией разработчик и клиенты обретают дополнительную степень уверенности в успехе. Чем сложнее система, тем выгоднее решать вечно досаждающие проблемы про­изводительности, распределения и надежности в масштабе целого семейства.

Линейки программных продуктов основываются на повторном использовании. В то же время, как видно из эпиграфа к настоящей главе, попытки внедрить повторное использование в программной инженерии предпринимаются уже мно­го лет, и успех этого предприятия пока что под вопросом — ожидания почти все­гда оказываются радужнее реальных результатов. Причина неудач отчасти кроет­ся в том, что до последнего времени технология повторного использования распространялась под лозунгом «сконструируй, и все будет!». Любая библиотека многократного применения состоит из элементов предыдущих проектов; от раз­работчиков, прежде чем переходить к кодированию новых элементов, требуется ознакомиться с ее содержанием. У этой схемы действий слишком много недо­статков. Если библиотека невелика, разработчик, однажды не обнаружив нужно­го элемента, потеряет всякое желание продолжать поиски. Если же она слишком обширна, провести поиск будет труднее. Если искомые элементы невелики, их проще переписать, чем найти в библиотеке и модифицировать. Если они круп­ные, подробно разобраться в их назначении очень сложно, а вероятность того, что они в точности подойдут для нового приложения, крайне невелика. Проис­хождение элементов, хранящихся в библиотеках повторного использования, как правило, в лучшем случае, неочевидна. Разработчик, таким образом, не может быть полностью уверен в назначении и надежности элемента, а кроме того, он не знает условий, в которых проводилось его тестирование. В то же время точное соответствие между атрибутами качества, требуемыми в новом приложении, с од­ной стороны, и реализуемыми элементами библиотеки — с другой, практически никогда не встречается.

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

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

14.3. Определение области действия

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

Рис. 14.1. Пространство всех возможных систем подразделяется на несколько участков: внутри области действия (белая), вне области действия (в крапинку) и предполагающие дифференцированное рассмотрение (черная) (Приводится по изданию [Clements 02b] (адаптированная версия).

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

Наличие разграниченной области действия во многом определяет дальней­шую судьбу линейки продуктов. Слишком узкая область (предполагающая из­менчивость лишь в нескольких характеристиках) может не оправдать вложенных средств, поскольку вывести из нее достаточное количество продуктов не удастся. Не в меру широкое определение области (когда продукты различаются не только по характеристикам, но и по видам), вероятнее всего, приведет к высоким затра­там на разработку отдельных продуктов на основе базовых средств, а потому достичь серьезной прибыли будет сложно. Уточнить область действия можно на этапе первоначального учреждения линейки продуктов, а также, исходя из стра­тегии принятия линейки продуктов (см. раздел «Стратегии принятия»), в любой последующий момент.

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

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

Линейки продуктов с узкой областью действия позволяют конструировать специализированные инструменты для специфицирования новых продуктов.

♦ FAST — процесс, поддерживающий построение линеек продуктов путем разработки предметно-ориентированных языков и соответствующих ком­пиляторов. Компилятор при этом входит в фонд базовых средств. При фиксации параметров изменчивости продукта (средствами предметно-ори­ентированного языка) в этот фонд также вносится оперативная библиоте­ка кода, сгенерированная посредством компилятора.

♦ GM Powertrain, собирая продукты из базовых средств линейки, основыва­ется на контрактах, хранящихся в базе данных. Каждый элемент снабжает­ся четко определенными интерфейсами и возможными изменяемыми пара­метрами. Проводя в базе данных поиск желаемых характеристик, этот инструмент производит сборку продукта.

Линейки продуктов с широкой областью действия, как правило, разрабатыва­ются по подобию каркасов или коллекций служб. Нижеследующие примеры — тому подтверждение.

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

♦ Система Luther (см. главу 17) представляет собой линейку продуктов, скон­струированную поверх J2EE (каркас). В ходе разработки каждого продукта конструируется пользовательский интерфейс и реализуются вспомогатель­ные прикладные модули.

НЕ ВСЕ ТАК ПРОСТО

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

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

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

К неудаче при попытке внедрения линейки продуктов способны привести следующие факторы:

♦ отсутствие явно выраженного лидера с достаточными управленческими и контрольными полномочиями;

♦ неспособность ответственных лиц постоянно и последовательно оказывать разработчи­кам поддержку;

♦ нежелание менеджеров среднего звена отказаться от единоличного контроля над проек­тами;

♦ нечеткое формулирование коммерческих задач, обусловливающих внедрение методики линеек продуктов;

♦ отказ от реализации методики при появлении первых же трудностей;

♦ недостаточно глубокое ознакомление персонала с методикой, неспособность должным образом объяснить или оправдать вносимые изменения.

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

Джо Гэймер (Joe Gahimer) из компании Cummins, Inc. (производителя крайне успешной линейки программных продуктов, рассматриваемой в работе [Clements 02b]) рассказывает о двух задействованных в продуктах компании элементах, владельцы которых были уверены в их неповторимости. По их мнению, схожесть регулятора скорости и регулятора гребного вала сводилась лишь к тому, что оба контролируют скорость. Tщательно зафиксировав дета­ли обоих приложений, участники группы базовых средств в конце концов выяснили, что эле­менты эти не только схожи, но и функционально идентичны — разница лишь в значениях кон­стант.

Дата добавления: 2015-04-25