Finále WorldSkills, vývoj IT řešení pro podnikání - co to je, jak se to stalo a proč tam vyhráli programátoři 1C

WorldSkills je mezinárodní hnutí, které pořádá profesionální soutěže pro mládež do 22 let.

Mezinárodní finále se koná každé dva roky. Letos bylo posledním místem Kazan (poslední finále bylo v roce 2017 v Abu Dhabi, další bude v roce 2021 v Šanghaji).

WorldSkills Championships jsou největší mistrovství světa profesionálních dovedností. Začínali s dělnickými profesemi a v posledních letech se stále více pozornosti věnuje „profesím budoucnosti“, včetně IT oborů, pro které byl na šampionátu v Kazani vyčleněn samostatný obrovský cluster.

V bloku IT je kompetence (specifický „sport“) s názvem „IT Software Solutions for Business“.

V každé soutěži je omezený povolený seznam používaných nástrojů. A pokud je například pro „krajinářský design“ seznam možných nástrojů omezený (samozřejmě bez uvedení explicitního výrobce nebo barvy), pak v kompetenci „Softwarová řešení pro podnikání“ seznam akceptovaných technologií, které mohou účastníci používat. je přísně omezeno a označuje konkrétní technologie a konkrétní platformy (.NET a Java se specifickou sadou rámců).

Postoj 1C k této problematice je následující: informační technologie jsou velmi dynamická oblast, ve světě se neustále objevují nové technologie a vývojové nástroje. Z našeho pohledu je správné umožnit specialistům používat nástroje, se kterými chtějí a jsou zvyklí pracovat.

Na podzim 2018 nás vedení WorldSkills vyslyšelo. Nyní jsme museli otestovat metodiku začleňování nových technologií do soutěží. Není to jednoduché.

Platforma 1C:Enterprise byla zařazena na seznam infrastruktury šampionátu v Kazani a byla uspořádána experimentální platforma pro IT Software Solutions for Business Sandbox.



Upozorňujeme, že oficiálním jazykem mistrovství je angličtina. V tomto jazyce měly být předávány i všechny materiály s výsledky řešení úloh (zdrojové kódy, průvodní dokumentace, softwarová rozhraní). Navzdory pochybám některých lidí (stále!) můžete psát anglicky v 1C.

Soutěže na tomto místě se zúčastnilo 9 mladých kluků z 8 zemí (Filipíny, Tchaj-wan, Korea, Finsko, Maroko, Rusko, Kazachstán, Malajsie).

V čele poroty – týmu odborníků – stál odborník z Filipín Joey Manansala.

Zastoupeni byli odborníci z Finska, Spojených arabských emirátů, Kostariky, Koreje, Ruska a Tchaj-wanu.

Samostatně poznamenáváme, že účastníci z Ruska (Pavkin Kirill, Sultanova Aigul) a Kazachstánu (Vitovsky Ludwig) se v rámci soutěže rozhodli použít platformu 1C:Enterprise. Zbytek účastníků používal .NET pro desktop a Android Studio pro mobilní vývoj. Je zajímavé, že účastníci, kteří zvolili 1C, jsou velmi mladí (Kirill je studentem školy ve Stavropolu, letos nastoupil do 11. třídy, Aigul je vysokoškolák, Kazaň, Tatarstan), zatímco jejich soupeři byli mnohem zkušenější ( například účastník z Koreje - vítěz mistrovství WorldSkills 2013 v Lipsku; všichni mají zkušenosti s účastí ve WorldSkills a několik let profesionální praxe v oboru).

Vzhledem k tomu, že v průběhu soutěže účastníci využívali různé moderní technologie, měli jsme možnost vyzkoušet platformu 1C:Enterprise ve skutečně bojových podmínkách, porovnat jak kvalitu řešení získaných s její pomocí, tak rychlost vývoje dosaženou jejím využitím.

Samostatně poznamenáváme, že v rámci speciální platformy IT Software Solutions for Business Sandbox účastníci plnili stejné úkoly jako účastníci hlavní platformy IT Software Solutions for Business.

Samotný úkol je komplexní úkol pro automatizaci určitého obchodu, letos byla příkladem obchodu fiktivní společnost KazanNeft.

legenda

