Разработка подсистемы автоматизации учета услуг спортивного клуба «Т-Фитнес»

АННОТАЦИЯ

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

Год защиты дипломного проекта: 2008.

Целью данного дипломного проекта является разработка подсистемы автоматизации учета услуг для спортивного клуба «Т-Фитнес».

Задачи дипломного проекта:

1. Рассмотрение общих вопросов проектирования информационных систем.

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

3. Анализ деятельности спортивного клуба «Т-Фитнес» и построение информационных моделей деятельности клуба;

4. Разработка приложения «Учет услуг в спортивном клубе „Т-Фитнес“».

5. Расчет экономической эффективности внедрения информационной подсистемы учета услуг спортивного клуба «Т-Фитнес».

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

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

2. Общие вопросы проектирования информационных систем учета услуг.

3. Анализ и построение моделей деятельности предприятия.

4. Разработка приложения «Учет услуг в спортивном клубе „Т-Фитнес“»

5. Безопасность и экологичность проекта.

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

ANNOTATION

This degree work was performed by Alyona Aleksandrovna Lyashenko a student of the group PI-520 of automation faculty of Omsk State Technical University under direction of Aleksandr Nikolaevich Silaenkov. The theme of this work is «The development of the subsystem of automation of services registration of sportclub „T-Fitnes“» (by example of sportclub «T-Fitnes»).

Defending year: 2005.

Purpose of the work is «the development of the subsystem of automation of services registration of sportclub «T-Fitnes».

Objectives of this one are:

1. consideration of general issues of information system development

2. review and analysis of the information systems presented on the Russian market

3. analysis of the sportclub «T-Fitnes» activity and development of information models of the sportclub activity

4. development of the program product «Services registration of the sportclub «T-Fitnes».

5. calculation of profitability of information subsystem of services registration of the sportclub «T-Fitnes» usage.

Work consist of content, introduction, 4 characters, conclusion, list of used literature and appendixes.

Degree research included following characters:

1. General issues

2. The analysis and development of activity models of the company

3. The development of the program product «Services registration of the sportclub «T-Fitnes».

4. Safety and ecological index of the project.

Work is made of pictures, tables, literature list of 20 items, appendixes, all on pages.

Содержание Введение

1 Общие вопросы

1.1 Проектирование экономических информационных систем

1.2 Анализ состояния рынка информационных систем в России

1.3 Оценка потребности в информационной системе

1.4 Обзор информационных систем, представленных на рынке

2 Анализ и построение моделей деятельности предприятия

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

2.2 Выбор методологии, нотации и инструментальных средств анализа разрабатываемой подсистемы

2.3 Построение модели деятельности «как есть» (AS-IS) и «как должно быть» (TO-BE) по методу SADT

2.4 Построение функциональных моделей «как есть» (AS-IS) и «как должно быть» (TO-BE) в виде иерархии потоков данных (DFD)

2.5 Информационная и физическая модели предметной области

3 Разработка приложения «Учет услуг в спортивном клубе «Т-Фитнес»

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

3.2 Установка и удаление приложения

3.3 Работа с приложением

3.4 Основные формы приложения

4 Безопасность и экологичность проекта

4.1 Анализ опасных и вредных производственных факторов на рабочем месте администратора спортивного клуба «Т-Фитнес»

4.2 Меры по снижению и устранению опасных и вредных факторов

4.3 Разработка инструкция по охране труда при работе с персональным компьютером

4.4 Пожарная безопасность Заключение Библиографический список Приложение А1

Приложение А2

Приложение А3

Приложение А4

Приложение Б

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

Сегодняшнее состояние рынка программного обеспечения в России обусловлено, в первую очередь, историческим развитием российских систем и приходом западных разработчиков и партнеров на российский рынок. Некоторые разработчики, сумевшие предвидеть развитие событий, предпочли эволюционный качественный рост российских продуктов простому увеличению продаж «коробочных» решений, вкладывая средства в развитие систем и научно-исследовательские работы. Западные системы в России прорвались на российский рынок в начале 90-х годов. Сначала открылись небольшие представительства, или были подписаны партнерские соглашения с российскими компаниями. Затем экспансия приобрела более массированный характер, и на Российские фирмы и предприятия обрушилась вся мощь типичной западной рекламной компании. Незнакомая и пугающая и одновременно заманивающая обещанием полного благополучия, при условии вложения 1−2-х миллионов долларов, компания имела определенный успех.

