ПГУТИ, операционные системы и оболочки (курсовая работа)

Задание и выбор варианта курсовых работ

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

1. Разработка графического интерфейса.

2. Разработка программного обеспечения.

3. Обеспечение минимального функционала.

4. Добавление дополнительного функционала.

5. Выбор стратегии тестирования и разработка тестов.

6. Формирование отчета по курсовой работе.

Варианты заданий:

1. Способ межпроцессного взаимодействия «Суперапп» и всплывающих окон: Отображение файлов – для последней цифры [1 и 2] зачетной книжки, Сокеты — [3 и 4], Каналы — [5 и 6], Очередь сообщений — [7 и 8] и Разделяемая память — [9 и 0].

Примечание: студент вправе предложить реализовать свое межпроцессное взаимодействие!

2. Отслеживание всех процессов ОС, кроме процессов, запущенных из разрабатываемого приложения, для последних цифр зачетных книжек [1-5] и отслеживание только процессов, запущенных из разрабатываемого приложения «Суперапп» [6-0] номера.

3. В разрабатываемом приложение должен присутствовать терминал Linux и иметь следующий набор: сетевые команды и команды для работы с файловой системой - для четных номеров зачетной книжки; команды управления процессами и команды для работы с устройствами ввода/вывода – не четные.

4. Функционал для «Суперапп» распределяет преподаватель каждому отдельно:

1) имя компьютера;

2) имя пользователя;

3) информация о пользователях ОС;

4) версию операционной системы;

5) информация о видеокарте;

6) информация об устройстве ПЗУ;

7) информация о звуковой карте;

8) информация об устройствах ввода/вывода;

9) имя процесса приложения;

10) время работы выбранного процесса;

11) время работы ОС;

12) процент используемой физической памяти;

13) процент используемой виртуальной памяти;

14) PID процесса;

15) приоритет процесса;

16) пользователь выбранного процесса;

17) количество пользовательских процессов;

18) количество системных процессов;

19) всего процессов;

20) всего потоков;

21) информация о статусе беспроводной сети;

22) информация о сетевых настройках;

23) текущее местное время;

24) продолжительность текущего сеанса работы пользователя;

25) информация о процессоре;

26) загрузка каждого ядра ЦП в %;

27) общая загрузка процессора в %;

28) размер файла подкачки в байтах;

29) количество свободных байтов файла подкачки;

30) ширину и высоту рамки окна приложения;

31) ширину и высоту экрана;

32) значение загрузки процессора данным процессом;

33) количество модулей, используемых процессом;

34) размер рабочего множества страниц;

35) завершение прикладного процесса, выбранного из списка;

36) счетчик количества созданных описателей (дескрипторов);

37) маска привязки процесса к процессорам;

38) количество страничных ошибок;

39) изменение приоритета выбранного процесса;

40) время старта процесса (час: мин: сек);

41) количество потоков процесса;

42) значение размера используемой оперативной памяти;

43) пиковое значение размера используемой виртуальной памяти;

44) обнаружение фактов создания файлов;

45) обнаружение фактов создания каталогов;

46) обнаружение фактов переименования файлов;

47) обнаружение фактов переименования каталогов;

48) для процесса, выбранного с помощью ввода его PID, вывести список его дочерних процессов (имя процесса, PID, время работы в системе);

49) вывод в текстовый файл списка процессов, завершивших выполнение в период работы монитора;

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

Пояснение

Задание 1. Разработка графического интерфейса. Рекомендуемый срок выполнения 6 неделя.

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

