Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 60

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 60)

Возможность трассировки имеет огромное значение. Разработчики могут использовать ее как для достижения лучшего понимания проекта, так и для обеспечения более высокой степени уверенности, что все требования выполняются данной реализацией. На. пример, мы испольэовали полную трассировку, чтобы соединить все элементы одного нашего медицинского проекта (среди которых были элементы документа-концепцни, элементы ЯКБ, тестирования, кодирования и ревизии проекта), которые возникалн на протяжении жизни проекта. Когда все этн элементы взаимосвязаны, разработчики гораздо лучше подготовлены к управлению взаимодействиями между ними.

Трассировка также позволяет команде решать вопросы "что, если...". ("Что, если мы примо сейчас изменим это требование? Повлияет ли это на разработку программы, и, если да, то на какие элементыг Придется ли нам пересматривать планы тестирования, н, если да, то какие?") В том же проекте мы создавали маланям жросси)заели, требуемые Р))А для того, чтобы удостовериться, что продукт соответствует ее собственным требованиям. Матрицы трассировки — бесценный способ "проверить" действия по разработке и убедиться, что вы делаете все необходимое (и не делаете того, что делать не следует). Мы проведем масштабное исследование возможностей трассировки в части 6. Понимаемые требования Множество требований является вонимаеммн, если пользователи и разработчики способны прийти к полному согласию относительно отдельных требований и общих функциональных возможностей, подразумеваемых данным множеством.

В документах, описанных в предыдущих главах данной книги, основное внимание уделяется общим описаниям и функциям системы, и их понять, как правило, не сложно. Но по мере уточнения определения системы, т.е. при разработке детальных требований, элементы ста. новятся все более конкретнзированными и детализированными и возникает искушение использовать более специальные термины. Таким образом, человек. который пишет тра бования.

должен знать терминологию обеих сторон.участниц. Валсно также, чтобы те, х76 Часть 5. Уточнение определения системы кто пользуется набором требовю~ий, могли понять поведение системы в целом. Этого можно добиться с помощью раскадровок, сценариев или иллюстративньш прецедентов, которые показывают, как предполагается использовать систему в ее операционной среде. Показатели качества для модели прецедентов Замечание. В этом разделе обсуждается широкий спектр вопросов, связанных с прецедентами.

Иногда элемент контрольного перечня будет со. держать ссылки па специфические элементы прецедента, которые не об. суждались в данной книге, так кэк они не очень важны для управления требованиями. Чтобы изучить эти вопросы, можно обратиться к соотвег ствующей литературе, посвященной прецедентам.

Мы рекомендуем две книги: Буч (ВоосЬ, 1999), а также Джейкобсон, Буч и Рамбо ()асоЬзоп, ВоосЬ, КпшЬапкЬ, 1999). ° Все ли прецеденты найдены? Выявленные прецеденты должны иметь возможность осуществить все варианты поведения системы; если это не так, значит, некоторые прецеденты пропущены.

В Все ли функциональные требования описываются прецедентами? Если вы иаме. ренно отложили некоторые требования, чтобы заняться ими при объектном моде лированин (например, нефункциональные требования), это необходимо гдето отразить. Если подобное требование затрагивает конкретный прецедент, это еле. дует отметить в специальном разделе данного прецедента (Специальные требования, прес)а1 Ке9п)гетепгз). ° 11е содержит ли модель прецедентов ненужное поведение.

т.е. не представляет ли болыяе функций, чем указано в требованиях? ° Действительно ли в модели необходимы все выявленные связи включения, пасхе. дования и генерализации? Если это не так, они могут быть избыточными, и их следует удалить. ° Зависят ли связи модели друг от друга? Важно, чтобы этого не происходило, по. этому нужно проверить это. ° Правильно ли произведено деление модели на пакеты прецедентов? Стала ли мо- дель в результате проще и удобнее для восприятия и сопровождения? ° Можете ли вы, изучив модель прецедентов, составить четкое представление о функциях системы и о том, как они связаны? ° Содержит ли введение (1пггодпсйоп) к модели всю необходимую информацию? ° Содержит ли общее описание (бпгтеу 1)езсг)рйоп) модели прецедентов всю необходимую информацию; например, представлены ли там наиболее типичные последовательности прецедентов? Спецификации прецедентов ° Кюкдый ли прецедент имеет хотя бы один актор? В противном случае пото непра- вильно; прецедент, который не взаимодействует ни с одним актором, следует удалить.

