Автоматизация проверки знаний и навыков студентов в области прикладной математики и информатики
Разработка и реализация программного комплекса для обеспечения возможности проведения тестирования в образовательной среде. Разработка структура системы, базы данных, алгоритмов, интерфейса пользователя. Технико-экономическое обоснование проекта.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 03.09.2012 |
| Размер файла | 3,3 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Сущность Answers. Варианты ответов к вопросам.
Атрибуты:
· Answer_id. Тип: integer. Первичный ключ.
· Answer_question_id. Тип: integer. Хранится идентификатор из сущности Questions. Определяет принадлежность варианта ответа к вопросу.
· Answer_number. Тип: integer. Локальный номер ответа. Нумерация начинается с единицы. Используется только для ответов на вопрос типа «упорядоченный список»
· Answer_text. Тип: varchar(512). Текст варианта ответа. Возможность форматирования текста отсутствует.
· Answer_score. Тип: integer. Количество баллов, начисляемых за ответ. Используется при типе теста «Психологический».
· Answer_right. Тип: bit. Флаг правильности ответа. Принимает значения «0» и «1». При типах вопроса «упорядоченный список», «на соответствие» и «свободный ввод» - всегда устанавливается значение «1»
· Answer_corresp. Тип: varchar(512). Применяется для определения правильного ответа в вопросах на соответствие.
· Answer_picture. Тип: image. Может храниться изображение с вариантом ответа
Сущность Groups. Информация о группах пользователей.
Атрибуты:
· Group_id. Тип: integer. Первичный ключ.
· Group_name. Тип: varchar(512). Наименование группы.
· Group_description. Тип: varchar(512). Описание группы.
· Group_hidden. Тип: bit. Флаг сокрытия группы. Принимает значения «1» и «0». При значении «1» группа удаляется из списка видимых. Информация не удаляется.
Сущность Groupsections. Информация о соответствии группам разделов тестов.
Атрибуты:
· Id. Тип: integer. Первичный ключ.
· Gs_group_id. Тип: integer. Идентификатор группы.
· Gs_section_id. Тип: integer. Идентификатор раздела тестов.
Сущность Users. Информация о пользователях.
Атрибуты:
· User_id. Тип: integer. Первичный ключ.
· User_group_id. Тип: integer. Хранится идентификатор из сущности Groups. Определяет принадлежность пользователя к группе.
· User_name. Тип: varchar(512). Имя пользователя в формате ФИО.
· User_code. Тип: varchar(128). Дополнительное поле для идентификатора пользователя (например, номера зачетной книжки).
· User_password. Тип: varchar(128). Пароль пользователя. Хранится в закодированном виде. Алгоритм кодирования - md5.
· User_desable_test. Тип: bit. Флаг, позволяющий временно запретить данному пользователю тестироваться
· User_garants. Тип: integer. Кодирует права доступа пользователя. «0» - тестирующийся, «1» - редактор тестов, «2» - администратор
· User_info. Тип: varchar(512). Информация о пользователе.
· User_deleted. . Тип: bit. Флаг удаления пользователя. Принимает значения «1» и «0». При значении «1» становится невозможным использование учетной записи, данные сохраняются.
· User_mail. Тип: varchar(128). Адрес e-mail пользователя.
Сущность User_results. Хранение результатов тестирования.
Атрибуты:
· User_result_id. Тип: integer. Первичный ключ.
· User_result_completed. Тип: bit. Флаг окончания теста (ответ на все имеющиеся вопросы). Принимает значения «1» и «0».
· User_result_time_begin. Тип: smalldatetime. Время начала тестирования.
· User_result_time_end. Тип: smalldatetime. Время окончания тестирования.
· User_result_cmpleted_questions. Тип: integer. Количество пройденных вопросов.
· User_result_right_questions. Тип: integer. Количество правильных ответов.
· User_result_score. Тип: integer. Количество заработанных баллов.
· User_result_percent_right. Тип: real. Процент правильных ответов.
· User_result_total_questions. Тип: integer. Всего вопросов в тесте.
· User_result_test_title. Тип: varchar(128). Название теста
· User_id. Тип: integer. Хранится идентификатор из сущности Users. Определяет принадлежность результата к конкретному пользователю.
Сущность User_answers. Лог прохождения теста, может быть показан в отчете.
Атрибуты:
· User_answer_user_result_id. Тип: integer. Первичный ключ.
· User_answer_qnumber. Тип: integer. Номер вопроса.
· User_answer_question. Тип: varchar(512). Текст вопроса с элементами разметки гипертекста для корректного вывода в поле отчета.
· User_answer_answer. Тип: varchar(512). Текст ответа с элементами разметки гипертекста для корректного вывода в поле отчета.
· User_answer_time. Тип: char(8). Время ответа на вопрос.
· User_answer_is_right. Тип: bit. Флаг правильности ответа. Принимает значения «T» и «F».
· User_answer_score. Тип: integer. Полученные баллы.
· User_answer_answerd. Тип: bit. Флаг ответа на вопрос. Принимает значения «1» и «0».
Поддержка целостности и непротиворечивости данных осуществляется средствами целевой СУБД MS SQL Server 2005. При возникновении конфликтной ситуации СУБД генерирует соответствующее сообщение, которое автоматически будет транслировано в клиентское приложение и показано пользователю. Вызвавшая исключительную ситуацию транзакция выполнена не будет, а набор данных будет возвращен в предыдущее непротиворечивое состояние.
Резервное копирование данных, настройка и иные административные функции выполняются средствами администрирования, такими, как SQL Server Management Studio и SQL Server Business Intelligence Development Studio.
Наличие описанных механизмов поддержки целостности и непротиворечивости данных, а так же средств администрирования базы данных, делает обоснованным использование SQL Server 2005 в качестве целевой СУБД.
2.3 Разработка и описание рабочих алгоритмов
В виду того, что модули разрабатываемого программного комплекса должны работать в многопользовательской среде, алгоритмы их работы должны обладать низкой ресурсоемкостью и малым временем выполнения.
Необходимо отметить, что в модуле редактирования тестов и модуле администрирования наличие каких-либо сложных вычислительных алгоритмов не предполагается. По сути, эти модули являются средствами просмотра и редактирования содержимого базы данных. Возникающие в процессе работы этих модулей задержки обусловлены лишь задержкой, связанной с пересылкой результатов запроса от СУБД к программному модулю, которая в свою очередь может меняться в зависимости от условий эксплуатации модулей: параметров сервера базы данных и качества линии связи между программным модулем и сервером базы данных.
В модуле тестирования пользователя помимо задержек, связанных с пересылкой запросов от сервера к клиенту, дополнительно могут возникнуть задержки при обработке и анализе ответа пользователя. Рассмотрим общий алгоритм работы модуля тестирования пользователей.
Рисунок 2.3 - Алгоритм работы модуля тестирования
Рисунок 2.4 - Алгоритм работы модуля тестирования (продолжение)
С целью приблизительной оценки задержки при работе модуля тестирования в многопользовательском режиме был произведен эксперимент, результаты которого приведенные в таблице 2.1
Таблица 2.1 Результаты тестирования на быстродействие в многопользовательском режиме.
|
№ |
Тестовый сервер |
Кол-во пользователей |
Время выполнения, с |
|
1 |
Intel Celeron2000, 2Гб ОЗУ PC-3200 |
10 |
0,013-0,015 |
|
|
20 |
0,012-0,016 |
Количество замеров для обоих случаев равно пяти. Как видим, полученные задержки малы, что обусловлено малой вероятностью выполнения сервером одновременно нескольких запросов к базе данных. Для этого нужно было бы, чтобы запросы пришли одновременно с точностью 0.01с.
2.4 Требования к системам передачи информации
Разрабатываемая система может использовать в качестве среды передачи данных как локальную, так и глобальные сети, в независимости от их топологии.
Основной объем пересылаемых данных составляют запросы клиентского модуля на выборку вопросов, относящихся к текущему тесту, и результат их выполнения. Пакет ответа на запрос с формулировкой вопроса в текстовом виде с элементами форматирования текста имеет размер 2-8 Кб. Размер пакетов во многом зависит от содержимого формулировки вопроса. Так использование различных мультимедейных объектов в формулировке вопроса может существенно увеличить время передачи вопроса в удаленный клиентский модуль, если последний подключен к базе посредствам низкоскоростного модемного соединения. Грамотное планирование структуры и содержания вопросов позволяет избежать подобных проблем.
Для осуществления работы клиентского модуля достаточно модемного соединения на скорости 33600 Кбит/сек., однако, использование в вопросе мультмедийных файлов больших размеров, может замедлить выдачу очередного вопроса. С точки зрения логики работы модуля это не критично, поскольку отсчет времени ответа на вопрос начинается с момента вывода формулировки вопроса на экран клиентского компьютера.
Для комфортной работы со всеми модулями комплекса достаточно использования высокоскоростного соединения 64 Кб/сек., что делает возможным использование комплекса, как в локальных, так и в глобальных сетях.
2.5 Описание технологии обработки информации
Входными данными для разрабатываемой системы являются файл тестового набора и реакции пользователя. Тестовый набор представляет собой результат выполнения запроса на выборку вопросов, относящихся к выбранному тесту, и ответов к ним. Механизм пересылки запросов и их обработки реализован средствами технологии Microsoft ActiveX Data Objects (ADO), которая основана на возможностях СОМ, а именно интерфейсов OLE DB.
Технология Microsoft ActiveX Data Objects обеспечивает универсальный доступ к источникам данных из приложений БД. Такую возможность предоставляют функции набора интерфейсов, созданные на основе общей модели объектов СОМ и описанные в спецификации OLE DB.
Технология ADO и интерфейсы OLE DB обеспечивают для приложений единый способ доступа к источникам данных различных типов (рис. 19.1). Например, приложение, использующее ADO, может применять одинаково сложные операции и к данным, хранящимся на корпоративном сервере SQL, и к электронным таблицам, и локальным СУБД. Запрос SQL, направленный любому источнику данных через ADO, будет выполнен.
Рисунок 2.5 - Схема доступа к данным через ADO
OLE DB представляет собой набор специализированных объектов СОМ, инкапсулирующих стандартные функции обработки данных, и специализированные функции конкретных источников данных и интерфейсов, обеспечивающих передачу данных между объектами.
Согласно терминологии ADO, любой источник данных (база данных, электронная таблица, файл) называется хранилищем данных, с которым при помощи провайдера данных взаимодействует приложение. Минимальный набор компонентов приложения может включать объект соединения, объект набора данных, объект процессора запросов.
Объекты OLE DB создаются и функционируют так же, как и другие объекты СОМ. Каждому объекту соответствует идентификатор класса CLSID, хранящийся в системном реестре. Для создания объекта используется метод CoCreateinstance и соответствующая фабрика класса. Объекту соответствует набор интерфейсов, к методам которых можно обращаться после создания объекта.
В результате приложение обращается не прямо к источнику данных, а к объекту OLE DB, который "умеет" представить данные (например, из файла электронной почты) в виде таблицы БД или результата выполнения запроса SQL.
Технология ADO в целом включает в себя не только сами объекты OLE DB, но и механизмы, обеспечивающие взаимодействие объектов с данными и приложениями. На этом уровне важнейшую роль играют провайдеры ADO, координирующие работу приложений с хранилищами данных различных типов.
Такая архитектура позволяет сделать набор объектов и интерфейсов открытым и расширяемым. Набор объектов и соответствующий провайдер может быть создан для любого хранилища данных без внесения изменений в исходную структуру ADO. При этом существенно расширяется само понятие данных -- ведь можно разработать набор объектов и интерфейсов и для нетрадиционных табличных данных. Например, это могут быть графические данные геоинформационных систем, древовидные структуры из системных реестров, данные CASE-инструментов и т. д.
Так как технология ADO основана на стандартных интерфейсах СОМ, которые являются системным механизмом Windows, это сокращает общий объем работающего программного кода и позволяет распространять приложения БД без вспомогательных программ и библиотек.
Спецификация OLE DB различает следующие типы объектов, которые будут рассмотрены ниже.
- Перечислитель (Enumerator) выполняет поиск источников данных или других перечислителей. Используется для обеспечения функционирования провайдеров ADO.
- Объект-источник данных (Data Source Object) представляет хранилище данных.
- Сессия (Session) объединяет совокупность объектов, обращающихся к одному хранилищу данных.
- Транзакция (Trasaction) инкапсулирует механизм выполнения транзакции.
- Команда (Command) содержит текст команды и обеспечивает ее выполнение. Командой может быть запрос SQL, обращение к таблице БД и т. д.
- Набор рядов (Rowset) представляет собой совокупность строк данных, являющихся результатом выполнения команды ADO.
- Объект-ошибка (Error) содержит информацию об исключительной ситуации.
Все описанные качества делают оправданным использование технологии Microsoft ADO в проекте, в качестве технологии доступа и обработки данных.
2.6 Разработка интерфейса взаимодействия пользователя с системой
Поскольку разрабатываемый программный комплекс в своем составе имеет модуль создания, редактирования тестов, модуль просмотра результатов тестирования и модуль тестирования знаний, то целесообразно наделять пользователей, работающих с разными модулями, разными правами доступа. Это позволит защитить тестовые наборы от посягательства злоумышленников и реализовать идеологию честного тестирования, при которой тестирующийся пользователь проходит тест, основываясь только на своих знаниях предмета тестирования.
Пользователи системы -- сотрудники и студенты высших учебных заведений. Всех пользователей системы можно, как будет показано ниже, разделить на несколько категорий, принадлежность к которым конкретизирует требования. Однако все пользователи должны иметь навыки работы с персональным компьютером. Выделим следующие категории пользователей комплекса:
Администратор выполняет функции управления группами и пользователями, а так же правами в системе, просматривает и распечатывает отчеты с результатами тестирования отдельных пользователей или групп, устанавливает соответствие между разделами тестов и группами. Администратор может при необходимости выполнять функции всех нижеследующих типов пользователей. Администратор должен иметь глубокие познания в сфере установки, конфигурирования и работы с ОС и программным обеспечением, используемым системой. Также ему необходимо знать основы администрирования СУБД вообще и SQL Server 2005 в частности. Желательно, чтобы администратор имел хотя бы общие познания в языках программирования и описания данных, используемых в системе (SQL DDL/DML, PL/SQL, и др.). Одной из задач администрирования является консультация пользователей системы в случае возникновения у них каких-либо вопросов.
Преподаватель. Вводит в систему новые тестовые задания и редактирует существующие, устанавливает временные границы тестирования.
Тестируемый. Эта категория пользователей добровольно или принудительно проверяет свои знания с помощью тестов. Перед началом тестирования пользователь входит под своей учетной записью. Затем он выбирает доступный для своей группы тест и проходит тестирование. По завершению тестирования пользователь имеет возможность просмотреть результаты сеанса тестирования.
Каждой категории пользователей соответствует отдельный программный модуль. Доступ к модулям редактирования тестов и администрирования возможен только после аутентификации пользователя. Доступ к модулю тестирования возможен без аутентификации, однако, полноценная работа с модулем возможна только после регистрации пользователя в системе.
Интерфейс всех модулей имеет академический стиль, отличающийся минимальными визуальными эффектами и интуитивной понятностью конечному пользователю. Экранные формы всех модулей представлены в приложении Б.
На рисунках 2.6, 2.7 и 2.8 представлены графы диалога пользователей категории «администратор», «преподаватель» и «тестирующийся» соответственно.
Рисунок 2.6 - Граф диалога администратора с системой
Рисунок 2.7 - Граф диалога преподавателя с системой
Рисунок 2.8 - Граф диалога тестирующегося с системой
Выводы
Во втором разделе была произведена разработка проекта системы. Структура комплекса состоит из трех модулей: модуля администрирования, модуля редактирования тестов и модуля тестирования. Каждый из модулей независим от остальных. В данном разделе была спроектирована ER-модель базы данных с подробным описанием всех ее сущностей и входящих в них атрибутов. На основе ER-модели была разработана реальная модель в целевой СУБД Microsoft SQL Server 2005. Затем были разработаны рабочие алгоритмы функционирования элементов системы. После определили требования к системе передачи информации. Для комфортной работы со всеми модулями комплекса достаточно использования высокоскоростного соединения 64 Кб/сек. Так же во втором разделе была описана технология доступа и обработки данных Microsoft ADO. Был обоснован ее выбор в качестве технологии обработки информации. Затем были выделены три категории пользователей, работающих с модулями комплекса. Для каждой категории был разработан граф диалога пользователя с системой. Работа над вторым разделом стала основой для разработки рабочих программ.
3. Реализация проекта системы
3.1 Разработка рабочей программы
Рабочая программа разрабатывалась в среде программирования Borland Delphi 7.0. Эта среда обладает удобным набором средств проектирования пользовательского интерфейса и работы с базами данных. В частности в Delphi 7 имеется коллекция компонентов, инкапсулирующих свойства и методы технологии доступа к данным Microsoft ADO. Так же при использовании Delphi 7 в качестве среды разработки, проектирование пользовательского интерфейса уходит на второй план, а на первое место выходит разработка и реализация алгоритмов работы системы. Все это послужило причиной выбора данной среды для разработки программного комплекса.
Весь комплекс разделен на три законченных программных модуля: модуль администрирования, модуль редактирования тестов и модуль тестирования. Доступ к каждому из модулей осуществляется запуском соответствующего приложения.
На рисунке 3.1 представлена модульная структура блока администрирования
Рисунок 3.1 - Модульная структура блока администратора
Как видно из рисунка данный блок содержит в себе четыре модуля:
1. uAdmDataModule. Состоит из компонентов доступа и отображения данных. В данном модуле реализованы SQL-запросы и реакции системы на изменение состояния наборов данных.
2. uAuthentification. Модуль аутентификации пользователя. Отображается непосредственно после запуска приложения. При успешном входе наборы данных будут открыты и отображены на главной форме приложения. В противном случае приложение будет закрыто автоматически.
3. uUserGrioup. Этот модуль предназначен для управления пользователями и группами. Здесь производится сопоставление разделов тестов и групп пользователей, создаются пользователи с правами администратора и редактора тестов.
4. uReporting. Модуль статистики и отчетов. Отображается статистика, как по отдельным пользователям, так и по группам пользователей.
На рисунке 3.2 представлена модульная структура модуля редактирования тестов
Рисунок 3.2 - Модульная структура редактора тестов
Редактор тестов состоит из трех модулей:
1. uEditorMain. Главный модуль программы. Содержит обработчики действий пользователя. Производит управление интерфейсом программы в зависимости от действий пользователя
2. uAuthentification. Назначение и функционирование такое же, как и в модуле администрирования.
3. uEditorDataModule. Состоит из компонентов доступа и отображения данных. В данном модуле реализованы SQL-запросы и реакции системы на изменение состояния наборов данных. В данном модуле реализуется поддержка целостности и непротиворечивости данных в базе.
Модульная структура блока тестирования представлена на рисунке 3.3.
Рисунок 3.3 - Модульная структура блока тестирования
Назначение модулей следующее:
uTestAuthentification. Модуль, осуществляющий аутентификацию пользователя в системе. В случае, если введенная учетная запись отсутствует в базе, пользователь может зарегистрировать новую учетную запись.
uNewUser. Модуль регистрации нового пользователя. Вызывается из модуля аутентификации. Добавляет нового пользователя с правами тестирующегося.
uSelectTest. Модуль выбора теста. данный модуль становится доступным после прохождения процедуры аутентификации. Если этого не сделано, то перед открытием модуля выбора теста, пользователю будет предложено войти в систему со своей учетной записью. На выбор доступны только тесты из разделов, разрешенных для группы, в которой зарегистрирован вошедший пользователь.
uTestDataModule. Состоит из компонентов доступа и отображения данных. В данном модуле реализованы SQL-запросы и реакции системы на изменение состояния наборов данных. В данном модуле реализуется поддержка целостности и непротиворечивости данных в базе.
uTestMain. Главный модуль программы. Осуществляет выдачу вопросов и вариантов ответов к ним. Вопросы и ответы имеют случайный порядок следования, что исключает механическое угадывание пользователем правильных ответов. Так же данный модуль принимает, анализирует ответы пользователей, заносит результаты в базу.
Тексты всех модулей представлены в приложении В.
3.2 Реализация графа диалога пользователей
При работе пользователей с компонентами программного комплекса должны быть выполнены следующие требования: первое - интерфейс модулей должен быть простым и понятным пользователям; второе - пользователи, не имеющие соответствующие права, не должны иметь возможности работать с модулями системы.
Первое требование выполняется при помощи интуитивно понятных элементов управления, системы подсказок и системы помощи при работе с системой. На рисунке 3.4 представлена главная форма модуля тестирования.
Рисунок 3.4 - Главная форма модуля тестирования
Из рисунка видно, что интерфейс прост и понятен. В верхней части окна помещается вопрос. В нижней - варианты ответа, которые вводит пользователь. После ответа на вопрос пользователь переходит к следующему вопросу. Если это разрешено, то возможен переход к предыдущему вопросу.
Кнопки инструментальной панели продублированы пунктами главного меню. Такое построение интерфейса используется мо многих известных приложениях, поэтому работа с модулями программного комплекса не должна вызвать затруднения даже у начинающих пользователей компьютера.
Чтобы предупредить возможные ошибки пользователя, связанные, например, с преждевременным пользователем из сеанса тестирования, реализована система информирования пользователя (рисунок 3.5)
Рисунок 3.5 - Реакция программы на преждевременное завершение работы
Чтобы предотвратить несанкционированный доступ пользователей не имеющих на это право к модулям редактирования тестов и администрирования реализована принудительная аутентификация при входе в приложение.
Рисунок 3.6 - Пример запуска редактора тестов
Интерфейс приложения фактически не скрыт, но загрузка данных в компоненты отображения не производится. Если вход в систему успешный, то все необходимы данные будут загружены в компоненты отображения.
Примеры остальных форм и реакции на действия пользователей представлены в приложении Б.
3.3 Тестирование программных средств
В настоящее время разработано достаточно много разнообразных методов отладки программного обеспечения. Выделим некоторые:
1. Синтаксическая и семантическая отладка.
2. Тестирование программ как "черного" или "белого" ящика.
3. Статическое и динамическое тестирование.
4. Разрушающие и неразрушающие методы.
5. Методологические способы отладки.
6. Другие приемы отладки.
В зависимости от объекта отладки методы и системы отладки можно разделить на две части: синтаксическую и семантическую.
Синтаксическая отладка начинается при первом вводе программы в ЭВМ для трансляции или сразу для выполнения и заканчивается получением текста программы, не содержащего конструкций языка программирования, противоречащих его синтаксису.
Семантическая отладка начинается в тот момент, когда программа стала синтаксически правильной и пригодна для выполнения на ЭВМ. Целью семантической отладки является поиск и корректировка программы таким образом, чтобы она выполняла заданную функцию (преобразование входных данных в выходные) в соответствии с требованиями к программе.
Наиболее распространенным и традиционным методом отладки программ является тестирование программ.
Подходы к решению задачи тестирования в зависимости от того, каким образом они учитывают или рассматривают структуру исследуемой программы, можно разделить на два направления:
1. Тестирование программы как "черного ящика" (при тестировании не учитывается внутренняя структура программы, а принимаются во внимание лишь значения входных и выходных данных);
2. Тестирование программы как "белого ящика" (при тестировании принимается во внимание также и внутренняя структура программы).
При тестировании программ по методу "белого ящика" тестовые данные для программы формируются с учетом ее внутренней структуры. При этом задача тестирования преобразуется в задачу обеспечения полноты проверки внутренней структуры, которая отражает алгоритм функционирования. Внутренняя структура может быть представлена в виде управляющего ориентированного графа, где вершины - это отдельные операторы, а дуги - возможные передачи управления между операторами.
Тогда тестирование может заключаться в проверке всех дуг такого графа, всех выходов из каждой вершины графа, маршрутов обработки инфоpмации внутри программы. При тестировании по этому методу программист располагает информацией о пути прохождения вычислительного процесса по графу и выбирает тесты таким образом, чтобы обеспечить проверку графа по заданному критерию. Также проверяются значения выходных данных, вырабатываемых программой. Поэтому тестирование по методу "белого" ящика в общем случае более глубокое и эффективное, чем по методу "черного" ящика.
Можно указать три вида тестирования, учитывающего внутреннюю структуру программы:
- тестирование путей;
- тестирование ветвей;
- тестирование операторов.
Тестирование путей программы предполагает выполнение всех возможных или подмножеств путей, существующих в программе, по крайней мере один раз. Путь программы определяется значениями входных данных. Каждый путь программы состоит из последовательности линейных участков, на которых расположены только безусловно выполняемые команды; линейные участки связаны командами условного перехода. Если команды условного перехода не коppелиpуют друг с другом по данным, то число различных реализуемых путей программы может достигать числа 2 в степени n, где n - число команд условных переходов, каждая из которых имеет два выхода ("да" и "нет"). Ясно, что даже для небольших программ достичь полного тестирования путей невозможно.
Тестирование ветвей предполагает, по крайней мере, однократное выполнение каждой ветви отлаживаемой программы. Ветвь программы - это последовательность безусловно выполняемых команд, заканчивающихся командой условного перехода (максимальный участок с одним входом и одним выходом). При тестировании ветвей можно достичь полного перекрытия всех ветвей относительно небольшим числом тестов.
Тестирование операторов состоит в выполнении, по крайней мере, один раз каждого оператора программы независимо от пути или ветви программы, на которых он находится. Это наиболее простой из трех перечисленных способов тестирования.
В зависимости от способа получения результатов выполнения программы все подходы к тестированию можно также разделить на два направления.
1. Если программа во время отладки непосредственно не выполняется, то такой подход называется статическим. При этом исследуется текст или код программы с целью выявления конструкций, которые можно интерпретировать как неправильные, для их последующего исправления;
2. Если программа в процессе отладки выполняется, то такой подход называется динамическим. При этом исследуются выходные и промежуточные значения переменных, и если они отличаются от предполагаемых, то делаются необходимые корректировки в программе, и процесс выполнения программы повторяется.
При статическом тестировании проводится достаточно глубокий и полный анализ управляющих и информационных связей программы. Такой анализ основан на исследовании преобразований управления и данных, выполняемых каждым оператором программы, и затем объединении этих преобразований в единую цепочку. В результате формируются единые потоки управления и данных, а сам метод анализа назван потоковым.
Потоки управления и данных представляются в виде управляющего и информационного графов соответственно.
По характеру воздействия на текст программы методы отладки классифицируются как неразрушающие и разрушающие.
неразрушающий метод не предполагает модификации программы во время отладки. Это, как правило, все статические методы и часть динамических. При статических методах отладки нет в принципе необходимости во внесении изменений в отлаживаемую программу, т.к.
всегда можно имитировать такое изменение с помощью других программ, обеспечивающих процесс отладки.
разрушающий метод отладки предполагает модифицирование программы на время отладки. примерами такой модификации могут быть:
- расширение программы макрокоманды отладки;
- добавление в программу отладочных операторов;
- создание контрольных точек;
- включение в текст операторов распечатки промежуточных данных;
- изменение участков программы или отдельных команд.
После завершения процесса отладки такие модифицированные участки программ необходимо восстанавливать. В случае обнаружения новых ошибок необходимо снова модифицировать программу и т.д. Таким образом, разрушающие методы отладки "провоцируют" внесение ошибок в программу в процессе отладки, хотя и позволяют эффективно исследовать программу.
Одной из наиболее распространенных и эффективных дисциплин является разработка программ методом сверху вниз, или нисходящая разработка.
При нисходящей разработке первоначально создаются подпрограммы, находящиеся на верхних "этажах" схемы иерархии (схемы связи) подпрограмм, т.е. те, которые включают в работу весь программный комплекс и осуществляют вызов других подпрограмм.
Существует также разработка программ методом снизу вверх или восходящая разработка, которая предполагает вначале разработку и отладку подпрограмм самых низких уровней, затем более высоких. Однако этот подход имеет более узкую область эффективного применения, чем нисходящая разработка.
Кроме рассмотренных, существуют и другие приемы отладки программ.
Объект испытаний. Объектом испытаний является система удаленного тестирования знаний, применяемая для тестирования пользователей по сети.
Цель испытаний. Целью проведения испытаний является выявление случаев некорректной работы системы и их устранение. Испытания проводятся согласно с ГОСТ 19.301-79 «Программа и методика испытаний».
Требования к программе. Программный комплекс проверки знаний должен выполнять обозначенные в техническом задании функции и не приводить к сбоям в случае ввода пользователем некорректной информации.
Состав и порядок испытаний.
Порядок и результаты испытаний приведены в таблице 3.1.
Таблица 3.1 Состав, порядок и результаты испытаний
|
№ |
Действие |
Ожидаемый результат |
Действительный результат |
|
|
1 |
Ввод неверного пароля |
Отказ в доступе |
Отказ в доступе |
|
|
2 |
Попытка входа без пароля |
Отказ в доступе |
Отказ в доступе |
|
|
3 |
Ввод неверного логина |
Отказ в доступе |
Отказ в доступе |
|
|
4 |
Попытка тестирования пользователем, не имеющим на это прав |
Отказ в доступе |
Отказ в доступе |
|
|
5 |
Попытка входа в модуль администрирования или редактор тестов пользователя, не имеющего на это прав |
Отказ в доступе, предложения повторного входа |
Отказ в доступе,закрытие приложения |
|
|
6 |
Попытка добавления в БД некорректного файла тестового набора |
Вывод сообщения об ошибке |
Вывод сообщения об ошибке |
Таблица 3.1(продолжение)
|
№ |
Действие |
Ожидаемый результат |
Действительный результат |
|
|
7 |
Удаление пользователя |
Будет удален только пользователь, результаты останутся |
Удалены и пользователь, и результаты |
|
|
8 |
Закрытие модуля тестирования во время сеанса |
Вывод предупреждения о незаконченном сеансе |
Вывод предупреждения о незаконченном сеансе |
|
|
9 |
Переход пользователя при тестировании к следующему вопросу без ответа на текущий |
Переход к следующему вопросу, занесение в базу ответа как неправильный |
Ошибка доступа к базе данных |
Выявленное в ходе тестирования несоответствие ожидаемого результата и действительного по пунктам 5 и 9 были устранены, ошибки исправлены.
Проведенное тестирование компонентов программного комплекса позволило выявить и исправить существующие ошибки в работе. В конечном итоге получен готовый работоспособный продукт.
3.4 Оценка надежности
Надежность разрабатываемой системы складывается из двух составляющих: надежность базы данных и надежность программного комплекса. Надежность базы данных обеспечивается ее внутренними механизмами. В частности выделим поддержку устойчивых к сбоям кластеров (Failover Clustering), в основе функционирования которых лежат средства оперативного переноса данных на запасное аппаратное обеспечение в случае аппаратного сбоя основного сервера. Размер подобных кластеров может достигать восьми узлов в зависимости от того, какая именно редакция Windows Server 2003 установлена на сервере баз данных. Отметим, что кластеры, устойчивые к сбоям, могут быть созданы и для аналитических служб, служб уведомлений, средств репликации данных. Еще одно средство повышения надежности SQL Server 2005 -- зеркалирование баз данных, основанное на постоянной передаче журнала транзакций с основного сервера на запасной, что позволяет в случае сбоя основного сервера немедленно переключить клиентские приложения на запасной сервер без задержки, поскольку состояние данных на нем синхронно с состоянием данных основного сервера.
Надежность программных модулей обусловлена их защитой двоичным кодом приложения. В модулях реализован механизм проверки вводимых пользователем данных, что так же увеличивает надежность системы. Аутентификация пользователей при входе в редактор тестов и модуль администрирования повышает защищенность данных от несанкционированного чтения и изменения.
В совокупности, оценка надежности базы данных и программного комплекса говорит о высокой надежности всей системы в целом.
3.5 Разработка сопроводительных документов
Для обеспечения работоспособности компонентов комплекса необходимо подключить базу данных к серверу СУБД SQL server 2005. Предполагается, что SQL server 2005 установлен на сервер и сконфигурирован нужным образом. Для подключения базы данных необходимо предпринять следующие действия:
1. Запускаем SQL Server Management Studio
2. Выбираем пункт контекстного меню объекта Databases->Attach…
Рисунок 3.7 - Подключение базы данных
В появившемся окне нажимаем кнопку Add и добавляем файл DB_test.mdf из корневого каталога установочного диска.
Рисунок 3.8 - Подключение базы данных (продолжение)
По желанию можно изменить настройки размещения файлов базы данных на сервере. Необходимо помнить, что размер базы постоянно увеличивается, поэтому на диске должно быть достаточное свободное пространство. После завершения подключения базы данных объект с ее именем должен появиться в дереве объектов SQL Server Management Studio в разделе Databases. Это является признаком успешного подключения базы.
Если по каким либо причинам подключить базу не удастся, то можно воспользоваться скриптом, который сгенерирует новую пустую базу данных. Для этого необходимо загрузить файл db_generation_script.sql из корневого каталога установочного диска в среду SQL Server Management Studio и запустить запрос на выполнение. Текст скрипта приведен в приложении А.
После подключения базы необходимо настроить подключение модулей редактора тестов и администрирования к базе данных. Для этого скопируйте файл connection.udl из корневого каталога установочного диска в каьалог %System Drive%\ Program Files\Common Files\System\Ole DB\Data Links\. После этого двойным щелчком по файлу запустите редактор строки подключения Microsoft. На странице «Подключение» введите IP-адрес или имя сервера, на который была установлена база данных DB_test. Выберите пункт «учетные сведения Windows NT» и имя базы данных. Если все сделано правильно, то после нажатия на кнопку «Проверить подключение» появится сообщения об успешном подключении.
Рисунок 3.9 - Настройка подключения базы
Нажмите кнопку «ОК», настройка соединения закончена. После можно приступать к работе с редактором тестов и модулем администрирования.
4. Технико-экономическое обоснование разработки
4.1 Расчет себестоимости разрабатываемой системы
Затраты на выполнение проекта состоят из затрат на заработную плату исполнителям, затрат на закупку или аренду оборудования и затрат на накладные расходы (4.1).
К = Сзарп + Соб + Снакл 4.1
где СЗАРП - заработная плата исполнителей, СОБ -затраты на обеспечение необходимым оборудованием, СНАКЛ- накладные расходы.
4.2 Затраты на выплату исполнителям заработной платы.
Определяется следующим соотношением:
4.2
где СЗ.ОСН - основная заработанная плата, СЗ.ДОП - дополнительная заработная плата, СЗ.ОТЧ - отчисление с заработанной платы.
4.3 Расчет основной заработанной платы.
При дневной оплате труда исполнителей проводится на основе данных по окладам и графику занятости исполнителей (4.3):
4.3
где ТЗАН - число дней, отработанных исполнителем проекта, ОДН - дневной оклад исполнителя. При 8-и часовом рабочем дне он рассчитывается по соотношению 4.4.
4.4
где ОМЕС - месячный оклад, FM - месячный фонд рабочего времени (4.5).
4.5
где tp - продолжительность рабочего дня, DK - общее число дней в году, DB - число выходных дней в году, DП - число праздничных дней в году.
Для 2007 года количество рабочих дней (с учетом праздников и выходных) 249, продолжительность рабочего дня составляет 8 часов. Учитывая полученные данные и формулу (4.5), получим:
FМ = 8*249/12 = 166
Оклад программиста в компании «Этна IT» составляет 14970 р.
С учетом налога на доходы физических лиц размер месячного оклада увеличивается, что отражено в формуле 4.6:
4.6
где О - оклад, НДФЛ - налог на доходы с физических лиц (13%).
Таким образом, месячный оклад составляет:
OМ = 14970(1+0,13) = 16 916 р.
Тогда дневной оклад составляет:
ОДН = 16916*8/166 = 815 р.
Расчет затрат рабочего времени (при 8-ми часовом рабочем дне) на выполнение программного продукта, представлен в таблице 4.1.
Таблица 4.1 - Затраты рабочего времени на разработку системы
|
Этап |
Содержание работы |
Трудозатраты |
||
|
Чел.-час |
Чел.-дни |
|||
|
1 |
Разработка структуры функционирования системы |
136 |
17 |
|
|
1.1 |
Разработка алгоритма функционирования системы |
16 |
2 |
|
|
1.2 |
Разработка структуры базы данных |
40 |
5 |
|
|
1.3 |
Разработка алгоритма прохождения теста |
40 |
5 |
|
|
1.4 |
Разработка алгоритма кодирования фалов теста |
40 |
5 |
|
|
2 |
Реализация проекта системы |
320 |
40 |
|
|
2.1 |
Реализация структуры базы данных |
120 |
15 |
|
|
2.2 |
Реализация программного модуля |
120 |
15 |
|
|
2.3 |
Реализация интерфейса системы для пользователей |
80 |
10 |
|
|
3 |
Проведение тестирования разработанного программного модуля |
24 |
3 |
|
|
ИТОГО |
480 |
60 |
Таким образом, число дней, затраченных на разработку составляет 60.
Рассчитаем Сизарп в соответствии с формулой (4.3):
Сизарп = 60*815 = 48 900 р.
4.4 Расходы на дополнительную заработанную плату
Учитывают все выплаты непосредственно исполнителям за время не проработанное на производстве, но предусмотренное законодательством, в том числе: оплата очередных отпусков, компенсация за недоиспользованный отпуск, и др. Величина этих выплат составляет 20% от размера основной заработной платы:
4.7
Получаем:
Сз.доп = 0,2*48900 = 9 780 р.
4.5 Отчисления с заработанной платы.
Состоят в настоящее время в уплате единого социального налога. Согласно налоговому кодексу РФ применяются ставки налога для отчисления в федеральный бюджет РФ, фонд социального страхования, фонды обязательного медицинского страхования (федеральный и территориальный фонды).
Отчисления с заработанной платы составляют:
4.8
где НСОЦ - отчисления с заработанной платы в виде единого социального налога.
С 1 января 2006 года ставка единого социального налога составляет:
1) отчисления в федеральный бюджет - 20%;
2) отчисления в фонд социального страхования - 3,2%;
3) отчисления в фонд обязательного медицинского страхования:
3.1) федеральный фонд обязательного медицинского страхования - 0,8%;
3.2) территориальный фонд обязательного медицинского страхования - 2,0%.
Таким образом, ставка единого социального налога составляет 26%.
Тогда отчисления с заработанной платы составят:
Сз.от = (48900+9780)*0,26 = 15 257 р.
4.6 Затраты, связанные с обеспечением работ оборудованием.
В таблице 4.2 представлено оборудование, необходимое для разработки проекта и стоимость этого оборудования.
Таблица 4.2 - Затраты, связанные с обеспечением работ оборудованием
|
№ |
Оборудование |
Стоимость, руб |
|
|
1 |
Системный блок |
15 000 |
|
|
2 |
Монитор |
7 000 |
|
|
3 |
Клавиатура |
500 |
|
|
4 |
Манипулятор «Мышь» |
250 |
|
|
Итого: |
22 750 |
4.7 Расходы на приобретение программного обеспечения.
Для осуществления разработки программного комплекса необходимы следующие программные продукты Microsoft Windows 2003 Server, Microsoft SQL Server 2005 (SE), Borland Delphi 7.0 Enterprise Edition, CA ERwin Data Modeler 7.0. Затраты на программное обеспечение приведены в таблице 4.3
|
№ |
Название программного продукта |
Стоимость, руб |
|
|
1 |
Microsoft Windows 2003 Server |
16 510 |
|
|
2 |
Microsoft SQL Server 2005 (SE) |
143 850 |
|
|
3 |
Borland Delphi 7.0 Enterprise Edition |
30 869 |
|
|
4 |
CA ERwin Data Modeler 7.0. |
60 000 |
|
|
Итого: |
251 229 |
4.8 Накладные расходы, связанные с выполнением проекта.
Накладные расходы составляют 60% от основной заработной платы (4.11)
4.11
Получаем: Снакл = 0,6*48900 = 29 340 р.
Калькуляция стоимости программного продукта.
Калькуляция себестоимости разрабатываемой системы приведена в таблице 4.3.
Таблица 4.3 - Калькуляция стоимости разрабатываемой системы
|
№ |
Статьи затрат |
Стоимость, руб |
|
|
1 |
Основная заработная плата |
48 900 |
|
|
2 |
Дополнительная заработная плата |
9780 |
|
|
3 |
Отчисления на социальные нужды |
15 257 |
|
|
4 |
Затраты на оборудование |
22 750 |
|
|
5 |
Накладные расходы |
29 340 |
|
|
6 |
Расходы на приобретение ПО |
251 229 |
|
|
Итого: |
377 256 |
5. Рекомендации по безопасности жизнедеятельности и экологии
Порядок аттестации рабочего места по условию освещенности регламентируется в МУ 2.2.4.706-98/МУ ОТ РМ 01-98. Согласно им, аттестация рабочих мест по условиям освещения выполняется в несколько этапов:
1) работа с нормативной документацией (см. табл.5.1.);
2) оценка соответствия исполнения применяемых в осветительной установке (ОУ) светильников требованиям по защите от воздействия среды в помещении (табл. 5.3);
3) обследование условий освещения рабочих мест (табл. 5.2);
4) обработка результатов обследования и оформление протокола (приложение В);
5) проверка соответствия показателей освещения нормативным требованиям;
6) оценка условий освещения по гигиеническим критериям в соответствии с руководством Р 2.2.013-94;
7) анализ причин несоответствия условий освещения рабочих мест требованиям нормативных документов и разработка предложений по совершенствованию ОУ с целью приведения условий освещения в соответствие с нормативной документацией.
Работа с нормативной документацией заключается в определении нормативных требований к освещению аттестуемых рабочих мест.
Проверка соответствия исполнения светильников требованиям по защите от воздействия среды в помещении обязательна, если аттестуемые рабочие места расположены в помещениях с тяжелыми условиями среды (взрывоопасных, пожароопасных, с химически активной средой и т. п.).
При несоответствии исполнения светильников требованиям по защите от воздействия среды в помещении аттестация не проводится и дается предписание о необходимости реконструкции ОУ.
Обследование условий освещения заключается в замерах, визуальной оценке или определении расчетным путем следующих показателей:
1) коэффициента естественной освещенности;
2) освещенности рабочей поверхности;
3) показателя ослепленности;
4) коэффициента пульсации освещенности;
5) отраженной блескости (наличия эффективных мероприятий по ее ограничению).
Проверка перечисленных показателей на соответствие их требованиям норм осуществляется путем сопоставления результатов обследования с нормативными величинами, указанными в отраслевых (ведомственных) нормативных документах по искусственному освещению или в СНиП 23-05-95.
При отсутствии для отдельных видов работ отраслевых (ведомственных) норм искусственного освещения нормируемые показатели освещения определяются в зависимости от разряда и подразряда зрительных работ по СНиП 23-05-95.
По результатам аттестации на основе анализа причин неудовлетворительных условий освещения отдельных рабочих мест разрабатываются предложения по совершенствованию ОУ.
Таблица 5.1 - Перечень основных нормативных документов, необходимых для оценки условий освещения
|
№№ п/п |
Статус (ГОСТ, СН, СНиП, МУ и т. д.) и № документа, дата утверждения, ведомство |
Наименование (полное) |
|
|
1 |
СНиП 23-05-95, 02.08.95, Минстрой России |
Строительные нормы и правила Российской Федерации. Естественное и искусственное освещение |
|
|
2 |
Отраслевые (ведомственные) нормативные документы по искусственному освещению утверждены в разное время соответствующими министерствами и ведомствами |
Отраслевые (ведомственные) нормы искусственного освещения предприятий различных отраслей промышленности, правила техники безопасности и производственной санитарии предприятий агропромышленного комплекса |
|
|
№№ п/п |
Статус (ГОСТ, СН, СНиП, МУ и т. д.) и № документа, дата утверждения, ведомство |
Наименование (полное) |
|
|
3 |
ГОСТ 24940-96, 20.10.96, Минстрой России |
Здания и сооружения. Методы измерения освещенности |
|
|
4 |
ГОСТ 26824-86, 30.01.86, Госстрой СССР |
Здания и сооружения. Методы измерения яркости |
|
|
5 |
Р 2.2.013-94, 12.07.94, Госкомсанэпиднадзор России |
Гигиенические критерии оценки условий труда по показателям вредности и опасности факторов производственной среды, тяжести и напряженности трудового процесса |
|
|
6 |
ГОСТ 17677-82, 29.06.87, Госстандарт СССР |
Светильники, общие технические условия |
Таблица 5.2 -Перечень средств измерения для оценки условий освещения
|
№№ п/п |
Наименование (тип) прибора |
Техническая характеристика |
|||
|
Пределы и единицы измерений |
Питание |
Масса, кг |
|||
|
1 |
Люксметр типа "Кварц-21" |
0,1-100000 лк |
Сеть 220 В, 50 Гц; автономное |
0,6 |
|
|
2 |
Люксметр типа "Аргус-01" |
5-200000 лк |
Автономное |
0,25 |
|
|
3 |
Люксметр типа Ю-116 |
5-100000 лк |
Автономное |
1,75 |
|
|
4 |
Люксметр типа Ю-117 |
0,1-100000 лк |
Автономное |
2,0 |
|
|
№№ п/п |
Наименование (тип) прибора |
Техническая характеристика |
|||
|
5 |
Люксметр-яркомер типа "ТКА-04/3" |
10-200000 лк 10-200000 кд/м |
Автономное |
0,39 |
|
|
6 |
Яркомер типа "Аргус-02" |
5-200000 кд/м |
Автономное |
0,35 |
|
|
7 |
Яркомер типа ФПЧ |
0,2-50000 кд/м |
Сеть 220 В, 50 Гц; 12 В |
14,5 |
Таблица 5.3. - Рекомендуемые типы светильников для помещений с различными условиями среды
|
Типовые кривые силы света |
Типы светильников |
|
|
Светильники для нормальных, пожароопасных класса П-11а* и жарких** помещений. Степень защиты не менее 1 Р20 |
||
|
М |
НСП04 |
|
|
Д1 |
ГВП02, ЛВП02, ЛВП05, ЛВП06 |
|
|
Д2 |
ЛД, ЛДОР, ЛСП02, ЛСП06, ГСП18, НСП01, НСП21 |
|
|
ДЗ |
РСП05, РСП08, РСП18, РСП21, ЛСП02, ЛСП0б |
|
|
Г1 |
РСП05, ГСП18, ЛСП13 |
|
|
Г2 |
НСП17, РСП08, РСП18, ГСП18 |
|
|
ГЗ |
ГСП17, РСП05 |
|
|
К1 |
РСП05, РСП08, РСП18, ГСП17, ГСП18, НСП17 |
|
|
КЗ |
ГСП17 |
|
|
Ш1 |
РСП08, ЛСП13, НСП17 |
|
|
Светильники для пыльных*** помещений. Степень защиты не менее 5'Х, IP5X |
||
|
М |
РПП05, ППР |
|
|
Д1 |
ЛВП02, ПВЛП, ПВЛ1, ППР, НСП11, НСП21, РСП11 |
|
|
Д2 |
НСП21, ЖСП20 |
|
|
Типовые кривые силы света |
Типы светильников |
|
|
ДЗ |
ПВЛМ-Д, ПВЛМ-ДО, РСП05, РСП08, РСП12, РСП13, РСП14, РСП16, РСП20 |
|
|
Г1 |
РСП05, РСП13, ГСП18 |
|
|
Г2 |
РСП08, РСП13, ГСП18, НСП17 |
|
|
Г3 |
РСП05, ЖСП01 |
|
|
К1 |
РСП05, РСП08, РСП13, НСП17, ЖСП01 |
|
|
Ш1 |
РСП08, РСП11, РСП20; НСП17 |
|
|
НТ |
РСП11, ЛСП18, НСП02, НСП09 |
|
|
Светильники для помещений с химически активной средой**** Степень защиты не менее 5 '4; IP53 |
||
|
М |
НСП02, НСП03 |
|
|
Д1 |
ЛСП16, ЛСП18, ПВЛП, ПВЛ1, ЛВП02, ЛВП04 |
|
|
Д2 |
ВЛВ, ЖСП21, РСП21 |
|
|
ДЗ |
ЖПП01 |
|
|
Г1 |
ЛВП02, ЛВП04, ЛВП33, РСП13, РСП16 |
|
|
Г3 |
РСП13 |
|
|
К1 |
РСП13 |
|
|
НТ |
ЛСП18 |
|
|
Светильники для пожароопасных помещений классов П-I, П-II. Степень защиты не менее 5 'X (с ЛЛ), IP5X (с ГЛВД и ЛН) |
||
|
|
||
|
М |
РСП27, НСП11, ППР |
|
|
Д1 |
РСП11, РСП12, РСП13, НСП11, НСП22, ППР |
|
|
Д2 |
ЖСП21, РСП21, НСП20, ПВЛМ-ДР, ПВЛМ-ДОР |
|
|
ДЗ |
ПВЛМ-Д, ПВЛМ-ДО, НСП20, РСП20, РСП21 |
|
|
НТ |
ЛСП18, ЛСП22, ПВЛМ, НСП02, НСП09, КОУ1 |
|
|
Светильники для взрывоопасных помещений класса В-1. Степень защиты не менее IP5X (взрывонепроницаемое) |
||
|
М |
ВЗГ, ВЗГ/В4А, РСП25 |
|
|
Д1 |
РСП25, ВЗГ, ВЗГ/В4А |
|
|
Д2 |
ГСП25, РСП25 |
|
|
ДЗ |
ГСП25 |
|
|
НТ |
КОУ1 |
|
|
Типовые кривые силы света |
Типы светильников |
|
|
Светильники для взрывоопасных помещений классов В-Ia, B-II. Степень защиты не менее IP5X (повышенной надежности против взрыва) |
||
|
М |
НОДЛ, НОГЛ, Н4Т4Л, Н4Т5Л, Н4Б, Н4Т2Н, Н4БН |
|
|
Д1 |
НОДЛ, НОГЛ, Н4Т4Л, Н4Т5Л, Н4Б, Н4Т2Н, Н4БН |
|
|
НТ |
КОУ1 |
|
|
* Для помещений класса П-IIа допускается использование светильников в исполнении IР2Х: с ГЛВД - при наличии приспособлений, препятствующих выпадению ламп (РСП18, ГСП18); с ЛЛ - при выполнении ввода в светильник проводом с негорючей оболочкой или в стальной трубе; светильников исполнения 2 `X с ЛН при наличии сплошного защитного стекла или рассеивателя из силикатного стекла. |
||
|
** Рекомендуется применение амальгамных люминесцентных ламп. |
||
|
*** Не рекомендуется применение светильников с решетками, сетками и другими элементами, собирающими пыль. |
||
|
**** Рекомендуется применение светильников, детали которых не подвержены действию данной химически активной среды, желательно с корпусами и отражателями из влагостойкой пластмассы, фарфора или покрытые силикатной эмалью. |
Заключение
В итоге выполнения дипломного проекта были получены следующие основные результаты и выводы:
· Обоснована целесообразность и актуальность разработки системы удаленного тестирования знаний.
· Изучена предметная область вопроса, рассмотрены существующие решения проблемы.
· Рассмотрены и изучены существующие аналоги системы, выявлены их достоинства и недостатки, конкретизированы данные технического задания
· Разработана структура системы в целом и отдельных модулей в частности.
· Разработаны и описаны рабочие алгоритмы системы
· Разработана структура базы данных, используемой системой
· Конкретизированы требования к средам передачи информации
· Описана технология обработки входной информации
Подобные документы
Сетевая система контроля знаний студентов на основе объектно-ориентированного подхода. Выбор программно-технических средств для реализации проекта. Алгоритмическое и программное обеспечение, интерфейс пользователя. Разработка элементов базы данных.
дипломная работа [1,3 M], добавлен 04.02.2013Проектирование логической схемы данных для предметной области, физической модели базы данных. Разработка алгоритмов функциональных модулей программного приложения. Принципы тестирования спроектированного программного обеспечения, анализ эффективности.
курсовая работа [926,7 K], добавлен 20.05.2015Клиент-серверная архитектура проектируемой программы по проверке знаний студентов, структура базы данных. Разработка ее программно-интерфейсной реализации в среде Delphi. Установка и запуск приложения, информация для пользователя, листинг программы.
дипломная работа [2,1 M], добавлен 20.06.2011Разработка концептуальной модели базы данных. Реализация алгоритмов и разработка управляющей программы. Разработка структуры системы управления данными. Методика проведения и результаты тестирования. Функционирование разработанного программного модуля.
курсовая работа [550,5 K], добавлен 08.06.2023Результаты предпроектного обследования завода. Разработка и реализация программного комплекса "Subсontraсting". Информационное и программное обеспечение продукта. Технико-экономическое обоснование внедрения проекта, его безопасность и экологичность.
дипломная работа [5,4 M], добавлен 22.06.2011Возможности создания баз данных средствами программного продукта SQL. Изучение предметной области и разработка проекта базы данных по учету студентов "Журнал классного руководителя". Задачи реализации программного средства, его тестирование и отладка.
курсовая работа [3,7 M], добавлен 07.12.2012Создание сетевой системы тестирования с целью автоматизации процесса контроля знаний, оценивания результатов и создания тестовых заданий. Файлы проекта и их назначение. Описание алгоритмов и модулей программы. Работа с сетью, руководство пользователя.
контрольная работа [928,3 K], добавлен 23.12.2012Технико-экономическое обоснование разработки информационной системы "План-меню". Выбор технических средств и стандартного программного обеспечения. Проектирование структуры базы данных. Разработка и структура пользовательского интерфейса и ER-модели.
курсовая работа [817,6 K], добавлен 07.05.2009Анализ существующих решений для составления расписания репетитора. Разработка архитектуры программного продукта. Выбор инструментальных средств. Проектирование реляционной базы данных. Определение методики тестирования. Реализация интерфейса пользователя.
дипломная работа [411,7 K], добавлен 22.03.2018Проектирование программы в среде Delphi для тестирования знаний студентов по программированию, с выводом оценки по окончанию тестирования. Разработка экранных форм и алгоритма программы. Описание программных модулей. Алгоритм процедуры BitBtn1Click.
курсовая работа [365,0 K], добавлен 18.05.2013
