Информационные системы

1. Информационная деятельность как атрибут основной деятельности.

В индустриальном обществе, где большая часть усилий направлена на

материальное производство, известно несколько основных видов ресурсов, которые
уже стали классическими экономическими категориями:
1. Материальные ресурсы – совокупность предметов труда, используемых в
процессе производства (сырье, материалы, топливо, энергия, детали и т.д.).
2. Природные ресурсы – объекты, процессы, природные условия.
3. Трудовые ресурсы – люди, обладающие общеобразовательными и
профессиональными знаниями, необходимыми для работы в обществе.
4. Финансовые ресурсы – денежные средства, которые находятся в
распоряжении государства или коммерческой структуры.
5. Энергетические ресурсы – носители энергии (уголь, нефть, газ,
электроэнергия и т.д.).
6. Информационные ресурсы – это знания, подготовленные людьми для
социального использования в обществе и зафиксированные на материальном
носителе. Знания материализуются в виде электронных и бумажных документов, БД,
БЗ, алгоритмов и программ, а также произведений искусства, литературы, науки.
Информационные ресурсы страны, региона, организации должны рассматриваться как
стратегические ресурсы аналогично другим ресурсам (по словарю Ожегова «Ресурс –
запасы, источники чего-либо»).
По мере развития общества происходит перераспределение трудовых ресурсов
из сферы материального производства в сферу информационного производства. Если в
начале XX века информационной деятельностью занималось 10% общества, то в
начале XXI века 50%. Материальные затраты общества на информационные
процессы превышают затраты в целом на энергетику. Это заставляет по новому
относиться к процессу накопления, хранения и использования информации, т. е.
Информация становится предметом труда и в результате этой трудовой деятельности
возникает новый вид ресурса – информационный.
Развитие мировых информационных ресурсов позволило:
- превратить деятельность по оказанию информационных услуг в глобальную
человеческую деятельность;
- сформировать мировой и внутригосударственный рынок информационных
услуг;
- образовать различные БД ресурсов регионов и государств, к которым
возможен недорогой доступ;
- повысить обоснованность и оперативность принимаемых решений на разных
уровнях управления (фирмы, отрасли, государства) за счет своевременного
использования необходимой информации.
Информационные ресурсы являются базой для создания информационного
продукта (как совокупности данных), который создается для конкретного
использования и отражает определенную предметную область для которой он создан.
Информационный продукт распространяется как и любой другой продукт с помощью
услуг – информационных услуг.
 Информационная услуга – получение и предоставление в распоряжение
пользователя информационного продукта. Информационная услуга может быть не
только с использованием компьютера, например, библиотека (подборка, анализ,
поиск). Рынок информационных продуктов и услуг (информационный рынок) – это
система экономических, правовых и организационных отношений по торговле
продуктами интеллектуального труда на коммерческой основе. Информационный
рынок характеризуется определенной номенклатурой продуктов и услуг, условиями и
механизмами их предоставления, ценами. Здесь в качестве предмета продажи или
обмена выступают информационные системы, ИТ, лицензии, патенты, товарные
знаки, ноу-хау, инженерно-технические услуги, различного рода информация и прочие
виды информационных ресурсов.
Основным источником информации для информационного обслуживания в
современном обществе являются БД. Инфраструктура информационного рынка
включает следующие виды информационных продуктов:
1. Деловая информация: статистическая, коммерческая, биржевая и
финансовая.
2. Потребительская информация: новости и литература, развлекательная,
предметно-ориентированные БД общего пользования.
3. Информация для специалистов: научно-техническая, профессиональная.
4. Услуги образования: дошкольное образование, школьное, специальное,
среднепрофессиональное, высшее, повышение квалификации и переподготовка
кадров.
5. Информационные системы и средства: разработка и сопровождение
информационных систем и инф. технологий; консультирование; программные
продукты; технические средства; подготовка источников информации.
Информационный рынок все больше расширяется и этому в значительной
степени способствует информационный бизнес, развитие которого тесно связано с
современными информационными технологиями.

2. Превращение информации в ресурс

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

2.1. Накопление данных.

Начальным источником любой информации является объект реального мира. За
счет процесса отражения наблюдатель выявляет характеристики этого объекта,
которые и составляют основу информации. Процесс отражения может протекать
естественным образом путем наблюдения либо с использованием современной
методологии, основанной на широком применении методов математического
моделирования и вычислительного эксперимента. При математическом
моделировании исходный объект заменяется математической моделью и процесс
отражения реализуется как изучение математической модели с помощью
вычислительно-логических алгоритмов на компьютере. Математическая модель может
быть проиграна в любых реальных и нереальных условиях.
 Независимо от характера эксперимента непосредственно либо опосредованно
наблюдатель пытается оценить характеристики объекта, как проявление его свойств во
времени. Эти характеристики находят свое отражение в информации, которая далее
накапливается и затем подвергается преобразованию. В ЭВМ информация хранится и
перерабатывается в некоторой символьной форме – форме данных. Под данными
понимаются факты и идеи, представленные в формализованном виде, который
позволяет передавать и обрабатывать эти факты и идеи с помощью соответствующих
технических и программных средств. Т.е. при вводе информации в компьютер
реализуется процесс преобразования информации в данные. Если данные нужно
преобразовать в информацию, их необходимо актуализировать и придать им
смысловое содержание.
Данные имеют определенный жизненный цикл актуального существования,
который в обобщенном виде можно представить следующей схемой.
Цикл начинается с процесса формирования данных, т.е. преобразования
информации в формализованный вид, затем осуществляется запись данных на
носитель и после этого хранение данных. Следующие этапы – поиск требуемых
данных, оценка данных с точки зрения их старения и содержательности. Большое
значение имеют экономические аспекты хранения данных: стоимость хранения
должна быть соизмерима с их ценностью. Поэтому необходимо регулярно выполнять
следующие этапы: сортировку данных, обработку в соответствии с реальными
вычислительными задачами, синтез данных – получение новых данных на основе
объединения отдельных элементов и анализа, воспроизведение данных в удобной для
использования форме, т.е преобразования их в информацию, необходимую для
принятия решений. При потере актуальности данные удаляются .
Все этапы в автоматизированной информационной системе (АИС) реализуются
с использованием разных методов и подходов. Например, формирование данных на
базе ССОД (систем сбора и обработки данных) или непосредственного ввода
документов.

2.2. Формирование знаний

