МДК

Цели и задачи модуля

Цели и задачи модуля

Цели и задачи модуля

Профессиональные компетенции

Междисциплинарные связи

Этапы изучения

Прикладное программирование

Раздел 1. Основные принципы разработки прикладных программ

Вопросы

ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

ЭТАПЫ СОЗДАНИЯ ПРОГРАММ

ЭТАПЫ СОЗДАНИЯ ПРОГРАММ

ЭТАПЫ СОЗДАНИЯ ПРОГРАММ

ЭТАПЫ СОЗДАНИЯ ПРОГРАММ

ЭТАПЫ СОЗДАНИЯ ПРОГРАММ

ЭТАПЫ СОЗДАНИЯ ПРОГРАММ

Вопросы

ДОКУМЕНТИРОВАНИЕ ПРОГРАММ

ДОКУМЕНТИРОВАНИЕ ПРОГРАММ

ДОКУМЕНТИРОВАНИЕ ПРОГРАММ

ДОКУМЕНТИРОВАНИЕ ПРОГРАММ

ДОКУМЕНТИРОВАНИЕ ПРОГРАММ

ДОКУМЕНТИРОВАНИЕ ПРОГРАММ

ДОКУМЕНТИРОВАНИЕ ПРОГРАММ

Домашнее задание

ОБЩЕСИСТЕМНЫЕ ПРИНЦИПЫ СОЗДАНИЯ ПРОГРАММ

ОБЩЕСИСТЕМНЫЕ ПРИНЦИПЫ СОЗДАНИЯ ПРОГРАММ

ТЕХНОЛОГИИ И ПАРАДИГМЫ ПРОГРАММИРОВАНИЯ

ТЕХНОЛОГИИ И ПАРАДИГМЫ ПРОГРАММИРОВАНИЯ

ТЕХНОЛОГИИ И ПАРАДИГМЫ ПРОГРАММИРОВАНИЯ

ТЕХНОЛОГИИ И ПАРАДИГМЫ ПРОГРАММИРОВАНИЯ

ТЕХНОЛОГИИ И ПАРАДИГМЫ ПРОГРАММИРОВАНИЯ

ТРАНСЛЯЦИЯ И ИНТЕРПРЕТАЦИЯ ПРОГРАММ

ТРАНСЛЯЦИЯ И ИНТЕРПРЕТАЦИЯ ПРОГРАММ

ТРАНСЛЯЦИЯ И ИНТЕРПРЕТАЦИЯ ПРОГРАММ

ТРАНСЛЯЦИЯ И ИНТЕРПРЕТАЦИЯ ПРОГРАММ

ТРАНСЛЯЦИЯ И ИНТЕРПРЕТАЦИЯ ПРОГРАММ

СРЕДЫ И РЕАЛИЗАЦИИ ЯЗЫКОВ ПРОГРАММИРОВАНИЯ

Задание

Переход от неформального к формальному существенно неформален.

Лекция 8.

РАЗРАБОТКА ПРОГРАММНОГО МОДУЛЯ

Порядок разработки программного модуля. Структурное программирование и пошаговая детализация. Понятие о псевдокоде. Контроль программного модуля.

8.1. Порядок разработки программного модуля.

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

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

· выбор алгоритма и структуры данных;

· программирование (кодирование) модуля;

· шлифовка текста модуля;

· проверка модуля;

· компиляция модуля.

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

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

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

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

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

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

8.2. Структурное программирование.

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

Рис. 8.1. Основные управляющие конструкции структурного программирования.

Основными конструкциями структурного программирования являются: следование, разветвление и повторение (см. Рис. 8.1). Компонентами этих конструкций являются обобщенные операторы (узлы обработки ) S, S1, S2 и условие (предикат) P. В качестве обобщенного оператора может быть либо простой оператор используемого языка программирования (операторы присваивания, ввода, вывода, обращения к процедуре), либо фрагмент программы, являющийся композицией основных управляющих конструкций структурного программирования. Существенно, что каждая из этих конструкций имеет по управлению только один вход и один выход. Тем самым, и обобщенный оператор имеет только один вход и один выход.

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

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

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

8.3. Пошаговая детализация и понятие о псевдокоде.

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

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

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

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

· начало модуля на базовом языке, т. е. первое предложение или заголовок (спецификацию) этого модуля ;

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

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

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

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

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

Рис. 8.2. Основные конструкции структурного программирования на псевдокоде.

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

Аннотация рабочей программы профессионального модуля

название профессионального модуля

1. Область применения программы

