Статьи

Томас Поул

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

Содержание

Введение
Поучительная история об управлении активами разработки ПО
Почему так произошло?
Решение проблемы
Заключение
Вопросы для критического осмысления
Дополнительная литература
Глоссарий

Введение

Пользователи системы управления активами разработки ПО (SEAMS — software-engineering asset-management system) в основном обращают внимание не на то, как выглядят активы или как они устроены. Их прежде всего интересует, какие активы могут решить поставленную задачу, как получить эти активы, как выбрать наилучший вариант для создания решения и как использовать эти активы для решения задачи.

Поучительная история об управлении активами разработки ПО

В начале 1990-х годов я работал в компании Trey Research над системой управления библиотеками для многократного использования (RLMS — reuse library-management system) — частью системы, называемой в наше время SEAMS. Изначально содержимое библиотеки состояло почти из сотни структур данных, которые были профессионально реализованы компанией Trey Research, что составляло основной вид ее деятельности. Разработанный набор общих типов данных и связанных с ними функциональных возможностей имел большой успех как в техническом, так и в финансовом плане. Система RLMS основывалась на этом успехе. Кроме управления этим набором структур она позволяла каждому заказчику, который приобрел данную библиотеку с системой RLMS, управлять многократно используемыми активами, созданными группой разработчиков заказчика.

В ходе исследований, проектирования и создания прототипа системы RLMS и до ее окончательного проектирования тестировщики активно пользовались возможностями самой системы RLMS для каталогизации своих многократно используемых активов, и в это время пользователям было довольно трудно найти компоненты, подходящие для их текущих нужд. Было непросто сопоставить свое ПО многократного использования со спецификациями требований или проектировочными свойствами системы, которую им было поручено применять. Полнотекстовый поиск (как в Интернете) мало что давал, поскольку искомые «слова» в большинстве своем оказывались зарезервированными словами программирования (например, return или cdr), именами переменных с системными префиксами (FGHMain) или комментариями в заголовках шаблонов, повторяющимися в разных файлах. Полнотекстовый поиск одного из этих общих слов или фраз всегда возвращал слишком много результатов, от которых практически не было пользы. Это было заранее очевидно, поэтому в системе RLMS сосредоточились на каталогизации активов наподобие каталогов книг в библиотеке, то есть в виде иерархии. При этом поддерживались и другие способы поиска и просмотра, включая тот же полнотекстовый поиск.

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

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

Почему так произошло?

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

• Задача 1. Нужно каталогизировать активы в соответствии с выполняемым ими действием, а не с тем, каким образом они это делают. Вместо того чтобы описывать активы по внутренней структуре, их следует каталогизировать в соответствии с назначением.
  
• Задача 2. Для составления словаря классификации необходимо знание основ систематизации информации, и средство RLMS должно либо научить пользователя этим навыкам, либо выступить в роли эксперта, направляющего пользователя.
  

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

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

• Хранение данных об активах разработки ПО. Позволяет архивировать данные для хранения; хранить метаданные об использовании и производительности активов, их роли в системе и решаемых задачах; использовать эти метаданные для поддержки поиска активов в контексте решаемых задач.
  
• Возможность пользовательского поиска в наборе активов разработки ПО в соответствии с решаемыми задачами. Позволяет представлять метаданные об активах так, чтобы удобно было видеть сходства и различия между ними, а также легко определять, какие активы наиболее полезны для решения конкретной задачи.
  
• Представление связей между активами, чтобы после нахождения нужного актива можно было легко обнаружить похожие или связанные активы. Позволяет администраторам системы RLMS или SEAMS задавать типы связей, а затем задавать по ним связи между активами.
  

