Проектирование информационной системы АО «Костанайтранстелеком»

СОДЕРЖАНИЕ

ВВЕДЕНИЕ 6

1 Теоретические аспекты проектирования информационных систем 8

1.1 Схемы разработки проекта 8

1.2 Методы проектирования информационных систем 22

1.3 Основные понятия электронного документооборота 27

2 Проектирование информационной системы 35

2.1 Описание предприятия 35

2.2Выбор среды программирования 37

2.3 Описание пользовательского интерфейса 42

2.4 Описание пользовательского интерфейса 46

ЗАКЛЮЧЕНИЕ 58

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

ВВЕДЕНИЕ

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

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

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

Проектирование информационных систем охватывает три основные области:

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

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

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

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

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

Цель работы. На основании анализа проектирования информационных систем спроектировать информационную систему управления предприятием «Отдел кадров».

В соответствии с поставленной целью необходимо решить ряд задач, а именно:

• провести анализ создания информационных систем и ведение электронного документооборота на предприятии;
• занесение в базу данных и удаление информации о сотрудниках АО «Костанайтранстелеком»;
• отображение информации о кадровой истории сотрудника;
• редактирование информации в базе данных;
• составление отчетов;
• быстрый поиск необходимой информации о сотруднике.

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

Предмет исследования – автоматизация процессов ведения документации отдела кадров на предприятии АО «Костанайтранстелеком» посредством программного обеспечения.

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

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

1 Теоретические аспекты проектирования информационных систем

1.1 Схемы разработки проекта

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

Известны следующие модели жизненного цикла:

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

Поэтапная модель с промежуточным контролем. Разработка ПО ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют уменьшить трудоемкость процесса разработки по сравнению с каскадной моделью; время жизни каждого из этапов растягивается на весь период разработки [1].

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

«Водопад» - схема разработки проекта

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

Рисунок 1. Схема «водопада».

Стратегия

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

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

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

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

В документе обязательно должны быть описаны:

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

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

Следует отметить, что и на этапе выбора стратегии, и на этапе анализа, и при проектировании независимо от метода, применяемого при разработке проекта, всегда следует классифицировать планируемые функции системы по степени важности. Один из возможных форматов представления такой классификации - MoSCoW - предложен в Clegg, Dai and Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.

Эта аббревиатура расшифровывается так: Must have - необходимые функции; Should have - желательные функции; Could have - возможные функции; Won't have - отсутствующие функции.

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

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

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

Анализ

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

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

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

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

Двумя классическими результатами анализа являются:

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

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

Три наиболее часто применяемые методологии структурного анализа:

• диаграммы «сущность-связь» (Entity-Relationship Diagrams, ERD), которые служат для формализации информации о сущностях и их отношениях;
• диаграммы потоков данных (Data Flow Diagrams, DFD), которые служат для формализации представления функций системы;
• диаграммы переходов состояний (State Transition Diagrams, STD), которые отражают поведение системы, зависящее от времени; диаграммы жизненных циклов сущностей относятся именно к этому классу диаграмм.

ER-диаграммы

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

Рисунок 2. Пример ER-диаграммы.

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

Отношение изображается линией между двумя сущностями.

Рисунок 3. Элемент ER-диаграммы.

Одиночная линия справа (рисунок3) означает «один», «птичья лапка» слева – «многие», а отношение читается вдоль линии, например «один ко многим». Вертикальная черта означает «обязательно», кружок - «не обязательно», например, для каждого издания в TITLE обязательно должен быть указан издатель в PUBLISHERS, а один издатель в PUBLISHERS может выпускать несколько наименований изданий в TITLES. Следует отметить, что связи всегда комментируются (надпись на линии, изображающей связь).

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

Рисунок 4. ER-диаграмма рефлексивного отношения.

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

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

Дуги

Если сущность имеет набор взаимоисключающих отношений с другими сущностями, то говорят, что такие отношения находятся в дуге. Например, банковский счет может быть оформлен или для юридического лица, или для физического лица [3, с.20]. Фрагмент ER-диаграммы для такого типа отношений приведен на рисунок 5.

Рисунок 5. Дуга.

В этом случае атрибут ВЛАДЕЛЕЦ сущности СЧЕТ имеет особое значение для данной сущности - сущность делится на типы по категориям: «для физического лица» и «для юридического лица». Полученные в результате сущности называют подтипами, а исходная сущность становится супертипом. Чтобы понять, нужен супертип или нет, надо установить, сколько одинаковых свойств имеют различные подтипы. Следует отметить, что злоупотребление подтипами и супертипами является довольно распространенной ошибкой. Изображают их так, как показано на рисунок 6.

Рисунок 6. Подтипы (справа) и супертип (слева).

Нормализация

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

Рисунок 7. Связи «один к одному».

Допустимые типы связей [3, с 30]. При ближайшем рассмотрении связи типа «один к одному» (рисунок 7) почти всегда оказывается, что A и B представляют собой в действительности разные подмножества одного и того же предмета или разные точки зрения на него, просто имеющие отличные имена и по-разному описанные связи и атрибуты.

Рисунок 8. Связи «многие к одному»

Связи «многие к одному» представлены на рисунке 8.

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

II - это наиболее часто встречающаяся форма связи. Она предполагает, что каждое и любое вхождение сущности A может существовать только в контексте одного (и только одного) вхождения сущности B. В свою очередь, вхождения B могут существовать как в связи с вхождениями A, так и без нее.

