Разработка информационной системы автоматизации бизнес-процессов проектной фирмы "Уралтрубопроводстройпроект"

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Введение

Данная выпускная квалификационная работа посвящена проектированию информационной системы автоматизации бизнес-процессов проектной фирмы «Уралтрубопроводстройпроект».

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

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

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

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

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

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

Таким образом, качестве объекта исследования в данной работе выступают деятельность и бизнес-процессы ПФ «УТПСП».

Предметом исследования является автоматизация и оптимизация деятельности и бизнес-процессов ПФ «УТПСП».

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

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

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

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

1. степени использования средств автоматизации:

a. ручное (традиционное проектирование);

b. методы автоматизированного проектирования (CASE-технология);

2. степени типизации проектных решений:

a. методы оригинального проектирования;

b. метлы типового проектирования;

3. степени адаптивности проектных решений к предполагаемым изменениям:

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

b. методы параметризации - изменение проектных решений в соответствии с новыми параметрами объекта проектирования;

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

Отдельное внимание стоит уделить методу автоматизированного проектирования с использованием CASE-технологий. Термин CASE (Computer Aided System Engineering) в настоящее время охватывает не только процесс автоматизации разработки программного обеспечения, но и процесс разработки сложных автоматизированных ИС в целом. За последнюю декаду появился класс программно-технологических CASE-средств, реализующих CASE-технологию создания и сопровождения автоматизированных ИС. В 70-х и 80-х гг. при разработке информационных систем стала широко применятся структурная методология анализа, которая предоставляла разработчикам строгие формализованные методы описания системы и принимаемых технических решений, а также основанная на применении наглядной графической техники для описания различного рода моделей. Наглядность и строгость средств структурного анализа позволяла участвовать в разработке системы с самого начала как разработчика так и будущим пользователям данной системы, обсуждать и закреплять понимание основных технических (проектных) решений.

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

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

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

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

Также в состав классических методологий проектирования входят методы:

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

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

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

Подходы к проектированию информационных систем.

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

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

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

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

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

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

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

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

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

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

В содержание составляющих ГОСТ 34 стандартов входят следующие:

· ГОСТ 34.003-90. «Автоматизированные системы. Термины и определения»;

· ГОСТ 34.10-01. «Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи»;

· ГОСТ 34.11-94. «Криптографическая защита информации. Функция хэширования»;

· ГОСТ 34.201-89. «Виды, комплектность и обозначение документов при создании автоматизированных систем»;

· ГОСТ 34.320-96. «Концепции и терминология для концептуальной схемы и информационной базы»;

· ГОСТ 34.321-96. «Эталонная модель управления данными»;

· ГОСТ 34.601-90. «Автоматизированные системы. Стадии создания";

· ГОСТ 34.602-89. «Техническое задание на создание автоматизированной системы»;

· ГОСТ 34.603-92. «Виды испытаний автоматизированных систем»;

· Руководящий документ РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов».

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

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

1. Стадия «Формирование требований к АС»;

a. Обследование объекта и формирование необходимости создания АС;

b. Формирования требований пользователя к АС;

c. Оформление отчета о выполненной работе;

2. Стадия «Разработка концепции АС»;

a. Изучение объекта;

b. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя;

3. Стадия «Технорабочий проект»;

a. Разработка проектных решений по системе и ее частям;

b. Разработка документации на АС и ее части;

4. Стадия «Ввод в действие»;

a. Комплектация АС поставляемыми элементами (программно-техническими комплексами, информационными изделиями);

b. Пусконаладочные работы;

c. Проведение предварительных испытаний;

d. Проведение опытной эксплуатации.

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

В главе был проведен обзор литературы по теме проектирования информационных систем. В ходе обзора были рассмотрены и описаны основные методологии и подходы к проектированию информационных систем, обозначены их достоинства и недостатки. Также в первой главе описаны метод сбора данных, основанный на использовании стандартов ГОСТ серии 34. Описаны основные моменты стандарта, необходимые для разработки информационной системы автоматизации бизнес-процессов ПФ «УТПСП».

2. Краткая характеристика ООО ПФ «Уралтрубопроводстройпроект»

Основные виды деятельности ООО ПФ «УТПСП»:

- комплексные инженерные изыскания (геодезические, геологические, грунтовые, гидрометеорологические, геофизические, экологические),

- проектирование,

- авторский надзор.

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

В настоящее время ООО ПФ «УТПСП» является одной из крупнейших проектных организаций Республики Башкортостан. Численность персонала составляет 520 человек. Предприятие проектно-ориентированное, с функциональной организационной структурой. Организационная структура фирмы, актуальная на момент прохождения практики, представлена на рисунке 1.

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Рисунок 1. Организационная структура ООО ПФ "Уралтрубопроводстройпроект"

Анализ текущего состояния бизнес-процессов ООО ПФ «Уралтрубопроводстройпроект»

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

1. Маркетинг (участие в тендере);

2. Организационная подготовка проектирования;

3. Сбор исходных данных и землеустройство;

4. Управление субподрядными работами;

5. Инженерные изыскания;

6. Проектирование;

7. Авторский надзор.

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

Рисунок 2. Схема взаимодействия процессов ООО ПФ "Уралтрубопроводстройпроект"

Процессы предприятия, в основе которых лежит творческая деятельность и изыскательные работы сотрудников практически не поддается автоматизации, так как суть этих работ заключается в создании качественно новых решений, уникальных по своему содержанию. Потенциал для автоматизации представляется лишь в повышении эффективности труда инженеров путем сокращения трудоемкости проектирования, себестоимости и затрат на моделирование. Указанные возможности реализованы в предприятии с применением лицензионного программного обеспечения AutoCAD, AutoCAD CIVIL3D, ArchiCAD, NormCAD, ГИС MapInfo Professional, GeoniCS, Credo, Model Sudio CS, Лира, ПК Гранд-Смета, программных комплексов для 3D моделирования - Autodesk Building Design Suite, Autodesk Infrastructure Design Suite, Model Studio Design CS трубопроводы, а также расчетных программ, таких как «Гидросистема», EXTRA 6, CPIPE, SCAD Office, AutoPipeProf и др.

Для производственных процессов используется система электронного документооборота и архива на базе программного продукта TDMS [10]. На данный момент осуществлена автоматизация процесса проектирования от стадии инициирования проекта ГИПом до выпуска проектно-сметной документации.

Менеджмент процессов управления в предприятии осуществляется с использованием ERP-системы на базе программного продукта «Инталев. Корпоративный менеджмент».

В рамках внедрения системы менеджмента качества в фирме определены стандарты организации и порядок проведения всех основных бизнес-процессов. Краткое последовательное изложение бизнес-процессов представлено ниже.

1. Маркетинг в фирме состоит из следующих функций и процессов:

1) Закупочные процедуры.

a. Прохождение аккредитации (предварительный отбор) потенциальных поставщиков;

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

2) Анализ документации закупочной процедуры;

3) Направление заявок и мониторинг участия организации в закупочных процедурах;

4) Оформление результатов закупочной процедуры;

5) Мониторинг и определение удовлетворенности потребителя;

6) Анализ результатов измерения.

2. Функции и процессы организационной подготовки проектирования (инициации проекта):

1) Разработка, согласование и утверждение приказа о назначении ГИП;

2) Внесение информации о проекте в информационные системы;

3) Внесение изменений и дополнений в реестр проектов;

4) Проведение запускного совещания;

5) Определение результатов запускного завещания;

6) Проведение предпроектного обследования;

a. Подготовка картографического материала района размещения объекта;

b. Разработка проекта акта выбора трассы;

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

7) Разработка и утверждение задания на сбор исходных данных;

8) Разработка и утверждение задания на проектирование

9) Разработка и утверждение графика проектно-изыскательских работ;

10) Создание рабочей среды проектно-изыскательских работ (ПИР) в СЭА TDMS:

a. Создание стадии проектирования;

b. Создание папок отделов-исполнителей;

c. Создание разделов проектно-сметной документации (ПСД);

d. Создание комплектов ПСД;

e. Назначение ответственного за разработку комплекта ПСД;

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

3. Функции и процессы сбора исходных данных и землеустройства:

1) Сбор исходных данных для определения объемов проектирования и места размещения работ;