Компании Trey Research предстояло сделать следующее: узнать, как помочь пользователям описать их потребности; сопоставить эти потребности с ресурсами для решения задач (в данном случае — активами для разработки ПО); сопоставить их потребности с имеющимися активами; найти наилучшие из возможных решений; извлечь данные о них; найти соответствующие активы, если таковые существуют; узнать, как использовать эти активы для решения их задач. После этого нужно было создать систему RLMS таким образом, чтобы она могла все это охватывать и представлять, а также функционировать в роли системы классификации с возможностью расширения, которую можно обновлять для представления новых видов решаемых задач, новых способов использования других активов для решения задач и новых типов связей между схожими или связанными активами. Наконец, возможность обновления классификации должна была поддерживаться сочетанием обучения основам систематизации и экспертными указаниями, с помощью которых неспециалисты в области систематизации могли бы составлять и сопровождать эффективные каталоги классификации.

Решение проблемы

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

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

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

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

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

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

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

Заключение

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

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

Наш рецепт прост. Мы применяем знания из библиотечного дела и теории информации. Берем оттуда способность упорядочивать активы, разрабатываем схему для упорядочивания этих активов в соответствии с решаемыми ими задачами и помогаем пользователям сформулировать их потребности на языке этой схемы. Из нашей родной профессии мы добавляем способность охватить все это в цифровой информационной системе: автоматизация потоков работ по вводу данных об активах; каталогизация по решаемым активами задачам; архивация; поиск и доступ; представление дополнительной полезной информации, например об использовании активов; поиск дополнительных потенциально полезных активов.

Вопросы для критического осмысления

• Как разработчики новых систем будут описывать свои потребности в многократно используемых программных активах?
  
• Как специалисты по сопровождению имеющихся систем будут формулировать вопросы о том, как работает система, какими компонентами выполняются те или иные роли и функции в системе?
  
• Как мы будем определять, что входит в наши системы RLMS или SEAMS, а что — не входит? Другими словами, как нам определить зону охвата нашей коллекции активов разработки ПО?
  
• Как лучше всего представить актив, данные о его прошлом использовании и данные об интеграции актива в новую систему?
  
• Как структурировать схему классификации системы RLMS или SEAMS, чтобы облегчить понимание и использование этой системы путем представления сходств и различий между активами?
  
• Как расширить имеющиеся средства (например, инструменты реляционных СУБД или средства автоматизации библиотек), чтобы автоматизировать средства SEAMS?
  

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

Поставщики средств SEAMS:

• Flashline
  
• Logidex
  

Статьи этого автора

• Contextual Classification in the Metadata Object Manager (M.O.M.), протоколы ежегодной встречи Американского общества по информатике и технологиям 1999 г.
  
• Extended Faceted Classification System (EFCS): Representing Software Engineering Domains, Systems, and Components, протоколы конференции по многократному использованию 1995 г.
  
• An Empirical Study of Representation Methods for Reusable Software Components, (совместно с У. Б. Фрейксом [W.B. Frakes]), операции IEEE по проектированию ПО, том 20, выпуск 8 (август 1994 г.).
  

Глоссарий

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

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

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

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

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

Система управления библиотеками для многократного использования (RLMS — reuse library-management system) — ранняя версия системы SEAMS, в которой основное внимание уделялось каталогизации исходного кода для исполняемых активов разработки ПО.

Система управления активами разработки ПО (SEAMS — software-engineering asset-management system) — система для каталогизации, управления (например, контроль внесения изменений и контроль доступа) и обеспечения доступности активов разработки ПО и информации об этих активах.

�
 

Об авторе

Томас Поул (Thomas Pole) уже 25 лет фанатично предан компьютерам: специалист по аппаратному обеспечению ПК, программист, исследователь, преподаватель и даже руководитель проекта. В настоящее время он связан с крупным системным интегратором в области проектов для государственных ведомств США, а также преподает в Университете Джона Хопкинса, в котором много лет назад защитил свою дипломную работу (сейчас он готовит новый курс по сервис-ориентированной архитектуре [SOA] и проектированию ПО на основе компонентных объектов [методология CBSE]).

Эта статья была опубликована на Skyscrapr, интернет-ресурсе корпорации Майкрософт. Дополнительные сведения об архитектуре и архитектурной концепции см. на веб-сайте skyscrapr.net.