Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

ПРОЕКТИРОВАНИЕ РЕАЛИЗАЦИИ ОПЕРАЦИЙ БИЗНЕС-ПРОЦЕССА «ДВИЖЕНИЕ БИБЛИОТЕЧНОГО ФОНДА» (Аналитическая часть)

Содержание:

Введение

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

Задачами выполнения курсовой работы являются:

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

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

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

- сбор и анализ фактических данных по проблематике курсовой работы;

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

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

Объектом исследования моей курсовой работы являются информационные системы. Предметом является проектирование операции бизнес-процесса «Движение библиотечного фонда».

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

Макропроектирование включает в себя три основных раздела:

1) определение целей создания системы и круга решаемых ею задач;

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

3) выбор показателя или группы показателей эффективности системы.

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

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

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

1. Титульный лист.

2. Содержание.

3. Введение.

4. Основное содержание (главы основной части).

5. Заключение.

6. Список использованной литературы.

Основное содержание разделено на две главы: аналитическая и проектная часть.

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

технологии прототипного проектирования и систему управления базами данных (СУБД) ACCESS. Конечный итог работы заключается в том, что будет спроектировано и реализовано рабочее клиентское приложение для

библиотечного фонда в Visual Studio C++. Актуальность данной работы высока, так как сегодняшние предприятия, все без исключения, стремятся ввести компьютеризацию и перейти на электронный вариант работы.

Конкретно будем рассматривать, и проектировать приложение и СУБД для

сотрудника библиотеки.

1 глава. Аналитическая часть

Выбор комплекса задач автоматизации

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

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

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

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

Как правило одновременно носителями логистической информации и формами ее сохранения выступают флоппи-диски, ZIP-диски, DVD, аудиокассеты, видеокассеты. CD, бумагу.

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

а) входные и выходные информационные потоки;

б) внутренние и внешние информационные потоки;

в) вертикальные и горизонтальные информационные потоки

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

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

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

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

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

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

Рассмотрим основные понятия и определения свойственные рассматриваемой области.

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

Процесс проектирования ИС представляет собой преобразование входной информации об объекте и методах проектирования в проект ИС в соответствии с ГОСТом.

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

Субъектами проектирования ИС являются проектная организация и организация заказчик.

Технология проектирования ИС – это комплекс методологий и средств проектирования, а также методов и средств организации проектирования.

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

В процессе работы над проектом необходимо знать ЧТО, КАК, КОМУ и в КАКОЙ ПОСЛЕДОВАТЕЛЬНОСТИ это должно быть сделано.

Требования к выбираемой технологии проектирования:

·      проект по выбранной технологии должен отвечать требованиям заказчика;

·      максимальное отображение всех этапов жизненного цикла проекта;

·      обеспечение min трудовых и стоимостных затрат на проектирование и сопровождение проекта;

·      технология должна способствовать росту производительности труда проектировщика;

·      простота ведения проектной документации;

·      технология должна обеспечивать надежность процесса проектирования и эксплуатации проекта.

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

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

§ каноническая - для небольших локальных ИС;

§ индустриальная технология, подразделяющаяся на:

·      автоматизированное –  использование CASE-технологий;

·      типовое - параметрически-ориентированное или модельно-ориентированное. 

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

Средства проектирования должны обладать следующими качествами:

·      охватывать все этапы жизненного цикла ИС;

·      совместимы технически, программно и информационно;

·      просты в освоении и применении;

·      экономически целесообразны.

Средства проектирования ИС можно разделить на два класса:

1.    без использования ЭВМ на всех стадиях проектирования (средства организационно-методического обеспечения операций проектирования, куда входят стандарты, регламентирующие процесс проектирования систем, Единая Система Классификации и Кодирования информации, унифицированная система документации (УСД), модели описания и анализа потоков информации и т.п.);

2.    с использованием ЭВМ, которые подразделяются на 4 подкласса:

  • Операционные средства (Алгоязыки, библиотеки стандартных подпрограмм и классов объектов, средства для тестирования и отладки программ, поддержки процесса документирования проекта и т.д.)
  • Средства общесистемного назначения (СУБД, методоориентированные ППП (задачи дискретного программирования, мат. Статистики), табл. процессоры, статистические ППП, граф., текстовые редакторы, оболочки экспертных систем, интегрированные ППП)
  • Функциональные средства (типовые проектные решения, функциональные ППП, типовые проекты)
  • Средства автоматизации проектирования ЭИС (Средства, поддерживающие разработку проекта- CASE-технологии)

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

