Технологии программирования - Wiegers.Software R. Development Productivity Award Москва 2004 удк 004. 45 В41 Карл Разработка требований к программному с англ. М. дом Русская Редакция , 2004. ил. Isbn 5-7502-0240-2 Эта книга
 Скачать 37.95 Mb.
| Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
Полное содержание архива WinRAR ZIP archive.zip: ГлаваОсобенности разработки требований к ПО Характеристики превосходных требований Как можно отличить отличную спецификацию требований к ПО от блематичной? В этом разделе обсуждается несколько характеристик, которым должны отвечать отдельные положения требований, а также соответствующие им черты спецификации в целом (Davis, 1993; IEEE, Лучший способ определить, действительно ли ваши ния имеют желаемые атрибуты, — попросить нескольких ванных в проекте лиц внимательно просмотреть спецификацию. Они обнаружат различные виды проблем. Так, например, аналитики и работчики не могут точно полноту или корректность мента, тогда как пользователям не удается оценить технические ха- рактеристики. Характеристики отдельных положений спецификации требований В идеальном мире каждый отдельный пользователь, бизнес или циональные требования отвечают различным параметрам качества которые и описаны в следующих разделах, Полнота Каждое требование должно полно описывать функциональность, кото- рую следует реализовать в продукте. То есть оно должно всю информацию, необходимую для разработчиков, чтобы тем уда- лось создать этот фрагмент функциональности. Если вы понимаете, что данных определенного рода не хватает, используйте пометку (to be determined — необходимо определить) на полях как стан- дартный флаг для выделения такого места. Восполните все пробелы в каждом фрагменте требований, прежде чем приступать к конструиро- ванию этой функции. Корректность Каждое требование должно точно описывать желаемую функциональ- ность. Для соблюдения корректности необходима связь с источника- ми требований, например с пожеланиями пользователей или высоко- уровневыми системными. Требования к ПО, которые конфликтуют с родительскими требованиями, нельзя считать корректными. Однако основная оценка за представителями пользователей, вот по- чему им или их непосредственным заместителям необходимо предос- тавлять требования для просмотра. 22 Часть I. Требования к что, почему и кто Осуществимость Необходима возможность реализовать каждое требование при из- вестных условиях и системы и операционной Чтобы не придумывать недостижимые положения, обеспечьте действие разработчиков с маркетологами и аналитиками требовании на период всего извлечения требований. Разработчики реально оце- нят, что можно выполнить технически, а что нет, или что сделать но при дополнительном финансировании. Инкрементальная раз- работка и подтверждающие концепцию прототипы позволяют прове- рить осуществимость требования. Необходимость Каждое требование должно отражать возможность, которая тельно необходима пользователям или которая нужна для соответст- вия внешним системным требованиям или стандартам. Кроме того, оно должно исходить от лица, которое имеет полномочия на запись положения. Отследите каждое требование вплоть до стадии мнений пользователей, когда выявлялись варианты использовании, бизнес-правила или другие источники. Назначение приоритетов Назначьте приоритеты каждому функциональному требованию, харак- теристике или варианту использования, чтобы определить, что ходимо для каждой версии продукта. Если все положения важны, менеджеру проекта будет трудно справиться с уменьшением бюджета, нарушением сроков, потерей персонала или добавлением новых требований в процессе разработки, Дополнительная информация В назначение приоритетов обсуждает- в деталях. Недвусмысленность Все читатели требований должны интерпретировать их одинаково, но естественный язык зачастую грешит многозначностью. Пишите доку- ментацию просто, кратко и точно, применяя лексику, понятную пользо- вателям. цель качества связанная с точно- стью: читатели должны четко понимать каждое положение. все специальные и запутанные термины в словарь. Глава Особенности разработки требований к ПО 23 Проверяемость Попробуйте разработать несколько тестов или примените другие приемы для проверки, например экспертизу или демонстрации, чтобы установить, действительно ли в продукте реализовано каждое вание. Если требование не проверяется, вопрос его корректной реа- лизации становится предметом а не целью анализа. Не- полные, несогласованные, невыполнимые или двусмысленные вания также не проверяются (Drabick Характеристики спецификации требований Недостаточно получить прекрасные отдельные положения. Набор тре- бований, составляющий спецификацию должен отвечать характери- стикам, описанным в следующих разделах. Полнота Никакие требования или необходимые данные не должны быть про- пущены. Согласованность Согласованные требования не конфликтуют с другими требованиями такого же типа или с высокоуровневыми пользовательскими, систем- ными или бизнес-требованиями. Несогласованность документов сле- дует устранить до начала процесса разработки. Вы не всегда знаете, какое именно положение некорректно (если какое-то некорректно), пока не выполните исследование. Рекомендуется записывать автора каждого требования, чтобы узнать, кто его высказал, если конфликт все-таки будет обнаружен. Способность к модификации Необходимо обеспечить возможность переработки требований, если понадобится, и поддерживать историю изменений для каждого поло- жения. Для этого все они должны быть уникально помечены и обозна- чены, чтобы вы могли ссылаться на них однозначно. Каждое требова- ние должно быть записано в спецификации только единожды. Иначе вы легко получите несогласованность, изменив только одно положение из двух одинаковых. Лучше используйте ссылки на первоначальные ут- верждения, а не дублируйте положения. Модификация спецификации станет гораздо легче, если вы составите содержание документа и ука- затель. Сохранение спецификации в базе данных коммерческого инст- румента управления требованиями сделает их пригодными для по- вторного использования. 24 Часть I. Требования к продукту: что, почему и кто или возможность для анализа, можно реализовать как в направлении назад, к первоисточникам, так и вперед, к элемен- там дизайна и исходному коду, который его реализует, а также к вари- антам использования, которые позволяют проверить реализации. Трассируемые требования помечены идентификаторами. Они записаны в ванной форме, в противоположность параграфам в длинной вательной форме. Избегайте слипания множества требований в один отдельные требования можно трассировать к различным там дизайна и кода. Дополнительная информация В главе обсуждается написание высококаче- ственных функциональных требований, а в главе 20 - трассировка. Вам никогда не удастся создать спецификацию, в которой бы являлись все эти атрибуты. Однако если вы будете помнить о них написании и просмотре требований, вы создадите более ный документ, а и продукт. Что теперь? I Опишите связанные с требованиями проблемы, с которыми вы сталкивались в текущем или предыдущих проектах. Идентифицируйте каждую проблему разра- ботки или управления, а также то влияние, которое она оказывает на проект и их основные причины. I Облегчите обсуждение с членами вашей команды и всеми заинтересованными лицами, записывая проблемы, с которыми вы сталкивались в текущем или пре- дыдущих проектах, их влияние и основные причины. Объясните участникам, что они должны противостоять этим трудностям, если когда-нибудь надеются спра- виться с ними. I Организуйте однодневный посвященный требованиям, для команды, которая работает над вашим проектом. Пригласите основных заказчиков, марке- тологов и менеджеров, используя что чтоб заманить их всех в одну ком- нату. Тренинг представляет собой эффективное средство сплочения команды. Он выработать единую лексику и общее понимание эффективных приемов и поведения, чтобы команда смогла решить поставленную перед ней задачу. Глава Особенности требований к ПО Требования с точки зрения клиента Герхард, старший менеджер компании Contoso cals, встретился с сотрудником отдела по разработке информационных систем. «Нам нужно создать но- вую систему контроля химических препаратов, — начал Гер- хард. — Она должна обеспечить контроль за всеми химически- ми контейнерами на складе и лабораториях. Возможно, бла- годаря этому химики смогут отказаться от новых контейнеров. Система сэкономит компании уйму денег. Кроме того, отделу контроля безопасности и здравоохранения необходимо отчитываться перед правительством». почему этот проект важен, Герхард, Син- тия. — Но прежде чем я набросаю график разработки проекта, нам потребуется собрать некоторые требования к системе". удивился: вы имеете в виду? Я только что числил вам требования», «На самом деле вы описали концепцию и некоторые цели проекта, — объяснила Синтия. — Бизнес-требования кого высокого уровня не дают достаточно информации, чтобы точно определить, какую систему создавать и сколько време- ни на это может потребоваться. Я чтобы аналитик пора- ботал с несколькими пользователями и понял, что они ожида- ют от системы. Затем мы определим, функциональность удовлетворит одновременно ваши бизнес-цели и потребно- сти пользователей. Возможно, вам даже не потребуется новая система, чтобы сэкономить средства». Герахрд никогда раньше не сталкивался с подобной реакцией специалиста отдела информационных систем. "Химики — за- 26 Часть I. Требования к продукту: что, почему и кто — он. — Вряд ли у них найдется время объяснить все подробности до того, как вы начнете пи- сать программу. Не могут ли ваши люди сами определить кс- цель?» Синтия попыталась объяснить, почему необходимо именно пользователей новой системы. мы сами станем угадывать ожидания пользователей, ничего хорошего не вый- дет. Мы — разработчики ПО, а не химики. Нам на самом неизвестно, чего именно хотят специалисты от системы троля препаратов. Я по собственному опыту знаю, что, если потратить время на изучение проблемы до начала результаты окажутся «У нас нет времени на это, — настаивал Герхард. — Я вам мои требования. Теперь, пожалуйста, просто систему. Сообщайте мне о ходе работы». Такие диалоги регулярно возникают при разработке ПО. Клиенты, торым требуется новая система, зачастую не пони- мают, насколько важно непосредственно опросить будущих реальных пользователей. Специалисты по разработавшие концеп- цию нового замечательного продукта, считают, что адекватно ставляют интересы предполагаемых покупателей. Тем не менее ние непосредственных покупателей ПО неоценимо, и заменить его чем-либо иным нельзя. Согласно некоторым современным концепци- ям разработки ПО, например концепции экстремального программи- рования (Extreme Programming), клиент, даже если он постоянно занят собственным бизнесом, должен тесно взаимодействовать с командсй разработчиков. Как говорится в одной книге по экстремальному про- граммированию, «успех проекта зависит от согласованных и программистов» (Jeffries, Anderson и Hendrickson, Одна из проблем при формировании требований том, что люди тают разные уровни требований: уровень телей и функциональный. Герхард перечислил несколько ществ, которые, по его мнению, получит компания Contoso, новую систему контроля химикатов. Однако он не знает требований пользователей, поскольку не этой системой. в свою могут описать необходимые им возможности мы, но не способны грамотно перечислить функции, которые должны реализовать разработчики для предоставления им таких стей. Глава 2. Требования с точки зрения клиента 7 В этой главе речь пойдет о взаимодействии клиента и разработчика жизненно важной для успеха проекта по разработке ПО. Я предлагаю вашему вниманию «Билль о правах клиента ПО» и соответствующий «Билль об обязанностях клиента ПО» при формировании требований Таким я надеюсь прояснить роль клиента, а конкретнее пользователя, в процессе создания требований, Страх отказа Недавно я побывал в отделе информационных систем одной фирмы и услышал пе- чальную историю. Разработчики только что создали новую внутрикорпоративную систему. Пользователи с самого начала не хотели общаться с и ко- гда те с гордостью представили новую систему, пользователи отвергли ее как со- неприемлемую. Разработчики, приложившие немало усилий, чтобы удов- летворить потребности как они их понимали, испытали настоящий шок. И что же они предприняли? Да просто все исправили. При несоответствии тре- бований систему всегда можно подправить, однако это значительно дороже, чем ес- ли бы пользователи описали свои потребности с самого начала. Безусловно, разработчикам пришлось потратить на доводку проекта больше вре- мени и, значит, отложить следующий проект. Это абсолютно проигрышная ситуа- ция. Разработчики растеряны и расстроены, клиенты разочарованы, так как система не оправдала их ожиданий, а компания потеряла кучу денег. Когда клиенты с самого начала плотно и постоянно вовлечены в разработку системы, такого неудачного, но, к сожалению, нередкого итога удается избежать. Кто же клиент? В широком смысле, это человек или организация, получаю- щая от продукта прямую или косвенную выгоду. Клиентами ПО можно считать заинтересованных в проекте лиц, требующих, оплачивающих, выбирающих, определяющих, использующих и получающих про- граммный продукт. Как говорилось в главе 1, прочие заинтересован- ные лица — аналитики требований, разработчики, специалисты по тестированию, технические писатели, менеджеры проектов, а также персонал службы поддержки, юридической службы и маркетинговой службы. Менеджер Герхард — это оплачивающий, или спонсирую- щий, проект по разработке ПО. Клиенты уровня Герхарда определяют бизнес-требования к системе. Они формулируют высокоуровневую концепцию продукта и бизнес-обоснование для его развертывания. 28 Часть I. Требования к продукту: что, почему и кто Как вы узнаете главы 5, бизнес-требования описывают бизнес-це- ли, которых хочет достичь клиент, компания или другие посредники. Бизнес-требования формируют каркас всего проекта. Любые функции и требования к продукту должны бизнес-тре- бования. Тем не менее бизнес-требования не предоставляют разра- ботчикам достаточно информации для создания продукта. Следующий уровень требований — требования пользователей: определяют те, кто прямо или косвенно взаимодействуют с продук- том, то есть конечные пользователи. Они способны описать требуе- мую функциональность, а также ожидаемые качественные стики продукта. Клиенты, предоставляющие бизнес-требования, иногда пытаются говорить от имени пользователей, но обычно они слишком далеки реальной работы, чтобы точно описать их нужды. В случае с ционными системами или разработкой нестандартного бизнес-требования должен определять тот, кто платит, а требования пользователей — те, кто будет стучать по клавишам и но работать с продуктом. Всем участникам проекта проверить бизнес-требований и требований пользо- вателей. К клиенты иногда не хотят найти время, чтобы порабо- тать с аналитиком требований, собирающим, анализирующим и ментирующим требования. Иногда клиенты полагают, что или разработчики собственными силами определят, что именно необ- ходимо пользователям, и не желают вступать в долгие дискуссии. Есл 1 бы все было так просто... В области разработки коммерческого ПО, где клиент и пользова- тель зачастую представлены одним лицом, ситуация несколько иная. Представители клиента, например, из отдела маркетинга или жеры по продукту, обычно пытаются на свой вкус определить, что кли- ент счел бы привлекательным. Тем не менее без конечных пользовате- лей сформулировать требования пользователей не удастся (подроб- нее — в главе 7). В противном случае будьте готовы читать обзоры журналах, описывающие недостатки вашего продукта, которых уда- лось бы избежать при активном участии пользователей. Неудивительно, что и требования пользовате- лей иногда противоречат друг другу. Бизнес-требования отражают ор- ганизационную стратегию или бюджетные ограничения, скрытые от пользователей. Пользователи, разочарованные тем, что менеджмент насильно внедряет новую информационную систему, не всегда хотят общаться с разработчиками ПО, считая последних  перейти в каталог файлов | Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
