Проектирование информационных систем. Основная литература Бугорский В.Н., Соколов Р.В

Литература

Литература

Основная литература

1. Бугорский В.Н., Соколов Р.В. Сетевая экономика и проектирование информационных систем. – СПб.: Питер, 2007. – 320с.

2. Вендров, А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – 2-е изд., перераб. и доп. / А.М. Вендров. – М.: Финансы и статистика, 2005. – 544 с.

1. Смирнова Г.Н. и др. Проектирование экономических информационных систем: учебник / Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов; под ред. Ю.Ф. Тельнова. – М.: Финансы и статистика, 2005. – 512 с.

Дополнительная литература

1. Романов, В. П. Проектирование экономических информационных систем [Текст]: методология и современные технологии [Текст]: учебное пособие / В. П. Романов, Н. З. Емельянова, Т. Л. Партыка. – М.: Экзамен, 2005. – 256 с.

Тема 9. Эффективность информационной системы

Цель:

· изучить требования к эффективности проектных решений ИС;

· изучить показатели экономической эффективности ИС;

· изучить методы и средства определения экономической эффективности ИС.

Результат обучения. После обучения студент должен:

· знать требования к эффективности проектных решений;

· знать показатели экономической эффективности;

· знать методы и средства определения экономической эффективности.

План:

9.1 Требования к эффективности и надежности проектных решений

9.2 Показатели экономической эффективности информационной системы. Вероятностная оценка достоверности обработки информации. Оценка времени обработки информации. Капитальные затраты. Эксплуатационные затраты.

9.3 Методика определения экономической эффективности: статические и динамические показатели.

9.4 Анализ риска в оценке экономической эффективности ИС. Оценка научно-технического уровня информационных систем.

Потребность в создании ЭИС может обусловливаться либо необходимостью автоматизации или модернизации существующих информационных процессов, либо необходимостью коренной реорганизации в деятельности предприятия (проведении бизнес-реинжиниринга). В зависимости от этого к ЭИС применяются соответствующие требования как по их функциональности, так и по принципам проектирования и внедрения. Требования к проекту определяются характеристиками проектируемой ЭИС и условиями среды разработки (окружением проекта).

Экономические информационные системы характеризуются следующими показателями:

§ конкретным типом решаемых задач;

§ степенью связи решаемых задач с реальным масштабом времени или допустимой длительностью ожидания результатов решения задачи;

§ объемом и сложностью совокупности программ, решающей единую целевую задачу данного типа;

§ необходимыми характеристиками качества и надежности;

§ классом программно-аппаратных средств, необходимых для реализации программ данного типа;

§ степенью использования готовых, ранее созданных компонент;

§ прогнозируемыми значениями длительности эксплуатации и возможностью развития множества версий программ;

§ предполагаемым тиражом производства и применения программ;

§ степенью необходимой документированности программ.

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

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

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

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

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

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

Динамика изменения требований зависит от выбранной модели жизненного цикла, в каскадной (последовательной) модели^* требования определяются один раз в начале проекта, а в спиральной (итерационной)^** – уточняются в ходе выполнения проекта. Во втором случае должна быть предусмотрена процедура управления требованиями. Одним из возможных подходов является представление совокупности требований в виде набора атомарных требований – утверждений, между которыми выявляются отношения зависимости. При использовании каскадной модели все требования содержаться в техническом задании, затем они преобразуются в архитектурное решение в техническом проекте, в этом случае процедура управления требованиями упрощается, ведь предполагается, что требования не будут меняться в ходе проекта.

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

К концептуальному представлению предъявляются требования устойчивости, абстрактности и конструктивности.

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

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

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

(дополнительно)

Основные требования к Эффективности ЭИС

Для оценки эффективности ЭИС служит набор критериев, которые количественно определяют степень соответствия системы целям ее создания. Критерий эффективности должен быть наглядным, напрямую зависеть от работы системы, допускать приближенную оценку по результатам экспериментов. Оценивают как ИС в целом, так и ее компоненты. Одновременное достижение всех целей невозможно, поэтому на практике выбирают компромиссное решение: один из критериев оптимизируется, а остальные служат в качестве ограничений. Ниже приведены типичные цели создания ЭИС и критерии для их оценки:

№	Цели	Критерии
	Максимальная полнота отображения информации	Отношение объема инф. в системе к объему инф. на объекте
	Максимальная скорость предоставления информации	Время обработки данных Время ответа на запрос
	Максимальное удобство пользователя	Время на формирование запроса и понимание ответа
	Минимальные расходы	Капитальные вложения + Текущие затраты
	Максимальное извлечение полезной информации	Отношение объема входной инф. к объему выходной инф.
	Минимальная избыточность базы данных	Отношение объема избыточной инф. к объему хранимой инф.

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

Схема безопасности, реализованная в подсистеме, должна быть отделена от средств безопасности самой операционной системы, на которой будет реализована АС, в том смысле, что сбой или уязвимость подсистемы безопасности операционной системы не должны влиять на работу подсистемы безопасности АС. То есть если организация считает, например, средства криптографической защиты, предоставляемые MS Win2000, достаточно надежными, она может снять этот вопрос в требованиях к приложению. Если же Windows — корпоративный стандарт, но при этом для конфиденциальных данных периодические «дыры» в ОС считаются существенной угрозой, значит, приложение должно само заботиться о криптографии. Таким образом, вопрос оставляется на усмотрение лица, принимающего конкретное решение.

Механизмы безопасности подсистемы должны быть реализованы в форме широко известных в мире, опробованных и одобренных стандартов и протоколов.

Подсистема безопасности должна обеспечивать замкнутое сохранение данных, связанных с АС (собственно модулей системы, системных и прикладных данных) таким образом, чтобы:

1) невозможно было получить логический доступ к указанным данным вне рамок работы приложения АС;

2) любые перемещения данных из/в систему происходили под контролем подсистемы безопасности.

Основная литература

1. Бугорский В.Н., Соколов Р.В. Сетевая экономика и проектирование информационных систем. – СПб.: Питер, 2007. – 320с.

2. Вендров, А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – 2-е изд., перераб. и доп. / А.М. Вендров. – М.: Финансы и статистика, 2005. – 544 с.

1. Смирнова Г.Н. и др. Проектирование экономических информационных систем: учебник / Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов; под ред. Ю.Ф. Тельнова. – М.: Финансы и статистика, 2005. – 512 с.

Дополнительная литература

1. Романов, В. П. Проектирование экономических информационных систем [Текст]: методология и современные технологии [Текст]: учебное пособие / В. П. Романов, Н. З. Емельянова, Т. Л. Партыка. – М.: Экзамен, 2005. – 256 с.