Эти документы регламентируют:

·      порядок разработки, внедрения, сопровождения ПО;

·      общие требования к составу ПО и связям между его компонентами, а также к его качеству;

·      виды, состав и содержание проектной и программной документации. 

Нормативной базой НМО являются международные и отечественные стандарты в области информационных технологий и прежде всего:

·      международные стандарты ISO/IEC;

·      стандарты Российской Федерации ГОСТ Р;

·      стандарты организации-заказчика. 

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

Одной из основных проблем, которые приходится решать при создании больших и сложных систем любой природы, в том числе и ПО, является проблема сложности. Ни один разработчик не в состоянии выйти за пределы человеческих возможностей и понять всю систему в целом. Единственный эффективный подход к решению этой проблемы, который выработало человечество за всю свою историю, заключается в построении сложной системы из небольшого количества крупных частей, каждая из которых, в свою очередь, строится из частей меньшего размера, и т.д., до тех пор, пока самые небольшие части можно будет строить из имеющегося материала. Этот подход известен под самыми разными названиями, среди них такие, как «разделяй и властвуй» (divide et impera), иерархическая декомпозиция и др. По отношению к проектированию сложной программной системы это означает, что ее необходимо разделить (декомпозировать) на небольшие подсистемы, каждую из которых можно разрабатывать независимо от других. Это позволяет при разработке подсистемы любого уровня иметь дело только с ней, а не со всеми остальными частями системы. Правильная декомпозиция является главным способом преодоления сложности разработки больших систем ПО. Понятие «правильная» по отношению к декомпозиции означает следующее:

·      количество связей между отдельными подсистемами должно быть минимальным (принцип «слабой связанности» — Low Coupling);

·      связность отдельных частей внутри каждой подсистемы должна быть максимальной (принцип «сильного сцепления» - High Cohesion).

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

·      каждая подсистема должна инкапсулировать свое содержимое (скрывать его от других подсистем);

·      каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами. 

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

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

Стоит подробно рассмотреть структурный метод анализа и проектирования ПО.

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

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

В качестве примера рассмотрим одну из широко используемых систем такого проектирования – SADT (Structured Analysis and Design Technique – технология структурного анализа и проектирования) – это графические обозначения и подход к описанию систем.

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

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

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

Метод SADT реализован в виде стандарта IDEF0.

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

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

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

Объекты имеют свойства и методы.

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

Методы объекта – это программные процедуры, обеспечивающие выполнение им определенных действий.

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

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

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

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

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

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

Характеристика существующих бизнес –процессов

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

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

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

Рисунок 1 Диаграмма IDEF0 верхнего уровня

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

Рисунок 2. Дочерняя диаграмма IDEF0

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

В стандарте ISO 9000-2001 процесс определен как «совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующих входы в выходы».

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

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

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

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

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

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

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

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

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

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

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

Рисунке 3. Стандартная цепочка управленческого цикла

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

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

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

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

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

Бизнес-процессы развития представляют инвестиционные виды деятельности, где усилия прикладываются сегодня, а результаты получаются по прошествии определенного периода (таблица .2.1.).

Таблица 1.

Характеристики бизнес-процессов развития

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

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

При описании окружения бизнес-процесса рекомендуется построить его графическую схему, приведенную на рисунке 4

Рисунок 4. Схема окружения бизнес процесса.

При описании окружения бизнес-процесса его входы и выходы делят на два типа: первичные и вторичные; их характеристики приведены в табл. 2.2.

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

Таблица 2

Характеристики первичных и вторичных входов и выходов бизнес-процесса

Рассмотрим некоторые распространенные модели выделения бизнес-процессов.