Для ЛПР данные должны предоставляться в виде информации, на основе
которой могут быть приняты решения и определенные действия. Информационное
обеспечение ППР выполняет АИС, которая использует имеющийся информационный
ресурс. В настоящее время сформировалось новое научное направление, в котором
рассматриваются различные методы и способы формирования знаний на основе
данных, получения новых знаний на основе имеющихся информационных ресурсов в
АИС.
Различные виды знаний (конструктивные, процедурные или алгоритмические,
понятийные или системные, фактографические (Фактографическая информация -
результаты измерений, описаний и иного способа фиксирования в чистом виде,
поддающиеся метрологическому анализу, аналогично результатам экспериментов.)
хранятся в БД и БЗ АИС. Для их создания используется также математическое
моделирование и вычислительный эксперимент. В этом случае исключается
трудоемкий натурный эксперимент и реализуется подход “модель-алгоритм-
программа”. Концептуальная модель АИС, включающая в себя фактографические,
понятийные и конструктивные знания , является основой для формирования
алгоритмической модели, которая базируется на процедурные знания. Реализация
алгоритмической модели – это создание программного обеспечения. Цепь “модель-
алгоритм-программа” – это путь получения новой информации: вместо объекта
используется модель, на основе модели создается алгоритм получения характеристик
объекта и программно реализуется этот процесс.
Современные ИТ позволяют по новому организовать информационный процесс
как на стадии получения новой информации, так и на стадии использования
информационного ресурса для управления объектом. Непрерывно происходит
преобразование информации в данные, данных – в информацию и новые знания.
Информационные ресурсы концентрируются в БД, БЗ, ХД (Хранилище Данных).
Эффективность формирования и использования информационного ресурса зависит от
решения проблемы представления информации в этих базах, составляющих основу
АИС.
Существуют следующие методы интеллектуального анализа данных для получения
новых знаний и построения ХД, содержащих обобщенные показатели.
Поиск ассоциаций. Ассоциации как привязка значений к какому-либо одному
событию или выявление взаимосвязей в данных .
Поиск последовательностей. Поиск последовательных во времени событий.
Поиск скрытых закономерностей. Определяются причинно-следственные связи
между значениями определенных косвенных параметров исследуемого объекта
(ситуации, процесса) и распознаваемым свойством.
Оценка важности (влияния) параметров на события и ситуации. Известно, что на
наступление некоторого события или ситуации влияет некоторый набор параметров.
Необходимо оценить степень этого влияния для перечисленных параметров.
Классификация. Рассматривается конечное число классов объектов, которыми
могут быть, в том числе, события, ситуации или процессы. Объекты должны быть
описаны количественными значениями свойств.
Классы описаны с помощью набора объектов, принадлежность которых данному
классу априорно известна. Требуется найти критерии, по которым можно было бы
отнести объект к тому или иному классу.
Кластеризация. Кластеризация напоминает классификацию, за тем исключением,
что критерии классификации не заданы.
Прогнозирование. Оценка состояния объектов на основе ретроспективного анализа
их свойств. По истории развития объекта управления определяются обобщенные
показатели на некоторое время вперед.

2.3. Свойства и назначение ХД

Концепция ХД получила развитие вследствие желания конечных пользователей
(ЛПР) иметь непосредственный единообразный доступ к необходимым им данным,
источники происхождения которых организационно и территориально распределены,
а анализ может повысить эффективность генерации ППР. В этом контексте наиболее
актуальной проблемой является обеспечение интегрированного представления о
сложном ОУ в целом, комплексного анализа собранных о нем сведений и извлечения
из огромного объема детализированных данных некоторой полезной информации –
знаний о закономерностях его развития.
Поддержка принятия управленческих решений на основе накопленной
информации может осуществляться в трех основных областях:
 1. Область детализированных данных. Это сфера действия большинства
оперативных, или транзакционных систем (OLTP – On Line Transaction Procession),
нацеленных на поиск детальной информации. В большинстве случаев реляционные
СУБД отлично справляются с возникающими здесь задачами.
2. Область агрегированных показателей. Комплексный взгляд на собранную
в ХД информацию, ее обобщение и агрегация, гиперкубическое представление и
многомерный анализ являются задачами систем оперативной аналитической
обработки данных (OLAP- On Line Analytical Procession). Здесь можно или
ориентироваться на специальные многомерные СУБД, или (как правило,
предпочтительнее) оставаться в рамках реляционных технологий. Во втором случае
заранее агрегированные данные могут собираться в специальной БД, либо агрегация
информации может производиться в процессе обработки детализированных таблиц
реляционной БД в интерактивном режиме.
3. Область закономерностей. Интеллектуальная обработка производится
методами интеллектуального анализа данных (Data Mining), главными задачами
которых являются поиск функциональных и логических закономерностей в
накопленной информации, построение моделей и правил, которые объясняют
найденные аномалии и/или (с определенной вероятностью) прогнозируют развитие
рассматриваемых процессов.
Предметом концепции ХД служат непосредственно данные. После того, как
традиционная система обработки данных (СОД) реализована и начинает
функционировать, она становится неотъемлемой частью производственного процесса.
Данные, которые являются одним из конечных продуктов деятельности СОД,
обладают такими же характеристиками, что и любой промышленный продукт: сроком
годности, местом складирования (хранения), совместимостью с данными из других
производств (СОД), рыночной стоимостью, транспортабельностью, комплектностью,
ремонтопригодностью.
Для обеспечения выполнения большой частоты аналитических запросов и
эффективной обработки огромных массивов информации могут быть использованы
различные технологии представления данных, отличные от классического
реляционного представления. В отличие от БД в традиционных OLTP-системах, где
данные подобраны в соответствии с конкретными приложениями, информация в ХД
ориентирована на задачи принятия решений и представляется в виде обобщенных или
агрегированных данных – знаний о поведении объекта управления.
Для пользователя OLAP-системы требуются метаданные, по крайней мере,
следующих типов:
- описание структур данных, их взаимосвязей;
- информация о хранимых в ХД и поддерживаемых им агрегатах данных;
- информация об источниках данных и о степени их достоверности. Одна и та же
информация могла попасть в ХД из разных источников. Пользователь должен иметь
возможность узнать, какой источник был выбран основным, каким образом
производились согласование и очистка данных;
- информация о периодичности обновлений данных. Желательно знать не только
то, какому моменту времени соответствуют интересующие его данные, но и когда они
в следующий раз будут обновлены;
- информация о владельцах данных. Пользователю OLAP-системы может
оказаться полезной информация о наличии в системе данных, к которым он не имеет
доступа, о владельцах этих данных и о действиях, которые он должен предпринять,
чтобы получить доступ к данным;
- статистические оценки времени выполнения запросов. До выполнения запроса
полезно иметь хотя бы приблизительную оценку времени, которое потребуется для
получения ответа, и объема этого ответа.
Уже сейчас известны примеры ХД, содержащих терабайты информации.
Проблемой таких больших хранилищ является то, что накладные расходы на внешнюю
память возрастают нелинейно при возрастании объема ХД. Исследования показали, что
для ХД объемом в 100 гегабайт потребуется внешняя память объемом в 4,87 раза
большая, чем нужно собственно для полезных данных. При дальнейшем росте ХД этот
коэффициент увеличивается.

3. Направления развития АИС

Высокие темпы развития информационных технологий в настоящее время

обеспечивают постоянное совершенствование систем сбора и обработки данных,
способы представления данных в БД и БЗ, создание новых методологий
формирования ХД с целью повышения эффективности вырабатываемых
управленческих решений. Новые средства и возможности информационных
технологий порождают новые запросы пользователей и диалектический процесс
автоматизации всех аспектов организационного управления формирует
информационный бизнес в этой области.
Несмотря на высокий существующий уровень автоматизации организационного
управления на всех уровнях темпы развития информационного бизнеса все больше
увеличиваются. Анализ этапов развития информационного бизнеса в области
организационного управления показывает, что формируются циклы с непрерывным
переходом на более высокий уровень автоматизации процессов принятия решений, а в
пределах одного цикла включаются новые аспекты информационных технологий.
Процесс развития информационного бизнеса тесно связан с информационными
технологиями. Развитие информационных технологий по циклам приводит к
необходимости реинжиниринга существующих АИС. Но, как правило, сложно
определить на каком этапе проводить реинжиниринг, чтобы получить наибольший
положительный эффект. Неопределенность возникает по следующим двум факторам.
Во-первых, до определенного уровня эффективнее использовать хорошо настроенные
АИС и решать вопросы интеграции с новыми информационными технологиями путем
надстройки дополнительных функциональных модулей. В этом случае возникает
опасность "бесконечного" подстраивания системы к новым условиям, что в конечном
итоге сделает ее неэффективной и, возможно, неработоспособной. Кроме этого,
стоимость самой АИС будет увеличиваться за счет новых компонентов и сильной
привязки к предметной области, а эффективность будет снижаться за счет
использования громоздких информационных технологий. К тому же, это
противоречие увеличивается с течением времени функционирования АИС.
Во-вторых, можно произвести реинжиниринг на новой базовой основе. Возникает
неопределенность во времени и масштабе реинжиниринга, так как использование
новых информационных технологий приведет к необходимости заменить многие
компоненты функциональной системы. Значительные материальные затраты
потребуются на приобретение новых информационных технологий, но еще большая
часть затрат возникает в процессе перехода от существующих технологий к новым
информационным технологиям. В процессе функционирования эволюционной модели
интеллектуальных информационных технологий в организационном управлении
производственными процессами создается значительный объем взаимосвязанных
данных, жизненный цикл которых еще не завершился. Из-за разнородности моделей
данных и способов их физического представления возникает необходимость переноса
накопленных в предметной области знаний и данных в новую программную среду.
Также необходимо перенести накопленный опыт функционирования самой
информационной системы на новую платформу.
Реализация интерфейса АИС, обучение пользователей не вызывает особых
затруднений. Но даже автоматизированное транспортирование больших объемов
информации приводит на практике к появлению ошибок и потере данных из-за
изменения модели данных и формы их представления. К тому же, в
функционирующих автоматизированных системах специалисты должны вести
параллельную обработку текущей информации. Если входные потоки данных имеют
большой объем и переменный жизненный цикл по группам потока, то перед ЛПР
возникает сложная многомерная задача по управлению потоками данных.
К указанным факторам необходимо добавить также следующее. Современные
информационные технологии усложняются по мере их совершенствования с точки
зрения функционального богатства и интеграции. В связи с этим для их эффективного
использования требуется все более высокая квалификация непосредственных
пользователей-специалистов помимо квалификации их в своей специальной области.
АИС – это человеко-компьютерные системы для поддержки принятия решений и
производства информационных продуктов, использующие определенные
информационные технологии. Они обеспечивают сбор, хранение, обработку, поиск,
выдачу информации, необходимой в процессе принятия решений, помогает
анализировать проблемы и создавать новые информационные продукты. Первые АИС
появились в 50-х годах. Развитие АИС и их назначение тесно связано с развитием
информационных технологий (но это разные понятия: ИТ могут существовать и вне
АИС, а реализация функций АИС без использования ИТ невозможна). Можно
выделить следующие этапы развития АИС в управлении экономикой, которые
приведены в таблице 1.1.

Таблица 1.1
Год Вид АИС Вид создаваемого Назначение АИС
информационного
продукта
1950- АИС для обработки Расчетные Повышение скорости
1960 расчетных документы на обработки документов
документов бумажном и вычислительных
носителе операций
1960- АИС для Сводные Ускорение процесса
1970 планирования и аналитические и подготовки отчетности.
управления другие отчеты на Систематизация
производственной бумажном производственной
деятельностью носителе деятельности
предприятий,
 организаций
1970- АИС в форме Базы данных, базы Выработка наиболее
1980 автоматизированных знаний рациональных
систем с принятием управленческих
решений решений
1980- Стратегические Объектно- Повышение
2003 АИС. ориентированные конкурентоспособности
Комплексные АИС БД, ХД, БЗ предприятий и более
(автоматизированные высокий уровень их
офисы) развития

4. Производственная система

Объектами автоматизированного управления являются: производство, научный

эксперимент, комплексные испытания, объекты социальной сферы и др. Наибольшее
значение имеет производство как источник экономического эффекта. Под
производством понимается организационно-экономическая деятельность на основе
единства целей функционирования, технологий, входных и выходных продуктов труда
(производственные продукты, услуги). Любое производство представляет собой
систему, которая функционирует в условиях воздействия окружающей среды. С
внешней средой производство связано через ресурсные отношения и информационные
связи. Производство направлено на достижение цели управления, например, получение
прибыли для предприятия или организации. Управление производством
осуществляется через производственные процессы. Производственный процесс – это
определенное воздействие на определенный ресурс в соответствии с поставленной
целью управления.
Организационное управление направлено на эффективную организацию
производственных процессов путем управления всеми видами ресурсов –
материальными, финансовыми, энергетическими, информационными, трудовыми.
Управляющими параметрами при этом являются объемы и темпы выпуска товарной
продукции необходимой номенклатуры. Под воздействием возмущений,
возникающих по вероятностным законам, появляются отклонения от заданных
параметров. Устранение возникающих отклонений происходит своевременным
принятием управленческих решений или выработкой управляющих воздействий, в
совокупности представляющих собою организационное управление. Оно заключается
в выделении ресурсов путем их размещения, изменения мощностей,
последовательности применения, сочетания, анализа различных вариантов решений
на количественной основе, выбора наилучшего варианта решений.
На рис. 4.1. показана общая структура производственной системы, в которой
взаимодействуют следующие наиболее динамические потоки:
- материальный поток W, представленный в системе предметами труда (сырья,
материалы, полуфабрикаты, запасные части);
- поток орудий труда М (инструментов, технологических машин, транспортных
средств, учитываемых в трудовом коллективе);
- поток труда рабочих R – непосредственная работа над предметами труда и
совместная деятельность с использованием орудий труда;
 - энергетический поток Э, образующийся в результате потребления электрической,
механической, других видов энергии;
- информационный поток H, адекватно отражающий состояние всех других
потоков.
Производственный процесс как определенное воздействие на определенный вид
ресурса образует поток готовой продукции Y. Являясь целью интеллектуальной
деятельности специалистов или ЛПР, он изначально задается по темпу и объему
выпуска.

Рис.4.1. Система управления производственными процессами

В реальных условиях в производственной системе возникают различные

нарушения в установившемся балансе динамичных потоков, что проявляется в
различных формах. В материальном потоке W это может быть неполная номенклатура
материалов, запасных частей, узлов, агрегатов, срывы графика движения транспортных
средств, наличие брака или некомплектность поставки. В потоке орудий труда М –
отказы или снижение производительности технологических машин, ухудшение
качества или брак инструмента, внезапные выходы из строя оборудования. В потоке
труда рабочих R – нехватка квалифицированных кадров, неправильное использование
имеющихся рабочих, увольнения, болезни. В энергетическом потоке Э – выход из
строя источников энергии, изменение их параметров, обрывы линии питания,
отсутствие необходимого сервисного оборудования, нарушение правил техники
безопасности. В информационном потоке Н – неточное определение расчетных
показателей, отражающих ход производственных процессов, конструктивные
переделки в чертежах, запаздывания в доставке технологической и сопроводительной
документации.
Указанные нарушения приводят к изменению объемов и темпов выпуска товарной
продукции. Они относятся к первой отрицательной группе возмущающих воздействий
. Вторая положительная группа возмущающих воздействий образуется за счет
появления новых возможностей: увеличения скорости потоков путем использования
высокопроизводительного оборудования, повышения квалификации кадров, более
прогрессивной оплаты труда и др. Возникающие отклонения в ресурсах приводят к
различным производственным ситуациям. Нежелательные ситуации устраняются за
счет создания запасов и резервов, а также простым устранением возмущающих
воздействий.
Одновременно возникают достаточно сложные нежелательные ситуации, способы
устранения которых неочевидны, неоднозначны и содержат неопределенности в
выборе управляющих воздействий. Причины их возникновения носят объективный
характер. Неопределенность связана с тем, что ход производственных процессов в
пространстве и во времени подвержен действию значительного числа возмущающих
воздействий, возникающих по вероятностным законам. Неоднозначность определена
множеством способов устранения нежелательных ситуаций, последствия от которых в
условиях многофакторности системы "человек-машина" трудно прогнозировать.
Фактически даже при наличии ресурсов в сложных системах "человек-машина"
интеллектуальная деятельность ЛПР протекает в условиях дефицита в них из-за трудно
учитываемого множества нежелательных ситуаций. Дефицит в ресурсах может быть
также искусственно создан в результате негативных последствий от ошибочных
решений ЛПР, либо из-за несвоевременно полученной или отсутствия информации о
наличии и движении ресурсов.

5. Информационное обеспечение процессов управления

Функционирование производства происходит в соответствии с некоторой целью

управления, которая задается в виде входной информации производственной системы
Hвх. Чтобы преобразовать входной материальный поток в готовую продукцию
необходима последовательность действий, которая должна быть оптимальной исходя
из некоторого плана. Форма воздействий на элементы материального потока задается
также входной информацией системы. Источником такой информации является
концептуальная модель, отображающая требуемые характеристики готовых изделий
конечной продукции. Конкретно концептуальная модель может быть представлена в
виде технического задания, которое на логическом уровне переводит эту информацию
в алгоритмическую модель, то есть в последовательность действий в соответствии с
выбранной технологией производства продукции. Информационный поток Н (Нвх и
Нвых) адекватно отражает состояние потоков R,W,Э,М. В результате взаимодействия
потоков (R,W,Э,М,I) образуется поток готовой продукции на выходе производственной
системы У.
Поток Нвх на основе концептуальной модели определяет плановые или
расчетные значения параметров производственных процессов, Нвых отражает текущее
состояние производственных процессов. Сопоставление плановых значений с
текущими позволяет выработать управленческую информацию. Получение
управленческой информации связано с большим объемом обработки и
моделированием управляющей деятельности специалистов предметной области.
Процессы управления в зависимости от решаемых задач можно разделить на
несколько уровней:
1. Организационно-экономическое управление как предприятием в целом так и
отдельными его подразделениями, которое позволяет достичь оптимальное значение
критериев эффективности, например, максимальной прибыли. На этом уровне
актуально применение ХД и OLAP – технологии для представления информации.
2. Организационно-технологическое управление – управление средствами и
предметами труда, производственными отношениями с целью оптимального их
использования. Эффективны OLAP – технологии.
3. Управление технологическими процессами с учетом внешних возмущений.
Основной целью функционирования любого производства является получение
заданного количества продуктов труда при гарантированном уровне его качества.
Эффективны OLTP – технологии обработки и представления данных.
Решение задачи управления производственными процессами означает наличие
идеализированной (эталонной) модели функционирования ОУ, получение модели его
фактического состояния и на основе их сравнения определение отклонения, с учетом
которого формируются управляющие воздействия. В производственной системе
управляющее воздействие – это выделенный ресурс. На основе этих задач процесс
управления включает три фазы:
 планирование (определение плановых показателей и программной траектории
управляющей системы. Без планирования не существует организационное управление);
 учет – получение данных о состоянии ОУ (производственных процессов);
 регулирование – нахождение управляющих воздействий, устраняющих
случайные возмущения.
В процессе производства возникает взаимодействие управляющей системы
(автоматической либо автоматизированной) с ОУ и устанавливается регулярный обмен
информацией, что позволяет реализовать оптимальный ход производственных
процессов. В системе управления с иерархической структурой у каждой подсистемы
должна существовать своя цель. Для эффективного функционирования системы
необходимо, чтобы цели подсистем более низкого уровня были согласованы с целями
подсистем более высокого уровня. То есть возникает иерархия целей. Дерево целей для
предприятия – это может быть план мероприятий в целом для предприятия и по
подразделениям. Оптимальное управление заключается в выборе наилучшего по
некоторому критерию эффективности управляющего воздействия из множества
возможных в соответствии с установленной целью управления, учетом ограничений и
на основе информации о состоянии ОУ и внешней среды. При реализации
оптимального управления важное значение имеет критерий эффективности –
показатель, по которому определяется эффективность функционирования
производственной системы. Таких показателей может быть много, что характерно для
сложной системы (многокритериальная система). Значения критериев эффективности
представляются в сводных отчетах предприятия, аналитических отчетах, балансе.
Аналогично дереву целей может быть построено дерево критериев.
В зависимости от уровня управления определяются функции и назначение АИС.
Чем выше по значимости уровень управления, тем меньше объем работ, выполняемых
специалистами с использованием АИС. Но при этом возрастает сложность и
интеллектуальные возможности АИС, ее роль в принятии решений. Любой уровень
управления нуждается в информации из всех функциональных производственных
подсистем, но в разных объемах и с разной степенью обобщения.

6. Программное обеспечение информационных систем

Программное обеспечение (ПО) информационных систем (ИС) включает:

 базовое ПО- это операционные системы (ОС) и системы управления базами
данных (СУБД);
 программные средства моделирования и проектирования ИС;
 средства реализации ИС – языки программирования;
 программное приложение, которое обеспечивает автоматизированное
выполнение задач предметной области.

6.1 Сравнительный анализ ОС

От операционной системы зависит эффективность выполнения приложений;
производительность, степень защиты данных, надежность работы сети; возможность
использования оборудования разных изготовителей; применение современных
информационных технологий и их развитие.
Выбор ОС производится исходя из следующих требований:
1. Соотношение стоимость/производительность.
1. Функциональные возможности.
2. Надежность функционирования.
3. Защита данных.
4. Возможность генерации ядра под конкретную структуру аппаратных средств.
5. Особенности функционирования и режимы работы ОС, позволяющие решать
поставленные задачи.
6. Все современные ОС поддерживают сетевой режим, но при этом требования
к серверу и рабочим станциям могут быть разными по следующим параметрам:
а) требуемый объем оперативной памяти;
б) требуемый объем дисковой памяти;
в) совместимость с другими системами.
7. Поддержка удаленного доступа к терминалам.
8. Перспективы развития всей вычислительной системы.
9. Поддержка стандартов.
10.Простота администрирования и установки.
Исходя из вышеперечисленных требований, для сравнительного анализа
включены популярные в настоящее время ОС Windows и ОС семейства Unix,
предназначенные для непосредственной работы в сетевом режиме и составляющие два
конкурирующих направления.

Windows NT
Стоимость Windows NT сравнительно невелика, но стоимость сервера и сети в
целом (с учетом дополнительного необходимого программного обеспечения) является
высокой. Обновление версий требует также значительных вложений в ПО и
аппаратные средства.
 Использование встроенных протоколов ТСР/IР и NetBios как основных
обеспечивает взаимосвязь с другими типами сетей и их приложениями. Возможность
исполнения Windows - приложений на сервере в процессе функционирования сети
позволяет делать его невыделенным.
В качестве достоинств можно также отметить следующие:
- простота установки и администрирования;
- высокая степень надежности при сбоях;
- защита класса С2;
- встроенная технология статического и динамического обмена данными между
Windows - приложениями (OLE (Object Linking and Embedding) - технология
позволяющая редактировать данные, созданные в другой программе, не выходя из
основного редактора. и DDE технологии Связь DDE (динамический обмен данными)
между файлом-"источником" (сервером) (например, электронной таблицей Excel) и
файлом данных системы STATISTICA (файлом-"клиентом") устанавливается таким
образом, что при внесении изменений в файл-источник в таблице исходных данных
системы STATISTICA (файле-клиенте) данные будут автоматически обновляться.);
- развитый графический интерфейс.
К недостаткам можно отнести следующие особенности:
- алгоритмы распределения оперативной памяти между процессами не могут
быть оптимизированы для выполнения большого количества активных фоновых
задач;
- в связи с тем, что система очень требовательна к аппаратным ресурсам,
обладает малой производительностью;
- невозможно конфигурировать для нестандартных аппаратных средств и
неэффективно используется стандартное программное обеспечение для нетипичных
конфигураций аппаратуры;
- для реализации виртуальной памяти используется страничная подкачка образов
процессов, а не общего пула памяти - что обеспечивает оптимизацию системы для
применения на рабочих станциях, но делает невозможной ее оптимизацию для
сервера.
В связи с этим Windows NT обладает невысокой производительностью в качестве
сервера;
- соответствует стандарту POSIX (стандарт для реализации UNIX - совместимых
систем), но отсутствует возможность генерации ядра, не поддерживается режим
реального времени;
- повышенное внимание к вопросам безопасности ограничивает совместимость
Windows NT с различными программами, в том числе с коммуникационными
программами, что также снижает производительность системы.

