Технологии программирования - Wiegers.Software R. Development Productivity Award Москва 2004 удк 004. 45 В41 Карл Разработка требований к программному с англ. М. дом Русская Редакция , 2004. ил. Isbn 5-7502-0240-2 Эта книга
 Скачать 37.95 Mb.
| Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
Полное содержание архива WinRAR ZIP archive.zip: Глава 3. Хорошиесоздания требований 53 Ведение журнала изменений требований. Фиксируйте даты нения спецификаций требований, сами коррективы, их причины, а же лиц, вносивших изменения. Автоматизировать эти задачи ет утилита управления версиями или коммерческая утилита ния требованиями. Контроль за состоянием всех требований. Создайте БД, щую по одной записи для каждого дискретного функционального тре- бования. Занесите в БД ключевые атрибуты каждого требования, включая его состояние «предложено», зовано» или «проверено»), чтобы в любой момент вы могли узнать личество требований в каждом состоянии, Оценка изменяемости требований. Еженедельно фиксируйте коли- чество требований, внесенных в базовую версию, а также число пред- ложенных и одобренных изменений (добавлений, модификаций и уда- лений). Если требования формируются не самим клиентом, а от его лица, может оказаться, что проблема понята границы проекта определены нечетко, бизнес стремительно меняется, при сборе ин- формации многие требования были упущены или внут- рикорпоративные политики меняются в худшую сторону. Использование средств требованиями. Коммерче- ские утилиты управления требованиями позволяют хранить различные типы требований в БД. Для каждого требования можно определить рибуты, отслеживать его состояние, а также выявить связи между тре- бованиями и другими рабочими продуктами. Данный прием поможет вам автоматизировать прочие задачи по управлению описанные ниже. Создание матрицы связей требований. Создайте таблицу, тавляющую все функциональные требования с элементами архитекту- ры и кода, которые реализуют данное требование, и с тестами, прове- ряющими его. Матрица связей требований позволяет также сопоста- вить функциональные требования с требованиями более высоких уровней, на основе которых они созданы, и с другими родственными требованиями. Заполняйте эту таблицу входе, а не в конце работы над проектом. Управление проектом Способы управления проектом ПО тесно связаны с работой над требо- ваниями к нему. Планируйте ресурсы, графики и обязательства по 54 Часть I. Требования к продукту: что, почему и кто проекту на основании требований, которые собираетесь реализовать. Изменения требований влияют на планы реализации, поэтому в пла- нах следует предусмотреть возможность частичного изменений бований и расширения границ проекта. Подробнее о способах ления проектом, касающихся создания требований — в следующих главах: 1 в главе о планах, связанных с проектом, о их реализации на нове требований; 1 в главе 18 — о контроле объема работ по созданию требований; в главе 23 — о документировании и управлении рисками, ми с требований. Выбор цикла разработки ПО. Вашей компании следует несколько жизненных циклов разработки для проектов различного ти- па и различных степеней неопределенности требований Каждый менеджер проекта должен выбрать и использовать цикл, оптимальным образом подходящий для его проекта. Включите -л цикл операции по созданию требований. Если на ранних этапах рабо- ты над проектом требования или границы проекта определены ко, разрабатывайте продукт постепенно (небольшими этапами), начи- ная с наиболее понятных требований и устойчивых элементов архи- тектуры. По возможности реализуйте наборы функций, чтобы дически выпускать промежуточные версии продукта и как можно рань • ше предоставлять клиенту работоспособные образцы 1988; Cockburn, Планы реализации проекта должны быть основаны на ниях. Разрабатывайте планы и графики работы над проектом посте- пенно, по мере прояснения границ и подробных требований. с оценки необходимых на реализацию функциональных ваний, определенных на основе первоначальных образа и границ про- дукт. Графики и оценка затрат, построенные на основе нечетких требо- ваний, окажутся крайне неточными, однако по мере детализации тре- бований их следует уточнить. Пересмотр обязательств по проекту при изменении требований. Добавляя в проект новые требования, удается ли обязательства, касающиеся графика и требований к качеству, при доступном объеме ресурсов. Если нет, обсудите реалии проекта ; менеджерами и согласуйте новые, достижимые обязательства (Hum- phrey, 1997; и 1991; 2002). Если переговоры не увенчаются успехом, сообщите менеджерам и клиентам о их ре- Глава 3. Хорошие приемы создания требований 55 зультатах, чтобы нарушение планов в реализации проекта не стало для них неожиданностью. Документирование и управление рисками, связанными с требо- ваниями. Одна из составляющих управления рисками проекта — выяв- ление и документирование связанных с требованиями. Умень- шайте или предотвращайте их посредством мозговых реали- зуйте корректирующие действия и отслеживайте их эффективность. Контроль объема работ по созданию требований. Фиксируйте усилия, прилагаемые вашей командой на разработку требований и управление проектом. Эти данные оценить соответствие планам и эффективнее спланировать необходимые ресурсы для буду- щих проектов. Также отслеживайте, как ваши действия по регламента- ции требований влияют на проект в целом. Это оценить отда- чу этой работы, Извлечение уроков из полученного опыта. Для этого в организации следует провести ретроспективу проектов, называемую также изуче- нием законченных проектов (Robertson и Robertson, 1999; 2001; Wiegers и Rothman, Ознакомление с опытом в области проблем и способов требований, накопленным в ходе работы над предыдущими проектами, помогает менеджерам и аналитикам требо- ваний более эффективно работать в будущем. Начинаем применять новые приемы В табл. 3-2 описанные выше приемы создания требований сгруппиро- ваны по их относительному влиянию на большинство проектов, а также по относительной сложности реализации. И хотя полезны все спосо- бы, начать можно с простейших, наиболее влияющих на успех проекта и относительно простых в реализации. 56 Часть I. Требования к продукту: что, почему и кто Таблица 3-2. Реализация приемов формулирования требований Сильное Среднее Сложность Высокая Определите про- цесс формулиро- вания требований Планируйте на осно- вании требований Пересматривайте обязательства 1 Ознакомьте предста- вителей пользова- телей и менеджеров с требованиями Моделируйте вания связанными с требованиями Используйте управления требова- ниями I Создайте матрицу требований Проводите семи- нары для уточнения требований Определите варианты использования 1 Укажите атрибуты качества Определите приори- теты требований Используйте шаблон спецификации требований к ПО 1 Определите процесс управления измене- ниями 1 Создайте совет управ- ления изменениями 1 Изучите документы с требованиями Распределите требо- вания по подсистемам Задокументируйте Обучите аналитиков требований 1 Выберите ярых сторон- ников продукта Создайте фокус- группы Создайте прототипы 1 Определите критерии приемлемости Анализируйте влияние изменений i Выберите соответ- ствующий цикл Низкая Обучите разработ- чиков основам пред- метной области 9 Определите образ и границы проекта Определите классы пользователей 1 Нарисуйте контекст- ную диаграмму i Определите источники требований 1 Определите базовую версию и управляйте версиями требований Проанализируйте осуществимость Создайте словарь бизнес-терминов Создайте словарь 1 Наблюдайте за пользо- вателями на рабочих местах Определите системные события и реакцию на них Задайте каждому тре- бованию уникальный идентификатор Протестируйте требо- вания i Отслеживайте состоя- ние 8 Извлекайте уроки из полученного опыта Глава 3. Хорошие приемы создания требований Таблица 3-2. приемов формулирования требований (продолжение) Слабое Сложность Высокая Используйте требования повторно Воспользуйтесь тех- нологией разверты- вания функций ка- чества Оцените изменя- емость требований Средняя 1 Ведите журнал изменении Отслеживайте объем работ по реализации требований Низкая Изучите отчеты о проблемах Не пытайтесь применять в своем следующем проекте сразу все эти приемы. Скорее, стоит рассматривать как новые компоненты вашего инструментария для работы над требованиями. Некоторые способы. например касающиеся управления изменениями, можно начать ис- пользовать независимо на какой стадии разработки находится ваш проект. Приемы выявления требований наиболее полезны в начале работы над очередным проектом или при повторении. Прочие способы могут оказаться неприемлемыми из-за ограничений текущего корпоративной культуры или объема доступных ресурсов. В главе 22 рассказывается, как оценить способы создания требований, исполь- зуемые вами в настоящий момент. Кроме того, описанные выше прие- мы помогут вам разработать план реализации сбора и ния требований. Процесс создания требований Не что все действия по выявлению, анализу, спецификации и проверке требований удастся выполнить последовательно и за один проход. На практике эти действия выполняются попеременно, поэтап- но и повторяются (рис. Работая с клиентами в качестве аналити- ка, вы будете задавать вопросы, выслушивать ответы и наблюдать за действиями клиентов (выявление Далее вы обработаете полученную информацию, классифицируете по различным категори- ям и соотнесете потребности клиентов с возможными требованиями к ПО (анализ). Затем вы оформите информацию от клиентов и вырабо- танные требования в виде письменных документов и диаграмм (спе- цификация), предложите представителям пользователей 58 Часть I. Требования к продукту: почему и кто дить, что написанный вами текст точен и полон, и попросите их испра- вить возможные ошибки (проверка). Этот итерационный процесс и есть процедура требований. Повторная оценка Анализ Спецификация Проверка Переработка Исправление и устранение недостатков Рис. Итеративный процесс формулирования требований Из-за разнообразия проектов по разработке ПО и организационных культур единого, шаблонного подхода к созданию требований не су- ществует. На рис. 3-2 показана схема создания требований, которая с разумными исправлениями подойдет для большинства проектов. Как правило, действия выполняются в основном по порядку, однако сам процесс не является строго последовательным. Первые семь дейст- вий обычно однократно выполняются на ранних стадиях работы проектом (тем не менее команде разработчиков придется периодиче- ски изменять приоритеты). Остальные необходимы для каждого оче- редного выпуска или этапа работы над проектом. Оценив доступные вам способы общения с представителями поль- зователей, выберите подходящие приемы выявления требований (круглые столы, исследования, опросы и т.д.) и спланируйте время и ресурсы, необходимые для сбора информации (этап 5 на рис. 3-2). Многие системы создаются и поэтому любой команде, ра- ботающей над проектом, необходимо определить приоритеты вариан- тов использования и других пользовательских требований (этап Расставив приоритеты, вы решите, на каком этапе следует реализо- вать те или иные варианты использования. В случае новых систем значительных усовершенствований можно на этапе определить уточнить архитектуру, а на этапе 15 распределить требования по конкретным подсистемам. Этапы 12 и 17 — это опера- ции по контролю качества, в результате которых вам, возможно, при- дется вернуться, чтобы исправить ошибки, улучшить модели анализа или выявить упущенные ранее требования. Прототипы, создаваемые на этапе 13, зачастую выявляют необходимость усовершенствовать и модифицировать определенные ранее требования. Завершив Глава 3. Хорошие приемы создания требований какой-либо части требований этап можно приступать к реализации соответствующей части системы. Повторите этапы для следую- щих наборов вариантов использования, которые могут войти в более позднюю версию продукта. образ и границы 2 Определите пользователей 3- 4. кто будет решения, 6. и задокументируйте Создайте прототипы i 14. 15. по компонентам 17. Проверьте варианты требования, модели и прототипы Повторить пункта N Рис. 3-2. Поэтапный процесс создания требований 60 Часть I. Требования к продукту: что, почему и кто Что теперь? i вернитесь к проблемам с которые вы определили, выполняя зада- ния раздела «Что теперь?» главы Выберите описанные в этой главе ко- торые помогут вам решить все эти Или же воспользуйтесь руково- по выявлению и устранению из приложения В. Сгруппируйте приемы по их влиянию на вашу организацию (сильное, среднее и слабое). Опре- какие препятствия в или культуре способны помешать вам воспользоваться тем или иным приемом. Кто поможет устранить эти препят- ствия? I Оцените которые считаете наиболее ценными. Позволят ли они умень- шить число некорректных требований, выявляемых на поздних стадиях работы над проектом, уменьшить объем ненужных точнее следовать графику проекта или предоставят какие-то другие преимущества? I Перечислите все приемы формулирования определенные на пер- вом этапе. Укажите, насколько члены вашей командой овладели на сегодняшний момент тем или иным приемом: квалифицированные специалисты, опытные специалисты, новички или не знакомы с данным приемом. Если квалификация членов команды ниже, чем по крайней мере опытные специалисты, попросите одного из них изучить данный прием и поделиться полученными знаниями с ос- тальными членами команды. Глава 3. Хорошие приемы создания требований 61 Аналитик требований Среди участников любого проекта по разработке ПО обязательно есть человек, явно или неявно выполняющий роль аналитика требований. Крупные фирмы для решения подобных задач привлекают специали- стов такого профиля — бизнес-аналитиков. Их также называют сис- темными аналитиками, инженерами по требованиям, менеджерами по требованиям и просто аналитиками. В разрабаты- вающей продукты, функции аналитика зачастую выполняет менеджер по продукту или специалист отдела маркетинга. Задача аналитика - отразить мнения заинтересованных сторон и лиц в спецификации тре- бований и передать информацию другим заинтересованным в проекте лицам. Аналитик помогает участникам проекта прояснить, действи- тельно ли пожелания, которые они высказывают вслух, — это то, что им на самом деле нужно. Аналитик обучает, задает вопросы, слушает, организует и учится. сложная работа. В этой главе я познакомлю вас с функциями аналитика требованиями, которые предъявляются к его знаниям и опыту, а также расскажу, как воспитать аналитика в своей организации 2000). Пример должностных обязанностей аналитика требований опубликован на: https://www.processimpact.com/goodies.shtml. Роль аналитика требований Аналитик требований — это основное лицо, отвечающее за сбор, ана- лиз, документирование и проверку требование к проекту. Это основ- ной коммуникативный канал между группой клиентов и командой раз- работчиков (рис. 4-1), хотя, не единственный: есть и другие, 62 Часть I. Требования к продукту: что, почему и кто Аналитик отвечает за сбор и распространение информации о те, а менеджер проекта — за обмен информацией о проекте. -требования поток функциональные и нефункциональные требования требования Тестирование [ Рис. Обязанности аналитика требований: наведение коммуникативных мостов между группами клиентов и проекта Аналитик требований — это одна из ролей участников проекта, а не обязательно название должности. На эту роль можно назначить или нескольких специалистов. Кроме того, функции аналитика могут выполнять другие члены команды параллельно со своими обязанно- стями, например менеджер проекта, менеджер по продукту, профиль- ный специалист matter expert), разработчик и даже пользо- ватель. В любом случае аналитик должен обладать всеми навыками, знаниями и личными необходимыми для эффективной ра- Ловушка Не думайте, что любой талантливый разработчик или опытный пользо- ватель автоматически, без обучения, чтения литературы и тренировок, станет про- фессиональным аналитиком требований. Все эти роли требуют разных навыков, знаний и личных качеств, От таланта аналитика зависит успех проекта. Один из клиентов, ко- торых я консультировал, пришел к выводу, что спецификации с требо- ваниями, созданные опытными аналитиками, удается изучать вдвое  перейти в каталог файлов | Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
