Разработка базы данных

ВведениеАктуальность исследования. В современном мире вопрос о применении новых информационных технологий в учебном процессе особенно актуален. Это не только современные средства, но и новые формы и методы преподавания, новый подход к процессу обучения. Использование мультимедийных средств помогает реализовать личностно-ориентированный подход в обучении, обеспечивает индивидуализацию и дифференциацию учебного процесса с учетом возрастных специфических особенностей учащихся, их уровня знаний и навыков.Цель исследования проанализировать макет веб-сервиса «Мониторинг учебного процесса группы студентов для преподавателей».Для достижения этой цели необходимо решить следующие задачи:1. Рассмотреть анализ состояния исследуемой области;2. Проанализировать формулировку цели работы и перечень решаемых задач;3. Выявить математическую формулировку целевой функции: показатель, значащие факторы, ограничения;4. Найти перечень основных применяемых стандартов;5. Сделать сравнительную оценку своей разработки;6. Разработать техническое задание на работу.Структура курсовой работы введение, 6 глав, заключение и список используемых источников. Курсовая работа имеет 33, 3 рисунка, 1 таблицу и 7 источников литературы.1. Анализ состояния исследуемой областиВысшее учебное заведение организационно состоит из факультетов. В свою очередь факультет включается в себя несколько кафедр. На кафедрах работают как штатные преподаватели, так и преподаватели-совместители. Существует три основных формы обучения: очная. заочная, вечерняя.Каждая выпускающая кафедра обучает студентов по нескольким специальностям. Каждый год на каждую специальность, на основе конкурсного отбора по результатам вступительных экзаменов зачисляются студенты. На каждого студента заводится личное дело, которое хранится в течении всего срока обучения, а затем передается в архив. Для правильной организации процесса обучения, студентов каждой специальности делят на группы. В каждой группе деканом назначается староста.Процесс обучения осуществляется на основе учебных планов, которые разрабатываются на выпускающих кафедрах и затем утверждаются деканом и начальником учебного управления. В учебных планах по семестрам отражаются наименования преподаваемых дисциплин, вид аттестации и ФИО преподавателя, его должность и звание.Различают следующие виды аттестации:Контроль знаний студентов осуществляется путем проведения различных видов аттестации: промежуточной текущей, итоговой. Аттестация выставляется на основании баллов, которые устанавливаются преподавателем по каждой дисциплине на основании разработанной им процедуры мониторинга успеваемости студентов.Текущая аттестация проводится по трем контрольным точкам в течение семестра. Отметка в контрольной точке аккумулирует в себе результат выполнения всех видов работ студентом за данный период в соответствии с учебно-методическим комплексом дисциплины. Данная система оценки знаний является базой для перехода вуза к зачету учебных единиц (кредитов) в соответствии с положениями Болонского соглашения в области образования.По окончании каждого семестра проводится промежуточный контроль в форме экзамена, зачета, защиты курсового проекта или курсовой работы.По результатам текущей и промежуточной аттестации студенту выставляется итоговая оценка по каждой изучаемой дисциплине.За систематическую неудовлетворительную аттестацию к студентам в установленном порядке могут быть применены меры дисциплинарного воздействия вплоть до отчисления за академическую неуспеваемость.В последнем семестре обучения студенты сдают государственный экзамен и защищают дипломный проект. Перед сдачей государственного экзамена по специальности на каждого студента высчитывается средний балл по итогам полученных оценок в течение всего периода обучения. Данная оценка является критерием при сдаче студентом государственного экзамена по специальности. В дальнейшем, при переходе вуза к зачету учебных единиц, при накопительной модели начисления балов по учебным дисциплинам каждый студент обязан набрать необходимое количество баллов за весь период обучения.Дипломный проект является заключительной самостоятельной работой студента на последнем году обучения. По своему содержанию он должен предоставлять соьой оригинальное научное исследование, освещающее одну из актуальных проблем в области будущей профессиональной деятельности выпускника.Основными отчетными документом по успеваемости студентов являются отчетные документы по результатам текущей, промежуточной и итоговой аттестации, которые представляются в учебное управление и используются деканом и его заместителями для анализа и принятия управленческих решений.Таким образом, учет успеваемости студентов - сложная задача, требующая большой обработки данных. Следовательно, эта информация важна не только для деканата, но и для кафедры.Использование компьютерного подхода в решении данной проблемы позволяет значительно сократить временные и трудовые затраты на выполнение поиска и предоставление информации о результатах успеваемости групп, а также отдельных студентов, выявление отстающих студентов. Возникает необходимость автоматизировать учет успеваемости студенческих групп и учет персональных данных.2. Формулировка цели работы и перечень решаемых задачПроцедура мониторинга качества (эффективности) деятельности администрации образовательных учреждений.В список должностей, составляющих администрацию образовательного учреждения (далее ― ОУ), задействованных в реализации дистанционного обучения, входят директор ОУ, заместитель директора ОУ по учебно-воспитательному процессу, заместитель директора ОУ по научной работе, заместитель директора по информатизации, диспетчер, ответственный за реализацию дистанционного обучения в ОУ.Мониторинг качества (эффективности) деятельности администрации образовательных учреждений является обязательной технологической составляющей, встроенной во все процессы, происходящие в связи с созданием в ОУ новой информационно-образовательной среды. Мониторинг предполагает постоянное отслеживание состояния и динамики управленческих действий, осуществляемых администрацией ОУ в рамках реализации различных направлений дистанционного обучения, анализ полученных данных, который служит основанием для дальнейшей разработки управленческих шагов (а, в случае необходимости, их корректировки), адекватных зафиксированной при мониторинге образовательной ситуации в ОУ.Цель мониторинга ― обеспечить условия реализации дистанционного обучения обучающихся в соответствии с их целями и задачами, направленными на достижение максимально возможного уровня удовлетворения образовательных потребностей обучающихся в получении ими качественного образования.Мониторинг деятельности администрации ОУ по реализации ДО включает решение следующих задач:-  систематического наблюдения регионального и территориального координаторов дистанционного обучения за деятельностью управленческих структур всех ОУ, участвующих в проекте;-  осуществления краткосрочного прогнозирования результатов предпринимаемых управленческих действий на разных этапах реализации дистанционного обучения;-  предупреждения ситуаций, связанных с прогнозируемыми рисками, и проведения экспресс-корректировки условий функционирования объектов, их вызывающих;-  оценки полноты и эффективности предпринимаемых управленческих шагов.Этапы мониторинга.Мониторинг деятельности администрации осуществляется в соответствии со следующими этапами реализации ДО.Диагностический этап ― период исследования уровня готовности образовательного учреждения к участию в реализации дистанционного обучения. Мониторинг на данном этапе предполагает исследование уровня эффективности деятельности администрации по организации и проведению диагностики уровня технологической и педагогической готовности к осуществлению учебного процесса с использованием ДОТ. Организационный этап, в течение которого проводится большой информационный педагогический совет ОУ, осуществляется расстановка кадров, формируются рабочая и аналитическая группы по реализации дистанционного обучения, проводится серия методических советов ОУ, информационно-обучающих семинаров, составление учебного плана и расписания в соответствии с сетевым расписанием, разработанным территориальным координатором дистанционного обучения, формирование учебных групп обучающихся групп в для обучения с использованием ДОТ, а также информирование родительской общественности о порядке реализации проекта. Этап апробации. Аналитический этап (экспериментальный режим). Этап внедрения. Аналитический этап (режим стабильного функционирования).Периодичность мониторинга.На пред диагностическом, диагностическом и организационном этапах ― в соответствии со сроками их проведения.В течение этапа апробации ― один раз в полгода.В течение этапа внедрения ― один раз в год.Принципы проведения мониторинга.Объективность информации. Принцип обусловлен необходимостью получения достоверных и надёжных данных, позволяющих проанализировать ход реализации дистанционного обучения обучающихся.Обеспечивается непосредственным участием экспертов в проведении мониторинга через мониторинговые визиты в регионы; формализацией и лёгкостью проверки и конкретностью получаемой информации.Сравнимость данных. Принцип обусловлен тем, что при отслеживании результатов хода реализации дистанционного обучения предполагается выявлять не только его состояние, но и изменения, которые происходят в его процессе, а также прогнозировать возможные социальные последствия и образовательные эффекты.Обеспечивается непрерывностью изучения хода реализации дистанционного обучения на основе одинаковых эмпирических показателей.Адекватность. Этот принцип предполагает оценку влияния на ход реализации проекта различных внешних социально-экономических, институциональных и других факторов, специфических факторов, вызванных различиями в региональных условиях, а также интерпретацию с их учётом полученных информационно-аналитических данных.Такая оценка предполагает изучение хода реализации дистанционного обучения с учётом изменяющихся внешних условий его проведения, оценка влияния которых включается в диагностические методики, опросы и рекомендации для экспертов при проведении мониторинговых поездок в регионы.3. Математическая формулировка целевой функции: показатель, значащие факторы, ограниченияНа основе проведенного анализа существующих методических и технологических решений используемых (и/или тех, которые могут быть использованы) при проведении мониторинга и сформированных концептуальных подходов была разработана модель мониторинга, характеризующего реализацию основных общеобразовательных программ в сетевой форме с системой зачета образовательных результатов освоения других модулей и программ.Модель мониторинга учитывает реализации образовательной деятельности по всем видам образования во всех типах образовательных организаций и организаций, осуществляющих обучение, особенности статистического наблюдения, а также задачу снижения «бюрократической нагрузки» на образовательные организации.Представленная ниже модель учитывает особенности федерального статистического наблюдения в сфере образования, задачу снижения «бюрократической нагрузки» на образовательные организации и особенности реализации образовательной деятельности по всем видам образования во всех типах образовательных организаций и организаций, осуществляющих обучение.Описание процесса мониторинга.Целью данного мониторинга является оценка интенсивности и эффективности процессов внедрения и использования сетевой формы и системы зачета образовательных результатов в ходе освоения обучающимися основных общеобразовательных программ.В связи с этим в ходе мониторинга будут решаться следующие задачи, определяющие процесс его разработки, реализации и использования:- Выявление ключевых характеристик (критериев) образовательных процессов, характеризующих реализацию основных общеобразовательных программ в сетевой форме с системой зачета образовательных результатов освоения других модулей и программ;- Подбор показателей, позволяющих описать эти характеристики, и определение возможностей включение их в формы федерального статистического наблюдения;- Сбор данных по сформированному набору показателей и формирование соответствующей базы данных с детализацией до уровня образовательных организаций;- Статистическая и аналитическая обработка полученных данных с использованием метода экспертных оценок;- Определение нормативных значений показателей, характеризующих реализацию основных общеобразовательных программ в сетевой форме с системой зачета образовательных результатов освоения других модулей и программ, которые могут быть использованы в качестве целевых значений;- Формирование рекомендаций по развитию сетевой формы и системы зачета образовательных результатов в ходе освоения обучающимися основных общеобразовательных программ.Объектом оценки в рамках данного мониторинга становится деятельность конкретных образовательных организаций всех уровней и типов по внедрению и использования сетевой формы и системы зачета образовательных результатов в ходе освоения обучающимися основных общеобразовательных программ.Источники данных в первичном формате – указанные образовательные организации.4. Перечень основных применяемых стандартовТаблица 1 – Перечень основных применяемых стандартовГОСТ 28195-89Оценка качества программных средств. Общие положения01.07.1990действующийНазвание (англ.): Quality control of software systems. General principles Область применения: Настоящий стандарт устанавливает общие положения по оценке качества программных средств вычислительной техники (далее - ПС), поставляемых через фонды алгоритмов и программ (ФАП), номенклатуру и применяемость показателей качества ПСГОСТ 28806-90Качество программных средств. Термины и определения01.01.1992действующийНазвание (англ.): Software quality. Terms and definitions Область применения: Настоящий стандарт устанавливает термины и определения понятий в области качества программных средств.Термины, установленные настоящим стандартом, обязательны для применения во всех видах документации и литературы по вычислительной технике и программным средствам, входящих в сферу работ по стандартизации и использующих результаты этих работГОСТ Р 51188-98Защита информации. Испытания программных средств на наличие компьютерных вирусов. Типовое руководство01.07.1999действующийНазвание (англ.): Information security. Software testing for the existence of computer viruses. The sample manual Область применения: Настоящий стандарт распространяется на испытания программных средств (ПС) и их компонентов, цели которых - обнаружить в этих ПС и устранить из них компьютерные вирусы силами специальных предприятий (подразделений), и устанавливает общие требования к организации и проведению таких испытаний.Настоящий стандарт предназначен для применения в испытательных лабораториях, проводящих сертификационные испытания ПС на выполнение требований защиты информацииГОСТ Р 51189-98Средства программные систем вооружения. Порядок разработки01.07.1999действующийНазвание (англ.): Software for military systems. The order of creating Область применения: Настоящий стандарт распространяется на любые программные средства, программные изделия, программы и другие виды и (или) компоненты программной продукции, предназначенные для использования в составе систем вооружения, и устанавливает общие правила разработки, документирования и изготовления (воспроизведения) программных средств систем вооруженияГОСТ Р 51904-2002Программное обеспечение встроенных систем. Общие требования к разработке и документированию01.07.2003действующийНазвание (англ.): Embedded system software. General requirements to development and documentation Область применения: Настоящий стандарт распространяется на процессы разработки и документирования программного обеспечения (ПО) встроенных систем реального времени. Стандарт распространяется на все действия, имеющие отношение к разработке программного обеспечения.Настоящий стандарт применяют полностью ко всему поставляемому программному обеспечению, включая среду разработки, если контрактом не предусмотрено использование специальных стандартов для определенных заказчиком типов ПО. Стандарт не применим для аппаратных элементов программно-аппаратного обеспеченияГОСТ Р 52657-2006Информационно-коммуникационные технологии в образовании. Образовательные интернет-порталы федерального уровня. Рубрикация информационных ресурсов01.07.2008действующийНазвание (англ.): Information and communication technologies in education. Federal level educational internet-portals. Information resources system of heading Область применения: Настоящий стандарт устанавливает общие требования к составу и виду рубрик информационных ресурсов образовательных Интернет-порталов федерального уровняГОСТ Р ИСО 9127-94Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов01.07.1995действующийНазвание (англ.): Information processing systems. User documantation and cover information for consumer software packages Область применения: Настоящий стандарт описывает документацию пользователя и информацию на упаковке, которой должны быть снабжены потребительские программные пакеты:- Документация пользователя - эта документация обеспечивает пользователей информацией, необходимой для установки и прогона программного средства.- Информация на упаковке - данную информацию приводят на внешней упаковке пакета с целью предоставления потенциальным покупателям возможности принять решение о применимости данного программного средства в соответствии с их потребностями.Настоящий стандарт не распространяется на:- торговые публикации;- брошюры и листовки, целью которых является содействие распространению пакета;- технические описания программного средства, а также документацию, описывающую содержание программного средстваГОСТ Р ИСО/МЭК 8631-94Информационная технология. Программные конструктивы и условные обозначения для их представления07.07.1995действующийНазвание (англ.): Information technology. Program constructs and conventions for their representation Область применения: Настоящий стандарт посвящен представлению процедурных алгоритмов. Стандарт:а) определяет основное свойство программных конструктивов;b) указывает способ объединения конструктивов;c) устанавливает требования к набору конструктивов;d) допускает описание различных подмножеств установленных конструктивовГОСТ Р ИСО/МЭК 9126-93Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению01.07.1994действующийНазвание (англ.): Information technology. Software product evaluation. Quality characteristics and guidelines for their use Область применения: Настоящий стандарт определяет шесть характеристик, которые с минимальным дублированием описывают качество программного обеспечения. Данные характеристики образуют основу для дальнейшего уточнения и описания качества программного обеспечения. Руководства описывают использование характеристик качества для оценки качества программного обеспечения.Настоящий стандарт не определяет подхарактеристики (комплексные показатели) и показатели, а также методы измерения, ранжирования и оценки.Определения характеристик и соответствующая модель процесса оценки качества, приведенные в настоящем стандарте, применимы тогда, когда определены требования для программной продукции и оценивается ее качество в процессе жизненного цикла.Эти характеристики могут применяться к любому виду программного обеспечения, включая программы ЭВМ и данные, входящие в программно-технические средства (встроенные программы).Настоящий стандарт предназначен для характеристик, связанных с приобретением, разработкой, эксплуатацией, поддержкой, сопровождением или проверкой программного обеспеченияГОСТ Р ИСО/МЭК 10746-1-2004Информационная технология. Открытая распределенная обработка. Базовая модель. Часть 1. Основные положения01.01.2005действующийНазвание (англ.): Information technology. Open distributed processing. Reference model. Part 1. Overview Область применения: Настоящий стандарт содержит:- введение и обоснование открытой распределенной обработки (ОРО);- обзор базовой модели открытой распределенной обработки (БМ-ОРО) и объяснение ее ключевых понятий;- руководство по применению БМ-ОРО.Настоящий стандарт содержит общий обзор и подробное объяснение ОРО и может использоваться различными способами в сочетании с другими стандартами данной серииГОСТ Р ИСО/МЭК 10746-4-2004Информационная технология. Открытая распределенная обработка. Базовая модель. Часть 4. Архитектурная семантика01.01.2005действующийНазвание (англ.): Information technology. Open distributed processing. Reference model. Part 4. Architectural semantics Область применения: Прогресс в области распределенной обработки привел к необходимости координации стандартов по открытой распределенной обработке (ОРО). Базовая модель ОРО предоставляет необходимый для этого каркас, а также устанавливает архитектуру, в которой могут быть скоординированы поддержка распределения, взаимодействия, совместимости и переносимостиГОСТ Р ИСО/МЭК 12119-2000Информационная технология. Пакеты программ. Требования к качеству и тестирование01.01.2002действующийНазвание (англ.): Information technology. Software packages. Quality requirements and testing Область применения: Настоящий стандарт применяется для пакетов программ. Например, для текстовых процессоров, электронных таблиц, программ баз данных, графических пакетов, программ, реализующих технические и научные функции, и для сервисных программ (утилит). Стандарт предназначен только для пакетов, являющихся объектами продажи и поставкиГОСТ Р ИСО/МЭК 12207-99Информационная технология. Процессы жизненного цикла программных средств01.07.2000действующийНазвание (англ.): Information technology. Software life cycle processes Область применения: Настоящий стандарт применяется при приобретении систем, программных продуктов и оказании соответствующих услуг; а также при поставке, разработке, эксплуатации и сопровождении программных продуктов и программных компонентов программно-аппаратных средств, как в самой организации, так и вне ее. Стандарт содержит также те аспекты описания системы, которые необходимы для обеспечения понимания сути программных продуктов и услугГОСТ Р ИСО/МЭК 14764-2002Информационная технология. Сопровождение программных средств01.07.2003действующийНазвание (англ.): Information technology. Software maintenance Область применения: Область применения настоящего стандарта охватывает сопровождение различных программных средств при использовании одинаковых ресурсов сопровождения.Настоящий стандарт устанавливает основную структуру, в пределах которой могут быть выполнены, оценены и практически реализованы общие и конкретные планы сопровождения применительно к области действия и объему заданных программных средств (продуктов).Настоящий стандарт определяет основные положения, точную терминологию и процессы, позволяющие последовательно применять соответствующие технологии (инструментальные средства, методологии и методы) при сопровождении программных средств.Настоящий стандарт в основном предназначен для организаций, сопровождающих программные средства (персонала сопровождения, сопроводителей), а также может быть использован субъектами, отвечающими за разработку и обеспечение качества этих средств. Стандарт может быть применен заказчиками и пользователями систем, содержащих программные средства, которые могут представлять исходные данные для плана сопровождения.Стандарт не распространяется на эксплуатацию программных средств.Настоящий стандарт не предназначен для применения пользователями готовых программных продуктов, не входящих в состав поставляемого продукта.Настоящий стандарт не предназначен для временно или эпизодически используемых программных средств (продуктов)ГОСТ Р ИСО/МЭК 15026-2002Информационная технология. Уровни целостности систем и программных средств01.07.2003действующийНазвание (англ.): Information technology. System and software integrity levels Область применения: Стандарт содержит основные положения, связанные с уровнями целостности, определяет процессы для установления уровней целостности и требований к целостности программных средств, а также устанавливает требования к каждому соответствующему процессу. Стандарт не предопределяет конкретный набор уровней целостности или требования к целостности конкретного программного средства. Стандарт применим только для программных средств.Настоящий стандарт предназначен для применения разработчиками, пользователями, поставщиками и экспертами программных продуктов или систем, содержащих программные средства, а также для административной и технической поддержки данных продуктов и систем.Настоящий стандарт не устанавливает способ интеграции определения уровня целостности в общие процессы жизненного цикла программной инженерииГОСТ Р ИСО/МЭК 15288-2005Информационная технология. Системная инженерия. Процессы жизненного цикла систем01.01.2007действующийНазвание (англ.): Information technology. System engineering. System life cycle processes Область применения: Настоящий стандарт устанавливает общие основы для описания жизненного цикла систем, созданных людьми, определяет детально структурированные процессы и соответствующую терминологию.В настоящем стандарте представлены также процессы, которые поддерживают определение, контроль и совершенствование процессов жизненного цикла внутри организации или в рамках какого-либо проекта.Настоящий стандарт применим к полному жизненному циклу системы, включая замысел, разработку, производство, эксплуатацию и снятие с эксплуатации, а также приобретение и поставку систем, осуществляемых внутри или вне организации.В настоящем стандарте не детализируются процессы жизненного цикла в терминах методов и процедур, необходимых для удовлетворения требований и достижений результатов процессаГОСТ Р ИСО/МЭК 15910-2002Информационная технология. Процесс создания документации пользователя программного средства01.07.2003действующийНазвание (англ.): Information technology. Software user documentation process Область применения: Настоящий стандарт определяет минимально необходимый процесс создания документации пользователя всех видов для программного средства, имеющего интерфейс пользователя.Стандарт предназначен для разработчиков и потребителей документации пользователя.Настоящий стандарт используется для печатной документации, а также для справочных экранов, справочной системы обеспечения поставки, справочной информации и т.д.Стандарт предназначен для применения при двусторонних отношениях и может быть использован, если обе стороны корпоративно связаны. Стандарт также может быть использован одной из сторон для самоконтроляГОСТ Р ИСО/МЭК ТО 9294-93Информационная технология. Руководство по управлению документированием программного обеспечения01.07.1994действующийНазвание (англ.): Information technology. Guidelines for the management of software documentation Область применения: Данный стандарт представляет собой руководство по документированию программного обеспечения для тех руководителей, которые отвечают за производство программного обеспечения или программной продукции.Данный стандарт направлен на определение стратегий, стандартов, процедур, ресурсов и планов, которыми должны заниматься сами руководители для того, чтобы эффективно управлять документированием программного обеспечения.Руководство предназначено для применения ко всем типам программного обеспечения - от простейших программ до наиболее сложного программного набора или системы программного обеспечения. Охвачены все типы программной документации, относящиеся ко всем стадиям жизненного цикла программного обеспеченияГОСТ Р ИСО/МЭК ТО 12182-2002Информационная технология. Классификация программных средств01.07.2003действующийНазвание (англ.): Information technology. Categorization of software Область применения: Областью применения настоящего стандарта является классификация программных средств (включая соответствующие продукты разработки программных средств и данные), создаваемых в процессах программной инженерии. Стандарт описывает схему классификации программных средств (ПС), охватывающую различные подходы к их классификации, а также существенные характеристики и атрибуты, описывающие и определяющие данные ПС и их классы.Классификация ПС, установленная в настоящем стандарте, распространяется на область программной инженерии и связанные с ней стандарты, ПС, данные и методологии.Настоящий стандарт в основном предназначен для специалистов в области программной инженерии, пользователей и разработчиков стандартов в данной областиГОСТ Р ИСО/МЭК ТО 15271-2002Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)01.07.2003действующийНазвание (англ.): Information technology. Guide for the application of GOST R ISO/IEC 12207 (Software life cycle processes) Область применения: Настоящий стандарт содержит рекомендации по применению ГОСТ Р ИСО/МЭК 12207.В стандарте основное внимание уделено особенностям, подлежащим учету при прикладном применении ГОСТ Р ИСО/МЭК 12207 в условиях реальных проектов создания программных средств. Приведенные в настоящем стандарте рекомендации не касаются обсуждения обоснованности требований ГОСТ Р ИСО/МЭК 12207.В стандарте рассмотрены три основополагающие модели жизненного цикла и приведены примеры прикладного применения ГОСТ Р ИСО/МЭК 12207ГОСТ Р ИСО/МЭК ТО 16326-2002Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом01.07.2003действующийНазвание (англ.): Software engineering. Guide for the application of GOST R ISO/IEC 12207 to project management Область применения: Настоящий стандарт уточняет и дополняет ГОСТ Р ИСО/МЭК 12207 в части процесса управления.Настоящий стандарт предназначен для лиц, отвечающих за управление реализацией основных процессов по ГОСТ Р ИСО/МЭК 12207: заказа, поставки, разработки, эксплуатации и сопровождения.В настоящем стандарте рассмотрены вопросы, специфичные для программных средств или приводящие к проблемам при реализации основных процессов по ГОСТ Р ИСО/МЭК 12207 в программных проектах5. Сравнительная оценка своей разработки5.1 Структура системыВ ходе разработки выпускной квалификационной работы использовались базы данных, созданные в среде MySQL Workbench, и создано клиентское приложение. Ниже представлена структура базы данных (рис. 1) и структура клиентского приложения (рис. 2).Рисунок 1 – Структура базы данныхРисунок 2 – Структура клиентскогоВ структуре клиентского приложения находятся папки с базовыми настройками проекта, ссылками на библиотеки, здесь же находится конфигурационный файл для подключения к базе данных, начальный файл для работы приложения Program.cs и 5 классов типа Windows Form. В файлах с обычным расширением .cs хранится код обработки формы, то есть основной код. В файлах с расширением .Designer.cs находится автоматически генерируемый код, отвечающий за основные настройки элементов на форме. Файлы типа .resx являются файлами-хранилищами ресурсов, представленных в XML виде. В файле «DiplomHelp.chm» находится справочная информация по проекту, призванная помочь пользователю.В данной структуре форма «StartWindows» является начальным окном выбора предмета, «MainWindow» содержит в себе основную таблицу оценок, «UpMarks» является окном проставления оценок за выбранное занятие, «LesEdit» является окном добавления, изменения и сохранения занятий, а форма «KursEdit» предоставляет аналогичные возможности для работы с учебными курсами. Данные формы будут подробно рассмотрены ниже.Общая схема связей основных классов представлена на рис. 3.5.2 Разработка клиент-серверной частиРазработка клиент-серверной части проекта, то есть связь между клиентским приложением и базой данных, реализуется при помощи специальной библиотеки MySQL для C#, свободно распространяемой на сайте MySQL. В структуре клиентского приложения (рис. 4) представлена часть этой библиотеки, а именно «MySQL.Data» в папке «Ссылки». Остальные части библиотеки не являются необходимыми для работы.Рисунок 3 – Схема связей между классамиДля работы с базой данных необходимо использовать поставщик данных, который обеспечивает подключение, позволяет выполнять SQL запросы и получать результаты. Для подключения необходимо знать ip адреса сервера, имя базы данных, которая используется системой, имя пользователя и его пароль, номер порта. Вся эта информация хранится в специальном xml-файле с типом расширения .config, что позволяет быстро изменять параметры подключения, а не искать по всему коду очередное поле, которое нужно изменить. В данный момент этот файл выглядит следующим образом: В самом коде связь между окном отображения информации DataGridView и базой данной осуществляется через класс DataTable. DataGridVies – это визуализированная таблица, которая позволяет отображать данные в различных форматах и хранить названия столбцов. DataTable – это внутренняя таблица хранения данных, схожая с DataGridView, но не представляющая пользовательский интерфейс для отображения информации. Создаётся функция, которая возвращает объект типа DataTable, а на входе всегда получает тип ConnectionStringSettings, содержащий информацию о конфигурационном файле с информацией о подключении к базе данных. Внутри функции находится строка с SQL запросом. Пример SQL запроса на выборку данных:string queryString = @"SELECT studId as 'ID', surname as 'Фамилия', name as 'Имя', midname as 'Отчество' FROM students";С помощью строки MySqlConnection con = new MySqlConnection(conString.ConnectionString) происходит подключение к базе данных. Далее создаётся связь между объектом типа MySqlCommand и строкой SQL запроса с указанием на нужное соединение, таким образом создаётся команда запроса к базе данных. Далее открывается соединение с базой по команде con.Open() и запускается режим запроса, в ходе которого вся информация, полученная в ходе SQL запроса, загружается в объект типа DataTable, который и является результатом функции. После получения результатов соединение закрывается. В дальнейшем форма DataGridView в своё свойство DataSource получает результат описанной ранее функции. Таким образом создаётся связь между окном отображения и объектом DataTable.Для случая записи в базу данных необходимо извлечь из окна отображения через свойство DataSource таблицу данных, и после этого при помощи функции записи изменить таблицу. В функции происходят почти те же действия, что и при считывании, однако есть принципиальные различия. Первое – это формирование запроса на обновление. Поскольку чаще всего необходимо будет проставлять оценки, то будет использоваться SQL запрос на обновление информации, уникальный для каждого студента. Поэтому используется цикл для прохождения всех студентов. Запрос в таком случае будет выглядеть примерно следующим образом:queryString = @"UPDATE grades SET grade = " + kostil + @" WHERE studID = " + dt.Rows[i]["ID"] + @" and lesID=" + idLes;В этом коде переменная kostil содержит в себе оценку, idLes – номер идентификатора занятия, а dt.Rows[i][“ID”] содержит идентификатор студента.Рассмотренные SQL запросы на получение информации из базы данных и её обновления являются стандартными в разработанной системе, а потому все похожие представлять нет необходимости.5.3 Разработка базы данныхПроектирование базы данных было подробно описано в главе 7. Благодаря графической оболочке MySQL Workbench для MySQL все SQL запросы на создание таблиц формируются автоматически. В оболочке нужно лишь задать имена столбцов, их тип и несколько параметров, таких как первичный ключ или автоматическое проставление ID. Здесь же есть возможность указать столбцы, являющиеся внешними ключами к другим таблицам. Пример лишь одного SQL запроса на создание таблицы, который генерирует MySQL Workbench, приведён ниже.CREATE TABLE `grades` ( `lesID` int(4) NOT NULL, `studID` int(4) NOT NULL, `grade` decimal(4,2) DEFAULT NULL, `date` date DEFAULT NULL, `teachID` int(4) DEFAULT NULL, `weigth` decimal(2,1) DEFAULT NULL, KEY `IDstud_idx` (`studID`), KEY `IDteach_idx` (`teachID`), KEY `IDless_idx` (`lesID`), CONSTRAINT `IDless` FOREIGN KEY (`lesID`) REFERENCES `lessons` (`lesId`) ON DELETE NO ACTION ON UPDATE NO ACTION, CONSTRAINT `IDstud` FOREIGN KEY (`studID`) REFERENCES `students` (`studId`) ON DELETE NO ACTION ON UPDATE NO ACTION, CONSTRAINT `IDteach` FOREIGN KEY (`teachID`) REFERENCES `teachers` (`teachId`) ON DELETE NO ACTION ON UPDATE NO ACTION) ENGINE=InnoDB DEFAULT CHARSET=utf8;Далее следовало лишь частично заполнить таблицы информацией для того, чтобы было с чем работать далее при разработке клиентской части.Следующим шагом, который необходимо выполнить для больших баз данных, является разработка триггеров. Триггеры выполняются до или после операций над таблицами, к которым они приписаны, а их использование повышает скорость работы СУБД над данными. В основном триггеры помогают обеспечивать целостность базы данных, чем ускоряют работу администратора базы данных. Например, если из родительской таблицы удалить строку, то перед этим из дочерней таблицы, где находится внешний ключ на родительскую, необходимо удалить все данные, относящиеся к удалённой строке. Если этого не будет сделано, то СУБД выдаёт ошибку и просит сначала удалить все внешние ключи на данную строку. В разрабатываемой системе подобные триггеры необходимы для таблиц «Курс», «Преподаватель» и «Занятие», которые могут меняться чаще всего. Пример создания триггеров для таблицы «Курс»:CREATE DEFINER=`root`@`localhost` TRIGGER `sysmp`.`kurs_BEFORE_DELETE` BEFORE DELETE ON `kurs` FOR EACH ROWBEGINdelete from kurs_group where OLD.kursId = idkurs; delete from kurs_year where OLD.kursId = idKurs; delete from formula where OLD.kursId = kursID;delete from lessons where OLD.kursId = kursID; delete from kurs_teach where OLD.kursId = idkursKT;ENDДанный триггер начинает свою работу перед удалением какой-либо строки в таблице «Курс». Перед удалением строки из таблицы триггеры удаляют другие записи, в которых содержится внешний ключ, указывающий на ID родительской таблицы. При этом, если в дочерних таблицах тоже прописаны какие-либо триггеры для события удаления, то они выполняются в то же время, обеспечивая целостность хранимых данных.Более сложный триггер нужен для поддержания целостности связки других таблиц, а именно «Занятие» и «Оценка». Необходимо, чтобы при внесении нового занятия в базу, в таблице «Оценка» для каждого студента по данному занятию создавалась пустая оценка и дата сдачи. Достигается это с помощью следующего триггера:CREATE DEFINER=`root`@`localhost` TRIGGER `sysmp`.`lessons_AFTER_INSERT` AFTER INSERT ON `lessons` FOR EACH ROWBEGINdeclare c int; declare n int;declare ni cursor for SELECT COUNT(*) FROM students where new.grID = `students`.`group`;declare i cursor for select studId from students where new.grID = `students`.`group`; open ni; fetch ni into n; close ni; SET @j = 0;open i; while @j < n dofetch i into c; insert into grades(lesID, studID) value (new.lesId, c); set @j = @j + 1; end while; close i;ENDВ данном случае необходимо использование курсоров, которые являются хранилищем результата запроса, которые в них требуется записать. Первый курсор сохраняет количество студентов, которые учатся в заданной группе, а второй указатель получает ID этих студентов. Далее с помощью результата первого курсора запускается цикл, в котором из второго курсора извлекается необходимая информация, после чего происходит внесение новой строки в таблицу «Оценка».Всё остальное обеспечение целостности данных связано с вводимой информацией, проверка которой возложена на клиентское приложение. Разработка базы данных на этом считается завершённой.6. Техническое задание на работу6.1 Требования к системному ПО системы мониторингаСистема мониторинга должна допускать исполнение ПО платформы на серверах под управлением операционных систем Linux и Microsoft Windows. Выбор операционной системы производится Заказчиком с учетом собственных корпоративных стандартов и имеющихся лицензий на использование ОС.Установку ОС на серверное оборудование системы мониторинга производится Подрядчиком проекта.Система мониторинга должна быть кросс-платформенной в смысле использования баз данных для хранения информации и допускать использования таких реляционных CУБД как MySQL, Oracle, PostgreSQL и др.Выбор СУБД производится Заказчиком с учетом собственных корпоративных стандартов и имеющихся лицензий на использование с учетом поддерживаемого релиза ПО платформой системы мониторинга.Установку СУБД на серверное оборудование системы мониторинга производится Подрядчиком проекта одновременно с установкой ПО платформы. 6.2 Требования к ПО платформы системы мониторингаПО платформы должно иметь модульную функциональную архитектуру и включать четыре основные подсистемы:- подсистему централизованного сбора и обработки информации;- подсистему хранения данных;- консоль управления;- подсистему отображения и аналитики;Должна использоваться единая модель данных для всех составляющих компонентов. Должны иметься гибкие средства масштабирования, позволяющие обеспечивать требуемые характеристики производительности в случае увеличения количества контролируемых объектов, видов собираемой информации и/или количества одновременно работающих пользователей.Должна предоставляться возможность управления функционалом как одним администратором, так и возможность разделения ответственности по администрированию между несколькими администраторами с разделением зон отвественности.Подсистема централизованного сбора и обработки информации должна обеспечивать следующие функции: - Возможность сбора данных с помощью протоколов ICMP, HTTP, SNMP, Syslog, WMI, опрос по tcp/udp портам.- Автоматическое обнаружение объектов мониторинга.- Автоматическое обнаружение топологических связей объектов.- Мониторинг доступности контролируемых объектов с заданным периодом опроса.- Сохранение собранных данных, их управляемое агрегирование для последующего анализа.- Управление параметрами опроса объектов мониторинга (периодичность, измеряемые параметры).- Возможность оперативного изменения параметров мониторинга в связи с технологическими изменениями и изменениями требований Заказчика.- Возможность расширения функционала, за счет включения дополнительных модулей (plugins) в систему, в частности сбора информации Netflow, результатов тестов IP SLA. Расширение функционала должно производиться без необходимости использования дополнительных серверов и консолей оператора системы.Подсистема хранения данных – хранилище, в котором находятся все данные конфигурации, статистики, оперативные данные, полученные от контролируемых объектов и результаты обработки информации о событиях. Это реляционная база данных, доступ к которой реализуется с использованием СУБД, выбираемой Заказчиком на этапе формирования задания Подрядчику. Консоль управления системой мониторинга должна позволять в реальном масштабе времени просматривать результаты работы системы, а также управлять её параметрами. Консоль управления должна обеспечивать одновременную работу нескольких пользователей и иметь возможность установки одновременного соединения с несколькими серверами. Подсистема отображения и аналитики должна обеспечить следующие функции:1. Отображение собранных данных в единой консоли с возможностью многооконного доступа.2. Управление доступом к системе.3. Возможность доменной аутентификации пользователей.4. Оповещения об инцидентах, отклонениях от заданных характеристик качества.5. Возможность выполнения агрегированных проверок на основе статистических расчетов по истории значений параметров из базы данных: среднее, максимальное, минимальное значение, сумма значений.6. Классификация объектов мониторинга по категориям.7. Доступ к картам топологий (построенным в автоматическом режиме с возможностью ручной корректировки).8. Возможность использования на картах фонового рисунка в формате GIF, PNG, JPEG, объем файла рисунка – не менее 1 МБ.9. Отображение текущих проблем.10. Отображение истории инцидентов.11. Отображение действий различных пользователей.12. Логирование всех действий пользователей в системе.13. Отображение графиков измерений эксплуатационных параметров объектов мониторинга (в реальном времени, по запросу).14. Формирование детальной отчетности по выбранным объектам мониторинга с возможностью настройки детализации критериев.15.Создание пользовательских объектов мониторинга.16. Управление событиями.Требования к пользовательскому интерфейсу: Доступ к подсистемам должен осуществляться через WEB интерфейс, факультативно используя ПО клиента, устанавливаемое на АРМ пользователя.Должна быть возможность изменения дизайна пользовательского интерфейса, таблиц, дашбордов, графиков, возможность выбора пиктограмм для различных объектов мониторинга. В ПО платформы должен иметься интегрированный визуальный редактор отчетов и встроенный редактор настройки пользовательского интерфейса с поддержкой следующих возможностей:- позиционирование компонентов при построении экранных форм;- использование созданных объектов в качестве шаблона при построении других объектов;- формирование различных типов графиков и диаграмм с визуально настраиваемыми параметрами;- поддержка следующих базовых интерфейсных компонентов: надписи, текстовые поля, кнопки, текстовые области, выпадающие списки, тригерные кнопки, селекторы даты\времени, счётчики;- создание связей с данными должно производиться в режиме Drag and Drop.Требования к локализации:- Все надписи экранных форм, а также сообщения, выдаваемые пользователю, кроме системных, должны быть на русском языке. Должна предусматриваться возможность обмена данными с другими автоматизированными системами Заказчика при помощи Web-сервисов, общедоступного SDK для Java и .NET API.ПО платформы должно обеспечивать возможность отправки пользователям сообщений о событиях по правилам:- в случае возникновения отказов должен подаваться звуковой сигнал.- звуковые сигналы должны различаться в зависимости от степени критичности отказа.- отправка SMS или сообщений на почтовый адрес в случае произошедшего отказа или его устранения.- должны гибко задаваться критерии, при которых происходит рассылка.- сообщение должно отправляться пользователям индивидуально или группам пользователей.Система должна позволять настраивать частоту сбора данных в соответствии с требованиями Заказчика независимо от количества объектов в зоне мониторинга. ЗаключениеКонтроль качества обучения нуждается в объективных методах педагогических измерений. Педагогический мониторинг как средство управления и контроля учебно-воспитательным процессом обеспечивает преподавателя обратной связью об уровне усвоения учебного материала с помощью регулярного системного отслеживания степени или уровня обученности. В условиях инновационной деятельности педагогический мониторинг может стать механизмом в системе учебно-воспитательного процесса, который будет способствовать стимулированию, активизации, развитию студентов, будет связан с предоставлением им большей свободы и ответственности.Педагогический мониторинг должен быть системно организованным, прежде всего по этапам обучения и инструментарию.Для его организации в колледже необходимо наличие следующих условий: Реализация системы контроля в его основных видах: текущий, тематический, промежуточный, рубежный, итоговый. Организация контрольно-проверочных срезов (директорских контрольных), обеспечивающих систематичность и переодичность контроля. Наличие пакета измерителей нат всех этапах контроля.Исходя из этого, в колледже разработана система мониторинга, включающая: Входной контроль с целью определения уровня знаний на начало изучения дисциплины; Текущие контрольные работы и тематический контроль по завершении раздела дисциплины; Рубежный контроль по итогам 1 2 полусеместров; Промежуточный контроль в форме диференцированного зачета или экзамена;Объектами контроля являются умения и навыки по дисциплинам согласно рабочим программам.Список использованной литературы1. Гагарина Л.Г., Кокорева Е.В. «Технология разработки программного обеспечения». - М., 2018. – 310 с.2. Карпова Т.С. Базы данных: модели, разработка, реализация / Т.С. Карпова. - СПб.: Питер, 2019. - 304 с. - ISBN 5-272-00278-4.3. Орлов С. А. «Технологии рзработки программного обеспечения». - М. 2020. – 410 с.4. Сборник статей II Всероссийской научно-технической конференции молодых ученых, аспирантов и студентов. «Мониторинг успеваемости студентов с применением мобильных технологий» – Таганрог: Издательство Южного федерального университета, 2018. – 274 с.5. Сергей Зуев. “Официальный сайт на базе MODx — как это делается" Часть I: "Пособие редактору сайта". 2019. – 311 с.6. Эрик Дж. Брауде «Технология разработки программного обеспечения». СПб: «Издательский дом Питер», 2020. – 430 с.7. Якобсон А., Буч Г., Рамбо Дж. «Унифицированный процесс разработки программного обеспечения». - СПб: «Издательский дом Питер», 2019. – 277 с.