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