מושגים בסיסיים

Agile

זמיש (זריז וגמיש)

קבוצה של מתודולוגיות לפיתוח מוצרי תוכנה, המבוססת על פיתוח

איטרטיבי בשלבים קטנים, תוך שילוב צוותים של מפתחים, בודקים,

משתמשים מומחי יישום ועוד.

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

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

ALM

Application Life Cycle Management

ניהול מחזור חיי פיתוח מערכת. תפיסה של ניהול כולל ומרכזי של

מחזור חיי התוכנה, החל מניהול הדרישות, דרך הארכיטקטורה,

הפיתוח, הבדיקות והיישום, וכלה בעדכון ובשחרור מהדורות.

מרבית ספקי הכלים הגדולים עברו בשנים האחרונות תהליכי קונסולידציה של מוצרים בכדי לפתח יכולות ALM אמיתיות (HP, IBM, Microsoft) ולתמוך בכל שלבי החיים של הפיתוח באופן עקיב ורציף.

CM - Configuration Management

ניהול תצורה

תחום בתורת הניהול, העוסק בניהול ובקרת השינויים של מערכות,

ניהול ומעקב אחר גרסאות תוכנה ורכיבים פיזיים.

היישום נעשה הן במסגרת הפיתוח והן בשלב התחזוקה.

ניהול תצורה כושל עלול להיות מקור לתקלות וכשלים, בגלל, גורמים שונים וביניהם למשל:

• קושי בזיהוי השינויים בקוד

• בניית גרסאות חלקיות

תיקוני תקלות חסרים או פונקציונאליות חסרה Code Overwriting

Debugging

ניפוי כשלים

פעילות של איתור, ניתוח וניפוי כשלים בתוכנה. באחריות המפתחים.

כלי Debugging יכולים לשמש גם ככלי Code Analysis בסיסיים.

Debugging אינה פעילות בדיקות בהגדרתה אלא פעילות של צוות הפיתוח ובאחריותו (לעיתים בעקבות תקלות או בעיות המתועדות ע"י צוות הבדיקות)

Environments

סביבות עבודה

סביבות מחשוב עצמאיות ומופרדות המשמשות את הפיתוח, הבדיקות והייצור. מקובל לנהל לפחות 3 סביבות: פיתוח, אינטגרציה, בדיקות וייצור. לעתים בונים סביבה ייחודית לבדיקות בלבד או סביבות לבדיקות עומסים וסביבות לבדיקות הסבה. ככל שהסביבה קרובה יותר לייצור ( לדוגמא סביבת בדיקות המערכת ) היא נדרשת להיות דומה יותר לסביבה האמיתית.

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

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

Insourcing

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

לעיתים פעילות של Insourcing מתוגברת ע"י צוותי Offshore או Nearshore , המשולבים בפעילות המנוהלת באחריות הארגון.

Offshore & Nearshore

מודל Sourcing המתייחס להעברת פעילות או נתח מוגדר מפעילות לאתר חיצוני לארגון המתאפיין בעלויות זולות יותר מבחינת תפעול וכוח אדם. OffShoring מתייחס למצב שבו האתר החיצוני נמצא בארץ אחרת ואולי אף באזור אחר של העולם (לדוגמא: הודו, סין, מזרח אירופה). NearShoring מתייחס למצב שבו האתר החיצוני הוא באותה מדינה או בסמוך אליה (באותו איזור זמן ובמרחק נסיעה קצר).

תופעה חדשה יחסית בתחום נקראת - Home Shoring עבודה מהבית.

כיום, ארגונים היוצאים ל- OffShoring או ל- NearShoring שואלים לא רק "כמה זה עולה ?" אלא גם "כמה זה איכותי ?" , "כמה זה מהיר ?" וגם "כמה זה סקלבילי (כמה זה יכול לגדול)?" אחד התחומים המתפתחים בצורה המשמעותית ביותר ב- Offshore ו- Nearshore הוא תחום הבדיקות. בתחום זה, הגמישות והסקלביליות הנדרשת הן קריטיות במיוחד.

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

Outsourcing

מיקור חוץ

מודל Sourcing המתייחס להעברת פעילות לספק חיצוני שמקבל אחריות כוללת על מימוש הפעילות.

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

יש בלבול לעיתים בין Outsourcing ל- Offshore או .Nearshore בעוד חלק מפעילויות ה- Offshore הן מקרה פרטי של Outsourcing (הארגון מוציא פעילות החוצה, במקרה לאתר אחר) קימות גם פעילויות Offshore או Nearshore הנעשות ללא הוצאת הניהול והאחריות על הפעילות החוצה. למשל: הרחבת צוות הבדיקות של הארגון באמצעות בודקים הפועלים ב- Offshore או Nearshore , אבל עדיין הניהול והאחריות הם של הארגון.

Requirements Management

ניהול דרישות

דרישה היא יכולת שפרויקט (מוצר, שירות או מערכת) צריכים לספק.

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

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

ניהול דרישות הוא חלק קריטי ממחזור החיים של הפיתוח ) ALM , ע"ע(. תפקידו להעביר את שלב הדרישות, מ"פרוזה" ל"הנדסה". ניהול דרישות באמצעות כלים לניהול דרישות מאפשרים לעבור מ- Paper-In Paper-Out כשיטת עבודה לניהול ממוחשב תוך עקיבות לשלבי הפיתוח (מה לפתח?) ושלבי הבדיקות (מה המשתמש מצפה לקבל?)

Risk Analysis

ניתוח סיכונים

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

רמת הסיכון נקבעת על בסיס המכפלה של "הסיכוי לתקלה" ו"עוצמת התקלה":

Risk Level = Probability*Impact

שלב הבדיקות הינו אחד הכלים החשובים ביותר בכל הכרוך בגידור סיכונים.

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

Sourcing

אסטרטגיה המטפלת בדרך שבה החברה מממשת פעילות עסקיתאו פעילות .IT פעילות של ארגונים כיום היא פעילות מורכבת המתייחסת להיבטים רבים ודורשת מרחב שלם של מיומנויות. יותר ויותרארגונים שואפים להתמקד בנושאי הליבה ולקבל שירות (זמין,איכות, סקלבילי, מהיר...) בתחומים המשלימים.בין אסטרטגיות ה- Sourcing השונות ניתן למצוא Insourcing, OutSourcing , Offshoring ו- NearShoring .

RightSourcing מציע בחירה היברידית (מעורבת) של שיטות Sourcing שונות בהתאם לאופי הפעילות וקרבתה לתחומי הליבה של הארגון.

TDD - Test Driven Development

פיתוח מונחה בדיקות

שיטת פיתוח תוכנה שבה נכתבת בדיקת יחידה בטרם נכתב הקודאותו היא בודקת. בפיתוח בשיטה זו, בדיקת היחידה נכתבת תמידבאמצעות חבילת תוכנה המיועדת להרצה אוטומטית של בדיקותהיחידה ) Unit Testing ע"ע(.פיתוח מונחה בדיקות הוא למעשה שיטת עיצוב תוכנה, המבטיחה שמאמצי העיצוב והפיתוח, מוכוונים לדרישות המערכת .

TDD התפתח במיוחד במסגרת מתודולוגית Agile .

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

Please reload