Лекция 14. Принципы и приемы оперирования требованиями (продолжение)

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

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

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

Прием 8. Использование метафор

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

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

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

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

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

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

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

* В буквальном переводе с греческого «метафора» (11ЕШфора} означает «перенос», что примени­тельно к программированию следует трактовать как перенос на разрабатываемую операцион­ную среду свойств автоматизируемой деятельности

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

• Единый уровень абстракции в представлении метафоры. Этот принцип расшифровывается как требование представлять все элемен­ты метафоры на одном абстрактном уровне. Нельзя выделять и частично детализировать какой-то один аспект деятельности- прототипа только по той причине, что его легко реализовать, ос­тавив в стороне другие аспекты. Если так поступать, опять-таки возникает дискомфорт из-за напрасных ожиданий. Скорее всего, в этой ситуации не продуман уровень допустимой детализации представления.

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

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

Привычность и естественность метафоры. Она всегда должна быть узнаваема тем, для кого предлагается то или иное средство. Тогда становятся излишними вопросы, зачем нужно это средство, — ему всегда должно быть место среди атрибутов деятельности-прототипа. Понятно, что привычность и естественность — качества субъективные, они всегда относительны, и выяснение их в конкретной ситу­ации может быть затруднительным. Тем не менее, если оценить за­траты на переучивание пользователей, станет понятно, что наруше­ние привычности и естественности обходится слишком дорого. • Учет психологических и эргономических особенностей. Это не от­дельный принцип, а комплекс рекомендаций, которые в большей мере, чем все остальное, относятся к интерфейсу создаваемой сис­темы. Специальный разбор интерфейсных рекомендаций можно найти в работе [21]. В рамках тематики обсуждения укажем лишь на так называемый эффект первого впечатления, который имеет серьезные последствия для всех аспектов проекта. Речь идет о спо­собности помнить первые ощущения от соприкосновения с чем-либо новым и в течение заметного времени переносить эти ощуще­ния на последующие контакты. Применительно к метафорам это означает необходимость тщательной заботы об их выборе в самом начале проекта и реализации в первом релизе системы*. Применение метафор имеет свои следствия на всех этапах разработ­ки проекта (итерации). Наиболее существенно оно влияет на работы, свя­занные с архитектурой и интерфейсом, а также на составление докумен­тации (всех видов, запланированных в проекте). Обсуждаемый прием наиболее интенсивно применяется в ходе аналитических работ, когда ре­шаются проблемы выбора пути развития проекта в целом и определяется задача текущей итерации. Корректировка метафор — одна из задач этапов оценки. Таким образом, метафоричность построения используется сов­местно с приемами определения системы и детализированного определе­ния системы (см. предыдущую лекцию).

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

Прием 9. Моделирование требований

Моделирование — прием, применимый во многих случаях познава­тельной и конструкторской деятельности. Есть много случаев и в про­граммистской проектной деятельности, которые естественно трактовать как применение моделирования. Ниже рассматривается лишь один из аспектов

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

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

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

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

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

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

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

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

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

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

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

Конспективно только что рассмотренные процессы можно пред­ставить в виде схемы, изображенной на рис. 14.1. Дополнительного ком­ментария на этой схеме требует лишь стрелка, соединяющая блок моде­лей уровня анализа с блоками программных и документных представле­ний. Дело в том, что в любой программной разработке необходимо до­казательство того, что система реализует именно то представление предметной области, которое фиксировано согласованными с инициа­торами работ аналитическими моделями. Процесс перехода к про­граммным и документным представлениям должен верифицироваться. Нужно доказать не только то, что система работает, но и то, что ее пове­дение соответствует аналитическим моделям и не опирается на сведения о реализации. Другая сторона этого положения связана с документными представлениями: разработчики обязаны описать систему так, чтобы описание было понятным пользователям, т.е. опять-таки без привлече­ния реализационных сведений. Может случиться, что некоторые реали­зационные концепции окажутся согласованными с пользовательским представлением о системе. Они способны стать основой для расшире­ния аналитических моделей (например, для унификации описаний по­хожих фрагментов системы). Но в таком случае эти концепции должны быть представлены достаточно абстрактно, чтобы основой пользова­тельского представления стали не особенности реализации, а понятные на уровне аналитических моделей положения, пусть даже внешние по отношению к этим моделям. Для такой адаптации полезно воспользо­ваться метафорическими построениями (см. прием 8).

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

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

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

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

