Назначение и виды требований к ИС.
Определение требований к ИС является наиболее этапом ее разработки.
Цель установления требований состоит в том, чтобы дать развернутое определение требований, которое участники проекта ожидают реализовать в разрабатываемой системе.
Сформированные требования должны быть подвергнуты тщательному анализу по возможности их реализации повторов и противоречий. Это приводит к пересмотру требований. Принятые З и Р требования должны быть задокументированы.
Значимость требований определяется их ролью в формировании ФСИС и ОКИС, процессами выполняемых работ на всех стадиях ЖЦ ИС.
Одной из основных проблем, связанных с процессом проектирования АС, является отсутствие методик реализации 1-ых стадий проектирования, прежде всего, определения требований.
Существуют разные технологии определения требований.
Британская технология SSADM предусматривает согласование проектных работ, ориентированных на применение САПР. Эта технология формирования требований позволяет разумно сочетать возможности формирования требований как заказчиком, так и разработчиком. Ее преимуществом является глубокий анализ варианта разрабатываемой системы с тщательной ее увязкой с общесистемным программным обеспечением и обеспечивающим комплексом в целом.
По сравнению с ГОСТ 34.601-90 методика SSADM является более гибкой, предусматривающей выявление общих требований к системе пользователем и в частности к ее функциональным назначениям. Кроме того она позволяет представлять требования для принятия конкретных решений.
|
|
|
Несмотря на то, что данная технология слабо формализована, она представляет возможность разработать 13 дополнительных методик, для разработки элементов АС.
Такие требования формируются в каталоге требований КТ. При этом порядок его оформления строго регламентирован. В то же время он позволяет фиксировать требования и служит для их соблюдения в процессе разработки ИС практически по всем стадиям, до физического проектирования.
Технология реализации методик формирования требований предусматривает, прежде всего, технологическое взаимодействие заказчика и разработчика. Учитывая, что заказчик хорошо понимает предметную область, но не понимает процедуры реализации функций АС, разработчик должен слабо формализованные его требования максимально использовать при макро- и микро- проектировании системы.
Все требования подразделяются на:
- функциональные,
- нефункциональные.
Функциональные требования описывают то, что должна выполнять система по реализации функций планирования, учета, контроля, анализа и управления, а также условий хранения, обработки информации.
|
|
|
Нефункциональные требования определяют, на каком уровне качества система будет реализовывать функциональные требования.
В процессе проектирования нефункциональные требования должны регулярно пересматриваться по мере добавления функций каждым пользователем. Это позволяет использовать КТ как на макро-, так и на микро- уровне проектирования.
Управление итерационным процессом проектирования ИС предусматривает многократное уточнение проектных решений. При этом степень детализации требований выбирают, руководствуясь здравым смыслом на неформальном уровне.
Полный перечень нефункциональных требований разработать невозможно. Выделяют следующие виды нефункциональных требований:
1. Меры безопасности, хранения данных предусматривают каким данным необходима защита, резервирование.
2. Обеспечение мониторинга и контролируемости данных. Мониторинг – слежение за функционированием системы с целью накопления статистики для анализа и оценки ее работы (актуализация данных).
3. Качество реализации функций определяется вычислительным комплексом и соответствующими обеспечениями в виде оценок. Естественно на I этапе устанавливаются грубые оценки, которые уточняются на этапе микропроектирования. Например:
|
|
|
а) производительность – это суммарный объем работы, выполняемый в ед. времени (продолжительность реализации функции),
б) надежность – наработка на отказ,
в) доступность системы, определяемая в процентах во времени, в течение которого реализуется функция запроса,
г) длительность функционирования системы.
4. Ограничение доступа – устанавливает какие меры должны быть приняты для ограничения доступа. Кроме того для установления мер безопасности, хранения данных определяется каким данным необходима защита, резервирование.
5. Прочие требования.
К прочим требованиям относятся требования для перехода существующей системы к новой системе, сопряжение с другими системами, накопление и уничтожение требований.
16. Методика формирования требований (МФТ) реализуется двумя этапами:
I. На первом этапе при активном участии пользователей составляется перечень реализуемых задач, информационных потоков и обрабатываемых данных. При этом не делаются попытки создания информационной системы. Все недостатки существующей системы, требования к ИС отражаются в каталоге требований. Если нет функционирующей информационной системы, то ИС разрабатывается на желаемой основе автоматизации.
|
|
|
II. На втором (II) этапе оцениваются варианты реализации проектов создаваемой системы исходя из принятых требований.
Результаты этих этапов могут корректироваться до получения оптимального варианта ИС. Если какой-то вариант не принимается, то указывается причина. В то же время все требования остаются в каталоге требований для того, чтобы была возможность возвратиться к соответственному варианту. На основе такой методики составляют детальный перечень требований АС. На основе сформированных требований разрабатывается функциональная модель АС в виде:
- модели инф. потоков,
- описания функций,
- конкретизированного каталога требований (КТ).
После 2-го этапа ТЗ, АТ может быть запрещено добавление новых функциональных требований, при этом остается небольшое количество требований на детализирование системы. Обычно это касается видов обеспечений.
На стадии технического этапа проектирования требования постоянно отслеживаются таким образом, чтобы они были полностью удовлетворены при соблюдении компромисса между затратами и качеством реализуемых функций.
Сущность методики формирования требований (МФТ) заключается в том, чтобы отработать технологию процесса создания функциональной структуры АС.
Методика формирования требований реализуется следующими процедурами:
1. Определение функций разработчика и пользователя на каждой стадии ЖЦ ИС;
2. Осуществление сбора первичных данных о ПрО (инф. потоки);
3. Формирование требований (КТ) (ТЗ).
4. Ведение каталога требований.
Эффективность применения такой методики позволяет перейти к формированию проект-х основополагающих документов.
Принципы проектирования ИС
Проектирование информационныхсистемсвязано сихмасштабностью,сложностью проектирования,трудоемкостью,и длительностью жизненного цикла. Процесс проектирования организационных и информационных систем отличается от систем автоматического управления.
Особенность проектирования технических систем предусматривает:
1) Получение физической модели объекта управления.
2) Применение классических методов управления.
3) Установления конкретных сроков окончания разработки САУ с заранее установленными параметрами ОУ.
Дата добавления: 2018-02-15; просмотров: 1251; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!