Модель цепочки добавления ценности (Value Chain Model) разработана М. Портером. Модель цепочки добавления ценности рассматривает компанию как цель базисных действий, каждое из которых добавляет ценность продукту, а оптимизация этих базисных действий максимизирует прибыль и/или минимизирует затраты. Эта модель включает процессы, приведенные на рисунке 5. Эта цепочка моделирует как основную, так и вспомогательную деятельность компании. Основная деятельность связана с производством и дистрибуцией продукции. Вспомогательная деятельность помогает выполнять основную деятельность. Структура бизнес-процессов (перечень подпроцессов) модели цепочки добавления ценности приведены в таблица 3.

Рисунок 5. Бизнес-процессы верхнего уровня модели

цепочки добавления ценности

Таблица 3.

Структура бизнес-процессов модели цепочки добавления ценности

Модель IBL (The International Business Language):

Модель разработана компанией Price Water House Coopers и включает процессы, приведенные на рисунке 6.

Процессы цепочки добавления ценности непосредственно влияют на продукт или услугу, предоставляемую клиенту.

Рисунке 6. Перечень бизнес-процессов верхнего уровня модели IBL

13-процессная модель разработана Американским центром производительности и качества (American Productiv Ityand Quality Center) и включает процессы, приведенные в таблице 4.

Таблица 4.

Выходы/результаты бизнес-процессы 13-процессной модели

1.3. Характеристика документооборота, возникающего при решении задачи

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

"1 С: Документооборот 8";

"Евфрат документооборот";

" LanDocs ".

1) "1С: Документооборот 8":

Программный продукт "1С:Документооборот 8", разработанный на новой технологической платформе "1С:Предприятие 8.2" , является преемником программного продукта "1С:Архив 3", который уже более 10 лет применяется в сотнях организаций, предприятий и учреждений, и предназначена для автоматизации документооборота.

"1С:Документооборот 8" позволяет:

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

· сократить время поиска нужной информации и суммарное время коллективной обработки документов;

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

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

"1С:Документооборот 8" в комплексе решает задачи автоматизации учета документов, взаимодействия сотрудников, контроля и анализа исполнительской дисциплины:

· централизованное безопасное хранение документов,

· оперативный доступ к документам с учетом прав пользователей,

· регистрация входящих и исходящих документов,

· просмотр и редактирование документов,

· контроль версий документов,

· полнотекстовый поиск документов по их содержанию,

· работа с документами любых типов: офисными документами, текстами, изображениями, аудио- и видеофайлами, документами систем проектирования, архивами, приложениями и т.д.,

· коллективная работа пользователей с возможностью согласования, утверждения и контроля исполнения документов,

· маршрутизация документов, настраиваемая по каждому виду документов в отдельности,

· автоматизированная загрузка документов из электронной почты и со сканера,

· учет и контроль рабочего времени сотрудников.

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

· ГОСТ Р 6.30-2003,

· ГОСТ Р 51141-98,

· Федеральный закон Российской Федерации от 27.07.2006 г. № 149-ФЗ "Об информации, информационных технологиях и о защите информации",

· Требования ГСДОУ,

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

"1С:Документооборот 8" поддерживает многопользовательскую работу в локальной сети или через Интернет, в том числе и через веб-браузеры.

Пользователи, создававшие документы в ознакомительной версии "1С:Архив 8" и бета-версии "1С:Документооборот 8", могут автоматически обновить их на финальную версию "1С:Документооборот 8". После обновления все созданные ранее документы будут сохранены.

2) Евфрат

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

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

В "бумажном" документообороте центральным является понятие документа. В электронном документообороте пользователи работают с электронными документами. Электронный документ не является в полном смысле аналогом документа физического. Например, если речь идет о договоре, то реальный договор представляет собой некий бумажный документ. Ему в соответствие ставится электронный документ, который в общем случае, помимо электронного аналога бумажного документа (например, текстового файла) включает также дополнительную информацию. При регистрации документ помещается в базу данных (БД) системы электронного документооборота (БД комплекса "ЕВФРАТ-Документооборот"). Далее все операции производятся с электронным документом.

В комплексе "ЕВФРАТ-Документооборот" под документом понимается совокупность трех информационных блоков :

1) регистрационно-контрольная карточка (РКК) документа, содержащая набор реквизитов, обеспечивающих быстрый поиск документа в БД комплекса;