Kazan Oil je jedním z největších ropných podniků v Republice Tatarstán, působí jako hráč na národním trhu a mezinárodně uznávaná značka v této oblasti. Sídlo společnosti, která se specializuje na terénní průzkum, výrobu, výrobu, rafinaci, přepravu a prodej a distribuci ropy, ropných produktů a zemního plynu, se nachází v Kazani (Rusko).

Protože společnost zavádí strategii rychlé expanze a vytváření nových kanceláří po celém Rusku, rozhodlo se vedení společnosti zavést nový software pro automatizaci podnikání zaměřený na údržbu a řízení určitých operací.

Podmínky mistrovství

Úkoly byly účastníkům zadávány ve formě modulů (sezení) s požadavkem je splnit v omezeném čase. Celkem bylo 7 modulů. Tři sezení pro řešení na ploše – každé 2.5 hodiny. Tři sezení - vývoj klient-server, kde klientem byla mobilní aplikace a komunikace mezi klientem a serverem probíhala přes WEB-API. To trvalo 3.5 hodiny. Poslední sezení – úkoly na reverzní inženýrství existujícího softwaru, 2.5 hodiny. V rámci reverzního inženýrství museli účastníci na základě informací, které jim byly poskytnuty, navrhnout strukturu aplikační databáze (sestavením ER diagramu), analyzovat scénáře použití systému (sestavením diagramu případů užití) a také vyvinout a navrhnout rozhraní softwarového řešení dle poskytnutých funkčních požadavků.