Рабочая программа профессионального модуля является частью программы подготовки специалистов среднего звена в соответствии с ФГОС СПО 09.02.07 Информационные системы и программирование, входящей в укрупненную группу специальностей 09.00.00 Информатика и вычислительная техника

и соответствующих профессиональных компетенций (ПК):

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

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

2. Цели и задачи модуля – требования к результатам освоения модуля

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

Разработки алгоритма поставленной задачи и реализаций его средствами автоматизированного проектирования;

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

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

Проведения тестирования программного модуля по определенному сценарию.

В результате освоения обязательной части модуля обучающийся должен уметь:

Осуществлять разработку кода программного модуля на современных языках программирования;

Создавать программу по разработанному алгоритму как отдельный модуль;

Выполнять отладку и тестирование программы на уровне модуля;

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

Использовать инструментальные средства для автоматизации оформления документации.

В результате освоения обязательной части модуля обучающийся должен знать:

Основные этапы разработки программного обеспечения;

Основные принципы технологии структурного и объектно-ориентированного программирования;

Основные принципы отладки и тестирования программных продуктов;

Методы и средства разработки технической документации.

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

7. Разработка программного кода с использованием пошаговой детализации

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

9. Инициализация массивов

10. Реализация динамических структур с помощью массивов

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

12. Разработка программного кода с использованием функций

13. Разработка программного кода с использованием разыменовывания указателей

14. Осуществление ввода-вывода

15. Осуществление файловых потоков

16. Осуществление строковых данных

17. Разработка статических классов

18. Разработка динамических классов

19. Разработка абстрактных классов

20. Разработка шаблонов классов

21. Выполнение отладки программного кода

22. Выполнение сортировки методом пузырька

23. Выполнение сортировки методом вставки

24. Выполнение сортировки методом Хоаре

25. Проведение тестирования программного кода принципом «белого ящика»

26. Проведение тестирования программного кода принципом «серого ящика»

27. Проведение тестирования программного кода принципом «черного ящика»

28. Осуществление оптимизации программного кода

29. Осуществление поисковой оптимизации программного кода

30. Составление технической документации

31. Составление алгоритмов работы с графикой

32. Инициализация графической системы

33. Работа с окнами и координатами

34. Работа с графическими примитивами

35. Создание анимационной картинки

36. Составление пользовательской документации

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ

ДОНЕЦКОЙ НАРОДНОЙ РЕСПУБЛИКИ

ГОСУДАРСТВЕННОЕ ПРОФЕССИОНАЛЬНОЕ

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

«ДОНЕЦКИЙ ПРОМЫШЛЕННО-ЭКОНОМИЧЕСКИЙ КОЛЛЕДЖ»

РАБОЧАЯ ПРОГРАММА

Учебной практики УП.01

профессионального модулю ПМ.01 Разработка программных модулей программного обеспечения для компьютерных систем

по специальности 09.02.03 «Программирование в компьютерных системах»

Составители:

Волков Владимир Александрович, преподаватель компьютерных дисциплин квалификационной категории «специалист высшей категории», ГПОУ «Донецкий промышленно-экономический колледж»

Программа согласована: Вовк Павел Андреевич, директор «Smart IT Service»

1 ПАСПОРТ ПРОГРАММЫ УЧЕБНОЙ ПРАКТИКИ УП. 01

1.1 Место учебной практики УП.01

Программа учебной практики УП.01 профессионального модуля ПМ.01 «Разработка программных модулей программного обеспечения для компьютерных систем» специальности 09.02.03 «Программирование в компьютерных системах» укрупнённой группы 09.00.00 «Информатика и вычислительная техника», в части освоения основного вида профессиональной деятельности (ВПД):

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

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

1.2 Цели и задачи учебной практики УП.01

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

иметь практический опыт:

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

разработки кода программного продукта на основе готовой спецификации на уровне модуля;

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

проведения тестирования программного модуля по определенному сценарию;

уметь:

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

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

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

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

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

знать:

основные этапы разработки программного обеспечения;

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

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

методы и средства разработки технической документации.

1.3 Количество недель (часов ) на освоение программы учебной практики УП.01

Всего 1,5 недели, 54 часа.

2 РЕЗУЛЬТАТЫ ПРАКТИКИ

Результатом учебной практики УП.01 профессионального модуля ПМ.01 «Разработка программных модулей программного обеспечения для компьютерных систем» является освоение общих компетенций (ОК):

профессиональных компетенций (ПК):

3 СТРУКТУРА И СОДЕРЖАНИЕ ПРОГРАММЫ УЧЕБНОЙ ПРАКТИКИ УП.01

3.1 Тематический план

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

4 УСЛОВИЯ ОРГАНИЗАЦИИ И ПРОВЕДЕНИЯ

