é un movemento internacional que organiza concursos profesionais para mozos e mozas menores de 22 anos.
A final internacional celébrase cada dous anos. Este ano foi o lugar definitivo (a última final foi en 2017 en Abu Dhabi, a seguinte será en 2021 en Shanghai).
WorldSkills Championships son os maiores campionatos do mundo de habilidades profesionais. Comezaron con profesións de colares azuis, e nos últimos anos prestouse cada vez máis atención ás "profesións do futuro", incluídas as disciplinas informáticas, para as que se asignou un enorme grupo separado no campionato de Kazán.
No bloque de TI hai unha competencia (un “deporte” específico) chamada “Solucións de software de TI para empresas”.
En cada concurso, a listaxe permitida de ferramentas utilizadas é limitada. E se, por exemplo, para o "deseño da paisaxe" a lista de ferramentas posibles é limitada (por suposto, sen indicar un fabricante ou cor explícitos), entón na competencia "Solucións de software para empresas" a lista de tecnoloxías aceptadas que os participantes poden usar. está estrictamente limitado, indicando tecnoloxías específicas e plataformas específicas (.NET e Java cun conxunto específico de frameworks).
A posición de 1C neste tema é a seguinte: a tecnoloxía da información é un ámbito moi dinámico, as novas tecnoloxías e ferramentas de desenvolvemento están a aparecer constantemente no mundo. Dende o noso punto de vista, é correcto permitir que os especialistas utilicen as ferramentas coas que queren e están afeitos a traballar.
No outono de 2018, a dirección de WorldSkills escoitounos. Agora había que probar a metodoloxía para incorporar as novas tecnoloxías aos concursos. Non é sinxelo.
A plataforma 1C:Enterprise incluíuse na lista de infraestruturas do campionato de Kazán e organizouse unha plataforma experimental de solucións de software de TI para Sandbox empresarial.
Teña en conta que o idioma oficial do campionato é o inglés. Todos os materiais cos resultados das tarefas de resolución (códigos fonte, documentación que se acompaña, interfaces de software) tamén debían ser transmitidos nesta lingua. A pesar das dúbidas dalgunhas persoas (aínda!), podes escribir en inglés en 1C.
Neste sitio participaron 9 mozos de 8 países (Filipinas, Taiwán, Corea, Finlandia, Marrocos, Rusia, Casaquistán, Malaisia).
O xurado -un equipo de expertos- estivo encabezado por un experto de Filipinas, Joey Manansala.
Estiveron representados expertos de Finlandia, Emiratos Árabes Unidos, Costa Rica, Corea, Rusia e Taiwán.
Por separado, observamos que os participantes de Rusia (Pavkin Kirill, Sultanova Aigul) e Kazajistán (Vitovsky Ludwig) decidiron utilizar a plataforma 1C:Enterprise como parte da competición. O resto dos participantes utilizaron .NET para escritorio e Android Studio para o desenvolvemento móbil. É interesante que os participantes que escolleron 1C sexan moi novos (Kirill é un estudante nunha escola de Stavropol, este ano entrou no 11º curso, Aigul é un estudante universitario, Kazan, Tatarstan), mentres que os seus opoñentes eran moito máis experimentados ( por exemplo, un participante de Corea, gañador do campionato WorldSkills 2013 en Leipzig; todos teñen experiencia participando en WorldSkills e varios anos de experiencia profesional na industria).
Tendo en conta que durante a competición os participantes utilizaron diversas tecnoloxías modernas, tivemos a oportunidade de probar a plataforma 1C:Enterprise en verdadeiras condicións de combate, para comparar tanto a calidade das solucións obtidas coa súa axuda como a velocidade de desenvolvemento acadada co seu uso.
Por separado, sinalamos que no marco da plataforma especial IT Software Solutions for Business Sandbox, os participantes realizaron as mesmas tarefas que os participantes na principal plataforma IT Software Solutions for Business.
A tarefa en si é unha tarefa complexa para automatizar un determinado negocio; este ano o exemplo dun negocio foi a empresa ficticia KazanNeft.
Lenda
Kazan Oil é unha das maiores empresas petroleiras da República de Tartarstán, que opera como un actor do mercado nacional e unha marca recoñecida internacionalmente neste campo. A sede da empresa, especializada na exploración de campo, produción, produción, refino, transporte e venda e distribución de petróleo, produtos petrolíferos e gas natural, está situada en Kazan (Rusia).
Dado que a compañía está a implementar unha estratexia de rápida expansión e creación de novas oficinas en toda Rusia, a dirección da compañía decidiu introducir un novo software de automatización empresarial destinado a manter e xestionar determinadas operacións.
Condicións do campionato
Entregáronse tarefas aos participantes en forma de módulos (sesións) co requisito de realizalas nun tempo limitado. En total foron 7 módulos. Tres sesións para resolver nun escritorio: 2.5 horas cada unha. Tres sesións: desenvolvemento cliente-servidor, onde o cliente era unha aplicación móbil, e a comunicación entre o cliente e o servidor realizouse mediante WEB-API. Isto levou 3.5 horas. Última sesión: tarefas de enxeñería inversa do software existente, 2.5 horas. Como parte da enxeñaría inversa, os participantes debían, en función da información que se lles proporcionaba, deseñar a estrutura da base de datos da aplicación (construíndo un diagrama ER), analizar escenarios de uso do sistema (construíndo un diagrama de casos de uso) e tamén desenvolver e deseñar a interface da solución de software segundo os requisitos funcionais proporcionados.
As principais plataformas de desenvolvemento empregadas foron .NET (C#) e Java (incluíndo Android Studio para o desenvolvemento móbil). O SandBox experimental utilizou .NET, Java e 1C:Enterprise versión 8.3.13.
Ao final de cada sesión, os expertos avaliaron o resultado: un proxecto viable preparado que implementa as tarefas establecidas ao comezo da sesión.
A peculiaridade das tarefas é a súa "vitalidade": moitos requisitos e tempo limitado. A maioría dos problemas non son problemas especiais das Olimpiadas, senón que están moi próximos a problemas industriais reais: os especialistas enfróntanse a eles todos os días. Pero hai moitas tarefas, e o tempo é limitado. O participante deberá resolver o máximo número de problemas que suporán o maior beneficio para o negocio. Non é para nada un feito que unha tarefa complexa desde o punto de vista algorítmico teña máis peso que unha elemental. Por exemplo, crear un sistema de contabilidade funcional de tres táboas é máis importante para unha empresa que un fermoso formulario de informes con algoritmos complexos, que é completamente innecesario sen estas táboas.
Pedímoslle ao gañador do concurso, un participante de Rusia, Kirill Pavkin, que nos contara máis sobre cales eran as tarefas e como abordou a súa solución.
A continuación móstrase unha descrición da tarefa, a propia historia de Kirill sobre como resolveu a tarefa. Tamén pedimos a Vitaly Rybalka, un empregado de 1C e un dos expertos en solucións informáticas para empresas Sandbox, que comentase as solucións de Kirill.
Como parte da cesión, foi necesario automatizar as actividades de varios tipos de usuarios:
- Responsable da contabilidade do patrimonio da empresa
- Responsable das reparacións non programadas e do mantemento programado dos activos da empresa
- Xestores de compras de compoñentes e consumibles
- Divisións de exploración e produción de petróleo
- A alta dirección necesitaba informes analíticos
Sesión 1
Desde o punto de vista dos activos (por exemplo, un parque de vehículos), foi necesario implantar a súa contabilidade (establecemento de novos, edición dos actuais), busca rápida e varios tipos de filtros para mostrar información, desprazamento de activos entre as divisións da Compañía. e os propios grupos de activos. Manteña un historial de tales movementos e proporcione análise sobre eles no futuro. A contabilidade de activos implementouse principalmente para grupos de usuarios móbiles.
Cyril: Unha subtarefa interesante foi a implementación de botóns na lista de activos. Para solucionalo, utilizamos unha lista dinámica: escribimos unha solicitude arbitraria e, ao recibir datos no servidor, asignamos ligazóns de navegación ás imaxes da biblioteca de imaxes aos campos necesarios.
Por convención, as fotos pódense anexar a un recurso de dúas formas: tirar unha foto (multimedia) e seleccionar na galería (diálogo de selección de ficheiros).
Algunhas formas debían ser redeseñadas cando se xiraba a pantalla:
Ao cambiar os parámetros da pantalla, cambiamos a visibilidade dos grupos de botóns.
As tarefas entretidas pero sinxelas inclúen filtros nunha lista dinámica, busca en dous campos (número e nome) e xeración dun número de serie de activos.
Comentario de expertos: dende o punto de vista da solución na plataforma 1C:Enterprise, a tarefa é bastante clara. Ademais da creación real da aplicación móbil, foi necesario encargarse de transferir os datos do "servidor" DBMS (MS SQL no escritorio) á aplicación móbil e viceversa. Para este fin, utilizáronse os mecanismos de fontes de datos externas e servizos http na "aplicación proxy" de escritorio. Para a propia plataforma móbil, mostrar imaxes nunha lista dinámica presentou unha maior complexidade.
Sesión 2
Foi necesario establecer a xestión de reparacións dos activos da Compañía. Como parte desta tarefa, foi necesario manter unha lista de solicitudes de reparación (por departamentos e grupos), ter en conta as prioridades para a urxencia das reparacións, planificar un calendario de reparacións de acordo coas prioridades, ordenar os compoñentes necesarios e tomar en conta os que xa están dispoñibles. Unha subtarefa interesante foi que algúns compoñentes tiñan data de caducidade; se xa se pediu unha peza para un determinado activo e o seu prazo non expirou, para este activo non hai que comprar de novo a mesma peza. A interface de reparación foi desenvolvida para o compoñente de escritorio do software da empresa.
Tamén foi necesario crear un formulario de autorización non trivial para dúas funcións: a persoa responsable e o responsable do servizo. A peculiaridade é que despois da autorización debes seleccionar automaticamente un dos roles.
A continuación preséntase o formulario de lista a disposición da persoa responsable:
Cyril: aquí só se pode resaltar o resaltado das solicitudes de servizo pendentes. Resolveuse mediante formato condicional nunha lista dinámica.
Premendo no botón da parte inferior da pantalla, o usuario pode ir ao seguinte formulario:
Non hai nada complicado desde o punto de vista 1C nesta forma.
O formulario dispoñible para o responsable do servizo é o seguinte:
Este formulario está ordenado por prioridade e data de solicitude. Premendo no botón de abaixo, o usuario pode ir ao formulario da solicitude seleccionada:
Ademais de infalible, este formulario suxeriu implementar unha lista de pezas de reposición para reparacións. A subtarefa é interesante porque as pezas teñen data de caducidade. Isto significa que se xa se produciu unha emerxencia con este activo e se encargou unha parte para el, cuxo período de validez non expirou, pódese reutilizar. Isto debería ser mostrado ao usuario.
Comentario de expertos: aquí o propio Kirill puxo correctamente os acentos. Desde o punto de vista da implementación na plataforma 1C:Enterprise, non hai nada extremadamente complexo. Requiriuse unha análise minuciosa das condicións de contabilización e utilización dos recambios e unha execución competente do conxunto da tarefa. Ademais, foi necesario rexistrar adecuadamente as solicitudes de servizo. A principal dificultade foi só a presión do tempo de 2.5 horas.
Ademais, como no desenvolvemento móbil, o participante tiña que obter de forma competente os datos dun DBMS externo (MS SQL).
Sesión 3
Para o mantemento (mantemento) propúxose implantar un servizo de planificación a longo prazo. Unha característica interesante aquí foi a esixencia de crear un calendario de mantemento dos activos segundo o calendario, por exemplo, cada dos meses o día 3. Así mesmo, segundo algún indicador cuantitativo, por exemplo, segundo o odómetro dun coche (cambio de aceite cada 5000 km, substitución de pneumáticos cada 20000 km). O xestor de mantemento debería ter recibido unha aplicación móbil conveniente que mostra de forma dinámica unha lista de mantemento vencido, actual e completado durante un período especificado. Ademais, cada tipo de mantemento debía pintarse de cor segundo unhas normas especialmente acordadas. A aplicación móbil debía garantir a creación de novos calendarios de mantemento e a marcación dos xa realizados directamente nos talleres coa pronta actualización desta información no servidor.
Cyril: Hai dous tipos de reparación: baseada no tempo e baseada en execución. Permítese a variabilidade dentro de cada un. Por exemplo, segundo o plan, as reparacións deberían producirse todos os venres, día 13 do mes ou cada 20,000 quilómetros. Unha tarefa considérase rematada se hai unha marca de verificación á dereita da mesma.
Forneceuse unha condición para clasificar as tarefas na lista. Ademais, cada liña debe ser resaltada en cor dependendo das condicións.
Premendo no botón de abaixo, pode crear un novo plan de servizos:
Os campos obrigatorios móstranse dependendo do tipo de gráfico seleccionado. Se seleccionamos un horario semanal, mostraranse dous campos: o número da semana e o día da semana. Por exemplo, os martes cada 3 semanas.
Comentario de expertos: como no desenvolvemento móbil anterior na plataforma 1C:Enterprise, aquí a tarefa divídese globalmente en 2 compoñentes: comunicación co "servidor" a través da web-api e visualización competente dunha lista dinámica con deseño condicional e filtrado (selección) de datos. Ademais, foi interesante implementar o requisito de contabilizar as reparacións tanto por período como por indicador cuantitativo.
Sesión 4
Para compoñentes e consumibles, foi necesario ter en conta as existencias, planificar gastos e futuras compras. Ademais, aquí apareceu a contabilidade por lotes, pero non para todos os bens. Todo isto tiña que ser xestionado dentro de múltiples almacéns, incluíndo a recepción, o gasto e o movemento. Segundo os termos da tarefa, era necesario garantir o control dos saldos e evitar conflitos ao traballar coas existencias actuais. Os xestores de compras traballan na versión de escritorio do software.
O formulario principal móstrase a continuación:
Cyril: Ademais de ordenar a partir da condición, propúxose darlle ao usuario a posibilidade de ordenar aleatoriamente. En 1C nin sequera tes que pensar niso. O campo coa cantidade de pezas debe resaltarse en verde para as facturas.
Nesta sesión pedíronlles que controlasen a mercadoría restante nos almacéns. Polo tanto, a mensaxe correspondente debería aparecer cando intente eliminar a factura. Aquí lembramos o exame de especialista en plataformas. A forma da factura é a seguinte:
Cada parte ten unha característica que determina se debe asignarse a un lote específico. Para estes recambios, é imprescindible indicar o número de lote en todos os documentos. Esta é unha medida adicional ao controlar os residuos de pezas. Tamén se poden mover entre almacéns:
O formulario difire do anterior só en que, en lugar do cliente, cómpre indicar o almacén desde o que se realizará a entrega. A lista de selección para o lote compílase automaticamente despois de seleccionar a peza. O usuario pode xerar un informe sobre saldos de recambios:
Aquí podemos ver as mercadorías restantes no almacén seleccionado. As caixas de verificación situadas á dereita do almacén permítenche configurar o filtrado e a clasificación. A lista non ten unha división explícita por sorteo para aquelas partes para as que se requira. Os saldos de cada número de lote da peza de recambio seleccionada pódense ver mediante a ligazón de navegación da dereita.
Comentario de expertos: nesta sesión (módulo) apareceu a contabilidade por lotes por primeira vez. Os participantes debían contabilizar os consumibles e os bens non só por si mesmos, senón tamén por lote. En xeral, a tarefa é perfecta para a plataforma 1C:Enterprise, pero todo tivo que ser desenvolvido desde cero e completado en 2.5 horas.
Sesión 5
Na quinta sesión, asignáronnos a funcionalidade de xestión de pozos. Para os grupos de exploración, foi necesario crear unha aplicación móbil que contabilizase os pozos de produción de petróleo ou gas. Aquí foi necesario recibir unha lista dos pozos actuais do servidor e mostrar o pozo seleccionado graficamente por capas (solo, area, pedra, aceite), tendo en conta as profundidades de cada capa. Ademais, a aplicación tiña que permitir actualizar a información sobre o pozo e engadir novos pozos. Para esta aplicación, o cliente establece condicións de funcionamento especiais nos modos fóra de liña e en liña (control da comunicación co servidor): comproba a comunicación co servidor cada 5 segundos e cambia a funcionalidade da aplicación dependendo da dispoñibilidade do servidor.
Cyril: Cando selecciona un pozo, móstrase un gráfico de barras, que destaca as capas ata os depósitos de petróleo ou gas. Para cada capa, gárdanse o seu nome, cor e intervalo de aparición. Debido ás características de deseño, os diagramas integrados na plataforma non axudan, pero o documento da folla de cálculo fai fronte á tarefa perfectamente. Os pozos pódense crear e modificar:
Ademais de múltiples proteccións infalibles, non había nada interesante neste formulario.
A continuación, suxeriuse controlar a conexión co servidor. Tentamos conectarnos cada 5 segundos. Se non funciona, limitamos a funcionalidade da aplicación e mostramos unha mensaxe.
Comentario de expertos: A tarefa desta sesión é interesante principalmente polas súas capacidades gráficas. Os participantes que usaron a plataforma 1C:Enterprise resolvírono de dúas maneiras diferentes: uns mediante un mecanismo de diagramas, outros mediante un documento de folla de cálculo. Cada método ten os seus pros e contras. Como parte da decisión no campionato de WorldSkills, o tempo foi clave (lembra de novo o límite de tempo). Unha tarefa interesante aparte é facer ping ao servidor cada 5 segundos e cambiar o comportamento da aplicación móbil dependendo da dispoñibilidade ou indisponibilidade do servidor.
Sesión 6
Propúxose crear un espazo de traballo para a alta dirección: Panel de control. Nunha pantalla foi necesario mostrar os indicadores xerais de rendemento da empresa durante un período determinado en forma gráfica e tabular. O formulario principal é o informe de custos:
Ademais do Dashboard, foi necesario implementar a distribución de pezas de reposición para a reparación de activos mediante métodos de amortización FIFO/LIFO/“Cheapest goes first”.
Durante a distribución, tívose en conta a contabilidade por lotes, utilizouse o control de saldos e a protección contra accións de usuarios non autorizadas ("protección tola").
Cyril: Para resolver, utilizáronse táboas de valores con xeración de columnas por software, xa que pode haber un número arbitrario delas:
- A primeira táboa é responsable dos custos totais dos departamentos por mes. As divisións máis rendibles e máis rendibles resáltanse en vermello e verde, respectivamente.
- A segunda táboa mostra as pezas máis caras e de uso máis frecuente para cada mes. Se hai varias partes que cumpren os criterios, deberían mostrarse nunha cela, separadas por comas.
- Os activos máis caros (en termos de custos de repostos) móstranse na primeira fila da terceira táboa. A segunda liña mostra a división á que pertence o activo anterior. Se hai dous activos máis caros cos mesmos custos, deberían mostrarse na mesma cela, separados por comas.
Os diagramas mostráronse mediante os mecanismos integrados na plataforma e cubríronse mediante programación mediante consultas.
Tamén se propuxo implementar o apoio ao plurilingüismo. O programa carga ficheiros XML coa localización dos elementos da interface, e o formulario debe ser redeseñado ao seleccionar un idioma na lista despregable.
Cando fai clic no botón da esquina inferior esquerda da pantalla, ábrese o formulario de xestión de inventario:
Neste formulario, finalmente comezamos a gastar pezas en reparacións. Aquí atopamos primeiro as pezas que necesitaremos para reparar o activo. En función dos campos seleccionados e do método de distribución (FIFO, LIFO ou prezo mínimo), móstranse as coincidencias atopadas ou unha mensaxe se non hai coincidencias. Despois podes marcar as pezas como destinadas a reparar ese activo. O control do saldo é relevante para a sesión actual. Se xa temos datos asignados, xa non se poden atopar.
Comentario de expertos: sesión moi interesante. Aproveita ao máximo as capacidades da plataforma 1C:Enterprise: aquí hai un traballo competente con táboas virtuais de rexistros de acumulación e un traballo programático con elementos de formulario (en primeiro lugar - táboas, segundo - títulos) e diagramas. E incluso LIFO/FIFO ao analizar o inventario, a análise de beneficios/perdas, etc.
Sesión 7
Ao final da tarefa (sesión 7), o cliente proporcionou software (ficheiro exe) para as actividades do proxecto e un pequeno vídeo sobre o traballo con el. Foi necesario realizar enxeñaría inversa e, a partir desta, crear 2 diagramas: un diagrama de casos de uso e un diagrama entidade-relación. Ademais, presentáronse algúns requisitos para crear software no futuro: foi necesario crear un deseño de interface segundo estes requisitos.
Segundo as condicións do concurso, só se requiría MS Visio para crear diagramas.
Comentario de expertos: nesta sesión practicamente non se utilizaron as capacidades da plataforma 1C:Enterprise. Creáronse diagramas para as condicións da competición en MS Visio. Pero un prototipo da interface podería crearse nunha base de información 1C baleira.
Notas xerais
Ao comezo de cada sesión, propúxose importar datos mediante un script SQL. Esta foi a principal desvantaxe de usar 1C en comparación co C#, xa que pasamos polo menos media hora destilando datos en fontes de datos externas, creando as nosas propias táboas e movendo filas de fontes externas ás nosas táboas. O resto só necesitaba facer clic no botón Executar en Microsoft SQL Studio.
Por razóns obvias, almacenar datos nun dispositivo móbil non é unha boa idea. Polo tanto, durante as sesións móbiles creamos unha base de servidores. Almacenaban datos alí e proporcionaban acceso a eles mediante servizos http.
Comentario de expertos: o equilibrio 1C/non-1C é interesante aquí, mentres que os programadores de 1C:Enterprise pasaron moito tempo conectándose a un DBMS externo (Kirill mencionou isto por separado arriba), os desenvolvedores de C#/Java (Android Studio para o desenvolvemento móbil) pasaron tempo noutras áreas. interfaces, escribindo máis código. Polo tanto, os resultados de cada sesión foron imprevisibles e sumamente interesantes para todos os expertos. E esta intriga mantívose ata o final: basta con mirar a táboa final de gañadores coa distribución de puntos.
Kirill rematou a historia :)
En conclusión, hai que lembrar que o intérprete non necesitaba "só programar a tarefa segundo as especificacións técnicas": tiña que analizar a tarefa, seleccionar bloques para a implementación de subtarefas, deseñalos e decidir o que sería exactamente. capaz de implementar a partir diso no tempo extremadamente curto previsto. Os 4 días tiven que actuar baixo unha forte presión de tempo, moitas veces comezando cada sesión posterior desde cero. Incluso un especialista adulto con moitos anos de experiencia na industria terá grandes dificultades para completar a tarefa asignada para a sesión 100% dentro do tempo asignado.
Mención especial merece o sistema de avaliación adoptado.
Para cada sesión, os autores das tarefas desenvolven un complexo sistema de criterios, que inclúe a comprobación da funcionalidade, o correcto funcionamento, os requisitos para a interface da aplicación e mesmo seguindo unha guía de estilo especialmente facilitada aos participantes pola empresa para a que están a desenvolver as súas solucións.
Os criterios de avaliación están moi finamente granulados: o custo total da tarefa da sesión é de decenas de puntos, o cumprimento dalgún criterio pode engadir décimas de punto ao participante. Con iso conséguese un nivel extremadamente alto e obxectivo de avaliación dos resultados de cada participante na competición.
Descubrimentos
Os resultados finais foron impresionantes.
Nunha dura loita gañou o ruso Kirill Pavkin, quen utilizou a plataforma 1C:Enterprise. Kirill ten 17 anos, é de Stavropol.
Literalmente décimas de punto separaban ao gañador dos seus perseguidores. O segundo lugar ocupou un participante de Taiwán. A táboa xeral dos seis primeiros resultados é o seguinte:
Por suposto, Kirill gañou grazas ao seu talento, coñecementos e habilidades.
Non obstante, observamos que os tres participantes que utilizaron a plataforma 1C:Enterprise como ferramenta foron incluídos entre os cinco primeiros, o que é unha confirmación incondicional do nivel mundial da tecnoloxía 1C:Enterprise.
Tras os resultados do concurso, os gañadores foron premiados no centro de medios KazanExpo; os mozos recibiron medallas de ouro puro (segundo o seu lugar) e premios en metálico. Os rapaces tamén recibiron certificados que lles permiten realizar prácticas en 1C.
Fonte: www.habr.com