Тема: Разработка программной подсистемы обеспечения учебно-методическим материалом

• Вид работы:
  Дипломная (ВКР) по теме: Разработка программной подсистемы обеспечения учебно-методическим материалом
• Предмет:
  Другое
• Когда добавили:
  23.03.2012 12:41:48
• Тип файлов:
  MS WORD
• Проверка на вирусы:
  Проверено - Антивирус Касперского

Другие экслюзивные материалы по теме

• Полный текст:

  Данный дипломный проект посвящен разработке программной подсистемы обеспечения учебно-методическим материалом. Разрабатываемая система является одним из модулей программного комплекса системы дистанционного обучения «*****» (СДО «*****»).

  Система дистанционного обучения «*****» создается по объектно-ориентированной технологии с использованием унифицированных процессов с целью повышения эффективности и качества учебного процесса путем создания условий для применения последних педагогических инновационных методов обучения.

  Что подтверждает актуальность темы дипломного проекта.

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

  Во втором разделе сделан обзор современных систем дистанционного обучения с упором на программные средства поддержки ДО. Раздел 3 содержит техническое задание на выполнение разработки. Обоснование выбора методов и средств проектирования и разработки программной подсистемы приводятся в разделе 0.

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

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

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

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

  
  

  Оглавление

  Аннотация…………………………………….…………………………………...3

  Оглавление. 4

  Перечень сокращений. 7

  1. Введение, обоснование актуальности задачи. 8

  2. Обзор программных решений систем дистанционного обучения гуманитарным дисциплинам. 13

  2.1 Введение. 13

  2.2 Обзор некоммерческих программных комплексов ДО.. 14

  2.3 Краткий обзор коммерческих программных комплексов ДО.. 22

  3. Техническое задание. 26

  3.1 Общие сведения. 26

  3.2 Назначение и цели создания системы.. 27

  3.2.1 Цель разработки. 27

  3.2.2 Основные функции. 27

  3.3 Особенности системы.. 27

  4 Постановка задачи. 29

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

  4.2 Приоритеты разработки. 32

  4.3 Характеристики объекта автоматизации. 33

  4.3.1     Краткие сведения об объекте автоматизации. 33

  4.3.2     Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.. 33

  4.4 Требования к системе. 34

  4.4.1 Требования к структуре и функционированию системы.. 34

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

  4.4.3 Требования к режимам функционирования системы.. 35

  4.4.4 Требование к численности и квалификации персонала системы и режиму его работы.. 36

  4.4.5 Показатели назначения. 36

  4.4.6 Требования к надежности и безопасности. 36

  4.4.7 Требования к эргономике и технической эстетике. 36

  5. Методы и средства решения задачи. 37

  5.1. Выбор СУБД и средства проектирования базы данных. 37

  5.2. Выбор средств разработки для реализации программного модуля ПП обеспечения материалом. 42

  5.3 Выбор средств разработки для реализации модуля графического интерфейса  46

  6 Проект системы.. 49

  6.1 Структура системы.. 49

  6.2 Описание системы.. 50

  6.3 Входная и выходная информация. 50

  6.4 Потоки данных. 52

  7.1 Разработка архитектуры системы с использованием технологии RUP. 53

  7.1.1 Выбор моделей формализации процесса разработки. 53

  7.1.2 Первый этап – Начало (Inception) 54

  7.1.3 Второй этап – Проектирование (Elaboration) 58

  7.1.4 Третий этап – Построение (Construction) 61

  7.1.5 Четвертый этап –Внедрение (Transition) 67

  7.2 Проект базы данных. 68

  7.3 Описание графического интерфейса пользователя. 69

  7.3.1 Интерфейс просмотра авторизованных пользователей СДО «*****» с возможностью предоставления полного доступа к УММ.. 70

  7.3.2 Интерфейс предоставления выборочного доступа пользователей СДО к курсам УММ.. 71

  7.3.3 Интерфейс создания нового текстового курса. 72

  7.3.4 Интерфейс редактирования и удаления выбранного текстового курса  73

  7.3.5 Интерфейс просмотра выбранного курса. 74

  7.4 Алгоритмы работы модуля обеспечения УММ. 75

  7.5 Тестирование подсистемы.. 76

  7.5.1 План тестирования. 76

  7.5.2 Содержание тестовых случаев. 83

  7.5.3. Таблица покрытий. 89

  7.5.4 Таблица тестов. 91

  7.5.5 Отчет. 91

  7.5.6 Проверочный лист (Checklist) 92

  7.5.7 Код сценариев автоматизированного тестирования. 93

  8. Организационно-экономическая часть. 94

  8.1. Организация и планирование работ по теме. 94

  8.2 Состав, принимающий участие в работе. 96

  8.3 Расчет договорной цены.. 97

  8.3.1. Материалы, покупные изделия. 97

  8.3.2. Основная заработная плата научного персонала. 98

  8.3.3 Дополнительная заработная плата научного персонала. 99

  8.3.4 Отчисления на социальные нужды.. 99

  8.3.5 Накладные расходы.. 99

  8.3.6 Прочие расходы.. 100

  8.3.7 Стоимость. 100

  8.3.8 Прибыль. 100

  8.3.9 Оптовая цена предприятия. 100

  8.3.10 Договорная цена. 100

  8.4 Экономическая целесообразность темы.. 101

  8.5 Заключение договора на создание научно-технической продукции. 101

  8.6 Бизнес-план (основные разделы) 103

  8.6.1 Описание продукта или вида услуг. 103

  8.6.2 Оценка рынка сбыта продукта. 103

  8.6.3 Конкуренция. 103

  8.6.4 Реклама. 103

  8.6.5 План производства. 103

  8.6.6 Организационный план. 103

  8.6.7 Юридический план. 103

  8.6.8 Финансовый план. 104

  8.7 Выводы.. 104

  8.8 Список литературы.. 104

  9. Охрана труда и экология. 105

  9.1 Введение. 105

  9.2 Организация рабочего места. 106

  9.3 Расчет оптимального освещения. 110

  9.4 Расчет оптимальной вентиляции. 113

  9.4.1 Расчёты выделения вредных веществ и влаги. 113

  9.4.2 Расчёты выделений тепла. 113

  9.4.3 Определение оптимального режима воздухообмена. 115

  9.4.4 Расчёт оптимальной вентиляции. 116

  9.5 Электробезопасность и расчёт заземляющего устройства. 119

  9.5.1 Защитное отключение в функции тока (ЗОТ) 120

  9.6 Выводы.. 121

  9.7 Список литературы.. 122

  Заключение. 123

  Список литературы.. 123

  Приложения. 127

  Матрица доступа пользователей СДО.. 127

  Код сценариев автоматизированного тестирования. 128

  Листинг исходных кодов подсистемы выдачи УММ.. 133

  Публикация. 154

  DFD диаграмма программной подсистемы.. 158

  Таблица названий тестов ПП.. 165

  
  

  Перечень сокращений

  1. ДО – дистанционное обучение

  2. СДО – система дистанционного обучения

  3. ОУДО – образовательные учреждения дистанционного обучения

  4. ПО – программное обеспечение

  5. ПП – программная подсистема

  6. СНИТ – средства новых информационных технологий

  7. УММ – учебно-методический материал

  1. Введение, обоснование актуальности задачи

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

  По мнению специалистов “Института информатизации образования” ЮНЕСКО, к наиболее важным направлениям формирования перспективной системы образования можно отнести:

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

  ·   обеспечение опережающего характера всей системы образования в целом;

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

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

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

  ·   люди, проживающие в малоосвоенных регионах страны, удаленных от вузовских центров;

  ·   обширный контингент потребителей образовательных услуг, готовящихся к поступлению в вузы;

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

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

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

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

  ·   лица, желающие получить образование в зарубежных образовательных учреждениях;

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

  Приведенные факты говорят об актуальности осуществления поиска, апробации и внедрения некоторой альтернативной формы получения образования, адекватной развивающемуся информационному российскому обществу. Она должна в полной мере обеспечивать ** на получение образования, обозначенное в Конституции (Ст. 42) и в Законе об «Образовании» (Раздел 1, Ст. 5) и кроме того, быть доступной для всех выше обозначенных категорий лиц, желающих получить современное и качественное образование.

  В качестве такой формы получения образования в настоящий момент активно позиционируется дистанционное обучение (ДО). Такой, сравнительно молодой тип получения знаний в настоящий момент актуален, так как позволяет:

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

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

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

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

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

  С начала 90-х годов российское образовательное и научное сообщество России стало обращает пристальное внимание на ДО, особенно после принятия в 1995 году Концепции о создании и развитии единой системы ДО в России. Количество образовательных учреждений в той или иной степени использующие технологию ДО стремительно растет. Для координации усилий в области ДО созданы соответствующие структуры в Министерстве общего и профессионального образования РФ, Евразийская Ассоциация ДО, Ассоциация Международного образования, Центр информационно аналитического обеспечения ДО, Межвузовский центр ДО РФ на базе Московского государственного университета экономики, статистики и информатики (МЭСИ) и др.

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

  Факт, что успешное развитие системы ДО может быть только при дидактически обоснованном использовании СНИТ (компьютеров, телекоммуникаций, систем мультимедиа и др.), являющихся материальной основой СДО – вполне очевиден. Парк этих средств количественно и качественно постоянно растет и совершенствуется, предоставляя богатый набор потенциальных возможностей для обучения.

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

  1. «Гибкость». Пользователи СДО работают с системой в удобное для себя время, в удобном темпе и в удобном для себя месте, оборудованном компьютером и оснащенным доступом во Всемирную Сеть. Каждый может учиться столько, сколько ему лично необходимо для освоения курса дисциплины и получения необходимых знаний по выбранным дисциплинам.

  2. «Эффективность» В программных комплексах подобного рода используются новые формы представления и организации информа­ции, обеспечивающие максимальную степень ее восприятия обучающимся. Среди них можно выделить

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

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

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

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

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

  
  

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

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

  7. «Рентабельность». Под этой особенностью подразумевается экономическая целесообразность разработки, введения в эксплуатацию и поддержки рассматриваемого типа ПО.

  В заключение необходимо также отметить, что разработка подобного рода программных комплексов актуальна не только в рамках национальных систем образования, но и в отдельных коммерческих компаниях с преимущественной ориентацией на подготовку в области бизнеса, которая составляет четвертую часть всех программ высшего образования. Частные корпоративные образовательные сети созданы такими компаниями как IBM, General Motors, Ford и др. Для России такая тенденция также актуальна. В настоящий момент ПО в сфере корпоративного ДО используется во многих банковских системах, РАО «ГАЗПРОМ», Центробанке, Санэпидемслужбе и др. Причем стоит заметить, что многие из этих образовательных систем намного опережают системы, созданные в университетах, как по сложности, так и по количеству. Сегодня многие компании пересматривают статус образовательных подразделений в своих структурах. Руководство предприятий все больше рассматривает инвестиции в обучение наравне с инвестициями в научно-исследовательские разработки.

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

  2.1 Введение

  Историко-педагогический анализ проблем становления и развития ДО показал, что в настоящее время в мире накоплен опыт реализации систем дистанционного обучения. В целом мировая тенденция перехода к нетрадиционным формам образования прослеживается в росте числа Вузов, ведущих подготовку специалистов с использованием новых информационных технологий. В США в системе ДО обучается около 1 миллиона человек. Так, Национальный Технологический Университет, который представляет консорциум из 40 инженерных школ, еще в начале 90-х годов обеспечил подготовку более 1100 студентов с помощью дистанционных методов на степень магистра. В более чем половине университетов используется технологии ДО для обучения взрослых. Для ДО широко используется телевидение. В рамках системы публичного телевещания PBS-TV обучается более миллиона студентов.

  С начала 90-х годов российское образовательное и научное сообщество России стало обращает пристальное внимание на ДО, особенно после принятия в 1995 году Концепции о создании и развитии единой системы ДО в России. Количество образовательных учреждений в той или иной степени использующие технологию ДО стремительно растет. Для координации усилий в области ДО созданы соответствующие структуры в Министерстве общего и профессионального образования РФ, Евразийская Ассоциация ДО, Ассоциация Международного образования, Центр информационно аналитического обеспечения ДО, Межвузовский центр ДО РФ на базе Московского государственного университета экономики, статистики и информатики (МЭСИ) и др.

  К сожалению, процесс развития программных комплексов ДО в России отчасти сдерживается традиционными для России причинами - отсутствием хорошего материально-технического обеспечения, высокой стоимости специализированной компьютерной техники, ограниченными возможностями связи и недостаточной квалификацией в области информационных технологий обслуживающего персонала таких комплексов. Тем не менее, заметна положительная динамика в данной области. Возрастающий уровень научного обеспечения процессов ДО в России подтверждается следующими фактами. Начиная с 1991 года открываются бюджетные и хоздоговорные НИР по проблемам ДО. Так, в 1993 Госкомвуз РФ открыл несколько бюджетных НИР по темам: международный электронный университет, телекоммуникации в образовании, информационные технологии в ДО, ДО с использованием средств массовой информации. Под патронажем Международной Ассоциации Дистанционного Образования было проведено ряд договорных НИОКР.

  Большая работа по педагогическому обеспечению СДО ведется в Российской академии образования (РАО). Так, лаборатория ДО Института общего и среднего образования Российской академии образования, под руководством Е.С.Полат разрабатываются теоретические основы и практические курсы для ДО, проблемы эвристического ДО исследуются А.В. Хуторским, ДО внедряется в учебный процесс Университета РАО.

  2.2 Обзор некоммерческих программных комплексов ДО

  ОРОКС

  Обзор отечественных некоммерческих программных комплексов стоит начать с системы ОРОКС (старое название WEB-Tester), разрабатываемой Московским Областным Центром Новых Информационных Технологий (МОЦНИТ) #"_Toc159573746">2.3 Краткий обзор коммерческих программных комплексов ДО

   

  "МИКРОТЕСТ"
  
           Одной из IT-компаний, наиболее активно развивающей направление дистанционного обучения как составную часть интеграционных проектов и предлагающей услуги в этой области своим заказчикам, является "Микротест". Технология, разработанная специалистами этого системного интегратора, была опробована в рамках реализации проектов в МПС.
           По разработанному в Учебном центре курсу было проведено дистанционное обучение свыше 400 специалистов всех 17 железных дорог России. Программа курсов была нацелена на освоение навыков работы с системами видеоконференцсвязи, сетевым оборудованием и программным обеспечением по управлению сетями. Систему дистанционного обучения собственной разработки "Микротест" использует и для подготовки своих сотрудников. Такая система развернута на интранет-сайте компании.

  
  Отличительные особенности данной системы:

  
  - сбалансированность методических и технологических аспектов обучения в предлагаемом комплексе
  
  

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

  
           В данный момент в комплексе "Микротест" завершается второй из проектов по дистанционному обучению в МПС, - по подготовке администраторов сетей. Всего предполагается обучить 350 человек. В планах - совершенствование технологий и методик дистанционного обучения, предложение заказчикам новых компонентов, например, полностью интегрированного с технологиями обучения "конструктора" для быстрого создания учебных курсов.
  
                                                          "СТ Курс"
  
           Летом прошлого года свой программный продукт "СТ Курс", предназначенный для организации дистанционного обучения, представила российская компания Cognitive Technologies.
  
           Содержание курсов и программу обучения заказчик этого продукта (равно как и многих других СДО) будет определять и размещать в системе самостоятельно. В качестве возможных направлений применения "СТ Курса" Cognitive рассматривает общее бизнес-образование, специализированное обучение, мониторинг уровня знаний персонала, сертификацию клиентов и т. п. К особенностям технической стороны "СТ Курса" можно отнести высокую скорость обработки запросов пользователей и небольшой объем передаваемых данных, что позволяет комфортно работать обладателям низкоскоростных линий связи.
  
           В режиме самостоятельного обучения слушатели и преподаватели курса работают с СДО "СТ Курс" в любое удобное время; в лекционном режиме - участники курса в определенные дни и часы недели находятся в виртуальном классе и взаимодействуют друг с другом в интерактивном режиме посредством чатов.
  
           В качестве дополнительных возможностей для учащегося разработчики отмечают словарь, список литературы, графические иллюстрации, аудиозаписи, видеоролики, а также средства самоконтроля. Кроме того, посетитель сайта www.ctkurs.ru имеет возможность пройти ознакомительное обучение, зарегистрировавшись в качестве гостя.
  
  

  “ИнтраЗнание”

   

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

  
  
  

  Особенности системы:

  
  

  - строится на основе веб-технологий и использует интерактивные Shockwave-ролики,

  
  

  - визуальные и звуковые "подсказки" обеспечивают наглядность и эффективность обучения.

  
  

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

           Первая версия была предназначена для дистанционного обучения офисным приложениям Word, Excel, Outlook, Explorer и в качестве корпоративного инструмента была установлена в компании "Татнефть" и в Министерстве Финансов РФ. В настоящее время число пользователей "ИнтраЗнания" составляет примерно 1100 человек. Исходя из потребностей заказчика, система может продаваться как вместе с контентом, так и без него.

  
  

  
  
                                                 " Батисфера "
  
           Большинство известных СДО предполагает для использования развитую инфраструктуру связи для работы через интернет. Но далеко не каждое отечественное учебное заведение пока имеет возможность использовать интернет-технологии в процессе обучения. Поэтому, с учетом российских условий, имеет смысл рассмотреть вариант реализации учебных курсов на компьютерах, связанных в локальные вычислительные сети организации и распространение учебных материалов на магнитных носителях и CD.
  
           Одним из сторонников такой формы обучения является компания "Информпроект" - разработчик "Программы для проектирования и выполнения мультимедийных обучающих работ "Батисфера", ориентированной на учебные заведения разного уровня и профиля.
  
           По утверждению разработчиков, "Батисфера" отличается от известных систем дистанционного обучения необходимой степенью адаптации к российской системе образования - требования к техническому оснащению максимально приближены к российским реалиям. Кроме того, данную систему отличает возможность сборки в единой обучающей среде готовых учебных материалов, выполненных в разных программных средах, а также вариативность ее использования. Так, один из вариантов предполагает возможность передачи учебных материалов слушателям по электронной почте или на дискетах. А второй, возможный при наличии в учебном заведении доступа в интернет, состоит в использовании "Батисферы" в качестве системы дистанционного обучения.
  
           По мнению разработчиков проекта, в большинстве обучающих программных продуктов, представленных на российском рынке, программная оболочка довольно жестко привязана к контенту. "Батисферу" же можно сравнить с кубиками, из которых преподаватель, не имеющий навыков программирования, может построить свой курс, выбрав по своему желанию количество лекций, тематику, и т.д. Преподавателю достаточно переложить свою методику обучения на компьютер, используя алгоритм формирования лекций, лабораторных работ и тестов, при этом подойдут любые программные средства, которыми он привык пользоваться.
  
  

  
  

  
           "Батисфера" состоит из двух блоков. Первый из них «Tutor» - это средство разработки курса, который преподаватель устанавливает на своем компьютере. Tutor позволяет создавать учебный материал любых типов и форм: лекции, домашние задания, лабораторные и контрольные работы, тесты, интерактивные зачеты, экзамены, электронные учебники. Причем преподаватель может при желании регламентировать время выполнения проверочной работы и устанавливать порядок допуска к следующему заданию. Второй блок «Reader» (прокатчик курса) - предназначен для учащихся. Он позволяет прослушать лекцию, выполнить лабораторную и контрольную работу, домашнее задание, сдать зачёт и экзамен в интерактивном режиме, занести результаты тестирования в текстовый файл, отправить его по электронной почте или распечатать. Блок Reader устанавливается на ПК обучаемых.

  
           В будующем планируется выпуск новой версии данной системы - "Батисфера 3.0". От предыдущей она будет отличаться расширенными функциональными возможностями и соответствием рекомендациям Министерства образования РФ.

  3. Техническое задание

  3.1 Общие сведения

  Полное наименование подсистемы: обеспечение учебно-методическим материалом СДО «*****».

  Заказчиком данной программной подсистемы (далее ПП) ***** в лице. Данная работа проводится в рамках разработки комплекса программных модулей и дальнейшей их интеграции в единую систему дистанционного обучения (далее СДО «*****»).

  Разработчик: Начало работ: 3 октября 2005 года.

  Планируемый срок окончания работ: декабрь 2006 года.

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

  3.2 Назначение и цели создания системы

  3.2.1 Цель разработки

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

  В качестве объекта рассматриваем организацию процесса обучения на отделении ** ОЛ *****. Ранее в процессе обучения для обмена учебными и методическими материалами использовалась обыкновенная почта, что требовало больших временных затрат и было весьма ненадежно. В данный момент решено, что часть процесса обучения будет происходить посредством Интернет, то есть будет разработана система обучения, использующая Интернет как платформу для взаимодействия ученика (Актора) и учителя (Тьютора).

  3.2.2 Основные функции

  Основными функциями подсистемы обеспечения учебно-методическим материалом СДО «*****» являются:

  ·   создание / редактирование / удаление курсов из БД тем,

  ·   создание / редактирование / удаление вопросов к темам,

  ·   создание / редактирование / удаление тестов к темам,

  ·   определение уровня доступа пользователей к методическому материалу.

  При использовании данной подсистемы к комплексе СДО «*****» ожидается уменьшение времени ожидания при взаимодействии Актора и Тьютора (увеличение динамичности обучения) при сохранении высокой надежности и защищенности как самой системы, так и ее данных.

  3.3 Особенности системы

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

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

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

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

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

  1. Уровень представления,

  2. Уровень воспроизведения,

  3. Уровень умений и навыков,

  4. Уровень развития творческих навыков.

  В качестве дополнительных особенностей стоит отметить:

  - Прохождение курса возможно только в диалоге с учителем (тьютором)

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

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

  4 Постановка задачи

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

  
  

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

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

  Среди основных структурных компонент и их функции в ПП стоит выделить:

  ·             БД приложения

  o выполнение запросов на идентификацию / авторизацию пользователей

  o выполнение запросов на создание / редактирование / удаление учебных курсов / тестов / вопросов

  o выполнение запросов на создание / редактирование / удаление пользователей

  o выполнение запросов на выборку статистическиз данных для отчетов

  o выполнение запросов на создание / редактирование / удаление записей о правах доступа пользователей

  ·            модуль управления УММ системы дистанционного обучения  «*****»

  o создание / редактирование / удаление учебных курсов / тестов / вопросов

  ·            модуль предоставления доступа к обучающему материалу

  o создание / редактирование / удаление записей о правах доступа пользователей

  
  

  Кроме того, в рамках разработки всего программного комплекса СДО «*****» также реализованы:

  ·            модуль управления учетными записями пользователей

  o создание / редактирование / удаление пользователей

  o регистрация / авторизация пользователей

  ·            модуль генерации отчетов

  o выборка статистических данных для отчетов

  ·            модуль автоматической нотификации пользователей

  o отправка нотификации пользователям системы в случае определенных изменений (авторизация/удаление записи/ окончание курса и т.д.)

  В первую очередь стоит остановиться на описании модуля управления УММ – как важнейшей компоненты разрабатываемого программного комплекса. Данный модуль был создан с целью выполнения главного требования заказчика, (ОЛ *****) а точнее, перевод учебного материала в цифровой формат. Данным действием повышается степень надежности хранения информации,  материал становится более доступным в рамках образовательного процесса.

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

  Базовым текстовым редактором для создания основы методического курса – электронной лекции, был выбран MS Word в силу своей распространенности и простоты использования. Создание такого текста можно считать основой будующего учебного курса. Первый этап разработки УММ состоит в создании текстовой части, форматировании документа и вставки графических файлов. Данный процесс является распределенным, то есть выполняется тьюторами на локальных машинах с тем, чтобы не создавать дополнительную нагрузку на сервер и всегда иметь возможность доступа к УММ, даже при отсутствии соединения с сервером СДО. В качестве формата учебных данных, предоставляемых СДО «*****» был выбран язык гипертекстовой разметки текста, HTML. Это выбор обусловился универсальностью данного веб-языка, полной совместимостью с большинством широкоиспользуемых аппаратных платформ, а также должным уровнем безопасности.

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

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

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

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

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

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

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

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

  4.2 Приоритеты разработки

  Основным требованием к разработанному ПО является обеспечение выборочного доступа к УММ. Кроме того, от продукта ожидается поддержание  на долном уровне безопасности данных системы, а также общее повышение эффективности прохождения учебного процесса на отделении ** при использовании СДО «*****». Эффективность использования данного программного обеспечения определяется следующими факторами:

  ·   временем реакции системы на запрос пользователя,

  ·   возможность построить эффективный запрос на изменение,

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

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

  
  
  
  
  

  4.3 Характеристики объекта автоматизации

  4.3.1 Краткие сведения об объекте автоматизации

  
  

  Разрабатываемая подсистема СДО «*****» является программным комплексом, построенным на базе интернет-сайта отделения Права. Для реализации данного проекта использовался следующий инструментарий:

  Язык программирования

  Система программирования для реализации данного проекта должна отвечать следующим условиям:

  - работала на разнородных платформах, таких как Unix, Windows, Macintosh, OS/2,

  - минимальные требования к ПО на стороне пользователя подсистемой

  В качестве средства реализации проекта использовался кросс-платформенный язык программирования PHP, версии 4.

  
  

  База данных

  В качестве СУБД использовалась MySQL. Основными плюсами данного инструмента является простота использования, нетребовательность к ресурсам сервера, бесплатное рапространение и хорошо известная быстрота, надежность и безопасность работы в связке с PHP.

   

  Web-сервер

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

  
  

  4.3.2 Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды

  
  

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

  4.4 Требования к системе

           4.4.1 Требования к структуре и функционированию системы

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

  
  

  Название подсистемы.	Назначение подсистемы.	Количество уровней иерархии.
  Основные подсистемы.
  БД пользователей системы	- регистрация новых пользователей - авторизация / редактирование / удаление пользователей из БД системы.	2-3
  Обеспечение учебного-методическим материалом	-создание / редактирование / удаление курсов из БД тем. - создание / редактирование / удаление вопросов к темам. - создание / редактирование / удаление тестов к темам. - определение уровня доступа пользователей к методическому материалу	3
  Дополнительные подсистемы (планируемые)
  Обратная связь.	- отправка подтверждения о регистрации / отказа в регистрации / рассылки новостей / комментария к работе	1
  Форум	- создание площадки для общения пользователей СДО.	1
  Система он-лайн платежей.	- предоставление пользователям системы оплатить услуги обучения через Интернет.	2

  
  

  Таблица 4.4.1

  
  

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

  
  

  Разрабатываемая подсистема взаимодействует с другими модулями СДО и другими программными приложениями посредством стандартных протоколов для обмена информацией в сети Интернет.

  Кроме того, ПП совместима с ОС Windows / Linux, поддерживается работа с процессором Pentium (не ниже 200 Mhz) и необходимым минимумом оперативной памяти (64 Mb). Для корректной работы с СДО рекомендуется использовать Internet Explorer 5.5 и выше (с поддержкой JavaScript) . Также возможна работа с Mozilla Firefox и Opera.

  
  

  4.4.3 Требования к режимам функционирования системы

  
  

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

  
  
  
  
  

  4.4.4 Требование к численности и квалификации персонала системы и режиму его работы

  
  

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

  
  
  

  4.4.5 Показатели назначения

  
  

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

  
  

  4.4.6 Требования к надежности и безопасности

  
  

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

  
  

  4.4.7 Требования к эргономике и технической эстетике

  
  

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

  
  

  5. Методы и средства решения задачи

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

  - база данных;

  - программного модуля ПП;

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

  5.1. Выбор СУБД и средства проектирования базы данных

  В соответствии с техническим заданием БД должна быть реализована на СУБД MySQL.

  MySQL была разработана Михаэлем Видениусом. Данная СУБД является относительно небольшой и быстрой реляционной СУБД основанной на традициях Hughes Technologies Mini SQL (mSQL).

  MySQL – компактный многопоточный сервер баз данных. MySQL характеризуется большой скоростью, устойчивостью и легкостью в использовании. Также MySQL является идеальным решением для малых и средних приложений. Исходники сервера компилируются на множестве платформ. Наиболее полно возможности сервера проявляются на Unix-серверах, где есть поддержка многопоточности, что дает значительный прирост производительности, кроме того, сервер является бесплатным для некоммерческого использования.

  MySQL поддерживает язык запросов SQL в стандарте ANSI 92, и кроме этого имеет множество расширений к этому стандарту, которых нет ни в одной другой СУБД.

  
  

  Краткий перечень возможностей MySQL:

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

  ·   Количество строк в таблицах может достигать 50 млн.

  ·   Быстрое выполнение команд. Возможно MySQL самый быстрый сервер из существующих.

  ·   Простая и эффективная система безопасности.

  ·   MySQL является очень быстрый сервером, но для достижения этого разработчикам пришлось пожертвовать некоторыми требованиями к реляционным СУБД. Данные недостатки описаны ниже.

  
  

  Также стоит остановиться на дополнительных преимуществах данной СУБД:

  ·   Многопоточность. Поддержка нескольких одновременных запросов.

  ·   Оптимизация связей с присоединением многих данных за один проход.

  ·   Записи фиксированной и переменной длины.

  ·   ODBC драйвер в комплекте с исходником

  ·   Гибкая система привилегий и паролей.

  ·   До 16 ключей в таблице. Каждый ключ может иметь до 15 полей.

  ·   Поддержка ключевых полей и специальных полей в операторе CREATE.

  ·   Поддержка чисел длинной от 1 до 4 байт (ints, float, double, fixed), строк переменной длины и меток времени.

  ·   Интерфейс с языками C и perl.

  ·   Основанная на потоках, быстрая система памяти.

  ·   Утилита проверки и ремонта таблицы (isamchk).

  ·   Все данные хранятся в формате ISO8859_1.

  ·   Все операции работы со строками не обращают внимания на регистр символов в обрабатываемых строках.

  ·   Псевдонимы применимы как к таблицам, так и к отдельным колонкам в таблице.

  ·   Все поля имеют значение по умолчанию. INSERT можно использовать на любом подмножестве полей.

  ·   Легкость управления таблицей, включая добавление и удаление ключей и полей.

  
  

  Для объективной оценки данной СУБД остановимся также на ее недостатках. В MySQL отсутствуют:

  ·   Поддержка вложенных запросов, типа SELECT * FROM table1 WHERE id IN (SELECT id FROM table2). Утверждается, что такая возможность будет в версии 3.23.

  ·   Не реализована поддержка транзакций. Взамен предлагается использовать LOCK/UNLOCK TABLE.

  ·   Нет поддержки внешних (foreign) ключей.

  ·   Нет поддержки триггеров и хранимых процедур.

  ·   Нет поддержки представлений (VIEW). В версии 3.23 планируется возможность создавать представления.

  
  

  Как уже говорилось ранее, MySQL соответствует спецификации ANSI 92 SQL. Наиболее простой способ работы с MySQL сводится к использованию программы MySQL. Это клиентская часть СУБД, кроме того команды можно выполнять непосредственно из командной строки системы unix или из интерактивного режима MySQL.

  СУБД MySQL имеет библиотеку C API. Ее можно использовать для запросов к базе данных, вставки данных, создания таблиц и т.п. C API поддерживает все функции MySQL. Язык perl поддерживается сразу двумя способами:

  - Портирован интерфейс с perl из mini-SQL

  - Есть модуль perl DBD

  Также доступен 32-битный ODBC драйвер для MySQL. Он позволяет запрашивать и получать данные из других источников с поддержкой ODBC.

  
  

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

  MySQL API использует структуры данных MYSQL (определены в mysql.h) чтобы установить связь с СУБД. Вы можете устанавливать много соединений из одной программы-клиента, однако, каждое соединений должно быть связано с собственной отдельной структурой MYSQL.

  После успешного запроса, если данные должны быть возвращены пользователю, набор результатов должен быть передан через функции mysql_use_result или через функцию mysql_store_result. Обе эти функции сохраняют набор результатов в структуре MYSQL_RES. Разница в том, что mysql_store_result передает весь набор результатов в память клиента, а mysql_use_result инструктирует клиента, чтобы он мог получить строку динамически с сервера с каждым обращением к mysql_fetch_row. Имейте в виду, что mysql_use_result занимает ресурсы сервера, и не должен использоваться для интерактивных прикладных программ, где действия пользователя часто непредсказуемы и могут привести к большим задержкам. Обратите внимание также, что Вы можете держать только одно соединение, которое использует mysql_user_result, открытым, и это должно быть последнее созданное соединение. По умолчанию процесс mysqld закроет соединение после тридцати секунд неактивности.

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

  
  

  Функции MySQL для работы с языком PHP, выбранным в качестве языка реализации ПП обеспечения учебно-методическим материалом СДО «*****»:

  
  

  mysql_affected_rows

  mysql_close

  mysql_connect

  mysql_create_db

  mysql_data_seek

  mysql_drop_db

  mysql_eof

  mysql_error

  mysql_fetch_field

  mysql_fetch_lengths

  mysql_fetch_row

  mysql_field_seek

  mysql_free_result

  mysql_get_client_info

  mysql_get_host_info

  mysql_get_proto_info

  mysql_get_server_info

  mysql_insert_id

  mysql_list_dbs

  mysql_list_fields

  mysql_list_processes

  mysql_list_tables

  mysql_num_fields

  mysql_num_rows

  mysql_query

  mysql_real_query

  mysql_reload

  mysql_select_db

  mysql_shutdown

  mysql_stat

  mysql_store_result

  mysql_use_result

  
  

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

  
  

  Стандартизация моделирования и проектирования
  
  

  ERwin облегчает проектирование баз данных. Для этого достаточно создать графическую E-R модель (объект-отношение), удовлетворяющую всем требованиям к данным и ввести бизнес-правила для создания логической модели, которая отображает все элементы, атрибуты, отношения и группировки.

  Средства моделирования программы помогают лучше спроектировать базу данных. Предусмотрены возможности манипулирования атрибутами путем их буксировки, внесения изменений и нормализации "на лету". Средства редактирования непосредственно на диаграммах позволяют вносить в модель изменения, не открывая специальных диалоговых окон. Навигация по отношениям обеспечивает быстрое перемещение в больших моделях для перехода к родительским или дочерним объектам. Формируемые системой отчеты позволяют проверить корректность спроектированной базы данных.
           Кроме того, данная программа автоматизирует процесс проектирования. Например, ERwin предусматривает возможность создания каталога наиболее часто используемых атрибутов, что обеспечивает согласованность имен и описаний по всему проекту. Представления БД поддерживаются как интегрированные компоненты модели, что позволяет автоматически отображать в их описаниях изменения, внесенные в базовые таблицы. Автоматический перенос ключей обеспечивает ссылочную целостность базы данных.
           Созданные с помощью ERwin модели данных можно редактировать, просматривать и распечатывать различными способами. В состав ERwin входит RPTwin - простая в использовании, оснащенная графическим интерфейсом утилита для формирования отчетов и встроенное средство для просмотра с настраиваемыми режимами , которые обеспечивают полный контроль над отображением содержимого отчетов. Кроме этого, уникальный интерфейс, построенный на использовании шаблонов, позволяет реализовать единые стандарты проектирования и отображать настройки для всех моделей.

   

  Основные достоинства данного программного пакета:
  
  

  - оптимизация модели в соответствии с физическими характеристиками целевой базы данных. В отличие от других инструментальных средств ERwin автоматически поддерживает согласованность логической и физической схем и осуществляет преобразование логических конструкций, таких как отношения многие-ко-многим, в их реализацию на физическом уровне.
  - установка динамической связи между моделью и базой данных, что позволяет реализовать как прямой, так и обратный инжиниринг. Используя эту связь, ERwin автоматически генерирует таблицы, представления, индексы, правила поддержания целостности ссылок (первичных и внешних ключей), устанавливает значения по умолчанию и ограничения для доменов/столбцов.
  - включенные в пакет средства расчета объема позволяют точно оценить первоначальный размер и характер роста базы данных или хранилища, облегчая эффективное распределение ресурсов системы и планирование мощности.
  - БД может быть спроектирована и создана без написания отдельных SQL-предложений типа CREATE TABLE или INDEX. Поскольку физическая схема формируется на основе описательной логической модели, ваше приложение будет сразу же полностью документировано.

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

  
  

  5.2. Выбор средств разработки для реализации программного модуля ПП обеспечения материалом

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

  PHP – это скрипт-язык (scripting language), встраиваемый в HTML, который интерпретируется и выполняется на сервере.

  Основное отличие от CGI-скриптов, написанных на других языках, типа Perl или C – это то, что в CGI-программах вы сами пишете выводимый HTML-код, а, используя PHP – вы встраиваете свою программу в готовую HTML-страницу, используя открывающий и закрывающий теги (пример:  <?php ?>).

  Отличие PHP от JavaScript, состоит в том, что PHP-скрипт выполняется на сервере, а клиенту передается результат работы, тогда как в JavaScript-код полностью передается на клиентскую машину и только там выполняется.

  
  

  Основные возможности PHP, используемые в разрабатываемой ПП:

  
  

  - обработка данных из форм

  - динамическая генерация страницы

  - работа с сессиями

  - поддержка необходимой БД

  
  

  Adabas D	InterBase	Solid
  dBase	mSQL	Sybase
  Empress	MySQL	Velocis
  FilePro	Oracle	Unix dbm
  Informix	PostgreSQL

  
  

  - работа с протоколами IMAP, SNMP, NNTP, POP3, HTTP,

  - работа с сокетами (sockets)

  - возможность коммуникации по другим протоколам.

  
  

   Практический характер РНР обусловлен пятью важными характеристиками:
  
  - традиционностью;
  - простотой;
  - эффективностью;
  - безопасностью;
  - гибкостью.
  
  Традиционность
  
  Синтаксис языка РНР может показаться знакомыми разработчикам, работавшими с другими языками высокого уровня. Эта деталь является отличительной особенность благодаря тому, что большое количество конструкции языка позаимствованы из Си, Perl.
  
  Код РНР очень похож на тот, который встречается в типичных программах на С или Pascal. Это заметно снижает начальные усилия при изучении РНР. PHP — язык, сочетающий достоинства Perl и Си и специально нацеленный на работу в Интернете, язык с универсальным и ясным синтаксисом.
  
  Стоит заметить, что хотя PHP является довольно молодым языком, он обрел немалую популярность среди web-программистов. На данный момент язык является одним из популярнейших языков для создания web-приложений (скриптов).
  
  Простота
  
  Сценарий РНР не использует динамическую подгрузку библиотек, указание специальных параметров компиляции или что-нибудь в этом роде. Механизм РНР начинает выполнять код после первой экранирующей последовательности (). Если код имеет правильный синтаксис, он исполняется в точности так, как указал программист.
  
  PHP — язык, который может быть встроен непосредственно в html -код страниц, которые, в свою очередь будут корректно обрабатываться PHP -интерпретатором. Можно использовать PHP для написания CGI-сценариев и избавиться от множества неудобных операторов вывода текста. Кроме того, имеет смысл привлекать PHP для формирования HTML-документов, тем самым избавившись от множества вызовов внешних сценариев.
  
  Эффективность
  
  Эффективность является исключительно важным фактором при программировании для многопользовательских сред, к числу которых относится и web .
  
  Очень важное преимущество PHP заключается в его «движке». «Движок» PHP является транслирующим интерпретатором (в отличие от компиляторных или интерпретаторных движков других языков веб-программирования). Такое устройство «движка» PHP позволяет обрабатывать сценарии с достаточно высокой скоростью. По оценкам, большинство PHP-сценариев (особенно не очень больших размеров) обрабатываются быстрее аналогичных им программ, написанных на Perl. Данные результаты позволяют остановить свой выбор на PHP как языке реализации программы, так как производительность языка вполне достаточна для создания вполне серьезных web-приложений.

  
  Безопасность
  
  РНР предоставляет в распоряжение разработчиков и администраторов гибкие и эффективные средства безопасности, которые условно делятся на две категории: средства системного уровня и средства уровня приложения.

  
  1. Средства безопасности системного уровня.

  
  

  В РНР реализованы механизмы безопасности, находящиеся под управлением администраторов; при правильной настройке РНР это обеспечивает максимальную свободу действий и безопасность. РНР может работать в так называемом безопасном режиме (safe mode), который ограничивает возможности применения РНР пользователями по ряду важных показателей. Например, можно ограничить максимальное время выполнения и использование памяти (неконтролируемый расход памяти отрицательно влияет на быстродействие сервера). По аналогии с cgi-bin администратор также может устанавливать ограничения на каталоги, в которых пользователь может просматривать и исполнять сценарии РНР, а также использовать сценарии РНР для просмотра конфиденциальной информации на сервере (например, файла passwd).
  
  

  
  

  
  2. Средства безопасности уровня приложения.
  
  В стандартный набор функций РНР входит ряд надежных механизмов шифрования. РНР также совместим с многими приложениями независимых фирм, что позволяет легко интегрировать его с защищенными технологиями электронной коммерции (e-commerce). Другое преимущество заключается в том, что исходный текст сценариев РНР нельзя просмотреть в браузере, поскольку сценарий компилируется до его отправки по запросу пользователя. Реализация РНР на стороне сервера предотвращает похищение нетривиальных сценариев пользователями, знаний которых хватает хотя бы для выполнения команды View Source.

  
  Гибкость

  
  Поскольку РНР является встраиваемым (embedded) языком, он отличается исключительной гибкостью по отношению к потребностям разработчика. Хотя РНР обычно рекомендуется использовать в сочетании с HTML, он с таким же успехом интегрируется и в JavaScript, WML, XML и другие языки. Кроме того, хорошо структурированные приложения РНР легко расширяются по мере необходимости (впрочем, это относится ко всем основным языкам программирования).
  
  Нет проблем и с зависимостью от браузеров, поскольку перед отправкой клиенту сценарии РНР полностью компилируются на стороне сервера. В сущности, сценарии РНР могут передаваться любым устройствам с браузерами, включая сотовые телефоны, электронные записные книжки, пейджеры и портативные компьютеры, не говоря уже о традиционных ПК. Программисты, занимающиеся вспомогательными утилитами, могут запускать РНР в режиме командной строки.
  
  Поскольку РНР не содержит кода, ориентированного на конкретный web-сервер, пользователи не ограничиваются определенными серверами (возможно, незнакомыми для них). Apache, Microsoft IIS, Netscape Enterprise Server, Stronghold и Zeus — РНР работает на всех перечисленных серверах. Поскольку эти серверы работают на разных платформах, РНР в целом является платформенно-независимым языком и существует на таких платформах, как UNIX, Solaris, FreeBSD и Windows 95/98/NT/2000/XP/2003.
  
  

  
  Наконец, средства РНР позволяют программисту работать с внешними компонентами, такими как Enterprise Java Beans или СОМ-объекты Win32. Благодаря этим новым возможностям РНР занимает достойное место среди современных технологий и обеспечивает масштабирование проектов до необходимых пределов.
  
  

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

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

  Основными особенностью реализации графического интерфейса является минимальный объем графического материала сайта СДО

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

  
  
  

  GIF (Graphic Interchange Format)

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

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

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

  Сжатие

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

  Алгоритм сжатия LZW относится к форматам сжатия без потерь. Это означает, что восстановленые из GIF данные будут в точности соответствовать упакованым. Следует отметить, что это верно только для 8-битных изображений с палитрой, для цветной фотографии потери будут обусловлены переводом её к 256 цветам.

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

  
  

  JPEG (Joint Photographic Experts Group)

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

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

  
  
  

  Сжатие

  При сжатии изображение переводится в цветовую систему YCbCr. Далее каналы изображения Cb и Cr, отвечающие за цвет, уменьшаются в 2 раза (по линейному масштабу). Уже на этом этапе необходимо хранить только четверть информации о цвете изображения.

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

  Далее цветовые каналы изображения, включая черно-белый канал Y, разбиваются на блоки 8 на 8 пикселей. Каждый блок подвергается дискретному косинусному преобразованию. Полученные коэффициенты подвергаются квантованию и упаковываются с помощью кодов Хаффмана.

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

  
  

  В качестве интсрумента по созданию элементов графического интерфейса использовался Adobe Photoshop - графический редактор, разработанный и распространяемый фирмой Adobe Systems. Этот продукт является лидером рынка в области коммерческих средств редактирования растровых изображений, и наиболее известным продуктом фирмы Adobe. В настоящее время Photoshop доступен на платформах Mac OS и Microsoft Windows. Ранние версии редактора были портированы под SGI IRIX, но официальная поддержка была прекращена, начиная с третьей версии продукта.

  
  

  Особенности

  
  

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

  RGB

  Lab

  CMYK

  Grayscale

  Bitmap

  Duotone

  6 Проект системы

  6.1 Структура системы

  Разрабатываемый программный продукт состоит из следующих модулей (подсистем):

  
  

  ·   база данных;

  ·   подсистема обеспечения учебно-методического материала;

  ·   подсистема управления учебным процессом;

  ·   подсистема администрирования учетных записей пользователей системы;

  ·   подсистема контроля доступа к УММ;

  ·   подсистема сбора статистики и системных отчетов.

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

  Модуль контроля лоступа обеспечивает выборочный доступ к УММ СДО. Администрированием данного модуля занимается человек, наделенный определенной компетенцией – администратор СДО

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

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

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

  
  

  6.2 Описание системы

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

  ·   работать с пользователями системы

  o создавать новых пользователей

  o редактировать данные существующих пользователей

  o удалять пользователей из системы

  ·   работать с учебно-методическим материалом

  o создавать новые курсы

  o редактировать данные существующих курсов

  o удалять курсы из системы

  ·   работать с вопросами\тестами к курсу

  o создавать новые вопросы\тесты

  o редактировать данные существующих вопросы\тесты

  o удалять вопросы\тесты из системы

  ·   определять доступ к курсам

  o назначать полный доступ ко всем курсам системы

  o назначать выборочный доступ к курсам системы

  ·   просматривать УММ

  
  

  6.3 Входная и выходная информация

  
  

  Программный модуль	Входная информация	Выходная информация
  модуль контроля доступа	·  Управляющие команды от модуля графического интерфейса ·  Результаты выполнения запросов к СУБД MySQL	·  Запросы на выборку данных к СУБД MySQL ·  Импортируемые данные в БД СДО
  модуль создания \ редактирования \ удаления УММ	·  Управляющие команды от модуля графического интерфейса ·  Результаты выполнения запросов к СУБД MySQL	·  Запросы к БД СДО на выборку данных ·  Файлы ИБД ·  Отчеты
  модуль просмотра данных	·  Данные от модуля графического интерфейса ·  Запросы к БД СДО на выборку данных	·  Результаты выполнения запросов модуля графического интерфейса ·  Результаты выполнения запросов к БД СДО
  база данных СДО	·  Данные от модуля графического интерфейса ·  Запросы от модуля графического интерфейса ·  Загружаемые данные от модуля модуль создания\ редактирования\ удаления УММ ·  Запросы на выборку от модуля просмотра данных	·  Результаты выполнения запросов модуля графического интерфейса ·  Результаты выполнения запросов модуля создания \ редактирования \ удаления УММ
  модуль графического интерфейса	·  Команды пользователей ·  Результаты выполнения запросов к БД СДО	·  Данные, введенные пользователями ·  Запросы к БД СДО ·  Управляющие команды к модулю создания \ редактирования \ удаления УММ ·  Управляющие команды к модулю просмотра данных

  
  
  

  6.4 Потоки данных

  Для того чтобы документировать механизмы передачи и обработки информации в моделируемой системе используются диаграммы потоков данных (DFD). Диаграммы DFD (Data Flow Diagrams) используются для наглядного изображения информационных потоков системы.

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

  Всего DFD использует четыре важных элемента:

  ·   работы;

  ·   стрелки;

  ·   внешние ссылки;

  ·   хранилища данных.

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

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

  Диаграммы DFD программной подсистемы обеспечения учебно-методического материала приведены в Приложении.

  
  
  
  
  

  7.1 Разработка архитектуры системы с использованием технологии RUP

  7.1.1 Выбор моделей формализации процесса разработки

  В начале данного раздела хотелось бы уделить внимание формализованности процесса разработки архитектуры программного комплекса с использованием методологии RUP. Данная методология отчасти была выбрана из-за того, что предоставляет очень гибкие возможности в плане адаптируемости уровня формализованности. Для выбора уровня формализованности стоит лишь уточнить конфигурацию RUP, так как данная настраиваемая технологическая основа позволяет пользователю самому создавать широкое разнообразие описаний процессов, артефактов и документов.
           В книге «Get Ready for Agile Methods, with Care» профессор Барри Боэм (Barry Boehm) описывает, как потребность в быстрой адаптации к меняющейся деловой среде можно соотнести с потребностью в предсказуемости и дисциплине путем выбора верного уровня формализованности, соответствующего нуждам проекта. (Боэм использует термины «гибкий» (Agile) и «дисциплинированный» (Disciplined), имея в виду соответствующие термины формализованности («низкоформализованный» и «высокоформализованный»).

  
  

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

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

  
  

  Рис. 7.1.1

  
  

  7.1.2 Первый этап – Начало (Inception)

  
  

           Согласно процессу разработки программы по RUP, архитектура должна быть закреплена на втором этапе разработки ПО – проектировании (Elaboration), но для стабильности выбранного архитектурного решения разрабатываемого мной программного продукта жизненно важно успешное завершение первой фазы разработки – выявления цели создания программы (Inception). В первую очередь были собраны все требования и пожелания (user requirements and needs) заказчика относительно функционала подсистемы. Кроме того, было достигнуто общее понимание всех функций, поддерживаемых системой. Может показаться странным, но это факт, что во многих проектах отсутствует об­щее понимание того, что нужно создавать. Хотя все участники процесса могут думать, что они знают это, но часто один имеет совершенно другое представление, чем другой. Соответственно, крайне необходимо придти к соглаше­нию с заказчиком, что считать успешным завершением проекта. В пректе разработки подсистемы было обеспечено полное понимание заданного объема работ для таких ролей, как: аналити­к, разработчик, тестировщик, инженер-технолог, менеджер проекта и, наконец, заказчик.

  Далее, после длительных консультаций с заказчиком, был сформирован небольшой документ под названием Концепция системы (Vision). (См. приложение, артефакты RUP, Vision). Данный документ в комплексе с некоторыми другими документами, принятыми Унифицированным Процессом за основополагающие, будет являться Техническим Заданием на разработку проекта. См. табл. 7.1.2

  
  
  
  
  
  
  
  

  Стадия	Артефакт RUP	Документы ГОСТ 19
  Техническое задание	Концепция системы Описание процесса разработки продукта План разработки продукта	Техническое задание 19.201-78

  
  

  Таблица 7.1.2

  
  

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

  
  

  Концепция описывает следующие параметры:

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

  - проблему или проблемы, решаемые приложением;

  - конечные пользователи системы;

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

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

           Концепция образует основу для общего понимания мотивов построения системы, а также высокоуровневое определение соз­даваемой системы. Данный документ считается полным и стабильным к концу первой фазы, но помимо этого он будет продолжать совершенство­ваться в ходе всего проекта разработки, особенно в ходе Проектирования (Elaboration) и начальных этапов Построения (Construction; вследствие наличия некоторого изменения границ проекта).

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

  
  
  

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

  Далее выявляются другие модули СДО, с которыми взаимодействует подсистема выдачи методического материала. Такие объекты также будут являться акторами по отношению к разрабатываемой подсистеме.

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

  
  

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

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

  
  

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

  
  
  

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

   Для нашей системы были выбраны и описаны 14 пре­цедентов использования из которых 4 являются критичными. (См. приложение, графические материалы, плакат №1, «Модель предметной области»).

  
  

           Понять что создавать - это главное, но столь же важно определить, как создавать и с какими затратами. С целью понимания, целесообразно ли с экономической точки зрения продолжать проект, был сделан приблизительный расчет стоимости проекта. Большая часть стоимости продукта оказалась связана с обеспечением требуемых ресурсов и с тем, сколько времени занимает выполнение проекта. Далее вышеобозначенные параметры были совмещены с оценкой требуемой функциональности с точки зрения ее ценности для заказчика, и на основе этого было созданой экономическое обоснование проекта (Business Case). Эко­номическое обоснование описывает ценность продукта, выражая ее в количественных единицах, таких, например, как окупаемость инвестиций (return of investment, ROI). Экономическое обоснование - это инструмент для по­лучения адекватного финансирования проекта. В случае разработки подсистемы выдачи материала для СДО «*****» бюджет был установлен еще до того, как началась разработка проекта. Также заранее был определен масштаб системы, которую возможно выпустить в рамках установленного бюджета и сроков. (См. приложение, артефакты RUP, Business Case)

  7.1.3 Второй этап – Проектирование (Elaboration)

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

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

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

  -риски, связанные с архитектурой (действительно ли выбрано нужное решение?);

  - риски, связанные со стоимостью и сроками (укладывается ли процесс разработки в границы по срокам и бюджету?);

  - риски, связанные с процессом и инструментом (действительно ли для работы востребованы нужные процессы и используются правильные инструменты?).

  
  

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

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

  
  

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

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

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

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

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

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

  
  

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

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

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

  - переход от общего знания наиболее важных требований к подробному по­ниманию более 80% всех требований.

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

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

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

  7.1.4 Третий этап – Построение (Construction)

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

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

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

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

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

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

  
  
  

  Требования	Компоненты	Тесты
  Конец проектирования
  ·   Выявлено 14 прецедентов использования (ПИ) ·   2 ПИ описаны детально, 4 довольно глубоко и 3 кратко	·   Определено 4 главных компонента ·   В 4-х из них реализовано 50% кода, включая все интерфейсы ·   В 3 из них реализованы интерфейсы и минимум логики (приблизительно 10-20% окончательного объема кода) ·   Нижние уровни архитектуры практически полностью реализованы ·   Реализованный код прошел модульное тестирование	·   Проведены первичные нагрузочные тесты и тесты производительности. Тестировались главным образом архитектурнозначимые ПИ ·   Должным образом протестирована функциональность 4-х архитектурнозначимых ПИ
  Конец первой итерации этапа Построение
  ·   6 ПИ описаны детально, 3 -достаточно глубоко	·   Определено 9 компонентов (один оказался ненужным из-за того, что был уда­лен ПИ) ·   7 из них практически полностью реализованы ·    В 2 из них реализовано 50% кода, включая все интерфейсы ·   В 8 есть реализованные интерфейсы и минимум логики (приблизительно, 10-20% окончательного объема кода) ·   Нижние уровни архитектуры практически полностью реализованы ·   Реализованный код прошел модульное тестирование	·   Продолжаются нагрузочные тесты и тесты производитель­ности, чтобы гарантировать стабильность качества архитектуры ·   Проводятся функциональные тесты ПИ по мере их завершения
  Конец второй итерации этапа Построение
  ·   Один из 3-х еще не описанных ПИ, выведен за рамки проекта из-зи ограничений времени ·   9 ПИ описаны подробно	·   Определено 13 главных компонентов (один оказался ненужным из-за того, что был уда­лен ПИ) ·   10 из них практически полностью реализованы ·    В 2 из них реализовано 50% кода, включая все интерфейсы ·   В 8 есть реализованные интерфейсы и минимум логики (приблизительно, 10-20% окончательного объема кода) ·   Нижние уровни архитектуры практически полностью реализованы Реализованный код прошел модульное тестирование	·   Продолжаются нагрузочные тесты и тесты производитель­ности, чтобы гарантировать стабильность качества архитектуры ·   Проводятся функциональные тесты ПИ по мере их завершения
  Конец третьей итерации этапа Построение
  ·   Все 14 ПИ описаны подробно	·   Определено 14 компонентов ·   Система полностью функциональна. Готов бета-релиз. ·    Все 14 компонентов практически польностью реализованы (тонкая доводка и исправление ошибок будут проводиться в ходе фазы Внедрение) ·   Реализованный код прошел модульное тестирование	·   Продолжаются нагрузочные тесты и тесты производитель­ности, чтобы гарантировать стабильность качества архитектуры ·   Проводятся функциональные тесты ПИ по мере их завершения

  
  

  Таблица 7.1.4.

  
  

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

           Обязательным условием на протяжении всех итерации этапа Разработчики является постоянное тестирование результатов разработки и контроль того, что реализация отвечает требованиям. Кроме того, для тестирова­ния программной подсистемы потребовалась реализация тестовых драйверов и тесто­вых «заглушек» для эмуляции других компонентов, которые будут взаимодейст­вовать с данным. Для автоматической генерации таких тестовых драйверов и «за­глушек» использовалось средство визуального моделирования. Получив «заглушки» был совершен прогон тестовых сценариев, которые создаются на основе сценариев прецедентов использования, в которы используются данные компоненты, поскольку сценарии прецедентов определяют то, каким образом компоненты будут взаимодействовать с пользователями.

           Далее по плану итерации следует подготовка к выпуску бета-версии.

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

  Бета-тестирование служит двум целям: во-первых, тестируется контролируе­мая реальная реализация программной подсистемы, во-вторых, обеспечивается предваритель­ный просмотр готовящегося релиза. Автору дипломного проекта в роли Менеджера по развертыванию (deployment manager) необходимо следить за программой бета-тестирования и обеспечить выпол­нение обеих этих целей.

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

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

  
  

           Так как все объективные метрики достигнуты, можно считать, что этап Построение был пройден успешно, то есть уже сделано следующее:

  -было разработано (с экономической точки зрения эффективно) программное обеспечение;

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

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

  -было обеспечено удобство использования системы и соответствие ПО нуждам пользователей.

  
  
  

  7.1.5 Четвертый этап –Внедрение (Transition)

  
  

  
  

           Так как была разработана архитектура и исполняеймый модуль программной подсистемы выдачи учебно-методического материала, я не буду детально описывать последний этап жизненного цикла RUP – Внедрение, так как на данном этапе существует множество требований к  созданию других программных подсистем – модулей СДО «*****»(БД пользователей, администраторского интерефейса, новостного движка и т.д.) следующая итерация будет Начало, в которой будет проводиться анализ требований и составления спецификации на другие подсистемы.

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

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

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

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

  
  

           И так можно считать, что этап Внедрение был пройден успешно в том случае, если:

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

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

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

  - Подготовлена площадка (сайт) для развертывания и конвертирования
  рабочей базы данных. Для запуска СДО «*****» в производство закупка нового оборудования, подготовка места для него или перевод данных из старых систем в новую не требуются.

           Успешным окончанием данного этапа для разработки всей СДО (соответственно, включая ПП для выдачи учебно-методического материала ) можно считать подписание заказчиком Акта о внедрении. (См. приложение, Акт о внедрении)

  7.2 Проект базы данных

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

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

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

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

  На основании составленной логической модели и учитывая типы данных поддерживаемые СУБД MySQL составляем физическую модель базы данных. Модель разработанной базы данных можно увидеть в Приложении 2, (Плакат №4 «Схема БД системы»).

  7.3 Описание графического интерфейса пользователя.

           Данный раздел дипломной работы посвящен описанию внешнего вида и выполняемых функций графического интерфейса ПП обеспечения учебно-методическим материалом СДО «*****». В качестве примеров реализации графической системы взаимодействия пользователей с программой в данном разделе будут описаны следующие стандартные интерфейсы СДО:

  - интерфейс просмотра авторизованных пользователей СДО «*****» с возможностью предоставления полного доступа к УММ (рис. 7.1)

  - интерфейс предоставления выборочного доступа пользователей СДО к курсам УММ (рис. 7.2)

           - интерфейс создания нового текстового курса (рис. 7.3)

  - интерфейс редактирования и удаления выбранного текстового курса (рис. 7.4)

  - интерфейс просмотра выбранного курса (рис. 7.5)

  
  

  7.3.1 Интерфейс просмотра авторизованных пользователей СДО «*****» с возможностью предоставления полного доступа к УММ

  Рис 7.1

  
  

  ·   Нахождение в общем дереве меню:

  ПОЛЬЗОВАТЕЛИ > ОПРЕДЕЛЕНИЕ ДОСТУПА

  ·   Доступно для следующих ролей:

  администратор, тьютор

  ·   Краткое описание возможных действий:

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

  
  

  7.3.2 Интерфейс предоставления выборочного доступа пользователей СДО к курсам УММ

  Рис 7.2

  ·   Нахождение в общем дереве меню:

  ПОЛЬЗОВАТЕЛИ > ОПРЕДЕЛЕНИЕ ДОСТУПА > ПОЛЬЗОВАТЕЛЬ

  ·   Доступно для следующих ролей:

  администратор, тьютор

  ·   Краткое описание возможных действий:

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

  7.3.3 Интерфейс создания нового текстового курса

  Рис 7.3

  ·   Нахождение в общем дереве меню:

  УЧЕБНЫЙ МАТЕРИАЛ > ДОБАВЛЕНИЕ

  ·   Доступно для следующих ролей:

  тьютор

  ·   Краткое описание возможных действий:

  В данном меню тьютор может создать новый текстовый курс. Данный курс импортируется из программы MS Word и с помощью данной страницы загружается в систему «*****». «На лету» генерируется физическое хранилище файлов курса на сервере, данные загружаются по протоколу ftp на сервер и создаются все логические связи данного курса с остальными посредством выполнения определенных запросов к БД.

  
  

  7.3.4 Интерфейс редактирования и удаления выбранного текстового курса

  Рис 7.4

  ·   Нахождение в общем дереве меню:

  УЧЕБНЫЙ МАТЕРИАЛ > РЕДАКТИРОВАНИЕ

  ·   Доступно для следующих ролей:

  тьютор

  ·   Краткое описание возможных ействий:

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

  7.3.5 Интерфейс просмотра выбранного курса

  
  

  Рис 7.5

  ·   Нахождение в общем дереве меню:

  УЧЕБНЫЙ МАТЕРИАЛ > ПРОСМОТР

  ·   Доступно для следующих ролей:

  администратор, тьютор, студент

  ·   Краткое описание возможных действий:

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

  
  

  Рис. 7.6

  7.4 Алгоритмы работы модуля обеспечения УММ.

  Рис. 7.7

  
  

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

  Для лучшего понимания алгоритма ниже будет рассмотрено пошаговое выполнение сценария процесса обучения акторами системы:

  1. НАЧАЛО*

  2. «Запрос на доступ к обучающим материалам»

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

  3. «Получение разрешения на доступ»

  В зависимости от текущих прав пользователя ПП либо предоставляет доступ к запрашиваемому УММ, либо выводит диагностическое сообщение (см. рис. 7.6) о нехватке полномочий, необходимых для просмотра данного курса (шаг. 4. «Вывод сообщения о недоступности курса»)

  5. «Вывод курса на экран». Показывается выбранный студентом курс.

  6. «Изучение материала». Студент изучает материал.

  7. «Отправка письма с ответами на вопросы». Студент отвечает на вопросы курса для перехода к следующему. Также тьютором может быть предлложено пройти тест для закрепления полученных знаний.

  8. «Анализ ответа слушателя на вопросы курса» Кроме прохождения теста тьютор может посоветовать студенту ознакомиться с курсом еще раз (шаг 9. «Письмо с предложением повторно изучить курс»)

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

  11. «Изменение инф. о слушателе в БД» Все изменения статуса и прав пользователя записываются в БД системы.

  12. «Оформление сертификата» После успешного окончания всех курсов, ученику предоставляется сертификат об успешном окончании курсов дистанционного обучения.

  13. «Получение сертификата»

  14. КОНЕЦ

  
  

  ·   Изначально предполагается, что актором «слушатель» является студент оплативший использование СДО и желающий начать процесс обучения.

  
  

  7.5 Тестирование подсистемы

  7.5.1 План тестирования

  
  

  1. Идентификатор тестового плана: ПП-ТП-1.0

  
  

  2. Ссылки на используемые документы.

  
  

           Данный план разработан на основании стандарта IEEE 829 (Стандарт на тестовую документацию) и Технического задания (В дальнейшем ТЗ) на Разработку системы дистанционного обучения «*****» (В дальнейшем СДО «*****»).

  
  

  3. Введение.

  
  

           Целью данного документа является детальная разработка плана тестирования возможностей программной подсистемы  (далее ПП)  обеспечения учебно-методическим материалом СДО «*****», определение программных и аппаратных средств для реализации этого плана и документов для хранения и отображения результатов тестирования. В связи с тем, что исходные коды программы также будут подвергаться анализу, одним из  методов тестирования будет методика «стеклянного ящика» (изнутри). Тестирование будет проводиться программными средствами компании IBM (подразделение Rational), в частности Rational Test Manager, Rational Robot и т.д.

  
  

  4. Тестируемые элементы.

  
  

           4.1 Тестируемы объект – ПП обеспечения учебно-методическим материалом СДО «*****», версия 1.5 beta.

           4.2 Исправление ошибок – Все найденные и исправленные в ходе тестирования ошибки должны быть проверенны.

           4.3 Документация – Вся разработанная документация должна соответствовать ТЗ и стандартнам ЕСПД.

  
  

  5. Проблемы риска тестируемого продукта.

  
  

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

  
  

  6. Свойства, подлежащие тестированию.

  
  

  6.1 Загрузка клиентом главной страницы Подсистемы в различных типах браузеров (Internet Explorer/Mozilla Firefox/Nescape Navigator/Opera).

           6.2 Повторная загрузка клиентом главной страницы Подсистемы.

  6.3 Регистрация нового курса (из меню администрирования, производиться тьютором).

  6.4 Регистрация нового курса (из меню администрирования, производиться                 тьютором).

           6.5 Удаление курса

           6.6 Редактирование курса

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

           6.8 Временные параметры выполнения всех вышеобозначенных действий.

           6.9 Обработка ошибок пользователей Подсистемой.

          

  
  

  7. Свойства, не подлежащие тестированию.

  
  

           Согласно п.5 данного плана, тестированию не подлежит ход выполнения программы (сценария).

  
  

  8. Подход (Стратегия тестирования).

  
  

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

  
  

  8.2    Функции Подсистемы проверяются независимо друг от друга.

  
  

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

  
  

  8.3.   Приемочное тестирование.

  
  

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

  
  

  8.4.   Регрессионное тестирование.

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

  
  

  8.5    Тестирование производительности

  
  

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

  
  

  8.6    Нагрузочное тестирование.

  
  

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

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

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

  - выполнение заданного сценария на компьютере с минимально воз­можной тактовой частотой и минимальным объемом памяти;

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

  
  

  8.7    Тестирование  на  "не  тронутой"   машине  (The virgin machine)

  
  

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

  
  

  8.8.   Отслеживание обнаруженных ошибок.

  
  

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

  Если программист исправляет ошибку, то он фиксирует это в базе данных ошибок. Тестер проверяет качество исправления ошибки и фиксирует это в базе данных ошибок. Он либо под­тверждает факт исправления ошибки, либо открывает ее вновь. ** закрыть проблему предоставляется либо руководителю проекта, либо руководителю группы программистов.

  
  

  9. Критерий приемочного тестирования

  
  

  Для оперативной оценки качества Подсистемы используется приемочный тест. Только после успешного прохождения приемоч­ного теста данная программа может быть принята тестовой группой для проведения полного цикла тестирования. Данные тест приво­дится в документе "Подсистема «БД пользователей».  Приемочный тест".

  
  

  10.Критерий прохождения тестов.

  
  

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

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

  
  

  11.Критерий приостановки и возобновления работ.

  
  

  Работы приостанавливаются до решения проблем в следую­щих случаях:

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

  - при тестировании обнаруживается, что не совпадает более 50% всех эталонных и полученных результатов;

  - при отказе оборудования;

  - при изменении отдельных функций Подсистемы.

  Тестирование возобновляется по решению руководителя разработки после устранения перечисленных причин приостанов­ки работ.

  
  

  12. Тестовая документация.

  
  

  Для тестирования Подсистемы должны быть составлены сле­дующие документы:

  - план тестирования;

  - приемочный тест;

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

  - база данных ошибок и отчеты на основе ее содержимого;

  - проверочный лист (Сheck List);

  - итоговый отчет по результатам тестирования.

  
  

  13. Задачи тестирования

  
  

  В ходе подготовки к тестированию и его проведения реша­ются следующие задачи:

  - изучение объекта тестирования (ПП обеспечения учебно-методическим материалом СДО «*****»);

  - разработка плана тестирования;

  - разработка системы проверочных тестов и тестовых случаев;

  - разработка документации для проведения процедуры тестиро­вания;

  - реализация процедур тестирования;

  - ведение базы данных ошибок;

  - разработка отчетов о результатах тестирования.

  
  

  14.    Необходимый персонал и обучение

  
  

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

  
  

  15.    Требования окружающей среды

  
  

  Для успешного тестирования Подсистемы необходимы сле­дующие аппаратные и программные средства:

  ПЭВМ с микропроцессором типа Pentium в стандартном окру­жении.

  Операционная среда: Windows XP;

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

  - броузер (Internet Explorer/Mozilla Firefox/Nescape Navigator/Opera) с открытой главной страницой подсистемы «БД пользователей»;

  - сетевая база данных ошибок Bugzilla;

  - пакет специализированных программ Rational для проведения тестирования.

  
  

  16. Распределение ответственности

  
  

  Для тестирования данной программы требуется один тестер; В его обязанности входит:

  - разработка всей указанной в п. 12 тестовой документации;

  - разработка системы тестов Подсистемы;

  - ведение базы данных ошибок;

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

  
  

  17. График работ.

  
  

           Работы по разработке и отладка тестов и тестовой документации производятся в соответствии с календарным планом:

  
  

  № п.п.	Задача	Дата начала	Дата конца
  1	Изучение технического задания	17 Апреля 2006г.	24 Апреля 2006г.
  2	Разработка и согласование плана тестирования.	24 Апреля 2006г.	26 Апреля 2006г.
  3	Разработка спецификации комплекса тестов	26 Апреля 2006г.	28 Апреля 2006г.
  4	Разработка тестов	28 Апреля 2006г.	1 Мая 2006г.
  5	Разработка тестовой документации	1 Мая 2006г.	7 Мая 2006г.
  6	Реализация тестовых процедур	1 Мая 2006г.	7 Мая 2006г.
  7	Тестирование рабочей документации	7 Мая 2006г.	9 Мая 2006г.
  8	Корректировка тестов и тестовой документации	9 Мая 2006г.	16 Мая 2006г.

   

  18. Утверждение плана

  
  

  План тестирования утверждает руководитель проекта.

  
  

  20. Глоссарий

  
  

                     Тестовый случай – это минимальный тестовый модуль, допускающий независимое выполнение от начала до конца.

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

                     Тестер – участник процесса тестирования программного продукта.

                     Пользователь системы – человек, использующий СДО «*****». В качестве ролей предполагаются: студент, тьютор и администратор.

  
  

           7.5.2 Содержание тестовых случаев

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

  
  

  Информация о тестовом случае
  Идентификатор тестового случая	Загрузка клиентом главной страницы Подсистемы в различных типах браузеров (Internet Explorer/Mozilla Firefox/Nescape Navigator/Opera). (ТС5131_1)
  Владелец теста	** П.А.
  Дата создания последней версии Тестового случая	10.05.06
  Местонахождение тестового случая	содержание_тестовых_случаев.doc
  Тестируемое требование	П. 4.1 ТЗ/П. 6.1
  Цель тестирования	Выявить корректность отображения данных различными браузерами.
  Конфигурация средств тестирования	Определена в разделе 15 ПТ
  Взаимозависимость тестовых случаев	Прогон тестового случая не требует прогона других тестовых случаев.

  
  

  Методика тестирования
  Установка тестового случая		Установка тестового случая осуществляется при загрузке начальной страницы ПП в браузере.
  Шаг	Действие	Ожидаемый результат	Отметка (V-нет ошибок, X - ошибка)
  1	Загрузка главной страницы подсистемы браузером MS Internet Explorer 6.0	Корректное отбражение текстовой и графической информации сервера, а так же сохранение оригинального форматирования.	V
  2	Загрузка главной страницы подсистемы браузером Netscape Navigator 8.0.4	___,,___	V
  3	Загрузка главной страницы подсистемы браузером Mozilla Firefox 1.0.7	___,,___	V
  4	Загрузка главной страницы подсистемы браузером Opera 8.0	___,,___	X
  5	Очистка данных тестового случая	Не производиться

  
  

  Результаты тестового случая.

  
  

  Тестер: ** П.А. Дата прогона: 10.05.06 Результат: тестовый случай обнаружил ошибки в программе.

  
  

  Примечания: тестовый случай обнаружил ошибки

  при форматировании текста в браузере Opera 8.0 

  
  
  
  
  

  Информация о тестовом случае
  Идентификатор тестового случая	Удаление курса из БД подсистемы. (ТС5131_5)
  Владелец теста	** П.А.
  Дата создания последней версии Тестового случая	10.05.06
  Местонахождение тестового случая	содержание_тестовых_случаев.doc
  Тестируемое требование	П. 4.1 ТЗ/П. 6.5
  Цель тестирования	Выявить, насколько «чисто» происходит удаление информации из БД.
  Конфигурация средств тестирования	Определена в разделе 15 ПТ
  Взаимозависимость тестовых случаев	Прогон тестового случая не требует прогона других тестовых случаев.

  
  

  Методика тестирования
  Установка тестового случая		Установка тестового случая осуществляется при загрузке начальной страницы ПП в браузере.
  Шаг	Действие	Ожидаемый результат	Отметка (V-нет ошибок, X - ошибка)
  1	Загрузка главной страницы подсистемы браузером MS Internet Explorer 6.0	Корректное отображение текстовой и графической информации сервера, а так же сохранение оригинального форматирования.	V
  2	Установить курсор на поле ввода логина. Ввести логин тестировщика для доступа в систему.	В наборном поле: tester	V
  3	Установить курсор на поле ввода пароля. Ввести логин тестировщика для доступа в систему.	В наборном поле: test_group	V
  4	Кликнуть на ссылку «Просмотр» раздела Пользователи.	Браузер переходит на страницу управления пользователями СДО.	V
  5	В меню администрирования пользователя поставить галочку в checkbox «Удалить» напротив желаемого курса	Появиться сообщение «Удален курс …»	V
  6	Проверить БД на наличие записей в различных таблицах с course_id только что удаленного тестового курса.	Записей не обнаружено.	V
  7	Очистка данных тестового случая	Не производиться

  
  
  
  

  Результаты тестового случая.

  
  

  Тестер: ** П.А. Дата прогона: 10.05.06 Результат: тестовый случай ошибки в функционировании программы не обнаружил.

  
  
  
  
  

  Информация о тестовом случае
  Идентификатор тестового случая	Регистрация нового курса (из меню администрирования, производиться тьютором). (ТС5131_6_3)
  Владелец теста	** П.А.
  Дата создания последней версии Тестового случая	10.05.06
  Местонахождение тестового случая	содержание_тестовых_случаев.doc
  Тестируемое требование	П. 4.1 ТЗ/П. 6.3
  Цель тестирования	Выявить временный параметры работы подсистемы при регистрации нового курса.
  Конфигурация средств тестирования	Определена в разделе 15 ПТ
  Взаимозависимость тестовых случаев	Прогон тестового случая не требует прогона других тестовых случаев.

  
  

  Методика тестирования
  Установка тестового случая		Установка тестового случая осуществляется при загрузке начальной страницы ПП в браузере.
  Шаг	Действие	Ожидаемый результат	Отметка (V-нет ошибок, X - ошибка)
  1	Загрузка главной страницы подсистемы браузером MS Internet Explorer 6.0	Корректное отбражение текстовой и графической информации сервера, а так же сохранение оригинального форматирования.	V
  2	Кликнуть по ссылке «Добавление»	Браузер переходит на страницу создания пользователя СДО.	V
  3	Установить курсор на поле ввода имени текстового файла:. Ввести название тестового курса.	В наборном поле: test	V
  4	Установить курсор на поле ввода имени первого графического файла. С помощью средств UI windows выбрать нужный графический файл.	В наборном поле: путь_к_файлу_на _локальном_диске_пользователя	V
  5	Установить курсор на поле ввода имени второго графического файла. С помощью средств UI windows выбрать нужный графический файл.	В наборном поле: путь_к_файлу_на_локальном _диске_пользователя2	V
  6	Установить курсор на поле ввода имени третьего графического файла. С помощью средств UI windows выбрать нужный графический файл.	В наборном поле: путь_к_файлу_на_локальном _диске_пользователя3	V
  7	Установить курсор на поле ввода названия тестового курса. Ввести текст «test».	В наборном поле: test	V
  8	Установить курсор на поле ввода  автора тестового курса. Ввести текст «test».	В наборном поле: test	V
  12	Кликнуть на кнопку «Отправить»	Появиться текст «Курс успешно создан »	V
  13	Проверить создание данных в БД Подсистемы	Данные по курсу сохраняются в БД в таблице course с уникальным course_id.	V
  7	Очистка данных тестового случая	Для очистки результатов тестового случая необходимо удалить тестовый курс.

  
  

  Результаты тестового случая.

  
  

  Тестер: ** П.А. Дата прогона: 10.05.06 Результат: тестовый случай ошибки в функционировании программы не обнаружил.

  
  

  Временные параметры: единичный прогон данного тестового случая занял 139.304 секунды.

  
  

  7.5.3. Таблица покрытий

  Требование / свойство	Тестовый случай	Исходные данные теста	Конфигурация средств тестирования	Назначение теста
  П. 4.1 ТЗ / П. 6.1	Загрузка клиентом главной страницы Подсистемы в различных типах браузеров (Internet Explorer/Mozilla Firefox/Nescape Navigator/Opera).	Задаются с клавиатуры и с помошью мыши.	Определена в разделе 15 ПТ	Проверка загрузки подсистемы.
  П. 4.1 ТЗ / П. 6.2	Повторная загрузка клиентом главной страницы Подсистемы.	Задаются с клавиатуры и с помошью мыши.	Определена в разделе 15 ПТ	Проверка загрузки подсистемы.
  П. 4.1 ТЗ / П. 6.3	Регистрация нового курса (из меню администрирования, производиться тьютором).	Задаются с клавиатуры и с помошью мыши.	Определена в разделе 15 ПТ	Работа с УММ подсистемы.
  П. 4.1 ТЗ / П. 6.4	Регистрация нового курса (из меню администрирования, производиться администратором)	Задаются с клавиатуры и с помошью мыши.	Определена в разделе 15 ПТ	Работа с УММ подсистемы.
  П. 4.1 ТЗ / П. 6.5	Удаление курса.	Задаются с клавиатуры и с помошью мыши.	Определена в разделе 15 ПТ	Работа с УММ подсистемы.
  П. 4.1 ТЗ / П. 6.6	Редактирование данных курса.	Задаются с клавиатуры и с помошью мыши.	Определена в разделе 15 ПТ	Работа с УММ подсистемы.
  П. 4.1 ТЗ / П. 6.7	Определение уровня доступа пользователей к курсам.	Задаются с клавиатуры и с помошью мыши.	Определена в разделе 15 ПТ	Работа с пользователями подсистемы.
  П. 4.1 ТЗ / П. 6.8	Временные параметры выполнения всех вышеобозначенных действий.	Задаются с клавиатуры и с помошью мыши.	Определена в разделе 15 ПТ	Мониторинг производительности подсистемы.
  П. 4.1 ТЗ / П. 6.9	Обработка ошибок пользователей Подсистемой.	Задаются с клавиатуры и с помошью мыши.	Определена в разделе 15 ПТ	Обработка ошибок подсистемой.

  
  

  7.5.4 Таблица тестов

  См. Приложение. Табл. 7.1 Таблица тестов

  7.5.5 Отчет

  В результате проведенного тестирования выявились следующие ошибки:

  
  

  1) Некорректно отображение форматирования страниц подсистемы в интернет-обозревателе Opera. Данный дефект относится к категории «ошибки пользовательского интерфейса», сложность: низкая. На момент составления отчета дефект не исправлен.

  
  

  2) Возможность оптимизации исполняемого кода подсистемы. Данный дефект относится к категории «Дефекты программного кода», сложность: средняя. На момент составления отчета код частично оптимизирован, т.е. дефект можно считать исправленным.

  
  

  3) Отсутствуют обработчики некоторых ошибок. Например, ввод неправильного пути к графическому файлу при создании нового курса. Данный дефект относится к категории «Обработка ошибок пользователя», сложность: низкая. На момент составления отчета дефект исправлен.

  
  

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

  7.5.6 Проверочный лист (Checklist)

  Дата: 15.05.06

  Версия подсистемы: 1.5 beta

  
  

  № п.п.	Объект	Статус	Тестировщик
  1.1	Система установки подсистемы	Протестировано	** П.А.
  1.2	Система установки подсистемы на virgin-машину	Протестировано	** П.А.
  2.1	Проверка кода	Протестировано, возможна доп. оптимизация.	** П.А.
  3.1	Функция корректного отображения данных	Протестировано, есть ошибки	** П.А.
  3.2	Загрузка и повторная загрузка	Протестировано	** П.А.
  3.3	Регистрация нового курса (из меню администрирования, производиться тьютором).	Протестировано	** П.А.
  3.4	Регистрация нового курса (из меню администрирования, производиться тьютором).	Протестировано	** П.А.
  3.5	Удаление пользователя	Протестировано	** П.А.
  3.6	Редактирование данных курса	Протестировано	** П.А.
  3.7	Корректное определение доступа для пользователей	Протестировано	** П.А.
  4.1	Загрузка окна «Регистрация нового курса» (для администратора). Временные параметры.	Протестировано, время выполнения операции 0.4-0.87 сек.	** П.А.
  4.2	Загрузка главного окна подсистемы Временные параметры.	Протестировано, время выполнения операции 0.21-0.63 сек.	** П.А.
  4.3	Загрузка окна «Регистрация нового курса» (для студента) Временные параметры.	Протестировано, время выполнения операции 0.39-0.72 сек.	** П.А.
  4.4	Повторная загрузка главного окна подсистемы Временные параметры.	Протестировано, время выполнения операции 0.11-0.4 сек.	** П.А.
  4.5	Удаление курса Временные параметры.	Протестировано, время выполнения операции 0.67-1.14 сек.	** П.А.
  4.6	Редактирование данных курса. Временные параметры.	Протестировано, время выполнения операции 0.55-0.64 сек.	** П.А.
  5.1	Производительность. Работа 30 пользователей одновременно. Временные параметры.	Протестировано, время доступа к странице 0.97-4.3 сек.	** П.А.
  6.1	Обработка ошибок	Протестировано, отсутствуют обработчики некоторых ошибок.	** П.А.

  
  
  

  7.5.7 Код сценариев автоматизированного тестирования

  В приложении (См. Приложение, «Код сценариев автоматизированного тестирования») данной дипломной работы прилагается исходный текст Rational Robot – скриптов, реализующих несколько тестовых случаев.

  
  

  8. Организационно-экономическая часть

  8.1. Организация и планирование работ по теме

  Данная система создается с целью ускорить получение знаний путем автоматизации процесса обучения, сделать учебный процесс более организованным и надежным, а также для введения новых возможностей в преподавания. В качестве объектов автоматизируемой деятельности следует рассматривать организацию процесса обучения на отделении ** ОЛ *****. Ранее в процесс обучения использовалась обыкновенная почта, а доставка писем отнимает много времени и весьма ненадежна. В данный момент решено, что часть процесса обучения будет происходить посредством Всемирной Глобальной Сети Интернет, то есть будет разработана система обучения, использующая Интернет как платформу для взаимодействия ученика (Актора) и учителя (Тьютора).

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

  
  

  Основные задачи планирования:

  ·   взаимная увязка всех работ;

  ·   определение общего объема работ и необходимых для его выполнения трудовых, материальных и денежных ресурсов;

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

  При планировании комплекса задач по данной НИОКР используются календарные графики.

  
  

  Перед построением графиков определяются:

  ·   перечень основных работ;

  ·   исполнители работ;

  ·   трудоемкость работ;

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

  
  
  
  
  

  Таблица 8.1.1 Календарный график

  № работы	Наименование работы	Длитель-ность, дн.	Исполнитель, должность	кол-во чел.	Трудо- емкость, чел/дн.
  1	Разработка и утверждение технического задания	7	Руководитель проекта (начальник сектора)	3	21
  			Разработчик БД  (инж. 1 кат.)
  			Программист (инж. 1 кат.)
  2	Исследование предметной области	9	Разработчик БД  (инж. 1 кат.)	2	18
  			Программист (инж. 1 кат.)
  3	Создание программного продукта (ПП)	50	Разработчик БД  (инж. 1 кат.)	2	100
  			Программист (инж. 1 кат.)
  4	Испытание ПП	9	Разработчик БД  (инж. 1 кат.)	2	18
  			Программист (инж. 1 кат.)
  5	Внесение изменений	4	Разработчик БД  (инж. 1 кат.)	2	8
  			Программист (инж. 1 кат.)
  6	Сдача проекта	15	Руководитель проекта (начальник сектора)	3	45
  			Разработчик БД  (инж. 1 кат.)
  			Программист (инж. 1 кат.)
  Общая длительность НИОКР		94			210

  
  

  Работы	№
  	6
  	5
  	4
  	3
  	2
  	1
  	Дни	5	10	15	20	25	30	35	40	45	50	55	60		65	70	75	80	85	90	95

  
  

  Рис. 8.1.2 Ленточный график

  8.2 Состав, принимающий участие в работе

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

  
  

  o Руководитель проекта (Начальник сектора);

  o Разработчик базы данных (инженер 1 - категории)

  o Программист (инженер 1 - категории);

  
  

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

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

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

  8.3 Расчет договорной цены

  8.3.1. Материалы, покупные изделия

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

  Транспортно-заготовительные расходы ТР рассчитываются в размере 18% от стоимости материалов по формуле:

  ТР = 0,18 * М,

  где М - стоимость материалов и покупных изделий.

  Получаем:

  ТР = 0,18 * 2500 = 360 руб.

  Стоимость материалов с учетом транспортных расходов:

  СМ = 2500 + 360 = 2860 руб.

  
  

  Таблица 8.3.1

  №п/п	Наименование материала	Единица измерения	Количество	Цена за ед. в руб.	Сумма, руб
  1	Канцтовары	-	-	-	500
  2	Бумага для принтера	пачка	3	150	450
  3	Бумага для графических материалов	лист	12	10	120
  4	Диски CD-R 700 Мб	шт.	5	10	50
  5	Чёрный картридж для принтера	шт.	1	630	630
  6	Цветной картридж для принтера	шт.	1	750	750
  Итого:						2500
  7	Транспортно-заготовительные расходы	-	-	360	360
  Всего, с учетом транспортных расходов:					2860

  
  
  

  8.3.2. Основная заработная плата научного персонала

  № п/п	Должность	Месячный оклад, руб	Дневной оклад, руб
  1	Руководитель проекта (начальник сектора)	18000	818
  2	Разработчик базы данных (инженер 1- категории)	12000	545
  3	Программист (инженер 1- категории)	12000	545

  
  

  Таблица 8.3.2

  
  

  Расчет основной заработной платы представлен в таблице 8.3.3.

  № работы	Наименование работы	Длитель-ность, дн.	Исполнитель, должность	Мес. оклад, руб.	Стои-мость чел.-дня, руб.	Стои-мость работы, руб.
  1	Разработка и утверждение технического задания	7	Руководитель проекта (начальник сектора)	18000	818	5726
  			Разработчик БД  (инж. 1 кат.)	13000	545	3815
  			Программист (инж. 1 кат.)	13000	545	3815
  2	Исследование предметной области	10	Разработчик БД  (инж. 1 кат.)	13000	545	5450
  			Программист (инж. 1 кат.)	13000	545	5450
  3	Создание программного продукта (ПП)	35	Разработчик БД  (инж. 1 кат.)	13000	545	19075
  			Программист (инж. 1 кат.)	13000	545	19075
  4	Испытание ПП	10	Разработчик БД  (инж. 1 кат.)	13000	545	5450
  			Программист (инж. 1 кат.)	13000	545	5450
  5	Внесение изменений	5	Разработчик БД  (инж. 1 кат.)	13000	545	2725
  			Программист (инж. 1 кат.)	13000	545	2725
  6	Сдача проекта	10	Руководитель проекта (начальник сектора)	18000	818	8180
  			Разработчик БД  (инж. 1 кат.)	13000	545	5450
  			Программист (инж. 1 кат.)	13000	545	5450
  Общая сумма						97200

  
  

  Таблица 8.3.3

  
  

  8.3.3 Дополнительная заработная плата научного персонала

  Дополнительная заработная плата Д_ЗП составляет 25% от основной заработной платы:

  Д_ЗП = 0,25 * О_ЗП,

  где О_ЗП — основная заработная плата.

  Получаем:

  Д_ЗП = 0,25 * 97200= 24300 руб.

  
  

  8.3.4 Отчисления на социальные нужды

  Отчисления на социальные нужды составляют 26% от суммы основной и дополнительной заработной платы:

  ОСН = 0,26 * (О_ЗП + Д_ЗП)

  Получаем:

  ОСН = 0.26 * (97200+ 24300) =31590 руб.

   

  8.3.5 Накладные расходы

  Накладные расходы составляют 250% от основной заработной платы:

  НР = 2,5 * 97200 = 243000 руб.

   

   

  8.3.6 Прочие расходы

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

  При разработке экспертной системы использовался персональный компьютер инженера-программиста. Учитывая использование машины по 6 часов в течение 120 рабочих дней и исходя из цены 5 руб. за 1 час машинного времени, прочие расходы составляют:

  ПР = 6*120*5 = 3 600 руб.

   

  8.3.7 Стоимость

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

  С = СМ + О_ЗП + Д_ЗП + ОСН + НР + ПР =

  = 2860 + 97200 + 24300 + 31590 + 243000 + 3600 = 402 550 руб.

   

  8.3.8 Прибыль

  Прибыль определяется на уровне 30% от стоимости:

  Пр = 0,3 * С = 0,3 * 402 550 = 120 750 руб.

   

  8.3.9 Оптовая цена предприятия

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

  ОЦ = С + Пр = 402 550 +120 750 = 523 300 руб.

   

  8.3.10 Договорная цена

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

  ДЦ = ОЦ + НДС

  Разработка ведется на основании подписания хоз. договора. Так как выделенные средства выделяются из государственного бюджета, налог на добавленную стоимость не взимается, поэтому договорная цена совпадает с оптовой ценой предприятия и составляет 523 300 руб. Структура договорной цены на научно-техническую продукцию приведена на таблице 8.3.4

  
  

  № п/п	Наименование статей расхода	Затраты,  руб.
  1	Материалы, покупные изделия	2360
  2	Основная заработная плата исполнителей	97200
  3	Дополнительная заработная плата исполнителей	24300
  4	Единый социальный налог	31590
  5	Оплата работ, выполняемых сторонними организациями и предприятиями	-
  6	Командировочные расходы	-
  7	Накладные расходы	243000
  8	Прочие расходы	3 600
  9	Стоимость	402 550
  10	Прибыль	120 750
  11	Оптовая цена предприятия	523 300
  12	НДС	-
  13	Договорная цена	523 300

   

  Таблица 8.3.4

  8.4 Экономическая целесообразность темы

  При использовании СДО «*****» прогнозируется уменьшении времени ожидания ответа со стороны Тьютора при взаимодействии с Актором (увеличение динамичности обучения) при сохранении высокой надежности и защищенности как самой системы, так и данных ее данных.

  
  

  8.5 Заключение договора на создание научно-технической продукции

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

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

  Оказание услуг по договору осуществляется в соответствии с календарным планом (или ведомостью исполнения), в которых оговорены сроки выполнения определенных работ с указанием их стоимости, что является неотъемлемой частью договора. Календарный план (или ведомость исполнения) разрабатываются "Исполнителем" и согласовываются с "Заказчиком".

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

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

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

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

  
  
  
  
  
  
  

  8.6 Бизнес-план (основные разделы)

  8.6.1 Описание продукта или вида услуг

  Программная подсистема обеспечения учебно-методическим материалом СДО «*****» (ОЛ ***** при **).

  
  

  8.6.2 Оценка рынка сбыта продукта

  Данная программная компонента входит в состав СДО «*****», на настоящее время использующейся только в пределах одной организации (Отделение ** ОЛ ***** при **)

  8.6.3 Конкуренция

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

  8.6.4 Реклама

  Необходимость в рекламе может возникнуть только при использовании программного продукта вне пределов организации.

  
  

  8.6.5 План производства

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

  
  

  8.6.6 Организационный план

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

  8.6.7 Юридический план

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

  
  

  8.6.8 Финансовый план

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

  
  

  8.7 Выводы

  В данном разделе было представлено экономическое обоснование для разработки программной подсистемы обеспечения учебно-методическим материалом СДО «*****» (ОЛ ***** при **).

  Так же были рассмотрены следующие задачи планирования:

  взаимная увязка всех работ;

  определение общего объема работ и необходимых для его выполнения трудовых, материальных и денежных ресурсов;

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

  При планировании комплекса задач по данной НИОКР использовался календарный график.

  В виде заключения стоит отметить, что прибыль при успешном завершении разработки комплеска ПО составит 120 750 руб.

  
  

  8.8 Список литературы

  
  

           1. Практикум по организации и планированию машиностороительного производства. Производственный менеджмент. Уч. пособие под ред. Ю.В. Скворцова. –М.:Высш.Шк.,2004 г.;

           2. Методические указания по организационно-экономической части дипломного проектирования. Уч. пособие – М.: **, 1990.

  
  
  
  
  
  
  
  

  9. Охрана труда и экология

  9.1 Введение

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

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

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

  
  

  · оптимальное размещение оборудования, входящего в состав

  рабочего места;

  
  

  · рациональное использование пространства на рабочем месте;

  
  

  · необходимое естественное и искусственное освещение;

  
  

  · достаточная вентиляция рабочего места;

  
  

  · уровень акустического шума не должен превышать допустимого значения.

  
  

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

  К техническим средствам защиты от поражения электрическим током относятся следующие:

  - все рукоятки и тумблеры сделаны из изоляционных материалов или
  имеют непроводящее покрытие;

  - защитное заземление корпусов ПЭВМ. При этом соответствующий провод входит в конструкцию ПЭВМ.

  К организационным мерам защиты от поражения электрическим током относятся следующие меры:

  -вывешивание плакатов;

  -проверка отсутствия напряжения.

  
  

  Данный раздел дипломного проекта посвящен рассмотрению следующих вопросов:

  
  

  · организация рабочего места;

  · расчет вентиляции;

  · расчет освещения;

  · электробезопасность.

  
  

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

  
  

  Вид выполняемых работ:

  · непрерывная работа с ЭВМ, программирование;

  
  

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

  
  

  9.2 Организация рабочего места

  
  

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

  · оптимальное размещение оборудования, входящего в состав
  рабочего места;

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

  · необходимо естественное и искусственное освещение для
  выполнения поставленных задач;

  · уровень акустического шума не должен превышать допустимого
  значения;

  · достаточная вентиляция рабочего места.

  
  

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

  
  

  Главными элементами рабочего места программиста являются письменный стол и кресло. Основным рабочим положением является положение сидя.

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

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

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

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

  При проектировании письменного стола следует учитывать следующее:

  
  

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

  
  

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

  
  
  

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

  
  

  · конструкция стола должна предусматривать наличие выдви/( ящиков (не менее 3 для хранения документации, листингов, канцелярских принадлежностей, личных вещей).

  
  

  Высота рабочей поверхности рекомендуется в пределах 680-760 Высота рабочей поверхности, на которую устанавливается клавиатура, должна быть 650 мм.

  Большое значение придается характеристикам рабочего кресла. Так, рекомендуется высота сиденья над уровнем пола должна быть в пределах 420-550 мм. Поверхность сиденья рекомендуется делать мягкой, передний край закругленным, а угол наклона спинки рабочего кресла - регулируемым.

  Необходимо предусматривать при проектировании возможность различного размещения документов: сбоку от видеотерминала, между монитором и клавиатурой и т.п. Кроме того, в случаях, когда видеотерминал имеет низкое качество изображения, например заметны мелькания, расстояние от глаз до экрана делают больше (около 700 мм), чем расстояние от глаза до документа (300-450 мм). Вообще при высоком качестве изображения на видеотерминале расстояние от глаз пользователя до экрана, документа и клавиатуры может быть равным.

  Положение экрана определяется:

  - расстоянием считывания (0.60 + 0.10 м);

  - углом считывания, направлением взгляда на 20 ниже горизонтали к
  центру экрана, причем экран перпендикулярен этому направлению.

  Должна предусматриваться возможность регулирования экрана:

  - по высоте +3 см;

  - по наклону от 10 до 20 относительно вертикали;

  в левом и **м направлениях.

  Зрительный комфорт подчиняется двум основным требованиям:

  -        четкости на экране, клавиатуре и в документах;

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

  Большое значение также придается правильной позе рабочей пользователя. При неудобной рабочей позе могут появиться боли в мышцах, суставах и сухожилиях. Требования к рабочей позе пользователя видеотерминала следующие: шея не должна быть наклонена более чем на 2 (между осью "голова-шея" и осью туловища), плечи должны расслаблены, локти - находиться под углом 80° - 100° , а предплечья и кисти рук - в горизонтальном положении. Причина неправильной пользователей обусловлена следующими факторами: нет хорошей подставки для документов, клавиатура находится слишком высоко, а документы слишком низко, некуда положить руки и кисти, недостаточно пространство для ног. В целях преодоления указанных недостатков даются рекомендации: лучше передвижная клавиатура, чем встроенная; должны быть предусмотрены специальные приспособления для регулирования высс стола, клавиатуры, документов и экрана, а также подставка для рук.

  
  

  Характеристики используемого рабочего места:

  -высота рабочей поверхности стола 750 мм;

  -высота пространства для ног 650 мм;

  -высота сиденья над уровнем пола 450 мм;

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

  -предусмотрена возможность размещения документов справа и слева;

  -расстояние от глаза до экрана 700 мм;

  -расстояние от глаза до клавиатуры 400 мм;

  -расстояние от глаза до документов 500 мм;

  -возможно регулирование экрана по высоте, по наклону, в левом и в
  **м направлениях;

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

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

  
  

  9.3 Расчет оптимального освещения

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

  Потребный световой поток ламп в каждом светильнике находится по формуле:

  Фл=

  Ен = 300 лк - нормируемое значение освещённости на рабочем месте - из [4];

  Кз = 1,5 из [2] - коэффициент запаса, учитывающий снижение освещённости в процессе эксплуатации за счёт загрязнения ламп и светильников (для помещений с низким количеством выделения пыли);

  S = 40 кв. м - освещаемая площадь;

  Z=1,1 из [2] - отношение средней освещённости к минимальной;

  n - число светильников;

  Uoy - коэффициент использования светового потока в долях единицы (отношение светового потока, падающего на расчётную поверхность, к суммарному потоку всех ламп). Uoy зависит от индекса помещения iп и коэффициентов отражения: от потолка

  Iп=

  (рп); стен (рс); расчётной поверхности (рр). Где:

  h- высота подвеса светильника над рабочей поверхностью;

  h = Н - hр - hс,

   Н = 4 м - высота помещения;

   hр = 0,8 м - высота рабочей поверхности от пола;

   hс = 0,2 м - расстояние от светильников до перекрытия;

   т.е. h = 4-0,8-0,2 = З м;

  А = 8 м - длина помещения;

   В = 5 м - ширина помещения;

   S = 40 кв. м - освещаемая площадь.

   Т.е. iп==1.5

  Для: рп = 0,7 (побелённый потолок);

  рс = 0,5 (побелённые стены при незанавешенных окнах);

  рр = 0,1 (расчётная поверхность тёмного цвета);

  (данные из таблицы 6.3 [2])

  iп=1,5

   из таблицы 6.4 [2] находим Uoy= 0,54, для светильника типа : ЛВООЗ - 2 х 40 - 001

   При расчёте люминесцентного освещения чаще всего первоначально намечается число рядов светильников М, которое подставляется в формулу для расчёта Фл вместо n. Тогда под Фл следует подразумевать световой поток светильников одного ряда.

   Рекомендуемое отношение расстояния между светильниками (L) к расчётной высоте (h) не должно превышать 0,6 - из [1], т.е. L = 1,8 м

  Тогда число рядов светильников (М) можно получить из следующего уравнения:

  M =

   Где:

  В = 5 м - ширина помещения;

  т.е. M= = 1,97.

   Примем M = 2, тогда:

  Фл ===17679 лм

  Число светильников в ряду определяется как: n =,где:

  Фл = 17679 лм - световой поток светильников одного ряда;

  Ф1 - световой поток одного светильника.

  Для определения Ф1 необходимо выбрать светильник.

  В качестве светильников освещения выбрал светильник:

  ЛВООЗ-2x40-001.

  В этом светильнике применяются две лампы ЛБ - 40 со световым потоком 3200 лм каждая, таким образом, суммарный световой поток выбранного светильника составит: Ф1=6400 лм.

  Габаритные размеры светильника (мм): 1275x310x115.

  Тогда число светильников в ряду составит:

   n= = 3.

  Суммарная длина светильников меньше длины помещения, поэтому применяется ряд с равномерно распределёнными вдоль него разрывами между светильниками.

   Определение коэффициента пульсации светового потока

  Максимально допустимое значение коэффициента пульсации светового потока при работе с дисплеями и видеотерминалами не должно превышать 10%.

  Такой коэффициент пульсации можно обеспечить при включении половины ламп в светильнике по схеме опережающего и половины - по схеме отстающего тока –из таблицы.9.17. (1).

  
  

  .

  Рис.8.1. Схема включения ..

  
  

  Расчёт показателя дискомфорта

  В соответствии с СанПиН 222-542-96 [1] показатель дискомфорта (М) не должен превышать 40%.

  Применяемый светильник относится к группе Iе - из таблицы 8.6 [2]. Зная группу, к которой относится выбранный светильник, при рс = 0.5 и рр = 0,1, определяем индекс помещения iм, при котором обеспечивается нормируемый максимально допустимый показатель дискомфорта (М).

  Из таблицы 8.7 [2] находим: iм = 2,5.

  Сравнивая iм с iп определяем соответствие требованиям по дискомфорту осветительной установки. Требования выполняются при соблюдении условия: iп < iм.

  В нашем случае iп = 1,5, т.е. условие выполняется, и выбранная осветительная установка соответствует требованиям по дискомфорту.

  • Расчёт размещения светильников

  Расстояние между рядами светильников L было определено ранее (L=1,8 м).

  Расстояние от светильника до стены А:

  = =1,6м

  Определим расстояние между светильниками 1 в одном ряду из уравнения:

  А = 3 • Iсв + 2 • I + 2 • 0,4 • I, где:

  А = 8 м - длина помещения;

  Iсв = 1,275 м - длина светильника.

  8 = 3 • 1,275+ 2-1 + 2-0,4-1,

  т.е. 1= 1,49м.

  Расстояние от светильника до стены В:

  0,4*I = 0,4* 1,49 = 0,6м

  Размещение светильников смотри на рисунке .

  :

  Рис.8.2. Размещение светильников.

  
  

  9.4 Расчет оптимальной вентиляции

  9.4.1 Расчёты выделения вредных веществ и влаги

  Влаговыделение

  Количество влаги, выделяемое людьми г/ч, определяется по формуле:

  W=n*, где:

  n = 4 - число людей находящихся в помещении;

   = 80 г/ч - количество влаги, выделяемое одним человеком при температуре в рабочей зоне равной 24 С°— из таблицы 1 [5], получено методом интерполяции.

  W= 4 • 80 = 320 г/ч.

  • Газовыделение

  Количество двуокиси углерода, содержащегося в выдыхаемом человеком воздухе, определяется по таблице 5 [5].

  При умственном характере выполняемой работы массовый расход двуокиси углерода СО2 одним человеком составляет 45 г/ч, т.к. в лаборатории находятся 4 человека, то общее количество выделяемого СO2 составит 180 г/ч.

  
  

  9.4.2 Расчёты выделений тепла

  
  

  Тепловыделение от людей

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

  При умственной работе, температуре окружающего воздуха 24 град и скорости движения воздуха не более 0,2 м/с количество тепла, выделяемое одним человеком, составит 80 Вт - из таблицы 1 [5]. Для 4 человек суммарное выделение тепла составит:

  320 Вт. (4*80=320 Вт.)

  •Теплопоступления от солнечной радиации

  Расчёт тепла поступающего в помещение от солнечной радиации через остекление производится по следующей формуле:

  Qост= Fост • qост • Аост, где:

   Fост = 10 кв. м - площадь поверхности остекления;

  qост =185 Вт/кв. м - удельное тепловыделение от солнечной радиации при юго-западной ориентации остекления (окна с двойным остеклением с металлическими переплётами) и географической широте 55 град - из таблицы 8 [5].

  Аост = 0,8 - коэффициент учёта характера остекления (обычное загрязнение) - из таблицы 8 [5].

  Qост =10* 185*0.8 = 1480 Вт

  •Тепловыделение от источников искусственного освещения и устройств вычислительной техники

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

  Q= N* *1000, где:

  N = 0,48 кВт - суммарная мощность источников искусственного освещения;

    = 0,55 - коэффициент тепловых потерь для газоразрядных ламп.

   Qосв= 0,48 • 0,55 • 1000 = 264 Вт.

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

  Q=N**1000, где:

  N = 0,24 кВт - суммарная мощность устройств вычислительной техники (системный блок + монитор + осциллограф) - испытание и наладка на рабочем месте производится с помощью ЭВМ и прикладных программ.;

    = 0,6 - коэффициент тепловых потерь для устройств вычислительной техники.

  Qвыч.тех. = 0,24 • 0,6 • 1000 = 144 Вт.

  
  

  9.4.3 Определение оптимального режима воздухообмена

  
  

  -Потребный воздухообмен при поступлении вредных веществ в воздух рабочей зоны

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

  G= , где:

  В = 180 г/ч - количество вредных веществ выделяющихся в помещении за 1 час; К=1.7;

  q2 = 30 г/м³ - концентрация двуокиси углерода в удаляемом воздухе, принимается равной предельно допустимой - из [6];

  q1 = 9 г/м³ - концентрация двуокиси углерода в приточном воздухе, составляет 30% от

  G== 14.6 куб.м/ч

  ПДК.

   •Воздухообмен, обеспечивающий удаление избытков тепла

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

  
  

  где:

  Q – теплоизбытки ;

  Ср=10і Дж/кг*град - массовая удельная теплоёмкость воздуха [4].

  Q= Qост + Qосв + Qвыч.тех. = 1480 + 264 + 144 = 1888 Вт,

  р = 1,2 кг/куб. м - плотность приточного воздуха;

  tуд - tр.з. + а(Н - 2),

  tр.з. = 24 град - температура в рабочей зоне [4];

  
  

  а = 1,2 град/м - нарастание температуры на каждый метр высоты [4];

  tyд=24 +1.2*(3 - 2) = 25.2 градC°.

   Н = 3 м - высота от пола до вытяжного отверстия.

  tпр = 22,3 градC°- температура приточного воздуха. СПиН-11-33-75 [6] Определение потребного воздухообмена для удаления избытка влаги

  G=

  G= =1930 куб.м/ч

  G=

  Расчёт расхода воздуха G, ведётся по следующей формуле:

  где:

  W = 320 г/ч - количество водяного пара выделяющегося в помещении;

  р = 1,2 кг/куб. м - плотность приточного воздуха;

  dв = 12 г/кг - влагосодержание вытяжного воздуха при tв = 25,2 С° и относительной влажности 60%; диаграмма рисунка 1 [5]

  dп = 7 г/кг - влагосодержание приточного воздуха при tп = 22,3 С° и относительной влажности 40%;

  (dв и dп определяются по i-d диаграмме - рисунок 1 [5])

  G==53 куб.м/ч

  9.4.4 Расчёт оптимальной вентиляции

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

  При тепловой аэрации движение воздуха осуществляется под действием разности давлений наружного и внутреннего воздуха за счёт разности температур вне и внутри помещения.

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

  Конструктивные характеристики вентиляционных проёмов:

  Фрамуги верхнего яруса вытяжных проёмов имеют среднеподвесные створки с углом открытия 60 градусов. Фрамуги нижнего яруса проточных проёмов имеют верхнеподвесные створки с углом открытия 45 градусов.

  Схема тепловой аэрации помещения представлена на рисунке 2.

  Воздух может входить и выходить из помещения через отверстия в плоскостях 1-1 и 2-2.

  Температура воздуха внутри помещения в плоскости 1-1 (приточных проёмов) равна температуре рабочей зоны (tв =tр.з. = 24 град).

  Температура воздуха внутри помещения в плоскости 2-2 (вытяжных проёмов) 1в2

  равна:

  tв2 = tрз + t*(Н - 2), где:

  tр.з. = 24 град - температура воздуха в рабочей зоне;

   t = 1,2 град/м - температурный градиент [4];

  Н = 3 м - высота расположения центра вытяжных проёмов над полом помещения.

  tв2 = 24 + 1.2 • (3 - 2) = 25,2 град.

  Определяем плотности наружного рн и внутреннего рв воздуха в плоскостях 1-1 и 2-2

  р= 

   273 + 1 (рв1 и рв2) по формуле:

  Плотность наружного воздуха (рн):

  Рh==1.2 кг/куб.м

  Плотность внутреннего воздуха в плоскости 1-1 (рв1):

  Рв1==1.19 кг/куб.м

  Плотность внутреннего воздуха в плоскости 2-2 (рв2):

  рв2==1.18 кг/куб.м

  •Определяется разность давлений на уровне приточных и вытяжных проёмов снаружи и внутри помещения:

  В плоскости приточных проёмов:

   Р1 =g-h1 • (рн-рв1)

  В плоскости вытяжных проёмов:

   Р2 = g • h2 • (рн - рв2), где: ;

  g = 9,8 м/кв. с - ускорение свободного падения;

  h1= 1,1 м;

  h2 = 1.4 м - см. рисунок 2;

  рн = 1,2 кг/куб. м - плотность наружного воздуха;

  рв1 = 1,19 кг/куб. м - плотность внутреннего воздуха в плоскости 1-1;

  рв2 = 1,18 кг/куб. м - плотность внутреннего воздуха в плоскости 2-2;

    Р1 = 9,8 • 1,1 • (1,2 - 1,19) = 0,108 Па,

    Р2 = 9,8 • 1,4 • (1,2 - 1,18) = 0,274 Па.

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

   Р = Р2- Р1,

   Р = 0,274-0,108 = 0,166Па.

  •Минимальное значение площади приточного проёма:

  F1= G/3600* пр*рв1/ Р1

  где:

  G = 1930 куб.м/ч - наибольший потребный воздухообмен;

  пр = 3,7 - коэффициент местного сопротивления приточных проёмов;

  рв1 = 1,19 кг/куб. м - плотность внутреннего воздуха в плоскости 1-1;

   Р1 =0,108 Па - разность давлений на уровне приточных проёмов снаружи и внутри помещения:

  F1=1930/3600* 3.7*1.19/0.108=3.4 кв.м

  •Минимальное значение площади вытяжного проёма:

  F2= G/3600* выт*рв2* Р2

  F2=1930/3600* 3.2*1.18/0.274=2 кв. м

  где:

  G = 1930 куб. м/ч - наибольший потребный воздухообмен;

  выт = 3,2 - коэффициент местного сопротивления вытяжных проёмов;

   рв2 =1,18 кг/куб. м - плотность внутреннего воздуха в плоскости 2-2;

   Р2 = 0,274 Па - разность давлений на уровне вытяжных проёмов снаружи и внутри помещения:

  F2=1930/3600 *3.2*1.18/0.274=2 куб.м.

  Рис.9.4.4 Разность давлений

  
  

  9.5 Электробезопасность и расчёт заземляющего устройства

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

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

  В установках напряжением до 1000В с глухозаземлённой нейтралью сопротивление заземляющего устройства, используемого для заземления электрооборудования, должно быть не более 4 Ом.

  Необходимо рассчитать заземляющее устройство выполненное из горизонтальных электродов (прямоугольная стальная полоса сечением 4x60=240 мм²) с глубиной заложения t=2 м (для исключения промерзания в зимнее время). Приближённое значение удельного сопротивления грунта по табл. 6-4 r=20 Ом×м.

  По**чный коэффициент с учётом климатического района согласно табл. 6-5 к=2,2.

  Длину полосы определим для сопротивления растекания из уравнения

  
  

  где r_расч.=kp=2,2-20=44 Ом×м.

  Задаваясь длиной полосы /=5 м; шириной полосы b=0,06 м; глубиной заложения t=2 м, получим R₃=10,27 Ом

  Для получения сопротивления менее 4 Ом соединим 3 полосы длиной по 5 м в параллель. При этом получим R₃=10,27/3=3,42 Ом.

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

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

  ПУЭ требует чтобы ток однофазного замыкания на корпус не менее чем в 3 раза превосходил номинальный ток плавкой вставки ближайшего предохранителя; не менее чем в 3 раза ток установки расцепителя автоматического выключателя, имеющего обратно зависимую от тока характеристику; не менее чем в 1,1 К_р раза ток мгновенного срабатывания автомата, имеющего только расцепитель без выдержки времени (К_р - коэффициент, учитывающий разброс токов срабатывания). При отсутствии заводских данных о величине разброса кратность тока К.З. относительно величины уставки следует принимать 1,4 для автоматов до 100 А и 1,25 для автоматов с номинальным током 100 А.

  
  

  9.5.1 Защитное отключение в функции тока (ЗОТ)

  
  

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

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

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

  
  

  Рисунок 9.5.1 – Защитное отключение в функции тока.

  
  

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

  
  

  9.6 Выводы

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

  9.7 Список литературы

  
  

  1.Айзенберг Ю.Б. и др. “С**чная книга по светотехнике” - М.: Энергоатомиздат , 1983 г.

  2.Кнорринг Г.М. и др. “С**чная книга для проектирования электрического освещения” – СПб.:Энергоатомиздат,1992 г.

  3. Санитарные нормы и правила 2-4-79. “Нормы проектирования. Естественное и искусственное освещение” – М.: Стройиздат. 1980 г.

  4.Самгин Э.Б. “Освещение рабочих мест” – М.:** ,1989 г.

  5.Санитарные правила и нормы 2.2.2.542-96. “Гигиенические требования к видеодисплейным терминалам, персональным электронно-вычислительным машинам и организации работы” – М .: Стройштад , 1996 г.

  6.Розанов В.С., Рязанов А.В. “Обеспечение оптимальных параметров воздушной среды в рабочей зоне”.- М.:**, 1998г.

  7.Санитарные правила и нормы П.04.91. “Отопление, вентиляция, кондиционирование”. - М.: Стройиздат,1991г.

  8.Богословский В.Н., Щеглов В.П., Разумов Н.Н. “Отопление и вентиляция”. – М.: Стройиздат, 1980 г.

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

  Заключение

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

  В данный момент все подсистемы, полностью покрывающие по функционалу требования заказчика, созданы, протестированы и проинтегрированы в единый программный комплекс СДО «*****».  Работа над системой дистанционного обучения велась около 3х лет. Выход на проектную загруку состоялся через год после начала реализации системы.

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

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

  
  

  Список литературы

  1. Андрианова Е.Г., Григорьев В.К. Ткаченко В.М. Реинжиниринговый подход при проектировании методики подготовки тьютора для дистанционной формы обучения. Сборник научных трудов IV международного симпозиума, М: Информационно-издательский центр Всемирного технологического университета, 2003

  2. Андрианова Е.Г., Ткаченко В.М. Подход к реинжинирингу информационной системы дистанционного обучения на базе репозитария многократно используемых компонент программного обеспечения и унифицированных учебных процессов. Сборник научных трудов. М.: ФГУП НИИ "Восход", ч.1, **, 2006г.

  3. Андрианова Е.Г., Чаплыгин А.Н. Повышение качества обучения за счет применения концепций CRM и социальных сетей при организации дистанционного учебного процесса. Сборник Трудов. 55 НТК **, ч.4,М.: 2006

  4. Федотова Д.Э., Семенов Ю.Д., Чижик К.Н. Case-технологии. Практикум. – М.: Горячая линия–Телеком, 2003. – 160с.

  5. Андреев А.А. Компьютерные сети в учебном процессе Вузов Материалы 18 научно-методической конференции “Организация и проведение образовательного процесса при обучении по новым учебным планам и программам” 26-28 ноября, 1996 г., г. Казань.

  6. ** П.А. Защита базы данных системы дистанционного обучения «*****». Материалы 55 НТК **. –М : 2006г.

  7. Андреев А.А. Обзор телекоммуникаций в образовании. Публикация в сети ИНТЕРНЕТ на сервере Центра информатизации Минобразования ИНФОРМИКА. #"_Ref135304039">49. Кнорринг Г.М. Осветительные установки. – Л.: Энергоиздат. Ленингр. отделение, 1981. – 288с.

  50. Розанов В.С., Рязанов А.В. Обеспечение оптимальных параметров воздушной среды в рабочей зоне: Учебное пособие – М.: **, 1998. – 44с.

  51. Самгин Э.Б. Освещение рабочих мест. Текст лекций. – М.: **, 1989.

  52. Санитарно-эпидемиологические правила и нормативы СанПиН 2.2.2/2.4.1340-03 "Гигиенические требования к персональным электронно-вычислительным машинам и организации работы" (утв. Главным государственным санитарным врачом РФ 30 мая 2003 г.)

  53. Практикум по организации и планированию машиностороительного производства. Производственный менеджмент. Уч. пособие под ред. Ю.В. Скворцова. –М.:Высш.Шк.,2004 г.;

  54. Методические указания по организационно-экономической части дипломного проектирования. Уч. пособие – М.: **, 1990.

  Приложения

   Матрица доступа пользователей СДО

  Зоны доступа	Полномочия	Роли
  		Учащийся	Тьютор	Админист-ратор
  Неавтори-зованный пользова-тель	Зарегистрироваться	Да	Да	Да
  	Авторизовать пользователя	Нет	Нет	Да
  	Создать \ редактировать \ удалить учетную запись пользователя	Нет	Нет	Нет
  	Создать УММ	Нет	Нет	Нет
  	Редактировать УММ	Нет	Нет	Нет
  	Удалить УММ	Нет	Нет	Нет
  	Создать \ редактировать \ удалить тест \ вопрос к курсу	Нет	Нет	Нет
  	Предоставить права доступа к УММ	Нет	Нет	Нет
  	Просмотреть УММ	Нет	Нет	Нет
  	Сгенерировать отчет	Нет	Нет	Нет
  Автори-зованный пользова-тель	Создать \ редактировать \ удалить учетную запись пользователя	Нет	Нет	Да
  	Создать УММ	Нет	Да	Да
  	Редактировать УММ	Нет	Да	Да
  	Удалить УММ	Нет	Да	Нет
  	Создать \ редактировать \ удалить тест \ вопрос к курсу	Нет	Да	Нет
  	Предоставить права доступа к УММ	Нет	Да	Да
  	Просмотреть УММ	Да	Да	Да
  	Сгенерировать отчет	Нет	Да	Да

  Код сценариев автоматизированного тестирования

  Загрузка клиентом главной страницы Подсистемы в различных типах браузеров (Internet Explorer/Mozilla Firefox/Nescape Navigator/Opera). (ТС5131_1)

  Sub Main

      Dim Result As Integer

  
  

      'Initially Recorded: 22.05.2006  1:03:28

      'Script Name: test1

     

      'Запуск браузера Internet Explorer

      Window SetContext, "Class=Shell_TrayWnd", ""

      Toolbar Click, "Text=Quick Launch;\;ItemText=Запустить обозреватель Internet Explorer",          "Coords=10,12"

     

      Window SetContext, "Caption=about:blank - Microsoft Internet Explorer", ""

      ComboEditBox Click, "ObjectIndex=4", "Coords=149,5"

      InputKeys "www.**-ru.org{ENTER}"

      Window CloseWin, "", ""

     

      'Запуск браузера Mozilla Firefox

      Window SetContext, "Class=Shell_TrayWnd", ""

      Toolbar Click, "Text=Quick Launch;\;ItemText=Mozilla Firefox", "Coords=10,5"

     

      Window SetContext, "Caption=Mozilla Firefox", ""

      InputKeys "www.org{ENTER}"

      Window CloseWin, "", ""

  
  

      'Запуск браузера Netscape Navigator

      Window SetContext, "Class=Shell_TrayWnd", ""

      Toolbar Click, "Text=Quick Launch;\;ItemText=Netscape Navigator", "Coords=10,5"

     

      Window SetContext, "Caption=Netscape Navigator 8.0.4", ""

      InputKeys "www.**-ru.org{ENTER}"

      Window CloseWin, "", ""

     

      'Запуск браузера Opera

      Window SetContext, "Class=Shell_TrayWnd", ""

      Toolbar Click, "Text=Quick Launch;\;ItemText=Opera", "Coords=10,5"

     

      Window SetContext, "Caption=Îpera 8", ""

      InputKeys "www.**-ru.org{ENTER}"

      Window CloseWin, "", ""

  End Sub

  
  

  Удаление курса из БД подсистемы. (ТС5131_5)

  Sub Main

      Dim Result As Integer

  
  

      'Initially Recorded: 10.05.2006  1:11:36

      'Script Name: test2

      StartBrowser "www.**-ru.org", "WindowTag=Begining"

     

      'Вход в подсистему под учетной записью администратора.

      Window SetContext, "WindowTag=Begining", ""

      Window WMaximize, "", ""

      Browser NewPage,"HTMLTitle= Заочная школа.**.Нравственность .Закон;Index=0",""

      EditBox Click, "Name=user", "Coords=54,15"

      InputKeys "zarembo{TAB}"

      InputEncKeys "CQAALAAANb1NUw0="

      PushButton Click, "HTMLText=Вход"

      Browser NewPage,"HTMLTitle= Заочная школа.**.Нравственность .Закон;Index=0",""

      HTMLLink Click, "HTMLText=Просмотр", ""

      Browser NewPage,"HTMLTitle= Заочная школа.**.Нравственность .Закон;Index=0",""

      'Удаление 2-х тестовых записей

      CheckBox Click, "Name=del117"

      CheckBox Click, "Name=del113"

      PushButton Click, "HTMLText=Выполнить"

      Browser NewPage,"HTMLTitle= Заочная школа.**.Нравственность .Закон;Index=0",""

      HTMLLink Click, "HTMLText=Выход из системы.", ""

  
  

  End Sub

  Регистрация нового курса (из меню администрирования, производиться тьютором). (ТС5131_6_3)

  Sub Main

      Dim Result,x As Integer

  
  

      'Initially Recorded: 10.05.2006  22:52:57

      'Script Name: test3

     

       StartTimer "timer1"

       

       ' время загрузки окна при наличии множества других окон броузера

       For x=1 to 10 step 1

           StartBrowser "www.**-ru.org", "WindowTag=Begining"

           Window SetContext, "WindowTag=Begining", ""

      Next x

     

      Window SetContext, "Caption= Заочная школа.**.Нравственность .- Internet Explorer", ""

      InputKeys "^p"

    

      ' время загрузки окна на фоне печати текстового файла на принтере.

      Window SetContext, "Caption=ОК", ""

      PushButton Click, "Text=Печать"

     

      StartBrowser "www.**-ru.org", "WindowTag=Begining"

      Window SetContext, "WindowTag=Begining", ""

       DelayFor (1000)  

      Window WMaximize, "", ""

      DelayFor (1000)

      ‘Регистрация нового пользователя

      Browser NewPage,"HTMLTitle=Заочная школа.**.Нравственность .Закон;Index=0",""

      HTMLLink Click, "HTMLText=Регистрация", ""

      DelayFor (1000)

      Browser NewPage,"HTMLTitle= Заочная школа.**.Нравственность.Закон;Index=0",""

      EditBox Click, "Name=course_name", "Coords=24,13"

      InputKeys "testt"

      DelayFor (1000)

      EditBox Click, "Name=path1", "Coords=24,9"

      InputKeys "test"

      DelayFor (1000)

      EditBox Click, "Name=path2", "Coords=28,18"

      InputKeys "test"

      DelayFor (1000)

      EditBox Click, "Name=path3", "Coords=28,6"

      InputKeys "test@test.ru"

      DelayFor (1000)

      EditBox Click, "Name=course_name", "Coords=35,24"

      InputKeys "test"

      DelayFor (1000)

      EditBox Click, "Name=author", "Coords=33,7"

      ComboBox Click, "Name=type", ""

      ComboListBox Click, "Name=type", "Text=Студент"

      PushButton Click, "HTMLText=ÎÊ"

      DelayFor (1000)

      Browser NewPage,"HTMLTitle= Заочная школа.**.Нравственность.Закон;Index=0",""

      HTMLLink Click, "HTMLText=Назад", ""

      DelayFor (1000)

      'Заход на страницу администратора для проверки создания пользователя

      Browser NewPage,"HTMLTitle= Заочная школа.**.Нравственность.Закон;Index=0",""

      EditBox Click, "Name=user", "Coords=66,4"

      DelayFor (1000)

      InputKeys "zarembo{TAB}"

      InputEncKeys "CQAAAAAANoP1NUw0="

      DelayFor (1000)

      PushButton Click, "HTMLText=Вход"

      Browser NewPage,"HTMLTitle= Заочная школа.**.Нравственность.Закон;Index=0",""

      HTMLLink Click, "HTMLText=Просмотр", ""

      DelayFor (1000)

      'Имя последнего зарегистировавшегося сверяется с эталонным  результатом

      Browser NewPage,"HTMLTitle= Заочная школа.**.Нравственность.Закон;Index=0",""

      Result = HTMLLinkVP (CompareData, "HTMLText=testt test test", "VP=Object Data")

      DelayFor (1000)

  
  

  End Sub

  
  
  
  
  
  

  Листинг исходных кодов подсистемы выдачи УММ

  Модуль просмотра пользователей системы

  <?

  include("data.php");

  include("session.php");

  
  

  ?>

  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

  <html>

  <head>

  <meta http-equiv="Content-Type" content="text/html; charset=windows-1251">

  <meta name="keywords" ; content=", заочная,  отеделение **,всероссийская заочная многомпредметная школа,отделение *****, *****,заочное обучение, заочное, дистанционное обучение, **, права человека, граждановедение, гражданское общество,гражданское самосознание, гражданин, компетентность граждан, нравстенность, закон, свод законов.">

  <meta name="robots" ; content="ALL">

  <meta name="description" ; content="Изучение права в теоретическом виде не только может быть скучно, но и принципиально неверно. Нельзя искусственно вырывать их из жизни, из истории человечества и гражданского общества.Необходимо хотя бы коротко рассказать, как, при каких обстоятельствах и почему они возникли. Значит придется говорить о том, что такое **, ЗАКОН, ГОСУДАРСТВО и ДЕМОКРАТИЯ, о ее становлении и многом еще. А как защитить свои права и права окружающих, как не поддаться на демагогию и обман? И более того, как занять активную позицию в общественной жизни, как отличить правду от лжи?Все это входит в понятие компетентность граждан. То есть, мы будем говорить об основах того, что называется ГРАЖДАНОВЕДЕНИЕ.">

  <title>Заочная школа. **. Нравственность.Закон</title>

  <link rel="Stylesheet" href="index/index.css" type="text/css">

  <SCRIPT LANGUAGE="JavaScript">

  function new_course()

  {

  window.open('new_course.htm','newwin','top=15, left=20, menubar=0, toolbar=0, location=0, directories=0, status=0, scrollbars=0, resizable=0,, height=400');

  }

  </SCRIPT>

  </head>

  <body>

  
  

  <table>

  <tr><td colspan=3>

  <tr><td bgcolor=white align=center valign=top>

  <table cellpadding=10 cellspacing=0>

  <tr><td><script src="index/menu_.js"></script>

  <? include("menu.php")?>

  </td></tr>

  </table>

  </td>

  <td></td>

  <td valign=top bgcolor=#452929>

  <table>

  <tr height=20><td colspan=2 align="center"><br><font size="4" color="red">ВНИМАНИЕ!</font><a href="javascript:new_course()"> > Появился новый курс < </a></td></tr>

  <tr><td>&nbsp;&nbsp;&nbsp;<img src="index/index.jpg"></td><td>

  <p><b>(ОЛ *****)</b>

  Российской академии образования, работающий при Московском университете им.

  Ломоносова, начал свою деятельность в 1964 году как Республиканская заочная

  математическая школа.</td></tr>

  <tr><td colspan=2><p>Лицей был создан по инициативе двух выдающихся

  отечественных математиков, академиков И.Г. Петровского (в то время Ректора

  **) и И.М. Гельфанда, а так же заместителя министра просвещения РСФСР

  М.П.Кашина, и вначале проводил обучение только по математике.

  <p>

  В настоящее время <b>ОЛ *****</b> насчитывает в своем составе 8 учебных отделений:

  <i><a href="#"_Toc159573844">Публикация

  Преимущества методологии RUP при разработке и внедрении подсистемы выдачи учебного материала

   СДО «*****»

  
  
  

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

  
  

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

  
  

  Вслед за западными коллегами, российские компании-разработчики переходят на промышленный уровень создания программ, используя строго упорядоченные, логически выверенные концепции и методологии разработки программного продукта. Одной из наиболее широко используемых методологий разработки программных продуктов является Унифицированный процесс (Rational Unified Process - RUP) и поддерживающие его программные средства, разработанные компанией IBM. Основные этапы разработки программных продуктов по технологии RUP приведены на рис. 1.

  
  

  Рис. 1. Основные этапы разработки программных продуктов

               по методологии RUP.

  
  

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

  
  

  Данная методология была принята за базовую при создании программного комплекса системы дистанционного обучения (СДО) «*****». Приведем основные характеристики системы: база данных СДО «*****»: MySQL, реализована на языке программирования PHP 4.3.11(некоторые функции на HTML 4.0, общее количество страниц: 70, среднее время доступа к странице: 0.74 сек., максимальное число пользователей: 50 без изменения времени доступа к странице.

  
  

  Для иллюстрации преимуществ технологии RUP рассмотрим подробно процесс разработки подсистемы выдачи слушателям методического материала, являющуюся частью СДО «*****». Создание прототипа подсистемы заняло около года. В процессе разработки выделим следующие этапы:

  1. Составление списка требований, их последующий анализ

  2. Создание, согласование и утверждение ТЗ на разработку подсистемы

  3. Выбор архитектуры (серверное ПО, база данных, язык программирования)

  4. Создание моделей подсистем, а также моделирование всех внутренних процессов и потоков данных

  5. Создание кода

  6. Тестирование подсистемы

  7. Сборка и развертка подсистем

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

  
  

  Процесс создания сопроводительной документации в RUP также автоматизирован. Достаточно добавить в UML-диаграмму текстовое описание пользователей, объектов, их функций, и возможна автоматическая генерация текстового документа по этим данным. Описанная возможность позволила в сжатые сроки разработать и полностью согласовать за один месяц ТЗ на разработку подсистемы.

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

           В нашем проекте дополнительно была добавлен еще один профиль - специалиста по безопасности системы, при этом автоматически (при помощи встраиваемого модуля (plug-in) компании-партнера IBM по безопасности) были встроены в существующий интерфейс RUP, соответствующие дополнительные функции, артефакты, действия и роли. Что позволило структурировать и активизировать работу по повышению уровня безопасности информации и процессов подсистемы выдачи учебного материала.

           Современный программный продукт должен быть не только функциональным, удобным в использовании и не слишком требовательным к ресурсам, он, несомненно, должен быть качественным. Сегодня понятие качество рассматривается как многомерный объект. Для заказчика качество означает выполнение всех необходимых функций, удобство использования, в то время как для IT-отдела, обслуживающего данный программный продукт, более принципиальным вопросом будет простота поддержки, обновления и изменения компонентов программы. С точки зрения RUP, качество оценивается по технологии FURPS+, разработанной одним из создателей RUP, Робертом Грейди. Аббревиатура «FURPS+» расшифровывается как: Functionality, Usability, Reliability, Performance, Supportability, + (and others), то есть Функциональность, Удобство использования, Надежность, Производительность, Поддержка и другие.

  В нашем случае качество подсистемы выдачи учебного материала оценивалось по следующим параметрам:

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

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

  ·   надежность - подсистема прошла проверку на устойчивость к сбоям в процессе эксплуатации. Также при помощи другого продукта семейства Rational (Rational Robot – тестировочный робот) путем нагрузочного тестирования было выявлено, что СДО «*****» одновременно может пользоваться до 50 пользователей без увеличения времени доступа к страницам СДО.

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

  DFD диаграмма программной подсистемы

  Рис. 6.1 DFD диаграмма программной подсистемы обеспечения учебно-методическим материалом СДО «*****»

  
  

  Рис. 6.2 Начальная декомпозиция DFD диаграммы ПП обеспечения учебно-методическим материалом СДО «*****»

  
  

  Рис. 6.3 Декомпозиция работы «обработать запрос пользователя»

  
  

  Рис. 6.4 Декомпозиция работы «предоставить учебный материал для просмотра»

  
  

  Рис. 6.5 Декомпозиция работы «редактировать учебный материал»

  
  

  Табл. 7.1

  Таблица названий тестов ПП
  Номер теста:	Тип:	Функциональное назначение теста:	Название тестового случая (test case):	Описание:
  1.1	Приемочное тестирование	Тест инсталляции	Установка 1	В данном тестовом случае рассматривается установка клиентской части программы СДО «*****» на компьютер пользователя.
  1.2	Приемочное тестирование	Тестирование  на  "не  тронутой"   машине	Установка 2	В данном тестовом случае рассматривается установка клиентской части программы СДО «*****» на компьютер пользователя с заново установленной операционной системой и необходимым для функционирования и тестирования Подсистемы программным обеспечением. Использование данного теста позволит выявить ошибки, принадлежащие исключительно Подсистеме, а также те ее ошибки, которые возникают только при первом запуске Подсистемы.
  2.1	Тестирование методом «стеклянного ящика»	Проверка кода программы на корректность и  безопасность	Код	Данный тест основан на использовании определенных знаний программного кода, необходимых для контроля корректности данных на выходе. Тест является правильным только в том случае, когда тестировщик знает, что конкретно должна делать программа. Таким образом, тестировщик может контролировать ожидаемый результат. Данный тест не обрабатывает случайные ошибки, но наряду с этим весь видимый код должен быть удобочитаемым.
  3.1	Тестирование методом «Черного ящика»	Тесты функций ПП.	Загрузка 1 *	Загрузка клиентом главной страницы Подсистемы в различных типах браузеров (Internet Explorer/Mozilla Firefox/Nescape Navigator/Opera). Условием удачного прохождения данного теста служит корректное отбражение текстовой и графической информации сервера, а так же сохранение оригинального форматирования.
  3.2	Тестирование методом «Черного ящика»	Тесты функций ПП.	Загрузка 2	Повторная загрузка ПП браузером.
  3.3	Тестирование методом «Черного ящика»	Тесты функций ПП.	Регистрация 1*	Регистрация нового курса (из меню администрирования, производиться тьютором). Условием удачного прохождения данного теста служит новая запись в БД, свидетельствующая об успешности выполнения операции.
  3.4	Тестирование методом «Черного ящика»	Тесты функций ПП.	Регистрация 2	Регистрация нового курса (из меню администрирования, производиться администратором). Условием удачного прохождения данного теста служит новая запись в БД, свидетельствующая об успешности выполнения операции.
  3.5	Тестирование методом «Черного ящика»	Тесты функций ПП.	Удаление *	Удаление курса. Условием удачного прохождения данного теста служит удаление всех данных, связанных с удаленным курсом в БД, свидетельствующее об успешности выполнения операции.
  3.6	Тестирование методом «Черного ящика»	Тесты функций ПП.	Редактирование	Редактирование данных курса. Условием удачного прохождения данного теста служит изменение всех данных, связанных с выбранным курсом в БД, свидетельствующее об успешности выполнения операции.
  3.7	Тестирование методом «Черного ящика»	Тесты функций ПП.	Доступ	Определение уровня доступа пользователей к курсам. Редактирование личных данных пользователя. Условием удачного прохождения данного теста служит изменение данных таблицы, связанной с предоставлением доступа к материалам сервера (матрицей доступа).
  4.1	Тестирование методом «Черного ящика»	Нагрузочное тестирование	Время загрузки 1	В данной группе тестов выявляется производительность различных компонентов подсистемы при обозначенных условиях. - время загрузки окна «Регистрация нового пользователя» при наличии множества других окон броузера; - время загрузки окна «Регистрация нового пользователя» при наличии мультизадачной среды; - время загрузки окна «Регистрация нового пользователя» на компьютере с минимально воз­можной тактовой частотой и минимальным объемом памяти; - время загрузки окна «Регистрация нового пользователя» на фоне печати текстового файла на принтере.
  4.2	Тестирование методом «Черного ящика»	Нагрузочное тестирование	Время загрузки 2	Повторная загрузка клиентом главной страницы Подсистемы. - время загрузки окна «Регистрация нового пользователя» при наличии множества других окон броузера; - время загрузки окна «Регистрация нового пользователя» при наличии мультизадачной среды; - время загрузки окна «Регистрация нового пользователя» на компьютере с минимально воз­можной тактовой частотой и минимальным объемом памяти; - время загрузки окна «Регистрация нового пользователя» на фоне печати текстового файла на принтере.
  4.3	Тестирование методом «Черного ящика»	Нагрузочное тестирование	Время загрузки 3 *	Регистрация нового курса (из меню администрирования, производиться тьютором). - время загрузки окна «Добавление материала» при наличии множества других окон броузера; - время загрузки окна «Добавление материала» при наличии мультизадачной среды; - время загрузки окна «Добавление материала» на компьютере с минимально воз­можной тактовой частотой и минимальным объемом памяти; - время загрузки окна «Добавление материала» на фоне печати текстового файла на принтере.
  4.4	Тестирование методом «Черного ящика»	Нагрузочное тестирование	Время загрузки 4	Регистрация нового курса (из меню администрирования, производиться администратором). - время загрузки окна «Добавление материала» при наличии множества других окон броузера; - время загрузки окна «Добавление материала» при наличии мультизадачной среды; - время загрузки окна «Добавление материала» на компьютере с минимально воз­можной тактовой частотой и минимальным объемом памяти; - время загрузки окна «Добавление материала» на фоне печати текстового файла на принтере.
  4.5	Тестирование методом «Черного ящика»	Нагрузочное тестирование	Время загрузки 5	Удаление курса. - время выполнения данной операции при наличии множества других окон броузера; - время выполнения данной операции при наличии мультизадачной среды; - время выполнения данной операции на компьютере с минимально воз­можной тактовой частотой и минимальным объемом памяти; - время выполнения данной операции на фоне печати текстового файла на принтере.
  4.6	Тестирование методом «Черного ящика»	Нагрузочное тестирование	Время загрузки 6	Редактирование данных курса. - время загрузки окна «Добавление материала» при наличии множества других окон броузера; - время загрузки окна «Добавление материала» при наличии мультизадачной среды; - время загрузки окна «Добавление материала» на компьютере с минимально воз­можной тактовой частотой и минимальным объемом памяти; - время загрузки окна «Добавление материала» на фоне печати текстового файла на принтере.  - время выполнения операции редактирования.
  5.1	Тестирование методом «Черного ящика»	Тестирование производительности	Производительность	В данном тесте проводится мониторинг производительности сервера при множественной загрузке страниц сервера (моделируется работа до 30 пользователей одновременно).
  6.1	Тестирование методом «Черного ящика»	Обработка ошибок пользователей Подсистемой	Ошибки	В данной группе тестов рассматривается реакция подсистемы на входные пользовательские данные. Условием удачного прохождения теста служит адекватная реакция подсистемы (выведение текста об ошибке) на неверные, либо на некорректно введенные данные. - Реакция на некорректно введенные данные о новом курсе (имя курса, автор, неверные пути к файлам курса) - Реакция на некорректно введенные данные о новом курсе (имя курса, автор, неверные пути к файлам курса). Проверяется при редактировании данных курса. - Реакция на регистрацию курса, который уже существует в системе.

  
  

  Тесты, отмеченные знаком *, подробно рассмотрены в п.7.5.2 настоящей дипломной работы.

Скачать дипломную работу