Организация труда при разработке АИС

Организация разработки технического проекта

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

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

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

Фактически технический проект содержит комплекс эконо­мико-математических и алгоритмических моделей.

Полный комплект технического проекта на систему вклю­чает в себя 10 документов:

1. Пояснительная записка.

2. Функциональная и организационная структура системы.

3. Постановка задач и алгоритм решения.

4. Организация информационной базы.

5. Альбом форм документов.

6. Система математического обеспечения.

7. Принцип построения комплекса технических средств.

8. Расчет экономической эффективности системы.

9. Мероприятия по подготовке объекта к внедрению системы.

10. Ведомость документов.

Из приведенного перечня документ 3 ("Постановка задач и алгоритм решения") выполняется для каждой отдельной за­дачи, включаемой в ЭИС, остальные документы являются об­щими для всей системы. Кроме того, документы 1, 2, 5, 8, 9 могут разрабатываться для отдельных подсистем.

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

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

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

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

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

• экономико-математическая модель задачи (структурная и развернутая форма представления);

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

• нормативно-справочная информация (НСИ) (содержание и формы представления);

• информация, хранимая для связи с другими задачами;

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

• информация по внесению изменений (система внесения изменений и перечень информации, подвергающейся измене­ниям);

• алгоритм решения задачи (последовательность этапов рас­чета, схема, расчетные формулы);

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

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

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

Информационная часть технического проекта объединяет документы 4 и 5. В документе "Организация информацион­ной базы" отражаются источники поступления информации и способы ее передачи для решения первоочередного комп­лекса функциональных задач; совокупность показателей, ис­пользуемых в системе; состав документов, сроки и периодич­ность их поступления; основные проектные решения по орга­низации фонда НСИ; состав НСИ, включая перечень рекви­зитов, их определение, значность, диапазон изменения и пере­чень документов НСИ; перечень массивов НСИ, их объем, по­рядок и частота корректировки информации; предложения по унификации документации, контрольный пример по вне­сению изменений в НСИ; структурная форма НСИ с описа­нием связи между его элементами; требования к технологии создания и ведения фонда; методы хранения, поиска, внесе­ния изменений и контроля; определение объемов и потоков информации НСИ.

"Альбом форм документов" содержит формы НСИ.

Математическая часть технического проекта содержит обоснование структуры математического обеспечения, обосно­вание выбора системы программирования, в том числе пере­чень стандартных программ.

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

3.9 Организация разработки рабочего проекта

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

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

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

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

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

В состав рабочей документации проекта входят документы:

1. Пояснительная записка.

2. Функциональная и организационная структура.

3. Должностные инструкции.

4. Инструкция по заполнению входных оперативных доку­ментов.

5. Инструкция по использованию выходных документов.

6. Инструкция по организации и ведению нормативно-справочной информации.

7. Инструкция по организации хранения информации в

архиве.

8. Инструкция по подготовке информации к вводу в ПК.

9. Расчет экономической эффективности системы.

10. Мероприятия по подготовке объекта к внедрению.

11. Ведомость документов.

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

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

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

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

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

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

Проектная документация, включая техническое задание, технические и рабочие проекты, оформляется в соответствии с требованиями Единой системы конструкторской докумен­тации (ЕСКД).

3.10 Внедрение экономической информационной системы

Рабочий проект служит основой для внедрения системы. Вне­дрение системы представляет собой процесс, включающий под­готовку объекта, опытную эксплуатацию и приемку ЭИС в промышленную эксплуатацию.

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

Основными этапами внедрения системы являются:

• подготовка объекта к внедрению системы;

• сдача задач и подсистем в опытную эксплуатацию;

• проведение опытной эксплуатации;

• сдача задач, подсистем, системы в целом в промышлен­ную эксплуатацию.

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

Сдача задач в опытную эксплуатацию осуществляется пос­ле представления рабочей документации заказчику и оформ­ляется актом.

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

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

Срок проведения опытной эксплуатации устанавливается в каждом конкретном случае.

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

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

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

Сдача подсистемы в промышленную эксплуатацию прово­дится после сдачи в промышленную эксплуатацию задач пус­кового комплекса данной подсистемы.

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

Опытная эксплуатация системы должна осуществляться на основе необходимого объема информации о деятельности объекта в установленном режиме функционирования.

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

В ходе промышленной эксплуатации ЭИС проводится ана­лиз функционирования системы. Целями анализа функциони­рования системы являются проверка эффективности реализо­ванных проектных решений в условиях ее промышленной экс­плуатации, выработка рекомендаций по дальнейшему разви­тию системы и формирование типовых решений.

Анализ функционирования системы предусматривает про­верку:

• функционирования технических средств;

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

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

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

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

В процессе анализа функционирования задач, подсистем и действий персонала в условиях внедрения ЭИС проводятся ра­боты, аналогичные обследованию объекта по параметрам каж­дой функции подсистем ЭИС, с учетом применяемого комп­лекса технических средств и следующих факторов:

• своевременности поступления к управленческому персо­налу необходимой информации;

• повышения достоверности информации;

• улучшения технико-экономических показателей работы

предприятия.

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

По результатам анализа функционирования системы раз­рабатываются предложения для дальнейшего развития ЭИС.

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. Трехуровневая архитектура информационной системы

.

Дата добавления: 2014-10-17