Для создания интерфейса допускается только Figma (https://www.figma.com/).

Задание 2. Разработка ПО. Рекомендуемый срок выполнения 7 неделя. Разрабатывается приложение «Суперапп» под любую версию& ОС Linux.

Создается корневая папка как среда работы «Суперапп» (в приложение отображаются только вложенные папки). Создать папку «Корзина» аналогичная ОС. Обеспечить удаление, как в корзину, так и безвозвратно. Создается папка «System», содержит все необходимые файлы (исполняемые) для работы приложения (ее удалить, переименовать или переместить нельзя). Так же создаются рабочие папки (произвольные). Защитить папку «System» от удаления/переименования (рис. 1). Сделать основное и контекстное меню (аналогичные выбранной ОС). В основное меню добавить пункт «О программе» - Операционные системы и оболочки, Язык программирования, ФИО и группа разработчика.

Скриншоты из среды разработки обязательны, так же сделать к ним пояснения.

Рис. 1 – Иерархия папок в приложение

Задание 3. Обеспечение минимального функционала. Рекомендуемый срок выполнения 9 неделя.

Обеспечить взаимодействие со съемными носителями, подключаемые к ОС.

Позволить через приложение запуск встроенных системных утилит ОС.

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

Добавить в программу поддержку горячих клавиш, не менее 5. Информацию по горячим клавишам внести в пункт меню «Справка». Также сделать поддержку Drag and Drop.

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

Добавить функцию поиска файлов и папок во вложенных папках «Суперапп».

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

Задание 4. Добавление дополнительно функционала. Рекомендуемый срок выполнения 12 неделя.

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

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

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

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

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

Лог-файл – это текстовый файл, в котором хранится информация о посещениях и параметрах посещений Файлового менеджера, которые возникали на нем.

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

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

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

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

Каналы (pipe). Существует два способа организовать двунаправленное соединение с помощью каналов: безымянные и именованные каналы.

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

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

Socket - «сокет». Используется для взаимодействия между сетевыми процессами.

Если двум процессам необходимо взаимодействовать, то можно однозначно идентифицировать процесс. Локальное межпроцессное взаимодействие (PIPE, FIFO, очередь сообщений, семафор, общая память) может однозначно идентифицировать процесс по идентификатору процесса. Однако PID уникален только локально, и существует высокая вероятность конфликта PID между двумя процессами в сети. IP-адрес уровня IP может однозначно идентифицировать хост, а протокол уровня TCP и номер порта могут быть однозначно идентифицированы Процесс хоста, поэтому можно использовать IP-адрес + протокол + номер порта для однозначной идентификации процесса в сети.

Socket разработан для модели «клиент / сервер» (C / S), обеспечивая различные системные вызовы Socket для клиентских и серверных программ. Этот режим грамотно решает проблему установления коммуникационного соединения между процессами. Серверный сокет будет объявлен стороне, которая должна связаться.

После перехода в режим C / S клиент инициирует запрос, и сервер получает запрос и отвечает, чтобы установить хорошее соединение.

Очередь сообщений (Message queues). Механизм межпроцессного взаимодействия в Linux. Позволяет процессам асинхронно отправлять и получать сообщения через общую очередь сообщений. Каждое сообщение в очереди имеет тип и размер, что облегчает взаимодействие между различными типами процессов.

Очереди сообщений в Linux создаются с помощью функции msgget(). Процессы могут отправлять сообщения в очередь с помощью функции msgsnd() и получать сообщения из нее с помощью функции msgrcv().

Разделяемая память (shared memory). В случае разделяемой памяти два или более процессов совместно используют сегмент памяти.

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

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

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

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

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

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

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

Синтаксис системного вызова shmget выглядит следующим образом:

shmid = shmget(key, size, flag);

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

Задание 5. Выбор стратегии тестирования и разработка тестов. Определить критическую секцию. Рекомендуемый срок выполнения 15 неделя.

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

Стратегия тестирования отвечает на вопросы:

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

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

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

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

Проектирование тестов можно начинать сразу же после завершения этапа внешнего описания ПО.

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

· на каждую используемую функцию или возможность - хотя бы один тест;

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

· на каждую особую (исключительную) ситуацию, указанную в спецификациях, - хотя бы один тест.

Рассмотрим подробнее методики тестирования «чёрный ящик» и метод тестирования «белый ящик».

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

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

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

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

пройдена (выполнена) хотя бы один раз.

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

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

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

Таблица 1

Образец для заполнения тест-требований

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

1. Значения исходных данных (во всех функциях ПС исходные данные- объекты файловой системы компьютера) - исходные данные отображаются в программе «Суперапп» верно.

2. Ожидаемый результат - выполнение соответствующих функций ПС над объектами файловой системы компьютера.

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

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

5. Возникаемые ошибки и их описание.

Таблица 2

Результаты тестирования приложения

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

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

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

Задание 6. Формирование отчета по курсовой работе. Рекомендуемый срок выполнения 16 неделя.

Оформление отчета по требованиям и отправка его на проверку.

Назначается дата и время защиты.

Контрольные вопросы

1. Имя компьютера.

2. Имя пользователя.

3. Информация о пользователях ОС;

4. Версию операционной системы.

5. Информация о видеокарте.

6. Информация об устройстве ПЗУ.

7. Информация о звуковой карте.

8. Информация об устройствах ввода/вывода.

9. Имя процесса приложения.

10. Время работы выбранного процесса.

11. Время работы ОС.

12. Процент используемой физической памяти.

13. Процент используемой виртуальной памяти.

14. PID процесса.

15. Приоритет процесса.

16. Пользователь выбранного процесса.

17. Количество пользовательских процессов.

18. Количество системных процессов.

19. Всего процессов.

20. Всего потоков.

21. Информация о статусе беспроводной сети.

22. Информация о сетевых настройках.

23. Продолжительность текущего сеанса работы пользователя.

24. Информация о процессоре.

25. Загрузка каждого ядра ЦП в %.

26. Общая загрузка процессора в %.

27. Размер файла подкачки в байтах.

28. Количество свободных байтов файла подкачки.

29. Значение загрузки процессора данным процессом.

30. Количество модулей, используемых процессом.

31. Размер рабочего множества страниц.

32. Счетчик количества созданных описателей (дескрипторов).

33. Маска привязки процесса к процессорам.

34. Количество страничных ошибок.

35. Время старта процесса (час: мин: сек).

36. Количество потоков процесса.

37. Значение размера используемой оперативной памяти.

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

39. Оперативная память.

40. Определение системных утилит.

41. Понятие лог-файла.

42. Тестирование программного обеспечения.

43. Стратегия тестирования.

44. Файловые менеджеры.

45. Понятие Операционная система.

46. Файловые системы. Понятие и описание.

47. Межпроцессное взаимодействие - Отображение файлов.

48. Межпроцессное взаимодействие - Сокеты.

49. Межпроцессное взаимодействие - Каналы.

50. Межпроцессное взаимодействие - Очередь сообщений.

51. Межпроцессное взаимодействие - Разделяемая память.

52. Иерархия каталогов и файловых систем.

53. Свойства файлов, папок и дисков.

54. Директория. Понятие и описание.

55. Понятие Процесс. Описание и назначение процессов.

56. Понятие Поток. Описание и назначение потоков.

57. Понятие Многопоточность. Описание и назначение потоков.

58. Логическая организация механизма передачи информации.

59. Организация памяти.

60. Физическое и логическое адресные пространства.

61. Понятие о виртуальной памяти.

62. Принцип адресации.

63. Способы организации виртуальной памяти.

64. Системные вызовы для управления файлами.

65. Системные вызовы для управления каталогами.

66. Системные вызовы для процессов.

Курсовая работа включает следующие элементы:

• титульный лист (Приложение А);

• рецензия (Приложение Б);

• содержание (Приложение В);

• задание;

• введение;

• основная часть;

• заключение;

• список использованных источников;

• приложения.

Рекомендуемый объем курсовой работы составляет 40 страниц печатного текста. Объем структурных частей курсовой работы:

- введение – 1-2 стр.;

- основная часть – 30 стр.;

- заключение – 1-2 стр.;

- список использованных источников – 1 стр.

Введение

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

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

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

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

Объект исследования – это конкретная сфера применения операционных систем и программного обеспечения.

Предмет исследования – это конкретная характеристика, направление в рамках объекта исследования. Берется из задания к курсовой работе.

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

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

Основная часть, в свою очередь, структурно и тематически делится на:

1 Проектирование приложения

1.1

1.2

2 Разработка приложения

2.1

2.2

3 Руководство пользователя

3.1

3.2

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

В отчете должен присутствовать раздел «Руководство пользователя», в котором будет изложена подробная инструкция использования разработанного вами «Суперапп».

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

1. Введение.

2. Назначение и условия применения.

3. Подготовка к работе.

4. Описание операций.

5. Аварийные ситуации.

6. Рекомендации по освоению.

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

Заключение

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

Список использованных источников

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

Приложения

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

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

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