Информационная система управления качеством. Создание программного обеспечения на основе библиотеки ITIL. Подсистема автоматизации процесса "Служба Service Desk"
Простые системы для отслеживания заявок. Информационные потоки, возникающие на этапе поступления запроса для решения инцидента. Концептуальная и логическая модель данных. Разработка программного обеспечения по автоматизации процесса Службы Service Desk.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 11.06.2017 |
| Размер файла | 2,6 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Министерство образования и науки Российской Федерации
Федеральное государственное бюджетное образовательное учреждение
высшего профессионального образования
«Южно-Уральский государственный университет»
(Национальный исследовательский университет)
Институт открытого и дистанционного образования
Кафедра «Экономики и инвестиций»
Информационная система управления качеством. Создание программного обеспечения на основе библиотеки ITIL. Подсистема автоматизации процесса «Служба Service Desk»
Содержание
ВВЕДЕНИЕ
1. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
1.1 Постановка задачи
1.2 Теоретические основы проектирования информационной системы
2. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ
2.1 Проектирование моделей предметной области
3. УПРАВЛЕНИЕ ПРОЕКТОМ РАЗРАБОТКИ ИС
3.1 Техническое задание
3.2 Разработка сетевого графика
3.3 Руководство пользователя
ЗАКЛЮЧЕНИЕ
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
ПРИЛОЖЕНИЕ А Листинг программ
ВВЕДЕНИЕ
В России уровень компьютеризации предприятий и организаций с каждым годом повышается, и поэтому на специалистов, которые занимаются технической поддержкой пользователей, лежит огромный объем работы. На отечественном рынке представлено большое количество систем, которые решают задачи автоматизированной технической поддержки пользователей.
Системы поддержки пользователей делятся на следующие группы.
1. Простые системы для отслеживания заявок.
2. Системы средней сложности предоставляют возможность для групповой работы, поддержки базы знаний, автоматизации действий, учета Соглашения об уровне услуг, формирования отчетных документов.
3. Комплексные решения, которые поддерживаются ITSM/ITIL, предназначены для управления процессами, разработкой программных продуктов связанными с технической поддержкой в больших организациях.
Чтобы эффективно осуществлять поддержку ИТ-услуг необходима информационная система Службы Service Desk. Service Desk это некоторая диспетчерская служба для пользователей и сотрудников ИТ-организации. Такая система должна выполнять функции «фронт-офиса» для всего предприятия.
Служба Service Desk обеспечивает единую точку контакта и для исполнителей и для руководителей, которые назначают задачи на исполнение. Даже если работы выполняются сотрудниками других ИТ-подразделений, то служба Service Desk обязана вести полный учет времени решения задачи и контролировать процесс решения, а также информировать пользователей о состоянии задачи, а руководство о задержках.
Также, Service Desk должна формировать разнообразную отчетную информацию:
1) об уровнях загруженности ресурсов;
2) производительности и эффективности предоставляемых услуг;
3) необходимости обучения клиентов и персонала;
4) совокупной стоимости услуг.
Объектом исследования является библиотека INIL, а предмет исследования - это оказание услуг технической поддержки сотрудников предприятия.
Цель выпускной квалификационной работы - автоматизация процесса Службы Service Desk.
Задачи, которые необходимо решить в соответствии с поставленной целью.
1. Дать краткую характеристику библиотеки INIL.
2. Изучить основы работы Службы Service Desk.
3. Исследовать информационные потоки, возникающие на этапе поступления запроса для решения инцидента;
4. Разработать концептуальную и логическую модели данных.
5. Разработать программное обеспечение по автоматизации процесса Службы Service Desk
В состав выпускной квалификационной работы входит введение, три главы и заключение.
Первая глава раскрывает теоретические основы проектирования информационных систем. Также в первой главе рассматриваются основные возможности службы Service Desk, структура работы и схема.
Во второй главе описываются этапы проектирования информационной системы «Служба Service Desk»:создание моделей в стандартах IDEF0, DFD, IDEF3 и IDEF1X.
В третей главе строится план-график работ по написанию ВКР и разработки информационной системы в программе MS Project. Разрабатывается техническое задание на создание информационной системы «Служба Service Desk» и руководство пользователя этой системы.
1. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
1.1 Постановка задачи
Почему был создан ITIL в целом и в частности функция Service Desk? В Великобритании, в 80 годы прошлого века, встал вопрос о повышении качества управления ИТ-обслуживанием, и по заказу правительства была создана библиотека ITIL. Ключевой частью ITIL является ITSM - концепция управления ИТ-службой, основные процессы которой нацелены не только на обеспечение бесперебойной работы ИТ-инфраструктуры, но в большей степени направлены на выполнение требований заказчика и пользователя.
Поворотным моментом для распространения библиотеки ITIL стала повсеместная компьютеризация предприятий. Все увеличивающие возможности, при использовании персональных компьютеров - от специализированных программ типа CRM или 1С, до call-центры или приема заказов через интернет - приводит к тому, что в зоне ответственности ИТ-службы оказывается большое количество объектов, сервисов и систем, которые влияют на работоспособность предприятия в целом. Служба Service Desk играет важную роль в этом деле, контролируя взаимодействие ИТ-организации с пользователями ИТ-сервисов. Именно от работы Службы Service Desk во многом зависит мнение пользователей обо всем ИТ-подразделении и в первую очередь - работоспособность всех сотрудников.
Первоначально библиотека ITIL была результатом работы Центрального агентства по вычислительной технике и телекоммуникациям при правительстве Великобритании. В апреле 2001 г. Центральное агенство было объединено с Государственной торговой палатой, которая в настоящее время является новым владельцем библиотеки ITIL.
Библиотека ITIL, принадлежащая Государственной торговой палате, состоит из нескольких доступных и детальных «Собраний практических руководств» для предоставления рациональных и эффективных ИТ-услуг.
Книги библиотеки ITIL рассматривают вопросы отдельной части структурированной процессной основы. В книгах дается описание того, что нужно для организации ИТ Сервис-менеджмента. В библиотеки ITIL определяются входные и выходные параметры процессов, цели и виды деятельности ИТ-организации.
Но, библиотека ITIL не дает точного описания способов осуществления деятельности ИТ-организации, так как они различны в каждом предприятии. Упор делается на проверенном опытным путем подходе, который реализовывается различными способами исходя из обстоятельств. Библиотека ITIL это не метод; библиотека предоставляет структурированную основу для планирования часто используемых процессов, видов и ролей деятельности, определяя связи между ними и необходимые виды коммуникации. Разработка библиотеки ITIL было вызвано необходимостью по предоставления высококачественных ИТ-услуг, уделяя особое внимание отношениям с заказчиком.
В настоящее время библиотека ITIL состоит из восьми книг:
- Service Support (Служба поддержки)
- Service Delivery Planning to Implement (Планирование оказание услуг по реализации)
- Service Management Application (Управление Услугами)
- Management ICT Infrastructure (Управление ИКТ-инфраструктурой))
- Management Security (Управление безопасностью)
- Management Software Asset (Управление Активами)
- Management The Business Perspective (Управление Бизнес-процесами)
К преимуществам библиотеки ITIL отнесятся:
- Использование проверенных и практик лучших знаний;
- IT службы являются поставщиками IT-услуг для предприятий;
- Ориентация работы IT-организаций на решение задач бизнеса;
- Определение правил и стандартов для IT-персонала;
- Деятельность IT-организации регламентируется соглашением об уровне услуг;
- Цель - обеспечение максимального качества предоставляемых пользователям IT-услуг;
- Возможность подтвердить и объяснить стоимость IT-услуг в соответствии с согласованным уровнем обслуживания
- Внедрение подходов менеджмента качества в управлении IT-сервисами;
Библиотека ITIL все время обновляется и перерабатывается, накапливая новые знания и новый опыт. В настоящее время рекомендациями и методологиями библиотеки ITIL пользуются огромное количество крупнейших предприятий, повышая эффективность управления ИТ -услугами.
В рамках выпускной квалификационной работы рассмотрим функцию Service Desk, которая играет главную роль для поддержки пользователей.
Служба Service Desk это общая точка контакта между поставщиками ИТ-услуг и пользователями в процессе каждодневного использования ИТ-услуг.
Service Desk представляет собой центр по приему запросов на обслуживание и сообщений об Инцидентах. Поэтому на Службу Service Desk возлагаются обязанности сообщать пользователям о действиях, событиях и возможностях, которые воздействуют на осуществление пользователями своей каждодневной деятельности. Службе Service Desk дается право на введения изменений, помогающие избежать инцидентов. При этом Служба Service Deck обязана действовать в рамах своих полномочий.
Служба Service Desk выполняет основные действия в ряде базовых процессов ITIL (на рисунке 1.1 представлены процессы в которых принимает участие Служба):
- Процесс Управления Инцидентами - большая часть инцидентов регистрируется Службой Service Desk и большинство обращений в Service Desk это именно по поводу инцидентов.
- Служба Service Desk отвечает за установку оборудования и программное обеспечение, а также играет не малую роль в процессах Управления Релизами или Изменениями.
- Регистрируя инциденты Служба Service Desk обязана проверить информацию о пользователе и конфигурацию его ИТ-ресурсов, а значит Service Desk участвует в Процессе Управления Конфигурациями.
- Служба Service Desk должна информировать пользователей о поддерживаемых операционных продуктах и услугах, если Service Desk не может выполнить какой- либо запрос, должен информировать Процесс Управления Уровнем Услуг о запросе.
Основная задача Службы Service Desk - это обеспечение доступа пользователей к организации предоставляющие ИТ-услуги.
Для доступа в Службу Service Desk используют различные технические средства, но самыми распространенными являются телефон и электронная почта.
Различные способы организации Службы Service Desk:
- Централизованная служба - имеет еденную точку контакта для всех пользователей.
- Локальные (распределенные) Службы, расположенные на нескольких объектах.
- Виртуальная Служба - географическое расположение не имеет значения, так как используется коммуникационные и Интернет технологии.
Рисунок 1.1 - Процессы, в которых принимает участие Служба Service Desk
Структура Service Desk представлена на рисунке 1.2. Ее ядро - это центр обработки вызовов, обеспечивающий грамотное распределение поступающих заявок. Вокруг него строится служба Help Desk, задачи которого зарегистрировать произошедший инцидент и как можно быстрее возобновить нормальную работу ИТ-сервиса самостоятельно или привлечь специалистов высокого уровня для устранения причины инцидента. Service Desk, как структурное подразделение предоставляет дополнительные услуги.
Техническая поддержка, как процесс, имеет несколько уровней.
Первый уровень -- это центральная служба технической поддержки (Служба Service Desk). Сюда обращаются все пользователи со своими проблемами, и попытка обратиться напрямую к специалистам пресекаются. Это необходимо, для того чтобы высококвалифицированные специалисты не отвлекались на решение простых задач (инцидентов).
Второй уровень поддержки -- это так называемые технические специалисты, у которых глубокие знания в определенных технических направлениях (разбирающие в работе веб-серверов или по SQL- серверу).
Третий уровень - это группа разработчиков, которая не только поддерживает программный продукт, но и может его доработать в соответствии с меняющимися запросами бизнеса.
Если инцидент переходит на очередной уровень технической поддержки (Эскалация) это значит увеличивается время и стоимость разрешения этого инциндента. Необходимо стремиться к тому, чтобы наибольшее число Инцидентов решалось на первом уровне, где специалисты имеют меньшую квалификацию.
Проанализировав работу Службы Service Desk, было принято решение автоматизировать процесс принятия заявок и распределения их по специалистам для принятия решения.
1.2 Теоретические основы проектирования информационной системы
1.2.1 Создание баз данных в MS Access
MS Access -- это система управления базами данных (СУБД) реляционного типа. MS Access, несмотря на появление новых ИТ-технологий в области управления базами данных, остается наиболее популярным продуктом в этой области. Это связано с тем, что Microsoft создавая новые версии сохраняет совместимость с предыдущими.
Несомненным достоинством MS Access является наличие простого графического интерфейса, который позволяет не только разрабатывать приложения, используя встроенные средства, но так же создавать собственную базу данных.
В отличие от других СУБД, у MS Access все данные хранятся в одном файле, хотя и распределены по разным таблицам, как и положено реляционной СУБД. К данным относится не только информация содержащая в таблицах, но и другие объекты базы данных.
Для выполнения основных операций в MS Access можно воспользоваться Мастером (Wizards), который сделает основную работу при разработке приложений и работе с данными, а также поможет избежать однотипных действий.
Особенности MS Access.
Создание многопользовательской базы данных MS Access2010 и чтобы несколько пользователей получило одновременно доступ к общей базе данных возможно в локальной сети и в сети с файловым сервером. Сеть необходима, что бы обеспечивать аппаратной и программной поддержки обмена данными между персональными компьютерами. MS Access отслеживает разграничения доступа различных пользователей к базе данных и обеспечивает защиту информации. Так как MS Access не является клиент-серверной СУБД, то возможности системы по обеспечению многопользовательской работы сильно ограничены. Для доступа к информации (данным) по сети с нескольких персональных компьютеров, файл БД MS Access имеющий расширение *.mdb, выкладывается на файловый сервер. Обработка данных ведется в на стороне клиента - там, где запущено приложение, это особенности организации файловых СУБД. Такая система ограничивает использование MS Access2010 для обеспечения работы нескольких пользователей и при больших количествах данных в таблицах, так как сильно возрастает нагрузка на сеть Кошелев, В. Е. Базы данных Access 2007 / В. Е. Кошелев. - М. : БИНОМ, 2013. - 592 с.
Целостность данных MS Access поддерживается только не сложными моделями баз данных. В таких базах отсутствуют такие средства как триггеры и хранимые процедуры, это заставляет разработчиков баз данных возлагать поддержание бизнес логики базы данных на клиентскую программу.
В MS Access нет надежных стандартных средств для защиты информации и разграничения доступа. Имеющие стандартные способы защиты легко снимаются специалистами.
Однако, несмотря на недостатки, у MS Access есть большое количество преимуществ в сравнении с системами подобного класса.
Во первых Access - это продукт компании Microsoft, программным обеспечением которой пользуется большинство пользователей персональных компьютеров. Система MS Access совместим с ОС (операционная система) Windows, которая постоянно обновляется производителем, а также поддерживает множество языков.
MS Access, имея низкую цену, предоставляет огромное количество возможностей. Также MS Access ориентирован на пользователей, которые имеют разную профессиональную подготовку, все это выражается в наличии большого количества вспомогательных средств и понятный интерфейс. Все это дает возможность легко проектировать и создавать базу данных.
В MS Access можно импортировать данные в различные форматы от текстовых файлов и таблиц Excel, до любых серверных СУБД через механизм ODBC.
Еще одно важное преимущество MS Access - это развитые встроенные средства разработки приложений. Большинство приложений, используемые пользователями, содержат тот или иной объем кода VBA (Visual Basic for Applications). Так как VBA это единственное средство для выполнения многих стандартных задач в MS Access (работа с переменными, обработка ошибок, построение команд SQL во время работы программы, использование Windows API и т. п.), для создания более-менее сложных приложений необходимо знания объектной модели MS Access.
В MS Access, одним из средств программирования является язык макрокоманд. Созданные программы на этом языке, называются макросами они позволяют связывать отдельные действия, реализуемые с помощью запросов, форм, отчетов. Макросы управляются событиями, вызываемые действиями пользователями при диалоговой работе с данными через формы и системными события.
MS Access, обладая многими чертами СУБД, предоставляет и дополнительные возможности. Это система для создания приложений работающих с базами данных, а не только простая в использовании СУБД.
Функциональные возможности MS Access
В MS Access база данных обозначает файл, который содержит набор информации. База данных в MS Access 2007 содержит следующие типы объектов (рисунок 1.3): таблица, форма, запрос, отчёт, страница, макрос, модуль Глушаков, С. В. Microsoft Access 2007 : лучший самоучитель / С. В. Глушаков, А. С. Сурядный, М. И. Шумилов. - 2-е изд., испр. и доп. - М. : АСТ, 2008. - 444 с..
отслеживание запрос информационный программный
MS Access работает одновременно только с одной базой данных. Но каждая БД MS Access включает множество таблиц, запросов, форм, отчётов, модулей и макросов, которые хранятся в файле с расширением mdb.
Таблица - это объект, соответствующий понятию «таблица» в теории реляционных баз данных. Для каждой таблицы в MS Access можно определить первичный ключ и один или несколько индексов для увеличения скорости доступа к данным Гурвиц, Г. Microsoft Access 2010. Разработка приложений на реальном примере / Г. Гурвиц. - СПб. : БХВ-Петербург, 2010. - 496 с..
В MS Access есть возможность создавать структуру таблицы в трех режимах - с помощью мастера, в режиме конструктора, и путем ввода данных. Также имеется возможность просматривать, удалять и добавлять записи, редактировать, осуществлять поиск, сортировку данных, замену, изменять вид таблицы. Связи между таблицами определяются специальным средством, которое называется «Схема данных» (рисунок 1.4).
Это удобный графический инструмент, который позволяет создавать связи между полями таблиц, устанавливать ограничения ссылочной целостности и задавать различные типы отношений. Все изменения сразу применяются в базе данных (если данные удовлетворяют выбранным условиям). Для удобства разработчика полученную диаграмму таблиц и связей можно распечатать.
Запрос - это объект, который содержит текст SQL запроса и имеет уникальное имя в разрабатываемой базе данных. Создавать запросы можно с помощью мастера, а так же в режиме конструктора. Мастер запросов предлагает выбирать имена таблиц и поля для выборки. В режиме конструктора предлагается выбрать несколько таблиц или же запросов и связать их графическим способом, а также определить поля выборки (рисунок 1.5).
Можно писать запрос вручную на языке SQL, но этот способ не очень удобный и не имеет наглядного оформления кода.
Форма - специальный объект-контейнер предназначенный для других интерфейсных компонентов (поля ввода, отображения данных и кнопки, а так же другие компоненты). На форме располагаются компоненты для ввода, просмотра, корректировки и группировки данных, в зависимости от специфики приложения. Форма создается двумя способами - в режиме конструктора, представленной на рисунке 1.6, (набор компонентов разработчик свободно размещает и задает параметры) и с помощью мастера (после выбора таблицы и стиля форма генерируется автоматически).
Отчёт - это объект, который предназначен для формирования отчетных документов, которые можно выдать на печать или включить в сводные документы другого приложения. Отчетные документы содержат результаты выборки из базы данных, в виде структурированной информации. Для создания отчетов можно воспользоваться мастером или создать в режиме конструктора (рисунок 1.7).
Страницы - это средство публикации данных в Internet или локальной сети. Создаваемая страница проектируется точно также как форма (отличаются используемые компоненты), при работе со страницей можно просматривать и изменять в базе данные. Сохранив страницы как объект в базе данных экспортируем ее в виде файла в формат HTML и тогда ее можно использовать через интернет-браузер для доступа к данным.
Макрос - это объект, который представляет собой последовательность макрокоманд для автоматизации часто выполняемых действий при работе с базой данных. Макрокоманды выбирают из имеющего списка, а разработчик задает параметры. Выполнить макрос можно или программным методом в коде или по нажатию на кнопку.
Модуль - это контейнер программного кода на VBA. Для редактирования и просмотра модуля используется оболочка Visual Basic. Программный код приложения находится в наборе модулей. Программный код имеет то же смысловое значение, как и в любом другом языке программирования Майкл Маккелви. Visual Basic 4 без проблем Под редакцией О. Рякина. М.: Восточная Книжная Компания, 1997 - 576 стр..
Выше был перечислен полный список объектов, хранящейся в базе данных MS Access.
Выбор СУБД это сложная многопараметрическая задача, которая считается важным этапом при разработке баз данных. Выбранный программный продукт должен удовлетворять как текущим, так и будущим потребностям организации и учитывать финансовые затраты на приобретение самой системы, необходимого оборудования и разработку необходимого программного обеспечения на ее основе, а также обучение сотрудников организации. Также, необходимо убедиться, что новая СУБД способна принести организации реальные выгоды.
Основополагающим фактором при выборе MS Access является использование платформы фирмы Microsoft - операционной системы Windows. Хотя MS Access применяется только под Windows, широчайшее распространение этой операционной системы не является препятствием для широкого использования.
1.2.2 Моделирование бизнес-процессов в BPwin
BPwin - это мощный инструмент для моделирования, который был разработан фирмой Computer Associates Technologies для анализа, реорганизации и документирования сложных бизнес-процессов. Созданные средствами BPwin модели позволяют документировать различные направления деятельности - действия, необходимые для принятия решений, способы их осуществления, а также требующиеся ресурсы. Отсюда формируется полная картина деятельности организации - от моделей этапов работы в небольших отделах до сложных разветвленных структур. При закупке или разработке программного обеспечения модели процессов служат отличным средством документирования потребностей, помогая тем самым обеспечить высокую эффективность вложений в сферу IT-технологий. В руках разработчиков и системных аналитиков BPwin становиться мощным средством для моделирования процессов при создании информационных систем.
Модели BPwin помогают осмыслить бизнес-процессы и оценить влияния различных событий, а также они описывают взаимодействие потоков информации и процессов на предприятии. Неэффективная или избыточная деятельность легко выявляется в процессе моделирования и, следовательно, изменяется или устраняется в соответствии с общими целями предприятия.
Внешние обстоятельства, как правило вынуждают вносить поправки в деятельность предприятия. Последствия изменений необходимо тщательно изучить и осмыслить перед тем, как система будет переделана с учетом изменений. BPwin помогает разработчику на протяжении всего цикла, и дает возможность оптимизировать бизнес-процесс, с учетом изменений.
С помощью BPwin можно сделать свою работу более эффективной.
BPwin позволяет:
Гарантировать эффективность операций и рассматривать текущие операции используя мощные инструменты моделирования.
Исключать малоэффективные операции, легко и интуитивно сопоставляя операционные изменения. Неэкономичные, неэффективные и избыточные операции можно легко выявить и, следовательно, улучшить, изменить или вовсе исключить - в соответствии с целями компании.
Совершенствовать бизнес-процессы, определяя и формулируя различные реакции на воздействия рынка.
BPwin является программным продуктом в области реализации средств CASE-технологий, позволяющий проводить моделирование, анализ и описание процессов. BPwin занимает одно из первых мест в своем сегменте рынка.
BPwin включает стандартные методологии: функциональное моделирование (IDEF0), моделирование потоков данных (DFD), а так же моделирование потоков работ (IDEF3). Каждую из этих методологий можно выполнить отдельно с помощью BPwin, но все вместе они предоставляют цельную картину предметной области.
BPwin необходим организациям, которые желают добиться оптимальности и эффективности собственного бизнеса или бизнеса заказчиков, а также руководителям проектов, системным аналитикам, бизнес-аналитикам, маркетологам, консультантам и др.
Аргументы и факты:
- поддерживает три стандартные нотации - IDEF0, DFD и IDEF3. Эти основные ракурса позволяют комплексно описывать предметную область;
- позволяет оптимизировать любые процедуры в компании и повысить эффективность бизнеса;
- поддерживает основные методы расчета себестоимости по объему хозяйственной деятельности;
- легко осваивается;
- распространен и не дорог, много информации, а также компетентных специалистов;
- интегрирован с Paradigm Plus (для моделирования компонентов программного обеспечения), ERwin (для моделирования баз данных);
- содержит генератор отчетов;
- BPwin содержит большой набор средств для документирования проектов и моделей.
- позволяет эффективно манипулировать моделями;
BPwin автоматизирует решение большинства вспомогательных задач, связанных с построением модели процесса обеспечивая логическую строгость, для достижения согласованных результатов. BPwin отслеживает связи в диаграммах, сохраняя их целостность при внесении изменений в модель. Динамическая «подсветка» объектов служит подсказкой при построении модели и предостерегает от повторения распространенных ошибок в моделировании. Кроме того, BPwin поддерживает заданные пользователем свойства, а это позволяет вносить необходимую информацию.
Анализ бизнеса с различных сторон.
С помощью функционального моделирования (нотация IDEF0), можно проводить систематический анализ бизнеса, сосредоточившись на регулярно решаемых задачах (функциях), свидетельствующих об их правильном выполнении показателях, необходимых для этого ресурсах, результатах и исходных материалах.
Цель методологии - построение функциональной схемы исследуемой предметной области, с описанием всех необходимых процессов с точностью, достаточной для однозначного моделирования деятельности организации. В IDEF0 моделируемая система представляется как совокупность взаимосвязанных работ (активностей, функций). Методология IDEF0 имеет развитые процедуры поддержки коллективной работы.
В основе методологии IDEF0 лежат четыре основных понятия:
- функциональный блок,
- дуга (стрелка),
- декомпозиция,
- глоссарий.
Функциональный блок представляет собой некоторую конкретную функцию (работу) в рамках рассматриваемой предметной области. Блок должен иметь название в глагольном наклонении (например, «Проверить документ» или «Проверка документа»).
На диаграмме функциональный блок изображается прямоугольником (рисунок 1.8). Каждая сторона функционального блока имеет свое определенное значение (роль) и определяет тип интерфейса, т. е. способ взаимодействия дуги с блоком:
- верхняя сторона - «Управление» (Control);
- левая сторона - «Вход» (Input);
- правая сторона - «Выход» (Output);
- нижняя сторона - «Механизм» (Mechanism).
Размещено на http://www.allbest.ru/
Дуга (Arrow) отображает элемент предметной области, который обрабатывается функциональным блоком или оказывает другое влияние на функцию, представленную данным функциональным блоком. Интерфейсные дуги часто называют стрелками или потоками. С помощью дуг отображают различные объекты, которые передаются между блоками, обрабатываются блоками, определяют правила обработки и механизмы обработки. Такими объектами могут быть элементы реального мира (детали, оборудование, сотрудники) или потоки данных и информации (ГОСТы, данные, инструкции и т.п.). Стрелки снабжаются надписями - названиями. В зависимости от того, к какой из сторон функционального блока подходит данная интерфейсная дуга, она носит название «входящей», «исходящей», «управляющей», «механизмом» или «вызовом».
В методологии IDEF0 различают пять типов стрелок.
Вход (Input) - информация или материальные объекты, которые используются или преобразуются работой для получения результата (выхода). Допускается, что блок может не иметь ни одной стрелки входа.
Управление (Control) - правила, процедуры, стратегии, стандарты, ограничения на бюджет и время, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Управление влияет на работу, но не преобразуется работой. В случае возникновения неопределенности в статусе стрелки (управление или вход) рекомендуется рисовать стрелку управления.
Выход (Output) - информация или материальный объект, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться.
Механизм (Mechanism) - ресурсы, которые выполняют работу, например сотрудники предприятия, оборудование и т. д. По усмотрению аналитика стрелки механизма могут не изображаться в модели.
Вызов (Call) - специальная стрелка, указывающая на другую модель работы. Стрелка вызова используется при расщеплении модели и указывает, что некоторая работа представлена отдельной моделью. Руководитель проекта может создать декомпозицию верхнего уровня и провести расщепление модели на отдельные модели. Аналитики работают над отдельными моделями, а затем объединяют отдельные модели в единую модель.
Основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. Декомпозиция позволяет постепенно и структурировано представлять модель предметной области в виде иерархической структуры отдельных диаграмм.
Глоссарий (Glossary) - это набор определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор является описанием сущности данного элемента. Глоссарий дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.
Модель в рассматриваемой методологии - это совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма это единица описания предметной области и располагается на отдельном листе. Модель может содержать четыре типа диаграмм:
1. Контекстная диаграмма
2. Диаграммы декомпозиции
3. Диаграммы дерева узлов
4. Диаграммы только для экспозиции
Моделирование потоков данных (DFD), используемое при разработке программного обеспечения, сосредоточено вокруг потоков данных, передающихся между различными операциями, включая их хранение, для достижения максимальной доступности и минимального времени ответа. Такое моделирование позволяет рассмотреть конкретный процесс, проанализировать операции, из которых он состоит, а также точки принятия решений, влияющих на его ход.
Цель методологии DFD - это построение модели рассматриваемой предметной области в виде диаграммы потоков данных. Диаграммы потоков данных предназначены для описания документооборота и обработки информации, но допускают и представление других объектов. При создании диаграммы потоков данных используются четыре основных понятия:
- потоки данных;
- процессы (работы) преобразования входных потоков данных в выходные;
- накопители данных (хранилища);
- внешние сущности.
Потоки данных - это абстракции, использующие для моделирования передачи информации (или физических компонент) из одной части рассматриваемой организации в другую. Потоки на диаграммах изображаются именованными стрелками, ориентация которых указывает направление движения информации.
Процессы (работы) служат для преобразования входных потоков данных в выходные. Имя процесса должно содержать глагол в неопределенной форме с последующим дополнением (например, «получить информацию о проблемах»). Каждый процесс имеет уникальный номер для ссылок на него внутри диаграммы, который может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.
Хранилище (накопитель) данных моделирует данные, которые сохраняются в памяти между процессами. Информация, содержащая в хранилище, может использоваться в любое время после ее получения, данные выбираются в любом порядке. Имя хранилища должно определять его содержимое и быть существительным.
Внешняя сущность представляет собой материальный объект вне контекста предметной области, являющейся источником или приемником данных. Ее имя должно содержать существительное. Предполагается, что объекты, представленные как внешние сущности, не должны участвовать ни в какой обработке.
Сравнивая методологии DFD и IDEF0, можно отметить, что в методологии DFD, кроме расширения изобразительных возможностей диаграмм (за счет хранилищ данных), изменяются правила интерфейсов для стрелок: стрелки могут входить и выходить с любой стороны блока.
Моделирование потоков работ (нотация IDEF3) позволяет рассмотреть конкретный процесс, проанализировать операции, из которых он состоит, а также точки принятия решений, влияющих на его ход.
Методология IDEF3 - это стандарт документирования технологических процессов, которые происходят в рассматриваемой организации, и предоставляемый инструментарий для наглядного исследования и моделирования их сценариев.
Сценарием (Scenario) называется описание последовательности изменений свойств объекта в рамках рассматриваемого процесса (описание последовательности этапов решения проблем). Исполнение каждого сценария сопровождается соответствующим документооборотом, который состоит из двух основных потоков: документов, определяющих структуру и последовательность процесса (технологические карты, стандарты и т.д.), и документов, отображающих ход его выполнения (результаты тестов и экспертиз, отчетные документы и т.п.). Для эффективного управления любым процессом, надо иметь детальное представление об его сценарии и структуре сопутствующего документооборота.
Задачи выполняемые средствами документирования и моделирования IDEF3:
1. Документировать данные о технологии процесса.
2. Определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов.
3. Определять ситуации, требующие принятия решения, которые влияют на жизненный цикл процесса (изменение конструктивных, технологических или эксплуатационных свойств конечного продукта).
4. Содействовать принятию оптимальных решений при реорганизации технологических процессов.
5. Разрабатывать имитационные модели технологических процессов, по принципу «как будет, если…».
В диаграммах модели IDEF3 номер действия, полученного в результате декомпозиции, обычно предваряется номером его родителя (рисунок 1.9).
Существенные взаимоотношения между действиями изображаются с помощью связей. Все связи в IDEF3 являются однонаправленными, и хотя стрелка может начинаться или заканчиваться на любой стороне блока, обозначающего действие, диаграммы IDEF3 обычно организуются слева направо таким образом, что стрелки начинаются на правой и заканчиваются на левой стороне блоков. В таблице 1 приведены три возможных типа связей.
Таблица 1 - Типы связей IDEF3
|
Изображение |
Название |
Назначение |
|
|
Временное предшествование (Temporal precedence) |
Исходное действие должно завершиться, прежде чем конечное действие сможет начаться |
||
|
Объектный поток (Object flow) |
Выход исходного действия является входом конечного действия (исходное действие должно завершиться, прежде чем конечное действие сможет начаться) |
||
|
Нечеткое отношение (Relationship) |
Вид взаимодействия между исходным и конечным действиями задается аналитиком отдельно для каждого случая использования такого отношения |
В IDEF3 для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы, используются перекрестки. Различают перекрестки для разветвления и перекрестки для слияния стрелок. Перекресток не может использоваться одновременно для разветвления и для слияния.
В методологии IDEF3 можно декомпозировать работу многократно, может иметь множество дочерних работ.
На рисунке 1.10 представлено два варианта декомпозиции родительского модуля IDEF3 // http://en.wikipedia.org/wiki/IDEF3 .
Размещено на http://www.allbest.ru/
1.2.3 ERwin
Логические модели данных создаются на стадии проектирования с использованием методологии IDEF1X. В ERWin существует Case-средство, которое поддерживает методологию IDEF1X и стандарт IE (Information Engineering). Методология IDEF1X подразделяется на уровни, соответствующие разрабатываемой модели данных системы. Каждый такой уровень относится к определенной фазе проекта. Этот подход полезен при создании систем по принципу «сверху вниз».
На стадии проектирования создаются логические модели трех уровней: Диаграмма сущность-связь (Entity Relation Diagram), Модель данных, основанная на ключах (Key-Based model) и Полная атрибутивная модель.
Диаграмма сущность-связь (ERD) определяет сущности и их отношения. Более подробное представление данных дает Модель данных, основанная на ключах. В ней содержится описание предметной области - всех сущностей и первичных ключей. Наивысшим уровнем в модели данных является диаграмма сущность-связь, которая определяет набор сущностей и атрибутов проектируемой системы. Цель этой диаграммы - формирование общего взгляда на систему для последующей ее детализации.
Модель данных Key-Based model (модель основанная на ключах), описывает структуру данных системы. В эту систему включены все сущности и атрибуты, в том числе ключевые.
Полная атрибутивная логическая модель - это модель, наиболее раскрыто представляет структуру данных, представленных в третьей нормальной форме.
Построение диаграммы ERD - первый шаг при создании логической модели БД. Диаграмма состоит из сущностей, атрибутов и взаимосвязей и позволяет рассмотреть систему в целом и выяснить требования, которые необходимы для ее разработки, в части хранения информации. ERD-диаграммы можно разделить на отдельные куски, которые соответствуют отдельным задачам, решаемым разрабатываемой системой. Это позволяет делать процесс проектирования управляемым, рассматривая систему с точки зрения функциональных возможностей.
Сущность - это субъект, место, событие, вещь или понятие, содержащее информацию. Точнее, сущность - это объединение (набор) объектов, называемых экземплярами. В диаграммах ER-модели сущность представлена в виде прямоугольника, который содержит имя сущности. Имя сущности - это имя типа, а не конкретного объекта-экземпляра этого типа. Любой экземпляр сущности должен быть отличен от любого другого экземпляра этой же сущности.
Графически изображаемая ассоциация - это связь, устанавливаемая между двумя сущностями. Эта ассоциация может существовать между сущностью и ей же самой (рекурсивная связь) или между двумя разными сущностями. Во всякой связи выделяются два конца (в зависимости от пары связываемых сущностей). На каждом конце указывается имя конца связи, сколько экземпляров данной сущности связывается (степень конца связи), любой ли экземпляр данной сущности должен участвовать в данной связи (обязательность связи).
ERwin поддерживает основные типы связей: полная категория, неполная категория, многие-ко-многим, идентифицирующая/неидентифицирующая.
В ERwin связи представлены следующими основными элементами информации:
- имя связи;
- тип связи;
- мощность связи;
- требования по обеспечению ссылочной целостности.
- допустимость пустых (null) значений;
Связь называется неидентифицирующей, если экземпляр дочерней сущности идентифицируется иначе, чем через связь с родительской сущностью. Атрибуты, входящие в первичный ключ родительской сущности, входят в первичный ключ дочерней сущности.
Связь называется идентифицирующей, если экземпляр дочерней сущности идентифицируется через ее связь с родительской сущностью. Дочерняя сущность при этой связи всегда является зависимой. Атрибуты, входящие в первичный ключ родительской сущности, при идентифицирующей связи входят в состав неключевых атрибутов дочерней сущности.
Идентифицирующая связь рисуется сплошной линией; неидентифицирующая - пунктирной. Со стороны дочерней сущности линии заканчиваются точкой.
Атрибуты не вводятся вручную. При определении связи происходит перемещение атрибутов первичного ключа родительской сущности в соответственную область атрибутов дочерней сущности.
Мощность связи (Cardinality) предназначена для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.
Различают 4 типа мощности:
- общий случай не помечается каким-либо знаком (одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности);
- знаком Р помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение);
- знаком Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения);
- цифрой помечается случай, когда одному экземпляру родительской сущности соответствует ранее заданное число экземпляров дочерней сущности.
Фраза, характеризующая отношение между дочерней и родительской сущностями - Имя связи (Verb Phrase). Для связи идентифицирующей или неидентифицирующей «один ко многим» достаточно указать имя, показывающее отношение «Parent-to-Child» (от родительской к дочерней сущности). Для связи «многие ко многим» надлежит указывать имя как Child-to-Parent, так и Parent-to-Child.
Логические конструкции, представляющие собой правила вставки, удаления и замены и выражающие бизнес-правила использования данных - правила ссылочной целостности (referential integrity (RI)).
Любая деталь, служащая для уточнения, классификации, идентификации, выражения состояния сущности или числовой характеристики является атрибутом сущности. Имена атрибутов изображаются малыми буквами и вносятся в прямоугольник под именем сущности, изображающий сущность.
Атрибут, комбинация связей, комбинация атрибутов или комбинация связей и атрибутов, уникально отличающая любой экземпляр сущности от других экземпляров сущности того же типа является уникальным идентификатором сущности.
Иерархия наследования связи и типы сущностей определяют, является ли сущность зависимой или независимой. Различают несколько типов зависимых сущностей: ассоциативная и характеристическая зависимая дочерняя. Ассоциативная сущность содержит информацию о связях сущностей, позволяет реализовать связь «многие-ко-многим» и связана с несколькими родительскими сущностями. Сущность, хранящая информацию о характеристиках родительской сущности и связанная только с одной родительской является характеристической зависимой дочерней сущностью. Например, связь Менеджер - Телефон.
Дочерняя сущность в иерархии наследования- это категориальная сущность.
Именующая сущность не имеет собственных атрибутов, только атрибуты родительских сущностей, перемещенных в качестве внешнего ключа, и является частным случаем ассоциативной сущности,
Иерархия наследования (иерархия категорий) - особый тип объединения сущностей, разделяющие общие характеристики.
Как правило, иерархию наследования создают, когда несколько сущностей имеют общие по смыслу связи (например, если бы Совместитель и Постоянный сотрудник имели близкую по смыслу связь «работает в» с сущностью Предприятие), либо когда сущности имеют общие по смыслу атрибуты, либо когда это диктуется бизнес-правилами.
Для любой категории можно указать атрибут родового предка - дискриминатор, показывающий, как отличить одну категориальные сущности (атрибут Тип на рисунке 1.11) одну от другой.
Иерархии категорий делятся на типы: полные и неполные.
В неполном типе категория еще не выстроена полностью, в родовом предке могут существовать экземпляры, которые не имеют соответствующих экземпляров в потомках.
Если одному экземпляру родового предка (сущность Сотрудник, смотри рисунок 1.11) обязательно соответствует экземпляр в каком-либо потомке (в примере служащий обязательно является либо Администратором, либо Агентом), то это полная категория.
Для создания связи следует:
- установить курсор в палитре инструментов на кнопке «Категория» и нажать левую кнопку мыши;
- щелкнуть вначале по родовому предку, а затем по потомку;
- для установления следующей связи в иерархии категории сначала следует щелкнуть по символу категории, а затем по второму потомку.
Для редактирования категорий необходимо щелкнуть по символу категории правой кнопкой мыши и выбрать в контекстном меню пункт Subtype Relationship Editor. В диалоге Subtype Relationship можно указать тип категории - полная/неполная (радио-кнопки Complete/Incomplete) и атрибут-дискриминатор категории (список Discriminator Attribute Choice).
Выводы по разделу 1
В первой главе рассмотрен жизненный цикл ITIL и в частности Служба Service Desk. Анализируя процесс Службы Service Desk, были определены направления для автоматизации процесса.
Рассмотрев теоретические основы проектирования информационных систем, сделаны следующие выводы:
2. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ
2.1 Проектирование моделей предметной области
2.1.1 Проектирование модели IDEF0
Моделируя деятельность Службы Service Desk, можно выделить как входную и выходную информацию, так и другие факторы, которые влияют на деятельность Службы Service Desk - это регламентирующие документы, техническое обеспечение и другие факторы.
Анализируя деятельность ИТ-организации был выделен основной процесс по работе с пользователями это деятельность Службы Service Desk (рисунок 2.1)
Для того чтобы лучше понять логику работы Службы Service Desk, было принято решение декомпозировать работу Службы на пять подработ: регистрация обращения, определение службы и ответственного, определение времени решения, закрытие обращения и извещение пользователя о результатах.
Из диаграммы следует, что Службы Service Desk выполняет несколько функций. Прежде всего, это регистрация обращения. Она заключается в том, чтобы, при обращении пользователя об возникшем инциденте или проблеме произвести регистрацию обращения для дальнейшего решения инцидента. Регистрация обращения осуществляется с обязательной авторизацией данных пользователя и информацией об инциденте или проблеме.
Другой не менее важной функцией является определение службы и специалиста для решения поставленной задачи.
Так же важной функцией является закрытие обращения, которая осуществляется после устранения инцидента и возобновлении работоспособности ИТ-услуги. На основании закрытия обращения составляется извещение пользователю о результатах работы.
2.1.2 Построение модели потоков данных
Для того чтобы выделить бизнес-процесс необходимо построить диаграмму DFD. При построении диаграммы были выделены две основные сущности - пользователи и специалисты Службы Service Desk.
Служба Service Desk это своего рода диспетчерская служба, сотрудники которой повседневно контактирует с пользователями и сотрудниками других процессов, поэтому информация о пользователях и сотрудниках всех служб поддержки, их адресах нахождения и контактные телефоны должны быть постоянно под рукой. Пользователи работают со специалистом Служба Service Desk, который принимает заявки на восстановление ИТ-услуг.
Этапы работы Службы Service Desk:
1. Пользователь обращается в Службу с заявкой о Проблеме (Инциденте).
2. Оператор выполняет анализ заявки, и присваивает ей Категорию, при возможности помогает пользователю решить проблему с помощью Базы Знаний.
3. Координатор назначает Инженера для решения заявки и фиксирует ее закрытие.
4. Инженер решает проблему либо возвращает ее координатору.
5. Выполняются работы по извещению пользователя.
2.1.3 Разработка схемы базы данных
Схема системы базы данных (от англ. Database scheme) это ее структура, описанная на формальном языке и поддерживаемой системой управления базами данных (СУБД). В реляционных базах данных схема определяет таблицы, поля в каждой таблице, а также отношения между полями и таблицами. После построения модели потоков данных, можно приступить к созданию схемы данных. Анализируя данные диаграммы выделим две сущности - клиенты (пользователи) и сотрудники. Эти сущности послужат каркасом схемы базы данных, информация о данных сущностях будет храниться в соответствующих таблицах («Клиенты», «Сотрудники»). Помимо информации о клиентах и сотрудниках необходимо следить за движение заявок, их регистрацией, статусом и приоритетом. Следовательно, необходимы еще как минимум четыре сущности, способных хранить необходимую информацию.
В результате проведенного анализа создана модель сущность-связь (рисунок 2.4).
Полученная схема данных позволит хранить всю необходимую информацию для нормального функционирования Службы Service Desk.
Таблица: ДвижениеЗаявки
|
Имя |
Тип |
Размер |
||
|
КодЗаявки |
Длинное целое |
4 |
||
|
НомерПункта |
Длинное целое |
4 |
||
|
ДатаДвижения |
Дата/время |
8 |
||
|
КодСотрудника |
Длинное целое |
4 |
||
|
КодПриоритетаЗаявки |
Длинное целое |
4 |
||
|
Решение |
Текстовый |
50 |
Таблица: Категория
|
Имя |
Тип |
Размер |
||
|
КодКатегории |
Длинное целое |
4 |
||
|
Категория |
Текстовый |
50 |
Таблица: Клиенты
|
Имя |
Тип |
Размер |
||
|
КодКлиента |
Длинное целое |
4 |
||
|
Фамилия |
Текстовый |
20 |
||
|
Имя |
Текстовый |
15 |
||
|
Отчество |
Текстовый |
15 |
||
|
Телефон |
Текстовый |
10 |
||
|
|
Текстовый |
30 |
Таблица: ОтделыServiceDesk
|
Имя |
Тип |
Размер |
||
|
КодОтдела |
Длинное целое |
4 |
||
|
Отдел |
Текстовый |
255 |
Таблица: ОтчетПользователю
|
Имя |
Тип |
Размер |
||
|
КодЗаявки |
Длинное целое |
4 |
||
|
КодОтчета |
Длинное целое |
4 |
||
|
ДатаОтчета |
Дата/время |
8 |
||
|
КодОператора |
Длинное целое |
4 |
||
|
ОтправкаТелефон |
Логический |
1 |
||
|
ОтправкаПочта |
Логический |
1 |
||
|
ТекстОтчета |
Текстовый |
50 |
Таблица: Приоритет
|
Имя |
Тип |
Размер |
||
|
КодПриоритета |
Длинное целое |
4 |
||
|
Приоритет |
Текстовый |
50 |
Таблица: РегистрацияЗаявки
|
Имя |
Тип |
Размер |
||
|
КодЗаявки |
Длинное целое |
4 |
||
|
НомерЗаявки |
Текстовый |
50 |
||
|
ДатаОткрытияЗаявки |
Дата/время |
8 |
||
|
ВремяОткрытияЗаявки |
Дата/время |
8 |
||
|
ОписаниеЗаявки |
Текстовый |
255 |
||
|
КодОператора |
Длинное целое |
4 |
||
|
СрокРешения |
Длинное целое |
4 |
||
|
КодСтатусаЗаявки |
Длинное целое |
4 |
||
|
ДатаЗакрытияЗаявки |
Подобные документы
Необходимость программы "Мониторинг" для службы Service Desk в АО "Алюминий Казахстана". Обработка заявок в службе Service Desk по установке программного обеспечения, покупке и замене офисной техники и расходных материалов. Управление уровнем сервиса.
курсовая работа [3,4 M], добавлен 23.02.2015Значение Информационных технологий. Традиционные проблемы взаимодействия. Принципы организации и возможности автоматизированной Диспетчерской службы. Основные преимущества компьютеризированной реализации службы Service Desk. Классификация, учет обращений.
лекция [2,0 M], добавлен 04.12.2014Экономическая характеристика организации, структура и анализ современной деятельности. Оценка рынка информационных систем и выбор лучшей. Обоснование проектного решения по информационному и программному обеспечению. Технологическое обеспечение проекта.
дипломная работа [4,7 M], добавлен 21.05.2013Порядок проектирования и разработки базы данных и программного обеспечения. Информация о структуре базы данных, созданных таблицах, формах, отчетах, запросах, хранимой информации. Логическая и концептуальная модели данных; выбор программного обеспечения.
курсовая работа [906,6 K], добавлен 20.01.2010Проблемы, обзор и анализ публикаций процесса функционирования библиотеки и обоснование его автоматизации. Анализ альтернативного программного обеспечения по автоматизации работы библиотек. Моделирование процесса функционирования библиотеки "Стэлс".
дипломная работа [1,2 M], добавлен 09.01.2014Разработка базы данных учета и хранения заявок пользователя. Создание программного средства на основе клиент/серверной технологии. Описание возможностей платформы Tandem Framework. Апробация программы автоматизации процессов подачи и обработки заявок.
дипломная работа [3,6 M], добавлен 08.03.2013Понятие, принципы бронирования билетов на железнодорожные рейсы, порядок автоматизации данного процесса. Методика и этапы формирования программного обеспечения для упрощения бронирования на основе входной и выходной информации. Модели организации данных.
контрольная работа [25,4 K], добавлен 21.02.2012Анализ технологий "умного дома", их базовые понятия. Описание технологического процесса и модель автоматизации. Разработка системы управления зданием. Анализ программного обеспечения. Технология производства программного продукта, разработка бизнес-плана.
дипломная работа [1,8 M], добавлен 06.04.2015Порядок автоматизации расчетов себестоимости и длительности программного обеспечения производственного предприятия. Выбор языка программирования и системы управления базами данных. Разработка алгоритмов расчета себестоимости программного обеспечения.
дипломная работа [1,7 M], добавлен 13.06.2017Help Desk - технічна підтримка користувачів: причини виникнення в Росії. Система управління взаємодією з клієнтами. Робота Help Desk на прикладі використання продукту IntraService, підвищення конкурентоспроможності компанії як результат застосування.
реферат [3,9 M], добавлен 11.06.2011
