Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 20
Текст из файла (страница 20)
Команда может испольаовать моделирование бизнеспроцесса как для понимания пути развития бизнеса, так и для определения, где внутри системы можно наиболее эффективно развернуть приложения. Мы также выяснили, что определенная нами бизнес-модель будет иметь параллельные конструкции в программном приложении, и будем испольэовать эту общность при проектировании программного обеспечения. Выявленные на данном этапе бизнес-прецеденты будут позднее приме. няться для определения требований к самому приложению.
Для класса программных приложений, которые мы отнесли к встроенным системам, при анализе проблемы мы испольэовали методы системной инженерии. позволяющие осуществить разбиение сложной системы на подсистемы. Этот процесс помогает понять, где должны находиться программные приложения и каким общим целям они служат. При этом оказалось, что мы в чем то усложняем проблему требований, создавая новые подсистемы, для которых в свою очередь нужно заниматься пониманием требований.
100 Часть 2. Понимание потребностей пользователей Среди причин возникновения проблем в проектах чаще всего упоминается "недостаток информации от пользователя". (Исследование группы Степдиша, 1994) В отчете группы Степдиша одной из наиболее часто упоминаемых причин возникню вения проблем в проектах назван "недостаток информации от пользователя". 13% респондентов указали эту причину в качестве основной, другие 12% назвали "неполные требования и спецификации".
Из этик данных следует, что примерно для четверти всех испытывающих затруднения проектов недостаточное понимание реальных требований пользователей (а точнее, всех заинтересованных лиц) является серьезной проблемой, влияющей на успех проекта. Очевидно, что инициативу должны взять на себя команды разработчиков, так как вряд ли все пользователи, проснувшись однажды утром, вдруг начнут делать все возможное для прояснения своих требовании. Иными словами, нашим командам необходиэю выработать профессиональные приемы выявления требований. =~'~ В части 1 мы разработали приемы, которые помогут понять реф~ с.з( ' з и шаемую проблему.
В части 2 описываются методы, которые команда разработчиков может использовать для достижения понимания реальных потребностей будущих пользователей и других заинтересованных лиц. При этом мы также начнем понимать возможные требо. вания к систел~е, которая будет разрабатыватыя для удовлетворения этих потребностей. На данном этапе о~ионное внимание уделяется потребностям заинтересованных лиц, которые находятся в верхней части пирамиды требований. В этой части будут рассматриваться различные методы — от простых и недорогих, таких как интервьюирование, до весьма дорогостоящих и достаточно формальных, таких как создание прототипов.
Ни один из этих методов не является универсальным, однако, ознакомившись с ними, команда сможет выбирать. Для кюкдого конкретного проекта команда сможет определить подходящие методы и применить опыт и знания, полученные при работе над выявлением требований в предыдущих проектах. Таким образом, команда создаст уникальный набор подходящих для данной среды приемов, которые мо~уг внести заметный вклад в совершенствование конечного результата. Глава 7 Задача выявления требований Основные положении ° Выявление требований осложняется тремя эндемическйми синдромами.
° Синдром "да, но..." является следствием человеческой природы и неспособности пользователя воспринимать программное обеспечение как физический прибор. В Поиск требований сродни археологическим; раскопкам (поиску "ненайденных руин"); чем больше вы находите,'тем,больше вы знаете о том, что еще осталось ненайденным.
° Синдром "пользователь и разработчик" отражает глубокое различие между ними, затрудняющее общение. В последующих нескольких главах мы будем рассматривать множество методов выявления требований пользонателей системы и других заинтересованных лицг. Этот про. цссс кажется достаточно очевидным: нужно собраться вместе с будущими пользователями системы и другими заинтересованными лицами и спросить их, что должна, по их мнению, делать система. Что в этом сложного? Почему нужно так много методов? И зачем нужны эти профессиональные приемы вообщез Чтобы лучше понять эту конкретную проблему, сначала рассмотрим три синдрома, которые могут значительно усложнить предмет. Преграды на пути выявления требований Синдром мда, но о ° ' ° Одной из сазных неприятных проблем при разработке приложений является то, что мы цазвалн синдромом "да, но...".
Это наблюдаемая нами реакция пользователя на каждый когда-либо разработанный фрагмент программного обеспечения. Именно благодаря ему лгы наблюдаем дее кемедзизспые зфовзивоноаолгиые реакции, когда пояьзовагяель вгзереые еидвт реолизайию пмтемы. З Иногда дяя нх обозначения иы будем использовать понятие назьхмаеиль в обобщсююм гиьиле. Методы применяются дая выявления требований всех заинтересованных лиц. 102 Часть х.
Понимание потребностей пользователей ° "О, это действительно здорово, мы можем реально использовать это, классная работа, молодцы. мальчики," и т. д. ° "Да, но, как насчет...) Нельзя ли было бы...з А что будет, если...?" Причина синдрома "да, но..." кроется глубоко в природе программного обеспечения как интеллектуального неосязаемого процесса.
Проблема усугубляется тем, что команды разработчиков крайне редко предоставляют что-либо пользователям для обсуждения и взаимодействия до окончания разработки программного кода. Реакция пользователей является следствием человеческой природы. Подобную ревю цию можно часто наблюдать и при других повседневных обстоятельствах. Пользователи никогда ранее не видели новую систему нли что.либо подобное; оии не понимают, что вы подразумеваете, когда описываете ее. И вот теперь она перед ними — впервые после стольких месяцев (или лет) ожидания они имеют возможность взаимодействовать с системой. И оказывается, что это не совсем то, чего они ожидали! Давайте сравним создание программного обеспечения с созданием механических приборов, технология и процесс разработки которых старше программирования на несколько сотен лет.
Для механических систем существует хорошо разработанная методология принципиальных моделей, макетов, пошаговых прототипов, пробных промышленных изделий и т.д. Все они являются осязаемыми, и большинство из них выглядит и действует аналогично разрабатываемому прибору. Пользователи могут увидеть макет прибора, потрогать его, всесторонне обсудить и даже попытаться поработать с ним гораздо раньше, чем будет завершена детальная реализация.
Исключительно для получения ранней непосредственной реакции на концептуальное определение продукта были разработаны специальные технологии, такие как стереолитография, в которых быстрый прототип создается сегодня на сегодня. И только в программном обеспечении, несмотря на всю его сложность, мы почему.то надеемся получить удовлетворительный результат с первой попытки.
Как это ни грустно, но нужно принять факт существования синдрома "да, но..." в качестве обаективной реальности и сделать некоторые выводы, которые помогуг членам команды смягчить влияние этого синдрома в будущих проектах. ° Синдром "да, но..." является следствием человеческой природы и неотьемлемой частью разработки любого приложения.
° Мы можем существенно уменьшить воздействие этого синдрома путем примеие. ния методов, которые выявят эти "но" как можно раньше. Выявив их иа более ранних этапах, мы можем направить большую часть наших усилий на разработку программ, которые уже прошли тест на "да, но.... Глава 7. Задача выявления требований 103 Синдром "неоткрытых руин" Один из наших друзей однажды был экскурсоводом иа автобусном марш руте в районе Ропг Согпегэ, области, определенной общими границами штатов Колорадо, НыоМексико, Юга и Аризона Экскурсия проходила по живописным вершинам горной цепи Ла-Плата, античным руинам Анасази в МесаВерде и окрестностям.
Вопросы туристов являются постоянным источником развлечения для экскурсоводов и создают определенный фольклор туристического бизнеса. У нашего друга самым любимым [:." . 11.; 'Т: "дурацким" вопросом был "А сколько здесь неоткрытых руин?", 1 'Я ' эу', Во многом поиск требований напоминает поиск неоткрытых руин: чем ["- ймыие пл найдено, ями лучше пзээсжяц что эжо еэке не вгк Вы никогда не сможете почувспювать, что нашли все, и, похалуй, так оно и есть на ымом деле.
Повсеместно команды разработчиков программного обеспечения пьпзются определить, когда же можно закончить с выявлением требований, т.е. когда можно считать, что они выявили все существенные требования или хотя бы достаточное их кол ичес пю. Чтобы помочь команде справиться с этой проблемой, мы предлагаем множество методов, как в рамках части 2, так и в последующих главах. Конечно, как отмечалось в части 1, огромное значение имеет выявление всех заинтересованных лиц на этапе анализа проблемы. Многие нз этих заинтересованных лиц (не являющихся пользователями) зачастую являются источниками требований, которые в противном случае так и не будут выявлены.
Как и в случае поиска неоткрытых руин, мы должны осознавать, что зту миссию никогда нельзя считать завершенной. Но мы также понимаем, что на определенном этапе можно будет с уверенностью сказать: "Мы узнали достаточно". Синдром "Пользователя и разработчика" Таблица 7.1. Синдром "пользователь и разработчик" Решение Проблема Признавать пользоэателя экспертом э предметной области и пенять его э этом качестве; Пользователи пе знают, чего хотят, а если и знают, то пе могут зто выразить пытаться использовать альтернатив~не мето- ды общения и выявления требований Методы выявления требований не новы.
Разработчики приложений более 40 лет работали над их совершенствованием. Почему же тогда понимание потребностей пользо. вателя остается одной из основных проблем? Поскольку лишь немногие разработчики приложений илгеют опыт применения методов выявления требований, это ие так уж удивительно. Синдром "пользователь и разработчик" является следствием расхождения взглядов пользователей и разработчиков. Пользователи и шиработчики, как правило, принадлежат к различным мирам, говорят иа разных языках и имеют рззличный опыт, мотивацию и цели. Иногда мы должны учиться более эффективно общаться с этими "пользователями из другого мира".
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