III - применяется редко. Как A, так и B могут существовать без связи между ними.

Связи «многие ко многим» представлены на рисунке 9.

Рисунок 9. Связи «многие ко многим».

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

II - применяется редко. Такие связи всегда подлежат дальнейшей детализации.

Рассмотрим теперь рекурсивные связи (рисунок10).

Рисунок 10. Рекурсивные связи.

I - редко, но имеет место. Отражает связи альтернативного типа.

II - достаточно часто применяется для описания иерархий с любым числом уровней.

III - имеет место на ранних этапах. Часто отражает структуру «перечня материалов» (взаимная вложенность компонентов). Пример: каждый КОМПОНЕНТ может состоять из одного и более (других) КОМПОНЕНТОВ и каждый КОМПОНЕНТ может использоваться в одном и более (других) КОМПОНЕНТОВ.

Недопустимые типы связей. К недопустимым типам связей относятся следующие: обязательная связь «многие ко многим» (рисунок11) и ряд рекурсивных связей (рисунок12).

Рисунок 11. Недопустимые связи «многие ко многим».

Рисунок 12. Недопустимые рекурсивные связи.

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

Диаграммы потоков данных

Логическая DFD (рисунок 13) показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицирует хранилища (накопители) данных, к которым осуществляется доступ [3, с 36].

Рисунок 13. Пример DFD.

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

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

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

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

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

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

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

Диаграммы изменения состояний STD

Жизненный цикл сущности относится к классу STD-диаграмм (рисунок 14).

Рисунок 14. Пример диаграммы жизненного цикла.

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

Существует несколько различных вариантов изображения подобных диаграмм, на рисунке приведен лишь один из них [3, с 50].

Некоторые принципы проверки качества и полноты информационной модели (источник - Richard Barker, Case Method: Entity Relationship Modelling, Addison-Wesley, 1990)

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

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

Качество сущностей

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

Список проверочных вопросов для сущности:

Отражает ли имя сущности суть данного объекта?

Нет ли пересечения с другими сущностями?

Имеются ли хотя бы два атрибута?

Всего атрибутов не более восьми?

Есть ли синонимы/омонимы данной сущности?

Сущность определена полностью?

Есть ли уникальный идентификатор?

Имеется ли хотя бы одна связь?

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

Ведется ли история изменений?

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

Нет ли такой же сущности в другой прикладной системе, возможно, под другим именем?

Не имеет ли сущность слишком общий смысл?

Достаточен ли уровень обобщения, воплощенный в ней?

Список проверочных вопросов для подтипа:

Отсутствуют ли пересечения с другими подтипами?

Имеет ли подтип какие-нибудь атрибуты и/или связи?

Имеют ли они все свои собственные уникальные идентификаторы или наследуют один на всех от супертипа?

Имеется ли исчерпывающий набор подтипов?

Не является ли подтип примером вхождения сущности?

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

Качество атрибутов

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

Список проверочных вопросов для атрибута:

Является ли наименование атрибута существительным единственного числа, отражающим суть обозначаемого атрибутом свойства?

Не включает ли в себя наименование атрибута имя сущности (этого быть не должно)?

Имеет ли атрибут только одно значение в каждый момент времени?

Отсутствуют ли повторяющиеся значения (или группы)?

Описаны ли формат, длина, допустимые значения, алгоритм получения и т.п.?

Не может ли этот атрибут быть пропущенной сущностью, которая пригодилась бы для другой прикладной системы (уже существующей или предполагаемой)?

Не может ли он быть пропущенной связью?

Нет ли где-нибудь ссылки на атрибут как на «особенность проекта», которая при переходе на прикладной уровень должна исчезнуть?

Есть ли необходимость в истории изменений?

Зависит ли его значение только от данной сущности?

Если значение атрибута является обязательным, всегда ли оно известно?

Есть ли необходимость в создании домена для этого и ему подобных атрибутов?

Зависит ли его значение только от какой-то части уникального идентификатора?

Зависит ли его значение от значений некоторых атрибутов, не включенных в уникальный идентификатор?

Качество связи

Нужно выяснить, отражают ли связи действительно важные отношения, наблюдаемые между сущностями.

Список проверочных вопросов для связи:

Имеется ли ее описание для каждой участвующей стороны, точно ли оно отражает содержание связи и вписывается ли в принятый синтаксис?

Участвуют ли в ней только две стороны?

Не является ли связь переносимой?

Заданы ли степень связи и обязательность для каждой стороны?

Допустима ли конструкция связи?

Не относится ли конструкция связи к редко используемым?

Не является ли она избыточной?

Не изменяется ли она с течением времени?

Если связь обязательная, всегда ли она отражает отношение к сущности, представляющей противоположную сторону?

Для исключающей связи:

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

Все ли из них относятся к одной и той же сущности?

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

Связь может покрываться только одной дугой. Так ли это?

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

Функции системы

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

Рисунок 15. Пример декомпозиции.

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

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

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

Уточнение стратегии

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

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

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

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

1.2 Методы проектирования информационных систем

Индустрия разработки автоматизированных информационных систем управления родилась в 50-х - 60-х годах и к концу века приобрела вполне законченные формы. Материалы данного руководства являются обобщением цикла лекций по Автоматизированным Банковским Системам (АБС) и Автоматизированным системам управления конструкторско-технологическим проектированием (АСУ КТП), читаемым в МГТУ им.Н.Э.Баумана. Не смотря на имеющиеся различия в реализации функциональных модулей данных систем, общие подходы к их разработки во многом схожи, что позволило нам объединить вопросы их проектирования в рамках одного издания [5].

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

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

