Unified Process או Unified Software Process הוא מסגרת לתהליך פיתוח תוכנה איטרטיבי. ה-Unified Process המוכר והמתועד ביותר הוא Rational Unified Process - RUP

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 דורש מצוות הפרויקט לשים לב לסיכונים קריטיים כמה שיותר מוקדם במחזור החיים של הפרויקט. התוצרים של כל איטרציה במיוחד של שלב ה"שכלול" חייבים להיבחר בסדר כזה שמבטיח שהתוצרים בעלי הסיכון הגבוה היותר יהיו ראשונים.

Unified Process מחלק את הפרויקט ל 4 חלקים:

• התחלה
• שכלול
• בנייה
• מעבר

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

• ביסוס או הצדקת המודל העסקי של הפרויקט
• ביסוס היקף הפרויקט
• התוויית תרחישי השימוש ודרישות מפתח
• התוויית ארכיטקטורה או כמה ארכיטקטורות שישמשו בפרויקט
• זיהוי סיכונים
• הכנת הקדמה ללוח הזמנים והערכת עלויות

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

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

וידוא הארכיטקטורה נעשה בעיקר דרך מימוש קווי המתאר של Executable Architecture, זהו מימוש חלקי של המערכת שמכיל מרכיבי הליבה (בעיקר מרכיבים תשתיתיים).

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

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

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

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

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

Enterprise Unified Process מרחיב את RUP על ידי הוספה של שמונה תחומי "Enterprise".

Agile משכללים את Unified Process כמו OpenUP/Basic ו Agile .Unified Process מפשטת את RUP על ידי הורדת מספר התחומים.

שכלולים של Unified Process משתנים במה קורה אחרי שלב המעבר. ב-Rational Unified Process בדרך כלל אחרי שלב המעבר מגיע שלב התחלה חדש.

ב-Enterprise Unified Process אחרי שלב המעבר מגיע שלב ייצור.

מספר השכלולים והווריאציות של Unified Process הוא רב, ארגונים משתמשים ב-Unified Process באופן שונה ומכניסים בו שינויים והרחבות משלהם.

רשימה של שכלולים ושינויים ידועים של Unified Process:

• Agile Unified Process (AUP), a lightweight variation developed by Scott W. Ambler
• Basic Unified Process (BUP), a lightweight variation developed by IBM and a precursor to OpenUP
• Enterprise Unified Process (EUP), an extension of the Rational Unified Process
• Essential Unified Process (EssUP), a lightweight variation developed by Ivar Jacobson
• Open Unified Process (OpenUP), the Eclipse Process Framework software development process
• Rational Unified Process (RUP), the IBM / Rational Software development process
• Oracle Unified Method (OUM), the Oracle development and implementation process
• Rational Unified Process-System Engineering (RUP-SE), a version of RUP tailored by Rational Software for System Engineering

• Kroll, Per; Kruchten, Philippe (2003). The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP. ISBN 0-321-16609-4.
• Kruchten, Philippe (2004). The Rational Unified Process: An Introduction (3rd Ed.). ISBN 0-321-19770-4.
• Larman, Craig (2004). Agile and Iterative Development: A Manager's Guide. ISBN 0-13-111155-8.
• Scott, Kendall (2002). The Unified Process Explained. ISBN 0-201-74204-7.
• Bergstrom, Stefan; Raberg, Lotta (2004). Adopting the Rational Unified Process: Success with the RUP. ISBN 0-321-20294-5.