Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 73
Текст из файла (страница 73)
Этот подход заслуживает внимания при условии, что элементы пропускаются по весомым причинам, не связанным с недостатком времени или денег. Если элементы не подвергаются Ч$сЧ, важно документировать причины этого. Существует опасность, что могут быть не выполнены ЧдсЧ-действия по отношению к элементу проекта, который вдруг окажется более важным, чем предполагалось изначально. Это может иметь перечисленные ниже последствия. ° Элемент не будет соответствовать спецификации клиента (как следствие — необ. ходимость неоплачиваемой переработки этой части системы).
° Элементы буд)т работать не так, как полагается согласно спецификации (следствие — дорогостоящий отзгвв изделий). ° Наихудший случай: в результате получится небезопасыый продукт, который может принести вред пользователям. Таким образом, даже в случае неформального выборочного сокращения ЧдсЧ- действий существует вероятность непредусмотренного развития событий.
Но если в крупных проектах не практикуется тотальное проведение ЧдсЧ, а необходимо гарантировать высокое качество, то как ревгить, какие элементы важны для ЧдсЧ- процесса, а какие — нет? Для ответа нам нужно обратиться к варианту 2. Вариант 2. Анализ рисков для определения необходимости чбсч' Одним из систечатических подходов к выявлению важных элементов проекта является анализ рисков (Ьэзагг( апа1уз!з) и связанные с ним действия по оценке рисков.
Мы не будем углублятыя в эти дисциплины в данной книге, но представим краткий обзор основных понятий. Регулирующие органы, такие как Р()А (Управление по санитарному надзору за продуктами и медикаментами США), рассматривают анализ рисков как ключевой фактор улучвзения качества продукта. Современные инструкции содержат целые разделы, посвященные оцеыке и анализу рисков. В частности, Вуд и Эрмс (аоод, Еппег, 1993,а) предложили полезное определение анализа рисков для медицинского продукта. Анализ )зисхое п)мдстааляет сойй под(зобное исследование гз)зибфа с точки з)зо нил палъзованмлл и пациента.
Его цель состоит в вьимлении потенциальных недсрабоонт пфоектиования (возмозкностей отказа, котс)гые могут принести в(зед) и п)зедоставлезгии пяоизводителю возмолсности исправить их до того, как ггриб'выбудет зануяген в зфоизеодство. Разработчик должен рассмотреть различные типы ошибок. которые могут возникать в создаваемом продукте. Все потенциальные риски исследуются и фиксируются в специальном документе, что позволяет разработчику предложить стратегии проектирования, которые помогуг их избежать. Глава 33. Применение метода анализа дивидендов для определения...
339 На последующих стадиях жизненного цикла разработки продукта документ анализа рисков будет служить для фиксации как потенциальных рисков, так и методов, применяемых для их уменыпения. Позднее при проверке правильности системы данный доку. мент используется для того, чтобы убедиться, что все предполагаемые риски полностью учтены и устранены, а тестирование будет преимущественно направлено на эти области, для достижения более высокой степени гарантий. Конечно же, анализ рисков можно применять не только к системам, в которых опас. ности подвергается жизнь людей (медицинским, транспортным илн промышленным).
Следует применять его повсюду, где, по вашему мнению, наиболее велик риск сбоев в системе. Например, в системе интерактивной торговли анализ рисков может быть направлен на то, чтобы "гарантировать, что предоставленная заявка является правильной", или "проверить число введенных пользователем акций". Телекоммуникационная компания может уделять основное внимание риску "катастрофического сбоя программы управления коммутацией".
В любом случае анализ рисков используется для того, чтобы решить, какие риски не. обходимо предотвратить в системе и каков объем необходимых для этого Ч8сЧ-действий. Для элементов проектирования, имеющих, согласно долумепту анализа рисков, большое значение для общей безопасности и успеха разработки, следует обеспечить проведение полномасштабных Ч8сЧдействий. Для алементов, имеющих меньший или незначительный риск, можно уменыпить объем Ч8сЧ-действий или вовсе пропустить их, хотя общее тестирование системы все равно необходимо.
Анализ рисков служит руководством при выборе элементов проекта для проведения ЧЙЧ. Анализ рисков можно испольэовать прн выборе элементов проекта, нуждающихся в верификации. Независилю от верификации, анализ рисков может также служить рукове дством при выборе тестов и тестового покрытия при проверке правильности. Нет правила, требующего тесной связи верификации н проверки правильности, поэтому команда может использовать результаты анализа рисков для независимой разработки планов верификации и проверки правильности. Анализ рисков и анализ дивидендов (КО1) Можно рассматривать анализ и оценку рисков, интерпретируя нх как стандартный анализ затрат/прибыли, и использовать результаты анализа рисков в качестве исходной информации для стандартного анализа дивидендов (геев гп оп 1м езппеш, ((О)), Сначала производятся оценки затрат (времени, ресурсов и денег) для действий по проверке некоего элемента нли сегмента проекта. Этн затраты вводятся в стандартные зкономические модели КО(, чтобы получить представление о затратах этапа.
Затем выполняется оценка возможного воздействия предварительно выявленных в результате анализа рисков негативных последствий, которые могут возннкп)ть прп неправильной работе элемента, не подвергавшегося Ч8сЧ. После сравнения двух получецных результатов можно принять обоснованное рея~ение о том, стоит лп проводить Ч8сЧ-действия и какой должна быть их глубина. Во многих случаях анализ показывает, что решение "да/пет" слишком упрощенное. Гораздо более типичная ситуация, когда одна часть Ч8сЧ-действий для сегмента эффек- 340 Часть б.
Построение правильной системы тивна, а другая — нет. В таких случаях, возможно, стоит рассмотреть модифицированную стратегию ЧгЛ, чтобы оптимизировать дивиденды от произведенных затрат. Всегда необходимо выполнять анализ рисков для аспектов, имеющих отношение к безопасности людей. Следует понимать, что вычисление дивидендов отличается от анализа безопасности и эффективности.
Например, анализ рисков может показать, что с определенной частью разработки и реализации программы связана проблема, касающаяся безопасности людей. В таких случаях просто недопустимо игнорировать факторы безопасности иэза размеров дивидендов. Следует всегда прогадать полный пика 7со'Ъ'огйсвиий по отпошгнию к сегментам пРогкта, гатРагиоаюогим пРобммм йвопаспосюи людей. ггрутими словами, ВОР методы — это только вопрос финансовых затрат проекта.
Если на карту поставлены во. просы безопасности и эффективности, необходимо использовать анализ и оценку рисков. Если это уместно, можно применять комбинацию различных методов. Далее.. Итак, посмотрим, чего мы достигли. ° Мы задали способ. который позволяет рассматривать и использо. вать артефакты требований в качестве основы при проектировании и реализации системы. ° Мы применили методы верификации, чтобы убедиться, что каж- дый вшг проекта трассируется к более ранним шагам. ° Мы описали два процесса проверки правильности (тестирование и приемо-сдаточные испытания), совместное применение которых помогает убедиться, что в результате реализации получилась работоспособная система. ° Мы исследовали методы оценки и анализа рисков, которые помогают принять решение, как наиболее эффективно использовать ресурсы проекта. Единственной нерассмотренной темой осталась проблема изменений.
В следующей главе мы научимся, как справляться с изменениями и правильно их обрабатывать в ходе разработки проекта. Глава 34 Управление изменениями ' Основные положения ;. ° Процесс управления требованиями может быть полезным только в том случае, если он позволяет распознавать и решать проблему измеиегп~й. ' ° Внутренними факторами, приводящими к возникновению изменений, явлщотся неспособность задать нужные вопросы нужным людям в нужное время и отсутствие практического процесса, призванного справиться с изменениями требований. , И Чтобы повысить шансы иа успех, необходимо предотвратить "просачивание" , требований илм, по крайней мере, существенно уменыпить его.
Почему изменяются требования Если бы можно было раэ и навсегда опредекнэь л~ножество требований к системе, жизнь была бы намного проще и данная глава была бы не нужна. Мы бы просто создали совершенный документ-концепцию, совершенную спецификацию программных требований и модель прецедентов, заморозили бы их на время разработки, а затем объявили, что за все, что про изошло после этого, отвечает команда сопровождения. Увы, тэк не бывает; так никогда ие было и ие будет даже при самом систематическом подходе к управлению требованиями. Есть несколько причин неизбежности изменений требований. Среди них внутренние факторы, которые мы можем контролировать, и внешние, которые нс подвластны контролю со стороны разработчиков и пользователей.
Внешние факторы Внешними факторами являются те источники изменений, которые команда проекта пе люжет контролировать. Вне зависимости от того, как мы справимся с пнин, необходимо подготовиться технически, эмоционально и методологически, чтобы воспринять эти изменения как часть "нормального развития событий прн разработке программного обеспечения". Изменения возникают по следующим причинам. ° Произошли кзмекищия лроблскм, которую мы пытались решить с помоьчью новой систел~ьь Возможно, возникли изменения в экономике, в правительственных ип.
струкциях, на рынке илн же изменились предпочтения потребителей. Из-за оыстрых темпов развития технологии сейчас становится все более вероятным, что такие изменения произойдут до того, как мы закончим рещение исходной проблемы, описанной пользователем. 342 Часть 6. Построение правильной системы ° Пользователи шменил»» свое мнение о том, чего они хотят от системы, или свои предпочтения. Это, в свою очередь, может произойти вследствие ряда причин: не только иэ-за непостоянства пользователей (которое особенно ярко проявляется при спецификации деталей интерфейса человек/система), но и из-эа того, что их предпочтения зависят от ситуации па рынке, экономики, различных инструкций и т.д.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