ОС семейства UNIX (SCO UNIX, SOLARIS, LINUX и др.)

Цена ОС UNIX как сервера сравнима с Windows NT, но UNIX может работать
на более дешевых серверах, чем другие системы того же класса. В то же время UNIX
используется на широком спектре серверов высокого класса, на которых эксплуатация
других систем неэффективна или невозможна. Поэтому средняя цена UNIX сервера
фактически не может быть сравнима с ценами других серверов. Конкретно для класса
РС серверов стоимость проекта в целом для варианта UNIX ниже любого другого
варианта.
 Сеть по протоколам TCP/IP является неотъемлемой частью ОС семейства UNIX.
Поддерживаются любые сети, от локальных до Internet, с использованием только
встроенных сетевых средств. Наиболее полное соответствие стандартам. Алгоритмы
планирования памяти и планирования процессов оптимизированы для
многозадачных приложений с большим количеством активных фоновых задач.
Наилучшим образом соответствует применению в качестве сервера. Обеспечивается
поддержка удаленных терминалов. Наиболее развитая поддержка баз данных, в том
числе "в реальном времени", наиболее богатые фонды прикладных программ для
промышленного применения. Имеют защиту класса C2. Ряд версий UNIX позволяют
обеспечить защиту с помощью независимых пакетов. Это сделано в связи с запретом
экспорта средств защиты данных из США.
Только система UNIX обеспечивает возможность генерации ядра, что позволяет
реализовать масштабируемость и возможность адаптации к нетиповым
конфигурациям аппаратных средств. Кроме того, статическое конфигурирование
системы эффективнее и безопаснее динамического.
UNIX является не только многозадачной, но и многотерминальной системой, что
в сочетании с поддержкой встроенных протоколов TCP/IP автоматически решает
проблемы удаленного доступа. Графическая оболочка (KDE, X-Windows)
обеспечивает сетевой, многотерминальный графический интерфейс.
Операционная система UNIX содержит все необходимые средства для
организации сетей любого уровня согласно международным стандартам: RFC-791,
RFC-768, RFC-793, TCP/IP, RFC-959 - FTP; RFC-1198-X Windows, RFC-976-MAIL;
и др.
Очень мощная и гибкая операционная система, но для ее эффективного
использования необходима высокая квалификация в области системного
администрирования.
Целесообразно использование только новейших версий систем семейства UNIX
(Linux), обладающих следующими особенностями:
- высокой производительностью и устойчивостью к сбоям файловой системы;
- высокопроизводительной модификацией сетевой файловой системы NFS;
- развитым графическим интерфейсом пользователя и администратора.
К недостаткам можно отнести то, что в настоящее время Unix-системы мало
используются в нашей стране на предприятиях, в организациях. Это связано с
недостаточным освещением преимуществ ПО UNIX, отсутствием рекламы на нее,
высокими требованиями к уровню квалификации по администрированию системы,
отсутствием до последнего времени офисных приложений, совместимых с Windows-
приложениями на уровне данных.
Заключение.
Для организации серверов приложений (SQL серверов) целесообразно
использование операционной системы UNIX, остальные ОС в качестве серверов
приложений менее эффективны.
Для реализации файл-серверов может быть использована любая современная
система. Но при этом Windows NT требует наибольших аппаратных ресурсов. При
невысокой пропускной способности каналов связи UNIX позволяет оптимизировать
доступ за счет маршрутизации пакетов.
Для реализации серверов удаленного доступа целесообразно использование
UNIX, поскольку не требует установки каких-либо дополнительных пакетов. Windows
NT требует больших аппаратных ресурсов с очень высокой стоимостью и не
предназначен для организации серверов удаленного доступа с малым числом
соединений.
Наиболее эффективной ОС по стоимости, производительности,
функциональным возможностям, защите данных и перспективе развития являются
операционные системы семейства UNIX.

6.2. Основные требования для работы ОС в сетевом режиме

Когда pечь идет о пpименении многопользовательской БД, используемой не
только в АРМ одного специалиста, но и в АРМах других специалистов, сетевая ОС
должна обладать возможностью организации файл-сервера. Кроме того, сетевые ОС с
сервером должны обеспечивать высокое быстродействие для сетей с большим числом
пользователей.
При создании ЛВС на базе сервера ключевым фактором является надежность,
после чего следуют такие фактоpы, как поддержка рабочих станций и показатели
быстpодействия. С точки зpения обеспечения надежности самое главное - это
эффективные средства управления памятью, поскольку без этого при большом числе
пользователей могут возникнуть ситуации, когда рабочие станции будут терять связь
друг с другом, а файл-серверы окажутся неработоспособными. Термин надежность
охватывает также понятие совместимости: сетевая ОС должна хорошо работать со
всеми распространенными многопользовательскими прикладными программами и
стандартными программными средствами. Надежность также означает, что сервер и
рабочие станции работают в сети без сбоев, прикладные программы выполняются
правильно, а сетевая ОС защищает данные при отказах аппаратуры. Требуется полный
набор средств защиты от ошибок, защита данных на уровне отдельных записей БД,
эффективные средства управления памятью и надежные механизмы организации
многозадачной работы. Важными также являются требования по поддержке рабочих
станций. Если сетевые драйверы занимают слишком много памяти на каждом ПК, то
возможна ситуация, когда на рабочей станции не будут выполняться прикладное ПО и
утилиты, резидентно размещающиеся в ОЗУ.
Быстродействие особенно важно при эксплуатации многопользовательских
программных пакетов, так как оно определяет эффективность выполнения SQL –
запросов и сколько дополнительных пользователей сможет обслуживать система,
прежде, чем появится необходимость в приобретении второго сервера.
Следующим по важности фактором после быстродействия являются средства
административного управления. Гибкие административные средства обеспечивают
установку и настройку сети с меньшими затратами времени. Сетевая ОС должна
предоставлять гибкие возможности разделения ресурсов в ЛВС - принтеров, модемов
и внешней памяти.

7. Выбор СУБД

Выбор СУБД зависит от организации локальной и сетевой базы данных (БД),

стоимости, специфики решаемых задач, функциональных особенностей (поддержка
целостности, уровень защиты данных, быстродействие, эффективно обрабатываемый
объем данных в БД, сетевая поддержка, наличие среды разработки, взаимодействие с
другими приложениями, в том числе Интернет-приложениями).
Необходимо рассмотреть следующие методологии организации сетевой базы
данных:
1. БД хранится централизованно на сервере, а доступ со стороны рабочих
станций по сети;
2. БД распределена по компьютерам-рабочим станциям, но жестко
зафиксирована.
Выбор сетевого протокола (ODBC, Microsoft, Novell).
Сетевой протокол используется для доступа к данным в удаленной БД. Он
позволяет интегрировать разнородные БД.
Выбор осуществляется в соответствии с международным стандартом ISO
(семиуровневой модели) и определяется следующими критериями:
1. Производительностью и эффективностью для обеспечения необходимой
скорости обработки запросов и ответов.
2. Возможностью его реализации существующим программным обеспечением с
использованием доступных системных модулей. В сети могут быть установлены
одинаковые SQL сервера, тогда можно использовать сетевой протокол SQL сервера, а
не использовать дополнительное ПО для реализации стандартного протокола
(ODBC).
Сетевой протокол должен соответствовать международному стандарту ISO. К
такому протоколу относится ODBC, который универсально подходит для
взаимодействия с любыми СУБД.

Выбор метода авторизации.

1. Стандарт ISO подразумевает хранение списка пользователей с прописанными
правами вместе с основной БД. Авторизация реализуется средствами СУБД.
2. Второй вариант подразумевает хранение списка пользователей не
непосредственно в БД, а в операционной системе. В этом случае авторизация
пользователей сетевая и реализуется на уровне ОС.
Резервирование БД.
Для обеспечения надежности хранения данных обязательно создается копия БД.
Централизованные БД, как правило, копируются на сервере. Для распределенных БД
существуют разные стратегии:
1) создание резервной копии БД на самой рабочей станции, либо на любой
рабочей станции в сети;
2) создание резервной копии на Backup сервере. С помощью специальной
программы Backup автоматически создается зеркальная копия БД на любом сетевом
компьютере достаточной мощности, который и является Backup-сервером.
Создание системы прав доступа.
Проектируется система прав доступа, т.е. определяется кому и сколько дать
прав для доступа к БД (только чтение, чтение и модификация, отсутствие прав на
предоставление информации). Детализация прав зависит от возможностей СУБД.
Права доступа могут быть определены на уровне всей БД, отдельных реквизитов,
отдельных записей или отдельных значений.
Скорость обработки запросов и ответов.
 SQL запросы необходимо сформировать таким образом, чтобы объем
передаваемой информации по сети был минимальным, т.к. он лимитируется сетевыми
средствами. Т.е. необходимо составлять максимально подробные SQL запросы, для
того чтобы обработка базы данных проходила преимущественно на сервере, а не на
клиентской машине. Для этого целесообразно использовать хранимые процедуры,
которые хранятся и выполняются на сервере. Хранимые процедуры и запросы к ним
должны быть предварительно спроектированы с учетом возможностей СУБД. Если
SQL не оптимизированы, то возможности СУБД не будут эффективно использованы.
Передаваемые объемы информации.
Необходимо по возможности сократить объем запросов в объявленных
транзакциях, для того чтобы уменьшить время блокировки записей (транзакция
включает один или несколько SQL-запросов). Некоторые СУБД во время доступа к
данным блокируют запись БД и в режиме чтения данных для всех остальных запросов
(которые ставятся при этом в очередь). Запись остается заблокированной пока не
будут обработаны все адресованные к ней запросы. Существуют также СУБД или
соответствующие настройки, которые не блокируют запись при чтении, а делают ее
временную копию, размещаемую в ОЗУ. Запись блокируется только при ее
модификации. В этом случае значительно уменьшается время обработки SQL –
запросов.
Особенности для распределенных БД
Важным является способ распределения информации в сети.
Информация может храниться на той рабочей станции где производится ее
первичная обработка. Она может также распределяться и храниться на любой другой
рабочей станции, где в ней есть потребность. Существуют также варианты, когда
информация дублируется по всем машинам (метод хеширования). СУБД должны
обеспечить целостное представление и резервирование данных.
Для распределенной БД критичной может быть организация транзакций
(операции, связанные с обработкой данных при выполнении запросов/ответов).
Современные СУБД по уровню применения в производственных
информационных системах можно классифицировать в следующем порядке:
1. Ocacle;
2. PostgresQL, IBM DB2;
3. MySQL, MS SQL;
4. FoxPro, Access, Paradox
Объектно-ориентированная СУБД (Oracle, PostgresQL) наиболее эффективна для
организации распределенной БД, поскольку взаимосвязи присутствуют в явном виде
(прописаны в рамках объекта, который включает множество параметров,
характеризующих его). Это обеспечивает наглядность их представления и
эффективность обработки по скорости и объему. Они обеспечивают также гибкие
модели данных (изменение структуры без перепроектирования).

7.1. Особенности объектно-ориентированных СУБД

Первой формализованной и общепринятой моделью данных была реляционная
модель Кодда. В этой модели, как и во всех следующих, выделялись три аспекта –
структурный, целостный и манипуляционный. Структуры данных в реляционной
модели основываются на плоских нормализованных отношениях, ограничения
целостности выражаются с помощью средств первого порядка, манипулирование
данными осуществляется на основе реляционной алгебры или равносильного ей
реляционного исчисления.
В объектно-ориентированной базе данных (ООБД) хранятся не записи данных, а
объекты, отображающие объекты некоторой предметной области. Каждый объект
обладает внутренним состоянием, т.е. хранит внутри себя запись данных, а также
набором методов - процедур, с помощью которых можно обратиться к этим записям
данным. Конструирование ООБД состоит в разработке структуры и методов
(поведения) объектов.
В настоящее время ведется много экспериментальных и производственных
работ в области ООБД. Наиболее мощные и популярные СУБД, такие как Oracle,
PostgresQL, Orion, Ingres и другие поддерживают объектные модели данных.
ООБД включают компоненты обработки запросов, управления схемой
(структурой) модели данных и версиями объектов. При изменении схемы
автоматически отслеживается влияние этого изменения на другие компоненты схемы
и на существующие объекты, тогда как в реляционных СУБД для схемы БД версии не
поддерживаются и изменение структуры приводит к необходимости ее
перепроектирования.
При обработке запросов в ООБД используется техника оптимизации, то есть
формируется набор возможных планов выполнения запросов, оценивается стоимость
каждого из них и выбирается для выполнения наиболее дешевый. Подсистема
управления транзакциями обеспечивает традиционную сериализуемость транзакций и
кроме этого поддерживает журнализацию изменений и восстановление БД после
сбоев. Для сериализации транзакций используются разновидности протоколов,
синхронизирующие доступ к данным с учетом специфики ООБД (например, иерархию
классов). Журнал изменений обеспечивает откаты индивидуальных транзакций и
восстановление БД после мягких сбоев (например, архивные копии БД для
восстановления после поломки дисков).

8. Классификация информационных систем

Информационные системы классифицируются по разным признакам. Рассмотрим
наиболее часто используемые способы классификации.
Классификация по масштабу
По масштабу информационные системы подразделяются на следующие группы (рис.
8.1):
□ одиночные;
□ групповые;
□ корпоративные.

Рис. 8.1 Деление информационных систем по масштабу

Одиночные информационные системы

Одиночные информационные системы реализуются, как правило, на автономном
персональном компьютере (сеть не используется). Такая система может содержать
несколько простых приложений, связанных общим информационным фондом, и
рассчитана на работу одного пользователя или группы пользователей, разделяющих по
времени одно рабочее место. Подобные приложения создаются с помощью так
называемых настольных, или локальных, систем управления базами данных (СУБД).
Среди локальных СУБД наиболее известными являются Clarion, Clipper, FoxPro,
Paradox, dBase и Microsoft Access.

Групповые информационные системы

Групповые информационные системы ориентированы на коллективное использование
информации членами рабочей группы и чаще всего строятся на базе локальной
вычислительной сети. При разработке таких приложений используются серверы баз
данных (называемые также SQL-серверами) для рабочих групп. Существует довольно
большое количество различных SQL-серверов как коммерческих, так и свободно
распространяемых. Среди них наиболее известны такие серверы баз данных, как Oracle,
DB2, Microsoft SQL Server, InterBase, Sybase, Informix.

Корпоративные информационные системы