2) Сбор исходных данных для разработки проектной документации и прохождения экспертиз;

3) Сбор исходных данных для разработки и согласования рабочей документации.

4. Управление субподрядными работами включает в себя следующие процессы:

1) Организация проведения выездных и камеральных проверок субподрядных организаций;

2) Аккредитация субподрядных организаций;

3) Повторная оценка и аккредитация субподрядных организаций;

4) Управление субподрядными работами:

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

b. Выбор субподрядной организации;

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

5. Инженерные изыскания состоят из следующих функций и процессов:

1) Разработка программы выполнения инженерных изысканий;

2) Согласование и утверждение программы выполнения инженерных изысканий;

3) Внесение изменений в программу выполнения инженерных изысканий;

4) Выполнение полевых работ:

a. Осуществление инженерно-геодезических изысканий;

b. Осуществление инженерно-геологических и инженерно-геотехнических изысканий;

c. Осуществление инженерно-экологических изысканий;

d. Осуществление инженерно-гидрометеорологических изысканий;

5) Выполнение камеральных работ.

6. Функции и процессы этапа проектирования:

1) Разработка схемы планировочной организации земельного участка, архитектурных, конструкторских и объемно-планировочных решений;

2) Разработка основных технических решений;

3) Разработка систем инженерного обеспечения;

4) Разработка специальных разделов проекта;

5) Разработка дополнительных разделов проекта;

6) Разработка сметной документации;

7) Разработка пояснительной записки и выпуск комплекта ПСД;

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

7. Авторский надзор (АН) состоит из следующих функций и процессов:

1) Инициация АН - направление заказчиком письменного запроса;

2) Разработка комплекта документации для проведения АН;

3) Заключение договора с заказчиком;

4) Проведение АН специалистами на объектах строительства:

a. Контроль квалификации и компетентности сотрудников АН;

b. Ведение журнала АН;

c. Учет и устранение несоответствий в ПСД, выявленных при проведении АН;

d. Согласование и внесение изменений в рабочую документацию.

5) Предоставление заказчику отчетности в ходе проведения АН.

Описание постановки задач исследования.

Этапы исследования:

1. Интервью.

2. Разработка функциональных требований.

3. Разработка ТЗ.

4. Согласование полученного ТЗ с постановщиком задачи.

5. Разработка пилотного проекта информационной системы.

Цель - постановка задачи проектирования ИС (найти область автоматизации), средство достижения - интервью.

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

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

Таблица 1. Интервью с начальником отдела ИТ

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

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

Автором работы было принято решение о проектировании информационной системы для автоматизации бизнес процесса авторского надзора в рамках данного исследования.

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

Информацию, которую было необходимо получить от куратора ГАН представлена в табл. 2.

Таблица 2. Интервью с куратором АН

