מדריך זה, דן בפיתוח מערכות מידע העושות שימוש בפרוטוקול TCP/IP, תשתית תקשורת האינטרנט ובמגוון הטכנולוגיות והיישומים הלקוחים מעולם האינטרנט, הן של מערכות אינטרנט (Internet) והן של מערכות אינטראנט (Intranet). המטרה הראשית של המדריך היא להציג טכנולוגיה זו ויישומיה ולהדגיש את השפעתם על רכיבי עץ המערכת (השפעה אנכית) ואת אפשרות שילובם במחזור חיי המערכת (השפעה אופקית).
מדריך זה, דן בפיתוח מערכות מידע העושות שימוש בפרוטוקול TCP/IP, תשתית תקשורת האינטרנט ובמגוון הטכנולוגיות והיישומים הלקוחים מעולם האינטרנט, הן של מערכות אינטרנט (Internet) והן של מערכות אינטראנט (Intranet). המטרה הראשית של המדריך היא להציג טכנולוגיה זו ויישומיה ולהדגיש את השפעתם על רכיבי עץ המערכת (השפעה אנכית) ואת אפשרות שילובם במחזור חיי המערכת (השפעה אופקית). בעקרון, אינטרנט מהווה טכנולוגיית בסיס ולא מערכת עצמאית. בד"כ אין מדובר במערכת אינטרנט אלא מערכת בעלת ממשק Web הכוללת אוסף טכנולוגיות ויישומים שונים.
ניתן לחלק את המערכות השונות למספר סוגים ראשיים:
· אתרי אינטרנט - מערכת המכילה מגוון יישומים על גבי ה-web שעיקרן הפצת מידע ושיתוף פעולה (Collaboration) באופן רוחבי, בין משתמשים רבים ומבוזרים בתוך הארגון ו/או מחוצה לו.
· רכיב Web למערכות מידע קיימות – הוספת תת מערכת אינטרנט למערכת מידע קיימת.
· מערכות מידע כלליות בעלות ממשק Web - פיתוח מערכת מידע חדשה בעלת ממשק web.
לבניית מערכת בטכנולוגיית האינטרנט מספר מאפיינים ודגשים מרכזיים ויחודיים:
· שכבת Client דקה- הממשק למשתמש
· שימוש מרבי בטכנולוגיות קיימות
· תשתיות
· עמידה בתקני פיתוח בינלאומיים
שימוש בכלי אינטרנט בצד הלקוח (client) על מנת לצמצם ככל האפשר את מגוון ממשקי הקצה בארגון והחלפתם בממשק דפדפן (browser), כאשר כל העבודה נעשית בשרתים באמצעות קווי התקשורת.
ריבוי השימוש בתוכנות מדף זמינות וכלי אינטרנט מקובלים כגון דואר אלקטרוני, ניהול קבוצות דיון וכו', לביצוע פעולות הקשורות בהעברת מסרים ושיתוף (collaboration) בין אנשי הארגון, החל מתיאום יומנים וכלה בעבודה אינטראקטיבית מתואמת של מספר אנשים על מסמך משותף, תוך העברת טקסט, גרפיקה, קול ווידאו ביניהם.
הגורמים הטכנולוגיים והכלכליים המשפיעים על מערכות אינטרנט מורכבים ומשתנים כל הזמן. מוצרים חדשים מוכרזים חדשות לבקרים. יש לבחון בקפידה את מכלול הטכנולוגיות הקיימות (והעתידיות) בתחום, ועם זאת לזכור שבסופו של דבר לב הבעיה אינו בטכנולוגיה, אלא בהגדרה ברורה של היעדים, ביישום, במימוש ובעלות/תועלת.
על הארגון לקבל החלטה האם להקים תשתיות אינטרנט עצמאיות או להשתמש בתשתיות של ספק חיצוני לארגון. להחלטות אלה השפעה מכרעת על עומק הפרוט הדרוש בתיעוד במהלך הפרויקט ועל קיצורי דרך נוספים.
מערכות אינטרנט בעלות ממשקים למגוון רב של מוצרים, חייבות להתייחס לתקנים וסטנדרטים בינלאומיים כגון אלו של איגוד האינטרנט העולמי (W3C).
יש לקבל החלטה על סוג המערכת המיועדת לפיתוח:
· תדמית הארגון – מידע כללי וקידום מכירות
· פורטל ארגוני ומאגר ידע (כולל תמיכה בשיתוף ידע, קבוצות עבודה וכו')
· מערכת מידע קלאסית: מכירות, רכש, מלאי וכו', פנימית או חיצונית
בנוסף, יש לקבל החלטה מקבילה על רמות השילוב בעץ המערכת, ייעוד המערכת והיקפה. ע"פ תיחום זה, תתקבל החלטה כוללת לגבי המודל הניהולי של פיתוח הפרויקט והאם להקים תשתיות אינטרנט עצמאית או להשתמש בתשתיות של ISP (Internet service provider) - ספק חיצוני לארגון. להחלטות אלה השפעה מכרעת על עומק הפירוט הדרוש בתיעוד במהלך הפרויקט.
שיקולים ניהוליים ועסקיים לפיתוח מערכות בטכנולוגית האינטרנט הם:
· איחוד ממשקי הקצה לממשק אחיד - פתרון בעיות בהתקנת מבחר כלים, הורדת עלות הדרכה למשתמשים, מניעת הצורך בעדכון גרסאות לכל יישום, קלות תפעול ועוד.
· מערך מידע בעל תפוצה נרחבת - טכנולוגיית אינטרנט מקילה על הפצת היישום ברשתות גדולות ומורכבות ובנויה לעבודה ברשת רחבה (WAN) האיטית יחסית.
· הפצת מידע טקסטואלי משולב מדיה - טכנולוגיית אינטרנט מתאימה במיוחד להפצת חומרים המשלבים טקסטים, מדיות כגון תמונה צליל ווידאו המקושרים ביניהם (כגון: ספר נהלים, ספר שירות, מדריכים שונים, מערכי הדרכה וכו').
· שיתוף מידע/פעולה בין משתמשים - שימוש בכלי Collaboration מאפשר הידוק שיתוף הפעולה והתיאום בין גורמים שונים, מקצר תהליכים ומייעל את עבודת הארגון המפוזר בד"כ בשטח גיאוגרפי נרחב.
· הורדת דרישות החמרה מתחנות הקצה - עם המעבר לסביבת אינטרנט ניתן להוריד את הדרישות ממחשב הלקוח אשר כל שהוא נדרש לעשות הוא להריץ את תכנת הדפדפן (Internet Browser).
· הגדלת פלח ו/או נתח שוק.
· הרחבת החשיפה בשוק מקומי ובשוק הבינלאומי ללקוחות.
· ייעול תהליך השליטה ובקרה, ניהול המידע ממקום אחד מרוכז.
· צמצום עלויות לחברות המנהלות מאגרי מידע.
האתגרים בפיתוח מערכות אינטרנט בקנה מידה גדול הם:
· אמון ותמיכה מתמשכת במשתמשים רבים מאוד.
· תמיכה בחיפוש ואיתור מידע.
· ריבוי פלטפורמות ומערכות.
· שמירה על רוחב פס מתאים.
· התייחסות מוגברת לתחום אבטחת המידע והרשת.
· יכולת גדילה וקצב גדילה של מידע ומשתמשים.
· ניהול תצורה.
· פיתוח תוך כדי שינוי מתמשך של דרישות וטכנולוגיות.
· תחזוקת שוטפת של המערכת.
· שימור השקעות העבר - שפת התכנות הנפוצה ביותר בעולם היא עדיין שפת cobol עם השקעות עצומות שנעשו במהלך שנים רבות.
שימוש בטכנולוגית אינטרנט מערב מספר רב מאוד של כלים. כלים אלה הם רובם ככולם כלי מדף הפועלים מול שרתים מרכזיים אשר מריצים תכנת שרת מתאימה. תוכנות השרת הנן ברובן תכנות מדף סטנדרטיות עם ממשקים פתוחים או ייעודיים למערכות נוספות .
לשימוש בכלי אינטרנט השפעות על תחום נרחב של טכנולוגיות בארגון ובעיקר על התחומים הבאים:
· שרתים
· עברית
כיוון שכלי הקצה הינו כלי צפייה בלבד, כל שאילתה/פעולה מבוצעת על ידי השרת - Application Server, כך שעצמתו צריכה להיות גבוהה מאוד. יש מקום לשקול חלוקת עומסים, בפרט במערכות גדולות, בין מספר שרתים. לדוגמא: שרת Database, שרת היישום ומס' שרתי אינטרנט, בנוסף ניתן לחלק עומס בין שרתים בצורה שקופה למשתמש הפונה לשרת וירטואלי יחיד.
לרמת זמן התגובה של יישומים יש חשיבות קריטית. במידה וקיים צורך בהעברה מסיבית של תמונה, וידאו או צליל יש צורך בתגבור קווי ה- WAN ורשתות ה- LAN בהתאם לעומס. (ראה קיט רשתות תקשורת בכרך נושאים תומכים).
תחום העברת המידע ברשת האינטרנט ואבטחתו הינו בעייתי ביותר. יש לבחון את הנושא במונחי עלות/תועלת.
מרבית כלי האינטרנט מבוססים על טכנולוגיית חלונות Microsoft Windows תוך שימוש בפרוטוקול TCP/IP. בפיתוח מערכות אינטרנט הפתוחות לציבור הכללי יש לקחת בחשבון מהדורות שונות וסוגים שונים של מערכות הפעלה ודפדפנים.
לא כל כלי האינטרנט הקיימים תומכים בשפה העברית בצורה מלאה. אי לכך יש לבחון בזהירות את הכלים בהם משתמשים.
הדינמיות בשוק כלי הפיתוח רבה ומשפיעה מאוד. כלי פיתוח שהיה בעבר להיט פתאום הופך למיושן ושולי, או אפילו נעלם. חשוב לאמץ סביבת פיתוח וותיקה ונפוצה עם גב חזק.
קיימת דינמיות מסויימת. יתכן ומוצר שהיה בעבר להיט פתאום הופך למיושן ושולי. בסיסי הנתונים הבולטים היום בשוק הם Oracle ו- SQL Server.
קיימת דינמיות רבה. כאשר טכנולוגיות חדשות תומכות רק בשפות תכנות חדשות. יש מקום לבחון את הכלים השונים ומגמות התפתחותם.
קיימת דינמיות בהעדפות ומגמות השימוש במערכות ההפעלה UNIX, Windows , Linux.
חשוב לבחור בסביבת פיתוח המסוגלת להשתלב בסביבת הדואר האלקטרוני הקיים בארגון.
מתודולוגית פיתוח וניהול מערכות אינטרנט מאופיינת לרוב ע"י כתיבת אפיון-על אסטרטגי, תוך הוספה הדרגתית של רכיבים, סבבי פיתוח מהירים והתבססות חזקה על כלי מדף בעלי טכנולוגיה משתנה. לאור זאת, מומלץ כי ניהול הפיתוח יעשה במתודולוגית המודל הספיראלי בהתאם לשלבי מחזור החיים של נוהל מפת"ח.
.jpg)
המרחק קצר יחסית בין האפיון ובין מימוש המערכת. הדבר מאפשר סבבי פיתוח קצרים בהם המשתמש מגיב ומאשר את יחידת המסירה.
שלב מתבקש במהלך פיתוח פרויקט מבוסס אינטרנט הינו מימוש אב טיפוס אבולוציוני במטרה להגביר את שקיפות המערכת (Transparency), את רמת שיתוף המשתמש/לקוח ואת יכולת המחשת המערכת מבחינת הממשק למשתמש ופונקציונאליות. (ראה קיט אבטיפוס – Prototyping בכרך נושאים תומכים).
תהליך פיתוח מערכת אינטרנט מחייב בחינה מתמדת של טכנולוגיות,יכולות וכלים חדשים תוך ביצוע בחינת חלופות ובחינת התאמת מוצרים לפרויקט. (ראה קיט ניתוח חלופות בכרך נושאים תומכים).
שלב זה איננו שונה במהותו מייזום של כל פרויקט אחר. הנהלת הארגון רשאית, כמובן, להחליט שמערכת זו דחופה במיוחד וליצור את הקשר בינה ובין תוכנית העבודה השנתית המאושרת, בכל דרך שתמצא לנכון. מה שחשוב הוא להגדיר היטב את סוג המערכת, תיחומה והיקפה, כולל קהל היעד והשירותים המתוכננים, לפי הפרמטרים והמאפיינים שהוסברו בסעיף מבוא - הסבר כללי לעיל.
לעתים נדירות, יכלול הייזום גם המחשה כלשהי בצורת דגם (קונספט מוחשי \ חזותי). רצוי לא להשקיע בדגם חי בשלב זה ולהסתפק בהפניות לאתרים ומערכות אינטרנט קיימות בין בארגון ובין מחוצה לו.
האפיון ישמש מעין תוכנית אב או תוכנית אסטרטגית לפיתוח הפרויקט. דגש מיוחד באפיון יושם על תיאור הדרישות הכלליות של המערכת: חלוקה ליחידות מסירה (תת מערכות, נושאים) והגדרת רכיבים (תשתיות ותקנים) המשותפים לכלל המערכת (לכל יחידות המסירה והנושאים הידועים והעתידיים). תשתיות אלה כוללות, בין השאר:
· סטנדרטים של ממשק המשתמש (UI), כולל שיטת הניווט הכללית
· סכימה כללית של כל בסיס הנתונים
· ארכיטקטורת הפתרון של המערכת: יישום וטכנולוגיה
· ניהול המשתמשים ואבטחת המידע
· מענה לעומסים משתנים ובלתי חזויים
· קישוריות וממשקים עם מערכות אחרות
המטרה היא שיקוף ראייה מערכתית שתאפשר אינטגרציה נוחה של יחידות מסירה אשר יתווספו בהמשך.
שלב האפיון יכול להיות מלווה בהקמת אב טיפוס (דגם) אשר יאפשר המחשה של המערכת ובחינת התאמת מוצרי מדף לדרישות.
במקביל, תוגדר תכנית פיתוח ואיכות (רכיבים 1,4,5 בעץ המערכת). התכנית תקבע את הפעילויות הנדרשות למימוש הפרויקט, ניהולו ומעקב אחר הביצוע.
אין הבדלים עקרוניים בשלב זה בהשוואה למערכות מידע אחרות. אין להעדיף ספקים המתמחים באינטרנט או לנהל מכרז סגור. מגוון הספקים והפתרונות לטכנולוגיית האינטרנט (ואינטראנט) הוא רחב דיו. ההחלטה על סעיפי סף, משקלות ויחס עלות/תועלת תידון לגופה.
שלב עיצוב ובנייה תלוי בהחלטות שנתקבלו בשלבים הקודמים, בפרט באפיון ובבקשה להצעות. אם הוחלט על פיתוח מערכת המבוססת על מערכות מדף קיימות, יהיה שלב זה קצר יחסית. כל החלטה אחרת, גם החלטה על ביצוע של מערכת מעטפת פשוטה המפעילה יישומי מדף בממשק אחיד מחייבת ביצוע שלב זה כמקובל.
החלטה אחרת היא פיתוח סדרתי או פיתוח בסבבים (יחידות מסירה). פיתוח בסבבים כולל שלושה מסלולי פעולה ותיעוד:
· אפיון, עיצוב, בניה ובדיקות לכל יחידת מסירה/מהדורה. במידת הצורך (והיכולת) ייכללו בכל סבב כזה (פיתוח יחידת מסירה) גם ניתוח חלופות ופנייה לספקים.
· עדכון שוטף של תכנית הפיתוח והאיכות וניהול הסיכונים.
· תיק מערכת לפרויקט המתעדכן באופן שוטף וכולל בתוכו את הסעיפים הכלליים וכן תוכנית פיתוח ואיכות (פרקים 1,4,5). במידה ויש שינוי בטכנולוגיה או צורך בהרחבה – יש לפרט זאת בפרק 3.
בדיקות מערכת ובדיקות קבלה של חבילות ישומים מוכנות נראות לעיתים מיותרות, אך לא כל חבילת תוכנה שעבדה כהלכה אצל היצרן או בהדגמות אכן תעבוד בצורה המצופה על חומרה הקיימת בארגון או על התשתית הקיימת בארגון. הדבר נכון במיוחד אם בחבילות בוצעו שינויים כדי להתאימן לדרישות הלקוח ואפילו שינויים אלו היו פרמטריים בלבד.
יש להשקיע כמובן זמן רב יותר בבדיקות קטעי הקוד שנכתבו ע"י הפרויקט, בבדיקות אינטגרציה של חבילות תוכנה שונות, האחת לשניה, וגם של כל חבילות התוכנה לתשתית הארגונית הקיימת או זו שהוקמה במיוחד לצרכי המערכת.
במידת הצורך והרלוונטיות, יש לערוך את הבדיקות לכל מערכת הפעלה וסוגי הדפדפנים הנדרשים. כמו כן, יש להקדיש מאמץ מיוחד בביצוע בדיקות עומסים, בדיקת זמני תגובה, בדיקת אבטחת המידע ובדיקות אמינות ושרידות.
אין שינוי בשלב זה לעומת המוגדר במחזור החיים הגנרי של מפת"ח.
אין הבדלים עקרוניים בשלב זה בהשוואה למערכות מידע אחרות. יש להקפיד על ניהול שינויים מסודר (מהדורות, Patch) למרות הקלות היחסית של הכנסת שינויים.
הוספת יחידת מסירה נוספת למערכת, כמוה כניהול תת פרויקט הכולל את כל שלבי מחזור החיים. כלומר כתיבת אפיון, עיצוב, בניה ובדיקות לכל יחידת מסירה/מהדורה. במידת הצורך ייכללו ניתוח חלופות ומפרטי RFP.
יש לשים דגש רב על ניהול תצורה במודל זה, כאשר בו זמנית מנוהלות מספר סביבות עבודה לכל יחידת מסירה.
שלב הפיתוח המתחיל באפיון המערכת ומסתיים בתחזוקתה יחזור על עצמו בכל יחידת מסירה.
תוצר התיעוד המרכזי של מערכת אינטרנט הוא תיק מערכת אשר מתגלגל לאורך מחזור החיים: מסמך ייזום, תיק אפיון, בקשה להצעות (אם יש פנייה לספקים), תיק עיצוב וכו'. תיק המערכת בנוי על בסיס עץ מערכת ייחודי (מתמחה) אשר מותאם לאתרי אינטרנט. רמת הפירוט של הגלופה נקבעת על פי השלב במחזור החיים בו נמצאת המערכת/האתר.
תחילה, יש לקבל החלטה על סוג האתר המיועד להקמה ורמת השילוב בעץ המערכת, יעוד המערכת והיקפה. ע"פ תיחום זה, תתקבל החלטה לגבי המודל הניהולי של הפיתוח והחלטה האם להקים תשתיות אינטרנט עצמאיות או להשתמש בתשתיות של ספק חיצוני לארגון. להחלטות אלה השפעה מכרעת על עומק הפרוט הדרוש בתיעוד במהלך הפרויקט ועל קיצורי דרך נוספים.
במהלך פיתוח פרויקט מבוסס אינטרנט מתבקש פיתוח אב טיפוס אבולוציוני (Mock up) במטרה להגביר את שקיפות המערכת (Transparency), את רמת שיתוף המשתמש/לקוח ואת יכולת המחשת המערכת מבחינת הממשק למשתמש ופונקציונאליות.
ראה קיט אבטיפוס – Prototyping בכרך נושאים תומכים.
בחירת גורם חיצוני לאפיון האתר (יועץ) היא בעיקרון בקשה להצעות לכל דבר ויש לפעול כמוגדר בקיט בקשה להצעות. היינו, להכין מפרט ומפ"ל, להגיש את המפרט לספקים (יועצים) מועמדים, לבדוק את הצעותיהם, לבחור בהצעה העדיפה ולהתקשר עם היועץ שנבחר. יש להימנע מסיבוך התהליך ולזכור שמדובר בשלב מכין לפני המכרז המרכזי, היינו, בבחירת הגורם שיבנה את האתר. יש לזכור שאפיון הוא פרויקט בפני עצמו, אשר משפיע מאד על כל המשך הפרויקט העיקרי ועולה הרבה משאבי זמן וכסף ואי לכך יש להפקידו בידיים נאמנות. בפועל, ניתן לפשט את תהליך בחירת היועץ בלי לוותר על עקרונות מכרז מסודר, כמוסבר להלן.
מפ"ל מגדיר את אופן בדיקת ההצעות וסיכומן. תפקיד המפ"ל להנחות את צוות הבדיקה בעבודתו, להסדיר מראש את הפרמטרים העיקריים של תהליך בדיקת הצעות ספקים (אמות המידה והקריטריונים להשוואת ההצעות) ולמנוע מצב בו פרמטרים אלה נקבעים במהלך הבדיקה. מפ"ל מגדיר נושאים כמו:
· תנאי סף
· סולם הציונים
· משקלות
· תבחינים
· אופן סיכום והצגת התוצאות לפני הגורם המחליט
בביצוע אבטחת איכות וקביעת מדדים לפרויקטי פיתוח ותחזוקה למערכות אינטרנט, מומלץ לשים לב לנקודות הבאות:
· בדיקת מימוש התכולה המתוכננת
· בדיקת התאמת היישום לצרכי הלקוח
· בדיקת רמת העומסים וביצועי המערכת
· בדיקת כמות ואופי השינויים הנדרשים ע"י הלקוח
· מדידת השקעת זמן פיתוח בסבב הפיתוח הראשון ובסבבי הפיתוח הנוספים
· משאבי כ"א שהושקעו בפיתוח
· מדידת עלויות הפיתוח ( חומרה, תוכנה, נסיעות הכשרה וכד')
· עלויות התפעול, הדרכה, ותמיכה.
· מספר סבבים
· משך כל סבב
· אופן הטיפול בניהול סיכונים
· לוחות זמנים – ביצוע מול תכנון
· ניהול ומעקב אחר משימות במהלך הפרויקט
· סקרים, שיקופים וציוותי עבודה.
· מעורבות מומחה היישום
· מדידת כמויות וסוגי התקלות בזמן הבדיקות ובתחזוקה שוטפת
· שימוש בניסיון שגובש במערכות קודמות / פרויקטים אחרים בארגון
· שימוש בתקנים
· תדירות עדכון ( או אי עדכון) תיק המערכת
· תכנית בדיקה המערכת והדגם המתגלגלים מתגלגלת במקביל לתיק
· תהליך בחירת טכנולוגיית התשתית
· תהליך בחירת טכנולוגיות היישום
· סוגי תחנות קצה (דפדפנים) נתמכים