Анализ и моделирование бизнес-процессов системы физкультурно-спортивного воспитания населения на примере РГЭУ (РИНХ)

Введение

Правительством Российской Федерации в августе 2009 г. утверждена «Стратегия развития физической культуры и спорта в Российской Федерации на период до 2020 года» [1] (далее Стратегия), а в январе 2015 г.федеральная целевая программа «Развитие физической культуры и спорта в Российской Федерации на 2016 - 2020 годы»[2] (далее Целевая программа). Одной из основных целей этих документов является создание условий, обеспечивающих возможность гражданам систематически заниматься физической культурой и спортом. К числу основных задач, требующих решения для достижения поставленной цели, относятся:

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

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

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

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

Ростовский-на-Дону государственный экономический университет (РГЭУ (РИНХ)) традиционно значительное внимание в свой деятельности уделяет как массовому спорту среди студентов вуза, так и подготовке спортсменов высокого класса и спортивного резерва из числа своих студентов. Сайт университета[3] имеет достаточно информационно наполненный раздел, посвященный деятельности управления по физической культуре и спорту университета (управления ФКИС), который включает как информацию о деятельности кафедры физкультуры, так и о деятельности подразделений, непосредственно выполняющих рекомендации Стратегии: наличие спортивных клубов, баз активного отдыха.

Актуальность реализации дополнительных информационных сервисов по вопросам физической культуры и спорта для РГЭУ (РИНХ) связана с необходимостью оптимизации работы кафедры физкультуры и управления ФКИС.

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

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

–       провести обследование предметной области;

–       построить модель предметной области «как есть» и выявить существующие недостатки;

–       построить модель «как будет» и предложить рекомендации модернизации системы управления ФИКС на базе внедрения информационных сервисов;

–       разработать базу данных (БД), обеспечивающую поддержку информационных сервисов;

–       разработать сервисы;

–       провести отладку системы;

–       провести оценку эффективности принятых решений, и реализованных сервисов.

1. Описание предметной области

архитектура интерфейс надежность информатизация

1.1 Анализ российской законодательной базы по проблемам информатизации физкультурно-спортивного воспитания населения

Значительное внимание в российском законодательстве уделяется вопросам физкультурно-спортивного воспитания населения. Целый ряд документов связан с развитием законодательства по вопросам спорта [1-3]. Разработана стратегия развития физической культуры и спорта в Российской Федерации на период до 2020 года [1], в 2015 планировалось принятие федеральной целевой программы "Развитие физической культуры и спорта в Российской Федерации на 2016 - 2020 годы" [2].

Ключевым законодательным актом РФ, определяющим политику государства в области физической культуры, стал федеральный закон (ФЗ) "О физической культуре и спорте в Российской Федерации" [3]. Одним из важнейших направлений работы закон называет формирование физической культуры студентов и молодежи, требования по организации физического воспитания и образования в образовательных учреждениях представлены в статье 28. Сюда входит как проведение обязательных занятий физической культурой и спортом в пределах основных образовательных программ, так и:

–       проведение медицинского контроля организации физического воспитания;

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

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

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

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

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

–       классификация по функциям;

–       классификация по методам;

–       классификация по этапам учебно-тренировочного процесса;

–       классификация по предлагаемым населению услугам;

–       по видам подготовки в сфере физической культуры и спорта.

В работе Журавлева В.А. и Ананьин В.Г. [5] сделана попытка систематизировать использование информационных технологий в отрасли "Физическая культура и спорт" в целом. Этими направлениями являются: учебный процесс, спортивная тренировка, спортивные соревнования, оздоровительная физическая культура, спортивный менеджмент и регуляция кадрового потенциала отрасли.

Традиционно информационная поддержка кафедр физической культуры ВУЗами осуществляется путем представления информации об их деятельности в рамках сайта ВУЗа. Были рассмотрены информационные ресурсы кафедр физкультуры РГЭУ (РИНХ) [6], ДГТУ [7] и РостГМУ[8]. На основании материалов этих сайтов можно сказать, что ВУЗы в основном ограничиваются минимальными данными о профессорско-преподавательском составе кафедр, о спортивных секциях и клубах с предоставлением уставных документов этих подразделений.

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

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

Проведем анализ необходимого программного обеспечения и информационных ресурсов на основе анализа деятельности кафедры физкультуры РГЭУ (РИНХ) и управления по физической культуре и спорту (УФК и С).

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

Главными достоинствами объектно-ориентированной методологии являются:

–       возможность преодолеть ограничения, связанные со сложностью разрабатываемых систем;

–       использование на стадии анализа моделей близких к реальности;

–       возможность применения как при анализе и проектировании информационных систем, так и систем реального времени и аппаратно-программных комплексов;

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

–       поддержка итеративного, а не лавинообразного, как в структурном подходе, процесса проектирования;

–       естественная работа с разнородной информацией, используемой в мультимедиа системах;

–       создание более открытых систем;

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

В состав РГЭУ (РИНХ) кроме головного ВУЗа входят 8 филиалов и Таганрогском институт имени А. П. Чехова, а также финансово-экономический колледж.

В РГЭУ (РИНХ) создано УФК и С, организационная структура которого представлена на рис. 1.1 по материалам сайта РИНХ [3]. УФК и С подчинено первому проректору по учебной работе. Руководство управлением осуществляется начальником управления через коллегиальным орган - совет по спортивно-оздоровительной работе. Функциями УФК и С являются [9]:

–       руководство спортивно-оздоровительной работой Университета;

–       контроль работы кафедр физического воспитания, спорта и туризма(ФВ,СиТ) РГЭУ(РИНХ), финансового колледжа

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

–       координация работы кабинета врачебно-спортивного контроля.

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

Рис. 1.1 - Организационная схема управления по УФК иС

Деятельность кафедр физического воспитания РГЭУ (РИНХ) строится на основе приказа Госкомвуза РФ от 26.06.1994 № 777 «Об организации процесса физического воспитания в высших учебных заведениях» [11]. На базе этого документа разработана объектная модель ролей кафедры физкультуры, представленная на рисунке 1.2.

Базовой сущностью модели является роль - Сотрудник каф. физкультуры. От него унаследованы роли: Преподаватель, Учебно-вспомогательный персонал, Зав. кафедрой. Роли описывающие деятельность сотрудников, ответственных по профилям работы кафедры, наследуют свойства роли Преподаватель. Это:

–       Ответственный за научную и учебно-методическую работу;

–       Ответственный по физическому воспитанию;

–       Ответственный по виду спорта;

–       Ответственный за массовую оздоровительную работу;

–       Ответственный за учебную работу.

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

Рис. 1.2 - Модель сотрудников кафедры физкультуры

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

.        Заведующий кафедрой физического воспитания несет личную ответственность за всю деятельность кафедры, в том числе:

–       проведение теоретических и практических учебных занятий со студентами в установленном объеме;

–       планирование и организацию учебно-воспитательного процесса и контроль за качеством учебных занятий;

–       руководство научной и научно-методической работой преподавателей кафедры;

–       организацию работы по повышению квалификации преподавателей с отрывом и без отрыва от учебного процесса;

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

–       составление расчетов и смет по штатному, финансовому и материальному обеспечению работы по физическому воспитанию;

–       проведение мероприятий совместно со спортивным клубом по развитию массового спорта в вузе, росту спортивного мастерства студентов-спортсменов, по подготовке спортсменов высших разрядов; проведение массовых физкультурно-оздоровительных мероприятий, спортивных соревнований и праздников;

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

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

–       составление отчетов о работе кафедры;

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

Диаграмма вариантов использования для деятельности рольаЗав. кафедрой представлена на рисунке 1.3.

.        Преподавательский состав кафедры осуществляет:

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

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

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

Рис. 1.3 - Модель деятельности заведующего кафедрой физкультуры

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

–       систематическую работу по повышению своего профессионального уровня;

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

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

–       подготовку спортивных команд и повышение мастерства студентов-спортсменов, руководство ими в процессе спортивных соревнований;

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

–       ежегодное составление индивидуальных планов и отчетов об их выполнении;

–       другие виды работ, связанные с физическим воспитанием студентов.

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

Диаграмма вариантов использования деятельности роли Преподаватель представлена на рисунке 1.4.

Рис. 1.4 - Модель деятельности преподавателя кафедры физкультуры

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

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

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

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

–       анализ качества и эффективности учебной работы, обобщение и внедрение передового опыта по совершенствованию учебно-воспитательного процесса;

–       контроль за проведением профессионально-прикладной физической подготовки в учебном процессе;

–       распределение почасового фонда, контроль за его расходованием;

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

–       ведение учета за динамикой состояния здоровья, физической подготовленности студентов, выполнением требований и тестов учебной программы;

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

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

–       разработку и проведение мероприятий по предупреждению спортивного травматизма на учебных занятиях;

–       составление отчета кафедры по разделу учебной работы.

Диаграмма вариантов использования деятельности роль а Ответственный за учебную работу представлена на рисунке 1.5.

.        Преподаватель, ответственный за научную и учебно-методическую работу (заместитель зав. кафедрой), проводит следующую работу:

–       планирование, организацию и проведение на кафедре научной и учебно-методической работы;

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

–       разработку и обоснование содержания и методики профессиональной прикладной физической подготовки студентов;

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

–       организацию и проведение на кафедре научных конференций;

