גמר WorldSkills, פיתוח פתרונות IT לעסקים - מה זה, איך זה קרה ולמה מתכנתי 1C זכו שם

WorldSkills היא תנועה בינלאומית המארגנת תחרויות מקצועיות לצעירים מתחת לגיל 22.

הגמר הבינלאומי מתקיים כל שנתיים. השנה היה המקום האחרון קאזאן (הגמר האחרון היה ב-2017 באבו דאבי, הבא יהיה ב-2021 בשנחאי).

אליפויות WorldSkills הן האליפויות הגדולות בעולם של כישורים מקצועיים. הם התחילו במקצועות הצווארון הכחול, ובשנים האחרונות יותר ויותר תשומת לב ניתנת ל"מקצועות העתיד", כולל מקצועות ה-IT, שלגביהם הוקצה אשכול ענק נפרד באליפות בקאזאן.

בבלוק ה-IT ישנה מיומנות ("ספורט") ספציפית הנקראת "פתרונות תוכנה IT לעסקים".

בכל תחרות, רשימת הכלים המותרים בשימוש מוגבלת. ואם, למשל, עבור "עיצוב נוף" רשימת הכלים האפשריים מוגבלת (כמובן, ללא ציון יצרן או צבע מפורש), אז בכשירות "פתרונות תוכנה לעסקים" רשימת הטכנולוגיות המקובלות בהן המשתתפים יכולים להשתמש מוגבל בהחלט, ומציין טכנולוגיות ספציפיות ופלטפורמות ספציפיות (.NET ו-Java עם סט ספציפי של מסגרות).

עמדת 1C בנושא זה היא כדלקמן: טכנולוגיית מידע היא תחום מאוד דינמי, טכנולוגיות וכלי פיתוח חדשים מופיעים כל הזמן בעולם. מנקודת המבט שלנו, נכון לאפשר למומחים להשתמש בכלים שבהם הם רוצים ורגילים לעבוד.

בסתיו 2018, הנהלת WorldSkills שמעה אותנו. כעת היינו צריכים לבדוק את המתודולוגיה לשילוב טכנולוגיות חדשות בתחרויות. זה לא פשוט.

פלטפורמת 1C:Enterprise נכללה ברשימת התשתיות של האליפות בקאזאן ואורגנה פלטפורמה ניסיונית ל-IT Software Solutions for Business Sandbox.



שימו לב שהשפה הרשמית של האליפות היא אנגלית. כל החומרים עם תוצאות של פתרון משימות (קודי מקור, תיעוד נלווה, ממשקי תוכנה) היו אמורים להיות מועברים גם הם בשפה זו. למרות הספקות של כמה אנשים (עדיין!), אתה יכול לכתוב באנגלית ב-1C.

9 בחורים צעירים מ-8 מדינות (פיליפינים, טייוואן, קוריאה, פינלנד, מרוקו, רוסיה, קזחסטן, מלזיה) השתתפו בתחרות באתר זה.

בראש חבר השופטים - צוות מומחים - עמד מומחה מהפיליפינים, ג'ואי מננסלה.

מומחים מפינלנד, איחוד האמירויות, קוסטה ריקה, קוריאה, רוסיה וטייוואן היו מיוצגים.

