Технологии программирования - 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 Нигде более, как на стадии сбора требований, так тесно не связаны интересы всех заинтересованных в проекте лиц с успехом проекта. К заинтересованным в проекте лицам относятся: 1 заказчики, которые финансируют проект или приобретают продукт для решения каких-то бизнес-задач; пользователи, которые взаимодействуют напрямую или не напря- мую с приложением (подкласс заказчиков); I аналитики требований, которые пишут требования и передают их разработчикам; 1 разработчики, которые разворачивают и поддерживают I которые определяют соответствие поведения ПО желае- мому; I технические писатели, которые отвечают за создание руководства тренировочные материалы и справочную систему; 1 менеджер по проекту, который планирует процесс и руководит ко- мандой разработчиков вплоть до успешного выпуска продукта; I сотрудники правового отдела, которые следят, чтобы продукт не противоречил всем действующим законам и постановлениям; 1 производственники, которые должны построить продукт, содержа- щий данное ПО; 1 сотрудники отдела продаж и маркетинга, выездной службы под- держки и другие, кому придется работать с продуктом и его пользо- вателями. Хорошо справившись с этой стадией вы получите отлич- ный продукт, восхищенных заказчиков и удовлетворенных разработчи- ков. В противном случае вам грозит непонимание, разочарование и разногласия, которые подрывают веру в продукт и его ценность. Так как требования представляют собой основу для действий и разработ- чиков и менеджеров проекта, все заинтересованные в проекте лица должны быть вовлечены в создание этого документа. Но разработка требований и управление ими — трудный процесс! Здесь нет быстрых или волшебных решений. Однако многие организа- ции борются с одними и теми же трудностями, для преодоления ко- торых мы можем найти общие годные в различных ситуациях. В этой книге описаны дюжины таких приемов. Их рекламируют для по- строения абсолютно новых систем, однако они отлично подходят для поддержки проектов и выбора коммерческих готовых решений (см. главу Не используйте эти приемы только для модели «водопада», Часть I. Требования к продукту; что, почему и кто Даже тем командам, которые выбирают итеративный процесс, знать, что же делать на каждом этапе. Из этой главы узнаете: i несколько ключевых терминов, применяемых при нии ПО; особенности разработки требований, которые отличают этот цесс от управления требованиями; тревожные симптомы некоторых связанных с требованиями блем, которые могут иногда возникать; I некоторые характеристики великолепных требований. Держите руку на пульсе Чтоб проверить приемы построения требований в вашей себя, как много следующих положений верны для ваших текущих проек- тов. Если вы пометите хотя бы три или четыре эта книга для вас. I Образ и границы проекта никогда не определены ясно. I Заказчики очень заняты, чтобы работать с аналитиками и программистами над требованиями. Заместители - менеджеры по продуктам, по разработке, менед- жеры пользователей или маркетологи - говорить от имени клиен- тов, но не точно представляют их потребности. 1 Требования существуют только в головах «экспертов», работающих в вашей ор- ганизации, и никогда не фиксируются в письменном виде. I Заказчики настаивают, чтобы критиковались все требования, без учета их при- оритетов. I Разработчики получают двусмысленную и неполую информацию, поэтому при ко- дировании им приходится делать предположения. Взаимодействие между разработчиками и заказчиками ограничивается внешним видом пользовательского интерфейса и не затрагивает того, что же действитель- но клиенты собираются делать с помощью приложения. 1 Ваши заказчики подписывают требования и затем постоянно изменяют их. 1 Проект разрастается, когда вы принимаете изменения требований, график при этом нарушается, потому что никаких дополнительных ресурсов не выделяется и никакие функции не удаляются. Запросы на требований теряются по пути: ни вы, ни ваши клиенты не знают статус каждого запроса. Заказчики настаивают на определенной которую разработчи- ки и создают, однако эти возможности системы клиентам не нужны. I Технические требования хороши, а вот заказчики нет. Глава Особенности разработки требований к ПО Оговоренные требования к ПО Одна из существующих в индустрии программного обеспе- чения, — это отсутствие общепринятых определений терминов, кото- рыми мы пользуемся для описания нашей работы. Разные эксперты, говоря об одном и том же документе, называют его и требования поль- зователя, и требования к ПО, и функциональные требования, и сис- темные требования, и технологические требования, и бизнес-требова- ния, и требования к продукту. Заказчики зачастую считают, что требо- вания -- это развитая концепция продукта, предназначенная для разработчиков. Те, в свою очередь, полагают, что в отношении клиен- тов это детальная разработка интерфейса пользователя. Такое много- образие ведет к сумятице и раздражающим проблемам коммуникации. Основной закон: требования должны быть документированы. Одна- жды я занимался проектом, который делала опытнейшая команда, од- нако ее состав постоянно менялся. Заказчик впал в неистовство, когда к нему пришел еще один аналитик требований и сказал: «Мы должны поговорить о том, что же вам нужно». На что заказчик ответил: «Я уже излагал свои требования. А теперь постройте мне систему!» Дело в том, что никто не документировал собранную информацию, поэтому каждому новому аналитику приходилось начинать с набросков. Пол- ный бред объявлять о готовности требований, если на самом деле у вас куча электронных писем, голосовых записок, про- токолов совещаний и неясных воспоминаний о беседах в коридоре. Особенности интерпретации требований Консультант Brian Lawrence предположил, что требования — это «неч- то такое, что приводит к выбору дизайна" (Lawrence, 1997). Многие категории информации попадают в эту категорию. IEEE Standard sary of Software Engineering Terminology определяет требования как: условия или возможности, необходимые пользователю для ния проблем или достижения целей; 2. условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетво- рять спецификациям или другим формальным доку- ментам; документированное представление условий или возможностей для пунктов 1 и 2. 6 Часть I. Требования к продукту; что, почему и кто Это определение охватывает требования как пользователей нее поведение системы), так и разработчиков (некоторые скрытые раметры). Термин пользователи следует распространить на заин- лиц, так как не все, кто заинтересован в проекте — зователи. Я думаю о требованиях, как о свойствах, которыми обладать продукт, чтобы представлять какую-то ценность для вателей. Следующее определение подтверждает различие типов тре- бований (Sommerville и Sawyer, Требования... это спецификация того, что должно реализовано. В них описано поведение системы, свойства системы или ее атрибуты. Они быть ограничены процессом разработки системы. Ясно, что нет универсального определения требований. Для облег- чения восприятия материала необходимо согласовать набор характе- ристик, чтобы модифицировать трудный термин требования (require- ments), а также оценить ценность их записи в общедоступной форме. Ловушка Не полагайте, что все лица, заинтересованные в вашем проекте, раз- деляют общее представление о том, что же такое требования. Задайте определения авансом, чтобы вы все изначально говорили на одном языке. Уровни требований В этом разделе приводятся определения, которыми я буду пользо- ваться для терминов, наиболее часто применяемых у такой сфере, как разработка требований. Требования к ПО состоят из трех уровней — требования пользователей и требования. Вдобавок каждая система имеет свои требования. Модель на рис. 1-1 иллюстрирует способ этих типов требований. Как и все модели, она не полная, но схематич- но показывает организацию требований. Овалы обозначают типы ин- формации для требований, а прямоугольники — способ хранения ин- формации (документы, диаграммы, базы данных). Дополнительная информация В главе 7 множество примеров различных типов требований. (business requirements) содержат высокоуровне- вые цели организации или заказчиков системы. Как правило, их выска- зывают те, кто финансируют проект, покупатели системы, менеджер альных пользователей, отдел маркетинга или «ясновидец» Глава Особенности разработки требований к ПО по системам машинного зрения). В этом документе объясняется, поче- му организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Мне нравится записы- вать бизнес-требования в форме документа об образе и границах екта, который еще иногда называют уставом проекта (project или документом рыночных требований (market requirements document). Создание такого документа описано в главе 5. Определение границ проекта представляет собой первый этап управление общими пробле- мами расползания границ. Функциональные Бизнес- требования Документ об образе и границах проекта пользователей качества Документ о вариантах использования интерфейс Системные требования Функциональные Спецификация к ПО Рис. 1 Взаимосвязи нескольких типов информации для требований Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким обра- зом, в этом документе указано, что клиенты смогут делать с помощью системы. Пример варианта использования — «Сделать заказ» для В Часть I. Требования к продукту: что, почему и кто заказа билетов на самолет, аренды заказа гостиницы че- рез Интернет. Дополнительная информация Глава 8 посвящена требованиям пользователей. Функциональные требования (functional requirements) функциональность ПО, которую разработчики должны построить, что- бы пользователи смогли выполнить свои задачи в рамках бизнес-тре- бований. Иногда именуемые требованиями поведения (behavioral re- quirements), они содержат положения с традиционным или «должна»: «Система должна по электронной почте отправлять вателю подтверждение о заказе». Как иллюстрируется в главе 10, функциональные требования описывают, что разработчику необходи- мо реализовать. Термином системные требования (system requirements) обозначают высокоуровневые требования к продукту, которые содержат подсистемы, есть система (IEEE, Говоря о системе, мы - разумеваем программное обеспечение или подсистемы ПО и дования. Люди — часть поэтому определенные функции темы могут и на людей. Однажды моя команда писала ПО для контроля некоторой торной аппаратуры, которая автоматизировала скучное добавление точного количества вещества в ряд мензурок. Из требований для всей системы мы вывели производные функциональные требования к ПО, чтобы посылать сигналы оборудованию для перемещения распреде- ляющих вещество насадок, считывания показаний датчиков ния и включения/выключения насоса. (business rules) включают корпоративные правительственные постановления, промышленные стандарты и алгоритмы. Как вы увидите в главе 9, бизнес-правила являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Однако они часто налагают ограничения, определяя, кто может выполнять конкретные варианты ния, или диктовать, какими функциями должна обладать подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности. Следовательно, вы можете отследить происхож- дение конкретных функциональных требований вплоть до - им бизнес-правил. Глава Особенности разработки требований к ПО 9 Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описы- вается так полно, как необходимо, ожидаемое поведение системы. Я буду относиться к как к документу, хотя это может быть база данных или крупноформатная таблица с требованиями, хранили- ще данных в коммерческом инструменте управления требованиями (см. главу 21) или даже, может быть, куча карточек для небольшого проекта. Спецификация требований к ПО используется при разработ- ке, тестировании, гарантии качества продукта, управлении проектом и связанных с проектом функциях. В дополнение к функциональным требованиям спецификация со- держит нефункциональные, где описаны цели и атрибуты качества. Ат- рибуты качества (quality представляют собой дополнитель- ное описание функций продукта, выраженное через описание его ха- рактеристик, важных для пользователей или разработчиков. К характеристикам относятся легкость и простота использования, лег- кость перемещения, целостность, эффективность и устойчивость сбоям. Другие нефункциональные требования описывают внешние взаимодействия между системой и внешним миром, а также ограниче- ния дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта, Люди часто рассуждают о характеристиках продукта. Характеристи- ка (feature) — это набор логически связанных функциональных требо- ваний, которые обеспечивают возможности пользователя и удовле- творяют бизнес-цели. В области коммерческого ПО характеристика представляет собой узнаваемую всеми заинтересованными лицами группу требований, которые важны при принятии решения о покупке — элемент маркированного списка в описании продукта. Характеристики продукта, которые перечисляет клиент, не эквивалентны тем, что вхо- дят в список необходимых для решения задач В каче- стве примеров характеристик продуктов можно привести избранные страницы или закладки Web-браузера, контроль за орфографией, за- пись макрокоманды, сервопривод стекла в автомобиле, он-лайновое обновление или изменение налогового кодекса, ускоренный набор те- лефонного номера или автоматическое определение вируса. Характе- ристики могут охватывать множество вариантов использования, и для каждого варианта необходимо, чтобы множество бований было реализовано для выполнения пользователем его задач. Чтобы вы лучше восприняли некоторые из различных видов требова- ний, я рассмотрю программу подготовки текстов. Бизнес-требование может выглядеть так: «Продукт позволит пользователям ор- Часть I. Требования к что, почему и кто ошибки в тексте эффективно». На коробке CD-ROM указано, что проверка грамматики включена как характеристика, удов- летворяющая бизнес-требования. Соответствующие требования зователей могут содержать задачи (варианты использования) та- кой: «Найдите орфографическую ошибку» или «Добавьте слово в общий словарь». Проверка грамматики имеет множество индивидуальных функциональных которые связаны с такими операциями, как поиск и выделение слова с ошибкой, отображение диалогового с фрагментом текста, где это слово находится, и замена слова с кой корректным вариантом по всему тексту. Атрибут качества и простота использования (usability) как раз и определяет его значение посредством слова «эффективно» в бизнес-требовниях. Менеджеры и сотрудники отдела маркетинга определяют - требовния для ПО, которые помогут их компании работать нее (для информационных систем) или успешно конкурировать рынке коммерческих продуктов). Каждое требование ля должно быть сопоставлено бизнес-требовнию. На основе ний пользователя аналитики определяют функции, которые пользователям выполнять их задачи. Разработчикам функциональные и нефункциональные требования, чтобы решения с желаемой функциональностью, определенным качеством и требуемыми рабочими характеристиками, не выходя за рамки гаемых ограничений. Хотя в модели на рис. показан поток требований в направлении сверху вниз, следует ожидать и циклов, и итераций между бованиями, требованиями пользователей и функциональными ваниями. Кто бы когда бы ни предложил новые характеристики, вари- анты использования или функциональные требования, аналитик дол- жен спросить; попадают в указанные границы?» Если ответ то они соответствуют спецификации. На «нет», как известно, и суда нет. А вот если ответ «нет, но они должны там быть», то заказчик тот, кто финансирует проект, должен решить, готов ли он границы проекта, чтобы принять новое требование. Каких требований не должно быть Спецификация требований не содержит деталей дизайна или зации (кроме известных ограничений), данных о планировании та или сведений о тестировании и Widrig, 2000). указанные элементы из требований, чтобы из этого документа было абсолютно ясно, что надлежит построить команде разработчиков. Для проекта, как правило, создаются требования других типов:  перейти в каталог файлов | Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