Вопрос	Ответ
1. Что такое авторский надзор?	Авторский надзор - это контроль соблюдения в процессе строительства требований проектной и, подготовленной на ее основе, рабочей документации. Сам по себе авторский надзор является частью строительного контроля. АН осуществляется по просьбе заказчика, который вправе как привлечь самого разработчика проектной и рабочей документации, так и иное лицо. АН осуществляется, как правило, на протяжении всего периода строительства и ввода объекта в эксплуатацию. При строительстве типична ситуация, когда подрядчик необоснованно отступает от проектных решений в виду отсутствия материалов или некомпетентности специалистов. Поэтому, для достижения инвестиционного замысла, критически важное значение имеет авторский надзор. Наличие контроля со стороны проектировщика гарантирует соответствие требованиям проектной и нормативной документации. Отступления бывают обоснованные. В этом случае надзор позволяет оперативно и квалифицированно внести изменения в проект.
2. Каковы цели авторского надзора?	Основная цель авторского надзора - это четкое соблюдение проектных решений и проведение работ в соответствии с действующими федеральными законами и нормативами технической документации, как Российской Федерации так и внутренних документов заказчика. Цель АН в строительстве - исключить необоснованные отступления от требований проектной, рабочей и сметной документации. Это дает гарантию того, что объект строительства примут в эксплуатацию, а его характеристики будут соответствовать инвестиционному замыслу.
3. Какие задачи стоят перед группой авторского надзора и как они достигаются?	Основные задачи: контроль за соответствием выполнения строительно-монтажных работ проектной и рабочей документации; своевременное решение всех технических вопросов, возникающих во время строительства; решение вопросов, связанных с внесением изменений в проектную и рабочую документацию, необходимость которых выявилась в процессе строительства.
4. Как сейчас организован процесс авторского надзора? Какие стадии существуют в процессе, если они есть?	АН наступает после подписания договорных отношений между заказчиком и исполнителем или после получения гарантийного письма. На основе договора составляется график выездов специалистов. Данный график может быть плавающим, т.е. в процессе строительства заказчик направляет письмо о необходимости выезда специалиста. Перед выездом определяется специалист для осуществления АН. Перед выездом специалист готовит все соответствующие документы, ознакомляется с проектом. Осуществляется выезд на объект строительства, где специалист непосредственно работает как с куратором от заказчика, так и с куратором от строительной организации, где они совместно решают все назревшие вопросы, а так же выполняет свою основную задачу - контроль проектных решений. В ходе проведения АН на выезде специалист вносит записи о наличии или отсутствии отступлений от рабочей документации в журнал авторского надзора. По итогу выезда специалист создает отчеты по шаблонам: авансовый и надзорный. Каждый назначенный специалист должен пройти контроль знаний рабочей документации. Контроль проводится ГИПом проекта до отъезда сотрудника. По итогам проверки составляется протокол знаний.
5. Каковы роли сотрудников и их функции в процессе авторского надзора?	Основные функции сотрудников: проведение АН, участие в освидетельствовании скрытых работ, геодезической разбивочной основы, согласование совместно с заказчиком изменений проектных решений, материалов, участие в выборочном контроле проверки качества и соблюдения технологических решений, ведение журнала авторского надзора, внесение в журнал замечаний и контроль последующего их устранения, решение вопросов, связанных с внесением в рабочую документацию, участие в приемке объекта в эксплуатацию, решение всех технических вопросов в процессе строительства. В процессе основную роль играют специалисты, выезжающие на объект. Также в процессе принимает участие ГИП проекта, который создает стадию авторского надзора в системе и оповещает об этом куратора группы. Куратор АН оставляет договор с заказчиком, планирует выезды (график АН) и согласует их с заказчиком, формирует состав группы АН и создает приказ о назначении специалистов. Сотрудники отдела делопроизводства ведут регистрацию корреспонденции и приказов по проектам.
6. В чем на Ваш взгляд недостатки нынешней ситуации, и как ее можно исправить?	Основные недостатки: - трудное взаимопонимание АН и разработчика документации. Решение: совещание для уточнение критических ошибок с разработчиками. - программное обеспечение и оборудование для проведения АН. Решение: внедрение средств, покупка планшетов. - мобильность АН - объекты могут находиться далеко от крупных городов. Решение: найм водителя. - мало времени для специалиста для ознакомления с документацией. Решение: заранее согласовывать выезды с заказчиком, что очень затруднительно. - трудности при чтении чертежей на бумажном носителе. Решение: разработка 3D модели.
7. Каким образом взаимодействует ГАН с другими отделами предприятия?	Специалист в сотрудничает с другими специалистами предприятия в основном методом мобильной связи, электронной почты, где посредством графики и фотографий точнее передается вопрос и проблемная ситуация.
8. Какие программные продукты используются в подразделении и для каких целей?	Используются AutoCad, Adobe Acrobat, MS Word для чтения документов.
9. Какие функции на данный момент автоматизированы, а какие - нет. И что по Вашему мнению может быть автоматизировано?	Автоматизированных функций нет, все делается в ручную. Начиная от оформления документов на командировку к заказчику до создания отчета по авторскому надзору. Почти все функции поддаются автоматизации, кроме самих выездов.

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

Процесс авторского надзора «как есть»

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

Авторский надзор осуществляется группой авторского надзора, которая входит в состав департамента технологического проектирования №3 ООО ПФ «УТПСП». Организационная структура отдела представлена на рис. 3.

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Рисунок 3. Организационная структура ДТП №3

Схема процесса авторского надзора «как есть» представлена на схеме в нотации IDEF0 (рис. 4-6).