2) присоединенные файлы: текст электронного документа, изображения, графики, диаграммы, аудио- и видеоматериалы и другие типы файлов;

3) ссылки на связанные документы — зарегистрированные в комплексе документы, с которыми связан данный документ.

Главное окно модуля Евфрат-документооборот представлено на таблице 5

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

Таблица 5

Главное окно модуля Евфрат-документооборот

Документооборот сегодня

Просрочено

Должно быть использовано сегодня

Поступили сегодня

Бессрочно

Всего

У меня на контроле

Док-ты

1

4

5

Поручения

6

6

Уведомления

2

15

Поручено мне

Док-ты

5

5

Поручения

2

3

Уведомления

8

42

Согласования и утверждения

Отправленные

2

24

26

Присланные

Уведомления

10

Сообщения пользователей

Входящие

1

Отправленные

1

Таблица 6

Стандартные папки и их содержание

Содержание

Папка

«Документооборот»

Вложенные папки «На контроле», «Поручения», «Согласования», «Входящие», «Исходящие»

«На контроле»

Документы, работы по которым контролирует пользователь

«Поручения»

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

«Согласования»

Документы, направленные пользователю на согласование

«Входящие»

Входящие сообщения внутренней почты

«Корзина»

Удаленные документы, поручения и сообщения внутренней почты

«Исходящие»

Исходящие сообщения внутренней почты

«Общие папки»

Общедоступные документы. Документы помещаются в эту папку и удаляются из нее администратором документооборота или администратором комплекса. Для него работа с этой папкой аналогична работе с папкой «Мои документы»

«Мои документы»

Папки, созданные пользователем, и папки, содержащие документы, отобранные по определенному признаку при помощи поиска

«Результаты поиска»

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

3) LANDOCS

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

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

• Администратор – сотрудник, выполняющий настройку и контроль работы системы.

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

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

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

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

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

Система обеспечивает:

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

• Автоматизированный контроль исполнения поручений. Позволяет контролировать исполнение документов сотрудниками.

• Поиск и информационно-справочное обслуживание.

• Согласование документов в электронном виде. Механизм сообщений предоставляет возможность автоматизированной рассылки документов сотрудникам.

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

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

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

1.4. Обоснование проектных решений по информационному обеспечению

Основным направлением совершенствования документации является унификация и стандартизация.

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

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

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

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

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

Унифицированные системы управленческой документации разрабатываются на основе:

- единообразия построения форм документов;

- регламентации содержания документов, входящих в каждую систему;

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

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

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

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

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

К настоящему времени на обще управленческом уровне унифицировано было свыше трех с половиной тысяч (3500) форм плановых, учетных, финансовых и других документов, сведенных в 1993 г. в Общероссийский классификатор управленческой документации (ОКУД). Каждый из документов получил кодовое обозначение, определяющее его принадлежность к одной из систем документации и место в этой системе. Код формы подтверждает само его право на существование и соответствие утвержденному образцу-эталону.

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

Унифицированная система внешнеторговой документации:

- оперативно-коммерческая документация;

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

- расчетная внешнеторговая документация;

- документация, оформляемая при ввозе (вывозе) товара;

- транспортная внешнеторговая документация;

- экспедиторская внешнеторговая документация.

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

Унификация текста производится по следующим основным направлениям: состав информации, структура текста, языковые средства представления информации.

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

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

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

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

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

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

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

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

Обеспечение конфиденциальности информации. Утечка конфиденциальной информации может повлечь за собой миллионные убытки организации. В отличие от традиционного «бумажного» документооборота, ECM-система обеспечивает доступ к документам строго в соответствии с назначенными правами пользователей, все действия над документом (чтение, изменение, подписание), протоколируются.

Выполнение требований стандартов ISO 9000. Постановка менеджмента качества в настоящее время стала одной из приоритетных задач, решаемых российскими компаниями. Одно из требований к системе менеджмента качества (СМК) - это прозрачно поставленный документооборот и информационное взаимодействие. Преимущества использования ECM-системы при постановке СМК:

- обеспечение строгого выполнения разделов стандарта ISO 9001:2000 по управлению документами и записями;

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

