CC BY
39
Полученные в работе результаты являются основой для построения регрессионных моделей программно-аппаратных платформ, отличающихся от рассмотренной в данной статье.
Литература
1. Таненбаум Э., ван Стен М. Распределенные системы. Принципы и парадигмы. -СПб: Питер, 2003. - 877 с.
2. Кельтон В., Лоу А. Имитационное моделирование. - 3-е изд. - СПб: Питер; Киев: Издательская группа БИУ, 2004. - 847 с.
3. Трусова П.В. Введение в математическое моделирование: Учеб. пособие. - М.: Логос, 2005. - 440 с.
4. Иглин С.П. Математические расчеты на базе МаЙаЬ. - СПб: Издательство «БНУ-Санкт-Петербург», 2005. - 640 с.
5. Максимова Ю.Д. Вероятностные разделы математики. - СПб: «Иван Федоров», 2001. - 592 с.
Скшидлевский Антон Алексеевич
Лямин Андрей Владимирович
- Санкт-Петербургский государственный университет информационных технологий, механики и оптики, аспирант, anton@cde.ifmo.ru
- Санкт-Петербургский государственный университет информационных технологий, механики и оптики, кандидат технических наук, доцент, lyamin@cde.ifmo.ru
УДК 004.02; 004.58
КООРДИНАЦИЯ УПРАВЛЯЮЩИХ ВОЗДЕЙСТВИЙ ПРИ ФОРМИРОВАНИИ ПРОФЕССИОНАЛЬНОЙ КОМПЕТЕНТНОСТИ В ПРОГРАММИРОВАНИИ Н.Ф. Гусарова, Г.О. Котелкова, В.А. Синицын, Ф.А. Смирнов
Рассматривается преодоление системной неопределенности среды как компоненты профессиональной компетентности программистов (ПКП). Представлены математическая модель и демонстрационная реализация системы поддержки формирования ПКП с использованием визуализации результатов программирования. Разработка сочетает погружение в реальную среду, характерное для метода проектов, с возможностью двухуровневого контроля процесса получения обучающимися профессиональных навыков. Ключевые слова: системная неопределенность технологической среды программирования, профессиональная компетентность программистов (ПКП), координация управляющих воздействий.
Введение
Качество подготовки программистов и, соответственно, их конкурентоспособность на рынке труда в значительной и все возрастающей степени определяются не столько академическими знаниями, сколько умением решать профессиональные задачи. Как показывает опыт общения со студентами, они в большей степени мотивированы именно на приобретение навыков реального программирования при решении прикладных задач. В то же время структура учебного процесса в техническом вузе ориентирована, в первую очередь, на передачу студентам академических знаний.
Актуальность и комплексный характер проблемы инспирируют множество подходов к ее решению. Так, исследования, проводимые в течение нескольких лет в СПбГУ ИТМО [1, 2], позволили раскрыть социально-психологические (в том числе де-
мографические и мотивационные) и организационно-методические аспекты проблематики. В настоящей статье обращается внимание на те аспекты обозначенной проблемы, которые связаны с системными характеристиками технологической среды программирования. Акцентируется роль опыта преодоления системной неопределенности среды как компонента ПКП. Предлагаются математическая модель и технологическая реализация поддержки формирования ПКП с использованием визуализации результатов программирования.
Системная сложность технологической среды программирования и профессиональная компетентность как средство ее парирования
Технологическая среда для решения прикладных задач программирования (ТСП) формируется, как правило, совокупностью проблемно-ориентированных программных продуктов (ПП) и доступна актору (программисту или пользователю) через пользовательский интерфейс. На формальном уровне [3, 4] интерфейс 1111 определяется как тройка
Ш = (X, У, 5), (1)
где X - множество стимулов, У - множество реакций, 5 - множество состояний 1111, а взаимодействие актора с ПП с интерфейсом (X, У, V) - как интерфейсная операция (ИО)
1А = (я, х,у, я') е 5 х Xх У х 5, (2)
где я - пресостояние, х - стимул, у - реакция, я' - постсостояние. Согласно (2), понятие взаимодействия интерпретируется следующим образом: в пресостоянии ПП я вызывается ИО с некоторыми значениями параметров х, на что ПП возвращает выходные параметры у и переходит в постсостояние я'. Набор ИО, определяющих функциональность ПП, описывается моделью требований - абстрактным автоматом
МЯ= (5, X, У, Е), (3)
где Е ^ 5 х XX У х 5 - множество переходов. Конкретизация (3) до уровня отдельных параметров производится через понятие спецификации. Сигнатурой ИО I называется тройка
= (1щ, Ои1/, 5Ц), (4)
где 1пг = {хг- | I = 1, ..., т(1); т(!) > 0} - упорядоченный набор входных параметров операции, Ои^ = {у | / = 1, ..., ои1;(1); ои1;(1) > 0} - упорядоченный набор выходных параметров операции, 5Ь = {яг- | I = 1, ., б1(1); б1(1) > 0} - набор переменных состояния, к которым обращается операция. Спецификацией Брес^ ИО I с сигнатурой называется пара предикатов
Брес/ = (рге1, роБ^), (5)
где рге1 - предусловие (предикат на множестве 5/ х 51,), роБ^ - постусловие (предикат на множестве 51 х XI х У1 х 5/), 1п = {хг- | I = 1, ..., т(1). Спецификацией ПП называется непустой набор спецификаций его ИО
БресПП = {Брес/ | I = 1, ., к; к > 0 }. (6)
Решая технологическую задачу Р8, актор задает последовательность интерфейсных операций {1А}я, т.е. формирует управление, потенциально приводящее к требуемому выходному набору переменных Ои^. Если это управление не противоречит ограничениям (3), то ПП его выполняет.
Однако в реальном программировании модель (1)-(6) оказывается, как правило, излишне упрощенной, что связано с принципиально неустранимой системной сложностью ТСП [5]. В 1975 г. Ф. Брукс выделил такие факторы системной сложности: (Ф.1) мощность множества состояний. Число возможных состояний ПП на порядки величин превышает число состояний компьютеров, которое само по себе очень велико, причем в большинстве случаев элементы ПП взаимодействуют между собой нелинейным образом, и сложность целого растет значительно быстрее, чем линейно;
(Ф.2) искусственное происхождение. В отличие от природных объектов, которые подчиняются фундаментальным инвариантам и законам, структура 1111 определяется «культурной матрицей» [5] их авторов, т.е. во многом произвольна и, соответственно, неполностью предсказуема для пользователей;
(Ф.3) сложность визуального представления полной структуры 1111, что затрудняет процесс проектирования, общение между разработчиками и работу пользователей в среде 11 .
С развитием ИТ этот список расширился: (Ф.4) компьютеры, являющиеся физической средой ТСП, включаются в локальные и/или глобальные сети и, соответственно, испытывают непрогнозируемые воздействия извне; (Ф.5) помимо процесса, регулируемого актором, в компьютере исполняются различные резидентные программы, не контролируемые актором;
(Ф.6) при создании 1111 широко используются внешние библиотеки и принцип инкапсуляции, а многие 11 являются проприетарными; в результате множество состояний StI доступно актору лишь частично.
В результате действия этих факторов множество состояний 11 S (1) становится не полностью наблюдаемым (не полностью измеримым)1 для актора, и априорно выделить в нем полностью наблюдаемую часть Sti, которая необходима для строгого соблюдения формализмов (4)-(6), не представляется возможным. Различные аспекты организации целенаправленной деятельности в условиях неполной наблюдаемости технологической среды изучаются в рамках когнитивной психологии, искусственного интеллекта, системного анализа и смежных дисциплин (см., например, [9-12]). 1римени-тельно к проблематике статьи выделим следующие результаты:
(Р.1) целенаправленные действия в таких условиях возможны при сочетании формальных моделей, выраженных в явных знаниях2, и эвристических стратегий (аналогии, ассоциации, предположения и т.п.);
(Р.2) последние формируются естественным интеллектом на основе внутренней активности и предыдущего опыта и во многом являются имплицитными, т. е. не доступными саморефлексии.
Для обозначения соответствующих способностей человека в педагогике [2, 13-15] используется ряд смежных понятий, в том числе умения, профессионализм, компетентность. В содержательном плане они характеризуют способности человека эффективно решать разнообразные задачи, в том числе нестандартные, в реальных ситуациях во всей области профессиональной ответственности.
Для формирования таких способностей оказываются в той или иной мере эффективными различные подходы - тренинги, наставничество, конструктивистские технологии, проектное обучение [16-21] и т.д. Многие из них находят применение в ИТ-компаниях при вводе в выполняемые проекты новых исполнителей. Так, компания Motorola/Bangalore проводит для всех вновь принятых на работу программистов профессиональный тренинг в объеме 42 рабочих дня, что считается особенно важным для погружения в сложный проект [22]. В компании Microsoft вновь принятые программисты приступают к реальной работе в проекте в день приема, однако к каждому из них прикрепляется персональный ментор, который в течение 2-10 месяцев читает все коды,
1 Несмотря на содержательную близость, понятие наблюдаемость (см., например, [6]) в разных предметных областях имеет различные формальные определения. 1рименительно к программированию, согласно [7], оно эквивалентно понятию измеримость [8]: под измеримым понимается [8] такое состояние, которое экспериментатор может определить для каждого момента времени либо непосредственно, либо через известные значения входного и выходного сигналов, не зная начального состояния.
2
Явные знания - накопленный опыт, который может быть выделен и представлен в форме методик, инструкций, руководств, рекомендаций к действию. Явные знания являются сформулированными, зафиксированными [13].
написанные новичком, дает профессиональные советы и т.д. [22]. Однако такие подходы ориентированы не на повышение исходного уровня ПКП, а на адаптацию новичка к принятым в конкретном проекте методам программирования, стилю кода и т.п. Кроме того, несмотря на свою потенциально высокую эффективность, такие подходы требуют больших ресурсов (в частности, большого штата высококвалифицированных менторов), а также предполагают возможность отложенного принятия решения о найме. В более мелких же компаниях процедуры ввода в проект новых исполнителей во многом формируются спонтанно, на уровне самоорганизации и, как правило, не имеют организационной и методической поддержки.
Таким образом, для формирования ПКП необходимо получение не только академических знаний и опыта работы в команде, но и профессиональных навыков3, а также опыта преодоления системной неопределенности ТСП, причем достижение этих целей должно быть верифицируемым. Сформулируем требования к системе поддержки ПКП (далее - системе) в свете этих задач.
(Т.1) Индивидуальный вклад обучающегося в работу над заданием должен отслеживаться. Как показывает наша практика организации проектной работы при обучении в области ИТ, нередки ситуации, когда при коллективной работе основной объем выполняют 1-2 талантливых студента, а остальные члены группы пользуются их результатами; при этом переломить ситуацию мотивационными и/или организационными мерами не удается.
(Т.2) Необходимо обеспечить, по возможности, объективный контроль уровня и содержания получаемых обучающимися профессиональных навыков.
(Т.3) Последовательность заданий должна поддерживать постепенное нарастание алгоритмической сложности и, одновременно, уровня неопределенности ТСП. (Т.4) В каждом задании обучающийся должен видеть пользу от применения конечного результата в своей реальной практике (на уровне повторно используемого кода). (Т.5) Формирование базовых уровней профессиональной компетентности должно происходить на стороне обучающей организации, а не ИТ-компании. В то же время, учитывая специфику требований к программисту, подготовку следует строить на основе максимального соответствия промышленному процессу. В частности, целесообразно использовать при реализации заданий некоторые принципы методологии экстремального программирования [23], такие как «юнит-тестирование», «рефракторинг» и «небольшие релизы». В целом же система должна быть достаточно легко адаптируемой к различным методологиям разработки.
(Т.6) Учитывая недостаток преподавателей, способных креативно инспектировать код в условиях неполной наблюдаемости ТСП, следует максимально разгрузить преподавателя от этой задачи, используя автоматическое тестирование кода, а также интегральную (в частности, визуальную) проверку результата выполнения задания.
Моделирование системы поддержки формирования ПКП
Как показывает наша практика, удачным подходом к построению системы может служить выполнение обучающимся (актором) набора заданий, состоящих в написании и запуске расширений к существующим прикладным 1111. В частности, эффективную поддержку формирования ПКП можно организовать в процессе освоения языка программирования JavaScript [24], который обладает развитой объектной моделью и является мощным средством разработки информационных систем, предполагающих работу
3 Навыки - двигательные, сенсорные и умственные действия, доведенные до автоматизма путем многократного повторения, упражнений. Применительно к умственной деятельности выделяют интеллектуальные навыки общения (коммуникативные навыки), навыки письма, навыки презентации, управленческие навыки и т.п. [15]
через html-интерфейс, а также важнейшей частью широко используемой технологии AJAX. С точки зрения реализации сформулированных выше требований JavaScript обладает рядом преимуществ:
- полная интеграция с браузером (что требует от обучающегося учета системных неопределенностей конкретного браузера);
- поддержка большинства браузеров (в отличие, например, от технологий ActiveX и VBScript);
- сравнительно низкий «порог вхождения» обучающегося.
Таким образом, выбор JavaScript позволяет удовлетворить требование Т.4, а использование платформы Windows с весьма сложной структурой потока визуализации
[25] предоставляет широкие возможности для удовлетворения требования Т.3.
Диаграмма информационных потоков в системе представлена на рис. 1. Набор заданий в системе ранжирован по уровням сложности в соответствии с требованием Т.3 (на рис. 1 n - номер уровня). После регистрации в системе обучающийся получает задание, соответствующее ранее пройденным уровням; в частности, при n=0 он проходит входное тестирование. Получив задание, обучающийся пишет код и запускает его на исполнение в системе. Для самоконтроля и проверки работоспособности кода реализована визуальная проверка результата исполнения кода, а также автоматическое тестирование кода (тем самым выполняются требования Т.2 и Т.5). Если обе проверки пройдены, обучающийся получает задание следующего уровня и повторяет цикл «кодирование - визуальная самопроверка - автоматическое тестирование» требуемое количество раз. На старших уровнях сложности в цикл включается проверка задания преподавателем, который указывает в комментариях свои пожелания - например, внести изменения в код, провести дополнительный рефакторинг или отладку (тем самым удовлетворяется требование Т.6).
В качестве методологической основы поддержки формирования ПКП используется концепция координации в иерархических многоуровневых системах [26], развиваемая применительно к сфере ИТ в работах [27, 28], в соответствии с которой построена модель управления в системе (рис. 2). Обучающийся Сг-, получив задание Pn, пишет код, т.е. формирует управление mзад, потенциально приводящее к требуемому результату y, и запускает его в ТСП, т.е. производит целенаправленное изменение изад потока параметров ТСП u. Очевидно, что задание Pn может быть различными способами декомпозировано на отдельные подзадачи (рис. 3). Подзадачи (а также выполненное задание с ТСП в целом) взаимодействуют посредством ИО (см. модель (1)-(6)) и/или их комбинаций, которые в [26] обозначаются термином связующие сигналы. В соответствии с
[26], качество выполнения задания описывается оценочной функцией
G: ХхУ^ КГлоб, (7)
причем в общем случае в оценочном объекте Кглоб присутствуют компоненты, допускающие полностью формальное описание (VMetr) и слабую формализацию (VNMet):
Утоб=Уме^УнМе, (8)
Соответственно, результаты выполнения задания доступны акторам системы посредством сигналов обратной связи zMetrUT, zMetrSt, zNMetr, причем функциональная связь между zNMetr и VNMet отсутствует. Компоненты VMetr оцениваются автоматически (например, посредством юнит-тестирования в блоке UnitTest). К компонентам V^Met относятся, в частности, ряд показателей поддерживаемого обучающимся стиля программирования (объем кода, использованный для решения задачи; наличие повторяющихся фрагментов кода, не выделенных в функции; количество операторов ветвления и т.д.), а также интегральные (общекультурные - см. фактор Ф.2) показатели реализованного расширения. Оценка неформализуемых показателей стиля программирования производится преподавателем (блок ChStyle), а интегральная оценка качества решения выполняется акторами системы за счет визуализации части потока ивиз (блок Viz).
Пользователь зарегистриро-
код, не прошедшии тестирование или проверку
Рис. 1. йРй-диаграмма информационных потоков в системе
Рис. 2. Модель управления в системе
^2 fп3 fп4
Utest 1 1 Utest3
эРп1
1Лев1 2
эРп2
sFfп3
эРп4
sFп5
1. Декомпозиция задания по умолчанию на методы Гп1() - Гп4()
2. Декомпозиция формализуемого компонента оценки посредством ипП-тестов
3. Самостоятельная декомпозиция задания обучающимся
Рис. 3. Примеры декомпозиции выполняемого задания
В силу неполной наблюдаемости множества состояний ТСП, а также наличия слабо формализуемых показателей качества решения УиМ^ задание Рп, очевидно, может ставиться только как поиск удовлетворительных решений: для допустимого подмножества управляющих воздействий М^с М найти управляющее воздействие М е М такое, что
£ (м ю)еКгаоб (9)
для всех возмущений ш е О, при этом допустимое подмножество управляющих воздействий М ^ с М задается преподавателем через допустимые диапазоны связующих входов
и параметров локальных функций качества х в[ . Другими словами, преподаватель Со воздействует на работу обучающегося С,, параметризуя либо задаваемую целевую функцию 0„ решаемой задачи, либо множество связующих входов для задания Рп и/или его подзадач, либо то и другое вместе, с помощью координирующих сигналов
у = (а, р); Г = АхВ, (10)
где а - вектор допустимых значений связующих входов задания, а с А, а в - вектор параметров, конкретизирующих компоненты целевой функции Gn, в с В.
Содержательный анализ показывает, что УМе^ имеет не более чем кодовую метрику, т.е. определяется над конечным полем, в то время как по крайней мере некоторые компоненты Уше& должны определяться над бесконечным полем [29]. В связи с этим поиск решения, удовлетворяющего условию (10), не может быть организован в итеративной форме, и его необходимо вести в лексикографическом порядке, а именно: вначале найти М€1 е М такое, что
£1(М1,ш) еУМе,г, (11)
а затем найти М2 е М такое, что
£ 2(М1,Ш) е (( ^ УмМе* ) . (12)
Таким образом, в рамках выполнения (9) обучающийся, выполняя задание в ограничениях (10), самостоятельно и во многом имплицитно (см. результат Р.2) строит матрицу технологических связей (связующих сигналов и,) между заданием (совокупностью подзадач) и ТСП. При этом сочетание неполной наблюдаемости ТСП и поисковой активности (см. Р.1) актора приводит к следующим ограничениям.
(О.1) При запуске написанного расширения в реальном ТСП происходит проверка равенства сечений полного потока ИО,
{и.}=(и+}, (13)
в форме компарирования на программно-аппаратном уровне (здесь {и.} и {и+} - поток параметров ТСП перед запуском и после него соответственно).
(О.2) Результаты проверки (13) могут быть интерпретированы при визуализации, т.е.
Кй }скш }. (14) (О.3) Результирующий вектор задания у должен соответствовать требованиям, задаваемым метризуемым компонентом оценочного объекта УМеоднако их трансляция на поток параметров ТСП
Удоп^ иГп (15) (т. е. задание вектора а) возможна только на уровне
<П зМ, (16)
где } - наблюдаемый (измеримый) по выходу подпоток полного потока и. Другими словами, требования к потоку параметров, реализуемых при выполнении задания Рп, как правило, могут быть заданы не в виде полного шаблона, а только в виде набора ограничений. При ограничениях О.1-О.3 можно доказать следующие утверждения. У.1. Если в системе управление организовано в соответствии с рис. 2 и выполняются ограничения О.1-О.3, то для удовлетворения требований к качеству ее работы в фор-
ме (11) необходимо, чтобы при запуске расширения допустимый набор подмножества
параметров uy принадлежал текущему сечению полного потока параметров
М:
К
•м.
-Г-,. (17)
У.2. Если для системы справедливо утверждение У.1, а модификации функций качества, задаваемые вектором в, монотонно связаны с соответствующими сигналами обратной связи (г), то возможно удовлетворение требований к качеству работы системы в форме (12).
Очевидно, что для поддержки сходимости ТСП в потоке ИО (и) не должны содержаться комбинации, противоречащие требованиям (3). Нарушение этих требований даже в части потока ИО, не входящей в (ивиз), проявляется в ошибках переполнения и, соответственно, нарушениях штатного поведения ТСП. Формирование индивидуального банка таких ситуаций и сценариев поведения в них, как показывает практика, является не менее важным аспектом ПКП актора, чем опыт его работы в штатных ситуациях.
Пример реализации системы поддержки формирования ПКП
Пример реализации разработанной системы представлен на рис. 4-5. Обучающиеся имеют доступ к заданиям своего уровня, рейтингу, учебно-справочной литературе и форуму. Каждое задание состоит из учебного материала, непосредственно задания, набора тестов, рекомендаций по тестированию и рекомендаций по инсталяции расширения в основную программу. Задания ранжируются по уровню сложности в соответствии с требованиями утверждения У.2. Некоторые примеры заданий младших уровней доступны для загрузки [30].
На странице задания (рис. 4) отображаются список заданий и результаты решений обучающегося, которые можно просмотреть, исправить, сохранить, протестировать и послать преподавателю на проверку. Напротив задания отображается статус проверки (принято, в очереди на проверку, не принято) и комментарий преподавателя. На странице решения (рис. 5) для удобства обучающихся встроен редактор кода Editarea 0.7.2.3 с номерами строк и подсветкой кода, а также консоль JavaScript для вывода промежуточных результатов и лога ошибок.
доп
Рис. 4. Интерфейс обучающегося
В настоящее время разрабатывается пакет заданий в форме создания востребованных в реальной практике расширений к open-source веб-браузеру Mozilla Fire Fox, что позволят сформировать постепенный сдвиг локализации сложности и неопределенности заданий - от выполнения задачи в ТСП к парированию неопределенности ТСП.
Рис. 5. Визуальный редактор кода
Заключение
В статье акцентируется роль опыта преодоления системной неопределенности среды как компонента профессиональной компетентности программистов (ПКП). Предлагаются математическая модель и технологическая реализация системы поддержки формирования ПКП с использованием визуализации результатов программирования. Предложенный подход сочетает в себе погружение в реальную среду, характерное для метода проектов, с возможностью объективного контроля и самоконтроля уровня и содержания получаемых обучающимся профессиональных навыков, а также разгружает преподавателя от рутинных проверок кода. В качестве перспектив развития концепции планируется дальнейшая разработка программных средств (с особым вниманием к многопользовательскому режиму) и создание учебно-методического обеспечения для внедрения системы в образовательный процесс.
Литература
1. Девятая Всероссийская олимпиада школьников по информатике и программированию / Под ред. В.Н. Васильева, В.Г. Парфенова, А.С. Станкевича. - СПб: СПбГУ ИТМО, 2008. - 244 с.
2. Лисицына Л.С. Концепция и методология управления разработкой образовательного процесса по подготовке компетентных выпускников средствами сетевой информационной системы: Автореферат дис. ... докт. техн. наук. - СПб: СПбГУ ИТМО, 2008.
3. Кулямин В.В., Петренко А.К., Косачев А.С., Бурдонов И.Б. Подход UniTesK к разработке тестов // Программирование. - 2003. - Т. 29. - № 6. - С. 25-43.
4. Хорошилов А.В. Спецификация и тестирование компонентов с асинхронным интерфейсом: Автореферат дис. ... канд. физ.-мат. наук. - М.: ИСП РАН, 2006.
5. Брукс Ф. Мифический человекомесяц или Как создаются программные системы. -М.: Символ-Плюс, 2006. - 304 с.
6. Kalman R.E. On the general theory of control systems // Proc. First Intern. Congr. Automatic Control. - Moscow, 1960. - Vol. 1. - London: Butter Worth & Co.
7. Шалыто А. А. SWITCH-технология. Алгоритмизация и программирование задач логического управления. - СПб: Наука, 1998. - 628 с.
8. Заде Л., Дезоер Ч. Теория линейных систем: Метод пространства состояний. - М.: Наука, 1970.
9. Гаврилова Т.А., Хорошевский В.Ф. Базы знаний интеллектуальных систем. - СПб: Питер, 2001. - 384 с.
10. Поспелов Д. А. Ситуационное управление: теория и практика. - М.: Наука, 1986. - 288 с.
11. Люгер Дж.Ф. Искусственный интеллект: стратегии и методы решения сложных проблем. 4-е издание: Пер. с англ. - М.: Издательский дом «Вильямс», 2003.
12. Джонс Дж.К. Методы проектирования: Пер. с англ. 2-е изд. - М.: Мир, 1986. - 326 с.
13. ГОСТ Р ИСО 10015, Государственный основной стандарт: Менеджмент организации. Руководящие указания по обучению, разработанный на основе международного стандарта: ISO 10015:1999 Quality management - Guidelines for training (IDT).
14. Дружилов С.А. Психология профессионализма субъекта труда: интегративный подход // Ежегодник Российского психологического общества: Материалы 3-го Всероссийского съезда психологов. - СПб: Изд-во СПбГУ, 2003. - Том 3. - С.153-157.
15. Пидкасистый П.И., Фридман Л.М., Гарунов М.Г. Психолого-дидактический справочник преподавателя высшей школы. - М.: Педагогическое общество России, 1999.
16. Пахальян В.Э. Групповой психологический тренинг. - СПб: Питер, 2006.
17. Коммуникативно-ориентированные образовательные среды. Психология проектирования / Под ред. В.В. Рубцова. М., 1996. - Режим доступа: http://ido.rudn.ru/psychology/psychology_of_marketing/ch11_1.html, своб.
18. Пакет Moodle2.0. - Режим доступа: docs.moodle.org, своб.
19. Kilpatrick W. H. The project method. - N.Y., Columbia University Teachers College, 1918.
20. Новые педагогические и информационные технологии в системе образования / Под ред. Е.С.Полат - М., 2000.
21. Лаврентьев М.М., Алсынбаева Л.Г., Васючкова Т.С. Метод проектов в системе непрерывного обучения информатике. Опыт НГУ.
22. Иордан Э. Человеческий фактор в разработке программного обеспечения: привлечение, мотивация и удержание ключевых сотрудников / Материалы семинара. -Режим доступа: http://www.yourdon.com, своб.
23. Бек К., Фаулер М. Экстремальное программирование. - СПб: Питер, 2003.
24. Дмитриева М.В. JavaScript. Занятия 1-7 // Компьютерные инструменты в образовании. - 2002. - № 1-5; 2003. - № 1, 2.
25. Таненбаум Э. Операционные системы. - СПб: Питер, 2005. - 1038 с.
26. Месарович М. , Мако Д., Такахара И. Теория иерархических многоуровневых систем. - М.: Мир, 1973. - 344 с.
27. Гусарова Н.Ф., Маятин А.В., Смирнов Ф.А. Обратные задачи в компьютеризированных технологических средах // Научно-технический вестник СПбГУ ИТМО. -2007. - Вып. 44. - С. 284-292.
28. Гусарова Н.Ф. Координация в технологичеких процессах со слабо формализуемыми критериями. - СПб: СПбГУ ИТМО, 2001. - 271 с.
29. Дударенко Н.А., Слита О.В., Ушаков А.В. Математические основы современной теории управления: аппарат метода пространства состояний: Учебное пособие / Под ред. А.В. Ушакова. - СПб: СПбГУ ИТМО, 2008. - 310 с.
30. Тестовое учебное задание. - Режим доступа: http://212.116.110.171:8081/share/devln/training.prj/files/task.smpl.zip, своб.
Гусарова Наталия Федоровна
Котелкова Галина Олеговна
Синицын Владислав Андреевич
Смирнов Филипп Александрович
Санкт-Петербургский государственный университет информационных технологий, механики и оптики, кандидат технических наук, доцент, щ1-fed@list.ru
Санкт-Петербургский государственный университет информационных технологий, механики и оптики, аспирант, glaya@inbox.ru Санкт-Петербургский государственный университет информационных технологий, механики и оптики, аспирант, shinisaru@gmail.com Санкт-Петербургский государственный университет информационных технологий, механики и оптики, аспирант, smirnfil@gmail.com