Корпоративные информационные системы являются развитием систем для рабочих
групп, они ориентированы на крупные компании и могут поддерживать территориально
разнесенные узлы или сети. В основном они имеют иерархическую структуру из
нескольких уровней. Для таких систем характерна архитектура клиент-сервер со
специализацией серверов или же многоуровневая архитектура. При разработке таких
систем могут использоваться те же серверы баз данных, что и при разработке групповых
информационных систем. Однако в крупных информационных системах наибольшее
распространение получили серверы Oracle, DB2 и Microsoft SQL Server.
Для групповых и корпоративных систем существенно повышаются требования к надежности
функционирования и сохранности данных. Эти свойства обеспечиваются поддержкой
целостности данных, ссылок и транзакций в серверах баз данных.
Классификация по сфере применения
По сфере применения информационные системы обычно подразделяются на четыре
группы (рис. 8.2):
□ системы обработки транзакций;
□ системы поддержки принятия решений;
□ информационно-справочные системы;
□ офисные информационные системы.
 Рис. 8.2 Деление информационных систем по сфере применения

Системы обработки транзакций, в свою очередь, по оперативности обработки данных

разделяются на пакетные информационные системы и оперативные информационные
системы. В информационных системах организационного управления преобладает режим
оперативной обработки транзакций (Online Transaction Processing, OLTP) для отражения
актуального состояния предметной области в любой момент времени, а пакетная
обработка занимает весьма ограниченную часть. Для систем OLTP характерен регулярный
(возможно, интенсивный) поток довольно простых транзакций, играющих роль заказов,
платежей, запросов и т. п. Важными требованиями для них являются:
□ высокая производительность обработки транзакций;
□ гарантированная доставка информации при удаленном доступе к БД по
телекоммуникациям.
Системы поддержки принятия решений (Decision Support System, DSS) представяют
собой другой тип информационных систем, в которых с помощью довольно сложных
запросов производится отбор и анализ данных в различных разрезах: временных,
географических, по другим показателям.
Обширный класс информационно-справочных систем основан на гипертекстовых
документах и мультимедиа. Наибольшее развитие такие информационные системы
получили в Интернете.
Класс офисных информационных систем нацелен на перевод бумажных документов в
электронный вид, автоматизацию делопроизводства и управление документооборотом.
Классификация по способу организации
По способу организации групповые и корпоративные информационные системы
подразделяются на следующие классы (рис. 8.3):
□ системы на основе архитектуры файл-сервер;
□ системы на основе архитектуры клиент-сервер;
□ системы на основе многоуровневой архитектуры;
□ системы на основе Интернет/интранет-технологий.
 Рис. 8.3. Деление информационных систем по способу организации
В любой информационной системе можно выделить необходимые функциональные
компоненты (табл. 8.1), которые помогают понять ограничения различных архитектур
информационных систем. Рассмотрим более подробно особенности вариантов
построения информационных приложений.
Таблица 8.1. Типовые Функциональные компоненты информационной системы

Обознач Наименование Характеристика

ение
PS Presentation Services (средства Обслуживает пользовательский ввод и
представления) отображает то, что сообщает ему
компонент логики представления (PL),
с использованием соответствующей
программной поддержки
PL Presentation Logic (логика Управляет взаимодействием между
представления) пользователем и ЭВМ. Обрабатывает
действия пользователя при выборе
команды в меню, щелчке на кнопке
или выборе пункта в списке
BL Business Logic (прикладная Набор правил для принятия решений,
логика) вычислений и операций, которые должно
выполнить приложение
DL Data Logic (логика Операции с базой данных
управления данными) (реализуемые SQL-операторами),
которые нужно выполнить для
реализации прикладной логики
управления данными
DS Data Services (операции с Действия СУБД, реализующие логику
базой данных) управления данными, такие как
манипулирование данными,
определение данных, фиксация или
откат транзакций и т. п. СУБД обычно
компилирует SQL-предложения
FS File Services (файловые Дисковые операции чтения и записи
операции) данных для СУБД и других
компонентов. Обычно являются
функциями операционной системы (ОС)
Архитектура файл-сервер
В архитектуре файл-сервер сетевое разделение компонентов диалога PS и PL
отсутствует, а компьютер используется для функций отображения, что облегчает
построение графического интерфейса. Файл-сервер только извлекает данные из файлов,
так что дополнительные пользователи и приложения лишь незначительно увеличивают
нагрузку на центральный процессор. Каждый новый клиент добавляет вычислительную
мощность к сети.
Объектами разработки в файл-серверном приложении являются компоненты
приложения, определяющие логику диалога PL, а также логику обработки BL и
управления данными DL. Разработанное приложение реализуется либо в виде
законченного загрузочного модуля, либо в виде специального кода для интерпретации.
Однако такая архитектура имеет существенный недостаток: при выполнении
некоторых запросов к базе данных клиенту могут передаваться большие объемы
данных, загружая сеть и приводя к непредсказуемости времени реакции. Значительный
сетевой трафик особенно сказывается при организации удаленного доступа к базам
данных на файл-сервере через низкоскоростные каналы связи. Одним из вариантов
устранения данного недостатка является удаленное управление файл-серверным
приложением в сети. При этом в локальной сети размещается сервер приложений,
совмещенный с телекоммуникационным сервером (обычно называемым сервером
доступа), в среде которого выполняются обычные файл-серверные приложения.
Особенность состоит в том, что диалоговый ввод-вывод поступает от удаленных
клиентов через телекоммуникации. Приложения не должны быть слишком сложными,
иначе велика вероятность перегрузки сервера или же нужна очень мощная платформа
для сервера приложений.

Архитектура клиент-сервер
Архитектура клиент-сервер предназначена для разрешения проблем файл-серверных
приложений путем разделения компонентов приложения и размещения их там, где они
будут функционировать наиболее эффективно. Особенностью архитектуры клиент-
сервер является наличие выделенных серверов баз данных, понимающих запросы на
языке структурированных запросов (Structured Query Language, SQL) и выполняющих
поиск, сортировку и агрегирование информации.
Отличительная черта серверов БД — наличие справочника данных, в котором записаны
структура БД, ограничения целостности данных, форматы и даже серверные процедуры
обработки данных по вызову или по событиям в программе. Объектами разработки в
таких приложениях, помимо диалога и логики обработки, являются, прежде всего,
реляционная модель данных и связанный с ней набор SQL-операторов для типовых
запросов к базе данных.
Большинство конфигураций клиент-сервер использует двухуровневую модель, в
которой клиент обращается к услугам сервера. Предполагается, что диалоговые
компоненты PS и PL размещаются на клиенте, что позволяет реализовать графический
интерфейс. Компоненты управления данными DS и FS размещаются на сервере, а диалог
(PS, PL) и логика (BL, DL) — на клиенте. В двухуровневом определении архитектуры
клиент-сервер используется именно этот вариант: приложение работает на клиенте, СУБД
— на сервере (рис. 8.4).

Рис. 8.4. Классический вариант клиент серверной системы

Поскольку эта схема предъявляет наименьшие требования к серверу, она обладает
наилучшей масштабируемостью. Однако сложные приложения, активно
взаимодействующие с БД, могут жестко загрузить как клиент, так и сеть. Результаты SQL-
запроса должны вернуться клиенту для обработки, потому что там реализована логика
принятия решения. Такая схема приводит к дополнительному усложнению
администрирования приложений, разбросанных по различным клиентским узлам.
Для сокращения нагрузки на сеть и упрощения администрирования приложений
компонент BL можно разместить на сервере. При этом вся логика принятия решений
оформляется в виде хранимых процедур и выполняется на сервере БД.
Хранимая процедура — процедура с SQL-операторами для доступа к БД, вызываемая по
имени с передачей требуемых параметров и выполняемая на сервере БД. Хранимые
процедуры могут компилироваться, что повышает скорость их выполнения и сокращает
нагрузку на сервер.
Хранимые процедуры улучшают целостность приложений и БД, гарантируют
актуальность коллективных операций и вычислений. Улучшается сопровождение таких
процедур, а также безопасность (нет прямого доступа к данным).
Следует помнить, что перегрузка хранимых процедур прикладной логикой может
перегрузить сервер, что приведет к потере производительности. Эта проблема особенно
актуальна при разработке крупных информационных систем, в которых к серверу может
одновременно обращаться большое количество клиентов. Поэтому в большинстве случаев
следует принимать компромиссные решения: часть логики приложения размещать на
стороне сервера, часть — на стороне клиента. Такие клиент-серверные системы называются
системами с разделенной логикой. Данная схема при удачном разделении логики
позволяет получить более сбалансированную загрузку клиентов и сервера, но при этом
затрудняется сопровождение приложений.
Создание архитектуры клиент-сервер возможно и на основе многотерминальной
системы. В этом случае в многозадачной среде сервера приложений выполняются
программы пользователей, а клиентские узлы вырождены и представлены
терминалами. Подобная схема информационной системы характерна для Unix.
В настоящее время архитектура клиент-сервер получила признание и широкое
распространение как способ организации приложений для рабочих групп и
информационных систем корпоративного уровня. Подобная организация работы
повышает эффективность выполнения приложений за счет использования возможностей
сервера БД, разгрузки сети и обеспечения контроля целостности данных.
Двухуровневые схемы архитектуры клиент-сервер могут привести к некоторым
проблемам в сложных информационных приложениях с множеством пользователей и
запутанной логикой. Решением этих проблем может стать применение многоуровневой
архитектуры.

Многоуровневая архитектура
Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в своей
классической форме состоит из трех уровней:
□ нижний уровень представляет собой приложения клиентов, выделенные для
выполнения функций и логики представлений PS и PL и имеющие программный
интерфейс для вызова приложения на среднем уровне;
□ средний уровень представляет собой сервер приложений, на котором выполняется
прикладная логика BL и с которого логика обработки данных DL выполняет операции
 с базой данных DS;
□ верхний уровень представляет собой удаленный специализированный сервер базы
данных, выделенный для услуг обработки данных DS и файловых операций FS (без
использования хранимых процедур).
Подобную концепцию обработки данных пропагандируют, в частности, фирмы Oracle,
Sun, Borland и др.
Трехуровневая архитектура позволяет еще больше сбалансировать нагрузку на разные
узлы и сеть, а также способствует специализации инструментов для разработки
приложений и устраняет недостатки двухуровневой модели клиент-сервер.
Централизация логики приложения упрощает администрирование и сопровождение.
Четко разделяются платформы и инструменты для реализации интерфейса и прикладной
логики, что позволяет с наибольшей отдачей реализовывать их специалистам узкого
профиля. Наконец, изменения прикладной логики не затрагивают интерфейса, и
наоборот. Но поскольку границы между компонентами PL, BL и DL размыты,
прикладная логика может реализовываться на всех трех уровнях. Сервер приложений с
помощью монитора транзакций обеспечивает интерфейс с клиентами и другими
серверами, может управлять транзакциями и гарантировать целостность распределенной
базы данных. Средства удаленного вызова процедур наиболее соответствуют идее
распределенных вычислений: они обеспечивают из любого узла сети вызов прикладной
процедуры, расположенной на другом узле, передачу параметров, удаленную обработку и
возврат результатов.
С ростом систем клиент-сервер необходимость трех уровней становится все более
очевидной. Продукты для трехуровневой архитектуры, так называемые мониторы
транзакций, являются относительно новыми. Эти инструменты в основном
ориентированы на среду Unix, однако прикладные серверы можно строить на базе
Microsoft Windows NT с вызовом удаленных процедур для организации связи клиентов с
сервером приложений. На практике в локальной сети могут использоваться смешанные
архитектуры (двухуровневые и трехуровневые) с одним и тем же сервером базы данных. С
учетом глобальных связей архитектура может иметь больше трех уровней. В настоящее
время появились новые инструментальные средства для гибкой сегментации приложений
клиент-сервер по различным узлам сети.
Таким образом, многоуровневая архитектура распределенных приложений позволяет
повысить эффективность работы корпоративной информационной системы и
оптимизировать распределение ее программно-аппаратных ресурсов. Но пока на
российском рынке по-прежнему доминирует архитектура клиент-сервер.

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

9. Средства моделирования АИС

9.1. Методология структурного анализа и моделирования информационных

систем
Существует множество средств для моделирования и создания информационных
систем. За последнее десятилетие сформировалось новое направление в
программотехнике - CASE (Computer-Aided Software/System Engineering) на основе
методологии структурного системного анализа и проектирования. CASE-технология
представляет собой совокупность методологий анализа, проектирования, разработки
программного обеспечения (ПО) и сопровождения информационных систем,
поддержанную комплексом взаимосвязанных средств автоматизации. CASE -– это
инструментарий для системных аналитиков, разработчиков и программистов,
позволяющий автоматизировать процесс проектирования и разработки ПО.
Практически ни один серьезный программный пакет не осуществляется без
использования CASE-средств. Известно много (порядка 90) разновидностей CASE-
технологий.
С самого начала CASE-технологии развивались с целью преодоления
ограничений при использовании структурных методологий проектирования 60-70
годов (сложности понимания, большой трудоемкости и стоимости использования,
трудности внесения изменений в проектные спецификации и т.д.) за счет их
автоматизации и интеграции поддерживающих средств. Таким образом, CASE-
технологии не могут считаться самостоятельными методологиями, они только
развивают структурные методологии и делают более эффективным их применение за
счет автоматизации.
Помимо автоматизации структурных методологий и, как следствие,
возможности применения современных методов системной и программной
инженерии, CASE обладают следующими основными достоинствами:
- улучшают качество создаваемого ПО за счет средств автоматического
контроля (прежде всего контроля проекта);
- позволяют за короткое время создавать прототип будущей системы, что
позволяет на ранних этапах оценить ожидаемый результат;
- ускоряют процесс проектирования и разработки;
- освобождают разработчика от рутинной работы, позволяя ему целиком
сосредоточиться на творческой части разработки;
- поддерживают развитие и сопровождение разработки;
- поддерживают технологии повторного использования компонент разработки.
Большинство CASE-средств основано на парадигме методология / метод /
нотация / средство. Методология определяет руководящие указания для оценки и
выбора проекта разрабатываемого ПО, шаги работы и их последовательность, а также
правила распределения и назначения методов. Метод – это систематическая
процедура или техника генерации описаний компонентов ПО (например,
проектирование потоков и структур данных). Нотации предназначены для описания
структуры системы, элементов данных, этапов обработки и включают графы,
диаграммы, таблицы, блок-схемы, формальные и естественные языки. Средства –
инструментарий (программные средства) для поддержки и реализации методов. Эти
инструменты поддерживают работу пользователей при создании и редактировании
графического проекта в интерактивном режиме.

9.2.Основные фазы проектирования информационной системы

Каждый проект, независимо от сложности и объема работ, необходимых для его
выполнения, проходит в своем развитии определенные состояния: от состояния, когда
«проекта еще нет», до состояния, когда «проекта уже нет». Совокупность ступеней
развития от возникновения идеи до полного завершения проекта принято разделять на
фазы (стадии, этапы).
В определении количества фаз и их содержания имеются некоторые отличия,
поскольку эти характеристики во многом зависят от условий осуществления
конкретного проекта и опыта основных участников. Тем не менее логика и основное
содержание процесса разработки информационной системы почти во всех случаях
являются общими.
Можно выделить следующие фазы развития информационной системы:
□ формирование концепции;
□ подготовка технического задания;
□ проектирование; О разработка;
□ ввод системы в эксплуатацию. Рассмотрим каждую из
них более подробно.