- предоставление средств для контроля со стороны руководства за функционированием СМК.

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

Развитие корпоративной культуры. Процесс внедрения ECM-системы налаживает и поддерживает корпоративную культуру. Оптимизация взаимодействия сотрудников и развитие горизонтальных связей приводят к сплочению команды. В то же время возрастает ответственность каждого сотрудника за качественное выполнение выданного ему задания.

Рост конкурентных преимуществ. Внедрение ECM-системы напрямую отражается на конкурентных преимуществах компании перед другими игроками рынка. Повышается скорость и качество обслуживания клиентов за счет ускорения движения информационных потоков и четкого контроля всех процессов. Функционирование даже крупного предприятия становится более мобильным и меньше зависит от конкретных «незаменимых» сотрудников».

1.5. Обоснование проектных решений по программному обеспечению

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

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

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

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

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

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

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

- технология должна максимально отражать все этапы цикла жизни проекта;

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

- технология должна способствовать росту производительности труда проектировщиков;

- технология должна обеспечивать надежность процесса проектирования и эксплуатации проекта;

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

Технология проектирования АИС реализует определенную методологию проектирования. В свою очередь, методология проектирования предполагает наличие некоторой концепции, принципов проектирования и реализуется набором методов и средств.

Методы проектирования АИС можно классифицировать по степени использования средства автоматизации, типовых проектных решений, адаптивности к предполагаемым изменениям.

По степени автоматизации различают:

- ручное проектирование (при котором проектирование компонентов ИС осуществляется без использования специальных инструментальных программных средств, а программирование — на алгоритмических языках);

- компьютерное проектирование (при котором производится генерация или конфигурирование (настройка) проектных решений на основе использования специальных инструментальных программных средств);

По степени использования типовых проектных решений различают:

- оригинальное (индивидуальное), когда проектные решения разрабатываются «с нуля» в соответствии с требованиями к АИС. Характеризуется тем, что все виды проектных работ ориентированы на создание индивидуальных для каждого объекта проектов, которые в максимальной степени отражают все его особенности;

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

По степени адаптивности проектных решений различаются следующие методы:

- реконструкция – адаптация проектных решений выполняется путем переработки соответствующих компонентов;

- параметризация – проектные решения настраиваются в соответствии с заданными и изменяемыми параметрами;

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

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

Основные стадии создания автоматизированной информационной системы:

- формирование требований к АИС;

- разработка концепции АИС;

- разработка технического задания;

- разработка эскиза проекта;

- разработка технической части проекта;

- разработка рабочей документации на АИС;

- ввод в действие;

- сопровождение АИС.

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

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

Технология проектирования определяется как совокупность трех составляющих:

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

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

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

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

На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми СП:

- ARIS;

- ERWin / BPWin;

- Rational Rose;

- Oracle Designer.

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

BPWin - инструмент визуального моделирования бизнес-процессов. ERWin - средство, используемое при моделировании и создании баз данных произвольной сложности на основе диаграмм «сущность - связь».

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

Oracle Designer - функциональное средство для описания предметной области. Входит в комплекс инструментальных средств Oracle9i Developer Suite по проектированию программных систем и баз данных, реализующих технологию CASE и собственную методологию разработки ИС компании Oracle - «CDM», позволяющих команде разработчиков провести проект, начиная от анализа бизнес-процессов через моделирование к генерации кода и получению прототипа, а в дальнейшем и окончательного продукта. Это средство имеет смысл использовать при ориентации на всю линейку продуктов Oracle, применяемую для проектирования, разработки и реализации сложной программной системы.

2 глава. Проектная часть

2.1. Информационная модель и её описание

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

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

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

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

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

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

Рисунок 7. Модель библиотеки

.

К функциональным обязанностям библиотекаря относится:

• Получение книг и журналов и завод их

на склад и в картотеку

• Выдача книг и журналов читателям

• Получение книг и журналов от читателей по возвращению

• Ведение картотеки, завод новых читательских билетов, замена

заполненных или негодных

• Хранение книг и журналов в должном вид

2.2. Характеристика нормативно-справочной, входной и оперативной информации

Перечень входных данных определяется реквизитами из читательского билета и вкладыша (рисунок 8 и рисунок 9):

