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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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