учебники, программирование, основы, введение в,

 

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

Приемы оперирования требованиями, рассмотренные в предыдущей лекции, предназначены для корректной работы с ними в процессе сбора и трансформаций требований. Они позволяют извлекать максимум информации из пожеланий инициаторов работ. В результате формируется основа проектной деятельности на очередной и последующих итерациях. Приемы, которые обсуждаются ниже, относятся к задачам внутренней проектной деятельности, связанной с требованиями как с материалом для конструирования артефактов проекта. Конечно, это разделение условно, поскольку зависимость работ от требований, с одной стороны, а предназначение артефактов – с другой, не дают возможности прямого разделения этих аспектов. Тем не менее соответствующая расстановка акцентов полезна для правильного восприятия материала.
Прием 8. Использование метафор
Метафоры используются в программных и аппаратных системах повсеместно. Это следствие более общего положения о человеческой деятельности. Всякий раз, когда человек сталкивается с новым видом деятельности, он пытается сопоставить его с тем, что уже известно, что он уже умеет, что делал ранее. В таких попытках очень помогают размышления с привлечением метафор. Это обычный прием познания. При разработке программных систем он может быть поддержан явно и управляемо, а может и оставаться на стихийном уровне восприятия.
Явное и осознанное внедрение метафор уместно при разработке аспектов проекта, непосредственно воспринимаемых пользователем. Но это не единственное поле их применения. Разработчики также вправе апеллировать к своему прежнему опыту при конструировании нового. Зачастую опыт не удается применить напрямую, и тогда на помощь приходят сопоставления, выяснение общностей и метафоры.
Среди критериев предпочтения для постановки ближайшей задачи проекта мы указывали на принцип полноты и функциональной замкнутости предлагаемых средств (см. лекцию 9). При проектировании он проявляется следующим образом. Сначала определяется функционально полный набор реализуемых средств, из него выделяются базовые средства, с помощью которых и при использовании средств, реализованных на предыдущих итерациях, достижима реализационная полнота. На этой основе определяется абстрактное управление, которое может конкретизироваться вариантами интерфейса. Затем проверяется, достигнута ли поддержка всех сторон автоматизируемой деятельности, и если нет, проводится ревизия средств, планируемых для реализации.
Эта процедура становится целенаправленной и получает реальные ориентиры, если разработчики будут следовать заранее продуманной метафоре, которая должна быть воплощена в системе. Для каждого элемента автоматизируемой деятельности должны быть найдены соответствующие образы среди средств системы (функциональная и реализационная полнота) и заданы адекватные формы (интерфейсная полнота).
Выбор метафоры как основы проектируемой системы неоднозначен, но во многом именно он определяет успех или неудачи проекта. Для того, чтобы избежать ошибок, необходимо осознанное следование определенным принципам, которые если и не гарантируют качества метафор, то, по крайней мере будут способствовать ему:

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

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

