Embed Size (px)
Citation preview
ע"מ 1דבר העורך דר' עמיהוד )עמי( הרי
ע"מ 2דבר הנשיא היוצא של INCOSE_IL עוזי אוריון
ע"מ 4דבר נשיא INCOSE_IL חיים רייכמן
ע"מ 5דבר מנכ"ל אילטם משה סלם
Researches & Development Directions InSystems Engineering
ד"ר אביגדור זוננשיין ופרופ' אביב רוזן ע"מ 6
Reengineering Systems EngineeringJoseph Kasser, Derek Hitchins & Thomas V.Huynh8 ע"מ
Is There A Complete Project Plan?A Model-Based Project Planning ApproachAmira Sharon, Olivier L.de Weck & Dov Dori
ע"מ 30
ע"מ 45הזמנות לסמינרים קרובים
תוכן עניינים
1 קול המערכות, ינואר 2010
קורא יקר,
בשעה טובה אתה מחזיק בידך את המהדורה החמישית של "קול המערכות" - כתב העת של מהנדסי המערכות
בישראל.
של הנשיאים חילופי בסימן עומדת זו מהדורה INCOSE_IL. אנו נפרדים בתודה מעוזי אוריון המסיים מר של פניו את בברכה ומקדמים שנתיים, בת כהונה חיים רייכמן שנכנס לתפקידו בנובמבר 2009. בגיליון זה נביא דברי סיכום ופרידה של מר עוזי אוריון, הנשיא היוצא
ודברי פתיחה של מר חיים רייכמן הנשיא הנכנס.
אנו ממשיכים להשתדל לשמור על הרמה הגבוהה של שני עמנו והפעם זה. עת בכתב המוצגים המאמרים
מאמרים מעניינים:
המאמר הראשון:
Reengineering Systems Engineering
שם ידועי פרופסורים שלושה ידי על נכתב המאמר בתחום הנדסת המערכות:
Professor Joseph Kasser, Temasek Defence • Systems Institute, National University of SingaporeProfessor Derek Hitchins, ASTEM• Professor Thomas V. Huynh, Department of • Systems Engineering, Naval Postgraduate School, Monterey, CA
בחרנו להציג מאמר זה בעקבות ההדים הרבים שעוררה וכיווני מחקרים על בכנוס קסר פרופ' של הרצאתו התפתחות בהנדסת מערכות שהתקיים בטכניון בחודש הפעילויות את תחילה מנתח המאמר האחרון. יוני של המוקדמים בשלבים מערכות להנדסת הייחודיות טיפוסים חמישה מציג השני ובחלקו מערכת פיתוח המאמר מסביר לבסוף, מערכות. מהנדסי של שונים בלתי מהצבה הנובעים מערכת הנדסת של כישלונות שלבי של למטלות המערכות מהנדסי של מתאימה
החיים המוקדמים.
המאמר השני:
Is There a Complete Project Plan? A Model-Based Project Planning Approach
נכתב על ידי: Amira Sharon, Faculty of Industrial • Engineering and Management, TechnionOlivier L. de Weck, Engineering Systems • Division, Massachusetts Institute of TechnologyDov Dori, Technion, Israel Institute of • Technology.
בשילוב העוסק שלם מחקר מתוך חלק מציג המאמר הקונספטואלי התכן בשלבי ומתמקד מוצר-פרויקט לפתח הינה בכללותו המחקר מטרת הראשוני. לניהול קונספטואלי ומודל מתודולוגיה אונטולוגיה, החיים מחזור עם במשולב המוצר של החיים מחזור של הפרויקט שמטרתו להביא את המוצר לכדי מימוש. המוצר עם הפרויקט את בו-זמנית המשלב המודל יאפשר להגיע לתוצאות ניהול מיטביות, בשל האפשרות של אלמנטים בין הקשרים את ישיר באופן לייצר ולבצע עליהם מעקב הפרויקט לאלמנטים של המוצר, פרויקטים למנהלי לסייע עתיד המודל לתכנון. ביחס ומהנדסי מערכות של מערכות מורכבות על פני מחזור אספקה, זמני לקיצור להביא ועשוי המתוכנן, החיים
הפחתת סיכונים והגדלת איכות המוצר.
מהדורה זו יוצאת לקראת יום העיון השנתי ע"ש דר' יוסי לווין שיתקיים ב 24 בינואר 2010 בטכניון. פרטים על יום
העיון אפשר למצוא בסוף הגיליון.
יום העיון סיכום של זו כן אפשר למצוא במהדורה כמו על כיוונים במחקר ופיתוח בהנדסת מערכות שאורגן על ידי מרכז גורדון להנדסת מערכות והתקיים בטכניון ב 24
ביוני 2009.
המערכות מהנדסי לכם, וקוראים חוזרים אנו לסיום ולשתף שלכם ומהידע מניסיונכם לתרום בישראל, מזמינים אנו שלנו. המערכות הנדסת קהיליית את בו אתכם לכתוב מאמרים, תגובות או להעלות נושאים לדיון שניתן להם במה. לבסוף אנו מבקשים לקבל מכם משוב ולדעת מה דעתכם על החומר שאתם מוצאים בו. נשמח
לקבל משובים ותגובות מכם.
דבר העורך
קריאה מהנה,
דר' עמיהוד )עמי( הרי, עורך העיתון
2 קול המערכות, ינואר 2010
INCOSE_IL דבר עוזי אוריון, הנשיא היוצא של
להנדסת הישראלי האיגוד חברי לכל להודות ברצוני מערכות ובעיקר להנהלת האיגוד על התקופה הנעימה שהיתה לי לעמוד בראשו. הרצון הטוב של כל כך הרבה
אנשים עשה את הפעילות למהנה, מעניינת ופוריה.
הורדנו האיגוד, פעילות את מחדש הגדרנו זו בתקופה על מפעילותנו הסודיות" "מעטה את מסוימת במידה ידי פרסום וחיזוק הקשר עם חברות רבות תוך העמקת חברות, של רבות בעשרות המערכות הנדסת תודעת
בעיקר לא בטחוניות.
מהנדסי הכשרת נושא את מספיק לא כי אם קידמנו, מערכות לתואר שני.
מהתעשיה, מרצים ע"י רבים טכניים פורומים קיימנו טובי ע"י סדנאות העברנו ומהאקדמיה. מהצבא המומחים בארץ ובעולם. הפעלנו 3 קבוצות עבודה של ומתודות, וכלים סיכונים ניהול מערכתית, אינטגרציה קבוצה להקים בתוכניתנו רבות. חברות נציגי בנוכחות
רביעית של הנדסת מערכות רזה.
תעשייתיות, בחברות רבים מפגשים קיימנו בנוסף, ביקורים שכללו הרצאות מאלפות וסיורים מרתקים תוך הפרויקטאליות לבעיות שונים ופתרונות גישות לימוד
בכל חברה וחברה.
שיתפנו פעולה עם הטכניון בעידוד המחקר בארץ בתחום לצרכי הלימודים תוכנית ובהתאמת המערכות הנדסת
השוק.
גולת הכותרת של הפעילות הייתה בקיום הכנס המוצלח של הנדסת מערכות, שהיה הגדול ביותר שנערך בישראל
ומהגדולים בהיקפו וברמתו בעולם.
מהנדסים של ופוריה רבה משותפת פעילות קיימנו Lean כגון בינלאומיות עבודה קבוצות עם ישראלים systems engineering, Value of systems engineering,Human system integration ועוד, אנו שותפים במחקרים כיושבי הבינלאומיים בכנסים השתתפנו בינלאומיים.
ראש מושבים, מרצים, פנליסטים וסתם מאזינים.
הברית בארצות INCOSE איגוד ראשי עם נפגשנו ובסינגפור ועם מהנדסי מערכות ומרצים רבים שפועלים התעשייתיות החברות ההשכלה, מוסדות במיטב את בארץ אירחנו והאירופאי. האמריקני והממסד סמנתה העולמי-גב' INCOSE של הנבחרת הנשיאה בראון מ-BAE שהיתה אורחת הכבוד בכנס שלנו במרץ
השנה.
באות פעמים שלוש האחרונות, שנים בשלוש זכינו, ה-Golden Chapter Circle Award, שהוא האות החשוב
.Chapters-ל INCOSE ביותר של
אילטם, המשתמשים איגוד של מחדש בבניה סייענו שתומך לגוף בעיקר והפך פעילותו דפוסי את ששינה שיתוף תוך מערכות, הנדסת של משולבת בפעילות
פעולה הדוק, פורה ומועיל עם כל מטרות האיגוד.
בשנתיים הצטרפו האיגוד, של מהאסטרטגיה כחלק ולאיגוד לאילטם רבות בטחוניות לא חברות האחרונות ונוספו לחוג המתרחב של משתמשים בתבונה בתהליכי
הנדסת המערכות בפעילותם השוטפת.
סדרת לקיים התחלנו אלו בימים חביב, אחרון ואחרון הרצאות בהנדסת מערכות לחברות לא בטחוניות קטנות בקרב מעולה לביקורת )בינתיים...( שזוכה ובינוניות,
המשתתפים.
הרבה דברים לא הושלמו. נושא ארגון מחדש של החברות באיגוד INCOSE העולמי זכה לתהודה רבה מאד ואפילו הנשיאה הנבחרת של האיגוד השתכנעה בנכונות הטענות שהעלינו בדבר הצורך בחברות חלקית זולה, שתאפשר לחברים להנות מהמידע שקיים באיגוד העולמי. תהליך כזה ירחיב גם את חוג החברים ב-INCOSE. פעילות זו
עדין לא הסתיימה.
רשימת ומהי הישראלי באיגוד חבר מיהו הגדרת נושא החברים המעודכנת, טרם בא על סיפוקו.
בארץ מערכות הנדסת של פורמאלי לימוד נושא באוניברסיטאות ומכללות לתואר שני בהנדסת מערכות לא אך חולון של הטכנולוגי )במכון חלקי פרי רק נשא גוריון(, בן אוניברסיטת או בראודה או אפקה במכללת
למרות המאמצים הרבים.
הרבה חברות רלוונטיות עדין לא נהנות מהידע שנמצא באיגוד שלנו ואין בהם הנדסת מערכות מסודרת.
חסרים כלי עבודה רבים, הן לניהול ממשקים והן למידול, בתקופה שהייתה מאד הרבה ההתקדמות למרות
האחרונה.
עומד בשנה פעמיים לצאת אמור שהיה שלנו העיתון ברמה אך לא עומד בקצב.
מערכות הנדסת הלאומי לכנס להערך צריכים אנו יותר בנוכחות ,2011 מרץ בסביבות שיערך השביעי
משתתפים, יותר מרצים, יותר אורחים ויותר מוכרים.
הנדסת תחום אפשר... אי הרי ביקורת, מילת ובלי מבחינת הן לעדנה, מלהגיע רחוק עדין המערכות מבחינת הן לרשותו, שעומדים המתמטיים האמצעים הכלים שהוא מעניק ובזמן האחרון גם בכמות החידושים שאיננה מספקת את צרכי ה-TTM המתקצר במהירות טובים תיכנון ותהליכי בפיתוח חדשות לגישות ומשווע
יותר.
3 קול המערכות, ינואר 2010
ומידיעותיו מנסיונו לתרום ואחת אחד לכל קורא אני הן המערכות, הנדסת תהליכי לשיפור הצעות ולהציע והן בתעשיה שאיננה בטחונית. מי בתעשיה הבטחונית
שלא מעז, לא עוזר.
על תרומה אישית לכמה אנשים להודות ברצוני לסיום מערכות להנדסת הישראלי האיגוד לפעולת חריגה
בתקופת כהונתי כנשיאו:
ראשית, ליקיר האיגוד, ד"ר אביגדור זוננשיין, שלא חוסך מזמנו ומשבטו בכל פעילות ויוזמה אפשרית, על הקשרים והטכניון, הישראליים האיגודים ,INCOSE עם הרבים זמן והקדשת עצומה באכפתיות המטרות קידום תוך
ללא חשבון. תודה רבה.
על הטכני, בתחום הרבה הפעילות על פרנק, למוטי תודה המעניינים, המפגשים והעברת הקשרים יצירת
רבה.
לרויטל גולדברג, שבמקביל לבחינות הסיום של לימודיה בהנדסת מערכות, ארגנה לנו ביקורים מרתקים בחברות
התעשייתיות, תודה רבה.
הנהלת את אישיות מסיבות שעזב ויילר, משה לד"ר האיגוד )ואני מקווה שיחזור לכאן( על תרומה רבת שנים ובמיוחד להובלה המוצלחת של גווניה לפעילות על כל
קבוצת העבודה של ניהול סיכונים, תודה רבה.
לד"ר עמי הרי על העיתון המעולה שהוא מוציא, למרות העומס הרב בו הוא שרוי. תודה רבה.
למשה סלם, על שיתוף הפעולה הנפלא, על המחשבה התמיכה על שלנו, והמצוקות הנושאים בפתרון הרבה הרבה בנושאים האדמיניסטרטיביים והפעולה ללא לאות להצלחת האיגוד. תודה רבה. תודה רבה גם לחגית ולטל
)וגם לליאת שעזבה בינתיים( על העזרה הרבה מאד.
תודה לכל הפעילים על הרצון הטוב, על היכולת הגבוהה האיגוד למען ופעלו שעשו הענקית הפעילות כל ועל
ולמעננו.
ואחרון אחרון חביב, לחיים רייכמן, על שהיעז ולקח את התפקיד הלא פשוט, ומרים את הדגל בהמשך, אני רוצה
לאחל לו הרבה הצלחה.
בברכה,
הנשיא היוצא של האיגוד הישראלי INCOSE_IL-להנדסת מערכות
4 קול המערכות, ינואר 2010
דבר נשיא INCOSE_IL האיגוד הישראלי להנדסת מערכות
קורא יקר,
עיתון זה של "קול המערכות" הינו מהדורה נוספת לכתב העת של איגוד מהנדסי המערכות ואמצעי חשוב להשגת
יעדי האיגוד.
ומחליף הארגון כנשיא לתפקידי נכנס אני אלה בימים את עוזי אוריון שכיהן בשנתיים האחרונות.
עוזי ביסס את יעדי הארגון, חידד את ייעודו, פעל במרץ ופיתח אמצעים רבים להשגת מטרות הארגון.
כצומת מעמדו את ביסס הארגון פעילותו, בשנות ובתעשייה בכלל. להנדסת מערכות באקדמיה, בצה"ל,
כולל התעשיות האזרחיות ומוסדות הממשלה.
פעילותו של הארגון ותרומתו לקהילת מהנדסי המערכות מורגשת בכל פינה, הן בימי העיון והסמינרים, והן בקבוצות
העבודה ומעורבות בארגון העולמי.
ברצוני להודות לעוזי ולכל חברי ההנהלה שתרמו, עשו, וימשיכו לתרום מזמנם ומרצם להצלחת הארגון. בטוחני לנווט את ואוכל שאזכה לשיתוף פעולה מכל הגורמים הארגון בדרך שנסללה ותוכננה עד כאן לקראת העתיד
והתאמת פעילות הארגון לצרכים ולסביבה המשתנה.
המקצועי האיגוד להיות הינו שהותווה כפי הארגון יעד של מהנדסי המערכות בישראל ולתרום באופן משמעותי
לתחום.
הנדסת מקצוע את ולקדם לטפח - הארגון יעוד המערכת, שיתוף מידע בשיטות ניהול הנדסת מערכת, אימוץ גישות רב תחומיות ליצירת פתרונות שעונים על הצרכים להצלחת התוכניות והפרויקטים לרווחה כלכלית
של מדינת ישראל ובטחונה.
כל בין שת"פ נדרש הייעוד ולמימוש ליעד להגעה וכן, השונים בארגונים מערכת בהנדסת המובילים תרומה ומעורבות של מהנדסי מערכת מכלל התעשיות
והארגונים.
בעיתון מאמרים פרסום המידע, שיתוף פעילותכם, כשומעים והן כמרצים הן פעילה השתתפות האיגוד, בימי העיון והסמינרים תבטיח את יכולת הארגון לעמידה
ביעוד והגעה ליעד.
שהתקיימו הפעילויות בכל נמשיך הקרובה בתקופה ותוכננו תוך דגש על:
• הגדרת תוצרים ודרכי שימוש בתוצרים של קבוצות העבודה השונות.
מהנדסי להכשרת פעילויות של והרחבה • ביסוס מערכת וחיזוק הקשר לאקדמיה.
הביטחוניות התעשיות בין הקשר ומיסוד • הרחבה והתעשייה האזרחית.
• עידוד שימוש בכלים להנדסת מערכת ושכנוע מנהלי התעשייה להשקיע בפיתוח ושימוש בתחום זה.
הנני מאחל לכולנו שנת פעילות פורייה ושת"פ מלא מכל בתפקיד קודמי של במסורת להמשיך שנוכל הגורמים
להעלאת קרנו וחשיבותו של הארגון.
כולכם מוזמנים לקחת חלק בפעילות חשובה זאת.
קריאה מהנה,חיים רייכמן
INCOSE_IL נשיא
5 קול המערכות, ינואר 2010
דבר מנכ"ל אילטם
נשמח לראותכם לוקחים חלק בפעילויותינו
משה סלם מנכ"ל אילטם
שלום רב,
מתקדמות בטכנולוגיות משתמשים איגוד - אילטם על-ידי הוקם )ע"ר(, ידע עתירות משולבות במערכות למענן פועל האיגוד הידע. עתירת בתעשייה חברות
ונמצא בבעלותן של החברות חברות האיגוד.
האיגוד פועל במסגרת תוכנית מגנ"ט, תחת פיקוחה של לשכת המדען הראשי, במשרד התעשייה והמסחר.
המשולמים שנתיים חברות דמי ע"י ממומנת פעילותו לאיגוד הניתן ומענק באיגוד החברות הָחַברות ידי על
על-ידי תוכנית מגנ"ט בלשכת המדען הראשי.
החברות באילטם הינה מוסדית. כל עובדי חברה החברה באילטם זכאים להשתתף בפעילויות האיגוד ובפעילויות
.INCOSE_IL
אילטם שם לו למטרה לשפר את כושר התחרותיות של התעשייה עתירת הידע בישראל ע"י זיהוי, לימוד, שיתוף מתקדמות, טכנולוגיות של ובהטמעה וניסיון בידע וייצור לפיתוח המשמשות ותשתיות מתודולוגיות מערכות משולבות עתירות ידע. שיפור כושר התחרותיות ,Time-To-Market קיצור טכנולוגית, הובלה משמעו: בינלאומיים, בתקנים עמידה והייצור, הפיתוח הוזלת
שיפור האיכות והאמינות, הגברת המצוינות.
האיגוד פועל למען חבריו ואינו בעל עניין בשום פעילות חברות ממאה למעלה באיגוד חברות כיום מסחרית.
מהתעשייה האזרחית והביטחונית.
אילטם מקיים סמינרים, ימי עיון, מפגשים ופורומים של פועלות תחום בכל השונים. בתחומים עבודה קבוצות מספר קבוצות עבודה, אשר מטרת פעילותן הינה הפריה
ידע הדדית .
להלן רשימת התחומים וקבוצות העבודה הפעילות בכל תחום:
תחום הנדסת מערכות: • קבוצת עבודה מתודולוגיות וכלים
• קבוצת עבודה אינטגרציה מערכתית
• קבוצת עבודה אימות ותיקוף
• קבוצת עבודה ניהול סיכונים
תחום הנדסת תוכנה: DATA MINING קבוצת עבודה •
• קבוצת עבודה גרסאות ותצורה
• קבוצת עבודה ארכיטקטורת תוכנה
תחום פיתוח חומרה:• קבוצת עבודה תיב"מ לתכן חשמלי
• קבוצת עבודה אמינות מערכת החומרה
תחום תכן תואם דירקטיבות ירוקות:• קבוצת עבודה תכן תואם דירקטיבות ירוקות
תחום הנדסה ותכן לייצוריות.תחום מכאניקה:
• קבוצת עבודה תכן תרמי
• קבוצת עבודה תיב"מ מכאני
תחום מערכות רפואיות:• קבוצת עבודה מערכות רפואיות.
תחום מערכות תבוניות בתחבורה:• קבוצת עבודה תחבורה חכמה
להצטרפות או העבודה קבוצות בנושא נוסף למידע לאחת מקבוצות העבודה
http://www.iltam.org/info.php?id=wgropexp
של הענפה בפעילות חלק לקחת אתכם מזמינים אנו האיגוד.
המומחים צוות באיגוד, הפעילות תחומי על עוד נושאי הפעילות, המרצים המהווה את הנהלת התחום, המשתתפים בפעילות התחום, קבוצות העבודה, תכנית העבודה השנתית ופעילויות הארגון השונות ניתן למצוא
www.iltam.org באתר אילטם
לשנת באיגוד לחברות מבוצעת ההרשמה אלו בימים ניתן באיגוד חברות חידוש /או הרשמה טופס .2010
למצוא בכתובת:
http://www.iltam.org/info.php?id=sd_joinunion
בהזדמנות זו ברצוני להודות מקרב לב למר עוזי אוריון, נשיא INCOSE_IL הפורש, על תרומתו הרבה, העשייה תחום לקידום וההשקעה האנרגיות נלאית, הבלתי רייכמן, חיים למר ולאחל בישראל. המערכות הנדסת והמשך החדש בתפקידו רבה הצלחה הנכנס, הנשיא
.INCOSE_IL - שיתוף פעולה פורה בין אילטם ל
6 קול המערכות, ינואר 2010
Researches & Development Directions In Systems Engineering
A Professional Event Planned & Organized By Gordon CenterJune 24, 2009
Summarized by Dr. Avigdor Zonnenshain & Prof. Aviv Rosen
IntroductionAbout 200 practitioners & researchers in Systems Engineers have gathered at the Technion on June 24, 2009 for the Third Annual Day for Researches in Systems Engineering )SER09(. This day is sponsored by Gordon Center with collaboration of INCOSE_IL, The Israeli Chapter of INCOSE & ILTAM.
The ProgramThe presentations this time were focused on new approaches which have been studied through advanced research at the Technion & other Universities in Israel, Australia, Singapore. The program was concluded with an interesting & vivid panel on the topic of integrating Systems Engineering & Art.
During the day the following papers were presented:The Forthcoming Seldon Crisis in Systems Engineering- Presented by Prof. Joe Kasser, Visiting Associate Professor at the National University of Singapore) By Video Conference(
Types of Systems Engineering- Presented by Dr. Naftaly Amit. This is the title of a current research at the Gordon Center, by Dr. Amit with Prof. Moti Frank, HIT & Dr. Avigdor Zonnenshain, RAFAEL
System Development in Dynamic Environment: Tools for architecture development and process management- Presented by Prof. Yoram Reich, Tel Aviv University
Conceptual Design to Cost: A New Systems Engineering Tool - Presented by Dr. Amihud Hari, The Gordon Center
Microcosm- A Systems Engineering "Sandpit"- Presented by Prof. Shraga Shoval, University of South Australia
Development of an Industrial Design Method (IDM) in Line with ICDM- Presented by Yariv Sadeh, Industrial Designer who is completing his Master degree at the Technion under the supervision of Prof. Menachem Weiss
Global Engineering- Presented by Yair Briman, Philips Israel VP for Engineering
Students Presentation of their final project for the Systems Engineering ME program at the Gordon Center/ Technion
7 קול המערכות, ינואר 2010
As mentioned above, the day was concluded by a Panel with the topic: Integrating Systems Engineering & Art for promoting Aesthetics & Creativity. The panelists were: Mr Giora Shalgi, Former General Manager of RAFAEL, Mr. Uzi Orion, Chief Engineer of ELOP & the President of INCOSE_IL, Prof. Menachem Weiss., Technion, Prof. Rivka Oxman, The Architecture & Cities Planning Faculty, Technion.Each panelist presented his point of view on the panel topic.All presentations can be found in the following link:http://ae-www.technion.ac.il/events/system_workshop/table_of_contents.pdf
Main FindingsIt is possible to draw some common findings from the talks during this day:
It is very important to teach & implement Systems Thinking as a valuable ingredient for Systems Engineers & Systems Engineering Processes
Systems Engineering is about People & not about Processes
It is essential to develop systems for continuous changes in the markets & technology
One of the ways to deal with complex systems is by designing simple systems )Design for Simplicity(
The integration of Systems Engineering & Art have an added value for developing high aesthetics systems & developing an efficient methodology for Industrial Design .This issue should be further developed, studied & promoted.
Global Systems Engineering is a real challenge for global companies. We may learn from the lessons & experience of global companies how to integrate the Systems Engineering efforts through the culture differences.
For effective Systems Engineering it is essential to integrate the various engineering disciplines & various managerial practices. This is another essential issue to be studied & further developed
Summarized by:
Dr. Avigdor Zonnenshain Prof. Aviv Rosen
מרכז גורדון INCOSE_IL אילטם אנא רישמו בפניכם
יום העיון השני למחקרים ונושאי הנדסת מערכות מתקדמים – 2010 יערך בטכניון ב – 22/3/2010
היום יוקדש לנושא: "שילוב בין הדיסציפלינות - משימה חיונית של הנדסת מערכות"
8 קול המערכות, ינואר 2010
Reengineering Systems Engineering
Abstract This paper documents )1( the early phases of using systems Engineering to develop a conceptual system – the system being developed is a systems engineering body of knowledge )SEBoK( and )2( the findings and opportunities generated in those early phases. The approach was based on identifying activities specific to systems engineering, as opposed to the broad raft of activities that systems engineers might undertake, according to their role. An activity-based definition of systems engineering vs. non-systems engineering role-based definition was developed. The second part of the paper identifies five types of systems engineers, discusses the evolution of systems engineering in terms of those five types, and hypothesizes that a major cause of the failure of systems engineering is the allocation of inappropriate types of systems engineers to early lifecycle phase systems engineering activities. The paper concludes with some insights and recommendations for further study.
Joseph KasserVisiting Associate ProfessorTemasek Defence Systems
InstituteNational University of Singapore
Block E1, #05-05, 1 Engineering Drive 2, Singapore 117576
Derek HitchinsASTEM
Consultant Systems Architect
Thomas V. HuynhAssociate Professor
Department of Systems Engineering
Naval Postgraduate SchoolMonterey, CA, 94393
תקציר מאמרמאמר זה מתעד:
את השלבים הראשונים של שימוש בהנדסת מערכות לפיתוח מערכת קונספטואלית – המערכת המפותחת 1 .Systems Engineering Body of Knowledge - SEBoK היא גוף הידע של הנדסת המערכות
ייחודיות זיהוי פעילויות וההזדמנויות שנוצרו באותם שלבים מוקדמים. הגישה התבססה על את הממצאים 2 .פותחה תפקידם. במסגרת מבצעים מערכות שמהנדסי פעילויות של רחב לזרם בניגוד מערכות, להנדסת הגדרה מבוססת פעילויות של הנדסת מערכות לעומת הגדרה המבוססת על פעולות שאינן ייחודיות להנדסת
המערכות.
חלקו השני של המאמר מגדיר חמישה טיפוסים של מהנדסי מערכות, הוא דן בהתפתחות האבולוציונית של 3 .הנדסת המערכות בביטויים של חמשת הטיפוסים האלה, וטוען שגורם עיקרי לכישלון של הנדסת מערכות הוא
ההצבה של טיפוסים בלתי מתאימים של מהנדסי מערכות לפעילויות המוקדמות של מחזור החיים.
9 קול המערכות, ינואר 2010
Fifty years later, nothing has changed in that respect1.
Evolution Of The Role Of Systems EngineeringDescriptions of systems engineering currently comprise different interpretations of the activities known as systems engineering and the broad raft of activities that systems engineers might undertake according to their role in the workplace. This quagmire has developed because different users of the term ‘systems engineering’ for almost 50 years have chosen or perceived different meanings. For example, one comment from 1960 was “Despite the difficulties of finding a universally accepted definition of systems engineering1 , it is fair to say that the systems engineer is the man who is generally responsible for the over-all planning, design, testing, and production of today’s automatic and semi-automatic systems” )Chapanis, 1960( page 357(. )Jenkins, 1969( page 164( expanded that comment into the following 12 roles of the systems engineer:
He tries to distinguish the wood from the trees – what’s it all about?1.
He stimulates discussion about objectives – obtains agreement about objectives.2.
He communicates the finally agreed objectives to all concerned so that their co-operation 3. can be relied upon.
He always takes an overall view of the project and sees that techniques are used 4. sensibly.
By his overall approach, he ties together the various specializations needed for model 5. building.
He decides carefully when an activity stops.6.
He asks for more work to be done in areas which are sensitive to cost.7.
He challenges the assumptions on which the optimization is based.8.
He sees that the project is planned to a schedule, that priorities are decided, tasks 9. allocated, and above all that the project is finished on time.
He takes great pains to explain carefully what the systems project has achieved, and 10. presents a well-argued and well-documented case for implementation.
He ensures that the users of the operational system are properly briefed and well 11. trained.
He makes a thorough retrospective analysis of systems performance.12.
Seven of these roles of the systems engineer )activities performed by a person with the title systems engineer( overlap the role of the project manager )activities performed by a person with the title project manager(. Research into the reason for the overlapping of the disciplines turned up information as to how the overlap originated in the form of the following statement. “Driven by cold war pressures to develop new military systems rapidly, operations research, systems engineering, and project management resulted from a growing recognition by scientists, engineers and managers that technological systems had grown too complex for traditional methods of management and development” )Johnson, 1997( Thus
10 קול המערכות, ינואר 2010
systems engineering, project management and operations research can be seen as three solutions to the problems posed by complex systems in the Cold War by three different communities of practice )Johnson, 1997( that have continued to evolve and overlap. Some of the evolution in systems engineering can be seen in the very little overlap between the 12 roles documented by )Jenkins, 1969( and the following 12 systems engineering roles documented by )Sheard, 1996(:
Requirements Owner (RO) Role1. . Requirements Owner/requirements manager, allocator, and maintainer/specifications writer or owner/developer of functional architecture/developer of system and subsystem requirements from customer needs.
System Designer (SD) Role2. . System Designer/owner of “system” product/chief engineer/system architect/developer of design architecture/specialty engineer )some, such as human-computer interface designers(/“keepers of the holy vision” )Boehm, 1994(.
System Analyst (SA) Role3. . System Analyst/performance modeler/keeper of technical budgets/system modeler and simulator/risk modeler/specialty engineer )some, such as electromagnetic compatibility analysts(.
Validation and Verification (VV) Role4. . Validation and Verification engineer/test planner/owner of system test program/system selloff engineer. VV engineers plan and implement the system
Logistics and Operations (LO) Role.5. Logistics, Operations, maintenance, and disposal engineer/developer of users’ manuals and operator training materials.
Glue (G) Role. Owner of “Glue”6. among subsystems/system integrator/owner of internal interfaces/seeker of issues that fall “in the cracks”/risk identifier/“technical conscience of the program”.
Customer Interface (CI) Role. 7. Customer Interface/customer advocate/customer surrogate/customer contact.
Technical Manager (TM) Role.8. Technical Manager/planner, scheduler, and tracker of technical tasks/ owner of risk management plan/product manager/product engineer.
Information Manager (IM) Role9. . Information Manager )including configuration management, data management, and metrics(.
Process Engineer (PE) Role.10. Process engineer/business process reengineer/business analyst/owner of the systems engineering process.
Coordinator (CO) Role.11. Coordinator of the disciplines/tiger team head/head of integrated product teams )IPTs(/system issue resolver.
“Classified Ads Systems Engineering” (CA) Role12. . This role was added to the first eleven in response to frustration encountered when scanning the classified ads, looking for the INCOSE-type of systems engineering jobs.
Jenkins’ roles relate to conceiving and planning the solution system while almost 30 years later, few of Sheard’s roles address the original systems engineering approach to conceiving and planning the solution system. Sheard’s set of roles relate to interpersonal relationships between the practitioners of disparate skills and disciplines implementing the solution system. Furthermore, according to both Jenkins and Sheard the role of the systems engineer )the
11 קול המערכות, ינואר 2010
activities performed by a person with the title systems engineer( overlaps activities performed )the roles( by people from other professions2 ; see )Brekka, et al., 1994; Roe, 1995; DSMC, 1996; Kasser, 1996; Sheard, 1996; Johnson, 1997; Watts and Mar, 1997; Bottomly, et al., 1998; Kasser, 2002b( and Figure 1 for just a few examples of the different overlaps between systems engineering and project management. Note the Defense Systems Management College definition of systems engineering as “The management function which controls the total system development effort for the purpose of achieving an optimum balance of all system elements. It is a process which transforms an operational need into a description of system parameters and integrates those parameters to optimise the overall system effectiveness” )DSMC, 1996(. Notice the use of the term “management function”! In addition, see )Emes, et al., 2005( for overlaps between systems engineering and other disciplines and )Hari, et al., 2004( for an example of
the activities performed in new product design that overlap systems engineering. In addition, the activities performed by the systems engineer in one organisation are different to those performed by a systems engineer in another organization and so are the knowledge requirements for their activities. Consequently, defining a body of knowledge for systems engineering poses a major challenge.
Defining a body of knowledge based on the role of a systems engineer will be difficult if not impossible because the role of the systems engineer has evolved over time so that it is different in practically every organisation. As such, the solution to the problem of defining a body of knowledge for systems engineering is to dissolve the problem by making a change in the paradigm. This approach, which redesigns the system containing the problem or changes the perspective from which the problem is viewed to produce an innovative solution is one of the four ways to tackle a problem suggested by )Ackoff, 1999( page 115(. The paradigm change is made by making a distinction between a set of activities known as systems engineering and the role of the systems engineer which is the sum of the systems engineering and non-systems engineering activities systems engineers perform in the workplace )Kasser and Palmer, 2005(. The focus on activities is a return to Hall’s definition
Figure 1 JAXA Project management and systems engineering (JAXA, 2007)
2. Fifty years later, nothing has changed in that respect
12 קול המערכות, ינואר 2010
of “systems engineering as a function not what a group does” )Hall, 1962( page 11( and means that the knowledge needed by systems engineers in their roles will be more than the activities to be defined as ‘systems engineering’ )see below(, and that knowledge can be separated into ‘systems engineering’ and ‘everything else’. The ‘systems engineering’ knowledge will be placed in the systems engineering body of knowledge )SEBoK(, and the subset of knowledge of ‘everything else’ that will be needed will be out of scope of the SEBoK but will be referenced appropriately.
Separating Out The Systems Engineering KnowledgeIn the activity paradigm, various people in various disciplines at various times perform a set of activities from the time a problem is being defined, though the conceptualisation, design, construction and operation of the system that solves, resolves or dissolves the problem to the time that the system has been taken out of service and disposed. This set of activities may be partitioned into subsets in various ways such as by professional discipline )project/engineering management, systems engineering, engineering, new product design, etc.( and by time )the phases in the system lifecycle(. Various systems engineers and non-systems engineers perform different subsets of systems engineering activities and different subsets of non-systems engineering activities. As discussed above, the mapping of the role of the systems engineer to activities is different in different organisations, hence the aforementioned difference in their descriptions when systems engineers get together and discuss their roles.
Looking at the structure of organisations from the temporal perspective, in general the structure of organisations is still based on the work of F.W. Taylor who systems engineered his mining organisation and split the work into two streams of activities which have become known as ‘management’ and ‘labour’)Taylor, 1911(. However, since that time, the structure of companies and the nature of work have changed. Organizational structures have become flatter, decision making has become decentralized, information is widely shared, workers form project teams, even across organizations, and work arrangements are flexible )Microsoft, 2008(. Taylor’s split is no longer applicable. Consequently, we now propose to reengineer )in the sense of the word as used by )Hammer and Champy, 1993( Taylor’s split for organisations developing systems by splitting work into two different streams, systems engineering and non-systems engineering and further partitioning the non-systems engineering streams as described below.
The INCOSE Fellows definition of systems engineering was considered as a starting point for determining what went into the systems engineering stream. The definition is “Systems Engineering is an engineering discipline whose responsibility is creating and executing an interdisciplinary process to ensure that the customer and stakeholder's needs are satisfied in a high quality, trustworthy, cost efficient and schedule compliant manner throughout a system's entire life cycle” )INCOSE Fellows, 2009(. However, if the words ‘engineering discipline’ are replaced by the words ‘project management’ many project managers would consider the definition to apply to project management. This definition may be understood as applying to both the role of the systems engineer and the role of the project manager since the roles overlap both in space and time as discussed above. As such, an alternative definition is needed.
13 קול המערכות, ינואר 2010
Further research to determine what went into the systems engineering stream showed that the approved Standards used in systems engineering do not seem to actually apply to systems engineering – they cover systems engineering management and the processes for engineering a system! Thus:
Mil-STD-499 covers systems engineering management )MIL-STD-499, 1969(. •
Mil-STD-499A covers engineering management )MIL-STD-499A, 1974( dropping the •word ‘systems’ from the title.
The draft )MIL-STD-499B, 1993( and MIL-STD-499C )Pennell and Knight, 2005( •Standards contain the words “systems engineering” in their titles but the Standards were never approved and these Standards also )as did 499 and 499A( generally ignore most of the problem identification, whole solution conceptualisation and solution implementation planning activities that take place in Phase A of Figure 1.
ANSI/EIA-632 covers processes for engineering a system )ANSI/EIA-632, 1999(.•
The IEEE 1220 Standard is for the application and management of the systems •engineering process )IEEE 1220, 1998(.
The ISO/IEC 15288 Standard lists processes performed by systems engineers )Arnold, •2002( and hence may be considered as being applicable to the role of the systems engineer rather than to the activities known as systems engineering.
The phases in providing a whole complete solution to a problem can be considered as a set of activities performed by various people in various disciplines at various times. Some of those activities are systems engineering, and some are not systems engineering. The next approach was to develop a list of activities that could be described as systems engineering. Research found several sources of lists of activities including:
)Eisner, 1988( who lists a general set of 28 tasks and activities that were normally •performed within the overall context of large-scale systems engineering. He calls the range of activities ‘specialty skills’ because some people spend their careers working in these specialties. Thus according to Eisner [the role of 3] systems engineering overlaps at least 28 engineering specialties.
)Hyer, 1997( provides a list of nine activities for systems integration but which do not •necessarily take place during the systems integration phase.
)Eisner, 1997( page 156( expands )Eisner, 1988( and discusses 30 tasks that form the •central core of systems engineering. The whole area of systems engineering management is covered in just one of the tasks. Eisner states that “not only must a Chief Systems Engineer understand all 30 tasks; he or she must also understand the relationships between them, which is an enormously challenging undertaking that requires both a broad and deep commitment to this discipline as well as the supporting knowledge base”.
Should the research continue in this direction, the resulting list would be long, subjective and open to never ending discussion. Looking outside the box, lessons learned from psychology
3. Author’s interpretation
14 קול המערכות, ינואר 2010
indicate that long lists are not the way to proceed. At one point of time in the development of theories of motivation, Henry A. Murray identified separate kinds of behaviour and developed an exhaustive list of psychogenic or social needs )Murray, 1938(. However, the list is so long that there is almost a separate need for each kind of behaviour that people demonstrate )Hall and Lindzey, 1957(. While Murray’s list of 39 kinds of behaviours has been very influential in the field of psychology, it has not been applied directly to the study of motivation in organizations because the length of the list makes it impractical to use. On the other hand, Maslow's hierarchical classification of needs )Maslow, 1966, 1968, 1970( has been by far the most widely used classification system in the study of motivation in organizations. Maslow differs from Murray in two important ways; his list is:
Arranged in a hierarchy• -commonly drawn as a pyramid, and contains a set of hypotheses about the satisfaction of these needs.Short• -- Only five categories.
The eventual approach chosen to determine what is and what is not a systems engineering activity was to dissolve the problem by developing a criterion for what constitutes an activity to be defined as systems engineering rather than trying to resolve the problem by a developing a list of activities. The following criterion was used to determine if an activity does or does not belong in the set of activities to be known as systems engineering:
If the activity deals with parts and their interactions as a whole, then it is an activity within •the set of activities to be known as systems engineering.
If the activity deals with a part in isolation, then the activity is not an activity within the •set of activities to be known as systems engineering but is part of ‘something else’, e.g., engineering management, software engineering, etc.
The activities of systems engineering have focused on both analysis and systems thinking. Analysis which has three steps )Ackoff, 1991( can be performed as ‘reductionism’ or ‘decomposition’ – reducing the parts to ever decreasing components in isolation, but should be performed by the systems engineer as ‘elaboration’ )Hitchins, 2003( pages 93-95( – which examines the parts in increasing detail without losing track of the part’s relationship to the overall system. Systems thinking, on the other hand also has three steps )Ackoff, 1991( but they are slightly different. Comparing analysis and systems thinking in the manner shown in Table 1, one can see that the focus of analysis is to look inwards while the focus of systems thinking is to look outwards. Both analysis )in the form of ‘elaboration’( and systems thinking have their place in the activities performed in developing an understanding of a system )Hitchins, 1992( page 14( and are but two of the systems thinking perspectives )Kasser and Mackley, 2008(.
table 1 Analysis and Systems Thinking
Analysis )Machine Age( Systems Thinking )Systems Age(
1. Take apart the thing to be understood 1. A thing to be understood is conceptualized as a part of one or more larger wholes, not as a whole to be taken apart;
2. Try to understand how these parts worked 2. An understanding of the larger system is sought3. Assemble an understanding of the parts into an understanding of the whole
3. The system to be understood is explained in terms of its role or function in the containing system.
15 קול המערכות, ינואר 2010
Since the activities forming the ‘something else’s’ are part of the context of systems engineering and are often performed by systems engineers, it is recognised that systems engineers need the knowledge to perform or understand many of the activities defined as ‘something else’ but that knowledge per se is out of the scope of the SEBoK and will be identified accordingly. The ‘something else’ activities were further partitioned into the following sets of non-systems engineering activities:
Engineering.•
Management.•
Other.•
The proposed activity paradigm definitions of the systems engineering sets of activities and the non-systems engineering sets of activities are as follows:
Systems engineering• is the set of activities involved with dealing with parts and their interactions as a whole.
Engineering• is the set of activities dealing with a part in isolation. If the part is not a technological product, for example if the part is such as a human element, then use of language is such that the activity is not called engineering but something else, such as training or exercising.
Management• is the set of activities known as planning organising, directing, staffing and controlling activities for and in the production of the part in isolation.
Other• is the remaining set of activities not included in the previous definitions.
Combining these definitions it can be seen that in the activity paradigm:
Systems engineering management• is the set of activities known as planning organising, directing, staffing and controlling systems engineering activities in isolation from the other sets of management activities.
Engineering management• is the set of activities known as planning organising, directing, staffing and controlling engineering activities in isolation from the other sets of management activities.
Lastly for the sake of completing the set of definitions, a task is an activity performed within a specific period of time and a project consists of a temporary endeavor [set of tasks] undertaken to create a unique product, service or result )PMI, 2004(. It follows that:
Project management • is the set of activities known as planning organising, directing, staffing and controlling a temporary set of tasks undertaken to create a unique product, service or result, in isolation from the other projects.
The next phase in determining the SEBoK will be to identify the activities performed in each phase of the system lifecycle developing a concept of operations of the work being performed and then using the simple activity-based criterion to determine which of the activities are and which are not systems engineering. Each activity will be defined in such a manner as to terminate with the production of a tangible product or products which is/are transferred to the start of the subsequent activity in accordance with )Kasser, 1997(. The activities
16 קול המערכות, ינואר 2010
4. The first systems engineering process deals with identifying the real problem and a number of alternative conceptual solutions followed by the choice of an optimal conceptual solution to the whole problem, The second systems engineering process follows the first and deals with the creation, operation and disposal of an optimal physical implementation of the conceptual solution to the problem generated by the first systems engineering process.
5. Other lifecycles do exist
have been grouped by the phases in the first and second systems engineering processes4
in the system lifecycle for a system that is developed from conception to disposal5 using the Hitchins-Kasser-Massie Framework )HKMF( for understanding systems engineering )Kasser, 2007( shown in Figure 2. Each area of the HKMF can potentially contain all sets of )systems engineering and non-systems engineering( activities – some more than others. Figure 1 also provides an indication of the relative ratios between the sets of activities known as systems engineering and the sets of activities known as project management over the system life cycle.
The HKMF has also identified one reason for debates in the meaning of terminology used by systems engineers. Words such as ‘capability’ and ‘system design’ have different meanings in different areas of the HKMF. The confusion in the use of the term ‘operations concept’ and ‘concept of operations’ can be similarly be clarified when one realizes that the terms refer to products produced in different columns of the
Figure 2 The HKM Framework for understanding systems engineering
HKMF. In addition the vocabulary for describing concepts in Layer 2 for single system development in isolation is different to the vocabulary used in Layer 3 to express the same concepts in business processing reengineering.
The vertical dimension of the HKMF contains the five-layers of systems engineering )Hitchins, 2000(. The horizontal dimension of the framework is organized as sequential phases in providing a whole complete solution to a problem as an overall, end-to-end process which consists of conceiving a whole solution to solve a problem and making that whole “come to life” for the development of a single system in isolation. The phases have been stated in various ways in various Standards, conference papers and books, but in the HKMF they are defined in generic terms as:
17 קול המערכות, ינואר 2010
A. Identifying the need. This is the phase where the bulk of the set of activities known as systems engineering is performed. Yet in the Type II systems engineering educational paradigm it tends to be glossed over )see below for an explanation of the five types of systems engineers and why this phase is glossed over(. Phase A is based on )Hall, 1962(, )Gelbwaks, 1967(, )Hitchins, 1992( and the summary in )Brill, 1998( and contains the first ‘systems engineering’ process addressing the conceptual solution. Phase A comprises the following sub-phases:
This sub-phase contains the set of activities that explore/scope the problem, leading 1. directly to Phase A.2. The activities performed in this phase produce a definitive statement of the problem-in-context.
This sub-phase contains the set of activities that conceive the whole solution system 2. )which 'emerges' from/"complements" the problem( and produces the concept of operations )CONOPS( that describes how the solution system will operate in its future environment.
This sub-phase contains the set of activities that design the whole solution system, 3. identify the environment, other interacting systems, the subsystems, parts, interactions, functional architecture, physical architecture, etc., etc., - but still all of the whole.
B. Requirements analysis. This phase is the first phase of the second ‘systems engineering’ process addressing the physical solution and its implementation and contains the set of activities that specify the solution system as a full set of specifications for the whole and for the parts and their infrastructure, including the environment/Weltanschauung or paradigm that justifies them. If the specifications are in the form of text mode requirements, the output of this phase tends to be at the ‘A’ specification level )MIL-STD-490A, 1985(. Unfortunately, many systems engineers have been educated to consider this phase as the first phase of a single systems engineering process. For example, )1( according to )Martin, 1997( page 95(, )Eisner, 1997( page 9(, )Wasson, 2006( page 60( and )DOD 5000.2-R, 2002(, pages 83-84( requirements are one of the inputs to the ‘systems engineering process’; and )2( in one postgraduate class at University of Maryland University College the instructor stated that systems engineering began for him when he received a requirements specification )Todaro, 1988(. While )DOD 5000.2-R, 2002( pages 73-74 ( does call out the ‘analysis of possible alternatives’ subset of activities in Phase A2 of the HKMF, those activities are called out as part of the separate seemingly independent Cost as an Independent Variable )CAIV( process which )1( is a way of complicating just a part of the concept of designing budget tolerant systems )Denzler and Kasser, 1995( using the Cataract approach )Kasser, 2002a( and )2( takes place before the DOD 5000.2-R ‘systems engineering process’ begins.
C. Design. This phase contains the set of activities that creates a more detailed design of the whole solution system through a combination of people, doctrine, parts, subsystems, interactions, etc., including configuration, architecture and implementation criteria. The output of this phase tends to be at the ‘B’ specification level )MIL-STD-490A, 1985(.
D. Construction. This phase contains the set of activities that create the individual parts, subsystems, interactions, etc. in isolation. Consequently the set of activities are mainly engineering, training, etc., not systems engineering. This situation is indicated in Figure 1 by the down slope in the line showing the amount of systems engineering at this phase.
18 קול המערכות, ינואר 2010
E. Unit Testing. This phase contains the set of activities that validate the performance of the individual parts, subsystems, interactions, etc. in isolation against their requirements. Consequently the set of activities are mainly engineering, not systems engineering.
F. Integration and testing of the system. This phase contains the set of activities that )1( combines the parts, subsystems, interactions, etc., to constitute the solution system, and )2( establishes, under test conditions, the performance of the whole solution system, with optimum effectiveness, in its operational context.
G. Operations, maintenance and upgrading of the system. This phase contains the set of systems engineering and non-systems engineering activities that actively provide a solution to the problem for which the whole system was created. This phase includes operating the system, support to maintain operations; improvements to the whole to enhance effectiveness, and to accommodate changes in the nature of the problem over time. These changes iterate phases A to F )call them Ga .. Gf(, ideally without rendering the operating solution system materially inoperative for an unacceptable period of time.
H. Disposal of the system. This phase contains the set of activities that dispose of the system. This phase is rendered necessary where either where the problem no longer exists, or the solution system is no longer capable of solving the problem effectively or economically. If the disposal method has not been predetermined, this phase may also iterate phases A to F )call them Ha .. Hf(.
This approach to determining the contents of the SEBoK is also domain independent but recognises that systems engineers do need domain knowledge )as well as systems thinking, communications and interpersonal skills(. A serendipitous outcome of this approach which needs more research, would truly reengineer the work of )Taylor, 1911(. For example,
The potential exists to redraw role boundaries to align with the activity boundaries and •remove much of the role overlap and inefficiency in organisations.
A systems engineering approach can be used to determine the systems and non-•systems engineering activities performed in any row and column of the HKMF based on the operations performed in that area of the framework. The activities can be grouped in various ways into specific roles )job positions( and the knowledge requirements for those roles can be developed. These requirements would provide the knowledge component requirement for the person or persons to be assigned to perform the activities. The competency requirement for the person would be determined separately.
The Five Types Of Systems EngineersThe human side of systems engineering is the systems engineers who perform the roles known as systems engineering. These roles perform the conceiving and creating the solution system systems engineering activities, the project management activities, engineering and other speciality engineering activities in various mixes depending on the phase in the system lifecycle and the organisation in which the systems engineer works. Optimal performance of each of the activities requires different characteristics in the systems engineer. Previous attempts to identify characteristics of systems engineers have been based on the traits attributable to systems engineers e.g. )Hall, 1962; Frank, 2006( and the INCOSE UK Systems Engineering Competencies Framework )Hudson, 2006( The list of desirable traits is increasing steadily. However, the lessons learned from psychology discussed above
19 קול המערכות, ינואר 2010
suggest lists are not the way to proceed and that an alternate approach6 be found. Hence, instead of using lists of traits, an alternative approach of characterising systems engineers into the following five types is proposed based on their ability to deal with problems and solutions.
Type I.• This type is an “apprentice who can be told “how” to implement the solution and can then implement it.Type II• . This type is the most common type of systems engineer. Type II’s have the ability to use the systems engineering process to figure out how to implement a physical solution once told what conceptual solution to implement. Type III• . Once given a statement of the problem, this type has the necessary know-how to conceptualize the solution and to plan the implementation of the solution. Type IV• . This type has the ability to examine the situation and define the problem )Wymore, 1993( page 2(. Type V• . This type combines the abilities of the Types III and IV, namely has the ability to examine the situation, define the problem, conceptualise the solution and plan the implementation of the physical solution.
Table 2 Failure data from GAO Report 06-368, 2006Types I to III are levels through which a person grows with education and experience. The debate on ‘nature’ or ‘nurture’ comes into play at Levels IV and V. However, irrespective of the debate, it is important to identify people with the potential to become Type IV’s and V’s as early as possible in their careers and then to provide them with fast track training to enable their organization to obtain the best use of their capabilities in the future. The new approach to characterizing systems engineers provides a hypothesis for a reason for the failure of systems engineering in the early stages of large projects )Hiremath, 2008( and other examples of poor systems engineering implementation )GAO, 2006(. For example, the cost and schedule overruns in the Joint Strike Fighter )JSF( development project shown in Table 2 were predicted in )Kasser, 2001( and hence probably preventable. Had Type V systems engineers been working on the phases of the JSF project in column A of the HKMF, the factors identified as potential causes of cost and schedule overruns leading to the prediction in )Kasser, 2001( would have probably been identified as risks. Appropriate risk management techniques would then have been recommended and if these risk management techniques had been implemented7 , the ensuring cost and schedule overruns would have been reduced.
6. Based on years of observations by the authors.7. A big “if” since political considerations in the Type II process paradigm would probably have precluded the risk mitigation
activities. Based on years of observations by the authors.
20 קול המערכות, ינואר 2010
MIL-STD 499C
ANSI EIA 632 IEE 1220 CMMI ISO 15288
Conceptualizing problem and alternative solutions No No No No No
Mission Purpose/Definition No No Yes Yes Yes
Requirements engineering Yes Yes Yes Yes Yes
System architecting Yes Yes Yes Yes Yes
System implementation No Yes No Yes Yes
Technical analysis Yes Yes Yes Yes Yes
Verification & validation Yes Yes Yes Yes Yes
Research seems to show that the early systems engineers of the 1950’s and 1960’s tended to focus on identifying the problem )Wymore, 1993( and finding an optimal solution )Goode and Machol, 1959; Hall, 1962(. These early systems engineers were of Type III, IV, and V, while the systems engineers who came later tended to focus on processes )Type II(’s. Back in the “good old days” of systems engineering Type III, IV and V systems engineers solved/resolved/dissolved the problem in the first ‘systems engineering’ process addressing the conceptual solution, then initiated the implementation of the solution, and moved on to the next contract, leaving the Type II’s to continue assisting the development of the solution system in the second systems engineering process. There then came a time when there was a lack of new projects and so many of the Type III, IV and V’s were laid off and lost to the discipline. When the need for systems engineers picked up again, in general only the Type II systems engineers were left and they took over systems engineering. They had seen a successful process for developing systems and so their focus was on the second systems engineering process. They wrote the standards used in systems engineering )MIL-STD-499, 1969; MIL-STD-499A, 1974; EIA 632, 1994; IEEE 1220, 1998( for other Type II systems engineers to follow. These Standards in turn became the foundation for educating systems engineers. The 499, 499A, 632, 1220, and 15288 Standards cover the systems engineering process and engineering management because there is actually very little systems engineering )the activity not the role( in the subsystem design, construction, and unit testing phases )HKMF Columns C, D and E( of the systems lifecycle for a single system in isolation. Activities pertaining to subsystems and units in isolation are engineering of systems not systems engineering activities according to the criterion defined above. The mantra became ‘follow the process and all will be well’. The term GIGO - garbage in, garbage out, was acknowledged but ignored. In this paradigm:
Table 3 Focus of Standards – Chronological Order
21 קול המערכות, ינואר 2010
8. Based on the issue date of MIL-STD-499, not the draft MIL-STD-499C since the contents of MIL-STD 499A and MIL-STD-499B don’t differ from MIL-STD 499C in this respect.
While the subset of the systems engineering profession focuses on processes )Type II •systems engineers(, the literature on “excellence” focuses on people )Type V systems engineers( e.g. )Peters and Waterman, 1982; Peters and Austin, 1985; Rodgers, et al., 1993(.(.
The focus is on process and not on providing an understanding of the context and the •ability to tailor the process )as was called out in )MIL-STD-499, 1969(. This is seen in systems engineering courses where the students are taught about the process but not about the context.
Processes seen to work in one culture or organization have been copied verbatim by •other organizations, with dismal results. Examples can be found in the lessons learned in )O’Toole, 2004( and )Angel and Froelich, 2008(’s reasons for a claimed Six Sigma initiative 60% failure rate.
The systems engineering process has a high degree of correlation to the problem solving •process because that was the process documented in the Standards. See )GDRC, 2009( and )OVAE, 2005( for typical examples of the problem solving process.
The Standards commonly used/taught in systems engineering )MIL-STD-499, 1969; •MIL-STD-499A, 1974( and )DOD 5000.2-R, 2002( pages 83-84( ignore most of the activities allocated to Phase A in Figure 1 and Phase A of the HKMF resulting in the critical first systems engineering process addressing the conceptual solution being out of mainstream Type II systems engineering. Table 3 contains data extracted from Table 5 in )Honour and Valerdi, 2006( and rearranged in chronological order8 showing the lack of coverage of the mission purpose/definition activities in MIL-STD 499 and ANSI EIA 632. The top row in Table 3 has been added in this paper to show that MIL-STD 499 and ANSI EIA 632 do not cover the conceptual activities in the first systems engineering process and while the Systems Engineering Capability Maturity Model )CMM(, the draft MIL-STD-499C Standard and ISO 15288 do address the mission/purpose definition activities to some extent they also do not cover the conceptual activities in the first systems engineering process. This situation )addressing mission/purpose definition activities to some extent while failing to cover the first systems engineering process( also appeared in a survey of current systems engineering processes in )Bruno and Mar, 1997( and in )Fisher, 1996(’s list of the engineering and systems engineering activities assigned to the systems engineering organization/team based on the )MIL-STD-499B, 1993(/)EIA 632, 1994( Standards.
Table 4 Types of Knowledge (Woolfolk, 1998)
Declarative knowledge Knowledge that can be declared in some manner. It is “knowing that” something is the case. Describing a process is declarative knowledge.
Procedural knowledge Knowing how to do something. It must be demonstrated; performing the process demonstrates procedural knowledge.
Conditional knowledge Knowing when and why to apply the declarative and procedural knowledge.
22 קול המערכות, ינואר 2010
A Benchmark Of Systems Engineering Postgraduate Degree SyllabiA benchmark of systems engineering postgraduate degree syllabi seems to indicate that:
Much of systems engineering is now taught as declarative and procedural knowledge •)See Table 4( )Woolfolk, 1998( describing the second systems engineering process. To be fair, this is not unique to systems engineering )Microsoft, 2008(. For example, Peter Drucker wrote “Throughout management science--in the literature as well as in the work in progress--the emphasis is on techniques rather than principles, on mechanics rather than decisions, on tools rather than on results, and, above all, on efficiency of the part rather than on performance of the whole.")Drucker, 1973( page 509.( Today’s academic institutions seem to be producing Type II systems engineers and managers )engineer leaders(; but they should be producing or at least identifying personnel with Type V characteristics by teaching conditional knowledge.
Some academic institutions teaching systems engineering are leaving out the critical first •systems engineering process of HKMF Column A. For example, a proposed reference curriculum for systems engineering )Jain and Verma, 2007( begins in Column B of the HKMF. This reference curriculum complies with )Martin, 1997( page 95(, )Eisner, 1997( page 9(, )Wasson, 2006( page 60( and )DOD 5000.2-R, 2002(, pages 83-84( which consider requirements as one input to the systems engineering process as mentioned above. This failure to teach the critical first systems engineering process has resulted in )1( at least one generation of “systems engineers” who are unfamiliar with the critical activities in Column A of the HKMF and )2( the terms CONOPS and ‘operations concept’ being used interchangeably by some systems engineers who do not have an appropriate frame of reference to understand the difference between the two documents when old timers try to explain it to them.
Hypothesis For A Reason For The Failure Of Systems EngineeringBased on a combination of the five types of systems engineers and the history of systems engineering paraphrased in terms of those five types, the hypothesis is that a current cause of failures in systems engineering is the assignment of Type II systems engineers or higher types trained in a Type II process thinking paradigm to tasks that need the problem/solution characteristics of the Type III, IV and V systems engineers. The associated prediction to test the hypothesis is that the cost and schedule overruns and other failures will continue in spite of all the funding being allocated to systems engineering education if the education of engineer leaders remains in the Type II paradigm and starts with the activities in column B of the HKMF. Type II systems engineers are and should be doing the engineering of systems )following the process designed by the Type V systems engineers(. Type V systems engineers should be doing systems engineering in Columns A, B, F and G of the HKMF.
RecommendationsThe following recommendations are made to improve systems engineering based on the research so far:
Continue with the development of the SEBoK creating a concept of operations for the 1. product producing activities in each rectangle of the HKMF using the simple activity-
23 קול המערכות, ינואר 2010
based criterion to determine which of the activities are and which are not systems engineering and then defining the knowledge requirements for the activities known as systems engineering.
Investigate the potential of redrawing role boundaries to align with the activity boundaries 2. and remove much of the role overlap and inefficiency in organisations. This approach, which needs more research, would truly reengineer the work of F. W. Taylor )Taylor, 1911(.
Once the activities performed by systems engineers in each area of the HKMF have 3. been identified, an appropriate level of competence for the activity should be made and optimal systems engineering teams could then be designed.
Work with psychologists to identify characteristics of the five types of engineer leaders so 4. that the Type V’s may be identified early in their career and put through fast track training to increase their value to their organizations.
Modify the curriculum for teaching systems engineering to include activities enabling the 5. early identification of potential Type V’s.
Modify the curriculum for teaching systems engineering to include the system engineering 6. activities performed in Column A of the HKMF.
Develop a good set of educational materials for use with the modified curriculum.7.
Identify the activities performed in the non-systems engineering streams in each column 8. of the HKMF. Then determine the knowledge and type of engineer leader needed to make optimal decisions and quantify the risks associated with decision making with specific levels of imperfect knowledge and using the wrong type of engineer leader. This model should inform customers concerning the prediction of the probability of future project failure at any point in any column of the HKMF by comparing the situation in a real project with the data in the model.
SummaryThis paper documented the early phases of using systems engineering to develop a SEBoK and some of the findings. The first part of the paper discussed the nature of the problem and dissolved the problem by applying an out-of-the-box approach. The second part of the paper identified five types of systems engineers, discussed the evolution of systems engineering in terms of those five types, hypothesised that a major cause of the failure of systems engineering is the allocation of inappropriate types of systems engineers to systems engineering activities and identifed a critcal gap in systems engineering education. The paper concluded with some insights from the out-of-the-box approach and recommendations for further study.
ConclusionThe out-of the-box approach to developing the SEBoK seems to be achievable and has produced some interesting insights.
24 קול המערכות, ינואר 2010
BiographiesJoseph Kasser has been a practicing systems engineer for nearly 40 years and an academic for about 10 years. He is an INCOSE Fellow, the author of “A Framework for Understanding Systems Engineering” and "Applying Total Quality Management to Systems Engineering" and many INCOSE symposia papers. He is a recipient of NASA’s Manned Space Flight Awareness Award )Silver Snoopy( for quality and technical excellence for performing and directing systems engineering and other awards. He holds a Doctor of Science in Engineering Management from The George Washington University, is a Certified Manager and holds a Certified Membership of the Association for Learning Technology. He has also served as the initial president of INCOSE Australia and Region VI Representative to the INCOSE Member Board. He gave up his positions as a Deputy Director and DSTO Associate Research Professor at the Systems Engineering and Evaluation Centre at the University of South Australia in early 2007 to move to the UK to develop the world’s first immersion course in systems engineering as a Leverhulme Visiting Professor at Cranfield University. He is currently a principal at The Right Requirement Ltd. in the UK and a Visiting Associate Professor at the National University of Singapore.
Derek Hitchins retired from full time academic work in 1994 on medical grounds, and is now a part-time consultant, teacher, visiting professor and international lecturer. Formerly, he held the British Aerospace Chairs in Systems Science and in Command and Control, Cranfield University at RMCS Shrivenham. Prior to that, he held the Chair in Engineering Management at City University, London. Derek started as a Cranwell apprentice and retired as a wing commander from the Royal Air Force after 22 years, to join industry. His first industry appointments were as the System Design Manager of the Tornado F3 Avionics, Technical Co-ordinator for UKAIR CCIS, and UK Technical Director for the NATO Air Command and Control System )ACCS( project in Brussels. He subsequently held posts in two leading systems engineering companies as Marketing Director, Business Development Director and Technical Director before becoming an academic in 1988. His current research is into system thinking, system requirements, social psychology & anthropology, Egyptology, command & control, system design and world-class systems engineering. He has published three systems engineering books: "Putting Systems to Work", John Wiley & Sons, in 1992; "Advanced Systems Thinking, Engineering and Management," Artech House, 2003; and, “Systems Engineering: A 21st Century Systems Methodology,” John Wiley & Sons in 2007/2008. He inaugurated the IEE’s PG M5 — Systems Engineering. He also started the UK Chapter of INCOSE and was its inaugural president. He is an INCOSE Fellow, an INCOSE "Pioneer" and a Charter Member of the Omega Alpha Association.
Thomas V. Huynh is an associate professor of systems engineering at the Naval Postgraduate School in Monterey, CA. His research interests include complex systems and complexity theory, system-of-systems engineering methodology, and systems architecting. Prior to joining the Naval Postgraduate School, Dr. Huynh was a Fellow at the Lockheed Martin Advanced Technology Center, Palo Alto, CA, where he engaged in research in computer network performance, computer timing control, bandwidth allocation, heuristic algorithms, nonlinear estimation, perturbation theory, differential equations, and optimization. He was also a lecturer in the departments of Physics and Mathematics at San Jose State University. Dr. Huynh obtained simultaneously a B.S. in Chemical Engineering and a B.A. in Applied Mathematics from UC Berkeley and an M.S. and a Ph.D. in Physics from UCLA. He is a member of INCOSE.
25 קול המערכות, ינואר 2010
ReferencesAckoff, R. L., "The Future of Operational Research is Past," Journal of the Operational Research Society, Volume 30, 1979, in Critical Systems Thinking Directed Readings, R. L. Flood and M. C. Jackson (Editors), 1991.
Ackoff, R. L., Ackoff's Best. His Classic Writings on Management, John Wiley & Sons, Inc., New York, 1999.
Angel, C. D. and Froelich, J., Six Sigma: What Went Wrong?, 2008, http://www.destinationcrm.com/Articles/Columns-Departments/The-Tipping-Point/Six-Sigma-What-Went-Wrong-51394.aspx, last accessed 26 April 2009
ANSI/EIA-632, Processes for Engineering a System, American National Standards Institute and Electronics Industries Association, 1999.
Arnold, S. (Editor), ISO 15288 Systems engineering — System life cycle processes, International Standards Organisation, 2002.
Boehm, B., "Integrating Software Engineering and Systems Engineering", Systems Engineering, Vol. 1 (1994), no. 1.
Bottomly, P. C., Brook, P., Morris, P. W. and Stevens, R., "A Study of the Relationship of Systems Engineering to Project Management", proceedings of Fourth Annual Symposium of the INCOSE-UK, 1998.
Brekka, L. T., Picardal, C. and Vlay, G. J., "Integrated Application of Risk Management and Cost of Quality", proceedings of The 4th Annual International Symposium of the NCOSE, 1994.
Brill, J. H., "Systems Engineering ---A Retrospective View", Systems Engineering, Vol. 1 (1998), no. 4, 258-266.
Bruno, M. E. and Mar, B. W., "Management of the Systems Engineering Discipline", proceedings of the 7th Annual Symposium of the International Council on Systems Engineering, Los Angeles, CA., 1997.
Chapanis, A., "Human Engineering," in Operations Research and Systems Engineering, C. D. Flagle, W. H. Huggins and R. H. Roy (Editors), Johns Hopkins Press, Baltimore, 1960.
Denzler, D. and Kasser, J. E., "Designing Budget Tolerant Systems", proceedings of The 5th Annual International Symposium of the NCOSE, St Louis, MO., 1995.
DOD 5000.2-R, "Mandatory Proceedures for Major Defense Acquisition Programs (MDAPS) and Major Automated Information System (MAIS) Acquisition Programs," US Department of Defense, 2002.
Drucker, P. F., Management: Tasks, Responsibilities, Practices, Harper & Roe, New York, 1973.
DSMC, Systems Engineering Management Guide, vol. May 1996, Defence Systems Management College, 1996.
EIA 632, "EIA 632 Standard: Processes for engineering a system," 1994.
Eisner, H., Computer Aided Systems Engineering, Prentice Hall, 1988.
Eisner, H., Essentials of Project and Systems Engineering Management, John Wiley & Sons, Inc., 1997.
Emes, M., Smith, A. and Cowper, D., "Confronting an identity crisis - How to brand systems
26 קול המערכות, ינואר 2010
engineering", Systems Engineering, Vol. 8 (2005), no. 2, 164-186.
Fisher, J., "Defining the Roles and Responsibilities of the Systems Engineering Organization/Team", proceedings of the 6th Annual Symposium of the International Council on Systems Engineering, Boston, MA, 1996.
Frank, M., "Knowledge, Abilities, Cognitive Characteristics and Behavioral Competences of Engineers with High Capacity for Engineering Systems Thinking (CEST)", The INCOSE Journal of Systems Engineering, Vol. 9 (2006), no. 2, 91-103.
GAO, "DEFENSE ACQUISITIONS Major Weapon Systems Continue to Experience Cost and Schedule Problems under DOD’s Revised Policy," GAO, 2006.
GDRC, The Problem Solving Process, 2009, * http://www.gdrc.org/decision/problem-solve.html, last accessed 11 Jan 2009
Gelbwaks, N. L., "AFSCM 375-5 as a Methodology for System Engineering", Systems Science and Cybernetics, IEEE Transactions on, Vol. 3 (1967), no. 1, 6-10.
Goode, H. H. and Machol, R. E., Systems Engineering, McGraw-Hill, 1959.
Hall, A. D., A Methodology for Systems Engineering, D. Van Nostrand Company Inc., Princeton, NJ, 1962.
Hall, C. S. and Lindzey, G., Theories of Personality, John Wiley & Sons, 1957.
Hammer, M. and Champy, J., Reengineering the Corporation, HarperCollins, New York, 1993.
Hari, A., Weiss, M. and Zonnenshain, A., "ICDM - An Integrated Methodology for the Conceptual Design of New Systems", proceedings of System Engineering Test and Evaluation Conference SETE 2004, Adelaide, Australia, 2004.
Hiremath, M., "Systems Engineering in Acquisition Strategy: Change Needed," INCOSE Insight, Vol. 11 (2008), no. 5, 32-33.
Hitchins, D. K., Putting Systems to Work, John Wiley & Sons, Chichester, England, 1992.
Hitchins, D. K., World Class Systems Engineering - the five layer Model, 2000, http://www.hitchins.net/5layer.html, last accessed 3 November 2006
Hitchins, D. K., Advanced Systems Thinking, Engineering and Management, Artech House, 2003.
Honour, E. C. and Valerdi, R., "Advancing an Ontology for Systems Engineering to Allow Consistent Measurement", proceedings of Conference on Systems Engineering Research, Los Angeles, CA., 2006.
Hudson, S. (Editor), Systems Engineering Competencies Framework, INCOSE UK, 2006.
IEEE 1220, "Std 1220 IEEE Standard for Application and Management of the Systems Engineering Process," 1998.
INCOSE Fellows, A Consensus of the INCOSE Fellows, 2009, http://www.incose.org/practice/fellowsconsensus.aspx, last accessed 18 March 2009
Jain, R. and Verma, D., "Proposing a Framework for a Reference Curriculum for a Graduate Program in Systems Engineering", INSIGHT, Vol. 10 (2007), no. 3, 9-11.
JAXA, Basics of Systems Engineering (draft ) , Version 1B, 2007.
27 קול המערכות, ינואר 2010
Jenkins, G. M., "The Systems Approach," in Systems Behaviour, J. Beishon and G. Peters (Editors), Harper and Row, London, 1969, p. 82.
Johnson, S. B., "Three Approaches to Big Technology: Operations Research, Systems Engineering, and Project Management", Technology and Culture, Vol. (1997), 891-919.
Kasser, J. E., "Systems Engineering: Myth or Reality", proceedings of The 6th International Symposium of the INCOSE, Boston, MA., 1996.
Kasser, J. E., "Transition via Transactions: First steps in creating a customer driven organization", proceedings of First World Customer Service Congress, Tyson's Corner, VA, 1997.
Kasser, J. E., "Writing Requirements for Flexible Systems", proceedings of INCOSE-UK Spring Symposium, 2001.
Kasser, J. E., "The Cataract Methodology for Systems and Software Acquisition", proceedings of SETE 2002, Sydney Australia, 2002a.
Kasser, J. E., "Systems Engineering: An Alternative Management Paradigm", proceedings of The Systems Engineering Test and Evaluation Conference, Sydney Australia, 2002b.
Kasser, J. E., A Framework for Understanding Systems Engineering, Booksurge Ltd, 2007.
Kasser, J. E. and Mackley, T., "Applying systems thinking and aligning it to systems engineering", proceedings of the 18th INCOSE International Symposium, Utrecht, Holland, 2008.
Kasser, J. E. and Palmer, K., "Reducing and Managing Complexity by Changing the Boundaries of the System", proceedings of the Conference on Systems Engineering Research, Hoboken NJ, 2005.
Martin, J. N., Systems Engineering Guidebook: A process for developing systems and products, CRC Press, 1997.
Maslow, A. H., The Psychology of Science, Harper and Row, 1966.
Maslow, A. H., Toward a Psychology of Being, Van Nostrand, 1968.
Maslow, A. H., Motivation and Personality, Harper & Row, 1970.
Microsoft, Transforming Education: Assessing and Teaching 21st Century Skills,, 2008, http://download.microsoft.com/download/6/E/9/6E9A7CA7-0DC4-4823-993E-A54D18C19F2E/Transformative%20Assessment.pdf, last accessed 20 March 2009
MIL-STD-490A, Specification Practices, United States Department of Defense, 1985.
MIL-STD-499, Mil-STD-499 Systems Engineering Management, United States Department of Defense (USAF), 1969.
MIL-STD-499A, Mil-STD-499A Engineering Management, United States Department of Defense (USAF), 1974.
MIL-STD-499B, "Draft MIL-STD-499B Systems Engineering," United States Department of Defense, 1993.
Murray, H. A., Explorations in Personality, Oxford University Press,, 1938.
O’Toole, P., "Do's and Don'ts of Process Improvement", proceedings of 2005 U.S. Census Bureau SEPG Conference, Suitland. MD, 2004.
28 קול המערכות, ינואר 2010
OVAE, Problem-Solving Process, 2005, http://www.c-pal.net/course/module3/pdf/Week3_Lesson21.pdf, last accessed 11 Jan 2009
Pennell, L. W. and Knight, F. L., "Draft MIL-STD 499C Systems Engineering," The Aerospace Corporation, 2005.
Peters, T. and Austin, N., A Passion for Excellence, Warner Books, 1985.
Peters, T. J. and Waterman, H. R., In Search of EXCELLENCE, Harper and Row, 1982.
PMI, A Guide to the Project Management Body of Knowledge (PMBOK Guide), Project Management Institute, 2004.
Rodgers, T. J., Taylor, W. and Foreman, R., No-excuses Management, Doubleday, 1993.
Roe, C. L., "The Role of the Project Manager in Systems Engineering", proceedings of The 5th Annual International Symposium of the NCOSE, 1995.
Sheard, S. A., "Twelve Systems Engineering Roles", proceedings of The 6th Annual International Symposium of the NCOSE, Boston, MA., 1996.
Taylor, F. W., The Principles of Scientific Management, Harper & Brothers Publishers, 1911.
Todaro, R. C., "Lecture Handout, ENEE 648R," in, University of Maryland University College, 1988.
Wasson, C. S., System Analysis, Design, and Development concepts, principles and practices, Wiley-Interscience, Hoboken, New JErsey, 2006.
Watts, J. G. and Mar, B. W., "Important Skills and Knowledge to Include in Corporate Systems Engineering Training Programs", proceedings of The 7th Annual International Symposium of the INCOSE, Los Angeles, CA, 1997.
Woolfolk, A. E., "Chapter 7 Cognitive views of learning," in Educational Psychology, Allyn and Bacon, Boston, 1998, pp. 244-283.
Wymore, A. W., Model-Based Systems Engineering, CRC Press, Boca Raton, 1993.
29 קול המערכות, ינואר 2010
האם קיים תכנון מושלם של פרויקט ?גישה מבוססת מודל לתכנון פרויקטים
תקציר מאמרפרויקט ומוצר הם שני פנים המשלימים זה את זה, במחזור החיים של מערכות מורכבות מעשה ידי אדם. הפרויקט מתמקד בהגדרת השלבים והמאמץ שיש להשקיע לטובת הפיתוח, הייצור, האספקה והתחזוקה של המוצר, בעוד שהמוצר עצמו ביניהם שנשמרת תחומים שני הם והמוצר הפרויקט מסורתי, באורח וההתנהגות. המבנה לפונקציונאליות, מתייחס הפרדה ברורה בכל הקשור לגישות, שיטות וכלים. הפרדה זו מונעת את האינטגרציה בין הפרויקט לתוצריו ואת היתרונות
הגלומים בכך לכל בעלי העניין.
ניהול הנדסת המערכת בפרויקט הוא השילוב בין המוצר לפרויקט האמור לספק את המוצר המוגדר. הגדרה משולבת של מערך פרויקט-מוצר לטובת ניהול הנדסת המערכת, נתקלת בקושי בשל היעדרה של אונטולוגיה משותפת לשני התחומים, מתודולוגיה ומודל קונספטואלי משולב. השגת שלושת המרכיבים החסרים הללו תאפשר הבעה בן-זמנית של
פונקציה, מבנה והתנהגות הן של הפרויקט והן של המוצר.
מאמר זה סוקר את השלבים הראשונים של תכנון הפרויקט, במשולב עם תכנון המוצר, ליצירת המודל הקונספטואלי הפרויקט אמור אותו המוצר, של הראשוני התכן קונספט עם היכרות דורש הפרויקט של הראשוני התכנון הראשוני. לספק. תכנון תכנית הפרויקט הראשונית, פירוק תכולת העבודה והקצאת המשאבים, נסמכים כולם על הבנה של תכן העל הראשוני של המערכת הכולל את הפונקציונליות המיוחסת לה, מבנה המערכת ברמת-העל וקונספט ההפעלה של איטראטיביים תהליכים הינם עליו, והבקרה המוצר תכנון גם כמו והבקרה, הפרויקט תכנון המתוכנן. הראשוני גזירה )derivation(, עידון )refinement( והדמיה )simulation( של מודל הפרויקט ומודל המוצר, תוך שמירה על עקיבות ומקובלים קיימים ייצוגים כן, פי על רמות הפירוק. אף בכל למוצר בין הפרויקט )coherence( ועקביות )traceability(לתכנון הפרויקט כגון Gantt, PERT, WBS ו-DSM, מכילים בנפרד חלק מכלל הקשרים בין האלמנטים של הפרויקט לאלמנטים של המוצר. מאמר זה סוקר את גישת התכנון מבוסס-מודל המשמשת לתכנון משולב פרויקט-מוצר, תוך שימוש במתודולוגית תהליכים-עצמים OPM( Object-Process Methodology(. המודל המשולב משמש כבסיס הייחוס ממנו ניתן לגזור את הייצוגים השונים המקובלים בתחום תכנון הפרויקט כך שהתוצרים המתקבלים הינם קוהרנטיים
ובעקיבות מלאה למוצר.
המאמר מציג חלק מתוך מחקר שלם העוסק בשילוב מוצר-פרויקט ומתמקד בשלבי התכן הקונספטואלי הראשוני. מטרת המחקר בכללותו הינה לפתח אונטולוגיה, מתודולוגיה ומודל קונספטואלי לניהול מחזור החיים של המוצר במשולב עם מחזור החיים של הפרויקט שמטרתו להביא את המוצר לכדי מימוש. המודל המשלב בו-זמנית את הפרויקט עם המוצר הפרויקט של אלמנטים בין הקשרים את ישיר באופן לייצר האפשרות בשל מיטביות, ניהול לתוצאות להגיע יאפשר לאלמנטים של המוצר, ולבצע עליהם מעקב ביחס לתכנון. המודל עתיד לסייע למנהלי פרויקטים ומהנדסי מערכות של מערכות מורכבות על פני מחזור החיים המתוכנן, ועשוי להביא לקיצור זמני אספקה, הפחתת סיכונים והגדלת איכות
המוצר.
Amira SharonFaculty of Industrial
Engineering and ManagementTechnion
Israel Institute of TechnologyHaifa 32000, Israel
[email protected] tel. +972503662466
Olivier L. de WeckEngineering Systems
DivisionMassachusetts Institute of
Technology77 Massachusetts Avenue,
Cambridge, MA [email protected]
Dov Dori Technion, Israel Institute of
TechnologyHaifa 32000, Israel,
and Engineering Systems Division
Massachusetts Institute of Technology, Cambridge, MA
30 קול המערכות, ינואר 2010
Is There a Complete Project Plan? A Model-Based Project Planning Approach
AbstractProject planning and control are the essentials of project management. The first steps of the project planning require some knowledge of the concept of the product that the project is expected to deliver. The initial project plan, scope of work, Work Breakdown Structure, and allocation of resources rely on understanding of at least the top-level product functionality, architecture, and concept of operation. The project planning and control is an iterative process of derivation, refinement, and simulation of the product model, while maintaining traceability and coherence between the product model and the project plan at all levels. Nevertheless, existing representations or views for project planning, such as Gantt, PERT, and DSM, contain only a portion of the entire set of relationships among project entities. This paper outlines a model-based approach to project planning, in which a joint project-product OPM model is the basis for the various project management views.
IntroductionSuppose you have been assigned to be the project manager of a new product development type project at Printers LTD. You will be leading the project of developing a new printer, which was identified as a need by the marketing department. As stated by that department's representatives, in addition to the standard printing functions, the printer is required to have two new capabilities: )1( wireless communication with a single computer or in a network, and )2( MS Vista OS compatibility. After some initial exploration, you determine the project scope and stakeholders views and you start thinking about the best way to devise the project plan, which will best serve as the basis for developing this wireless Vista-compatible printer. You know from your past experience that the initial project plan – the definition of tasks, their dependencies and duration, and the allocation of resources – rely on understanding of at least the top level product functionality, architecture, and concept of operation. The project planning and control is an iterative process of derivation, refinement and simulation of the product model, while thriving to maintain consistency and coherence between the product model and the project plan at all levels through the hierarchical structure of both the product and the project, as illustrated in Figure 1.
Figure 1. Building the project plan iteratively while creating the product model
31 קול המערכות, ינואר 2010
With this realization in mind, you start by writing down the major tasks you think are necessary to deliver the printer, trying to determine what tasks must start before others, and what tasks must be completed in order for others to begin. You create the project Activities Network to depict the tasks, duration, and dependency information. The resulting network may have multiple parallel or interconnecting tasks. You plan scheduled milestones, checkpoints, or review points, where all tasks up to each one of those project control points must terminate at that review node.
As you are interested in viewing the information you have modeled in a manner that presents the duration, you will create and inspect the Gantt chart representation of the data. This will provide you with the information of what needs to be done and when. You define the top-level hammock tasks, followed by an iterative drill-down definition of the next level activities under each hammock. Usually, the last data line under each hammock is a milestone for indicating the end event of the specific hammock. Milestones are also used to indicate specific outcomes, associated with end of specific activity. The dependencies among the tasks are defined implicitly, based in the rationale of a "technological order" [Levy et. al. 1963] as understood from the product model.
Basically, the Gantt chart model contains activities )usually in a hierarchical manner(, their duration, milestones )which are assigned zero duration(, and dependencies among the activities. The dependencies are typically Finish-Start )FS(, and each activity can start at its earliest start )ES(. Task durations are deterministic, and no split of activities is modeled.
To gain better understanding of the human resource allocation, you use organizational charts and wish you had a way to automatically connect these chart nodes to specific tasks. Figure 2 presents a Gantt chart for our wireless printer. The first level hammock tasks are Scope, Requirements Analysis, Design Development, Testing, Documentation Preparation, Pilot, and Deployment. These top-level processes are typical and rather generic. The lower-level activities reflect increasingly deeper details and typify the specific product to be delivered by the project. A Gantt chart does not show the importance and inter-dependence of related parallel activities, neither does it show the prerequisite to complete one task before another can begin, as a critical path analysis does. To determine the critical path, you use the Critical Path Method )CPM(, where you obtain, in addition to the tasks' duration and dependency information, also the slack time for each activity, and the critical path. This will provide you with the time required to complete the project, showing which activities are critical to maintaining the schedule and which are not. You know that a delay in the critical path causes a delay of the entire project, and if you are required to accelerate the project, it is necessary to reduce the total time required for the activities along the critical path. However, since the critical path of the activities does not account for the information flow of product parts or required artifacts as they are being designed, you will need to use Design Structure Matrix )DSM, also known as N-square matrix( in order to analyze the interdependencies among the product components information and minimize the design process iterations based on information extracted from the DSM.
Regardless of the way you model and analyze the project plan, you must constantly and closely consult the product model, which is the ultimate project goal. Some of the task names contain product components names, some of the milestones represent completion of product-related issues, and the order of activities is the "technological order" in which the product evolves throughout the project activities. The product model is written all over the project plan, albeit not explicitly.
32 קול המערכות, ינואר 2010
Figure 2. Wireless Printer project plan Gantt chart model
Having studied the different models and representation you had created in order to come up with a good project plan, you might realize that each of these is some derivative of a yet-to-be-determined overall project model, exposing a relatively narrow point of view of the project and even less of the product it is expected to ultimately deliver. How, then, is it possible to evaluate how "good" is your plan? How certain are you that the plan is complete and internally consistent? How can you ensure that the project plan is consistent with the product model to be designed?
A step towards enhancing your confidence in this project plan can be achieved if there was a way in which you could simultaneously model the project processes )activities and tasks(, including their duration and dependencies, together with the project artifacts and their relationships to these processes, as well as resources allocation, in a single coherent model.
The Model-Based Project Plan FrameworkOur Model-Based Project Planning )MBPP( approach calls for construction and utilization of a comprehensive product-integrated project model. MBPP is a derivative of the Project-Product Lifecycle Management )PPLM( approach [Sharon et. al. 2008, Perelman et. al. 2008], which integrates the project domain with the product domain via a shared ontology that explicitly relates project entities to product entities within a unifying frame of reference. PPLM is a combined research effort aimed at developing a methodology and a software environment for fusing the product to be developed with the project as they are executed by the enterprise. More specifically, the research concerns the development of an underlying holistic conceptual model, based on a shared ontology and supported by a software environment, for an integrated project and product lifecycle management. The shared ontological foundations facilitate associating concepts from the three domains, such that the resulting comprehensive model and supported software yield significant cuts in time-to-market, project risks, and product malfunctions.
33 קול המערכות, ינואר 2010
To make the framework useful and beneficial, analysis mechanisms to evaluate the integrated model are defined, including the provision of execution capabilities for evaluation of project constraints and assertions related to the cost, time limits, resource allocation, and "what-if" scenario analyses.
A major challenge is to unify data from different sources through a systematic model-based approach. Hence, the supporting model notation for our MBPP framework must be both formal and intuitive. Desired characteristics of the modeling language include )1( ability to represent large amounts of data in simple, hierarchically organized diagrams, )2( expressiveness that allows definition of a common conceptual metamodel, and )3( formalism and clear semantics that can serve as a basis for model simulation and execution. Since the potential users of our contemplated framework would come from a wide range of disciplines and user profiles, such as project management and enterprise management, while formal, the notation must also be simple and intuitive so all the potential users and stakeholders can relate to the model as it evolves.
The candidate modeling languages were the same as for PPLM, namely UML, xUML, SysML, and OPM. UML and xUML are software oriented and hence less appropriate for modeling of general systems. SysML is designed for general systems and its notation modifies a subset of UML diagrams, while adding two new diagrams: Requirements Diagram and Parametric Diagram. Like UML, SysML handles complexity management primarily via aspect decomposition, while hierarchical breakdown is supported for a subset its diagrams. Unfortunately, the multiple-views model of SysML makes it difficult to comprehend the system as a whole. Unlike xUML, the notation does not use the formal activities specifications, and it allows free text for equation descriptions in the Parametric Diagram. This lack of formality hinders the definition of SysML model-based execution without significantly changing the notation. OPM notation supports conceptual modeling for general systems. Its top-down approach includes refinement mechanisms of in-zooming and unfolding. OPM [Dori. 2002] uses a single type of diagram to describe the functional, structural and behavioral aspects of the system. OPCAT [Dori et. al. 2003], an OPM-based conceptual modeling software environment features an accessible API, a basic animation module, and integration with files of various formats e.g., XML and CSV(, reducing the development effort.
OPM is a holistic, integrated approach to the design and development of systems in general and complex dynamic systems in particular. OPM comprises entities and links. The three entity types are objects, processes )both referred to as "things"(, and states. Objects are things that exist and can be stateful )i.e., have states(. Processes transform objects: they generate and consume objects, or affect stateful objects by changing their states. Objects and processes are of equal importance, as they complement each other in the single-model specification of the system. Links, which are the OPM elements that connect entities, are of two types: structural and procedural. OPM objects relate statically to each other via structural relations, graphically expressed as structural links. The four fundamental structural relations are aggregation-participation, generalization-specialization, exhibition-characterization, and classification-instantiation. Objects can also be structurally related to each other by unidirectional or bidirectional tagged relations, similar to association links in UML class diagrams. Structural relations specify relations between any two objects. Due to the object-process symmetry, they can also specify relations between any two processes. Conversely, procedural links connect a process with an object or an object's state to specify the dynamics of the system. Procedural links include )1( transforming links: effect link,
34 קול המערכות, ינואר 2010
consumption link, result link, and the pair of input-output links, )2( enabling links, which are the agent and instrument links, and )3( control links: event, condition, invocation, and time exception links.
An OPM model consists of a set of hierarchically organized Object-Process Diagrams )OPDs( that alleviate systems' complexity. Each OPD is obtained by in-zooming or unfolding of a thing )object or process( in its ancestor OPD. One or more new things )objects and/or processes( can be specified within a thing in an OPD that was refined from a higher-level OPD. Copies of an existing thing can be placed in any diagram, where some or all the details, such as object states or links to other things, which are unimportant in the context of the diagram, can be hidden. It is sufficient for some detail to appear once in some OPD for it to be true for the system in general even though it is not shown in any other OPD.
The MBPP framework and platform is developed as an extension of Object Process Methodology )OPM(, using the infrastructure provided by OPCAT and taking advantage of its following features:
OPM is a visual methodology that incorporates the static-structural and dynamic-•procedural aspects of a system into a unifying model, which is presented in its entirety using a single diagram type. This is achieved by treating both objects and processes as equally important things )entities(. By using a single model at varying levels of detail, clutter and incompatibilities are likely to be avoided even in highly complex systems.
OPM is designed to express triggering events, guarding conditions, timing constraints, •timing exceptions, and flow-of-control constructs. These features are the basic elements required for exceptional behavior design, which is typical of real-life projects as they execute and therefore need to be simulated.
OPM has proven to be an efficient methodology for modeling complex dynamic behaviors •in general and temporal exceptions in particular. OPM was shown to be significantly better in specification quality, compared with OMT, UML's main predecessor [Peleg and Dori. 2000].
Through its recursive seamless complexity management )scaling, or abstraction/•refinement( mechanisms, OPM is highly appropriate for managing systems' complexities. There are three complexity management mechanisms in OPM: )1( unfolding/folding, which is used for refining/abstracting the structural hierarchy of a thing; )2( in-zooming/out-zooming, which exposes/hides the inner details of things within its frame; and )3( expressing/suppressing, which exposes/hides the states of an object. These complexity management mechanisms enable OPM to represent complex systems gradually.
OPM consists of two semantically equivalent modalities of the same model: graphical and textual. A set of interrelated Object-Process-Diagrams )OPDs( constitute the graphical model, and a set of automatically-generated sentences in a subset of English constitute the Object-Process Language )OPL(. In the graphical-visual model, each OPD consists of OPM elements depicted as graphic symbols, while the OPD syntax specifies the consistent and correct ways by which those elements can be managed. Since the corresponding textual model is generated in a subset of English, it is immediately understood by domain experts, who need not learn any special language nor decipher cryptic code.
35 קול המערכות, ינואר 2010
The Model-Based Project PlanWe now construct and examine the Model-Based Project Plan for the new wireless printer project, prepared in the Model-Based Project Plan Framework of OPM, using OPCAT. Figure 3 shows the OPM top level model for the project. The automatic Object Process Language )OPL(, generated in OPCAT while creating the OPM model, is listed in Figure 4. The top level process at the first System Diagram )SD( of the model, New Printer Project, represents the entire project, which )like any project( is a process, and it is analogous to the first hammock activity in the Gantt chart, which encompasses all the project activities. The duration of this process is the duration of the entire project, and it is either determined a-priori or obtained by recursively aggregating the durations of all the subprocesses. The process is triggered by the New Marketing Requirement for a wireless printer, exhibited by the Marketing Department, which is a part of Printers Ltd. Printers Ltd. consists also of the Project Team, Facilities Set, and Budget. The process is handled by the Project Team )the agent( and consumes the Budget Resources, using the Facilities Set )the instrument(. Facilities Set is instrument of the New Printer Project—it is required for executing the process but is not affected by it. The output of the process is the product – the New Printer in its final state which is complete – exhibiting the Wireless Functionality and the Vista Compatibility.
Figure 3. OPD of the top-level System Diagram (SD) of New Printer Project
36 קול המערכות, ינואר 2010
Figure 4. The automatically-generated top-level OPL paragraph of the OPD in Figure 3
Zooming into the project process New Printer Project )Figure 5( reveals the next-level processes, which are identical to the hammocks of the Gantt chart for the wireless printer, shown in Figure 2: Scope Defining, Requirements Analysis, Design Development, Testing, Documentation Preparation, Pilot, and Deployment, only this time these processes are presented along with the objects flow among them, explicitly addressing the processes order rationale and required outcomes design. Each one of these sub-processes can be further decomposed, using the in-zooming mechanism, maintaining downwards and upwards consistency at each level of decomposition. The automatically generated Object Process Language )OPL( text is listed in Figure 6.
Figure 5. OPD of New Printer Project in-zoomed
37 קול המערכות, ינואר 2010
The Scope Defining process accomplishes two outputs: The Project Scope Document and the Product Specification, both in their initial state. These two outputs are required for the Requirements Analysis process, which also affects Product Specification, and it accomplishes the Requirements Document. The Requirements Analysis process yields the New Printer at its defined state. This New Printer's state together with the Requirements Document, are required for the Design Development process to begin. The Design Development process changes the New Printer's state from state defined to state developed. It accomplishes the Design Document Set required for the Documentation Preparation process and Testing process, both of which enabled simultaneously. The Testing process yields Testing Results at their approved final state, while the Documentation Preparation process yields the Documentation Material at its completed final state. The Deployment process requires the completed Documentation Material and the approved Testing Results. The Deployment process yields the completed New Printer, which is constructed from Reused Sub-Systems Set, as well as Newly Developed Sub-Systems Set.
Figure 6. The automatically-generated OPL paragraph of the OPD in Figure 5
Project Team handles New Printer Project. New Marketing Requirement triggers New Printer Project. New Printer can be defined, developed, tested, or completed. New Printer exhibits Wireless Functionality and Vista Compatibility. New Printer consists of Reused Sub-Systems and Newly Developed Sub-Systems. New Printer Project requires Facilities Set. New Printer Project affects Printers Ltd. New Printer Project consumes Budget and New Marketing Requirement. New Printer Project zooms into Scope Defining, Requirements Analysis, Design Development, Documentation Preparation, Testing, and Deployment, as well as Documentation Material, Testing Results, Requirements Document, Design Documents Set, Product Specification, and Project Scope Document. Documentation Material can be completed or in progress. completed is final. Testing Results can be approved or in progress. approved is final. Product Specification can be initial, revised, or final. initial is initial. Project Scope Document can be initial, revised, or final. initial is initial. Scope Defining yields initial Project Scope Document and initial Product Specification. Requirements Analysis affects Product Specification. Requirements Analysis consumes initial Project Scope Document. Requirements Analysis yields Requirements Document and defined New Printer. Design Development requires Requirements Document. Design Development changes New Printer from defined to developed. Design Development yields Design Documents Set. Documentation Preparation requires Design Documents Set. Documentation Preparation yields completed Documentation Material. Testing requires Design Documents Set. Testing changes New Printer from developed to tested. Testing yields approved Testing Results. Deployment requires approved Testing Results and completed Documentation Material. Deployment yields completed New Printer.
38 קול המערכות, ינואר 2010
Modeling each one of the New Printer Project subprocesses further is conducted in the same manner. In-zooming into the Scope Defining process )Figure 7( shows again the required two basic essential inputs – the Budget resources )consumed by the process( as well as the Project Team )to handle the process(. Examining the objects in Figure 7, we can clearly see the things that reside in the product domain, which are colored in yellow: The objects—Product Specification, and New Printer—the final product, as well as specific attributes of the Selected Alternative. Things in the project domain, identified by their green color, include Project Scope Document, the Cost attribute of each Alternative under the Alternatives Set, and the Cost and Schedule attributes of the Selected Alternative. The things that are common to both the project and the product domains are colored in light blue )which is the color obtained by mixing green with yellow(: The Alternatives Set, which obviously contains both product- and project-related data and issues, including the associated Risk for each Alternative, which is also constructed based on data from both domains. The automatically generated Object Process Language )OPL( text is listed in Figure 8.
Figure 7. OPD of Scope Defining in-zoomed
39 קול המערכות, ינואר 2010
Figure 8. The automatically generated OPL paragraph of the Scope Defining process
The entire project is further modeled through concurrent hierarchical decomposition of processes and objects. Using this approach the model ultimately contains the activities and tasks )which are simply processes at various detail levels( required for completing the product, the artifacts )mainly model-based documents( created during the project process, and the different resources, both agents and budget. Having all this information embedded consistently in the same model eventually yields all the specific structural relations )among objects( and procedural relations )between objects and processes(. The project planner can model the rationale for the processes order by identifying the objects flow in and out of each process. Understanding the objects hierarchy hand-in-hand with the project progress is the rationale for the technological process order and timing.
Another advantage of this model-based project planning approach is the capability of zigzagging between the product domain and the project domain in the same model. In fact, the planner must perform this back-and-forth thinking process while planning in order to come up with a project plan that best addresses the product to be accomplished by the project.
The ability to simultaneously express the required information from both domains within a single integrated model-based framework can potentially lead to a more reliable project plan, which is less prone to the need for repeated changes. The increased robustness of the resulting project plan results from having to make the decisions about the project's process order and logic while explicitly addressing the associated product model. The planning process carried out following this approach clarifies the intricate relationships between the project and product entities. This model-based approach enables the simultaneous expression of the function, structure and behavior of both the project and the product via the same ontological and methodological foundations, maintaining full traceability between the project and product data.
Project Team handles Scope Defining. Project Scope Document can be initial, revised, or final. initial is initial. Product Specification can be initial, revised, or final. initial is initial. Scope Defining requires Facilities Set. Scope Defining consumes Budget. Scope Defining zooms into Solution Exploration, Alternative Selection, and Scope Finalizing, as well as Selected Alternative, Schedule, Cost, Risk, Cost, Risk, Alternatives Set, Alternative, Functionality, and Architecture. Selected Alternative exhibits Risk, Cost, Schedule, Architecture, and Functionality. Alternatives Set consists of many Alternatives. Alternative exhibits Risk and Cost. Solution Exploration yields Alternatives Set. Alternative Selection consumes Alternatives Set. Alternative Selection yields Selected Alternative. Scope Finalizing consumes Selected Alternative. Scope Finalizing yields initial Product Specification and initial Project Scope Document.
40 קול המערכות, ינואר 2010
The Generic Project ConstructInvestigating the complete project model throughout its levels reveals a basic Generic Project Construct )GPC(, which is presented in Figure 9. This generic construct contains one Process representing a single activity at any level, with an associated Duration, related to at least three generic object-sets )one or many(: Budget )the input(, Human Resources Set )the agent(, Facilities Set )the instrument( and Deliverables Set )the output(. The logic behind this generic construct is that a process is aimed at achieving a specific Deliverables Set and it can be accomplished by the Human Resources Set, Budget, and Facilities Set. The Deliverables Set may include artifact such as documents, approvals, simulations, analysis, specifications, and reports. Each one of these artifacts results explicitly from a specific process and used )usually as instruments, since they are informatical objects and hence are not consumed( in a subsequent process.
Using the GPC facilitates complete modeling of the entire project, as it provides a means for explicitly addressing the artifacts that are generated and required along the project process, together with the time aspects for these artifacts, as derived from the relevant processes duration. The resulting project plan integrally incorporates the product to be designed, manufactured, delivered, used, serviced, and disposed of, with the project, including all its significant artifacts, such as resources and their allocation, timetable, limits and milestones, evaluation of project constraints, and assertions related to its cost and duration. Since all the entities and their relations are represented in the model, automatic procedures can be devised to generate other project view representations, such as Activities Network Plan, Gantt chart, PERT, Organizational charts, DSM, and CPM analysis.
The Activities Network Plan view is generated based on the dependencies between processes in the OPM model-based Project Plan. Each process turns into an activity node of the network, and all its predecessors are identified and automatically converted into adequately linked nodes while maintaining their names. Since the OPM Project Plan is hierarchical, the user can choose the level of Activities Network Plan she whishes to look at. The coherence of the network is valuable, since although an Activities chart might be created for the entire project, size limitations of real-life projects require breaking the top-level chart into smaller, manageable parts, which are not necessarily coherent with each other, or with the entire project network. The automatically-generated nested Activities Network Chart maintains the required coherence and enables zooming in or out as necessary, in order to gain full comprehension of the network.
Figure 9. The Generic Project Construct (GPC) of the Model-Based Project Plan
41 קול המערכות, ינואר 2010
The classical Activities Network contains all the processes without dataflow, but the automatic extraction from the OPM model-based Project Plan enables viewing an Enhanced Activities Network Plan, in which the processes and the objects are simultaneously displayed, along with their input, output, agent, and instrument relationships. A simple mechanism can show or hide the dataflow of objects among the processes, at each level of detail in the Enhanced Activities Network )EAN(. Assigning probabilistic durations to the processes in the OPM model-based project plan, followed by applying the OPCAT simulation mechanism to the project model will provide statistical estimations of the project duration processes and their corresponding budget allocations.
If Early Start )ES(, Late Start )LS(, Early Finish )EF(, and Late Finish )LF( constraints have been determined for the processes in the OPM model-based Project Plan, then the critical path can be obtained in the OPM model. Furthermore, this information can be extracted from the OPM model, copying the data to the corresponding activity nodes, and presented in its common CPM view. Like the Activities Network, the classical CPM view lacks dataflow. Automatic extraction of the CPM view from the OPM model-based Project Plan enables the view of an Enhanced Critical Path )ECP( showing the processes and objects simultaneously. This enables the project manager to detect not just the critical path, but also the critical artifacts )human resources, budget…( and risks—those that are related to the processes along the critical path—and monitor them closely. Knowing what these artifacts and risks are, enabling to focus on managing them with high priority, adds value to the project management process. Rather than inquiring about the processes designed to achieve and produce these different artifacts, the project manager can monitor the status of the different artifacts themselves, including documents, approvals, simulation outcomes, analyses, specifications, and reports. This, in turn provides the project manager with the flexibility of treating the processes not as end in itself but rather as a means, vehicles for obtaining the required artifacts and optimizing the processes accordingly to achieve the critical artifacts rather than complete the critical tasks. In other words, the ability to describe the critical path in terms of products )artifacts( rather than the processes that yield them, can be extremely valuable to the project manager, since one can easily spend the budget and time on completing less critical processes, or "spin the wheels in neutral" on work activities, and produce outputs that do not advance the project goals and deliverables.
The Gantt chart is the view that is simplest to automatically generate from the OPM model-based Project Plan, since its structure contains all the processes in their exact hierarchical structure. Some project planning software packages )e.g., MS-Project( treat a milestone the same as a process )activity( only with zero length. However, semantically, a milestone is an event—a point in time at which some important happening occurs in the project system. To remedy this, a special transformation rule has been devised within the model-based OPM project plan, for the last process at each level, along with its related objects, enabling the smooth transformation of theses final constructs in the OPM project plan to corresponding milestones in the Gantt chart, and visa versa.
The three different types of DSM presented in Table 1 can also be automatically generated from the OPM model. The Process-based DSM is obtained from the relationships defined in the OPM model. Examining the generated DSM, identifying blocks of coupled activities, iterations and re-sequencing product development tasks to minimize budget and duration can be integrated into OPM. Since the OPM model includes the project and product objects in addition to the processes, the automatic generation of the component-based DSM can also be extracted based on the relationships established in the OPM product model. As a
42 קול המערכות, ינואר 2010
result of the inclusion of all agent human resources in the OPM model-based project plan, it is also possible to automatically produce the Organizational-based DSM or social network, as revealed from the assignment of the humans in the model.
Table 1. Different types of Dependency Structure Matrix (DSM)
Summary and Future ResearchThe model-based project management )MBPM( paradigm proposed in this paper can be considered a subset of model-based systems engineering )MBSE(. Indeed, some general benefits of MBSE are especially notable and valuable in MBPN. These include the ability to gain deep comprehension of the project-product super-system and to derive the various project management tools and views from the unifying project-product model. We have focused on the model-based construction of the project plan. The Model-Based Project Plan )MBPP( is the basis for MBPM. Starting with construction of an OPM model of the project and the product it is expected to deliver, we obtain a comprehensive model that serves as a basis for deriving the customary repertoire of project management tools. However, rather than being constructed separately and independently, which is a certain source of mismatches and incompatibilities with potential detrimental consequences to the project success, these project views are merely reflections of various aspects of a comprehensive underlying model and are therefore consistent and coherent. Any change in the project model is automatically reflected in the various project management tools—Activities Network, CPM, DSM, WBS, and Gantt. Moreover, any change in the product to be delivered—the ultimate output of the project—can be modeled in the joint project-product model and its implications on the project parameters can be directly inspected and assessed.
The fact that the model integrates the process view of project activities and tasks with the object view of the product deliverables with its components at all levels and their associated artifacts, enables the project manager to focus on advancing the completion of the output deliverables rather than on just performing processes without direct reference to their anticipated outcomes. Knowing the critical path and the critical artifacts—those generated by processes along the critical path—enables to closely manage and monitor them. Future work includes the following research items:
Specifying • algorithms for creating the various project management tools from the OPM model and automatically updating them in response to changes in the project plan or product specification.
Enabling real-time instance and data-based • execution of the project model for simulation, exploration, and forecasting purposes. Using the enhanced execution
DSM Data Types Representation Application Analysis Method
Process-based )Task-based, Activity-based(
Activity input/output relationships Project planning Sequencing &
Organizational-based Multi-team interface characteristics
Organizational design, interface management,
team integrationPartitioning
Component-based Multi-component relationships System architecting, Clustering
43 קול המערכות, ינואר 2010
capabilities of OPCAT, it will be possible to simulate and adapt the project and product parameters for feasibility or even optimality of the project's designed timeline, resource allocation, and tradeoff of product functionality and deliverables.
Developing mechanisms for effectively • assessing and managing risks that relate to processes and their resulting objects along the critical path by monitoring them more closely than other, less critical risks and mitigating them by allocating more resources to reduce the probability of their occurrence.
Concurrently monitoring and controlling both the project and product evolution, the •product manager will be able to take corrective actions in real time as needed if potential deviations are detected via the execution-based simulation or if actual deviations are detected via close monitoring of the interacting project-product lifecycles within the enterprise or in relation to subcontractors' deviations from their schedules, and
Developing mechanisms for answering "what-if" questions that enable executives •to assess the impact of changes requested by the customer or are about to be introduced to the product during its design due to technological, legislative, or economical considerations, in terms of impacting cost, risk, and time-to-market. What-if analysis based on possible architecture models can be conducted to help achieve objective and rationalized decisions regarding the appropriate architecture from the set of potential candidates. Such analysis can reveal contradicting requirements and find out corrective actions in order to improve the analyzed architecture. Finally, the system model analysis reduces the risk of developing a system with architecture that does not meet the requirements and the technical, legal, and/or environmental constraints.
ReferencesSharon, A., Perelman V., and Dori, D. 2008. A Project-Product Lifecycle Management Approach For Improved Systems Engineering Practices. In Proceedings of the Eighteenth Annual International Symposium of the International Council on Systems Engineering )Utrecht(: INCOSE.
Perelman, V., Sharon, A., and Dori, D. 2008. Towards a Unified Product and Project Lifecycle Model )PPLM( for Systems Engineering. In Proceedings of ESDA 2008 – 9th ASME Engineering Systems Design and Analysis Conference, Haifa, Israel, July 7-9, 2008.
Dori, D. 2002. Object-Process Methodology – A Holistic Systems Paradigm, Springer Verlag, Berlin, Heidelberg, New York.
Dori, D. Reinhartz-Berger, I., and Sturm, A. 2003. Developing Complex Systems with Object-Process Methodology using OPCAT. Conceptual Modeling – ER 2003. Lecture Notes in Computer Science )2813(, pp. 570-572, 2003.
Levy, K.F., Thompson, G. L and Wiest, J.D. 1963. The ABCs of the Critical Path Method, Harvard Business Review, #63508, Harvard Business School Publishing.
Peleg, M. and Dori, D. 2000. The Model Multiplicity Problem: Experimenting with Real-Time Specification Methods," IEEE Transactions on Software Engineering, vol. 26, pp. 742-759.
44 קול המערכות, ינואר 2010
BiographiesAmira Sharon is Systems Engineer at IAI – Israel Aerospace Industries' ELTA Division and a Ph.D. candidate of Information Management Engineering at the Technion. She holds a B.Sc. in Mechanical Engineering )1992( and M.Sc. in Industrial Design )1997( from Technion. Her professional career spans the areas of programming, systems engineering, and data management of large scale projects. During the past seven years, she has been leading systems engineering methodologies development and implementation across IAI.
Olivier L. de Weck is Associate Professor of Aeronautics and Astronautics and Engineering. He holds an industrial engineering degree from ETH Zurich )1993( and Ph.D. in aerospace systems engineering from MIT )2001(. Before joining MIT he was a liaison engineer and later engineering program manager on the F/A-18 aircraft program at McDonnell Douglas )1993-1997(. His research interests, teaching emphasis and professional experience is mainly in two areas: Systems Engineering for Changeability and Commonality and Space Exploration Logistics. Prof. de Weck is an Associate Fellow of AIAA, winner of the 2006 Frank E. Perkins award for excellence in graduate advising and recipient of the 2007 AIAA MDO TC outstanding service award. He won two best paper awards at the 2004 INCOSE Systems Engineering Conference, held the Robert Noyce Career Development Professorship from 2002-2005, and co-advised the best MIT System Design and Management thesis in 2005. He has over 100 journal and conference publications in the area of systems engineering and space systems design for exploration and communications. His research has been funded by GM, NASA, BP, JPL, Arvin Meritor, DARPA/AFRL and the Alfred P. Sloan Foundation. Prof. de Weck is a member of the International Council on Systems Engineering )INCOSE( and the American Society of Engineering Education )ASEE(. He served as the General Chair for the 2nd AIAA MDO Specialist Conference in May 2006. He serves as a faculty mentor to a number of student teams.
Dov Dori is Visiting Professor at MIT's Engineering Systems Division )ESD(. Between 2001 and 2008 he was Head of Technion's Area of Information Systems Engineering at the Faculty of Industrial Engineering and Management, and Research Affiliate at MIT. Between 1999 and 2001 he was Visiting Faculty at MIT's Sloan and ESD. Professor Dori received his B.Sc. in Industrial Engineering and Management from the Technion in 1975, M.Sc. in Operations Research from Tel Aviv University in 1981, and Ph.D. in Computer Science from Weizmann Institute of Science, Israel, in 1988. Between 1978 and 1984 he was Chief Industrial Engineer of the MERKAVA Tank Production Plant. His research interests include Model-Based Systems Engineering, Systems Development and Lifecycle Methodologies, and Information Systems Engineering. Between 1999 and 2001 he was Associate Editor of IEEE T-PAMI and is currently Associate Editor of Systems Engineering. He is author/co-editor of four books and author of over 150 publications. Prof. Dori is Fellow of the International Association for Pattern Recognition )IAPR(, Senior Member of IEEE and ACM, and member of INCOSE.
45 קול המערכות, ינואר 2010
Organized By The Gordon Center For Systems Engineering With The Support Of Iai , Rafael, Incose_il & Iltam In Conjuction With Yossi Levine Day For Systems Engineering
08:30 – 09:30 Gathering
09:30 – 10:00
Opening:•Prof. Aviv Rosen-the head of the Gordon Center- Technion• A Representative of IAI Management• A Representative of RAFAEL Management• Yossi Levine Family• Excellent Systems Engineers Awards
10:00 – 11:15 Prof. Nancy Leveson, MIT- A New Approach to System Safety Based on Systems Theory
11:15 – 11:45 Coffee Break
11:45 – 13:00 Prof. Nancy Leveson, MIT – Case Studies of the New Approach to System Safety
13:00 – 13:30A PANEL DISSCUSION: How to Integrate Safety Aspects into the System Design?• Panelists: Dr. Michael Maharik, Safety Expert, Rafi Miron, RAFAEL
13:30 – 14:30 Lunch Break
14:30 – 16:00 Prof. Olivier de Weck, MIT – Design For Changeability- An Essential Aspect for the Systems Designers
16:00 – 16:30
A PANEL DISSCUSSION: How to Educate our Systems Designers for Changeability?• Panelists: Dr. Avner Engel, Dr Zeev Mitelman, RAFAEL, Prof. Menachem Weiss, TECHNION
16:30 – 17:00 CONCLUSIONS: Prof. Aviv Rosen,Technion, Gordon Center, Dr. Avigdor Zonnenshain, RAFAEL, Dr. Michael Winokur, IAI
ההשתתפות ביום העיון הינה ללא תשלום[email protected] :נא אשר/י השתתפותך עד תאריך: 24.12.09 בדוא"ל
ההרשמה הינה מראש ואישורה על-ידינו ישמש אישור כניסה לטכניון אשר יועבר בדוא"ל
אל : מרכז גורדון-טכניון אני מאשר השתתפות ביום העיון , בתאריך – 24.1.10
שם: __________________ חברה: _______________ תפקיד: __________________
טל': __________________ אימייל: _______________________________________
Innovative Approaches For Systems Safety & Changeability הזמנה ליום עיון 24.1.10
יתקיים במוסד נאמן- אולם בטלר הממוקם בבניין פורשהיימר, טכניון חיפה
46 קול המערכות, ינואר 2010
Invitation
A New Approach to System Safety How to Better Understand Accidents & How to Prevent Them
Herzlia 25.1.2010-26.1.2010
Prof. Nancy Leveson, MIT The seminar will teach how to use the new system’s theoretic approach to safety. While the approach seems new or paradigm changing, it is rooted in control theory and the system engineering ideas developed for ballistic missile systems after World War II. The new approach to be presented returns to these ideas and updates them for today’s technology. Safety engineering returns to being an integral part of system engineering.
The tutorial will start by introducing a new, extended accident causality model called STAMP. Current accident causality models assume that losses are caused by component failure and that making the components highly reliable or planning for their failure will prevent accidents. While this assumption is true in the relatively simply electro-mechanical systems of the past, it is no longer true for the types of complex socio-technical systems we are building today. Accidents are increasingly the result of interactions among system components that have not failed. The complexity of our systems makes it impossible, however, to anticipate and guard against all potential interaction and interface problems. A new, extended model of accident causation is needed to underlie more effective system engineering approaches to improving safety and better managing risk in these complex systems. In the new paradigm, the emphasis changes from “prevent failures” to “enforce the behavioral safety constraints.”
The rest of the tutorial will teach how to apply the new causality model in accident/incident analysis; hazard analysis; safety-driven design; and requirements generation and analysis. A new hazard analysis technique, called STPA, will be presented along with examples of how to use it. STPA can be used very early in development to provide the information necessary to create safe designs from the start. The emphasis changes from assessing the safety of a proposed design to using the results of hazard analysis to build safety into the design from the beginning. Finally, some basic principles for managing safety-critical projects will be described along with an example of an extremely successful implementation of these principles—the U.S. Navy atomic submarine safety program called SUBSAFE.
About the speakerProf. Nancy Leveson, MIT: Nancy Leveson is Professor of Aeronautics and Astronautics and also Professor of Engineering Systems at MIT. She is an elected member of the National Academy of Engineering )NAE(. Prof. Leveson conducts research on the topics of system safety, software safety, software and system engineering, and human-computer interaction. In 1999, she received the ACM Allen Newell Award for outstanding computer science research and in 1995 the AIAA Information Systems Award for "developing the field of software safety and for promoting responsible software and system engineering practices where life and property are at stake." In 2005 she received the ACM SIGSOFT Outstanding Research Award. She has published over 200 research papers and is author of a book, "Safeware: System Safety and Computers" published by Addison-Wesley and a new book to be published next year titled “Engineering a Safer World.” She consults extensively in many industries on the ways to prevent accidents.
http://sunnyday.mit.edu
Registration: [email protected] or call ILTAM Office 03-5118112
47 קול המערכות, ינואר 2010
InvitationStrategic Systems Engineering For Changeability & Commonality
Designing Systems For an Uncertain FutureHerzlia 25.1.2010
Prof. Olivier de Weck, MIT Increasingly, complex engineering systems have to account for partially unknown future requirements rather than being designed to a single “optimal” point. A key issue is that properties that are desirable in the long term, such as changeability, often cause short-term performance and cost penalties. How can such tradeoffs in system design be modeled and resolved? How can we identify changes that are likely to propagate? Are there generalizable principles across multiple domains, or must each engineering project be treated as a unique undertaking? Many engineering systems of the past were designed with only immediate use in mind as well as in relative isolation from broader considerations of context and uncertainty. This has led to some spectacular technical and business failures due to lock-in, i.e. the inability to change. Noteworthy examples are the bankruptcies of the Iridium and Globalstar satellite constellations in the 1990s, the inflexibility of GM’s car factories and platforms that were designed for mass production rather than for customization as well as the NASA Space Shuttle that was designed for an aggressive traffic model that never materialized. Strategic Systems Engineering is both a philosophy as well as a collection of methods and tools that emphasizes designing systems and products for an uncertain future. Rather than optimizing for best performance or minimal cost, strategic engineering emphasizes the maximization of lifecycle value under uncertainty. This workshop presents a way of thinking and a set of methods and tools that help to better design systems for changeability to uncertain future requirements. What you will learn:
Examples and case studies of systems that were built to a fixed forecast and failed1. How to distinguish and model different types of epistemic and aliatoric uncertainty using techniques such as 2. Geometric Brownian Motion, binomial trees and jump-diffusion models.How to think about and analyze engineering changes and change propagation in complex systems such as radar 3. systems, aircraft, launch, automobiles, launchers and energy systemsHow to quantify the cost of changing and evolving systems over their lifecycle4. How to identify and build in opportunities for flexibility in system design5. How to combine everything into an overall analysis framework called time-expanded decision networks )TDN(6. What the advantages are of TDN compared to traditional decision trees7. To apply strategic engineering to system design problems in your domain through small group exercises and 8. discussion
Prof. Olivier de Weck - Associate Professor of Aeronautics and Astronautics and Engineering Systems Massachusetts Institute of Technology )MIT(.Olivier de Weck is a tenured professor of Engineering at MIT and holds degrees in industrial engineering from ETH Zurich )1993( in Switzerland and aerospace systems engineering from MIT )1999,2001(. Before joining MIT he was a liaison engineer and later engineering program manager on the F/A-18 aircraft program at McDonnell Douglas )1993-1997(. He currently serves as Associate Head of the MIT Engineering Systems Division with 53 faculty members and staff and a total of 440 graduate students. His research interests, teaching emphasis and professional experience is mainly in two areas:
Systems Engineering for Changeability and Commonality.•Space Exploration Logistic. •
http://strategic.mit.edu
Registration: [email protected] or call ILTAM Office 03-5118112
