4. Жизненный цикл аис

В ходе своего жизненного цикла информационная система проходит 6 стадий:

1) Предпроектная стадия;

2) Стадия проектирования;

3) Стадия разработки;

4) Стадия внедрения;

5) Стадия эксплуатации;

6) Стадия модернизации

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

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

ПРЕДПРОЕКТНАЯ СТАДИЯ

Основные этапы:

1) Осознание потребности в автоматизации;

2) Определение целей, задач и стратегии автоматизации;

3) Составление технического задания на проектирование.

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

• такая система уже создана в соседней (конкурирующей) организации;

• деньги есть, почему бы и не сделать - к тому же это сейчас модно и престижно;

• люди, предлагающие создать систему, пользуются высоким авторитетом:

• закуплено огромное количество компьютеров, использующихся, в лучшем случае, как индивидуальная картотека, в худшем - как печатная машинка или игрушка;

• из-за нечеткого информационного взаимодействия между подразделениями организации участились сбои в работе организации;

• рутинная обработка и неэффективный доступ к информации сдерживает рост организации;

• созданная в 70-е (на базе ЕС ЭВМ), 80-е (на базе СМ ЭВМ) и 90-е гг. (на базе персональных компьютеров) система не способна решать сегодняшние задачи.

Первым решением, принимаемым на предпроектной стадии, является определение целей, задач.

Рис 1.1 Стадии и основные этапы жизненного цикла информационной системы и стратегии автоматизации.

Что даст автоматизация?

Как правило, грамотный руководитель понимает, что автоматизация не снизит, а скорее увеличит текущие расходы и численность персонала. Многолетняя практика развеяла миф середины 70-х об автоматизации как способе экономии средств. Сегодня его место

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

Первые шаги.

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

Имеет ли организации опыт автоматизации?

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

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

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

Все ли целесообразно автоматизировать?

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

Один из законов разделения задач между человеком и компьютером состоит в том, чтобы каждому поручить, делать то, с чем он справляется наилучшим образом. Так, компьютер может оперировать огромными объемами информации, производить трудоемкие расчеты, совершенно при этом не уставая. Человек с этим справляется гораздо хуже, однако он хорошо действует в условиях неопределенности, отсутствия четких критериев и алгоритмов работы. Иначе говоря, автоматизации подлежат все задачи, решение которых можно описать формализованным способом - с помощью структур, алгоритмов, математических зависимостей и др. Однако, применение этого правила всегда (или почти всегда) провоцирует вопросы совершенно иного рода - насколько эффективна будет такая автоматизация, осуществима ли она при умеренных затратах, насколько она усложнит эксплуатацию системы, не приведет ли частичное высвобождение человека от «живого» процесса к потере им опыта и навыков и др. Ответив на эти вопросы, разработчик сталкивается со следующими проблемами.

Какую стратегию выбрать?

Известны две ортогональные стратегии автоматизации - они получили названия: метод «шахт» и метод «пластов» (в классической литературе по автоматизации можно встретить другие названия этих стратегий - автоматизация «снизу-вверх» и автоматизация «сверху-вниз»). Рассмотрим их сущность, основные достоинства и недостатки.

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

• благодаря методу шахт оказывается возможным «делить каждое из исследуемых затруднений на столько частей (задач), сколько это возможно и нужно для лучшего их преодоления» (Декарт). Однако не следует допускать чрезмерную декомпозицию на множество «микроскопических» задач - это приводит к «тяжеловесности», громоздкости и распыленности системы и избыточности процедур обработки;

• основное преимущество метода заключается в «кажущейся» простоте реализации, поскольку задачи разрабатываются изолированно друг от друга (однако мы увидим ниже, что при этом

возникают большие неудобства;

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

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

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

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

В зависимости от обстоятельств, перечисленные достоинства метода шахт могут превратиться и его недостатки:

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

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

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

• внедрение средств автоматизации часто создает благоприятные условия для пересмотра организационной структуры, уже устаревшей и не приспособленной к нуждам и функциям организации;

• независимые с виду задачи нередко требуют сбора одной и той же информации, что приводит к избыточности данных и некоторых процедур обработки;

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

1) описать и исследовать информационную систему организации;

2) разбить систему на информационные подсистемы таким образом, чтобы они были в наибольшей мере независимы друг от друга;

3) автоматизировать информационные подсистемы с учетом существующих между ними связей;

4) связать и собрать подсистемы в одно целое - интегрированную автоматизированную информационную систему.

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

Рис. 1.2. Стратегии автоматизации методом шахт и пласта

• возможность достижения в итоге интегрированного управления организацией;

• однократная регистрация данных, используемых несколькими информационными подсистемами;

• реализация метода редко осуществляется на основе существующей организационной структуры.

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

Среди недостатков метода:

• необходимость почти во всех случаях затрагивать структуру

организации;

• слишком затяжной и трудный процесс системного исследования и описания организации;

• система в целом представляет собой настоящую паутину, запутанную и непрочную, что затрудняет как ее реализацию, так и внесение изменений впоследствии;

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

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

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

Техническое задание: привычный документ?

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

• параметры функционирования - технические характеристики, характеристики надежности и др.;

• технология проектирования и изготовления.

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

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

• выполнить функциональный анализ процессов производства и управления,

• проанализировать организационную структуру и документооборот (информационные потоки),

• поставить диагноз существующей системе организационного управления,

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

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

• общее описание объекта автоматизации, его функциональную, организационную и территориальную структуру;

• архитектурные решения (включая общие решения о структуре корпоративной сети);

• варианты и планы реализации информационной системы

• оценку необходимых ресурсов и др.

СТАДИЯ ПРОЕКТИРОВАНИЯ

Основные этапы:

1) Проектирование архитектуры системы;