Вместе с тем, огромное количество российских предприятий — это малые частные предприятия, которые не могут позволить себе вкладывать сотни тысяч долларов в покупку системы, возможности которой будут использоваться на 5−10%. Для малых предприятий, торговых фирм и компаний, предоставляющих услуги по соотношению цена/качество наиболее подойдут финансово-управленческие системы, так как основные решаемые ими задачи — это бухгалтерский учет, управление складами продукции, управление кадрами. Финансово-управленческие системы (особенно системы российских разработчиков) значительно более гибкие в адаптации к нуждам конкретного предприятия. Часто предлагаются «конструкторы», с помощью которых можно практически полностью перестроить исходную систему, самостоятельно, или с помощью поставщика установив связи между таблицами баз данных или отдельными модулями.

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

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

Целью работы является разработка подсистемы автоматизации учета услуг спортивного клуба «Т-Фитнес».

Для достижения поставленной цели в работе были поставлены следующие задачи:

— изучить общие вопросы проектирования информационных систем;

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

— проанализировать деятельность спортивного клуба «Т-Фитнес», сформировать информационные модели деятельности клуба;

— разработать приложение «Учет услуг в спортивном клубе „Т-Фитнес“»

— выполнить расчет экономической эффективности внедрения информационной подсистемы учета услуг спортивного клуба «Т-Фитнес»

— проанализировать опасные и вредные производственные факторы на рабочем месте администратора спортивного клуба «Т-Фитнес»

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

Объектом исследования данного дипломного проекта является спортивный клуб «Т-Фитнес».

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

1 Общие вопросы

1.1 Проектирование экономических информационных систем

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

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

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

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

Только 16,2% проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности; 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме; 31,1% проектов были аннулированы до завершения. Для проектов, которые завершились с опозданием или были аннулированы до завершения, бюджет среднего проекта оказался превышенным на 89%, а срок выполнения — на 122%.

В 1998 г. процентное соотношение проектов лишь немного изменилось в лучшую сторону (26%, 46% и 28% соответственно).

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

Потребность контролировать процесс разработки ПО, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела в конце 70-х годов к необходимости перехода от кустарных к индустриальным способам создания ПО и появлению совокупности инженерных методов и средств создания ПО, объединенных общим названием «программная инженерия». Впервые этот термин был использован как тема конференции, проводившейся под эгидой NATO в 1968 г. Спустя семь лет, в 1975 г., в Вашингтоне была проведена первая международная конференция, посвященная программной инженерии, — IEEE Transaction on Software Engineering.

В процессе становления и развития программной инженерии можно выделить два этапа: 70-е и 80-е гг. — систематизация и стандартизация процессов создания ПО (на основе структурного подхода) и 90-е годы — начало перехода к сборочному, индустриальному способу создания ПО (на основе объектно-ориентированного подхода).

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

1.2 Анализ состояния рынка информационных систем в России

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

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

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

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

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

1.3 Оценка потребности в информационной системе

Имея представление о существующих типах систем можно понять, какая система подходит для предприятия. Очевидно, что нет смысла тратить сотни тысяч долларов на покупку системы, возможности которой будут использоваться на 5−10%.

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

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

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

1.4 Обзор информационных систем, представленных на рынке

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

Классификация рынка информационных систем:

— Локальные системы (1С, БЭСТ, Инотек, ИНФИН, Инфософт);

— Малые интегрированные системы (БОСС-Корпорация, Галактика/Парус, Ресурс, Эталон, Axapta);

— Средние интегрированные системы (JD Edwards (Robertson& Blums), MFG-Pro (QAD/BMS));

— Крупные интегрированные системы (SAP/R3 (SAP AG), Baan (Baan), BPCS (ITS/SSA), Oracle);

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

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

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

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

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

Финансово-управленческие системы (особенно системы российских разработчиков) значительно более гибкие в адаптации к нуждам конкретного предприятия. Часто предлагаются «конструкторы», с помощью которых можно практически полностью перестроить исходную систему, самостоятельно, или с помощью поставщика установив связи между таблицами баз данных или отдельными модулями. Хотя общая конфигурация систем может быть достаточно сложна, практически все финансово-управленческие системы способны работать на персональных компьютерах в обычных сетях передачи данных Novell Netware или Windows NT. Они опираются на технологию выделенного сервера базы данных (file server), которая характеризуется высокой загрузкой сетевых каналов для передачи данных между сервером и рабочими станциями. Только отдельные из предлагаемых в России систем такого класса были разработаны для промышленных баз данных (Oracle, SYBASE, Progress, Informix, SQL Server). В основном использовались более простые средства разработки Clipper, FoxPro, dBase, Paradox.

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

Рассмотрим некоторые из подобных систем и их основные возможности:

Maxs&Soft. Система предназначена для работы в частной медицинской клинике. Реализована на базе Delphi. Система состоит из трех независимых модулей, которые интегрируются в единую систему через общее хранилище данных. Это позволяет сделать процесс внедрения системы автоматизации максимально гибким и безболезненным. Например, сначала можно внедрить модуль регистратуры, автоматизирующий учет пациентов, кассы и отчетности по страховым компаниям. Затем можно автоматизировать диагностические отделения (УЗИ, рентген, лаборатория, КТ и т. д.) и уже после автоматизировать работу всех врачей. Полная автоматизация клиники позволяет обмениваться врачам всей информацией по пациентам, результатам исследований, заключениям и полностью исключает бумажный документооборот. Это позволяет максимально оптимизировать рабочее время врачей, а значит сэкономить время пациентов. Любая информация по пациенту и по всем его посещениям может быть получена в течение нескольких секунд (рентген и УЗИ снимки, заключения терапевта, результаты лабораторных исследований, снимки томографии и т. д.), что повышает качество обслуживания пациентов и исключает ошибки и недочеты в работе врачей.

Система для работы в кабинете УЗИ. Реализована на базе Delphi. Программный продукт «Кабинет ультразвуковой диагностики», предназначен для ведения базы данных пациентов кабинетов ультразвуковой диагностики. Основная цель программного продукта — максимально сократить время составления протокола обследования, предоставляя удобный интерфейс для ввода параметров обследования и вывода полного текста протокола на фирменном бланке медицинского учреждения. Среди второстепенных целей можно отметить быстрый и удобный просмотр истории всех хранящихся в базе данных обследований конкретного пациента, а также анализ накопленной информации в базе данных с помощью запросов, с целью каких-либо медицинских статистических исследований. Все протоколы в системе создаются на основе предварительно подготовленных шаблонов в Microsoft Excel, что позволяет подготовить свой фирменный бланк протокола под любые требования и любой формат выдачи результатов. Одна из основных отличительных особенностей программного продукта от систем подобного рода — система является полностью расширяемой и настраиваемой под нужды конкретных пользователей. Ввод и изменение данных в программе облегчается при использовании множества предусмотренных справочников.

ООО Ристар. Система предназначена для работы в поликлинике, больнице, офисе врача. Реализована на базе Delphi 5, Oracle 9.2; Delphi 6, Interbase. Медицинская информационная система предназначена для комплексной автоматизации ввода, обработки, хранения, поиска и анализа всей информации, обрабатываемой администрацией, медицинским и прочим персоналом медицинского учреждения. Система может быть сконфигурирована для работы на отдельных рабочих местах врача, в рамках локальных вычислительных сетей отделений/подразделений, в качестве комплексной информационно-управляющей системы медицинского учреждения, группы медицинских учреждений.

Подобные системы позволяют:

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

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

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

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

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

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

Основные преимущества систем учета медицинских услуг:

Универсальность — отдельные программные модули решают задачи как поликлиники, так и стационара, возможно применение системы в крупных ЛПУ, имеющих удаленные филиалы.

Модульность — каждый отдельный участок автоматизации может работать в автономном режиме.

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

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

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

Основные модули систем учета медицинских услуг:

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

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

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

Модуль «Анализ заболеваемости» используется для изучения заболеваемости прикрепленного контингента по зарегистрированным заболеваниям, позволяет проводить глубокий анализ

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

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

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

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

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

Программа управления спортивной организацией «Спортклуб» компании IT FastSoft предназначена для администраторов и тренеров спортивных организаций.

Программа позволяет:

— Организовывать базы данных по спортсменам в одном или нескольких спортивных клубах

— Создавать базы по тренерам спортивных клубов

— Хранить подробную персональную информацию о спортсменах и тренерах

— Архивировать клубную информацию, например, номера и даты регистрационных документов, бухгалтерской отчетности

— Печатать различные бланки и заявления

— Составлять планы тренировок

— Записывать информацию об ошибках спортсменов на тренировках.

— Учитывать и контролировать посещаемость тренировок спортсменами

— Формировать статистику посещений, печатать журнал посещений

— Составлять расписания посещений занятий

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

— Рассчитывать бухгалтерию клуба на основании данных по доходности групп и стоимости аренды помещения

— Вести подробный учет различных доходов и расходов клуба

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

Вид главного окна программы Sportclub представлен на рисунке1.2.

Рисунок 1.2 — Главное окно программы Sportclub

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

2 Анализ и построение моделей деятельности предприятия

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

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

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

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

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

Стенограмма интервью с руководителем отдела. Составлена анкета для директора клуба и проведен опрос. Ниже приведены вопросы анкеты и ответы на них (курсивом):

1. ФИО руководителя, телефон;

Заруцкий А.Н. 22−52−42

2. Каковы с вашей точки зрения должны быть цели создания информационной системы на Вашем предприятии?

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

3. Каковы основные направления деятельности Вашего предприятия?