Концептуальная фаза
Главным содержанием работ на концептуальной фазе является определение проекта,
разработка его концепции, включающая:
□ формирование идеи, постановку целей;
□формирование ключевой команды проекта;
□ изучение мотивации и требований заказчика и других участников;
□ сбор исходных данных и анализ существующего состояния;
□ определение основных требований и ограничений, требуемых материальных,
финансовых и трудовых ресурсов;
□ сравнительную оценку альтернатив;
□ представление предложений, их экспертизу и утверждение.
Подготовка технического предложения
Главным содержанием фазы подготовки технического предложения является
уточнение технического предложения в ходе переговоров с заказчиком о заключении
контракта. Общее содержание работ этой фазы:
□ разработка основного содержания, базовой структуры проекта;
□ разработка и утверждение технического задания;
□ планирование, декомпозиция базовой структурной модели проекта;
□ составление сметы и бюджета проекта, определение потребности в ресурсах;
□ разработка календарных планов и укрупненных графиков работ;
□ подписание контракта с заказчиком;
□ ввод в действие средств коммуникации участников проекта и средств контроля за
ходом работ.
Проектирование
На фазе проектирования определяются подсистемы, их взаимосвязи, выбираются
наиболее эффективные способы выполнения проекта и использования ресурсов.
Характерные работы этой фазы:
□ выполнение базовых проектных работ;
□ разработка частных технических заданий;
□ выполнение концептуального проектирования;
□ составление технических спецификаций и инструкций;
□ представление проектной разработки, экспертиза и утверждение.

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

Ввод системы в эксплуатацию

На фазе ввода системы в эксплуатацию проводятся испытания, идет опытная
эксплуатация системы в реальных условиях, ведутся переговоры о результатах
выполнения проекта и о возможных новых контрактах. Основные виды работ:
□ комплексные испытания;
□ подготовка кадров для эксплуатации создаваемой системы;
□ подготовка рабочей документации, сдача системы заказчику и ввод ее в
эксплуатацию;
□ сопровождение, поддержка, сервисное обслуживание;
□ оценка результатов проекта и подготовка итоговых документов;
□ разрешение конфликтных ситуаций и закрытие работ по проекту;
□ накопление опытных данных для последующих проектов, анализ опыта, состояния,
определение направлений развития.
Следует иметь в виду, что на обнаружение ошибок, допущенных на стадии
системного проектирования, расходуется примерно в два раза больше времени, чем на
последующих фазах, а их исправление обходится в пять раз дороже. Поэтому на
начальных стадиях проекта разработку следует выполнять особенно тщательно.
Наиболее часто на начальных фазах допускаются следующие ошибки:
□ ошибки в определении интересов заказчика;
□ концентрация на маловажных, сторонних интересах;
□ неправильная интерпретация исходной задачи;
□ неправильное или недостаточное понимание деталей;
□ неполнота функциональных спецификаций (системных требований);
□ ошибки в определении требуемых ресурсов и сроков;
□ редкая проверка на согласованность этапов и отсутствие контроля со стороны
заказчика (нет привлечения заказчика).
9.3. Процессы, протекающие на протяжении жизненного цикла информационной
системы
Понятие жизненного цикла является одним из базовых понятий методологии
проектирования информационных систем. Жизненный цикл информационной
системы представляет собой непрерывный процесс, начинающийся с момента
принятия решения о создании информационной системы и заканчивающийся в
момент полного изъятия ее из эксплуатации.
Существует международный стандарт, регламентирующий жизненный цикл
информационных систем — ISO/IEC 12207.
ISO расшифровывается как International Organization of Standardization
(международная организация по стандартизации), IEC— как International
Electrotechnical Commission (международная комиссия по электротехнике).
Стандарт ISO/IEC 12207 определяет структуру жизненного цикла, включая процессы,
действия и задачи, которые должны быть выполнены во время создания
информационной системы. Согласно данному стандарту, структура жизненного цикла
основывается на трех группах процессов:
□основные процессы жизненного цикла (приобретение, поставка, разработка,
эксплуатация, сопровождение);
□вспомогательные процессы, обеспечивающие выполнение основных процессов
(документирование, управление конфигурацией, обеспечение качества,
верификация, аттестация, оценка, аудит, разрешение проблем);
□организационные процессы (управление проектами, создание инфраструктуры
проекта, определение, оценка и улучшение самого жизненного цикла, обучение).
Рассмотрим каждую из указанных групп более подробно.

Основные процессы жизненного цикла

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

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

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

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

Вспомогательные процессы жизненного цикла

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

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

9.4. Структура жизненного цикла информационной системы

Полный жизненный цикл информационной системы включает в себя, как правило,
стратегическое планирование, анализ, проектирование, реализацию, внедрение и
эксплуатацию. В общем случае жизненный цикл можно, в свою очередь, разбить на
ряд стадий. В принципе, это деление на стадии достаточно произвольно. Мы
рассмотрим один из вариантов такого деления, предлагаемый корпорацией Rational
Software — одной из ведущих фирм на рынке программного обеспечения средств
разработки информационных систем (среди которых большой популярностью
заслуженно пользуется универсальное CASE-средство Rational Rose).
Согласно методологии, предлагаемой Rational Software, жизненный цикл
информационной системы подразделяется на четыре стадии:
□ начало;
□ уточнение;
□ конструирование;
□ передача в эксплуатацию.

Границы каждой стадии определены некоторыми моментами времени, в которые

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

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

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

Стадия конструирования
На стадии конструирования разрабатывается законченное изделие, готовое к передаче
пользователю. По окончании этой стадии определяется работоспособность
разработанного программного обеспечения.

Стадия передачи в эксплуатацию

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

9.5. Модели жизненного цикла информационной системы

Моделью жизненного цикла информационной системы будем называть некоторую
структуру, определяющую последовательность осуществления процессов, действий и
задач, выполняемых на протяжении жизненного цикла информационной системы, а
также взаимосвязи между этими процессами, действиями и задачами.
В стандарте ISO/IEC 12207 не конкретизируются в деталях методы выполнения
действий и решения задач, входящих в процессы жизненного цикла информационной
системы, а лишь описываются структуры этих процессов. Это вполне понятно, так как
регламенты стандарта являются общими для любых моделей жизненного цикла,
методологий и технологий разработки. Модель же жизненного цикла зависит от
специфики информационной системы и условий, в которых она создается и
функционирует. Поэтому не имеет смысла предлагать какие-либо конкретные модели
жизненного цикла и методы разработки информационных систем для общего случая,
без привязки к определенной предметной области.
К настоящему времени наибольшее распространение получили две основные модели
жизненного цикла:
□ каскадная модель, иногда также называемая моделью водопада (waterfall);
□ спиральная модель.

Каскадная модель жизненного цикла информационной системы

Каскадная модель демонстрирует классический подход к разработке различных
систем в любых прикладных областях. Для разработки информационных систем
данная модель широко использовалась в 70-х и первой половине 80-х годов.
Каскадные методы проектирования хорошо описаны в зарубежной и отечественной
литературе разных направлений: методических монографиях, стандартах, учебниках.
Организация работ по каскадной схеме официально рекомендовалась и широко
применялась в различных отраслях. Таким образом, наличие не только теоретических
оснований, но и промышленных методик и стандартов, а также использование этих
методов в течение десятилетий позволяет называть каскадные методы классическими.
Каскадная модель предусматривает последовательную организацию работ. При этом
основной особенностью является разбиение всей разработки на этапы, причем
переход с одного этапа на следующий происходит только после того, как полностью
завершены все работы на предыдущем этапе. Каждый этап завершается выпуском
полного комплекта документации, достаточной для того, чтобы разработка могла
быть продолжена другой командой разработчиков.
Основные этапы разработки по каскадной модели
За десятилетия существования каскадной модели разбиение работ на стадии и
названия этих стадий менялись. Кроме того, наиболее разумные методики и
стандарты избегали жесткого и однозначного приписывания определенных работ к
конкретным этапам. Тем не менее все же можно выделить ряд устойчивых этапов
разработки, практически не зависящих от предметной области (рис. 9.1):
□ анализ требований заказчика;
□ проектирование;
□ разработка;
□ тестирование и опытная эксплуатация;
□ сдача готового продукта.

Рис. 9.1 Каскадная модель разработки

На первом этапе проводится исследование проблемы, которая должна быть решена,

четко формулируются все требования заказчика. Результатом, получаемым на данном
этапе, является техническое задание (задание на разработку), согласованное со всеми
заинтересованными сторонами.
На втором этапе разрабатываются проектные решения, удовлетворяющие всем
требованиям, сформулированным в техническом задании. Результатом данного этапа
является комплект проектной документации, содержащей все необходимые данные
для реализации проекта.
 Третий этап — реализация проекта. Здесь осуществляется разработка программного
обеспечения (кодирование) в соответствии с проектными решениями, полученными
на предыдущем этапе. Методы, используемые для реализации, не имеют
принципиального значения. Результатом выполнения данного этапа является готовый
программный продукт.
На четвертом этапе проводится проверка полученного программного обеспечения
на предмет соответствия требованиям, заявленным в техническом задании. Опытная
эксплуатация позволяет выявить различного рода скрытые недостатки,
проявляющиеся в реальных условиях работы информационной системы.
Последний этап — сдача готового проекта. Главная задача этого этапа — убедить
заказчика, что все его требования выполнены в полной мере.
Этапы работ в рамках каскадной модели часто также называют частями «проектного
цикла» системы. Такое название возникло потому, что этапы состоят из многих
итерационных процедур уточнения требований к системе и вариантов проектных
решений. Жизненный цикл самой системы существенно сложнее и длиннее. Он
может включать в себя произвольное число циклов уточнения, изменения и
дополнения уже принятых и реализованных проектных решений. В этих циклах
происходит развитие информационной системы и модернизация отдельных ее
компонентов.
Основные достоинства каскадной модели
Каскадная модель имеет ряд положительных сторон, благодаря которым она хорошо
зарекомендовала себя при выполнении различного рода инженерных разработок и
получила широкое распространение. Рассмотрим ее основные достоинства.
□ На каждом этапе формируется законченный набор проектной документации,
отвечающей критериям полноты и согласованности. На заключительных этапах
также разрабатывается пользовательская документация, охватывающая все
предусмотренные стандартами виды обеспечения информационной системы
(организационное, методическое, информационное, программное, аппаратное).
□ Выполняемые в логичной последовательности этапы работ позволяют планировать
сроки завершения и соответствующие затраты.
Каскадная модель изначально разрабатывалась для решения различного рода
инженерных задач и не потеряла своего значения для прикладной области до
настоящего времени. Кроме того, каскадный подход хорошо зарекомендовал себя при
разработке определенных информационных систем. Имеются в виду системы, для
которых в самом начале разработки можно достаточно точно и полно сформулировать
все требования, с тем, чтобы предоставить разработчикам свободу выбора реализации,
наилучшей с технической точки зрения. К таким информационным системам, в
частности, относятся сложные расчетные системы, системы реального времени.
Тем не менее, несмотря на все свои достоинства, каскадная модель имеет ряд
недостатков, ограничивающих ее применение при разработке информационных
систем. Причем эти недостатки либо делают ее полностью неприменимой, либо
приводят к увеличению сроков разработки и стоимости проекта. В настоящее время
многие неудачи программных проектов объясняются именно последовательным
процессом разработки.
Недостатки каскадной модели
Перечень недостатков каскадной модели при ее использовании для разработки
информационных систем достаточно обширен. Вначале просто перечислим их, а затем
рассмотрим основные из них более подробно:
□ существенная задержка в получении результатов;
□ ошибки и недоработки на любом из этапов проявляются, как правило, на
последующих этапах работ, что приводит к необходимости возврата назад;
□ сложность параллельного ведения работ по проекту;
□ чрезмерная информационная перенасыщенность каждого из этапов;
□ сложность управления проектом;
□ высокий уровень риска и ненадежность инвестиций.
Задержка в получении результатов обычно считается главным недостатком
каскадной схемы. Данный недостаток проявляется в основном в том, что из-за
последовательного подхода к разработке согласование результатов с
заинтересованными сторонами производится только после завершения очередного
этапа работ. Может оказаться, что разрабатываемая информационная система не
соответствует требованиям пользователей, причем такие несоответствия могут
возникать на любом этапе разработки — искажения могут непреднамеренно вноситься
и проектировщиками-аналитиками, и программистами, так как они необязательно
хорошо разбираются в тех предметных областях, для которых производится
разработка информационной системы.
Кроме того, используемые при разработке информационной системы модели
автоматизируемого объекта, отвечающие критериям внутренней согласованности и
полноты, могут в силу различных причин устареть за время разработки (например, из-
за внесения изменений в законодательство, колебания курса валют и т. п.). Это
относится и к функциональной модели, и к информационной модели, и к проектам
интерфейса пользователя, и к пользовательской документации.
Возврат на более ранние стадии. Данный недостаток каскадной модели в общем-то
является одним из проявлений предыдущего. Поэтапная и последовательная работа
над проектом может быть следствием того, что ошибки, допущенные на более ранних
этапах, как правило, обнаруживаются только на последующих стадиях работы над
проектом. Поэтому, после того как ошибки проявятся, проект возвращается на
предыдущий этап, перерабатывается и снова передается на последующую стадию.
Это может служить причиной срыва графика работ и усложнения взаимоотношений
между группами разработчиков, выполняющих отдельные этапы работы.
Самым же неприятным является то, что недоработки предыдущего этапа могут
обнаруживаться не сразу на последующем этапе, а позднее (например, на стадии
опытной эксплуатации могут проявиться ошибки в описании предметной области).
Это означает, что часть проекта должна быть возвращена на начальный этап работы.
Вообще, работа может быть возвращена с любого этапа на любой предыдущий этап,
поэтому в реальности каскадная схема разработки выглядит так, как показано на рис.
9.2.

Рис. 9.2. Реальный процесс разработки по каскадной схеме