Рисунок 4. Блок "Авторский надзор"



Рисунок 5. Декомпозиция блока "Авторский надзор"

Рисунок 6. Декомпозиция блока "Осуществление выездов"

Главный инженер проекта (ГИП) оповещает куратора - сотрудника, ответственного за авторский надзор (АН), по корпоративной почте или лично о том, что проект перешел на стадию АН.

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

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

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

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

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

По итогам проведения авторского надзора составляются отчеты: авансовый и надзорный.

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

Обоснование необходимости автоматизирования процесса авторского надзора.

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

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

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

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

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

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

Требования к функциям (задачам) системы.

В функции и задачи системы автоматизации авторского надзора входят:

1. Централизованное хранение исходящей и входящей корреспонденции по проекту на стадии авторского надзора;

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

3. Создание плана выездов специалистов и учет фактических выездов.

4. Автоматическое заполнение части данных документов;

5. Автоматическое формирование Word-документов.

Процесс авторского надзора «как должно быть».

На рис. 8-10 изображены схемы процесса авторского надзора «как должно быть». В отличие от схем «как есть», данные схемы отличаются наличием новых элементов управления и исполнения («Инструкции к TDMS» и «TDMS»).



Рисунок 8. Блок "Авторский надзор"

Рисунок 9. Декомпозиция блока "Авторский надзор"

Рисунок 10. Декомпозиция блока "Осуществление выездов"

Выбор системы электронного архива и документооборота TDMS.

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

Далее, если раскрыть «Объекты», а в нем - «Объекты проектирования», то мы увидим список объектов предприятия, по которым ведутся работы. В окне справа от дерева объектов располагается «Окно состава» выделенного объекта, а в окне «Свойства» находятся данные о проекте. Так объект «0035 - ГРС Наумовка» содержит в себе типовые объекты проекта и типовые папки стадий, которые создает ГИП для каждого проекта.

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

СЭАД TDMS (Technical Data Management System) - это система, разработанная компанией Consistent Software SPb/Бюро ESG и предназначенная для управления информационными потоками и электронной документацией проектных, конструкторских, производственных организаций и любых других предприятий, в работе которых используются технические данные и создаваемые на их основе документы: чертежи, планы, схемы, спецификации, ведомости и т.п.

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

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

Система TDMS - клиент-серверное приложение. В качестве системы управления базами данных TDMS используется Microsoft SQL Server 2008 R2. программный серверный код

В TDMS встроен внутренний язык программирования TDMScript, основанный на Microsoft Visual Basic Scripting Edition и дополненный множеством свойств, методов и событий системы. TDMScript - простой в изучении и использовании язык программирования, который позволяет администратору TDMS описывать поведение системы, а также, в соответствии с требованиями и правами доступа, создавать команды по работе с информационными объектами и программировать различные события, практически безгранично расширяя функционал TDMS.

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

Так, система обеспечивает удобство при работе с файлами произвольных форматов за счет неограниченного количества встраиваемых средств просмотра и прямых интерфейсов с популярными приложениями, такими как Microsoft Word, Microsoft Excel, Microsoft Project, Microsoft Outlook и AutoCAD.

Таким образом, СЭАД TDMS обладает гибким и удобным инструментарием, позволяющим пользователю создавать собственные типы объектов, задавать и модифицировать их атрибуты.

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

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

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

Нотация eEPC

Для моделирования процесса используется нотация eEPC (extended event-driven process chain - расширенное описание событийной цепочки процессов), которая представляет процесс в виде последовательности событий и функций. В дословном переводе раскрывается основное предназначение нотации: описание цепочки бизнес-процессов.

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

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

Таким образом, в настоящем описании будут представлены следующие элементы:

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

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

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

· Статус объекта системы (синий прямоугольник) - этап жизненного цикла объекта информационной системы.

· Исполнитель команды/процесса (желтый овал) - лицо или отдел, исполняющие процесс или отдающие команду.

Используемые справочники.

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

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

· Организация.

· Контрагент.

· Отделы.

· Сотрудники.

Допускается наличие в системе других справочников.

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

Роли.

Ролями в системе разграничиваются права на объекты системы. Разным ролям доступны разные списки команд.

