Связь метода описания с предметом интереса, проектными ролями и системой
В прошлых разделах говорилось, что предмет интереса связан с системой. Систему могут характеризовать разные предметы интереса. Предметы интереса связаны с проектными ролями, то есть людей в ролях интересуют какие-то характеристики системы.
Команда определяет, какие интересы проектных ролей[1] будут удовлетворяться при создании системы. Соответственно, от этого зависит, какие будут нужны рабочие продукты (документация). Рабочие продукты – это физические носители, на которых содержится описание системы, отвечающее за определенный предмет интереса.
Для того, чтобы создать документацию, необходимо владеть определенной практикой[2] или методом описания. Посредством этого метода описания на физическом носителе создаётся описание системы, отвечающее на предмет интереса к системе.
Например, гонщика интересует скорость болида. То же самое можно сказать по-другому: внешняя проектная роль «гонщик» имеет предмет интереса «скорость» к системе «болид». Разработчики решили удовлетворить интересы гонщика, то есть команда посчитала, что интересы данной проектной роли должны быть удовлетворены. Это означает, что далее с этим предметом интереса будут продолжать работу, в рамках которой будет создана документация (компьютерная модель).
Далее разработчики выбирают метод описания, для того чтобы сделать описание системы. Они выбирают один из методов описания, который позволяет построить компьютерную модель расчета скорости автомобиля[3]. Данная модель в компьютере – это рабочий продукт, в котором содержится описание системы автомобиль по предмету интереса скорость.
Кстати, в этой модели может учитываться не только данный предмет интереса, но и другие. Общее количество рабочих продуктов (документации) по описаниям системы пропорционально числу предметов интересов, а количество предметов интересов пропорционально количеству проектных ролей, которое решено удовлетворить[4].
Из всех учтенных проектных ролей выбираются предметы интересов и/или предпочтения, которые будут удовлетворяться. Невозможно удовлетворить все интересы, поскольку может не хватить ресурсов (средств и времени), но, с другой стороны, команда не должна совершить фатальную ошибку. Фатальная ошибка может быть в том, что команда не учла какой-то интерес, что потом принесет значительные и непоправимые затраты. ↩︎
Как вы помните, проектная роль создаёт рабочий продукт по практике. ↩︎
Здесь важна и теоретическая часть расчетов, и компьютерная часть того, как можно провести эти расчеты. ↩︎
Как вы помните, учитываются все проектные роли, но команда может решить, что удовлетворяться будут только избранные. По каждой из них для удовлетворения проектной роли создаётся рабочий продукт. На схеме представлена только внешняя проектная роль, но то же самое относится и к внутренней проектной роли. ↩︎