пользователей: 30398
предметов: 12406
вопросов: 234839
Конспект-online
РЕГИСТРАЦИЯ ЭКСКУРСИЯ

I семестр:
» ИС
» ИИС
» РСПСИТ

9.10. Требования, предъявляемые к информационным системам

Информационная система должна соответствовать требованиям гибкости, надежности, эффективности и безопасности.

Гибкость

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

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

Вместе с тем возникает риск применения устаревших решений при модернизации системы. Рекомендация в таком случае одна — внимательнее относиться к подбору разработчиков информационных систем.

 

Надежность

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

 

Эффективность

Система является эффективной, если с учетом выделенных ей ресурсов она позво­ляет решать возложенные на нее задачи в минимальные сроки.

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

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

Активное сотрудничество с заказчиком с ранних этапов проектирования позволяет уточнить потребности заказчика. Часто встречается ситуация, когда заказчик чего-то хочет, но сам не знает чего именно. Чем раньше будут учтены дополнения заказчика, тем с меньшими затратами и в более короткие сроки система будет создана.

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

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

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

 

Безопасность

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

Система, не отвечающая требованиям безопасности, может причинить ущерб интересам заказчика, прежде всего имущественным.

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

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

И наконец, самый важный фактор, влияющий на процесс разработки, — знания и опыт коллектива разработчиков информационных систем.

 

9.11. Средства структурного моделирования

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

-          функции, которые система должна выполнять;

-          отношения между данными;

-          зависящее от времени поведение системы (аспекты реального времени).

Среди многообразия средств для решения данных задач наиболее часто и эффективно применяются следующие методологии структурного анализа:

-          DFD (Data Flow Diagrams) – диаграммы потоков данных совместно со словарями данных и спецификациями процессов или миниспецификациями;

-          ERD (Entity-Relationship Diagrams) – диаграммы «сущность-связь», которые определяют структуру базы данных;

-          STD (State Transition Diagrams) – диаграммы переходов состояний.

Все они содержат графические и текстовые средства моделирования: первые – для наглядного представления основных компонентов модели, вторые – для обеспечения точного определения (описания) ее компонентов и связей.

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

Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня; когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции при помощи спецификации процесса (миниспецификации – алгоритма выполнения элементарных функций). Структура данных ИС раскрывается с помощью ERD – модели, на основе которой создается база данных ИС. В случае наличия реального времени DFD-диаграмма дополняется средствами описания, зависящего от времени поведения системы. Для этого используются STD-модели, в которых указываются условия перехода между функциями (вероятность перехода) и допустимое время перехода. Взаимосвязь моделей показана на рис.9.5.

 

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

Для создания DFD – диаграмм (моделей) используются такие распространенные программные продукты как INCOME Mobile, CPN-AMI, BPWIN, CPNIDEF и другие. Для построения ERD – моделей широко применяются ERWIN, BPWIN, а также встроенные средства СУБД. Интеграция DFD и STD осуществляется за счет расширения классической методологии DFD специальными средствами проектирования систем реального времени. Одним  из решений является использование методологии и средств динамического моделирования, основанных, например, на цветных сетях Петри - CPN (Color Petri Nets). В качестве программных средств могут использоваться CPNIDEF, CPN-AMI.

Для ERD и STD методологий (соответственно для информационного и поведенческого моделирования) нет альтернативы. Для средств функционального моделирования DFD существует альтернативная методология SADT (Structured Analysis and Design Technique) - модели и соответствующие функциональные диаграммы. Методология SADT успешно работает только для моделирования хорошо специфицированных и стандартизованных процессов (деятельность в их рамках жестко регламентирована должностными инструкциями, методиками и другими нормативными материалами). В случае слабой типизации производственных процессов, их стихийного появления и развития единственно возможными являются DFD – методологии.

Методология SADT на базе программных средств IDEF0 является в настоящее время одной из наиболее широко применяемых в России. Тем не менее, она поддерживается лишь 10 процентов существующих CASE-пакетов, оставшиеся 90 процентов поддерживают DFD - методологии.

                Фрагменты функциональной модели на примере автоматизации учебного процесса показаны ниже на рисунках 9.6, 9.7.

 

 
 

 

 

Рис. 9.6. Контекстная диаграмма функциональной модели организации учебного процесса

на отделениях (первый уровень функциональной модели)

Рис. 9.7. Фрагмент функциональной модели для организации учебного процесса

на отделениях (второй уровень декомпозиции)

 

 

 

 


хиты: 522
рейтинг:+1
Точные науки
информатика
для добавления комментариев необходимо авторизироваться.
  Copyright © 2013-2024. All Rights Reserved. помощь