–       обсуждение на кафедре новой учебно-теоретической литературы;

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

Рис. 1.5 - Модель деятельности ответственного за учебную работу

–       контроль и оказание помощи в работе методического кабинета и научной лаборатории при кафедре;

–       составление отчета кафедры по разделу научной и учебно-методической работы.

Диаграмма вариантов использования деятельности роли Ответственный за научную и учебно-методическую работу представлена на рисунке 1.6.

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

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

–       контроль за совершенствованием спортивного мастерства студентов-спортсменов высокой квалификации;

–       планирование, организацию и проведение в вузе массовых оздоровительных и спортивных мероприятий среди студентов;

–       проведение спортивных соревнований внутри вуза и руководство спортивными командами на внешних соревнованиях;

–       развитие в вузе массового туризма, организацию и контроль за проведением туристских походов, слетов;

Рис. 1.6 - Модель деятельности ответственного за научную и учебно-методическую работу

–       проведение анализа спортивной работы, обобщение и распространение в вузе передового опыта физкультурной и спортивной работы;

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

–       составление отчета кафедры по разделу массовой оздоровительной, физкультурной и спортивной работы.

Диаграмма вариантов использования деятельности ролиОтветственный за массовую оздоровительную работу представлена на рисунке 1.7.

.        Преподаватели, ответственные за работу в учебных отделениях (по виду спорта и виду занятий), обеспечивают:

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

–       контроль за успеваемостью студентов-спортсменов на факультетах;

–       составление отчета о работе, проделанной по видам спорта (видам занятий).

Диаграмма вариантов использования деятельности роли Ответственный за виды спорта представлена на рисунке 1.8.

Рис. 1.7 - Модель деятельности ответственного за массовую оздоровительную работу

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

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

–       контроль за качеством и эффективностью учебного процесса по физическому воспитанию на факультете;

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

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

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

–       проведение на факультете работы по наглядной агитации и пропаганде физической культуры и спорта;

Рис. 1.8 - Модель деятельности ответственного за работу в учебных отделениях

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

–       составление отчета о работе по физическому воспитанию на факультете.

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

Рис. 1.9 - Модель деятельности ответственного за работу по физическому воспитанию

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

Информационные технологии управления учебным процессом в РГЭУ (РИНХ) включают следующие: ИС «Контингент», подсистема «Успеваемость», программный комплекс электронного расписания занятий, подсистема «Электронная ведомость». Данные программные продукты не охватывают бизнес процессы, связанные с подсистемой Оздоровительной и массовой работы. Как показано выше, общевузовская система автоматизации не учитывает специфику функций кафедры физкультуры в части проведения тренировок и соревнований, как видов учебного процесса, а также учета физического состояния студентов в ходе обучения. На рисунке 1.10 представлена подсистема Учебная работа, обеспечивающая тематику кафедры. В результате выполнения дипломного проекта необходимо реализовать сервис «Учебный процесс кафедры физкультуры», обеспечивающий реализацию и внедрение данной подсистемы.

Рисунок 1.10 - Подсистемы деятельности кафедры физкультуры

.3 Сбор и моделирование требований

Сбор требований - один из основных этапов анализа системы, обеспечивающий успешную реализацию проекта [12, 13]. Результатом проведения сбора требований служит техническое задание (ТЗ) на проект.

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

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

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

.3.1 Описание использования системы

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

–       Обеспечение учебно-тренировочного процесса;

–       Контроль за проведением профессионально-прикладной физической подготовки;

–       Контроль замедицинским обследованием студентов;

–       Комплектование групп;

–       Учет результатов медицинского освидетельствования студентов;

–       Анализ динамики состояния здоровья, физического развития и физической подготовленности;

–       Разработка комплексов упражнений;

–       Контроль перемещений студентов.

Таким образом, диаграмма вариантов использования системы будет иметь вид, представленный на рисунке 1.11.

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

Рисунок 1.11 - Диаграмма вариантов использования сервиса Учебная работа обеспечивающая тематику кафедры

Рисунок 1.12 - Диаграмма вариантов использования ролиСтудент

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

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

Рисунок 1.13 - Диаграмма вариантов использования подсистемы Администрирование

.3.2 Определение терминов для описания требований

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

–       Гость;

–       Администратор;

–       Преподаватель;

–       Студент.

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

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

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

–       Группа учебная,

–       Группа по физкультуре.

Свойства перечисленных сущностей связаны перечнями:

–       Специальность,

–       Должность,

–       Тип обучения.

1.3.3 Отображение рабочего процесса между пользователями и системой

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

Рисунок 1.14 - Диаграмма деятельности прецедента «Назначить студента в группу»

.4 Спецификация требований

В приложении А представлено техническое задание (ТЗ) на реализацию сервиса поддержки учебного и воспитательного процесса кафедры физкультуры.

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

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

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

–       карта сервиса,

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

Выводы

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

На базе объектно-ориентированного подхода проведен анализ предметной области деятельности кафедры ФК,СиТ РГЭУ (РИНХ). Выявлены основные требования к сервису поддержки работы кафедры. Определены основные подсистемы сервиса и выявлены его пользователи.

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

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

.1 Архитектура сервиса

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

–       Представление преподавателя;

–       Представление студента;

–       Представление администратора.

Рисунок 2.1 - Концептуальная архитектура сервиса учебного процесса кафедры физкультуры

Современное Web-приложение основывается на технологии "клиент-сервер". Таким образом, его архитектура расширяется до трехуровневой. При такой архитектуре клиентский уровень занимает обозреватель, на уровне сервера находится сервер БД, а на промежуточном уровне размещаются Web-сервер и модули расширения сервера. Модуль расширения сервера выступает преобразователем протоколов между клиент-серверным приложением БД и Web-сервером. Структура приложения представлена на рисунке 2.2.

Рисунок 2.2 - Базовая архитектура трехуровневогоWeb-приложения

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

─       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 <https://ru.wikipedia.org/wiki/.NET_Framework>.

Шаблоном архитектуры программного обеспечения выбрана технология MVC .Net. Данный паттерн обеспечивает разделение данных, логики и интерфейса (см. рис. 2.3):

–       Model - часть приложения, содержащая в себе бизнес-логику, описывающую предметную область. Модель знает, как устроены данные и как с ними работать;

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

–       View - часть приложения, визуализирующая модель данных. Обычно представление имеет прямой доступ к модели, но разрешено только чтение этих данных;

Рис. 2.3- Структура шаблона MVC

.2 Проектирование интерфейса

Уровень представления Web-приложения критически важен при разработке системы и оказывает значительное влияние на степень принятия приложения пользователями. Уровень представления - это своего рода «парадная дверь» в приложение. Он обеспечивает выполнение бизнес-функций, представляемых приложением пользователям, а также визуальное представление информации, которой управляет приложение. Эффективность пользовательского интерфейса значительно влияет на успех приложения в целом [20].

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

Производительность - главное требованием к Web-приложению. Максимальное время выполнения операций не должно превышать 3-10 с.

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

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

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

Для структуры макета сервиса Учебная работа кафедры ФВ,СиТбыла принята концепция «резинового» макета, который подразумевает информация будет занимать пространство, подстраиваясь под разрешение. Используется решение с адаптивным 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 - Реализация структуры проекта

.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.

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

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

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

На основе концептуальной модели создана БД проекта, реализованная в MSSQLServer 2008 R2. Структура и связи таблиц представлены рисунке 2.10.

Рисунок 2.10 - Структура таблиц подсистемы администрирования

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

.4 Структура проекта 

Web-сервис разрабатывается в VisualStudio 2013, как проектSportEducation. Разработка проекта осуществлялась на основе мастера Веб-приложение ASP.NetMVC 4. На рисунке 2.11 представлена страница выбора данной категории проекта. На рисунке 2.12 представлен выбор шаблона проекта: Интернет-приложение на базе обработчика представлений Razorс созданием проекта разработки модульных тестов - 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 для настройки приложения._Data - папка области физического хранилища данных. Эта папка выполняет те же функции, что и для веб-сайтов ASP.NET, которые используют страницы веб-форм.- папка для рекомендуемого расположения файлов содержимого (например, файлов каскадных таблиц стилей, изображений и пр.). В общем случае папка Content предназначена для статических файлов.- папка для рекомендуемого расположенияконтроллеров. Имена контроллеров в платформе MVC должны оканчиваться на "Controller", например HomeController, LoginController или ProductController.- предназначена для классов, которые представляют модель приложения для веб-приложения MVC. Эта папка обычно содержит код, который определяет объекты и логику взаимодействия с хранилищем данных. Сами объекты модели обычно располагаются в отдельных библиотеках классов. Тем не менее, при создании нового приложения классы можно расположить в этой папке, чтобы переместить их в отдельные библиотеки на более поздней стадии разработки.- рекомендуемое расположение для файлов скриптов, поддерживающих приложение. Эта папка по умолчанию содержит файлы платформы ASP.NET Ajax и библиотеку jQuery.- рекомендуемое расположение для представлений. Представления используют файлы ViewPage (ASPX), ViewUserControl (ASCX) и ViewMasterPage (MASTER) в дополнение к остальным файлам, которые связаны с отображением представлений. Папка Views содержит папки для всех контроллеров. Название папки состоит из префикса имени контроллера. Например, если существует контроллер с именем HomeController, то в папке Views будет вложенная папка с именем Home. При загрузке представления платформой ASP.NET MVC в папке "Views\имя_контроллера" по умолчанию выполняется поиск файла ViewPage (ASPX), который имеет имя требуемого представления. По умолчанию в папке Views находится папка Shared, которая не соответствует ни одному контроллеру. Папка Shared используется для представлений, которые используются на нескольких контроллерах. Например, главную страницу веб-приложения можно поместить в папку Shared.

