Worldskills russia программные решения для бизнеса

WSR 2023 🚀

🛠️ Технологии

Сессия 1

https://disk.yandex.ru/d/gcqNGLGLzrxPOQ

Презентация

Составить презентацию о себе, 10 слайдов

Задание на Сессию 1

1. Прочитать предметную область

2. Построить диаграмму прецедентов UML(MS Visio, Star UML)

3. Построить ERD диаграму (MS Visio)

4. Построить скрипт базы даных (MSSQL, PostgeSQL)

Замечание: дополнительно можно MySQL.

Замечание: можно сразу написать скрипт базы данных, а потом из нее получить ERD. Научиться пользоваться DBeaver для отладки базы данных

1. Создать словарь данных на основе ERD (по примеру). Сохранить в xls

2. Разработать wareframe для клиента мобильного приложения (Visio)

git push origin Designing

1. Реализация модуля авторизация (WPF Core 6,7 + EF

Замечание: нам потребуется Reverse Engeeniring (Scaffold) и выучить механизм миграций (Code First)

git push origin Desktop_Auth

Readme: описать результаты: UML, ERD, Словарь, Wareframe, модуль авторизации

Проверка: git(push, pull, config), база данных (подключение через vs, dbeaver)

Подготовка: час, потом будут чистить git и базу, компьютер не чистят, можно подготовить visual studio (архитектура, пакеты, подключение к базе данных, подключение к git, конфиги)

Стек: WPF(событийная модель) + MSSQL + Требования по стилю

Повышенная сложность: WPF(MVVM) + PostgreSQL + Material Design

Вариация: MAUI(MVVM) + MySQL + WPF Toolkit

Усложненная архитектура: MAUI(MVVM) + API + MSSQL + Fontawesome

Микросервисная архитектура: ASP Core API + PostgreSQL + VueJS(web) + MAUI(client) + Electron(client) + Android(client) (maybe remote api on VPS or db on Cloud)

Ответ прислать мне Pull Request в репозиторий WSR 2023

Замечание: для развертывания базы данных сделать готовый скрипт вместе с данными (схема + данные)

WorldSkills — это международное движение, занимающееся проведением профессиональных соревнований для молодых людей в возрасте до 22 лет.

Международный финал проводится раз в два года. В этом году местом проведения финала стала Казань (прошлый финал был в 2017 году в Абу-Даби, следующий будет в 2021 году в Шанхае).

Чемпионаты WorldSkills — это самые большие мировые чемпионаты профессионального мастерства. Начались они с рабочих профессий, а в последние годы все больше внимания уделяется “профессиям будущего”, включая IT-дисциплины, под которые на чемпионате в Казани был выделен отдельный огромный кластер.

В IT-блоке есть компетенция (конкретный «вид спорта») под названием «Программные решения для бизнеса» (IT Software Solutions for Business).

В каждом из соревнований ограничивается разрешенный список используемых инструментов. И если, например, для «ландшафтного дизайна» ограничивается именно список возможных инструментов (конечно, без указания явного производителя или цвета), то в компетенции «Программные решения для бизнеса» список допущенных технологий, которые могут использовать участники, жестко ограничен с указанием конкретных технологий и конкретных платформ (.NET и Java с определенным набором фреймворков).

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

Осенью 2018 г дирекция WorldSkills услышала нас. Теперь предстояло обкатать методику включения новых технологий в соревнования. Это непросто.

В инфраструктурный лист чемпионата в Казани включили платформу 1С:Предприятие (1С:Enterprise) и организовали экспериментальную площадку IT Software Solutions for Business Sandbox.

Отметим, что официальный язык чемпионата – английский. Все материалы с результатами решения заданий (исходные коды, сопроводительная документация, интерфейсы ПО) должны были передаваться тоже на этом языке. Несмотря на сомнения некоторых людей (до сих пор!), на 1С можно писать на английском.

В соревнованиях на этой площадке приняли участие 9 молодых ребят из 8 стран мира (Филиппины, Тайвань, Корея, Финляндия, Марокко, Россия, Казахстан, Малайзия).

Жюри — команду экспертов — возглавил эксперт из Филиппин Джоуи Манансала.

Были представлены эксперты из Финляндии, ОАЭ, Коста-Рики, Кореи, России и Тайваня.

Отдельно отметим, что участники из России (Павкин Кирилл, Султанова Айгуль) и Казахстана (Витовский Людвиг) приняли решение использовать платформу 1С:Предприятие в рамках соревнований. Остальные участники использовали .NET для десктопной и Android Studio для мобильной разработки. Интересно то, что участники, выбравшие 1С — совсем молодые (Кирилл — ученик школы в Ставрополе, в этом году перешел в 11 класс, Айгуль — студентка колледжа, Казань, Татарстан), тогда как их соперники были гораздо более опытные (например, участник из Кореи — призер чемпионата WorldSkills 2013 года в Лейпциге; все имеют опыт участия в WorldSkills и несколько лет профессионального опыта работы в индустрии).

Учитывая, что в рамках соревнований участники использовали различные современные технологии, нам представился шанс проверить платформу 1С:Предприятие в действительно боевых условиях, сравнить как качество получаемых с ее помощью решений, так и скорость разработки, достигаемую с ее использованием.

Отдельно отметим, что в рамках специальной площадки IT Software Solutions for Business Sandbox участники выполняли те же задания, что и участники основной площадки IT Software Solutions for Business.

Само задание представляет собой комплексную задачу на автоматизацию определенного бизнеса, в этом году примером бизнеса стала условная компания «КазаньНефть».

Легенда

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

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

Условия Чемпионата

Задачи выдавались участникам в виде модулей (сессий) с требованием реализовать их за ограниченное время. Всего было 7 модулей. Три сессии для решения на десктопе – по 2.5 часа. Три сессии – клиент-серверная разработка, где клиентом выступало мобильное приложение, а общение между клиентом и сервером осуществлялось посредством WEB-API. На это отводилось по 3.5 часа. Последняя сессия – задачи на реверс-инжиниринг существующего программного обеспечения, 2.5 часа. В рамках реверс-инжиниринга участники должны были, основываясь на предоставленной им информации, спроектировать структуру базы данных приложения (построив ER-диаграмму), проанализировать сценарии использования системы (построив диаграмму вариантов использования), а также разработать и спроектировать интерфейс программного решения по предоставленным функциональным требованиям.

В качестве платформ для разработки использовались на основной площадке .NET (C#) и Java (включая Android Studio для мобильной разработки). В экспериментальном SandBox использовались .NET, Java и 1C:Enterprise версии 8.3.13.

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

Особенностью заданий является их «жизненность» — множество требований и ограниченное время. Большинство задач не специальные олимпиадные, а очень близкие к реальным промышленным задачам — с ними специалисты сталкиваются каждый день. Но задач много, а время ограничено. Участник должен решить максимальное количество задач, которые будут иметь наибольшую пользу для бизнеса. Совсем не факт, что сложная с точки зрения алгоритмики задача будет иметь больший вес, чем элементарная. Например, создание функционирующей учетной системы из трех таблиц для бизнеса важнее, чем красивая отчетная форма, со сложными алгоритмами, которая без этих таблиц совершенно не нужна.

Мы попросили победителя соревнований, участника от России, Кирилла Павкина, рассказать подробнее о том, какие были задачи и как он подошел к их решению.

Ниже – описание задания, рассказ самого Кирилла о том, как он решал задание. Мы также попросили Виталия Рыбалку, сотрудника 1С, одного из экспертов IT Solutions for Business Sandbox, прокомментировать решения Кирилла.

В рамках задания требовалось автоматизировать деятельность нескольких видов пользователей:

• Ответственных за учет активов компании
• Ответственных за внеплановые ремонты и плановое ТО активов компании
• Менеджеров по закупкам комплектующих и расходных материалов
• Нефтеразведочных и нефтедобывающих подразделений
• Топ-менеджементу требовались аналитические отчеты

Сессия 1

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

Кирилл: Интересной подзадачей была реализация кнопок в списке активов. Для решения использовался динамический список: пишем произвольный запрос, а при получении данных на сервере присваиваем нужным полям навигационные ссылки на изображения из библиотеки картинок.

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

Некоторые формы нужно было перерисовывать при повороте экрана:

При изменении параметров экрана меняем видимость групп кнопок.

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

Комментарий эксперта: с точки зрения решения на платформе 1С:Предприятия задача довольно понятна. Кроме собственно создания мобильного приложения нужно было озаботиться передачей данных из СУБД «сервера» (MS SQL на десктопе) в мобильное приложение и обратно. Для этого использовались механизмы внешних источников данных и http-сервисов в десктопном «прокси-приложении». Для самой мобильной платформы повышенную сложность представлял вывод картинок в динамический список.

Сессия 2

Нужно было наладить менеджмент ремонтов по активам Компании. В рамках этой задачи нужно было вести список запросов на ремонты (по подразделениям и группам), учитывать приоритеты срочности ремонтов, планирование графика ремонтов в соответствие с приоритетами, заказ нужных комплектующих и учет уже имеющихся. Интересной подзадачей являлось то, что некоторые комплектующие имели срок годности; если для данного актива уже заказывали деталь и ее срок не истек, то для этого актива не нужно закупать эту же деталь еще раз. Интерфейс по ремонтам разрабатывался для десктопной составляющей ПО компании.

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

Форма списка, доступная ответственному лицу представлена ниже:

Кирилл: Здесь можно выделить только подсветку незавершенных запросов на обслуживание. Решается условным оформлением в динамическом списке.

При нажатии на кнопку внизу экрана пользователь может перейти к следующей форме:

Ничего сложного с точки зрения 1C в этой форме нет.

Форма, доступная менеджеру по обслуживанию далее:

В этой форме есть сортировка по приоритету и дате запроса. Нажимая на кнопку снизу пользователь может перейти в форму выбранного запроса:

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

Комментарий эксперта: тут Кирилл сам верно расставил акценты. С точки зрения реализации на платформе 1С:Предприятия ничего архисложного нет. Требовался внимательный анализ условий учета и использования запчастей и грамотная реализация задачи в целом. Кроме этого, нужно было правильно наладить учет запросов на обслуживание. Основную сложность представлял лишь цейтнот в 2.5 часа.

Кроме этого, как в мобильной разработке, участнику следовало грамотно получать данные из внешней СУБД (MS SQL).

Сессия 3

Для ТО (технического обслуживания) предлагалось реализовать сервис долгосрочного планирования. Интересной особенностью здесь являлось требование формирования графика ТО по активам как по срокам – например, каждый второй месяц 3-го числа. Так и по какому-то количественному показателю – например, по одометру автомобиля (замена масла каждые 5000км, замена покрышек каждые 20000км). Менеджер по ТО должен был получить удобное мобильное приложение, которое динамически выводит список просроченных, актуальных и выполненных ТО за указанный период. Кроме этого, каждый вид ТО должен был раскрашен цветом по специально оговоренным правилам. Мобильное приложение должно было обеспечить заведение новых графиков ТО и отметку уже выполненных прямо в мастерских с оперативной актуализацией этой информации на сервере.

Кирилл: Существует два типа ремонтов: по времени (time-based) и по пробегу (run-based). Внутри каждого допускается вариативность. Например, по плану ремонт должен происходить каждую пятницу 13-го числа месяца или через каждые 20,000 километров пробега. Задача считается завершенной, если справа от нее стоит галочка.

Было предоставлено условие сортировки задач в списке. Также, каждая строка должна выделяться цветом в зависимости от условий.

При нажатии на кнопку снизу можно создать новый план на обслуживание:

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

Комментарий эксперта: как и в предыдущей мобильной разработке на платформе 1С:Предприятие здесь задача глобально разделилась на 2 составляющие – общение с «сервером» через web-api и грамотное отображение динамического списка с условным оформлением и фильтрации (отбор) данных. Кроме этого интересным для реализации было требование учета ремонтов как по периодам, так и по количественному показателю.

Сессия 4

По комплектующим и расходным материалам требовалось учитывать запасы, планировать расходы и будущие закупки. Кроме этого, здесь появлялся партионный учет, но не для всех товаров. Все это необходимо было вести в рамках множества складов, включая поступление, расходование и перемещение. По условиям задачи требовалось обеспечить контроль остатков и не допускать конфликтов при работе с актуальными запасами. Менеджеры по закупкам работают в десктопной версии ПО.

Главная форма представлена ниже:

Кирилл: Помимо сортировки из условия, предлагалось дать пользователю возможность произвольной сортировки. На 1C об этом можно даже не задумываться. Поле с количеством деталей должно быть подсвечено зеленым для приходных накладных.

В этой сессии просили контролировать остатки товаров на складах. Так, должно выводиться соответствующие сообщение при попытке удалить приходную накладную. Здесь и вспоминаем экзамен на специалиста по платформе. Форма приходной накладной далее:

У каждой детали есть признак, по которому определяется, должна ли она привязываться к определенной партии. Для таких запчастей обязательно нужно указывать номер партии во всех документах. Это является дополнительным измерением при контроле остатков деталей. Их также можно перемещать между складами:

Форма отличается от предыдущей лишь тем, что вместо заказчика нужно указывать склад, из которого будет осуществляться поставка. Список выбора для партии автоматически составляется после подбора детали. Пользователь может сформировать отчет по остаткам запчастей:

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

Комментарий эксперта: в этой сессии (модуле) впервые появился партионный учет. Участникам требовалось учитывать расходные материалы и товары не только сами по себе, но и по партиям. В целом, задача отлично подходящая для платформы 1С:Предприятие – вот только разработать это всё нужно было с нуля и успеть за 2.5 часа.

Сессия 5

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

Кирилл: При выборе скважины высвечивается столбчатая диаграмма, на которой выделены слои до залежей нефти или газа. Для каждого слоя хранится его наименование, цвет и диапазон залегания. Из-за особенностей оформления, встроенные в платформу диаграммы не спасают, зато табличный документ отлично справляется с поставленной задачей. Скважины можно создавать и изменять:

Кроме множественной защиты от дурака, ничего интересного в этой форме не было.
Далее предлагалось контролировать подключение к серверу. Каждые 5 секунд пытаемся подключиться. Если не получилось, то ограничиваем функциональность приложения и выводим сообщение.

Комментарий эксперта: задача этой сессии интересна в первую очередь графическими возможностями. Участники, использующие платформу 1С:Предприятие решали её двумя разными способами – кто-то механизмом диаграмм, кто-то табличным документом. У каждого из способов есть свои плюсы и минусы. В рамках решения на чемпионате WorldSkills ключевым являлось время (снова вспоминаем про ограничение времени). Отдельная интересная задача – пинг сервера каждые 5 секунд и изменение поведения мобильного приложения в зависимости от доступности либо недоступности сервера.

Сессия 6

Для топ-менеджмента предлагалось создать рабочее пространство – Dashboard. На одном экране нужно было выводить общие показатели деятельности компании за указанный период в графическом и табличном виде. Главной формой является отчет по затратам:

Кроме Dashboard нужно было реализовать распределение запчастей для ремонтов активов, используя методы списания FIFO/LIFO/«Самый дешевый уходит первым».

При распределении учитывался партионный учет, использовался контроль остатков и защита от несанкционированных действий пользователя («защита от дурака»).

Кирилл: Для решения использовались таблицы значений с программной генерацией колонок, поскольку их может быть произвольное количество:

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

Диаграммы выводил с помощью встроенных механизмов платформы, а заполнял программно с помощью запросов.

Здесь же предлагалось реализовать поддержку многоязычности. Программа загружает XML-файлы с локализацией элементов интерфейса, а форма должна перерисовываться при выборе языка в выпадающем списке.

При нажатии на кнопку в левом нижнем углу экрана открывается форма по управлению запасами:

В этой форме мы наконец-то начинаем тратить запчасти на ремонт. Здесь мы сначала находим детали, которые нам понадобятся для починки актива. По выбранным полям и методу распределения (FIFO, LIFO или минимальная цена) выводятся найденные совпадения или сообщение, если таковых нет. После этого можно пометить детали как предназначенные для починки данного актива. Контроль остатков актуален для текущей сессии. Если мы уже назначили детали, то они больше не могут попасть в найденные.

Комментарий эксперта: очень интересная сессия. Она по максимуму использует возможности платформы 1С:Предприятия – тут и грамотная работа с виртуальными таблицами регистров накоплений, и программная работа с элементами формы (в первую очередь – таблицами, во вторую — заголовками), и диаграммы. И даже LIFO/FIFO при анализе запасов, анализ прибыли/убытков и т.п.

Сессия 7

В финале задания (7 сессия) заказчик предоставил ПО (exe-файл) по проектной деятельности и небольшое видео по работе с ним. Требовалось провести реверс-инжиниринг и на основании этого создать 2 диаграммы: диаграмму вариантов использования и диаграмму сущность-связь. Кроме этого, были выдвинуты некоторые требования по созданию ПО в будущем – необходимо было сформировать макет интерфейса по этим требованиям.

По условиям соревнований для создания диаграмм требовались использовать исключительно MS Visio.

Комментарий эксперта: в этой сессии возможности платформы 1С:Предприятия практически не использовались. Диаграммы по условиям соревнований создавались в MS Visio. А вот прототип интерфейса можно было создать в пустой информационной базе 1С.

Общие замечания

В начале каждой сессии предлагалось выполнить импорт данных посредством SQL-скрипта. В этом заключался главный недостаток в использовании 1C по сравнению с C#, поскольку мы тратили не менее получаса на перегонку данных во внешние источники данных, создание собственных таблиц и перемещение строк из внешних источников в наши таблицы. Остальным требовалось всего-лишь нажать кнопку Execute в Microsoft SQL Studio.

По очевидным причинам хранить данные на мобильном устройстве не стоит. Поэтому на мобильных сессиях мы создавали серверную базу. Там хранили данные и предоставляли доступ к ним по http-сервисам.

Комментарий эксперта: здесь интересен баланс 1С/не1С – в то время как программисты на 1С:Предприятие тратили ощутимое время на подключение к внешней СУБД (Кирилл отдельно упомянул это выше), разработчики на C#/Java (Android Studio для мобильной разработки) тратили время на другие направления – интерфейсы, написание большего количества кода. Поэтому итоги каждой сессии были для всех экспертов непредсказуемы и крайне интересны. И интрига эта сохранялась до конца – достаточно посмотреть финальную таблицу победителей с распределением баллов.

Кирилл рассказ закончил

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

Отдельного упоминания заслуживает принятая система оценивания.

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

Критерии оценивания очень мелко гранулированы — при общей стоимости задания сессии в десятки баллов, выполнение какого-то критерия может добавить участнику десятые доли балла. Тем самым достигается крайне высокий и объективный уровень оценивания результатов каждого участника соревнований.

Результаты

Финальные результаты оказались впечатляющими.

В упорной борьбе победу одержал Кирилл Павкин из России, использовавший платформу 1С:Предприятие. Кириллу 17 лет, он из Ставрополя.

Буквально десятые доли балла отделили победителя от преследователей. Второе место занял участник из Тайваня. Общая таблица лучших шести результатов выглядит так:

Безусловно, Кирилл одержал победу благодаря своему таланту, знаниям и умениям.

Однако отметим, что все три участника, использовавшие в качестве инструмента платформу 1С:Предприятие, вошли в первую пятерку — что является безусловным подтверждением мирового уровня технологии 1С:Предприятие.

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

ТЕХНИЧЕСКОЕ
ОПИСАНИЕ

КОМПЕТЕНЦИЯ

«ИТ – Программные решения для бизнеса»

Организация
WorldSkillsRussia (WSR) с согласия технического комитета в соответствии с
уставом организации и правилами проведения конкурсов установила нижеизложенные
минимально необходимые требования владения этим профессиональным навыком для
участия в конкурсе.

Техническое
описание включает в себя следующие разделы:

1. Введение

2. Стандартные
спецификации WorldSkills (WSSS)

3. Оценка стратегии и
спецификация

4. Схема оценки

5. Тестовый проект

6. Развитие
квалификаций и общение

7. Техника безопасности

8. Инфраструктура

9. Участие посетителей
и медиа

10. Экологичность

Дата вступления в силу:

______________________ Тымчиков Алексей,
Технический директор WSR

_____________________
Осадчий Александр, эксперт WSR

1. Введение

1.1.
Название и описание компетенции

1.1.1.
Название Компетенции:

ИТ – Программные решения для бизнеса

ITSoftwareSolutionsforBusiness (англ.)

1.1.2.
Описание работы, роли или задания

Быстрые темпы глобализации в последние десять
лет были, в значительной степени, обусловлены прогрессом в области
информационных и коммуникационных технологий (ИКТ). IT-специалисты пользуются
большим спросом по разным направлениям, одним из которых является
предоставление решений для бизнеса.

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

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

IT специалисты решают профессиональные задачи
такие как (но не только эти):

—    
анализ текущей информационной системы, представлениевариантов
по её обновлению, включая анализ затрат и выгод;

—    
анализ и формализация требований пользователя;

—    
разработка детальных спецификаций системы;

—    
разработка программного обеспечениядля решения
поставленных задач и тестирование решения;

—    
интеграция программного обеспечения с другими
системами;

—    
создание учебных материалов, обучение
пользователейи презентация программных решений пользователям;

—    
установка, внедрение и поддержка программного
обеспечения системы.

IT-профессионалы в области разработки программных
решений могут работать на крупных, средних и малых предприятиях в качестве
инженера-программиста, в консалтинговых фирмах — в качестве консультанта, в
фирмах по разработке или поставкам программного обеспечения — в качествеподрядчика.

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

1.2.
Актуальность и значимость данного документа

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

Каждый эксперт и участник должен знать и
понимать Техническое описание.

В случае любой неточности в техническом
описании на разных языках, английской версииотдается предпочтение.

1.3.
Необходимые документы

Данное техническое описание содержит только
профессиональную информацию, оно должно использоваться в сочетании со
следующими документами:

·      «WorldSkillsRussia»,
Правила проведения конкурса;

·     
«WorldSkills International», «WorldSkills Russia»: онлайн—ресурсы, указанныевданномдокументе;

·     
Правила техники безопасности и санитарные нормы.

2. Стандартные спецификации WorldSkills (WSSS)

2.1.
Основные понятия WSSS

В WSSS указывает на знание, понимание и
конкретные навыки, которые лежат в основе лучшей международнойпрактикис позиции
технического и профессионального выполнения. Это должно отражаться в общем
глобальном понимании того, что все работы, выполненные индивидуально или
группой, должны быть связаны с производством или бизнесом. (www.worldskills.org/WSSS)

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

Во время конкурса оценка знаний и понимания
будет проходить через оценку выполнения. Не будет отдельных тестов на знание и
понимание.

Стандартныеспецификации разделены на
определенные разделы с заголовками с добавлением справочных номеров.

Каждому разделу ставится в соответствие
процент от общей оценки для указания относительной важности раздела в пределах
норм. Сумма всех процентных оценок 100.

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

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

2.2.
WORLDSKILLS Стандартныеспецификации

Секции	Относительная важность (%)
1	Организация работы и управление	5
	Участник должен знать и понимать: — принципы продуктивной работы в команде; — принципы организации и поведение систем; — подходы, способствующие эффективности продуктов, стратегий и практик; — технологии сбора информации из различных источников, анализа и оценки информации. Каждый должен уметь: — составлять ежедневный планработс учетом сроков ивременных ограничений; — использовать компьютер или иное устройство и соответствующее программное обеспечение; — применять методы и навыки исследования и актуализации информациив соответствии с отраслевыми рекомендациями; — сравнивать результат работы с ожиданиями и потребностями клиента / организации.
2	Общение и международные навыки	5
	Участник должен знать и понимать: — важность умения слушать; — необходимость соблюдения принципов внимательности и соблюдения конфиденциальности при работе с клиентами; — важность разрешения недоразумений и противоречивых требований; — важность создания и сохранения доверительных и продуктивных  клиентов и продуктивных рабочих отношений; — Ценность навыков понятной и грамотной письменной и устной речи Участник должен уметь: Использовать навыки грамотности для: — составленияи следования инструкциям в соответствии со имеющимися справочниками; — интерпретировать служебные инструкции и другие технические документы; — -актуализировать документацию в соответствии с последними отраслевыми рекомендациями; Использовать навыки устного общения в: — обсуждении и внесении предложений по вопросу специфики информационных систем; — информировании клиента о развитии системы; — проведении переговоров с клиентом по вопросам бюджета проекта и графику его выполнения; — сборе и согласовании требований клиента; — представлении итоговых разработанных программных решений и в формировании предложений по их дальнейшему развитию; Использовать навыки письменного общения в: — документировании программного решения (например, для составления технических документов, руководств пользователя и т.д.); — информировании клиента о развитии системы; — предоставлении подтверждении,о том, чторазработанное приложение соответствует оригинальной спецификации,и пользователь получает готовую систему; Использовать коммуникационные навыки при работе в команде для: — сотрудничества с другими для достижения требуемых результатов; — слаженно работать в группе по решению проблем. Использовать навыки управления проектами в: — определении приоритетов и планировании задач; — выделении ресурсов для решения задач.
3	Решение проблем, инновации, креативность	5
	Участник должен знать и понимать: — типы проблем, которые могут возникнуть при разработке программного обеспечения; -типы проблем, которые могут возникнуть в бизнесе организации; — подходы к диагностике проблем; — отраслевые тенденции и разработки в отрасли, включая новые платформы, языки, конвенции и технические навыки. Участник должен уметь использовать аналитические навыки для: — обобщения сложной или разнородной информации; — определения функциональных и нефункциональных требований спецификации; Участник должен уметь использовать навыки изучения и обследования для: — сбора требований пользователя (например, интервью, анкетирование, поиск и анализ документов) Участник должен уметь самостоятельно решать проблемы, с которыми столкнулся в процессе работы: — использовать навык решения проблем; — выявлять и решать проблемы своевременно; — собирать и анализировать информацию; — разрабатывать альтернативные решения, выбирать наиболее подходящий вариант и принимать необходимое решение.
4	Анализ и проектирование программных решений	30
	Каждый должен знать и понимать: — важность рассмотрения всех возможных вариантов и выбора лучшего решения на основе взвешенного аналитического суждения и интересов клиента; — важность использования системного анализа и методологий проектирования (например, унифицированногоязыка моделирования(UnifiedModellingLanguage),программной платформыMVC (Model—View-Control), фреймворки, шаблоны проектирования); — необходимость быть в курсе новых технологий и приниматьрешение о целесообразности их применения; — важность оптимизации архитектуры системы с учетом модульности и повторного использования. Участник должен уметь: Анализировать системыс помощью: — моделирования и анализа прецедентов использования (например, диаграммы прецедентов, описания прецедентов, описание действующих субъектов (актер), диаграммы вариантов использования) — структурного моделирования и анализ (например,объектакласса, диаграммы класса домена); — динамического моделирования и анализа (например, схемы последовательности, схемы взаимодействия, диаграммы состояний, диаграммы деятельности); — инструментов и методов моделирования (например, диаграмма сущностей и связей, нормализации, словарь данных; Проектировать системы на основе: — диаграммы классов, диаграммы последовательности, диаграммы состояний, диаграммы деятельности — описания объекта; -схемы реляционной или объектной базы данных; -структурычеловеко-машинного интерфейса; -средств безопасности и контроля; -структурымногозвенного приложения.
5	Разработка программных решений	40
	Участник должен знать и понимать: — важность рассмотрения всех возможных вариантов и выбора лучшего решения для удовлетворения требований пользователя и интересов клиента; — важность использования методологий разработки системы (например, объектно-ориентированные технологии); — важность рассмотрения всех нормальных и ненормальных сценариев и обработки исключений; — важность соблюдения стандартов(например, правила кодирования, руководство по стилю (оформление системной и программной документации), дизайна пользовательского интерфейса, управление каталогами и файлами); — важность точного и постоянного контроля версий (управление версиями); — использование существующего кода в качестве основы для анализа и модификации; — важность выбора наиболее подходящих средств разработки из предложенных вариантов. Участник должен уметь: — Использовать системы управления базами данных для построения, хранения и управления данными для требуемой системы (MySQL или MSSQLServer); — Использовать последнюю версию программного обеспечения среды разработки и инструменты, чтобы изменить существующие коды и писать новый код «клиент-сервер» на базе программного обеспечения (.NETили Java); — определить и интегрировать соответствующие библиотеки и Фреймворки в программное решение; — строить многоуровневые приложения; — разрабатывать мобильный интерфейс для клиента на основе серверной системы.
6	Тестирование программных решений	10
	Участник должен знать и понимать: — принципы устранения распространенных проблем программных приложений; — важность тщательного тестирования решения; — важность документирования испытаний. Участник должен уметь: — составлять план тестирования (например, модульное тестирование, объемное испытания, интеграционноетестирование и приемочные испытания); — разрабатывать тест-кейсы и проверять результаты тест-кейсов; — устранять и исправление ошибок; — составлять отчет о процессе тестирования.
7	Документирование программных решений	5
	Участник должен знать и понимать: — важностьтщательного документирования разработанных решений; Участник должен уметь: — Проявлять профессионализм в подготовке: — Разрабатывать документацию пользователей; — Работать с технической документацией.

3. Оценка стратегии и спецификация

3.1.
Общие рекомендации

Оценивание регулируется Оценкой стратегии
WorldSkills. Стратегия устанавливает принципы и приемы, которые должны
соответствовать оценке, установленной правиламиWorldSkills.

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

В конкурсе WorldSkillsоценка состоит издвух
широких категорий: измерение и мнение судей.
СоответственноониназываютсяобъектнойиJudgement-оценкой. Для обоих типов оценки используются установленные критерии,
по которым оценивается каждый аспект, который имеет большое значение для
обеспечения качества в целом.

Схема маркировки должна следовать нормам
нагрузки в рамках Технического описания. Тестовый проект — это средства оценкив
рамках заявленных навыков на конкурсе и также должен следовать правилам Технического
описания. Специализированная информационная системаКонкурсапредусматривает
своевременную и точную запись оценок и имеет расширенный вспомогательный объем.

Схема маркировки, в общих чертах, будет
сопровождатьпроцесс создания Тестового проекта. После этого Схема маркировки и Тестовый
проект будут разрабатываться и развиватьсяпосредством итеративного процесса для
того, чтобы совместно оптимизировать свои взаимоотношения в рамках Стандартнойспецификации
и Положения о стратегии оценки. Они будут согласованы с экспертами и
представлены WSR для утверждения, чтобы продемонстрировать
их качество и соответствие Стандартному руководству.

До представления на утверждение WSR Схемы маркировки и Тестового проекта будет поддерживаться связь с
квалифицированными консультантами WSR для того, чтобы использовать
данные конкурса(CIS).

4. Схема оценки

3.2.
Общие правила

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

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

Он
предназначен для оценки каждого этапа выполнения работ в соответствии с
распределением значений «весов» в Спецификации стандартов.

На
основе значений «весов» в Техническом описании, Схема оценки
устанавливаетпараметры для тестового проекта. В зависимости от навыков
(мастерства) и оценки их значимости, допустимо разработать более подробную
Схему оценки, которая будет использоваться в качестве руководства для тестового
проекта.

Кроме
того, первоначальный тестовый проект может быть основан на плане Схемы оценки.

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

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

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

Детализированная
и финальная Схемы оценки и тестовый проект должны быть одобрены всем Экспертным
Жюри до конкурса для предоставления независимого контроля качества. Исключением
являются компетенции, которые используют внешнего специалистадля разработки
Схемы оценки и тестового проекта.

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

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

3.3.
Критерии оценки

Основные
пункты (заголовки, разделы) Схемы оценки являются критериями оценки. Заголовки
разделов получаются совместно с тестовым проектом. В соревнованиях Критерии
оценки могут быть похожи на заголовки разделов в Стандартных спецификациях; в
других они могут быть совершенно другими. Существует, как правило, 5-9
критериев оценки. Соответствуют они заголовкам или нет, Схема оценки должна
отражать значения «весов» в Стандартных спецификациях.

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

Суммарная
форма оценки генерируется CIS и будет включать в себя список Критериев оценки.

Оценка,
по каждому из критериев будет рассчитана CIS. Оценки будут представлять собой
совокупную сумму оценки, данную в отношении каждого элемента оценки в рамках этих
Критериев оценки.

3.4.
Подкритерии

Каждый
Критерий оценки состоит из одного или нескольких подкритериев. Каждый подкритерий
— заголовок раздела в Форме оценки WorldSkills.

Каждая
Форма оценки (подкритерий) содержит информацию об определенном дне, в который
он будет отмечен.

Каждая
Форма оценки (подкритерий) содержит либо объективные или субъективные аспекты,
которые должны быть оценены.

Некоторые
подкритерии содержат в себе как объективные, так и субъективные аспекты, и в
этом случае существует Форма оценки для каждого из них.

3.5.
Аспекты

Каждый
аспект определяется детально, каждый элемент маркируется и оценивается
совместно с другими оценками или по инструкции, содержащей информацию о том,
как должны оцениваться аспекты. Аспекты оцениваются объективно или субъективно
и появляются в соответствующей Форме оценки.

Форма
оценок – это детальный список, в котором каждый аспект отмечается совместно с
оценкой (маркировкой), указывается ссылка на раздел навыков, как изложено в Стандартных
спецификациях.

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

3.6.
Judgement (Мнение экспертов)

Judgement-оценка осуществляется в соответствии с правилами WorldSkills.

Оценка
должна быть проведена с использованием:

·      критериев с мнением экспертов по каждому аспекту

·      с указанием следующего масштаба:

—    
0неприемлемо для коммерческого производства;

—    
1: приемлемо для коммерческого производства;

—    
2приемлемо, с элементами более высокого качества;

—    
3превосходно.

Judgement-оценка не является субъективной оценкой.

3.7.
Measurement(измерение)

Оценка
производится в соответствии с правилами WorldSkills. Measurement-оценка используется.

3.8.
Использование Judgement и Measurement

Окончательное
раскрытие объективной или Judgement-оценки будут согласованы, когда Схема оценки и
тестовый проект будут завершены. Приведенная ниже таблица носит
рекомендательный характер для разрабатываемого тестового проекта и Схемы
оценки.

Секция	Критерий	Оценка
		Judgement	Measure	Общий
A	Организация работы и управление			5
B	Общение и международные навыки			5
C	Проблемы, инновация, креативность			5
D	Анализ и проектирование программных решений			30
E	Разработка программных решений			40
F	Тестирование программных решений			10
G	Документирование программных решений			5
Всего		20% или меньше	80% или больше	100

3.9.
Окончание спецификации оценки навыков

Оценочные
группы будут сформированы в соответствии с Правилами соревнований.

Критерии
оценки, разработанные внешним писателем, четкие и лаконичные, онипоясняют, как
и почему присуждается каждая оценка.

Существует
три разных типа объективных критериев для оценки тестового проекта. Приведенная
ниже таблица описывает эти типы:

Тип	Пример	Максимальная оценка	Все верно	Не верно
Полная оценка или нулевая	Круговая диаграмма показывает в процентах	0,2	0,2	0
При уменьшении количества баллов используется скользящая шкала	В формате отчет указано, что за каждую ошибку вычитается по 0.1 балла.	0,5	0,5	0-0,4
Добавление баллов к 0 отметкам (используется прогрессивная шкала).	При правильном решении добавляется по 0, 1 балла.	1,0	1,0	0-0,9

3.10.
Процедуры оценки навыков

Каждый
эксперт выступает в качестве члена команды оценки тестового проекта.

Эксперты
будут разделены на команды оценки при максимально возможном равенстве в
количестве оценки критериев.

Состав
команд оценки будет определять Главный эксперт и Заместитель главного эксперта
с целью достижения баланса между новыми и опытными экспертами в каждой из
команд.

Эксперты
будут разделены по различным культурным группам по субъективным оценкам на
сколько это будет возможным.

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

Эксперты согласуют окончательную Схему оценки
иопределят, используя субъективные/ объективные оценки, стоит ли оценить проект
в 100% объективных баллов. Judgement-оценки не должны
превышать 20 %.

Тестовый проект

3.11.
Общие сведения

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

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

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

Тестовый
проект не будет использовать разделы, не входящие в WSSS,
указанные в Разделе 2.

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

Тестовый
проект не будет оценивать знания норм и правил WorldSkills.

3.12.
Структура тестового проекта

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

Общие
файлы данных могут бытьпредоставлены нарусском и английском языке и только
английские версии программного обеспечения.

Участникам
разрешен выход в интернет в зоне соревнования. Интернет будет доступен на обозначенных
компьютерах в пределах 15 минут на участника на сессию. Это время включается во
соревновательное время конкурса.

 В
течении соревновательного времени может быть объявлен “Overdrive” – неожиданное
независимое испытание на скорость. Привычным запросом в данной области
является, что чья-то работа может быть прервана по просьбе. В какой-то момент в
каждый из дней проведения конкурса участникам может быть поставлена
задача, которая должна быть решена в течение 20 минут. Это будет задача
визуального характера, которая будут привлекать зрителей к территории
соревнований. Задача должна быть одна, и иметь быстрое решение.

3.13.
Требования к тестовому дизайн проекту

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

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

В
тех случаях, когда работа длиться в течение нескольких соревновательных этапов
она будет сохранена для оценки в конце каждого из этапов. Например, проект
может потребовать разработки базы данных:

—
Определения таблиц, импорт данных, разработки форм и запросов и построения отчета.
Проект может содержать, определенные результаты работы, которые необходимо
предоставить в первом соревновательном этапе. В перерыве, результаты работы
будут помещены в резервные копии и оценены. Любая работа, выполняемая с
результатами после перерыва, не оценивается.

3.14.
Развитие тестового проекта

Тестовый проект должен быть подан в
соответствие с шаблоном, предоставленным WorldSkillsInternational (www.worldskills.org/expertcentre). Используйте шаблон Word для текстовых документов и DWG шаблон для рисунков.

1.1.3.
Кто разрабатывает тестовые проекты

Тестовые проекты разрабатываются разработчиком
в идеале с постоянным взаимодействием с организациями из отрасли. Определенными
Главным Экспертом, в идеале контактирующими с партнерами в промышленности. Заинтересованные
члены организации, для которой разрабатывается тестовый проект, также
консультируют разработчика.

Разработчик предоставляет следующее:

·      Разрабатывает детали сценария примера Тестового Проекта;

·      Обозначает и документирует ожидаемые характеристики разрабатываемой системы;

·      Предоставляет тестовые данные;

·      Предоставляет образцы решения;

·      Предоставляет критерии оценки в соответствии со спецификациями
Технического Описания и WSR CIS системы оценок.

Все зарегистрированные эксперты в соревновании
приглашаются для подачи заявки (“ExpressionofInterest”)
для номинации экспертов или группы экспертов на позицию команды разработчиков.
Все номинации должны быть отправлены по электронной почте техническому
директору WSR.

WSR проверит все номинации и выберет наиболее
подходящую.

Разработчик будет общаться только с главным
экспертомпо компетенции и не будет контактировать с «Группой Связи Проекта» (“ProjectLiaisonTeam”) и экспертами.

1.1.4.
Как и где разрабатываются тестовый проекты или модули

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

«Группа Связи Проекта» (PLT) будет формироваться,
по меньшей мере, за четыре месяца до начала соревнований. Эта команда будет
включать в себя главного эксперта, заместителя главного эксперта, и три других
эксперта, которые имеют опыт, по крайней мере, одного предыдущего национального
конкурса. Эти три эксперта будут отобраны командой управлениями квалификациями
(SMT), которая будет стремиться к тому, чтобы отобранные эксперты отражали
состав участников. Роль PLT будет состоять в том, чтобы оказывать помощь,команде
разработчиков отвечая на организационные вопросы, касающиеся проведения
Конкурса. В идеале команда разработчиковпредставит тестовый проект экспертам
лично или через электронные средства связи.

Каждый эксперт конкурса будет участвовать в
оценке тестового проекта в составе группы. SMT будет определять состав группы,
а также долю ответственности за оценки проектов для каждой команды. Главный
специалист-эксперт, заместитель главный специалист могут, но не обязаны
участвовать в оценке.

1.1.5.
Временные рамки разработки тестового проекта

Разработка проекта должно производиться в
соответствие со следующим графиком:

ВРЕМЯ	МЕРОПРИЯТИЕ
В течение двух месяцев после последнегоКонкурса	Каждый эксперт должен представить обзор тестового проекта этого конкурса, в том числе руководство по оценке
За двенадцать месяцев перед Конкурсом	Эксперты могут проявить заинтересованность в написании тестовых проектов
Восемь месяцев до начала Конкурса	Формируется команда PLT
Три месяца до начала Конкурса	Тестовый проект разработан и направлен главному эксперту
Два месяцев до начала Конкурса	Руководства по стилю и обзоры проекта распространяются для ознакомления конкурсантам через веб-сайт
Во время Конкурса	Тестовый проект показывается экспертам. Эксперты должны немедленно сообщить их участникам соревнованиям о тестовом проекте.

3.15.
Проверка тестового проекта

Тестовый проект проверяется экспертами на
конкурсе. Каждая команда оценки отвечает за проверку компонентов тестового
проекта, который они оценивают. Они оценивают тестовый проект по следующим
критериям:

·      образцы решений тестового проекта, предоставленные внешним
разработчиком, соответствуют установленным требованиям;

·      схемы оценки разработаны;

·      тестовый проект соответствует техническому описанию;

·      точный список необходимых файлов с даннымидля каждой сессии имеется в
наличии;

·      каждая команда оценки представит и объяснит, что требуется от проекта,
для каждой команды, включая критерии оценки.

3.16.
Отбор тестовых проектов

Тестовый проект будет предоставлен главномуэксперту
командой разработчиков, в идеале за три месяца до начала соревнований.

3.17.
Распространение тестового проекта

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

Тестовый проект не распространяется до
соревнований. Тестовый проект будет показан экспертам в первый подготовительной
день перед соревнованиями. На этом этапе эксперты должны связаться со своими
участниками соревнований и информировать их о тестовом проекте.

3.18.
Координация тестового проекта (подготовка к конкурсу)

Согласование тестового проекта будет
проводиться группами SMT и PLT, а также техническим директором WSR.

3.19.
Изменение тестового проекта на конкурсе.

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

3.20.
Материалы или спецификации производителя

Конкретные материалы и/или спецификации
производителя, необходимые участникам соревнований для выполнения тестового
проекта будут предоставлены организаторами соревнования и будут доступны на
сайте www.worldskillsrussia.orgрасположенной в экспертном центре.

4. Развитие квалификаций и общение

4.1.
Форум для обсуждения

До конкурса, все обсуждения, общение,
сотрудничество и принятия решений в отношении компетенции конкурса должны
проходить на специальном форуме (http://forum.worldskillsrussia.org). Обсуждения являются действительными только если они происходят
на форуме. Модератором этого форума будет главный эксперт (или эксперт,
назначенный главным экспертом). Обращайтесь к правилам соревнований для
получения информации о сроках обсуждения и требованиях развития конкурса.

4.2.
Информация для участников

Вся информация для зарегистрированных
участников доступна на сайте www.worldskillsrussia.org.

Эта информация включает:

·      Правила соревнований;

·      Технические описания;

·      Схемы оценок;

·      Тестовые проекты;

·      Список инфраструктур;

·      Документация о нормах безопасности;

·      Другая информация, связанная с проведением конкурса.

4.3.
Тестовые проекты и схемы оценок

Тестовые проекты будут доступны на сайтах
www.worldskillsrussia.org.

4.4.
Повседневное управление

Управление квалификациями во время конкурса
определяется планом управления квалификациями (SkillManagementPlan), который разрабатывается командой управления квалификациями во главе
с главным экспертом. Команда управления квалификациями состоит из президента
жюри, главного эксперта и заместителя главного эксперта. План управления квалификациями
разрабатывается в течение шести месяцев до начала соревнований и завершается во
время конкурса по соглашению экспертов. План управления квалификациями может
быть увиден на сайте экспертного центра www.worldskillsrussia.org.

Техника
безопасности

Применяется стандартная техника безопасности
при работе за компьютером

Инфраструктура

4.5.
Списокинфраструктуры

Список инфраструктуры содержит все
оборудование, материалы и средства, предоставляемые организаторами конкурса.
Список инфраструктуры доступен в разделе www.worldskillsrussia.org.
Список инфраструктуры определяет предметы и их количество, запрашиваемые
экспертами для очередного конкурса. Организатор конкурса будет постепенно
обновлять список инфраструктуры, конкретизируя количество, вид, марку и модель
объектов. Комплект поставки предметов инфраструктуры от организаторов показан в
отдельной колонке. Для каждого конкурса, эксперты должны пересмотреть и
обновить список инфраструктуры в рамках подготовки к следующему конкурсу.
Эксперты должны проинформировать технического директора об увеличении площади
или количества оборудования. Технический наблюдатель должен проверить список
инфраструктуры, которая была использована на каждом конкурсе. Список
инфраструктуры не включает в себя предметы,которые должны принести участники
или эксперты, а также предметы, которые участникам не разрешается приносить —
они указаны ниже.

4.6.
Материалы, оборудование и инструменты, предоставляемые
участниками

Не применимо.

4.7.
Материалы, оборудование и инструменты, предоставляемые
экспертами

Не применимо.

4.8.
Материалы, не допускаемые в зоне конкурса

·      Участники могут использовать защиту для ушей

·      Участники могут принести с собой свои клавиатуры, мышки и коврики для
мышек. Все принесенные клавиатуры, мышки и коврики должны быть предварительно
сданы на проверку технической команде. Запрещено использование Клавиатур и
мышек с подключением по беспроводным каналам. Запрещено наличие USB входов на клавиатуре. Устройства ввода не должны быть
программируемыми.

·      Участники могут слушать музыку. Наушники и музыка в виде файлов должна
быть предварительно сдана в техническую команду для проверки. Принесенная
музыка будет хранится на серверах для конкурсантов к которым они будут иметь
доступ.

·      Участники не должны приносить:

—    
Дополнительные программы

—    
Мобильные телефоны

—    
Портативные электронные устройства (планшеты, и т
п)

—    
Устройства для хранения информации (флэш-накопители,
диски, и т п)

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

·      Эксперты обладают правом запретить определенное оборудование в зоне
конкурса.

4.9.
План застройки конкурсного участка

Планы застройки предыдущих конкурсных участков
доступны на сайте www.worldskills.org/sitelayout.

Пример застройки конкурсного участка:

·      Дизайн
должен предусматривать возможность уединения для участника, а также
необходимость доступности для наблюдения экспертом. Должно быть легко заметить,
что участник хочет позвать эксперта. Высота перегородок между двумя участниками
должна быть не выше 120 см.

·      Дизайн должен максимизировать простоту обслуживания;

·      Если возможно экспертам должно быть доступно как минимум четыре
отдельных и закрытых комнаты для оценки достаточного размера (чтобы 5 экспертов
могли сесть в один ряд), чтобы разместить команду оценки. Каждая команда оценки
должна быть обеспечена ключом от комнаты;

·      Для главного эксперта и заместителя главного эксперта также должны быть
предоставлены закрытая комната, чтобы они могли руководить конкурсом;

·      Необходимо хорошо оборудованное помещение для опроса участников с
проектором, экраном, а также аудио системой с компьютером, аудио, видео, и
другими возможностями.

5. Участие посетителей и медиа

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

·      Экраны

·      Описания тестовых проектов

·      Объяснения того, чем занимаются участники

·      Профили участников

·      Карьерные возможности

·      Ежедневное объявление промежуточных результатов

6. Экологичность

·      Утилизация

·      Использование экологичных материалов

·      Использование завершенных тестовых проектов после конкурса

·      Использование электронных материалов вместо печатных

• Главная

• Каталог курсов

• Повышение квалификации

• WORLDSKILLS RUSSIA. Программные решения для бизнеса

WORLDSKILLS RUSSIA. Программные решения для бизнеса