отчет по практике вводный инструктаж

Инструктаж по прохождению практики

МИНИСТЕРСТВО СПОРТА РОССИЙСКОЙ ФЕДЕРАЦИИ

Федеральное государственное образовательное учреждение высшего образования «Российский государственный университет физической культуры, спорта, молодежи и туризма (ГЦОЛИФК)»

ОТЧЕТ

о прохождении производственной практики

обучающегося группы 3 курса 4

направление подготовки: 43.03.02 «Туризм»

профиль: «Технология и организация туроператорских и турагентских услуг»

Сроки прохождения практики: 27.04.2018-10.05.2018 гг.

Руководитель практики от РГУФКСМиТ: д.с.н., доцент Дусенко С.В.

Заведующий кафедрой: д.с.н., доцент Дусенко С.В.

Содержание

1. Основная часть. 5

1.1. Содержание практики. 5

1.2. Инструктаж по прохождению практики. 6

1.3. Развитие автотуризма в Республике Крым.. 8

1.4. Участие с докладом в студенческой всероссийской конференции, конференции РГУФКСМиТ. 13

Список используемых источников. 16

Введение

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

Согласно Государственному образовательному стандарту на различные виды практики отводится определенное количество учебного времени:

1. Учебно-ознакомительная практика — 3 недели;

2. Производственная практика — 6 недель;

3. Научно-исследовательская и квалификационная практика — 10 недель.

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

Основные задачи практики:

1. Формирование научно-исследовательского мышления;

2. Формирование знания современных навыков и приемов научного исследования;

3. Формирование практических навыков применения современных технических средств и информационных технологий для решения задач НИР;

4. Формирование способности интерпретации полученных экспериментальных и (или) эмпирических данных;

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

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

7. Развитие навыков по изучению и анализу статистических данных в области туризма и гостеприимства.

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

Основная часть

1.1. Содержание практики

Инструктаж по прохождению практики

Инструктаж по охране труда и техники безопасности.

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

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

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

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

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

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

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

Дата добавления: 2018-06-01 ; просмотров: 6610 ; Мы поможем в написании вашей работы!

Источник

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

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

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

Разработка и оформление технического задания.

Распределять технические командные роли.

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

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

2. Основания для разработки

3. Назначение разработки

4. Требования к программе или программному изделию

4.1. Требования к функциональным характеристикам

4.2. Требования к надёжности

4.3. Условия эксплуатации

4.4. Требования к составу и параметрам технических средств

4.5. Требования к информационной и программной совместимости

4.6. Требования к маркировке и упаковке

4.7. Требования к транспортированию и хранению

4.8. Специальные требования

5. Требования к программной документации

6. Технико-экономические показатели

7. Стадии и этапы разработки

8. Порядок контроля и приёмки
Так же я составил техническое задание из предметной области «Электронная коммерция», а конкретнее «Онлайн-магазин растений». Конкретную реализацию технического задания можно увидеть в таблице 1.
Таблица 1

Техническое задание по созданию маркетплейса строительных материалов

Распределение технических командных ролей

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

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

Таблица №2

Построение архитектуры программного средства

Архитектура программного обеспечения (англ. softwarearchitecture) — совокупность важнейших решений об организации программной системы. Архитектура включает:

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

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

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

Создание команды разработчиков.

Работа в системе контроля версий.

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

Создание команды разработчиков.

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

Сильная команда — это такая команда, в которой слабые стороны одного участника перекрываются сильными сторонами другого.

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

Работа в системе контроля версий.

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

1. Установить программу git на вашей системе.
2. Настроить программу и проверить её работоспособность локально.
3. Зарегистрировать ваш аккаунт на GitHub.
4. Создать локальный репозиторий или копировать репозиторий существующего проекта.
5. Написать файл README.MD.
6. В случае, если вы начинаете проект, создать удаленный репозиторий.
7. Фиксировать изменения локально.
8. Отправлять изменения на GitHub.
9. Зарегистрировать аккаунты разработчиков вашего проекта.
10. Выдать им ссылку на проект.