Глава 27. Критерии качества требований к программному обеспечению 277 Все ли прецеденты независимы друг от друга? Если два прецедента всегда активизируются в одной и той же последовательности, возможно, их удастся объединить в один прецедент. Естьли прецеденты с очень похожим поведением или похожими потоками событий? Если да и вьг хотите, чтобы их поведение оставалось таким же и в будущем, ну~кно объ единнть их в единый прецедент.

Тогда в будущем будет проще производить необходимые изменения. Заяэчаняе. Если вы принимаете решение о слиянии прецедентов, не. обходимо проинформировать об этом пользователей, так как зто может оказать влияние на тех из них, кто взаимодействует с объединяемыми прецедентами. Не получилось ли так, что часть потока событий уже моделировалась в качестве другого прецедента? Если да, то можно в новом прецеденте использовать старый.

Не является ли часть потока событий частью другого прецедента? Если да, то следует выделить этот субпоток и предоставить воэможность рассматриваемым прецедентам испольэовать его. Замечание. Необходимо проинформировать пользователей при' принятии решения "повторно использовать" субпоток, так как это мо.

жег повлиять на тех из ннх, ато использует существующий прецедент. Будет ли поток событий одного прецедента включаться в поток событий другого? Если да, зто следует моделировать с помощью отношений наследования прецедентов. (Мы не обсуждали этот вопрос, так как он не был столь важен для общей концепции прецедентов.) Имеют ли прецеденты уникальные, понятные и содержательные имена, чтобы не перепугать их' на последующих этапах? Если нет, имена следует изменить.

Понимают ли пользователи и клиенты имена и описания прецедентов? Каждое имя должно описывать поведение, поддерживаемое соответствующим прецедентом. Удовлетворяет ли прецедент все требования, которые очевидным образом рег?- лируют его выполнение? Можно включить любые нефункциональные требования, описанные в других частях пакета Модегп ЯЮ Рас1саяе. Соответствует ли последовательность взаимодействий автора и прецедента ожиданиям пользователя? Понятно ли, как и когда начинается и заканчивается поток событий прецедента? Может существовать поведение, которое активизируется только в случае невыполнения некоторого условия.

Есть ли описание того, что произойдет, если данное условие не выполняется? Нет ли слишком сложных прецедентов? Если вы хотите, чтобы модель прецедентов можно было легко понять, нужно расщепить" сложные прецеденты. Содержит ли прецедент раздельные потоки событий? Если это так, лучше разделить его на два нли более отдельных прецедентов. Прецедент, содержащий независимые потоки событий, очень сложно понимать и обслуживать. Тщательно ли смоделирован субпоток событий в прецеденте? Ясно ли, кто хочет выполнять прецедент? Понятно ли назначение прецедента? Понятны ли взаимодействия с ахторами и обмен информацией? Передает ли краткое описание истинную природу прецедента? 278 Часть Б.

Уточнение определения системы Акторы прецедента ° Все ли акторы найдены? Иными словами, все ли роли в окружении системы учтены и смоделированы» Несмотря иа проводимые проверки, нельзя быть уверенным в этом до тех пор, пока не будут найдены и описаны все прецеденты. ° Каждый актор должен входить, по крайней мере, в один прецедент. Акторы, кото. рые ие упоминаются в описаниях прецедентов или ие имеют коммуникационных связей с прецедентами, нужно удалить.

Но аатор, упоминаемый в описании прецедента, скорее всего, имеет с иим некую связь. ° Можете ли вы назвать хотя бы двух человек, которые смогут выполнять действия, как конкретный актор» Если нет, проверьте, ие является ли роль, моделируемая автором, частью другой роли. Если это так, следует произвести операцию слияния акторов. ° Есть ли акторы, играющие аналогичные роли по отношению к системе? Если это так, их следует объединить.

Коммуникационные ассоциации и описания преце. деитов показывают, как взаимосвязаны акторы и система. ° Если два актора играют по отношению к прецеденту одну и ту же роль, иеобходи. мо использовать ген ералиэацию для моделирования их общего поведения. ° Если некий эктор использует систему с помощью нескольких полностью отличных способов или имеет несколько совершенно различных целей при использовании прецедента, то, вероятно, вы имеете дело с несколькими авторами.

Характеристики

Список файлов книги