Unified Process

מתוך ויקיפדיה, האנציקלופדיה החופשית
קפיצה אל: ניווט, חיפוש

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.