Физкультурно-оздоровительные услуги.

4. Какая инфрмация формируется внутри предпиятия?

Учет посещаемости, контроль за результатами занятий;

5. С кем взаимодействует Ваше предприятие и какой информацией обменивается?

С федерацией аэробики (г. Омск), с другими клубами (Москва, Новосибирск). Обмен информацией, аудиовидеопродукция, мастерклассы.

6. Физическое представление информации (Пример: документ, дискета, сеть, журнал, картотека и т. п.);

Документы, таблицы.

7. Время хранения информации;

3 года.

8. Какова штатная структура и квалификация кадров?

8 человек. Высшее спортивное или хореографическое образование.

На основании ответов на вопросы анкеты был проведен устный опрос.

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

— Проведение работы с посетителями;

— Проведение работы с поставщиками;

— Взаимодействие с другими организациями;

Наиболее формализованной областью деятельности является работа с посетителями.

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

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

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

2.2 Выбор методологии, нотации и инструментальных средств анализа разрабатываемой подсистемы

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

— количество связей между отдельными подсистемами должно быть минимальным;

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

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

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

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

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

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

— принцип «разделяй и властвуй» ;

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

— принцип абстрагирования — выделение существенных аспектов системы и отвлечение от несущественных;

— принцип непротиворечивости — обоснованность и согласованность элементов системы;

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

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

— диаграммы, иллюстрирующие функции, которые должна выполнять система, и связи между этими функциями — для этой цели чаще всего используются нотации SADT и DFD;

— диаграммы, моделирующие данные и их взаимосвязи (диаграммы сущность-связь — ERD);

— диаграммы, моделирующие поведение системы (диаграммы переходов состояний — STD).

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

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

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

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

— использование специальным образом организованного хранилища проектных метаданных (репозитория).

Наиболее распространены: CASE. Аналитик, Bpwin и ERwin, EasyCASE, Designer/2000 и другие. Как правило, один отдельно взятый пакет поддерживает лишь часть видов проектной деятельности, поэтому фактически требуется сформировать своеобразную CASE-среду, т. е. комплекс CASE-средств, покрывающий весь жизненный цикл ПО.

Для выполнения данной дипломной работы в качестве инструмента был выбран программный продукт BPwin от фирмы Platinum technology/Logic Works. Он позиционируется для использования проектировщиками, аналитиками, разработчиками. Bpwin — это CASE-средство визуального проектирования информационных систем, позволяющее моделировать бизнес-процессы, реализующее метод IDEF0. Текущая версия BPwin поддерживает также диаграммы потоков данных и потоков работ.

На этапе моделирования подсистемы используются нотации SADT (Structured Analysis and Design Technique) и DFD (Data Flow Diagrams), поскольку они позволяют наиболее адекватно отобразить логику предметной области и легко воспринимаются для анализа. Диаграммы потоков данных и диаграммы «сущность-связь» — наиболее часто используемые в CASE-средствах виды моделей. На стадии формирования требований к разрабатываемой подсистеме SADT-модели и DFD используются для построения модели «AS-1S» и модели «ТО-ВЕ», отражая, таким образом, существующую и предлагаемую структуру бизнес-процессов спортивного клуба и взаимодействие между ними.

2.3 Построение модели деятельности «как есть» (AS-IS) и «как должно быть» (TO-BE) по методу SADT

Результатом применения метода SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы — главные компоненты модели, все функции организации и интерфейсы на них представлены как блоки и дуги соответственно. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как входная информация, которая подвергается обработке, показана с левой стороны блока, а результаты (выход) показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (рисунок 2.1).

Механизм

Рисунок 2.1 — Функциональный блок и интерфейсные дуги

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

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

Для спортивного клуба «Т-Фитнес» простейшим компонентом является блок «Осуществление физкультурно-оздоровительной деятельности» с интерфейсными дугами «Посетители», «Постоянные клиенты», «Посетители, отказавшиеся от постоянных услуг», «Фитнес-директор», «Тренеры», «Администратор», «Потребности в оборудовании, товарах, услугах», «Стандарты, нормативные документы».

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

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

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

На SADT-диаграммах не указаны явно ни последовательность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Например, на диаграмме А0 «Осуществление физкультурно-оздоровительной деятельности» обратная связь по управлению «Товары и оборудование» (См. приложение А1).

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

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

Для того чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок А21 на диаграмме А2. (рисунок 2.2)

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

Рисунок 2.2 — Детализация диаграмм Различают по крайней мере связи семи типов (в порядке возрастания их относительной значимости):

— случайная;

— логическая;

— временная;

— процедурная;

— коммуникационная;

— последовательная;

— функциональная.

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

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

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

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

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

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

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

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

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

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

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

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