Прием 9. Моделирование требований
Моделирование — прием, применимый во многих случаях познавательной и конструкторской деятельности. Есть много случаев и в программистской проектной деятельности, которые естественно трактовать как применение моделирования. Ниже рассматривается лишь один из аспектов моделирования, который непосредственно связан с проблемами оперирования требованиями: задача моделирования области определения системы. Ее можно рассматривать как подчиненную приему 6, специально посвященному управлению области применимости. Но целесообразна более широкая позиция, включающая в себя деятельности этапов конструирования архитектуры и далее программирования и внедрения. Именно в этих двух качествах предлагаются средства поддержки моделирования в развитых CASE-системах.
Применение моделирования в начале проекта и при разработке последующих итераций различается существенно, поскольку в первом случае модель создается «с нуля», а во втором — расширяет сложившуюся модель, а потому поле возможных решений сужается. Мы сначала рассмотрим начальное моделирование, а задачу расширения моделей обсудим при сопоставлении.
Совокупность всех требований в их исходном представлении указывает на определенный аспект реального мира, в рамках которого будет разрабатываться система поддержки деятельности пользователей. В этом смысле данная совокупность может рассматриваться как первичная модель прикладной области. Анализ осуществимости, который включает в себя построение унифицированных представлений требований и типизацию требований, сужает обозначенную прикладную область, делает ее более определенной. С его помощью в первичной модели ликвидируются явные противоречия. Этот процесс можно назвать построением уточненной первичной модели прикладной области.
Первичная и уточненная первичная модели принципиально неформальны, что не дает необходимой точности информации о прикладной области. Для исправления этого недостатка строятся первоначальные модели уровня анализа, которые согласуются с явно выделенными потребностями в разработке системы. До тех пор пока трансформация первичных требований в такие модели не выполнена, определение прикладной области не фиксировано однозначно, а значит, о моделировании сферы приложения разрабатываемой системы говорить можно лишь условно. Именно модели уровня анализа рассматриваются в качестве такого определения.
Главной целью моделей уровня анализа является достижение понимания предметной области, для которой строится программная система. В этой связи считается, что эти модели адекватны прикладной области, если они согласованы с инициаторами работ. Способы проведения такого согласования рассматривалась выше. С точки зрения согласования понимается и полнота моделей, которая определяется как отражение в них максимального числа требований, фиксированных (согласованных с инициаторами работ) в унифицированном и типизированном представлениях.
Что касается непротиворечивости, то забота об исключении из рассмотрения тех элементарных составляющих требований, которые приводили бы к взаимоисключающим результатам, лежит на разработчиках. На них возлагается обязанность выявлять противоречия, предлагать решения в таких случаях или, на худой конец, приемлемые компромиссы. Следует осознавать, что в результате принимаемых компромиссов первоначальные противоречивые требования уже не определяют границы области применения системы, и это обстоятельство должно быть отражено в соответствующем описании явно.
Для успешного развития проекта важным дополнительным свойством моделей уровня анализа, а также последующих представлений требований является их расширяемость, т.е. способность включать в себя новые требования в процессе разработки системы. Нужно уметь определять, является ли набор объектов, определенных на уровне анализа, необходимым и достаточным для реализации требуемой функциональности (как правило, это не так). Кроме того, следует позаботиться о том, чтобы действия, связываемые с объектами (прообразы будущих методов этапа конструирования) задавались как абстрактные обобщения, конкретизируемые в точном соответствии с потребностями. На уровне анализа рано говорить об использовании шаблонов проектирования , однако полезно проработать гипотезы о том, как модели будут представлены в реализации.
Построение моделей уровня анализа позволяет ставить вопрос об извлечении конструкторской информации, которая оформляется в виде моделей уровня конструирования. Степень технологичности такого извлечения может служить характеристикой качества как процесса моделирования уровня анализа, так и применяемых для него средств. Понятно, что абсолютной технологии (в ее понимании, представленном выше — см. лекцию 5) достичь не удастся. Нужна лишь поддержка сопряжения уровней: задания образов аналитических объектов и действий в элементах моделей конструирования, отслеживание появления новых объектов и классов с мотивациями этих решений, использование готовых шаблонов, требующих лишь простых и ясных настроек.
Модели уровня конструирования представляют архитектуру системы в той ее части, которая реализуется в текущей итерации. Фиксация сценариев, поддержку которых предполагается обеспечить, сужает определение прикладной области, но только на время итерации. Иными словами, для текущих моделей уровня конструирования критерий общей полноты является не очень существенным, он рассматривается для всего процесса итеративного наращивания, но не для отдельных его элементов. Полнота моделей уровня конструирования в рамках одной итерации — это извлечение всей информации из аналитических моделей, назначенных для реализации, с одной стороны, а с другой — построение архитектуры, допускающей реализацию всех выбранных моделей. Из самой сути итеративного наращивания следует, что свойство расширяемости для моделей уровня конструирования является одним из основных.
По аналогии с аналитическими моделями можно определить качество моделирования уровня конструирования как степень технологичности построения программных и документных представлений требований, реализуемых на итерации, из конструкторских моделей. Так же как в предыдущем случае, это характеристика как процесса моделирования, так и применяемых для него средств, методов, систем.
Конспективно только что рассмотренные процессы можно представить в виде схемы, изображенной на. Дополнительного комментария на этой схеме требует лишь стрелка, соединяющая блок моделей уровня анализа с блоками программных и документных представлений. Дело в том, что в любой программной разработке необходимо доказательство того, что система реализует именно то представление предметной области, которое фиксировано согласованными с инициаторами работ аналитическими моделями. Процесс перехода к программным и документным представлениям должен верифицироваться. Нужно доказать не только то, что система работает, но и то, что ее поведение соответствует аналитическим моделям и не опирается на сведения о реализации. Другая сторона этого положения связана с документными представлениями: разработчики обязаны описать систему так, чтобы описание было понятным пользователям, т.е. опять-таки без привлечения реализационных сведений. Может случиться, что некоторые реализационные концепции окажутся согласованными с пользовательским представлением о системе. Они способны стать основой для расширения аналитических моделей (например, для унификации описаний похожих фрагментов системы). Но в таком случае эти концепции должны быть представлены достаточно абстрактно, чтобы основой пользовательского представления стали не особенности реализации, а понятные на уровне аналитических моделей положения, пусть даже внешние по отношению к этим моделям. Для такой адаптации полезно воспользоваться метафорическими построениями (см. прием 8).
Приоритетной задачей моделирования как приема оперирования требованиями является обеспечение максимально простого расширения моделей. Трудность здесь заключается в том, что разработчик зачастую стоит перед альтернативой: строить ли новую, дополнительную модель или же модернизировать существующую. Общих рецептов по этому поводу дать невозможно, однако следует указать на то, что система моделей должна оставаться понятной. Для ситуаций использования это утверждение означает, что нет нужды перегружать действиями субъекты, если эти действия разнородны и их совместное представление ничего не поясняет. Нет необходимости объединять разнородные сценарии даже в тех случаях, когда расширение связывает новый фрагмент действий с существующим сценарием. Напротив, при расширении уточняющего характера новые модели вводить не стоит. Особое место в расширяющих построениях занимают объекты, которые выявляются при моделировании. Здесь могут воз никнуть проблемы введения новых объектов и классов, абстрактных обобщений, а также использования шаблонов проектирования. Критерий, который чаще всего выставляют как для начального моделирования, так и для расширения, — добиваться возможности независимой реализации различных аспектов системы. Именно он дает возможность максимально простого расширения моделей и, что еще более важно, повторного использования реализации средств любого уровня в конструируемых системах.
Легко заметить, что схема процесса моделирования требований имеет не просто аналогии, но и глубокие параллели с диаграммой трансформации требований . Это совсем неудивительно, ведь в обоих случаях речь идет об оперировании требованиями, рассматриваемыми как материал весьма похожих деятельностей. Разумно рассматривать моделирование требований в качестве инструмента трассировки.
Из приведенного обсуждения видно, что термин моделирование требований используется как сокращение для более точного названия процесса построения моделей прикладной области по динамически изменяемой совокупности требований к программной системе. Результатом этого процесса являются модельные представления требований и программные и документные компоненты системы, если саму программную систему рассматривать в качестве модели прикладной области.
Несколько слов о нотации, применяемой при построении модельных представлений требований. В принципе в проекте можно использовать любые формы таких представлений, если они дают возможность обеспечивать взаимопонимание и однозначное выражение требований. И для локальных проектов, сведения о которых не распространяются далее коллектива разработчиков, такое положение вполне оправданно — нет необходимости осваивать что-то новое, когда старое всех устраивает. Однако ограниченность такого пути очевидна. Он препятствует использованию чужих разработок, не следующих принятым для данного проекта соглашениям, затрудняет последующее распространение рабочих продуктов проекта и их переиспользование в последующих проектах, выходящих за рамки данного коллектива. Затрудняется обучение привлекаемого персонала. Предпочтительнее задействовать стандартные общепринятые представления требований и отработанные методы их трансформации, которые поддерживаются инструментально в рамках интегрированных средств поддержки разработки пр ограммного обеспечения CASE-систем .
Разработка содержательных аспектов моделирования — это сфера ответственности тех участников проекта, которые занимаются соответствующими уровнями представления требований. Общий контроль этого процесса относится к функциям архитектора проекта, который должен гарантировать стабильность развития текущего состояния. В тех случаях, когда изменение моделей требует согласования с заказчиком, архитектор проекта извещает менеджера, который организует необходимые контакты. Хранение моделей — забота библиотекаря системы, который под контролем специалиста по информационной поддержке выбирает базовую инструментальную систему и адаптирует ее к условиям проекта.
Результатом моделирования как приема оперирования требованиями является система моделей области применения программной системы на том уровне, на котором этот прием использован. Эта система удовлетворяет соответствующим условиям корректности моделей.

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

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

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

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

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

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

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

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

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

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

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

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

