2014-02-13
940
Управление сложностью путем выбора уровня абстракции
Систему произвольной сложности можно определить с помощью списка ид 25-99 функций.
Количество функций, которое мы позволяем себе рассматривать, будет существенно влиять на уровень абстракции определения. Для того чтобы справиться со сложностью разрабатываемой системы, мы рекомендуем описывать возможности каждой новой системы или дополнения к уже существующей системе как можно более абстрактно, чтобы в результате получить не более 25- 99 функций, примем желательно, чтобы их число не превышало 50.
При этом относительно небольшой объем информации обеспечивает всестороннюю и полную основу для определения продукта, общения с заказчиками, управления масштабом и проектом. С помощью 25-99 функций, удобным образом разбитых на категории и упорядоченных, мы сможем описывать и обсуждать самые разнообразные системы, будь то космический корабль многоразового использования или программное средство (например, автоматическое обнаружение неисправностей). В части 5 эти функции будут преобразованы в детальные требования, достаточно конкретные, чтобы их можно было реализовать. Мы будем называть их требованиями к программному обеспечению, или программными требованиями (software requirements), в отличие от высокоуровневых функций. Необходимость в дополнительной конкретизации возникнет позднее. На данном этапе нам достаточно рассуждать на уровне функций.
|
|
|
После того как возможные функции перечислены, можно приступить к принятию решений вида "отложить до следующей версии", "реализовать немедленно", "полностью отвергнуть" или "исследовать дополнительно". Этот процесс корректировки масштаба лучше проводить на уровне функций, а не на уровне требований, иначе можно просто увязнуть в деталях. Мы рассмотрим проблему масштаба более подробно в части 4, "Управление масштабом".
Чтобы было легче оперировать этой информацией, мы будем рассматривать атрибуты функций — элементы данных, которые обеспечивают дополнительную информацию о каждой функции. Атрибуты используются для того, чтобы связать функции или требования с другой информацией проекта. С помощью атрибутов можно отслеживать функции (имя или уникальный идентификатор, состояние, исторические данные, распределен из, трассируется к и т.д.), задавать их приоритет (поле приоритета), а также управлять (статус) функциями, предложенными для реализации, Например, атрибут приоритет можно использовать для хранения результатов накопительного голосования время "мозгового штурма"; атрибут номер версии — для фиксации конкретной версии программного обеспечения, в которой предполагается реализовать данную функцию.
|
|
|
Присваивая функциям различные атрибуты, можно более успешно управлять сложностью информации. Хотя атрибуты могут быть самыми разнообразными, опыт свидетельствует, что существуют некие общеупотребительные атрибуты, которые применяются в большинстве проектов (табл. 8.2). Далее в данной книге мы будем использовать эти атрибуты при работе с функциями и требованиями, а также отношениями между различными типами системных требований.
Таблица 8.2. Атрибуты функций
| Атрибут | Описание |
| Статус | Отслеживает ход процесса определения базового уровня проекта и последующей разработки. Пример, функция может иметь статус предлагаемая, утвержденная, включенная |
| Приоритет/Полезность | Функции не одинаковы по своей важности. Определение относительных приоритетов или полезности для конечного пользователя открывает путь к диалогу между заинтересованными лицами и членами команды разработчиков. Этот атрибут используется при управлении масштабом и определении очередности. Пример, определение функции как критической, важной, полезной |
| Трудоемкость | Оценка количества командо- или человеко-недель, строк кода или общего уровня трудоемкости помогает определить, что можно, а что нельзя осуществить за определенный период времени. Пример. низкий, средний или высокий уровень трудоемкости |
| Риск | Вероятность того. что данная функция вызовет нежелательные последствия, такие как увеличение расходов, отставание от графика или даже закрытие проекта. Пример, высокий, средний и низкий уровень риска |
| Стабильность | Вероятность того, что будет меняться данная функция или ее понимание командой. Используется для того, чтобы помочь при определении приоритетов разработки и выявлении тех элементов, для которых следующим действием должно стать дополнительное исследование |
| Целевая версия | Указание версии продукта, в которой впервые появится реализация данной функции. Комбинирование этого атрибута с полем статуса дает команде возможность предлагать, записывать и обсуждать различные функции, не принимая их к разработке |
| Назначение | Во многих проектах функции будут предназначаться "функциональным командам", ответственным за дальнейшую их доработку, написание программных требований, а также, возможно, их реализацию |
| Обоснование | Используется для отслеживания источника запрашиваемой функции. Например, ссылка может указывать на страницу или номер строки спецификации продукта или временной маркер на видеозаписи важного интервью с клиентом. |
Итак, давайте перейдем к некоторым профессиональным приемам, которые помогут нам получить необходимую информацию. Начнем с интервьюирования (глава 9).