2) Проектирование функциональной модели;

3) Проектирование информационной (концептуальной) модели;

4) Проектирование алгоритмической модели;

5) Составление технического задания (спецификации) на разработку.

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

• характер деятельности, цели и задачи организации;

• организационная и должностная структура организации;

• документы, документооборот и другие потоки данных;

• используемые средства обработки информации;

• затраты на функционирование системы.

Должностная структура отражает «архитектуру» управления.

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

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

Классификация функций.

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

• оперативное управление, осуществляемое на уровне среднего и высшего звена управления и включающее функции оперативного анализа, планирования и управления;

• стратегическое управление, осуществляемое только на уровне

высшего управленческого звена и предполагающее принятие

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

По своему характеру как исполнительные, так и управленческие функции подразделяются на:

• производственно-хозяйственные; непосредственно обеспечивающие исполнение производственного процесса;

• финансово-экономические;

• технологические, связанные с поддержанием и оперативным, управлением технологическими процессами;

• научные и конструкторские.

Основная идея группирования видов деятельности и функций состоит в разделении исполнительных и управленческих функции, и определении двух принципиально различных типов подсистем создаваемой системы: "низовых" подсистем и подсистем оперативного и стратегического управления. Здесь необходимо обратить внимание, что задачей «низовых» звеньев системы является не только автоматизация исполнительской деятельности конкретного подразделения или лица, но и (главная задача!) информационное обеспечение высшего и среднего управленческого звена.

Документооборот - «лицо» организации.

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

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

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

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

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

В зависимости от специфики организации, могут существовать и другие признаки классификации документов, например, уровень секретности, степень важности и др.

Документы существуют, но не нужны.

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

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

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

Документы не существуют, но нужны.

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

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

• заголовок либо отсутствует, либо не соответствует содержанию документа;

• имеющиеся в документе графы не всегда используются;

• на поставленные в документе вопросы не всегда даются ответы;

• поперек некоторых документов вручную делаются надписи и т.д

До каких пор обследовать?

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

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

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

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

• полностью централизованные, предполагающие наличие единого ядра, в котором сосредоточены все ресурсы и всецело зависящих от его подсистем и элементов нижнего уровня (“сильный” центр и “слабые” элементы)

• полностью децентрализованные, когда все подсистемы и элементы функционируют самостоятельно и независимо взаимодействуют друг с другом в соответствии с некоторым протоколом (“сильные” элементы и отсутствие центра)

Функциональная архитектура.

Рассмотрение различных видов функциональной организации основано на разбиении функции информационной системы на 3 основные категории:

• Функция накопления, хранения и обслуживания информации (назовем такие функции сервисом);

• функции формализации и автоматизации задач и процессов управления организацией с использованием хранимой информации (назовем их сервисом приложений);

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

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

Одноуровневая (традиционная) архитектура.

Архитектура большинства информационных систем, функционирующих сегодня в организациях, представляется простой схемой, состоящей из автоматизированных рабочих мест (АРМ), связанных между собой локальной сетью (рис. 1.3). АРМ, как правило, принадлежит одному пользователю (или группе пользователей со сходными задачами) и жестко ориентирован на его задачи. Каждая задача, решаемая пользователем, разрабатывается независимо, имеет свои собственные данные, свои алгоритмы их обработки и свой пользовательский интерфейс. Иначе говоря, в одноуровневой системе каждое АРМ сочетает в себе все три перечисленные выше функции: обслуживание данных, формализованное описание управленческого процесса и пользовательский интерфейс. Традиционная архитектура соответствует типичной децентрализованной схеме. Единое информационное пространство в ней отсутствует, различные базы данных слабо или вообще не связаны между собой, модели данных, на основе которых они построены, могут существенно "отличаться” друг от друга (одни и те же сущности имеют разные атрибуты, сами атрибуты по-разному описаны). Данные, посредством которых разные базы данных взаимодействуют друг с другом, передаются в лучшем случае по сети или на дискетах, в худшем - на бумаге. Любая, модификация данных или алгоритмов их обработки ведет к переделке существенной части программного обеспечения. Для обеспечения информационного обмена и поддержания баз данных в актуальном (отражающем текущую информацию) состоянии существуют сложные административные или организационные процедуры, предписывающие исполнителям определенный порядок обслуживания и ведения баз данных. Обычно эти процедуры далеки от совершенства и не всегда досконально выполняются - как следствие, возникают проблемы защиты данных, поддержания их целостности.

Рис. 1.3. Одноуровневая архитектура информационной системы

Двухуровневая архитектура (с сервером данных).

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

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

Трехуровневая архитектура (с сервером данных и сервером приложений).

Архитектурное решение этого типа предполагает дальнейшее разделение функций системы. Автоматизируемые процессы управления типизируются (отчуждаются от конкретных пользователей и «обезличиваются»), формально описываются и объединяются, образуя так называемые серверы приложений (рис. 1.5). Сервер приложений не знает, кто пользуется его услугами - он лишь умеет выполнять определенные типовые управленческие задами. Чтобы решить свою конкретную задачу, пользователь посылает запрос на нужный ему сервер приложений, который активизирует требуемую управленческую процедуру и, в свою очередь, обращается к серверу данных за информацией. Серверов приложений, как и серверов данных, может быть несколько - в этом случае каждый из них реализует свою группу задач управления.При трехуровневой архитектуре АРМ пользователя выполняет, по сути, функции удаленного терминала, обеспечивая пользовательский интерфейс. Сама организация интерфейса сводится к компоновке рабочего стола пользователя определения требуемых ему процедур и организации взаимодействия с ними. Изменения, вносимые в какой-либо компонент трехуровневой системы, в наименьшей степени затрагивают другие компоненты.

Рис. 1.5. Трехуровневая архитектура информационной системы