Метод «снизу-вверх»

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

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

Метод «сверху-вниз»

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

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

Принципы «дуализма» и многокомпонентности

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

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

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

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

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

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

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

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

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

Что же заставляет банки разрабатывать предприятия и банки свои АИС собственными силами [7]:

• Во-первых, это конечно относительно низкая стоимость таких разработок (по сравнению с покупными). Как правило, к существующим подразделениям департамента информатизации, таким как: управление эксплуатации, управление эксплуатации вычислительной сети и средств связи, экспертно-аналитическое управление (постановка задач), добавляется лишь новая структура: управление развития и разработки АИС, что, как правило, не влечет за собой больших финансовых затрат.
• Во-вторых, собственная разработка - это максимальная ориентация на реализацию бизнес - процессов предприятия или банка, его уникальных финансовых и управленческих технологий, складывающихся годами.
• В третьих, это позволяет обеспечивать значительно более высокий уровень безопасности и независимости от внешних факторов.
• В четвертых, оперативная реакция на изменения правил игры на рынке.
• Вместе с тем при собственной разработке необходимо решить целый комплекс организационно-технических задач, которые позволили бы избежать ошибочных решений [8]:
• Во-первых, правильный выбор архитектуры построения вычислительно-коммуникационной сети и ориентация на профессиональные СУБД. По экспертным оценкам собственные разработки АИС в 53% базируются на СУБД Oracle, около 15% на Informix, 22% - другие СУБД.
• Во-вторых, использование при разработке современного инструментария (CASE средства, эффективные средства разработки: Delphi, Designer2000, Developer2000, SQL-Stations и т.п.).
• В третьих, мультизадачная инфраструктура разработки проекта, когда конкретный модуль АИС ведет группа разработчиков с взаимосвязанным перечнем задач, построенная на принципах полной взаимозаменяемости, т.е. функционирование данного модуля АИС и его развитие не связано с одним конкретным разработчиком.
• В четвертых, применение эффективных организационно-технических средств по управлению проектом и контролю версий АИС.

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

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

1.3 Основные понятия электронного документооборота

Документ.

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

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

Итак, документ - это совокупность трех составляющих [9]:

• Физическая регистрация информации.
• Форма представления информации
• Активизация определенной деятельности.

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

Документ [9, с. 17] - слабоструктурированная совокупность блоков или объектов информации, понятная человеку. В общем случае обойтись без документов пока нельзя. Сам по себе документ, независимо от того, обычная ли это бумага или электронный бланк, проблем корпорации не решает - первичны бизнес-процессы и четкий контроль за выполнением проекта.

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

Собственно документооборот может быть двух типов:

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

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

Итак, документ занимает определенное место в процессе некоторой деятельности на границе разделяемых функций исполнения. Поэтому правильно рассматривать документ как инструмент распределения функций между работниками [9, с 25].

Преимущества электронного документооборота

К основным преимуществам электронного документооборота можно отнести следующие:

• Полный контроль за перемещением и эволюцией документа, регламентация доступа и способ работы пользователей с различными документами и их отдельными частями.
• Уменьшение расходов на управление за счет высвобождения (на 90% и более) людских ресурсов, занятых различными видами обработки бумажных документов, снижение бюрократической волокиты за счет маршрутизированного перемещения документов и жесткого контроля за порядком и сроками прохождения документов.
• Быстрое создание новых документов из уже существующих.
• Поддержка одновременной работы многих пользователей с одним и тем же документом, предотвращение его потери или порчи.
• Сокращение времени поиска нужных документов.
• Использование АИС может рассматриваться в качестве базы для общего совершенствования управления предприятием. При этом управление предприятием реализует следующие основные функции:
• обслуживание клиентов;
• разработка продукции;
• учет и контроль за деятельностью предприятия;
• финансовое обеспечение деятельности предприятия и т.д.

Модели информационного пространства предприятия.

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

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

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

Начальным этапом создания такой системы является построение модели предметной области или другими словами модели документооборота для конкретного бизнеса и позиционировать в ней свое предприятие [10].

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

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

Рисунок 16. Трехмерное пространство свойств.

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

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

Точка в пространстве (F, D, R) определяет состояние системы документооборота и имеет координаты (f,d,r), где f,d и r принадлежат множествам F,D и R, соответственно. Положение этой точки зависит от уровня развития и стадии внедрения системы документооборота на предприятии, а также от его специфики и самих масштабов бизнеса.

Представив модель документооборота именно таким образом, можно, например, зная текущее положение дел с организацией делопроизводства на каждом конкретном предприятии, четко представить, в каких направлениях нужно двигаться дальше, чего недостает в текущий момент и каким образом органично использовать уже существующие системы автоматизации. Например, в одном из московских банков был накоплен большой массив фактографических данных, для обработки которых использовалась современная СУБД, развернутая на мощных, отказоустойчивых серверах - все, казалось бы, должно быть отлично. Однако при работе с внутренними документами наблюдалось дублирование информации: возникали ситуации, когда «никто вроде бы и не виноват», а банк время от времени лишается выгодных клиентов. Причина в том, что точка, отражающая положение системы документооборота для этой организации, имела достаточно большие координаты по оси «F» и, возможно, по оси «D», однако значение координаты по оси «R» было близко к нулю. Конкретным решением в этом случае может быть рассмотрение вопроса о внедрении системы управления регламентом. При этом не надо пока заботится о СУБД (ось «F») или электронных архивах (ось «D») - речь идет только об изменении значения координат по оси «R».