Одной из причин данной ситуации является то, что в качестве экспертов,
участвующих в описании предметной области, часто выступают будущие
пользователи системы, которые иногда не могут четко сформулировать то, что они
хотели бы получить. Кроме того, заказчики и исполнители часто неправильно
понимают друг друга вследствие того, что исполнители обычно не являются
специалистами в предметной области решаемой задачи, а заказчики далеки от
программирования.
Сложность параллельного ведения работ. Отмеченные проблемы возникают
вследствие того, что работа над проектом строится в виде цепочки последовательных
шагов. Причем даже в том случае, когда разработку некоторых частей проекта
(подсистем) можно вести параллельно, при использовании каскадной схемы
распараллеливание работ весьма затруднительно. Сложности параллельного ведения
работ связаны с необходимостью постоянного согласования различных частей
проекта. Чем сильнее взаимозависимость отдельных частей проекта, тем чаще и
тщательнее должна выполняться синхронизация, тем сильнее зависят друг от друга
группы разработчиков. Поэтому преимущества параллельного ведения работ просто
теряются.
Отсутствие параллелизма негативно сказывается и на организации работы всего
коллектива разработчиков. Работа одних групп сдерживается другими. Пока
производится анализ предметной области, проектировщики, разработчики и те, кто
занимается тестированием и администрированием, почти не загружены. Кроме того,
при последовательной разработке крайне сложно внести изменения в проект после
завершения этапа и передачи проекта на следующую стадию. Так, например, если
после передачи проекта на следующий этап группа разработчиков нашла более
эффективное решение, оно не может быть использовано. Это связано с тем, что более
раннее решение уже, возможно, реализовано и связано с другими частями проекта.
Поэтому исключается (или, по крайней мере, существенно затрудняется) доработка
проекта после его передачи на следующий этап.
Информационная перенасыщенность. Проблема информационной перенасыщенности
возникает вследствие сильной зависимости между различными группами
разработчиков. Данная проблема заключается в том, что при внесении изменений в
одну из частей проекта необходимо оповещать всех разработчиков, которые
использовали или могли бы использовать эту часть в своей работе. Когда система
состоит из большого количества взаимосвязанных подсистем, то синхронизация
внутренней документации становится важной самостоятельной задачей. При этом
синхронизация документации на каждую часть системы — не более чем процесс
оповещения групп разработчиков. Самим же разработчикам необходимо
ознакомиться с изменениями и оценить, не сказались ли эти изменения на уже
полученных результатах. Все это может требовать проведения повторного
тестирования и даже внесения изменений в уже готовые части проекта. Причем эти
изменения, в свою очередь, должны быть отражены во внутренней документации и
разосланы другим группам разработчиков. Как следствие, объем документации по
мере разработки проекта растет очень быстро, так что требуется все больше времени
для составления документации и ознакомления с ней.
Следует также отметить, что, помимо изучения нового материала, не отпадает
необходимость в изучении старой информации. Это связано с тем, что вполне
вероятна ситуация, когда в процессе разработки изменяется состав группы
разработчиков (этот процесс носит название ротации кадров). Новым разработчикам
необходима информация о том, что было сделано до них. Причем чем сложнее
проект, тем больше времени требуется, чтобы ввести нового разработчика в курс дела.
Сложность управления проектом при использовании каскадной схемы в основном
обусловлена строгой последовательностью стадий разработки и наличием сложных
взаимосвязей между различными частями проекта.
Последовательность разработки проекта приводит к тому, что одни группы
разработчиков должны ожидать результатов работы других команд. Поэтому
требуется административное вмешательство для согласования сроков работы и
состава передаваемой документации.
В случае же обнаружения ошибок в выполненной работе необходим возврат к
предыдущим этапам выполнения проекта. Это приводит к дополнительным
сложностям в управлении проектом. Разработчики, допустившие просчет или ошибку,
вынуждены прервать текущую работу (над новым проектом) и заняться исправлением
ошибок. Следствием этого обычно является срыв сроков выполнения как
исправляемого, так и нового проектов. Требовать же от команды разработчиков
ожидания окончания следующей стадии разработки нерационально, так как приводит
к существенным потерям рабочего времени.
Упростить взаимодействие между группами разработчиков и уменьшить
информационную перенасыщенность документации можно, сокращая количество
связей между отдельными частями проекта. Однако это обычно весьма непросто.
Далеко не каждую информационную систему можно разделить на несколько слабо
связанных подсистем.
Высокий уровень риска. Чем сложнее проект, тем больше продолжительность каждого
из этапов разработки и тем сложнее взаимосвязи между отдельными Частями проекта,
количество которых также увеличивается. Причем результаты разработки можно
реально увидеть и оценить лишь на этапе тестирования, то есть после завершения
анализа, проектирования и разработки — этапов, выполнение которых требует
значительного времени и средств. Как уже было отмечено, запоздалая оценка
порождает серьезные проблемы при выявлении ошибок анализа и проектирования —
требуется возврат проекта на предыдущие стадии и повторение процесса разработки.
Однако возврат на предыдущие стадии может быть связан не только с ошибками, но и
с изменениями, произошедшими в предметной области или в требованиях заказчика
за время разработки. Причем возврат проекта на доработку вследствие этих причин не
гарантирует, что предметная область снова не изменится к тому моменту, когда будет
готова следующая версия проекта. Фактически это означает, что существует
вероятность того, что процесс разработки «зациклится» и система никогда не дойдет
до сдачи в эксплуатацию. Расходы на проект будут постоянно расти, а сроки сдачи
готового продукта постоянно откладываться.
Поэтому можно утверждать, что сложные проекты, разрабатываемые по каскадной
схеме, имеют повышенный уровень риска. Этот вывод подтверждается практикой: по
сведениям консалтинговой компании The Standish Group в США более 31 % проектов
корпоративных информационных систем (IT-проектов) заканчивается неудачей; почти
53 % IT-проектов завершается с перерасходом бюджета (в среднем на 189 %, то есть
почти в два раза); и только 16,2 % проектов укладывается и в срок, и в бюджет.
Спиральная модель жизненного цикла
Спиральная модель, в отличие от каскадной, предполагает итерационный процесс
разработки информационной системы. При этом возрастает значение начальных этапов
жизненного цикла, таких как анализ и проектирование. На этих этапах проверяется и
обосновывается реализуемость технических решений путем создания прототипов.
Итерации
Каждая итерация представляет собой законченный цикл разработки, приводящий к
выпуску внутренней или внешней версии изделия (или подмножества конечного
продукта), которое совершенствуется от итерации к итерации, чтобы стать законченной
системой (рис. 9.3).
Таким образом, каждый виток спирали соответствует созданию фрагмента или версии
программного изделия, на нем уточняются цели и характеристики проекта, определяется
его качество, планируются работы на следующем витке спирали. На каждой итерации
углубляются и последовательно конкретизируются детали проекта, в результате чего
выбирается обоснованный вариант, который доводится до окончательной реализации.
Использование спиральной модели позволяет осуществлять переход на следующий
этап выполнения проекта, не дожидаясь полного завершения текущего —
недоделанную работу можно будет выполнить на следующей итерации. Главная
задача каждой итерации — как можно быстрее создать работоспособный продукт,
который можно показать пользователям системы. Таким образом существенно
упрощается процесс внесения уточнений и дополнений в проект.

Рис. 9.3. Спиральная модель жизненного цикла информационной системы

Преимущества спиральной модели

Спиральный подход к разработке программного обеспечения позволяет преодолеть
большинство недостатков каскадной модели и, кроме того, обеспечивает ряд
дополнительных возможностей, делая процесс разработки более гибким.
Рассмотрим преимущества итерационного подхода более подробно.
□ Итерационная разработка существенно упрощает внесение изменений в проект при
изменении требований заказчика.
□ При использовании спиральной модели отдельные элементы информационной
системы интегрируются в единое целое постепенно. При итерационном подходе
интеграция производится фактически непрерывно. Поскольку интеграция
начинается с меньшего количества элементов, то возникает гораздо меньше
проблем при ее проведении (по некоторым оценкам, при использовании каскадной
модели разработки интеграция занимает до 40 % всех-затрат в конце проекта).
□ Уменьшение уровня рисков. Данное преимущество является следствием
предыдущего, так как риски обнаруживаются именно во время интеграции.
Поэтому уровень рисков максимален в начале разработки проекта. По мере
продвижения разработки ожидаемый уровень рисков снижается. Данное
утверждение справедливо при любой модели разработки, однако при использовании
спиральной модели снижение уровня рисков происходит с наибольшей скоростью.
Это связано с тем, что при итерационном подходе интеграция выполняется уже на
первой итерации и на начальных итерациях выявляются многие аспекты проекта,
такие как пригодность используемых инструментальных средств и программного
обеспечения, квалификация разработчиков и т. п. На рис. 9.4 приведены в
сравнении графики зависимости уровня рисков от времени разработки для
каскадного и итерационного подходов.

Рис. 9.4. Зависимость рисков от времени разработки

□ Итерационная разработка обеспечивает большую гибкость в управлении проектом,

давая возможность внесения тактических изменений в разрабатываемое изделие.
Например, можно сократить сроки разработки за счет снижения функциональности
системы или использовать в качестве составных частей системы продукцию
сторонних фирм вместо собственных разработок. Это может быть актуальным в
условиях конкурентной борьбы, когда необходимо противостоять продвижению
изделия, предлагаемого конкурентами.
□ Итерационный подход упрощает повторное использование компонентов (реализует
компонентный подход к программированию — более подробно об этом мы будем
говорить в следующей главе). Это обусловлено тем, что гораздо проще выявить
(идентифицировать) общие части проекта, когда они уже частично разработаны, чем
пытаться выделить их в самом начале проекта. Анализ проекта после проведения
нескольких начальных итераций позволяет выявить общие многократно
используемые компоненты, которые на последующих итерациях будут
совершенствоваться.
□ Спиральная модель позволяет получить более надежную и устойчивую систему. Это
связано с тем, что по мере развития системы ошибки и слабые места
обнаруживаются и исправляются на каждой итерации. Одновременно могут
корректироваться критические параметры эффективности, что в случае каскадной
модели доступно только перед внедрением системы.
□ Итерационный подход дает возможность совершенствовать процесс разработки —
анализ, проводимый в конце каждой итерации, позволяет проводить оценку того,
что должно быть изменено в организации разработки, и улучшить ее на следующей
итерации.
Недостатки спиральной модели
Основная проблема спирального цикла — определение момента перехода на следующий
этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов
жизненного цикла. Иначе процесс разработки может превратиться в бесконечное
совершенствование уже сделанного. При итерационном подходе полезно следовать
принципу «лучшее — враг хорошего». Поэтому завершение итерации должно
производиться строго в соответствии с планом, даже если не вся запланированная работа
закончена.
Планирование работ обычно проводится на основе статистических данных, полученных в
предыдущих проектах, и личного опыта разработчиков.
9.6. Принципы структурного анализа системы
Структурный анализ – это метод исследования системы, который начинается с
ее общего обзора и затем детализируется, приобретая иерархическую структуру со все
большим числом уровней. Для такого метода характерно разбиение на уровни
абстракции с ограничением числа элементов на каждом из уровней; ограниченный
контекст, включающий только существенные на каждом уровне детали;
использование строгих формальных правил записи; последовательное приближение к
конечному результату.
Все методологии структурного анализа базируются на ряд общих принципов,
часть из которых регламентирует организацию работ на начальных этапах жизненного
цикла, часть используется при выработке рекомендаций по организации работ. В
качестве двух базовых принципов используются следующие: принцип «разделяй и
властвуй» и принцип иерархического упорядочивания. Первый принцип используется
для решения трудных проблем путем разбиения их на множество меньших
независимых задач, легких для понимания и решения. Второй принцип резко
повышает понимание проблемы за счет представления ее частей в виде древовидной
иерархической структуры, т.е. система может быть понята и построена по уровням,
каждый из которых добавляет новые детали.
Существует ряд не менее значимых принципов инженерии программного
обеспечения, игнорирование любого из них может привести к непредсказуемым
последствиям (в том числе к неуспеху всего проекта). Необходимо отметить основные
из таких принципов.
1. Принцип абстрагирования – заключается в выделении существенных с
некоторых позиций аспектов системы и представление проблемы в простом общем
виде.
2. Принцип формализации – заключается в необходимости строгого
методического подхода к решению проблемы.
3. Принцип упрятывания – заключается в упрятывании несущественной на
конкретном этапе информации: каждая часть «знает» только необходимую ей
информацию.
4. Принцип концептуальной общности – заключается в следовании единой
философии на всех этапах жизненного цикла (структурный анализ – структурное
проектирование – структурное программирование – структурное тестирование).
5. Принцип полноты – заключается в контроле необходимых выполняемых
системой функций.
6. Принцип независимости данных – заключается в том, что модели данных
должны быть проанализированы и спроектированы независимо от процессов их
логической обработки, а также от их физической структуры и распределения.
7. Принцип структурирования данных – заключается в том, что данные
должны быть структурированы и иерархически организованы.
 8. Принцип доступа конечного пользователя – заключается в том, что
пользователь должен иметь средства доступа к базе данных, которые он может
использовать непосредственно (без программирования).

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

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

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

Эффективность
Система является эффективной, если с учетом выделенных ей ресурсов она позволяет
решать возложенные на нее задачи в минимальные сроки.
В любом случае оценка эффективности будет производиться заказчиком, исходя из
вложенных в разработку средств и соответствия представленной информационной
системы его ожиданиям.
Негативной оценки эффективности информационной системы со стороны заказчика
можно избежать, если представители заказчика будут привлекаться к проектированию
системы на всех его стадиях. Такой подход позволяет многим конечным пользователям
уже на этапе проектирования адаптироваться к изменениям условий работы, которые
иначе были бы приняты враждебно.
Активное сотрудничество с заказчиком с ранних этапов проектирования позволяет
уточнить потребности заказчика. Часто встречается ситуация, когда заказчик чего-то хочет,
но сам не знает чего именно. Чем раньше будут учтены дополнения заказчика, тем с
меньшими затратами и в более короткие сроки система будет создана.
Кроме того, заказчик, не являясь специалистом в области разработки информационных
систем, может не знать о новых информационных технологиях. Контакты с заказчиком во
время разработки для него информационной системы могут подтолкнуть заказчика к
модернизации его аппаратных средств, применению новых методов ведения бизнеса, что
отвечает потребностям как заказчика, так и проектировщика. Заказчик получает рост
эффективности своего предприятия, проектировщик — расширение возможностей,
применяемых при проектировании информационной системы.
Эффективность системы обеспечивается оптимизацией данных и методов их обработки,
применением оригинальных разработок, идей, методов проектирования (в частности,
спиральной модели проектирования информационной системы, о которой речь пойдет в
следующих главах).
Не следует забывать и о том, что работать с системой придется обычным людям,
являющимся специалистами в своей предметной области, но зачастую обладающим весьма
средними навыками в работе с компьютерами. Интерфейс информационных систем должен
быть им интуитивно понятен. В свою очередь, разработчик-программист должен
понимать характер выполняемых конечным пользователем операций. Рекомендациями в
этом случае могут служить повышение эффективности управления разработкой
информационных систем, улучшение информированности разработчиков о предметной
области.

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

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

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

ПРОЦЕСС

ДЕТАЛИЗИРУЮЩАЯ DFD

управля-
потоки хранилище ющий
ПРОЦЕСС процесс
данных ще

Специфи- словарь
кация ERD SDT
данных
процесса

Рис.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. Фрагмент функциональной модели для организации учебного процесса

на отделениях (второй уровень декомпозиции)
 10.Средства реализации АИС

Средства реализации АИС выбираются исходя из требований к ОП, ВЗУ,