· Куратор.

· Руководитель группы АН.

· Сотрудник группы АН.

· ГИП.

· Сотрудник отдела делопроизводства.

· Остальные пользователи.

Права доступа.

· Куратор - смена статуса стадии АН, просмотр писем, создание приказов, графика АН, выездов, журнала АН, просмотр документов выезда;

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

· Сотрудник группы АН - просмотр писем, акта, табеля, отчетов по выезду, заявления и служебного задания на командировку;

· ГИП - создание стадии АН, просмотри писем, создание протокола знаний, просмотр документов выезда;

· Сотрудник ОД - импорт файлов приказов, просмотр стадии и документов;

· Остальные пользователи - просмотр стадии и документов.

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

Описание объектов системы.

В системе TDMS ГИП создает в проекте стадию «Авторский надзор». Жизненный цикл стадии представлен на рисунке 11.

Рисунок 11. Жизненный цикл объекта "Авторский надзор"

Жизненный цикл, изображенный на рисунке, был определен исходя из интервью с пользователями системы и анализа процесса, На рисунке показана последовательность событий, процессов, команд, выполняемых пользователями, и статусов объекта. Каждая команда изменяет статус объекта «Авторский надзор».

В таблице 3 приведено соответствие статусов объекта «Авторский надзор» и доступных команд над данным объектом.

Таблица 3. Соответствие статусов объекта "Авторский надзор" и доступных команд над объектом

Статус объекта «Авторский надзор»	Доступные команды
«стадия инициирована»	«Стадия в разработке»
«стадия в разработке»	«Закрыть стадию»
«стадия закрыта»	Нет доступных команд

При создании стадии ГИПом объект «Авторский надзор» автоматически приобретает статус «стадия инициирована». При статусе объекта «стадия инициирована» в контекстном меню объекта «Авторский надзор» доступна команда «Стадия в разработке», по которой меняется статус данного объекта на статус «стадия в разработке». При статусе объекта «стадия в разработке» - доступна команда «Закрыть стадию», по которой меняется статус объекта «Авторский надзор» на статус «стадия закрыта». При статусе «стадия закрыта», доступные команды отсутствуют.

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



Рисунок 12. Дерево объектов системы стадии "Авторский надзор"

Дерево объектов представляет собой иерархию объектов в стадии «Авторский надзор», которая была разработана на основе анализа процесса и интервью с пользователями системы. При инициировании ГИПом стадии «Авторский надзор» автоматически создаются объекты «Корреспонденция АН», «Приказ АН», «График АН», «Протоколы знаний», «Журнал АН», «Отчет АН».

Атрибуты объекта «Авторский надзор» представлены в таблице 4.

Таблица 4. Атрибуты объекта "Авторский надзор"

Названия атрибута	Тип	Значение
Название стадии	строка	Авторский надзор
Наименование проекта	ссылка на проект	Наименование проекта
Плановый срок сдачи	дата	Дата
Примечание	строка	Комментарии по стадии
Окончание работ по контракту	дата	Дата окончания работ по контракту
Фактический срок сдачи	дата	Дата фактического срока сдачи работ по стадии

Описание объектов стадии.

1. Корреспонденция АН.

1.1. Объект «Корреспонденция АН» аналогичен существующему в системе объекту «Корреспонденция» и предназначен для объединения входящих и исходящих писем по проекту на стадии авторского надзора.

1.2. Данный объект представляет собой хранилище ссылок на письма по проекту, которые были зарегистрированы в системе TDMS после даты приобретения объектом «Авторский надзор» статуса «стадия в разработке». После приобретения объектом статуса «стадия закрыта» процесс занесения в состав объекта ссылок на письма прекращается.

2. Приказ АН.

2.1. Объектом «Приказ АН» является основной приказ о назначении специалистов по ведению авторского надзора.

2.2. Объект «Приказ АН» создает при инициировании стадии и автоматически приобретает статус «приказ в разработке». Жизненный цикл объекта «Приказ АН» начинается с команды куратора в системе.

Для создания приказа куратор выбирает команду контекстного меню «Создать приказ». Если объект «Приказ АН» пустой, то открывается форма создания основного приказа. Если в объекте уже хранится файл, команда создания приказа недоступна.

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