В общем случае, как уже отмечалось, процесс автоматизации делопроизводства на предприятии можно представить в виде кривой в трехмерном пространстве координат F,D,R. Причем, чем круче эта кривая, тем быстрее идет процесс модернизации, а чем больше значения всех трех координат - тем выше уровень автоматизации на корпорации и, как следствие, тем меньше у нее проблем с организацией своей собственной деятельности [11].

Работоспособна ли данная модель для задания пространства развития неавтоматизированной системы управления документооборотом. Да. Единственно, что в этом случае решается задача не облегчения рутинного труда по перемещению документов, их поиску и регистрации, а упорядочения всей системы документооборота. Новое качество, с которым сегодня ассоциируется возросший интерес к системам электронного документооборота, связано с использованием инструментальных систем, предназначенных для хранения, регистрации, поиска документов, а также для управления регламентом. Чаще ошибочно под новым качеством сегодня понимается простое внедрение отличной от ранее используемой технологии работы с документами, например локальной сети вместо дискет, переносимых с одного компьютера на другой. Вряд ли в этом случае уместно говорить о новом качестве управления предприятием. Кстати, уже упомянутый пример ручной работы режимных служб «почтовых ящиков», прекрасно вписывается в предложенную модель документооборота, а точка, отражающая его состояние, будет иметь координаты (1,1,1) - все равномерно, единственное, что отсутствует - компьютеризация.

Эволюция модели.

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

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

Рисунок 17. Эволюция бизнес - моделей документооборота.

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

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

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

На данной оси также имеются свои этапы - с определенного момента развития хранилища можно уже говорить не об индивидуальном, а о корпоративном архиве, обслуживающем деятельность рабочих групп. Точка на плоскости эволюции, достигнутой во второй фазе, характеризует систему документооборота, позволяющую отображать фактографическую информацию в виде полнотекстовых документов, имеющих необходимое количество атрибутов. Доступ к этим документам может быть осуществлен по маршруту любого уровня сложности с соблюдением различных уровней конфиденциальности. Если, например, говорить о точке «А», то соответствующее ей состояние системы документооборота позволяет осуществлять синхронизацию работы различных рабочих групп сотрудников корпорации, расположенных на различных площадках. Система для этой точки предполагает также структурирование информации по уровням управления и наличие средств репликации данных. Однако, как только речь пошла о корпорации, двумерного пространства для соответствующей ей системы документооборота опять становится недостаточно - необходим новый скачок к очередной фазе [13-15].

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

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

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

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

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

2 Проектирование информационной системы

2.1 Описание предприятия

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

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

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

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

Авторитет компании признан в Республике Казахстан и за рубежом. Получена золотая медаль «За высокое качество в деловой практике» от Международного фонда «Foundation for excellence in business practice» (Женева, Швейцария).

Филиал «Костанайтранстелеком» является одним из 13-ти филиалов АО «Транстелеком» и предоставляет услуги связи в г.Костанае, Котанайской и Акмолинской области. Общая карта сетей представлена на рисунке 18.

Рисунок 18. Карта сетей АО «Транстелеком».

Протяжённость обслуживания линии связи составляет 1560 км. Техническая база филиала «Костанайтранстелеком» состоит из 1-го крупного узла и 2-х участков связи.

«Костанайтрастелеком» оператор связи, предостовляющий широкий спектор услуг связи на территории Костанайской, Акмолинской облости и г.Костанае.

В г.Костанае, ст.Ж.Рудная, ст.Тобол, ст. Есиль компанией эксплуатируется современные электронно-цифровые АТС:

• АТС ANS Translocol Eriesson-Швеция;
• АТС-MD-110 пройзводства Eritisson-Швеция.

Эти АТС обеспечивают:

• высокое качество и надёжность связи;
• высокую скорость передачи данных при пользовании ИНТЕРНЕТ;
• возможность выхода «8», «10»,а также на сотовую связь, любых операторов связи;
• возможность переадресации входящего вызова;
• будильник;
• возможность кодирования «8» и «10» от несанкционированного использования;
• другие услуги.

Преимущества современных цифровых телефонных станции используемых АО «Транстелеком», дает следующие:

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

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

Партнеры филиала «Костанайтранстелеком»:

• Дирекция «Костанайская отделение дороги. НОД-2
• Магистральные сети. НЖС.
• АО Пассажирские перевозки.
• АО Военизированная ж/.охрана.
• АО Локомативный сервисный центр.
• АО Казтранссервис.
• АО Кедентранссервис.
• Филиал АО «Кедентранссервис»
• Компания «Жолжондеуши». ПМС.
• ТОО ТЭК Казахстан.
• ТОО «Темиржолсу-Костанай».
• ТОО «Темиржолжылу-Кушмурун».
• ТОО «Болашак».
• Госсанэпид-надзор.
• Санэпидэксперт.
• Ж/Дорожная больница.

Адрес: Республика Казахстан, 110003, г.Костанай. ул. Толстого, 135 А

Телефон: +7(7142) 90-13-77 Приемная: +7(7142) 90-06-65. Факс:+7(7142) 90-16-53.

2.2Выбор среды программирования

Delphi - это комбинация нескольких важнейших технологий:

- Высокопроизводительный компилятор в машинный код;

- Объектно-ориентированная модель компонент;

- Визуальное построение приложений из программных прототипов;

- Масштабируемые средства для построения баз данных.

Компилятор в машинный код

Компилятор, встроенный в Delphi, обеспечивает высокую производительность, необходимую для построения приложений в архитектуре «клиент-сервер». Этот компилятор быстрый, его скорость компиляции составляет свыше 120 тысяч строк в минуту на компьютере 486DX33. Он предлагает легкость разработки и короткое время проверки готового программного блока, характерного для языков четвертого поколения (4GL) и в то же время обеспечивает качество кодировки, характерное для компилятора 3GL. Кроме того, Delphi обеспечивает быструю разработку без необходимости писать вставки на Си или ручного написания кода [16].

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

Объектно-ориентированная модель программных компонент

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

В стандартную поставку Delphi входят основные объекты, которые образуют удачно подобранную иерархию из 270 базовых классов. Но если возникнет необходимость в решении какой-то специфической проблемы на Delphi, прежде чем попытаться начинать решать проблему «с нуля», то необходимо просмотреть список свободно распространяемых или коммерческих компонент, разработанных третьими фирмами. Количество этих фирм в настоящее время превышает число 250 с.

Быстрая разработка работающего приложения из прототипов

Игровая программа Rendzu была собрана из готовых кусков за рабочий день, причем большая часть времени была посвящена прихорашиванию и приукрашиванию [17].

Screen Saver в виде прыгающих часиков был также изготовлен на Delphi за весьма незначительное время. Конечно, на разработку серьезной информационно-поисковой системы в архитектуре клиент-сервер может уйти гораздо большее время, чем на разработку программы-игрушки. Среда Delphi включает в себя полный набор визуальных инструментов для скоростной разработки приложений (RAD - rapid application development), поддерживающей разработку пользовательского интерфейса и подключение к корпоративным базам данных.

VCL - библиотека визуальных компонент, включает в себя стандартные объекты построения пользовательского интерфейса, объекты управления данными, графические объекты, объекты мультимедиа, диалоги и объекты управления файлами, управление DDE и OLE. Единственное, что можно поставить в вину Delphi, это то, что готовых компонент, поставляемых Borland, могло бы быть и больше. Однако, разработки других фирм, а также свободно распространяемые программистами freeware-компоненты уже восполнили этот недостаток.

Масштабируемые средства для построения баз данных

Объекты БД в Delphi основаны на SQL и включают в себя полную функциональность Borland Database Engine. В состав Delphi также включен Borland SQL Link, поэтому доступ к СУБД Oracle, Sybase, Informix и InterBase происходит с высокой эффективностью. Кроме того, Delphi включает в себя локальный сервер Interbase для того, чтобы можно было разработать расширяемые на любые внешние SQL-сервера приложения в офлайновом режиме. Разработчик в среде Delphi, проектирующий информационную систему для локальной машины (к примеру, небольшую систему учета медицинских карточек для одного компьютера), может хранить информацию в файлах формата .dbf (как в dBase или Clipper) или .db (Paradox). Если же он будет использовать локальный InterBase for Windows 4.0 (это локальный SQL-сервер, входящий в поставку), то его приложение безо всяких изменений будет работать и в составе большой системы с архитектурой клиент-сервер [18].

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

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

Некоторые особенности Delphi

Локальный сервер InterBase

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

Team Development Support

Средство поддержки разработки проекта в группе. Позволяет существенно облегчить управление крупными проектами. Это сделано в виде возможности подключения такого продукта как Intersolve PVCS непосредственно к среде Delphi.

Открытая компонентная архитектура

Благодаря такой архитектуре приложения, изготовленные при помощи Delphi, работают надежно и устойчиво. Delphi поддерживает использование уже существующих объектов, включая DLL, написанные на С и С++, OLE сервера, VBX, объекты, созданные при помощи Delphi. Из готовых компонент работающие приложения собираются очень быстро. Кроме того, поскольку Delphi имеет полностью объектную ориентацию, разработчики могут создавать свои повторно используемые объекты для того, чтобы уменьшить затраты на разработку [20].

Delphi предлагает разработчикам - как в составе команды, так и индивидуальным - открытую архитектуру, позволяющую добавлять компоненты, где бы они ни были изготовлены, и оперировать этими вновь введенными компонентами в визуальном построителе. Разработчики могут добавлять CASE-инструменты, кодовые генераторы, а также авторские help’ы, доступные через меню Delphi.

Two-way tools - однозначное соответствие между визуальным проектированием и классическим написанием текста программы. Это означает, что разработчик всегда может видеть код, соответствующий тому, что он построил при помощи визуальных инструментов и наоборот.

Визуальный построитель интерфейсов (Visual User-interface builder) дает возможность быстро создавать клиент - серверные приложения визуально, просто выбирая компоненты из соответствующей палитры.

Поддержка OLE 2.0, DDE и VBX

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

Инспектор объектов

Этот инструмент представляет из себя отдельное окно, где вы можете в период проектирования программы устанавливать значения свойств и событий объектов (Properties & Events).

Менеджер проектов

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

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

Компоненты доступа к базам данных и визуализации данных.

Библиотека объектов содержит набор визуальных компонент, значительно упрощающих разработку приложений для СУБД с архитектурой клиент-сервер. Объекты инкапсулируют в себя нижний уровень - Borland Database Engine.

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

