Unified Process

סקירה

Unified Process הוא לא סתם תהליך אלא מסגרת עבודה נרחבת שנועדה להיות מותאמת לארגונים או פרויקטים מסוימים.
השם Unified Process בניגוד ל-RUP מתאר את התהליך בכלליות וגם נקרא כך בשביל להימנע מסימני מסחר מכיוון ש-RUP למשל הוא סימן מסחר של IBM.
הספר הראשון שמתאר תהליך זה נקרא:  (The Unified Software Development Process (ISBN 0-201-57169-2 והוצא לאור בשנת 1999 על ידי Ivar Jacobson, Grady Booch, James Rumbaugh.
מאז מחברים שונים שלא מזוהים עם Rational Software הוציאו לאור ספרים שמשתמשים בשם Unified Process. לעומת סופרים אחרים שמזוהים עם Rational Software שהעדיפו להשתמש בשם  Rational Unified Process.

איטרטיבי ומצטבר

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

מונע תרחישי שימוש

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

ארכיטקטורה מרכזית

ב-Unified Process לב המאמץ של משתתפי הפרויקט הוא בניית  הארכיטקטורה לעיצוב המערכת. מכיוון שאין מודל אחד שמכסה את כל היבטי המערכת Unified Process תומך במודלים אַרְכִיטֶקְטוֹנִים מרובים.
אחד מהתוצרים החשובים של התהליך זה  Executable Architecture שנוצר במהלך שלב השכלול. המימוש החלקי הזה של המערכת משמש לוודא את טיב הארכיטקטורה ולהיות התשתית של שאר הפיתוח.

ממוקד סיכונים

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

שלב השכלול

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

שלב הבניה

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

שלב המעבר

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