Hlavními používanými vývojovými platformami byly .NET (C#) a Java (včetně Android Studio pro mobilní vývoj). Experimentální SandBox používal .NET, Java a 1C:Enterprise verze 8.3.13.

Na konci každého zasedání odborníci zhodnotili výsledek – hotový proveditelný projekt, který implementuje úkoly stanovené na začátku zasedání.

Zvláštností úkolů je jejich „životnost“ – mnoho požadavků a omezený čas. Většina problémů nejsou speciální problémy olympiády, ale jsou velmi blízké skutečným průmyslovým problémům - specialisté se s nimi potýkají každý den. Ale úkolů je mnoho a čas je omezený. Účastník musí vyřešit maximální počet problémů, které budou mít pro podnikání největší přínos. Není vůbec pravda, že složitý úkol z algoritmického hlediska bude mít větší váhu než elementární. Například vytvoření fungujícího účetního systému tří tabulek je pro firmu důležitější než krásný reportovací formulář se složitými algoritmy, který je bez těchto tabulek zcela zbytečný.

O jaké úkoly se jednalo a jak k jejich řešení přistupoval, jsme požádali vítěze soutěže, účastníka z Ruska Kirilla Pavkina.

Níže je popis úkolu, Kirillův vlastní příběh o tom, jak úkol vyřešil. O vyjádření ke Kirillovým řešením jsme požádali také Vitalyho Rybalku, zaměstnance 1C a jednoho z expertů na IT Solutions for Business Sandbox.

V rámci zadání bylo nutné zautomatizovat činnost několika typů uživatelů:

• Zodpovědnost za účtování majetku společnosti
• Zodpovědnost za neplánované opravy a plánovanou údržbu majetku společnosti
• Manažeři nákupu komponent a spotřebního materiálu
• Divize průzkumu a těžby ropy
• Vrcholový management potřeboval analytické zprávy

Relace 1

Z hlediska majetku (například vozového parku) bylo nutné zavést jejich účtování (zakládání nových, editace stávajících), rychlé vyhledávání a různé druhy filtrů pro zobrazování informací, přesun majetku mezi divizemi společnosti a samotné skupiny aktiv. Uchovávejte si historii takových pohybů a poskytujte o nich v budoucnu analýzy. Účtování majetku bylo implementováno především pro skupiny mobilních uživatelů.

Кирилл: Zajímavým dílčím úkolem byla implementace tlačítek v seznamu aktiv. K vyřešení jsme použili dynamický seznam: napíšeme libovolný požadavek a při příjmu dat na server přiřadíme do požadovaných polí navigační odkazy na obrázky z knihovny obrázků.

Podle konvence lze fotografie připojit k aktivu dvěma způsoby: pořídit fotografii (multimédia) a vybrat z galerie (dialog pro výběr souboru).

Některé tvary bylo potřeba při otočení obrazovky překreslit:

Při změně parametrů obrazovky měníme viditelnost skupin tlačítek.

Mezi zábavné, ale jednoduché úkoly patří filtry v dynamickém seznamu, vyhledávání ve dvou polích (číslo a název) a generování sériového čísla majetku.

Komentář odborníka: z pohledu řešení na platformě 1C:Enterprise je zadání celkem jasné. Kromě samotného vytvoření mobilní aplikace bylo potřeba postarat se o přenos dat z DBMS „serveru“ (MS SQL na desktopu) do mobilní aplikace a zpět. K tomuto účelu byly využity mechanismy externích datových zdrojů a http služeb v desktopové „proxy aplikaci“. Pro samotnou mobilní platformu představovalo zobrazení obrázků v dynamickém seznamu zvýšenou složitost.

Relace 2

Bylo nutné zavést správu oprav majetku společnosti. V rámci tohoto úkolu bylo nutné vést seznam požadavků na opravy (podle oddělení a skupin), zohlednit priority pro naléhavost oprav, naplánovat harmonogram oprav v souladu s prioritami, objednat potřebné komponenty a vzít v úvahu stávající. Zajímavým dílčím úkolem bylo, že některé komponenty měly datum expirace; pokud je k danému majetku již objednán díl a neuplynula jeho lhůta, pak pro tento majetek není potřeba stejný díl znovu pořizovat. Opravné rozhraní bylo vyvinuto pro desktopovou komponentu firemního softwaru.

Dále bylo nutné vytvořit netriviální autorizační formulář pro dvě role: odpovědnou osobu a manažera služby. Zvláštností je, že po autorizaci musíte automaticky vybrat jednu z rolí.

Formulář seznamu, který má odpovědná osoba k dispozici, je uveden níže:

Кирилл: Zde lze zvýraznit pouze zvýraznění čekajících servisních požadavků. Řeší se podmíněným formátováním v dynamickém seznamu.

Kliknutím na tlačítko v dolní části obrazovky může uživatel přejít do následujícího formuláře:

Z pohledu 1C není v této podobě nic složitého.

Formulář, který má k dispozici správce služeb, je níže:

Tento formulář je řazen podle priority a data požadavku. Kliknutím na tlačítko níže může uživatel přejít do formuláře vybraného požadavku:

Kromě zabezpečení proti chybám tento formulář navrhoval zavedení seznamu náhradních dílů pro opravy. Dílčí úkol je zajímavý tím, že díly mají datum expirace. To znamená, že pokud u tohoto majetku již došlo k mimořádné události a byl k němu objednán díl, jehož doba platnosti neuplynula, lze jej znovu použít. To by se mělo uživateli ukázat.

Komentář odborníka: zde Kirill sám správně umístil akcenty. Z pohledu implementace na platformě 1C:Enterprise nejde o nic extrémně složitého. Byla vyžadována pečlivá analýza podmínek pro účtování a použití náhradních dílů a kompetentní realizace úkolu jako celku. Navíc bylo nutné řádně evidovat servisní požadavky. Hlavním problémem byla pouze časová tíseň 2.5 hodiny.

Navíc, stejně jako v mobilním vývoji, musel účastník kvalifikovaně získávat data z externího DBMS (MS SQL).

Relace 3

Pro údržbu (údržbu) bylo navrženo zavést službu dlouhodobého plánování. Zajímavostí zde byl požadavek na vytvoření plánu údržby majetku podle časového rozvrhu - například každý druhý měsíc 3. Stejně tak podle nějakého kvantitativního ukazatele - například podle počítadla kilometrů automobilu (výměna oleje každých 5000 20000 km, výměna pneumatik každých XNUMX XNUMX km). Správce údržby by měl obdržet pohodlnou mobilní aplikaci, která dynamicky zobrazuje seznam zpožděné, aktuální a dokončené údržby za zadané období. Každý typ údržby musel být navíc barevně natřen podle speciálně dohodnutých pravidel. Mobilní aplikace měla zajistit tvorbu nových plánů údržby a označení již hotových přímo v dílnách s rychlou aktualizací těchto informací na serveru.

Кирилл: Existují dva typy oprav: založené na čase a na běhu. V rámci každého je povolena variabilita. K opravám by podle plánu mělo dojít například každý pátek, 13. v měsíci nebo každých 20,000 XNUMX kilometrů. Úkol je považován za dokončený, pokud je napravo od něj zaškrtnuto.

Byla zadána podmínka pro řazení úkolů v seznamu. Každý řádek by měl být také barevně zvýrazněn v závislosti na podmínkách.

Kliknutím na tlačítko níže můžete vytvořit nový plán služeb:

V závislosti na zvoleném typu grafu se zobrazí požadovaná pole. Pokud jsme zvolili týdenní časový plán, zobrazí se nám dvě pole: číslo týdne a den v týdnu. Například v úterý každé 3 týdny.

Komentář odborníka: stejně jako v předchozím mobilním vývoji na platformě 1C:Enterprise je zde úkol globálně rozdělen na 2 komponenty - komunikace se „serverem“ přes web-api a kompetentní zobrazení dynamického seznamu s podmíněným návrhem a filtrováním (výběrem) data. Zajímavá byla navíc implementace požadavku účtovat opravy jak podle období, tak podle kvantitativního ukazatele.

Relace 4

U komponentů a spotřebního materiálu bylo nutné počítat se zásobami, plánovat výdaje a budoucí nákupy. Navíc se zde objevilo účtování šarží, ale ne u všeho zboží. To vše bylo nutné řídit v rámci více skladů, včetně příjmu, výdeje a pohybu. Podle podmínek zadání bylo nutné zajistit kontrolu zůstatků a vyhnout se konfliktům při práci s aktuálními zásobami. Manažeři nákupu pracují v desktopové verzi softwaru.

Hlavní formulář je uveden níže:

Кирилл: Kromě řazení podle podmínky bylo navrženo dát uživateli možnost náhodného řazení. Na 1C o tom nemusíte ani přemýšlet. Pole s množstvím dílů by mělo být u faktur zvýrazněno zeleně.

V této relaci byli požádáni o kontrolu zbývajícího zboží ve skladech. Při pokusu o smazání faktury by se tedy měla zobrazit odpovídající zpráva. Zde si pamatujeme zkoušku platformového specialisty. Forma faktury je následující:

Každý díl má charakteristiku, která určuje, zda má být přiřazen ke konkrétní dávce. U takových náhradních dílů je bezpodmínečně nutné uvádět číslo šarže ve všech dokumentech. Jedná se o dodatečné měření při sledování zbytků dílů. Lze je také přesouvat mezi sklady:

Formulář se od předchozího liší pouze tím, že místo odběratele je potřeba uvést sklad, ze kterého bude dodávka realizována. Po výběru dílu se automaticky sestaví výběrový seznam pro dávku. Uživatel může vygenerovat zprávu o zůstatcích náhradních dílů:

Zde si můžeme prohlédnout zbývající zboží ve vybraném skladu. Zaškrtávací políčka napravo od skladu umožňují konfigurovat filtrování a třídění. Seznam nemá výslovné rozdělení losem pro ty části, pro které je požadován. Zůstatky pro každé číslo šarže vybraného náhradního dílu lze zobrazit pomocí navigačního odkazu vpravo.

Komentář odborníka: v této relaci (modulu) se poprvé objevilo dávkové účtování. Účastníci byli povinni účtovat spotřební materiál a zboží nejen sami, ale i šarže. Obecně je úkol perfektní pro platformu 1C:Enterprise – ale vše muselo být vyvinuto od nuly a dokončeno za 2.5 hodiny.

Relace 5

V pátém sezení nám byla přidělena funkcionalita správy studní. Pro průzkumné skupiny bylo nutné vytvořit mobilní aplikaci, která by počítala s těžbou ropy nebo plynu. Zde bylo nutné získat ze serveru seznam aktuálních vrtů a vybraný vrt graficky zobrazit po vrstvách (půda, písek, kámen, olej) s přihlédnutím k hloubce jednotlivých vrstev. Aplikace navíc musela umožňovat aktualizaci informací o vrtu a přidávání nových vrtů. Pro tuto aplikaci si zákazník nastavil speciální provozní podmínky v offline i online režimu (řízení komunikace se serverem) - kontrola komunikace se serverem každých 5 sekund a změna funkčnosti aplikace v závislosti na dostupnosti serveru.

Кирилл: Když vyberete vrt, zobrazí se sloupcový graf, který zvýrazňuje vrstvy až po ložiska ropy nebo plynu. Pro každou vrstvu je uložen její název, barva a rozsah výskytu. Vzhledem k konstrukčním prvkům diagramy zabudované do platformy nepomáhají, ale tabulkový dokument se s tímto úkolem dokonale vyrovná. Studny lze vytvářet a upravovat:

Kromě vícenásobné spolehlivé ochrany nebylo na této formě nic zajímavého.
Dále bylo navrženo řídit připojení k serveru. Snažíme se připojit každých 5 sekund. Pokud to nefunguje, omezíme funkčnost aplikace a zobrazíme zprávu.

Komentář odborníka: Úkol této relace je zajímavý především svými grafickými možnostmi. Účastníci využívající platformu 1C:Enterprise to vyřešili dvěma různými způsoby – někteří pomocí mechanismu diagramu, jiní pomocí tabulkového dokumentu. Každá metoda má své pro a proti. V rámci rozhodování na mistrovství WorldSkills byl klíčový čas (zapamatujte si opět časový limit). Samostatným zajímavým úkolem je ping na server každých 5 sekund a změna chování mobilní aplikace v závislosti na dostupnosti nebo nedostupnosti serveru.

Relace 6

Bylo navrženo vytvořit pracovní prostor pro vrcholový management – ​​Dashboard. Na jedné obrazovce bylo nutné zobrazit obecné ukazatele výkonnosti společnosti za zadané období v grafické a tabulkové podobě. Hlavním formulářem je výkaz nákladů:

Kromě Dashboardu bylo nutné implementovat distribuci náhradních dílů pro opravy majetku metodami odpisů FIFO/LIFO/„Nejlevnější jede první“.

Při distribuci bylo zohledněno účtování dávek, kontrola zůstatku a ochrana před neoprávněným zásahem uživatele („ochrana bláznů“).

Кирилл: K řešení byly použity tabulky hodnot se softwarovým generováním sloupců, protože jich může být libovolný počet:

• První tabulka odpovídá za celkové náklady oddělení podle měsíce. Nejvíce nerentabilní a nejziskovější divize jsou zvýrazněny červeně a zeleně.
• V druhé tabulce jsou uvedeny nejdražší a nejčastěji používané díly za jednotlivé měsíce. Pokud existuje několik částí, které splňují kritéria, měly by být zobrazeny v jedné buňce oddělené čárkami.
• Nejdražší aktiva (z hlediska nákladů na náhradní díly) jsou zobrazena v prvním řádku třetí tabulky. Druhý řádek zobrazuje divizi, do které výše uvedený majetek patří. Pokud existují dvě nejdražší aktiva se stejnými náklady, měla by být zobrazena ve stejné buňce oddělená čárkami.

Diagramy byly zobrazovány pomocí vestavěných mechanismů platformy a vyplňovány programově pomocí dotazů.

Bylo také navrženo zavést podporu mnohojazyčnosti. Program načte soubory XML s lokalizací prvků rozhraní a formulář by se měl překreslit při výběru jazyka v rozevíracím seznamu.

Když kliknete na tlačítko v levém dolním rohu obrazovky, otevře se formulář pro správu zásob:

V této podobě konečně začínáme utrácet díly za opravy. Zde nejprve najdeme díly, které budeme potřebovat k opravě aktiva. Na základě vybraných polí a způsobu distribuce (FIFO, LIFO nebo minimální cena) se zobrazí nalezené shody nebo zpráva, pokud nejsou žádné shody. Poté můžete označit díly jako určené k opravě daného majetku. Kontrola vyvážení je relevantní pro aktuální relaci. Pokud jsme již přiřadili podrobnosti, pak je již nelze najít.

Komentář odborníka: velmi zajímavá relace. Maximálně využívá možnosti platformy 1C:Enterprise - zde je kompetentní práce s virtuálními tabulkami akumulačních registrů a programová práce s formulářovými prvky (především tabulky, za druhé nadpisy) a diagramy. A dokonce i LIFO/FIFO při analýze zásob, analýze zisku/ztráty atd.

Relace 7

Na konci zadání (session 7) zákazník poskytl software (exe soubor) pro projektové aktivity a krátké video o práci s ním. Bylo potřeba provést reverzní inženýrství a na základě toho vytvořit 2 diagramy: diagram případu užití a diagram entita-vztah. Kromě toho byly vzneseny některé požadavky na tvorbu softwaru v budoucnu - bylo nutné vytvořit rozložení rozhraní podle těchto požadavků.

Podle soutěžních podmínek bylo pro tvorbu diagramů vyžadováno pouze MS Visio.

Komentář odborníka: v této relaci nebyly prakticky využity možnosti platformy 1C:Enterprise. Diagramy pro soutěžní podmínky byly vytvořeny v MS Visio. Ale prototyp rozhraní by mohl být vytvořen v prázdné informační základně 1C.

Obecné poznámky

Na začátku každé relace bylo navrženo importovat data pomocí SQL skriptu. To byla hlavní nevýhoda použití 1C ve srovnání s C#, protože jsme strávili nejméně půl hodiny destilací dat do externích datových zdrojů, vytvářením vlastních tabulek a přesouváním řádků z externích zdrojů do našich tabulek. Zbytek stačí kliknout na tlačítko Execute v Microsoft SQL Studio.

Z pochopitelných důvodů není ukládání dat na mobilní zařízení dobrý nápad. Proto jsme během mobilních relací vytvořili serverovou základnu. Ukládali tam data a poskytovali k nim přístup prostřednictvím http služeb.

Komentář odborníka: vyvážení 1C/non-1C je zde zajímavé – zatímco programátoři 1C:Enterprise strávili značný čas připojením k externímu DBMS (Kirill to zmínil samostatně výše), vývojáři C#/Java (Android Studio pro mobilní vývoj) strávili čas v jiných oblastech – rozhraní, psaní více kódu. Proto byly výsledky každého sezení nepředvídatelné a pro všechny odborníky nesmírně zajímavé. A tahle záludnost zůstala až do konce – stačí se podívat na konečnou tabulku vítězů s rozdělením bodů.

Kirill dokončil příběh :)