Библиотека объектных Визуальных Компонент

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

Этот костяк называется Visual Component Library (VCL). В VCL есть такие стандартные элементы управления, как строки редактирования, статические элементы управления, строки редактирования со списками, списки объектов. Добавлены такие компоненты, которые ранее были доступны только в библиотеках третьих фирм: табличные элементы управления, закладки, многостраничные записные книжки.

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

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

Классы объектов построены в виде иерархии, состоящей из абстрактных, промежуточных, и готовых компонент. Разработчик может пользоваться готовыми компонентами, создавать собственные на основе абстрактных или промежуточных, а также конструировать собственные объекты [21].

Формы, модули и метод разработки

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

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

Такая синхронизация и делает Delphi two-way-инструментом, обеспечивая полное соответствие между кодом и визуальным представлением. Как только добавляется новый объект или код, Delphi устанавливает так называемую “кодовую синхронизацию” между визуальными элементами и соответствующими им кодовыми представлениями.

Делегирование: события программируются проще

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

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

Ссылки на классы

Ссылки на классы придают дополнительный уровень гибкости, необходимо динамически создавать объекты, чьи типы могут быть известны только во время выполнения кода. К примеру, ссылки на классы применяются при формировании пользователем документа из разного типа объектов, где он набирает нужные объекты из меню или палитры. Собственно, эта технология использовалась и при построении Delphi [22-30].

2.3 Описание структуры базы данных

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

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

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

Рисунок 19. Схема данных базы данных.

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

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

Таблица 1

Информация о сотрудниках

Поле	Тип	Дополнительно	Описание
TabNomer	Счетчик	Ключевое	Идентификационный номер работника присваивается автоматически, является уникальным
SurName	Текстовый	Обязательное	Фамилия работника в базе данных
FirstName	Текстовый	Обязательное	Имя работника в базе данных
OtchName	Текстовый		Отчество работника в базе данных
Birthday	Дата/время	Обязательное	Дата рождения работника
Foto	Поле объекта OLE		Объект фотография работника, формируется при добавлении информации о работнике
YdostNomer	Текстовый	Обязательное	Номер удостоверения личности, в случае если работник не является гражданином Республики Казахстан, номер паспорта
YdostVidan	Текстовый		Орган осуществлявший выдачу удостоверения личности
YdostDate	Дата/время		Дата выдачи удостоверения личности
PHH	Текстовый	Обязательное	Регистрационный номер налогоплательщика работника
Pensdogovor	Текстовый	Обязательное, Ключевое	Данные о пенсионном договоре
Sik	Текстовый	Обязательное	Социальный индивидуальный код работника
HomeTel	Текстовый		Номер домашнего телефона (в случае наличия)
SotTel	Текстовый		Номер мобильного телефона (в случае наличия)
Adress	Текстовый	Обязательное	Адрес прописки

Таблица «Obrazovan» содержит информацию о виде образовании, наименования специальности, квалификации работника, стаж работы а так же другие данные, структура таблицы представлена в таблице 2.

Таблица 2

Информация о профессиональном образовании работников

Поле	Тип	Дополнительно	Описание
TabNomer	Счетчик	Ключевое	Идентификационный номер работника присваивается автоматически, является уникальным
Obrazov	Текстовый	Обязательное	Образование которое имеет работник (неполное среднее, среднее, средне специальное, высшее)
SchollName	Текстовый		Наименование организации образования, которую окончил работник
Spez	Текстовый		Специальность, по которой обучался работник ( в случае нескольких дипломов указывается тот на основании которого принят на работу)
Kvalif	Текстовый		Присвоенная квалификация, в соответствии со специальностью
Razrad	Текстовый		Имеющийся разряд
Staz	Текстовый	Обязательное	Стаж работы в данной организации
Stazob	Текстовый	Обязательное	Общий стаж работы сотрудника
Staznepr	Текстовый	Обязательное	Непрерывный стаж работы сотрудника

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

Таблица 3

Информация о составе семьи сотрудника

Поле	Тип	Дополнительно	Описание
TabNomer	Счетчик	Ключевое	Идентификационный номер работника присваивается автоматически, является уникальным

Продолжение таблицы 3

Famsupr	Текстовый		Фамилия супруга (супруги)
Namesupr	Текстовый		Имя супруга (супруги)
Otchsupr	Текстовый		Отчество супруга (супруги)
Datesupr	Дата/время		Дата рождения супруга (супруги)
FamChild1	Текстовый		Фамилия (первого) ребенка
NameChild1	Текстовый		Имя (первого) ребенка
OtchChild1	Текстовый		Отчество (первого) ребенка
DateChild1	Дата/время		Дата рождения (первого) ребенка
FamChild2	Текстовый		Фамилия (второго) ребенка
NameChild2	Текстовый		Имя (второго) ребенка
OtchChild2	Текстовый		Отчество (второго) ребенка
DateChild2	Дата/время		Дата рождения (второго) ребенка
FamChild3	Текстовый		Фамилия (третьего) ребенка
NameChild3	Текстовый		Имя (третьего) ребенка
OtchChild3	Текстовый		Отчество (третьего) ребенка
DateChild3	Дата/время		Дата рождения (третьего) ребенка

Таблица «Dopoln» содержит служебную информации по кадровой истории сотрудника, структура таблицы представлена в таблице 4.

Таблица 4

Служебная информация отдела кадров о сотруднике

