מעלה-מטה ומטה-מעלה הן אסטרטגיות לפיתוח תוכנה, המופיעות גם בהקשר של תורות המערכות ההומניות והמדעיות.
במודל מעלה-מטה מנוסחת תחילה סקירת מערכת בקווים כלליים בלי להיכנס לפרטים של שום חלק ממנה. לאחר מכן מנוסח כל חלק של המערכת לפרטיו, ואז כל פרט חדש עשוי להיות מנוסח שוב תוך שמגדירים אותו לפרטים נוספים עד שכל המפרט מפורט דיו כדי לתקף את המודל. מודל מעלה-מטה מעוצב לעיתים קרובות תוך הסתייעות ב"קופסאות שחורות" שמקלות את מימוש סקירת המערכת, אך באופן שאין בו די להבנת המנגנון שביסוד המערכת.
בניגוד לזאת, במודל מטה-מעלה מוגדרים תחילה החלקים הפרטיים של המערכת לפרטיהם, ואז מצורפים החלקים יחדיו לרכיבים גדולים יותר, שבתורם מצורפים גם הם עד להשגתה של המערכת השלמה. אסטרטגיות שמבוססות על זרימת מידע מטה-מעלה עשויות להראות כחיוניות ומספקות עקב היותן מבוססות על ידיעת כל הגורמים שעשויים להשפיע על חלקיה היסודיים של המערכת.
מדעי המחשב
רקע היסטורי
בתהליך פיתוח תוכנה הגישות מעלה-מטה ומטה-מעלה משחקות תפקיד מרכזי.
עיצוב מעלה-מטה הוא המקור העיקרי של שפות תכנותפרוצדורליות מסורתיות. עיצוב זה קודם בשנות השבעים של המאה ה-20 על ידי הרלן מילס וניקלאוס וירת. מילס פיתח תפישות של תכנות מובנה לשימוש מעשי, שאותן הוא בחן בפרויקט מיכון אינדקס הארכיון של הניו יורק טיימס בשנת 1969. הצלחתו ההנדסית והניהולית של הפרויקט הובילה לתפוצת גישת מעלה-מטה דרך IBM ושאר תעשיית המחשבים. ניקלאוס וירת, שפיתוח שפת התכנותפסקל הוא אחד מהישגיו, כתב את המאמר המשפיע "Program Development by Stepwise Refinement".
שיטת מעלה-מטה הועדפה בהנדסת תוכנה עד לעלייתה של פרדיגמת תכנות מונחה עצמים בשנות השמונים המאוחרות של המאה העשרים. בשפות מונחות עצמים כדוגמת C++ או Java הועדפה שיטת תכנות מטה-מעלה.
גישות מודרניות לעיצוב תוכנה משלבות בדרך כלל את הגישות מעלה-מטה ומטה-מעלה. מחד, הבנה של המערכת בכללותה נחשבת לרוב כחיונית לעיצוב טוב, מה שאופייני לגישת מעלה-מטה. ומאידך, ברוב הפרויקטים לפיתוח תוכנה מנסים להשתמש בקוד קיים להשגת כמה יתרונות, והאפשרות לשימוש חוזר בקוד אופיינית לגישת מטה-מעלה.
תכנות
עיצובו של תכנות מעלה-מטה מתחיל בהגדרת מכלול של חלקים ואז פיצולם לחתיכות קטנות בזה אחר זה. עד שלבסוף, כשהרכיבים מפורטים דיים כך שניתן יהיה לקודד אותם, נכתבת התוכנה.
הטכניקה לכתיבת תוכנה בגישת מעלה-מטה היא לכתוב פונקציה ראשית שנותנת שמות לכל הפונקציות העיקריות שידרשו לה. בהמשך, צוות התכנות בוחן את המפרט הדרישות של כל אחת הפונקציות הללו והתהליך חוזר על עצמו. לבסוף פונקציות מפוצלות אלו יבצעו פעולות בסיסיות, שהקוד שלהן יכול להיכתב בתמציתיות. כאשר כל אותן פונקציות מגוונות כבר נכתבו, התוכנה מוכנה.
שיטת מעלה-מטה מדגישה תכנון והבנה מלאים של המערכת. משמעות הדבר היא, שכתיבת הקוד אינה מתחילה עד שהושגה רמה מספקת של פרטים בעיצובם של לפחות כמה מחלקיה של המערכת. דבר זה מעכב בדיקה של יחידות פונקציונליות בסיסיות של המערכת עד להשלמתו של חלק משמעותי מהעיצוב.
לעומת זאת, שיטת מטה-מעלה מדגישה כתיבת קוד ובדיקות מוקדמות, שעשויות להתחיל מיד משהוגדר המודול הראשון. גישה זו טומנת בחובה סיכון שבקידוד מודולים בלא שיהיה ברור כיצד הם אמורים להיות מקושרים לחלקיה האחרים של המערכת, וקישור כזה עלול להיות קשה מכפי שזה נראה במחשבה ראשונה.
הטכניקה לכתיבת תוכנה בגישת מטה-מעלה היא לעצב ולקודד באופן מלא מערכת בעלת פונקציונליות חלקית, ואז להרחיב את המערכת עד למימוש כל דרישות הפרויקט.
יתרונות וחסרונות
שיטת מעלה-מטה
יתרונות:
צוות התכנות נותר ממוקד במטרה
בשעה שהתכנות מתחיל אין יותר שאלות
הקוד קל למעקב, כיוון שהוא נכתב בשיטתיות ועם מטרה
חסרונות:
תכנות מעלה-מטה עלול להכביד על הבדיקות, כיוון ששום תוכנה שניתנת לביצוע אינה קיימת עד סמוך לגמר ביצוע הפרויקט
שיטת מטה-מעלה
יתרונות:
אפשרות לשימוש חוזר בקוד
ניתן לבצע בדיקות סמוך לתחילת הפרויקט
חסרונות:
קושי בשילוב מודולים של מערכת, כיוון ששילוב זה לא תוכנן מראש.
במושגים אלה נעשה שימוש גם במדעי המוח ובפסיכולוגיה. דוגמה ניתן לראות במחקר על תשומת לב ויזואלית. אם תשומת לבו של אדם נמשכת לפרח בשדה, ייתכן שזאת משום שהפרח בולט יותר באופן ויזואלי מאשר השדה שבו הוא מוקף. המידע שגרם לאדם לשים לב לפרח הגיע אליו בסגנון של מטה-מעלה - תשומת לבו לא הייתה תלויה במודעותו לפרח, די היה בגירוי החיצוני. הדבר שונה ממצב בו האדם מחפש בעצמו פרח - יש לו ייצוג של מה שהוא מחפש, וכשהוא רואה את האובייקט שחיפש, זה בולט. זו דוגמה לשימוש של מידע מעלה-מטה.
בניהול ידע
הצלחה של פרויקט בתחום ניהול ידע קשורה במידה רבה בעבודה שהיא גם מלמעלה-למטה וגם מלמטה-למעלה. חשוב מאוד לעשות עבודה עם המנהלים בארגון אשר יסייעו יתנו גיבוי, משאבים וזמן להשקיע בתהליכי ניהול ידע. הנהלה צריכה להיות מגויסת לתהליך, ותומכת בו לכל אורך הדרך. עם זאת, בתחום ניהול ידע, החלטת הנהלה (ותמיכה מלמעלה-למטה בלבד) אינה מספיקה. מערכות לניהול ידע הן מערכות אשר אין בהן חובת השתתפות, ולכן רתימת "עד אחרון העובדים" היא קריטית להצלחה.
עבודה מלמטה-למעלה מתחילה משלב הבנת הצרכים של העובדים בשטח - מהם צורכי הידע, איזה ידע חסר להם, איזה ידע היו רוצים לתרום ולקבל. בהקשר ניתן להיעזר במבחן אמילי ולהבין את הערך עד אחרון העובדים.
עבודה מלמטה-למעלה ממשיכה בשיתוף של העובדים בגיבוש הפתרון שנבנה, רתימה של העובדים ליצירת תוכן משמעותי, ועבודה ביחד עם העובדים כדי למנף את הידע והיכולות שלהם.
עבודה מלמטה-למעלה מאפיינת מאוד את גישות web 2.0 וגישות נוספות של חכמת ההמונים ורשתות חברתיות.
במהלך תהליך ניהול ידע יש לחזור להנהלה, להציג ממצאים, להציג מגמות ולדון במשמעות של השינוי התרבותי שנוצר בארגון.
שילוב של עבודה מלמעלה-למטה ועבודה מלמטה-למעלה היא קריטית בהצלחה של תהליך ניהול ידע ארגוני כמו גם בהצלחה של פיתוח תוכנה.
