Технологии программирования - Wiegers.Software R. Development Productivity Award Москва 2004 удк 004. 45 В41 Карл Разработка требований к программному с англ. М. дом Русская Редакция , 2004. ил. Isbn 5-7502-0240-2 Эта книга
 Скачать 37.95 Mb.
| Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
Полное содержание архива WinRAR ZIP archive.zip:  С этим файлом связано 6 файл(ов). Среди них: task2.txt, unit4.png, task1.txt, Mikhneva_Anastasia_1951.pkt, WinRAR_ZIP_archive.zip, Wiegers_Software_Requirements.pdf, Metodicheskie_ukazania_praktika.docx. Показать все связанные файлыГлава 14. Назначение приоритетов требований 271 10 — реализуйте их». Трудно убедить клиентов обсуждать приоритеты, если они знают, что функций с низким приоритетом не получат Один разработчик как-то сказал мне, что в их компании не принято на- значать требованию низкий приоритет. Категории приоритетов требо- ваний назывались у них «очень высокие» и «невероятно вы- сокие». Другой разработчик заявлял, что назначение приоритетов всем не нужно: если он записал что-либо в то собирается это реализовать. Но это не отвечает на вопрос, когда будет реализована каждая функция. Некоторые разработчики избега- ют определения приоритетов, потому что оно не соответствует пози- ции «мы можем которую они декларируют. Ловушка Избегайте определения приоритетов «по когда требова- ние, высказанное громче всего, получает наибольший приоритет, и «по угрозе», когда те, кто имеют больший вес в компании, всегда получают требуемое. В действительности некоторые возможности системы более чем остальные. Это становится очевидным, когда на поздних стадиях требуется «быстро урезать» проект, то есть отбросить несущественные характеристики, чтобы критически важные возможности удалось реа- лизовать в срок. Определив приоритеты на ранних этапах разработки проекта и переоценивая их в соответствии с изменяющимися пред- почтениями клиентов, условиями рынка и реалиями бизнеса, команда сможет мудро тратить свое время на создание наиболее ценных воз- можностей. Реализовав большую часть функции, а затем решив, что она не нужна, вы впустую потратите ресурсы и испытаете горькое раз- очарование. Предоставленные самим себе, клиенты, скорее всего назначат 85% требований высокий приоритет, 10% — средний и 5% низкий. не дает менеджеру проекта большой свободы для маневра. Если почти все требования действительно важны, вы рискуете тем, что не весь ваш проект будет успешен, поэтому придется составить планы соот- ветствующим образом. Отшлифуйте требования до блеска, чтобы от- бросить не имеющие большой ценности и упростить неоправданно сложные требования 1996). Чтобы представители клиен- тов с большим мужеством назначали требованиям низкие приоритеты, аналитику стоит задать вопросы, подобные перечисленным ниже. ! Есть ли другой способ удовлетворить это требование клиентов? 1 Что случится, если это требование убрать или отложить? 272 Часть II. Разработка требований к ПО 1 Что произойдет с бизнес-целями, если это требование не будет реа- лизовано немедленно? 1 Почему будут если реализацию этого требования отложить до следующего выпуска? Однажды команда управления менеджментом в крупном коммерче- ском проекте выразила нетерпение, когда аналитик настаивал на оп- ределении приоритетов требований. Менеджеры отметили, что зачас- тую они могут обойтись без какой-либо функции, но тогда в цию придется усиливать другую функцию. Если бы они слишком много функций, то продукт не принес бы доходов. Оценивая приоритеты, учитывайте связи и взаимосвязи меж- ду различными требованиями, а также их соответствие бизнес-целям проекта. Шкала приоритетов Обычный метод расстановки приоритетов подразумевает три группы категорий требований. Неважно, как вы назовете их, все сводится к высокому, среднему и низкому приоритетам. Такие шкалы приорите- тов субъективны и неточны. Лица, заинтересованные в проекте, ны согласовать, что означает каждый уровень в используемой шкале. Один из способов оценки приоритетов предлагает учитывать два из- мерения: важность и срочность (Covey, 1989). Каждое требование счи- тается важным либо не важным и срочным либо не срочным. Как пока- зано в табл. 14-1, получаются четыре комбинации для определения шкалы приоритетов: требования с высоким приоритетом (high priority) — и важные (поль- зователям нужны функции), и срочные (они необходимы уже в сле- дующем выпуске). Некоторые требования приходится включать в эту категорию согласно контрактным или юридическим обязательствам либо из-за непреодолимых бизнес-причин; I требования со средним приоритетом (medium priority) — важные (пользователям нужны функции), но не срочные (они могут ждать следующего выпуска); требования с низким приоритетом (low priority) — не важные (поль- при необходимости могут обойтись без этой функций) и не срочные (пользователи могут ждать, причем вечно); I требования в четвертой клетке кажутся срочными, но в действи- тельности — они не важны. Не тратьте время на работу над ними. Они не сделают продукт более ценным. Глава 14. Назначение приоритетов требований 273 Таблица Определение приоритетов требований по важности и Важные Не важные Срочные Высокий приоритет Не занимайтесь ими! Не срочные Средний приоритет Низкий приоритет Включайте приоритеты каждого требования в описания вариантов использования, спецификацию требований или базу данных требова- ний. Установите правила, чтобы пользователь знал, присваивается ли приоритет, назначенный высокоуровневому требованию, всем дочер- ним требованиям или же каждое функциональное требование должно иметь свой собственный атрибут Даже проект средних масштабов может иметь сотни функциональ- ных требований — слишком много, чтобы классифицировать их анали- тически и последовательно. Чтобы не потерять контроль над ситуаци- ей, выберите для определения приоритетов определенный абстракции — возможности, варианты использования или функцио- нальные требования. В рамках одного варианта использования неко- торые альтернативные направления могут иметь больший приоритет, чем остальные. Вы имеете возможность сначала определить приори- теты на уровне функций, а затем назначить приоритеты функциональ- ным требованиям отдельно для каждой функции. Это поможет вам от- делить основную функциональность от усовершенствований, которые предполагается реализовать позже. Документируйте даже требования с низким приоритетом. Их приоритет может впоследствии изменить- ся, и если разработчики знают о них сейчас, им проще планировать бу- дущую модификацию. Определение приоритетов на основе ценности, стоимости и риска В малом проекте заинтересованные лица могут согласовать приори- теты требований неформально. Крупные или спорные проекты требу- ют более структурированного подхода, устраняющего из процесса не- которые эмоции, политику и догадки. Для помощи в определении при- оритетов предлагается несколько аналитических и математических методик. Они предполагают оценку относительной ценности и относи- тельной стоимости каждого требования. Требования с самым 274 Часть II. Разработка к ПО приоритетом — те, что обеспечивают большую ценность продукта при меньшей стоимости (Karlsson и Ryan, 1997; Jung, 1998). Субъективная оценка стоимости и ценности посредством попарного сравнения всех требований не годится, если требований более двух дюжин. Другая Quality Function Deployment (QFD), ронний метод определения относительной ценности для предлагаемых функций продукта (Zultner, 1993; Cohen, 1995). Третий подход, заимствованный из Total Quality Management оценить каждое требование по нескольким весомым критериям проекта и подсчитать количество баллов для назначения требований. Тем не менее, по-видимому, лишь немногие организации- разработчики ПО готовы применять QFD или В табл. 14-2 показана крупноформатная модель, которая поможет вам оценить относительные приоритеты для набора вариантов пользования, функций или функциональных требований. Загрузить таблицу в формате Microsoft Excel можно с pact.com/goodies.shtml. В табл. 14-2 перечислено несколько функций Chemical Tracking System (а каких же Эта схема заимствует QFD концепцию обоснования ценности для пользователя; как выгода для пользователя, если функция реализована в так и неудобство, если она отсутствует 1996). Привлекатель- ность функции прямо пропорциональна ее полезному действию и об- ратно пропорциональна стоимости и риску, связанному с ее реализа- цией. При прочих равных условиях функции с наибольшим ценность/стоимость должны иметь наивысший приоритет. При этом набор оцениваемых приоритетов распределяется по всему континуу- му, а не по нескольким отдельным уровням. Примените эту схему определения приоритетов к дискреционным требованиям, не имеющим наивысшей ценности. Не нужно включать в этот анализ элементы, которые реализуют основные бизнес-функции продукта, которые вы считаете основными отличительными чертами продукта или которые необходимы для соответствия юридическим нормам. Если нет возможности назначить этим функциям со временем более низкий приоритет при изменении условий, то необходимо реа- лизовать их в продукте как можно быстрее. Определив функции, кото- рыми обязательно должен обладать выпускаемый продукт, используй- те табл. чтобы оценить по шкале относительных приоритетов ос- возможности. Обычно в процессе назначения приоритетов участвуют: Глава 14. Назначение приоритетов требований 275 проекта, который ведет процесс, разрешает и при необходимости адаптирует данные, поступающие от других 1 представители клиента— сторонники продукта или маркетологи, предоставляющие информацию о сильных и слабых сторонах про- дукта; 1 представители разработчиков, например руководители команд, со- общающие данные о стоимости и риске. Таблица Образец матрицы определения приоритетов для Chemical Tracking System Относительный 2 вес функция 1. Распечатка списка данных по безопас- ности мате- риалов 2. ста- тусе поставщика 3. Создание отче- та о инвентари- зации склада химикатов 4. Просмотр ис- тории исполь- зования каждо- го контейнера с химикатом 5. Поиск хими- ката по ката- логам постав- щиков ос а л 5 Я 0 о а 3 2 5 9 5 9 1 О X 4 3 7 5 8 л к § 8 13 25 15 26 Л 0 X I 8,4 16,1 9,7 16,8 1 к а л S О 2 S Е о 5 5 1 2 3 3 о 3 2,7 5,4 13,5 8,1 8,1 0,5 3 X S О ас О 1 1 3 2 8 3,0 3,0 9,1 6,1 24,2 0 Е 1,22 1,21 0,89 0,87 0,83 276 Часть Разработка требований к ПО Таблица Образец матрицы определения приоритетов для Chemical System вес Функция 6. Поддержка списка опас- ных химикатов 7. Модификация невыполнен- ных заявок на химикаты 8. Создание отче- тов об инвента- ризации от- дельных ла- бораторий Проверка в базе данных по обучению наличия запи- 2 х л § 1 >х X л § £ О X 3 4 6 си о прохожде- нии обучения по обращению с опасными веществами Импорт хими- ческих структур из инструмен- тальных средств для рисования структур Итоги 3 7 53 o 9 3 2 4 х О 15 11 14 18 А О i 9,7 7,1 9,0 6,5 1 X л s g I 8 § 8 i £ s о 3 4 4 9 49 155 8,1 8,1 10,8 10,8 24,3 100,0 0,5 >х 2 х А 5 X II 4 2 3 2 о 12,1 6,1 9,1 6,1 33 21,2 а о а. с 0,68 0,64 0,59 0,47 0,33 100,0 | Глава 14. Назначение приоритетов требований 277 При использовании этой модели определения приоритетов поль- зуйтесь следующим планом. Перечислите в таблице все функции, варианты использования или требования, для которых хотите определить приоритеты; я для примера взял функции. Все элементы должны принадлежать к од- ному уровню абстракции — не смешивайте функциональные тре- бования с функциями продукта. Если определенные функции логи- чески связаны (например, вы реализуете функцию В только при на- личии функции А), в анализ включайте только ведущую функцию. Эта модель работает лишь для нескольких дюжин функций, далее она становится слишком громоздкой. Если у вас несколько дюжин элементов, группируйте связанные функции, чтобы составить управляемый первоначальный список. При необходимости вы мо- жете провести второй раунд анализа, на более детальном уровне. 2. Попросите представителей клиентов оценить относительную выго- ду, которую каждая функция дает клиенту или бизнесу, по шкале от 1 до 9: 1 балл означает, что никто не находит ее полезной, а 9 — что она крайне ценная. Эти оценки выгоды отражают связь функций с бизнес-требованиями к продукту. 3. Оцените относительный урон, который потерпит клиент или биз- нес, если функция не будет включена в продукт. Снова используйте шкалу от 1 до 9: 1 балл означает, что никто не расстроится, если ее не окажется; 9 показывает серьезный урон. Требования, имеющие низкие рейтинги и выгоды, и урона, увеличивают стоимость, но имеют малую ценность; они могут оказаться мишурой: выглядят привлекательно, но не стоят инвестиций. Оценивая урон, учиты- вайте, насколько расстроятся клиенты, если определенная функ- ция не будет реализована. Задайте себе вопросы, аналогичные пе- ниже. Проиграет ли ваш продукт по сравнению с другими, содержащи- ми эту функцию? I Будут ли какие-либо юридические или контрактные последствия? I Не вы какой-либо юридический или промышленный стандарт? Не лишит ли это пользователей возможности выполнять либо необходимые или ожидаемые действия? 1 Намного ли сложнее добавить эту функцию позже, в качестве мо- дернизации? I Возникнут ли проблемы из-за того, что отдел маркетинга обещал эту функцию, чтобы удовлетворить некоторых потенциальных клиентов, но команда решила не включать ее? 278 Часть II. Разработка требований к ПО 4. В этой таблице подсчитаны итоговые значения для каждой ции как сумма баллов ее выгоды и урона. По умолчанию выгода и урон оцениваются одинаково. Для уточнения вы можете изменить относительный вес этих двух параметров в верхней строке цы. В примере, взятом для табл. выгода оценивается как и урон. В таблице суммируется ценность всех функций и посчи- тан процент от общего значения для каждого набора функций, ного сумме ценностей каждой функции 5. Попросите разработчиков оценить относительную стоимость лизации каждой функции, опять-такии по шкале от 1 (легко и быст- ро) до 9 и дорого). В таблице подсчитан процент общей стоимости, составленной из вклада каждой функции. ки оценивают рейтинги стоимости, учитывая сложность объем требуемой работы над интерфейсом пользователя, потен- циальную возможность повторного использования о кода, объем необходимого тестирования и документации и т.д. 6. Подобным же образом, разработчики оценивают относительную степень технического или другого риска, связанного с каждой функцией, по шкале от 1 до 9. Технический риск — это вероятность неудачной реализации функции с первого раза. 1 балл означает, что вы сможете запрограммировать ее даже во сне, 9 баллов чает серьезную озабоченность возможностью реализации, нехват- кой сотрудников с необходимым опытом или неиспытанных или незнакомых средств и технологий. Плохо опре- деленные требования, которые могут нуждаться в переработке, следуют из высоких оценок риска. В таблице подсчитан процент риска, который складывается из риска каждой функции. В стандартной модели выгода, урон, стоимость и риск одинаково, но вы можете изменить их вес. В табл. 14-2 риск половину веса фактора стоимости, который имеет тот же вес, что и урон. Если вы не желаете учитывать риск вообще в этой модели, приравняйте значение его веса к нулю. 7. После того как вы введете все результаты оценки в таблицу, по сле- дующей формуле подсчитывается значение приоритета для дой функции: приоритет = % ценности стоимости * вес стоимости) + риска * вес риска) 8. Отсортируйте список функций по уменьшению подсчитанного при- оритета. Функции вверху списка характеризуются наиболее благо- приятным сочетанием ценности, стоимости и риска и поэтому - перейти в каталог файлов | Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
