| Общая информация » Каталог студенческих работ » ТЕХНИЧЕСКИЕ ДИСЦИПЛИНЫ » Информационные системы в экономике |
| 27.01.2026, 16:38 | ||||||||||||||||||||||||||||||||||||||||||||
Отчет должен содержать следующие разделы: титульный лист; введение (формулировка темы, то есть формулировка своего варианта разрабатываемой ИС); основную часть отчета (содержание этой части поясняется отдельно для каждой лабораторной работы). Лабораторная работа № 1 Тема: ПОИСК ИНФОРМАЦИИ ДЛЯ РАЗРАБОТКИ ИС Задание: В соответствии с индивидуальным вариантом, используя поисковые системы, тематические каталоги и другие средства сети Internet, осуществить поиск необходимых информационных материалов для разработки индивидуального варианта информационной системы (ИС). В частности, поиск проектной документации на сходную (похожую) информационную систему, исходных текстов программной документации (полностью/частично отдельных модулей, которые можно использовать в разработке индивидуального варианта ИС, руководств и т.п.). Найденная информация будет использоваться при выполнении последующих лабораторных работ. Порядок сдачи лабораторной работы: Представить отчёт о найденных ресурсах и соответствии их содержания выбранной теме. Общие требования к отчету указаны в § 1. Дополнительные требования к отчёту Отчет должен содержать следующую информацию: • организация поиска: средства поиска, атрибуты поиска, использованные ресурсы: • просто поисковые машины Internet, • специализированные поисковые средства, • форумы, • конференции Internet, • новостные рассылки, • иное (указать); • найденные первоисточники (указать адреса); • краткое описание источников (рецензия): оценка содержания, значимость для своей темы, удобство использования, найденные в источнике материалы и т. д.
Лабораторная работа № 2 Тема: ПРЕДПРОЕКТНОЕ ОБСЛЕДОВАНИЕ ФИРМЫ / ОРГАНИЗАЦИИ Цель: Научиться проводить предпроектное обследование фирмы / организации. Задание: Разработать отчёт о предпроектном обследовании фирмы / организации (по индивидуальному варианту) для внедрения в фирме/организации Информационной системы. Содержание отчета должно соответствовать приложенному к заданию примеру. Оформление отчета должно соответствовать требованиям стандартов ГОСТ 19.104-78 ЕСПД. Основные надписи» по оформлению листа утверждения и титульного листа, ГОСТ 24.301-80 Система технической документации на АСУ. Общие требования к выполнению текстовых документов» по оформлению остальной части документа. Порядок сдачи лабораторной работы: Представить отчёт о предпроектном обследовании фирмы/организации (по индивидуальному варианту) для разработки информационной системы. Общие требования к отчету указаны в § 1. Указания к выполнению работы Пример отчета о предпроектном обследовании фирмы приведен в Приложении 1.
Лабораторная работа № 3 Тема: РАЗРАБОТКА ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ К ПРОЕКТУ ИС Цель: Научиться разрабатывать пояснительную записку к проекту ИС. Задание: Разработать пояснительную записку к проекту ИС по индивидуальному варианту. Оформление и содержание пояснительной записки должно соответствовать требованиям стандарта «ГОСТ 19.404-79. ЕСПД. Пояснительная записка. Требования к содержанию и оформлению» и приложенного к заданию примера. Порядок сдачи лабораторной работы: Представить отчёт, содержащий пояснительную записку к проекту ИС фирмы / организации (по индивидуальному варианту) для внедрения в фирме / организации информационной системы. Общие требования к отчету указаны в § 1. Указания к выполнению работы Пример пояснительной записки приведен в Приложении 2.
Лабораторная работа № 4 Тема: РАЗРАБОТКА ТЕХНИЧЕСКОГО ЗАДАНИЯ НА ИС Цель: Научиться разрабатывать техническое задание на ИС. Задание: Разработать техническое задание на ИС по индивидуальному варианту. Оформление и содержание технического задания должно соответствовать требованиям стандарта «ГОСТ 19.201-78. ЕСПД. Техническое задание. Требования к содержанию и оформлению» и приложенного к заданию примера. Порядок сдачи лабораторной работы: Представить отчёт, содержащий техническое задание на ИС фирмы/организации (по индивидуальному варианту) для внедрения в фирме/организации информационной системы. Общие требования к отчету указаны в § 1. Указания к выполнению работы: Пример технического задания приведен в Приложении 3.
Лабораторная работа № 5 Тема: ПОСТРОЕНИЕ МОДЕЛИ БИЗНЕС-ПРОЦЕССОВ ПРЕДПРИЯТИЯ Цель: Научиться строить модель бизнес-процессов предприятия. Задание: 1. Разработать модель бизнес-процессов обследуемого предприятия / организации / фирмы (заказчика), для которой разрабатывается вариант информационной системы. Определить основные, дополнительные, вспомогательные бизнес-процессы, а также бизнес-процесс управления. 2. Определить состав бизнес-функций по каждому бизнес-процессу. Описать работы, выполняемые в рамках каждой бизнес-функции. 3. Определить штат сотрудников для выполнения описанного в пункте 2 состава бизнес-функций. Описать: кто, на каком рабочем месте выполняет перечисленные в пункте 2 работы. Построить матрицу ответственности. По матрице ответственности составить штатное расписание. 4. Построить структуру программного обеспечения проектируемой информационной системы. Уровень детализации: одно рабочее место – один функциональный программный модуль информационной системы. Порядок сдачи лабораторной работы: Представить отчёт, содержащий модель бизнес-процессов предприятия / организации / фирмы (по индивидуальному варианту) для разработки Информационной системы. Общие требования к отчету указаны в § 1. Дополнительные требования к отчёту: Отчет должен содержать следующую информацию: • описание процесса построения бизнес-модели и представление модели бизнес-процессов на рисунке; • состав бизнес-функций (и выполняемых работ по ней) по каждому бизнес-процессу (в виде таблицы); • матрица ответственности: - сверху – бизнес-функции / работы; - слева – подразделения и сотрудники; - на пересечении (в клеточках матрицы) – рабочие места, на которых выполняются соответствующие функции / работы; • штатное расписание в форме таблицы: - подразделение, - по каждому подразделению – должности, - по каждой должности – количество сотрудников данной должности; - структура программного обеспечения проектируемой информационной системы: модули рабочих мест и их взаимосвязи (рисунок); Указания к выполнению работы 1) Общие замечания Здесь используется классическая технология проектирования информационных систем, позволяющая интуитивно ясно и последовательно перейти от миссии фирмы и её целей существования к функциональной структуре фирмы и, соответственно, к структуре программного обеспечения информационной системы. Другие технологии проектирования (основанные на IDEF или основанные на прецендентах) являются более запутанными и не позволяют столь же просто и последовательно перейти от бизнес-модели к структуре ПО ИС. Они требуют большого опыта и дополнительных интеллектуальных усилий для построения структуры ПО на основе разработанного определения функциональности. 2) Построение бизнес-модели Создаётся описание бизнес-процессов фирмы / организации. При этом, как правило, предполагается, что фирма / организация является узкопрофильной, то есть производит только какой-то один товар, или предоставляет только какую-то одну услугу. В реальной жизни это, как правило, не так: большинство фирм / организаций являются многопрофильными. Но при выполнении лабораторной, для упрощения ситуации, предполагается, что фирма / организация – узкопрофильная. При таком предположении задача описания бизнес-процессов существенно упрощается и становится типовой: • выделяется основной бизнес-процесс – это тот, который приносит деньги. Он декомпозируется на составляющие бизнес-функции, то есть, выделяются действия, выполнение которых обеспечивает выполнение этого основного бизнес-процесса (см. примеры ниже, в частности рисунок 1); • помимо основного бизнес-процесса возможно выделение поддерживающих бизнес-процессов (дополнительных к основному, обеспечивающих его выполнение). Например, для библиотеки основным бизнеспроцессом будет обслуживание читателей, а поддерживающими будут бизнес-процессы «книгохранилище» и «комплектация книжного фонда». Эти поддерживающие бизнес-процессы являются затратными, но они непосредственно связаны с основным и поддерживают его выполнение; • поддерживающие бизнес-процессы также декомпозируются на составляющие бизнес-функции. Например, бизнес-процесс «книгохранилище» может декомпозироваться на бизнес-функции: - поиск и выдача единиц хранения; - приём и раскладка единиц хранения; - отслеживание состояния единиц хранения; - ремонт единиц хранения и др. • почти во всех самостоятельных фирмах / организациях существуют бизнес-процессы «управление», «учёт» и «вспомогательные». Учёт – это, обычно, бухгалтерия + формирование различного вида отчётности, выдаваемой вовне по запросам государственных или местных органов власти. Сюда же может входить функция создания рекламы. «Вспомогательный» бизнес-процесс – это бизнес-функции «бухгалтерия», «отдел кадров», «охрана», «уборка» и другие вспомогательные операции, не имеющие прямого отношения к основному бизнес процессу. 3) Состав бизнес-функций и матрица ответственности Даже если информационная система предназначена для автоматизации маленькой фирмы, для более качественного проектирования следует предположить, что объём работ, выполняемых фирмой, требует как минимум 20-30 человек штата. Тогда будут видны (станут заметны) те работы, которые в маленькой фирме со штатом 3-5 человек не видны: их выполняют «по совместительству» (неявно) сотрудники или хозяин фирмы, иногда даже не замечая. В средней же фирме эти работы приходится выделять официально в отдельные бизнес-функции и поручать их выполнение отдельным штатным единицам. 4) Штатное расписание Далее под созданную модель бизнес-процессов, функций (работ) формируется организационная структура фирмы и определяются штатные должности с соответствующими обязанностями, которые будут выполнять бизнес-функции (определённую работу). Каждой бизнес-функции должен соответствовать некоторый сотрудник, который эту функцию выполняет. В противном случае будут функции, которые никто не выполняет, и структурные подразделения (должностные лица), которым нечего делать (см. табл. 2, 3). Подобное нередко происходит при смене или изменении фирмой своей рыночной ниши или, в общем случае, при реорганизации бизнеса, когда от старой организационно-функциональной структуры остаются должности, которые «забыли» убрать. Таким образом, декомпозиция бизнес-процесса – это разложение на бизнес-функции (работы). По некоторым бизнес-функциям возможны более детальные (более глубокие) декомпозиции. 5) Структура ПО Далее по матрице ответственности определяется состав рабочих мест фирмы / организации и принимается решение о том, какие из них будут автоматизироваться (см. табл. 4), то есть определяется список АРМ – автоматизированных рабочих мест, тех рабочих мест, которые будут оснащаться компьютерами и соответствующим ПО разрабатываемой информационной системы. Этот список должен формироваться с учётом требований технического задания на информационную систему, поскольку именно в ТЗ оговаривается, что собственно должно автоматизироваться. Таблица 4 Список АРМ
Определяем взаимосвязи этих автоматизируемых рабочих мест – строим укрупнённую (обобщённую) структуру информационной системы (см. рис. 2). По этой структуре уже видно, какое программное обеспечение (с какой функциональностью) для каждого автоматизируемого рабочего места нужно создавать. Этот документ (рис. 2) является основой для дальнейшей разработки информационной системы. На основе данной структуры далее разрабатываются частные технические задания (ЧТЗ) на компоненты информационной системы: АРМ, программные комплексы, протоколы, интерфейсы и отдельные программы.
Рис. 2. Обобщенная структура ПО информационной системы для небольшой частной типографии На рисунке 2 стрелками показаны информационные связи. Программный интерфейс с СУБД имеют только АРМ «Управление» и «Бухгалтер». Но это не лучшее решение. Более эффективно всем АРМ иметь доступ к СУБД, а права доступа разграничить на уровне таблиц. В АРМ «Дизайнер-1,2,3» имеется отдельная СУБД для хранения архива графических материалов.
Лабораторная работа № 6 Тема: РАЗРАБОТКА АЛГОРИТМА ФУНКЦИОНИРОВАНИЯ АРМ ИС Цель: Научиться разрабатывать алгоритм функционирования АРМ ИС. Задание: В соответствии с индивидуальным вариантом разработать алгоритм функционирования одного АРМ из построенной модели бизнес-процессов предприятия / организации / фирмы. Алгоритм функционирования должен быть представлен в виде блок-схем с пояснениями. Оформление должно соответствовать требованиям стандартов «ГОСТ 19.002–80. ЕСПД. Схемы алгоритмов и программ. Правила выполнения», «ГОСТ 19.003–80. ЕСПД. Схемы алгоритмов и программ. Обозначения условные графические». Порядок сдачи лабораторной работы: Представить отчёт, содержащий алгоритм функционирования АРМ ИС, принадлежащего основному бизнес-процессу, предприятия / организации / фирмы (по индивидуальному варианту). Общие требования к отчету указаны в § 1. Дополнительные требования к отчёту Отчет должен содержать следующую информацию: • спецификация функций; • обобщенный алгоритм действий пользователя; • структура программного обеспечения АРМ; • формы ввода (вид окна, структура меню); • особенности входной информации (формат, диапазон изменения, другие особенности) с привязкой к формам ввода; • формы вывода (отчеты).
Лабораторная работа № 7 Тема: РАЗРАБОТКА СТРУКТУРЫ БАЗЫ ДАННЫХ И КОНТРОЛЬНОГО ПРИМЕРА ДЛЯ АРМ ИС Цель: Закрепить навыки создания структуры базы данных. Задание: Разработать отчет, содержащий структуру базы данных и контрольный пример для АРМ ИС. Должны быть определены: • состав таблиц: по каждой таблице – поля, размерность полей, тип полей; • взаимосвязь таблиц: ключевые атрибуты; • структура: нарисовать структуру базы данных (рисунок рисовать в Inkscape). Контрольный пример должен обеспечить проверку функционирования АРМ ИС, в том числе действий, выполняемых пользователями в процессе эксплуатации, и реакции АРМ на действия пользователей. Описание должно соответствовать требованиям стандартов «ГОСТ 19.301–79. ЕСПД. Программа и методика испытаний. Требования к содержанию и оформлению» и «ГОСТ 34.603–92. Информационная технология. Виды испытаний автоматизированных систем». Порядок сдачи лабораторной работы: Представить отчёт, содержащий структуру базы данных и контрольный пример для АРМ ИС. Общие требования к отчету указаны в § 1. Дополнительные требования к отчёту: Отчет должен содержать следующую информацию: • таблицы описаний атрибутов по каждому отношению базы данных, содержащие названия полей, размерность полей, тип полей; • структуру базы данных в виде рисунка; • контрольный пример в виде таблицы:
Указания к выполнению работы 1) Простейший алгоритм проектирования базы данных. 1. Составляем перечень входных данных. 2. Разделяем данные на группы, описывающие конкретные сущности (объекты). Сущность (объект) – нечто целое, некоторый объект, информация о котором используется / обрабатывается в системе неделимо, совокупно. Например, объект «студент» в ИС «Деканат», или «абонент» в ИС учёта абонентов АТС, или «книга» в ИС «Библиотека», или «квартира» в ИС ЖЭУ, или «достопримечательность» в ИС учёта достопримечательностей, или понятие «вид подключения» в ИС учёта абонентов сотовой связи, или понятие «приход» в ИС торговой фирмы и т. д. 3. В каждой группе данных проверяем функциональную зависимость между ними. Те данные, которые находятся во взаимно однозначном соответствии, остаются в этой группе, иначе разносятся в разные группы, то есть, возможно, создаётся новая группа. 4. Каждая уточнённая группа данных формирует таблицу (отношение) базы данных. В каждую таблицу добавляется первичный ключ «с автоматическим увеличением самой СУБД» (с автоинкрементом). То есть, для каждой записи таблицы добавляется выделенное поле порядкового номера этой записи – это поле и будет первичным ключом в этой таблице. Так лучше делать даже в том случае, если одно из полей таблицы само является/формируется как порядковый номер (например, поле NAbonent формируется как порядковый номер абонента по мере появления новых абонентов; однако абоненты не вечны, приходят и уходят, номер NAbonent однажды освобождается и, если вы будете использовать это поле как первичный ключ, то 1) алгоритм обработки таблицы усложнится, 2) возникнут некоторые ограничения, например, вы не сможете легко сменить N абонента, поскольку первичный ключ не может быть изменён). 5. Проверяем связи между таблицами. 5.1. Если таблицы связаны между собой как «1_к_1», то они имеют один и тот же первичный ключ. 5.2. Если таблицы связаны как «1_к_∞ », то первичный ключ таблицы со стороны «1» копируется в таблицу со стороны «∞ ». И этот ключ становится вторичным ключом в таблице, на стороне «многие». 5.3. Если таблицы связаны как «∞_к_∞ », то создаётся дополнительная таблица, в которую копируются первичные ключи обеих таблиц. Оба эти поля образуют составной первичный ключ дополнительной таблицы. В эту таблицу вносятся также данные, относящиеся одновременно к обоим этим отношениям (таблицам). Примеры структуры базы данных приведены на рис. 3, 4.
2) Контрольный пример – документ с описанием конкретного теста. Основное требование к контрольному примеру – описание проверки и ожидаемых результатов четко определенной самостоятельной части функциональности (или свойств) программного обеспечения, которое должно быть однозначно понятно вам. Разработка контрольных примеров очень сильно завязана на требования, которые и проверяются описанными в них тестами. Вся суть таких контрольных примеров в том, что их можно потом структурировать, превращая в наборы таблиц контроля (при автоматизации тестирования это будут наборы): • таблица контроля (Check-list, он же Suite-набор). Это табличный документ, объединяющий в себе набор контрольных примеров с отметками о результате их исполнения и примечаниями; • отчет о тестировании – результирующий документ, содержащий в себе ссылки на таблицы контроля и выводы о работоспособности релиза с подписями тестера и руководителя проекта. На каждую сборку системы создаются все указанные документы (кроме, естественно, тест-плана). В таком виде их уже достаточно, чтобы по окончании этапа разработки знать, что вся основная функциональность системы была протестирована, и утверждать, что данная сборка работоспособна. Контрольный пример должен обеспечить проверку функций задач во всех режимах, а также проверку информационных связей между задачами. Разработчик должен проверить исходные данные, провести анализ результатов выполнения контрольного примера и исправить ошибки, допущенные при доработке программ. Контрольный пример должен охватывать ошибочные ситуации, которые могут возникнуть при эксплуатации программ в результате некорректности исходной информации. Для этого следует использовать искусственно подобранные ошибочные данные для проверки работоспособности программ. Примечание. Хранилище данных и версионность. На файл-сервере может формироваться общий ресурс, в котором создаются папки на каждый проект. Каждая такая папка содержит следующие элементы: · файл с тест-планом; · файл с шаблоном отчета о тестировании; · каталог TestCase с набором контрольных примеров по данному проекту; · каталог Builds, в котором в отдельных папках хранятся отработанные контрольные примеры по данной сборке (практически, копия папки TestCase, документы из которой используются в качестве шаблонов) и отчет о тестировании. Для начала и дальнейшего использования подобной структуры вполне хватит для контроля процесса тестирования. Желательно в папку каждой сборки системы вкладывать файл со списком требований на данную итерацию.
Лабораторная работа № 8 Тема: НАСТРОЙКА ЛОКАЛЬНОЙ СЕТИ В УСЛОВИЯХ ОТСУТСТВИЯ DNS Цель: Научиться настраивать локальную сеть в условиях отсутствия DNS. Задание: Необходимо получить стандартно работающую локальную сеть, в которой обращение к другому компьютеру локальной сети обеспечивается: • при указании ip-адреса компьютера; • по полному имени компьютера; • по имени host'а компьютера. Для проверки правильности настройки сети на всех компьютерах установить сервис telnet. Порядок сдачи лабораторной работы 1. Выполнить необходимые работы по настройке сети на компьютерах лаборатории. 2. Продемонстрировать доступность компьютеров сети по командам: $ telnet 127.0.0.1 $ telnet localhost.localdomain $ telnet localhost $ telnet <ip-адрес своего компа> $ telnet <полное имя своего компа> $ telnet <hostname своего компа> $ telnet <ip-адрес другого компа> $ telnet <полное имя другого компа> $ telnet <имя host'а другого компа> 3. Представить отчёт, содержащий описание процесса настройки локальной сети в условиях отсутствия DNS. Общие требования к отчету указаны в § 1. Дополнительные требования к отчёту: Отчет должен содержать следующую информацию: • описание выполненных работ по настройке компьютеров для работы в сети; • содержание изменённых в процессе настройки конфигурационных файлов; • скрины, демонстрирующие выполнение указанных в п. 2 команд; • методику «Порядок правильной настройки локальной сети». Указания к выполнению работы 1) Общие сведения 1. Определение (для стека протоколов TCP/IP) Сеть называется локальной, если • все компьютеры доступны непосредственно по физическому адресу; • все компьютеры сети имеют общее (одно и то же) доменное имя; • все компьютеры имеют ip-адреса из одной сети класса А, В или C. 2. Для выполнения лабораторной работы используется следующее аппаратно-программное обеспечение лаборатории: • дистрибутивы Linux; • 6 компьютеров, коммутатор, кабели. 3. DNS не установлен. 4. Сервис telnet может быть заменён на сервис ssh. 2) Краткое руководство по настройке ЛВС Необходимость «правильной» настройки локальной сети обусловливается тем, что некоторые сервисы (почта, ftp, web и некоторые другие) не смогут работать полностью или частично, если разрешение имён работает неверно или не работает вовсе. Настройка сети выполняется в три шага (на «раз-два-три»): Шаг 1. Определение домена и политики именования host'ов. Здесь необходимо выбрать домен для локальной сети. Если данная ЛВС является частью корпоративной сети фирмы и домен фирмы уже существует, то поддомен для данной ЛВС определяется просто как поддомен существующего домена (даже если создаваемая сеть находится в удалённом филиале). Если сеть вновь создаваемая для (пока ещё) небольшой фирмы, то необходимо определить новое доменное имя второго уровня (как правило). Причём при подборе доменного имени нужно исходить из предположения, что фирма будет бурно расти в ближайшие годы и домен, вероятно, • будет делиться на поддомены в соответствии с ростом организационной структурой фирмы; • его придётся регистрировать официально как доменное имя данной фирмы у некоторого регистратора (например, в РосНИИРОС, www.nic.ru). Поэтому рекомендуется сразу, подобрав доменное имя, проверить его на уникальность с помощью сервиса whois (например, на www.nic.ru). При подборе имени следует руководствоваться двумя правилами: имя должно быть максимально коротким и имя должно соответствовать миссии и цели фирмы (бренду), то есть, быть осмысленным. В результате будем иметь некоторый домен второго уровня, например, firma.ru. Соответственно host'ы будут теперь именоваться например так: comp1.firma.ru, comp2.firma.ru, . . ., compN.firma.ru. Здесь firma.ru – доменная часть имени host'а, compM – hostname, compM.firma.ru – полное (каноническое) имя компьютера. Примечание. (Очень важно!) При реальном выполнении данного шага в некоторой фирме настоятельно рекомендуется согласовать с руководством (собственником) фирмы и сам домен фирмы, и порядок присвоения имён компьютерам. Для этого следует написать и утвердить служебную записку, проект решения «О домене и именовании компьютеров», правила именования. Данный подход ограничит пользователей в именовании своих машин и обезопасит ИТ-персонал от обвинений в самоуправстве. Шаг 2. Определение политики присвоения IP-адресов. Здесь также нужно исходить из предположения, что фирма будет бурно расти в ближайшие годы и ЛВС будет делиться на подсетки в соответствии с ростом организационной структурой фирмы. Также следует иметь в виду, что с ростом структуры фирмы появятся требования по разграничению доступа и защите, а функции разграничения доступа и защиты базируются на проверке IP-адресов по маскам. В настоящее время в основном используется протокол IP верcии 4 (IPV4) и имеет место дефицит «белых» (настоящих интернетовских) IPадресов. Очень часто фирмы имеют один-два «белых» адреса для обеспечения связи с Интернет, а для адресации компьютеров внутри фирмы используют «приватные» адреса из сеток 10.0.0.0, 172.16-32.0.0, 192.168.0.0. Поэтому самое простое и надёжное решение здесь – это выбор сеток из диапазона 192.168.0.0. Именно этот диапазон сеток рекомендуется использовать в небольших и средних фирмах по следующим причинам: а) количество доступных для использования адресов в сетке класса С–254, а редко в каком подразделении малого и среднего бизнеса требуется количество компьютеров больше этого числа; б) всего в диапазоне 192.168.0.0 может быть использовано 254 сетки (сетки 0 и 255 использовать не рекомендуется), а редко в какой фирме малого и среднего бизнеса имеется более 254 подразделений; в) защита базируется на проверке ip-адресов по маскам и, – если вы придерживаетесь правила: каждому подразделению – отдельную сетку класса С, то авария / сбой / ошибка может привести к «слёту» маски, и по умолчанию она восстановится снова в нужном виде, то есть 255.255.255.0, и, следовательно, защита не будет нарушена; – если же вы используете сетку класса А (10.0.0.0) и делите её искусственно на подсетки с помощью масок, то в аналогичной ситуации все маски по умолчанию восстановятся к виду 255.0.0.0 и защита нарушится; – кроме того, сам по себе расчёт и проверка масок – совсем не тривиальная задача, а защиту проверять нужно постоянно. Таким образом, при выборе сетки адресов для локальной сети необходимо выбирать сетку из диапазона 192.168.0.0. Шаг 3. Правка конфигурационных файлов На этом шаге необходимо исправить конфигурационные файлы сетевого интерфейса eth0 (сетевой платы) и конфигурационные файлы резолвера. Полшага 3.1. Конфигурационные файлы интерфейса Наиболее просто их поправить с помощью «Центра управления системой» (раздел «Сеть»). На страничке «Сетевые интерфейсы» необходимо ввести полное доменное имя компьютера, как определено на шаге 1, переключить порядок присвоения ip-адреса из «автоматического» в «ручное» и ввести ip-адрес сетевой карты в соответствии с шагом 2. Можно их исправить и вручную: для ALTLinux версии 4 конфигурационные файлы сетевого интерфейса находятся в каталоге /etc/net/ifaces/, а hostname определяется в файле /etc/sysconfig/network. Если в локальной сети есть компьютеры с ОС Windows, то необходимо тоже исправить имя компьютера, определить доменное имя, переключить порядок определения адреса на ручной и ввести ip-адрес на страничке определения сетевого интерфейса «Панели управления». Проверка правильности настройки интерфейсов может быть выполнена с помощью команды ping. Полшага 3.2. Конфигурационные файлы резолвера: – файл /etc/host.conf – определяет порядок разрешения имен и адресов, он должен содержать строчку order hosts,bind или просто hosts bind Это означает, что резолвер сначала будет смотреть файл hosts, а если в нём соответствия имя-адрес не найдено – обращаться дальше; – файл /etc/hosts – локальная база резолвера – должен содержать следующее
Здесь первая строчка – определение адреса и имени для интерфейса локальной петли (lo0), последующие строчки – определение адресов и имён для интерфейсов сетевых плат всех компьютеров ЛВС (интерфейсов eth0) в предположении, что для локальной сети выбрана сетка 192.168.199.0. Замечание 1. Файл должен содержать определение интерфейсов для всех компьютеров локальной сети, если какой-либо компьютер не будет описан в этом файле или в строчке описания будет ошибка, то этот компьютер не будет виден в сети и, следовательно, недоступен. Замечание 2. Этот файл должен быть одинаковым на всех компьютерах ЛВС, в том числе, на тех на которых установлена ОС Windows. В ОС Windows этот файл находится по пути C:\windows\system32\drivers\etc\ и по умолчанию называется hosts.SAM. Его необходимо исправить, как указано выше, и сохранить под именем hosts. В результате выполнения данных трёх шагов имеем правильно настроенную локальную сеть, в которой полностью будет выполняться пункт 2 раздела «Порядок сдачи лабораторной работы». Дополнительно можно продемонстрировать работу интерфейсов с помощью команды ping.
Лабораторная работа № 9 Тема: РАЗРАБОТКА ПРОГРАММ СОЗДАНИЯ / ПРОВЕРКИ ЭЦП Цель: Научиться разрабатывать программы на языке С под ОС Linux. Задание: Разработать программу создания/проверки ЭЦП согласно указаниям к выполнению работы. Программа должна быть написана на языке С в ОС Linux. Для разработки может использоваться любой дистрибутив ОС Linux, но программа должна быть работоспособна в ОС Linux, установленной в лаборатории. В качестве сред разработки может быть использовано: • текстовый редактор (например, kate, kwrite, встроенный редактор mc) + gcc (компилятор); • IDE Eclipse. Интерфейс с пользователем – текстовый. Порядок сдачи лабораторной работы: 1. Скомпилировать программы, возможно что-то изменив (по указанию), на компьютерах лаборатории. 2. Выполнить программы на некотором файле. Файл и ключ будет указаны. 3. Представить отчёт. Общие требования к отчету указаны в § 1. Дополнительные требования к отчёту Отчет должен содержать следующую информацию: • краткое описание процесса создания и компиляции; • исходные тексты программ в бумажном и электронном виде. Указания к выполнению работы В задании используется достаточно простой алгоритм вычисления ЭЦП, но позволяющий понять принципы использования ЭЦП. 1) Простой алгоритм программы создания ЭЦП 1.1. Программа должна обрабатывать документы (в данном варианте – только текстовые) объёмом до 100 (ста) килобайт. 1.2. Интерфейс с пользователем текстовый. 1.3. Определяется следующая структура памяти, в которую будет считываться подписываемый документ: union ecp_tip { unsigned long int ecpl [25000]; char *ecpc [100000]; }; 1.4. Диалог программы. Вводятся: • ФИО полностью в переменные strf, stri, strf; • ключ в переменную структуры union key_tip { unsigned long int keyl; char *keyc[4]; }; • имя подписываемого файла в переменную namefile. Ключ вводится как четыре символа, причём при вводе ключа желательна проверка, что символы вводятся разные. 1.5. Открывается файл документа и считывается в ecpc потоком, то есть, вместе с символами «конец строки», «перевод каретки» и прочими символами форматирования. Это значит, следует читать, пока не достигнут конец файла, но его размер не должен превышать 100 килобайт. 1.6. В конец ecpc добавляется ФИО: strcat (ecpc, '\n'); strcat (ecpc, strf); strcat (ecpc, '\n'); strcat (ecpc, stri); strcat (ecpc, '\n'); strcat (ecpc, stro); 1.7. В конец ecpc добавляется дата и время подписания документа: strcat (ecpc, '\n'); strcat (ecpc, date(...)); strcat (ecpc, '\n'); strcat (ecpc, date(...)); strcat (ecpc, '\n'); 1.8.Вычисляется, сколько полных unsigned long int помещается в ecpc и запоминается в переменной n. Последний неполный unsigned long int дополняется нулями (двоичными!). Получается n+1 (в случае наличия неполного unsigned long int). 1.9. Вычисляется hash-функция следующим образом: n+1 hash = Σ ecpl[i]*i i=1 1.10. Складываются побитово два unsigned числа: ecp = hash | keyl; 1.11.Добавляется полученное ecp к файлу подписываемого документа: strcat (ecpc, ecp); strcat (ecpc, '\n'); 1.12. Сохраняется ecpc в файл с именем: namefile+'ecp'.«тип файла тот же». 2) Алгоритм программы проверки ЭЦП 2.1. Аналогичен п. 1.1-1.3. 2.2. Диалог программы. Вводим: • ключ в переменную структуры union key_tip { unsigned long int keyl; char *keyc[4]; }; • имя полученного файла в переменную namefile. 2.3. Аналогичен п. 1.5. 2.4. Удаляем из ecpc цифровую подпись ecp и сохраняем её. 2.5. Вычисляем n+1 по п. 1.8. 2.6. Вычисляем hash-функцию по п. 1.9. 2.7. Складываем побитово два unsigned числа: ecp1 = hash | keyl; 2.8. Сравниваем ecp и ecp1. Равно? Тогда «Документ неизменён.». Иначе «Документ плохо хранили!».
Лабораторная работа № 10 Тема: ПРЕОБРАЗОВАНИЕ ПРОГРАММ СОЗДАНИЯ / ПРОВЕРКИ ЭЦП В АРХИТЕКТУРУ КЛИЕНТ-СЕРВЕР Цель: Научиться разрабатывать программы клиент-серверной архитектуры. Задание: Разработать программу создания / проверки ЭЦП в клиентсерверной архитектуре. Программа должна быть написана на языке С в Linux. Для разработки может использоваться любой дистрибутив ОС Linux, но программа должна быть работоспособна в ОС Linux, установленной в лаборатории. В качестве сред разработки могут быть использованы: • текстовый редактор (например, kate, kwrite, встроенный редактор mc) + gcc (компилятор); • IDE Eclipse. Интерфейс с пользователем – текстовый. Порядок сдачи лабораторной работы: 1. Скомпилировать программы, возможно, что-то изменив (по указанию), на компьютерах лаборатории. 2. Выполнить программы на некотором файле. Файл и ключ будут указаны. При этом клиент должен запускаться на одной ПЭВМ, а серверная часть – на другой. 3. Представить отчёт. Общие требования к отчету указаны в § 1. Дополнительные требования к отчёту Отчет должен содержать следующую информацию: • краткое описание процесса создания и компиляции; • исходные тексты программ в бумажном и электронном виде.
Лабораторная работа № 11 Тема: РАЗРАБОТКА ГРАФИЧЕСКОЙ ОБОЛОЧКИ ДЛЯ ПРОГРАММЫ СОЗДАНИЯ / ПРОВЕРКИ ЭЦП Цель: Научиться разрабатывать графические оболочки для клиентской части. Задание: Разработать графическую оболочку для программы создания / проверки ЭЦП. Программа должна быть написана на языке С++ в ОС Linux. Для разработки может использоваться любой дистрибутив ОС Linux, но программа должна быть работоспособна в ОС Linux, установленной в лаборатории. В качестве сред разработки могут быть использованы: • Qt-designer; • IDE Eclipse. Интерфейс с пользователем – графический. Порядок сдачи лабораторной работы: 1. Скомпилировать программы, возможно что-то изменив (по указанию), на компьютерах лаборатории. 2. Выполнить программы на некотором файле. Файл и ключ будет указаны. 3. Представить отчёт. Общие требования к отчету указаны в § 1. Дополнительные требования к отчёту Отчет должен содержать следующую информацию: • краткое описание процесса создания и компиляции; • исходные тексты программ в бумажном и электронном виде.
Лабораторная работа № 12 Тема: РАЗРАБОТКА ПРИЛОЖЕНИЯ КЛИЕНТ-СЕРВЕРНОЙ АРХИТЕКТУРЫ ДЛЯ ЛОКАЛЬНОЙ СЕТИ Цель: Научиться разрабатывать программы клиент-серверной архитектуры. Задание: Разработать приложение, реализующее функционирование АРМ ИС (см. лаб. работы № 6, 7), в клиент-серверной двухуровневой архитектуре для локальной сети. Программа должна быть написана на языке С в ОС Linux. В качестве СУБД использовать MySQL. Для разработки может использоваться любой дистрибутив ОС Linux, но программа должна быть работоспособна в ОС Linux, установленной в лаборатории. В качестве сред разработки могут быть использованы: • текстовый редактор (например, kate, kwrite, встроенный редактор mc) + gcc (компилятор); • IDE Eclipse. Интерфейс с пользователем – текстовый. Порядок сдачи лабораторной работы: 1. Скомпилировать программы, возможно что-то изменив (по указанию), на компьютерах лаборатории. 2. Выполнить программу на одном из компьютеров лаборатории, MySQL должна быть запущена на другом компьютере. В процесс сдачи входит также правильная настройка сети (доступ к другой машине по имени компьютера – см. лаб. работу № 7) и обеспечение старта СУБД MySQL при включении компьютера. 3. Демонстрация работоспособности приложения будет происходить следующим образом. На ПЭВМ-1 запустить разработанную программу, которая должна проделать следующие действия: • подключиться к СУБД MySQL, запущенной на ПЭВМ-1; • зайти root'ом (пароль не задан); • создать базу с названием ФИО (первые буквы ФИО латинскими буквами); • создать пользователя «имяОФ» (имя_полностью+первые_буквы_отчества_и_фамилии латинскими буквами и с таким же паролем); • предоставить необходимые права пользователю на созданную ранее базу; • выйти из MySQL. На ПЭВМ-2 запустить разработанную программу, которая должна проделать следующие действия: • подключиться к MySQL, запущенной на ПЭВМ-1; • зайти созданным пользователем; • подключиться к базе данных; • создать в базе данных таблицы в соответствии с разработанной структурой базы данных; • записать в них данные контрольного примера; • запросить данные из таблиц; • отобразить их на экран в форме разграфлённой таблицы; • выйти из MySQL; • завершить программу, получив правильный код возврата. 4. Представить отчёт. Общие требования к отчету указаны в § 1. Дополнительные требования к отчёту Отчет должен содержать следующую информацию: • краткое описание процесса создания и компиляции; • исходные тексты программ в бумажном и электронном виде.
Лабораторная работа № 13 Тема: ПРЕОБРАЗОВАНИЕ ПРИЛОЖЕНИЯ КЛИЕНТ-СЕРВЕРНОЙ АРХИТЕКТУРЫ ДЛЯ ЛОКАЛЬНОЙ СЕТИ К ТРЁХУРОВНЕВОЙ АРХИТЕКТУРЕ С ТОНКИМ КЛИЕНТОМ Цель: Научиться разрабатывать приложение трёхуровневой архитектуры с тонким клиентом. Задание: Преобразовать приложение, реализующее функционирование АРМ ИС (см. лаб. работу № 12) в клиент-серверной двухуровневой архитектуре для локальной сети, к трёхуровневой архитектуре с тонким клиентом. Программа должна быть написана на языке С в ОС Linux. В качестве СУБД использовать MySQL. Для разработки может использоваться любой дистрибутив ОС Linux, но программа должна быть работоспособна в ОС Linux, установленной в лаборатории. В качестве сред разработки может быть использовано: • текстовый редактор (например, kate, kwrite, встроенный редактор mc) + gcc (компилятор); • IDE Eclipse. Интерфейс с пользователем – текстовый. Порядок сдачи лабораторной работы: 1. Скомпилировать программы, возможно что-то изменив (по указанию), на компьютерах лаборатории. 2. Выполнить программу на компьютерах (двух или трёх) лаборатории, СУБД MySQL должна быть запущена на одном компьютере, сервер – на нём же, или на втором, клиент – на третьем компьютере. В процесс сдачи входит также правильная настройка сети (доступ к другой машине по имени компьютера) и обеспечение старта СУБД MySQL при включении компьютера. 3. Демонстрация работоспособности приложения должна происходить следующим образом. На ПЭВМ-1 запустить первую разработанную программу, которая должна проделать следующие действия: • подключиться к СУБД MySQL, запущенной на ПЭВМ-1; • зайти root'ом (пароль не задан); • создать базу с названием ФИО (первые буквы ФИО латинскими буквами); • создать пользователя «ИмяОФ» (имя_полностью+первые_буквы_отчества_и_фамилии латинскими буквами и с таким же паролем); • предоставить необходимые права пользователю на созданную ранее базу; • выйти из MySQL. На ПЭВМ-2 запустить серверную часть разработанной программы. На ПЭВМ-3 запустить клиентскую часть разработанной программы, которая должна проделать следующие действия: • подключиться к серверу, запущенному на ПЭВМ-2; • передать серверу запрос на подключение к нужной базе данных созданным пользователем; • передать серверу запрос на создание в базе данных таблиц в соответствии с разработанной структурой базы данных; • передать серверу запрос на запись в них данных из контрольного примера, передать серверу сами данные; • передать серверу запрос на получение данных из таблиц; • полученные от сервера данные отобразить на экран в форме разграфлённой таблицы; • передать серверу запрос на отключение от СУБД MySQL; • отключиться от сервера, сервер должен остаться в состоянии ожидания; • завершить программу с выдачей правильного кода возврата. 4. Представить отчёт. Общие требования к отчету указаны в § 1. Дополнительные требования к отчёту Отчет должен содержать следующую информацию: • краткое описание процесса создания и компиляции; • исходные тексты программ в бумажном и электронном виде.
Лабораторная работа № 14 Тема: РАЗРАБОТКА ГРАФИЧЕСКОЙ ОБОЛОЧКИ ДЛЯ КЛИЕНТСКОЙ ЧАСТИ ПО АРМ Цель: Научиться разрабатывать графические оболочки для клиентской части. Задание: Разработать графическую оболочку для клиентской части ПО АРМ (см. лаб. работу № 13). Программа должна быть написана на языке С++ в ОС Linux. Для разработки может использоваться любой дистрибутив ОС Linux, но программа должна быть работоспособна в ОС Linux, установленной в лаборатории. В качестве сред разработки может быть использовано: • Qt-designer; • IDE Eclipse. Интерфейс с пользователем – графический. Примечание. В данной лабораторной работе не может использоваться интерфейсный модуль из лабораторной работы № 10. Межпроцессное взаимодействие с помощью сокетов должно реализовываться средствами библиотеки Qt. Порядок сдачи лабораторной работы: 1. Скомпилировать программы, возможно, что-то изменив (по указанию), на компьютерах лаборатории. 2. Выполнить программу на компьютерах лаборатории, СУБД MySQL должна быть запущена на одном компьютере, разработанная программа – на другом. В процесс сдачи входит также правильная настройка сети (доступ к другой машине по имени компьютера) и обеспечение старта СУБД MySQL при включении машины. 3. Представить отчёт. Общие требования к отчету указаны в § 1. Дополнительные требования к отчёту: Отчет должен содержать следующую информацию: • краткое описание процесса создания и компиляции; • исходные тексты программ в бумажном и электронном виде. | ||||||||||||||||||||||||||||||||||||||||||||
