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

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

• удовлетворить спрос на новых специалистов на рынке труда для конкретных компаний (в идеале сразу поставить человека за “станок”);
• сделать человека востребованным на рынке труда в длительной перспективе и с высоким уровнем мобильности (человек приспособлен к тому, чтобы менять свою роль/должность, используемые технологии и предметную область, интересует большое количество работодателей);
• развлечь/занять студента в течение обучения, помочь обзавестись знакомствами;
• развлечь преподавателя и предоставить ему возможности для саморазвития и развития собственных идей/проектов;
• предоставить академии и индустрии новых предпринимателей, учёных и преподавателей;

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

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

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

Учебная программа должна включать в себя:

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

Примечания:

• Нет идеального специалиста, он всегда продукт компромисса (специализация).
• Есть обратная связь, так как выпускники рано или поздно начинают определять рынок.
• Область невероятно разнообразна и изменчива, отсутствуют какие-либо индустриальные стандарты, нет устоявшихся методов, подходов, критериев оценки, всё всегда по месту. В подавляющем большинстве случаев это означает, что выпускнику придётся учиться технологическому стеку и хорошим привычкам принятым на конкретном рабочем месте, образование может лишь подготовить его к этому.
• Информатика и вычислительная техника – инструментальные дисциплины, а значит знания прикладных областей будут лежать за пределами учебной программы. В подавляющем большинстве случаев это означает, что выпускнику придётся учиться прикладной специфике уже на месте работы.
• Инструменты радуют и удивляют только тех, кто в них разбирается. В других областях есть прыгающие роботы, красивые визуализации больших данных и т.п., а у нас это текст “AAAAAABBBBBAAAA” демонстрирующий смену процессов (Линус Торвальдс, Ради удовольствия: Рассказ нечаянного революционера).

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

1. инструмент для определения и управления ТЗ (характеристиками нашего будущего выпускника);
2. инструмент для формирования, управления и документирования методологий (учебных планов).

Инструмент для определения и управления целью учебного процесса

Начнём с первой задачи, что мы хотим получить в результате учебного процесса? В соответствии с системным подходом, system-of-interest определяется с точки зрения её функционального места и операционного окружения. Другими словами – будущее место работы студента в некоторой организационной структуре, где он должен поддерживать процесс (performing process), решать определенный круг технических, организационных и социальных задач, причём большая часть из них не может быть артикулирована (см. практическая информация и неравномерность распределения информации в австрийской экономической школе).

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

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

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

Одним из актуальных стандартов в области работы с методологиями разработки компьютерных систем (software intensive system) является стандарт Essence, разработанный для их описания, разработки и сравнения ².

Предлагаемый стандартом язык ³ для описания методологий включает в себя следующие элементы:

• Альфы – аспекты, точки зрения на систему, сильно взаимосвязаны между собой, но при этом рассматривающие разные вопросы и требующие разных компетенций. Для программной системы определены семь альф: opportunity, stakeholder, requirement, software system, work, team, way of work.
• Состояния альф – оценка уровня готовности / завершённости аспекта системы (к примеру, для stakeholder это Recognized, Represented, Involved, In Agreement, Satisfies for Deploy, Satisfied in Use).
• Место для активности и активности – непосредственные работы над системой.
• Компетенции – то, что позволяет реализовать требуемые активности (инструментальные средства являются продолжением компетенций, а не самостоятельным элементом).

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

• шаблоны синхронизации прогресса по альфам (водопад – сперва требования, потом код; XP – сперва код, а на требования вообще забьём);
• шаблоны составных активностей и выбора активностей;
• шаблоны организационных структур и ролей в команде.

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

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

Но у него есть и недостатки, он будет заострять проблемы и противоречия такие как специализация/универсальность или прикладник/специалист по ВТ. К примеру, зачем бизнес программисту лямбда исчисление, архитектура процессоров, OSI модель, верилоги и математика, если не для удовлетворения честолюбия?

Отсюда можно поставить следующие задачи:

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

Пока, в этой части, остановимся.

Инструмент для формирования, управления и документирования учебных планов

Если решены описанные выше задачи, то мы можем применить язык Essence для описания учебной программы (методика ситуативной инженерии методов) и учебного плана (индивидуальной траектории):

• Объектом, рассматриваемым в рамках методики является учащийся.
• Альфой – компетенция/дисциплина в широком смысле/вопрос/какое-то близкое понятие.
• Состояние альфы – уровень владения вопросом, к примеру альфа организации процессора: архитектура фон Неймана -> предоставляемые программисту механизмы -> оптимизации (память, конвейер…) -> микропрограммирование -> проектирование pipeline…
• Активность – набор учебных мероприятий, направленных на освоение вопроса. К примеру: курс, лекция, лабораторная работа, курсовой проект.
• Компетенция – в данном случае относится к преподавательскому составу, а не к учащемуся, так как процесс рассматривается с точки зрения реализации учебной программы.

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

Визуально это будет выглядеть примерно следующим образом (на схеме представление водопадной модели разработки):

Где у разработчика учебного плана (методики) есть возможность:

• в заданных пределах сортировать относительно друг друга уровни владения вопросами (стадии альф), и тем самым формировать последовательность курсов/мероприятий;
• определять нижнюю границу для выпускника (состояние каждой альфы, на котором студент в должной мере овладел вопросом).

Причём такой подход позволяет динамически адаптировать учебный план, делать его индивидуальным. Главное, что бы достигнутый профиль получился осмысленным (не нарушались инварианты заложенные на уровне учебного плана).

---

1. См. отношение архитектуры и архитектурного описания по ISO/IEC/IEEE 42010 Systems and software engineering – Architecture description. 2011. ↩

2. Ivar Jacobson, Discover the Essence of Software Engineering. CSI Communications, July 2011, http://semat.org/documents/20181/27952/Technical_Trends_3.pdf/f12257fc-81e9-4a25-8fef-c2076ebce105 ↩

3. Essence – Kernel and Language for Software Engineering Methods. Foundation for the Agile Creation and Enactment of Software Engineering Methods (FACESEM) RFP, 2012. ↩

4. Возможно, имеет смысл отказать от жёсткой привязки курсов к тому или иному семестру. ↩