Технологии программирования - 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. Хорошие приемы4! стабильным, но для каждого необходимо составлять отдель- ный документ о границах. Определение классов пользователей и их характеристик. Чтобы не упустить из виду потребности пользователей, их в группы. по частоте работе с ПО, используемым циям, уровню привилегий и навыкам работы. Опишите их сти, местоположение и личные характеристики, способные повлиять на архитектуру продукта. Выбор сторонника продукта (product champion) в каждом классе пользователей. Это человек, который сможет точно передавать на- строения и нужды клиентов. Он представляет потребности определен- ного класса пользователей и принимает решения от их лица. В случае разработки внутрикорпоративных информационных систем, когда все пользователи — ваши коллеги, такого человека выбрать проще. При коммерческой разработке пораспросите клиентов или используйте площадки бета-тестирования. Выбранные вами люди должны прини- мать постоянное участие в проекте и обладать полномочиями для при - нятия решений, касающихся пользовательских требований. Создание фокус-групп типичных пользователей. Определите группы типичных пользователей предыдущих версий вашего продукта или похожих. Выясните у них подробности о функциональности и каче- ственных характеристиках разрабатываемого продукта. Фокус-группы особенно значимы при разработке коммерческих продуктов, когда приходится иметь дело с большой и разнородной клиентской базой. В отличие от сторонников у фокус-групп обычно нет полномо- чий на принятие решений, Работа с пользователями для выяснения назначения продукта. Выясните у пользователей, какие задачи им требуется выполнять средствами ПО. как должен клиент взаимодействовать с системой для выполнения каждой такой задачи. Воспользуйтесь стан- дартным шаблоном для документирования всех задач и для каждой сформулируйте функциональные требования. Похожий способ, часто применяемый в правительственных — создать документ с концепциями операций (ConOps), где указаны характеристики новой системы зрения пользователя (IEEE, Определение системных событий и реакции на них. Определите возможные внешние события и ожидаемую реакцию системы на них. Это могут быть сигналы и данные, получаемые от внешнего оборудо- вания, а также временные события, вызывающие ответную например ежевечерняя передача данных, генерируемых 46 Часть I. Требования к продукту: что, и кто внешнему объекту. В бизнес-приложениях бизнес-события напрямую связаны с задачами. Проведение совместных семинаров. Совместные семинары по вы явлению требований, где тесно сотрудничают аналитики и клиенты — отличный способ выявить нужды пользователей и составить наброски документов с требованиями 2002). Конкретные примеры таких семинаров — Joint Requirements Planning (JRP — планирование (Martin, и Joint Application — совместная разработка приложений) (Wood и 1995). Наблюдение за пользователями на рабочих местах. Наблюдая работой пользователей, выявляют контекст потенциального ния нового продукта и Простые диаграммы бочих потоков, а также диаграммы потоков данных позволяют нить, где, как и какие данные задействовал пользователь. руя ход бизнес-процесса, удается определить требования к системе предназначенной для поддержки этого процесса. Иногда даже няется, что для выполнения деловых задач клиентам вовсе и не ется новое ПО и Harbison, Изучение отчетов о проблемах работающих систем с целью иска новых идей. Поступающие от клиентов отчеты о проблемах и предложения о расширении функциональности — отличный идей о возможностях, которые можно реализовать в следующей сии или новом продукте. За подобной информацией стоит обратиться и к персоналу службы поддержки. Повторное использование требований в разных проектах. Если необходимая клиенту функциональность аналогична уже ной в другом продукте, подумайте, готовы ли клиенты гибко реть свои требования для использования существующих компонентов Требования, соответствующие бизнес-правилам компании, применить в нескольких проектах. Это требования к определяющие порядок доступа к приложениям, и требования, ветствующие постановлениям правительства, например Закон о данах США с ограниченными возможностями (Americans with Act). Анализ требований Анализ требований подразумевает их детализацию, что требования понимают все лица, а также Глава 3. Хорошие приемы создания требований 47 тельное исследование требований на предмет ошибок, пробелов и других недостатков. Кроме того, анализ включает создание прототи- пов, анализ осуществимости и согласование приоритетов. Цель ана- лиза — достаточно качественно и подробно описать требования, по- зволяющие менеджерам реалистично оценить все затраты на проект, а техническому персоналу — начать проектирование, сборку и тести- рование. Зачастую отдельные требования стоит представить несколькими способами, например в текстовой и графической форме. Это позволит выявить их особенности и проблемы, не заметные при одним способом (Davis, 1995). Также это помогает всем заинтересо- ванным лицам выработать согласованное представление об итогах разработки продукта. Подробнее об этих темах — в следующих главах: 1 в главе 5 — о создании контекстной диаграммы; в главе — о создании словаря данных; 1 в главе — о моделировании требований; в главе 13 — о создании пользовательского интерфейса и техниче- ских прототипов; в главе — об определении приоритетов 1 в главе — о распределении требований по подсистемам. Создание контекстной диаграммы. Контекстная диаграмма — про- стая модель анализа, отображающая место новой системы в соответ- ствующей среде. Она определяет границы и интерфейсы между рабатываемой системой и сущностями, внешними для этой системы, например пользователями, устройствами и прочими информационны- ми системами. Создание пользовательского интерфейса и технических прото- типов. Если разработчики или пользователи не совсем уверены насчет требований, создайте прототип — частичную, возможную или предва- рительную версию продукта, которая сделает концепции и возможно- сти более осязаемыми. Оценка прототипа поможет всем заинтересо- ванным лицам достичь взаимопонимания по решаемой проблеме. Анализ осуществимости требований. Проанализируйте, насколько реально реализовать каждое требование при разумных затратах и с приемлемой производительностью в предполагаемой среде. Рас- смотрите риски, связанные с реализацией каждого требования, вклю- чая конфликты с другими зависимость от внешних фак- торов и препятствия технического характера. Определение приоритетов требований. Воспользуйтесь аналити- ческим подходом и определите относительные приоритеты реализа- 48 Часть I. Требования к продукту: что, почему и кто ции функций продукта, решаемых задач или отдельных требований. На основании приоритетов установите, в какой версии будет реализо- вана та или иная функция или набор требований. Подтверждая изме- нения, распределите все их по конкретным версиям и включите в план выпуска этих версий затраты, необходимые на внесение изменений. В ходе работы над проектом периодически корректируйте приоритеты в соответствии с потребностями клиента, условиями рынка и бизнес- целями. Моделирование требований. В отличие от подробной информации, представленной в спецификации требований к ПО или пользователь- ского интерфейса графическая модель анализа отобража- ет требования на высоком уровне абстракции. Модели позволяют вы- явить некорректные, несогласованные, отсутствующие и избыточные требования. К таким моделям относятся диаграммы потоков данных, диаграммы «сущность — связь», диаграммы перехода состояний, на- зываемые также автоматами карты диалогов, диаграммы классов, диаграммы последовательностей, диаграммы взаимодейст- таблицы решений и деревья решений. Создание словаря терминов. В нем соберите определения всех элементов и структур данных, связанных с системой, что позволяет всем участникам проекта использовать согласованные определения данных. На стадии работы над требованиями словарь должен содер- жать определения элементов данных, относящихся к предметной об- ласти, чтобы клиентам и разработчикам было проще общаться. Распределение требований по подсистемам. Требования к слож- ному продукту, включающему несколько подсистем, следует сораз- мерно распределять между программными, аппаратными и оператор- скими подсистемами и компонентами (Nelsen, Как правило, это осуществляет системный инженер или разработчик. Применение технологий развертывания функций качества. Тех- нология развертывания функций качества Function Deploy- ment, QFD) — точная методика, соотносящая возможности и атрибуты продукта с их значимостью для клиента 1996). Она позволяет аналитически выявить функции, которые максимально удовлетворят потребности клиента. Технология развертывания функций качества рассчитана на три класса требований: ожидаемые, о которых клиент может не упомянуть, но бу- дет расстроен, если их не окажется в продукте, обычные требования и отдельные, специальные требования, которые обеспечивают удобство Глава 3. Хорошие приемы создания требований 49 работы клиентам, но отсутствие которых не влечет санкций со стороны клиента. Спецификации требований Независимо от способа выявления требований, документировать их нужно так, чтоб это обеспечивало удобный доступ и просмотр. Зафик- сировать бизнес-требования можно в положении об образе и грани- цах проекта. Пользовательские требования обычно представляют в виде вариантов применения или таблиц «событие — реакция». Специ- фикация требований содержит подробные функциональные и нефунк- циональные требования к ПО. Подробнее о приемах по спецификаци- ям к требованиям — в следующих главах: i в главе 9 — о документировании бизнес-правил; I в главе 10 — об использовании шаблона спецификации требований к ПО, о присвоении уникальных всем требованиям; I в главе — об указании атрибутов качества. Использование шаблона спецификации требований к ПО. Создай- те стандартный шаблон для документирования требований к ПО в ва- шей организации. Шаблон предоставляет согласованную структуру, позволяющую фиксировать описания нужной функциональности, а так- же прочую информацию, касающуюся требований. Вместо того чтобы изобретать новый шаблон, модифицируйте один из существующих в соответствии со спецификой проекта. Многие компании начинают с ис- пользования шаблона спецификации требований к ПО, описанного в стандарте IEEE (IEEE, подробнее о работе с ним — в главе 10. Если ваша компания занимается разными проектами, напри- мер проектирует новое крупное приложение и параллельно дорабаты- вает версии старых программ, создайте соответствующие шаблоны для всех типов проектов. Шаблоны и процессы должны быть масштаби- руемыми. Определение источников требований. Чтобы гарантировать, что все заинтересованные лица почему то или иное требование зафиксировано в спецификации требований к ПО, и упростить после- дующее прояснение требований, выявите источники всех требований, Это может быть вариант использования или другая информация от пользователей, системное требование высокого уровня, бизнес-пра- вило или иной внешний фактор. Указав всех лиц, заинтересованных в каждом требовании, вы будете знать, к кому обратиться при поступле- нии запроса на изменение. Источники требований устанавливают на 50 Часть I. Требования к продукту; что, почему и кто основе связей или определяют для этой цели атрибут требования, Подробнее об атрибутах требований — в главе Присвоение уникальных идентификаторов всем Выработайте соглашение о присвоении уникальных требованиям, зафиксированным в спецификации требований к Соглашение должно быть устойчивым к дополнению, удалению ментов и изменениям, вносимым в требования. Присвоение фикаторов позволяет отслеживать требования и фиксировать изменения. Указание атрибутов качества. Выявляя качественные тики, удовлетворяющие потребности клиента, не ограничивайтесь только обсуждением функциональности. Выясните ожидаемые произ- водительность, эффективность, надежность, удобство использованич и др. Информация от клиентов об относительной важности тех или иных качественных характеристиках позволит разработчику принят правильные решения, касающиеся архитектуры приложения. Документирование бизнес-правил. К бизнес-правилам относятся корпоративные политики, правительственные распоряжения и алго- ритмы вычислений. Ведите список бизнес-правил отдельно от фикации к ПО, поскольку правила обычно существуют рамок конкретного проекта. Для выполнения некоторых создавать реализующие их функциональные требования, и необходимо определить связь между этими требованиями и ствующими правилами. Проверка требований Проверка гарантирует, что все положения требований корректны, отражают желаемые качественные характеристики и удовлетворяют потребностям клиента. Может оказаться, что требования, в специфи- кации требований к ПО выглядевшие превосходно, при реализации чреваты проблемами. В большинстве случаев удается выявить смысленности и неопределенности, написав для требований тестирования. Если требования должны стать надежной осно- вой для проектирования и итоговой проверки системы посредством системного тестирования или тестирования на приемлемость для пользователей, эти проблемы необходимо устранить. Подробнее о проверке требований — в главе Глава 3. Хорошие приемы создания требований Изучение документов с требованиями. Официальная проверка до- кументирования требований — один из наиболее ценных способов проверки качества ПО. Соберите небольшую команду, члены которой различные направления аналитик, разработчик и специалист по и тщательно изучите спецификацию к ПО, модель анализа и соответствующую информацию на предмет недостатков. Также полезно провести в ходе формулирования требований их неофициальный предварительный просмотр. И хотя реализовать это на практике непросто, данный при- ем — один из самых ценных, так что начинайте внедрять проверку тре- бований в вашей организации прямо сейчас. Тестирование требований. На основе пользовательских требований создайте сценарии функционального тестирования и задокументи- руйте ожидаемое поведение продукта в конкретных условиях. Совме- стно с клиентами изучите сценарии тестирования и убедитесь, что они отражают нужное поведение системы. Проследите связь сценариев тестирования с функциональными требованиями и удостоверьтесь, что ни одно требование не пропущено и что для всех требований есть соответствующие сценарии тестирования. Запустите сценарии, чтобы удостовериться в правильности моделей анализа и прототипов. Определение критериев приемлемости. Предложите лям описать, как они собираются определять соответствие продукта их потребностям и его пригодность к работе. Тесты на приемлемость следует основывать на сценариях использования (Hsia, и Sell, 1997). Управление требованиями Начальные требования неизбежно корректируются в процессе работы клиентами, менеджерами, специалистами по маркетингу, разработчи- ками и другими лицами. Для управления требованиями необходим процесс, позволяющий предлагать изменения и оценивать их возможную стоимость и влияние на проект. Решения о внесении из- менений принимает по управлению изменениями (change con- trol board, в который входят все заинтересованные лица. Кон- троль за выполнением требований на разных стадиях разработки и тестирования системы позволяет лучше понять состояние проекта в целом. Для эффективного управления проектом жизненно необходимы вы- веренные способы управления конфигурацией. Для управления требо- 52 Часть I. Требования к продукту: что, почему и кто годятся те же утилиты для контроля версий, которые вы пользуете для управления базой кода. Подробнее о способах ния требованиями — в следующих главах: в главе 18 — о создании базовой версии и управлении версиями требований, о контроле за состоянием всех в главе 19 — об определении процесса управления создании совета управления изменениями, оценке изменяемости требований, анализе влияния изменений требований; 1 в главе 20 — о создании матрицы связей требований; I в главе 21 — об использовании средств управления требованиями. Определение процесса управления изменениями. процесс анализа и утверждения или отклонения нений. Применяйте его для управления всеми предлагаемыми изме- нениями. В контексте процесса управления изменениями полезно ис- пользовать коммерческие средства отслеживания недостатков. Создание совета по управлению изменениями. Из лей заинтересованных в проекте лиц организуйте совет по нию изменениями, который будет получать информацию о предпола- гаемых изменениях требований, оценивать ее, решать, какие измене- ния принять, а какие отклонить, и определять, в какой версии продукт будет внедрена та или иная функция. Анализ влияния изменений требований. Анализ влияния ний помогает совету по управлению изменениями принимать обосно- ванные решения. Оцените, как каждое предлагаемое изменение тре- бований повлияет на проект. На основе матрицы связей выявите дру- гие требования, элементы архитектуры, исходный код и тестирования, которые, возможно, придется изменить. что необходимо для реализации изменений, и оцените затраты на - лизацию. Создание базовой версии и управление версиями требований. Базовая версия содержит требования, утвержденные для реализации в конкретной версии продукта. После определения базовых требований изменения можно вносить только в соответствии с процессом - изменениями. Присвойте всем версиям спецификации уникальные идентификаторы, чтобы избежать путаницы между выми вариантами и базовыми версиями, а также между предыдущей текущей версиями требований. Более надежное решение — версиями документов с требованиями при помощи средств управления конфигурацией.  перейти в каталог файлов | Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