Организация работ по управлению требованиями
Управление требованиями и приемы этой работы, представленные выше, являются главными условиями успешного развития большинства сложных проектов, поскольку именно это обеспечивает возможность построения системы, реально удовлетворяющей потребности пользователей с учетом внешних обстоятельств разработки (надежность заказчика, рыночная конъюнктура и др.). Однако большинство рекомендаций, которые можно дать для организации этих работ, принадлежат конкретным методологиям. Наиболее регламентированно подходят к вопросу монументальные методологии, ставящие критерии отслеживания процесса развития проекта на первое место. Противоположная позиция у методологии экстремального программирования, провозгласившей «путешествие налегке» (все, что не относится к решению задач проекта в их текущем видении, не требуется учитывать, а тем более специально разрабатывать), сотрудничество с заказчиком как с членом команды (он отвечает за актуальность решаемых при производстве р елизов задач), а также ряд специальных методик, делающих классический анализ требований избыточным .
Позиция, которая провозглашается в данном курсе по отношению к требованиям, исходит из того, что в любом успешном реальном проекте процессы, определяющие разработку программного проекта, выполняются явно или неявно, документируются в той степени, в которой это необходимо для решения задач проекта. Применительно к управлению требованиями это означает, что всегда выполняются работы, которые обеспечивают корректное решение проблем, обозначенных в лекции 12. Все это относится к внутренней организации дел проекта. Что же касается взаимоотношений с инициаторами работ, поставляющими требования, то здесь ситуация иная: необходимо придерживаться общепринятых норм общения и правил, которые без дополнительных соглашений обеспечивают бесконфликтность контактов и нормальное развитие. Они сводятся к следующему регламенту действий, сопровождающих анализ распространения изменений требований. Требования, возникающие и изменяемые в течение этапов итерации, разделяются на принимаемые и отвергаемые:

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

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика