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

При подготовке разработчиков встроенного программного обеспечения в соответствии с ГОСТ Р 51904-2002 приходится обращать значительное внимание не только на приемы написания и тестирования программного кода [1,2], но и на такие аспекты, как соблюдение четкого временного графика проекта, владение средствами конфигурационного управления (configurationcontrol) (КУ) и процедурами управления изменениями (changecontrol).

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

 На кафедре «Бортовая автоматика беспилотных космических и атмосферных аппаратов» МАИ (НИУ) с 2014 года начал внедряться комплекс инструментальных и методических средств, стимулирующих студентов к освоению промышленных приемов  разработки встроенного программного обеспечения и выработке у них привычки строгого соблюдения сроков при выполнении групповых проектов.

Иллюстрацией данного подхода может служить выполнение заданий учебно-исследовательской работы студента (УИРС) – дисциплины охватывающей 2 – 5 курсы подготовки. Как уже говорилось [3], студенту предлагается последовательно выполнить различные этапы создания упрощенной системы управления, используя материалы (проектные документы) созданные другими участниками разработки и, в свою очередь, подготовить материалы  для следующих этапов и исполнителей. При этом единой информационной средой, обеспечивающей целостность проектной документации, является Redmine совместно Subversion.

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

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

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

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