И. Соммервилл - Инженерия программного обеспечения (1133538), страница 38
Текст из файла (страница 38)
2. Уя)вммние юмеиеяиами лгуибований. Процесс управления изменениями (рис. 6.16) упрощается, если есть эффективные средства поддержки. 3. Упраюеню оявраогюным ионограаем. Как отмечалось выше, средства подяержки опе- ративного контроля позволяют обнаруживать взаимосвязанные требования. Для небольших программных систем нет необходимости использовать специализированные средства управления требованиями. Здесь для поддержки процесса управления можно обратитьсл к текстовым процессорам. электронным таблицам и обычным компьютерным базам данных. Однако для больших систем требуются специализированные средства поддержки. Информацию о средствах управления такими требованилми, как ГООКБ и Кег)шз)ге Рго, можно найти на 1теЬстранице данной книги.
6.4.3. Управление изменениями требований Управление изменениями требований (см. рис.6.16) должно применяться ко всем предложенным изменениям требований. Преимущество использования формального процесса управления изменениями состоит в том, что все предложенные изменения обрабатываются последовательно, при этом можно управлять и отслеживать внесение измене. ний в системную спецификацию. Овведшжяяе проблем в г)жбоавниях Рис. б.15. Управление изменениями жуебоваиий Процесс управления изменениями состоит из трех основных этапов.
1. Анелю плебеем юмеиения сиевифихапии. Процесс начинается с определения проблем в требованиях или с прямого предложения внесения изменений. На этой стадии проблема илн предложенные изменения анализируются для проверки их обосно. ванности. Затем могут быть сделаны более определенные предложения относительно изменений в требованиях. 2. Авалю изменений и расчет ил ежоимоеми.
Эффект от внесения предложенного изменения оценивается с использованием оперативного контроля. Стоимость изменений оценивается двумя показателями: стоимостью внесения изменения в спецификацию н стоимостью внесения изменений в структуру системы и непосредственно в программный код. По окончании этого этапа принимается решение, продолжать или нет внесение изменений в систему. 6. Рлзработиа требований 147 В. Реппиояил кмииенкц Реализация изменений в системной спецификации, структуре системы н программном коде. Если требуется срочно внести изменения в требования, всегда существует соблазн сделать сначала изменения е системе.
а затем задним числом изменить спецификацию. Это почти неизбежно приводит к тому, что готовая система не будет согласована с требованиями. ~яММ~БХяцяя1ЩЯяйЬфЬЮ яяятгенлз Р с4,' Ш е вклюурйгтеайшщвезосущййувйкшотйхсаздвйиакжтемы, 'формиро-. рсааниь зребовнибйратувстшйвозрвбовений:и3лравление грабова«нчй;'гимаектьрвйичщкее:приоритеты,ври фзормулироеа-'-"' истемы-ПО нвабжрйщо аюизироватьгс различных точек, ы оюимевгргзбояьшое'вяияние «а сищвмнеые требования.. '' верки треэбсщший:ю';дастоаергдгсть, ненротнворячивость,, требований,«, прорщуйббгввцне,дшщются основными методами вклкаает ЯшайойвйиРУйРзеленшэ гДе опРВДелвщсЯ сднпд- .' Упражнения 6.1.
Предложите, кто бы мог участвовать в формировании требований для университетской системы регистрации студентов. Объясните, почему почти неизбежно, что требования, сформулированные разными лицами, будут противоречивы. 6.2. Разрабатывается система ПО для автоматизации библиотечного каталога. Эта система будет содержать информацию относительно всех книг е библиотеке и будет полезна библиотечному персоналу, абонентам и читателям. Система должна иметь средства просмотра каталога, средства создания запросов н средства, позволяющие пользователям резервировать книги, находящиеся в данный момент на руках.
Определите основные опорные точки зрения, которые необходимо учесть в спецификации системы, и покажите их взаимоотношения, используя диаграмму иерархии точек зрения, 6.3. Для трех точек зрения, определенных в системе библиотечного каталога, укажите сервисы н соответствующие данные, которые обеспечиваются этими точками зренгм, и события, которые улравля. ют этими сервисами.
6.4. Для сервисов, определенных в упражнении 6.3, укажите наиболее важные нефункциональные огра- ниченна. 148 '%аско 11. Требования 6.6. Приведите пример типа системы, где сацизльные и политичес»» факторы могут иметь сильное влияние на системные требования. 6.6. Кто должен проводить обзор требованийт Нарисуйте модель процесса обзора требований. 6Л. Почему матрицы оперативного контроля трудны дпя управления в случае болылого количества системных требований? Предложите механизм структурирования требований, основанный на тачках зрения, который может помочь решить эту проблему.
6.6. Существуют ситуации, когда изменения в системе вносятся прежде, чем изменения в требованиях будут одобрены. Предложите модель процесса внесения срочных изменений в систему, который гарантирует согласованность системы и спецификации требований. 6.9. Ваша компания использует стандартный метод анализа требовза|й. В процессе работы вы обнаружили, что этот метод нв учитывает социальные факторы, вшкные для системы, которую вы анализируете.
Ваш руководитель дзл вам ясна пашнь, какому методу анализа нужно следовать. Обсудите, что вы должны делать в такой ситуации. Модели систем Эта глава знакомит с различными типами моделей систем, которые используются в процессе разработки требований. Прочитав ес, вы должны: О понимать, почему важны модели рабочего окружения систем; 0 знать концепции моделирования поведения, данных и объектов систем; ознакомиться с нотациями, применяемыми в унифицированном языке моделирования БМ1., и с тем, как они используются при разработке различных типов моделей систем; знать инструментальные САБЕсредства, используемые при моделировании систем.
7.1. Модели системного окружения 7.2. Поведенческие модели 7.3. Модели данных 7ай Объектные модели 7.5. Инструментальные СЛ5Е.средства 150 'Часть11.Требования Пользовательские требования обычно пишутся на естественном языке, поскольку они должны быть понятны даже не специалистам в области разработки ПО. Однако более детализированные системные требования должны описываться более "техническим" способом. Одной из широко используемых методик документирования системных требований является построение ряда моделей системы. Эти модели используют графические представления, показывающие решение как исходной задачи, для которой создается система, так и разрабатываемой системы.
Как правило, графические представления более понятны, чем детальное описание системных требований на естественном языке. Модели являются связующим звеном между процессом анализа исходной задачи и процессом проектирования системы. Модели можно использовать в процессе анализа существующей системы, которую нужно или заменить, или модифицировать, а также для формирования системных требований.
Модели могут представить систему в различных аспектах. 1. Внешнее представление, когда моделируется окружение или рабочая среда системы. 2. Описание поведения системы, когда моделируется ее поведение. 3. Описание структуры системы, когда моделируется системная архитектура или структуры данных, обрабатываемых системой. Эти три типа представления систем раскрыты в данной главе; кроме того, здесь рассматривается объектное моделирование, которое до некоторой степени объединяет поведенческое и структурное моделирование.
Такие структурные методы, как структурный анализ систем [91, 12'", 24э) и объектноориентированный анализ [302, 54, 33э1, обеспечивают основу для детального моделирования системы как части процесса постановки и анализа требований. Большинство структурных методов работают с определенными типами системных моделей.
Эти методы обычно определяют процесс, который используются для построения моделей, и набор правил, ко. торые применяются к этим моделям. Для поддержки структурных методов существуют раз. личные САБЕсредства (обсуждаемые в разделе 7.5), включающие редакторы моделей, автоматизированную систему документирования и инструменты проверки моделей.
Однако методы структурного анализа имеют ряд недостатков. 1. Они не обеспечивают эффективной поддержки формирования нефункциональных системных требований. 2. Обычно руководства по этим методам не содержат советов, которые помогали бы пользователям решить, подходит ли данный метод для решения конкретной задачи. 3. В результата применения этих методов часто получается объемная документация, прн этом суть системных требований скрывается за массой несущественных деталей.
4. Построенные модели очень детализированы и трудны для понимания. Обычные пользователи не могут реально проверить действенность этих моделей. Практическая разработка требований не должна ограничиваться только моделями, построенными с помощью тех или иных методов.
Например, объектно.ориентированные методы обычно не предполагают применения для разработки моделей потоков данных. Однако, исходя из моего опыта, такие модели полезны для объектно. ориентированного анализа, поскольку отражают понимание системы конечным пользователем и могут помочь идентифицировать объекты и действия с ними. Наиболее важным аспектои системного моделирования является то, что оно опускает детали. Модель является абстракцией системы и легче поддается анализу, чем любое дру- 7. Модели систем 151 гое представление этой системы. В идеале я]чдсвкылеякэ системы должно сохранлть всю информацию относительно представляемого объекта.
Абалракккл является упрощением н определяется выбором наиболее важных характеристик системы. Различные типы системных моделей основаны на разных подходах к абстракции. Например, модель потоков данных концентрирует внимание на прохождении данных через систему и на функциональных преобразованиях этих данных. Модель оставляет без внимания структуру данных. И наоборот, модель "сущность-связь" предполагает документирование системных данных и их взаимосвязь, не касаясь системных функций, Приведем типы системных моделей, которые могуг создаваться в процессе анализа систем.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
