Принципы и приемы оперирования требованиями

Прием 5. Определение системы

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

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

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

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

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

Прием 6. Управление областью применимости системы

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

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

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

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

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

Прием 7. Детализированное определение системы

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

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

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

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

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

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

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

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

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