быстродействию, функциональным возможностям, дизайну, общей стоимости АИС,
включая средства проектирования и реализации. Средствами реализации (создания
программного кода АИС) являются языки низкого, среднего и высокого уровня;
средства визуального проектирования, которые на основе спроектированных
структурных элементах генерируют программный код; объектно-ориентированные
языки; скриптовые языки (сверхвысокого уровня).
На языках низкого уровня (Ассемблер, Си) создаются отдельные модули АИС,
для которых очень критично время обработки данных, работающих на стыке
аппаратных и программных средств (например, драйверы устройств). Такие модули
необходимы в АИС реального времени для обработки входной информации.
Достигается наибольшая эффективность функционирования АИС по скорости
обработки данных и выполнению вычислительных операций, использованию
стандартного и нестандартного оборудования, минимизируются требования к
аппаратным ресурсам. Но при программной реализации требуется чрезвычайно
большой объем анализа логических операций.
Языки среднего уровня (С, встроенные языки различных СУБД, Паскаль и др.)
используются для создания приложений пользователя. Программирование
трудоемко при создании больших АИС (множество функций, сложная структура,
множество отчетов). Сложно реализовать повышенные требования к интерфейсу
пользователя. АИС получаются эффективными для решения конкретных задач.
Средства визуального проектирования (Visual C, Delphi, CBuilder, Visual Basic,
встроенные средства СУБД) имеют встроенный дизайнер, с помощью которого
проектируются элементы АИС (экранные формы, поля ввода, кнопки, отчеты). Это
позволяет сделать быстро хороший многофункциональный интерфейс, обеспечить
высокий уровень дизайна. Генерация программного кода автоматически может быть
выполнена на разных языках, на которые настроено визуальное средство. Это могут
быть языки Си, СУБД, С++ и т.д. Легко программировать, но приложение
получается громоздким за счет универсальности средств.

10.1 Сравнительный анализ языков программирования

для создания интернет–приложений

На данный момент в глобальной сети Интернет стало быстро увеличиваться

количество динамических страниц. Разработчики уже не могут обойтись без того или
иного интернет-приложения (например: динамическая навигация, счетчик посещений,
гостевая книга, голосование и так далее). Если необходимо более сложное приложение
(например, интернет-магазин), то возникает необходимость в написании большого
объема программного кода, вследствие чего встанет вопрос о выборе языка
программирования, оптимального для создания данного приложения.
Существует большой выбор таких языков, среди которых существуют
признанные лидеры в своих областях. К примеру, Web-страницы города Уфы
включают интернет-приложения, большинство из которых написано на Perl.
Изначально этот язык был создан для решения более широкого круга задач; как
следствие сценарии Perl получаются громоздкие и трудночитаемые. Простота языка
PHP, платформенная совместимость и открытость его кода сделали его быстро
развивающимся языком программирования для создания интернет-приложений. В то
же время другой язык программирования – Python, помимо всех достоинств языка
PHP, в свою очередь, имеет еще и другие преимущества, в том числе богатый набор
стандартных модулей для работы с протоколами Интернет, языками структурной
разметки, поддержки форматов, используемых в Интернет, с различными форматами
баз данных и многие другие. Также объектно-ориентированный язык Python позволяет
внести в интернет-приложения некоторые элементы искусственного интеллекта и
повысить гибкость Web-дизайна, что в корне отличает его от PHP.
Интернет-приложения могут выполняться на стороне клиента (клиентский
скрипт). В этом случае приложения будут обрабатываться средствами браузера, не
обращаясь к серверу. Одним из преимуществ применения клиентских скриптов
является то, что они позволяют распознавать события, вызванные действиями
пользователя (ввод данных в форме, появление курсора мыши над конкретным
графическим объектом и так далее). Затем, получая информацию о действиях
пользователя, клиентские сценарии могут либо вызывать другие части сценария, либо
выполнять иную работу, не обращаясь снова к серверу и не требуя дополнительной
информации. Это, в свою очередь, уменьшает нагрузку на сервер, экономит время
пользователя, который может загрузить один раз клиентское приложение и работать с
ним в режиме «off line» сколько угодно. Но это преимущество одновременно является
и недостатком, так как невозможно делать запросы к базе данных, читать и записывать
файлы, общаться с внешними серверами, также сильно повышается вероятность
заражения компьютерными вирусами. Кроме того, применение клиентских скриптов
затруднено отсутствием единого стандарта для JavaScript, а другие языки (Perl)
поддерживаются браузерами лишь опционально. Также наличие обработки данных с
помощью скрипта на стороне клиента не освобождает от необходимости проверок
данных на стороне сервера, так как клиентские скрипты могут быть отключены или
замещены самим пользователем. Задачи работы с базами данных и многие другие
задачи можно реализовать сценариями серверного приложения либо совместным
использованием серверных или клиентских скриптов.
Примером таких приложений являются: создание интерактивной конференции,
гостевой книги, интернет-магазина, почтовой службы, счетчика посещений или просто
динамической страницы. В этих приложениях пользователь посылает определенный
запрос на сервер, с которого ему передается ответ. Для написания приложений,
выполняемых на стороне сервера, используются либо языки, создающие CGI–скрипты
(внешние приложения, которые передают браузеру код HTML), либо обработчики
гипертекста, конструкции которых встраиваются в HTML–страницу (интерпретатор на
сервере обрабатывает скрипты, а код HTML, находящийся вне скрипта, остается
неизменным). Практически любой язык можно применить для написания CGI, тогда
как обработчики гипертекста создавались именно для написания интернет-
приложений, вследствие чего выявляются сильные различия в этих группах. Реально
вместо CGI скриптов обычно используются модули Web–сервера Apache,
имитирующие функции CGI, но подключаемые к Web–серверу как разделяемые
библиотеки, а не как приложения, что существенно сокращает затраты времени на
отображение HTML–страницы за счет исключения операций создания контекста
процесса на Web–сервере. Язык PHP реализован как модуль Web–сервера, а для
остальных языков необходимо использование специальных модулей интеграции.
Другим способом повышения эффективности работы интерпретатора языка
программирования сверхвысокого уровня является использование сервера
приложений, при этом исключается необходимость повторного запуска
интерпретатора и соответственно связанных с этой операцией накладных расходов
при отображении каждой HTML-страницы. Интеграция с Web-сервером в этом случае
осуществляется на основе использования обмена данных между Web-сервером и
сервером приложений по протоколу Fast CGI (или его разновидности).
Далее будут рассмотрены лишь некоторые из языков для создания интернет-
приложениий: Perl, PHP, Python и Java.
Приложения, написанные на Java, значительно больше, чем такие же на других
языках. Это связано с недостаточно высоким уровнем объектно-ориентированных
конструкций языка Java. Как правило, использование этого языка не оправдывает
усилий и времени, затраченных на воплощение приложения, так как на программиста
возлагается слишком много функций по реализации механизмов наследования,
обработки исключений и т.д. Для большинства интернет-приложений достаточно
средств, которые предоставляют языки Perl, PHP (объектно-ориентированные средства
в них являются опциональными). Если человек достаточно хорошо знает Perl, то,
скорее всего, он будет для него лучшим языком для создания динамических страниц
HTML, потому что такой профессионал сможет использовать определенные рычаги и
весь свой опыт. Синтаксис языка Perl прост для изучения, но стиль программирования
на этом языке уникален (задача по передаче переменных методом post требует от
программиста детального знания заголовков HTML, либо определенной библиотеки).
Кроме того, особенности синтаксиса Perl и библиотеки языка, содержащие большое
количество модулей, приводят к тому, что при использовании этого языка трудно
проконтролировать возможные побочные эффекты. Для создания интернет-
приложений эффективны также языки Python и PHP. Их программный код хорошо
читаемый и не требуются глубокие познания в смежных областях. Perl нацелен на
поддержку общих программно-ориентированных задач, например, имеет встроенную
обработку регулярных выражений, сканирование файлов и генерирование отчетов.
Python концентрируется на общих методологиях программирования, таких как
разработка структур данных и объектно-ориентированное программирование,
способствует написанию удобочитаемого (а значит легко поддерживаемого) кода,
путем предоставления не чрезмерно зашифрованной нотации. Python близко подходит
к Perl, но редко побеждает в его оригинальной нише приложений; однако Python имеет
хорошую применимость за пределами ниши Perl. Для разработки Web приложений
имеется система Python сервлетов – Webware, сервер приложений, которые позволяют
соединить достоинства языка Python с возможностью инкапсулировать код скрипта
непосредственно в HTML–страницу (достоинства языка PHP) и, кроме того, повышает
производительность приложения в целом. Благодаря простоте и гибкости языка
Python, его можно рекомендовать пользователям (математикам, физикам, экономистам
и т.д.), не являющимся программистами, но использующими вычислительную технику
и программирование в своей работе. Программы на Python разрабатываются в среднем
в два-три раза быстрее, чем на языке Java и, по крайней мере, в десять раз быстрее,
чем на компилируемых языках (С, С++, Pascal). Поэтому язык может представляет
интерес и для профессиональных программистов, разрабатывающих приложения, не
критичные к скорости выполнения. Python хорошо зарекомендовал себя при
разработке программ работы с графами, генерации деревьев. Для языка Python (по
сравнению с языками Perl, PHP) существенно облегчена интеграция с
компилированными программами, написанными на языках C,С++, что позволяет
реализовать критическую секцию в компилированном коде. Интерпретатор Python
может быть непосредственно подключен к приложению, написанному на языке C,C++
как разделяемая библиотека
Из рассмотренных языков для создания интернет-приложений наиболее
эффективным является PHP, так как он обладает легко доступным синтаксисом и
наиболее простым способом интегрируется с Web-сервером. Эффективным по
совокупности свойств простоты, наглядности и скорости разработки является также
язык Python в сочетании с сервером приложений.

11. Комплексные АИС

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

1. Функции и назначение.
Автоматизируют задачи учета и контроля производственной деятельностью
предприятия (организации), охватывают весь цикл от планирования производства
продукции до ее реализации. К таким системам относятся Галактика, BAAN, R3, Alfa.
(«1С: Предприятие» является финансово-экономической системой и не
автоматизирует управление производством изделий).
Комплексные АИС автоматизируют хорошо специализированные и
стандартизированные производственные процессы и обеспечивают комплексную
информационную поддержку принятия управленческих решений. Не автоматизируют
задачи принятия решений (ПР), требуется дополнительный модуль, который
интегрируется с АИС на основе БД. Комплексные АИС отвечают следующим
основным требованиям:
1. Адаптивность по отношению к профилю деятельности предприятия
(организации) любой формы деятельности;
2. Наличие достаточного количества параметров, позволяющих настроить
систему под специфические особенности хозяйственной, финансовой и
производственной деятельности предприятия (организации);
3. Четкое разграничение оперативно-управленческих и бухгалтерско-
учетных задач при полной их интеграции на уровне единой базы данных;
4. Охват всего спектра типовых производственно-экономических функций;
5. Соблюдение единообразного для всех решаемых задач пользовательского
интерфейса;
6. Представление пользователям простого инструментария для
самостоятельного развития системы;
7. Поддержка распределенных баз данных для обеспечения
информационного взаимодействия удаленных филиалов, подразделений на основе
сетевых технологий;
8. Использование решений, не требующих длительной специальной
подготовки системных администраторов, отвечающих за эксплуатацию системы.
Дружественный интерфейс по администрированию системы.
При четко налаженной организационной схеме функциональной эксплуатации
комплексной АИС каждый специалист выполняет определенные для него инструкцией
функции, получая информацию в объеме, необходимом и достаточном для
осуществления своих должностных обязанностей. Создается АРМ специалиста,
который несет ответственность за содержание своего фрагмента БД. В результате
работы всех пользователей системы происходит наполнение БД предприятия
(организации) оперативной информацией о производственных процессах,
хозяйственной, финансовой и производственной деятельности предприятия.
Обработка оперативной информации позволяет определять динамику изменения
технических показателей производственных процессов, проанализировать
взаимоотношения с контрагентами на основе сведений о движении материальных
ценностей, услуг, работ и финансовых средств, оценить эффективность работы
предприятия по различным направлениям деятельности. При этом для специалистов
обеспечивается вертикальный анализ данных о производственных процессах, то есть
одновременно по взаимосвязанным видам и показателям за любой период,
горизонтальный анализ данных (динамика изменения), то есть по конкретному виду
деятельности предприятия за любой период, вертикальный и горизонтальный анализ
данных одновременно за любое время, формирование различных отчетов.
Достигается наибольшая эффективность автоматизации.
В комплексной АИС используется общая БД для всех специалистов предприятия
и обеспечивается:
- принцип однократного ввода в БД информации и, как следствие, отсутствие
дублирования функций пользователей, упорядочивание документооборота;
- легкость контроля на корректность и целостность данных, персонификацмя
действий пользователя;
- быстрая перестройка системы, изменение эксплуатационной схемы системы при
изменении бизнес-процесса (технологии управления);
- интеграция существующей АИС;
- развитие комплексной АИС (создание АСПР).
Администрация предприятия, используя для управления производственными
процессами комплексную АИС, получает возможность:
- оперативного получения достоверной информации о текущей деятельности
предприятия;
- оперативного управления финансами;
- контроля за ходом выполнения договорных отношений;
- контроля взаимных обязательств;
- контроля и управления материальными, трудовыми и техническими ресурсами;
- формирования и контроля бизнес-плана предприятия и подразделений;
- планирования и учета выполнения внутреннего бюджета.

2. Структура комплексной АИС

Анализ функций управления предприятием позволяет выделить следующие
главные функции в контексте системной модули:
 контур административного управления;
 контур оперативного управления;
 контур управления производством;
 контур бухгалтерского учета.
Модульный принцип построения системы допускает как изолированное
использование отдельных программных модулей, так и их произвольные комбинации,
в зависимости от производственно-экономической необходимости. Общая структура
комплексной АИС для управления предприятием показана на рис. 11.1.

Рис. 11.1. Общая структура комплексной АИС

