Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 33
Текст из файла (страница 33)
Во всех трех случаях цель состоит в создании прототипа с наимепьвгимн затратами. Если его создание обойдется слишком дорого, может оказаться более эффективным сразу создавать, реальную систему! Многие прототипы программного обеспечения являются прототипами требований н используются в основном для фиксации элементов интерфейса пользователя создаваемой системы. Тому есть две причины.
1. Появление множества недорогих и широко доступных средств быстрого построе- ния интерфейсов пользователя. х. Для систем, активно взаимодействующих с пользователем, создание прототипа интерфейса пользователя выявляет также много других требований, а именно, какие функции предоставляются пользователю, когда каждая функция доступна ему и какие функции для него пропущены. Однако необходимо следить за тем, чтобы доступность этих средств не заставила нас прототипировать те части системы, которые на саьюм деле не имеют самого высокого риска и не нуждаются в первоочередном прототипировании.
Что прототипировать Как же узнать, какую часть системы нужно прототнпироватьУ В типичной ситуации наше понимание потребностей пользователей находится в диапазоне от хорошо попятных и легко объяснимых до совершенно неизвестных (рис. 15.2). Ряс. з5.2.
Наше поннманне потребностей пользоаателей Хорошо понимаемые требования могут очевидным образом вытекать из содержания приложения и опыта пользователей и команды, полученного при работе с системами подобного типа. Например, если мы просто совершенствуем существукнцую систему, по.
пятно, каюгвз должно быть большинство новых функциональных возможностей. Хорошо 162 Часть 2. Понммание потребностей пользователей известные и понимаемые требования не нуждаются в прототипировании, если они не являются необходимыми для того, чтобы помочь пользователям визуализировать содержание др)тих их потребностей. Создание прототипов таких требований будет излишней тратой ресурсов.
а поскольку они и так уже хорошо понятны, из их рассмотрения мало что можно будет почерпнуть. Неизвестные требования являются теми "неоткрытыми руинами", которые мы хотели бы найти. К сожалению, мы не можем по-настоящему прототипировать их, так как в противном случае они уже не были бы неизвестными! Таким образом в качестве объекта прототирования остаются расположенные в середние "неясные" требования. Эти гребо. ванна могут быть известны, но плохо определены и плохо понимаемы.
Построение прототипа Выбор технологии, используемой для построения прототипа, зависит от принятия дальнейших решений в правой части дерева решений на рис. 1з.1. Например, для отбра. сываемого СШ-прототипа можно вьюрать любой л~етод (при условии, что он является самым быстрым, сальным недорогим способом реализации образцов СШ). Если выбран эволюционирующий прототип, нужно применить тот же язык реализации и ту же среду разработки, которые будут использоватыя в промышленном изделии. Придется затратить значительные усилия на проектирование архитектуры системы, а также применить все стандарты кодирования и программныс процессы, которые вы нал|еревастесь использовать при создании системы.
В противном случае вы будете пытаться развивать систему, которая имеет сузцественные недостатки в одном или нескольких из этих аспектов. В конце концов, может оказаться, что прототип придется отбросить! Или, что еще хуже, созданный из лу <ших побуждений прототип требований отрицательно повлияет на качество развертываемой системы. Оценка результатов После создания прототипа пользователи должны поработать с ним в среде, которая как можно более точно имитирует производственную среду использования результирующей системы. Тогда проявятся факторы среды и другие внешние факторы, оказывающие влияние на требования к изделию.
Кроме того, важно, чтобы с продуктом поработали пользователи, представляющие различные их классы, в противном случае результаты могут оказаться однобокилш. Результат процесса прототипирования будет следующим. 1. Неясные требования становятся более понятными. 2. Практическая работа с прототипом неизбежно вскроет реакцию пользователя типа "да, по..."; !гоэтому станут очевидны неизвестные ранее потребности.
Даже то, что пользователь просто увидит множество вариантов поведения, поможет ему понять др)тие требования, которые доллпгы быть наложены на систему. В любом случае прототипирование практически всегда приносит свои плоды. Поэтому, как правило, следует прототиппровать любое новое или инновационное приложение. Главное, чтобы полученные в результате знания о требованиях стоили произведенных затрат. Поэтому мы всегда стараемся испольэовать при создании прототипов (или, по Глава 15. Создание прототипов 163 крайней мере, при реализации наиболее ранних прототипов) самые быстрые и недорогие методы. Ограничивая расходы, мы максимизируем отдачу от инвестиций в получение знаний о требованивх. Заключение Поскольку прототипы программного обеспечения демонстрируют часть желаемых функциональных возможностей новой системы, их можно с успехом применять для уточнения реальных требований к системе.
Секрет их успеха в том, что пользователи могут взаимоййсшаозашь с прототипом в своей среде, которая близка к реальной настолько, насколько этого можно добиться, не разрабатывая п ромьппленную версию программы. Выбирать метод создания прототипа следует в зависимости от типа риска, присутствующего в выпей системе.
Недорогие и простые в разработке прототипы требований помогут вам исключить большую часть связанных с требованиями рисков в проекте. Среди всех имеющихся возможностей следует выбрать ту, которая позволит затратить на прототип как можно меньше средств. Использование любого нз существующих методов прототипирования, а еще лучше — комбинации нескольких методов, доказало свою исключительную эффективность в совершенствовании понимания командой проекта реальных требований к программной системе.
164 Часть 2. Понимаиие потребностей пользователей Задача понимания реальных потребностей пользователей и других заинтересованных лиц осложпнстся тремя "синдромами . Описание синдромов "да, по..., "неоткрытые рутины" н "пользователь н разработчик" помогает л1 ~ше ионин ь прсдстоящис проблемы и даст представление о том, в какой среде будут использоваться методы выявление, которые мы разработали для понимания потребностей пользователей. '1'ак как команлы редко получают совсршснныс спецификации требований к создаваслюй системс, оии должны сами добыеаегь информацию, нсобходнмуто им для успешной работы. Тсрлпш "выявление требований" очень точно отражает данный процесс, в котором команда должна играть более активную роль.
т1тобы помочь команде репщть эти проблемы и лучше понять потребности пользователей п др1тих заинтересованных лпц, можно использовать различныс методы. ° Интервьюирование и анкетирование ° Совещание, посвященные требованиям ° Мозговой штурм и отбор идей ° Создание раскадровок ° 1!рсцедснты ° О<>ыгрывапис ролей ° Создание прототипов Хотя ни один могол нс являстсв универсальным, каждый из ннх позволяет лучше понять потребности пользователей и тем самым превратить "нсвсныс" требования в требования. которые "л1"пвс известны".
Каждый из этих методов "срабатывает" в оцрслелсииых ситуациях, однако мы отдаем предпочтение совсщашпо, посввщепиому требованиям, и мозговоиу нгтурлгу. 166 Часть 3, Определение системы В части! расслщтрпвалцсь методы анализа проблем. Они позволяют достичь понимании проблемы до того, как будут затрачены значитсльныс усилия на ее решение. В этой части мы запинались исключительно областью проблемы.
В части 2 оыл описан ряд методов, которые команда может использовать для понимания потребностей пользователей. Эти потребности находятся на вершине пирамиды требований и таким образом представляют наиболее важную информацию, которая является основой всех последующих действий, В части 3 мы переходим нз области проблемы к области решения и концентрируем свои усилия на онределении снсиьсжм, катар>то можно создать для удовлетворения потребностей пользователей и заинтересованных лиц. Чем ниже мы спускаемся по пирамиде (рис. 1), тем балыке объем информации. Например, для выполнения одной потребности пользователя может понадобиться зпачителыюе число системных функций. Для дальнейшего определения поведения системы необходима дополнительная конкретизация; таким образом, объем необходимой информации увеличивается.
Объем информации, которой мы должны управлять, увеличивается по мере спуска к основанию пирамиды. 1>ее.1. Фуннкии в ниРамиде тРебвваний Кроме того, на данном этапе команде необходимо обратить внимание на множество др>тих вопросов, прис>щих области решения, но мало связанных с областью проблемы.
Например, при разработке п рограло~ного продукта для продажи приходится заниматься вопросами упаковки, инсталляции и лицензирования, каждый из которых может быть уникальным для предлагаемого нами решения. Если же разрабатываемая система предназначена для >довлстворспия пекой внутренней потребности в Ь/1Т,может понадобиться рассмотреть требования к 1зазвсртывапнк> и поддержке, которые практически не имеют отношения к пользователю, пе использующему так>ю систему в настоящее время. Часть 3. Определение системы 167 Однако иам по прежнему следует оставаться на достаточно высоком уровне абстракции, потому что если мы слишком рано перейдем к подробному рассмотрению, то будем не в состоянии "эа деревьями увидеть лес". Кроме того, нужно на секунду остановиться и воспольэоватыя этим временем, чтобы организовать информацию о требованиях, преж. де чем перейти к части пирамиды, содержащей программные требования (она будет рассматриваться в части 5, "Уточнение определения системы").
На данном этапе мы займемся организацией информации о требованиях (глава 16), определением концепции (глава 17) и организацией нашей команды для решения задачи управления требованиями к системе (глава 18). Глава 16 Организация информации о требованиях Основные положения ° Требования к нетривиальным приложеш»ял» следует фиксировать и сохранять в виде базы данных, модели или в форме, которая обеспечивается специальной вспомогательной программой. И В зависимосп» от типа приложе»п»я необходимо применять различные методы организации требований.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
