-לקחת בעירבון מוגבל-

idoelad@gmail.com –ונים משמעותיים תיקל

oftware Development ProcessesS

ifecycle ModelsL

:לא איטרטיביים תהליכי פיתוח תוכנה

Waterfall )רויס(

o לוגי, כל שלב מוגדר היטב ובכל שלב יש מיקוד במשימה אחת -תהליך שיטתי

.עיקרית

o .כל הדרישות מוחלטות לפני הפיתוח, העיצוב נעשה במלואו לפני הפיתוח

o שלביםהשאיפה היא לא לחזור אחורה ב

o דרישות < עיצוב תוכנה < תכנות < בדיקות < אינטגרציה < התקנה < תחזוקה

o :שלבים נוספים שרויס מציע להוסיף ע"מ להפוך את התהליך לריאלי יותר

Prototype – מעבר על כל השלבים )מעיצוב –לאחר קבלת כל הדרישות

בים ועד שימוש ממש( עבור מוצר פשוט יותר כדי כן לקבל פידבק מהשל

השונים )תקלות גדולות, דרישות לקוח לא שלמות וכ'ו(.

כמעט בכל שלב יש קשר עם הלקוח לפני המעבר לשלב – קשר עם הלקוח

הבא.

כל שלב צריך להיות מתועד במסמך, כל אחד צריך להכיר – דוקומנטציה

את כל התוכנה ברמת הדוקומנטציה.

o טענות שלBrooks נגד מודל ה-aterfallW

ת לא יודעים מה הם רוציםלקוחו

אפשר למפות את כל האלטרנטיבות מראש-אי

חייבים להיות מעגלים

דרישות, אילוצים, סביבה וכ'ו(. דברים כל הזמן משתנים(

אף אחד לא באמת עובד ככה

o שורשי הבעיה עפ"יBrooks

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

o האלטרנטיבה שמציעrooksB

הגשת הדרישות ע"י הלקוח עצמו :חוזה ראשון עם ארכיטקט

הבנת הדרישות

תכנון קונספטואלי

תכנון בפועל

תשלום לארכיטקט עפ"י שעות עבודה

)חוזה עם ה"קבלן" עצמו )המוציא לפועל

שימוש במסמך שכתב הארכיטקט

מחיר קבוע מראש לשלב זה

Model-V

o כל שלב בפיתוח נמצא מול הבדיקות המקבילות אליו

o ה-Flow של הפיתוח הוא משמאל לימין

תהליכי פיתוח תוכנה איטרטיביים:

בוהם( מודל הספירלה(

o ונים ע"י כלים ש הסיכון הגדול ביותרבכל שלב בפיתוח התוכנה מזהים את

(Prototype)ופועלים כדי לצמצם אותו. , אנליזה

o :בכל סיבוב "נפח" הפרוייקט עולה

פיתוח הקונספט הכללי – 1סיבוב

2סיבוב – Top Level requirements

...

o אם בסיבוב כלשהו אין דרך לפתור סיכון ניתן להפסיק את הפרוייקט

o ן ונראה ישיםהאם הפרוייקט במסלול הנכו –בכל סיבוב נעשית הערכה

o לא חייב להיות מסמכים רשמיים( שלושה אבני דרך עיקריות בתהליך הפיתוח(:

הבנת הפרוייקט והחלטה שהוא ישים

שלב התכנון הבסיסי והארכיטקטורה

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

EVO (Gilb)

o פיתוח המערכת בחלקים קטנים בצורה איטרטיבית ואינקרמנטלית

o נותנים –לב בפיתוח, ברגע שיש משהו פונקציונלי שיכול לעזור ללקוח בכל ש

.אותו ללקוח

o כל איטרציה היא "מיניWaterfall עם "Scope אין צורך בתכנון יתר.קטן .

o ערך ללקוח ההחלטה מה מפתחים נעשית לפיבכל איטרציה:

"פונקציה "בטוחה

הכי קלה למימוש

עלות נמוכה

ערך פוליטי גבוה

o ם לפי תשלומיDeliveries – נותן תמריצים לשני הצדדים

o "הכל צריך ואפשר –צריך להימנע ממצבים שבהם דרישות מנוסחות ב"נפנופי ידיים

לכמת.

The unified Software Development Process )ג'ייקובסון,בוש,רומבה(

o תהליך איטרטיבי ואינקרמנטלי

o נעשה שימוש גדול ב-Use Case – הרבה אינטרקציה עם הלקוח

o חלה חלק גדול מהפיתוח עוסק בהקטנת סיכוניםבעיקר בהת

o פאזות 4-ל כל איטרציה מחולקת -מימד הזמן:

(WHAT?) Inception Phase

הגדרת ה-Scope בעיקר בעזרת(Use Case)

ארכיטקטורה ראשונית

חוזה ראשוני או הפסקת הפרוייקט

(HOW?) Elaboration Phase

equiermentsR מפורטים

זרת בע –זיהוי סיכוניםUse Case ,Prototype

)החלטה על קו הארכיטקטורה הכללי )יכול להשתנות

חוזה עבור המערכת כולה

(DO IT) Construction Phase

יצירתWorkplan

בזמן עבודה מוגדרביצוע האיטרציות

טסטים, אינטגרציה וכ'ו

ransition PhaseT

הרצת המערכת אצל הלקוח

תיקון באגים

אופטימיזציה

תהכשרו

o 5 -)לאורך כל הפרוייקט( מימד העבודה Workflows:

Requirements workflow

בשפת הלקוח, לא רשמי

הגדרת שני סוגיeq'sR :

o Functional

o functional-Non

תחזוקה של רשימת רעיונות תוך כדי הפיתוח

אפשרות לשינוי ע"י גורם חיצוני

Analysis Workflow

תרגום הדרישות ל-design שפה "רשמית" יותרכללי ,

בניית ארכיטקטורה בסיסית

Design Workflow

עיצוב המערכת בצורה מפורטת

Implementation Workflow

מימוש

אינטגרציה

WorkflowTest

בדיקות

gileA

o ההפך ממודל ה –הרוח הכללית-aterfallW

o 4 עקרונות עיקריים

ם ותהליכיםאינטרקציה בין אנשים ויחסי גומלים במקום מסמכי

תוכנה עובדת במקום עודף דוקומנטציה

שיתוף הלקוח במקום חתימה על חוזים

תגובה לשינויים במקום הקפדה על התוכנית שתוכננה מראש

o הימנעות מגישת"Freeze the world".

o ולא עלות והיקף( זמן ואיכות –שני פרמטרים עיקריים כמדד(

o .ההיקף לטווח הארוך נקבע בקווים כלליים

o בסוף כל חודש מספקים ללקוח משהו שעובד. –דוגמא אפשרית

o XP (Extreme Programing) – אחת הדרכים למימושgileA

הבנה מה התהליך שמשתמש עובר בריצת המערכת

בניית צורה כללית ולא מפורטת של הרעיון שמאחורי המערכת

עיצוב כללי של המערכת והזמן בטווח הרחוק

בנייתPrototype

טרציות )מימוש(אי

דברים שמתוכננים לאיטרציה הזו

דברים שלא טופלו באיטרציה הקודמת

דברים חדשים

לא צוברים חובות, עושים מה שאפשר ומה שלא – הרעיון העיקרי

עשינו חוזר לתכנון כדי להחליט מתי יעשה

פגישת סטטוס יומיות

"עבודה בזוגות ו"ריפקטור ללא רחמים

חוזר לאיטרציה הבאה, מה שכן עובר ללקוחמה שלא עובר –בדיקות

o SCRUM השיטה הכי נפוצה למימוש(gileA)

איטרטיבי ואינקרימנטלי

פשרה ביןAgile "מקפיאים" את הכל בכל ספרינט. –לגמרי ל"הקפאה"

יכול להיות כלל תהליך הפיתוח או רק חלק ממנו

עצמו, תכנון, הספרינט :שלבים 4איטרציות / "ספרינטים", בכל אחת

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

להמשך.

:משתתפים

Product Owner – לקוח, לא מתכנת, אחראי על ה-backlog

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

Scrum Master – "מנהל טכני, אחראי לתת שקט "ניהולי

למתכנתים

Team member – חר על מה לעבודמתכנת, בו

Spring Backlog – התוכנית לספרינט הספציפי, חלק מה-Product

backlog.

מנגנונים לבדיקת הסטאטוס של הספרינט ושל כל הפרוייקט

:פגישות יומיות בזמן הספרינט

העברת משימות מה-backlog ל- sprintlog

החלטות פרטניות וטכניות לספרינט הנוכחי

רינט ומשוב ממנוהצגה ללקוח בסוף כל ספ

מדידת התהליך עצמו של ה-Scrum

לגישה המסורתית gileAהשוואה בין

איטרציות חסומות בזמן )הקרבה של דרישות לטובת עמידה בזמנים( לעומת עמידה על כלל

הדרישות

)תהליך לא פורמלי לעומת תהליך פורמלי מאוד )חוזים, מסמכים וכ'ו

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

תועלת ללקוח בכל איטרציה לעומת מזעור סיכונים

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

קשר צמוד עם הלקוח לעומת פגישות לעיתים רחוקות

כתיבת הטסטים לפני הפיתוח לעומת כתיבת הטסטים בסוף

ידה נפרדת לעומת טסטים עבור הכל ביחדטסטים עבור כל יח

השוואה בין המודלים העיקריים

Driven Formal? Prototype? Delivery ev.D Model

Reqs. Plan Reqs. Doc.

Design Doc. Yes Bang Linear Waterfall

Risks ? Yes Bang iterative Spiral

Value No No Incremental iterative EVO

Risks UML Yes Bang iterative Unified Process

Value No! No Incremental iterative Agile

UML

.Object Orientedדיאגרמות שונות לתיאור 14

Use Case Diagram

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

o :בדר"כ קיים גם תיאור מילולי בצורת טבלאות

UC Name

Goal in context

Scope & Level

Precondition )תנאי התחלה(

Success end condition)תנאי להצלחה(

Trigger )מתי יופעל(

Action Step

Normal

)מה קורה כשהכל בסדר(

Variations

Failures

)מה קורה כשנכשל(

Class Diagram

o יהן מחלקות והיחס בינ

o מאפיינים של כלClass:

+ (public) ,- (Private) ,# (Protected)

משתנים, ריבוע אמצעי

Name : type

"/" לפני שם המשתנה= Derived

משתנה של המחלקה ולא של האובייקט –קו תחתון

פונקציות, ריבוע התחתון

מלבן עם שני חלקים במקום שלושה- Interface

o לקות:חיבורים בין מח

קו רגיל– Association – שתי המחלקות מכירות אחת השניה ויכולות

לקרוא לפונקציות אחת של השניה

מעויין ריק– Aggrigation – אותוClass יכול להיות שייך לשני קלאסים

אחרים שונים )אותו קורס יכול להיות שייך לשני חוגים שונים(

מעויין מלא– Composition – Class להיות שייך רק לקלאס אחד יכול

מעליו )חוג יכול להיות שייך רק לאוניברסיטה אחת(

ירושה -משולש עם קו רציף

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

ה"משתתפים" בקשר.

Interaction Diagram :שני סוגים

o Collaboration Diagram

o Sequence Diagram

oration DiagramollabC

o ולא של מחלקה( אובייקט מסויםאינטרקציה של(

Sequence Diagram

o למטה. "קו החיים" של האוביקט, הזמן מלמעלה

o סינכרונית-הודעה א –הודעה סינכרנית, חץ ריק –חץ מלא

Activity Diagram

o מתאר תהליך סינכרוני

o כל אליפסה היא פעולה שיכולה לקרות

e chartsStag

o ספסיפיקציה מלאה, מובנת ומוגדרת היטב. –הרעיון

o הצגת קוד בעזרת דיאגרמת מצבים

Class course{

Enum regist; /* open,close,full */

Enum state; /* future, active, finished */

_____ task; /* none,ex1,ex2 */

}

o "ו שנכון לכל המצבים בפניםמצב שמכיל תת מצב, וממנו קורה משה –"הכלה

o קורס פתוח להרשמה, האם יש מספר מצבים שאין ביניהם קשר –אורתוגונליות(

תרגיל בקורס(

o יצוג נוסף לאותו דבר:

o .יכול להיות מצב עם תת מצבים שונים

אבולוציה של תוכנה

האב המייסד –מאיר להמן

E-type – מערכתEmbedded – רכת שלא ניתן להפריד המערכות עליהן מדברים, מע

מהלקוח )לדוג' מערכת מחשבים של בנק(

8 החוקים של להמן המתארים התפתחות תוכנה כזו

o והתאמה למציאות שינוי מתמשך

o אלא אם נעשה גדילה בסיבוכיות התוכנה(refactor)

o הקצב שבו הדברים משתנים הוא מוגבל –רגולציה עצמית

o קבועבפרויקט גדול קצב העבודה נוטה להיות

o כדי לשמר את הידע בדרך כלל אין "מהפכות גדולות" –שימור ידע

o מערכת גדלה באופן קבוע

o איכות המערכת יורדת עם התפתחותה )אלא אם נעשים מאמצים אקטיביים כדי

למנוע את זה(

o התפתחות המערכת נעשית בעזרת משוב של בעלי העניין במערכת

:חלוקת פרוייקטים לשני סוגים

o gTerminatin – שמטרותיו ברורות. פרוייקט סופי

,מספקיםמפתחים Delivery אחד

לאחר הפיתוח מתחזקים

o Evolutionary – שמטרותיו הסופיות אינן ברורות ) פרוייקט אבולוציוניFacebook,

Linux:גם זה מתחלק לשני סוגים .)

Staged model

למשל כך שמטרות כל מחזור ידועות מראש מחזורים של עבודה(

(Unified Processעבודה בשיטת

,פיתוח Release ,פיתוח , Release ..

תחזוקה במקביל לפיתוח

Perpetual development –

מטרות לא מדויקות לטווח ארוך עבודה ללא תכנון.

ברגע שמשהו מוכן באופן מתוכנן אוכאן ניתן לשחרר

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

עצמו.

ריימונד( לינוקס –מקרה בוחן(

o Merge window – שבועיים בערך בהם מפתחים מציעים קוד שכתבו לטובת

הקרוב, נעשים טסטים ובדיקות ומחליטים מה יכנס. Release-ה

o כל פיתוח נעשה ע"י קבוצות שונות

o כל חודשיים בערךRelease חדש

להמן וטורסקי( של מערכתגדילה(

o מערכת גדלה עם הזמן

o ככל שמערכת גדלה קשה יותר לשנות אותה

o :פיתחו נוסחה להערכת גודל הגרסה הבאה 𝑆𝑖+1 = 𝑆𝑖 +𝐸

𝑆𝑖 =מאמץ.Eכאשר 2

o גדילה לינארית, קיבלנו גדילה –בניגוד למה שהיינו חושבים שנראה

דלגם קצב הגדילה ג –אספוננציאלית

o מספר המפתחים גדל -למה זה קורה

o Law" rooksB": הוספת כח אדם לפרוייקט שמתעכב רק תעכב את הפרוייקט

יותר כי ירש מאמץ בהכשרת העובדים החדשים.

o ?למה זה לא קורה בלינוקס

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

Continuous Deployment Variant

o "במיוחד שיטת פיתוח "מהירה

o Release כל כמה דקות

o )כל מפתח מספק ישר את מה שפיתח )טסטים אוטומטיים

o Release אוטומטי

o משמש בעיקר חברותWeb

o פייסבוק –מקרה בוחן

מפתחים עובדים על הגרסא שרצה

אין צוותQA מפתח אחראי על הקוד שלו, כל

Deployment פעמיים ביום

אשפרות לאפשר פיצ'רים למשתמשים ספציפיים -

אחוז קטן רואה את השינויים וכך מקבלים פידבק -

כל עובד בוחר על מה לעבוד

המערכת גדלה בצורה דרמטית

o אופציות לארכיטקטורה בפרוייקטים כאלה

נותגרעין יציב ומסביבו ארכיטקטורות קטנות שמשת

Services בעיקר ב( שונים וממשקים ביניהם-Web)

source-Open )ריימונד(

o זמן ארוך, תכנון למראשמסודר ומאורגן הכל –שיטת הקטדרלה o אבולוציה. –יש כביש וסביבו בונים לאט לאט דוכנים -שיטת הבזאר

מוש תוכנהיצוב ומיע

ארכיטקטורה

כללי- רכיטקטורהא

o אמורה לטפל בכל באינטרסים מנוגדים, אילוצים ומגבלות

o :אמורה לשקף את ההחלטות העיקריות

מבנה

)פונקציונליות )מה קורה אחרי מה

תקשורת בין החלקים השונים

אמינות וכ'ו ביצועים, – איךלא מה התוכנה עושה אלא

מתודולוגיות ,Frameworks

מודולריות

o בניית תוכנה במודולים

o :יתרונות

גמישות, שימוש חוזר, הרכבות חדשות

יתוח במקבילפ

חלוקה לוגית של הקוד

בדיקות פשוטות יותר

הבנה פשוטה יותר של הקוד

קל לתחזוקה

o :שני מדדים עבור מודולריות

Cohesion – רמות שונות של הקשר: .דולבין פונקציות באותו מוקשר

Incidental cohesion - גיבוב מקרי של פונקציות

Logical cohesion - פונקציות קריאת קבצים סוג לוגיפונקציות מאותו(

שונים(

Temporal cohesion - הריצה זמןשקשורות לפונקציות (init, config)

Procedural/Sequential cohesion - בסדר פונקציות שקשורות

מסויים flow-הופעתן ב

Communicational cohesion - אותם נתונים פונקציות שעובדות על

חיצוניים

Functional cohesion - עניין משותףמטרהשיש להן פונקציות/

Type/Data/Information cohesion - אותו מימוש שלפונקציות שהן

Abstract Data Type

ן הפונקציות.נרצה שיהיה קשר גדול בי

oupelingC – בין מודולים שוניםקשר

Common coupling - כמה מודולים שמשתפים משתנים גלובליים

Control coupling - מודול אחד ששולט במודול אחר

Stamp coupling - העברת מבנה נתונים למודל כאשר הוא צריך רק

חלק ממנו

Data coupling - העברת נתונים לפי צורך

נרצה שיהיה קשר מוגדר היטב אך שלא יהיו הרבה תלויות

o של מודול אחר מימושכלומר, לא להתבסס על – לדבר עם זרים"לא " –כלל אצבע

שלנו מול המודל. הקשראלא רק על

Composability (~)קשר בין רכיבים בתוכנה

Pre & Post condtions (oareH)

o הסימון {P} S {Q} היה העולם מצב אם: "מסמל P הפעולה את וביצענו S מצב אז

".Q יהיה העולם

o P הוא בעצם ה-Preconditions ו-Q זה ה-Postconditions

o Invariants – התוכנית ריצת במהלך מתקיימים שתמיד דברים על הצהרה.

o שבהנתן כדי להוכיח )גרירה, שרשור, איטרציה וכ'ו( יומותור הגדיר אוסף של אקסה

Preconditions אכן נקבל את ה-Postconditions .)לא צריך להבין לעומק(

חוזים (ayerM)

o לכל פונקציה צריך להיות חוזה שנכתב ע"י מי שכתב את הפונקציה ומי שמשתמש

בפונקציה.

o :יתרונות החוזים

בצורה מסודרת, חוסך כאב ראשחשיבה –מתודולוגיה

מאפשר להבין מה המערכת עושה מבלי לקרוא את החוזה –דוקומנטציה

הקוד עצמו

o :חסרונות

בדיקת יתר של דברים )בודקים משתנים לפני קריאה לפונקציה למרות

שברור לנו שהם בסדר(

עבור כל לקוח הטיפול במצב השגיאה יכול להיות שונה

פת אייפלש

o שפתOOP

o מושפעת מאוד מנושא ה-Contracts – רבות לגבי הצהרותPreconditions ו-

Postconditions.

הפרת חוזים

o באג:יש –אם חוזה מופר

Precondition שאצל המשתמבאג –הופר

Postcondition אוinvariant אצל ספק הקודאג ב –הופר

o :רמות שונות לוידוא הפרות בתוך הקוד

ללא

רקPrecondition )זו ברירת המחדל בדרך כלל(

recondition, PostconditionP

, invariantrecondition, PostconditionP

:הכל וגםLoop invariant, Assrtions

ubtitutionS (Liskov, Wing)

o פולימורפיזםנפוץ: הכי –ים במקום אובייקט אחר מסוג מסו הכנסה של אובייקט

o :עניינים סינטקטיים

חתימה המתודה

כלב( האובייקט המוחזר יכול להיות יותר ספציפי(

חיה( פחות ספציפיהאובייקט שהמתודה מקבלת יכול להיות(

xceptionsE

תת מחלקה לא יכולה לזרוק אקספשן משלה אלא רק של מחלקת

האב

o :עניינים סמנטים

:חוזים

על רק תת מחלקה יכולה להצהירreconditionP חלש שווה או

ממחלקת האב יותר

conditiontosP על זה ולהוסיף ויכול הכילל חייבשל תת מחלקה

של מחלקת האב.

ל ויכול להוסיף חייבת להכיל תת מחלקה-sinvariant מחלקת של

האב.

הוספת מתודות ב-subtype

מכירה שמחלקת האבבאובייקט לתת מחלקה אסור לשנות משהו

לא יכולה לשנות אך

לתת מחלקה מותר לשנות דברים שלא קיימים כאשר האובייקט

הוא מסוג מחלקת האב

בדיקה

LSP – שלנו על מבנה הנתונים מבלי לדעת מאיזה סוג ההנחות

ספציפי כל אובייקט

ורה לקבל פונקציה אמT אבל אנחנו נותנים להS שהוא תת

ולא Tבעזרת מתודות של S. אם נעשה בדיקות על Tמחלקה של

כלומר – LSP-עמדנו בדרישות ה – Sהצלחנו לגלות שהוא בעצם

.T-ב Sאפשר להחליף את

estingT

תי שיטות טסטים עיקריותש

o Black Box –

ממשק ומקבלים-Spec )קופסא שחורה( .

יודעים מה הפלט עבור קלט מסוים.לא יודעים איך הקוד ממומש .

נרצה לבדוק את המקרים הקשים ביותר

לקבוצות שקילות שונות האפשרי )כולל הלא חוקי( קלטמחלקים את ה

נעדיף בדיקות עבור כל קבוצת שקילות ולא הרבה בדיקות עבור

קבוצה אחת

נדאג לבצע בדיקות עבור מקרי הקצה של כל קבוצה

o White Box –

מתעלמים מה-Spec ובודקים את הקוד של הפונקציה עצמה

Flow Data –

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

.רשימת הזיווגים בין השמה לשימוש היא רשימת הטסטים שלנו

ontrol FlowC –

:נרצה לייצר טסטים מכל הסוגים

o Statement Coverage – ו את כל בוחן שיפעיל מקרי

לנו לעבור פעם מספיק –)בענף למשל שורות הקוד

אחת(

o Branch Coverage – שיבחנו את כל הבוחן מקרי-If,

Else גם .Loop-control הואBranch-point הרעיון הוא .

ומה קורה TRUEלבחון עבור כל "ענף" מה קורה כשהוא

.)נצטרך לעבור בו פעמיים( FALSEכשהוא

o Path Coverage – את כל המסלולים בוחן שיבחנומקרי

האפשריים בקוד.

:הסבר טוב

http://testersthoughtsuncombed.blogspot.co.il/2013/02/sta

coverage.html-branch-vs-coverage-tement

שתדע להריץ את כל הטסטים בצורה אוטומטית כך שאם נשנה משהו לא נצטרך תשתית

לעשות זאת ידנית מהתחלה.

השוואה אוטומטית בין תוצאות הטסטים לתוצאה הרצויה

טבלתCases-Test

:(Name, ID)עבור פונקציה שמקבלת בדר"כ נראית כך

Rational Result ID Name

”T 012345678 “Moshe תקין

”F “ “moshe אות קטנה בשם

”F 1 “Moshe ת.ז. קצרה

שיהיו מיותרים ויש כאלה Test-casesיכול להיות כמובן שיש אם יש לנו גישה אל הקוד עצמו,

שנרצה להוסיף.

Inspection

o אחר שמסתכל על הקודשהו ימ – טסטים רך חלופית לבדוק קוד. במקום להריץד

o רמות שונות שלInspection:

reviewPeer -)בדיקה ע"י עמית )הכי פחות פורמלי

Walk through – דבקים של הקבוצה.של כותב הקוד לקבוצה עם פיהצגה

Formal inspection – ,קבוצה של אנשים עם תפקידים פורמלי מאוד

:, תפקידם למצוא בעיות אפשריות בקודמוגדרים

Moderator – ,אחראי על תכנון ותיאום יוזם

Reader – בהצגת הקוד)שלא נוכח( את המתכנת מחליף

Inspectors – הנוכחיםכל

Recorder – .מתעד הכל

o חסרון ה-Formal inspection לפי(Gilb :)

ריאלילא – שיטה שקשה מאוד לעבוד בה

מצריך יותר מדי זמן

o ורה מדגמית ולקבל החלטות אסטרטגיות.הפתרון: לעשות את זה רק בצ

תלהיויכול –התפלגות הבאגים במודולים השונים לא אחידה אם –חסרון

שלא נקבל אומדן אמיתי )נפספס מודולים עם באגים משמעותיים(.

נורמליזציה של איכות קוד (apres JonesC)

o איך להשוות בין איכות של קוד בין פרויקטים בלי להתחשב בגודל שלהם

o :מדדים אפשריים

Cost per Defect – טוב, המחיר יכול להשתנות לפי המפתחיםלא

טוב, תלוי באבסטרקציה של הקוד ובשפת לא – פיזור הבאגים בקוד

לא מאפשר לבדוק מה שהוא לא קוד התכנות.

Defect per function cost – לפי התוכן הפונקציונליבאגים (function

point) הכי טובה לפי השיטה – ולא לפי הקוד עצמוJones.

aintenanceM – תחזוקה

Corrective maintenance –

o באגים שמדווחים ע"י לקוחתיקון o יקונית Security – דווקא לפי דיווחלאו

Adaptive Maintenance – למצב המשתנההתאמה פיתוחים ו

תהליך maintenance )כולל )בעיקר בהקשר של תיקון באגים:

o Concept Localization –

המקום הספציפי בקודמציאת

שימוש בעיקר ב-Control Flow

o Impact analysis –

איך תיקון הבאג ישפיע על כל התוכנה

שימוש בעיקר ב-Data Flow

בשביל מה צריךMaintenance?

o Code comprehension – של הקוד ברמת הפרטיםהבנה

o Reverse Engineering – בעיקר לתיקוני של מבנה הקוד ולמה הוא כתוב כךהבנה(

Security ול-Impact analysis.)

lexityode compC קשור ל(-Code comprehension)

o כמה קשה להבין קוד

o :גורמים המשפיעים על המורכבות של קוד

LOC (Lines Of Code)

התאמה או סטייה ממקובלות

מודולאריות

דוקומנטציה

מבני שליטה (if, switch, for, goto)

שימוש ב-nesting )כינון(

פורמט: אינדנטציה, אורך שורה

שפה

o :מדדים שונים למורכבות קוד

LOC – קל למדודהכי ( רקNMBC – Non Blank Non Comment)

MCC – McCabes Cyclomatic Comp –

1זרימה, שקול למספר מבני שליטה +גרף.

נותן את המספר המינימלי של הטסטים שיעברו על כל המסלולים

(Branch Coverageהב"ת בקוד )כמו

לפי הממציא פונקציה שה-MMC היא בעייתית 11שלה מעל

ה ללא מוסיף הרב –חסרונות-LOCלא בודק כינון ,

Structure Complexity –

לא רק פונקציה כמו( בודק את המבנה הכללי של התוכנהMCC)

איך המודולים מתקשרים אחד עם השני

𝐶 = 𝐶𝑖𝑛 ∗ (𝑓𝑎𝑛 − 𝑖𝑛 ∗ 𝑓𝑎𝑛 − 𝑜𝑢𝑡)2

Cin ( סיבוכיות פנימית =MCC)

fan-in כמפה פעמים קוראים לפונקציה =

Fan-out לכמה פונקציה הפונקציה קוראת =

לכל אחת מהפונקציות Cמחשבים

managementProject

MM – Monthan M

o מדד לכמות עבודה ומאמץ

o MM אידאלי מחושב ע"י פונקציה שלוקחת בחשבון את גודל הפרויקט והקושי שלו

o אקספוננציאלי ומייצג מימד של קושי אץ אינו פונקציה לינארית של הגודל אלמהמא

כת גודל של פרוייקטהער

o LOC – "כ מתכוונים רק לבדר-Statements

o FP (Function Points )–

ן הפונקציונלי של הפרויקטלהעריך את את התוכנסיון

התבססות על הדרישות

אפשר להמיר ל-LOC

התחשבות גם במורכבות הקוד

הערכה נעשית עוד לפני המימוש

COCOMO

o נתייחס בעיקר להקשר הערכת המאמץ – מודל הערכות בתכנון פרויקט

o ע"י תרגום יתיקט נעשל הפרוהערכת גודFP ל-LOC לפי השפה שבשימוש "(KLOC)"

o תוך יתן לחשב גם את הזמן הדרוש מנMM הוואת הצוות הדרוש מתוך הזמן-MM

16

1

91.05

194.2

i i

SF

EMKLoCMMj j

SF, EM - Scaling factors, Effort multipliers

= 3.67 * MM^somthingime T

Staff = MM/time

o ניתן במקום לחשבFP לחשבUCP – Case PointsUse :

* ENV TECH * CP = (UC+A)U

UC – סיבוכיות ה דירוג-Use Cases לפי מספר הצעדים, מספר(

הקלאסים(

A - סיבוכיות השחקנים )בן אדם, תוכנה וכ'ו(דירוג

TECH – מתוך טבלה( טכנית של הפרוייקטמורכבות(

ENV – מתוך טבלה( הסביבהמורכבות(

ארכיון

o בדר"כ מגבים בארכיון גרסאות ישנות של הקוד

בעיה: כתיבה במקביל

o :פתרונות

נעילה בזמןCheckout )למפתח אחד יש רק –)שליפת גרסה מהארכיון

Checkinגישה, נפתחת רק בזמן

Merge – מקומות שונים בתוכנה. אם אוטומטי של קוד שנכתב בשני מיזוג

יתקבל. Commitה שינוי באותו מקום רק הראשון שיעשה נעש

Update – אוטומטית את הגרסה שעליה עובדים עכשיולעדכן

בעיה: אטומיות

o רוצים ש(-Commit שכולם או – תהיה פעולה על מספר קבצים ולא רק אחד

(מתעדכנים או שאף אחד לא מתעדכן

o מיות וטא –פתרון(…Shocking )– בפעולתCommit או שכל הקבצים עולים או שאף

קובץ לא עולה

בארכיון( בעיה: נפח(

o פתרון: לשמור רקdiff ולא את הקבצים עצמם

o בכל פעם שעושיםcommit מתווספת הערה של מה ששינינו

Distributed VC

o תח יש ארכיב משלו.לכל מפ

o GIT ,ercurialM

o :איך מתאמים בין הארכיבים

Pull – את הארכיב שלי ע"ב מה שנמצא בארכיב אחרלעדכן

Push – גרסה בארכיב אחר לגרסה שלילעדכן

o :יתרונות

מהירות

גיבוי נוסף

o lowF :אופייני

Pull

Update

Edit

Pull + Update + merge

בדיקות

Push + commit