מתי לשדרג גרסת MOODLE?

25/05/15

מתי לשדרג את ה MOODLE שלכם?

 

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

 

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

 

נפתח במידע כללי על גרסאות MOODLE ותוספיהם:

 

גרסאות  מוודל

גרסת על (טרמינולוגיה אישית שלי, לא מבית MOODLE)  -גרסאות  MOODLE כמקובל בסימון גרסאות, התחילו בגרסת על 1.0 בשנת 2002, גרסת על 2.0 יצאה בשנת 2008 וגרסת על 3.0 צפויה לצאת בנובמבר 2015, כך שגרסת על יוצאת אחת לשש שנים בערך.

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

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

נכון להיום איננו מזהים כי המעבר מ 2 ל 3 ייצור מורכבויות ושינויים כה משמעותיים.

 

גרסא מזורית יוצאת אחת לחצי שנה - הגרסאות המזוריות (X.1, X.2 וכו) על פי רוב נותנות שני מרכיבים מרכזיים:

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

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

ישנם גרסאות מזוריות שגורמות למורכבות מיוחדת בשדרוג.

 

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

• אבטחה

• באגים

טבלה הממחישה התקדמות הגרסאות ב MOODLE

תוספים וגרסותיאהם

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

תוספים אלו ברובם עולים לאתר MOODLE ומתחלקים ל 20 קטגוריות שונות.

להלן מספר קטגוריות חשובות של תוספים , בסוגריים מספר התוספים הקיים כיום בקישור

Blocks - בלוקים- משבצות (253)

Activities - פעילויות (269)

Themes - ערכת עיצוב (118) חלקם רספונסיביים.

Course formats - עיצוב קורס - פורמט קורס (25)

( General plugins (Local  - תוספים כלליים - ליתר פירוט עיין כאן (84)

Reports - דוחות (25)

Gradebook- לוח ציונים (13)

Users - ניהול משתמשים(65)

 

הנכם מוזמנים לקישור לראות את מלוא התוספים האפשריים

דילמת התוספים -

קיימות מספר בעיות הנצבות בפני הלקוח כאשר הוא מעוניין בהוספת יכולת מסויימת למערכת, הראשונה היא האם כבר מישהו מימש זאת כתוסף? במידה וכן גם אז יש לבדוק האם זה מומש באופן עליו "חלם" הלקוח, יתר על כן האם התוסף מתוחזק? האם הוא יפותח גם לגרסאות הבאות? האם הוא קיים כ RTL (עבור עברית)? האם הוא כבר תורגם?

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

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

 

שינויים יזומים

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

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

פיתוח מודולרי (ללא נגיעה בקוד מקור , למעט מקרי קיצון)

ניהול שלוש סביבות מקבילות: פיתוח (במידה ויש), טסט, פרודקשין,

ניהול המערכות המקבילות וניהול הגרסאות במערכת כדוגמת GIT

 

להלן סוגי שינויים שונים נדרשים על יד לקוחות:

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

סנכרונים - הסנכרונים הם לרוב מול מערכות מנהל תלמידים, CRM למיניהם, מערכות משאבי אנוש ERP כגון SAP.

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

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

עיצוב - לקוחות רבים מעוניינים בעיצוב משלהם הכולל בניית CSS מותאמים לרצון הלקוח.

פרמטרים לשקלול לקבלת החלטת שדרוג

 

• הלקוח - אופי הארגון, מורכבות תוך ארגונית.

• כמות משתמשים - כמות משתמשי הקצה, מרצים/מדריכים , מנהלי מערכת.

• חומרה - מיקום השרתים: אצל הלקוח, בענן OPENAPP, בענן אחר, כמות שרתים, קונפיגורציה.

• תוספים מובנים - כמות התוספים וסוגיהם שהותקנו במערכת הלקוח מתוך התוספים המובנים הקיימים

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

• שינויי קוד מקור - שינויי קוד מקור שבוצעו לפי בקשת לקוח במקרי קיצון.

• ממשקי הזדהות - האם יש ממשקי הזדהות מול LDAP וכדומה?

• ממשקי סנכרון  - לאן מתממשקת המערכת? אופן הסנכרון: WS או שיטה אחרת וכו, SSO

• עיצוב - האם נעשה עצוב מיוחד כולל THEME מיוחד

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

• ניהול המערכת: האם המערכת מנוהלת נכון כגון על יד GIT (אם זה לא היה אצלנו)

• שילוב מערכות שונות - כגון KALTURA או BBB ועוד

• שימוש בסביבות DEV טסט פרודקשין.

• יציבות גירסא שיצאה, נשתדל לא לשדרג לגירסא מז'ורית X.0

• שיטות ניהול שנים/מחזורים בארגון

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

 

אני מקווה שבלוג זה הוסיף לך להבנה ולקבלת החלטה בנושא שדרוג גרסא האם ומתי?.