Анализ российской законодательной базы по проблемам информатизации физкультурно-спортивного воспитания населения. Выбор архитектуры, проектирование пользовательского интерфейса. Разработка структуры модели данных. Надежность и эффективность Web-сервиса.
Аннотация к работе
Правительством Российской Федерации в августе 2009 г. утверждена «Стратегия развития физической культуры и спорта в Российской Федерации на период до 2020 года» [1] (далее Стратегия), а в январе 2015 г.федеральная целевая программа «Развитие физической культуры и спорта в Российской Федерации на 2016 - 2020 годы»[2] (далее Целевая программа). Одним из направлений, обеспечивающих как реализацию пропаганды физической культуры и спорта, так и модернизацию системы физического воспитания является широкое внедрение информационных технологий в деятельность кафедр физической культуры высших учебных заведений профессионального образования. Разработана стратегия развития физической культуры и спорта в Российской Федерации на период до 2020 года [1], в 2015 планировалось принятие федеральной целевой программы "Развитие физической культуры и спорта в Российской Федерации на 2016 - 2020 годы" [2]. На основании этих требований информатизация бизнес-процессов обеспечивается для вуза в пунктах связанных как с автоматизацией документооборота кафедр физкультуры, так и в плане мониторинга психофизического развития и текущего состояния студентов, а также информатизации пропаганды и популяризации занятий спортом и здорового образа жизни[4]. В связи с этим представляет интерес проанализировать требования к реализации информационных сервисов, обеспечивающих поддержку реализации требований ФЗ "О физической культуре и спорте в Российской Федерации" в части развития здорового образа жизни.Базовая архитектура трехуровневой системы может быть представлена на основании разделения на уровни пользовательского представления, представления бизнес логики и представления данных. При такой архитектуре клиентский уровень занимает обозреватель, на уровне сервера находится сервер БД, а на промежуточном уровне размещаются Web-сервер и модули расширения сервера. Уровень представления Web-приложения критически важен при разработке системы и оказывает значительное влияние на степень принятия приложения пользователями. Он обеспечивает выполнение бизнес-функций, представляемых приложением пользователям, а также визуальное представление информации, которой управляет приложение. Данный проект, как и все проекты MVC содержит следующие папки: App_Data, Content, Controllers, Models, Scripts и Views.В дополнение к данным папкам сгенерированное веб-приложение MVC использует код в файле Global.asax для установки глобальных параметров маршрутизации URL-адресов по умолчанию, а также использует файл Web.config для настройки приложения.Проведен выбор архитектуры Web-сервиса «Учебный процесс кафедры физкультуры» как трехуровневого Web-приложения. Надежность сайта - эксплуатационное качество сайта, характеризующееся вероятностью безотказной работы сайта в определенный промежуток времени при сохранении параметров, заданных в техническом задании на сайт. Так как Web-сервис «Учебный процесс кафедры физкультуры» не предусматривает завоевание пользовательской аудитории, а является сервисом для обеспечения учебной деятельности, то при анализе надежности сайта следует исходить из первого определения, связанного с безотказной работой. Определим модель ЖЦ проектирования на основе методики предложенной в работе Т. При выполнении нашего проекта, для которого модель «RAD» подходит в достаточной мере, появляются следующие преимущества: - время цикла разработки для всего проекта можно сократить благодаря использованию мощных инструментальных средств;В третьей главе произведено обоснование выбора жизненного цикла информационной системы и выделено, что наиболее оптимальным вариантом модели является модель RAD.В дипломной работе рассмотрена деятельность кафедры физкультуры РГЭУ (РИНХ). В результате проведенного анализа выявилась актуальность автоматизации бизнес-процессов кафедры в свете постановлений правительства Российской федерации по вопросам развития физкультуры и спорта. В ходе проведенного анализа было показана ограниченность существующих решений по автоматизации предметной области кафедр физкультуры. В связи с этим представляет интерес разработка Web-сервиса, обеспечивающего деятельность кафедры в плане активизации учебного процесса путем использования информационных технологий. В ходе выполнения дипломного проекта был спроектирован и РАЗРАБОТАНWEB-СЕРВИСУЧЕБНАЯ работа обеспечивающая тематику кафедры.Сервис «Учебный процесс кафедры физкультуры»(СЕРВИС) - Web-приложение, обеспечивающее поддержку работы кафедры физкультуры РГЭУ (РИНХ) в области оптимизации учебного процесса. На втором этапе завершающего ввода в эксплуатацию сервис должен обеспечивать учет медицинских показаний студентов к проведению тренировок, учет выполнения индивидуальных заданий студентами. Загрузка необходимых компонентов системы F Система должна загружать свои компоненты, в зависимости от типа пользователя Задание свойств пользователя F Система должна определять свойства сотрудника авторизованного в системе. Применяемые при эксплуатации СЕРВИСА средства резервного копирования и восс
Введение
Правительством Российской Федерации в августе 2009 г. утверждена «Стратегия развития физической культуры и спорта в Российской Федерации на период до 2020 года» [1] (далее Стратегия), а в январе 2015 г.федеральная целевая программа «Развитие физической культуры и спорта в Российской Федерации на 2016 - 2020 годы»[2] (далее Целевая программа). Одной из основных целей этих документов является создание условий, обеспечивающих возможность гражданам систематически заниматься физической культурой и спортом. К числу основных задач, требующих решения для достижения поставленной цели, относятся: 1) создание новой национальной системы физкультурно-спортивного воспитания населения;
2) разработка и реализация комплекса мер по пропаганде физической культуры и спорта как важнейшей составляющей здорового образа жизни;
3) модернизация системы физического воспитания различных категорий и групп населения, в том числе в образовательных учреждениях профессионального образования.
Одним из направлений, обеспечивающих как реализацию пропаганды физической культуры и спорта, так и модернизацию системы физического воспитания является широкое внедрение информационных технологий в деятельность кафедр физической культуры высших учебных заведений профессионального образования.
Ростовский-на-Дону государственный экономический университет (РГЭУ (РИНХ)) традиционно значительное внимание в свой деятельности уделяет как массовому спорту среди студентов вуза, так и подготовке спортсменов высокого класса и спортивного резерва из числа своих студентов. Сайт университета[3] имеет достаточно информационно наполненный раздел, посвященный деятельности управления по физической культуре и спорту университета (управления ФКИС), который включает как информацию о деятельности кафедры физкультуры, так и о деятельности подразделений, непосредственно выполняющих рекомендации Стратегии: наличие спортивных клубов, баз активного отдыха.
Актуальность реализации дополнительных информационных сервисов по вопросам физической культуры и спорта для РГЭУ (РИНХ) связана с необходимостью оптимизации работы кафедры физкультуры и управления ФКИС.
Целью дипломного проекта является разработка информационных сервисов, обеспечивающих оптимизацию работы кафедры физкультуры и управления ФКИС.
Для достижения поставленной цели необходимо решить следующие задачи: - провести обследование предметной области;
- построить модель предметной области «как есть» и выявить существующие недостатки;
- построить модель «как будет» и предложить рекомендации модернизации системы управления ФИКС на базе внедрения информационных сервисов;
- разработать базу данных (БД), обеспечивающую поддержку информационных сервисов;
- разработать сервисы;
- провести отладку системы;
- провести оценку эффективности принятых решений, и реализованных сервисов.
1. Описание предметной области архитектура интерфейс надежность информатизация
1.1 Анализ российской законодательной базы по проблемам информатизации физкультурно-спортивного воспитания населения
Значительное внимание в российском законодательстве уделяется вопросам физкультурно-спортивного воспитания населения. Целый ряд документов связан с развитием законодательства по вопросам спорта [1-3]. Разработана стратегия развития физической культуры и спорта в Российской Федерации на период до 2020 года [1], в 2015 планировалось принятие федеральной целевой программы "Развитие физической культуры и спорта в Российской Федерации на 2016 - 2020 годы" [2].
Ключевым законодательным актом РФ, определяющим политику государства в области физической культуры, стал федеральный закон (ФЗ) "О физической культуре и спорте в Российской Федерации" [3]. Одним из важнейших направлений работы закон называет формирование физической культуры студентов и молодежи, требования по организации физического воспитания и образования в образовательных учреждениях представлены в статье 28. Сюда входит как проведение обязательных занятий физической культурой и спортом в пределах основных образовательных программ, так и: - проведение медицинского контроля организации физического воспитания;
- формирование ответственного отношения родителей (лиц, их заменяющих) к здоровью детей и их физическому воспитанию;
- проведение ежегодного мониторинга физической подготовленности и физического развития обучающихся.
На основании этих требований информатизация бизнес-процессов обеспечивается для вуза в пунктах связанных как с автоматизацией документооборота кафедр физкультуры, так и в плане мониторинга психофизического развития и текущего состояния студентов, а также информатизации пропаганды и популяризации занятий спортом и здорового образа жизни[4].
Автоматизация документооборота реализуется в вузах в области разработки учебных планов и формирования учебной нагрузки преподавателей, безбумажного накопления учебных материалов в хранилищах данных по учебным дисциплинам. Значительно меньший уровень автоматизации наблюдается при разработке и реализации непосредственно учебных программ основных и дополнительных дисциплин.
Проблемы внедрения информационных технологий непосредственно на кафедрах физкультуры российских вузов практически не получили развития. Как указывается в работе [4]отсутствует даже общепринятая классификация информационных технологий в спорте. В данной работе предлагается классифицировать их по следующим показателям: - классификация по функциям;
- классификация по методам;
- классификация по этапам учебно-тренировочного процесса;
- классификация по предлагаемым населению услугам;
- по видам подготовки в сфере физической культуры и спорта.
В работе Журавлева В.А. и Ананьин В.Г. [5] сделана попытка систематизировать использование информационных технологий в отрасли "Физическая культура и спорт" в целом. Этими направлениями являются: учебный процесс, спортивная тренировка, спортивные соревнования, оздоровительная физическая культура, спортивный менеджмент и регуляция кадрового потенциала отрасли.
Традиционно информационная поддержка кафедр физической культуры ВУЗАМИ осуществляется путем представления информации об их деятельности в рамках сайта ВУЗА. Были рассмотрены информационные ресурсы кафедр физкультуры РГЭУ (РИНХ) [6], ДГТУ [7] и РОСТГМУ[8]. На основании материалов этих сайтов можно сказать, что ВУЗЫ в основном ограничиваются минимальными данными о профессорско-преподавательском составе кафедр, о спортивных секциях и клубах с предоставлением уставных документов этих подразделений.
В связи с этим представляет интерес проанализировать требования к реализации информационных сервисов, обеспечивающих поддержку реализации требований ФЗ "О физической культуре и спорте в Российской Федерации" в части развития здорового образа жизни.
1.2 Анализ предметной области
Проведем анализ необходимого программного обеспечения и информационных ресурсов на основе анализа деятельности кафедры физкультуры РГЭУ (РИНХ) и управления по физической культуре и спорту (УФК и С).
Анализ проводится на основе объектно-ориентированной методологии. Объектно-ориентированный анализ - это методология, при которой требования к системе формируются на основе понятий классов и объектов, выявленных в предметной области.
Главными достоинствами объектно-ориентированной методологии являются: - возможность преодолеть ограничения, связанные со сложностью разрабатываемых систем;
- использование на стадии анализа моделей близких к реальности;
- возможность применения как при анализе и проектировании информационных систем, так и систем реального времени и аппаратно-программных комплексов;
- обеспечение возможности повторного использования разработанного программного обеспечения, позволяющего существенно сократить сроки и снизить затраты на разработку каждой последующей системы;
- поддержка итеративного, а не лавинообразного, как в структурном подходе, процесса проектирования;
- естественная работа с разнородной информацией, используемой в мультимедиа системах;
- создание более открытых систем;
- полное использование описательных возможностей объектно-ориентированных языков программирования.
В состав РГЭУ (РИНХ) кроме головного ВУЗА входят 8 филиалов и Таганрогском институт имени А. П. Чехова, а также финансово-экономический колледж.
В РГЭУ (РИНХ) создано УФК и С, организационная структура которого представлена на рис. 1.1 по материалам сайта РИНХ [3]. УФК и С подчинено первому проректору по учебной работе. Руководство управлением осуществляется начальником управления через коллегиальным орган - совет по спортивно-оздоровительной работе. Функциями УФК и С являются [9]: - руководство спортивно-оздоровительной работой Университета;
- контроль работы кафедр физического воспитания, спорта и туризма(ФВ,СИТ) РГЭУ(РИНХ), финансового колледжа
- организацию и руководство спортивно-оздоровительной работы в спортклубах, спорткомплексах и спортивных сооружениях и в спортивно-оздоровительном лагере Университета, филиалах и колледже;
- координация работы кабинета врачебно-спортивного контроля.
Такая организационная структура позволяет снизить нагрузку на кафедры физического воспитания, спорта и туризма(ФВ, СИТ) в части управления спортивными комплексами и спортивными клубами, которые переподчинены управлению и могут быть использованы кафедрами ФВ, СИТ, как головного вуза, так филиалов и колледжа.
Рис. 1.1 - Организационная схема управления по УФК ИС
Деятельность кафедр физического воспитания РГЭУ (РИНХ) строится на основе приказа Госкомвуза РФ от 26.06.1994 № 777 «Об организации процесса физического воспитания в высших учебных заведениях» [11]. На базе этого документа разработана объектная модель ролей кафедры физкультуры, представленная на рисунке 1.2.
Базовой сущностью модели является роль - Сотрудник каф. физкультуры. От него унаследованы роли: Преподаватель, Учебно-вспомогательный персонал, Зав. кафедрой. Роли описывающие деятельность сотрудников, ответственных по профилям работы кафедры, наследуют свойства роли Преподаватель. Это: - Ответственный за научную и учебно-методическую работу;
- Ответственный по физическому воспитанию;
- Ответственный по виду спорта;
- Ответственный за массовую оздоровительную работу;
- Ответственный за учебную работу.
Таким образом, работа кафедры физкультуры кроме трех основных бизнес-процессов - учебного, научного и учебно-методического, воспитательного, присущих любой из кафедр ВУЗА, включает бизнес-процесс организации массовой оздоровительной работы.
Рис. 1.2 - Модель сотрудников кафедры физкультуры
Проведем анализ деятельности кафедры физкультуры на основе примерных должностных обязанностей преподавательского состава кафедры. При рассмотрении вариантов использования проведем разделение на прецеденты общие для сотрудников кафедры физкультуры и других кафедр университета (прецеденты желтого цвета) и прецеденты характерные исключительно для кафедры физкультуры - зеленые.
1. Заведующий кафедрой физического воспитания несет личную ответственность за всю деятельность кафедры, в том числе: - проведение теоретических и практических учебных занятий со студентами в установленном объеме;
- планирование и организацию учебно-воспитательного процесса и контроль за качеством учебных занятий;
- руководство научной и научно-методической работой преподавателей кафедры;
- организацию работы по повышению квалификации преподавателей с отрывом и без отрыва от учебного процесса;
- внедрение научной организации труда на кафедре, оснащение учебного процесса техническими средствами обучения, компьютерной техникой, тренажерами и наглядными пособиями;
- составление расчетов и смет по штатному, финансовому и материальному обеспечению работы по физическому воспитанию;
- проведение мероприятий совместно со спортивным клубом по развитию массового спорта в вузе, росту спортивного мастерства студентов-спортсменов, по подготовке спортсменов высших разрядов; проведение массовых физкультурно-оздоровительных мероприятий, спортивных соревнований и праздников;
- контроль за правильностью расходов средств, ассигнуемых на физическое воспитание, сохранением и использованием спортивного имущества, инвентаря и аппаратуры, за состоянием и эксплуатацией имеющихся спортивных помещений и сооружений;
- руководство работой учебно-вспомогательного и административно-хозяйственного персонала кафедры;
- составление отчетов о работе кафедры;
- активное участие в составлении плана строительства и благоустройства учебных спортивных сооружений и оздоровительных баз вуза в соответствии с утвержденными нормами.
Диаграмма вариантов использования для деятельности РОЛЬАЗАВ. кафедрой представлена на рисунке 1.3.
2. Преподавательский состав кафедры осуществляет: - планирование, организацию и проведение теоретических и практических учебных занятий по физическому воспитанию с закрепленными группами студентов на высоком профессиональном уровне;
- работу с отстающими студентами, руководство самостоятельными занятиями студентов (разработку индивидуальных и групповых заданий, методических материалов, комплексов упражнений, консультативную помощь и т.п.);
- прием у студентов контрольных упражнений и нормативов, зачетов в учебное время;
Рис. 1.3 - Модель деятельности заведующего кафедрой физкультуры
- научную и учебно-методическую работу, разработку методических материалов по разделам учебной программы, положений о спортивных соревнованиях, методических указаний, учебных, наглядных пособий и др.;
- систематическую работу по повышению своего профессионального уровня;
- учет пройденного материала, анализ динамики состояния здоровья, физического развития и физической подготовленности, выполнения студентами контрольных требований и тестов учебной программы в течение всего периода обучения в вузе;
- участие в организации и проведении запланированных мероприятий: судействе внутренних и внешних спортивных соревнований, туристических походов и других массовых оздоровительных, физкультурных и спортивных мероприятий;
- подготовку спортивных команд и повышение мастерства студентов-спортсменов, руководство ими в процессе спортивных соревнований;
- учет результатов медицинского освидетельствования студентов и систематический контроль за состоянием их здоровья в процессе учебно-тренировочных занятий;
- ежегодное составление индивидуальных планов и отчетов об их выполнении;
- другие виды работ, связанные с физическим воспитанием студентов.
Внештатные преподаватели и преподаватели на условиях почасовой оплаты привлекаются для проведения учебных занятий по физическому воспитанию. Круг их обязанностей определяется договором.
Диаграмма вариантов использования деятельности роли Преподаватель представлена на рисунке 1.4.
Рис. 1.4 - Модель деятельности преподавателя кафедры физкультуры
Для обеспечения всех разделов работы по физическому воспитанию заведующий кафедрой может возложить на наиболее квалифицированных преподавателей ответственность за их выполнение.
3. Преподаватель, ответственный за учебную работу (заместитель заведующего кафедрой), выполняет следующие обязанности: - проверку и подготовку к утверждению учебных программ, графиков учебного процесса, планов работы кафедры, учебных отделений, методических комиссий и преподавателей и реализацию их в учебно-воспитательном процессе;
- контроль за организацией и качеством проведения учебных занятий, организацию взаимопосещения занятий, проводимых преподавателями, и открытых занятий с последующим обсуждением итогов на заседаниях кафедры;
- анализ качества и эффективности учебной работы, обобщение и внедрение передового опыта по совершенствованию учебно-воспитательного процесса;
- контроль за проведением профессионально-прикладной физической подготовки в учебном процессе;
- распределение почасового фонда, контроль за его расходованием;
- организацию и проведение контрольных соревнований, приема контрольных нормативов и зачетов по физическому воспитанию;
- ведение учета за динамикой состояния здоровья, физической подготовленности студентов, выполнением требований и тестов учебной программы;
- контроль за выполнением распоряжений по кафедре, плана работы кафедры, планов работы отделений и методических комиссий, индивидуальных планов преподавателей и решений кафедры;
- контроль за систематическим проведением медицинских обследований и врачебно-педагогического контроля над студентами, занимающихся физическими упражнениями и спортом;
- разработку и проведение мероприятий по предупреждению спортивного травматизма на учебных занятиях;
- составление отчета кафедры по разделу учебной работы.
Диаграмма вариантов использования деятельности роль а Ответственный за учебную работу представлена на рисунке 1.5.
4. Преподаватель, ответственный за научную и учебно-методическую работу (заместитель зав. кафедрой), проводит следующую работу: - планирование, организацию и проведение на кафедре научной и учебно-методической работы;
- совершенствование учебной документации: рабочих учебных программ, графиков учебного процесса, планов-конспектов лекций, групповых занятий, индивидуальных тренировочных планов и др.;
- разработку и обоснование содержания и методики профессиональной прикладной физической подготовки студентов;
- подготовку методических пособий, указаний, разработок, необходимых для совершенствования учебно-воспитательного процесса;
- организацию и проведение на кафедре научных конференций;
- обсуждение на кафедре новой учебно-теоретической литературы;
- разработку и использование в учебном процессе наглядных пособий, технических средств, компьютерной техники, элементов программированного и проблемного обучения, тренажеров;
Рис. 1.5 - Модель деятельности ответственного за учебную работу
- контроль и оказание помощи в работе методического кабинета и научной лаборатории при кафедре;
- составление отчета кафедры по разделу научной и учебно-методической работы.
Диаграмма вариантов использования деятельности роли Ответственный за научную и учебно-методическую работу представлена на рисунке 1.6.
5. Преподаватель, ответственный за массовую оздоровительную, физкультурную и спортивную работу (заместитель зав. кафедрой), совместно со спортивной общественностью осуществляет: - руководство и контроль за планированием круглогодичного учебно-тренировочного процесса в спортивном учебном отделении и за качеством проведения спортивных соревнований;
- контроль за совершенствованием спортивного мастерства студентов-спортсменов высокой квалификации;
- планирование, организацию и проведение в вузе массовых оздоровительных и спортивных мероприятий среди студентов;
- проведение спортивных соревнований внутри вуза и руководство спортивными командами на внешних соревнованиях;
- развитие в вузе массового туризма, организацию и контроль за проведением туристских походов, слетов;
Рис. 1.6 - Модель деятельности ответственного за научную и учебно-методическую работу
- проведение анализа спортивной работы, обобщение и распространение в вузе передового опыта физкультурной и спортивной работы;
- руководство и контроль за работой по агитации и пропаганде физической культуры и спорта в вузе, по внедрению мероприятий физической культуры в повседневный быт студенческой молодежи;
- составление отчета кафедры по разделу массовой оздоровительной, физкультурной и спортивной работы.
Диаграмма вариантов использования деятельности РОЛИОТВЕТСТВЕННЫЙ за массовую оздоровительную работу представлена на рисунке 1.7.
6. Преподаватели, ответственные за работу в учебных отделениях (по виду спорта и виду занятий), обеспечивают: - планирование, организацию и проведение учебно-тренировочного процесса, организацию и подготовку спортивных команд и отдельных спортсменов для участия во внутри вузовских и внешних спортивных соревнованиях, проведение массовых оздоровительных, физкультурных и спортивных мероприятий в вузе, наглядной агитации и пропаганды по видам спорта;
- контроль за успеваемостью студентов-спортсменов на факультетах;
- составление отчета о работе, проделанной по видам спорта (видам занятий).
Диаграмма вариантов использования деятельности роли Ответственный за виды спорта представлена на рисунке 1.8.
Рис. 1.7 - Модель деятельности ответственного за массовую оздоровительную работу
7. Преподаватель, ответственный за работу по физическому воспитанию на факультете (заместителя декана по физическому воспитанию), входит: - комплектование групп во всех учебных отделениях для занятий по физическому воспитанию и контроль за перемещением студентов в течение учебного года;
- контроль за качеством и эффективностью учебного процесса по физическому воспитанию на факультете;
- организация и проведение на факультете контрольных соревнований и зачетов;
- оказание квалифицированной помощи спортивному совету факультета в планировании, организации и проведении на факультете массовых оздоровительных, физкультурных и спортивных мероприятий; в комплектовании спортивных команд факультета, подготовке и организации их для участия в спортивных соревнованиях на первенство вуза;
- содействие росту спортивного мастерства студентов-спортсменов высокой квалификации, помощь им в целях успешного сочетания обучения на факультете с активными занятиями спортом;
- проведение на факультете работы по наглядной агитации и пропаганде физической культуры и спорта;
Рис. 1.8 - Модель деятельности ответственного за работу в учебных отделениях
- ведение учета по всем разделам работы на факультете по физическому воспитанию и спорту, ежедневное сообщение на совете факультета информации о состоянии здоровья, физического развития и физической подготовленности студентов, а также о развитии спорта на факультете;
- составление отчета о работе по физическому воспитанию на факультете.
Диаграмма вариантов использования деятельности роли Ответственный за работу по физическому воспитанию представлена на рисунке 1.9.
Рис. 1.9 - Модель деятельности ответственного за работу по физическому воспитанию
На основании проведенного анализа можно выделить три основных подсистемы деятельности кафедры (см. рис. 1.10): учебной, научно-методической работы, а также оздоровительной и массовой работы. При этом подсистема учебной работы должна быть разбита на два компонента: собственно компоненты Учебная работа - характерная для всех кафедр университета, и Учебная работа обеспечивающая тематику кафедры.
Информационные технологии управления учебным процессом в РГЭУ (РИНХ) включают следующие: ИС «Контингент», подсистема «Успеваемость», программный комплекс электронного расписания занятий, подсистема «Электронная ведомость». Данные программные продукты не охватывают бизнес процессы, связанные с подсистемой Оздоровительной и массовой работы. Как показано выше, общевузовская система автоматизации не учитывает специфику функций кафедры физкультуры в части проведения тренировок и соревнований, как видов учебного процесса, а также учета физического состояния студентов в ходе обучения. На рисунке 1.10 представлена подсистема Учебная работа, обеспечивающая тематику кафедры. В результате выполнения дипломного проекта необходимо реализовать сервис «Учебный процесс кафедры физкультуры», обеспечивающий реализацию и внедрение данной подсистемы.
Рисунок 1.10 - Подсистемы деятельности кафедры физкультуры
1.3 Сбор и моделирование требований
Сбор требований - один из основных этапов анализа системы, обеспечивающий успешную реализацию проекта [12, 13]. Результатом проведения сбора требований служит техническое задание (ТЗ) на проект.
Сбор требований осуществляется путем непосредственного взаимодействия с сотрудниками Заказчика. В основе данного этапа работы лежит выявление потенциальных заинтересованных лиц в реализации проекта и потребителей услуг. В ходе сбора требований выявляются основные направления автоматизации и, далее, осуществляется сбор материалов о деятельности организации.
В процессе разработки требований для создания сервиса «Учебный процесс кафедры физкультуры»осуществлялся опрос потенциальных пользователей сервиса: преподавателей и методиста кафедры, т.е. непосредственно тех лиц, для которых разрабатывается сервис.
Кроме того проводился анализ литературы по современным тенденциям развития программного обеспечения для организаций, осуществляющих спортивную подготовку.
1.3.1 Описание использования системы
На основании проведенного анализа актуальности разработки подсистем Учебная работа,обеспечивающая тематику кафедры и Оздоровительной и массовой работы с сотрудниками кафедры физкультуры, выявлена потребность в автоматизации следующих прецедентов: - Обеспечение учебно-тренировочного процесса;
- Контроль за проведением профессионально-прикладной физической подготовки;
- Контроль замедицинским обследованием студентов;
- Комплектование групп;
- Учет результатов медицинского освидетельствования студентов;
- Анализ динамики состояния здоровья, физического развития и физической подготовленности;
- Разработка комплексов упражнений;
- Контроль перемещений студентов.
Таким образом, диаграмма вариантов использования системы будет иметь вид, представленный на рисунке 1.11.
Разработанный сервис должен обеспечивать возможность работы с ресурсами, как преподавателей кафедры, так и студентов, обучающихся на кафедре. Студенты кафедры должны иметь возможность выбора спортивной секции и группы занятий физической подготовкой, возможность определения уровня своей подготовленности, просматривать расписание занятий и тренировок, возможность мониторинга своего физического состояния. Диаграмма вариантов использования этой категории пользователей сервиса представлена на рисунке 1.12.
Рисунок 1.11 - Диаграмма вариантов использования сервиса Учебная работа обеспечивающая тематику кафедры
Рисунок 1.12 - Диаграмма вариантов использования РОЛИСТУДЕНТ
Включение студентов в разряд удаленных пользователей сервиса, предполагает необходимость реализации сервиса как сетевого Web-приложения. Кроме того, опрос преподавателей кафедры показал необходимость использования сервиса как источника справочной информации по спортивным и физическим нормативам обучающихся студентов, возможность предоставления информации о результатах спортивных соревнований, проводимых в рамках университета, по направлениям спортивной подготовки. Справочная и информационная составляющие сервиса могут быть доступны внешним пользователям - гостям сервиса. Однако саморегистрация на сервисе при обсуждении с заказчиками была признана нецелесообразной.
Наличие нескольких категорий пользователей системы предполагает необходимость разработки подсистемы авторизации, обеспечивающей как учет пользователей системы, так и защиту данных, обрабатываемых пользователями. Диаграмма вариантов использования подсистемы администрирования сервиса представлена на рисунке 1.13.Регистрация пользователей сервиса осуществляется администратором.
Рисунок 1.13 - Диаграмма вариантов использования подсистемы Администрирование
1.3.2 Определение терминов для описания требований
Реализация данных подсистем требует,прежде всего, рассмотрения основных понятий и документов, используемых сервисом, для администрирования состояния различных категорий пользователей: - Гость;
- Администратор;
- Преподаватель;
- Студент.
Категории ролей, принятые ранее при анализе системы на начальном этапе моделирования требований могут не рассматриваться, т.к. недостаточно проработан предметный функционал системы.
Выбор администратором категории пользователя определяется через меню. В зависимости от выбранной категории пользователя изменяется функционал сервиса в соответствии с реализацией основных вариантов использования системы.
Прецеденты, представленные на диаграмме вариантов использования администратора (см. рисунок 1.13), также предполагают определение сущностей: - Группа учебная, - Группа по физкультуре.
Свойства перечисленных сущностей связаны перечнями: - Специальность, - Должность, - Тип обучения.
1.3.3 Отображение рабочего процесса между пользователями и системой
Для отображения рабочего процесса между разными вариантами использования можно использовать диаграмму деятельности. На этой диаграмме отображается рабочий процесс выполнения деятельности. Так, например, представим диаграмму деятельности для выполнения прецедента «Назначить студента в группу», входящего в вариант использования показанный на рисунке 1.13, (см. рисунок 1.14). На данной диаграмме показаны потоки данных между действиями, в данном случае идентификаторы сущностей учебная и физкультурная группы, а также идентификатор сущности студент.
Рисунок 1.14 - Диаграмма деятельности прецедента «Назначить студента в группу»
1.4 Спецификация требований
В приложении А представлено техническое задание (ТЗ) на реализацию сервиса поддержки учебного и воспитательного процесса кафедры физкультуры.
Данное ТЗ разработано на основе предположения, что реализация сервиса будет происходить в несколько этапов. На первом этапе разрабатывается: - функционал деятельности администратора, обеспечивающего регистрацию пользователей различных категорий, - функционал, обеспечивающий наполнение сервиса справочными и информационными материалами, необходимыми для дальнейшего использования студентами и преподавателями кафедры, - карта сервиса, - функционал аутентификации пользователей сервиса для различных категорий, обеспечивающий возможности отображения меню сервиса данной категории пользователя.
Вывод
Проведен анализ российского законодательства в области информационной поддержки физического воспитания населения. Выявлены проблемы в реализации эффективных программных сервисов, обеспечивающих работу кафедр физической культуры ВУЗОВ.
На базе объектно-ориентированного подхода проведен анализ предметной области деятельности кафедры ФК,СИТ РГЭУ (РИНХ). Выявлены основные требования к сервису поддержки работы кафедры. Определены основные подсистемы сервиса и выявлены его пользователи.
Рассмотрены функции, обеспечивающие поддержку работы сервиса администратором ресурса. На основе проведенного анализа разработано техническое задание на сервис поддержки работы кафедры физкультуры.
2. Проектирование и разработка сервиса учебного процесса кафедры физкультуры
2.1 Архитектура сервиса
Базовая архитектура трехуровневой системы может быть представлена на основании разделения на уровни пользовательского представления, представления бизнес логики и представления данных. Для сервиса учебного процесса кафедры физкультуры представление пользователя делится на три составляющих, представленных на рисунке 2.1: - Представление преподавателя;
- Представление студента;
- Представление администратора.
Рисунок 2.1 - Концептуальная архитектура сервиса учебного процесса кафедры физкультуры
Современное Web-приложение основывается на технологии "клиент-сервер". Таким образом, его архитектура расширяется до трехуровневой. При такой архитектуре клиентский уровень занимает обозреватель, на уровне сервера находится сервер БД, а на промежуточном уровне размещаются Web-сервер и модули расширения сервера. Модуль расширения сервера выступает преобразователем протоколов между клиент-серверным приложением БД и Web-сервером. Структура приложения представлена на рисунке 2.2.
Выбор программного обеспечения Веб-сервера определяет технологию реализации Веб-приложения. Основными конкурентами среди Веб-серверов сегодня являются: - Apache HTTP-сервер - кроссплатформенное ПО, поддерживаемое операционными системами Linux, BSD, Mac OS, Microsoft Windows, Novell NETWARE, BEOS - 57,93% серверов;
- NGINXHTTP-сервер -сервер, работающий на Unix-подобных операционных системах, с версии 0.7.52 появилась бинарная сборка под Microsoft Windows - 12,18%серверов;
- IIS (Internet Information Services) - набор серверов для нескольких служб Интернета от компании Майкрософт. IIS распространяется с операционными системами семейства Windows NT - 12,14%.
Для реализации сервиса учебного процесса кафедры физкультуры выбран сервер IIS 7.0с операционной системой WINDOWSSERVER 2008 R2.IIS 7.0 поставляется вместе с библиотекой .NET Framework .
Шаблоном архитектуры программного обеспечения выбрана технология MVC .Net. Данный паттерн обеспечивает разделение данных, логики и интерфейса (см. рис. 2.3): - Model - часть приложения, содержащая в себе бизнес-логику, описывающую предметную область. Модель знает, как устроены данные и как с ними работать;
- Controller. - контролирует части программы, реагирует на какие-то события и, исходя из этого, влияет на модель или представление.
- View - часть приложения, визуализирующая модель данных. Обычно представление имеет прямой доступ к модели, но разрешено только чтение этих данных;
Рис. 2.3- Структура шаблона MVC
2.2 Проектирование интерфейса
Уровень представления Web-приложения критически важен при разработке системы и оказывает значительное влияние на степень принятия приложения пользователями. Уровень представления - это своего рода «парадная дверь» в приложение. Он обеспечивает выполнение бизнес-функций, представляемых приложением пользователям, а также визуальное представление информации, которой управляет приложение. Эффективность пользовательского интерфейса значительно влияет на успех приложения в целом [20].
Благодаря бурному росту Интернета (особенно облачным вычислениям и появлением различных типов устройств) разработка уровня презентаций в приложении становится довольно непростой задачей.
Производительность - главное требованием к Web-приложению. Максимальное время выполнения операций не должно превышать 3-10 с.
1. Дружественность к пользователю. Приложение должно быть простым в использовании и навигации с очевидными инструкциями, не вводящими пользователя в заблуждение.
2. Интерактивность и широкие возможности. Пользовательский интерфейс должен быть интерактивным и отзывчивым. Кроме того, уровень представления должен быть обогащенный в визуальном смысле, включая диаграммы, drag-and-drop компоненты, ползунки для изменения данных, интерфейс в виде панелей и т.п.
3. Доступность. В наши дня пользователи требуют, чтобы приложение было доступным, в том числе и на мобильных устройствах.
Для структуры макета сервиса Учебная работа кафедры ФВ,СИТБЫЛА принята концепция «резинового» макета, который подразумевает информация будет занимать пространство, подстраиваясь под разрешение. Используется решение с адаптивным web-дизайном, когда определены основные разрешения (размеры экрана), под которые адаптируется контент.
Структура макета главной страницы сервиса для мониторов с большим разрешением, представлена на рисунке 2.4. Макет включает области заголовка (heder), навигации (sidebar), контента страницы (content) и нижнего колонтитула (footer). Для главной страницы введено понятие максимальной ширины в 1280 пикселов, что обусловлено удобством восприятия информации на больших мониторах. В этом случае информация не будет растягиваться так, что ее неудобно будет читать.
Рисунок 2.4 - Структура макета главной страницы
Для мониторов мобильных устройств макет главной страницы использует горизонтальную навигацию, скрывает фоновые изображения. Структура макета представлена на рисунке 2.5.
Реализация структуры сайта приведена в листинге 2.1. При верстке сервиса использован блочный подход. Таблицы используются только для своей прямой роли - представление информации в виде таблицы.
Код HTML создает скелет страницы, ее абстрактную модель при помощи тэгов (языка разметки HTML). При написании разметки прописываются классы и идентификаторы.
Рисунок 2.5 - Структура макета главной страницы для мобильных устройств
Для создания единообразного вида сайта применяются в MVC .Netприменяются мастер-страницы. Мастер-страницы - это по сути те же самые представления. На мастер-странице определяются некоторые элементы, которые будут отображаться на всех страницах сайта. А также определяются заполнители или плейсхолдеры, содержание которых обеспечивают другие представления.
Листинг 2.1 показывает мастер-страницу _Layout.chtml. На вид это обычное представление за одним исключением - вызовов методов @RENDERBODY() и @RENDERSECTION("featured", required: false). Эти два вызов является плейсхолдерами, на место которых другие представления, которые используют эту мастер-страницу, будут подставлять свое содержимое. И таким образом, мы можем легко установить для представлений веб-приложения единообразный стиль.
Листинг 2.1 - Реализация структуры проекта
2.3 Проектирование и разработка БД сервиса
При проектировании базы (БД) данных создаются два уровня модели - логический и физический. Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире[19].
На рисунке 2.9 представлена концептуальная модель БД подсистемы администрирования сервиса. Ключевой сущностью модели является сущность Лицо, определяющая основные атрибуты пользователей системы различных категорий. С этой сущностью связаны справочники Паспорт и Пол (отношение один ко многим). Категории пользователей системы задаются сущностями Студент и Преподаватель, которые связаны с сущностью Лицо отношением один к одному. Сущность Студент связана с сущностями Специальность и Тип обучения отношением один ко многим. Отношение между сущностями Студент и Группа - многие ко многим. Это связано с тем, что одним из определяющих атрибутов сущности Группаявляется атрибут Курс, который для студента изменяется по времени обучения.
Представленные на рисунке 2.9 сущности USERPROFILE, webpages_Rolesи webpages_Membership определяют роль пользователя системы, справочник ролей (Гость, Студент, Преподаватель или Администратор) и параметры входа пользователя в систему. Данные сущности создаются автоматически при использовании шаблона приложения MVC в среде VISUALSTUDIO.
Рис. 2.9 - Концептуальная модель БД подсистемы администрирования
Разработка модели БД проводилась средствами MSVISUALSTUDIO2013 с использованием на модели ADO.NETEDM[22]. Данная модель - это модель "сущность-связь" - Entity Data Model (EDM), описанная Питером Ченом в 1976 году. Данная модель представляет собой набор основных понятий, которые описывают структуру данных независимо от формы хранения.
Средства для работы с моделями EDM служат для построения приложений Entity Framework. С помощью средств модели EDM можно создать концептуальную модель на основе существующей базы данных, а затем создать ее графическое представление и внести нужные изменения. Либо можно сначала создать концептуальную модель с помощью графических средств, а затем создать базу данных, которая поддерживает эту модель. В любом случае можно автоматически обновлять модель при изменении основной базы данных и автоматически создавать код объектного уровня для приложения. Процессы создания базы данных и создания кода объектного уровня допускают настройку.
В следующем списке описаны средства, входящие в состав средств для работы с моделями EDM.
1. Конструктор моделей EDM ADO.NET (конструктор сущностей) позволяет с помощью визуальных средств создавать и изменять сущности, ассоциации, сопоставления и связи наследования. Конструктор сущностей также формирует код уровня объекта на языке C# или Visual Basic.
2. Мастер моделей EDM дает возможность построить концептуальную модель на основе существующей базы данных и добавить в приложение сведения о подключении базы данных.
3. Мастер создания базы данных позволяет сначала создать концептуальную модель, а затем создать базу данных, поддерживающую эту модель.
4. Мастер обновления моделей позволяет обновить концептуальную модель, модель хранения и сопоставления, если в основную базу данных внесены изменения.
На основе концептуальной модели создана БД проекта, реализованная в MSSQLSERVER 2008 R2. Структура и связи таблиц представлены рисунке 2.10.
Рисунок 2.10 - Структура таблиц подсистемы администрирования
DDLСЦЕНАРИЙ создания БД для учебного процесса кафедры физкультуры представлен в Приложении В. Данный сценарий прописывает пути размещения файла БД и файла журнала, создает БД SPORTEDUCATION, включает функции настройки ее параметров. Далее в сценарии создаются таблицы, представленные на рис. 2.10. Последней частью сценария является установка связей между таблицами, формирование вторичных ключей и условий целостности данных.
2.4 Структура проекта
Web-сервис разрабатывается в VISUALSTUDIO 2013, как ПРОЕКТSPORTEDUCATION. Разработка проекта осуществлялась на основе мастера Веб-приложение ASP.NETMVC 4. На рисунке 2.11 представлена страница выбора данной категории проекта. На рисунке 2.12 представлен выбор шаблона проекта: Интернет-приложение на базе обработчика представлений Razorc созданием проекта разработки модульных тестов - SPORTEDUCATION.Tests.
Полученная структура проекта представлена на рисунке 2.13.
Рис. 2.11. - Открытие шаблона создания проекта SPORTEDUCATION
Рис. 2.12. - Открытие шаблона создания проекта SPORTEDUCATION
Рис. 2.13. Структура проекта SPORTEDUCATION
Данный проект, как и все проекты MVC содержит следующие папки: App_Data, Content, Controllers, Models, Scripts и Views.В дополнение к данным папкам сгенерированное веб-приложение MVC использует код в файле Global.asax для установки глобальных параметров маршрутизации URL-адресов по умолчанию, а также использует файл Web.config для настройки приложения.
App_Data - папка области физического хранилища данных. Эта папка выполняет те же функции, что и для вебсайтов ASP.NET, которые используют страницы веб-форм.
Content - папка для рекомендуемого расположения файлов содержимого (например, файлов каскадных таблиц стилей, изображений и пр.). В общем случае папка Content предназначена для статических файлов.
Controllers - папка для рекомендуемого расположенияконтроллеров. Имена контроллеров в платформе MVC должны оканчиваться на "Controller", например HOMECONTROLLER, LOGINCONTROLLER или PRODUCTCONTROLLER.
Models - предназначена для классов, которые представляют модель приложения для веб-приложения MVC. Эта папка обычно содержит код, который определяет объекты и логику взаимодействия с хранилищем данных. Сами объекты модели обычно располагаются в отдельных библиотеках классов. Тем не менее, при создании нового приложения классы можно расположить в этой папке, чтобы переместить их в отдельные библиотеки на более поздней стадии разработки.
Scripts - рекомендуемое расположение для файлов скриптов, поддерживающих приложение. Эта папка по умолчанию содержит файлы платформы ASP.NET Ajax и библиотеку JQUERY.
Views - рекомендуемое расположение для представлений. Представления используют файлы VIEWPAGE (ASPX), VIEWUSERCONTROL (ASCX) и VIEWMASTERPAGE (MASTER) в дополнение к остальным файлам, которые связаны с отображением представлений. Папка Views содержит папки для всех контроллеров. Название папки состоит из префикса имени контроллера. Например, если существует контроллер с именем HOMECONTROLLER, то в папке Views будет вложенная папка с именем Home. При загрузке представления платформой ASP.NET MVC в папке "Views\имя_контроллера" по умолчанию выполняется поиск файла VIEWPAGE (ASPX), который имеет имя требуемого представления. По умолчанию в папке Views находится папка Shared, которая не соответствует ни одному контроллеру. Папка Shared используется для представлений, которые используются на нескольких контроллерах. Например, главную страницу веб-приложения можно поместить в папку Shared.
2.5 Клиентская часть
Разработка клиентской части приложения осуществляется в папке Views с использованием файлов MASTERPAGE. MASTERPAGE представляет собой шаблон страницы, при этом, она может содержать любые элементы, допустимые для обычной страницы, а также программный код. Страница содержимого содержит допустимые элементы управления, с помощью которых определяет содержимое, которым заполняются специальные области мастер страниц. Каждая страница содержимого ссылается на одну мастер страницу, от которой получает элементы и их расположение.
MASTERPAGE содержит фиксированные элементы, одинаковые для всех страниц, и заполнитель содержимого для остальной части страницы. Фиксированными элементами являются верхний и нижний колонтитулы, панель навигации, панель меню и т.д. Страница содержимого получает от мастера страницы фиксированные элементы и предоставляет дополнительное содержимое.Структура MASTERPAGE показана в листинге 2.1 подраздела 2.2.
Как указывалось в подразделе 2.2 вызов плейсхолдера на MASTERPAGE обеспечивает загрузку различных представлений и поддерживает единообразие стиля страниц Web-приложения. На рисунке 2.14 представлена структура файлов-представлений для контроллеров поддерживающих реализацию функционала Web-приложения, расположенных в папке Views.
На рисунке показаны файлы представления для контроллеров: ACCOUNTCONTROLLER, ПОЛЬЗОВАТЕЛИCONTROLLER, а также содержимое папки Shared, содержащей компоновки и представления, не являющиеся специфичными для какого-либо контроллера. Представления контроллера Account Controller обеспечивают ввод, изменение логина, авторизацию и регистрацию пользователя. Представления контроллера Пользователи Controller обеспечивают создание, удаление пользователя, редактирование его свойств, просмотр списка пользователей.
На рисунке 2.15 показана реализация пользовательской страницы Регистрация, которая обеспечивает ввод нового пользователя системы.
Рис. 2.14. Структура файлов приложений проекта SPORTEDUCATION
Рис. 2.15. Внешний вид страницы регистрации пользователя
2.6 Организация взаимодействия с БД
Как указывалось в разделе 2.3 взаимодействие с источником данных MVCПРИЛОЖЕНИЯ базируется на модели EDM. Модель EDM представляет набор основных понятий, которые описывают структуру данных независимо от формы хранения. Данные Web-сервиса хранятся на SQLSERVER.В результате такого подхода, форма хранения данных отделена от приложения и не влияет на его разработку. Это обеспечивается тем, что сущности и связи описывают структуру данных так, как она используется в приложении. Модель EDM использует три основных понятия для описания структуры данных: - тип сущности;
- тип ассоциации;
- свойство.
Структура концептуальной модели передается при помощи доменного языка (DSL).Платформа ADO.NET Entity Framework использует язык DSL на основе XML, называемый языком CSDL, для определения концептуальных моделей. Файл метаданных концептуальной модели представлен в Приложении В.
Структура модели данных представлена на рисунке 2.16.
В проекте автоматически сгенерируется классе nterprise _order Entities1, который наследуется от класса Object Context, представляет сущности базы данных Sport Education, содержит свойства, моделирующие таблицы и связи между таблицами.
При создании модели данных в проекте автоматически сгенерирован конфигурационный файл Web.config, который содержит строку соединения с базой данных (см. листинг 2.2).
Листинг 2.2 - Код для строк соединения с базой данных
Рис. 2.16 Структура модели данных
2.7 Развертывание сервиса
Завершающим и критически важным шагом разработки веб-приложений является развертывание. Рассмотрим развертывание приложения SPORTEDUCATION.
Существует множество разнообразных способов развертывания приложений MVC Framework, а также широкий спектр целевых платформ, предназначенных для развертывания. Приложение может быть развернуто: - на машине Windows Server с Internet Information Services (IIS), что предполагает локальное управление, - с помощью службы удаленного хостинга, самостоятельно управляющей серверами, - в облачной инфраструктуре, обеспечивающей работу и масштабирование приложения.
Тестовая версия разработанного Web-сервиса была размещена на виртуальном сервере (VPS) компании INFOBOX. WINDOWSVPSСЕРВЕРА данной компании располагаются в Амстердаме и Санкт-Петербурге, имеют архитектуру на быстрых SSD (сверхпроизводительных твердотельных накопителях), имеют минимальный ping до городов России и СНГ. На серверах устанавливается лицензионная ОС WINDOWSSERVER. НАVPSУСТАНОВЛЕНА ОС WINDOWSSERVER 2012 r2, веб-сервер IIS 7.0, СУБД MSSQLSERVER 2008 r2.
Управление данным сервером осуществляется через удаленный рабочий стол.
Web-сервис публикуется на веб-сервере IIS. Вначале осуществляется конфигурирование веб-сервер. Для этого открывается средство администрирования IIS. Необходимо зайти в Панель управления, затем выбрать Администрирование->Диспетчер служб IIS. Откроется консоль управления IIS, представленная на рисунке 2.17.
Рис. 2.17. Консольуправления IIS
Вначале происходит настройка пула приложений. Для этого вызывается функция добавления пула приложений, как показано на рисунке 2.18. В окне добавления пула приложений указывается имя Web-приложения и версия среды .NETFRAMEWORK. Для устанавливаемого Web-сервиса это .NETFRAMEWORK версии 4.0.
Рис. 2.18. Добавление пула приложений
Следующим шагом является добавление сайта SPORTEDUCATION, как показано на рисунке 2.19.
Рис. 2.19. Добавление нового Web-приложения
После введения параметров нового Web-приложения можно переходить к опубликованию приложения в VISUALSTUDIO. Для этого необходимо нажать правой кнопкой на название проекта и в появившемся меню выбрать Опубликовать, как показано на рисунке 2.20.
Рис. 2.20. Выбор меню Опубликовать
Открывается мастер публикации, который предложит пройти несколько этапов. Вначале выбираем профиль, как представлено на рисунке 2.21. Так как профиль новый, то определяем имя профиля. В нашем случае публикация осуществляется в локальной системе и, лишь, потом папка с опубликованными файлами переносится на удаленный сервер. Поэтом далее осуществляем выбор или создание папки для размещения файлов. На диске C:// создаем папку SPORTEDUCATION (см. рис. 2.22).
На вкладке Подключение определяем тип подключения как файловую систему и указываем целевое назначение (см. рис. 2.23). На рисунке 2.24 показан последний шаг - это просмотр полученных файлов в созданной папке.
Рис. 2.21. Выбор профиля публикации
Рис. 2.22. Создание папки для размещения публикуемых файлов
Рис. 2.23. Определение типа размещения файлов
Рис. 2.24. Просмотр содержимого подключения
Папка с полученными файлами переносится на виртуальный сервер.
При такой настройке Web-сервера нужно помнить, что базу данных требуется переносить на сервер вручную.Проведен выбор архитектуры Web-сервиса «Учебный процесс кафедры физкультуры» как трехуровневого Web-приложения. Проведена разработка интерфейса сервиса. Разработана база данных проекта для подсистемы администрирования сервиса.
Разработано Web-приложение SPORTEDUCATIONНА базешаблона MVC .Net 4.0. Рассмотрены основные аспекты программирования данного приложения. Проведено развертывание сервиса на Web-сервере.
3. Надежность и эффективность Web-сервиса
3.1 Оценка надежности Web-сервиса
Надежность сайта - эксплуатационное качество сайта, характеризующееся вероятностью безотказной работы сайта в определенный промежуток времени при сохранении параметров, заданных в техническом задании на сайт.
Если говорить о надежности сайта с точки зрения бизнеса, то надежность сайта - способность сайта, в определенный период времени, оставаться конкурентоспособным среди сайтов аналогичной тематики и одной ценовой категории.
Так как Web-сервис «Учебный процесс кафедры физкультуры» не предусматривает завоевание пользовательской аудитории, а является сервисом для обеспечения учебной деятельности, то при анализе надежности сайта следует исходить из первого определения, связанного с безотказной работой.
Критерии надежности сайтов отличаются для статических и динамических сайтов. Для статических сайтов характеристики надежности связаны со временем безотказной работы.
О надежности сайта, в зависимости от срока его автономной работы, можно судить по следующим критериям, приведенным в таблице 3.1.
Таблица 3.1 - Характеристика надежности
Лет Характеристика надежности сайта Примечание
2 и более Очень высокая надежность сайта. Владельцу сайта повезло. Очень высокое качество сайта.
1,5-2 Высокая надежность сайта. Высокое качество сайта.
1-1,5 Надежный сайт. Сайт создан профессиональным веб-дизайнером. Сайт качественный .
0,5-1 Низкая надежность сайта. Качество сайта ниже среднего. менее 0,5 Очень низкая надежность сайта. Владельцу сайта не повезло. Очень низкое качество сайта.
Разработанный Web-сервис является динамическим ресурсом, функционирование которого связано с управлением данными. Для таких ресурсов критерии надежности связаны с правильностью выполнения запросов к БД.
3.2 Оценка стоимости проекта
Проект - это уникальный процесс, в ходе выполнения которого получают уникальный продукт. Таким образом, для разработки продукта в проекте, скорее всего, должен применяться уникальный процесс. Разработчики могут воспользоваться обобщенной, проверенной на практике методикой, адаптировав ее для конкретного проекта. Как правило, всегда есть возможность выбора среди нескольких «начальных» жизненных циклов (ЖЦ). Жизненный цикл - непрерывный процесс, который начинается с момента принятия решения о необходимости создания ИС и заканчивается в момент ее полного изъятия из эксплуатации.
Определим модель ЖЦ проектирования на основе методики предложенной в работе Т. Фатрелла [23].
Таблицы обоснования выбора модели представлены в приложении Д. Сводный результат анализа представлен в таблице 3.2.
Таблица 3.2- Определение оптимальной модели жизненного цикла, в баллах
Характеристика Каскадная V-образная Прототипирование Спиральная RAD Инкрементная
Требования 4 4 3 1 5 3
Участники команды разработчиков 4 5 5 2 8 5
Коллектив пользователей 4 7 6 9 8 7
Типы проектов и рисков 2 2 4 2 5 4
Итого 14 18 18 14 26 19
Из приведенных данных можно сделать следующие выводы. Для разрабатываемого Web-сервиса, наиболее подходящей моделью ЖЦ является метод быстрой разработки приложений «RAD».
Характерной чертой «RAD» является короткое время перехода от определения требований до создания полной системы. Метод основывается на последовательности итераций эволюционной системы или прототипов, критический анализ которых обсуждается с заказчиком. В процессе такого анализа формируются требования к продукту. Разработка каждого интегрированного продукта ограничивается четко определенным периодом времени, который, как правило, составляет 60 дней и называется временным блоком.
Форелью, позволяющие создать систему за 60 дней, причем без ущерба качеству, включает в себя использование мощных инструментальных средств разработки, высокий уровень повторного использования, а также осмысления и выделенные ресурсы.
При выполнении нашего проекта, для которого модель «RAD» подходит в достаточной мере, появляются следующие преимущества: - время цикла разработки для всего проекта можно сократить благодаря использованию мощных инструментальных средств;
- существует возможность произвести быстрый изначальный просмотр продукта;
- благодаря принципу временного бока уменьшаются затраты и риск, связанный с соблюдением графика;
- благодаря сокращенному времени цикла и усовершенствованной технологии, а также меньшему количеству задействованных в процессе разработчиков уменьшаются затраты;
- модель обеспечивает эффективное использование имеющихся в наличии средств и структур;
- привлечение заказчика на постоянной основе сводит до минимума риск того, что он не будет удовлетворен разработанным продуктом, кроме того, это гарантирует, что система будет соответствовать коммерческим потребностям, а сам программный продукт будет надежен в эксплуатации;
- в состав каждого временного блока входит анализ, проектирование и внедрение (фазы отделены от действий);
- интеграции констант предотвращают возникновение проблем и способствуют созданию обратной связи с потребителем;
- основное внимание переносится с документации на код, причем соблюдая принцип «получите то, что видите»;
- в модели используются следующие принципы и инструментальные средства моделирования: деловое моделирование (методы передачи информации, место генерирования информационных потоков, кем и куда направляется, каким образом обрабатывается); моделирование данных (происходит идентификация объектов данных и атрибутов, а также взаимосвязей); моделирование процесса (выполняется преобразования объектов данных); генерирование приложения (метод четвертого поколения);
- в модели повторно используются компоненты уже существующих программ.
3.3 Создание пооперационного перечня работ
Для успешного создания уникального продукта или услугb необходимо, прежде всего, осуществить некоторую последовательность работ. Основная задача планирования проекта заключается в достаточно точной оценке сроков исполнения и стоимости этих работ. Чтобы добиться наивысшего качества плана проекта необходимо дать как можно более точную оценку сроков исполнения и стоимости работ. Точную оценку можно дать только в том случае, если хорошо представлен состав работ по выполнению проекта, то есть те работы, которые необходимо выполнить для получения необходимого результата. Как только мы составили список всех проектных работ, производится оценка длительности каждой из них, а также выделяются необходимые ресурсы для их выполнения. И только после всего этого можно будет оценить стоимость и сроки выполнения проекта. Именно поэтому определение состава работ является первым и наиболее важным шагом при планировании проекта.
Модель RAD, представляет собой специальный случай линейной модели. Главной отличительной чертой этой модели является то, что для нее присущ чрезвычайно короткий цикл разработки ПО, при осуществлении которого используется конструкция, основанная на компонентах. Для данного дипломного проекта была выбрана модель RAD и посредством ее показана версия задач и действий, необходимых для построения жизненного цикла Web-сервиса кафедры физкультуры.
Показанный на рисунке 3.1 перечень действий и задач, представляет собой схему жизненного цикла Web-сервиса и состоит из четырех фаз: - планирование и активизация проекта;
- фаза планирования требований;
- фаза описания пользователя;
- фаза «расчистки».
Рисунок 3.2 - Пооперационный перечень
После того как разработчик определился с составом и результатами этапов проекта, необходимо определить последовательность этих этапов относительно друг друга и сроков выполнения каждого этапа. После этого необходимо определить работы, составляющие каждый этап, последовательность исполнения этих работ, а также сроков выполнения всех этих работ. Например, этап «начало выполнения проекта» делится на: - установку соответствия между действиями и планом;
- распределение ресурсов проекта;
- установку среды проекта;
- планирование управлением проекта.
Данный жизненный цикл разработан для полноценно функционирующего Web-сервера учебного процесса.
Создание структуры пооперационного перечня работ влечет за собой декомпозицию полномасштабного действия (всего проекта) на ряд последовательных и меньших действий. Этот процесс продолжается до тех пор, пока не будут подробно описаны все детали предстоящей работы, что в свою очередь, позволит реализовать надлежащее управление этой работой. В любом случае идентификация корректных действий представляет собой дело первоочередной важности.
Разрабатываемый Web-сервис включает в себя: - анализ функций на уровне системы/продукта;
- разработку системной архитектуры;
- декомпозицию системных требований;
- уточнение и разработку требований к ПО;
- определение требований к интерфейсу;
- изучение выполнимости - выполнение имитаций и сравнительных тестов;
- анализ проекта - проектирование на основе предварительно сформулированных требований;
- создание БД - идентификация предварительных элементов БД;
- проектирование пользовательского интерфейса - определение порядка взаимодействия интерфейса с пользователем, проектирование алгоритмических функций;
- планирование следующей фазы.
Идентификация задач представлена на рисунке 3.2.
3.4 Эффективность проекта
Расчет экономической эффективности для данного дипломного проекта не целесообразен, так как разрабатываемая подсистема не направлена на непосредственное увеличение прибыли РГЭУ (РИНХ). Реализация проекта улучшает систему ведения учебного процесса.
Для оценки эффективности воспользуемся методом экспертных оценок. Метод расчета в данном случае состоит из нескольких этапов: - выделить цели работы системы;
- определить наборы показателей, характеризующих определенную цель;
- определить уровень достижения показателя;
- рассчитать степень достижения каждой цели по выдвинутым показателям;
- определить весовые коэффициенты целей;
- рассчитать общий показатель эффективности разрабатываемой информационной системы;
Степень достижения цели рассчитывается как средняя величина достижения частных показателей. Формула расчета имеет следующий вид: , (4.1)
Где - степень достижения цели, баллы;
- значение показателя, баллы;
- количество показателей.
Весовой коэффициент вычисляется по формуле: , (4.2)
Где - весовой коэффициент, баллы;
- оценка, баллы.
Расчет оценки ведется по формуле: , (4.3) где - оценка, баллы;
- минимальное значение ранга, баллы;
- сумма рангов, баллы.
Для расчета суммы рангов воспользуемся формулой: , (4.4)
Где - сумма рангов, баллы;
- значение, выставленное экспертом, баллы;
- количество экспертов.
При этом проверяется согласованность мнений экспертов путем расчета значения известного коэффициента q Кендала (конкордации), для оценок данных экспертами.
Общий показатель эффективности рассчитывается как:
, (4.5)
Где - показатель эффективности, баллы;
- весовой коэффициент, баллы;
- степень достижения цели, баллы.
Теперь, рассмотрев общие положения методики оценки информационной системы, перейдем к расчету конкретного показателя эффективности работы ИС. Для начала, определим цели и показатели работы системы, а так же укажем уровень достижения показателей при создании прототипа. Все это сведем в таблицу (таблица 4.2).
Таблица 4.2 - Цели, показатели и уровень достижения работы ИС
Цель Показатель Уровень достижения, баллы Рассчитаем степень достижения целей g1 - технический уровень y11 - минимизация количества ошибок при автоматическом формировании отчетов 0,91 0,94 y12 - автоматизированный процесс формирования учебных групп 1 y13 - автоматизация регистрации преподавателей и студентов на сервисе 0,95 g2 - коммуникация y21 - оперативность 0,8 0,85 y22 - удобство использования 0,9 g3 - социальные цели y31 - улучшение условий труда 0,95 0,91 y32 - удобство работы 0,85 y33 - уменьшение времени выполнения работ 0,95 g4 - получение отчетности y41 - автоматическое получение отчетов 0,87 0,94 y42 - уменьшение объема рутинной работы преподавателей кафедры 1 g5 - простота использования y51 - легко понимаемый интерфейс пользователя 0,95 0,86 y52 - возможность поиска 0,75 y53 - возможность сохранения, извлечения и редактирования документов 0,89
Округлим полученные результаты и выведем степень достижения целей.
Чтобы определить весовые коэффициенты был применен экспертный опрос десяти человек. Список опрошенных приведен в таблице 4.3.
Таблица 4.3 - Список опрошенных
ФИО опрошенного Должность
Денисов Е.А, зав. кафедрой
Ключкина Г. О Доцент
Степанов В.В. Доцент
Дорофеев А.С. Преподаватель
Никитина Н.В. Преподаватель
Сладков И.Р. Преподаватель
Сергеев А.И. Преподаватель
ГАЛКИНИ.А. Студент
Шишкина О.В. Студент
Герман И.С. Студент
Результаты опроса представлены в таблице 4.4. В данной таблице также рассчитаны суммы рангов: R1=33, R2=22, R3=31, R4=33, R=31, минимальный из которых составляет 22, рассчитаны оценки : V1=0,6(6), V2=1, V3=0,71, 0,6(6), 0,71, определена общая оценка: , рассчитан показатель эффективности: Таким образом, можно сказать, что эффективность работы разработанной нами информационной системы по отношению к заданным целям составляет 0,91 балл, таким образом, только на 90% система работает оптимально. Неэффективность работы ИС составляет 10%.
Таблица 4.4 - Результаты опроса и расчет показателей
Степень достижения цели, g(i) 0,94 0,85 0,91 0,94 0,86
Показатель эффективности, E 0,8952149
На основании представленных расчетов можно утверждать, что реализация и внедрение Web-сервис Учебная работа обеспечивающая тематику кафедры является целесообразным.В третьей главе произведено обоснование выбора жизненного цикла информационной системы и выделено, что наиболее оптимальным вариантом модели является модель RAD. Создана структура пооперационного перечня работ (проект создания информационной системы реализован в Microsoft Project). Определены используемые в проекте ресурсы и на последнем этапе проведена оценка эффективности прототипа ИС, которая показала, что внедрение проекта целесообразно.В дипломной работе рассмотрена деятельность кафедры физкультуры РГЭУ (РИНХ). В результате проведенного анализа выявилась актуальность автоматизации бизнес-процессов кафедры в свете постановлений правительства Российской федерации по вопросам развития физкультуры и спорта. В ходе проведенного анализа было показана ограниченность существующих решений по автоматизации предметной области кафедр физкультуры. В связи с этим представляет интерес разработка Web-сервиса, обеспечивающего деятельность кафедры в плане активизации учебного процесса путем использования информационных технологий.
В ходе выполнения дипломного проекта был спроектирован и РАЗРАБОТАНWEB-СЕРВИСУЧЕБНАЯ работа обеспечивающая тематику кафедры. Для этого: 1) был проведен анализ бизнес-процессов деятельности кафедры ФВ,СИТ;
2) был выбран объектно-ориентированный подход к реализации приложения;
3) были выбраны следующие программные продукты для разработки приложения: - Microsoft Visual Studio 2013;
- Microsoft SQL Server 2008;
- MS Project 2010;
- MS Word 2010;
- MS Power Point 2010.
На этапе логического проектирования были построены диаграмма деятельн
Список литературы
1. Распоряжение Правительства РФ от 07.08.2009 N 1101-р «Об утверждении Стратегии развития физической культуры и спорта в Российской Федерации на период до 2020 года» [Электронный документ] / КОНСУЛЬТАНТПЛЮС. URL: www.consultant.ru (Дата сохранения: 01.04.2016).
2. Постановление Правительства РФ от 21.01.2015 N 30 «О федеральной целевой программе "Развитие физической культуры и спорта в Российской Федерации на 2016 - 2020 годы» [Электронный документ] / КОНСУЛЬТАНТПЛЮС. URL: www.consultant.ru (Дата сохранения: 04.04.2016).
3. Федеральный закон от 04.12.2007 N 329-ФЗ (ред. от 03.11.2015) "О физической культуре и спорте в Российской Федерации" [Электронный документ] / КОНСУЛЬТАНТПЛЮС. URL: www.consultant.ru (Дата сохранения: 01.04.2016)
4. Воронов, И.А. Информационные технологии в физической культуре испорте: [Электронный учебник] / И.А. Воронов; СПБ ГУФК им. П.Ф. Лесгафта. -СПБ.: изд-во СПБ ГУФК им. П.Ф. Лесгафта, 2005 - 80с.URL:http://sat.ru/attachments/Information_technologies_in_physical_training_and_sports.pdf Загл. с экрана.(Дата сохранения: 04.04.2016)
5. Журавлев В.А., Ананьин В.Г. Использование информационных технологий в физической культуре и спорте. //Современные информационные технологии в физической культуре и спорте: Тез.докладов Международной научно-практической конференции, посвященной 70-летию образования Удмуртского государственного университета /Под общ. ред. проф. П.К. Петрова - Ижевск: Издательский дом "Удмуртский университет", 2001. С. 27-29.
7. Спортивный клуб «Медик». [Электронный ресурс] /РОСТГМУ. URL: Загл. с экрана. (Дата сохранения: 04.04.2016)
8. Положение об управлении по физической культуре и спорту РГЭУ (РИНХ) [Электронный документ] / РГЭУ (РИНХ). 2015. URL: (Дата сохранения: 04.04.2016)
9. Роль физического воспитания и спорта в подготовке молодежи в перспективе непрерывного образования // Спорт, духовные ценности, культура. - М., 1997. - Вып. 7. - С. 10-16. [Электронный документ] / Центральная отраслевая библиотека по физической культуре и спорту. URL: 10. Приказ Госкомвуза РФ от 26.07.1994 N 777 Об организации процесса физического воспитания в высших учебных заведениях. [Электронный документ] / КОНСУЛЬТАНТПЛЮС. URL: www.consultant.ru (Дата сохранения: 04.04.2016)
11. Методические основы управления ИТ-проектами: учебник / В.И. Грекул, Н.Л. Коровкина, Ю.В. Куприянов. - М.: ИНТЕРНЕТУНИВЕРСИТЕТ Информационных Технологий: БИНОМ. Лаборатория знаний, 2010. - 391 с.
12. Вигерс, К. Разработка требований к программному обеспечению./Пер. с англ. М.: Издательско-торговый дом «Русская редакция», 2004.
13. Рапопорт Л.А. Спорт в вузе: проблемы организации. Теория и практика физической культуры. Научно-теоретический журнал. № 8 - 2001. [Электронный документ]URL: (Дата сохранения: 04.05.2016)
14. Строшков В.П., Строшкова Н.Т. Программно-аппаратные средства автоматизированного сбора и анализа данных о физическом состоянии организма человека, подвергающегося тренировочным нагрузкам. - Российский государственный профессионально-педагогический университет, Уральский федеральный университет. [Электронный документ] Сайт: Журнал тренера. URL:.
15. Теория и методика физического воспитания. Учебник для ин-тов физ. культуры. Под общей ред. Л.П. Матвеева и Ф.Д. Новикова. Изд. 2-е, испр. И доп. (В 2-ч т.). М., «Физкультура и спорт», 1976.
16. Основы спортивной тренировки. Учебное пособие для ин-тов физ. культуры. Под редакцией Л.П. Матвеева. М., «Физкультура и спорт», 1977.
17.
18. Создание Web-страниц и Web-сайтов. Самоучитель : [учеб. пособие] / под ред. В. Н. Печникова. - М.: Изд-во Триумф, 2006.- 464 с.
19. URL: (Дата сохранения: 24.05.2016)
20. А. Д. Хомоненко, В. М. Цыганков, М. Г. Мальцев. Базы данных. Учебник для вузов // Издание: Корона-принт, 2004 г.
21. Средства модели ADO.NETEDM. Microsoft | DEVELOPERNETWORK. URL: (Датасохранения: 24.05.2016)
22. Фатрелл, Т. Управление программными проектами: достижение оптимального качества при минимуме затрат.: Пер. с англ. / Р.Т. Фатрелл, Д.Ф. Шафер, Л.И. Шафер. - М.: Издательский дом «Вильямс», 2003