Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 78
Текст из файла (страница 78)
Мы можел~ угочиить требования позднее". Но слишком часто подобный подход приводит к хаотическим дейст. виям прп разработке, когда никто ие знает, чего иа самом деле хочет пользователь и что в действительности делает созданная на данный момент система. 360 Глава бб. С чего начать Как узнать, что должна делать система? Как отслеживать текущее состояние требований? Как определить воздействие изменений? Чтобы решить эти проблеллы, мы рекомендовали руководствоваться философией управления требованиями, которое определилии следующим образом. Уэсрааеение требованиями — вто асспмиалаическ1сй подход к вылкееэлию, ореаниэации и докуменопсрованню ллребованнй к системе, а такэке процесс, в ходе колпороео еиробаолиеоетсн и обесгмнив стлал согла1кенне меэкду закаэчикам к вмполнлюгцей проект группой но поеоду меняющгсхся требований к аитеме.
Поскольку история развития программирования и его обозримое будущее связаны с возрастанием сложности, мы отдаем себе отчет, что разработкой программного обеспечения должны заниматься хорошо организованные и хорошо обученные команды разработчиков. Каждый член команды в той или иной степени будет привлекаться к управлению требованиями к проекту. Команде необходимо выработать профессиональные приеллы для понимания потребностей пользователей, управления маспгтабом приложения и построения системы, удовлетворяющей эти потребности. Чтобы успевллло справигься с задачей управления требованиями, группа разработчиков должна работать как настоящая команда.
Набор приемов 1. Анализ проблемы В части 1 рассматривались приемы, которые команда может применить для того, чтобы пшшть решаемую проблему до начала роэрабонаси ллрилозсения. Для этого мы предл<» жили использовать состоящий из пяти этапов метод анализа проблемы. 1. Достигнуть соглашения по определению проблелэьь 2. Выделить основные причины — проблемы, стоящие за проблемой. 3. Выявить заинтересованных лиц н пользователей, чье коллективное лгпенне в конечном итоге определяет успех или неудачу системы.
4. Определить, где приблизительно находятся границга реп~ения. 5. !!опять ограничения, которые будут наложены на команду и решение. Следуя этому процессу, команде будет легче справиться с предстоящей задачей— предложить решение рассматривоезит" проблемке Мы также отмечали, что для анализа проблелгы можно использовать самые разнообразные методы. В частности, мы рассмотрели моделирование бизнес-процессов, специальный метод анализа проблемы, который достаточно хорошо зарекомендовал себя для сложных информационных систем, осуществляющих поддержку ключевых бизнес-инф1клструктур. Команда лн» жег применять этот метод как для понимания путей развития данного бизнеса, так и для выявления, где внутри системы можно наиболее эффективно развернуть приложения.
Мы так. жс вьшс пили, что определенная нами бизнес-модель будет иметь параллельные конструшпли в программном приложении, н мы будем использовать эту общность при проектировании про. граммного обеспечения. Выявленные на данном этапе бизнес-прецеденты будут позднее применяться для определения требовшпгй к самому приложению. В программных приложениях, которые мы отнесли к классу встроенных систем, для анализа проблсллы применяются методы системной инженерии, позволяющие осуществить разбиение сложной системы на подсистемы.
Этот процесс помогает понять, где должны находиться программпыс приложения и каким общим целям они служат. При Глава эб. С чего начать Зб1 этом оказалось, что мы в чем-то усложняелг проблему требований, создавая новые под. системы, для которых в свою очередь нужно заниматься пониманием требований. Набор приемов 2. Понимание потребностей пользователей Мы начали часть 2 с рассмотрения трех "синдромов", которые значительно усложняют задачу понимания реальных потребностей пользователей и других заинтересованных лиц. Описание синдромов "да, но...", "неоткрытые руины" и "пользователь н разрабог чик" помогло нам лучше понять предстоящие проблемы и получить представление о том, в какой среде будут применяться методы выявления, разработанные для понимания потребностей пользователей.
Так как команды редко получают совершенные спецификации требований к создаваемой системе, они должны сами добмоажл информацию, необходимую им для успешной работы. Термин выявление шребооаннй очень точно отражает данный процесс, в котором команда должна играть более активную роль. Чтобы помочь команде решить эти проблемы и лучше понять потребности пользователей и друтих заинтересованных лиц, люжно использовать различные методы.
° Интервьюирование и анкетирование ° Совещание, посвященное требованиям ° Мозговой штурм и отбор идей ° Создание раскздровок ° Прецеденты ° Обыгрывание ролей ° Создание прототипов Хотя ни один метод пе является улливерсэльнылг, каждый из них позволяет лучше понять потребности пользователей и тем самым превратить "неясные" требования в требования, которые "лучше известны". Каждый из этих методов "срабатывает" в определенных ситуациях, однако мы отдаем предпочтение совещанию, посвященному требованиям, и мозговоллу штурму.
Набор приемов 3. Определение системы В части 3 мы перешли от понимания потребностей пользователя к определению решения. При этом мы сделали свои первые шаги из области проблемы, вотчины пользователя, в область решения, где наша задача состоит в том, чтобы определить систему для решения имеющейся проблемы. Мы поняли, что для сложных систем требуются всеобъемлющие стратегии управления информацией о требованиях, и рассмотрели несколько способов орлвнизации данной ин. формации.
Оказалось, что на сэмом деле существует информационная иерархия; она начинается с потребностей пользователей, передюпльлх с помощью функций, которые затем превра. знаются в более подробные требования к программному обеспечению, выраженные посредсг вом прецедентов нли традиционных форм описания. Эта иерархия отрахолет уровень абстракции при рассмотрении области проблемы и области решения. После этого мы рассмотрелп процесс определения отдельного программного приложения и затратили некоторое время на определение документа-концепции для приложе- 362 Глава 35. С чего начать пня такого типа. Мы считаем, что документ-концепция, модифицированный в соответ. стяни с конкретным содержанием программных приложений компании, является чрезвычайно важным, и его необходимо иметь в каждом проекте.
Мы также осознали, что без лидера- человека, который будет защищать требования к приложению и поддерживать потребностлл клиента и комшщы разработчиков — нельзя быль уверенным в том, что будут приняты необходимые жесткие решении. Возлюжно возникновение дрейфа требований, задержек, а также принятие неоптимальных решений, вызванное приближением срока окончания проекта.
Поэтому мы решили назначить лидера, который оу. дет владеть докумслпом-коььцспцисй н содержащпьпюя в псм фуниьл~яьпь В свою очередь, лидер и команда должны создать совет по контролю за ллзмсльспиюььл, который призван помогать лидеру в принятии действительно сложных репьсппй и гарантировать, что изменения требы навий будут приниматься только после их обсуждения. Набор приемов 4.
Управление масштабом В части 4, "Управление масштабом", л~ы выяснилн, что проблема масштаба проекта является весьма типичной. Проекты, как правило, иинциируются с объемом функциональных возможностей, вдвое превьппающим тот, который кол~энда может реализовать, обеспечив приемлемое качество. Это пе должно пас удивлять: заказчики хотят большего, маркетинг хочет большего и мы также желаем большего. Тслл не лленее палл пеобходнлю ограничить ссоя, чтобы иметь возможность предоставить в срок хоть чию-лядудь.
Мы !засслютрелп различныс л~стодьь задания очередности выполнения (приоритстон) и ввели повнтис базового уровня (сонместно согласованного представления о том, в чем будут состоять кльочевлле функции системы как рабочего продукта нашего проекта) — понятие,:ыдакяцес точку отсчета и ориентир для принятия решений и пх оценки. Если ььасп~тььб и со~ьутстнуюлллпс ожидания заказчиков прсвышшот реальные, в люоом случае придется сообщать некие неприятные новости.
Мы остановились на философии прпнлсчспня заказчика к процессу принятия трудных рсшсппй. В конце концов, мы являемся только исполнителями, а принимать решения должны наши заказчики, ведь это их проект, !!оэтому вопрос стоит так: что аблзаеильяа дььлжяо быть сделано и следующей всрспп при пмскьщихся ресурсах проектаз Даже н этом ель лае пам придется вести переговоры; в некотором смысле нся жизнь и, конечно, весь бизнес состоят из переговоров, н мы нс должны этому удивляться.
Мы кратко псречпглнлп некоторые приемы ведения псрсгонорон н пал~екнулзь, что опи могут понадобиться команде. 1!сльзя ожидать, что данный процесс полностью решит проблему масштаба, точно так жс как никакой другой процесс в отдельности не решит проблемы разработки приложений. Ио указанные шаги окажут заметное воздействие на размеры проблемы, позволят разработчикам приложения гкопцентрировать сноп усилия па критически важных подмножествах функций и в несколько приемов предоставить высококачсствсппыс системы, удовлетворяющие или превосходящие ожидания пользователей. ! !рпнлсченпс заказчика к решенило проблемы управления масштабом повышает ооязатсльстна сыьроп, способствует росту взанльоповпмания и доверня между заказчиком и коьландой разр.юотчнков приложения. Имея нссобъсьлллоплее определение п!ьодукта (документ-концепцию) и сократив масштаб проекта до разумного уровня, мы можсль надеяммл на успех в слсдузоьцпх фазах проекта.
Глава 35. С чего начать 363 Набор приемов Б. Уточнение определения системы В части б мы выяснили, что в требованиях должны быть возню и сжато зафиксированы потребности пользователей в таком вндс, чтобы разработчик люг построить удовлетворяющее их приложение. !<роме того, требования должны быть достаточно конкретными, чтобы можно было определить, когда опи удовлетворены.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