Поле	Тип	Дополнительно	Описание
TabNomer	Счетчик	Ключевое	Идентификационный номер работника присваивается автоматически, является уникальным
Dolz	Текстовый	Обязательное, ключевое	Должность работника, на которой он работает
DayPrim	Дата/время		Дата приема на работу
DayIsn	Дата/время		Дата окончания испытательного срока
DayYvol	Дата/время		Дата увольнения работника
DateNachOtp	Дата/время		Дата начала отпуска
DateOkOtp	Дата/время		Дата окончания отпуска
Osnov	Текстовый		Вид отпуска (очередной, без содержания, декретный и т.д.)

Таблица «Dolznost» содержит перечень должностей костанайского филиала АО «Трантелеком», структура таблицы представлена в таблице 5.

Таблица 5

Перечень должностей «Костанайтранстелеком»

Поле	Тип	Дополнительно	Описание
IDDolz	Счетчик		Идентификационный номер должности присваивается автоматически, является уникальным
Dolz	Тестовый	Ключевое	Наименование должности

Таблица «PensFond» перечень пенсионных фондов работающих на территории Республики Казахстан, структура таблицы представлена в таблице 6.

Таблица 6

Информация о пенсионных фондах работающих на территории Республики Казахстан

Поле	Тип	Дополнительно	Описание
IDPensdogovor	Счетчик		Идентификационный номер пенсионного фонда присваивается автоматически, является уникальным
PensDogovor	Текстовый	Ключевое	Наименование пенсионного фонда

2.4 Описание пользовательского интерфейса

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

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

Рисунок 20. Графическое представление работы программы.

Для вызова программы необходимо переместить указатель мыши последовательно по следующему меню: Пуск Программы БД Отдел кадров Otdel kadrov, либо программа запускается после двойного нажатия левой кнопки мыши на исполняемом файле Otdel kadrov.exe, расположенном в каталоге программы. После запуска программы на экран выводиться главное окно базы данных «Отдел кадров» (рисунок 21).

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

Рисунок 21. Главное окно базы данных «Отдел кадров».

Ввод данных о новом сотруднике

Для внесения данных о новом сотруднике открывается через меню «Данные» «Новый сотрудник» окно «Данные о работнике» (рисунок 22). Данное окно имеет четыре вкладки для ввода данных, такие как: «Данные о сотруднике», «Дополнительно», «Образование» и «Семейное положение».

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

Рисунок 22. Окно ввода данных о новом сотруднике, вкладка «Данные о сотруднике»

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

Вкладка «Дополнительно» (рисунок 23) служит для ввода таких данных, как: номер удостоверения личности, кем выдано, дата выдачи удостоверения, РНН, СИК, наименование пенсионного фонда, домашнего и сотового телефонов, домашнего адреса, даты начала и окончания отпуска, основания предоставления отпуска (приказ №, дата).

Рисунок 23. Окно ввода данных о новом сотруднике, вкладка «Дополнительно».

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

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

Рисунок 24. Окно ввода данных о новом сотруднике, вкладка «Образование».

Вкладка «Семейное положение» (рисунок 25) служит для ввода следующих данных: фамилии, имени, отчества супруга(и) и детей.

Рисунок 25. Окно ввода данных о новом сотруднике, вкладка «Семейное положение».

Справочник «Перечень должностей»

Для внесения данных о новой должности служит окно «Перечень должностей», которое открывается через меню «Данные» «Перечень должностей» (рисунок 26).

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

Навигатор состоит из шести кнопок используемых для управления набором данных. Кнопка Insert создает поле для ввода записи. После ввода новых данных необходимо нажать кнопку Refresh для их сохранения. Для удаления записи необходимо выделить нужную запись и нажать кнопку Delete . Кнопка Edit используется для редактирования записей. Для утверждения изменения записи используется кнопка Post . Кнопкой Cancel можно воспользоваться для отмены изменения в текущей записи.

Рисунок 26. Окно «Перечень должностей».

Справочник «Перечень пенсионных фондов»

Для внесения данных о новых пенсионных фондах служит окно «Перечень пенсионных фондов», которое открывается через меню «Данные» «Пенсионные фонды» (рисунок 27).

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

Рисунок 27. Окно «Перечень пенсионных фондов»

Поиск данных

Для поиска данных о сотрудниках служит окно «Поиск данных» (рисунок 28), которое открывается в меню «Сервис» «Поиск данных». Для осуществления поиска данных о сотруднике, в открывшемся окне необходимо ввести фамилию сотрудника и нажать на кнопку . Результаты поиска выводятся в таблицу, если в базе данных нет данных, то появиться окно, уведомляющее об этом (рисунок 29).

Рисунок 28. Окно «Поиск данных».

Рисунок 29. Окно уведомления, при отсутствии необходимых данных.

Редактирование данных

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

Рисунок 30. Окно «Редактирование данных».

Отчеты

С помощью меню «Отчеты» «Краткие данные о сотрудниках» открывается специально окно (рисунок 31), в котором выводиться личные карточки сотрудников, которые при необходимости можно вывести на печать.

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

Рисунок 31. Окно с отчетом «Краткие данные о сотрудниках».

С помощью меню «Отчеты» - «Полные данные о сотрудниках» (рисунок 32), в котором выводиться полный список личных карточек сотрудника с данными о сотруднике. Управление в данном окне производиться аналогично управлению в окне «Краткие данные о сотрудниках».

Рисунок 32. Окно с отчетом «Полные данные о сотрудниках».

