Главная | Обратная связь | Поможем написать вашу работу!

Управление изменениями требований

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

Рис. 6.15. Управление изменениями требований

Процесс управления изменениями состоит из трех основных этапов.

1. Анализ проблем изменения спецификации. Процесс начинается с определения проблем в требованиях или с прямого предложения внесения изменений. На этой стадии проблема или предложенные изменения анализируются для проверки их обоснованности. Затем могут быть сделаны более определенные предложения относительно изменений в требованиях.

2. Анализ изменений и расчет их стоимости. Эффект от внесения предложенного изменения оценивается с использованием оперативного контроля. Стоимость изменений оценивается двумя показателями: стоимостью внесения изменения в спецификацию и стоимостью внесения изменений в структуру системы и непосредственно в программный код. По окончании этого этапа принимается решение, продолжать или нет внесение изменений в систему.

3. Реализация изменений. Реализация изменений в системной спецификации, структуре системы и программном коде.

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

КЛЮЧЕВЫЕ ПОНЯТИЯ

• Процесс разработки требований включает анализ осуществимости создания системы, формирование и анализ требований, специфицирование требований, аттестацию требований и управление требованиями.

• Анализ требований является итерационным процессом, который включает анализ предметной области, сбор требований, их классификацию, разрешение противоречий, назначение приоритетов и проверку требований.

• Лица, участвующие в формировании требований, имеют различные приоритеты при формулировании требований. Поэтому сложные системы ПО необходимо анализировать с различных точек зрения.

• Социальные и организационные фактору оказывают большое влияние на системные требования.

• Аттестация требований – процесс требований на достоверность, непротиворечивость, полноту ивыполнимость. Обзоры требований и прототипирование являются основными методами аттестации требований.

• Процесс управлений требованиями включает планирование управления, где определяется стратегияи процедуры управления требованиями, и непосредственно управление изменениями, где осуществляется анализ изменений и контроль за их реализацией.

Упражнения

6.1. Предложите, кто бы мог участвовать в формировании требований для университетской системы регистрации студентов. Объясните, почему почти неизбежно, что требования, сформулированные разными лицами, будут противоречивы.

6.2. Разрабатывается система ПО для автоматизации библиотечного каталога. Эта система будет содержать информацию относительно всех книг в библиотеке и будет полезна библиотечному персоналу, абонентам и читателям. Система должна иметь средства просмотра каталога, средства создания запросов и средства, позволяющие пользователям резервировать книги, находящиеся в данный момент на руках. Определите основные опорные точки зрения, которые необходимо учесть в спецификации системы, и покажите их взаимоотношения, используя диаграмму иерархии точек зрения.

6.3. Для трех точек зрения, определенных в системе библиотечного каталога, укажите сервисы и соответствующие данные, которые обеспечиваются этими точками зрения, и события, которые управляют этими сервисами.

6.4. Для сервисов, определенных в упражнении 6.3, укажите наиболее важные нефункциональные ограничения.

6.5. Приведите пример типа системы, где социальные и политические факторы могут иметь сильное влияние на системные требования.

6.6. Кто должен проводить обзор требований? Нарисуйте модель процесса обзора требований.

6.7. Почему матрицы оперативного контроля трудны для управления в случае большого количества системных требований? Предложите механизм структурирования требований, основанный на точках зрения, который может помочь решить эту проблему.

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

6.9. Ваша компания использует стандартный метод анализа требований. В процессе работы вы обнаружили, что этот метод не учитывает социальные факторы, важные для системы, которую вы анализируете. Ваш руководитель дал вам ясно понять, какому методу анализа нужно следовать. Обсудите, что вы должны делать в такой ситуации.

Модели систем

Цели

Эта глава знакомит с различными типами моделей систем, которые используются в процессе разработки требований. Прочитав ее, вы должны:

q понимать, почему важны модели рабочего окружения систем;

q знать концепции моделирования поведения, данных и объектов систем;

q ознакомиться с нотациями, применяемыми в унифицированном языке моделирования UML, и с тем, как они используются при разработке различных типов моделей систем;

q знать инструментальные CASE-средства, используемые при моделировании систем.

Пользовательские требования обычно пишутся на естественном языке, поскольку они должны быть понятны даже не специалистам в области разработки ПО. Однако более детализированные системные требования должны описываться более "техническим" способом. Одной из широко используемых методик документирования системных требований является построение ряда моделей системы. Эти модели используют графические представления, показывающие решение как исходной задачи, для которой создается система, так и разрабатываемой системы. Как правило, графические представления более понятны, чем детальное описание системных требований на естественном языке. Модели являются связующим звеном между процессом анализа исходной задачи и процессом проектирования системы.

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

1. Внешнее представление, когда моделируется окружение или рабочая среда системы.

2. Описание поведения системы, когда моделируется ее поведение.

3. Описание структуры системы, когда моделируется системная архитектура или структуры данных, обрабатываемых системой.

Эти три типа представления систем раскрыты в данной главе; кроме того, здесь рассматривается объектное моделирование, которое до некоторой степени объединяет поведенческое и структурное моделирование.

Такие структурные методы, как структурный анализ систем [91, 12*, 24*] и объектно-ориентированный анализ [302, 54, 33*], обеспечивают основу для детального моделирования системы как части процесса постановки и анализа требований. Большинство структурных методов работают с определенными типами системных моделей. Эти методы обычно определяют процесс, который используются для построения моделей, и набор правил, которые применяются к этим моделям. Для поддержки структурных методов существуют различные CASE-средства (обсуждаемые в разделе 7.5), включающие редакторы моделей, автоматизированную систему документирования и инструменты проверки моделей.

Однако методы структурного анализа имеют ряд недостатков.

1. Они не обеспечивают эффективной поддержки формирования нефункциональных системных требований.

2. Обычно руководства по этим методам не содержат советов, которые помогали бы пользователям решить, подходит ли данный метод для решения конкретной задачи.

3. В результате применения этих методов часто получается объемная документация, при этом суть системных требований скрывается за массой несущественных деталей.

4. Построенные модели очень детализированы и трудны для понимания. Обычные пользователи не могут реально проверить действенность этих моделей.

Практическая разработка требований не должна ограничиваться только моделями, построенными с помощью тех или иных методов. Например, объектно-ориентированные методы обычно не предполагают применения для разработки моделей потоков данных. Однако, исходя из моего опыта, такие модели полезны для объектно-ориентированного анализа, поскольку отражают понимание системы конечным пользователем и могут помочь идентифицировать объекты и действия с ними.

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

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

Приведем типы системных моделей, которые могут создаваться в процессе анализа систем.

1. Модель обработки данных. Диаграммы потоков данных показывают последовательность обработки данных в системе.

2. Композиционная модель. Диаграммы "сущность-связь" показывают, как системные сущности составляются из других сущностей.

3. Архитектурная модель. Эти модели показывают основные подсистемы, из которых строится система.

4. Классификационная модель. Диаграммы наследования классов показывают, какие объекты имеют общие характеристики.

5. Модель "стимул-ответ". Диаграммы изменения состояний показывают, как система реагирует на внутренние и внешние события.

Эти типы моделей описаны далее в главе. Везде, где возможно, я использую обозначения унифицированного языка моделирования UML, который является стандартом языка моделирования, особенно для объектно-ориентированного моделирования [55, 303, 5*, 30*]. В тех случаях, когда UML не предусматривает подходящих нотаций, для описания моделей я использую простые интуитивные обозначения.

⇐ Предыдущая 44 45 46 47 484950 51 52 53 Следующая ⇒