Ирина Лавринова говорит: «Я иногда прошу детей закрыть глаза, отвернуться от монитора или выйти из-за компьютера, и выполнить упражнение под моим контролем. Я говорю, что именно делать, а они выполняют упражнения».
С проблемами дистанционного образования мы разобрались.
Большинству преподавателей эта система не нравится, затрудняет весь процесс обучения, но что же думают студенты БНТУ. Был проведен опрос, в котором поучаствовали тридцать обучающихся, вопросы приведены на рисунке 1.
Рис. 1 – Результаты опроса студентов БНТУ
Как показал опрос, не все студенты обучались на дистанционном обучении. Это было связано, что в нашей стране не был введен обя- зательный переход на онлайн-режим. Но по показателям можно увидеть, что многие хотели бы перейти на эту систему. Конечно, это связанно с комфортным обучением. Например, отсутствует большая степень контроля, не требуется перемещение в учебные заведения, что дает экономию времени, кроме этого можно учиться в удобном положении.
120
Ответ на вопрос о дистанционном образовании остается весьма неоднозначным. Для каждой стороны есть свои плюсы и минусы.
Данная система имеет множество нюансов, исправление которых требует больших усилий и времени. Для полного внедрения онлайн- режима понадобится существенный переворот во всем учебном процессе, поэтому переход не может осуществиться.
Список используемых источников
1. Ирина Лавринова, 7 трудностей онлайн-обучения. И как учи- телю с ними справиться [Электронный ресурс]. – Режим доступа:
pedsovet.org. – Дата доступа: 30.10.2022.
УДК 001.8
Гибкая методология разработки программного обеспечения Григоренко А. А., студент
Андреев М. А., студент
Белорусский национальный технический университет Минск, Республика Беларусь
Научный руководитель: к.т.н. Евтухова Т. Е.
Аннотация:
В данной статье рассматриваются компоненты и методология разработки программного обеспечения.
Гибкая методология разработки – разбиение проектов на не- большие части работы, называемые пользовательскими историями.
В приоритетном порядке задачи решаются короткими двухнедель- ными циклами (итерациями).
Agile – это итеративная модель разработки, в которой программ- ное обеспечение создается постепенно с самого начала проекта, в отличие от каскадных моделей, когда код доставляется ближе к концу рабочего цикла разработки.
121 Основные принципы разработки Agile:
наиболее эффективным методом обмена информацией в коллективе является личная встреча;
производительность – включает в себя скорость и незавер- шенное производство. Первый подходит не для всех проектов, так как количество выполненных задач измеряется за одну итерацию, и они не равнозначны. Метрика незавершенного производства опре- деляет порог задач на разных стадиях: чем выше, тем хуже;
работающее программное обеспечение – лучший показатель прогресса, спонсоры, разработчики и пользователи должны иметь возможность поддерживать стабильный темп сколь угодно долго;
прогнозирование – это мера производительности: определи- те количество идеальных часов, доступных в следующем спринте. В результате вы сможете понять, сколько времени доступно для рабо- ты, эффективность выполнения задач и как спланировать количе- ство задач на отдельно взятый спринт;
работники постоянно размышляют о том, как повысить эф- фективность, и соответствующим образом корректирует рабочий процесс разработки программного продукта.
Существуют методологии, которые придерживаются ценностей и принципов, изложенных в Манифесте Agile, некоторые из кото- рых представляют собой следующие:
гибкое моделирование – модель концепций в котором нет конкретной структуры разработки программы, но есть несколько концепций и моделей разработки, комбинируя и достигается необ- ходимый результат. Всего таких 12 принципов;
Agile Unified Process (AUP) Упрощенная версия IBM Rational Unified Process (RUP), разработанная Скоттом Амблером, которая описывает простой и понятный (стандартный) подход к разработке программного обеспечения для бизнес-приложений;
Agile Data Method – генерация требований и проектных ре- шений с помощью различный команд. Как и AUP, это не цельный метод сам по себе, а лишь один из этапов;
DSDM подход в котором пользователь принимает постоян- ное непосредственное участие в разработке ПО;
основной унифицированный процесс;
122
функционально-ориентированная разработка (FDD) – это функционально-ориентированная разработка. Концепция системной функции или свойства, используемая в FDD, очень похожа на кон- цепцию вариантов использования, используемую в RUP, с тем важ- ным отличием, что существует дополнительное ограничение «каж- дая функция должна быть реализована не более чем за две недели»;
Get Real – это подход к разработке проекта. Это поможет подойти к разработке с другого ракурса, где у нас нет времени, больших ресурсов и того, что мы считаем нужным для проекта.
Этот подход хорошо работает для дизайнеров и программистов.
Ведь самый простой инструмент – это компьютер;
OpenUP – это метод который делит цикл проекта на четыре фазы: инициация, расширение, сборка и развертывание. Это позво- ляет контролировать ситуацию и вовремя принимать решения по проекту. Во время каждого из этапов клиент может принимать непосредственное участие в разработке и вносить коррективы. Фи- нальным результатом разработки будет являться итоговый продукт;
Scrum – это гибкая среда разработки программного обеспе- чения, которая считается методологией «по умолчанию». Для мно- гих это синоним Agile. Согласно статистике за 2017 год, предостав- ленной VersionOne, 56 % agile-компаний используют Scrum. Gentle разработка программного обеспечения использует подходы gentle производства программного продукта;
Xtreme Programming – экстремальное программирование.
Как и в случае с другими agile-методами, то же самое относится и к XP: чем короче итерации, тем лучше. Если обзор можно сделать за день, сделайте это. Но вряд ли пользователь захочет ежедневно об- новлять версию своей рабочей программы. Максимальный срок в XP – один месяц. Таким образом, средняя итерация может быть укорочена вдвое и занимает две недели или 14 дней.
Список использованных источников
1. Гибкая методология разработки [Электронный ресурс]. – Режим доступа: https://ru.wikipedia.org/wiki/Гибкая_методология_
разработки. – Дата доступа: 01.11.2022.
123 УДК 681.3.06
Алгоритмический язык Ершова и его назначение
Гурская Д. А., студент Василевская В. А., студент
Белорусский национальный технический университет Минск, Республика Беларусь
Научный руководитель: преподаватель Михасик Е. И.
Аннотация:
В данной статье рассматривается понятие алгоритмического языка Ершова и его назначение. Также в данной статье выделены области применения данного языка и его свойства.
Алгоритмический язык (он же, в ряде публикаций – Алгоритми- ческий язык Академика Ершова, а также Русский Алгоритмический Язык (РАЯ)) – язык программирования, используемый для записи и изучения алгоритмов. При изучении информатики в школах для изучения основ алгоритмизации применяется т. н. школьный алго- ритмический язык (учебный алгоритмический язык), использующий понятные школьнику слова на русском языке. В отличие от боль- шинства языков программирования, алгоритмический язык не при- вязан к архитектуре ЭВМ, не содержит деталей, связанных с устройством машины (персонального компьютера).
Алголо-подобный алгоритмический язык был введен в употреб- ление академиком Андреем Петровичем Ершовым в середине 80-х годов, в качестве основы для «безмашинного» курса информатики.
Язык использовался для записи алгоритмов в учебнике «Основы информатики и вычислительной техники» для 9–10 классов (изда- ние 1990 года было выпущено тиражом в 7 млн экземпляров).
Обладая определенной свободой записей, учебный алгоритмиче- ский язык позволяет, тем не менее, познакомиться со всеми основ- ными понятиями и методами алгоритмизации. Кроме того, он обла- дает целым рядом свойств, которые и объясняют, почему при выбо- ре дидактического средства для записи алгоритмов в курсе информатики именно этому языку было отдано предпочтение перед
124
широко распространенными в то время официальными языками программирования. Примером такого является Бейсик.
Свойства:
1. Русская (или национальная) лексика. Служебные слова языка пишутся на русском (или родном) языке и понятны школьнику.
2. Структурность. Учебный алгоритмический язык (в отличие, скажем от того же Бейсика, использующего построчную алгорит- мическую нотацию) построен на куда более современных идеях структурного программирования.
3. Независимость от ЭВМ. В алгоритмическом языке нет дета- лей, связанных с устройством машины, что позволят сосредоточить внимание на алгоритмической сути решаемых задач.
В записи алгоритма ключевые слова обычно подчеркивались ли- бо выделялись полужирным шрифтом. Для выделения логических блоков применялись отступы, а парные слова начала и конца блока соединялись вертикальной чертой.
С технической точки зрения алгоритмический язык является практически однозначным слепком с распространенных и близких друг другу алголоподобных структур и ключевых слов, используе- мых для полуформального описания алгоритмов в научных статьях и вузовских учебниках. Эта реальная общезначимость нотации под- черкивается тем, что алгоритмическому языку в учебнике не дается никакого специфического названия.
Алгоритмический язык является открытой системой, опираю- щейся на незаданный словарь простых команд и условий, образую- щих соответственно операционные и распознающие возможности исполнителя и составляющих вместе его систему команд.
Алгоритмический язык допускает без каких-либо ограничений рекурсивное исполнение алгоритмов. При этом при каждом вызове возникает новый экземпляр памяти алгоритма, образуемой его ар- гументами, результатами и промежуточными величинами.
В алгоритмическом языке нет команд ввода и вывода. Это не со- здает каких-либо проблем, пока источник аргументов, исполнитель и получатель результатов – одно и тоже лицо, и в то же время поз- воляет не вводить различия между главным и вспомогательными алгоритмами и, вообще, не застревать раньше времени на деталях передачи параметров в алгоритме.
125
В алгоритмическом языке нет понятия глобальных переменных.
Это сознательное ограничение, которое нельзя снимать мимоходом.
Глобальные переменные, по нашему мнению, – это принципиальное расширение класса функциональных (f(аргумент) → результат) ал- горитмов на так называемые алгоритмы работы во внешней обста- новке (задаваемой глобальной переменной). Нам представляется, что алгоритмы работы в обстановке, хотя они с точки зрения жи- тейского опыта даже предшествуют функциональным алгоритмам (например, алгоритм перехода улицы), более трудны для формали- зации и систематического изучения. В то же время в классе алго- ритмов работы с величинами можно практически вплотную подой- ти к понятию глобальной переменной, разрешая некоторым вели- чинам быть, одновременно, аргументом и результатом алгоритма.
Это особенно годится для алгоритмов работы с табличными ве- личинами (например, алгоритмы сортировки).
Список использованных источников
1. Ершов, А. П. Два облика программирования / А. П. Ершов – Кибернетика, № 6. – 1982. – С. 122–123.
2. Ершов, А. П. Предварительные соображения о лексиконе программирования. – Проблемы кибернетики и вычислительной техники, вып. 1 / А. П. Ершов – М.: Наука. – 1985.
3. Основы информатики и вычислительной техники. Пробное учебное пособие для 9-го кл. средней школы. Под ред. А. П. Ершова и В. М. Монахова. – М.: Просвещение, 1985.
УДК 655.56
Инклюзивный дизайн приложений Гурская Д. А., студент Василевская В. А., студент
Белорусский национальный технический университет Минск, Республика Беларусь
Научный руководитель: к.т.н., доцент Дробыш А. А.
126 Аннотация:
В данной статье рассматривается понятие инклюзивного дизайна приложений и его назначение. Также в данной статье выделены ос- новные правила инклюзивного дизайна при создании приложений.
Инклюзивный, или универсальный дизайн – метод проектирова- ния, который считается с потребностями и возможностями макси- мального количества людей. Вместо того чтобы ориентироваться на гипотетического пользователя, инклюзивный дизайн заботится о широком круге людей, создавая интерфейсы для совместного ис- пользования отдельным продуктом.
Инклюзивный дизайн не работает на определенную группу, он ориентируется на особые предпочтения и общие ситуации. Дизайн, который предназначен только для человека с повышенными по- требностями, – не инклюзивный, потому что исключает других лю- дей. Это лишь вспомогательная технология.
Люди с инвалидностью регулярно сталкиваются с трудностями:
не все подъезды оборудованы пандусами, дверные проемы и двери лифтов зачастую слишком узкие для колясок, а рельефная плитка для незрячих людей – совсем редкость. Похожие проблемы есть и в цифровых продуктах: иногда пользователям с плохим зрением зака- зать еду в приложении так же трудно, как добраться до магазина и самостоятельно ее купить.
Основные правила инклюзивного дизайна:
1. Контраст. Проблемы со зрением в той или иной мере испы- тывают более 2 млрд человек. А для людей с ослабленным зрением важна контрастность. Для этого существует стандарт контрастности текста WCAG. Этот стандарт принят для текста, поэтому логотипы и иллюстрации не должны ему соответствовать.
Проверить, соответствует ли дизайн рекомендованному WCAG контрасту, можно в онлайн-сервисах Coolors или WebAIM или с помощью плагинов Figma – Contrast и Color Contrast Checker.
2. Размер шрифта. Оптимальные значения трудно определить точно, потому что при одинаковом кегле в одних шрифтах буквы будут крупными, а в других – мелкими. В гайдлайне «Сбера» реко- мендовано брать не менее 16 пикселей для основного текста. В
127
стандартах WCAG есть только минимальный интерлиньяж – кегль умножить на 1,5 и никаких других требований.
3. Цвет. Некоторые пользователи хорошо различают текст лю- бого размера, но имеют нарушения цветового восприятия. И если цвет в интерфейсе несет какую-то важную информацию, нужны текстовые подсказки. Например, для обозначения ошибки традици- онно используют красный, который не воспринимают люди с даль- тонизмом. Поэтому изменения цвета недостаточно – нужно явно написать, что именно пошло не так.
4. Скринридеры. Незрячим людям контраст, размер шрифта, подсказки и возможность увеличить масштаб не помогут. Для таких людей существуют скринридеры – программы и приложения, кото- рые зачитывают текст на экране.
Для корректной работы скринридера важна работа не только ди- зайнера, но и разработчика. Типы элементов должны быть прописа- ны в коде – тогда скринридер сможет показать незрячим и слабови- дящим людям, где кнопка, где подпись, а где заголовок.
Чтобы скринридер работал корректно, важно также сделать кнопки и заголовки информативными – чтобы они помогали без контекста разобраться в устройстве интерфейса.
5. Делать контент проще для восприятия. Тексты, напечатан- ные декоративными шрифтами, или плохо структурированные веб- страницы трудно воспринимать невыспавшимся людям и дислекси- кам. Упрощение дизайна улучшает доступность.
6. Помочь пользователям кликать и скроллить. Людям с двига- тельными нарушениями может быть трудно задействовать сразу две руки или точно попасть в маленькую кнопку. Если элемент неиз- бежно мелкий, вокруг него нужно больше пустого места.
Пространство вокруг элементов тоже должно быть кликабель- ным. Прицельно попасть пальцем или мышкой прямо в кнопку мо- жет быть трудно всем пользователям.
С точки зрения разработки важно корректно сделать управление интерфейсом с клавиатуры – начиная от скроллинга и заканчивая выбором кнопок для перехода по ссылкам. Нажимать на кнопки при нарушениях моторики проще, чем управлять мышкой и тачпадом.
7. Помнить про другие нарушения. У пользователя может быть полная или частичная потеря слуха. Обычно это не мешает работе с
128
сайтами и приложениями – многие люди добровольно отключают звук на своих гаджетах. Но в онлайн-игре или видео важно позабо- титься о субтитрах. А если в интерфейсе какого-нибудь сервиса звуковой сигнал обозначает новое сообщение или успешную опла- ту, это должно еще и визуально отражаться на экране.
Активная анимация может спровоцировать приступ у людей с эпилепсией. В WCAG прописана возможность отключения анима- ции, которая не влияет на понимание интерфейса. В гайдлайне Google рекомендуется автоматически отключать анимацию контен- та спустя пять секунд, а если необходимо мигание, ограничить его до трех кадров в секунду.
Но всегда стоит помнить, что доступность для всех недостижи- ма. Даже если дизайн сделан строго по принципам WCAG, нельзя с уверенностью сказать, что им сможет пользоваться любой. Все про- блемы и неочевидные мелочи учесть невозможно – интерфейс мо- жет стать доступнее для одних и сложнее для других.
Список использованных источников
1. Курносова, С. А. Инклюзивная компетентность: концепту- альное обоснование / С. А. Курносова – Типография ООО «Печат- ный двор». – Челябинск. – 2015.
2. Анищенко, Ю. WWW-редактор: больше, чем просто HTML / Ю. Анищенко. – 2012.
3. Шрейдер, Ю. А. Информационные процессы и информаци- онная среда / Ю. А. Шрейдер. – Науч.-техн. информ. – 1976.
УДК 621.762.4
No-code разработка приложений Каминская И. В., студент
Бабицкая Э. С., студент
Белорусский национальный технический университет, г. Минск, Республика Беларусь
Научный руководитель: к.т.н., доцент Дробыш А. А.
129
Аннотация: в статье рассматривается понятие No-code разработ- ки, определяется целесообразность и ограничения ее использования в повседневной работе.
No-code (зерокод, zerocode и др.) – обобщенное название для со- здания цифровых продуктов без программирования с помощью конструкторов. Работа строится путем перетаскивания элементов приложения в рабочую область no-code-инструмента и настройке связей между ними. Наиболее популярными инструментами явля- ются Bubble, Glide, Adalo, Bravo Studio, Thunkable и др. Данный вид деятельности характеризуется низким порогом вхождения, что де- лает технологию более доступной и дешевой.
Вокруг разработки приложений без знания языков программиро- вания ведутся споры, которые зачастую основаны на маркетинговой выгоде той или иной стороны. Например, платформам (конструкто- рам, программам) по созданию приложений без участия програм- мистов выгодно отстаивать собственную идею, так как они получа- ют прибыль за счет предоставления инструмента для разработки.
Так, стоимость тарифов может зависеть от функционала разрабаты- ваемого приложения, от продолжительности техподдержки, от до- ступного места хранения данных и пр.
No-code-решения подходят, если:
нет необходимости в нестандартном дизайне;
нет необходимости в сложных технических решениях;
необходимо проверить бизнес-гипотезу на релевантность (исследовать рынок) с наименьшими затратами;
компания, заказчик не располагает большим бюджетом;
клиентура бизнеса не превышает условно 500 человек;
необходимо воплотить минимально жизнеспособную вер- сию программного продукта.
Конструкторы приложений позволяют выбирать шаблоны под нужды пользователя, осуществлять интеграцию с другими плат- формами, организовывать управление базами данных, использовать готовые подключаемые модули и др. Вместе с тем, no-code сервисы являются платными инструментами, пусть и предоставляют огра- ниченную бесплатную версию. Как правило, ее недостаточно для
130
того, чтобы реализовать рабочий функционал с дополнительными модулями и интеграциями.
Однако не стоит забывать об ограничениях No-code инструмен- тов. Первое из них – это плохая масштабируемость продукта. Вто- рое ограничение – зависимость приложения от платформы разра- ботки. Так, приложение, созданное программистами «с нуля», в большинстве случаев, принадлежит заказчику, в то время, как при- ложение, разработанное с помощью No-code подвержено риску ока- заться вне зоны доступа, если лицо, которому принадлежит плат- форма по каким-либо причинам решит ограничить к ней доступ.
Иными словами, архитектура приложения, собранного в конструк- торе, попадает под значительную зависимость от платформы разра- ботки, что отрицательно сказывается на выживаемости бизнес- проекта в дальнейшем итоге а также на его прибыльность.
Следующее ограничение – вопросы к безопасности разрабатыва- емого продукта. Данные пользователей чаще всего находятся на серверах владельцев No-code платформ, что не позволяет бизнесу давать клиентам собранных приложений гарантии о безопасности и конфиденциальности при их использовании.
На данный момент no-code разработка приложений как самосто- ятельное направление не получила широкого развития ввиду приве- денных выше ограничений. Однако к созданию приложений без программирования прибегают в контексте более глобальных задач.
Так, навыки ноу-кодинга могут использоваться продуктовыми ме- неджерами для донесения мысли и задумки подчиненным специа- листам (дизайнерам, разработчикам), которые работают над созда- нием самостоятельного программного продукта без использования конструкторов приложений.
Таким образом, No-code направление постепенно развивается, предоставляя возможность создавать программные продукты без знания программирования. Но стоит помнить, что No-code решения хорошо подходят для простых приложений, требования к безопас- ности и функционалу которых не достигают масштабов серьезных бизнес-проектов. Вместе с тем, они способны нанести вред расши- ряющемуся бизнесу, если вовремя не предоставить разработку при- ложения программистам-профессионалам.
131
Список использованных источников
1. Кому стоит специализироваться на No-code [Электронный ресурс] // Хабр. – 2022. – Режим доступа: https://habr.com/ru/post/
666396/?ysclid=l7bgiwzvl5219326582. – Дата доступа: 24.10.2022.
2. «Революция отменяется»: почему сервисы no-code далеко не всегда полезны бизнесу [Электронный ресурс] // RВ.RU. – 2022. – Режим доступа: https://rb.ru/opinion/nocode-is-it-ok/?ysclid=l7bhtolp1c 897424527. – Дата доступа: 24.10.2022.
3. Rocketslides: как одному дизайнеру зерокодить 1000 слайдов в день [Электронный ресурс] // VC.RU. – 2020. – Режим доступа:
https://vc.ru/tribuna/183108-rocketslides-kak-odnomu-dizayneruzerokod it-1000-slaydov-v-den – Дата доступа: 24.10.2022.
УДК 37.032
Организация процесса обучения робототехнике на основе технологии проектного обучения
Каминская И. В., студент
Белорусский национальный технический университет, г. Минск, Республика Беларусь
Научный руководитель: к.п.н., доцент Евсеева О. П.
Аннотация: в статье рассматривается возможности применения технологии проектного обучения на занятиях объединения по инте- ресам «Робототехника» для учащихся с 1 по 4 класс.
Технология проектного обучения – система получения знаний, когда ученики вовлечены в процесс планирования и выполнения проектов, т. е. практических заданий, которые постепенно усложня- ются от одного к другому [1].
На занятиях объединения по интересам «Робототехника» проис- ходит овладение навыками начального технического конструирова- ния, развития мелкой моторики, изучение понятий конструкции и ее основных свойств (жесткости, прочности, устойчивости), навык взаимодействия в группе.
132
С целью реализации образовательной программы дополнитель- ного образования детей и молодежи технического профиля по направлению «Техническое конструирование» была разработана программа базового уровня. Учебная программа «Робототехника»
разработана на основе типовой программы дополнительного обра- зования детей и молодежи (технический профиль), утвержденной Постановлением Министерства образования Республики Беларусь от 6 сентября 2017 года № 123. Она рассчитана на обучение детей в возрасте от 6 до 11 лет с разной степенью одаренности, имеющих интерес к технической деятельности и была направлена на обеспе- чение дополнительной теоретической и практической подготовки по техническому конструированию и моделированию.
Содержание программы было нацелено на развитие творческих способностей, адаптацию к жизни в социотехническом обществе, на развитие интеллекта и нравственности. Содержание программы способствует расширению представлений учащихся о технике, ме- ханизмах, машинах, роботизированных устройствах, а также спосо- бах их конструирования и программирования.
Разработанная программа рассчитана на 1 год обучения и ориен- тирована на учащихся младшего и среднего школьного возраста.
Предполагается, что занятия групповые, проводятся 1 раз в неделю по 2 часа. Такого количества часов достаточно, чтобы освоить предложенную программу в данном возрасте.
Занятия по робототехнике включали следующие этапы. На заня- тии учащиеся конструировали одна модель из специального кон- структора LegoWeDo 1.2, в процессе работы учащиеся осваивают базовые принципы механики, математики и физики. Обучение вы- страивается согласно принципу наглядности, так как у учащихся есть учебно-методическое обеспечение в электронном виде – это пошаговая инструкция, представленная виде PDF-файл или набор последовательных фотографий с пошаговой сборкой модели, ос- новной обучающий материал встроен в программное обеспечения LegoWeDo. Каждая собранная модель представляет собой практи- ческое задание, которое вовлекает учащихся в процесс выполнения проектов, в рамках реализации занятий на объединении по интере- сам «Робототехника» реализовывается технология проектного обу- чения с различными целями и задачами на каждом занятии [2].
133
В учебном году 2021–2022 занятия проводились с ноября по май.
В ноябре занималось 14 учеников, затем с декабря по март их чис- ленность в среднем равнялась 11–12 ученикам, а в апреле-мае со- кратилась до 9 и 6 одновременно. При этом, с ноября по март сред- ний процент посещаемости занятий за месяц составил 50 %. Один ученик посетил 100 % занятий.
На посещение занятий влияют субъективные и объективные факторы. К субъективным факторам относится личный интерес учащегося, то, каким в его глазах предстает педагог, наличие или отсутствие таких личностных характеристик как целеустремлен- ность, усидчивость, коммуникабельность и др. К объективным при- чинам можно отнести время проведения занятий, уровень их орга- низации. Важную роль в посещении занятий также играет личность преподавателя, его педагогическое мастерство, техники и методы, которые он выбирает для проведения занятий.
Рис. 1 – Динамика изменения посещаемости объединения по интересам
«Робототехника» учащимися в течении периода обучения
На основании приведенной статистики выяснить причины отри- цательного прироста посещения невозможно, так как необходимо учитывать дополнительные факторы, влияющие на процесс обуче-