Технологии программирования - Wiegers.Software R. Development Productivity Award Москва 2004 удк 004. 45 В41 Карл Разработка требований к программному с англ. М. дом Русская Редакция , 2004. ил. Isbn 5-7502-0240-2 Эта книга
 Скачать 37.95 Mb.
| Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
Полное содержание архива WinRAR ZIP archive.zip: Глава 4. Аналитик требований 71Те, кому нравится общаться с пользователями — хорошие кандидаты для специализации в области анализа требований. Разработчику, ставшему аналитиком, вероятно, придется более по- дробно ознакомиться с предметной областью бизнеса. Однако разра- ботчики легко переходят на техническое мышление и жаргон, концен- трируясь вместо потребностей пользователей на программном про- дукте, который надо создать. Им будет полезно дополнительное обучение в области межличностных коммуникаций, которыми искусно владеют лучшие аналитики — умение эффективно слушать, вести пе- реговоры и создавать комфортные условия общения. Профильный специалист Ralph Young рекомендует, чтобы аналитик требований был экс- пертом в предметной области или профильным специалистом, а не обычным пользователем: «Спецификация требований к ПО может оп- ределить, ... насколько разумны требования, они расширяют суще- ствующую систему, как следует проектировать предполагаемую архи- тектуру и какое влияние они окажут на пользователей». Некоторые ор- ПО нанимают опытных пользователей их продуктов, обладающих большим опытом в предметной области, в ка- честве аналитиков или представителей пользователей. Аналитик требований, будучи экспертом в предметной области, за- частую определяет требования к системе, которые соответствуют его личным предпочтениям, а не обоснованным потребностям различных классов пользователей. Иногда профильные специалисты увлекаются созданием универсальной, системы, когда на самом деле большую часть потребностей пользователей удовлетворит менее сложное решение. Зачастую лучше, чтобы аналитик требований из ко- манды разработчиков взаимодействовал с профильным специали- стом, который кроме того выбран в качестве ключевого пользователей (сторонника Подробнее о роли сторонников продукта в разработке пректа — в главе 6. Создание атмосферы тесного сотрудничества Иногда в проектах по разработке ПО возникают напряженные отноше- ния между аналитиками, разработчиками, пользователями, менедже- рами и специалистами по маркетингу. Стороны не всегда доверяют мотивации других участников и не ценят потребности и ограничения других. Однако на самом деле у разработчиков и потребителей про- 72 Часть I. Требования к продукту: что, почему и кто продукта общая цель. При создании корпоративных систем все стороны работают на одну компанию и все они получают выгоду от улучшения результатов ее работы. В случае коммерческого продукта налицо счастливые клиенты, получивший прибыль производитель и удовлетворенный разработчик. требований — основное лицо, отвечающее за обеспечение тесного доброжелательного сотрудничества с представителями пользователем и прочими сторонами, заинтересованными в проекте. аналитик принимает во внимание трудности, с которыми сталкиваются представители бизнеса и технических служб, и постоянно демонстри рует коллегам свое уважение. Аналитик добивается от участников про екта согласования требований, в результате чего выигрывают все: клиенты довольны продуктом; 1 организация-разработчик получает прибыль; 1 разработчики гордятся работой, выполненной в ходе сложного про екта. Что теперь? I Если вы - аналитик требований, сравните свои и навыки с описанными в Этой главе. Если выявили какие-либо пробелы, выберите две темы и прора- ботайте их, читая, практикуясь, работая с наставником или посещая специализи- рованные курсы. I Выберите этой книги один способ создания требований, о котором вы знаете недостаточно, и начните применять его со следующей недели - в бук- вальном смысле! Выберите два или три дополнительных способа и начните ис- пользовать их месяц. Другие оставьте на потом, чтобы изучить и приме- нять их через пять-шесть месяцев. Определите, когда вы хотели бы применять каждый из новых способов, преимущества, которые, как вы считаете, он даст вам, а также какая помощь или дополнительная информация может потребовать- ся. Подумайте, чье сотрудничество понадобится вам, чтобы начать использовать новые способы. Выявите препятствия, которые могут помешать применять кон- фетный способ, и подумайте, кто в силах помочь вам преодолеть их. Глава 4. Аналитик требований 73 II Определение образа и границ проекта Когда моя коллега Карен ввела в компании, где она работала, практику экспертизы документации требований, она обратила внимание, что многие проблемы, которые выявили проверяющие, касались объема проекта. Часто у экспертов было разное представление о предпола- гаемых границах и целях проекта. В результате им трудно было дого- вориться о том, какое функциональное требование относится к специ- фикации требований. Как мы уже видели в главе бизнес-требования составляют выс- ший уровень абстракции в цепи требований: они определяют образ и границы системы ПО. Пользовательские и функциональные требова- ния к ПО должны находиться в соответствии с контекстом и целями, ус- танавливаемыми бизнес-требованиями. не содействую- щие достижению бизнес-целей проекта, не стоит включать в проект. Проект, в котором нет четко определенного и согласованного на- правления, можно смело кандидатом на провал. Участники проекта могут, сами того не осознавая, решать прямо противополож- ные задачи, если у у них разные бизнес-цели и приоритеты. заинтересованные в проекте, никогда не смогут договориться о соста- ве если они не выработали общего понимания лей. Четкое представление образа и границ проекта особенно важно при разработке сложного, распределенного ПО, когда географическое разделение участников замедляет ежедневное взаимодействие, упро- щающее коллективную работу. Признаком того, что бизнес-требования недостаточно ясно опреде- лены, можно считать ситуацию, когда определенные функции сначала включают в продукт, затем удаляют из него, а позднее снова добавляют. Проблемы, касающиеся образа и границ, необходимо разрешать до спецификации детализированных функциональных требований. Поло- 76 Часть II. Разработка требований к ПО жение о рамках и ограничениях проекта необычайно при ждении предлагаемых функций и целевых выпусков. Кроме того, на него можно ссылаться при принятии решений о изменении и расшире- нии требований. В некоторых компаниях основные положения об об- разе и границах помещают на схему, которую приносят на каждое про- ектное совещание, чтобы все смогли быстро оценить, не выходит ли предложенное изменение за рамки проекта. Определение образа продукта вплоть до бизнес-требований Образ продукта (product vision) выстраивает работу всех заинтересо- ванных лиц в одном направлении. Он что продукт ставляет собой сейчас и каким он станет впоследствии. Границы про- екта (project scope) показывают, к какой области конечного ного образа продукта будет направлен текущий проект. В положении о границах определена черта между тем, что входит в проект и тем, что остается вовне. То есть указанные рамки также определяют ния проекта. Более детально эти сведения изложены в базовой версии требований, которую разрабатывает команда для данного проекта. Говоря об образе, мы подразумеваем весь продукт. Он будет няться относительно медленно при определении со временем гии продукта или развитии бизнес-целей. Границы же относятся к оп- ределенному проекту или его итерации, в которых реализуется чуть больше возможностей продукта, как показан на рис. Границы бо- лее динамичны, чем образ, так как менеджер проекта изменяет содер- жимое каждой версии в соответствии с графиком, бюджетом, ресурса- ми и ограничениями качества. Задача планирования заключается в управлении границами определенного проекта (разрабатываемого или расширяемого), как определенным подмножеством большого гического образа. Положение об объеме для каждого проекта или ках- дой итерации или расширения продукта, вероятнее всего будет вклю- чено в спецификацию требований к этому ПО, а не в отдельный мент об образе и границах. Для крупных новых проектов необходимо создавать и полный документ об образе и границах проекта, и фикацию требований. О шаблоне спецификации требований но в главе Например, федеральное правительственное агентство получило дол- госрочный заказ, рассчитанный на пять лет, на разработку массивней 5. Определение образа и границ проекта 77 информационной системы. Команда определила бизнес-цели и образ системы еще на начальной стадии и за несколько следующих лет никак не меняла их. Было запланировано 15 отдельных выпусков конечной системы. Каждый выпуск создавался как отдельный проект с описани- ем его собственных границ. Последние должны были соответствовать общему образу продукта и перекликаться с положениями о границах других проектов — это позволяло гарантировать, что ничего не будет пропущено. Нереальные требования Менеджер компании, специализирующейся на разработке ПО, сильно переживаю- щая из-за почти катастрофического расползания проекта, с сожалением ска- зала мне; «Мы создали слишком нереальные требования*. Она имела в виду, что любая идея, возникающая у члена команды, включалась в документ. У команды был четкий образ проекта, однако они не управляли границами, планируя несколько вер- сий и откладывая определенные функции до более поздней (возможно, неопреде- ленно поздней) версии. Наконец, после четырех лет разработки, черезмерно груженный продукт был выпущен. Толковое управление рамками проекта и посте- пенность в разработке позволили бы им поставить качественный продукт намного раньше. оговоренного Версия оговоренного объема Рис. Образ продукта содержит запланированные версии оговоренного Конфликтующие бизнес-требования собранные из разных источников, могут конфлик- товать. Представьте себе компьютер со встроенным ПО, подсоеди- ненный к Интернету и предназначенный для покупателей магазина (киоск). При его разработке следует удовлетворить следующие биз- нес-цели: 1 получение дохода путем сдачи в аренду или продажи киоска про- давцу; I продажу потребительских товаров покупателям; Часть II. Разработка требований к ПО привлечение внимания покупателей к торговой марке; 1 предоставление широкого ассортимента товаров. Бизнес-интересы розничного продавца таковы: I максимальное увеличение дохода с доступного пространства; I привлечение большего количества покупателей в магазин; i увеличение объема продаж и уровня прибыли, если киоск операции, выполняемые вручную. Разработчику иногда хочется сделать киоск высокотехнологичным и увлекательным для покупателей. Продавцу же нужна простая и стью готовая к эксплуатации система, а для покупателя важны во и функциональные возможности. Напряженность между этими мя сторонами с их различными целями, ограничениями и бюджетом может привести к несогласованности бизнес-требований. Тот, кто нансирует проект, должен разрешить эти конфликты до того, как литик детализирует системные требования и требования к ПО киоска Основное внимание следует уделять фундаментальным задачам, щим наибольшую коммерческую выгоду продажи, привлечены новые При этом можно легко отвлечься внешние характеристики продукта пользователь- ский интерфейс, привлекающий клиентов»), которые не отражают альные бизнес-цели. Кроме того, тот (или те), кто финансирует проект, проекта разрешать конфликты различных заинтересованных в проекте лиц — не стоит ждать, что разработчики разберутся сами. По мере того как определяется все больше заинтересованных лиц и появляется все больше групп спонсоров с соперничающими интересами, увеличива- ется риск увеличения обьема проекта. Неконтролируемый рост объе- ма из-за того, что заинтересованные лица пытаются каждое пожелание, может привести к тому, что проект рухнет под соб- ственным весом, так и не дав каких-либо ценных результатов. Разре- шение подобных конфликтов часто удается лишь в результате полити- ческой и жестокой борьбы, что выходит за рамки тем, обсуждаемых в этой книге. Бизнес-требования и варианты использования определяют и набор бизнес-задач ис- пользования), которые позволяет выполнять приложение и глубину до которого реализуется каждый вари- ант использования. Если бизнес-требования помогают вам опреде- лить, что некий вариант использования выходит за границы Глава 5. Определение образа и границ проекта 79 значит, что вы принимаете решение о ширине проекта. Глубина про- стирается от простой реализации до полной автоматизации с множе- ством вспомогательных средств. Бизнес-требования по- для каких вариантов использования необходима надежная и пол- ная функциональность, а для каких достаточно поверхностной реализации, по крайней мере на первое время. Бизнес-требования влияют на приоритеты реализации вариантов использования и связанные с ними функциональные требования. На- пример, такая бизнес-цель, как получение максимальной дохода от ки- оска, подразумевает реализацию на ранней стадии функций, отвечаю- щих за продажу большего количества продуктов или предоставляю- щих услуги покупателям. Экзотичные, эффектные функции, привлекающие лишь немногих, жадных до технологичных новинок кли- ентов и не способствующие выполнению основной бизнес-задачи, не должны получать высокий приоритет. Бизнес-требования также существенно влияют на способ реализа- ции требований. Например, одна из причин создания Chemical Track- ing System — уменьшить закупку новых бутылей с химикатами, исполь- зуя те химикаты, которые уже есть на складе или в другой лаборато- рии. Опросы и наблюдения должны помочь выяснить, почему в данный момент это не делается. В свою очередь, на основе этой информации создаются функциональные требования и элементы дизайна, которые облегчают отслеживание химикатов в каждой лаборатории и помогают сотруднику, запрашивающему химикат, отыскивать искомое как можно Документ об образе и границах проекта Документ об образе и границах and scope document) собирает бизнес-требования в единый который подготавливает осно- ву для последующей разработки продукта. В некоторых организациях с этой же целью создают устав проекта или положение о бизнес-зада- чах. Очень полезен и документ основных рыночных требований ket requirements document, В нем более детально, чем в доку- менте об образе и границах, рассматриваются целевые сегменты рын- ка и проблемы, касающиеся коммерческого успеха продукта. Владельцем документа об образе и границах считается кто фи- нансирует проект или несет аналогичную ответственность. Аналитик требований может вместе с этим человеком разрабатывать документ об образе и границах проекта. Информация, касающаяся бизнес-тре- 80 Часть II. Разработка требований к ПО бований, должны поступать от лиц, четко понимающих, почему взялись за проект. Это может быть клиент или топ-менеджер организа- ции, разрабатывающей продукт, тот, кого привлекают технические но- винки, менеджер по продукту, эксперт в данной предметной области или специалисты отдела маркетинга. На рис. 5-2 показан шаблон документа об образе и границах Шаблоны стандартизируют структуру документов, создаваемых про- ектными командами каждой организации. Как и в случае с любым шаб- лоном, измените его в соответствии со спецификой вашего проекта. показаться, что части документа об образе и границах повто- ряются, однако они должны смыкаться. Рассмотрим пример. Бизнес-требования 1.1. Исходные данные 1.2. Возможности бизнеса Бизнес-цели и критерии успеха Потребности клиента или рынка Бизнес-риски 2. Образ решения 2.1. Положение об образе проекта 2.2. Основные функции 2.3. Предположения и зависимости 3. Масштабы и ограничения проекта Объем первоначально запланированной версии 3.2. Объем последующих версий 3.3. Ограничения и исключения 4. Профили заинтересованных лиц 4.2. Приоритеты проекта 4.3. Операционная среда Рис. 5-2. Шаблон документа об образе и границах проекта Бизнес-шансы. Использовать слабо защищенные документы о конку- рирующем продукте. Бизнес-цель. Получить признание в качестве наиболее защищенного продукта на рынке, используя обзоры в отраслевых журналах и опросы потребителей, и захватить 80% рынка. Пожелания потребителей. Более защищенный продукт, Функция. Новый надежный механизм защиты,  перейти в каталог файлов | Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