Для наглядности я разместил небольшие рисунки централизованной (Рисунок №1) и распределенной (Рисунок №2) систем.

(Рис.1)

(Рис.2)
Для простоты изучения темы, я написал словарь терминов, непосредственно связанных с данной темой (Таблица №3).

Таблица №3

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

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

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

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

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

(Рис. 3)

Дата выполнения – 29.05.2021. Количество часов – 6 часов.

Интегрирование программных модулей.
Адаптирование программных продуктов и информационных ресурсов к среде функционирования.

Интегрирование программных модулей.

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

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

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

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

Адаптирование программных продуктов и информационных ресурсов к среде функционирования.

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

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

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

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

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

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

Построение диаграммы Последовательности.

Построение диаграммы Кооперации и диаграммы Развертывания.
Проектирование архитектуры программного средства.

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

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

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

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

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

Модуль — это замкнутая программа, которую можно вызвать из любого другого модуля в программе и можно отдельно ком­пилировать.

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

От заказчиков и руководителей проектов до технических писателей, конструкторов, аналитиков, программистов и тестеров — представители каждой роли будут использовать конкретную диаграмму в соответствии со своими потребностями. Это означает, что каждый шаблон требует различного фокуса и уровня детализации. Цель UML — визуально представить диаграммы, которые легко понять каждому.
Построение диаграммы Последовательности.
Для построения диаграммы последовательности используется шаблон UML Sequence из раздела Software and Database программы Visio.

Объекты обычно подписываются в формате «объект:класс» и изображаются как в виде обычных прямоугольников, так и с использованием дополнительных обозначений. В представленном примере объектами являются запрос, обозначенный прямоугольником, а также тренер и клиент, обозначенные элементом «Актер».

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

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

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

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

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

Построение диаграммы Кооперации и диаграммы Развертывания.

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

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

(Рис. 6)

(Рис. 7)

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

(Рис. 9)

Он указывает на то, что в системе участвует объект или субъект. В конце жизненного горизонта появится большой X.

Создание диаграммы Кооперации и диаграммы Развёртывания.

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

Графическое изображение активного объекта (слева) на диаграмме кооперации

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

Каждое сообщение может быть помечено строкой текста, которая имеет следующий формат:

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

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

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

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

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

Артефакты

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

Коммуникационная ассоциация

Устройства

Устройство – это узел, который используется для представления физического вычислительного ресурса в системе. Примером устройства является сервер приложений.

Спецификации Развертывания

Спецификации развертывания – это файл конфигурации, например текстовый файл или XML-документ. В нем описывается, как артефакт развертывается на узле.

Пример диаграммы развертывания рисунок 10.

Построение диаграммы Классов и диаграммы компонентов.

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

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

Диаграмма деятельности для проектируемой предметной области представлена на рисунке 11.

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

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

Триггер-идентификатор — единственное событие, способное вызвать изменение состояния. Пропуск этой части означает, что переход происходит немедленно.

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

Активность — поведение системы во время перехода. Пропуск активности означает, что в процессе перехода ничего не происходит.

Построение диаграммы Классов и диаграммы компонентов.

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

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

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

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

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

Кратность связи или множественность ассоциации — диапазон целых чисел, указывающий возможное количество связанных объектов. Кратность задается путем указания минимального и максимального количества объектов, разделенных двумя точками. Варианты кратности связи: 1 (единица), 0.1 (ноль или один), 0.* (любое значение) и 1.* (один или несколько)

Наследование — отношение типа «общее-частное», при котором один класс обладает поведением и структурой ряда других классов.

Атрибут описывает свойство класса в виде строки текста, имеющей в общем случае следующую структуру.

Операции — действия, реализуемые некоторым классом, т. е. по сути методы класса. Общая форма записи операции. Пример диаграммы классов рисунок 13.

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

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

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

Правила и советы по построению диаграмм потоков данных

Источник