По кнопке на форме «Сформировать в Word» формируется Word-файл, и объекту «Приказ АН» выставляется статус «приказ сформирован».

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

Атрибуты объекта «Приказ АН» представлены в таблице 5.

Таблица 5. Атрибуты объекта "Приказ АН"

Название атрибута	Тип	Значение
Дата	дата	Дата создания приказа
Наименование проекта	Ссылка на объект проекта	Наименование проекта
Группа специалистов АН	Таблица	См. табл. 6
ФИО ГИПа	Ссылка на объект «ГИП»	ФИО ГИПа

Таблица 6. Атрибуты табличного атрибута "Группа специалистов АН"

Название атрибута	Тип	Значение ...

Страница:

•  1 
•  2 

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

Подобные документы

• Разработка информационной системы "Библиотека" с использованием клиент-серверной технологии

  Разработка базы данных для информационной системы "Библиотека". Системный анализ, инфологическое, даталогическое и физическое проектирование. Программирование бизнес-логики, разработка клиентского приложения. Создание web-приложения, web-доступ.
  
  курсовая работа [3,3 M], добавлен 15.09.2014
  

• Разработка информационно-аналитической системы на тему "Конкурс поэтов" с использованием технологии объектно-ориентированного программирования

  Анализ предметной области "Конкурс поэтов" на основе объектно-ориентированного подхода. Разработка оконного приложения и описание информационной модели предметной области. Описание разработанных процедур С++ и результатов тестирования приложения.
  
  курсовая работа [355,9 K], добавлен 18.06.2013
  

• Разработка информационной системы управления данными для медицинского центра СевКавГТУ, г. Ставрополь

  Назначение и цели создания информационной системы. Характеристика объекта автоматизации. Реализация информационной системы "Medic", серверной части приложения. Требования к оперативному запоминающему устройству клиента. Выходные данные программы.
  
  дипломная работа [5,1 M], добавлен 29.06.2011
  

• Автоматизация бизнес-процессов предприятия ООО "Финансовые технологии"

  Описание общих закономерностей функционирования организации. Изучение структуры предприятия, определение функций его подразделений и основных бизнес процессов. Разработка клиент-серверной системы по автоматизации получения и обработки заявок от абонентов.
  
  курсовая работа [1,8 M], добавлен 02.10.2011
  

• Разработка информационной системы АЗС с использованием клиент-серверной технологии

  Проектирование физической и логической моделей удаленной базы данных для АЗС. Разработка базы данных в СУБД Firebird с помощью утилиты IBExpert. Создание клиентского приложения для Windows с использованием клиент-серверной технологии в среде C++ Builder.
  
  курсовая работа [3,9 M], добавлен 18.01.2017
  

• Разработка информационной системы "Компьютерные комплектующие" с использованием клиент-серверной технологии

  Проектирование и разработка базы данных в РСУБД Firebird. Последовательность создания приложения, основанного на клиент-серверной технологии и работающего в операционной системе Windows. Хранимые процедуры и триггеры. Доступ к сети и транзакции.
  
  курсовая работа [2,6 M], добавлен 27.07.2013
  

• Разработка программы "Кафе" с использованием классов на языке программирования С#

  Общая характеристика объектно-ориентированного подхода в программировании, его основные свойства и принципы. Разработка программы для автоматизация деятельности кафе на основе объектно-ориентированного подхода, проектирования и реализации схемы данных.
  
  курсовая работа [1,2 M], добавлен 22.01.2012
  

• Разработка информационной системы для туристической фирмы "Шелковый путь"

  Анализ предметной области информационной системы (ИС) для туристической фирмы "Шелковый путь". Описание организации, являющейся объектом автоматизации. Разработка проекта автоматизации бизнес-процессов. Программное и техническое обеспечение (ИС).
  
  курсовая работа [1,8 M], добавлен 15.03.2017
  

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

  Анализ информационной системы салона сотовой связи. Разработка модели бизнес-процессов учебной информационной системы. Создание справочников и их заполнение, документов и их программного кода. Порядок разработки регистров, трех видов планов и отчетов.
  
  курсовая работа [1,4 M], добавлен 05.06.2013
  