.5 Клиентская часть

Разработка клиентской части приложения осуществляется в папке Views с использованием файлов 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.

В проекте автоматически сгенерируется классe nterprise _order Entities1, который наследуется от класса Object Context, представляет сущности базы данных Sport Education, содержит свойства, моделирующие таблицы и связи между таблицами.

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

Листинг 2.2 - Код для строк соединения с базой данных

Рис. 2.16 Структура модели данных

.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-сервиса

.1 Оценка надежности Web-сервиса

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

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

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

Критерии надежности сайтов отличаются для статических и динамических сайтов. Для статических сайтов характеристики надежности связаны со временем безотказной работы.

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

Таблица 3.1 - Характеристика надежности

Лет	Характеристика надежности сайта	Примечание
2 и более	Очень высокая надежность сайта.	Владельцу сайта повезло. Очень высокое качество сайта.
1,5-2	Высокая надежность сайта.	Высокое качество сайта.	Надежный сайт.	Сайт создан профессиональным веб-дизайнером. Сайт качественный <#"896869.files/image038.gif"> Рисунок 3.2 - Пооперационный перечень После того как разработчик определился с составом и результатами этапов проекта, необходимо определить последовательность этих этапов относительно друг друга и сроков выполнения каждого этапа. После этого необходимо определить работы, составляющие каждый этап, последовательность исполнения этих работ, а также сроков выполнения всех этих работ. Например, этап «начало выполнения проекта» делится на:          установку соответствия между действиями и планом;          распределение ресурсов проекта;          установку среды проекта;          планирование управлением проекта. Данный жизненный цикл разработан для полноценно функционирующего Web-сервера учебного процесса. Создание структуры пооперационного перечня работ влечет за собой декомпозицию полномасштабного действия (всего проекта) на ряд последовательных и меньших действий. Этот процесс продолжается до тех пор, пока не будут подробно описаны все детали предстоящей работы, что в свою очередь, позволит реализовать надлежащее управление этой работой. В любом случае идентификация корректных действий представляет собой дело первоочередной важности. Разрабатываемый Web-сервис включает в себя: –       анализ функций на уровне системы/продукта; –       разработку системной архитектуры; –       декомпозицию системных требований; –       уточнение и разработку требований к ПО; –       определение требований к интерфейсу; –       изучение выполнимости - выполнение имитаций и сравнительных тестов; –       анализ проекта - проектирование на основе предварительно сформулированных требований; –       создание БД - идентификация предварительных элементов БД; –       проектирование пользовательского интерфейса - определение порядка взаимодействия интерфейса с пользователем, проектирование алгоритмических функций; –       планирование следующей фазы. Идентификация задач представлена на рисунке 3.2. .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 - Результаты опроса и расчет показателей Эксперты Критерии оценки g1 g2 gЗ g4 g5 Э1 5 1 3 4 2 Э2 4 2 3 5 1 ЭЗ 5 2 3 4 1 Э4 4 1 3 5 2 Э5 4 1 2 5 3 Э6 5 1 3 4 2 Э7 1 4 3 2 5 Э8 2 3 4 1 5 Э9 1 4 3 2 5 Э10 2 3 4 1 5 Ранг, R(i) 33 22 31 33 31 Ранг минимальный 22 Оценка, V(i) 0,67 1,00 0,71 0,67 0,71 Общая оценка 3,75 Весовые коэффициенты, w(i) 0,18 0,27 0,19 0,18 0,19 Степень достижения цели, g(i) 0,94 0,85 0,91 0,94 0,86 Показатель эффективности, E 0,8952149 На основании представленных расчетов можно утверждать, что реализация и внедрение Web-сервис Учебная работа обеспечивающая тематику кафедры является целесообразным.   Выводы В третьей главе произведено обоснование выбора жизненного цикла информационной системы и выделено, что наиболее оптимальным вариантом модели является модель RAD. Создана структура пооперационного перечня работ (проект создания информационной системы реализован в Microsoft Project). Определены используемые в проекте ресурсы и на последнем этапе проведена оценка эффективности прототипа ИС, которая показала, что внедрение проекта целесообразно. Заключение В дипломной работе рассмотрена деятельность кафедры физкультуры РГЭУ (РИНХ). В результате проведенного анализа выявилась актуальность автоматизации бизнес-процессов кафедры в свете постановлений правительства Российской федерации по вопросам развития физкультуры и спорта. В ходе проведенного анализа было показана ограниченность существующих решений по автоматизации предметной области кафедр физкультуры. В связи с этим представляет интерес разработка Web-сервиса, обеспечивающего деятельность кафедры в плане активизации учебного процесса путем использования информационных технологий. В ходе выполнения дипломного проекта был спроектирован и разработанWeb-сервисУчебная работа обеспечивающая тематику кафедры. Для этого: )        был проведен анализ бизнес-процессов деятельности кафедры ФВ,СиТ; )        был выбран объектно-ориентированный подход к реализации приложения; )        были выбраны следующие программные продукты для разработки приложения: –       Microsoft Visual Studio 2013; –       Microsoft SQL Server 2008; –       MS Project 2010; –       MS Word 2010; –       MS Power Point 2010. На этапе логического проектирования были построены диаграмма деятельности, диаграмма компонентов. Диаграмма деятельности показывает сущность кафедры. Во втором были проведены: )        выбор технология реализации сервиса - шаблон MVC 4.0 .Net, обеспечивающий единую среду реализации проекта; )        разработан интерфейс сервиса; )        проведено моделирование структуры данных средствами MSVisualStudio2013 с использованием на модели ADO.NetEDM. )        разработано приложение; )        определена методология развертывания сервиса. Произведено тестирование приложения по методу «белого ящика», которое показало, что приложение работает корректно. В третьем разделе дипломного проекта была определена модель жизненного цикла приложения. Проанализировав основные отличительные категории проекта, был выбран метод быстрой разработки приложений «RAD». При помощи программного продукта MS Project ,был создан пооперационный перечень работ для выполнения проекта, определены и назначены ресурсы проекта, определены затраты на внедрение данной подсистемы. Был произведен расчет эффективности проекта, с помощью экспертных оценок который показал, что система работает эффективно на 91%. Оценка эффективности разработанной подсистемы по отношению к заданным целям показала высокий бал. На основании данных результатов можно сделать вывод, что внедрение Web-сервисУчебная работа обеспечивающая тематику кафедры- целесообразно.   Список сокращений EDM   - Entity Data Model, модель «сущность-связь»;      - доменного языка;      - язык DSL на основе XML; БД       - база данных; кафедра ФВ,СиТ         - кафедра физического воспитания, спорта и туризма; ЖЦ     - жизненный цикл; ПП      - программный продукт; РГЭУ (РИНХ)     - Ростовский государственный экономический университет; ТЗ       - техническое задание; УФК и С    - управление по физической культуре и спорту;   Библиографический список 1.      Распоряжение Правительства РФ от 07.08.2009 N 1101-р «Об утверждении Стратегии развития физической культуры и спорта в Российской Федерации на период до 2020 года» [Электронный документ] / КонсультантПлюс. URL: www.consultant.ru <file:///C:\Users\basic\AppData\Local\Temp\www.consultant.ru> (Дата сохранения: 01.04.2016). .        Постановление Правительства РФ от 21.01.2015 N 30 «О федеральной целевой программе "Развитие физической культуры и спорта в Российской Федерации на 2016 - 2020 годы» [Электронный документ] / КонсультантПлюс. URL: www.consultant.ru <file:///C:\Users\basic\AppData\Local\Temp\www.consultant.ru> (Дата сохранения: 04.04.2016). .        Федеральный закон от 04.12.2007 N 329-ФЗ (ред. от 03.11.2015) "О физической культуре и спорте в Российской Федерации" [Электронный документ] / КонсультантПлюс. URL: www.consultant.ru <file:///C:\Users\basic\AppData\Local\Temp\www.consultant.ru> (Дата сохранения: 01.04.2016) .        Воронов, И.А. Информационные технологии в физической культуре испорте: [Электронный учебник] / И.А. Воронов; СПб ГУФК им. П.Ф. Лесгафта. -СПб.: изд-во СПб ГУФК им. П.Ф. Лесгафта, 2005 - 80с.URL:http://sat.ru/attachments/Information_technologies_in_physical_training_and_sports.pdf <http://sa-t.ru/attachments/Information_technologies_in_physical_training_and_sports.pdf>Загл. с экрана.(Дата сохранения: 04.04.2016) .        Журавлев В.А., Ананьин В.Г. Использование информационных технологий в физической культуре и спорте. //Современные информационные технологии в физической культуре и спорте: Тез.докладов Международной научно-практической конференции, посвященной 70-летию образования Удмуртского государственного университета /Под общ. ред. проф. П.К. Петрова - Ижевск: Издательский дом "Удмуртский университет", 2001. С. 27-29. .        Спорт. [Электронный ресурс] / ДГТУ. URL:<http://www.donstu.ru/social-life/sport/>Загл. с экрана. (Дата сохранения: 04.04.2016) .        Спортивный клуб «Медик». [Электронный ресурс] /РостГМУ. URL: <http://rostgmu.ru/%D0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-2/%D0%B2%D0%BE%D1%81%D0%BF%D0%B8%D1%82%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0-%D0%B2-%D1%80%D0%BE%D1%81%D1%82%D0%B3%D0%BC%D1%83/%D1%81%D0%BF%D0%BE%D1%80%D1%82%D0%B8%D0%B2%D0%BD%D1%8B%D0%B9-%D0%BA%D0%BB%D1%83%D0%B1-%D0%BC%D0%B5%D0%B4%D0%B8%D0%BA>Загл. с экрана. (Дата сохранения: 04.04.2016) .        Положение об управлении по физической культуре и спорту РГЭУ (РИНХ) [Электронный документ] / РГЭУ (РИНХ). 2015. URL: <http://www.rsue.ru/sport.aspx>(Дата сохранения: 04.04.2016) .        Роль физического воспитания и спорта в подготовке молодежи в перспективе непрерывного образования // Спорт, духовные ценности, культура. - М., 1997. - Вып. 7. - С. 10-16. [Электронный документ] / Центральная отраслевая библиотека по физической культуре и спорту. URL: <http://lib.sportedu.ru/GetText.idc?TxtID=934> .        Приказ Госкомвуза РФ от 26.07.1994 N 777 Об организации процесса физического воспитания в высших учебных заведениях. [Электронный документ] / КонсультантПлюс. URL: www.consultant.ru <file:///C:\Users\basic\AppData\Local\Temp\www.consultant.ru> (Дата сохранения: 04.04.2016) .        Методические основы управления ИТ-проектами: учебник / В.И. Грекул, Н.Л. Коровкина, Ю.В. Куприянов. - М.: ИнтернетУниверситет Информационных Технологий: БИНОМ. Лаборатория знаний, 2010. - 391 с. .        Вигерс, К. Разработка требований к программному обеспечению./Пер. с англ. М.: Издательско-торговый дом «Русская редакция», 2004. .        Рапопорт Л.А. Спорт в вузе: проблемы организации. Теория и практика физической культуры. Научно-теоретический журнал. № 8 - 2001. [Электронный документ]URL: <http://lib.sportedu.ru/press/tpfk/2001N8/p16-18.htm>(Дата сохранения: 04.05.2016) .        Строшков В.П., Строшкова Н.Т. Программно-аппаратные средства автоматизированного сбора и анализа данных о физическом состоянии организма человека, подвергающегося тренировочным нагрузкам. - Российский государственный профессионально-педагогический университет, Уральский федеральный университет. [Электронный документ] Сайт: Журнал тренера. URL:<http://cithall.com/?p=395%20>. .        Теория и методика физического воспитания. Учебник для ин-тов физ. культуры. Под общей ред. Л.П. Матвеева и Ф.Д. Новикова. Изд. 2-е, испр. И доп. (В 2-ч т.). М., «Физкультура и спорт», 1976. .        Основы спортивной тренировки. Учебное пособие для ин-тов физ. культуры. Под редакцией Л.П. Матвеева. М., «Физкультура и спорт», 1977. .        <http://refdb.ru/look/1280882-p4.html> .        Создание Web-страниц и Web-сайтов. Самоучитель : [учеб. пособие] / под ред. В. Н. Печникова. - М.: Изд-во Триумф, 2006.-- 464 с. 19.    URL: <https://habrahabr.ru/post/273795/>(Дата сохранения: 24.05.2016) .        А. Д. Хомоненко, В. М. Цыганков, М. Г. Мальцев. Базы данных. Учебник для вузов // Издание: Корона-принт, 2004 г. .        Средства модели ADO.NETEDM. Microsoft | DeveloperNetwork. URL: <https://msdn.microsoft.com/library/bb399249.aspx>(Датасохранения: 24.05.2016) 22.    Фатрелл, Т. Управление программными проектами: достижение оптимального качества при минимуме затрат.: Пер. с англ. / Р.Т. Фатрелл, Д.Ф. Шафер, Л.И. Шафер. - М.: Издательский дом «Вильямс», 2003 .        Е.Н. Ефимов Эффективность информационных технологий. Электронный конспект лекций. РГЭУ(РИНХ). 2013 - 139 с. .        Е.Н. Ефимов, Основы Интернет-экономики. Учебное пособие.РГЭУ(РИНХ). 2014 - 123 с. Приложение А   Техническое задание Сервис «Учебный процесс кафедры физкультуры»(СЕРВИС) - Web-приложение, обеспечивающее поддержку работы кафедры физкультуры РГЭУ (РИНХ) в области оптимизации учебного процесса. Разработка сервиса предполагает два этапа. Начальный этап обеспечивает реализацию системы администрирования сервиса и информационной части сайта сервиса. На втором этапе завершающего ввода в эксплуатацию сервис должен обеспечивать учет медицинских показаний студентов к проведению тренировок, учет выполнения индивидуальных заданий студентами. Назначение разработки Функциональным назначением сервиса является учёт: –       учет пользователей системы; –       ведение информационной поддержки деятельности кафедры физкультуры; –       ведение учебных и тренировочных материалов; –       мониторинг физического состояния студента; –       расписание обязательных и секционных занятий; –       анализ физического состояния студентов. Эксплуатационное назначение СЕРВИСА Программа эксплуатируется профессорско-преподавательским составом кафедр физкультуры, студентами. Требования к программе или программному изделию Требования к функциональным характеристикам Категории описания требований приведены в таблице 1.1. Таблица 1 - Категории описания требований Категория Описание F Функциональные требования, описывающие требуемую функциональность или прецеденты системы C Системные требования, такие как используемые платформы P Требования к представлению R Требования, определяющие риски, которым должно быть уделено основное внимание при разработке системы Требования к составу выполняемых функций На первом этапе разработки выполняются функции, приведенные в таблице 2 по категориям пользователей. Таблица 2-Функциональные требования Требование Тип Описание Пользователь Авторизация F Система должна осуществлять авторизацию пользователей и настройку функционала под выбранную категорию пользователя Редактирование собственных учетных данных F Система должна осуществлять редактирование учетных данных пользователя в рамках его компетенции (смена пароля) Загрузка необходимых компонентов системы F Система должна загружать свои компоненты, в зависимости от типа пользователя Администратор системы Регистрация пользователей F Система должна регистрироватьпользователя Редактирование учетных данных выбранного пользователя F Система должна осуществлять редактирование учетных данных пользователя в рамках компетенции администратора Определение типа пользователя F Система должна определять для авторизованного сотрудника один из заданных типов сотрудника Задание свойств пользователя F Система должна определять свойства сотрудника авторизованного в системе. Связь между функциями и свойствами F Система должна осуществлять связь с функциями, реализующими свойства пользователя Удаление пользователя F Система должна осуществлять уничтожение учетной записи пользователя либо перенос её в архив Блокировка пользователя F Система должна осуществлять блокирование учетной записи пользователя Резервное копирование F Система должна осуществлять резервное копирование данных Восстановление данных F Система должна осуществлять восстановление данных из резервных копий Требования к надежности Для СЕРВИСА должна быть обеспечена отказоустойчивость, в том числе за счет распределения нагрузки и резервирования критических точек отказов. СЕРВИС должен предусматривать применение стандартных средств предотвращения потери данных и их восстановления в случае возможных сбоев оборудования. Применяемые при эксплуатации СЕРВИСА средства резервного копирования и восстановления должны предоставлять пользователям возможность выбора различных стратегий резервного копирования, обеспечивающих необходимый уровень защиты данных в случае возникновения сбоев в работе системы, при этом администратору должна предоставляться возможность выполнения резервного копирования, как на съемные, так и на несъемные устройства хранения. Функциональные возможности примененной системы резервного копирования и восстановления СЕРВИСА должны позволять возвращать систему в состояние, предшествующее сбою. При этом в системе не должно происходить потери и искажения данных. Надежность СЕРВИСА на стороне сервера должна обеспечиваться следующими способами: Требованиями по надежности системы электропитания. Допустимая продолжительность отсутствия электропитания определяется на этапе проектирования проекта внедрения СЕРВИСА. Должно быть сформулировано требование обеспечения вычислительного комплекса средствами стабилизации напряжения и источниками резервного и бесперебойного питания с тем, чтобы при аварийном отключении электроэнергии обеспечить его работоспособность на время, достаточное для корректного завершения работы; средствами последующего автоматического возобновления работы в штатном режиме. Надежностью выбираемых технических средств путем формулирования разработчиками СЕРВИСА четких требований к надежности оборудования и ЛВС, включая: –       требования по применению дисковых массивов серверов технологии RAID; –       использование резервирования аппаратных компонентов системы; –       возможность «горячей» замены отдельных узлов на серверах (вентиляторы, блоки питания, накопители на жестких дисках); –       возможность реализация механизма восстановления баз данных. Соблюдением условий эксплуатации оборудования в соответствии с техническими (паспортными) нормами, установленными разработчиком СЕРВИСА. Технологией ведения информационной базы и возможностью ее восстановления в случае искажения или утраты, осуществлением контроля входной информации, как на этапе ввода, так и на этапе хранения. Требованием сохранения резервных копий базы на независимые носители информации. Надежность СЕРВИСА на стороне клиента обеспечивается: –       использованием лицензионного программного обеспечения; –       испытанием программных средств на наличие компьютерных вирусов Время восстановление после отказа Время восстановления после отказа, вызванного сбоем электропитания технических средств (иными внешними фрольами), не фатальным сбоем (не крахом) операционной системы, не должно превышать 6 минут при условии соблюдения условий эксплуатации технических и программных средств. Время восстановления после отказа, вызванного неисправностью технических средств, фатальным сбоем (крахом) операционной системы, не должно превышать времени, требуемого на устранение неисправностей технических средств и переустановки программных средств. Перечень аварийных ситуаций также составляет Заказчик и согласовывает с Исполнителем. Фактически, это время на перезагрузку операционной системы, если отказ не фатален, не вызван крахом операционной системы или выходом из строя технических средств. Отказы из-за некорректных действий оператора Отказы программы возможны вследствие некорректных действий оператора (пользователя) при взаимодействии с операционной системой. Во избежание возникновения отказов программы по указанной выше причине следует обеспечить работу конечного пользователя без предоставления ему административных привилегий. Условия эксплуатации Климатические условия эксплуатации Климатические условия эксплуатации СЕРВИСА на стороне сервера, при которых должны обеспечиваться заданные характеристики, должны удовлетворять требованиям, предъявляемым к техническим средствам в части условий их эксплуатации. Требования к составу и параметрам технических средств В состав технических средств сервера должен входить IBM-совместимый персональный компьютер, включающий в себя: Intel(R) Core(TM) i5-2500K 32-разрядную операционную систему материнскую плату с FSB, ГГц - 5 Требования к информационной и программной совместимости Требования к информационным структурам и методом решения Требования к информационным структурам(файлов) на входе и на выходе, а также к методам решения не предъявляются. Требования к исходным кодам и языкам программирования Исходные коды должны быть реализованы на языке С#. В качестве интегрированной среды разработки программы должна быть использована среда Microsoft Visual Studio. Шаблон проектирования MVC 4. Требования к программной документации В состав программной документации должны входить: –       Техническое задание; –       Программный продукт; –       Руководство пользователя. Технико-экономические показатели Ориентировочная экономическая эффективность не рассчитывается. Предполагаемое число использования программы в год- 365 сеансов работы на одном рабочем месте. Стадии и этапы разработки Стадии и этапы Разработка должна быть проведена в три стадии: –       Техническое задание; –       Технический (и рабочий) проекты; –       Внедрение. На стадии «Техническое задание» должен быть выполнен этап разработки, согласования и утверждения настоящего технического задания. На стадии «Технический (и рабочий) проект» должны быть выполнены следующие этапы работ: разработка программы, разработка программной документации, испытания программы. На стадии «Внедрение» должен быть выполнен этап разработки «Подготовка и передача программы». Содержание работ по этапам На этапе разработки технического задания должны быть выполнены перечисленные ниже работы: .        Постановка задачи; .        Определение и уточнение к техническим средствам; .        определение требований к программе; .        определение стадий, этапов и сроков разработки программы и документации на неё; .        согласование и утверждение технического задания. На этапе разработки программы должна быть выполнена работа по программированию (кодированию) и отладке программы. На этапе разработки программной документации должна быть выполнена разработка программных документов в соответствии с требованиями ГОСТ 19.101-77 с требованием п. Предварительный состав программной документации настоящего технического задания. На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ: .        разработка, согласование и утверждение программы .        проведение приемо-сдаточных испытаний; .        корректировка программы и программной документации по результатам испытаний. На этапе подготовки и передачи программы должна быть выполнена работа по подготовке и передаче программы и программной документации в эксплуатацию на объектах Заказчика. Порядок контроля и приемки Виды испытаний Приемо-сдаточные испытания должны проводиться на объекте Заказчика в оговоренные сроки. Приемо-сдаточные испытания программы должны проводиться согласно с разработанной Исполнителем и согласованной с Заказчиком программой и методикой испытаний. Ход проведения приемо-сдаточных испытаний Заказчик и Исполнитель документируют в Протоколе проведения испытаний. Общие требования к приемке работ На основании Протокола проведения испытаний Исполнитель совместно с Заказчиком подписывает Акт приемки-сдачи программы в эксплуатацию.   Приложение Б   Структура таблиц подсистемы администрирования Ключ Имя столбца Тип данных Значение NULL Примечание UserProfile PK UserId int Ключевое поле, идентификатор пользователя UserNamt nvarchar(56) Логин пользователя webpages_Membership PK UserId int Ключевое поле, идентификатор пользователя CreateDate datetime да Дата регистрации ConfirmationToken nvarchar(128) да IsConfirmed bit да LastPasswordFailureDate datetime да Дата последней смены пароля PasswordFailuresSinceLastSuccess int Password nvarchar(128) Кодировка пароля пользователя PasswordChangedDate datetime да PasswordSalt nvarchar(128) PasswordVerificationToken nvarchar(128) да PasswordVerificationTokenExpirationDate datetime да webpages_Roles PK RoleId int Ключевое поле, идентификатор категории пользователя RoleName nvarchar(256) Наименование категории пользователя webpages_UsersInRoles PK UserId int Ключевое поле, идентификатор пользователя PK RoleId int Ключевое поле, идентификатор категории пользователя Лицо PK ID_Лица int Ключевое поле, идентификатор пользователя Имя nvarchar(50) Отчество nvarchar(50) Фамилия nvarchar(50) ID_Паспорт ID_Пол Приложение В сценарий создания объектов базы данных USE [master] /****** Object: Database [SportEducation] Script Date: 06/01/2016 05:26:23 ******/DATABASE [SportEducation] ON PRIMARY ( NAME = N'SportEducation', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\SportEducation.mdf' , SIZE = 6144KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB )ON ( NAME = N'SportEducation_log', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\SportEducation_log.ldf' , SIZE = 1024KB , MAXSIZE = 2048GB , FILEGROWTH = 10%)DATABASE [SportEducation] SET COMPATIBILITY_LEVEL = 100(1 = FULLTEXTSERVICEPROPERTY('IsFullTextInstalled'))[SportEducation].[dbo].[sp_fulltext_database] @action = 'enable'DATABASE [SportEducation] SET ANSI_NULL_DEFAULT OFFDATABASE [SportEducation] SET ANSI_NULLS OFFDATABASE [SportEducation] SET ANSI_PADDING OFFDATABASE [SportEducation] SET ANSI_WARNINGS OFFDATABASE [SportEducation] SET ARITHABORT OFFDATABASE [SportEducation] SET AUTO_CLOSE OFFDATABASE [SportEducation] SET AUTO_CREATE_STATISTICS ONDATABASE [SportEducation] SET AUTO_SHRINK OFFDATABASE [SportEducation] SET AUTO_UPDATE_STATISTICS ONDATABASE [SportEducation] SET CURSOR_CLOSE_ON_COMMIT OFFDATABASE [SportEducation] SET CURSOR_DEFAULT GLOBALDATABASE [SportEducation] SET CONCAT_NULL_YIELDS_NULL OFFDATABASE [SportEducation] SET NUMERIC_ROUNDABORT OFFDATABASE [SportEducation] SET QUOTED_IDENTIFIER OFFDATABASE [SportEducation] SET RECURSIVE_TRIGGERS OFFDATABASE [SportEducation] SET DISABLE_BROKERDATABASE [SportEducation] SET AUTO_UPDATE_STATISTICS_ASYNC OFFDATABASE [SportEducation] SET DATE_CORRELATION_OPTIMIZATION OFFDATABASE [SportEducation] SET TRUSTWORTHY OFFDATABASE [SportEducation] SET ALLOW_SNAPSHOT_ISOLATION OFFDATABASE [SportEducation] SET PARAMETERIZATION SIMPLEDATABASE [SportEducation] SET READ_COMMITTED_SNAPSHOT OFFDATABASE [SportEducation] SET HONOR_BROKER_PRIORITY OFFDATABASE [SportEducation] SET READ_WRITEDATABASE [SportEducation] SET RECOVERY FULLDATABASE [SportEducation] SET MULTI_USERDATABASE [SportEducation] SET PAGE_VERIFY CHECKSUMDATABASE [SportEducation] SET DB_CHAINING OFFsys.sp_db_vardecimal_storage_format N'SportEducation', N'ON'[SportEducation] /****** Object: Table [dbo].[Факультет] Script Date: 06/01/2016 05:26:23 ******/ANSI_NULLS ONQUOTED_IDENTIFIER ONTABLE [dbo].[Факультет]( [ID_Факультет] [int] IDENTITY(1,1) NOT NULL, [Наименование] [nvarchar](80) NOT NULL,[PK_Факультет] PRIMARY KEY CLUSTERED ( [ID_Факультет] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] /****** Object: Table [dbo].[Типобучения] Script Date: 06/01/2016 05:26:23 ******/ANSI_NULLS ONQUOTED_IDENTIFIER ONTABLE [dbo].[Типобучения]( [ID_Тип] [int] IDENTITY(1,1) NOT NULL, [Наименование] [nvarchar](50) NULL, [Кол_лет] [real] NULL,[PK_Типобучения] PRIMARY KEY CLUSTERED ( [ID_Тип] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] /****** Object: Table [dbo].[Специальность] Script Date: 06/01/2016 05:26:23 ******/ANSI_NULLS ONQUOTED_IDENTIFIER ONTABLE [dbo].[Специальность]( [ID_Специальность] [int] IDENTITY(1,1) NOT NULL, [Наименование] [nvarchar](80) NOT NULL, [Код] [nvarchar](50) NULL,[PK_Специальность] PRIMARY KEY CLUSTERED ( [ID_Специальность] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] /****** Object: Table [dbo].[Пол] Script Date: 06/01/2016 05:26:23 ******/ANSI_NULLS ONQUOTED_IDENTIFIER ONTABLE [dbo].[Пол]( [ID] [smallint] NOT NULL, [Пол] [nchar](10) NULL, [Краткое] [nchar](1) NULL,[PK_Пол] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] /****** Object: Table [dbo].[Паспорт] Script Date: 06/01/2016 05:26:23 ******/ANSI_NULLS ONQUOTED_IDENTIFIER ONTABLE [dbo].[Паспорт]( [ID] [int] NOT NULL, [Серия] [nchar](5) NOT NULL, [N паспорта] [nvarchar](20) NOT NULL, [Когдавыдан] [datetime] NULL, [Кемвыдан] [nvarchar](50) NULL,[PK_Паспорт] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] /****** Object: Table [dbo].[Должность] Script Date: 06/01/2016 05:26:23 ******/ANSI_NULLS ONQUOTED_IDENTIFIER ONTABLE [dbo].[Должность]( [ID_должность] [int] IDENTITY(1,1) NOT NULL, [Должность_] [nvarchar](50) NOT NULL,[PK_Должность] PRIMARY KEY CLUSTERED ( [ID_должность] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] /****** Object: Table [dbo].[UserProfile] Script Date: 06/01/2016 05:26:23 ******/ANSI_NULLS ONQUOTED_IDENTIFIER ONTABLE [dbo].[UserProfile]( [UserId] [int] NOT NULL, [UserName] [nvarchar](56) NOT NULL,[PK_UserProfile] PRIMARY KEY CLUSTERED ( [UserId] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] /****** Object: Table [dbo].[webpages_Roles] Script Date: 06/01/2016 05:26:23 ******/ANSI_NULLS ONQUOTED_IDENTIFIER ONTABLE [dbo].[webpages_Roles]( [RoleId] [int] NOT NULL, [RoleName] [nvarchar](256) NOT NULL,[PK_webpages_Roles] PRIMARY KEY CLUSTERED ( [RoleId] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] /****** Object: Table [dbo].[webpages_OAuthMembership] Script Date: 06/01/2016 05:26:23 ******/ANSI_NULLS ONQUOTED_IDENTIFIER ONTABLE [dbo].[webpages_OAuthMembership]( [Provider] [nvarchar](30) NOT NULL, [ProviderUserId] [nvarchar](100) NOT NULL, [UserId] [int] NOT NULL ) ON [PRIMARY] /****** Object: Table [dbo].[webpages_Membership] Script Date: 06/01/2016 05:26:23 ******/ANSI_NULLS ONQUOTED_IDENTIFIER ONTABLE [dbo].[webpages_Membership]( [UserId] [int] NOT NULL, [CreateDate] [datetime] NULL, [ConfirmationToken] [nvarchar](128) NULL, [IsConfirmed] [bit] NULL, [LastPasswordFailureDate] [datetime] NULL, [PasswordFailuresSinceLastSuccess] [int] NOT NULL, [Password] [nvarchar](128) NOT NULL, [PasswordChangedDate] [datetime] NULL, [PasswordSalt] [nvarchar](128) NOT NULL, [PasswordVerificationToken] [nvarchar](128) NULL, [PasswordVerificationTokenExpirationDate] [datetime] NULL,[PK_webpages_Membership] PRIMARY KEY CLUSTERED ( [UserId] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] /****** Object: Table [dbo].[Группа] Script Date: 06/01/2016 05:26:23 ******/ANSI_NULLS ONQUOTED_IDENTIFIER ONTABLE [dbo].[Группа]( [ID_Группа] [int] IDENTITY(1,1) NOT NULL, [Наименование] [nvarchar](12) NOT NULL, [Специальность] [int] NOT NULL, [Типобучения] [int] NOT NULL, [Годобучения] [nchar](10) NOT NULL,[PK_Группа] PRIMARY KEY CLUSTERED ( [ID_Группа] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] /****** Object: Table [dbo].[webpages_UsersInRoles] Script Date: 06/01/2016 05:26:23 ******/ANSI_NULLS ONQUOTED_IDENTIFIER ONTABLE [dbo].[webpages_UsersInRoles]( [UserId] [int] NOT NULL, [RoleId] [int] NOT NULL,[PK_webpages_UsersInRoles] PRIMARY KEY CLUSTERED ( [UserId] ASC, [RoleId] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] /****** Object: Table [dbo].[Факультет_Специальность] Script Date: 06/01/2016 05:26:23 ******/ANSI_NULLS ONQUOTED_IDENTIFIER ONTABLE [dbo].[Факультет_Специальность]( [ID_Факультет] [int] NOT NULL, [ID_Специальность] [int] NOT NULL,[PK_Факультет_Спкциальность] PRIMARY KEY CLUSTERED ( [ID_Факультет] ASC, [ID_Специальность] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] /****** Object: Table [dbo].[Студент] Script Date: 06/01/2016 05:26:23 ******/ANSI_NULLS ONQUOTED_IDENTIFIER ONTABLE [dbo].[Студент]( [ID_Студент] [int] NOT NULL, [N_ЗачКН] [int] NOT NULL, [Год поступления] [date] NULL, [ID_Специальность] [int] NULL, [ID_ТипОбучения] [int] NULL,[PK_Студент] PRIMARY KEY CLUSTERED ( [ID_Студент] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] /****** Object: Table [dbo].[Преподаватель] Script Date: 06/01/2016 05:26:23 ******/ANSI_NULLS ONQUOTED_IDENTIFIER ONTABLE [dbo].[Преподаватель]( [ID_Преподаватель] [int] NOT NULL, [ID_Должность] [int] NULL,[PK_Преподаватель] PRIMARY KEY CLUSTERED ( [ID_Преподаватель] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] /****** Object: Table [dbo].[СтудентГруппа] Script Date: 06/01/2016 05:26:23 ******/ANSI_NULLS ONQUOTED_IDENTIFIER ONTABLE [dbo].[СтудентГруппа]( [ID_Студент] [int] NOT NULL, [ID_Группа] [int] NOT NULL,[PK_СтудентГруппа] PRIMARY KEY CLUSTERED ( [ID_Студент] ASC, [ID_Группа] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] /****** Object: StoredProcedure [dbo].[Пользователь] Script Date: 06/01/2016 05:26:24 ******/ANSI_NULLS ONQUOTED_IDENTIFIER ON - ============================================= - Author:              <Author,,Name> - Create date: <Create Date,,> - Description:       <Description,,> - =============================================PROCEDURE [dbo].[Пользователь] - SET NOCOUNT ON added to prevent extra result sets from - interfering with SELECT statements.NOCOUNT ON; - Insert statements for procedure heredbo.UserProfile.UserId AS Номер, dbo.UserProfile.UserName AS Логин, dbo.webpages_Membership.CreateDate AS [Датасоздания]dbo.UserProfile INNER JOIN.webpages_Membership ON dbo.UserProfile.UserId = dbo.webpages_Membership.UserId /****** Object: Table [dbo].[Лицо] Script Date: 06/01/2016 05:26:24 ******/ANSI_NULLS ONQUOTED_IDENTIFIER ONTABLE [dbo].[Лицо]( [ID_Лица] [int] NOT NULL, [Имя] [nvarchar](50) NOT NULL, [Отчество] [nvarchar](50) NOT NULL, [Фамилия] [nvarchar](50) NOT NULL, [ID_Паспорт] [int] NULL, [ID_Адрес] [int] NULL, [ID_Пол] [smallint] NULL, [Дата_рождения] [date] NULL,[PK_Лицо] PRIMARY KEY CLUSTERED ( [ID_Лица] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] /****** Object: ForeignKey [FK_webpages_Membership_UserProfile] Script Date: 06/01/2016 05:26:23 ******/TABLE [dbo].[webpages_Membership] WITH CHECK ADD CONSTRAINT [FK_webpages_Membership_UserProfile] FOREIGN KEY([UserId])[dbo].[UserProfile] ([UserId])TABLE [dbo].[webpages_Membership] CHECK CONSTRAINT [FK_webpages_Membership_UserProfile] /****** Object: ForeignKey [FK_Группа_Специальность] Script Date: 06/01/2016 05:26:23 ******/TABLE [dbo].[Группа] WITH CHECK ADD CONSTRAINT [FK_Группа_Специальность] FOREIGN KEY([Специальность]) REFERENCES [dbo].[Специальность] ([ID_Специальность]) GOTABLE [dbo].[Группа] CHECK CONSTRAINT [FK_Группа_Специальность] /****** Object: ForeignKey [FK_Группа_Типобучения] Script Date: 06/01/2016 05:26:23 ******/TABLE [dbo].[Группа] WITH CHECK ADD CONSTRAINT [FK_Группа_Типобучения] FOREIGN KEY([Типобучения])[dbo].[Типобучения] ([ID_Тип])TABLE [dbo].[Группа] CHECK CONSTRAINT [FK_Группа_Типобучения] /****** Object: ForeignKey [FK_webpages_UsersInRoles_UserProfile] Script Date: 06/01/2016 05:26:23 ******/TABLE [dbo].[webpages_UsersInRoles] WITH CHECK ADD CONSTRAINT [FK_webpages_UsersInRoles_UserProfile] FOREIGN KEY([UserId])[dbo].[UserProfile] ([UserId])TABLE [dbo].[webpages_UsersInRoles] CHECK CONSTRAINT [FK_webpages_UsersInRoles_UserProfile] /****** Object: ForeignKey [FK_webpages_UsersInRoles_webpages_Roles] Script Date: 06/01/2016 05:26:23 ******/TABLE [dbo].[webpages_UsersInRoles] WITH CHECK ADD CONSTRAINT [FK_webpages_UsersInRoles_webpages_Roles] FOREIGN KEY([RoleId])[dbo].[webpages_Roles] ([RoleId])TABLE [dbo].[webpages_UsersInRoles] CHECK CONSTRAINT [FK_webpages_UsersInRoles_webpages_Roles] /****** Object: ForeignKey [FK_Факультет_Спкциальность_Специальность] Script Date: 06/01/2016 05:26:23 ******/TABLE [dbo].[Факультет_Специальность] WITH CHECK ADD CONSTRAINT [FK_Факультет_Спкциальность_Специальность] FOREIGN KEY([ID_Специальность]) REFERENCES [dbo].[Специальность] ([ID_Специальность])TABLE [dbo].[Факультет_Специальность] CHECK CONSTRAINT [FK_Факультет_Спкциальность_Специальность] GO /****** Object: ForeignKey [FK_Факультет_Спкциальность_Факультет] Script Date: 06/01/2016 05:26:23 ******/TABLE [dbo].[Факультет_Специальность] WITH CHECK ADD CONSTRAINT [FK_Факультет_Спкциальность_Факультет] FOREIGN KEY([ID_Факультет])[dbo].[Факультет] ([ID_Факультет])TABLE [dbo].[Факультет_Специальность] CHECK CONSTRAINT [FK_Факультет_Спкциальность_Факультет] /****** Object: ForeignKey [FK_Студент_Специальность] Script Date: 06/01/2016 05:26:23 ******/TABLE [dbo].[Студент] WITH CHECK ADD CONSTRAINT [FK_Студент_Специальность] FOREIGN KEY([ID_Специальность]) REFERENCES [dbo].[Специальность] ([ID_Специальность]) GOTABLE [dbo].[Студент] CHECK CONSTRAINT [FK_Студент_Специальность] /****** Object: ForeignKey [FK_Студент_Типобучения] Script Date: 06/01/2016 05:26:23 ******/TABLE [dbo].[Студент] WITH CHECK ADD CONSTRAINT [FK_Студент_Типобучения] FOREIGN KEY([ID_ТипОбучения])[dbo].[Типобучения] ([ID_Тип])TABLE [dbo].[Студент] CHECK CONSTRAINT [FK_Студент_Типобучения] /****** Object: ForeignKey [FK_Преподаватель_Должность] Script Date: 06/01/2016 05:26:23 ******/TABLE [dbo].[Преподаватель] WITH CHECK ADD CONSTRAINT [FK_Преподаватель_Должность] FOREIGN KEY([ID_Должность]) REFERENCES [dbo].[Должность] ([ID_должность]) GOTABLE [dbo].[Преподаватель] CHECK CONSTRAINT [FK_Преподаватель_Должность] /****** Object: ForeignKey [FK_СтудентГруппа_Группа] Script Date: 06/01/2016 05:26:23 ******/TABLE [dbo].[СтудентГруппа] WITH CHECK ADD CONSTRAINT [FK_СтудентГруппа_Группа] FOREIGN KEY([ID_Группа])[dbo].[Группа] ([ID_Группа])TABLE [dbo].[СтудентГруппа] CHECK CONSTRAINT [FK_СтудентГруппа_Группа] /****** Object: ForeignKey [FK_СтудентГруппа_Студент] Script Date: 06/01/2016 05:26:23 ******/TABLE [dbo].[СтудентГруппа] WITH CHECK ADD CONSTRAINT [FK_СтудентГруппа_Студент] FOREIGN KEY([ID_Студент])[dbo].[Студент] ([ID_Студент])TABLE [dbo].[СтудентГруппа] CHECK CONSTRAINT [FK_СтудентГруппа_Студент] /****** Object: ForeignKey [FK_Лицо_UserProfile] Script Date: 06/01/2016 05:26:24 ******/TABLE [dbo].[Лицо] WITH CHECK ADD CONSTRAINT [FK_Лицо_UserProfile] FOREIGN KEY([ID_Лица])[dbo].[UserProfile] ([UserId])TABLE [dbo].[Лицо] CHECK CONSTRAINT [FK_Лицо_UserProfile] /****** Object: ForeignKey [FK_Лицо_Паспорт] Script Date: 06/01/2016 05:26:24 ******/TABLE [dbo].[Лицо] WITH CHECK ADD CONSTRAINT [FK_Лицо_Паспорт] FOREIGN KEY([ID_Паспорт])[dbo].[Паспорт] ([ID])TABLE [dbo].[Лицо] CHECK CONSTRAINT [FK_Лицо_Паспорт] /****** Object: ForeignKey [FK_Лицо_Пол] Script Date: 06/01/2016 05:26:24 ******/TABLE [dbo].[Лицо] WITH CHECK ADD CONSTRAINT [FK_Лицо_Пол] FOREIGN KEY([ID_Пол])[dbo].[Пол] ([ID])TABLE [dbo].[Лицо] CHECK CONSTRAINT [FK_Лицо_Пол] /****** Object: ForeignKey [FK_Лицо_Преподаватель] Script Date: 06/01/2016 05:26:24 ******/TABLE [dbo].[Лицо] WITH CHECK ADD CONSTRAINT [FK_Лицо_Преподаватель] FOREIGN KEY([ID_Лица]) REFERENCES [dbo].[Преподаватель] ([ID_Преподаватель]) GOTABLE [dbo].[Лицо] CHECK CONSTRAINT [FK_Лицо_Преподаватель] /****** Object: ForeignKey [FK_Лицо_Студент] Script Date: 06/01/2016 05:26:24 ******/TABLE [dbo].[Лицо] WITH CHECK ADD CONSTRAINT [FK_Лицо_Студент] FOREIGN KEY([ID_Лица])[dbo].[Студент] ([ID_Студент])TABLE [dbo].[Лицо] CHECK CONSTRAINT [FK_Лицо_Студент] GO Приложение Г - Структураконцептуальной моделина основе DSL <?xmlversion="1.0"encoding="utf-8"?> <edmx:EdmxVersion="3.0"xmlns:edmx="http://schemas.microsoft.com/ado/2009/11/edmx"> <!-- EF Runtime content --> <edmx:Runtime> <!-- SSDL content --> <edmx:StorageModels> <SchemaNamespace="Хранилище SportEducationModel"Provider="System.Data.SqlClient"ProviderManifestToken="2008"Alias="Self"xmlns:store="http://schemas.microsoft.com/ado/2007/12/edm/EntityStoreSchemaGenerator"xmlns="http://schemas.microsoft.com/ado/2009/11/edm/ssdl"> <EntityTypeName="Группа"> <Key> <PropertyRefName="ID_Группа" /> </Key> <PropertyName="ID_Группа"Type="int"StoreGeneratedPattern="Identity"Nullable="false" /> <PropertyName="Наименование"Type="nvarchar"MaxLength="12"Nullable="false" /> <PropertyName="Специальность"Type="int"Nullable="false" /> <PropertyName="Годобучения"Type="nchar"MaxLength="10"Nullable="false" /> </EntityType> <EntityTypeName="Должность"> <Key> <PropertyRefName="ID_должность" /> </Key> <PropertyName="ID_должность"Type="int"StoreGeneratedPattern="Identity"Nullable="false" /> <PropertyName="Должность_"Type="nvarchar"MaxLength="50"Nullable="false" /> </EntityType> <EntityTypeName="Лицо"> <Key> <PropertyRefName="ID_Лица" /> </Key> <PropertyName="ID_Лица"Type="int"Nullable="false" /> <PropertyName="Имя"Type="nvarchar"MaxLength="50"Nullable="false" /> <PropertyName="Отчество"Type="nvarchar"MaxLength="50"Nullable="false" /> <PropertyName="Фамилия"Type="nvarchar"MaxLength="50"Nullable="false" /> <PropertyName="ID_Паспорт"Type="int" /> <PropertyName="ID_Адрес"Type="int" /> <PropertyName="ID_Пол"Type="smallint" /> <PropertyName="Дата_рождения"Type="date" /> </EntityType> <EntityTypeName="Паспорт"> <Key> <PropertyRefName="ID" /> </Key> <PropertyName="ID"Type="int"Nullable="false" /> <PropertyName="Серия"Type="nchar"MaxLength="5"Nullable="false" /> <PropertyName="N паспорта"Type="nvarchar"MaxLength="20"Nullable="false" /> <PropertyName="Когдавыдан"Type="datetime" /> <PropertyName="Кемвыдан"Type="nvarchar"MaxLength="50" /> </EntityType> <EntityTypeName="Пол"> <Key> <PropertyRefName="ID" /> </Key> <PropertyName="ID"Type="smallint"Nullable="false" /> <PropertyName="Пол"Type="nchar"MaxLength="10" /> <PropertyName="Краткое"Type="nchar"MaxLength="1" /> </EntityType> <EntityTypeName="Преподаватель"> <Key> <PropertyRefName="ID_Преподаватель" /> </Key> <PropertyName="ID_Преподаватель"Type="int"Nullable="false" /> <PropertyName="ID_Должность"Type="int" /> </EntityType> <EntityTypeName="Специальность"> <Key> <PropertyRefName="ID_Специальность" /> </Key> <PropertyName="ID_Специальность"Type="int"StoreGeneratedPattern="Identity"Nullable="false" /> <PropertyName="Наименование"Type="nvarchar"MaxLength="80"Nullable="false" /> <PropertyName="Код"Type="nvarchar"MaxLength="50" /> </EntityType> <EntityTypeName="Студент"> <Key> <PropertyRefName="ID_Студент" /> </Key> <PropertyName="ID_Студент"Type="int"Nullable="false" /> <PropertyName="N_ЗачКН"Type="int"Nullable="false" /> <PropertyName="Годпоступления"Type="date" /> <PropertyName="ID_Специальность"Type="int" /> <PropertyName="ID_ТипОбучения"Type="int" /> </EntityType> <EntityTypeName="СтудентГруппа"> <Key> <PropertyRefName="ID_Студент" /> <PropertyRefName="ID_Группа" /> </Key> <PropertyName="ID_Студент"Type="int"Nullable="false" /> <PropertyName="ID_Группа"Type="int"Nullable="false" /> </EntityType> <EntityTypeName="Типобучения"> <Key> <PropertyRefName="ID_Тип" /> </Key> <PropertyName="ID_Тип"Type="int"StoreGeneratedPattern="Identity"Nullable="false" /> <PropertyName="Наименование"Type="nvarchar"MaxLength="50" /> <PropertyName="Кол_лет"Type="real" /> </EntityType> <EntityTypeName="Факультет"> <Key> <PropertyRefName="ID_Факультет" /> </Key> <PropertyName="ID_Факультет"Type="int"StoreGeneratedPattern="Identity"Nullable="false" /> <PropertyName="Наименование"Type="nvarchar"MaxLength="80"Nullable="false" /> </EntityType> <EntityTypeName="Факультет_Специальность"> <Key> <PropertyRefName="ID_Факультет" /> <PropertyRefName="ID_Специальность" /> </Key> <PropertyName="ID_Факультет"Type="int"Nullable="false" /> <PropertyName="ID_Специальность"Type="int"Nullable="false" /> </EntityType> <AssociationName="FK_Группа_Специальность"> <EndRole="Специальность"Type="Self.Специальность"Multiplicity="1" /> <EndRole="Группа"Type="Self.Группа"Multiplicity="*" /> <ReferentialConstraint> <PrincipalRole="Специальность"> <PropertyRefName="ID_Специальность" /> </Principal> <DependentRole="Группа"> <PropertyRefName="Специальность" /> </Dependent> </ReferentialConstraint> </Association> <AssociationName="FK_Группа_Типобучения"> <EndRole="Типобучения"Type="Self.Типобучения"Multiplicity="1" /> <EndRole="Группа"Type="Self.Группа"Multiplicity="*" /> <ReferentialConstraint> <PrincipalRole="Типобучения"> <PropertyRefName="ID_Тип" /> </Principal> <DependentRole="Группа"> <PropertyRefName="Типобучения" /> </Dependent> </ReferentialConstraint> </Association> <AssociationName="FK_Лицо_Паспорт"> <EndRole="Паспорт"Type="Self.Паспорт"Multiplicity="0..1" /> <EndRole="Лицо"Type="Self.Лицо"Multiplicity="*" /> <ReferentialConstraint> <PrincipalRole="Паспорт"> <PropertyRefName="ID" /> </Principal> <DependentRole="Лицо"> <PropertyRefName="ID_Паспорт" /> </Dependent> </ReferentialConstraint> </Association> <AssociationName="FK_Лицо_Пол"> <EndRole="Пол"Type="Self.Пол"Multiplicity="0..1" /> <EndRole="Лицо"Type="Self.Лицо"Multiplicity="*" /> <ReferentialConstraint> <PrincipalRole="Пол"> <PropertyRefName="ID" /> </Principal> <DependentRole="Лицо"> <PropertyRefName="ID_Пол" /> </Dependent> </ReferentialConstraint> </Association> <AssociationName="FK_Лицо_Преподаватель"> <EndRole="Преподаватель"Type="Self.Преподаватель"Multiplicity="1" /> <EndRole="Лицо"Type="Self.Лицо"Multiplicity="0..1" /> <ReferentialConstraint> </Association> <!-- Diagram content (shape and connector positions) --> <Diagrams></Diagrams> </Designer> </edmx:Edmx>   Приложение Д - Обоснование модели выбора жизненного цикла Таблица Д.1 - Выбор модели ЖЦ на основе характеристик требований Требования Каскадная V-образная Прото-типирование Спиральная RAD Инкрементная Являются ли требования легко определимыми и/или хорошо известными Да Да Нет Нет Да Нет Могут ли требования заранее определятся в цикле Да Да Нет Нет Да Да Часто ли изменяются требования в цикле Нет Нет Да Да Да Нет Нужно ли демонстрировать требования с целью определения Нет Нет Да Да Да Нет Требуется ли демонстрация возможностей проверка концепции Нет Нет Да Да Да Нет Будут ли требования отражать сложность системы Нет Нет Да Да Нет Да Обладает ли требование функциональными свойствами на раннем этапе Нет Нет Да Да Да Да Таблица Д.2 - Выбор модели ЖЦ на основе характеристик участников команды разработчиков Команда разработчиков проекта Каскадная V-образная Прото-типирование Спиральная RAD Инкрементная Являются ли проблемы предметной области проекта новыми для большинства разработчиков Нет Нет Да Да Нет Нет Является ли технология предметной области проекта новой для большинства разработчиков Да Да Нет Да Нет Да Являются ли инструменты, используемые проектом, новыми для большинства разработчиков Да Да Нет Да Нет Нет Изменяются ли роли участников проекта во время ЖЦ Нет Нет Да Да Нет Да Могут ли разработчики проекта пройти обучение Нет Да Нет Нет Да Да Является ли структура более значимой для разработчиков, чем гибкость Да Да Нет Нет Нет Да Будет ли менеджер проекта строго отслеживать прогресс проекта Да Да Нет Да Нет Да Важна легкость распределения ресурсов Да Да Нет Нет Да Да Приемлет ли команда равноправные обзоры инспекций, менеджмент/обзоры заказчиков, а так же стадии Да Да Да Да Нет Да Таблица Д.З - Выбор модели ЖЦ на основе характеристик типа проектов и рисков Тип проекта и риски Каскадная V-образная Прото-типирование Спиральная RAD Инкрементная Будет ли проект идентифицировать новое направление продукта для организации Нет Нет Да Да Нет Да Будет ли проект иметь тип системной интеграции Нет Да Да Да Да Да Будет ли проект являться расширением существующей системы Нет Да Нет Нет Да Да Будет ли финансирование проекта стабильным на всем протяжении ЖЦ Да Да Да Нет Да Нет Ожидается ли длительная эксплуатация продукта в организации Да Да Нет Да Нет Да Должна ли быть высокая степень надежности Нет Да Нет Да Нет Да Будет ли система изменяться, возможно, с применением непредвиденных методов, на этапе сопровождения Нет Нет Да Да Нет Да Является ли график ограниченным Нет Нет Да Да Да Да Являются ли «прозрачными» интерфейсные модули Да Да Нет Нет Да Доступны ли повторно используемые компоненты Нет Нет Да Да Да Нет Являются ли достаточными ресурсы (время, деньги, инструменты, персонал) Нет Нет Да Да Нет Нет Таблица Д.4 - Выбор модели ЖЦ на основе характеристик пользователей Коллектив Пользователей Каскадная V-образная Прото-типирование Спиральная RAD Инкрементная Будет ли присутствие пользователей ограниченно в ЖЦ Да Да Нет Да Нет Да Будут ли пользователи знакомы с определением системы Нет Нет Да Да Нет Да Будут ли пользователи ознакомлены с проблемами предметной области Нет Нет Да Нет Да Да Будут ли пользователи вовлечены во все фазы ЖЦ Нет Нет Да Нет Да Нет Будет ли заказчик отслеживать ход выполнения проекта Нет Нет Да Да Нет Нет Похожие работы на - Анализ и моделирование бизнес-процессов системы физкультурно-спортивного воспитания населения на примере РГЭУ (РИНХ)   Нужна качественная работа без плагиата? Другие дипломные работы по информационному обеспечению Не нашли материал для своей работы? Поможем написать уникальную работу Без плагиата! Узнайте © 2003 - 2022 «Библиофонд» Обратная связь Пользовательское соглашение Политика конфиденциальности Полная версия Помощь по учебным работам Консультация по курсовой работе Консультация по дипломной работе ВКР Консультация по реферату Консультация по отчетам о практике