• Данные о читателе (фамилия, имя, отчество, группа, домашний адрес, домашний телефон, сотовый телефон)

• Данные о взятых книгах и журналах (инвентаризационный номер, автор и название)

• Данные о движении книг и журналов (дата выдачи, отдел, причина спроса)

К условно постоянной информации относиться данные о читателе.

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

• Сведения об оставшихся книгах и журналов

• Сведения об отпущенных на руки книгах и журналах

Рисунок 8. Читательский билет

Рис.9. Вкладыш в читательский билет

2.3. Характеристика результатной информации

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

Рисунок 10. Контекстная диаграмма ИС

Диаграмма состоит из следующих составляющих:

1.Входные потоки:

•Данные о читателях (Код абонента, ФИО, читательский билет)

•Данные о книгах (Код книги, название книги, автор, издание, номер стеллажа)

2.Управляющие потоки:

•Законодательство РФ (ГОСТы, законы, указы, постановления и т.д.)

•Методика формирования статистики посещения библиотеки читателем (Правила, формулы)

•Методика подсчёта рейтинга книг (Формулы, рейтинг у читателей)

3.Ресурсные потоки:

•Библиотекарь (Сотрудник библиотеки)

•База данных библиотеки (Информация о книгах, журналах)

4.Выходные потоки:

•Статистика посещения читателем библиотеки (Информация о посещении может быть выдана в виде графика или таблицы)

