לאתר Netwise | חזרה לעיתון

ניתוח מערכות - כלי חיוני לתוכנות בריאות
מאת אור עד-שניידר, מנתחת מערכות בחברת Netwise

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

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

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

• מהות המערכת
• הקשרים של המערכת עם מערכות אחרות
• התהליכים שיש במערכת
• מאגרי המידע של המערכת

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

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

ניתוח מערכות From Scratch
DFD, UML, נוהל מפת"ח הן רק חלק מהמתודולוגיות שנבנו לטובת ניתוח מערכות. אך אף מתודולוגיה לא עונה על כל הצרכים וכמובן שלא קיימים אנשי ביטחון שיבצעו מעקב אחר שימוש נכון בסטנדרטים. בדרך כלל שילוב של מתודולוגיה אחת עיקרית עם מתודולוגיה או שתיים נוספות זה המתכון הכי מוצלח. נכון להיום מומלץ להשתמש ב- Unified Modeling Language) UML).
אחרי שלב התחקור הראשוני של משתמשים קיימים ועתידיים, מסמכים שנכתבו, מערכות מעורבות ואנשי UI שכבר עשו את רוב התחקיר, כדאי לכם ליצור:

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

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

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

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

• במסמך word עבור רשימת השחקנים,
• בתוכנות Visio Poseidon ,Rational Rose או Smart Draw לכל השאר.
  בשלושת הכלים הראשונים ניתן להמיר את תרשים המחלקות לשורות קוד באופן די טריוויאלי.

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