Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Проектирование и разработка информационных систем. Учебное пособие для СПО
.pdf
21
1) спецификации требований;
2) управление требованиями клиента.
К тому же наиболее дорогостоящим является исправление
ошибок, допущенных на этапе формирования требований.
Процесс сбора требований весьма сложен по следующим
причинам.
1. Пользователи часто не знают конкретно, чего они хотят
от ИС, за исключением наиболее общих положений, им трудно
сформулировать свои пожелания, они могут предъявлять нереальные требования, так как не подозревают, какова стоимость их
реализации.
2. Пользователи и разработчики, как правило, принадле-
жат к различным мирам, говорят на разных языках и имеют различный опыт, мотивацию и цели. Поэтому разработчики могут
просто не понимать или понимать неадекватно требования пользователей.
3. Реакция пользователя на каждый когда-либо разрабаты-
ваемый фрагмент программного обеспечения обычно двояка:
«О, это здорово, мы можем реально использовать это, молодцы!» «Да, но как насчет..? Нельзя ли было..? А что будет, если..?».
Причина этого кроется глубоко в природе программного
обеспечения как интеллектуального неосязаемого процесса.
Проблема усугубляется тем, что команды разработчиков крайне
редко предоставляют пользователям какие-либо сведения для
обсуждения и взаимодействия до окончания разработки программного кода.
Итак, для корректного формирования требований необходимо знать методы их сбора и иметь средства их описания, понятные и пользователям, и разработчикам (см. гл. 2).
1.1.3. Методы сбора требований
Для достижения лучшего понимания потребностей пользователя надо переместиться из области битов и байтов, где
многие разработчики чувствуют себя более комфортно, в область, где нужно общаться с реальными людьми и понимать
22
проблемы реального мира. Существует множество методов для
понимания требований пользователей и заинтересованных лиц:
– мозговой штурм и отбор идей;
– обыгрывание ролей;
– интервьюирование и анкетирование;
– сценарии;
– прототипирование.
Выбор конкретного метода будет зависеть от типа ИС,
опыта и уровня подготовки команды разработчиков, заказчика,
масштаба проблемы, используемой технологии и уникальности ИС. Рассмотрим некоторые из них.
Мозговой штурм — проведение совещаний, на которые
люди, знакомые с предметной областью, высказывают идеи без
какой-либо их фильтрации. Предполагается, что все высказанные идеи фиксируются, но никак не комментируются. Уже выявленное требование, даже если оно кажется абсурдным, может
потом быть переформулировано или по ассоциации может вызвать формулирование следующих требований. Поэтому, чем
больше человек участвует в мозговом штурме, тем лучше.
Обыгрывание ролей, или ролевые игры, очень продук-
тивно в качестве выявления требований, поскольку требует детального представления последовательности действий потенциального пользователя (например, кассира, менеджера, администратора) и, следовательно, осознания их текущих потребностей
как потенциальных пользователей.
Интервьюирование и анкетирование. При применении
этого метода сначала надо выявить всех лиц, заинтересованных
в проекте. Например, в процессе формирования требований для
системы банкоматов участвуют:
1) обычные клиенты банка, пользующихся услугами бан-
коматов;
2) представители других банков, имеющих взаимные со-
глашения с данным банком о совместном использовании банкоматов;
3) руководители филиалов банка, получающих информа-
цию из системы управления банкоматами;
23
4) сотрудники филиалов банка, вовлеченные в повседнев-
ную работу системы банкоматов, обрабатывающие рекламации
клиентов и т. д.;
5) администраторы баз данных, ответственные за связь
банкоматов с базой данных клиентов;
6) руководители службы безопасности банка, обеспечи-
вающей защиту системы банкоматов;
7) отдел маркетинга банка, использующий систему бан-
коматов как средство маркетинга;
8) разработчики аппаратных и программных средств, от-
ветственные за сопровождение и модернизацию аппаратных и
программных средств.
Сценарии особенно полезны для детализации уже сформулированных требований, поскольку описывают последовательность интерактивной работы пользователя с системой.
Сценарий начинается с общего описания, затем постепенно детализируется для создания полного описания взаимодействия пользователя с системой. В большинстве случаев сценарий
включает описание:
– состояния системы в начале сценария;
– нормального протекания событий;
– исключительных ситуаций и способов их обработки;
– состояния системы после завершения сценария, а также
информацию о других действиях, которые можно осуществлять
во время выполнения сценария.
1.1.4. Функциональные и нефункциональные
требования
Требования к программной системе часто классифицируются как функциональные (системные) и нефункциональные
(качественные).
Функциональные (системные) требования отвечают на
вопрос «ЧТО должна делать ИС». Это перечень функций, которые должна выполнять система, причем должно быть указано,
как система реагирует на те или иные входные данные, как она
ведет себя в определенных ситуациях и т. д. В некоторых случаях указывается, что система не должна делать. Пример функци-
24
онального требования к библиотечной системе университета,
предназначенной для заказа книг и документов из других библиотек.
1. Пользователь должен иметь возможность проводить
поиск необходимых ему книг и документов или по всему множеству доступных каталожных баз данных.
2. Система должна предоставлять пользователю подхо-
дящее средство просмотра библиотечных документов.
3. Каждый заказ должен быть снабжен уникальным иден-
тификатором (NUM_ID), который копируется в формуляр пользователя для постоянного хранения.
Эти функциональные требования определяют свойства,
которыми должна обладать система. Они взяты из документа,
содержащего пользовательские требования, и показывают, что
функциональные требования могут быть описаны с разным
уровнем детализации (сравните первое и третье требования).
Чтобы избежать проблем из-за неоднозначности толкований, требования должны быть прописаны максимально четко.
Рассмотрим второе требование к библиотечной системе и
обратим внимание на выражение «подходящее средство просмотра документов». Библиотечная система может представлять
документы в широком спектре форматов. В требовании подразумевается, что система должна предоставить средства для просмотра документов в любом формате. Но вполне возможно, что
под «подходящим средством» разработчики и пользователи понимают разные средства. В этом случае система не устроит
пользователя, разработчикам придется её переделывать, что увеличит стоимость системы.
Нефункциональные требования отвечают на вопрос, как
должна работать ИС, описывают характеристики системы и ее
окружения. Здесь также может быть приведен перечень ограничений, накладываемых на действия и функции, выполняемые
системой, например, временные ограничения, ограничения на
процесс разработки системы, стандарты и т. д.
Все нефункциональные требования можно разбить на три
большие группы.
1. Требования к продукту. Описывают эксплуатацион-
ные свойства программного продукта. Это требования к произ-
25
водительности системы, объему необходимой памяти, надежности (определяет частоту возможных сбоев в системе), переносимости системы на разные компьютерные платформы и удобству
эксплуатации.
2. Организационные требования. Отображают политику
и организационные процедуры заказчика и разработчика ПО.
Они включают стандарты разработки программного продукта,
требования к реализации ПО (То есть к языку программирования и методам проектирования), выходные требования, которые
определяют сроки изготовления программного продукта, и сопутствующую документацию.
3. Внешние требования. Учитывают факторы, внешние
по отношению к разрабатываемой системе и процессу ее разра-
ботки. Например:
– требования, определяющие взаимодействие данной системы с другими системами;
– юридические требования, следование которым гарантирует, что система будет разрабатываться и функционировать в
рамках существующего законодательства;
– этические требования, гарантирующие, что система будет приемлемой для пользователей или заказчика.
Нефункциональные требования по своей природе каче-
ственные, но должны выражаться через количественные показатели, которые можно объективно измерить. В табл. 1.1 приведены показатели, с помощью которых можно специфицировать
качественные требования к ПО.
Таблица 1.1
Количественные показатели качественных требований
Показатель
Единицы измерения
Скорость
Количество выполненных транзакций в секунду;
время реакции на действия пользователя;
время обновления экрана
Размер
Килобайты;
количество модулей памяти
26
Показатель Единицы измерения
Простота эксплуатации
Время обучения персонала;
количество статей в справочной системе
Надежность
Средняя продолжительность времени между двумя
последовательными проявлениями ошибок в системе;
вероятность выхода системы из строя;
коэффициент готовности системы
Устойчивость к
сбоям
Время восстановления системы после сбоя;
процент событий, приводящих к сбоям;
вероятность порчи данных при сбоях
Переносимость
Процент машинно-зависимых операторов;
количество машинно-зависимых подсистем
Пример некорректной формулировки требования: система
должна быть простой в эксплуатации для опытного оператора и
сводить количество его ошибок к минимуму. Это требование
лучше сформулировать так: опытному оператору должны быть
доступны все системные функции после двух часов обучения
работе с данной системой. После такого обучения среднее число
ошибок оператора не должно превышать двух за рабочий день.
1.1.5. Методы описания требований
Как уже отмечалось, главная проблема формирования требований — взаимопонимание между пользователями и разработчиками.
В настоящее время данная проблема решается при помощи
языка UML, разработанного специально для обеспечения связи
между участниками проекта. Некоторые аспекты языка нацелены на установку связи между потребителями и разработчиками;
другие — на общение проектировщиков системы и разработчиков баз данных; третьи — на связи между разработчиками, создающими разные части системы. Предлагая набор хорошо
определенных диаграмм и точно определенные пояснения к ним,
UML позволяет всем участникам проекта в любой момент понимать, что происходит в системе, и сводит к минимуму риск не-
27
правильного понимания. Де-факто данный язык уже является
стандартом при проектировании ИС.
Конкретно для описания требований обычно используют
диаграммы прецедентов. Основные положения языка приведены
в гл. 2.
1.1.6. Специфицирование требований
Учитывая, что системе будут предъявлены сотни, если не
тысячи требований (например, при разработке системы управления самолетом «Боинг 777» было 300 000 требований), очень
важно организовать их. Поскольку невозможно удерживать в
памяти более нескольких десятков фактов, для успешного взаимодействия различных участников процесса необходимо обеспечить документирование требований. Требования следует записать так, чтобы они были доступны для ознакомления — это
может быть документ, модель, база данных или листок на доске
объявлений.
При специфицировании требований производится и их
анализ на полноту и непротиворечивость. В случае, если выполнение какого-либо требования невозможно при выполнении
другого, приходится либо аннулировать то из них, которое имеет меньший приоритет, либо смягчить одно или оба требования,
чтобы их выполнение стало реальным.
1.1.7. Аттестация требований
Аттестация должна продемонстрировать, что требования,
действительно, определяют ту систему, которую хочет иметь
заказчик.
Во время процесса аттестации должны быть выполнены
различные типы проверок документации требований.
1. Проверка правильности требований. Пользователь мо-
жет считать, что система необходима для выполнения некоторых определенных функций. Однако дальнейшие размышления
и анализ могут привести к необходимости введения дополнительных или новых функций. ИС может быть предназначена для
разных пользователей с различными потребностями, и поэтому
28
набор требований будет представлять собой некоторый компромисс между требованиями пользователей системы.
2. Проверка на непротиворечивость. Спецификация тре-
бований не должна содержать противоречий. Это означает, что в
требованиях не должно быть противоречащих друг другу ограничений или различных описаний одной и той же системной
функции.
3. Проверка на полноту. Спецификация требований
должна содержать требования, которые определяют все системные функции и ограничения, налагаемые на систему.
4. Проверка на выполнимость. На основе знания суще-
ствующих технологий требования должны быть проверены на
возможность их реального выполнения. Здесь также проверяются возможности финансирования и график разработки системы.
При аттестации надо ответить на множество вопросов,
например, это:
– потребность или требование;
– то, что «хорошо бы иметь», или то, что «должно быть»;
– постановка задачи или речь идет о формулировке решения;
– цель системы или одно из условий контракта;
– действительно ли нужно программировать на языке
Java? И кто будет это делать;
– кому не нравится наша новая система и где был этот человек, когда мы приходили сюда раньше?
После того как спецификация требований признана удовлетворительной как руководством предприятия-разработчика,
так и заказчиком, она используется как фундамент, на базе которого строится ТЗ, рассчитываются основные параметры проекта — величина, стоимость, трудозатраты, длительность выполнения.
1.1.8. Управление требованиями
Требования задают возможности, которые должна предоставлять система, так что соответствие или несоответствие некоторому множеству требований часто определяет успех или неудачу проекта. К сожалению, требования имеют свойство изменяться с течением времени либо по мере их уточнения, либо по
29
мере возникновения новых. Поэтому имеет смысл не только записать и упорядочить требования, но и отслеживать их изменения. Иными словами, можно определить управление требованиями следующим образом.
Управление требованиями это систематический подход к
выявлению, организации и документированию требований к системе, а также процесс, в ходе которого вырабатывается и обеспечивается соглашение между заказчиком и выполняющей проект группой по поводу меняющихся требований к системе.
Управление требованиями — это важная составляющая
управления проектом, оно подразумевает:
– идентификацию требований. Каждое требование должно быть однозначно определено, поскольку оно может пересекаться с другими требованиями. Пересечение требований можно
обнаружить с помощью оперативного контроля;
– управление процессом внесения изменений. Это ряд операций, которые оценивают воздействие на систему вносимых
изменений, а также стоимость изменений;
– стратегию оперативного контроля. Определяет отношения между требованиями, а также между требованиями и
проектированием системы;
– поддержку CASE-средств. Управление требованиями
предполагает обработку большого объема информации о требованиях. В этом процессе могут использоваться разнообразные
инструментальные средства, например, электронные таблицы
или простые системы баз данных.
Для оперативного контроля над требованиями необходима, как минимум, информация о:
– источнике требования — связывает требование с лица-
ми, которые предложили эти требования, и с логическим обоснованием этих требований. Если предложено изменение в требованиях, эта информация используется для определения лиц,
которые могут обосновать эти изменения;
– требованиях — связывает требования внутри специфи-
кации. Эта информация используется для оценки количества
требований, которые затрагивают предложенные изменения;
– структуре системы — связывает требования с системными модулями, которые реализуют требования. Эта информа-
30
ция используется для оценки влияния предложенных изменений
на систему и ее реализацию.
Информация для оперативного контроля часто представляется в виде специальных матриц, которые связывают требования с лицами, предложившими эти условия, требования между
собой и требования с системными модулями. Если матрица оперативного контроля связывает требования между собой, то каждое требование представлено в матрице как строкой, так и
столбцом. Тогда, если между требованиями существует зависимость, это указывается в ячейках на пересечении строк и столбцов, соответствующих этим требованиям. Пример простой матрицы зависимостей между требованиями показан в табл. 1.2.
Символ И (использование) на пересечении строки и
столбца показывает, что требование в строке использует средства, определенные в требовании представленном столбце. Символ С (связь, зависимость) означает, что существует некоторая
взаимосвязь между требованиями. Например, оба требования
входят в один и тот же системный модуль.
Таблица 1.2
Матрица оперативного контроля
1.1
1.2
1.3
2.1
2.2
3.1
1.1 И
С И
И
1.2
И И С 1.3 С С
С
2.1
С И
2.2 И С И
3.1
И И
Матрицы оперативного контроля (см. табл. 1.2) используются для управления небольшим набором требований, они становятся громоздкими и неудобными для больших систем со
многими требованиями. Для таких систем информацию опера-
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]