Несколько слов о нотации, применяемой при построении модель­ных представлений требований. В принципе в проекте можно использо­вать любые формы таких представлений, если они дают возможность обеспечивать взаимопонимание и однозначное выражение требований. И для локальных проектов, сведения о которых не распространяются далее коллектива разработчиков, такое положение вполне оправданно — нет необходимости осваивать что-то новое, когда старое всех устраивает. Од­нако ограниченность такого пути очевидна. Он препятствует использова­нию чужих разработок, не следующих принятым для данного проекта со­глашениям, затрудняет последующее распространение рабочих продук­тов проекта и их переиспользование в последующих проектах, выходящих за рамки данного коллектива. Затрудняется обучение привлекаемого пер­сонала. Предпочтительнее задействовать стандартные общепринятые представления требований и отработанные методы их трансформации, которые поддерживаются инструментально в рамках интегрированных средств поддержки разработки программного обеспечения CASE-систем (см., например, [50]).

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

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

Прием 10. Управление изменениями требований

Этот прием относится к задачам оперирования новыми требования­ми в контексте уже существующей системы требований к проекту.

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

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

Существенные аргументы в пользу принятия или отклонения требо­вания появляются при проверке, не нарушается ли при расширении це­лостность системы:

• дополнительные и ранее выделенные субъекты автоматизируемой деятельности совместимы;

• прежний и новый наборы действий каждого субъекта не противо­речат друг другу;

• при расширении действия каждого субъекта не перестают соответ­ствовать ранее принятым соглашениям о системе.

При отказе от ранее принятых требований проверяется, не приводит ли связанное с этим удаление субъектов и действий к зависанию ссылок.

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

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

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

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

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

История изменения требований используется следующим образом:

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

• для отслеживания аналогичных ситуаций, чтобы текущее планиро­вание опиралось на полученный ранее опыт;

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

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

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

• протоколирование появления данных: когда, в связи с чем возник хранимый информационный объект, кто (что) является инициато­ром его появления (регистрация появления и трансформации представлений проектных сведений: требований, связей, рабочих продуктов);

• обратимость изменения данных, т.е. сохранение возможности вос­становления любого предшествующего состояния баз данных;

• фиксация времени каждой модификации данных, согласованная для всех баз (для откатов изменений, для просмотра истории и др.).

На рис. 14.2 приведен условный пример фрагмента протокола опе­рирования с требованием ТРО, поступившим от Иванова (авторство ука­зано в правой графе протокола) 12.12.2003. Все записи пронумерованы и справа от номера указана дата — 13.12.2003 к работе с этим требованием приступил Петров. Прежде всего, он трансформирует исходное представление в три типизированных представления ТР1, ТР2 и ТРЗ, из которых второе требование отклоняется (запись 0652 от 14.12.2003). Атеунификации ТР1 и ТРЗ трансформируются в ТР1У и ТРЗУ (записи 0*Ш и 0655 от 14.12.2003). 15.12.2003 Петров строит расширение модели Мисадюсредством ТР1У и ТРЗУ (запись 0681). Анализ показал неприемлем;^ тъ тако­го расширения из-за ТРЗУ. Как следствие, решено отклонить В^ЗУ (за­пись 0682). Это влечет за собой автоматическое отклонение ТЕ» гв графе авторства записи 0683 есть соответствующая пометка и указана причина отклонения — ссылка на предыдущую запись). По этой же при« не авто­матически восстанавливается модель М01. Завершает фрагмент запись, свидетельствующая о том, что Петров строит расширение модели с уче­том лишь ТР1 У.

Данный пример показывает важность решения еще одной задачи, связанной с организацией хранения истории:

• разработка системы типовых запросов, благодаря которым обеспе­чивается выполнение семантически емких часто повторяющихся заданий.

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

• выдать набор всех требований, поступивших в течение опреде­ленного периода от заданного инициатора работ и касающихся интерфейса;

• показать все требования, принятые к некоторому моменту и свя­занные с изменением заданного требования;

• показать ретроспективу изменений представления конкретного требования.

Во всех примерах отличительным является временной параметр за­проса, используемый для получения исторических или текущих сведений.

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

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

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

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

Результатом сохранения истории изменений требований является вся совокупность исторических сведении, которая хранится для данного проекта и используется при организации дальнейших работ.