УЧЕБНОЙ ПРАКТИКИ УП. 01

4.1 Требования к документации , необходимой для проведения практики :

Рабочая программа учебной практики УП.01 профессионального модуля ПМ.01. «Разработка программных модулей программного обеспечения для компьютерных систем» является частью программы подготовки специалистов среднего звена Государственным профессиональным образовательным учреждением «Донецкий промышленно-экономический колледж» в соответствии с государственным образовательным стандартом среднего профессионального образования по специальности 09.02.03 «Программирование в компьютерных системах», основана на учебном плане по специальности, рабочей программе по дисциплинам МДК.01.01 «Системное программирование», МДК01.02 «Прикладное программирование», методических рекомендациях по учебно-методическому обеспечению практики студентов, осваивающих образовательные программы среднего профессионального образования.

4.2 Требования к учебно-методическому обеспечению практики :

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

4.3 Требования к материально-техническому обеспечению :

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

Оборудование кабинета и рабочих мест:

посадочные места по количеству студентов (стол, компьютер, стул);

рабочее место преподавателя (стол, компьютер, стул);

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

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

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

набор системных, прикладных и обучающих программ для ПК на оптических и электронных носителях;

журнал инструктажа студентов по охране труда;

комплект учебно-наглядных пособий.

Технические средства обучения:

аудиторная доска;

персональный компьютер с лицензионным программным обеспечением;

принтер лазерный;

• учебные ПК;

  комплект интерактивного оборудования (проектор, экран, колонки);

  средства пожаротушения (огнетушитель).

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

Все компьютеры в классе объединены в локальную сеть, имеют доступ к сетевому хранилищу информации и имеют доступ в сеть Интернет.

Коммуникационное оборудование:

сетевые адаптеры;

сетевые кабели;

беспроводное оборудование WiFi.

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

4.4 Перечень учебных изданий , Интернет ресурсов , дополнительной литературы

Основные источники:

Олифер В.Г. Сетевые операционные системы: учебник для вузов/ В.Г.Олифер, Н.А.Олифер. - 2-е изд. - Санкт-Петербург: Питер, 2009,2008. - 668 с.:

Э. Таненбаум. Операционные системы. Разработка и реализация. СПб.: Питер, 2006. - 568 с.

Пупков К.А. Освоение операционной системы Unix / К.А.Пупков, А.С.Черников, Н.М.Якушева. - Москва: Радио и связь, 1994. - 112 с.

Л. Бек Введение в системное программирование - М.: Мир, 1988.

Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем / Москва: Бином, 2008. – 304 с.

Липаев, В. В. Программная инженерия. Методологические основы [Текст]: Учеб. / В. В. Липаев; Гос. ун-т - Высшая школа экономики. - М.: ТЕИС, 2006. - 608 с.

Лаврищева Е. М., Петрухин В. А. Методы и средства инженерии программного обеспечения. - Учебник

Иан Соммервилл. Инженерия программного обеспечения, 6-ое издание.: Пер. с англ. ―М. :Издательский дом "Вильямс", 2002.―624 с.

Еxcel 2010: профессиональное программирование на VBA.: Пер. с англ. - М.: ООО “И.Д. Вильямс”, 2012. - 944 с. : ил. - Парал. тит. Англ

Фаулер М. Рефакторинг: улучшение существующего кода.―Пер. С англ.―СПб: Символ-плюс, 2003.―432 с.

Дополнительные источники:

Волков В.А. МЕТОДИЧЕСКИЕ УКАЗАНИЯ к выполнению практических работ по дисциплине «Системное программирование», Донецк: ДОНПЭК, 2015.

Волков В.А. Методические указания к выполнению курсового проекта, Донецк: ДОНПЭК, 2015.

Интернет- ресурсы:

Системное программирование [электронный ресурс] / Режим доступа: http://www.umk3.utmn.ru.

Программное обеспечение и Интернет-ресурсы: http://www.intuit.ru

Литература по дисциплине - http://www.internet-technologies.ru/books/

Электронный учебник «Введение в программную инженерию» - http://www.intuit.ru/studies/professional_skill_improvements/1419/info

Электронный учебник «Технология программирования» -http://bourabai.kz/alg/pro.htm

4.5 Требования к руководителям практики от образовательного учреждения и организации

Требования к руководителям практики от образовательного учреждения:

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

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

5 КОНТРОЛЬ И ОЦЕНКА РЕЗУЛЬТАТОВ

УЧЕБНОЙ ПРАКТИКИ УП. 01

Форма отчетности по учебной практике УП.01 – отчет по практике, оформленный согласно требованиям методических рекомендаций.

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