Бухгалтерский учет
Бухгалтерский учет — классическая и наиболее часто реализуемая на сегодняшний день
область применения информационных технологий. Такое положение вполне объяснимо.
Во-первых, ошибка бухгалтера может стоить очень дорого, поэтому очевидна выгода
автоматизации бухгалтерии. Во-вторых, задача бухгалтерского учета довольно легко
формализуется, так что разработка систем автоматизации бухгалтерского учета не
представляет технически сложной проблемы.
Управление финансовыми потоками
Внедрение информационных технологий в управление финансовыми потоками также
обусловлено критичностью этой области управления предприятия к ошибкам.
Неправильно построив систему расчетов с поставщиками и потребителями, можно
спровоцировать кризис наличности даже при налаженной сети закупки, сбыта и хорошем
маркетинге. И наоборот, точно просчитанные и жестко контролируемые условия
финансовых расчетов могут существенно увеличить оборотные средства фирмы.
Управление складом, ассортиментом, закупками
Далее, можно автоматизировать процесс анализа движения товара, тем самым отследив и
зафиксировав те двадцать процентов ассортимента, которые приносят восемьдесят
процентов прибыли. Это же позволит ответить на главный вопрос — как получать
максимальную прибыль при постоянной нехватке средств?
«Заморозить» оборотные средства в чрезмерном складском запасе — самый простой
способ сделать любое предприятие, производственное или торговое, потенциальным
инвалидом. Можно просмотреть перспективный товар, вовремя не вложив в него деньги.
Управление производственным процессом
Оптимальное управление производственным процессом представляет собой очень
трудоемкую задачу. Основным механизмом здесь является планирование.
Автоматизированное решение подобной задачи дает возможность грамотно планировать,
учитывать затраты, проводить техническую подготовку производства, оперативно
управлять процессом выпуска продукции в соответствии с производственной программой
и технологией.
Очевидно, что чем крупнее производство, тем большее число бизнес-процессов участвует
в создании прибыли, а значит, использование информационных систем жизненно
необходимо.
Управление маркетингом
Управление маркетингом подразумевает сбор и анализ данных о фирмах-конкурентах, их
продукции и ценовой политике, а также моделирование параметров внешнего окружения
для определения оптимального уровня цен, прогнозирования прибыли и планирования
рекламных кампаний. Решения большинства этих задач могут быть формализованы и
представлены в виде информационной системы, позволяющей существенно повысить
эффективность маркетинга.
Документооборот
Документооборот является очень важным процессом деятельности любого предприятия.
Хорошо отлаженная система учетного документооборота отражает реально
происходящую на предприятии текущую производственную деятельность и дает
управленцам возможность воздействовать на нее. Поэтому автоматизация
документооборота позволяет повысить эффективность управления.
Оперативное управление предприятием
Информационная система, решающая задачи оперативного управления предприятием,
строится на основе базы данных, в которой фиксируется вся возможная информация о
предприятии. Такая информационная система является инструментом для управления
бизнесом и обычно называется корпоративной информационной системой.
Информационная система оперативного управления включает в себя массу программных
решений по автоматизации бизнес-процессов, имеющих место на конкретном
предприятии.
Предоставление информации о фирме
Активное развитие Интернета привело к необходимости создания корпоративных
серверов для предоставления различного рода информации о предприятии. Практически
каждое уважающее себя предприятие сейчас имеет свой веб-сервер. Веб-сервер
предприятия решает ряд задач, из которых можно выделить две основные:
□ создание имиджа предприятия;
□ максимальная разгрузка справочной службы компании путем предоставления
потенциальным и уже существующим абонентам возможности получения
необходимой информации о фирме, предлагаемых товарах, услугах и ценах.
Кроме того, использование веб-технологий открывает широкие перспективы для
электронной коммерции и обслуживания покупателей через Интернет.
 3. Основные технические характеристики современных АИС.
Создаются версии комплексных АИС под разные базовые платформы: версий ОС
и СУБД. Базовыми ОС являются Windows, UNIX, a СУБД MS SQL, Oracle.
Примеры используемых платформ приведены в таблице.

Используемая MS SQL Oracle

СУБД

ОС сети с Windows NT Более 80 ОС, в

выделенным сервером Server том числе 40 вариантов
UNIX, Alpha VMS, OC\
390;Novell NetWare;
Windows NT
ОС клиента сети с Windows for MS DOS,
выделенным сервером Workgroupse; Windows Windows for
95,98, Windows NT Workgroupse; Windows
Workstation 95,98, Windows NT
Workstation
ОС не сетевого клиента Windows NT Windows 95,98,
(локальный вариант) Workstation Windows NT
Workstation
Разграничение прав на уровне элемента меню, таблицы БД,
доступа пользователей колонки, строки таблицы
Требования к серверу Не ниже Pentium II\128\106
Требования к рабочим 486DX2\8\500(DOS),
станциям 486DX2\16\500(Windows), P 120\64\2G, Pentium II\
128\106 и т.д.
Рекомендуемое до 1000 300-5000
количество определяется определяется
рабочих станций в сети техническими техническими
характеристиками характеристиками
сервера, типом сервера, типом
выбранной ОС, выбранной ОС,
пропускной пропускной
способностью способностью
сетевого оборудования сетевого оборудования
Комментарии к выбору технических аспектов реализации.
Выбор MS SQL сервера обусловлен широкой популярностью данной СУБД, а
значит, много специалистов, знакомых с данным SQL-сервером. Наличие хороших
утилит администратора, защищенность данных как от сбоев, так и от
несанкционированного доступа, невысокая цена и несложность освоения, несомненно,
компенсируют повышение требований к аппаратуре. Положительным моментом так
же можно считать хорошую интеграцию с офисным пакетом Microsoft.
Такая популярная СУБД как Oracle представляет широкий выбор как аппаратных,
так и программных платформ, масштабируясь от персонального компьютера до
многопроцессорных систем и кластеров. Является одним из лидеров на рынке SQL –
серверов. Oracle является отличным решением для корпораций, всерьез задумавшихся
о надежности, масштабируемости, открытости и прогрессивности применяемых
решений и защите капиталовложений. Конечно, столь мощный инструмент требует
квалифицированного обслуживания персонала и стоит несколько дороже. Однако
позволяет наращивать число рабочих станций сети в соответствии с нарастающими
потребностями предприятия (организации).

1. Масштабируемость решений при использовании комплексной системы

(адаптивность)
Под масштабируемостью принято понимать возможность использования
программного продукта в вычислительных сетях разного уровня в масштабе
отдельного подразделения, предприятия, корпорации.
Первым направлением масштабируемости является широкий выбор применяемых
СУБД (MS SQL, Oracle, Sybase, Informix,DB2, PostgresQL), что позволяет покрыть
практически любые запросы по автоматизации. Вторым направлением
масштабируемости является возможность выбора аппаратной и программной
платформы сервера БД: Intel c Windows NT Server, NetWare, Solaris, IIP c IIP\UX, AIX,
Sunc Solaris, SCO Unixware, DEC Alpha c NTWorkgroup Server, AS\400 – это лишь
небольшой перечень возможных конфигураций. Необходимо отметить, что
невозможно дать однозначные рекомендации по выбору наиболее подходящего
варианта, даже опираясь на оценки стоимость\ производительность (основная оценка
по выбору варианта конфигурации программно-технических средств), так как помимо
этого существует множество других, порой, более важных факторов.
Выбирая ту или иную БД, аппаратную и программную конфигурацию, можно
порекомендовать следующие критерии:
- количество одновременно работающих пользователей в сети;
- состав существующего парка вычислительной техники и архитектуры
вычислительной сети;
- характер и структура подразделений предприятия (организации) и
информационные потоки между ними;
- необходимая степень надежности системы (критичность информации).
При большом количестве пользователей важную роль начинает играть
архитектура построения вычислительной сети, так как «узким местом» может стать
пропускная способность самой сети. Обычно для прокладки сети используется
коаксиальный кабель со скоростью передачи данных в 10 МВ\ сек. При более 50-ти
интенсивно работающих пользователей такая пропускная способность может
увеличивать время реакции системы на запрос.

12. Системы электронной коммерции

1. Функции и назначение.
В области современных информационных технологий важное место начинает
занимать электронная коммерция – бизнес, основанный на информационных
технологиях. Развитие электронной коммерции связано с интеграцией различных
стран в рамках Всемирной Торговой Организации (ВТО), в том числе, и России.
Поэтому возникает необходимость взаимодействия на информационном уровне в
соответствии с международными стандартами. Однако использование электронной
коммерции не гарантирует безусловный успех. Так, Efdex, электронная биржа
напитков и продуктов, потерпела крах в сентябре 2000 года. За ней последовала
chemdex.com, обслуживающая химическую промышленность. В январе 2001 года
свернула хозяйственную деятельность Worldoffruit.com, торговавшая свежими
продуктами. Этот перечень может быть продолжен российскими предприятиями.
Дистанционные бизнес-процессы по управлению различными видами ресурсов
реализуются с использованием программно-техничес- ких средств, составляющих
отдельные компоненты информационных технологий.
Системы электронной коммерции используют глобальные вычислительные и
коммуникационные среды и позволяют реализовать новые механизмы управления
предприятием. Однако отсутствуют методики создания, функционирования, оценки
эффективности систем электронной коммерции, интегрированных с
информационными производственными системами.
Необходимо отметить следующие факторы, влияющие на развитие электронной
коммерции применительно к предприятиям:
- стоимость программного обеспечения достаточно высокая;
-стоимость обучения специалистов предметной области по внедрению и
администрированию систем электронной коммерции может превышать стоимость
используемого программного обеспечения;
-требуются инженеры по знаниям для их формализации;
- на специалистов предприятия возлагаются дополнительные функции, связанные
с администрированием системы электронной коммерции по группе потока
материальных ресурсов, за которые они отвечают;
- требуется юридическая поддержка, связанная с новыми технологиями в
виртуальных финансовых системах;
- высокая стоимость поддержки программного обеспечения фирмами-
изготовителями;
- возрастает роль патентной защиты научно-технической продукции для контроля
за существующим и перспективным товарными рынками.
Для разработки и внедрения систем электронной коммерции, интегрированных с
производственной автоматизированной информационной системой, необходимы
методологические основы, определяющие принципы их создания, функционирования,
организационного обеспечения и механизмы влияния на производственные и
социальные сферы. Как и в любой новой области здесь накапливаются понятийные,
конструктивные, процедурные, фактографические знания, которые необходимо
систематизировать, интегрировать с общими принципами управления предприятием.
Полученные новые знания в формализованном виде позволяют повысить
эффективность использования таких компьютеризированных систем с
дистанционными бизнес-процессами, определить тенденции развития
информационных технологий в этой области.
Интеграция России в ВТО требует развития разных форм электронной
коммерции, таких как бизнес-бизнес (business-to-business «B2B»), бизнес-потребитель
(business-to-customer «B2C») и других. Существующие B2B-техно- логии реализуют
взаимодействие автоматизированных информационных систем (АИС) предприятий-
партнеров и обеспечивают передачу данных между ними, которая осуществляется
через вычислительные сети разных уровней. B2C-технологии наиболее актуальны с
точки зрения потребителя. Они поддерживают опосредованный доступ пользователя в
информационно-торговую систему «Продавца».
 2. Электронная коммерция на основе B2C-технологии.
Можно выделить следующие виды В2С – технологий.
1. Web-витрины. Прототипом WEB-витрин можно считать статические WEB-
страницы в Интернет, которые предоставляют информацию о наличии товаров и услуг.
Развитие HTML-технологий обеспечило функциональное развитие WEB-страниц и
автоматизацию некоторых дистанционных бизнес-процессов. Существующие Web-
витрины представляют собой информационную систему для размещения прайс-листов
с возможностью выбора конкретных товаров и автоматического формирования заказов
на эти товары в режиме удаленного доступа. Как правило, web-витрины не имеют
администраторского интерфейса, служащего для управления «электронным
магазином». Кроме того, web-витрины не связаны на информационном уровне с
другими программными приложениями предприятия, организации. Передача
информации в торговую систему «Продавца» осуществляется вручную.
Развитие HTML-технологий и создание динамических средств взаимодействия
дистанционных бизнес-процессов позволяют реализовать на программном уровне
функциональную модель любого типа.
2. Интернет-магазины. Полноценный интернет-магазин – это синтез web-витрины
и системы удаленного управления магазином и полной автоматизации процесса
оформления заказа («Бэк-офиса»). То есть подобная система позволяет
зарегистрировать заказ в торговой системе «Продавца», зарезервировать товары на
складе, передать информацию в финансовую информационную систему, предоставить
«Продавцу» некоторую статистическую информацию.
3. Торговые ряды. Интернет-системы, объединяющие в единый каталог несколько
Web-витрин и Интернет-магазинов, позволяют покупателю сделать выбор
интересующего его товара среди нескольких предложений от разных поставщиков.
4. Аукционы. Интернет-системы для проведения виртуальных аукционов.
5. Электронные биржи. Системы ведения торговых операций купли-продажи через
Интернет, представленные торговыми биржами. Позволяют совершать коммерческие
сделки одновременно многим продавцам и покупателям.
Рассмотренные виды В2С-технологий в своей совокупности представляют
распределенную информационную систему, реализующую разные формы электронной
коммерции, с опосредованным доступом пользователя. Они выполняют
информационно-поисковые функции, включают компоненты информационной
поддержки принятия решений. Для повышения интеллектуальности этих компонент
требуется информационное и математическое моделирование процедур принятия
решений.
3. Электронная коммерция на основе В2В-технологий.
Применение ERP-систем (Enterprise Resource Planning— планирование ресурсов
предприятия)  на сегодняшний день фактически стало стандартом. ERP-система
является комплексной автоматизированной информационной системой и
предназначена для управления финансовой и хозяйственной деятельностью
предприятия, организации. Они позволяют достичь максимальной
производительности предприятия. Однако в современных условиях жесткой
конкуренции применение ERP - систем необходимо, но недостаточно. Предприятия,
организации для достижения максимальной производственной эффективности,
начинают переносить свое внимание с внутренних производственных процессов на
потребителя.
 Наблюдается активное движение в сторону концепции CSRP. Суть ее заключается
в интеграции потребителя с ключевыми бизнес-процессами предприятия. CSRP
(Customer Synchronized Resource Planning - планирование ресурсов в соответствии с
потребностями покупателя) — это система, в некотором роде, являющаяся
надстройкой над ERP и смещающая акцент планирования производства в сторону
предпочтений покупателя. Цель применения CSRP — создание устойчивого
конкурентного преимущества.
Для внедрения CSRP необходимо:
1. Функционирование комплексной автоматизированной информационной
системы на предприятии;
2. Интеграция покупателя с производственной информационной системой и
реализация через него обратной связи на информационном уровне для взаимодействия
с планирующими и производственными подсистемами;
3. Внедрение открытых технологий для информационного взаимодействия
покупателей, поставщиков и автоматизированной информационной системы
предприятия.
Стремительно развивается новая стратегия, называемая CRM, главная идея
которой — максимальная ориентация на каждого конкретного клиента. Customer
Relationships Management - управление взаимоотношениями с клиентами. Это
системы, обеспечивающие автоматизированное управление деятельностью
предприятия, начиная рекламой и процессом продажи и заканчивая производством
продукции, с учетом потребностей конкретных покупателей.
Системы CSRM и CRM можно отнести к системам электронной коммерции,
которые обеспечивают информационную поддержку процедур принятия
управленческих решений и реализуют распространение, маркетинг, продажу или
доставку товаров и услуг электронным способом по вычислительной сети, в том
числе, и Интернет.
В2В - технологии представляют собой совокупность организационного,
программного, информационного и технического обеспечения и реализуют
информационное взаимодействие между удаленными системами с использованием
глобальной сети Интернет. Системы электронной коммерции на основе В2В –
технологий являются перспективным направлением в развитии информационных
технологий для комплексной автоматизации дистанционных бизнес-процессов. Такие
WEB - технологии обеспечивают информационное взаимодействие на разных уровнях
организационного управления потоками ресурсов.
Актуальны разработки В2В-технологий в форме интегрированной
информационной системы на основе распределенной базы данных оперативного
доступа в режиме реального времени. Это позволяет интегрировать разнородные
автоматизированные информационные системы и WEB-приложения,
автоматизировать дистанционные бизнес-процессы в едином информационном
пространстве.

4. Интеграция систем электронной коммерции с производственными

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