•Рейтинг (Информация о рейтинге может быть выдана в виде графика или таблицы

Далее необходимо провести функциональную декомпозицию системы. Разбиение представлено на рисунке 11.

Рисунок 11. Диаграмма декомпозиции

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

1. Управление личными карточками читателя

Входные данные получаем из входных потоков, а именно, «Данные о читателях». На основе данных документов заполняются соответствующие поля в личной карточке читателя (Код абонента, ФИО, читательский билет). Эти данные заносит непосредственно библиотекарь, а также заносит данные о том, когда, насколько и какая книга\журнал были выданы.

Соответственно ввод, удаление или редактирование данных о читателя осуществляется в базе данных библиотеки.

Данный блок курируется законодательством РФ (ГОСТы, законы, указы, постановления и т.д.)

  1. Управление книгами

В базе данных, в соответствующие поля вводятся данные о поступивших книгах: код книги, название книги, автор, издание, номер стеллажа. Ввод осуществляет библиотекарь. Данный блок курируется законодательством РФ (ГОСТы, законы, указы, постановления и т.д.)

  1. Выдача книг

Выдача осуществляется непосредственно самим сотрудником библиотеки. При выдаче необходимо в базе данных указать: код выдачи, код абонента, код книги отделения, дата взятия, дата возврата. Данный блок курируется законодательством РФ (ГОСТы, законы, указы, постановления и т.д.)

  1. Получение рейтинга книг

Рейтинг составляется на основе популярности книги у читателей.

Данные берутся базы данных и анализируются сотрудником библиотеки или автоматически. Подсчёт статистики ведётся в рамках законодательства РФ.

  1. Получение статистики посещения

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

2.4. Общие положения (дерево функций и сценарий диалога)

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

Выделяется два подмножества функций программы (рисунок 12):

- справочная информация (абонемент, отделение, книга и др.)

- запросы (книги у абонента, книги в отделении, дата возврата книг)

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

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

Рисунок 12. Дерево функций

2.5. Характеристика базы данных

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

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

Между сущностями «Книги» и «Экземпляры» существует связь (1:М), обязательная с двух сторон. Каждая книга может присутствовать в библиотеке в нескольких экземплярах, поэтому — связь 1:М. При этом если в библиотеке нет ни одного экземпляра данной книги, то мы не будем хранить ее описание, поэтому если книга описана в сущности «Книги», то по крайней мере один экземпляр этой книги присутствует в библиотеке. Это означает, что со стороны книги связь обязательная. Что касается сущности «Экземпляры», то не может существовать в библиотеке ни одного экземпляра, который бы не относился к конкретной книге, поэтому и со стороны «Экземпляры» связь тоже обязательная.

Теперь необходимо определить, как в системе будет представлен читатель. Естественно предложить ввести для этого сущность «Читатели», каждый экземпляр которой будет соответствовать конкретному читателю. В библиотеке каждому читателю присваивается уникальный номер читательского билета, который однозначно идентифицирует читателя. Номер читательского билета будет ключевым атрибутом сущности «Читатели». Кроме того, в сущности «Читатели» должны присутствовать дополнительные атрибуты, которые требуются для решения поставленных задач; этими атрибутами будут: «Фамилия Имя Отчество», «Адрес читателя», «Телефон домашний» и «Телефон рабочий». Кроме того, в сущности «Читатели» следует ввести атрибут «Дата рождения», который позволит контролировать возраст читателей.

Каждый читатель может держать на руках несколько экземпляров книг. Для отражения этой ситуации следует провести связь между сущностями «Читатели» и «Экземпляры», т. к. читатель берет из библиотеки конкретный экземпляр конкретной книги, а не просто книгу. А узнать, какая книга у данного читателя можно по дополнительной связи между сущностями «Экземпляры» и «Книги», и эта связь каждому экземпляру ставит в соответствие одну книгу, поэтому всегда можно однозначно определить, какие книги находятся на руках у читателя, хотя связываем с читателем только инвентарные номера взятых книг. Между сущностями «Читатели» и «Экземпляры» установлена связь 1:М, и при этом она не обязательная с двух сторон. Читатель в данный момент может не держать ни одной книги на руках, а с другой стороны, данный экземпляр книги может не находиться ни у одного читателя, а просто стоять на полке в библиотеке.

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

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

ER-модель предметной области «Библиотека» представлена на рисунке. 13.

Рисунок 13. ER-модель предметной области «Библиотека»

2.6. Структурная схема пакета (дерево вызова программных модулей)


Выделим 3 группы программных модулей системы (рисунок 14):

1. Управляющие модули – выполняющие функции по управлению объектами системы

2. Функциональные модули – позволяющие обеспечить ввод и обработку данных

3. Сервисные модули – обеспечивающие дополнительные сервисы

Рисунок 14. Дерево вызова программных модулей

2.7 Описание программных модулей

В таблице 7 приведено описание функций основных программных модулей.

Таблица 7

Описание функций основных программных модулей

Наименование модуля

Функции модуля

1


Модуль безопасности

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

2

Модуль инициализации интерфейса программы

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

3

Модуль управления деревом объектов

Содержит процедуры и функции, позволяющие управлять отображением дерева объектов и его элементами

4

Модуль взаимодействия с базой данных

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

5

Модуль справочной системы

Содержит процедуры и функции, необходимые для отображения справочной информации

6

Модуль «Справочники»

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

7

Модуль ввода данных «Заявки»

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

8

Модуль «Отчеты»

Содержит процедуры и функции для просмотра типовых отчетов и создания произвольного отчета

9

Модуль «Печать документов»

Обеспечивает предварительный просмотр, настройку параметров документов и печать на принтере

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

2.8. Контрольный пример реализации проекта и его описание

Клиентское приложение написано по следующей схеме:

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

1.Справочная информация (таблицы с данными)

2.Запросы

•Следующие формы содержат в себе, непосредственно информацию (справочную или запросы).

Управляющий элемент «Справочная информация» содержит в себе 5 форм:

•Абонемент

Позволяет просматривать списки абонементов, а также вносить, редактировать или удалять информацию (рисунок 15).

Рисунок 15. Пункт меню абонемент

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

Рисунок 16. Пункт меню «Отделение»

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

Рисунок 17. Пункт меню «Книга»

•Выдача (рисунок 18) Позволяет просматривать информацию

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

Рисунок 18. Пункт меню «Выдача»

•Каталог (рисунок 19) Позволяет просматривать весь каталог библиотеки, а также вносить, редактировать или удалять информацию. При заполнении поля «Название книги» и «Отделение» можно осуществить подбор названия книг и название отделения. Это очень удобно при вводе новой записи.

Рисунок 19. Пункт меню «каталог»

Управляющий элемент «Запросы» содержит в себе 3 формы (рисунок 20):

Рисунок 20. Управляющий элемент «Запросы»

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

Каждый бизнес-процесс (функция) должен быть реализован в отдельном модуле на отдельной форме.

Заключение

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

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

Дана характеристика и описание входной и результативной информации, а

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

Разработан сценарий диалога (дерево вызова модулей). Созданный проект

позволит избавиться от большой бумажной работы, хранить информацию в

электронном виде, позволит эффективно вести учёт по приёмке, отпуску и

движению книг или журналов в библиотеке, повысить производительность

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

серьёзных знаний от пользователя, это делает всё взаимодействие с ним

простым и удобным.

Список литературы

1. Владимир Грекул, Нина Коровкина, Юрий Куприянов. Проектное управление в сфере информационных технологий. – М.:БИНОМ, ИНФРА-М, 2013

2. Ричард Ньютон. Управление проектами от А до Я. – М.: Альпина Паблишер, 2014

3. В.Г. Елиферов, В.В. Репин. Процессный подход к управлению. Моделирование бизнес-процессов. – М.:Манн, Иванов и Фербер, 2013

5. Крышкин, О. Настольная книга по внутреннему аудиту: Риски и бизнес-процессы. / О. Крышкин. - М.: Альпина Паблишер, 2016. - 477 c.
6. Михеев, А.Г. Системы управления бизнес-процессами и административными регламентами на примере свободной программы RunaWFE. / А.Г. Михеев. - М.: ДМК, 2016. - 336 c.
7. Нелис, Й. Управление бизнес-процессами: Практическое руководство по успешной реализации проектов / Й. Нелис, Д. Джестон. - СПб.: Символ-плюс, 2015.
8. Репин, В.В. Бизнес-процессы. Моделирование, внедрение, управление / В.В. Репин. - М.: Манн, Иванов и Фербер, 2013. - 512 c.
9. Репин, В.В. Процессный подход к управлению. Моделирование бизнес-процессов / В.В. Репин. - М.: Манн, Иванов и Фербер, 2013. - 544 c.
10. Ротер, М. Учитесь видеть бизнес-процессы: Построение карт потоков создания ценности / М. Ротер. - М.: Альпина Паблишер, 2015. - 136 c.
11. Рудакова, О.С. Реинжиниринг бизнес-процессов: Учебное пособие для студентов вузов, обучающихся по специальностям экономики и управления / О.С. Рудакова. - М.: ЮНИТИ-ДАНА, 2013. - 343 c.
12. Тельнов, Ю.Ф. Инжиниринг предприятия и управление бизнес-процессами. Методология и технология: Учебное пособие / Ю.Ф. Тельнов, И.Г. Фёдоров. - М.: ЮНИТИ, 2015. - 176 c.
13. Хаммер, М. Быстрее, лучше, дешевле: Девять методов реинжиниринга бизнес-процессов / М. Хаммер. - М.: Альпина Пабл., 2012. - 356 c.
14. Чукарин, А.В. Бизнес-процессы и информационные технологии в управлении современной инфокоммуникационной компанией / А.В. Чукарин. - М.: Альпина Паблишер, 2016. - 512 c.
15. Ширяев, В.И. Управление бизнес-процессами: Учебно-методическое пособие / В.И. Ширяев, Е.В. Ширяев. - М.: Финансы и статистика, 2014. - 464 c.

16. Варзунов А. В., Торосян Е. К., Сажнева Л. П., Анализ и управление бизнеспроцессами // Учебное пособие. – СПб: Университет ИТМО, 2016. –112 с.

17. Управление бизнес-процессами предприятия : учебное пособие / сост. Е. В. Пирогова. – Ульяновск : УлГТУ, 2017. – 107 с.

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

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

20. Маклаков С. В. Создание информационных систем с AllFusion Modeling Suite. – 2-е изд., доп. – М.: Издательство Диалог-МИФИ, 2007 – 400 с.

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

22. Уткин В. Б. Информационные системы в экономике: Учебник для студ. высш. учеб, заведений / В. Б. Уткин, К. В. Балдин. — М.: Издательский центр «Академия», 2004. — 288 с., Глава 2.

23. Вендров А. М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. Пособие. – М.: Финансы и статистика, 2006.