И. Соммервилл - Инженерия программного обеспечения (1133538), страница 37
Текст из файла (страница 37)
Методы прототипирования описаны в главе 8. 1еиерпцил вмсаовык сценариев. В идеале требования должны быть такими, чтобы их реализацию можно было протестировать. Если тесты для требований разрабатываются как часть процесса аттестации, то часто это позволяет обнаружить проблемы в спецификации. Если такие тесты сложно или невозможно разработать, то обычно это означает, что требования трудно выполнить н поэтому необходимо их пересмотреть. Авошматиеиропиный пиалке иеаровиеюфечивости. Если требованил представлены в виде структурных или формальных системных моделей, можно использовать инс1- рументальные СЛ5Е.средства для проверки непротиворечивости моделей. Этот процесс показан на рис.
6.13. Для автоматизированной проверки непротиворечивости необходимо построить базу данных требований и затем проверить все требования в этой базе данных. Анализатор требований готовит отчет обо всех обнаруженных противоречиях. Рис. 6.13. АвтомаваииРованный аиавие яелРотиво1мчивости тУмбовпиий 142 'Часть П. Требования Трудности аттестации требований нельзя недооценивать. Продемонстрировать, что все требования отвечают потребностям пользователя, очень трудно.
Пользователи должны представить систему в действии и вообразить, как эта система впишется в их работу. Это трудно представить даже квалифицированным специалистам, не говоря уже о пользо. вателях системы. В результате аттестации требований редко обнаруживаются все проблемы системной спецификации, поэтому в ней неизбежны изменения даже после согласованияя документа требований. 6.3.1.
Обзор требований Обзор требований -это процесс просмотра системной спецификации для нахождения неточных описаний и ошибок. К этому процессу привлекается большое количество лиц как со стороны заказчика, так и со стороны разработчиков. Обзор требований можно ор. ганизовать так же, как и инспекцию программ (см. главу 19). Обзор требований может быть неформальным и формальным. 1-1еформальный обзор— это простое обсуждение требований с большим количеством лиц, участвующих в их фор. мированни. Удивляет то, что часто связь между разработчиками системы и этими лицами заканчивается после формирования требованиИ бездокументального подтверждения, что эти требованнл описывают ту систему, которая необходима данным лицам.
Многие про. блемы перел переходом к формальному обзору мокнут быть обнаружены простым обсуждением разрабатываемой системы с лицами, формирующими требования. При формальном обзоре группа разработчиков должна "вести" заказчика через спецификацию, объясняя причину включения каждого требования. При этом проверяется не. противоречивость требований и их полнота. Обнаруженные во время обзора противоречия, ошибки и упущения в требованиях должны быть зафиксированы документально.
Затем эти документы передаются заказчику и разработчикам системы для принятия соответствующих мер. 6.4. Управление требованиями Требования к большим системам ПО неизбежно бугут изменяться в процессе их разработки. Причины этого многочисленны и разнообразны. Одной нз причин является то, что во время процесса создания ПО понимание разработчиками поставленных перед ними задач бу шт неизбежно меняться, что вызгнвает необходимость возвращения к требованиям. Кроме того, для больших программных систем, которые приходят на смену действующим, должна быть обеспечена преемственность. Хотя проблемы в работе со старой системой известнЫ, трудно предсказать, какой аффект "улучшенная" система даст для организации. Если конечные пользователи имеют опыт работы с подобной системой, новые требования появляются по ряду причин.
1. Большие системы обычно имеют многообразный контингент пользователей. Разные пользователи имеют различные требования и приоритеты, которые могут быть противоречивыми или несовместкмыми. Окончательный вариант системных требований представляет неизбежный компромисс между ними, который часто принимается только на заключительном агапе разработки системы. 2. Заказчики системы и ее пользователи — редко одни и те же люди. Заказчики формулируют требования, руководствуясь своими организационными и бюджетными ограничениями. Они мо~ут входить в противоречие с требованиями конечных пользователей. б.
Разработка требований 143 3. Деловая среда и техническое окружение системы изменяются. что должно найти отражение в системе. Например. может быть закуплено новос оборудование, может появиться необходимость сопряжения системы с другими системами, деловые приоритеты органиэации мокнут измениться, будут введены новые законодательство и стандарты и т.д. Измененил в аппаратных средствах особенно затрагивают нефункциональные системные требования. Управление требованиями — это процесс управления изменениями системных требо. наний. Процесс управления требованиями выполняется совместно с другими процессами разработки требований. Начало этого процесса планируется ца то же время, когда начинается процесс первоначального формирования требований, непосредственно процесс управления требованиями должен начаться сразу после того, как черновая версия спецификации требований будет готова.
Описание процесса управления требованиями приведено ниже. Но прежде следует обсудить, почему требования неизбежно меняются, и объяснить, почему олци типы требований более подвержены изменениям, чем другие. 6.4.1. Постоянные и изменяемые требования При формировании требований основное внимание сосрелоточегю на возможностях создаваемого ПО, бизнес-целях и других бизнес. системах организации.
После формирования требований лести~затея более глубокое понимание потребносгей пользователей, вследствие чего может возникнуть необхолимость в изменении ранее сформулированных требований. Измененные требования отсылаются заказчику с объяснением причины сде. ланных изменений (рис. 6.14). Создание болъпюй системы может занять несколько лет.
За это время окружение и бизнес. требования к системе, несомненно, изменятся, что также должно найти отражение в измененных требованиях. Рис. 6.14. Эеоемаия ояибоеаний С точки эренил разработки требования можно разделить надва кчасса. 1. Поетоянньм ифебоеания. Это отпоситслыю стабильныс требования, которые исхо. дят иэ основной деятельности организации и касаются непосредственно предиет. ной области, где будет эксплуатироваться система. 2. Иэиенееиае оребоелнил.
Эти требования отображают изменения, сделанные во вре- мя разработки системы илн после ввода ес в эксплуатацию. 144 Часть 11. Требования В работе ~!571 предложено классифицировать изменяемые требования по пяти классам. Но я считаю. что из этих классов два тесно связаны, поэтому предлагаю классификацию, показанную в табл. б.1. Таблица 6.1. Классификация изменяемых требований Тнп требований Описание Требования, которые изменяются из-за изменений в ок- ружении системы Непостоянные требования Неожиданно возникающие требования Требования, которые появляются во время разработки системы.
В процессе проектирования может возникнуть необходимость добавления новых требований Непрямыетребования Требования, которые являются результатом внедрения компьютерной системы, способной изменить организа- ционные процессы и показать новые способы работы, ко- торые приведуг к новым системным требованиям Вторичные требования Требования, которые зависят от особенносгей данной системы или от бизнес. проблем организации 6.4.2. Планирование управления требованиями 1.
Идеижификацил эфейюаиий. Каждое требование должно быть однозначно определено, поскольку оно может пересекаться с другими требованиями. Пересечение требований можно обнаружить с помощью оперативного контроля. 2. Управление процессам еигееиил игмнииий.
Это ряд операций, которые оценивают воз. действие на систему вносимых изменений, а также стоимость изменений. Более подробно этот вопрос рассматривается в следующем разделе. 3. Софажегия оаеражиеаого коимргмя. Определяет отношения между требованиями, а также между требованиями и проектированием системы. 4. ПоддеРэека САЖфедеэм. Управление требованиями предполагает обработку большого объема информации о требованиях. В этом процессе мо~ут использоваться разнообразные инструментальные средства, например электронные таблицы нли простые системы баз данных.
Существует много взаимозависимостей между требованиями, а также между требованиями и структурой системы. Кроме того, существует свлзь между требованиями и причинами, по которым эти требования были предложены. Если необходимо внести в требава. ния изменения, в процессе управления нужно проследить влияние этих изменений на лругие требования и саму систему. Оперативный контроль позволяет обнаружить связанные требования и отследить влияние одних требований на другие.
Планирование является первым этапом процесса управления требованиями. Управление требованиями очень дорого, и для каждого проекта на стадии планирования устанавливается необходимый уровень детализации управления требованиями. В процессе управления нужно отслеживать ряд вопросов, касающихся разработки требований. 6. Разработка требований 145 Существует три типа информации, используемой в оперативном контроле. 1. Инфо~вищия об шточнике жребоаяякя свлзывает требование с лицами, которые предложили эти требования, и с логическим обоснованием этих требований. Если предложено изменение в требованиях, эта информация используется для опреде.
ления лиц, которые могут обосновать эти изменения. 2. Информация о жргмманяях связывает требования внутри спецификации. Эта информация используется для оценки количесгва требований, которые затрагивают предложенные изменения. 3. Инфофмаккя о сжР)ктфе аимакм связывает требования с системными модулями, которые реализуют требования. Эта информация используется для оценки влияния предложенных изменений на систему и ее реализацию. Информация для оперативного контроля часто представляется в виде специальных матриц, которые связывают требования с лицами, предложившими эти условия, требования между собой и требования с системными модулями. Если матрица оперативного контроля связывает требования между собой, то каждое требование представлено в матрице как строкой, так и столбцом.
Тогда, если между требованиями существует зависимость, это указывается в ячейках на пересечении строк и столбцов, соответствующих этим тре. бованиям. Пример простой матрицы зависимостей между требованиями показан в табл. 6.2. Символ 11 (от цзе — использование) на пересечении строки и столбца показывает, что требование в строке использует средства, определенные в требованиях, представленных в столбце.
Символ К (от ге1абоп — связь, зависимость) означает, что существует некоторая взаимосвязь между требованиями. Например, оба требования определяют один и тот же системный модуль. Таблица 6.2. Матрица оперативного контроля Требования 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2 1.2 2.1 К Матрицы оперативного контроля используются для управления небольшим набором требований, онн становятся громоздкими н неудобными для больших систем со многими требованиями. Для таких систем информацию оперативного контроля рациональнее держать в базе данных требований, где каждое требование связано явным образом с дру- 146 'Часть П. Требоввжия гимн требованиями. Влияние изменений в требованиях можно проследить, используя средства просмотра базы данных.
Управление требованиями нуждается в автоматизированной поддержке, для чего можно использовать разнообразные САБЕсредства. Средства поддержки необходимы для выполненияследующнхопераций. 1. Хранеяие юфебований. Информация о требованиях должна быть защищена, процесс хранения должен быть управляем, требования должны быть доступны для каждого участника процесса разработки требований.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