Na závěr je třeba připomenout, že performer nepotřeboval „pouze naprogramovat úkol podle technických specifikací“ - musel úkol analyzovat, vybrat bloky pro realizaci dílčích úkolů, navrhnout je a rozhodnout, co přesně bude schopni to realizovat v extrémně krátkém stanoveném čase. Celé 4 dny jsem musel jednat pod velkým časovým tlakem, přičemž každé následující sezení jsem často začínal od nuly. I dospělý specialista s mnohaletou praxí v oboru bude mít velké potíže splnit zadaný úkol na relaci na 100 % ve stanoveném čase.

Zvláštní zmínku si zaslouží přijatý systém hodnocení.

Autoři úkolu pro každé sezení vypracují komplexní systém kritérií, včetně kontroly funkčnosti, správného fungování, požadavků na aplikační rozhraní a dokonce i podle stylového průvodce, který účastníkům speciálně poskytla společnost, pro kterou svá řešení vyvíjejí.

Kritéria hodnocení jsou velmi jemně granulovaná - s celkovou cenou úkolu sezení v řádu desítek bodů, splnění některého kritéria může účastníkovi přidat desetiny bodu. Tím je dosaženo mimořádně vysoké a objektivní úrovně hodnocení výsledků každého účastníka soutěže.

výsledky

Konečné výsledky byly působivé.

V lítém boji zvítězil Kirill Pavkin z Ruska, který používal platformu 1C:Enterprise. Kirillovi je 17 let, pochází ze Stavropolu.

Doslova desetiny bodu dělily vítěze od jeho pronásledovatelů. Druhé místo obsadil účastník z Tchaj-wanu. Celková tabulka šesti nejlepších výsledků vypadá takto:

Kirill samozřejmě zvítězil díky svému talentu, znalostem a dovednostem.

Podotýkáme však, že všichni tři účastníci, kteří používali platformu 1C:Enterprise jako nástroj, byli zařazeni do první pětice – což je bezpodmínečné potvrzení světové úrovně technologie 1C:Enterprise.

Po výsledcích soutěže byli vítězové oceněni v mediálním centru KazanExpo, kluci obdrželi čisté zlaté medaile (podle umístění) a peněžní ceny. Kluci také získali certifikáty, které jim umožňují absolvovat stáž v 1C.

Zdroj: www.habr.com