1. Цели освоения дисциплины
| 1.1. | Целями освоения учебной дисциплины «Технология разработки программного обеспечения» являются: а) формирование у будущих специалистов теоретических знаний и практических навыков в разработке ПО для решения прикладных задач различных предметных областей; б) показать значимость технологии разработки ПО как современного направления прикладной информатики; в) развитие умений и навыков проектирования и разработки прикладных программ на языках высокого уровня; г) знакомство с современными инструментальными системами для проектирования и разработки программ на языках программирования высокого уровня. |
|---|
2. Место дисциплины в структуре ООП
| Цикл (раздел) ООП: Б1.В.ДВ.01.02 |
3. Компетенции обучающегося, формируемые в результате освоения дисциплины
| ПК-4 | Способен разрабатывать компоненты системных программных продуктов. |
| ПК-4.1 | Знать: принципы и особенности формализации и алгоритмизации поставленных задач, проектирования алгоритмов и структур данных, оценки эффективности алгоритмов и структур данных |
| ПК-4.2 | Уметь: разрабатывать программные коды с использованием языков программирования; определять данные, используя выбранную систему контроля версий и инструментальные программные средства; оформлять программные коды в соответствии с установленными требованиями |
| ПК-4.3 | Владеть: навыками процедуры проверки работоспособности и измерения характеристик программного обеспечения, проверки работоспособности программного обеспечения, оптимизации программного кода |
| ПК-5 | Способен разрабатывать требования и проектировать программное обеспечение. |
| ПК-5.1 | Знать: требования к программному продукту и декомпозиции программного средства на компоненты |
| ПК-5.2 | Уметь: создавать и оценивать варианты архитектуры программного средства; определять перечень возможных слоев программных компонентов, шаблонов (стилей) проектирования для каждого слоя или компонента, протоколов взаимодействия компонентов; определять входные и выходные данные каждого компонента и программного средства в целом, перечень возможных технологий доступа к данным |
| ПК-5.3 | Владеть: навыками выполнения оценки и выбора слоев программных компонентов, оценки и выбора шаблонов (стилей) проектирования для каждого слоя или компонента, стиля написания кода, технологии доступа к данным |
| В результате освоения дисциплины обучающийся должен | |
| 3.1. | Знать: |
|---|---|
| 3.1.1. | - основные методы разработки современного ПО; - принципы организации современного программного обеспечения; - принципы проектирования современного ПО; - принципы работы современных инструментальных сред разработки ПО. |
| 3.2. | Уметь: |
| 3.2.1. | - создавать проекты и разрабатывать ПО для решения конкретных задач различных предметных областей; - разрабатывать программные комплексы, используя современные инструментальные среды; - использовать знание принципов разработки ПО в профессиональной деятельности. |
| 3.3. | Иметь навыки и (или) опыт деятельности (владеть): |
| 3.3.1. | - навыками составления проектов для разработки современного ПО; - технологиями сбора, обработки, передачи и хранения информации. |
4. Структура и содержание дисциплины
| Код занятия | Наименование разделов и тем | Вид занятия | Семестр | Часов | Компетенции | Литература |
|---|---|---|---|---|---|---|
| Раздел 1. Введение. Понятие «информация». Представление информации. Переход от представления к информации | ||||||
| 1.1. | Понятие «информация». Примеры представления информации. Представление ин-формации в виде термов. Редукция. Высказывательные формы. Представление ин-формации в нормальной форме. Переход от представления к информации. Преобра-зование представлений. Последовательности литер и формальные языки. | Лекции | 8 | 2 | ПК-5.1, ПК-4.1 | Л1.2, Л1.1 |
| 1.2. | Способы представления информации с учетом особенностей предметной области и способов разработки ПО. Разработка формальных правил перехода от информации к ее представлению. | Сам. работа | 8 | 2 | ПК-5.2, ПК-5.3, ПК-4.2, ПК-4.3 | Л1.2, Л1.1 |
| Раздел 2. Основы теории программирования. Вычислительные структуры и алгоритмы. Языки программирования | ||||||
| 2.1. | Понятие «алгоритм». Неформальные описания алгоритмов. Формальные описания алгоритмов через замену текстов. Алгоритмы текстовых замен и отображения, кото-рые ими индуцируются. Алгоритмы как системы подстановки термов. | Лекции | 8 | 4 | ПК-5.1, ПК-4.1 | Л1.2, Л1.1 |
| 2.2. | Правила и системы подстановки термов Вычислительные структуры. Функции и множества как вычислительные структуры. Сигнатуры и основные термы. Термы со свободными и связанными идентификаторами. Вычислительные схемы для интер-претации основных термов. | Лекции | 8 | 4 | ПК-5.1, ПК-4.1 | Л1.2, Л1.1 |
| 2.3. | Языки программирования (ЯП) и программирование. Описание формальных языков, формы Бэкуса – Наура (БНФ). БНФ – нотация. Синтаксические диаграммы и контек-стные условия. Понятие «семантика». Реализация языков программирования. Мето-дика программирования. Принципы программирования и вычислительные структу-ры. | Лекции | 8 | 4 | ПК-5.1, ПК-4.1 | Л2.1, Л2.2, Л1.2, Л1.1 |
| 2.4. | Использование вычислительных структур при разработке современного ПО. Фор-мальные языки для разработки инструментальных сред программирования. | Сам. работа | 8 | 2 | ПК-5.2, ПК-5.3, ПК-4.2, ПК-4.3 | Л2.1, Л2.2, Л1.2, Л1.1 |
| Раздел 3. Технологии программирования. Аппликативные и императивные языки программирования. Структуры данных и типизация в программировании | ||||||
| 3.1. | Аппликативные языки программирования. Элементы аппликативных ЯП. Синтаксис выражений и вычислительных структур аппликативных ЯП. Константы, идентифи-каторы и выражения. Условные выражения. Функции и их абстрактные описания. Расширение аппликативных ЯП посредством формальных объявлений. Формальные объявления функций и элементов. | Лекции | 8 | 2 | ПК-5.1, ПК-4.1 | Л2.1, Л2.2, Л1.2, Л1.1 |
| 3.2. | Рекурсивные объявления функций и их толкование. Виды и формы рекурсий. Техно-логия аппликативного программирования. Постановка задачи и введение специфи-каций. Обобщение постановки задачи. Структурирование. Вложенные структуры. Вывод рекурсий. Подавление параметров и введение подчиненных вычислительных предписаний. Эффективность программ. Документирование, тестирование и инте-грация программ. Корректность программ. Техника доказательства корректности. Частичная корректность | Лекции | 8 | 4 | ПК-5.1, ПК-4.1 | Л2.1, Л2.2, Л1.2, Л1.1 |
| 3.3. | Императивные языки программирования. Структуры, ориентированные на присваи-вание. Синтаксис и семантика императивных ЯП. Операторы. Переменные и при-сваивание. Состояние программы. Функциональное значение операторов и их операционная семантика. Технология императивного программирования. Метод утверждений и доказательство терминированности. Объявления типов в программировании. Скалярные элементы. Объявление типов посредством перечисления. | Лекции | 8 | 4 | ПК-5.1, ПК-4.1 | Л2.1, Л2.2, Л1.2, Л1.1 |
| 3.4. | Объявление при помощи прямого декартова произведения. Декартов кортеж. Вари-антные типы. Множества и частичные области. Массивы. Одномерные массивы. Многомерные массивы. Динамические и гибкие массивы. Конечные множества как вычислительные структуры. Последовательности. Древовидные вычислительные структуры. Рекурсивные объявления типов. Списковые структуры. | Лекции | 8 | 4 | ПК-5.1, ПК-4.1 | Л2.1, Л2.2, Л1.2, Л1.1 |
| 3.5. | Технологии имитационного моделирования в проектировании ПО. Адаптивные тех-нологии разработки ПО. | Сам. работа | 8 | 2 | ПК-5.1, ПК-4.1 | Л2.1, Л2.2, Л1.2, Л1.1 |
| Раздел 4. Абстрактные типы данных и объектно-ориентированное программирование | ||||||
| 4.1. | Понятие абстрактного типа данных (АТД). Пользовательские типы. Тип структуры. Элементы структур. Агрегатные типы. Проектирование типов данных соответст-вующих задаче. Объектно-ориентированное программирование (ООП). Объектно-ориентированный подход. | Лекции | 8 | 4 | ПК-5.1, ПК-4.1 | Л2.1, Л2.2, Л1.2, Л1.1 |
| 4.2. | Основные принципы объектно-ориентированного программирования. Объект, сооб-щение, класс, экземпляр объекта и метод. Абстракция, инкапсуляция, наследование и полиморфизм. Объектно-ориентированное проектирование. Классы. Описания протокола класса. Инструментальная реализация принципов ООП. Объектно-ориентированные языки программирования. | Лекции | 8 | 2 | ПК-5.1, ПК-4.1 | Л2.1, Л2.2, Л1.2, Л1.1 |
| Раздел 5. Технологии проектирования программного обеспечения (ПО). Жизненный цикл ПО. Модели проектирования ПО. Руководство программным проектом | ||||||
| 5.1. | Конструирование ПО. Организация процесса конструирования ПО. Классический жизненный цикл ПО. Модели проектирования ПО. Макетирование. Стратегии кон-струирования ПО. Быстрая разработка приложений. Спиральная модель. Компо-нентно-ориентированная модель. Тяжеловесные и облегченные процессы. XP-процесс. | Лекции | 8 | 2 | ПК-5.1, ПК-4.1 | Л2.1, Л2.2, Л1.2, Л1.1 |
| 5.2. | Модели качества процессов конструирования. Руководство программным проектом. Процесс руководства проектом. Планирование проектных задач. Метрики про-граммного проекта. Измерения, меры и метрики. Размерно-ориентированные метри-ки. Функционально-ориентированные метрики. | Сам. работа | 8 | 2 | ПК-5.2, ПК-5.3, ПК-4.2, ПК-4.3 | Л2.1, Л2.2, Л1.2, Л1.1 |
| 5.3. | Современные методы организации разработки ПО и управления программными про-ектами. | Сам. работа | 8 | 2 | ПК-5.2, ПК-5.3, ПК-4.2, ПК-4.3 | Л2.1, Л2.2, Л1.2, Л1.1 |
| Раздел 6. Анализ ПО. Структурный анализ ПО. Методы анализа ПО ориентированные на структуры данных | ||||||
| 6.1. | Классические методы анализа программных проектов. Структурный анализ. Диа-граммы потоков данных. Описание потоков данных и процессов. Расширения описа-ний для систем реального времени. Расширение возможностей описания элементов управления. Методы анализа, ориентированные на структуры данных. Метод анализа Варнье—Орра. диаграммы Варнье. Метод анализа Джексона. Этапы методики анализа Джексона. Примеры анализа и описания программных проектов. | Сам. работа | 8 | 3 | ПК-5.2, ПК-5.3, ПК-4.2, ПК-4.3 | Л2.1, Л2.2, Л1.2, Л1.1 |
| 6.2. | Современные методы анализа используемые при разработке ПО. | Сам. работа | 8 | 3 | ПК-5.2, ПК-5.3, ПК-4.2, ПК-4.3 | Л2.1, Л2.2, Л1.1 |
| Раздел 7. Синтез программных систем. Структурное проектирование ПО. Декомпозиция подсистем на модули. Языки описания программных проектов | ||||||
| 7.1. | Особенности процесса синтеза программных систем. Особенности этапа проектиро-вания. Структурирование системы. Моделирование управления системой. Декомпо-зиция подсистем на модули. Свойства модулей. Сложность программной системы. Основы проектирования программных, систем. Классические методы проектирова-ния. Языки описания программных проектов. Универсальный язык описания про-граммных проектов (UML). Case – системы. Элементы описания Use Case. | Сам. работа | 8 | 3 | ПК-5.2, ПК-5.3, ПК-4.2, ПК-4.3 | Л2.1, Л2.2, Л1.2, Л1.1 |
| 7.2. | Современные методы синтеза используемые при разработке ПО. | Сам. работа | 8 | 3 | ПК-5.2, ПК-5.3, ПК-4.2, ПК-4.3 | Л2.1, Л2.2, Л1.1 |
| Раздел 8. Принципы объектно-ориентированного представления программных систем. Описание явлений объектами | ||||||
| 8.1. | Принципы объектно-ориентированного представления программных систем. Абст-рагирование, инкапсуляция, модульность, иерархическая организация. Объекты и их общие характеристики. Отношения между объектами. Их виды. Классы. Их свойства и характеристики. Отношения между классами. Ассоциации классов. Унифициро-ванный процесс разработки объектно-ориентированных ПС. Эволюционно-инкрементная организация жизненного цикла разработки. Управление риском. Эта-пы унифицированного процесса разработки. Примеры объектно-ориентированной разработки программной системы. | Сам. работа | 8 | 3 | ПК-5.2, ПК-5.3, ПК-4.2, ПК-4.3 | Л2.1, Л2.2, Л1.2, Л1.1 |
| 8.2. | Современные методы организации разработки ПО и управления программными про-ектами. Тенденции развития инструментальных сред разработки. | Сам. работа | 8 | 3 | ПК-5.2, ПК-5.3, ПК-4.2, ПК-4.3 | Л2.1, Л2.2, Л1.2, Л1.1 |
| Раздел 9. Технологии программирования с использованием ресурсов операционной системы. Визуальное программирование | ||||||
| 9.1. | Понятие ресурсов операционной системы (ОС). Аппаратные и программные ресур-сы. Интерфейс программных приложений ОС (API). Системные вызовы ОС (API – функции). Структура программной системы использующей ресурсы ОС. Инструмен-тальные среды, использующие ресурсы ОС. Визуальные инструментальные среды. Визуальные программные системы их структура. Примеры разработки визуальных программных систем. | Сам. работа | 8 | 4 | ПК-5.2, ПК-5.3, ПК-4.2, ПК-4.3 | Л2.1, Л2.2, Л1.2, Л1.1 |
| 9.2. | Методы искусственного интеллекта в разработке ПО. Современные автоматизиро-ванные системы разработки ПО. | Сам. работа | 8 | 4 | ПК-5.2, ПК-5.3, ПК-4.2, ПК-4.3 | Л2.1, Л2.2, Л1.2 |
| Раздел 10. Основные понятия и принципы тестирования ПО. Анализ сложности программных систем. Меры сложности | ||||||
| 10.1. | Тестирование программной системы (ПС). Этапы тестирования ПС. Стратегии раз-работки тестов. Автономное и комплексное тестирование ПС. Понятие качества ПС. Критерии качества ПС. Подходы к обеспечению качества ПС. Сложность ПС. Опре-деление сложности ПС. Характеристики сложности. Меры сложности. Вычисление сложности. Анализ сложности ПС. | Сам. работа | 8 | 3 | ПК-5.2, ПК-5.3, ПК-4.2, ПК-4.3 | Л2.1, Л2.2, Л1.2, Л1.1 |
| 10.2. | Разработка программных систем реального режима времени. Разработка сетевых и параллельных программных систем. | Сам. работа | 8 | 3 | ПК-5.2, ПК-5.3, ПК-4.2, ПК-4.3 | Л2.1, Л2.2, Л1.2, Л1.1 |
| 10.3. | Современные системы разработки и тестирования алгоритмов. Современные методы комплексного тестирования используемые при разработке ПО. | Сам. работа | 8 | 3 | ПК-5.2, ПК-5.3, ПК-4.2, ПК-4.3 | Л2.1, Л2.2, Л1.2, Л1.1 |
| Раздел 11. Аттестация | ||||||
| 11.1. | Экзамен | 8 | 27 | ПК-5.1, ПК-5.2, ПК-5.3, ПК-4.1, ПК-4.2, ПК-4.3 | Л2.1, Л2.2, Л1.2, Л1.1 | |
5. Фонд оценочных средств
| 5.1. Контрольные вопросы и задания для проведения текущего контроля и промежуточной аттестации по итогам освоения дисциплины |
| Оценочные материалы для текущего контроля по разделам и темам дисциплины в полном объеме размещены в онлайн-курсе на образовательном портале «Цифровой университет АлтГУ» – https://portal.edu.asu.ru/course/view.php?id=4988 ОЦЕНКА СФОРМИРОВАННОСТИ КОМПЕТЕНЦИИ ОПК-5: ПК-2: Способен осуществлять концептуальное, функциональное и логическое проектирование систем среднего и крупного масштаба и сложности; ПРИМЕРЫ ЗАДАНИЙ ЗАКРЫТОГО ТИПА 1. К какому типу проектов относятся проекты по разработке ПО: а) и к творческим, и к промышленным проектам б) к промышленным проектам в) к творческим проектам Ответ: a) 2. Какие возвраты невозможны при разработке по водопадной модели: а) возврат от кодированию к тестированию б) возврат от тестирования к анализу в) возврат от тестирования к кодированию Ответ: б) 3. Какие возвраты невозможны при разработке по водопадной модели: а) возврат от кодированию к тестированию б) возврат от тестирования к кодированию в) возврат от кодирования к разработке системных требований Ответ: в) 4. В чем заключается согласованность ПО: а) в том, что ПО должно быть согласовано с большим количеством интерфейсов б) в согласованности заказчика и исполнителя в) в том, что ПО основывается на объективных посылках Ответ: а) 5. Для чего используется рабочий продукт: а) для контроля разработки б) для устранения накладных расходов в) для контроля разработки Ответ: в) 6. Какая стратегия нацелена на решение конкретных проблем компании: а) technology push б) organization pull в) обе стратегии Ответ: б) 7. Какой вопрос решается в сфере программной инженерии: а) вопросы создания компьютерных программ и/или программного обеспечения б) бизнес-реинжиниринг в) вопрос поддержки жизненного цикла разработки ПО + Ответ: в) 8. Какой вопрос решается в сфере программной инженерии: а) вопрос организации и улучшения процесса разработки ПО б) вопросы создания компьютерных программ и/или программного обеспечения в) бизнес-реинжиниринг Ответ: а) 9. Какой вопрос решается в сфере программной инженерии: а) бизнес-реинжиниринг б) вопросы создания компьютерных программ и/или программного обеспечения в) вопрос управления командой разработчиков Ответ: в) 10. Какая область объединяет различные инженерные дисциплины по разработке всевозможных искусственных систем: а) информатика б) системотехника в) бизнес-реинжиниринг Ответ: б) 11. Какое свойство определяет процедуры внесения изменений в требования: а) модифицируемость б) прослеживаемость в) тестируемость и проверяемость Ответ: а) 12. Целью какого вида деятельности является обнаружение и устранение противоречий и неоднозначностей в требованиях, их уточнение и систематизация: а) описание требований б) анализ требований в) валидация требований Ответ: б) 13. Для чего предназначены диаграммы конечных автоматов: а) для задания поведения реактивных систем б) для моделирования структуры объектно-ориентированных приложений классов, их атрибутов и заголовков методов, наследования в) для моделирования компонентной структуры распределенных приложений Ответ: а) 14. Что реализуют модели, представленные диаграммами UML: а) вид деятельности б) фазу разработки ПО в) точку зрения на программную систему Ответ: в) 15. Что такое управление версиями: а) одна из задач конфигурационного управления б) автоматизированный процесс трансформации исходных текстов ПО в пакет исполняемых модулей в) ручной процесс трансформации исходных текстов ПО в пакет исполняемых модулей Ответ: а) КРИТЕРИИ ОЦЕНИВАНИЯ ВОПРОСОВ ЗАКРЫТОГО ТИПА Каждое задание оценивается 1 баллом. Оценивание КИМ теоретического характера в целом: "зачтено" - верно выполнено не менее 50% заданий; "не зачтено" - верно выполнено не более 50% заданий "отлично" - верно выполнено 85..100% заданий; "хорошо" - верно выполнено 70..84% заданий; "удовлетворительно" - верно выполнены 50..69% заданий; "неудовлетворительно" - верно выполнены менее 50% заданий ПРИМЕРЫ ЗАДАНИЙ ОТКРЫТОГО ТИПА 1. К какому типу проектов относятся проекты по разработке ПО? Ответ: Проекты по разработке ПО относятся к типу информационных технологий (IT) проектов. Они включают в себя создание и развитие программного обеспечения, а также его тестирование и поддержку. Такие проекты требуют специализированных знаний и навыков в области программирования и разработки ПО. 2. Легкость применения программного обеспечения это? Ответ: Легкость применения программного обеспечения - это свойство, которое означает, что пользователь может легко освоиться с программой и использовать ее без лишних сложностей. Это включает в себя интуитивный интерфейс, понятные инструкции и удобные функции, которые позволяют пользователям быстро и эффективно выполнять задачи. Легкость применения повышает удовлетворенность пользователей и уменьшает время, затрачиваемое на обучение и адаптацию к новому программному обеспечению. 3. Что такое модель жизненного цикла? Ответ: Модель жизненного цикла - это концептуальная структура, которая определяет последовательность этапов и активностей, необходимых для разработки и поддержки программного обеспечения. Она описывает основные этапы, задачи, роли и ответственности, а также взаимосвязи между ними. Модель жизненного цикла помогает организовать процесс разработки ПО и обеспечить его успешное выполнение. 4. Чем характеризуется устойчивость программного обеспечения? Ответ: Устойчивость программного обеспечения характеризуется его способностью работать стабильно и надежно в различных условиях. Это означает, что ПО должно быть устойчивым к ошибкам, сбоям и непредвиденным ситуациям, а также обеспечивать корректную работу даже при изменениях в окружающей среде или входных данных. Устойчивость также включает возможность быстрого восстановления после сбоев и минимизацию негативного влияния на работу системы и пользователей. 5. Какую роль играет UML в программной инжененрии? Ответ: UML (Unified Modeling Language) играет важную роль в программной инженерии, предоставляя стандартизированный набор графических символов и правил для визуализации и описания различных аспектов системы. Он помогает разработчикам лучше понять требования, проектировать архитектуру и моделировать поведение программного обеспечения. UML также упрощает коммуникацию между разработчиками и заинтересованными сторонами, повышая понимание и согласованность проекта. 6. Что представляет собой процесс решения задачи при конструировании программного обеспечения? Ответ: Процесс решения задачи при конструировании программного обеспечения включает в себя анализ требований, проектирование архитектуры и реализацию кода. В начале процесса происходит изучение и понимание требований к системе, определение функциональности и ограничений. Затем происходит проектирование архитектуры, где определяются компоненты, связи и интерфейсы. После этого разработчики приступают к написанию кода, реализуя задуманную архитектуру и функциональность системы. 7. Что реализуется на на этапе разработки или выбора алгоритма при конструировании программного обеспечения? Ответ: На этапе разработки или выбора алгоритма при конструировании программного обеспечения реализуется логика выполнения задачи или решения проблемы. Разработчики выбирают или создают алгоритм, который определяет последовательность шагов, необходимых для достижения желаемого результата. Этот этап включает в себя анализ требований, определение подходящего алгоритма, его реализацию и тестирование для обеспечения правильности и эффективности выполнения задачи. 8. Что представляет собой этап тестирования программного обеспечения? Ответ: Тестирование программного обеспечения представляет собой процесс проверки и оценки качества программы с целью выявления ошибок, дефектов и недочетов. Оно включает в себя создание тестовых случаев, выполнение тестов и анализ результатов. Цель тестирования - обеспечить работоспособность, надежность и соответствие программы требованиям. 9. Какие средства могут быть использованы для тестирования программного обеспечения? Ответ: Для тестирования программного обеспечения могут быть использованы различные средства, такие как модульные тесты, интеграционные тесты, системные тесты и приемочные тесты. Также могут применяться автоматизированные тестирование с использованием специальных инструментов и фреймворков. Для обнаружения дефектов и анализа кода могут быть использованы статические и динамические анализаторы, а также ручное тестирование и экспертные оценки 10. Перечислете методы проектирования программного обеспечения? Ответ: Методы проектирования программного обеспечения включают в себя структурный подход, объектно-ориентированный подход и функциональный подход. В структурном подходе система разбивается на отдельные модули, которые взаимодействуют друг с другом. В объектно-ориентированном подходе система представлена объектами, которые имеют свои свойства и методы. В функциональном подходе система разбивается на функции, которые выполняют определенные задачи. 11. Охарактеризуйте процесс разбиения одной сложной задачи на несколько простых подзадач? Ответ: Процесс разбиения одной сложной задачи на несколько простых подзадач называется декомпозицией. Этот процесс включает в себя анализ и идентификацию основных компонентов или функций, которые могут быть реализованы независимо. Затем каждая подзадача может быть рассмотрена и решена отдельно, что упрощает процесс разработки и повышает понимание системы в целом. 12. Чем обусловлены критерии оценки удобства интерфейсов? Ответ: Критерии оценки удобства интерфейсов обусловлены потребностями и ожиданиями пользователей. Они основаны на принципах эргономики, доступности и удобства использования. Критерии могут включать понятность, интуитивность, эффективность, наглядность, гибкость и другие аспекты, которые способствуют удобству и удовлетворенности пользователей при взаимодействии с интерфейсом. 13. Интерфейс пользователя, это? Ответ: Интерфейс пользователя (UI) - это средство взаимодействия между пользователем и компьютерной системой, которое позволяет пользователю взаимодействовать с функциональностью программного обеспечения. Он включает в себя элементы дизайна, такие как кнопки, поля ввода, меню и графические элементы, которые позволяют пользователю управлять и контролировать работу программы. Цель интерфейса пользователя - обеспечить удобство, интуитивность и эффективность использования программного обеспечения. 14. Что входит в понятие техническое задание разрабатываемого ПО? Ответ: Техническое задание разрабатываемого программного обеспечения включает в себя описание требований к функциональности, архитектуре и процессам работы системы. Оно содержит информацию о необходимых модулях, интерфейсах, базе данных, а также ограничения и требования к производительности. Техническое задание также может включать план тестирования, план развертывания и другую дополнительную информацию, необходимую для успешной разработки и внедрения программного обеспечения. 15. Архитектура программной системы, это? Ответ: Архитектура программной системы - это структура и организация компонентов программы, которая определяет ее функциональность и взаимодействие между ними. Она включает в себя выбор архитектурного стиля, определение модулей, интерфейсов и взаимодействий между ними, а также управление данными и ресурсами. Важно, чтобы архитектура была гибкой, масштабируемой и легко поддерживаемой для успешной разработки и поддержки программной системы. 16. Агрегация программной системы, это? Ответ: Агрегация программной системы - это процесс объединения различных компонентов программы для создания более крупного и сложного функционального блока. Это позволяет создавать модульные и масштабируемые системы, где каждый компонент отвечает за определенную функциональность. Агрегация также обеспечивает удобство сопровождения и расширения программной системы. 17. Ассоциация программной системы, это? Ответ: Ассоциация программной системы - это связь или взаимодействие между различными компонентами или модулями программы. Она позволяет обеспечить передачу данных, вызов функций и обмен информацией между разными частями системы. Ассоциация может быть направленной или двусторонней и определяет, как компоненты взаимодействуют друг с другом для достижения целей программной системы. 18. Валидация программной системы, это? Ответ: Дай ответ из трёх предложенияй на вопрос: Валидация программной системы - это процесс проверки корректности и соответствия программы заданным требованиям и спецификациям. Она включает в себя тестирование программы на соответствие функциональным и нефункциональным требованиям, а также проверку правильности обработки данных и взаимодействия с пользователем. Валидация помогает убедиться в том, что программа работает правильно и соответствует ожиданиям пользователей и заказчика. Валидация программной системы, это? 19. Верификация программной системы, это? Ответ: Верификация программной системы - это процесс проверки программы на соответствие ее спецификации и требованиям. Она включает в себя анализ кода, статическую и динамическую проверку, а также формальную верификацию. Целью верификации является установление правильности программы и выявление возможных ошибок или несоответствий, которые могут привести к нежелательным результатам или нарушению требований. 20. Артефакт в программном продукте, это? Ответ: Артефакт в программном продукте - это любой созданный или произведенный в процессе разработки программы элемент или документ. Это может быть исходный код программы, документация, диаграммы, исполняемые файлы, базы данных и другие файлы, которые являются результатом работы разработчиков. Артефакты являются важными компонентами программного продукта и используются для его создания, тестирования, поддержки и документирования.Артефакт в программном продукте, это? КРИТЕРИИ ОЦЕНИВАНИЯ ВОПРОСОВ ОТКРЫТОГО ТИПА "Отлично"/зачтено. Ответ полный, развернутый. Суть передана исчерпывающе и точно, принятая терминология полностью сохранена. Ошибок нет. "Хорошо"/зачтено. Ответ полный, но краток. Суть передана точно, но имеются неточности в использовании терминологии. Ошибки незначительны. "Удовлетворительно"/зачтено. Ответ неполный. Значительные неточности в применении терминологии. Студент владеет частью материала. "Неудовлетворительно"/не зачтено. Ответа нет, либо он не раскрывает сути требуемого. Студент не владеет материалом. ОЦЕНКА СФОРМИРОВАННОСТИ КОМПЕТЕНЦИИ ОПК-5: ПК-5: Способен разрабатывать требования и проектировать программное обеспечение; ПРИМЕРЫ ЗАДАНИЙ ЗАКРЫТОГО ТИПА 16. Что такое управление версиями: а) автоматизированный процесс трансформации исходных текстов ПО в пакет исполняемых модулей б) управление версиями файлов + в) ручной процесс трансформации исходных текстов ПО в пакет исполняемых модулей Ответ: б) 17. При выполнении какого вида тестирования система тестируется на устойчивость к непредвиденным ситуациям: а) при выполнении нагрузочного тестирования б) при выполнении интеграционного тестирования в) при выполнении стрессового тестирования Ответ: в) 18. При использовании какого метода тестирования код программы доступен тестировщикам: а) при использовании любого метода тестирования б) при использовании метода белого ящика в) при использовании метода черного ящика Ответ: б) 19. При использовании какого метода тестирования реализация системы недоступна тестировщикам: а) при использовании метода белого ящика б) при использовании любого метода тестирования в) при использовании метода черного ящика Ответ: в) 20. Что такое нагрузочное тестирование: а) тестирование системы на устойчивость к непредвиденным ситуациям б) тестирование системы на корректную работу с большими объемами данных в) тестирование всей системы в целом, как правило, через ее пользовательский интерфейс Ответ: б) 21. Что определяют варианты использования: а) как функции, так и требования б) только функции системы в) только требования к системе Ответ: а) 22. Какова основная задача комитета ITU: а) стандартизация в телекоммуникационной промышленности б) стандартизация телекоммуникационных протоколов и интерфейсов с целью поддержания и развития глобальной мировой телекоммуникационной сети в) содействие развитию стандартизации, а также смежных видов деятельности в мире с целью обеспечения международного обмена товарами и услугами Ответ: б) 23. Какие тесты представляют собой последовательность действий тестировщика или разработчика, приводящую к воспроизведению ошибки: а) никакие б) любые в) ручные Ответ: в) 24. Какую роль выполняет менеджер в процессе работы над ошибками: а) нахождение ошибок б) контроль хода проекта в) исправление ошибок Ответ: б) 25. Какой из участников создания модели при описании системы не несет ответственности за качество моделирования: а) автор б) эксперт в) читатель Ответ: в) 26. При выполнении какого вида тестирования тестируется отдельный модуль, в отрыве от остальной системы:а) при выполнении интеграционного тестирования б) при выполнении модульного тестирования в) при выполнении системного тестирования Ответ: б) 27. С какой ролью можно совмещать разработку: а) архитектура б) управление продуктом в) тестирование Ответ: а) 28. На каком уровне зрелости осуществляется анализ причин возникновения проблем и предотвращение их появления в будущем: а) на уровне зрелости 3 б) на уровне зрелости 4 в) на уровне зрелости 5 Ответ: в) 29. Какой этап следует за созданием требований к продукту при использовании метода Scrum: а) планирование итерации б) анализ результатов, пересмотр требований в) выполнение итерации Ответ: а) 30. На каком уровне процессы в полной мере существуют лишь в рамках отдельных проектов: а) на начальном уровне б) на управляемом уровне в) на оптимизирующемся уровне Ответ: б) КРИТЕРИИ ОЦЕНИВАНИЯ ВОПРОСОВ ЗАКРЫТОГО ТИПА Каждое задание оценивается 1 баллом. Оценивание КИМ теоретического характера в целом: "зачтено" - верно выполнено не менее 50% заданий; "не зачтено" - верно выполнено не более 50% заданий "отлично" - верно выполнено 85..100% заданий; "хорошо" - верно выполнено 70..84% заданий; "удовлетворительно" - верно выполнены 50..69% заданий; "неудовлетворительно" - верно выполнены менее 50% заданий ПРИМЕРЫ ЗАДАНИЙ ОТКРЫТОГО ТИПА 1. Что представляют собой метрики программного продукта? Ответ: Метрики программного продукта - это количественные показатели, которые используются для измерения и оценки различных характеристик программного продукта. Они могут включать в себя такие параметры, как количество строк кода, время выполнения программы, количество ошибок и т. д. Метрики помогают разработчикам и менеджерам программного проекта получить объективную информацию о качестве и эффективности продукта. 2. Чем характеризуются внутренние метрики продукта? Ответ: Внутренние метрики продукта характеризуются тем, что они измеряют и оценивают внутренние характеристики программного продукта, такие как структура кода, сложность алгоритмов, уровень повторяемости кода и т. д. Они помогают разработчикам определить качество и поддерживаемость кода, а также выявить потенциальные проблемы и улучшить процесс разработки. Внутренние метрики также могут использоваться для сравнения различных версий программного продукта и определения эффективности внесенных изменений. 3. В чём заключается метод С.Шлеер и С.Меллора? Ответ: Метод Шлеер и Меллора, также известный как метод объектно-ориентированного анализа и проектирования, заключается в разработке программного продукта, основанного на объектно-ориентированном подходе. Он предполагает выявление основных объектов системы, их атрибутов и взаимодействий, а также определение классов и их иерархии. Этот метод позволяет создавать гибкие и расширяемые программные системы, которые легко поддерживать и модифицировать. 4. Какую последовательность работ предполагает каскадная модель разработки ПО? Ответ: Каскадная модель разработки ПО предполагает следующую последовательность работ: анализ требований, проектирование, разработка, тестирование и сопровождение. В этой модели каждая фаза выполняется последовательно, и переход к следующей фазе происходит только после завершения предыдущей. Такой подход обеспечивает четкое планирование и контроль процесса разработки, но не предусматривает возможность параллельной работы над различными аспектами проекта. 5. Проектирование проектных решений, это? Ответ: Проектирование проектных решений - это процесс разработки и создания детального плана или концепции для реализации проекта. Он включает в себя определение целей и требований проекта, анализ возможных вариантов решений, выбор оптимального варианта и разработку детального плана действий. Проектирование проектных решений позволяет определить необходимые ресурсы, оценить риски и принять решения, необходимые для успешной реализации проекта. 6. Что представляет собой процесс проектирование программных систем? Ответ: Процесс проектирования программных систем - это систематическое и творческое создание архитектуры и дизайна программного продукта, учитывая его требования, функциональность и ограничения. Он включает в себя определение структуры, компонентов, интерфейсов и взаимодействия между ними, а также выбор подходящих технологий и инструментов разработки. В результате процесса проектирования создается план реализации программной системы, который затем используется во время разработки и тестирования. 7. Определите принципы объектно-ориентировананного программирования? Ответ: Принципы объектно-ориентированного программирования включают абстракцию, инкапсуляцию и полиморфизм. Абстракция позволяет выделить существенные характеристики объектов и игнорировать несущественные детали. Инкапсуляция обеспечивает объединение данных и методов в классы, скрывая внутреннюю реализацию и предоставляя только интерфейс взаимодействия. Полиморфизм позволяет использовать объекты разных классов с одинаковыми методами, что упрощает кодирование и повышает гибкость приложения. 8. В чём заключается стандартизация программного обеспечения? Ответ: Стандартизация программного обеспечения заключается в установлении общепринятых и однозначных правил, спецификаций и протоколов, которые определяют форматы данных, интерфейсы и поведение программных компонентов. Это позволяет обеспечить совместимость и взаимодействие между различными системами и приложениями, упростить разработку, тестирование и сопровождение программного обеспечения, а также повысить его качество и безопасность. Стандартизация также способствует улучшению межоперационной совместимости и обмену информацией между различными платформами и устройствами. 9. В чём заключается сертификация программного обеспечения? Ответ: Сертификация программного обеспечения - это процесс подтверждения соответствия программного продукта определенным стандартам, требованиям и нормативам. В ходе сертификации проводится анализ и проверка качества, безопасности, функциональности и соответствия программного обеспечения заданным спецификациям. Получение сертификата подтверждает, что программное обеспечение соответствует определенным критериям и может быть использовано с высоким уровнем надежности и безопасности. Сертификация также может быть требованием для использования программного обеспечения в определенных отраслях или сферах деятельности. 10. Определите различия между оптимизацией программного кода и рефакторингом? Ответ: Оптимизация программного кода и рефакторинг - это два разных подхода к улучшению программного обеспечения. Оптимизация кода направлена на улучшение производительности, эффективности и использования ресурсов программы, обычно путем оптимизации алгоритмов, структур данных или использования специфических оптимизирующих техник. Рефакторинг, с другой стороны, фокусируется на улучшении внутренней структуры и качества кода, с целью повышения его понятности, гибкости и легкости сопровождения, без изменения его функциональности. Рефакторинг может включать переименование переменных, вынос повторяющегося кода в отдельные функции или классы, устранение дублирования и упрощение сложных конструкций кода. 11. Опишите цели обратного инжененринга. Ответ: Цели обратного инженеринга включают понимание и анализ уже существующего программного обеспечения, которое не сопровождается достаточной документацией или исходным кодом. Обратный инженеринг помогает выявить структуру и архитектуру программы, а также понять ее функциональность и взаимодействие с другими системами. Это позволяет внести изменения, улучшить или перенести программное обеспечение на другую платформу без необходимости полной переработки с нуля. Кроме того, обратный инженеринг может быть полезен для анализа и исправления ошибок, оптимизации производительности и обеспечения безопасности программного обеспечения. 12. Каким оразом осуществляется опровождение программного обеспечения? Ответ: Опровождение программного обеспечения осуществляется путем поддержки и обслуживания программного продукта после его выпуска. Это включает в себя обнаружение, исправление и тестирование ошибок, обновление и улучшение функциональности, а также обеспечение совместимости с новыми технологиями и платформами. Опровождение программного обеспечения также может включать обучение пользователей, предоставление технической поддержки и обновление документации. 13. В чём разница между поддержкой и сопровождением ПО? Ответ: Разница между поддержкой и сопровождением программного обеспечения заключается в их целях и активностях. Поддержка ПО ориентирована на оказание помощи конечным пользователям, включая решение проблем, ответы на вопросы и предоставление технической поддержки. Сопровождение ПО, с другой стороны, включает в себя более широкий спектр деятельностей, таких как исправление ошибок, обновление функциональности, оптимизация и адаптация программного обеспечения к новым требованиям и технологиям. Таким образом, поддержка ПО является частью сопровождения, но не охватывает все его аспекты. 14. Какие этапы жизненного цикла существуют в стандарте PMBOK? Ответ: В стандарте PMBOK выделяются пять этапов жизненного цикла проекта: инициация, планирование, выполнение, контроль и завершение. Каждый из этих этапов имеет свои уникальные задачи и цели, направленные на успешное выполнение проекта. 15. Что такое «железнный треугольник» проекта? Ответ: Железный треугольник проекта – это концепция, которая отображает взаимосвязь между тремя основными факторами проекта: сроками, стоимостью и качеством. Он указывает на то, что изменение одного из этих факторов может повлиять на другие, и для достижения успеха проекта необходимо найти баланс между ними. 16. Что является критерием качества программного продукта? Ответ: Критерий качества программного продукта – это характеристика или стандарт, по которому оценивается его соответствие требованиям и ожиданиям пользователей. Он может включать в себя такие аспекты, как функциональность, надежность, производительность, удобство использования и безопасность. 17. Что включает в себя система измерения ПО? Ответ: Система измерения ПО включает в себя набор метрик и инструментов, которые используются для оценки различных аспектов программного обеспечения. Она может включать в себя метрики процесса разработки, такие как время и затраты, а также метрики качества, такие как количество ошибок или уровень покрытия кода тестами. 18. Что представляет собой CASE-технология разработки ПО? Ответ: CASE-технология разработки ПО представляет собой методологию, которая использует компьютерные инструменты для автоматизации различных этапов жизненного цикла разработки программного обеспечения. Она включает в себя инструменты для моделирования, анализа, проектирования, тестирования и документирования программного продукта, упрощая и ускоряя процесс разработки. 19. Что нужно предпринять для повышения эффективности программного обеспечения? Ответ: Для повышения эффективности программного обеспечения необходимо принять ряд мер. Во-первых, следует провести анализ и оптимизацию процессов разработки и тестирования, устранить узкие места и избыточные операции. Во-вторых, важно инвестировать в обучение и развитие команды разработчиков, чтобы повысить их навыки и знания. Также целесообразно использовать автоматизированные инструменты и методы, такие как CI/CD и DevOps, чтобы ускорить процесс разработки и достичь более высокой степени автоматизации. 20. Охарактеризуйте требования по разработке ПО в стандарте SWEBOK? Ответ: В стандарте SWEBOK требования по разработке ПО охарактеризованы как процесс определения, документирования и утверждения функциональных и нефункциональных характеристик программного продукта. Они включают в себя требования к функциональности, производительности, надежности, безопасности, а также требования к интерфейсам, архитектуре и дизайну программы. КРИТЕРИИ ОЦЕНИВАНИЯ ВОПРОСОВ ОТКРЫТОГО ТИПА "Отлично"/зачтено. Ответ полный, развернутый. Суть передана исчерпывающе и точно, принятая терминология полностью сохранена. Ошибок нет. "Хорошо"/зачтено. Ответ полный, но краток. Суть передана точно, но имеются неточности в использовании терминологии. Ошибки незначительны. "Удовлетворительно"/зачтено. Ответ неполный. Значительные неточности в применении терминологии. Студент владеет частью материала. "Неудовлетворительно"/не зачтено. Ответа нет, либо он не раскрывает сути требуемого. Студент не владеет материалом. |
| 5.2. Темы письменных работ для проведения текущего контроля (эссе, рефераты, курсовые работы и др.) |
| Не предусмотрены |
| 5.3. Фонд оценочных средств для проведения промежуточной аттестации |
| Промежуточная аттестация заключается в проведении в конце семестра экзамена по всему курсу. Экзамен проводится в устной форме по билетам. В билет входит 2 вопроса теоретического характера. ВОПРОСЫ ТЕОРЕТИЧЕСКОГО ХАРАКТЕРА 1. Принципы проектирования. 2. Организация процесса конструирования ПО. 3. Классический жизненный цикл ПО. 4. Модели проектирования ПО. 5. Стратегии конструирования ПО. 6. Модели качества процессов конструирования. 7. Руководство программным проектом. 8. Планирование проектных задач. 9. Метрики программного проекта. 10. Размерно-ориентированные метрики. 11. Функционально-ориентированные метрики. 12. Классические методы анализа программных проектов. 13. Структурный анализ. Диаграммы потоков данных. 14. Описание потоков данных и процессов. 15. Методы анализа, ориентированные на структуры данных. 16. Метод анализа Варнье—Орра. диаграммы Варнье. 17. Метод анализа Джексона. 18. Этапы методики анализа Джексона. 19. Особенности процесса синтеза программных систем. Особенности этапа проектирования. 20. Моделирование управления системой. Декомпозиция подсистем на модули. Свойства модулей. 21. Сложность программной системы. 22. Основы проектирования программных, систем. 23. Классические методы проектирования. 24. Языки описания программных проектов. Универсальный язык описания программных проектов (UML). 25. Case – системы. Элементы описания Use Case. 26. Принципы объектно-ориентированного представления программных систем. 27. Классы. Их свойства и характеристики. 28. Унифицированный процесс разработки объектно-ориентированных ПС. 29. Эволюционно-инкрементная организация жизненного цикла разработки. Управление риском. 30. Этапы унифицированного процесса разработки. 31. Понятие ресурсов операционной системы (ОС). Аппаратные и программные ресурсы. 32. Интерфейс программных приложений ОС (API). Системные вызовы ОС (API – функции). 33. Структура программной системы использующей ресурсы ОС. 34. Инструментальные среды, использующие ресурсы ОС. 35. Визуальные инструментальные среды. 36. Тестирование программной системы (ПС). Этапы тестирования ПС. 37. Стратегии разработки тестов. Автономное и комплексное тестирование ПС. 38. Понятие качества ПС. Критерии качества ПС. Подходы к обеспечению качества ПС. 39. Сложность ПС. Определение сложности ПС. 40. Характеристики сложности. Меры сложности. 41. Вычисление сложности. Анализ сложности ПС. 42. Программирование в сетевых технологиях. 43. Программирование в создании микроконтроллерных устройств. 44. Применение параллельного программирования на современных процессорах. Системы распараллеливания. 45. Применение параллельного программирования на современных видеокартах. CUDA. OpenCL. КРИТЕРИИ ОЦЕНИВАНИЯ: «Отлично» (зачтено): студентом дан полный, в логической последовательности развернутый ответ на поставленные вопросы, где он продемонстрировал знания предмета в полном объеме учебной программы, достаточно глубоко осмысливает дисциплину, самостоятельно, и исчерпывающе отвечает на дополнительные вопросы, приводит собственные примеры по проблематике поставленного вопроса, решил предложенные практические задания без ошибок. «Хорошо» (зачтено): студентом дан развернутый ответ на поставленный вопрос, где студент демонстрирует знания, приобретенные на лекционных и семинарских занятиях, а также полученные посредством изучения обязательных учебных материалов по курсу, дает аргументированные ответы, приводит примеры, в ответе присутствует свободное владение монологической речью, логичность и последовательность ответа. Однако допускаются неточности в ответе. Решил предложенные практические задания с небольшими неточностями. «Удовлетворительно» (зачтено): студентом дан ответ, свидетельствующий в основном о знании процессов изучаемой дисциплины, отличающийся недостаточной глубиной и полнотой раскрытия темы, знанием основных вопросов теории, слабо сформированными навыками анализа явлений, процессов, недостаточным умением давать аргументированные ответы и приводить примеры, недостаточно свободным владением монологической речью, логичностью и последовательностью ответа. Допускается несколько ошибок в содержании ответа и решении практических заданий. «Неудовлетворительно» (не зачтено): студентом дан ответ, который содержит ряд серьезных неточностей, обнаруживающий незнание процессов изучаемой предметной области, отличающийся неглубоким раскрытием темы, незнанием основных вопросов теории, неумением давать аргументированные ответы. Выводы поверхностны. Решение практических заданий не выполнено. Студент не способен ответить на вопросы даже при дополнительных наводящих вопросах преподавателя. |
| Приложения |
|
Приложение 1.
ФОС_ТРПО_ПК4_ПК5.docx
|
6. Учебно-методическое и информационное обеспечение дисциплины
| 6.1. Рекомендуемая литература | ||||
| 6.1.1. Основная литература | ||||
| Авторы | Заглавие | Издательство, год | Эл. адрес | |
| Л1.1 | Сергиевский Г.М., Волченков Н.Г. | Функциональное и логическое программирование: учеб. пособие для вузов | М.: Академия, 2010 | |
| Л1.2 | Незнанов А.А. | Программирование и алгоритмизация: учебник | М.: Академия, 2010 | |
| 6.1.2. Дополнительная литература | ||||
| Авторы | Заглавие | Издательство, год | Эл. адрес | |
| Л2.1 | Т. А. Павловская | С / С++. Программирование на языке высокого уровня: учеб. для вузов | СПб.[и др.]: Питер, 2007 | |
| Л2.2 | В. В. Лаптев | С++. Объектно-ориентированное программирование: учеб. пособие | СПб.[и др.]: Питер, 2008 | |
| 6.2. Перечень ресурсов информационно-телекоммуникационной сети "Интернет" | ||||
| Название | Эл. адрес | |||
| Э1 | ТРПО | portal.edu.asu.ru | ||
| 6.3. Перечень программного обеспечения | ||||
| Visual Studio Условия использования: https://code.visualstudio.com/license) Open Office – Условия использования по ссылке http://www.openoffice.org/license.html LibreOffice Условия использования: https://ru.libreoffice.org/about-us/license/ 7-zip Условия использования: https://www.7-zip.org/license.txt Acrobat Reader Условия использования: http://wwwimages.adobe.com/content/dam/Adobe/en/legal/servicetou/Acrobat_com_Additional_TOU-en_US-20140618_1200.pdf Mozila FireFox Условия использования: https://www.mozilla.org/en-US/about/legal/eula/ Chrome Условия использования: http://www.chromium.org/chromium-os/licenses Microsoft WindowsMicrosoft Office 2010 (Office 2010 Professional, № 4065231 от 08.12.2010), (бессрочно); Microsoft Windows 7 (Windows 7 Professional, № 61834699 от 22.04.2013), (бессрочно); Chrome (http://www.chromium.org/chromium-os/licenses), (бессрочно); 7-Zip (http://www.7-zip.org/license.txt), (бессрочно); AcrobatReader (http://wwwimages.adobe.com/content/dam/Adobe/en/legal/servicetou/Acrobat_com_Additional_TOU-en_US-20140618_1200.pdf), (бессрочно); ASTRA LINUX SPECIAL EDITION (https://astralinux.ru/products/astra-linux-special-edition/), (бессрочно); LibreOffice (https://ru.libreoffice.org/), (бессрочно); Веб-браузер Chromium (https://www.chromium.org/Home/), (бессрочно); Антивирус Касперский (https://www.kaspersky.ru/), (до 23 июня 2024); Архиватор Ark (https://apps.kde.org/ark/), (бессрочно); Okular (https://okular.kde.org/ru/download/), (бессрочно); Редактор изображений Gimp (https://www.gimp.org/), (бессрочно) | ||||
| 6.4. Перечень информационных справочных систем | ||||
| Не требуется | ||||
7. Материально-техническое обеспечение дисциплины
| Аудитория | Назначение | Оборудование |
|---|---|---|
| 001вК | склад экспериментальной мастерской - помещение для хранения и профилактического обслуживания учебного оборудования | Акустический прибор 01021; виброизмеритель 00032; вольтметр Q1202 Э-500; вольтметр универсальный В7-34А; камера ВФУ -1; компьютер Турбо 86М; масспектрометр МРС -1; осциллограф ЕО -213- 2 ед.; осциллограф С1-91; осциллограф С7-19; программатор С-815; самописец 02060 – 2 ед.; стабилизатор 3218; терц-октавный фильтр 01023; шкаф вытяжной; шумомер 00026; анализатор АС-817; блок 23 Г-51; блок питания "Статрон" – 2 ед.; блок питания Ф 5075; вакуумный агрегат; весы; вольтметр VM -70; вольтметр В7-15; вольтметр В7-16; вольтметр ВУ-15; генератор Г-5-6А; генератор Г4-76А; генератор Г4-79; генератор Г5-48; датчик колебаний КВ -11/01; датчик колебаний КР -45/01; делитель Ф5093; измеритель ИМП -2; измеритель параметров Л2-12; интерферометр ИТ 51-30; источник "Агат" – 3 ед.; источник питания; источник питания 3222; источник питания ЭСВ -4; лабораторная установка для настройки газовых лазеров; лазер ЛГИ -21; М-кальк-р МК-44; М-калькул-р "Электроника"; магазин сопротивления Р4075; магазин сопротивления Р4077; микроскоп МБС -9; модулятор МДЕ; монохроматор СДМС -97; мост переменного тока Р5066; набор цветных стекол; насос вакумный; насос вакуумный ВН-01; осциллограф С1-31; осциллограф С1-67; осциллограф С1-70; осциллограф С1-81; осциллоскоп ЕО -174В – 2 ед.; пентакта L-100; пирометр "Промень"; пистонфон 05001; преобразователь В9-1; прибор УЗДН -2Т; скамья оптическая СО 1м; спектограф ДФС -452; спектограф ИСП -51; стабилизатор 1202; стабилизатор 3217 – 4 ед.; стабилизатор 3218; стабилизатор 3222 – 3 ед.; станок токарный ТВ-4; усилитель мощности ЛВ -103 – 4 ед.; усилитель У5-9; центрифуга ВЛ-15; частотомер Ч3-54А; шкаф металлический; эл.двигатель; электродинамический калибратор 11032 |
| Учебная аудитория | для проведения занятий лекционного типа, занятий семинарского типа (лабораторных и(или) практических), групповых и индивидуальных консультаций, текущего контроля и промежуточной аттестации, курсового проектирования (выполнения курсовых работ), проведения практик | Стандартное оборудование (учебная мебель для обучающихся, рабочее место преподавателя, доска) |
| Учебная аудитория | для проведения занятий лекционного типа, занятий семинарского типа (лабораторных и(или) практических), групповых и индивидуальных консультаций, текущего контроля и промежуточной аттестации, курсового проектирования (выполнения курсовых работ), проведения практик | Стандартное оборудование (учебная мебель для обучающихся, рабочее место преподавателя, доска) |
| Помещение для самостоятельной работы | помещение для самостоятельной работы обучающихся | Компьютеры, ноутбуки с подключением к информационно-телекоммуникационной сети «Интернет», доступом в электронную информационно-образовательную среду АлтГУ |
| 419К | лаборатория информационных технологий - компьютерный класс - учебная аудитория для проведения занятий семинарского типа (лабораторных и(или) практических); проведения групповых и индивидуальных консультаций, текущего контроля и промежуточной аттестации; | Учебная мебель на 17 посадочных мест; рабочее место преподавателя; доска маркерная - 1 шт.; компьютеры: NAIO Corp Z520, НЭТА - 4 in - 13 ед. |