CC BY
40
Опыт развития навыков разработки встроенного программного обеспечения на базовой кафедре МАИ (НИУ) - МОКБ «Марс»
Кузьмин Сергей Александрович ассистент кафедры "Бортовая автоматика беспилотных космических и атмосферных летательных аппаратов", Московский авиационный институт (НИУ). Москва, (499)158-47-69, [email protected]
Порешин Петр Петрович старший преподаватель кафедры "Бортовая автоматика беспилотных космических и атмосферных летательных аппаратов", Московский авиационный институт (НИУ). Москва, (499)158-47-69, [email protected]
Синицын Сергей Владимирович кандидат технических наук, профессор кафедры "Бортовая автоматика беспилотных космических и атмосферных летательных аппаратов", Московский авиационный институт (НИУ). Москва, (499)158-47-69 svsinitsyn@mai. ru
Саурский Илья Викторович начальник лаборатории «ФГУП Московское опытно-конструкторское бюро «Марс». Москва, saurskiy [email protected] (499)978-47-71
Аннотация
Создание высококритичного по области применения встроенного программного обеспечения требует наличия у разработчиков некоторых специфических навыков. Для их формирования приходится применять ряд методических приемов, инструментальных средств и технологических процедур, редко встречающихся при создании программных систем общего назначения. Опыт предприятия, занимающегося созданием систем управления беспилотными аппаратами, был положен в основу учебного плана подготовки специалистов по направлению 161101 «Системы управления летательными аппаратами». Обсуждается опыт его воплощения на кафедре Московского авиационного института (Национального исследовательского университета) совместно с коллективом базового предприятия - Московского опытно-конструкторского бюро «Марс».
Creating application field-critical embedded software requires developers with several specific skills. Building those skills requires the use of a number of methodological techniques, instruments and technological procedures that rarely occur during development of general purpose software systems.
The experience of company engaged in the creation of control systems of unmanned vehicles was used as the basis for curriculum for field of study 161101 "Aircraft Control Systems". This article discusses its application in the departament of Moscow Aviation Institute jointly with collective of basic company - Moscow Experimental Design Bureau "Mars".
Ключевые слова
базовая кафедра, системы управления, встроенное программное обеспечение, оценка работ.
basic department, control systems, embedded software, evaluation works.
Введение
При создании современных систем управления (СУ) в высокотехнологичных областях ключевую роль играют микропроцессорные системы, скорость, точность и надежность которых подтверждены многолетней практикой их применения. Основным фактором, обеспечивающим гибкость использования цифровой вычислительной техники, является их программное обеспечение. Технологии его разработки, обеспечивающие сжатые сроки и высокое качество являются предметом пристального внимания и дискуссий программирующего сообщества в течение последних десятилетий.
Особое отношение заслужило программное обеспечение, используемое в таких отраслях, где его неправильная работа может привести к большим материальным потерям, человеческим жертвам, экологическим катастрофам. Для этих областей применения на государственном, а порой и межгосударственном уровнях созданы стандарты [1,2], регламентирующие процессы разработки и верификации программного обеспечения. Одним из ярких примеров подобного подхода являются документы серии DO-178 (в Российской Федерации серия КТ-178), которые уже десятки лет регламентируют сертификацию программных систем в авиации. Поэтому знакомство с документами подобного типа и развитие навыков работы в соответствии с их требованиями является одной из задач подготовки специалистов в области создания встраиваемого программного обеспечения (ВПО).
Основные проблемы
В чем же состоит специфика разработки ВПО? Начнем с того, что процессоры и операционные среды ВПО не приспособлены для проведения разработки непосредственно на них. Они не имеют средств трансляции программного кода с языков разработки в целевой код и часто не имеют файловой системы для ведения документации разработки. Все это реализуется в среде кросс-систем программирования, функционирующих на инструментальных процессорах, архитектура которых может значительно отличаться от архитектуры целевого процессора.
Соответственно и вся система кросс-разработки по своему составу отличается от целевой системы. В нее, как правило, не могут быть включены реальные устройства и их интерфейсы, являющиеся датчиками и исполнительными элементами в целевой системе. Вместо этого используются различные модели и имитаторы. Даже сам целевой код в инструментальной среде исполняется на эмуляторе целевого процессора, что создает дополнительные трудности для оценки скорости его выполнения.
Из-за длительности разработки (несколько лет), сопровождения и эксплуатации (десятки лет) документирование ВПО и всех процессов его создания становится самостоятельной проблемой. Это касается вопросов хранения и гарантии целостности документации разработки, которые обеспечиваются применением специальных баз данных и соответствующих процессов, которые в вышеупомянутых стандартах получили
наименование процессов конфигурационного управления и систем конфигурационного управления (СКУ).
Дополнительным фактором, влияющим на требования к документации, является изменение состава участников разработки. Потому развитие навыка написания документации в форме пригодной для отчуждения ее от автора, является одной из актуальных задач подготовки разработчиков ВПО.
Наконец, коснемся проблем организации работ в коллективе: согласование интерфейсов ВПО, распределения функций по компонентам, соблюдение сроков разработки и т.п. Все это обязательные составляющие современной инженерной разработки, которыми молодой специалист должен овладеть в период обучения.
Пути решения
При создании кафедры «Бортовая автоматика беспилотных космических и атмосферных летательных аппаратов» МАИ (НИУ) и ФГУП МОКБ «Марс» ставили целью подготовку специалистов, способных сразу после окончания университета войти в производственные процессы предприятий ракетно-космической отрасли, принимать участие в разработке систем управления космических аппаратов, проводить разработку и комплексные испытания ВПО аэрокосмических систем.
Для достижения этой цели базовое предприятие не только предоставило широкий спектр своих технологий и инструментальных комплексов, но и обеспечило подключение компетентного состава своих сотрудников для подготовки учебных программ и проведения занятий со студентами базовой кафедры. В 2010 году на территории предприятия был оборудован учебный корпус с лекционными и лабораторными аудиториями. По материалам основных проектов, выполняемых предприятием, был выпущен комплект учебных пособий [3-7].
Для проведения занятий в рамках базовой кафедры был сформирован преподавательский коллектив, состоящий из трех непересекающихся групп. В первую, самую многочисленную, вошли профессиональные преподаватели других кафедр МАИ (НИУ), проводящие занятия по общеобразовательным и ряду общепрофессиональных дисциплин. Все проводимые ими занятия проходят в аудиториях университета и находятся под традиционным контролем учебного управления и деканата. Базовая кафедра в отношении программ этих дисциплин играет согласующую роль, так как группа студентов базовой кафедры включена в общий поток.
Вторая группа преподавателей образует собственно кафедральный коллектив, сформированный в основном из совместителей - сотрудников базового и родственных ему предприятий. Степень их вовлечения в преподавательскую деятельность зависит от выполняемой нагрузки и колеблется от 0,1 до 0,25 ставки. Основной объем, проводимых этой группой занятий, относится к специальным дисциплинам, читаемым только студентам базовой кафедры, а сами занятия проводятся в учебном корпусе на территории предприятия.
Наконец, выделилась группа сотрудников предприятия, оказавшихся активно вовлеченными в образовательный процесс в рамках узко специализированных занятий, проводимых на базе производственных процессов предприятия, обеспечивающих руководство индивидуальными работами студентов: учебно-исследовательской работой, курсовыми и дипломными проектами, практиками. Для координации их действий на базовом предприятии было создано специальное подразделение.
Для осуществления поддержки и развития у студентов навыков коллективной работы было решено сформировать общее информационное пространство на базе использующихся на предприятии программных средств — системы управления проектами Redmine [8] и системы контроля версий Subversion [9,10] (subversion.apache.org). Каждая из этих систем работает в режиме «клиент-сервер», обеспечивая механизм многопользовательского распределенного доступа к данным. Работа с ними не требует специализированных клиентских программ, достаточно любого современного браузера.
Система Redmine представляет собой приложение для управления проектами и задачами, для контроля за ошибками в разрабатываемом программном обеспечении. Система позволяет: сопровождать несколько проектов, обеспечивает систему доступа, основанную на ролях, отображать прогресс разработки в виде диаграмм Ганта, вести учет временных затрат и дает возможность оповещать обо всех изменениях в проектах.
Система контроля версий Subversion предоставляет сервисы по хранению электронных документов и программного кода, хранению информации о проведенных над ними изменениях и позволяет идентифицировать пользователя, внесшего эти изменения. Результатом каждого изменения является создание на сервере системы новой версии документа или файла с программным кодом.
Основными целями их внедрения этих программных инструментов было: o накопление всех результатов выполнения учебных заданий каждого студента для последующего анализа и определения индивидуальной траектории его подготовки;
o формирование у студента навыков работы в обобщенной среде конфигурационного управления с применением современных инструментальных средств и отчуждением результатов его работы; o обеспечение оперативного контроля выполнения индивидуальных заданий студентов;
o сбор объективных данных для оценки работы студента в семестре; o контроль со стороны администрации кафедры за своевременностью выдачи
индивидуальных заданий студентам и соблюдением учебного графика. Такой подход потребовал введения в информационной среде определенной системы ролей. Головную роль выполняет заведующий кафедрой или его заместитель по учебной работе. Задача этой роли - формирование в системе реализуемой части учебного плана. Фактически речь идет о формировании в системе проектов, соответствующих тем видам занятий семестровых планов, которые попадают под контроль Redmine. Это лабораторные занятия, курсовые работы, учебно-исследовательские проекты и т.п. Ответственными за выполнение этих работ назначаются преподаватели, выполняющие соответствующую нагрузку.
В свою очередь, преподаватель формирует индивидуальные проекты студентов, в рамках которых определяет график выполнения работ. Каждой работе приписывается свой «вес» - трудоемкость, а в последующем и степень выполнения, что позволяет вычислять количество набранных за выполненную работу «баллов». Кроме того могут устанавливаться штрафные баллы за несвоевременное начало и/или окончание работы.
Студент в процессе выполнение своего проекта обязан сохранять все результаты работы в системе. Отсутствие данных к указанному в работе моменту времени обычно наказывается штрафом. Кроме того, преподаватель может проверить и оценить только находящиеся в системе документы. Если результат (в том числе и промежуточный) не оформлен и не размещен в хранилище, то студент не может получить помощь со стороны преподавателя. При этом использование системы версионного контроля (Рис.1)
позволяет сохранять в системе все промежуточные результаты (версии проекта) и, при необходимости, проводить ретроспективный анализ хода выполнения здания.
^ А / - Хранилище - Ефимов i- >:Обзор - УИРС-2 • И н фор г
СО studserv, mars/red mine/projects/efimov/repository
I Моя страница Проекте! Администрирование floi
Дисциплина "Программно-алгоритмическое обеспечение встроенных систем" 2015 учебный год, семестр 4 » УИРС-2 » Ефимов A.C. УИРС-2
Обзор Действия Задачи Новая задача Диаграмма Ганта Календарь Новости Документы Wiki Файлы
efimov
Имя Размер Редакция Возраст Автор
о т Regulate 25 3 месяца Алексей Ефимов
Q Интерфейсов 93,371 КБ 28 3 месяца Алексей Ефимов начата пояснительная записка, наг
] Пояснительная записка.doc 52 Кб 29 3 месяца Алексей Ефимов Написана пояснительная записка
| Пояснительная записка.odt 16,635 КБ 27 3 месяца Алексей Ефимов Начата пояснительная записка
Q Тест_план.о<Й: 15,313 КБ 26 3 месяца Алексей Ефимов добавлен тест план
П ФункцТреб-odt 1а,946 КБ 22 4 месяца Алексей Ефимов внесены изменения в работу автом
Последние редакции
# Дата Автор Комментарий
29 ф 27.05.2015 09 56 Алексей Ефимов Написана пояснительная записка
28 © ф 20.05.2015 10 21 Алексей Ефииов начата пояснительная записка, написан тест план
27 © © 20.05.2015 10 20 Алексей Ефимов Начата пояснительная записка
26 © © 20.05.2015 10 20 Алексей Ефимов добавлен тест план
25 © © 20.05.2015 10 20 Алексей Ефимов
24 © © 29.04.2015 09 42 Алексей Ефимов написан код
23 © © 22.04.2015 09 36 Алексей Ефимов написан главный модуль, исправлены параметры функций.
22 © © 15.04.2015 11 34 Алексей Ефимов внесены изменения в работу автоматического режима работы и старта систб
21 © © 14.04.2015 09 29 Сергей Синицын Добавлены замечания по поводу противоречивости
20 © 08.04.2015 09 47 Алексей Ефимов программа начата
Просмотреть отличия ] Показать все ревизии Рис. 1. Окно контроля версий результатов работы студента
в системе Redmine.
На Рис.1 представлено окно системы Redmine, отображающее содержимое связанного хранилища версий системы Subversion. Опции меню демонстрируют функциональные возможности системы, а именно:
o опция "Обзор" отображает основную информацию о проекте (список
пользователей, ссылки на основные документы); o опция "Действия" позволяет просматривать список действий
пользователей данного проекта в хронологическом порядке; o опция "Задачи" позволяет выводить в табличном виде список задач,
выполняемых в данном проекте; o опция "Новая задача" обеспечивает возможность создания новых задач и
назначения ответственных исполнителей; o опция "Диаграмма Ганта" выводит на экран задачи по данному проекту в
виде диаграмы Ганта; o опция "Календарь" отображает в виде событий календаря сроки
выполнения задач текущего проекта o опция "Новости" выводит на экран последние новости (групповые
оповещения для участников проекта) o опция "Документы" предоставляет доступ к документам, связанным с проектом, но не попадающих под версионный контроль
o опция "Wiki" обеспечивает доступ к системе Wiki-страниц, связанных с данным проектом. Такие страницы носят вспомогательный характер и используются в качестве справочной информации. o опция "Файлы" предоставляет доступ к файлам, связанным с проектом, но
не попадающих под версионный контроль o опция "Хранилище" обеспечивает доступ к связанному с текущим
проектом хранилищу версий Subversion; o опция "Настройки" позволяет проводить настройку параметров проекта.
Пример (Рис.1.) демонстрирует состояние хранилища документов проекта пользователя (студента) Efimov. Проект находится под управлением системы Redmine. В терминах конфигурационного управления, здесь приведена текущая конфигурация проекта.
Сведения по составу проекта (документы и файлы), хранящегося в системе, отражаются в верхней части окна. Каждый документ или файл проекта характеризуется следующим свойствами:
o "Имя" — идентификатор документа либо файла; o "Размер" — объем документа либо файла;
o "Редакция" — номер версии документа. Данный номер может соответствовать либо последней версии конфигурации проекта, либо последней версии, в которой этот документ был изменен o "Возраст" — показывает интервал времени с момента его создания либо с
момента его последнего изменения; o "Автор" — определяет (идентифицирует) пользователя, сделавшего
изменения или добавившего в систему документ. o "Комментарий" — краткая характеристика внесенного изменения.
В частности, объект конфигурации с именем "Интерфейс^Г имеет размер 93871 кб, последнее изменение зафиксировано в версии №28, автор изменений — студент Ефимов, сделал правку 3 месяца назад от даты обращения авторов статьи к текущему проекту.
Нижняя часть окна предназначена для отображения таблицы редакций проекта. Каждая запись таблицы представляет сведения о редакциях проекта и характеризуется следующими свойствами:
o "Номер" — номер версии (редакции) проекта o "Дата" — дата создания версии
o "Автор" — определяет (идентифицирует) пользователя, создавшего версию проекта
o "Комментарий" — краткая характеристика всех внесенных изменений.
Таблица отсортирована начиная с самых последних редакций (наиболее актуальных). Средства системы для данной таблицы позволяют вывести отчет о сравнении изменений между двумя любыми различными версиями (кнопка «Просмотреть отличия»»). Также возможно вывести отчет обо всех проведенных изменениях для всех редакций проекта, начиная с самого начала работ над УИРС («Показать все ревизии»).
Анализ этого примера показывает, что на момент обращения к проекту последняя версия (редакция) имеет номер 29, была создана 27.05.2015 пользователем Ефимовым. Эта версия содержит пять файлов и одну папку. Последние изменения затронули файл «Пояснительная записка.doc», что также видно по сопровождающему комментарию. Согласно требованиям к выполнению УИРС студент должен был до 27.05.2015 разработать документы: пояснительную записку, интерфейс программы, тест-
план программы и описать функциональные требования к ней. Таким образом, конфигурация проекта содержит все необходимые документы и эти документы разработаны не позднее установленного срока.
Обращаясь к различным записям таблицы редакций можно получить отчет о работе данного студента в интересующий преподавателя временной период. Иными словами, система Redmine позволяет проводить контроль состояния работ студента в любой момент времени.
Нормальное функционирование системы информационной поддержки потребовало добавления двух вспомогательных ролей: администратора-инструментальщика, который вводит новые роли и развивает программное обеспечение информационной среды, и секретаря, задачей которого является формирование и сопровождение списков студенческих групп [11, 12].
Основным методическим приемом, ориентированным на развитие необходимых навыков разработчиков ВПО, стал сквозной междисциплинарный проект. Задачей проекта ставится разработка упрощенной системы управления, использующей 3-5 датчиков и 2 - 3 исполнительных механизма. В состав такой системы обязательно включается учет времени.
Примером такой системы может быть упрощенная схема управления светофором на крестообразном перекрестке, которая переключает свет с учетом интенсивности движения транспорта по направлениям. При этом должны выдерживаться минимальный и максимальный интервалы времени разрешающего сигнала. Важным моментом при выполнении подобного проекта является то, что в его воплощении поэтапно участвует несколько разных студентов, передавая друг другу через общее информационное пространство кафедры созданную документацию разработки.
Информационная система поддержки занятий представляет собой образец системы конфигурационного управления, функционирующей согласно требованиям стандартов в области конфигурационного управления [1, 2].
Методическая ценность использования такой информационной системы в том, что студенты имеют возможность освоить приемы работы, применяемые сотрудниками базового предприятия в реальных проектах разработки СУ. Практическая ценность, как для преподавательского состава, так и для студентов, заключается в том, что в любой момент времени каждый пользователь системы может получить данные требуемой конфигурации из информационного пространства. Разделение пользователей на роли позволяет создавать и извлекать типовые конфигурации — (учебный план, проект студента, список группы, исходный код, документация и пр.). Каждая конфигурация может являться совокупностью артефактов, называемых объектами конфигурации (ОК). С помощью дополнительных инструментальных средств становится возможным вычислять статусы таких конфигураций (например, определять динамику работы отдельного студента или группы студентов, определять количество обнаруженных ошибок, количество определять активность преподавателей).
Как это реализуется
Давайте на примере одного учебного курса четвертого семестра «Учебно-исследовательская работа студента» рассмотрим технику реализации вышеозначенного подхода. Возьмем упомянутое выше задание «Светофор», в рамках которого студенту требуется разработать программное обеспечение модуля ядра системы управления.
Термин «ядро» подразумевает наличие вспомогательных модулей: снятия данных с датчиков интенсивности движение, взаимодействия со службой времени, включения и выключения лампочек светофора.
В начале четвертого семестра (реально в первых числах февраля) заместителем заведующего кафедрой создается в системе проект «2015 учебный год, семестр 4-УИРС-2», ответственными за выполнение которого назначаются преподаватели Саурский И.В и Синицын С.В. и сроками выполнения 26 февраля 2015 года - 29 мая 2015 года. Заметим, что списки групп к этому моменту уже сформированы (в первом семестре) и могут при необходимости быть скорректированы секретарем. Оба преподавателя оповещаются автоматически о назначенной им работе.
5 [2015 учебный год, семестр 4 - УИРС-2 #196] (Новая) Проведение УИРС - ИСП3705 - Mozilla Thunde Файл ПраЕкг Вид Пеэехоц Сообщение Инструменты С-разка ^ А Получить | ~ & Создать ^ А Адресная книга ^^ ^ Метка * ^^^^^^^^^^^ ИСЛ3705 Г2015 учебный год, семестр 4 -...
от ¡spz705@mars'L.j'
те ма [2015 учебный год, семестр 4 - УИРС-2 #196] (Новая) Проведение УИРС
Информационная система поддержки занятий Создана новая задача #196 (Сергей Кузьмин).
УИРС-2 #196: Проведение УИРС
• Автор: Сергей Кузьмин
• Статус: Новая
• Приоритет: Высокий
• Назначена: Илья Саурский
• Категория:
• Версия:
Вы назначены для проведения УИРС 4-го семестра.
Для подтверждения Вашего назначения пройдите по ссылке.
Список группы доступен по ссылке.
Вы получили это уведомление о событии так как либо подписаны на него, либо участвуете в нём.
Рис.2. Пример почтового оповещения преподавателя о назначенной работе.
Для назначения преподавателей администратор создает новую задачу в проекте «2015 учебный год, семестр 4-УИРС-2». В результате система Redmine формирует оповещение и отправляет его по электронной почте заданному пользователю. На рис.2 представлен образец такого уведомления. Оно содержит ссылки на информационные ресурсы системы, например, на список группы или на проект, который будет вести
преподаватель. О необходимости скорейшей реакции на данное письмо служат поля уведомления «Статус» и «Приоритет». Как видно из рис.2, назначение преподавателя является новой высокоприоритетной задачей, поэтому преподаватель должен зайти в проект и подтвердить, что уведомление им получено и, он может приступить к выполнению своих обязанностей.
Это оповещение обязывает преподавателя назначить по проекту УИРС-2 (4-й семестр) назначить исполнителей по темам УИРСа (выдать задание). При описываемой технологии, вместе с заданием на УИРС должны быть выданы и исходные данные для создания проекта.
Как отмечалось выше, в основе формирования заданий лежит сквозной междисциплинарный проект разработки упрощенной системы управления, использующей 3 - 5 датчиков и 2 - 3 исполнительных механизма. В состав такой системы обязательно включается учет времени. Этот проект берет свое начало в третьем семестре (УИРС-1).
Пусть студент «Х» выполнил задание УИРС-1 (проект) на логическое проектирование системы управления заданным объектом (предметная область в этом примере носит прикладной характер). Результатом этого проекта является создание типовой конфигурации, содержащей следующие ОК:
• логическое определение входов, как правило, на уровне бинарный датчиков сигналов «есть/нет»;
• логическое описание выходов - «включить/выключить»;
• описание логики работы системы управления в форме конечного автомата;
• пояснительная записка с обоснованием проектных решений.
Теперь эти документы, хранящиеся в СКУ кафедры, и служат исходными данными для студента «У», которого преподаватель назначает исполнителем для проекта реализации ВПО устройства управления того же объекта.
Результатом работы студента «У» будет являться типовая конфигурация: спецификация программных интерфейсов, требования к программному обеспечению, код программы управляющего модуля, тест-план и протокол проверки работоспособности созданной системы и пояснительная записка с обоснованием принятых решений. В качестве вспомогательного результата получаются наборы тестовых данных и программы тестового окружения, которые по объему порой в 2 - 3 раза превышают основной программный код.
Учебный проект разбивается преподавателем на 5 работ общей стоимостью 100 условных единиц трудоемкости (баллов). График начала и окончания работ согласуется с расписанием занятий. В рамках 4-го семестра 2015 года занятия проводились по средам, поэтому оценка итогов (завершение работ) была отнесена на пятницу (20 и 27 марта, 24 апреля, 22 и 29 мая).
Для первых двух работ: разработка программного интерфейса (структуры данных, имена функций, описания и форматы их вызовов) и разработка требований, были определены штрафные баллы, по 10 за просрочку начала работ (т.е. до конца февраля в системе не появились первые версии спецификации интерфейсов и требований к ВПО). Тем самым стимулировалось раннее появление документов, требующих согласования с другими участниками разработки. Отсутствие прототипов этих документов сильно усложняет процесс координации работ при проектировании общей архитектуры системы. Завершение обеих работ планировалось на конец марта. За выполнение работы в полном объеме студент мог получить по 15 баллов. Для этого студент должен был оформить и положить в среду Subversion два документа достаточно
полные, чтобы независимый разработчик (по оценке преподавателя) имел возможность произвести реализацию программного комплекса.
Последующие три работы делили между собой оставшиеся 70 баллов: 15 -кодирование, 30 - разработка тест-плана и 15 - оформление результатов. При этом невыполнение каждой работы в срок наказывалось 20 штрафными баллами. Тем самым получалось, что даже «идеальное» выполнение всех работ не в срок приводило к получению 100 бонусных баллов и 100 штрафных, а если первые работы не были начаты вовремя, то и еще 20 штрафных баллов. Этим стимулировалась выработка у обучающихся представления, что в коллективном проекте работа, выполненная не в срок может оказаться совершенно бесполезной и даже привести к провалу всего проекта.
С точки зрения формирования навыков конструирования ВПО, следует упомянуть еще об одной особенности применяемого инструментария. Собственно разработка кода программы производилась на языке «С» в среде Codeblocks [13]. Принципиальным для процесса проверки работоспособности созданной системы управления является необходимость формирования модуля драйвера - головной программы, которая создает среду функционирования для системы управления, и комплекса процедур заглушек - программных функций имитирующих работу датчиков и исполнительных механизмов. Это тестовое окружение по своему объему и сложности порой превосходит само ВПО, являющееся объектом разработки.
Как правило, тестовое окружение создается в процессе разработки тест-плана и во многом зависит, от выбранной стратегии тестирования. От качества его разработки, со своей стороны, зависит достоверность результатов тестовых испытаний и простота последующей диагностики выявленных несоответствий.
При подведении итогов работ в четвертом семестре была выбрана следующая стратегия. Всего при полном выполнении задания можно набрать до 100 баллов или меньше, с учетом процента выполнения работы. Положительные баллы за выполненную работу вычисляются, как трудоемкость работы, умноженная на процент ее выполнения (оценивается преподавателем по материалам, размещенным в системе). Выполнение работы на 30% и ниже наказывается 20-ю штрафными баллами. Такая работа считается невыполненной. Первоначально каждому участнику начислялось 120 баллов. Итоговая оценка получается суммированием исходных, набранных и вычитанием штрафных баллов:
• 220 - 180 баллов - пятерка;
• 179 - 150 баллов - четверка;
• 149 - 120 баллов - тройка;
• менее 120 - неудовлетворительно.
Итоги применения
В результате применения нового алгоритма оценивания, были получены следующие данные.
Из группы 14 человек:
• 6 студентов получили оценку «5»;
• 2 студента - «4»;
• 6 студентов - «2».
Основной причиной получения студентами неудовлетворительной оценки было нарушение установленных сроков сдачи этапов, в результате чего они получали
штрафные баллы. Так же двое студентов пропускали занятия, соответственно не записывали файлы в Redmine и автоматически получили в итоге «2».
Подробная информация об оценках за этапы приведена в таблице 1.
Таблица 1.
Сту- Процент выполнения и количество баллов за этап Штрафы Итоговая
дент Этап 1 Этап 2 Этап 3 Этап 4 Этап 5 оценка
1 100% 100% 90% 100% 90% 0 217 б
15 б 20 б 13,5 б 35 б 13,5 б «5»
2 70% 70% 70% 100% 70% 0 200,5 б
10,5 б 14 б 10,5 б 35 б 10,5 б «5»
3 50% 50% 90% 80% 80% -40 б 151 б
7,5 б 10 б 13,5 б 28 б 12 б «4»
4 0% 0% 0% 0% 0% -120 б 0 б «2»
5 100% 100% 100% 100% 100% 0 220 б
15 б 20 б 15 б 35 б 15 б «5»
6 0% 0% 0% 0% 0% -120 б 0 б «2»
7 100% 90% 100% 80% 90% 0 209,5 б
15 б 18 б 15 б 28 б 13,5 б «5»
8 80% 40% 0% 0% 0% -60 б 80 б
12 б 8 б «2»
9 100% 100% 90% 90% 90% 0 213,5 б
15 б 20 б 13,5 б 31,5 б 13,5 б «5»
10 100% 90% 90% 10% 10% -90 б 81,5 б
15 б 18 б 13,5 б 3,5 б 1,5 б «2»
11 90% 50% 20% 0% 0% -60 б 83,5 б
13,5 б 10 б 3 б «2»
12 20% 3 б 0% 0% 0% 0% -110 б 13 б «2»
13 90% 90% 40% 10% 50% 0 168,5 б
13,5 б 18 б 6 б 3,5 б 7,5 б «4»
14 100% 90% 90% 90% 90% -20 б 191,5 б
15 б 18 б 13,5 б 31,5 б 13,5 б «5»
Опыт выполнения в общей информационной среде кафедры учебно-исследовательских работ и курсовых проектов показал, что достигаются четыре основных цели: накопление результатов, развитие навыков работы у студентов, оперативность и объективность оценки результатов. В полном объеме не получилось обеспечить контроль преподавателей со стороны администрации. Дело в том, что в настоящий период с системой работает ограниченная часть преподавательского коллектива, которая проводит занятия в первых четвертых семестрах.
Широкого опыта использования системы для преподавателей третьей группы (сотрудников предприятия), проводящих в основном индивидуальные занятия -руководство практикой, курсовыми и дипломными проектами, не получилось. Однако есть надежда, что хорошо опробованный при контроле выполнения работ студентов
механизм будет достаточно эффективен и при контроле своевременности выдачи заданий, согласовании и утверждении тем курсовых и дипломных проектов.
Одновременно стало понятно, что ручное отслеживание хода выполнения проекта и подведение его итогов весьма трудоемко и требует добавления в систему некоторых средств автоматизации, традиционно именуемых системой построения отчетов. Поэтому именно это программное обеспечение было добавлено в систему Redmine в первую очередь.
Кроме того опыт применения системы в учебном процессе показал, что ее инструментарий желательно расширить набором групповых операций. Примером такой операции может служить создание совокупности проектов для определенной группы студентов. Исходными данными для нее должны быть список группы, файлы заданий и описание структуры типового проекта. Применение подобного средства экономит для преподавателя около 4-х часов работы на одну студенческую группу 15 - 16 человек.
В настоящее время это средство автоматизации находится в зачаточном состоянии, так как пока не вполне определились алгоритмы распределения заданий и варианты различных структур студенческих проектов.
Перспективы развития
Развитие системы может идти по трем направлениям. Во-первых, дальнейшее совершенствование средств автоматизации выдачи заданий и формирования различных отчетов для администрации кафедры. Это позволит значительно сократить временные затраты как в начале, так и в конце семестра.
Расширение WEB-интерфейса системы, который позволит как преподавателям, так и студентам иметь ограниченный удаленный доступ к базе данных системы. В настоящее время доступ к данным в системе ограничен сетью базового предприятия, что обеспечивает контроль входа и со стороны программного обеспечения, и организационно. Существует опасность потери контроля самостоятельности выполнения заданий.
Наиболее интересная и трудоемкая часть перспективных разработок заключается в создании автоматизированных средств контроля результатов студенческих работ. Это относится и к содержимому создаваемых студентами файлов и к конфигурации, образуемой совокупностью файлов результатов.
Для проектов разработки ВПО в среде Redmine имеются некоторые средства работы с файлами программных кодов, а вот для текстов требований, планов тестирования, результатов тестирования подходящих инструментов нет. Наиболее просто можно создать средства перекрестного анализа текстов с использованием дополнительной трассировочной информации (анкоров и ссылок) связывающей файлы программной документации между собой. Подобные трассировочные таблицы создаются во всех промышленных программных проектах и знакомство студентов с техникой их использования естественно ложится в программу подготовки разработчиков ВПО.
Заключение
Специфика обучения специалистов по разработке СУ потребовала внедрения новых методических решений. Такие методические решения вылились в разработку
сквозного учебно-исследовательского проекта, выполнение которого позволяет ознакомиться с промышленными приемами разработки и современными информационными средствами.
Среда информационной поддержки кафедры позволила объединить результаты работы разнородного коллектива преподавателей и студентов базовой кафедры, а также дала результаты для её дальнейшего совершенствования.
Литература
1. ГОСТ Р 51904-2002. Программное обеспечение встроенных систем. Общие требования к разработке и документированию. - М.: Госстандарт России, 2002.
2. КТ-178А. Квалификационные требования часть 178А. - Жуковский.: АОЗТ "ИСПАС". - 1997.
3. Порешин П.П., Попов Б.Н. Дискретная математика: множества, отношения, логика, автоматы. Учебное пособие/ - М.:МОКБ Марс». 2012. - 172 с.: ил.
4. Основы разработки программного обеспечения на примере языка Си: Учебник./С.В.Синицын, О.И.Хлытчиев.- 2-е изд., испр. -М.:Национальный Открытый Университет «ИНТУИТ», 2013.-220с.: ил.
5. Проектирование и испытание бортовых систем управления: Учебное пособие под редакцией А.С.Сырова — М.: Изд-во МАИ-ПРИНТ, 2011. -344 с.: ил.
6. Система управления разгонным блоком: Учебное пособие / Андреев В.П., Бонк Р.И., Бровкин А.Г. и др./ др. под редакцией А.С.Сырова — М.: Изд-во МАИ-ПРИНТ, 2010. -272 с.: ил.
7. Бортовые системы управления космическими аппаратами: Учебное пособие / Бровкин А.Г., Бурдыгов Б.Г., Гордийко С.В. И / др. под редакцией А.С.Сырова — М.: Изд-во МАИ-ПРИНТ, 2010. -304 с.: ил.
8. Redmine http://www.redmine.org (дата обращения: 12.03.15).
9. Subversion http://subversion.apache.org (дата обращения: 12.03.15).
10. Управление версиями в Subversion http://svnbook.red-bean.com/nightly/ru/index.html (дата обращения: 12.03.15).
11. Синицын С.В., Кузьмин С.А., Порешин П.П., Попов Б.Н. Среда конфигурационного управления учебным процессом на базовой кафедре. // Преподавание информационных тенхологий в Российской Федерации: материалы Тринадцатой открытой Всероссийской конф. Пермский государственный национальный исследовательский университет. - Пермь, 14-15 мая, 2015. С.135-137.
12. Попов Б.Н., Порешин П.П., Синицын С.В., Сыров А.С. Организационные и технологические приемы подготовки разработчиков бортовых систем управления космическими аппаратами// Международный электронный журнал «Образовательные технологии и общество (Educational Technology & Society)» -2014. - V.17. - №3. - С.667-680. URL:
http://ifets.ieee.org/russian/depository/v17_i3/pdf/20.pdf (дата обращения: 01.02.15).
13. codeblocks www.codeblocks.org (дата обращения: 02.03.13).
