יום אחד בעבודה, ראש הקבוצה שלנו החליט שזמן רב מדי לא הייתה ישיבת קבוצה. הוא ריכז ספונטנית את כל חברי הקבוצה, בעמידה, באחד החדרים ומסר כמה עדכונים בנושאים שונים. אחד מהם היה מינויי לארכיטקט "effective immediately".
לא הייתי מוכן, לא ציפיתי, ולאחר התרגשות קצרה הדבר הראשון שעשיתי הוא "לפנק" את עצמי ב 3 ספרים מאמזון על ארכיטקטורת תוכנה. כלומר - רציתי לדעת "מה עושים ארכיטקטים?".
הספרים היו בעלי שמות גדולים, ביקורות מצוינות באמזון, והייתי מוכן להישבע שראיתי אחד או שניים מהם במשרדים של כמה טכנולוגים חזקים בחברה. אבל אחרי שקצת קראתי בהם - רציתי לבכות!
"באמת ארכיטקטורה זה כ"כ משעמם?" - היה קול אחד שניקר בראשי.
אולי אני לא מבין שומדבר ("you know nothing Jon Snow") - היה קול ספקני שני.
ברטרוספקטיבה של כחמש שנים לאחור, ברור לי שהספרים הללו, המקובלים בג'אנר, תרמו לי מעט. גם כי תיארו תפקיד קצת שונה מזה שעשיתי, אבל בעיקר מכיוון שרוב הכלים שהם הציעו - היו תרגילים תאורטיים שלא סייעו לי לפתור בעיות בפועל - ורובם לא מסייעים לי גם כיום לאחר שעברתי כברת-דרך כארכיטקט.
בכל זאת, מתוך מגוון הכלים (קרי, תרגילי מחשבה חביבים) המקובלים בקרב פורומים של ארכיטקטורת תוכנה [א], מספר קטן של כלים היה שימושי והועיל לי בפועל ליצור תוכנה טובה יותר.
אחד הכלים הללו נקרא מאפייני איכות (Quality Attributes) - ועליו נדבר בפוסט זה.
הערה: יוצא לי בפוסט זה, ובפוסטים אחרים להתייחס ל"ארכיטקט" מול "לא-ארכיטקט". אנא סלחו לי. ההפרדה הזו היא מלאכותית ולא בעלת משמעות רבה. בפועל כולנו אנשי תוכנה, ו"עשיית ארכיטקטורה" איננה שמורה לבעל תפקיד (או תואר) כזה או אחר. תודה לישראל שהעלה את הנקודה.
מה מאפייני-איכות הם לא?
הנה screenshot ממצגת שראיתי, אשר ניסתה להסביר "מהם מאפייני איכות":
המטפורה הזו היא שטותית!
מצד אחד בניין חרב, ומצד שני מלון מפואר. האם ללא מאפייני איכות המוצר שלנו יהיה שבור ומקולקל? - ברור שלא!
האם בעזרת מאפייני איכות המוצר שלנו יהפוך למוצר יוקרה? אולי הוא מוצר יוקרה - אך אין קשר.
לא קיים מוצר ללא מאפייני איכות. לכל היותר קיים מוצר שמאפייני האיכות שלו נקבעו בצורה לא-מודעת.
אז מה הם מאפייני איכות?
מאפייני איכות הן סט התכונות של המוצר שמאפיינות את השימוש שלו. לעיתים קרובות עושים בספרות הבחנה בין Functional Requirements, שהם "פיצ'רים", לבין Non-Functional Requirements שבניהן גם מאפייני האיכות. "דרישות רוחביות". הבחנה זו שימושית במידת מה, אך איננה מדוייקת לגמרי.
אנסה להסביר מהם מאפייני איכות בעזרת דוגמה: חי-הסוללה של מחשב נייד (Laptop).
על מנת להגיע לחיי סוללה גבוהים של מחשב נייד מנהל המוצר יכול לדרוש "סוללה חזקה במיוחד" שזה סוג של "פ'יצר" - אך זה לא יספיק. על מנת שהמכשיר יחזיק זמן רב ללא טעינה יש להשתמש ברכיבים (מעבד, דיסק) שצורכים מעט חשמל ולעתים קרובות יש תוכנה תומכת (כגון כיבוי משדר ה wi-fi או אפילו מחברי ה USB לאחר זמן ללא שימוש).
חיי סוללה נמוכים לא מעידים על מוצר באיכות ירודה. ייתכן מחשב פרמיום שבו הסוללה מחזיקה פחות משעתיים ("מחשבי גיימינג") ומוצר זול (נטבוקים) שסוללתם מחזיקה 8 שעות ויותר.
חיי סוללה נמוכים הם גם לא משהו ש"אפשר" לפתוח באג עליו. כלומר - בוודאי שאפשר, אך על מנת "לפתור את הבאג" יהיה צריך לבצע תכנון מחדש של המוצר - זו לא תקלה נקודתית.
אנו רואים ש"חיי סוללה ארוכים", עבור מחשב נייד, זו איכות רוחבית של המוצר. "מאפיין איכות" (Quality Attribute), בשפה שלנו.
הנה דוגמה לבחירה בין מאפייני איכות שונים:
טויוטה לנד-קרוייזר ופולסוואגן פולו הם שני מוצרים מעולים. מהטובים בתחומם - הצלחה הנדסית אמיתית. שניהם "מסיעים אנשים ממקום למקום". שניהם "נוסעים על כביש". לשניהם "4 מושבים או יותר" ולשניהם יש "רדיו ומזגן". אם כך - מה ההבדל בניהם?
מכיוון שכולנו מבינים טוב יחסית ב Domain של המכוניות - התשובה נראית ברורה:
לנד-קרוייזר הוא רכב שטח בעל עבירות גבוהה ונוחות גבוהה גם בשטח קשה ("עושה לכם קרוז על הקרקע הקשה").
פולו הוא רכב קטן ומגניב שקל (יותר) למצוא איתו חניה בת"א, הוא מעוצב למדי וצורך מעט דלק.
ניתן לומר שבנוסף לצרכים בסיסיים מאוד של "הסעת נוסעים" - כל אחד מהרכבים מספק צרכים אחרים שמאופיינים באיכויות רוחביות של המוצר.
מאפייני איכות בעולם התוכנה
עד כאן הדוגמאות עסקו במוצרים שאנו כבר מכירים, והיטב, מחיי היום-יום.
נעבור למוצר פחות ברור: שירות שמאכסן קבצים עבור משתמשי המערכת שלכם. איש המוצר יכול להגדיר "כמשתמש, אני רוצה ללחוץ על כפתור כחול עגול ולטעון קבצים במערכת לנוחויותי".
כמה אכסון נדרש? איזו אמינות? זמינות? ביצועים? אבטחה?
ברוב המקרים, איש המוצר לא יתייחס בדרישותיו להיבטים אלו. "פשוט שיעבוד" יאמר סוג אחד של איש מוצר, "הכי טוב שקיים, כפול 10 (ליתר ביטחון)" - היא גישה נפוצה אחרת.
מצד שני יבואו המפתחים עם שאלות:
אתה רוצה להשקיע 5 ימי פיתוח בהגנה בפני Directory Traversal[ב]? זו כמובן שאלה לא הוגנת - שרוב אנשי המוצר פשוט לא מסוגלים לענות עליה.
"כמה יהיה 'ציון האבטחה' של המערכת שלנו עם ובלי Directory Traversal?" היא שאלת הנגד המעשית של איש המוצר - שהמפתחים מצידם לא יהיו מסוגלים לספק לה תשובה.
לבחירת מאפייני האיכות במוצר שלנו יש השפעה רבה על עלות פיתוח המוצר, אך חשוב מכך - על שביעות הרצון וההתאמה ללקוח.
כדאי מאוד שמישהו ייקח באופן מודע את ההחלטה לגבי מאפייני האיכות, מישהו:
חשוב להבין: תרכובת הידע הנדרשת לקבלת החלטה טובה היא לא טריוויאלית, ועל מנת לייצר אותה ארגונים נדרשים להשקיע לא מעט באותם האנשים: לחשוף אותם ללקוחות וקבלת ההחלטות, לספק להם דיי זמן כדי להתעמק מקצועית, לסייע להם לבנות את הביטחון על מנת שיוכלו לעמוד מאחורי ההחלטה.
הדרך בה אני נתקלתי בעבודה עם מאפייני איכות, בהגדרת מוצר חדש, היא כזו:
חילקתי פוסט זה (שהתארך) ל-2 חלקים.
בחלק השני נעסוק בדרך השימוש של מאפייני האיכות בפועל.
בהצלחה!
----
[א] ישנם מספר גופים שמגדירים הגדרות לגבי ארכיטקטורה והנדסת תוכנה בכלל. SEI (Software Engineering Institute) היא דוגמה לגוף שכזה. לגופים אלו לרוב יש השפעה רבה על ארגוני-ענק ועל האקדמיה, אך נראה שהשפעתם על כלל התעשייה - מעטה.
[ב] סוג של פגיעות מערכת, בהיבט האבטחה.
לא הייתי מוכן, לא ציפיתי, ולאחר התרגשות קצרה הדבר הראשון שעשיתי הוא "לפנק" את עצמי ב 3 ספרים מאמזון על ארכיטקטורת תוכנה. כלומר - רציתי לדעת "מה עושים ארכיטקטים?".
הספרים היו בעלי שמות גדולים, ביקורות מצוינות באמזון, והייתי מוכן להישבע שראיתי אחד או שניים מהם במשרדים של כמה טכנולוגים חזקים בחברה. אבל אחרי שקצת קראתי בהם - רציתי לבכות!
"באמת ארכיטקטורה זה כ"כ משעמם?" - היה קול אחד שניקר בראשי.
אולי אני לא מבין שומדבר ("you know nothing Jon Snow") - היה קול ספקני שני.
ברטרוספקטיבה של כחמש שנים לאחור, ברור לי שהספרים הללו, המקובלים בג'אנר, תרמו לי מעט. גם כי תיארו תפקיד קצת שונה מזה שעשיתי, אבל בעיקר מכיוון שרוב הכלים שהם הציעו - היו תרגילים תאורטיים שלא סייעו לי לפתור בעיות בפועל - ורובם לא מסייעים לי גם כיום לאחר שעברתי כברת-דרך כארכיטקט.
בכל זאת, מתוך מגוון הכלים (קרי, תרגילי מחשבה חביבים) המקובלים בקרב פורומים של ארכיטקטורת תוכנה [א], מספר קטן של כלים היה שימושי והועיל לי בפועל ליצור תוכנה טובה יותר.
אחד הכלים הללו נקרא מאפייני איכות (Quality Attributes) - ועליו נדבר בפוסט זה.
הערה: יוצא לי בפוסט זה, ובפוסטים אחרים להתייחס ל"ארכיטקט" מול "לא-ארכיטקט". אנא סלחו לי. ההפרדה הזו היא מלאכותית ולא בעלת משמעות רבה. בפועל כולנו אנשי תוכנה, ו"עשיית ארכיטקטורה" איננה שמורה לבעל תפקיד (או תואר) כזה או אחר. תודה לישראל שהעלה את הנקודה.
מה מאפייני-איכות הם לא?
הנה screenshot ממצגת שראיתי, אשר ניסתה להסביר "מהם מאפייני איכות":
המטפורה הזו היא שטותית!
מצד אחד בניין חרב, ומצד שני מלון מפואר. האם ללא מאפייני איכות המוצר שלנו יהיה שבור ומקולקל? - ברור שלא!
האם בעזרת מאפייני איכות המוצר שלנו יהפוך למוצר יוקרה? אולי הוא מוצר יוקרה - אך אין קשר.
לא קיים מוצר ללא מאפייני איכות. לכל היותר קיים מוצר שמאפייני האיכות שלו נקבעו בצורה לא-מודעת.
אז מה הם מאפייני איכות?
מאפייני איכות הן סט התכונות של המוצר שמאפיינות את השימוש שלו. לעיתים קרובות עושים בספרות הבחנה בין Functional Requirements, שהם "פיצ'רים", לבין Non-Functional Requirements שבניהן גם מאפייני האיכות. "דרישות רוחביות". הבחנה זו שימושית במידת מה, אך איננה מדוייקת לגמרי.
אנסה להסביר מהם מאפייני איכות בעזרת דוגמה: חי-הסוללה של מחשב נייד (Laptop).
על מנת להגיע לחיי סוללה גבוהים של מחשב נייד מנהל המוצר יכול לדרוש "סוללה חזקה במיוחד" שזה סוג של "פ'יצר" - אך זה לא יספיק. על מנת שהמכשיר יחזיק זמן רב ללא טעינה יש להשתמש ברכיבים (מעבד, דיסק) שצורכים מעט חשמל ולעתים קרובות יש תוכנה תומכת (כגון כיבוי משדר ה wi-fi או אפילו מחברי ה USB לאחר זמן ללא שימוש).
חיי סוללה נמוכים לא מעידים על מוצר באיכות ירודה. ייתכן מחשב פרמיום שבו הסוללה מחזיקה פחות משעתיים ("מחשבי גיימינג") ומוצר זול (נטבוקים) שסוללתם מחזיקה 8 שעות ויותר.
חיי סוללה נמוכים הם גם לא משהו ש"אפשר" לפתוח באג עליו. כלומר - בוודאי שאפשר, אך על מנת "לפתור את הבאג" יהיה צריך לבצע תכנון מחדש של המוצר - זו לא תקלה נקודתית.
אנו רואים ש"חיי סוללה ארוכים", עבור מחשב נייד, זו איכות רוחבית של המוצר. "מאפיין איכות" (Quality Attribute), בשפה שלנו.
הנה דוגמה לבחירה בין מאפייני איכות שונים:
טויוטה לנד-קרוייזר ופולסוואגן פולו הם שני מוצרים מעולים. מהטובים בתחומם - הצלחה הנדסית אמיתית. שניהם "מסיעים אנשים ממקום למקום". שניהם "נוסעים על כביש". לשניהם "4 מושבים או יותר" ולשניהם יש "רדיו ומזגן". אם כך - מה ההבדל בניהם?
מכיוון שכולנו מבינים טוב יחסית ב Domain של המכוניות - התשובה נראית ברורה:
לנד-קרוייזר הוא רכב שטח בעל עבירות גבוהה ונוחות גבוהה גם בשטח קשה ("עושה לכם קרוז על הקרקע הקשה").
פולו הוא רכב קטן ומגניב שקל (יותר) למצוא איתו חניה בת"א, הוא מעוצב למדי וצורך מעט דלק.
ניתן לומר שבנוסף לצרכים בסיסיים מאוד של "הסעת נוסעים" - כל אחד מהרכבים מספק צרכים אחרים שמאופיינים באיכויות רוחביות של המוצר.
מאפייני איכות בעולם התוכנה
עד כאן הדוגמאות עסקו במוצרים שאנו כבר מכירים, והיטב, מחיי היום-יום.
נעבור למוצר פחות ברור: שירות שמאכסן קבצים עבור משתמשי המערכת שלכם. איש המוצר יכול להגדיר "כמשתמש, אני רוצה ללחוץ על כפתור כחול עגול ולטעון קבצים במערכת לנוחויותי".
כמה אכסון נדרש? איזו אמינות? זמינות? ביצועים? אבטחה?
ברוב המקרים, איש המוצר לא יתייחס בדרישותיו להיבטים אלו. "פשוט שיעבוד" יאמר סוג אחד של איש מוצר, "הכי טוב שקיים, כפול 10 (ליתר ביטחון)" - היא גישה נפוצה אחרת.
מצד שני יבואו המפתחים עם שאלות:
אתה רוצה להשקיע 5 ימי פיתוח בהגנה בפני Directory Traversal[ב]? זו כמובן שאלה לא הוגנת - שרוב אנשי המוצר פשוט לא מסוגלים לענות עליה.
"כמה יהיה 'ציון האבטחה' של המערכת שלנו עם ובלי Directory Traversal?" היא שאלת הנגד המעשית של איש המוצר - שהמפתחים מצידם לא יהיו מסוגלים לספק לה תשובה.
לבחירת מאפייני האיכות במוצר שלנו יש השפעה רבה על עלות פיתוח המוצר, אך חשוב מכך - על שביעות הרצון וההתאמה ללקוח.
כדאי מאוד שמישהו ייקח באופן מודע את ההחלטה לגבי מאפייני האיכות, מישהו:
- בעל ידע טכני עמוק
- בעל הבנה טובה של המוצר, הלקוחות והדרישות
- מספיק בכיר ועצמאי בארגון בכדי לקחת החלטה, או לפחות להביא אותה למי שיכול לקחת.
נקרא לאדם זה "ארכיטקט". בארגונים קטנים אלו לרוב מנהלי הפיתוח (שאת ההשקעה בידע מקצועי עשו לפני-כן), בארגונים גדולים אלו יהיו פעמים רבות אנשים המוגדרים כ"ארכיטקטים".
האם זה בסדר שארכיטקט יקבל החלטה על השקעה במאפיין איכות? השקעה שמשפיעה על המוצר ועל כמות העבודה המושקעת? הרי מי ש"מחליט מה נכנס למוצר" הוא רק מנהל המוצר (לפחות בהגדרה).
בהנחה שהחלטתם לבחור בגישה המעשית, קרוב לוודאי שכדאי שמי שייקח את ההחלטה הוא מי שיכול לקחת אותה בצורה הטובה ביותר - אפילו אם הוא איננו מנהל המוצר.האם זה בסדר שארכיטקט יקבל החלטה על השקעה במאפיין איכות? השקעה שמשפיעה על המוצר ועל כמות העבודה המושקעת? הרי מי ש"מחליט מה נכנס למוצר" הוא רק מנהל המוצר (לפחות בהגדרה).
חשוב להבין: תרכובת הידע הנדרשת לקבלת החלטה טובה היא לא טריוויאלית, ועל מנת לייצר אותה ארגונים נדרשים להשקיע לא מעט באותם האנשים: לחשוף אותם ללקוחות וקבלת ההחלטות, לספק להם דיי זמן כדי להתעמק מקצועית, לסייע להם לבנות את הביטחון על מנת שיוכלו לעמוד מאחורי ההחלטה.
הדרך בה אני נתקלתי בעבודה עם מאפייני איכות, בהגדרת מוצר חדש, היא כזו:
- הארכיטקט לומד כמה שאפשר על דרישות המוצר ממנהל המוצר - מצד אחד, ומתעמק באתגרים הטכנולוגיים - מצד שני.
- הארכיטקט מגדיר בעצמו את מאפייני האיכות (פרטים בפוסט ההמשך) ומציג את תובנותיו למנהל המוצר / הנהלה.
על ההגדרה להיות בהירה ולאפשר דיון אמיתי עם מנהל המוצר.
כאשר יש ספקות - ניתן וכדאי להציג כמה אלטרנטיבות ("האם נכון שהדגש שלנו הוא על רכב מהיר, גם במחיר צריכת דלק גבוהה - או שאנו רוצים לאזן בין שניהם?"). - לאחר דיון, ניתן לבצע שינויים ותיקונים - אך המחוייבות על ההחלטה היא משותפת לארכיטקט ולאיש המוצר. עליה לנבוע מהבנה הדדית.
חילקתי פוסט זה (שהתארך) ל-2 חלקים.
בחלק השני נעסוק בדרך השימוש של מאפייני האיכות בפועל.
בהצלחה!
----
[א] ישנם מספר גופים שמגדירים הגדרות לגבי ארכיטקטורה והנדסת תוכנה בכלל. SEI (Software Engineering Institute) היא דוגמה לגוף שכזה. לגופים אלו לרוב יש השפעה רבה על ארגוני-ענק ועל האקדמיה, אך נראה שהשפעתם על כלל התעשייה - מעטה.
[ב] סוג של פגיעות מערכת, בהיבט האבטחה.
אולי חסר לי מעט נסיון מסויים שגורם לי לחשוב כך, אך אני רואה את ה"ארכיטקט תוכנה" כמתכנת שנבחר להחליט על ארכיטקטורת התוכנה המפותחת.
השבמחקבמילים אחרות: לא מדובר בידע שונה מהמתכנתים האחרים, לא מדובר בידע בטכנולוגיה מסויימת שהיא זאת שעושה אותו "ארכיטקט", אלא בכך שבחרו בו לשאת את התפקיד, בדרך כלל כיון שיש לו יותר נסיון והידע שלו רב ומקיף יותר (וזאת כן נדרש על מנת להיות מתכנת. לדוגמה, כדי להחליט באיזו שפה התוכנה תפותח, כיצד היא תותאם למערכות שונות, שימוש במטמון הוא וויתור עליו לטובת צורך אחר, מבנה והפרדת חלקי התוכנה, קשרים בין חלקי התוכנה, מסד הנתונים ועוד).
תיקונים בתגובתי לעיל:
השבמחקוזאת כן נדרש על מנת להיות מתכנת -> להיות ארכיטקט
שימוש במטמון הוא וויתור -> או וויתור
היי ישראל,
השבמחקאני מסכים איתך שתחומי הידע של הארכיטקט לא שונים מהותית מזה של המתכנת. ההבדל בין התפקידים הוא לא ברור או חד משמעי, והוא בעיקר משהו ש"ארכיטקטים" מנסים להגדיר בכדי לבדל את עצמם. ככה נדמה לי.
לא צריך תואר "ארכיטקט" כדי לעשות ארכיטקטורה.
הזדמן לי לקרוא מספר רב ספרים על תוכנה, הנדסת-תוכנה וכו' - אך מעולם לא נתקלתי בהם בנושא של "חשיבה ב Quality Attributes". מצד שני יצא לי להתקל בנושא בכמה ספרים והכשרות של "ארכיטקטים". באזור זה הטכניקה היא יחסית מוכרת.
מכיוון שמצאתי טכניקה / סוג חשיבה זו באמת מועילה, ולא סתם גימיק - אני מנסה לשתף אותה בשאיפה שהיא תשרת כמה שיותר אנשים.
בראיה פילוסופית, ניתן לומר שטכניקה זו (ועוד כמה שמיוחסות לעיתים ל"ארכיטקטים") הן טכניקות פחות "לוגיות" ויותר של "חשיבה מערכתית" - חשיבה שעוזרת להתמודד עם שאלות של המערכת - היכן שאין יכולת להתמצא בכל הפרטים.
בפועל, אפשר לשים את הפילוסופיה בצד. ככל שיותר אנשים יוכלו להשתמש בטכניקה זו (או אחרת) בצורה שסייע להם - כך ייטב.
אני מקווה שהגבתי לעצם העניין,
ליאור
החכמת אותי תודה רבה
השבמחקקונג'אק