és un moviment internacional que organitza concursos professionals per a joves menors de 22 anys.
La final internacional se celebra cada dos anys. Aquest any va ser el lloc definitiu (l'última final va ser el 2017 a Abu Dhabi, la següent serà el 2021 a Xangai).
WorldSkills Championships són els campionats d'habilitats professionals més grans del món. Van començar amb professions de coll blau, i en els darrers anys s'ha prestat cada cop més atenció a les "professions del futur", incloses les disciplines de TI, per a les quals es va assignar un gran clúster separat al campionat de Kazan.
Al bloc informàtic hi ha una competència (un "esport") anomenada "Solucions de programari informàtic per a empreses".
En cada concurs, la llista permesa d'eines utilitzades és limitada. I si, per exemple, per al "disseny del paisatge" la llista de possibles eines és limitada (per descomptat, sense indicar un fabricant o un color explícit), aleshores a la competència "Solucions de programari per a empreses" la llista de tecnologies acceptades que els participants poden utilitzar està estrictament limitat, indicant tecnologies específiques i plataformes específiques (.NET i Java amb un conjunt específic de frameworks).
La posició d'1C sobre aquest tema és la següent: les tecnologies de la informació són un àmbit molt dinàmic, les noves tecnologies i les eines de desenvolupament estan apareixent constantment al món. Des del nostre punt de vista, és correcte permetre als especialistes utilitzar les eines amb les quals volen i estan acostumats a treballar.
A la tardor del 2018, la direcció de WorldSkills ens va escoltar. Ara calia provar la metodologia per incorporar les noves tecnologies als concursos. No és senzill.
La plataforma 1C:Enterprise es va incloure a la llista d'infraestructures del campionat de Kazan i es va organitzar una plataforma experimental de solucions de programari informàtic per a Sandbox empresarial.
Tingueu en compte que l'idioma oficial del campionat és l'anglès. Tots els materials amb els resultats de les tasques de resolució (codis font, documentació adjunta, interfícies de programari) també s'havien de transmetre en aquest idioma. Malgrat els dubtes d'algunes persones (encara!), pots escriure en anglès en 1C.
9 nois joves de 8 països (Filipines, Taiwan, Corea, Finlàndia, Marroc, Rússia, Kazakhstan, Malàisia) van participar en la competició en aquest lloc.
El jurat, un equip d'experts, estava encapçalat per un expert de les Filipines, Joey Manansala.
Van estar representats experts de Finlàndia, els Emirats Àrabs Units, Costa Rica, Corea, Rússia i Taiwan.
Per separat, observem que els participants de Rússia (Pavkin Kirill, Sultanova Aigul) i Kazakhstan (Vitovsky Ludwig) van decidir utilitzar la plataforma 1C:Enterprise com a part del concurs. La resta de participants van utilitzar .NET per a l'escriptori i Android Studio per al desenvolupament mòbil. És interessant que els participants que van triar 1C són molt joves (Kirill és un estudiant d'una escola de Stavropol, aquest any va entrar a l'11è grau, Aigul és un estudiant universitari, Kazan, Tatarstan), mentre que els seus oponents eren molt més experimentats ( per exemple, un participant de Corea, guanyador del campionat de WorldSkills 2013 a Leipzig; tots tenen experiència participant a WorldSkills i diversos anys d'experiència professional en la indústria).
Tenint en compte que durant la competició els participants van utilitzar diverses tecnologies modernes, vam tenir l'oportunitat de provar la plataforma 1C:Enterprise en condicions realment de combat, per comparar tant la qualitat de les solucions obtingudes amb la seva ajuda com la velocitat de desenvolupament aconseguida amb el seu ús.
Per separat, destaquem que en el marc de la plataforma especial IT Software Solutions for Business Sandbox, els participants van realitzar les mateixes tasques que els participants a la principal plataforma IT Software Solutions for Business.
La tasca en si és una tasca complexa per automatitzar un determinat negoci; aquest any l'exemple d'un negoci va ser l'empresa fictícia KazanNeft.
The Legend
Kazan Oil és una de les empreses petrolieres més grans de la República de Tatarstan, que opera com a actor del mercat nacional i una marca reconeguda internacionalment en aquest camp. La seu central de l'empresa, especialitzada en l'exploració de camp, producció, producció, refinació, transport i venda i distribució de petroli, productes derivats del petroli i gas natural, es troba a Kazan (Rússia).
Atès que l'empresa està implementant una estratègia d'expansió ràpida i creació de noves oficines a tot Rússia, la direcció de l'empresa va decidir introduir un nou programari d'automatització empresarial destinat al manteniment i gestió de determinades operacions.
Condicions del campionat
Les tasques es van lliurar als participants en forma de mòduls (sessions) amb el requisit de completar-les en un temps limitat. Hi havia 7 mòduls en total. Tres sessions per resoldre en un escriptori: 2.5 hores cadascuna. Tres sessions: desenvolupament client-servidor, on el client era una aplicació mòbil, i la comunicació entre el client i el servidor es va dur a terme mitjançant WEB-API. Això va trigar 3.5 hores. Última sessió: tasques d'enginyeria inversa del programari existent, 2.5 hores. Com a part de l'enginyeria inversa, els participants havien de dissenyar, a partir de la informació que se'ls havia proporcionat, l'estructura de la base de dades de l'aplicació (construint un diagrama ER), analitzar escenaris per utilitzar el sistema (construint un diagrama de casos d'ús) i també desenvolupar i dissenyar la interfície de la solució de programari segons els requisits funcionals proporcionats.
Les principals plataformes de desenvolupament utilitzades van ser .NET (C#) i Java (incloent Android Studio per al desenvolupament mòbil). El SandBox experimental utilitzava .NET, Java i 1C:Enterprise versió 8.3.13.
Al final de cada sessió, els experts van avaluar el resultat: un projecte viable ja fet que implementa les tasques establertes a l'inici de la sessió.
La peculiaritat de les tasques és la seva "vitalitat": molts requisits i temps limitat. La majoria dels problemes no són problemes especials de les Olimpíades, sinó que s'acosten molt a problemes industrials reals: els especialistes s'hi enfronten cada dia. Però hi ha moltes tasques i el temps és limitat. El participant haurà de resoldre el màxim nombre de problemes que tindran el major benefici per al negoci. No és gens cert que una tasca complexa des d'un punt de vista algorítmic tingui més pes que una elemental. Per exemple, crear un sistema de comptabilitat funcional de tres taules és més important per a una empresa que un bonic formulari d'informes amb algorismes complexos, que és completament innecessari sense aquestes taules.
Vam demanar al guanyador del concurs, un participant de Rússia, Kirill Pavkin, que ens expliqui més sobre quines eren les tasques i com va abordar la seva solució.
A continuació es mostra una descripció de la tasca, la pròpia història de Kirill sobre com va resoldre la tasca. També vam demanar a Vitaly Rybalka, un empleat d'1C i un dels experts en solucions informàtiques per a empreses Sandbox, que comentés les solucions de Kirill.
Com a part de l'encàrrec, va ser necessari automatitzar les activitats de diversos tipus d'usuaris:
- Responsable de la comptabilitat del patrimoni de l'empresa
- Responsable de reparacions no programades i manteniment programat dels actius de l'empresa
- Gestors de compres de components i consumibles
- Divisions d'exploració i producció de petroli
- L'alta direcció necessitava informes analítics
Sessió 1
Des del punt de vista dels actius (per exemple, una flota de vehicles), calia implantar-ne la comptabilitat (establir-ne de nous, editar-ne els actuals), la cerca ràpida i diversos tipus de filtres per a la visualització d'informació, el trasllat d'actius entre les divisions de l'empresa. i els propis grups d'actius. Manteniu un historial d'aquests moviments i proporcioneu-ne analítiques en el futur. La comptabilitat d'actius es va implementar principalment per a grups d'usuaris mòbils.
Cyril: Una subtasca interessant va ser la implementació de botons a la llista d'actius. Per solucionar-ho, hem utilitzat una llista dinàmica: escrivim una sol·licitud arbitrària i, quan rebem dades al servidor, assignem enllaços de navegació a les imatges de la biblioteca d'imatges als camps requerits.
Per convenció, les fotos es poden adjuntar a un actiu de dues maneres: fer una foto (multimèdia) i seleccionar-la a la galeria (diàleg de selecció de fitxers).
Algunes formes s'havien de tornar a dibuixar quan es girava la pantalla:
Quan canviem els paràmetres de la pantalla, canviem la visibilitat dels grups de botons.
Les tasques entretingudes però senzilles inclouen filtres en una llista dinàmica, cerca en dos camps (número i nom) i generació d'un número de sèrie d'actius.
Comentari d’experts: des del punt de vista de la solució a la plataforma 1C:Enterprise, la tasca és força clara. A més de la creació real de l'aplicació mòbil, calia encarregar-se de la transferència de dades des del "servidor" de DBMS (MS SQL a l'escriptori) a l'aplicació mòbil i viceversa. Amb aquesta finalitat, es van utilitzar els mecanismes de fonts de dades externes i serveis http a l'"aplicació proxy" d'escriptori. Per a la pròpia plataforma mòbil, mostrar imatges en una llista dinàmica presentava una complexitat més gran.
Sessió 2
Calia establir la gestió de reparacions dels actius de l'empresa. Com a part d'aquesta tasca, va ser necessari mantenir una llista de sol·licituds de reparació (per departaments i grups), tenir en compte les prioritats per a la urgència de les reparacions, planificar un calendari de reparacions d'acord amb les prioritats, ordenar els components necessaris i prendre tenint en compte les existents. Una subtasca interessant va ser que alguns components tenien una data de caducitat; si ja s'ha encarregat una peça per a un determinat actiu i el seu termini no ha expirat, per a aquest actiu no cal tornar a comprar la mateixa peça. La interfície de reparació es va desenvolupar per al component d'escriptori del programari de l'empresa.
També calia crear un formulari d'autorització no trivial per a dues funcions: la persona responsable i el responsable del servei. La particularitat és que després de l'autorització cal seleccionar automàticament un dels rols.
A continuació es presenta el formulari de llista disponible per a la persona responsable:
Cyril: aquí només es pot destacar el ressaltat de les sol·licituds de servei pendents. Solucionat mitjançant format condicional en una llista dinàmica.
En fer clic al botó de la part inferior de la pantalla, l'usuari pot anar al següent formulari:
Des del punt de vista de l'1C, no hi ha res complicat en aquesta forma.
El formulari disponible per al responsable del servei és el següent:
Aquest formulari s'ordena per prioritat i data de sol·licitud. Fent clic al botó següent, l'usuari pot anar al formulari de la sol·licitud seleccionada:
A més d'infal·libles, aquest formulari va suggerir implementar una llista de peces de recanvi per a reparacions. La subtasca és interessant perquè les peces tenen data de caducitat. Això vol dir que si ja s'ha produït una emergència amb aquest actiu i se n'ha demanat una part, el període de validesa de la qual no ha expirat, es pot reutilitzar. Això s'ha de mostrar a l'usuari.
Comentari d’experts: aquí el mateix Kirill va col·locar correctament els accents. Des del punt de vista de la implementació a la plataforma 1C:Enterprise, no hi ha res extremadament complicat. Es va requerir una anàlisi acurada de les condicions de comptabilitat i ús de les peces de recanvi i una execució competent de la tasca en el seu conjunt. A més, calia registrar correctament les peticions de servei. La principal dificultat era només la pressió del temps de 2.5 hores.
A més, com en el desenvolupament mòbil, el participant havia d'obtenir dades de manera competent d'un SGBD extern (MS SQL).
Sessió 3
Per al manteniment (manteniment) es va proposar implantar un servei de planificació a llarg termini. Una característica interessant aquí va ser el requisit de crear un programa de manteniment dels actius segons el calendari, per exemple, cada dos mesos el dia 3. De la mateixa manera, segons algun indicador quantitatiu, per exemple, segons l'odòmetre d'un cotxe (canvi d'oli cada 5000 km, canvi de pneumàtics cada 20000 km). El gestor de manteniment hauria d'haver rebut una aplicació mòbil convenient que mostri dinàmicament una llista de manteniment vençut, actual i completat durant un període determinat. A més, cada tipus de manteniment s'havia de pintar de color segons unes normes especialment acordades. L'aplicació mòbil havia d'assegurar la creació de nous horaris de manteniment i el marcatge dels ja realitzats directament als tallers amb una ràpida actualització d'aquesta informació al servidor.
Cyril: Hi ha dos tipus de reparacions: basades en el temps i basades en l'execució. Es permet la variabilitat dins de cadascun. Per exemple, segons el pla, les reparacions haurien de fer-se cada divendres, dia 13 del mes o cada 20,000 quilòmetres. Una tasca es considera completada si hi ha una marca de verificació a la dreta.
Es va proporcionar una condició per ordenar les tasques a la llista. A més, cada línia s'ha de ressaltar en color segons les condicions.
Si feu clic al botó següent, podeu crear un nou pla de servei:
Els camps obligatoris es mostren en funció del tipus de gràfic seleccionat. Si hem seleccionat un horari setmanal, ens mostraran dos camps: el número de la setmana i el dia de la setmana. Per exemple, els dimarts cada 3 setmanes.
Comentari d’experts: com en el desenvolupament mòbil anterior a la plataforma 1C:Enterprise, aquí la tasca es divideix globalment en 2 components: comunicació amb el "servidor" a través de l'api web i visualització competent d'una llista dinàmica amb disseny condicional i filtrat (selecció) de dades. A més, va ser interessant implementar el requisit de comptabilitzar les reparacions tant per període com per indicador quantitatiu.
Sessió 4
Pel que fa als components i consumibles, calia tenir en compte les existències, planificar despeses i futures compres. A més, aquí va aparèixer la comptabilitat per lots, però no per a tots els béns. Tot això s'havia de gestionar dins de múltiples magatzems, incloent la recepció, les despeses i el moviment. Segons els termes de la tasca, calia garantir el control dels saldos i evitar conflictes quan es treballava amb les existències actuals. Els gestors de compres treballen a la versió d'escriptori del programari.
El formulari principal es mostra a continuació:
Cyril: A més d'ordenar a partir de la condició, es va proposar donar a l'usuari la possibilitat d'ordenar aleatòriament. A 1C no cal ni pensar-hi. El camp amb la quantitat de peces s'ha de ressaltar en verd per a les factures.
En aquesta sessió se'ls va demanar que controlessin la resta de mercaderies als magatzems. Per tant, s'hauria de mostrar el missatge corresponent quan intenteu eliminar la factura. Aquí recordem l'examen d'especialista en plataforma. La forma de la factura és la següent:
Cada part té una característica que determina si s'ha d'assignar a un lot concret. Per a aquestes peces de recanvi, és imprescindible indicar el número de lot a tots els documents. Aquesta és una mesura addicional quan es controlen els residus de peces. També es poden traslladar entre magatzems:
El formulari es diferencia de l'anterior només en què, en comptes del client, cal indicar el magatzem des del qual es farà el lliurament. La llista de selecció per al lot es compila automàticament després de seleccionar la peça. L'usuari pot generar un informe sobre els saldos de recanvis:
Aquí podem veure la resta de mercaderies al magatzem seleccionat. Les caselles de selecció a la dreta del magatzem us permeten configurar el filtratge i l'ordenació. La llista no té una divisió explícita per sorteig per a aquelles parts per a les quals es requereix. Els saldos de cada número de lot de la peça de recanvi seleccionada es poden veure mitjançant l'enllaç de navegació de la dreta.
Comentari d’experts: en aquesta sessió (mòdul) la comptabilitat per lots va aparèixer per primera vegada. Els participants havien de comptabilitzar els consumibles i els béns no només per ells mateixos, sinó també per lots. En general, la tasca és perfecta per a la plataforma 1C:Enterprise, però tot s'havia de desenvolupar des de zero i completar-lo en 2.5 hores.
Sessió 5
A la cinquena sessió, ens van assignar la funcionalitat de gestió de pous. Per als grups d'exploració, calia crear una aplicació mòbil que tingués en compte els pous de producció de petroli o gas. Aquí calia rebre una llista dels pous actuals del servidor i mostrar el pou seleccionat gràficament per capes (sòl, sorra, pedra, oli), tenint en compte les profunditats de cada capa. A més, l'aplicació havia de permetre actualitzar la informació sobre el pou i afegir nous pous. Per a aquesta aplicació, el client estableix condicions de funcionament especials en els modes fora de línia i en línia (control de la comunicació amb el servidor): comprovant la comunicació amb el servidor cada 5 segons i canviant la funcionalitat de l'aplicació en funció de la disponibilitat del servidor.
Cyril: Quan seleccioneu un pou, es mostra un gràfic de barres, que destaca les capes fins als dipòsits de petroli o gas. Per a cada capa, s'emmagatzemen el seu nom, color i rang d'ocurrències. A causa de les característiques de disseny, els diagrames integrats a la plataforma no ajuden, però el document del full de càlcul s'adapta perfectament a la tasca. Els pous es poden crear i modificar:
A part de la protecció múltiple infalible, no hi havia res interessant en aquest formulari.
A continuació, es va suggerir controlar la connexió al servidor. Intentem connectar-nos cada 5 segons. Si no funciona, limitem la funcionalitat de l'aplicació i mostrem un missatge.
Comentari d’experts: La tasca d'aquesta sessió és interessant sobretot per les seves capacitats gràfiques. Els participants que utilitzaven la plataforma 1C:Enterprise ho van resoldre de dues maneres diferents: algunes utilitzant un mecanisme de diagrames, altres utilitzant un document de full de càlcul. Cada mètode té els seus pros i contres. Com a part de la decisió al campionat de WorldSkills, el temps va ser clau (recordeu el límit de temps de nou). Una tasca interessant a part és fer ping al servidor cada 5 segons i canviar el comportament de l'aplicació mòbil en funció de la disponibilitat o indisponibilitat del servidor.
Sessió 6
Es va proposar crear un espai de treball per a la direcció superior: Dashboard. En una pantalla era necessari mostrar els indicadors generals de rendiment de l'empresa durant un període determinat en forma gràfica i tabular. El formulari principal és l'informe de costos:
A més del Dashboard, va ser necessari implementar la distribució de recanvis per a la reparació d'actius mitjançant mètodes de cancel·lació FIFO/LIFO/“Cheapest goes first”.
Durant la distribució, es va tenir en compte la comptabilitat per lots, es va utilitzar el control del saldo i la protecció contra accions d'usuari no autoritzades («protecció dels tontos»).
Cyril: Per resoldre es van utilitzar taules de valors amb programari de generació de columnes, ja que pot haver-ne un nombre arbitrari:
- La primera taula és responsable dels costos totals dels departaments per mes. Les divisions més no rendibles i més rendibles es destaquen en vermell i verd, respectivament.
- La segona taula mostra les peces més cares i utilitzades amb més freqüència per a cada mes. Si hi ha diverses parts que compleixen els criteris, s'han de mostrar en una cel·la, separades per comes.
- Els actius més cars (en termes de costos de peces de recanvi) es mostren a la primera fila de la tercera taula. La segona línia mostra la divisió a la qual pertany l'actiu anterior. Si hi ha dos actius més cars amb els mateixos costos, s'haurien de mostrar a la mateixa cel·la, separats per comes.
Els diagrames es van mostrar mitjançant els mecanismes integrats de la plataforma i es van omplir mitjançant programes mitjançant consultes.
També es va proposar implementar suport al multilingüisme. El programa carrega fitxers XML amb la localització d'elements de la interfície i el formulari s'ha de tornar a dibuixar en seleccionar un idioma a la llista desplegable.
Quan feu clic al botó de l'extrem inferior esquerre de la pantalla, s'obre el formulari de gestió d'inventari:
D'aquesta forma, finalment comencem a gastar peces en reparacions. Aquí primer trobem les peces que necessitarem per reparar l'actiu. En funció dels camps seleccionats i del mètode de distribució (FIFO, LIFO o preu mínim), es mostren les coincidències trobades o un missatge si no hi ha coincidències. A continuació, podeu marcar les peces com a destinades a reparar aquest actiu. El control de l'equilibri és rellevant per a la sessió actual. Si ja hem assignat detalls, ja no es poden trobar.
Comentari d’experts: sessió molt interessant. Aprofita al màxim les capacitats de la plataforma 1C:Enterprise: aquí hi ha un treball competent amb taules virtuals de registres d'acumulació i un treball programàtic amb elements de formulari (en primer lloc, taules, en segon lloc, encapçalaments) i diagrames. I fins i tot LIFO/FIFO quan s'analitza l'inventari, l'anàlisi de guanys/pèrdues, etc.
Sessió 7
Al final de la tasca (sessió 7), el client va proporcionar programari (fitxer exe) per a les activitats del projecte i un breu vídeo sobre com treballar-hi. Calia fer enginyeria inversa i, a partir d'això, crear 2 diagrames: un diagrama de casos d'ús i un diagrama entitat-relació. A més, es van proposar alguns requisits per crear programari en el futur: era necessari crear un disseny d'interfície d'acord amb aquests requisits.
Segons les condicions de la competició, només calia MS Visio per crear diagrames.
Comentari d’experts: en aquesta sessió, pràcticament no s'han utilitzat les capacitats de la plataforma 1C:Enterprise. Els diagrames per a les condicions de la competició es van crear a MS Visio. Però es podria crear un prototip de la interfície en una base d'informació 1C buida.
Notes generals
Al començament de cada sessió, es va proposar importar dades mitjançant un script SQL. Aquest va ser el principal desavantatge d'utilitzar 1C en comparació amb C#, ja que vam passar almenys mitja hora destil·lant dades en fonts de dades externes, creant les nostres pròpies taules i movent files de fonts externes a les nostres taules. La resta només cal fer clic al botó Executar a Microsoft SQL Studio.
Per raons òbvies, emmagatzemar dades en un dispositiu mòbil no és una bona idea. Per tant, durant les sessions mòbils vam crear una base de servidors. Hi van emmagatzemar dades i hi van donar accés mitjançant serveis http.
Comentari d’experts: el balanç 1C/no-1C és interessant aquí, mentre que els programadors 1C:Enterprise van passar un temps important connectant-se a un DBMS extern (Kirill ho va esmentar per separat més amunt), els desenvolupadors de C#/Java (Android Studio per al desenvolupament mòbil) van dedicar temps a altres àrees: interfícies, escrivint més codi. Per tant, els resultats de cada sessió van ser impredictibles i molt interessants per a tots els experts. I aquesta intriga es va mantenir fins al final: només cal mirar la taula final de guanyadors amb el repartiment de punts.
Kirill va acabar la història :)
En conclusió, cal recordar que l'intèrpret no necessitava "només programar la tasca segons les especificacions tècniques": havia d'analitzar la tasca, seleccionar blocs per a la implementació de subtasques, dissenyar-los i decidir què seria exactament. capaç d'implementar-ho en el temps assignat extremadament curt. Els 4 dies vaig haver d'actuar sota una forta pressió de temps, sovint començant cada sessió posterior des de zero. Fins i tot un especialista adult amb molts anys d'experiència en la indústria tindrà grans dificultats per completar la tasca assignada per a la sessió al 100% dins del temps assignat.
Menció especial mereix el sistema d'avaluació adoptat.
Per a cada sessió, els autors de la tasca desenvolupen un complex sistema de criteris, que inclou la comprovació de la funcionalitat, el correcte funcionament, els requisits de la interfície de l'aplicació i, fins i tot, el seguiment d'una guia d'estil que l'empresa per a la qual desenvolupen les seves solucions proporciona especialment als participants.
Els criteris d'avaluació estan molt finament granulats: el cost total de la tasca de la sessió és de desenes de punts, el compliment d'algun criteri pot afegir dècimes de punt al participant. D'aquesta manera s'aconsegueix un nivell extremadament alt i objectiu d'avaluació dels resultats de cada participant en la competició.
Troballes
Els resultats finals van ser impressionants.
En una dura lluita, Kirill Pavkin de Rússia, que va utilitzar la plataforma 1C:Enterprise, va guanyar. Kirill té 17 anys, és de Stavropol.
Literalment, unes dècimes de punt separaven el guanyador dels seus perseguidors. El segon lloc l'ha ocupat un participant de Taiwan. La taula general dels sis primers resultats és la següent:
Per descomptat, Kirill va guanyar gràcies al seu talent, coneixements i habilitats.
Tanmateix, observem que els tres participants que van utilitzar la plataforma 1C:Enterprise com a eina es van incloure entre els cinc primers, la qual cosa és una confirmació incondicional del nivell mundial de la tecnologia 1C:Enterprise.
Després dels resultats del concurs, els guanyadors van ser premiats al centre de mitjans de KazanExpo; els nois van rebre medalles d'or pur (d'acord amb el seu lloc) i premis en metàl·lic. Els nois també van rebre certificats que els permeten fer pràctiques a 1C.
Font: www.habr.com