Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 68
Текст из файла (страница 68)
Способность отслеживать отношения и находить их связи прн возникновении изменений яв. ляется основной нитью многих современных высоконадежных программных процессов, осо. бенно в медицине (устройства жизнеобеспечения) и др)тих критически важных областях. Причина в том, что, как свидетельствуют данные, касающиеся оезопасностн, воздействие изменения часто в полной мере не отслеживается и незначительные изменения системы могут вызвать значительные проблемы с безопасностью и надежностью.
Инструкции Управления по санитарному надзору за продуктами и медикаментами США (Г1)А) (Г1)А Ой)се оЕ Пег!се Ета!найооз (О1)Е) СнЫаосс 1Эосиогевг (1996, Ь) и Г!)А Сштеог Соос1 Мани(асгнппй Ргасцссз (ССМР) (Г)ЪА 1996, а) указывают на необходимость трассировки при проведении действий по разработке программного обеспечения лля медицинских целей. Стандарт 1ЕЕЕ (1994) предлагает два рабочих определения трассировки.
И4 Часть б. Построение правильной системы ° "Степень, до которой можно установить связь между двумя или большиьт числом продуктов процесса разработки, особенно продуктаьтн, которые являются по ог пснпспн|о друг к пруту ттредшсствуютттим-ттоследуюптиьт или главным-подчиненным; например, степень соответствия между требованиями и проектом конкретного программного компонента" (1ЕЕЕ 610.12-1990 03). ° "Степень, до которой кажный элемент пролукта программной разраоотки оправдывает слтысл своего существования; паприьтер.
насколько калсдый элемент схемы, изображаемой кружками и стрелками, соответствует удовлетворяемому им трсбо. вопию" (!1 ЕЕ 6! 0.12-1990 03). Ключсвыьт элементом трассировки является "отношение трассировки" (ггассаЬт!н) ге!айопк1нр). Удобно опрсдслттть это отношение с помощью простой околели, использующей понятия "трасснрустся к" (тгасебчо) "трассируется от" (тгасет14тотп). Например, одно или несколько требований к программному обеспечению создаются с целью поддержки нской функции, заданной в документе-концепции.
Можно сказать, что программное требование трассир>ется от некоторой функции (рис. 31,1). Докуиенгконцопцип (функции) Трассироаочнао сонзь Протраннное тробовомм (прецедент) Рттс. з1.1. Трасси~овочиаа саиь ож документа. конвенции к ороероммиому ит)эебооонию В зависимости от типов создаваемых требований данное отношение приобретает до. полнитсльный смысл.
Например, то, что некос требование к программному обеспечению "трассирустся к" определенному тестовому примеру, означает, что данное требование "тсстирустся" этилт тестовым примером. То, что описание объекта "трассируется от" конкретного программного требования, подразумевает, что это требование "реализуется" указапныьт объсктоьт. Мсхтду этими элементами проекта иьтсются отношения вида одинко-мпогим, многие-к-одному н многие-ко-многим. Основываясь па том, что говорилось о различных средствах выражения требований и их организации (глава 2э), можно считать, что структура проекта с полныьт набором отношений будет выглядеть так, как показано на рис. 31.2. Неявнаяиявнаятрассировка На рис.
31.2 видно, что команда разработчиков явным образом задает отношения ьтежду элеьтснтами. Это лвнал отутасстт)ровна — разработка отношений, основанная на соооражспиях команды. Например, связь, или отношение, между функцией продук- Глава 31. Использование трассировки для поддерзгки верификации 313 та и прецедентом, осуществляющим полдержку этой функции, определяется исклю- чительно ретцепием команды о том, что такое отношение имеет смысл.
Не существу- ет внутренне присущей элементам связи между ними; только внешние реятсния мо- гут привести к заданию этой связи. Замечание. Эта трассировочная связь является необюательной,так какое можно полумть из связи между функцией продукта и разделом прецедентов. Данная связь часто используется для того, чтобы связать функции продукта с прецедентами до написания раздела прецедентов трасси руется к сируется к трассируется к трассируется к Прецеаент раздел прецедентов .Ъс. 31.2. Оимнмиенми итрассмроеггм между елсмемтамм препона Структура модели может обеспечить неявные отношения трассировки, С другой стороны, методология и структура модели могут задавать неявные отношения итрассмроехм. Например, в части 5 обсуждалось понятие "дочерних" требований; между ними и "родительскими" требованиями существуют формальныс иерархические отношения.
В этом случае существуют неявныс отношения трассировки между родительскнлти и соответствующими дочерними требованиями. Такое неявное отношение нет необходимости задавать в виде явного; более того, его не сеедуеги задавать явно, иначе могут возникнуть недоразумения. Неявная трассировка может также возникнуть вследствие использования определенной парадигмы моделирования. Например, применяемые в процессе разработки инструментальные средства моделирования лтотч г автоматически обеспечивать отношения трассировки между моделируемыми элементами. Если средство моделирования обеспечивает неявные связи между элементами модели прецедента и взаимодействующими с прецедентом акторами, сутцествует реальная возможность использовать этн пеявныс отношения трассировки.
Можно продолжить зту трассировку далее к реализации, трассируя кооперации прецедентов к объектам реализации. В конечном счете, различие между двумя классами трассировки невелико. Едтттгствегтттое, что мы хотели бы посоветовать, это убедиться, что вы знаете о всех формах трассировки, предлагаемых вашими автоматическими средствами моделирования. Если опи дсйствигелыю предлагают определенные формы неявной трассировки, используйте их. Если в интересую. щих вас областях средства не обеспечивают неявную трассировку, вам понадобится создать явные трассировочные связи, необходимые для поддержки ваших действий. 316 Часть 6.
Построение правильной системы Дополнительные возможности, предоставляемые трассировкой Трассировка зачастую помогает понять друтне части проекта. Мы в своей практике часто вносили в проект менее традициоппыс элементы и включали их в процессы трассировки, поскольку онн оыли полезны для понимания проекта. 11апример, иногда полезно определить новый элемент, назвав его "спорный вопрос", и хранить всс текущие нерешенные вопросы как подобные влез|гиты проекта.
Используя трассировку, можно связать спорные вопросы с пунктамц, где они упоминаются. Например, если есть нерешенный вопрос о функциональных возможностях продукта, можно связать его с соответствующими функциями продукта и требованиями к программному обеспечению. Поддерживая связи "спорных вопросов, можно потом легко вернуться назад и найти все элементы проекта, связанные с вопросом, который только что решен. В процесс трассировки проекта можно также включить следующие элементы.
° !1редположения и объяснения ° Элементы действий ° Запросы па поные/цсрссз1отрснные функции ° Термины глоссария и акронимы ° Библиографические ссылки Друтимп словами, трассировку можно использовать для того, чтобы понять отноп~е. ния между элсмснтамн проекта. Пусть воображение поможет вам добавить такие элементы, которые позволят вашей команде лучше понять проект. Трассируйте все полезные отношения.
11апример, существует нерешенный вопрос относительно определения некоего элслюснта глоссария. В таком случае можно связать вопрос с элементолю глоссария (и, возможно, другими функциями), Это будет служить полезным напоминаписл~ команде, что в проекте все еще существуют нерешенные вопросы. Дополнительные элементы можно добавить к типичной структуре трассировки, как показано на рис.
31.3. Всегда следите за балыком важности элементов трассировки и затрат на нх поддержку. Прадуярсждение. Не следует злоупотреблять этилзи элементами. Мы обнаружили, что добавление слишком большого числа таких элементов в процесс трассировки делает сго поддержку обременительной. Как и всегда, нужно стремиться к разумному балансу междт важностью дополнительных элементов, которые вы хотите трассировать, и затратамп па пх поддержку. Использование автоматических средств трассировки Мощпыс ппструментальпыс средства разработки программного обеспечения предлагают простые осуществляемые пользователем процедуры "указать и щелкнуть" для зада.