בנפרד, נציין כי משתתפים מרוסיה (פאבקין קיריל, סולטנובה איגול) וקזחסטן (ויטובסקי לודוויג) החליטו להשתמש בפלטפורמת 1C:Enterprise כחלק מהתחרות. שאר המשתתפים השתמשו ב-.NET למחשב שולחני וב-Android Studio לפיתוח נייד. מעניין שהמשתתפים שבחרו ב-1C הם צעירים מאוד (קיריל הוא תלמיד בבית ספר בסטברופול, השנה הוא עלה לכיתה י"א, איגול הוא סטודנט בקולג', קאזאן, טטרסטן), בעוד היריבים שלהם היו הרבה יותר מנוסים ( למשל, משתתף מקוריאה - זוכה באליפות WorldSkills 11 בלייפציג; לכולם ניסיון בהשתתפות ב-WorldSkills וניסיון מקצועי של מספר שנים בענף).

בהתחשב בכך שבמהלך התחרות המשתתפים השתמשו בטכנולוגיות מודרניות שונות, הייתה לנו הזדמנות לבדוק את פלטפורמת 1C:Enterprise בתנאי קרב אמיתיים, כדי להשוות הן את איכות הפתרונות שהושגו בעזרתה והן את מהירות הפיתוח שהושגה עם השימוש בה.

בנפרד, נציין כי במסגרת הפלטפורמה המיוחדת של IT Software Solutions for Business Sandbox, המשתתפים השלימו את אותן משימות כמו המשתתפים בפלטפורמת IT Software Solutions for Business הראשית.

המשימה עצמה היא משימה מורכבת לאוטומציה של עסק מסוים; השנה הדוגמה לעסק הייתה החברה הפיקטיבית KazanNeft.

אגדה

Kazan Oil הוא אחד ממפעלי הנפט הגדולים ברפובליקה של טטרסטן, הפועל כשחקן שוק לאומי ומותג בינלאומי מוכר בתחום זה. המשרד הראשי של החברה, המתמחה בחיפושי שטח, ייצור, הפקה, זיקוק, הובלה ומכירה והפצה של נפט, מוצרי נפט וגז טבעי, ממוקם בקאזאן (רוסיה).

מאחר שהחברה מיישמת אסטרטגיה של התרחבות מהירה ויצירת משרדים חדשים ברחבי רוסיה, החליטה הנהלת החברה להציג תוכנת אוטומציה עסקית חדשה שמטרתה לתחזק ולנהל פעולות מסוימות.

תנאי אליפות

המשימות ניתנו למשתתפים בצורה של מודולים (מפגשים) עם דרישה להשלמתן בזמן מוגבל. היו 7 מודולים בסך הכל. שלושה מפגשים לפתרון על שולחן עבודה – 2.5 שעות כל אחד. שלושה מפגשים - פיתוח שרת-לקוח, כאשר הלקוח היה אפליקציה סלולרית, והתקשורת בין הלקוח לשרת התבצעה באמצעות WEB-API. זה לקח 3.5 שעות. מפגש אחרון – משימות בנושא הנדסה לאחור של תוכנות קיימות, 2.5 שעות. כחלק מהנדסה לאחור, על המשתתפים, בהתבסס על המידע שנמסר להם, לתכנן את מבנה מסד הנתונים של האפליקציה (על ידי בניית דיאגרמת ER), לנתח תרחישים לשימוש במערכת (על ידי בניית דיאגרמת מקרי שימוש), וכן לפתח ולעצב את הממשק של פתרון התוכנה בהתאם לדרישות הפונקציונליות שסופקו.

פלטפורמות הפיתוח העיקריות בהן נעשה שימוש היו .NET (C#) ו-Java (כולל Android Studio לפיתוח נייד). ה-SandBox הניסיוני השתמש ב-.NET, Java ו-1C:Enterprise בגרסה 8.3.13.

בסוף כל מפגש העריכו המומחים את התוצאה - פרויקט בר-ביצוע מוכן המיישם את המשימות שנקבעו בתחילת המפגש.

הייחודיות של המשימות היא "החיוניות" שלהן - דרישות רבות וזמן מוגבל. רוב הבעיות אינן בעיות אולימפיאדה מיוחדות, אלא קרובות מאוד לבעיות תעשייתיות אמיתיות - מומחים מתמודדים איתן מדי יום. אבל יש הרבה משימות, והזמן מוגבל. על המשתתף לפתור את המספר המקסימלי של בעיות שיביאו את התועלת הגדולה ביותר לעסק. זה כלל לא עובדה שלמשימה מורכבת מנקודת מבט אלגוריתמית תהיה משקל רב יותר מאשר יסודי. לדוגמה, יצירת מערכת חשבונאית מתפקדת של שלוש טבלאות חשובה יותר לעסק מאשר טופס דיווח יפה עם אלגוריתמים מורכבים, מיותר לחלוטין ללא הטבלאות הללו.

ביקשנו מהמנצח בתחרות, משתתף מרוסיה, קיריל פאבקין, לספר לנו יותר על מה המשימות וכיצד הוא ניגש לפתרון שלהן.

להלן תיאור של המשימה, סיפורו של קיריל עצמו על איך הוא פתר את המשימה. ביקשנו גם מ-Vitaly Rybalka, עובד 1C ואחד ממומחי ה-IT Solutions for Business Sandbox, להגיב על הפתרונות של Kirill.

במסגרת המשימה, היה צורך לבצע אוטומציה של הפעילויות של מספר סוגי משתמשים:

• אחראי על הנהלת חשבונות של נכסי החברה
• אחראי על תיקונים לא מתוכננים ותחזוקה מתוכננת של נכסי החברה
• מנהלי רכש של רכיבים וחומרים מתכלים
• חטיבות חיפושי נפט והפקת נפט
• ההנהלה הבכירה הייתה זקוקה לדוחות אנליטיים

מפגש 1

מבחינת נכסים (למשל צי רכב) היה צורך ביישום החשבונאות שלהם (הקמת חדשים, עריכת שוטפים), חיפוש מהיר ומסננים שונים להצגת מידע, העברת נכסים בין חטיבות החברה. וקבוצות של נכסים עצמם. שמור היסטוריה של תנועות כאלה וספק ניתוחים לגביהן בעתיד. חשבונאות נכסים יושמה בעיקר עבור קבוצות משתמשים ניידים.

סיריל: תת-משימה מעניינת הייתה הטמעת כפתורים ברשימת הנכסים. כדי לפתור זאת, השתמשנו ברשימה דינמית: אנו כותבים בקשה שרירותית, וכאשר מקבלים נתונים בשרת, אנו מקצים קישורי ניווט לתמונות מספריית התמונות לשדות הנדרשים.

לפי המוסכמה, ניתן לצרף תמונות לנכס בשתי דרכים: לצלם תמונה (מולטימדיה) ולבחור מהגלריה (תיבת שיח לבחירת קבצים).

היה צורך לצייר מחדש כמה צורות כאשר המסך היה מסובב:

בעת שינוי פרמטרי מסך, אנו משנים את הנראות של קבוצות הכפתורים.

משימות משעשעות אך פשוטות כוללות מסננים ברשימה דינמית, חיפוש בשני שדות (מספר ושם) ויצירת מספר סידורי של נכס.

פרשנות מומחה: מנקודת המבט של הפתרון בפלטפורמת 1C:Enterprise, המשימה ברורה למדי. בנוסף ליצירת האפליקציה הסלולרית בפועל, היה צורך לדאוג להעברת נתונים מ"שרת" ה-DBMS (MS SQL בדסקטופ) לאפליקציה הסלולרית ובחזרה. למטרה זו, נעשה שימוש במנגנונים של מקורות נתונים חיצוניים ושירותי http ב"אפליקציית פרוקסי" של שולחן העבודה. עבור הפלטפורמה הניידת עצמה, הצגת תמונות ברשימה דינמית הציגה מורכבות מוגברת.

מפגש 2

היה צורך להקים ניהול תיקונים לנכסי החברה. במסגרת משימה זו היה צורך לנהל רשימת בקשות לתיקון (לפי מחלקות וקבוצות), לקחת בחשבון את סדרי העדיפויות לדחיפות התיקונים, לתכנן לוח תיקון בהתאם לסדרי עדיפויות, להזמין את הרכיבים הדרושים ולקחת בחשבון קיימים. תת-משימה מעניינת הייתה שלחלק מהרכיבים היה תאריך תפוגה; אם כבר הוזמן חלק עבור נכס נתון והמועד האחרון שלו לא פג, אז עבור נכס זה אין צורך לרכוש את אותו חלק שוב. ממשק התיקון פותח עבור רכיב הדסקטופ של תוכנת החברה.

כמו כן, היה צורך ליצור טופס הרשאה לא טריוויאלי לשני תפקידים: האדם האחראי ומנהל השירות. המוזרות היא שאחרי האישור עליך לבחור אוטומטית באחד מהתפקידים.

טופס הרשימה העומד לרשות האדם האחראי מוצג להלן:

סיריל: ניתן להדגיש כאן רק את ההדגשה של בקשות שירות ממתינות. נפתרה על ידי עיצוב מותנה ברשימה דינמית.

בלחיצה על הכפתור בתחתית המסך, המשתמש יכול לעבור לטופס הבא:

מנקודת מבט של 1C, אין שום דבר מסובך בצורה הזו.

להלן הטופס העומד לרשות מנהל השירות:

טופס זה ממוין לפי עדיפות ותאריך הבקשה. בלחיצה על הכפתור למטה, המשתמש יכול לעבור לטופס הבקשה שנבחרה:

בנוסף לאיטום, טופס זה הציע ליישם רשימה של חלקי חילוף לתיקונים. המשנה מעניינת כי לחלקים יש תאריך תפוגה. המשמעות היא שאם כבר אירע מקרה חירום עם נכס זה והוזמן עבורו חלק שתוקפו לא פגה, אז ניתן לעשות בו שימוש חוזר. זה צריך להיות מוצג למשתמש.

פרשנות מומחה: כאן קיריל עצמו הציב נכון את המבטאים. מנקודת מבט של יישום בפלטפורמת 1C:Enterprise, אין שום דבר מסובך במיוחד. נדרש ניתוח מדוקדק של התנאים לחשבונאות ושימוש בחלקי חילוף ויישום מוכשר של המשימה בכללותה. בנוסף, היה צורך ברישום נכון של בקשות שירות. הקושי העיקרי היה רק ​​לחץ הזמן של 2.5 שעות.

בנוסף, כמו בפיתוח נייד, המשתתף היה צריך להשיג נתונים במיומנות מ-DBMS חיצוני (MS SQL).

מפגש 3

לצורך תחזוקה (אחזקה) הוצע ליישם שירות תכנון ארוך טווח. תכונה מעניינת כאן הייתה הדרישה ליצור לוח זמנים תחזוקה לנכסים לפי תזמון - לדוגמה, כל חודש שני ב-3. כמו כן, לפי אינדיקטור כמותי כלשהו - למשל, לפי מד מרחק של מכונית (החלפת שמן כל 5000 ק"מ, החלפת צמיגים כל 20000 ק"מ). מנהל התחזוקה היה צריך לקבל אפליקציה נוחה לנייד שמציגה באופן דינמי רשימה של תחזוקה באיחור, שוטפת והסתיימה לתקופה מוגדרת. בנוסף, כל סוג של תחזוקה היה צריך להיות צבוע בצבע לפי כללים מוסכמים במיוחד. האפליקציה הסלולרית הייתה אמורה להבטיח יצירת לוחות זמנים חדשים לתחזוקה וסימון של אלו שכבר הושלמו ישירות בסדנאות עם עדכון מהיר של מידע זה בשרת.

סיריל: ישנם שני סוגים של תיקונים: מבוססי זמן ומבוססים על ריצה. שונות מותרת בתוך כל אחד. כך למשל, על פי התוכנית, תיקונים צריכים להתבצע בכל יום שישי, 13 בחודש, או כל 20,000 קילומטרים. משימה נחשבת שהושלמה אם יש סימן ביקורת מימין לה.

ניתן תנאי למיון משימות ברשימה. כמו כן, יש להדגיש כל שורה בצבע בהתאם לתנאים.

בלחיצה על הכפתור למטה, תוכל ליצור תוכנית שירות חדשה:

השדות הנדרשים מוצגים בהתאם לסוג התרשים שנבחר. אם בחרנו לוח זמנים שבועי, יוצגו לנו שני שדות: מספר השבוע ויום השבוע. למשל, בימי שלישי כל 3 שבועות.

פרשנות מומחה: כמו בפיתוח המובייל הקודם בפלטפורמת 1C:Enterprise, כאן המשימה מחולקת באופן גלובלי ל-2 רכיבים - תקשורת עם ה"שרת" באמצעות web-api ותצוגה מוכשרת של רשימה דינמית עם עיצוב מותנה וסינון (בחירה) של נתונים. בנוסף, היה מעניין ליישם את הדרישה להתחשב בתיקונים הן לפי תקופה והן לפי אינדיקטור כמותי.

מפגש 4

עבור רכיבים וחומרים מתכלים, היה צורך לקחת בחשבון מלאי, לתכנן הוצאות ורכישות עתידיות. בנוסף, הופיעה כאן חשבונאות אצווה, אך לא עבור כל הסחורה. כל זה היה צריך להיות מנוהל בתוך מספר מחסנים, כולל קבלה, הוצאה ותנועה. על פי תנאי המשימה, היה צורך להבטיח שליטה באיזונים ולהימנע מעימותים בעבודה עם מניות שוטפות. מנהלי רכש עובדים בגרסת שולחן העבודה של התוכנה.

הטופס הראשי מוצג להלן:

סיריל: בנוסף למיון מהתנאי, הוצע לתת למשתמש אפשרות למיין באופן אקראי. ב-1C אתה אפילו לא צריך לחשוב על זה. השדה עם כמות החלקים צריך להיות מסומן בירוק עבור חשבוניות.

בפגישה זו הם התבקשו לשלוט על הסחורה שנותרה במחסנים. לכן, ההודעה המתאימה צריכה להיות מוצגת כאשר אתה מנסה למחוק את החשבונית. כאן אנו זוכרים את בחינת מומחה הפלטפורמה. צורת החשבונית היא כדלקמן:

לכל חלק יש מאפיין שקובע אם יש להקצות אותו לאצווה מסוימת. עבור חלקי חילוף כאלה, חובה לציין את מספר האצווה בכל המסמכים. זוהי מדידה נוספת בעת ניטור שאריות חלקים. ניתן גם להעביר אותם בין מחסנים:

הטופס שונה מהקודם רק בכך שבמקום הלקוח יש לציין את המחסן ממנו תתבצע המשלוח. רשימת הבחירה עבור האצווה מורכבת אוטומטית לאחר בחירת החלק. המשתמש יכול להפיק דוח על יתרות חלקי חילוף:

כאן נוכל לראות את הסחורה שנותרה במחסן הנבחר. תיבות הסימון מימין למחסן מאפשרות לך להגדיר סינון ומיון. ברשימה אין חלוקה מפורשת לפי הגרלה לאותם חלקים שעבורם היא נדרשת. ניתן לראות את היתרות עבור כל מספר אצווה של חלק החילוף הנבחר באמצעות קישור הניווט בצד ימין.

פרשנות מומחה: בפגישה זו (מודול) הופיעה לראשונה חשבונאות אצווה. המשתתפים נדרשו לתת דין וחשבון על חומרים מתכלים וסחורות לא רק בעצמם, אלא גם לפי אצווה. באופן כללי, המשימה מושלמת עבור פלטפורמת 1C:Enterprise - אבל הכל היה צריך להיות מפותח מאפס ולהסתיים תוך 2.5 שעות.

מפגש 5

בפגישה החמישית הוקצתה לנו הפונקציונליות של ניהול בארות. עבור קבוצות חיפוש, היה צורך ליצור אפליקציה ניידת שתתחשב בארות הפקת נפט או גז. כאן היה צורך לקבל רשימה של בארות שוטפות מהשרת ולהציג את הבאר שנבחרה בצורה גרפית לפי שכבות (אדמה, חול, אבן, שמן), תוך התחשבות בעומק של כל שכבה. בנוסף, האפליקציה הייתה צריכה לאפשר עדכון מידע על הבאר והוספת בארות חדשות. עבור אפליקציה זו הלקוח קבע תנאי הפעלה מיוחדים במצבי Offline ו-Online (שליטה בתקשורת עם השרת) - בדיקת תקשורת עם השרת כל 5 שניות ושינוי פונקציונליות האפליקציה בהתאם לזמינות השרת.

סיריל: כאשר אתה בוחר באר, מוצג גרף עמודות, המדגיש את השכבות עד למרבצי הנפט או הגז. עבור כל שכבה מאוחסנים השם, הצבע וטווח המופעים שלה. בשל תכונות העיצוב, הדיאגרמות המובנות בפלטפורמה אינן עוזרות, אך מסמך הגיליון האלקטרוני מתמודד עם המשימה בצורה מושלמת. ניתן ליצור ולשנות בארות:

מלבד הגנה מרובת תקלות, לא היה שום דבר מעניין בטופס הזה.
לאחר מכן, הוצע לשלוט בחיבור לשרת. אנחנו מנסים להתחבר כל 5 שניות. אם זה לא עובד, אנו מגבילים את הפונקציונליות של האפליקציה ומציגים הודעה.

פרשנות מומחה: המשימה של הפעלה זו מעניינת בעיקר בשל היכולות הגרפיות שלה. משתתפים שהשתמשו בפלטפורמת 1C:Enterprise פתרו את זה בשתי דרכים שונות - חלקם באמצעות מנגנון דיאגרמה, אחרים באמצעות מסמך גיליון אלקטרוני. לכל שיטה יש את היתרונות והחסרונות שלה. כחלק מההחלטה באליפות WorldSkills, הזמן היה המפתח (זכור שוב את מגבלת הזמן). משימה מעניינת נפרדת היא לעשות פינג לשרת כל 5 שניות ולשנות את התנהגות האפליקציה לנייד בהתאם לזמינות או חוסר הזמינות של השרת.

מפגש 6

הוצע ליצור מרחב עבודה לניהול העליון - לוח מחוונים. במסך אחד היה צורך להציג את מדדי הביצועים הכלליים של החברה לתקופה מוגדרת בצורה גרפית וטבלאית. הטופס העיקרי הוא דוח העלות:

בנוסף ללוח המחוונים, היה צורך ליישם חלוקה של חלקי חילוף לתיקוני נכסים באמצעות שיטות מחיקה של FIFO/LIFO/"הזול הולך קודם".

במהלך ההפצה נלקחה בחשבון חשבונאות אצווה, נעשה שימוש בבקרת איזון והגנה מפני פעולות משתמש לא מורשות ("הגנה על שוטים").

סיריל: כדי לפתור, נעשה שימוש בטבלאות ערכים עם יצירת עמודות בתוכנה, מכיוון שיכול להיות מספר שרירותי שלהן:

• הטבלה הראשונה אחראית על סך העלויות של המחלקות לפי חודש. החטיבות הלא רווחיות והרווחיות ביותר מסומנות באדום וירוק, בהתאמה.
• הטבלה השנייה מציגה את החלקים היקרים והנפוצים ביותר עבור כל חודש. אם ישנם מספר חלקים העומדים בקריטריונים, אז הם צריכים להיות מוצגים בתא אחד, מופרדים בפסיקים.
• הנכסים היקרים ביותר (במונחים של עלויות חלקי חילוף) מוצגים בשורה הראשונה של הטבלה השלישית. השורה השנייה מציגה את החטיבה שאליה שייך הנכס שלמעלה. אם יש שני נכסים יקרים ביותר עם אותן עלויות, אז הם צריכים להיות מוצגים באותו תא, מופרדים בפסיקים.

התרשימים הוצגו באמצעות המנגנונים המובנים של הפלטפורמה, ומולאו באופן תכנותי באמצעות שאילתות.

כמו כן הוצע ליישם תמיכה בריבוי לשוניות. התוכנה טוענת קבצי XML עם לוקליזציה של רכיבי ממשק, ויש לצייר מחדש את הטופס בעת בחירת שפה ברשימה הנפתחת.

כאשר תלחץ על הכפתור בפינה השמאלית התחתונה של המסך, טופס ניהול המלאי נפתח:

בטופס הזה, סוף סוף אנחנו מתחילים לבזבז חלקים על תיקונים. כאן אנו מוצאים תחילה את החלקים שנצטרך לתיקון הנכס. בהתבסס על השדות שנבחרו ושיטת ההפצה (FIFO, LIFO או מחיר מינימום), מוצגות ההתאמות שנמצאו או הודעה אם אין התאמות. לאחר מכן תוכל לסמן את החלקים כמי שנועדו לתקן את הנכס הזה. בקרת איזון רלוונטית להפעלה הנוכחית. אם כבר הקצינו פרטים, אז לא ניתן עוד למצוא אותם.

פרשנות מומחה: מפגש מעניין מאוד. זה מנצל את היכולות של פלטפורמת 1C:Enterprise - כאן יש עבודה מוכשרת עם טבלאות וירטואליות של אוגרי צבירה, ועבודה פרוגרמטית עם אלמנטים של טופס (קודם כל - טבלאות, שנית - כותרות), ודיאגרמות. ואפילו LIFO/FIFO בעת ניתוח מלאי, ניתוח רווח/הפסד וכו'.

מפגש 7

בתום המשימה (מפגש 7) סיפק הלקוח תוכנה (קובץ exe) לפעילות הפרויקט וסרטון קצר על העבודה איתה. היה צורך לבצע הנדסה לאחור ועל בסיס זה ליצור 2 דיאגרמות: דיאגרמת מקרי שימוש ודיאגרמת יחסי ישות. בנוסף, הועלו כמה דרישות ליצירת תוכנה בעתיד - היה צורך ליצור פריסת ממשק לפי דרישות אלו.

על פי תנאי התחרות, רק MS Visio נדרשה ליצור דיאגרמות.

פרשנות מומחה: בהפעלה זו, היכולות של פלטפורמת 1C:Enterprise כמעט ולא נוצלו. ב-MS Visio נוצרו דיאגרמות לתנאי התחרות. אבל אב טיפוס של הממשק יכול להיווצר בבסיס מידע 1C ריק.

הערות כלליות

בתחילת כל סשן, הוצע לייבא נתונים באמצעות סקריפט SQL. זה היה החיסרון העיקרי בשימוש ב-1C בהשוואה ל-C#, מכיוון שהקדשנו לפחות חצי שעה בזיקוק נתונים למקורות נתונים חיצוניים, יצירת טבלאות משלנו והעברת שורות ממקורות חיצוניים לטבלאות שלנו. השאר רק היו צריכים ללחוץ על כפתור הביצוע ב-Microsoft SQL Studio.

מסיבות ברורות, אחסון נתונים במכשיר נייד אינו רעיון טוב. לכן, במהלך הפעלות ניידות יצרנו בסיס שרתים. הם אחסנו שם נתונים וסיפקו להם גישה באמצעות שירותי http.

פרשנות מומחה: מאזן 1C/non-1C מעניין כאן - בעוד שמתכנתי 1C:Enterprise השקיעו זמן משמעותי בחיבור ל-DBMS חיצוני (Kirill הזכירה זאת בנפרד למעלה), מפתחי C#/Java (אנדרואיד סטודיו לפיתוח נייד) בילו זמן בתחומים אחרים - ממשקים, כתיבת קוד נוסף. לכן, התוצאות של כל מפגש היו בלתי צפויות ומעניינות ביותר עבור כל המומחים. והאינטריגה הזו נשארה עד הסוף - רק תסתכלו על טבלת המנצחים הסופית עם חלוקת הנקודות.

קיריל סיימה את הסיפור :)

לסיכום, יש לזכור שהמבצע לא היה צריך "רק לתכנת את המשימה לפי המפרט הטכני" - הוא היה צריך לנתח את המשימה, לבחור בלוקים ליישום המשימות, לעצב אותן ולהחליט מה בדיוק הוא יהיה. מסוגל ליישם מזה בזמן הקצר ביותר. כל 4 הימים נאלצתי לפעול תחת לחץ זמן חמור, ולעתים קרובות התחלתי כל פגישה שלאחר מכן מאפס. גם מומחה מבוגר בעל ניסיון רב שנים בענף יתקשה מאוד לבצע את המשימה שהוטלה על הפגישה ב-100% בזמן המוקצב.

מערכת ההערכה המאומצת ראויה לציון מיוחד.

עבור כל מפגש מפתחים עורכי המשימות מערכת קריטריונים מורכבת, הכוללת בדיקת פונקציונליות, תפעול נכון, דרישות לממשק האפליקציה, ואפילו ביצוע מדריך סגנונות שניתן במיוחד למשתתפים על ידי החברה שעבורה הם מפתחים את הפתרונות שלהם.

קריטריוני ההערכה הם מפרט היטב - כאשר העלות הכוללת של משימת הפגישה היא עשרות נקודות, מילוי קריטריון כלשהו יכול להוסיף עשיריות הנקודה למשתתף. כך משיגים רמה גבוהה ואובייקטיבית ביותר של הערכת התוצאות של כל משתתף בתחרות.

ממצאים

התוצאות הסופיות היו מרשימות.

במאבק מר ניצח קיריל פאבקין מרוסיה, שהשתמש בפלטפורמת 1C:Enterprise. קיריל בן 17, הוא מסטברופול.

ממש עשיריות הנקודה הפרידו בין המנצח לבין רודפיו. את המקום השני תפס משתתף מטייוואן. הטבלה הכוללת של שש התוצאות המובילות נראית כך:

כמובן, קיריל ניצח בזכות הכישרון, הידע והכישורים שלו.

עם זאת, נציין כי כל שלושת המשתתפים שהשתמשו בפלטפורמת 1C:Enterprise ככלי נכללו בחמישייה המובילה - המהווה אישור ללא תנאי לרמה העולמית של טכנולוגיית 1C:Enterprise.

בעקבות תוצאות התחרות הוענקו הזוכים במרכז המדיה KazanExpo, החבר'ה קיבלו מדליות זהב טהורות (בהתאם למקומם) ופרסים כספיים. החבר'ה קיבלו גם תעודות המאפשרות להם לעבור התמחות ב-1C.

מקור: www.habr.com