Требования к системе

Программа работает на любых IBM совместимых компьютерах, под управлением операционных систем от Windows 98 до Windows 7 на которых установлены средства для работы с мультимедийными приложениями (звук, видео, графика). Размер занимаемой памяти не превышает 20 Мбайт (основная часть информации – цифровые фотографии). Программа работает как на компьютере, так и непосредственно с какого-либо носителя цифровой информации.

Минимальные требования для работы информационной системы:

- компьютер типа IBM с процессором Intel Pentium IV или выше и любые другие процессоры с равными техническими характеристиками;

- операционная система Windows 98-7;

- наличие приводов или USB концентраторов для копирования приложения на жесткий диск;

- наличие 20 Мбайт свободного пространства на жестком диске в случае копирования приложения на жесткий диск.

ЗАКЛЮЧЕНИЕ

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

• Получения информации;
• Переработка информации;
• Анализа, подготовки и принятия решения.

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

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

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

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

- занесение в базу данных, редактирование и удаление информации о сотрудниках АО «Костанайтранстелеком»;

- отображение информации о кадровой истории сотрудника;

- редактирование информации в базе данных;

- составление отчетов;

- быстрый поиск необходимой информации о сотруднике.

При написании программы была выбрана среда визуального программирования Borland Delphi 6 и база данных MS Access. В результате приложение вышло не требовательным к ресурсам компьютера и может выполняться на компьютерах с низкими техническими характеристиками, что уменьшает затраты на приобретение и модернизацию компьютера.

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Бирник А.С. Информация и управление. – М., 2007. – 240 с.
2. Введение в информационный бизнес: Учебное пособие. /Под ред. В.П.Тихомирова, А.В.Хорошилова. - М.: Финансы и статистика, 2007
3. Вычислительные машины, системы и сети. /Под ред. А.П.Пячтибратова. - М.: Финансы и статистика, 2007
4. Информационное обеспечение предпринимательской деятельности. — М.: ВИНИТИ, 2006. - 0,2 п. л.
5. Карминский А.М., Нестеров П.В. Информатизация бизнеса. – 2-е изд. - М.: Финансы и статистика, 2004
6. Свириденко С.С. Современные информационные технологии. - М.: Радио и связь, 2005
7. Титоренко Г.А. Автоматизированные информационные технологии в экономике. - М.: Компьютер, ЮНИТИ, 2005.
8. Трубилин И.Т., Семенов М.И., Лойко В.И., Барановская Т.П. Автоматизированные информационные технологии в экономике. - М.: Финансы и статистика, 2005
9. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем / В.В. Бойко, В.М. Савинков. - М. : Финансы и статистика, 1999. - 68с. Организация взаимодействия человека с техническими средствами АСУ, том 7: «Системное проектирование взаимодействия человека с техническими средствами», редакция В.Н.Четверикова, Москва, «Высшая Школа» 1993г.
10. «Рекомендации по общепользовательскому интерфейсу», Microsoft, редакция 1995г.
11. Фокс Дж. Программное обеспечение и его разработка / Пер. с англ. — М.: Мир, 1985. - 368 с., ил.
12. Леонтьев В.П. Новейшая энциклопедия персонального компьютера 2003. – М.: ОЛМА-ПРЕСС, 2003. – 920 с.: ил. ISBN 5- 224-04032-0
13. Вирт Н. Алгоритмы и структуры данных / Пер. с англ. — М.: Мир, 1989. - 360 с., ил.
14. Зелковиц М., Шоу А., Гэннон Дж. Принципы разработки программного обеспечения / Пер. с англ. — М.: Мир, 1982. — 386 с., ил.
15. Ахаян Р. Д. Эффективная работа с СУБД / Р.Д. Ахаян. - СПб. : Питер, 1997. – 284с.
16. Дейта К. Введение в системы баз данных – М: Наука,1980.-101с.
17. Александровский А.Д. Разработка корпоративных приложений. Delphi 7. М.: 2000.
18. Александровский А.Д. Delphi 7.0. Учебный курс. М.: 2001.
19. Хомоненко А. Delphi 7.0 Полное руководство. С-П.: 2002.
20. Гофман Г. Delphi 7.0 Полное руководство, С-П.: 2002.
21. Гофман Г., Хомоненко А. Работа с базами данных в Delphi. Учебный курс. С-П.: 2003.
22. Жуков А. Изучаем Delphi – С.-Пб.: Питер, 2000.- 246с.
23. Федоров А., Создание Windows-приложений в среде Delphi – С.-Пб.: Питер, 2000.-56с.
24. Безопасность жизнедеятельности, Приходько Н.Г., Алматы, 2004 г.,
25. Клещев Н.Т., Романов А.А. Проектирование информационных систем: Учебное пособие. – М.: Рос. экон. акад., 2000. 386с.
26. Delphi: полное руководство. Сухарев М - Наука и техника, 2008 г.,- 1035 с.
27. Delphi 7. Хомоненко. - БХВ - Санкт-Петербург, 2007 г., - 1216 с.
28. Delphi 2005 для Win32. Дарахвелидзе П.Г., Марков Е.П., - БХВ-Петербург, 2005 г., - 1112 с.
29. Delphi в задачах и примерах. Культин Н., - БХВ-Петербург 2008 г.
30. Дантеманн Джефф. Программирование в среде Delphi. Киев, 2005.

Проектирование информационной системы АО «Костанайтранстелеком»