הנדסת מערכות

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

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

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

### אבני דרך בהנדסת המערכת - מסמכים וסקרים
תהליך הנדסת המערכת כולל אבני דרך מקובלות. אבני הדרך האלו מובילות את התהליך ממשימה למשימה, כאשר כל משימה מסתיימת בסקר.

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

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

תהליך הטיפול הדרישות מתחלק לשלבים כדלקמן. 

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

##### ניתוח וטיוב הדרישות
בשלב השני מנתחים את הדרישות בשני היבטים:

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

# הדרישה הכרחית (Necessary), כלומר כוונת הדרישה אינה מצוינת על ידי דרישות אחרות
# הדרישה בלתי תלויה בפתרון (Implementation Independent), כלומר לא מכתיבה יישום מסוים
# הדרישה חד-משמעית (Unambiguous), כלומר לא ניתנת לפרשנויות שונות
# הדרישה שלמה (Complete), כלומר כתובה כמשפט שלם תחבירית, העומד בפני עצמו, ללא צורך להתייחס לדרישות אחרות לשם הבנתה
# הדרישה יחידה (Singular), כלומר מדברת על רעיון בודד
# הדרישה ישימה (Feasible), כלומר שעל פניה ניתנת ליישום (במונחי עלות, לוחות זמנים, טכנולוגיה וסיכונים)
# הדרישה בת-אימות (Verifiable), כלומר ניתנת לאימות באופן ברור
# הדרישה  נכונה (Correct), כלומר מבטאת כהלכה את ציפיות בעלי העניין
# הדרישה תואמת (Conforming), כלומר עומדת בסטנדרטים שקבע הארגון

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

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

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

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

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

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

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

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

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

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

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

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

התכן הראשוני מוצג בסקר תיכון ראשוני (Preliminary Design Review = PDR). בסקר נבחן התכן הראשוני, או חלופות התכן, שהוצגו כדי לוודא את התאמת התכן לדרישות, את סיכויי ההצלחה של המימוש, ואת איכות המערכת שתתקבל. בשלב הזה כבר אפשר לנתח ולהעריך גורמי איכות כמו בדיקתיות, ייצוריות, תחזוקתיות וכדומה.

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

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

## ראו גם
*הנדסת מערכות תקשורת
*הנדסת מערכות מידע
* ilities
* מערכת מורכבת

## קישורים חיצוניים

* הנדסת מערכות מידע
* אילטם
* קול המערכות - כתב העת של מהנדסי המערכות בישראל
* 
* 
* 

## הערות שוליים

*
קטגוריה:הנדסה