• Разработка автоматизированной информационной системы "Планета животных"

  Сущность объектно-ориентированного подхода в программировании. Описание языков программирования. Использование бинарных деревьев для поиска данных, алгоритмы их обхода. Разработка Windows-приложения автоматизированной системы "Планета животных".
  
  курсовая работа [3,7 M], добавлен 16.09.2016
  

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

  Особенности реализации главных элементов разрабатываемой программы (цифровые элементы) с помощью объектно-ориентированного подхода. Применение принципа инкапсуляции для защиты данных. Конструирование классов, описание и тестирование программного продукта.
  
  курсовая работа [2,3 M], добавлен 10.05.2015
  

• Разработка информационной системы "Компьютерные комплектующие" с использованием клиент-серверной технологии

  Реляционные базы данных как часть корпоративных информационных систем, их построение по принципам клиент-серверной технологии. Основные характеристики СУБД Firebird. Проектирование базы данных для информационной системы "Компьютерные комплектующие".
  
  курсовая работа [1,9 M], добавлен 28.07.2013
  

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

  Анализ проблематики построения объектно-ориентированного канала связи. Основные понятия протокола Modbus. Возможности CodeSys для реализации объектно-ориентированного подхода. Разработка методики кроссплатформенной библиотеки для интеграции устройств.
  
  курсовая работа [38,6 K], добавлен 15.06.2013
  

• Разработка автоматизированной информационной системы "Учет заявок на ремонт и диагностику"

  Анализ входной информации и процессов, уровня автоматизации на предприятии. Выявление объекта и задачи автоматизации. Разработка концепции построения информационной модели информационной системы. Разработка структуры базы данных и клиентского приложения.
  
  дипломная работа [2,0 M], добавлен 22.11.2015
  

• Разработка и проектирование информационной системы для салона мобильной связи при помощи Microsoft Access на языке программирования Visual Basic

  Общие понятия реляционного похода к базам данных. Разработка программы для автоматизации функций руководителя салона сотовой связи. Детализация бизнес-процессов. Интерфейс для работы пользователя. Тестирование разработанной информационной системы.
  
  курсовая работа [2,2 M], добавлен 26.06.2012
  

• Разработка отказоустойчивой вычислительной системы

  Создание программного продукта на основании клиент-серверной технологии, реализующего отказоустойчивую работу системы, которая способна в случае потери связи с ведущим сервером подключить клиента к альтернативному серверу (на примере сервера погоды).
  
  курсовая работа [238,0 K], добавлен 24.08.2012
  

• Разработка программного средства автоматизации обслуживания заявок пользователей локальной вычислительной сети филиала РГУ нефти и газа имени И.М. Губкина в г. Оренбурге

  Разработка базы данных учета и хранения заявок пользователя. Создание программного средства на основе клиент/серверной технологии. Описание возможностей платформы Tandem Framework. Апробация программы автоматизации процессов подачи и обработки заявок.
  
  дипломная работа [3,6 M], добавлен 08.03.2013
  

• Проектирование информационной системы ВУЗа

  Разработка информационной системы ВУЗа с использованием методики объектно-ориентированного моделирования UML. Анализ требований к системе. Концептуальная (содержательная) модель. Диаграмма компонентов и классов. Программная реализация приложения.
  
  курсовая работа [797,7 K], добавлен 16.04.2014
  

• Разработка информационной системы детского сада с использованием клиент-серверной технологии

  Системный анализ предметной области. Выбор инструментальных средств для создания программного обеспечения. Программирование на стороне SQL-сервера. Создание клиентского Win-приложения, пользовательский интерфейс. Физическое проектирование базы данных.
  
  курсовая работа [3,7 M], добавлен 20.11.2013
  

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

  Технико-экономическая характеристика предприятия. Выбор комплекса задач автоматизации, анализ бизнес-процессов. Концептуальный уровень архитектуры базы данных, ее физическая модель. Программная реализация информационной системы для учета ремонтных работ.
  
  дипломная работа [8,8 M], добавлен 27.06.2012
  

Другие документы, подобные "Разработка информационной системы автоматизации бизнес-процессов проектной фирмы "Уралтрубопроводстройпроект""

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