Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 46
Текст из файла (страница 46)
Если функции были праввсльно выбраны и упорядочены, это позволит заказчилу достичь своих целей, по крайней мере частично, в то время как команда продолжит работу нал итерациями разработки. Если архитектура устойчива и отвечает осцовиым техническим требованиям, у команды будет надежная зклат форма Лля предоставления дополнительных функциональных возможностей. Что делать, что делать... Независимо от того, какая молсль используется, комапяа должна предложить по крайней мере олин устойчивый оценочный прототип Лля раннего получения реакции клиента. Олни из прслпосылок данной книги состоит в том, что раннее получение реакции "да, цо..." является одной из самых главных задач в процессе разработки программного обеспечения. ° Сколько раз прилется делать прототип? ° Изменяются ли требования заказчика для каждого нового прототипа? ° Обречены лп мы па неудачу, независимо от того, какому процессу следуем? Глава 22. Управление масштабом и модели процесса разработки...
221 Ответы таковы. Да, клиенты будут требовать изменений при каждом представлении. Нет, мы не обречены. Причина в том, что проблемы. связанные с внесением изменений, которые возникают после того, как клиент имеет возможность увидеть предлагаемую реализацию и поработать с ней, невелики по сравнению с важностью отзыва клиента на первый осязаемый артефакт процесса. Такнгз образом, хотя мы предпочитаем использовать в наших разработках итеративную модель, независимо от того, какую модель процесса разработки используете вы, не.
обходимо обгсгичить создание но крайней за)эе одного устойчивого окгночного прснютина для получении реакции клиента до того, как будет выполнен основной объем действий по проектированию и написанию программного кода. (Помните о действиях по созданию прототипа, которые Ройс (Коусе, 1970) изначально предлагал для модели водопада?!) Благодаря уменыпенню числа изменений до разумного уровня разработчику удается путем внесения инкрементных изменений (как правило, в интерфейсы пользователя, отчеты и другие выходные результаты) создать качественный устойчивый технический про екг и реализовать его. Затем пцательно организованный процесс завершения проектирования, кодирования, тестирования компонентов и сборки системы обеспечит для продукта прочный фундамент и в значительной мере будет способствовать действиям по обеспечению качества и тестированию.
222 т2асть 4. Управление масштабом В части 4, "Управление маспггабом", мы выяснили, что проблема масштаба проекта является весьма типичной. Проекты, как правило, инициируются с объемом функцио. нальных возможностей, вдвое превышающим тот, который команда может реализовать, обеспечив приемлемое качество. Это не должно нас удивлять: заказчики хотят большего, маркетинг хочет большего и мы также желаем болынего. Тем не менее, нам необходимо ограничить себя, чтобы иметь возможность предоставить в срок хоть что-нибудь Мы рассмотрели различные методы задания очередности выполнения (приоритетов) и ввели понятие базового уровня (совместно согласованного представления о том, в чем будут состоять ключевые функции системы как рабочего продукта нашего проекта) — по.
пятне, задающее точку отсчета и ориентир для принятия решений и их оценки. Если маспгтаб и сопутствующие ожидания превышают реальные, в любом случае придется сообщать некие неприятные новости. Мы остановились на философии привлечения заказчика к процессу принятия трудных решений. В конце концов, мы являемся только исполнителями. а принимать решения должны наши закаэчики, ведь зто их проект. Поэтому вопрос стоит так: что обяэаямлькл даикно быть сделано в следугощей версии прн имеющихся ресурсах проекта? Даже в этом случае нам придется вести переговоры; в некотором смысле вся жизнь и, конечно, весь бизнес состоят из переговоров, и мы не должны этому удивляться. Мы кратко перечислили некоторые приемы ведения переговоров и пючекнули, что они мог)т понадобиться команде. Нельзя ожидать, что данный процесс полностью решит проблему масштаба, точно так же как никакой другой процесс в отдельности не решит проблемы разработки приложений.
Но укаэанные шаги окажут заметное воздействие на размеры проблемы, позволят разработчикам приложения сконцентрировать свои усилия на критически важных подьпюжествах функций и в несколько приемов предоставить высококачественные системы, удовлетворяющие илн превосходящие ожидания пользователей.
Привлечение закаэчика к решению проблемы управления масштабом повышает обязательства сторон, способствует юаимопониманию и доверию между закаэчиком и командой разработчиков приложения. Имея всеобъемлющее определение продукта (документ.концепцию) и сократив масштаб проекта до разумного уровня, мы можем надаюиьгл на успех в следующих фазах проекта. Часть Б Уточнение определения системы И Глава 23. Требования к программному обеспечению И Глава 24.
Уточнение прецедентов ° Глава 25, Спецификация требований к программному обеспечению (Мойегп Бойь аге Кес~шгегпепа Брес1псаноп) ° Глава 26. Неоднозначность и уровень конкретизации И Глава 27. Критерии качества требований к программному обеспечению ° Глава 28. Теоретически обоснованные формальные методы спецификации требований 224 Часть 5.
Уточнение определения системы Предыдущие части были посвящены анализу проблемы, выявлению потребностей пользователей, сбору и документированию желаемых функций продукта и управлению ими. После того как функции продукта определены, следующая задача состоит в угочпе. нии спецификации до уровня детализации, пригодного для проведения процессов проектирования, написания программного кода и тестирования. Мы оказываемся в самой середине пирамиды требований, па уровне спецификации, как показано иа рисунке.
.р,~" "',и зч Прослемнал 'ЛР~лйлилг:л ", область Парями да требований В части б будут обсуащаться методы исследования и организации требований к программ. ному обеспечению, а также способы доведения их ло всех участников. Часть завершается рассмотрсиисм одной из важнейших тем как сформулкревалль лфеболания ко~ютлко н ястю. Независимо от того, каким методом вы пользуетесь для сбора требований, необходимо помнить, что тбрлняыл эяРплманлл ~к глалько онк!) шлужат движущей силой проекта.
Если ока. жется, что оци недостаточны или даже ошибочны, их нужно быстро и официально изменить; так что правило остается в силе. При таком подходе вся команда имеет перед собой ясную цель и может сосредоточить свои усилия иа выявлении и реализации требований, сократив время, потраченное напрасно. Начнем с изу ~сипя самой природы требовшппь Глава 23 Требования к программному обеспечению '; Основные положения, : ° Полный набор требований можно получить.
определив вводы, выводы,' р ' 'функции и атрибуты системы, а тахже атрибуты ее окружения. ° В требования не следует включать общую информацию (графики, планы 'разработки, выделенные средства, тесты), а также информацию, касающуюся проектирования. ° Процесс разработки требований/проектирования является итеративным; вы; явленные требования ведут к выбору конкретных вариантов проектирования, которые в свою очередь приводатк возникновению новых требований. ; ° Ограничения проектирования касаются вариантов проектирования системы или процессов, с помощью которых система разрабатывается.
В предыдущих частях мы намеренно оставили определенные для системы функции на высоком уровне абстракции с тем, чтобы удобнее было выполнить следующие действия. ° Понять форму системы, сосредоточив внимание иа ее функциях и иа том, как оии выполняют потребности пользователя. ° Оценить полноту н целостность системы, а также ее соответствие среде. ° Использовать данную информацию для определения возможности построения системы и управления се масштаболг перед тем, как будут производиться значительные инвестиции. Кроме того, оставаясь на высоком уровне абстракции, мы воздерживаеьюя от преждевременного принятия чрезмерно ограиичителыгых решений по требованиягк т.
е. до того, как люди, непосредственно занимающиеся реализацией системы, получат воэможность внести свой вклад в определение системы. В части э, "Уточнение определения системы," мы перехо дим к разработке функций системы до уровня детализации, достаточного, чтобы гарантиро. вать, что в ходе проектирования и кодирования будет создана система, полностью соответст. вукяпэя потребностям пользователя. При этом мы переходим па следъэощий уровень конкре. тиэации и создаем более полную, глубокую модель требований к разрабатываемой системе. Конечно, количество информации, которой пало управлять, также увеличивается, и нам ие.
обходимо подготовиться к работе с пей. 226 Часть 5. Уточнение определения системы Уровень конкрстнзжппп необходимый на этом шаге, зависит от множества факторов, среди которых содержание приложения и профсссиональныс навыки команды разработчиков.
Для высокобсзопасных систем программного обеспечения в медицине, авиации цли интерактивной торговле уровень конкретизации особенно высок. Процесс уточнения может включать в себя использование формальных средств обеспечения качества, просмотры, ревизии, моде. лированис н т.п.
В системах, где последствия сбоев не столь катастрофичны, уровень трудоемкости более умеренный. В этих случацх просто необходимо сформулировать определение системы достаточно четко, чтобы сто могли повять все участники процесса, а также для того, чтобы обеспечить эффективные условия разработки и "достаточно высокую" вероятность ус. псла.
Руководствуясь прагматическими и экономическими соображениями, следует создать достаточное количество спспификапий треоований, чтобы разрабатываемая программа была именно тем, чего хочет пользователь. Точно так жс, как не существует языка программирования, подходящего для всех без исключения приложений, нет и универсального способа разработки более детальных спецификаций, В различных средах требуются различные методы, н тем, кто пишет требования и управляет пми, необходимо овладеть разнообразиыл~и профессиональными приемами. Нам приходилось а своей практике применять множество методов — от применения дое,' 'м"':,~!':.
~ таточно строгих документов требований, традиционных баз данных * ~ или архивов требований до использования моделей прецедентов и более формальных методов. Но всегда главное внимание уделялось спецификации на естественном языке, написанной достаточно ясно, чтобы сс могли понять все заинтересованные лица, заказчики, пользователи, раэработ чики и тсстологи, но также достаточно конкретно ("Максимальиая горизонтальная ско. рость оси 4 должна составлять 1м/с"), чтобы можно было выполнить верификацию и продемонстрировать соответствие.
Перед тем как организовывать требования к системс, рассмотрим саму природу этих требований. Определение требований к программному обеспечению В главе 2 мы дзлп следующее определение требования. ° Некос свойство программного обеспечения, необходимое пользователю для ре- шения проблемы при лостижспип поставленной цели. ° Некос с~юйство программного обеспечения, которым должна обладать система плп сс компонент, чтобы удовлетворить требования контракта, стандарта, спспнфпкацнн либо пиой формалыюй документации, Требовании к яро!льмккоку обсслгчскпю — это то, что данная программа делает для пользователя, прибора плп дру ой системы. Начинать их поиск следует среди того, что "входит" в систему и "выходит" нз нес, т.с.
необходимо рассмотреть взаимодействия системы с сс пользоватслямп. Для этого проще всего сначала представить ссбс систему как некий черный ящик и подумать о том, что следует определить, чтобы полностью описать, что делает этот черный ящик. Глава 2В.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
