ניהול איכות תוכנה – ניתוח מערכות עכשווי ואיך עושים זאת על פי ISO 9000-3 ת"י 2000-3

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

OCR (הסבר)
בריאן המבלינג ₪5 הוצאת הוד-עמי לספרי מחשבים ניהול איכות תוכנה !5)( 3 כולל ת"י 2000-3 תרגוס לעברית : אליעזר ארז עורך: יצחק עמיהוד ייעוץ מקצועי: דר' אביגדור זוננשטיין - מכון התקנים הישראלי עריכה לשונית ועיצוב: אניקה סואץ, קרן קוברובסקי עיצוב עטיפה: סטודיו מצגר שמות מסחריים שמות המוצריס והשירותיס המוזכריס בספר הינס שמות מסחרייס רשומיס של החברות שלהס. הוצאת |וו-שוגזכ)))א והוצאת הָוד-עמי עשו כמיטב יכולתן למסור מידע אודות השמות המסחרייס המוזכריס בספר זה ולציין את שמות החברות, המוצריס והשירותיס. שמות מסחרייס רשומיסם (001510760ז 5 חח הזו) המוזכריס בספר צוינו בהתאמה. הודעה ספר זה מיועד לתת מידע אודות מוצריס שונים. נעשו מאמצים רביסם לגרום לכך שהספר יהיה שלם ואמין ככל שניתן, אך אין משתמעת מכך כל אחריות שהיא. המידע ניתן ''כמות שהוא' ("8 5"). הוצאת !/₪1-שגז66וא והוצאת הוד-עמי אינן אחראיות כלפי יחיד או ארגון עבור כל אובדן או נזק אשר ייגרס, אס ייגרס, מהמידע שבספר זה, או מהדיסקט שעשוי להיות מצורף לו. לשם שטף הקריאה כתוב ספר זה בלשון זכר בלבד. ספר זה מיועד לגברים ונשיס כאחד ואין בכוונתנו להפלות או לפגוע בציבור המשתמשים/ות. שירותי תקשורת : ב טלפון: 09-9564716 24 שעות ב פקט: 09-9571582 24 שעות ב חנות וירטואלית באינטרנט: //₪61.60.1זהחז]אס.צוששש//:0ו1ח ב) דואר אלקטרוני: ]ו.)6ח.חסופוט)6ח0)!חחג סמ 0-ב ב.גווך ניהול איכות תוכנה !5)6( 3 ----4%---- כולל ת"' 2000-3 בריאן המבלין 6 ד הוצאת הוד-עמי ד 6 1 ₪] לספרי מחשבים ₪ צזווהּוכ) 6זבּצ50 סחוטְהּחבּו פחוופחחזהּר! הפוזם עץ 2ז .= :הסו31|פה3ז ד שצ6זס6] טח וח .1 :זס+ו0= חסוו60 פִהְבּטחָח3! חפווהַח= 6ח+ וחסז] הסו)5!3ח3ז! 260וזסחזטה .6 6 )חוזץק60 ,ו!ורו-ששבּזכ)סו עס ססתפווסטס 7 6 זַתִ8זץק0ס6 .10 ווחג-0סרן )0( כל הזכויות שמורות הוצאת הוד-עמי לספרי מחשבים בע'ימ ת.ד. 6108 הרצליה 46160 טלפון: 09-9564716 פקס: 09-9571582 אין להעתיק או לשדר בכל אמצעי שהוא ספר זה או קטעים ממנו בשוס צורה ובשום אמצעי אלקטרוני או מכני, לרבות צילוס והקלטה, אמצעי אחסון והפצת מידע, ללא אישור בכתב מאת ההוצאה, אלא לשם ציטוט קטעים קצרים בציון שם המקור. הודפס בישראל ניסן תשנייז, אפריל 1997 0 %5חףוה ו|א .+ ואה-ססו הּץו|2ז46] ,6108 .0.8 ק 7 ווזסג , 51| מסתב 965-361-124-0 א58! ה-----.-|-| | |[ תוכן עניינים קצר % פתח דבר ל :סמש 17 מבוא ב חק 1 - יור ור פרק 1: הנדסת איכות תוכנה להקל בטב טבה 2/5 פרק 2: מערכות לניהול האיכות - לשס מה! 1 חק 2 0 פרק 3: ניהול איכות, סיכוניס ופרויקטיםס ||[ | פרק 4: תהליך הפיתוח הבסיסי ...| ...|| -. פרק 5 : עיקרי מערכת האיכות - לב המערכת 7 מ4ק 3 ו פרק 6: מדידה ושיפור תהליכיס לק לטרה בלשמש םמשל תונכל 11315 תק 4 8 פרק 7: איכות ומתזורי חייס לא-קווייס 1074 פרק 8: יצירת אבטיפוס ופיתוח יישומיס מהיר 19 פרק 9: פיתוח מוכוון-עצמיס 177 מק 5 ו פרק 10 : הדרך שלפנינו 0 [(ספת :7'₪‏ 2"! 2000-3 2 [ססת 5': כפכס ₪42!א/ ₪4/כ!מ. פמ ש6ית ו ₪'[לקס מכ60'אים 1 ₪.ק ס 5כ! 2 יקס 914 ו תוכן תעניינים | 5 תוכן העניינים % פתח דבר .ורי יר מבוא האורו רו .|| | הספר, ומה שיש בו 0 0 מפת התפיסה הכללית 20-5050550 מק 1 || 0 ו תוכנה, איכות והנדסה ...]|| | התוכנה מהי האיכות מהי מה ההקשר של ההנדסה לכאן הנדסת תוכנה 7- -|-|---/.---- יר איכות תוכנה 2 הגדרת דרישות השגת איכות התוכנה 32 תהליכי איכות תהליכי הנדסת תוכנה 0 מודליס המבוססים על מחזור חייס הנדסת איכות תוכנה 0 תהליכיס ומוצריס 0 שיטות מוכוונות-תהליך שיטות מוכוונות-מוצר || || ...2 --// //-/-ר-0 00 0. פיתוח התפתחותיל (אבולוציוני) פיתוח מוכוון-אובייקטיס ניהול פרויקט תוכנה -[///----/-.-/-/-/-/. מ" תע - גישת תקן 9000-3 150 לניהול איכות תוכנה 0 תוכן העניינים ‏ 7 פרק 2. מערכות לניהול האיכות - לשם מה .... אתגר האיכות סיל של בו למל ₪1 מהי הדרך אל האיכות ו ל קנ ו ו 00 ו מהי איכות תוכנה ו -/-//‏ - ררה מה אנו מחפשיס ||[ --..-.-- -- // //00/0. תהליכי איכות ...0-7 ל יי מערכות איכות טב הכ 0 מערכות לניהול איכות -|||-|-- || -כ.---.-- -- || | סדרת התקנים 9000 150 0 שו סש בהסה טל אוב סקמ הטלמל אש 17 דרישות תקן 9001 150 ו ו 7 16 1 150 - 20 הסעיפיס 0 אחריות הנהלה ְְְָ|/|/|/|/|---|-|--|-|--- .2 -.-‏ - 8 תחוס העבודה 0 פעילויות תומכות 0 ו ב .50 מה מיוחד כל כך בתוכנה 0 הקוויס המנחיס 9000-3 150 ב ל ל 51 3 1500 - פירוט הסעיפיס ו ה ו 2 3 1500: מערכת איכות - מסגרת ל 0 = קל 3 (1500: מערכת איכות - פעילויות במחזור החיים 52-22 3 (150(0: מערכת איכות - פעילויות תומכות ג וסיט 2056 2 56 מערכת לניהול איכות למפתחי תוכנה 0 איכות תוכנה - עובדות התייס 0 שב < ל מק 2 ור - פרק 3 ניהול איכות, סיכוניס ופרויקטים 5 מבוא ל ניתוח הסיבות לכישלון פרויקטים /---/------|-|-|-|-|-|-/-/-/ יי שלב 1 - אופטימיות ריר שלב 2 - התפכחות.... שלב 3 - תקוות 0 שלב 4 - ייאוש 7/0 שלב 5 - ציניות 0-9 שלב 6 - פיטורין מה השתבש כאן ב ניהול סיכוניס 8 ניהול איכות תוכנה סיכוניס שמקורס בתכנון ב צמצוס הסיכוניס - תכנון האיכות הבהרה מלאה של הדרישות ב הגדרת תפקוד המוצר וו ,| הגדרת דרישות:האיכות ה אבצה מדידת איכות המוצר וו הו | || דרישות המעקב סקר החוזה 1 כיצד מטפל תקן 9000-3 150 בסוגיות אלו | השאלה של מחזור החייס 0 תכנון פרויקטיס וו[ | ...]|| תכנון הפיתות.... || ניתוח הדרישות וסקר החוזה .י | בקרת הדרישות 0 .||||- ו ..|.-|-|-| - - | | כיצד נוודא התחלה מוצלחת של פרויקטיס כ ניתוח ותיעוד הדרישות 6 קטלוג הדרישות קווי פעילות וטבלאות של קווי פעילות.... ניתוח דרישות וניהול פרויקט מתוך ההֶקשר עקרונות בסיסייס של ניהול פרויקטיס 0 2 פרק 4: תהליך הפית(ח הבל/0?וטודורורווטרולורורוירורום ...85 מהו התהליך הבסיסי.. 0 מחזורי חייס || || || 7 מודל מפל המיס .|| מודל החילזון 7[ | || || מודל מסוג צ .|| מתודולוגיות ...7 - כל אימות ובדיקת תקפות ... ניהול תצורה תחזוקת תוכנה -| | |-|-|-|-/-/-/-/--- 0 כיצד תומך תקן 9000-3 150 ברעיונות מפתח אלה עו 5 הנחייה בנושא מחזור החייס || || ||[ || הנחייה בנושא מתודולוגיות לו הנחיות בנושא אימות .15 הנחיות בנושא סקריס .15( הנחיות בנושא בדיקות והוכחת התקפות וו וי הנחיות בנושא ניהול תצורה 757 הנחיות בנושא תחזוקת התוכנה 0 ב תוכן העניינים ‏ 9 10 נהלי פיתוח תוכנה ו -..--/-/---. מתודולוגיות מעשיות כללי תיכון 0 נהגי תכנות .| --- --/-/-/- -/-..- פיתוח המבוסס על טכנולוגיית יהדור הרביעלי פיתוח מבוסס חבילות יישומיםס סטנדרטיות או מותאמות 101 הבחירה והשימוש בכלי תוכנה [..].-.-.-.-.-/-./-/-0000909₪/79 00/0 הערכה ובחירה של כליס | .]|| ההכנה וההרצה של כלי התוכנה 7 ניהול הכליס - -------///./- | רמות הבדיקה || | -- תכנון הבדיקה 0 מה אמורה תוכנית בדיקה להכיל 0 מפרט הבדיקה ותיכון הביצוע ... בקרה ורישוס של בדיקות 0 קבלת המוצר | ניהול תצורה | ו | זיהוי ויכולת מעקב בקרת שינוייס | תכנון ניהול תצורה כיצד משתלב תהליך הפיתוח הבסיסי במערכת ניהול איכות (15א0) שלנו 1 פרק 5: עיקרי מערכת האיכות - לב המערכת ו 117 מהו עיקר מערכת איכות 1 פעילויות עיקריות במערכת האיכות || תקן 9000-3 150 ומה שמעבר לו - עיקרי מערכת האיכות 1 מדיניות האיכות 0 ארגון ותחומי אחריות נציג ההנהלה 0 הדרכה |[ //, מבדקי איכות פנימיים פעולה מתקנת 0 סקר חוזר של ההנהלה מדידות ומדדיס 0 129 בקרת התיעוד /... רשומות האיכות ניהול איכות תוכנה קצת תיאוריה ]| .]| -.- -|-- 2 .-/-.-/-/// | מתודולוגיית המדידה יעדיס, שאלות ומדידות ...|| .| -/--/-/-. חשיבה מסתעפת-מתכנסת ְְְ|[/|/|/-////-/-//-----//----.-.|.-|].-.- || הנחיות תקן 9000-3 150 ה כיצד ליישס בפועל את רעיונות המדידה הצגת המדדיס /₪ְְ[₪/[₪[ְְ[||-]ְְ[|/|[/[/-/-/-/-/-/- --‏ -- מה הס התהליכיס שיפור תהליכיס טכניקות למידול תהליכיס || אסטרטגיות לשיפור תהליכיס 0 גישת ימעלה-מטה! -..|[|-|-|-|-|-|-/-/-/- | גישת ימטה-מעלה! ןוו[ //-.----|[||| ./-, אסטרטגיה משולבת 2-00 :- >< ב מדדים מעשייס לשיפור תהליכיס ו[ ]|| :|| מבדקיס ומדידת ביצועיס ןוו .-.1[1-7.-/-- ת- מבדקי פיתוח תוכנה מדידת ביצועי פיתוח התוכנה וו || שיפור תהליכיס מעשי ...| 7/-- - 2 הצבת מטרות מציאותיות לשיפוריס י 222 --/-/-/- /.-.-.2- 2064 מחזור‎ טכניקות וכליס כיצד מתחיליס בהכנת האסטרטגיה למדידה ולשיפור תהליכים 162 וודא שהתהליכיסם יהיו נכוניס וו[ .|| מה בדבר איכות המוצר! ו[ .| -‏ - --, מק 4 .|| .. פרק 7: איכות ומחזורי חייס לא-קווייס 1 מבוא ההכ -- מחזורי חיים קווייס ולא-קווייס 1 מהן השיטות הלא-קוויות 1 תוכן העניימים ‏ 11 ה התפתחות התוכנה ו .| | התפתחות מתוכננת ולא מתוכננת 1 שיטות התפתחותיות :|( | /-/--,. פיתוח תוספתי .|| ו שיטות מבוססות-חבילת-תוכנה... התחזוקה כתהליך התפתחותי ה הנחיות תקן 9000-3 150 מיושמות לשיטות לא-קוויות ל[ תקן 9000-3 150 ומחזורי חייס לא-קווייס ניהול פרויקט - הגדרת שלבי הפרויקט... ניטור ההתקדמות 0 תכנון ותכנון חוזר - |[ || |[ 0 תכנון איכות עבור פיתוח לא-קווי 0 לס אימות ובדיקת תקפות ניהול התצורה 0 מה הם היתרונות והמכשוליס שבגישה הלא-קווית פיתוח יישומיס משותף 0 פיתוח יישומיס מהיר - 384 תכנון פרויקט בשיטת פיתות יישומים מהיר תכנון ראשוני -/-.-. בקרת תהליך פיתוח יישומיס מהיר ניהול איכות פרק 9: פיתוח מוכוון- עצמיס 0 מבוא 1 מהו עצס! התשובה מותנית במי שהנך 1 מהו מודל עצס || ניתוח מוכוון-עצמיס תיכון מוכוון-עצמיס תכנות מוכוון-עצמיס גישת הפיתוח מוכוון-העצמיס גישת הכלאיים (אוזפעו) | יצירת אבטיפוס עס מחלקות.. מחזור חייס מוכוון-עצמים 2 ניהול איכות תוכנה ניהול פיתוח מוכוון-העצמיס מהן סוגיות האיכות 07 70 00 כ מספר בעיות איכות מעשיות... תכנון האיכות תכנון איכות עבור פיתוח מוכוון-עצמיס ל 2 האס פיתוח מוכוון-העצמיס הוא אמנס התשובה הנכונה! 0-ב 216 מק 5 0 פרק 10: הדרך שלפנינו 22 האס אנו זקוקיס לדרך קדימה? 0 הגישה המבוססת על תקניס בעיית מחזור החייס ו[ כ , 2 ניהול פרויקטיס לא-קווייס מיומנות הבוחניס || 0/-/-/-/./.-/---|-‏ 8 ירוי הגישה המבוססת על מודליס וו[ |-|-/-/-/-/-./-/-./././-/-/-/00007/ 000 / מודליס לאיכות וסכימות הערכה.... בשלות התהליך והערכת היכולת מהן מגבלות הגישה המבוססת על מודלים! 25 גישת שיפור תהליכים לאן עכשיו? 2 גיבוש הגישות .| .|| רע מסגרת להתפתחות לארה 2.28 שאלות, שאלות ב 0 [(ססת ₪'%: 2"! 2000-3 2 (ססת 9': כפכס ₪42!א! 4ש/כ!מ. פמ צ6ית וו.. ש'[3קס מכ60'איט ו 0 708 6ק ס שכ! 2 בק ס 914 ורוו רו יי תוכן העניינים ‏ 13 פתח דכר התוכנה כבשה לה מקוס מרכזי בתיינו. השימוש בה כמרכיב החכם במוצרים, כאמצעי לשכלולס ולפישוטס של תהליכי הספקת השירות וכמקור להספקת מידע עדכני אמין ומנותח עבור הצרכים הניהוליים, הולך וגובר בקצב מסחרר. במקביל, ולהתפתחות התוכנה חלק בזה, מתרחש תהליך הגלובליזציה שבו העולס הופך לכפר גדול אחד. תהליך אה מתבטא במיזוג של חברות והקמת חברות רב- לאומיות, במעבר כמעט חופשי של סחורות מכל אתר לכל אתר על פני הגלובוס, ובהספקת מידע עדכני בזמן אמת על כל נושא שהוא, לרבות חדשנותס ואיכותם של מוצריס חדשים וותיקים. מצב זה מהווה כר פורה להגברת התחרות, כשייהאיכותיי מהווה פרמטר מרכזי בה, ולהגדלת מודעותו של הצרכן, הן כארגון והן כאדס בודד, לאיכותס של המוצריס. ואיכות נתפסת במגוון התכונות והאפשרויות שגלומות במוצר, ובמספר מינימלי של תקלות, לאורך מחזור חייו. מצב ענייניסם זה מציב למגזר בתי התוכנה רף יעדים שמורם על ידי הלקוחות באופן תדיר, מדי יוס ביומו, והרף כולל שתי דרישות, שעל פניו, בתפיסת הדברים הקלאסית, נראות כסותרות: הספקת תוכנות מורכבות *ותר ובזמן תגובה קצר יותר מחד גיסא, ומסירתן כשהן יינקיותיי מתקלות מאידך גיסא. הניסיון, שנצבר תחילה בארגוניסם התעשייתיסם, לימד, שתנאי הכרחי לשיפור האיכות הינו הקמה וקיוס של מערכת לניהול האיכות בארגון. בעולס שבו כל ספק הוא גס לקוח, התאגדו כולס ותחת החסות של ארגון התקינה הבינלאומי, פרסמו את סדרת התקניס בקבוצת 9000 180. תקנים אלה זכו להצלחה מסחררת והפכו לרבי מכר. כיום, הדרישה להתאמה לתקן הרלוונטי בסדרה זו, הוא תנאי הכרחי לקבלתה של הזמנת עבודה במרבית ההתקשרויות התוזיות. בגלל ייחודה של התוכנה כמוצר, הוקדש לה תקן מיוחד שמספרו 9000-3 150. תקן זה קיבע את הדרישות לניהול האיכות בארגוניס שעיסוקס פיתוח תוכנות. ההצלחה הכללית של 9000 150, לא פסחה על תקן ייחודי זה. עדות לכך הוא מספרס הגדל במהירות של בתי התוכנה, באר ובעולס, שמקבליס את אישור ההתאמה לתקן. אני מקווה שהקריאה בספר זה יהיה בה כדי לפתוח בפניך זוויות מבט חדשות בכל הקשור לניהול האיכות בתהליכי פיתוח התוכנה, ושהמידע והרעיונות שמצוייס בו יסייעו לך ולארגונך בשיפור מערכת האיכות, בפיתוחם והפקתס של מוצרי תוכנה איכותייס יותר, וכתוצאה מכך, בשיפור כושר התחרותיות של הארגון. זיוה פתיר מנכ''ל מכון התקנים הישראלי 15 רינזהתפ‎ מבוא םוה הספר, ומה שיש בו ספר זה מציין מסע של תגליות. לאחר קריירה בחומרה, בתוכנה ובהנדסת מערכות, בהס מילאה האיכות תפקיד משני ולא בולט, גויס המחבר לשורות חברת 11א6וך %8. בתפקיד בלתי מוכר ומלא אתגריס זה, התגלו לו דבריס חדשיס בקצב דחוס ומהיר. מעטות ההתנסויות שהן מאירות עינייס יותר מאשר בדיקה מפורטת של שגיאות הזולת, בהן אתה נוכח שהן בדיוק אותן שגיאות שעשית אתה במצביס דומיס רק לפני שניס מספר. התחושה, שבמקצוע המאופיין בקצב גבוה של שינוייס טכנולוגיים, דווקא הדבריס החשוביס באמת הם המנוגדים לשינוייסם ולשיפוריס כאחד, היא ממש מהממת. המסע האמיתי מתבטא בהכרה ההדרגתית שהנדסת תוכנה מעשית וניהול האיכות אינס בלתי תואמיס. היפוכו של דבר, רבות מהבעיות המעיקות עלינו, שורשיהן נעוציס בפיתוח גרוע של תרבות האיכות, בעוד אנו מחפשיס את הפתרונות בטכנולוגיה. דוגמה קלאסית לכך ישמשו שפע הכליס לניהול פרויקטים, שנועדו להפוך את התהליכיס לאוטומטייס, ואשר רק מהנדסי תוכנה מעטיסם הצליחו ללמוד את השימוש בהסם. קריירה בענף התוכנה, שהתחלתה בניהול צוות פיתוח תוכנה אינה דבר שכיח, אך יש גם יתרונות ברכישת ניסיון מעשי לפני רכישת השכלה. כאשר באה לידי ההזדמנות להעביר שנה בלימודיס שלאתר התואר, היתה זאת חוויה רצויה ופורייה. שהות מסוימת בתעשיה יכולה להוות תרופת-נגד לשגיונות של חיי האוניברסיטה ועימות קשה לרעיונות החדשיס שטופחו שס. ההתנסות שלי בניהול פרויקטיס בתעשיה הותירה בי עקבות שלא יימחו, ועוררה מספר שאלות יסוד בנוגע לקשר שבין האיכות לבין פרמטריס מותחשייס יותר של פרויקטיס, כגון פרמטר העלויות. החזרה לחייס האוניברסיטאייס סיפקה את פסק הזמן שנדרש להרהור בהתנסויות שלי ולעיצוב מספר רעיונות לצורך הצגתס לתלמידיס. בחמש השנים האחרונות עובדו רעיונות אלה ונוסו בשאון וההמולה של עבודת הייעוץ. בדומה למתבריס רבים לפני, אני מבין עכשיו שאני יודע הרבה פחות ממה שחשבתי, ויש לי גסם מספר רב של שאלות שנותרו ללא מענה. פוא 17 מה שהתכוונתי לספק כאן, הוא מורה דרך שימושי לניהול האיכות בענף התוכנה. אראה סיפוק במאמצי, אס יעלה בידי להרתיע מביורוקרטיה מיותרת, או לשכנע מספר מהנדסי תוכנה להאמין שאכן יש חשיבות לאיכות. ספר זה אמור להיות נגיש למנהלים ולאנשי מקצוע בתוכנה ובאיכות, משוס שכל אחד מהס ימצא בו חומר המכוון אליו ספציפית. אחת המטרות החשובות ביותר היא טיפותח הדו-שיח בין כל העוסקיס בניהול איכות התוכנה - |הסוח6קהתגות ץ1ו!|טף 6זבשו]50. תקוותי היא, שכל שלוש הקבוצות יקראו בו וידונו בהשלכותיו. הספר צמח מתוך 6וח5616 116%11, שהיא יוזמת איכות בריטית, אך הנושאים הנדוניס הס אלה המתעורריס כתוצאה מיישוסם התקניס 9001 150 ו- 9000-3 150, או מיישוס תקנים והנחיות אחריס לניהול מערכת איכות. הספר אמור להיות בעל ערך בכל מקוס בו קיימת גישה לאיכות המבוססת על תקניס, או במקוס בו שוקליס שימוש בגישה זו. בספר חמישה חלקים. חלק ראשון (המכיל שני פרקים), מספק חומר רקע והדרכה לרעיונות הבסיסייס שמאחורי הנדסת תוכנה, איכות תוכנה וניהול האיכות, ומבהיר במה עוסק ניהול מערכת איכות. פרק 1 מציג את הנושאיסם הראשייס בזה אחר זה ומציב אותס בהקשר שביניהם. כן מוצגות הגישות החלופיות להנדסת איכות התוכנה שנדון בהן בהמשך הספר. פרק 2 שוקל את המשמעות של תוכניות איכות והישגיהן. מוצגיס עקרונות ניהול האיכות ומוסברת בו הגישה של ניהול מערכות איכות. יש אף התייחסות קצרה לתקן 9001 150 ולקוויס המנחיס של תקן 9000-3 150. תקניס אלה הותאמו לדרישות בישראל על ידי מכון התקניס הישראלי ויצאו לאור רשמית, ת''י 9001 150 ו-ת''י 2000-3, בהתאמה. מן הראוי לציין שתקן 9000-3 150 שבו אנו דנים, הינו במהדורת 1991. ועדות התקינה של 180 מכינות מהדורה מעודכנת, שצפוייה לשנת 1998. התקן הישראלי המקביל יעודכן גס הוא וייקרא: ת''י 9000-3 150. חלק שני מתמקד בשלושה רכיביס ראשיים של מערכת ניהול איכות : ניהול פרויקטים, פיתוח תוכנה וניהול האיכות. פרק אחד לכל אחד מנושאיס אלה מזהה את הדיסציפלינות התיוניות ודן בקוויסם המנחיס של תקן 9000-3 150. לפני מתן עצות שימושיות בדבר הדרכים לטיפול בנושאים העיקרייס בסביבה מסורתית, בה תהליך הפיתוח הוא ביסודו רציף, או קווי (ליניארי). פרק 3 בוחן את אופי הסיכוניס שבפיתות תוכנה ומזהה אחדים מהסיכוניסם הראשייםס המשפיעים על פרויקטי פיתוח. הרעיונות הראשיים של ניהול פרויקטיס ותכנון האיכות מתואריס בהקשר של ניהול הסיכונים. פרק 4 מתבונן בתהליך הפיתוח הבסיסי על ידי בחינת מחזור החייס והפעילויות המרכיבות אותו, בעוד פרק 5 בודק את נושאי ניהול האיכות שבתקן 9000-3 150 ומציב אותס בהקשר שלהם עס ארגון לפיתוח תוכנה. פרק זה דן גם בצדדיסם המעשייס ליישוס לב תוכנית האיכות (6ו5/5 ע4111נו 6זס6). חלק שלישי עוסק בשאלת המדידה ושיפור תהליכים, ובו רק פרק אחד, פרק 6. הוא משליס את הצגת הקוויס המנחיס של תקן 9000-3 150 על ידי המחשת מה שאמור להיות רמה מזערית קבילה של המדידה. הוא חוקר את יתרונות השימוש במדידות לשיפור מערכת ניהול האיכות, ומצביע קדימה אל היבט חדש של האיכות, אל מעבר 8 ניהול איכות תוכנת הייייי.....--וווד. בב 7 לתקן 9000-3 150. הצעד הבא הוא טיפול במנגנון לשיפור תהליכיס, שמאפשר לנו להמשליך ולשפר את ביצועי המערכת. חלק רביעי דן בכמה מהכיווניסם החדשיס יותר של טכנולוגיית התוכנה, בהס תהליך הפיתוח הוא לא-קווי (לא-ליניארי), ושוקל אס ובאיזה מידה תקן 9000-3 150 חל על טכנולוגיות אלו. חטכנולוגיות החדשות מציבות תביעות שונות למערכת ניהול איכות, וטכניקות האיכות שפותחו לפי ההנחיות של תקן 9000-3 150 עשויות לא להתאים יותר. ניתן כאן ייעוץ מעשי בנושא ניהול האיכות לגבי טכנולוגיות לא-קוויות אלו. חלק זה מכיל שלושה פרקים: פרק 7 מציג את רעיון אי-הקוויות ומזהה את סוגי השיטות המאמצות את גישת הפיתוח הזו. מוצגת כאן שיטת מדידה של שיטות לא קוויות יחד עס מספר רעיונות בדבר אתגרי האיכות המתייבים טיפול. פרק 8 בוחן את גישות השימוש באבטיפוסים ובעיקר, את קבוצת הגישות שנקראת פיתוח יישומיס מהלר (ות6נתקס[6ש126 מ0סגז1104קק 4 4וסְג334). הוא בוחן את הרציונל שמאחורי שיטות אלו ואת מאפייניהן המעשיים, לפני המעבר לפיתוח מספר עקרונות איכות שעליהם מבוססת אסטרטגיית ניהול האיכות המעשית עבור שיטות אלו. פרק 9 דן בפיתות מוכוון-עצמים, גס כטכנולוגיה חשובה בזכות עצמה וגס כדוגמה לשיטת פיתוח שאינה רק איטרטיבית או רק רציפה, אלא, כפי שמכנים אותה בצדק, שיטת כלאיים. הוא בוחן את סוגיות האיכות המעשיות שבפיתוח כלאיים בכלל, ובפיתוח מוכוון-עצמיס בפרט. חלק חמישי, פרק 10, מאחד את הנושאים שנדונו בחלקיס הקודמים של הספר. כך ניתן להגיע להערכה כוללת של תקן 9000-3 150 ולאומדן תרומתו האפשרית בעתיד, לפני המעבר הלאה, לחיפוש גישת איכות שתתמוך בכל הטכנולוגיות. מהו סוג הגישה לניהול האיכות שיוכל להתאיס לכל השיטות שהצגנו!ּ האם יש קו משותף לכל השיטות מהעבר ומההווה שיוסיף להמשיך ולהתקיים! האם יש עקרונות ניהול איכות נצחייס שיש לנסות להעניק להס מעמד של קדושה?! לקוראי ספר זה אמורה להיות היכרות מעניינת עס פיתוח תוכנה מתוך היבט של ניהול איכות. לא נדרשת התמחות מלוחדת, משוס שהחלק הראשון בספר פותח בהדרכה מספקת בתתוס זה. קוראיס שאינס מכיריס כלל מערכות ניהול איכות, או את נושא פיתוח התוכנה, רצוי שיתחילו בחלק הראשון וימשיכו ברצף לכל אורך הספר. אלה הבקיאיס כבר במערכות ניהול איכות ובתקן 9000-3 150 יכוליס לדלג ללא כל חשש על חלק זה בזמן הקריאה הראשונה ולרפרף על החלק השני. עס זאת, עליהס להיות מודעיס לעובדה שהגישה לאיכות מוגדרת בחלק הראשון. אלה המעוניניס בעיקר בשיטות לפיתוח תוכנה צריכיס להתרכז בפרקים 1, 4, ו- 6 עד 9; לניהול האיכות יש להתרכז בפרקים 1, 2, 5, ו- 6 עד 9; לניהול פרויקטים יש להתרכז בפרקיס 1, 4, ו- 6 עד 9. עס זאת, דבריס אלה נכוניס רק לגבי קריאה בלבד. כוחו של הספר בהיותו יחידה אחת שלמה. בכל חלק של הספר, מוצגיס תחילה הרעיונות בקטע המבוא. הרעיונות נתמכיס ומודגמים במפת תפיסה כללית של הרעיונות ושל הקשריס שביניהס. ממא 19 "'"- הערה: בשל הקושי לתרגם מונחיס מסוימים, תמצא לעיתים מונחים מתורגמים אחרת מאשר אתה מכיר. לדוגמה: המילה 461106זק תורגמה לנוהג, נהגי-, נהגים. הפן הישראלי של תקני האיכות ופעילויות לאיכות לספר שני נספחים : נספח א': ת''י 2000-3 התקן הישראלי ת'ייי 2000-3 מקביל לתקן 9000-3 150 שמוצג בספר. פרט למספר התאמות שנדרשו עבור תנאי הארץ, אין כל הבדל בין התקניסם, וגסם מספרי הסעיפים נשארו ללא שינוי. על כן, הקורא יכול למצוא את דרכו בתקן הישראלי בקלות רבה, בעת הקריאה בספר זה. נספח ב': הפרס הלאומי לאיכות בתעשיה בנספח זה תמצא את עיקרי התקנון למתן הפרס, אשר כולל את מטרות הענקתו, המדדיס ובעיקר את פרטי טופס ההערכה שבו מפורטיס הקריטריוניס לבחינת זכאות לפרס. לפת התפיסה הכללית מפות המציגות את התפיטה הכללית (5קגו 6חוח) הן טכניקה גרפית רבת עוצמה לרישוס מידע בדרך טבעית לחשיבה האנושית. למפות אלו שימושים רבים, אך בספר זה הן משמשות לתיאור תמציתי של הקשרים שבין רעיונות הקשורים זה לזה ומוצגיס בחלקיס שונים של הספר. למפת התפיסה הכללית ארבעה מאפיינים עיקריים : 1. הנושא בו מתרכזת תשומת הלב מגובש בדמות מרכזית אחת. 2. הרעיונות הראשיים של הנושא מסתעפיס מהתמונה המרכזית בצורת ענפים. 3 הענפים מכילים תמונת מפתח, או מילת מפתח, המודפסות על גבי קו הקישור. נושאיס בעלי חשיבות פחותה יותר מיוצגים כענפים הנספחיס אל ענפים של רמה גבוהה יותר. 4. הענפים מהוויס מבנה של צמתים מחוברים. בתרשים 1 מוצגת מפת תפיסה כללית של הספר, כדי להראות כיצד הרעיונות המוצגיס בספר קשורים זה לזה. מפות תפיסה (פקגות 6חווח) דומות מופיעות כמורי דרך בתחילת כל חלק ספר. בספר זה השתמשנו במפות תפיסה כדי להציג קישור של רעיונות הקשורים זה לזה. מפות התפיסה שנמצאות בתחילת כל חלק של הספר מכוונות לשמש רק כנקודת מוצא, שתעודד את הקוראים לחשוב על הקישוריס המוצגיס ולחפש קישוריס חדשים. המפה לא נועדה לשמש כפעלול או כתרגיל אקדמי; אמיתות חשובות רבות מתגלות לעין רק 0 ניהול איכות תוכנה ממרחק מתאיס בו מיטשטשיס הפרטים, והקשריס משתלטיס על התמונה. הסתכלות מרחוק על ציור מעניקה לנו את הרושס שאליו התכוון הצייר; גישה דומה מסייעת לנו לקבל מראה הוליסטי של מה שנראה כמצב מורכב ומבלבל. מפות תפיסה משתמשות בדרך כלל בצבעים, בצורות ובדמויות, כדי להביע רעיונות וקשריס. בספריזה אנו מוגבליס לייצוג בשחור ולבן, ולכן השתמשנו בקוויס מסגנונות שונים כתחליף לצבעיס. דבר זה מקטין ללא ספק את כוח המשיכה ואת היכולת המרשימה של מפת התפיסה בכללותה. אנו מקוויס שהסגנונות השוניסם של הקוויס יהיה בהס כדי להבליט את צירופי הרעיונות השוניס שבמפות. לסגנונות הקוויס אין משמעויות מוגדרות. הס משמשיס רק לזיהוי מה שנמצא בתוך או מחוץ לצירופי רעיונות מסוימיס. עס זאת, ניסינו להשתמש בסגנונות-קו דומים כדי לשקף צירופיס דומיס במפות התפיסה השונות. נקווה שתהנו מקריאת המפות, מהפרשנות ומההרחבה שלהן, וכי נוהל זה יפתח לפניכס מראות חדשים בנוף איכות התוכנה. מפות תפיסה הן שעשוע של ממש וגס :כולות להיות מקור להתבוננות מעמיקה במערכות ובפעולות שעוסקיס בהן. ההשראה למפות התפיסה שבספר זה מקורה בספרו של טוני בוזאן יספר מפת התפיסהי (1990 ,328 - 200% 13 6תו]א 6תד). אלו מפות פשוטות ביותר, וללא ספק ניתן לשפרן. ועוד על מפות התפיסה: בשרטוט מפות תפיסה (825ו 6מווח) משתמשיס בדרך כלל בצבעיס, צורות, תמונות ותבניות שונות כדי לבטא רעיונות או יחסיס. בספר זה השתמשנו בצבע אחד, שחור, ולכן ניצלנו קוויס בסגנונות שוניס, כדי להחליף את אפשרויות הצבע. צריך לשיס לב לכך שסגנון קו מסויס מציין קבוצה של פעולות, או נושאיס בעלי מכנה משותף. מגוא 21 2 ניהול איכות תוכנה תרשיס 1 מפת התפיסה של הספר 6-0 - ₪ - 2-27 5, ו 0 ב = 0 אשיי ל 0% / 5=. לדד0009 790 900000060 השן .8 צר "₪ 5 מל לש = .. ב / 0 9 0 3( וס 2% - / 1 שרה - = "י.. על ו ו ּ. >ר ו , 7" "ה "000% ""-+שס, : % "לאש 0 ₪200 ; *29 . * 6 א 0 ברד וטוא 277 7 ל שי - 7 המיר ו 7 5 9 0 , וא 0 508 יש "יי צווהטס יי 7 ( 7 ל | ] 7 ששרי. וטו % זו ]- חס 0 / | לצסטף/חו1661 7 7 בא) וק 777 ₪" ודהלרד ללה דחואוידי=חדריהר יה / ,,,/ 7 | 3 2" יד 4 א 7 8 - "י - -. וטק / - . ₪ - על % % % אי --.<.ב.- .-. ,| חספה - | הטוחטםההג)א ₪ 5 זל -- וח 4 אחותההןק | 7, / ח ל ק 1 ו מבוא להנדסת איכות תוכנה % מטרת חלק 1 לספק מבוא לעקרונות הבסיסיים של הנדסת איכות תוכנה ולזהות את הרעיונות העיקריים שאנו דניס בהס בספר זה. חלק 1 מחולק לשני פרקים: 0 פרק 1: הנדסת איכות התוכנה 0 פרק 2: מערכות לניהול איכות - מה מטרתן1 בפרק 1 נחקור משמעות המונחים 'תוכנה' ו'הנדסה' לפני שנצרפם יחד כדי לאפיין את הדיסציפלינות של 'הנדסת תוכנה'. אחר כך ננקוט בגישה דומה לגבי המונח 'איכות' ונחקור כיצד הוא מיושם לגבי התוכנה, כדי לאפיין את 'איכות התוכנה/. ולבסוף נצרף את כל הקצוות כדי לזהות מספר אלמנטים עיקריים של הנדסת התוכנה ושל איכות התוכנה, שיש לשקול במסגרת דיסציפלינה לניהול איכות תוכנה. לתוצאה זו נקרא בשם 'הנדסת איכות תוכנה/. בפרק 2 נתבונן בצורה כוללת יותר בניהול האיכות, כדי לזהות את מרכיבי מערכת לניהול האיכות וכיצד משתלבים בה הרכיבים השוניס זה בזה. נציג את דרישות תקן 1 1500 ואת הקווים המנחים של תקן 9000-3 150 כדי לראות כיצד הס מגלמים את עקרונות ניהול האיכות. מבוא קצר זה למסמכי 150 משמש גם כהפנייה לעיון נוסף בקוויס המנחים שבפרקים המאוחרים יותר. לכשתסיים חלק זה של הספר תהיה לך תפיסה מוצקה למדי של היסודות שבבסיסס של הנדסת תוכנה וניהול האיכות, כדי להבין ולהפיק תועלת מהטיפול בנושאי הנדסת איכות התוכנה שנציג בחלקי הספר האחרים. רעיונות המפתח שמוצגים בחלק 1 מתוארים בתרשים ה.1, המציג דוגמה למפת תפיסה כללית. 24 ניהול איכות תוכנה תדשים ח.1 דוגמה למפת תפיסה כללית - - - ל - ₪ % ב 9 -, פוחסואע5 בש שו 2 ססקט | 20 6130568 + , 10005808 " | אט060%%] 7 | 68סו!וטוא 7 הח ב וטק [הטוחטטה ההא 'ח"י=. - ,/ יי / 7 ו 4 ו / = | | / לש "אק | , / 1 ו - וג טסן 7/ ל ב ₪ ב ב % % שש ור 225-ה = מ ב / :0 "₪7 / 4 . - / 2 ₪ 5 ==.. \1 יש 7 לוווטט.. ו | ואט אט[קוטהוזק 30 4 ה "ג צזו ןוטס 4 0 :1 , , 2545 1% 5 . י י 0 י בוו ל ליל ל ל 55 , ל 257 בש 1 בלו אי ;". שחוזשטחופוום + | >ט|קוסחוזע 0 ג פ6קוטחוזץ פכק 1 הנדסת איכות תוכנה מכוא הנדסת איכות תוכנה היא המזיגה הנבונה של העקרונות ההנדסיים, של טכניקות התוכנה ושל שיטות האיכות, המפיקה בעקביות מוצרי איכות בעלויות ובלוחות זמנים סבירים. מציאת היחסים המדויקים של מרכיבי המזיגה היתה מאז ומתמיד יעד מבוקש של מהנדסי התוכנה ושל המשתמשים במוצרי תוכנה. אם יש ברצוננו להפליג במסע חיפוש אחר יעד זה, עלינו להבין שני דברים חשובים: כיצד נבחין ביעד לכשנגיע אליו, ומהו הכיוון בו נפתח בחיפוש זה? הגישה שננקוט לגבי שאלות אלו היא שתגדיר את הערכים שאנו עוסקים בהם, ותיתן לנו מפת דרכים עבור המסע - ועבור ספר זה. תוכנה, איכות והנדסה הצירוף של שלוש מילים אלו - תוכנה, איכות והנדסה - רווי כולו באי הבנות פוטנציאליות. מיליס אלו, על אף היותן מושרשות כבר בשפת היומיוס שלנו, מעוררות אוסף רחב ומגוון מאוד של רעיונות, ואף פעס אין ביטחון באיזה מהפירושים הרביס אנו משתמשים כאשר אנו מנסיס לתקשר עס הזולת, גס אס הוא חבר למקצוע. אין כוונתנו ליצור בספר זה אוצר מיליס בעלות מובן חד-משמעי. עס זאת, יש צורך להגיע להסכמה בדבר תמצית הרעיונות המסתתרים מאחרי שלוש מילות המפתת יתוכנהי, יאיכותי ויהנדסהי. נקדיש מאמץ מסויס להסברת מילים אלו, כדי שנוכל לבנות סביבן מסגרת רעיונית. נעשה זאת בגישה שתמחיש באמצעות דוגמאות והשוואות, את שיש ברצוננו להביע. התוכ(ה מהי מבין שלוש המיליס הנזכרות, השס תוכנה הוא הפחות צפוי לאי הבנות. קל להגדיר אותו במיליס אלו, למשל: יהדבר שמקנה למערכת מחשב את ההתנהגות האופיינית להי. זהו צירוף מיליס חופשי מדי מכדי שיוכל לשמש כהגדרה, אך כוללני במידה מספקת שמאפשר גיוון מסויס. ניסות זה למשל, יכול לאפשר את הכללת השימוש פדק 1: הנדסת איכות תוכנה | 25 בחבילות סטנדרטיות, בצד פיתות יישומיס מורכביס המשתמשיס בארכיטקטורות מחשביס המיועדות למטרות ספציפיות מאוד. הבעיות הנלוות לתוכנה, כגון אמינות נמוכה, חוסר גמישות ועלויות פיתוח חריגות, חלות על כל הרמות ועל כל סוגי התוכנה. בין אס נתחיל לעצב תוכנה מנקודת האפס, נתחזק תוכנה קיימת, נתאים חבילות תוכנה לצרכינו, נבחר ונתקין חבילות סטנדרטיות, או פשוט ננסה לנצל בדרכיס חדשות את מערכות המחשבים הקיימות מבלי לכתוב תוכניות כלל. בכל המצביס האלה נימֶצא ביעולס התוכנה' ונהיה כפופיס לתרבות הייחודית לה. בהקשריס שבספר זה, כל פעילות המיועדת להשיג תוצאה מסוימת על ידי השימוש במחשב כחלק מתהליך כלשהו, נחשבת כפעילות של תוכנה. האיכות מֶהי ידועים הקשייס הרביס שבהגדרת איכות. בדומה ליופי, האיכות נמצאת בדרך כלל יבעיני המתבונןי, ובדרך כלל אנו מתפשריס על אמירות מפוקפקות, כגון יכאשר אראה אותה, אבחין בהי. אמירות מסוג זה עשויות להכיל מידת מה של אמת, אך אין בהן כדי לספק קו מנחה למי שמנסה ליצור מוצריס שיענו דרך קבע על ציפיותינו. גם אס יש פגמיס בנסיונות שלנו לאפיין את האיכות, חייבת להיות לנו מטרה כלשהי שנוכל לשאוף אליה. בסביבה עסקית, האיכות מתבטאת במשמעות פורמלית שאפשר להביעה בקבוצה מגובשת של דרישות שיסופקו במועד מאוחר יותר, ושאפשר יהיה למדוד אותן, כך שנוכל להיות בטוחיס באמת, שאכן סופקו לנו הדרישות שהצגנו. בעולם המושלם, כולם יראו את אותו דבר בעת שיחשבו על 'איכותי; הם יראו את אותו הדבר לפני חתימת החוזה וגם לאחר אספקת נשוא החוזה. קאמרון לאו (1993 ,/50). אם כן, כיצד נגדיר את 'איכותי: נצטט רק שלוש מתוך ההגדרות היותר ימכובדותי, שהושמעו בעבר, כגון יהתאמה למטרהי, יתאימות לדרישות' וידרגת המצוינות'. אף לא אחת מהן נכונה באופן בלעדי. אף אחת מהן גס אינה הולמת בשלמות את הנושא, וכולן יחד אקדמיות במידה רבה. בפועל, אם ברצוננו לשרוד בעולס העסקים, כל מה שחשוב לנו, היא השאלה אס הלקוח אמנם שבע רצון, או אפילו מאושר מהתוצאות. עלינו לוודא שאנו מתמקדים כל הזמן במשאלות ובצרכיס של הלקוח, בין אס הוגדרו במלואס ובבהירות במפרט מתאים של הצרכים, ובין אם לאו. גישה שיטתית לאספקת איכות מחייבת בהכרת יצירת הגדרה מוסכמת של הדרישות, ואחר כך, אישוש העובדה שהמוצרים אכן תואמים דרישות אלו. בהנחה שאין ביכולתנו להגדיר כבר מלכתחילה בצורה ברורה וחד-משמעית את מה שאנו רוציס, עלינו לוודא יכולת של מתן ביטוי לשינוייס ולהתפתחויות כדי שנוכל להוסיף וללמוד את הצרכים, תוך כדי התקדמות התְיכגּן, ולשנות את מוצרינו כפי שיידרש, כתוצאה מהבנתנו המחודשת את הצרכיס האלה. 6 ניהול איכות תוכנה בספר זה, המונת יאיכותי ישמש במשמעות של השגת ישביעות הרצון של הלקוחי. דבר זה פירושו אספקת מוצרים שיענו במועד מוסכס על קבוצה מוגדרת ומוסכמת של דרישות. תוך מתן ביטוי להתפתחות מתמשכת של דרישות אלו. הדרישות עשויות לכלול גס צרכיס פונקציונליים (מה חייב המוצר לבצע) וגס צרכיס לא-פונקציונליים (כיצד חייב המוצר להתנהג). מה ההקשר של הה(דסה לכאן לא לכל תוכנה יש קשר להנדסה, כשס שגס המושג יאיכות' אינו שמור למהנדסיס בלבד. מדוע אס כן, מוקדשיס כל כך הרבה ספריס לנושא יהנדסת תוכנהי ומדוע מתוארות טכניקות האיכות לעיתיס כה תכופות בהקשר של ההנדסה! הסיבה היא שהדיסציפלינה (6מ11ק41561) של ההנדסה היא כה מוצלחת בתחומה, עד שגס אחרים ניסו ללכוד את תמצית הדיסציפלינה הזו ולהשתמש בה כמודל לפיתוח שיטות, נהליס ומשמעת עבודה, שיהיו מוצלחיס גס בתחומי התמחות אחריס. מה שאנו מביניס היוס תחת השס דיסציפלינה הנדסית, הלך והתפתח במרוצת מאות השניסם, והיוס אפשר לראות בו מכשיר אמין ועקבי לבניית כליס ומערכווז, הבאיס לענות על צורכי אנוש. יש תחומים, כגון בניין אוניות והנדסה אזרחית, שהפכו לשגרתייס יחסית, אף שלעיתיס תכופות הס עוסקיס בבעיות קשות ומורכבות מאוד. המהנדסים פיתחתו מספר עקרונות בסיסייס המשמשיסם אותס נאמנה כבר דורות רביסם. כדאי לנו להקדיש מאמצ מסויס ולהתבונן באחדיס מעקרונות אלה. שמונה עקרונות הנדסיים חשובים 1. תכנן לפני שאתה בונה המהנדסיס יודעיס שמשתלס לתכנן את הדרך בה אתה מתכונן לבנות דבר מה, לפני שאתה חותך את החומר ממנו תבנה את המוצר; אחרת, אתה צפוי לבזבוז רב בשל התחלות מוטעות, ואיכות המוצר תשקף בוודאי את הגישה האקראית של הבנייה. התפיסה של הגדרת תהליך הפיתוח ותיעודו מבוססת על גישה זו. המתודולוגיה של התִיכוּן מספקת מבנה של תכנון מפורט יחד עס מוצרים מוגמרים (8611/6180165) מוגדריס היטב בכל שלב, וזיהוי הנקודות בהן יש לקייס ביקורות, כדי לוודא שהתָּיכוּן מתבצע בהתאס לתוכנית. 2. וודא שהחלקים יתאימו זה לזת המהנדסיס יודעיס שהדרך היחידה בה ניתן להשיג תאימות בין חלקיס המיוצריס בזמניס ומקומות שוניס, היא על ידי הסכמה על דרך סטנדרטית לתיאור החלקיס האלה, ועל ידי שימוש בכלים ובמכונות שיכולים לפעול במידת הדיוק הנדרשת. כך יהיה ביכולתס לוודא שהחלקיס יתאימו זה לזה כאשר יצרפו אותס יחד. פרק 1: הנדסת איכות תוכנה | 27 א 28 תכנן את המבחנים לפני הבניית המהנדס המגדיר את החלקים שייוצרו עבור העבודה המסוימת חייב גם להחליט על הדרך שבה ייבדקו וייבחנו החלקיס המיוצריס; אחרת, קיימת סכנה שהבדלים בייצור יתבטאו בחלקיס שאינס מתאימים זה לזה, או שדרך פעולתם לא תהיה תקינה. דרישות אלו של הבדיקות והניסויים חייבות להיות מוגדרות מלכתחילה בצורה שתבהיר במפורש ומראש מהו הדבר שנדרש, תאפשר את השימוש בדרישות לבקרה של תהליך הייצור, ותמנע את הבעיות שהן אמורות לחשוף לאחר גמר הייצור. בדוק את התִיכוּן לפני כניסה למחויבות ייצור על פי שרטוטיס יש בו כדי לוודא את העקביות, אך לא את הנכונות, אלא אס כן נבדקו תחילה השרטוטים עצמם ונמצאו נכוניס. מסיבה זו, שרטוטי התֶּיכוּן הראשוני מאומתיס בדרך כלל על ידי המעצב, כדי לוודא שלא השתרבבו שגיאות תוך כדי פעולת השרטוט עצמה, וכדי לערוך בדיקה סופית שמטרתה לוודא שהתָּיכוּן עצמו הוא אמנס נכון. דאג לקיים בקרה מתמדת על הכנסת שינויים בתיכון משעה שהשרטוטים מועבריס אל פסי הייצור, חשוב לקייס בקרה קפדנית על כל השינוייס המתבצעיס בשרטוטים. כל שינוי שלא אושר על ידי המעצב עלול לפגוס בתקפות של התָיכוּן כולו, ובוודאי גם לגרוס לאובדן מחזור ייצור שלס. כל שינוי שאינו חייב להיעשות על ידי המעצב עצמו, צריך להישקל בזהירות ולהיות נתון לבקרה שתוודא את צמצום ההשפעה על הייצור עד למינימוםס. כל השינוייס חייבים להשתקף גם בדרישות הבדיקות והניסויים, משוס שאחרת, הניסויים לא יהיו אפקטיביים. וודא שאתה אכן מספק את האיכות הנכונה משעה שמתחילים בייצור, חיוני לוודא שכל הרכיביס המיוצריס (או לפחות מדגס של מוצרים אלה) תואמיס את המפרטים, וכי תהליך הייצור אינו תורס באופן שיטתי לשגיאות ייצור כלשהן. בקרת האיכות ([סזוחסס עזו|4טף) ואבטחת האיכות (8000ז8550 /זו|4טוף) מספקות שירותיס קריטיים אלה. למד משגיאותיך והשתפר בפעם הבאה השימוש במידע סטטיסטי המתייחס למוצריס ולתהליכי הייצור, מאפשר את צמצוס הבזבוז ומשפר את התהליכים להגדלת היעילות ושביעות הרצון של הלקוחות. בארגוניס רבים, איסוף נתוניס מקווי הייצור, ממחלקות התכנון והתָיכוּן, משירותי התמיכה ללקוחות ומדומיהם, מהווה חלק מתהליך הפעילות השגרתית. רבות מההחלטות המסחריות מותנות באספקה במועד הנכון של נתוניס מדויקיס בדבר איכות המוצר והתהליכים. דע לאן אתה הולך אי אפשר להגזים בתיאור החשיבות והמשמעות של פעולה על פי אסטרטגיה כוללת, המבוססת על יעדים ברורים. חברות מצליחות הן חברות ששמות להן למטרה להשיג יעדיס ספציפיים ורותמות את משאביהן בצורה אפקטיבית להשגת ניהול איכות תוכנה יעדיסם אלה. האסטרטגיה הכוללת הזו אמורה להכיל הגדרה ברורה של יחס החברה ומחויבותה לאיכות. דבר זה חיוני לניהול הטוב, משוס שהייצור של מוצרי איכות ייראה תמיד כאילו הוא יקר יותר, ורק מחויבות אמיתית לאיכות תמנע קיצוצ בעלויות שיהיה גס מלווה בפגיעה באיכות. אס האיכות היא אמנס מרכיב יסודי בתדמית החברה, יש לשקוד על כך שתהיה לנחלת הכלל ותהנה מפרופיל גבוה בחברה. הגנדסת תוכ(ה האס נוכל לרתוס עקרונות מנחיס אלה שמתחוס ההנדסה בצורה שתוכל לשרת אותנו גם בתחוס פיתוח התוכנה! הנדסת התוכנה (עז66חו(ח6 6ז8ש:/50) היא לפחות ניסיון בכיוון זה. ההגדרה המוקדמת ביותר להנדסת התוכנה ניתנה כנראה על ידי פרופסור פריץ באואר בשנת 1969 : מיסוד ושימוש בעקרונות סבירים של ההנדסה כדי להשיג בדרך כלכלית תוכנה, שהיא אמינה זפועלת ביעילות במחשבים אמיתיים. הדיסציפלינה ההנדסית סיפקה בשעתה מודל אפשרי יחיד שעליו ניתן היה לבסס את הגישה המקצועית לפיתוח תוכנה, והכותרת 'הנדסת תוכנה' העניקה מידה מסוימת של מכובדות למה שהיה באותה עת אוסף אקראי של רעיונות השוניס זה מזה, המדבריס על הדרך בה יש לבצע את פיתוח התוכנה. בתקופה שחלפה מאז, הלכה ובשלה הדיסציפלינה החדשה ויישומיס חדשיס הופיעו ועלו במגוון רחב של תחומיס. במקביל, גדל גסם מספר מפתחי היישומים בעלי רקע שאינו דווקא מתחוס ההנדסה, ואלה עסקו בבניית מערכות שהקשר שלהן אל ההנדסה היה מצומצם, או כלל לא קיים. כתוצאה מכך, ייתכן שהתואר יהנדסת תוכנהי פגע אולי במספר לא מבוטל של מפתחי תוכנה מקצועיים, אך עס זאת הפך להיות חלק בלתי נפרד מתרבות התוכנה. ההגדרה של פרופסור באואר אינה בשוס מקרה ההגדרה היחידה שהוצעה לציבור, אך היא שימשה כנקודת מוצא נוחה, ואין ספק שהיא מכילה מספר אלמנטיס עיקרייס שלא הוצבו יחד קודס לכן. השימוש בביטוי "(עקרונות הנדטה סבירים! (169ק61חוזק 8ַת1ז66ה1פת6 6תט50) בהגדרה דלעיל, מדגיש את הכוונה לפעול לפי הדמייה של הגישה ההנדסית, אס כי לא ברור כיצד יושג הדבר בפועל. יש מקום לכך שנעניק לביטוי זה את המשמעות הבאה: מיסוד דיסציפלינה הנדסית סבירה ומוסכמת, בצירוף עס קבוצת רעיונות בסיסייס על האופי של פיתוח התוכנה. ניסוח זה מרמז למשל, על הסכמה בדבר מודליס של מחזור חיים (6615סוח 6616 1:16) ומתודולוגיות מתאימות. מילות מפתח אחרות הכלולות בהגדרה - משקית, אמינה, ופועלת ביעילות - ממחישות את הדאגה להיבטיס הבלתי-פונקציונלייס של מוצרי התוכנה וגם לדרישות הפונקציונליות. בהתחשב במהירויות ובעוצמות החישוב הכמעט בלתי מוגבלות של פרק 1: הנדסת איכות תוכנה | 29 ----=- ימינו, עשויה היעילות שלא להיות נושא לדאגה כה מקיפה, אך העיקרון של זיהוי , תכונות (165טפ/4//7) רצויות ובניית מוצרים שיספקו אותן, ממשיך להיות עיקרון בעל ערך רב. מה שהגדרה זו אינה מספקת, הוא התהליך באמצעותו ניתן להשיג את התכונות הרצויות. המשימה שלנו בספר זה היא להגדיר את תהליך הפיתוח בצורה שניתן יהיה ליישמו בצורה שימושית בארגוניס גדולים וקטניס, ויאפשר לנו להפיק מוצריס בעלי איכות מוגדרת העוניס על צורכי הלקותות. נקודה נוספת מתוך ההגדרה, שחשוב לציינה, היא הדגש על השימוש במילים יכדי להפיקי ולא במיליס ילעצב, לתכנת, או לבנות מערכותי. הנדסת תוכנה פירושה *ותר מאשר רק כישורים טכניים. ההגדרה מכירה בכך שהנדסת תוכנה היא דיסציפלינה שחייבת להקיף את כל הפעילויות התיוניות, המוודאות שהלקוחות יקבלו מערכות שעונות על צורכיהם. עיון חוזר בעקרונות ההנדסייס שתוארו לעיל יסייע לנו לזהות אחדות מהפעללויות החיוניות. ןוו שמונת העקרונות של הנדסת התוכנה [. הגדר את מחזור החיים של פיתוח תוכנה (תכנן לפני שאתה בונה) מהנדסי תוכנה זקוקים להגדרה של מחזור החיים של הפיתות (16] זהסוהקס[66/6 86) כדי שיוכלו לדעת באיזה סדר לבצע את הדברים, וכדי שיוכלו לתקשר עס הזולת בכל הנוגע לתהליך ולהכניס בו התאמות במקרה הצורך. מתודולוגיית פיתוח מעדנת את התהליך המבוסס על מחזור חיים, כדי לסייע בתכנון וכדי לספק מסגרת לשיטות תָּיכוּן ולשיטות רישוס נתונים. תן פירוט של הממשקים (וודא שהחלקים יתאימו זה לזה) ₪ מהנדסי תוכנה זקוקים להגדרות מדויקות של מה שצריך לבנות, הגדרות שתינתנה בצורת מפרטים. דבר זה חשוב במיוחד כאשר רכיבי תוכנה חייביס לפעול ביחד. הגדרה זהירה של הממשקים שבין רכיבי התוכנה יש בה כדי לוודא שהרכיביס יתאימו זה לזה בצורה נכונה, וגם כדי לאפשר את בניית הרכיבים על ידי עובדיס שוניס בצוות. כלים התומכיס בתהליך הבנייה מסייעים לצמצוס הסיכוייס לטעויות בממשקים. 3 תכנן מראש את הבדיקות (תכנן את המבחנים לפני הבנייה) תכנון הבדיקות (1658) ומפרטי הניסוי קובעיס את הדרישות לביקורת עוד לפני הייצור. על ידי כך ניתן לוודא תשתית אובייקטיבית לבדיקות, שתהיה מבוססת על הדרישות ותספק בסיס לביקורות תוך כדי התהליך, ובכלל זה בדיקות של רכיבי התָּיכוּן ההולך ומתגבש. 4. בחן מחדש את התיכוּן (בדוק את התיכון לפני כניסה למחויבות) בחינה חוזרת של התְיכוּן (ח66518) היא שיטה לאימות התָיכוּן שיש בה כדי לוודא עוד לפני התחלת יהייצורי, שלא השתרבבו שגיאות לתוך התְיכוּן. 0 ניהול איכות תוכנה נהל את התצורה (דאג לבקרה מתמדת על הכנטת שינויים בתיכון) לגבי מהנדס מערכות, ניהול התצורה (תסוגזטפו)תס6) הוא המקבילה של בקרת השרטוט; עס זאת, בתחוס התוכנה, הקלות היחסית בה ניתן לשנות את המוצרים, מגבירה עוד יותר את החשיבות של שימת דגש על משמעת ניהול השינוייס. נהל את האיכות (וודא שאתה אכן מספק את האיכות הנכונה) האופי של רוב מוצרי התוכנה, שהס בלתי נראיס לעין ובלתי מוחשיים, מקנה חשיבות רבה ביותר למתן שירותי בקרת איכות ואבטחת האיכות, ומקשה על מתן שירותיס אלה. בדיסציפלינה שמבוססת במידה רבה ביותר על שיטה מכוונת - תיכוּן (160ח16ז665180-0), ובעלת שלב ייצור טריוויאלי, אימות התְיכוּן חשוב במיוחד והביקורת של המוצריס הפיסייס הנמסרים ללקות (6:80165ש8611) אין בה תועלת רבה. הנדסת תוכנה עוסקת הרבה *ותר בפונקציה (כלומר בביצועיס) מאשר בצורה. מדוד את המוצרים והתהליכים (למד משגיאותיך והשתפר בפעם הבאה) השיטה למדידת התוכנה נמצאת עדיין בחיתוליה, אך יש צורך לפתח אותה, כדי לספק תמיכה למנהליסם האחראיס להעשרת תהליך פיתוח התוכנה. הגדר את מדיניות האיכות (דע לאן אתה הולך) לגבי מפתחי התוכנה, היכולת לספק מוצרים בעלי איכות הנראית לעין, היא עתה משימה בעלת חשיבות ראשונה במעלה. האמון במוצרי תוכנה נמצא היוס בשפל, וזאת דווקא בשעה בה מוצרי התוכנה משפיעיס במידה גדלה והולכת על חיי היומיוס של הציבור הרחב. תחומי יישוס חדשיסם צצים ועולים מדי יוס. עימס גדל גם הצורך בהקמת מנגנון אמין, שבאמצעותו ניתן יהיה לנהל את איכות המוצר, כדי לעמוד באתגר של הצורך באמון רב יותר. ןו דגש זה על התהליך של פיתוח התוכנה חודר בהדרגה לתודעה של תעשיית התוכנה. היו כבר בעבר התחלות שנכשלו או שהסתיימו במבוי סתוס, אך החיפוש אחר תוכנה איכותית בעלת רמה, הוליך את מהנדסי התוכנה להתמקד פחות במחשבים ויותר בטכנולוגיה שבאמצעותה נעשה שימוש במחשביסם. לטכנולוגיה זו מספר צרכיס בסיסייס : אמצעיס שיאפשרו את התקשורת עס המחשביס באמצעות שפות התכנות ; שיטות וכלים לתָיכוּן, והתודעה שמקוס התכנות אינו בתחילת הדרך, אלא דווקא אי-שס קרוב לסוף; ההגדרה של המונתח מחזורי חיים של הפיתות שממקמת את כל הפעילויות הרלבנטיות, מהתפיסה הראשונית עד לסיום הסופי, בסדר לוגי. זיהוי המתודולוגיות של הפיתוח כדרך שתשמש להגדרת השלבים ושל הפריטים הנמסריט (66|1/6:80165), שיש לאמצה במסגרת מחזור חיים נתון; ההכרה בכך שמערכות תוכנה חיות בתוך סביבה המשפיעה על הדרישות הספציפיות של המשתמש, ועל התרבות בה ייושמו וייעשה בהן שימוש. פרק 1: הנדסת איכות תוכנה | 31 -.שששת הווה הנדסת התוכנה מספקת את הבסיס לתהליך פיתוח התוכנה. היא מתמקדת באספקת מוצריס שעונים על דרישות מוגדרות, כולל דרישות לאיכות, והיא מביאה בחשבון את מחזור החייס השלס של הפיתות. אך כיצד נגדיר את הדרישות לאיכות התוכנה! איכות תוכ(ה אס האיכות משמעותה שביעות רצון של הלקוח, כיצד נוודא שאנו אמנס משיגיס אותה: לקוחות בסופו של דבר הס רק בני אנוש, ומסוגליס לשנות את דעתם, או אפילו לא לדעת מה הס בדיוק רוצים. מהר מאוד ניווכח לדעת ששינוייס הס חלק מכל תהליך פיתוח תוכנה, ואס ננהג בחכמה, נלמד להיענות לשינוייס אלה. יחד עס זאת, יהיה זה מסוכן מאוד לפתוח בפרויקט כלשהו, מבלי שתהיה לפנינו נקודת מוצא ברורה. כבר מההתחלה חייב להיות לנו רישוס של מה שהלקות חושב שהוא רוצה בשלב זה, גסם אס רצון זה אינו מלא, אינו נכון או אפילו בלתי ניתן להשגה; שאס לא כן, לא יהיה לנו קו מוצא בסיסי, שבו צריך יהיה להכניס את השינויים במועד מאוחר יותר. הגדרת דרישות הלקוח, כולל התכונות המופיעות תחת הכותרת 'איכותי, היא המוצר התיונ?ל הראשון של כל פרויקט תוכנה. הגדות דוישות מה צריכות הדרישות לכלול: נעשו מספר נסיונות להגדיר קבוצה אובייקטיבית של קריטריונים לאיכות, אך אף אחד מאלה לא הביא פתרון קבע לבעיה. מבחינה מסוימת, אין גס סיכוי למצוא פתרון כזה, משוס שאין בפתרון זה כדי לוודא שהלקוח אכן התייחס כבר במועד מסויס להיבטים שהס קריטיים ליישוס מסויס. 'מוצר איכות* מבצע את רוב הדברים שאנו רוצים שיבצע, וגם נוכל להשלים עם הפגמים שקיימים בו. פאול הרצליך (1993 ,5021) הקריטיות היא הציר המרכזי של נושא האיכות. הלקוחות עשויים שלא להבין את כל המשמעויות של הדרישות העסקיות שלהם, אבל עליהס להחליט מהס האלמנטים שחיוניותם מוחלטת. מהס הגורמים הקריטיים להצלחתו של הפרויקט הזה! אס נצליח ללכוד את הנתונים האלה בצורה כמותית - למשל, בצורת קבוצה של גורמי הצלחה קריטיים - יעמוד לרשותנו בסיס ממשי שנוכל לשפוט באמצעותו אס אכן אנו בוניס את מה שהלקוח באמת מעוניין בו. השגת איכות התוכ(ה נאמר כבר שהשגת האיכות פירושה ייצירת תוכנה שלא תחזור אליך, עבור לקוחות שכן יחזרו אליךי, ובכל הנוגע למטרות ספר זה, הגדרה זו יכולה בהחלט לענות על הצרכים. כשלרשותנו הגדרה פרגמטית של האיכות, המלווה בגישה מציאותית אל דרישות 2 ניהול איכות תוכנה האיכות, כל מה שנדרש לנו הוא תהליך שבאמצעותו ניתן להשיג את דרישות האיכות האלו בצורה אמינה ועקבית. כיצד ייראה התהליך הזה? הדיון שלעיל מרמז על כך שהתהליך שבאמצעותו אנו מספקיס את האיכות צריך להיות מבוסס על הדיסציפלינה של הנדסת התוכנה, אך האס עלינו להמשיך גס הלאה בתהליך זה! האס יש ביכולתנו להגדיר תהליך כוללני שיפיק איכות בצורה שיטתית, ושיגלס בתוכו את שמונת העקרונות ההנדסייס בצורה שלא תרחיק ממנו את עובד הפיתוח שאינו בעל רקע הנדסי: בפרק 4 נדון ביתר הרחבה בתהליך הפיתוח הבסיסי. תהליכי איכות מהו תהליך איכות! לצורך הדיון שלנו, תהליך איכות (655ססזק עזו!ג4טוף) הוא תהליך המכיל שלושה מרכיביס : > אנו יודעיס מה נדרש מהתהליך; > אנו יודעיס כיצד הוא פועל; = אנו יודעיס כיצד לתקן או לשפר אותו. התייחסנו כבר לקריטריון הראשון. ההתייחסות לקריטריון השני נדונה כבר חלקית כשעסקנו בטכניקות הנדסת תוכנה. עלינו לבחור שיטות ספציפיות ולתאר את הדרך בה הן פועלות, כדי שנוכל לשנותן ללא סיכון, במקרה שיתברר שהן אינן עונות בדיוק על הצרכיס שלנו. בדיון על עקרונות ההנדסה, נגענו בתחוס אבטחת האיכות (06ח8זט855 עזו(טף). רכיב זה הוא שמוסיף את המנגנון של תיקון-עצמי ושיפורים, ולכן עלינו להוסיף אותו לדיסציפלינת הנדסת התוכנה שלנו, כדי להגיע לשיטה של הנדסת איכות תוכנה. תחוס זה לא נדון עדיין במלואו, ונשוב אליו ביתר פירוט בפרק 5. לאחר צירוף כל שלושת המרכיביס האלה, אמורה לעמוד לרשותנו קבוצת תהליכי איכות שנצמדיס לשמונת העקרונות ההנדסיים. הס ישקפו את הנוהג הטוב ביותר בענף התוכנה, ויספקו את האמצעים לתחזוקתם ולשיפורם העצמי. אוסף כזה של תהליכי איכות קרוי בשס מערכת לניהול איכות (וח5/516 זה6וח46תגוח עזו!4טף). תקני מערכת לניהול איכות, כדוגמת התקנים הכלולים במשפחת 9000 150, מנסים ללכוד את הנוהג הטוב ביותר, בעיקר מתעשיית הייצור. אלה מספקיס את המסגרת שבתוכה ניתן לשבץ דיסציפלינות כמו הנדסת תוכנה (8ַח[ז66ח81ח6 6ז8או501). תהליכי ה(דסת תוכג(ה מהו הדבר שאמנס מייחד את תהליך הנדסת התוכנה!: מבחינות מסוימות אין זה אלא מקרה פרטי של תהליך הנדסי כלשהו, אלא שהוא כולל כמה היבטים ייחודיים, ועלינו לוודא שאנו מביאים אותס בחשבון במלואם, בשעה שאנו מתאריסם את התהליך ומבקשיס לשלוט בו. פרק 1: הנדסת איכות תוכנה | 33 מהו הדבר שמייחד את הנדסת התוכנה [. סביר להנית, שהמאפיין המשמעותי ביותר של פיתוח תוכנה, היא כמות האיטרציות הכלולות בתהליך. כל תיכון כולל בתוכו איטרציות, אלא שהנדסת התוכנה מתבצעת בדרך כלל בהקשר של מורכבות ואי-ודאות בדבר הדרישות האמיתיות. כתוצאה מגורמיס אלה ומחוסר הבשלות היחסי של שיטות תִיכוּן התוכנה, חשופה פעילות התיכון לטעויות, והיא צפויה לכמות רבה ביותר של שינוייס. לכן חייב תהליך התיכון להכיר במשמעות הנובעת מהאיטרציות. 2. לפיתוח התוכנה יש מוניטין של אי עמידה בתקציב ובלוח הזמניס. הסיבות לכך אינן פשוטות, אלא שהתחושה של ביצועים גרועים בכל הנוגע לניהול פרויקטיס מחוללת לח להוספת שיפורים. תהליך הנדסת התוכנה חייב להיבנות בצורה שאפשר יהיה לבנות דיסציפלינה של ניהול פרויקט-תוכנה שתהיה מבוססת על התהליך ותוכל לנהלו ביעילות. 3 תהליך הנדסת התוכנה חייב להביא בחשבון את כל הפעילויות הכרוכות באספקה של תוכנה יאיכותיתי, החל בהעלאת הדרישות ההתחלתיות דרך האספקה ללקוח, קבלה על ידו, ומשם גם לתחזוקה. קרוב ל- 80 אחוז מההשקעה של המשאביס במוצר תוכנה מתבצעיס רק לאחר הקבלה הראשונית של מוצר התוכנה על ידי הלקות, ומשוס כך עלינו להביא בתשבון את התהליך כולו ובשלמותו. נקודת המבט הזאת של תהליך הנדסת התוכנה נקראת בשס מחזור חיים (616ע6 116). 2 = ווה כתוצאה מהאמור לעיל, אנו יכוליס לקבוע שהנדסת התוכנה מחייבת הגדרת מודל של מחזור חייס איטרטיבי, הכולל מידה מספקת של פירוט שתאפשר למנהלי פרויקטיס לבנות וגם לבצע תוכניות מציאותיות. מודליפ הטבוססיפ על מחזור חיים מודל המבוסס על מחזור חיים הוא בפשטות תיאור לתהליך שלס של פיתוח ואספקת תוכנה. מודלים של מחזור חיים מוצגים בדרך כלל בצורה גרפית. קיימיס מודליס יסטנדרטייסי אחדים שמשמשים לאפיון גישות שונות לנושא פיתוח התוכנה, ומאפשריס את הדיון ביתרונות ובמגבלות שלהס. מודל מחזור החיים ([006 6616 116) המוקדס יותר וכנראה גם הידוע ביותר הוא מודל-מפל-המים, המוצג בתרשים 1.1. המגבלה הראשית של מפל המים היא בהיותו בעל אופי עוקב, סדרתי, שמשאיר את הבדיקות לשלב מאוחר בחיי הפרויקט, כאשר תיקון השגיאות יהיה יקר וגוזל זמן. שינוייס שונים במודל מפל המים ניסו להדגיש את האופי האיטרטיבי של פיתוח התוכנה, אלא שהרעיון הבסיסי של פאזה אחת הזורמת לתוך הפאזה שלאחריה מרמז על רציפות ופעולות סדרתיות, או קוויות (לינאריות). 4 ניהול איכות תוכנה = וויק -ונו ריוור . 5חטוח6זוטסטת צנ [תס!וז6תט] חסן10 5601 תדשים 1.1 מחזור החייסם של מפכ המים 5ח6וח6זוט6ת 5 . ןווס [4תסוזסתט] חסו631ו]וסטק5 הסוז6]וזש/ חג1ק 1651 006018800 הסוו6 וז 6 הו מסו60 וזש תרשיס 1.2 מחזור התיים שבסגטון ץ פרק 1: המדסת איכות תוכנת | 35 "------/-% השינוייס המשמעותייס ביותר שהונהגו במפל המיס יצרו מחזור חיים בסגנון ץצ (016ע6 116 ץצ). תרשים זה מציג מחדש את הרצף של מפל המים בצורה שמדגישה את הקשר שבין השלבים המוקדמיס והמאוחרים של הפרויקט, ומפנה את תשומת הלב להזדמנות לתכנן ולהגדיר בדיקות בשלב מוקדס. תרשים 1.2 מציג את מחזור החיים שבסגנון צ, המשמעויות של מודל זה נדונות בפרקים 3 ו- 4. היתרונות שבגישה זו טמוניס בחלקם בכך שמשיגים אובייקטיביות רבה יותר בבדיקות, ובחלקס בכך שמשתמשיס בתהליך פיתוח הבדיקות, כדי למצוא ולסלק שגיאות בדרישות, במפרטיס ובמסמכי התָּיכוּן של הדרג הגבוה. על אף היותו צעד נכבד קדימה אל מעבר למודל מפל המים, ממשיך מודל ‏ להיות סדרתי, או קווי ביסודו, והדגש מושם בו על גישה של שלב אחר שלב. מחזור החייס בסגנון % סייע בהדגשת המשמעות של האימות וגם של בדיקת התקפות במאמציס להשגת מוצרי איכות; מודל פשוט של האימות (תסו)868וז6) ובדיקת התקפות (ח0סןז81/68ץ) ניתן ליישס לגבי כל מוצר מוגמר, כלומר, לגבי הפלט המתקבל מכל שלב של מחזור החיים. המודל הרדיקלי יותר שבין המודליס של מפל המים וסגנון היה מודל החילזון ([006ח |4זוק5), שניסה לאפיין את האופי האיטרטיבי וההתפתחותי של פיתוח התוכנה. מעצס טבעו, מודל התילזון קשה יותר לניהול מאשר מחזורי החיים הקווייס, אך עם זאת אפשר לטעון שיש בו אפיון מדויק יותר של התהליך. מודל החילזון מוצג בתרשיס 1.3. מודל זה זכה להתעניינות מחודשת עס התפתחותן המהירה של הגישות ליצירת אבטיפוסים, שיידונו בהרחבה רבה יותר בפרק 8. צטטווסטןס שחוו501 פופץ[ח3 אפום סז חסןזבזהטוחטקוח] פחוחחגן? תרשים 1.3 מחזור החיים במודל התילזון (הספירלי) חשוב להדגיש בשלב זה שאין יתרון בשימוש במודל מסויס כלשהו של מחזור החיים. כל אחד מהמודלים היסטנדרטייםי הוא לא פחות יטובי מהמודל האחר, ורבים ממפתחי התוכנה פיתחו לעצמם מודלים שיש בהס מעט מאוד מהמשותף עם אחד 6 ניהול איכות תוכנה מהמודליס היסטנדרטייסי, ולעומת זאת, משקפיס ביתר דיוק את גישתס לנושא הפיתוח. השיקול הקובע הוא, אס מודל מחזור החייס הולס אמנס את צורכי הפרויקט שעוסקיס בו. המודליס הסטנדרטייסם משמשיס רק כדי להפנות את תשומת לבנו לאופי מחזור החיים וכדי למשוך אותנו לדו-שיח בנושא תהליך הפיתוח שלנו. המטרה היא שכל ארגון יכיר ויסכיסם על המודל או המודליס של מחזור החייס בהם הוא משתמש. יש מקוס לכך שכל ארגון העוסק במגוון פעילויות של פיתוח תוכנה - כגון בית תוכנה - יגדיר לעצמו מודל של מחזור חייס עבור כל סוג של פעולת פיתוח שהוא עשוי לעסוק בה, ועבור כל פעולת פיתוח נתונה ישתמשו במודל ההולס אותה. ה(דסת איכות תוכגה תהליכים ומוצרים עד עכשיו התרכז הדיון בגישה אל איכות מוכוונת-תהליך (60)ח6וז0 00655זק). ההנחה הבסיסית היתה שמוצרי איכות מופקיס בתהליכי איכות. האס גישה זו נכונה בהכרת: המצב ההפוך תקף ללא ספק : העדר תהליכי איכות כלשהס צפןי לפגוע באיכות המוצר, לפחות בטווח הארוך. לעומת זאת, האס יש בכוחו של תהליך איכות להבטיח גם את איכות המוצר! בוודאי שלא. מוצר שאינו עונה על צורכי הלקוח, לא יהיה בו שימוש, ואין זה משנה עד כמה היתה בנייתו טובה באמת. מבחינה מסוימת אפשר לומר שהמוצר חסר את האיכות. באותה מידה, מוצר שכן עונה על צורכי הלקות, כן ייחשב למוצר איכות, מבלי להתחשב בדרך בה נבנה. רק למוצרי איכות יש ערך אמיתי. שיטות מוכוונות-תהליך (610005ו 160160ז06655-0זק2) מייצגות את אחת הגישות האפשריות לפיתוח מוצרי איכות. ניתן לבנות תהליכי איכות שיתמכו ויעשירו את תהליכי הפיתוח הבסיסייס, ויספקו סביבה שמעודדת נהגי פיתוח טוביס. אין בזה כדי להבטיח תֶיכגּן טוב, אך הוא מצמצס את הסיכון של תָּיכוּן טוב שנפגם על ידי נהגי פיתוח גרועיס. שיטות מוכוונות-מוצר (065ז6ות 66)ח6!זס-06061זק) עוסקות בצורה ישירה יותר בהשגת מוצריס טוביס, אך שיטות אלו נוטות להיות נטולות מסגרת (666ח6-ח6קס) וקשות לניטור ולבקרה יעילה. הן אמנס מספקות נתיב מהיר וישיר המכוון למוצרי האיכות, אך חסרות בלמים ואיזוניס המאפייניסם את השיטות מוכוונות-התהליך. שיטות לוכוונות-תהליך מודליס של מחזור חייס כגון מפל המים ו-צ מגלמיס למעשה גישה יקוויתי. הס מתתיליס בהצגת הדרישות, ממשיכיס בהרחבת דרישות אלו למפרטיס טכניים, ואחר לתִיכוּו שייושס, ייבדק, ויימסר ללקות. פרק 1: הנדסת איכות תוכנה | 37 ההנחה הבסיסית שביסוד מודל ממין זה, היא שניתן להגדיר את הדרישות כבר בתחילת הפרויקט. הניסיון בהנדסת תוכנה אמיתית הראה שהנחה זו אינה תמיד תקפה. רק במקרים מעטים הושגה הגדרה נאותה של הדרישות, דבר הגורס לאיטרציות, שלעיתיס תכופות לא הובאו בחשבון בתוכניות הפרויקט, וגורמות לכן לפיגוריס. האיטרציות הבלתי צפויות גם מפעילות לעיתים תכופות לחציס על צוות הפיתוח, דבר הגורס לבעיות איכות. תהליכי האיכות שתוארו עד כה, אם :ישמו אותס ברצינות, ייקלו על ניהול הפרויקטים, ויגבירו את היתכנות אספקת מוצרי איכות. לגישות הקוויות יש פתיחות (119|6ק50506) לגישת תהליך איכות. תשומת לב נאותה לתהליך הפיתוח תגרוס להתגברות על חולשות הגישה הקווית, ובסופו של דבר להגדלת סבירות ההצלחה. התהליכיס הקווייס נחקריס בפרקים 3, 4, ו- 5. שיטות מוכווגנות-מלוגר מחזור החייס החלזוני הוא יבלתי-קוויי, משוס שהוא אינו מייצג גישה הדרגתית של שלב אחרי שלב, הניתנת לתכנון כבר מההתחלה. תהליך זה מאופיין על ידי שיטות יבלתי-קוויות' שפעולת פיתוחן משתמשת בגישה התפתחותית של יצירת אבטיפוסים. בגישה זו מושס דגש מועט על הניסיון לקבוע את הדרישות לפני התחלת הפיתוח, ודגש רב יותר על מתן אפשרות להתגלות הדרישות תוך כדי פיתוח מספר פתרונות של אבטיפוסיס. סגנון יצירת אבטיפוסיסם ממקד את תשומת הלב במוצר המוגמר ולא בתהליך. יישוס שיטות איכות מוכוונות-תהליכיס וטכניקות מקובלות של ניהול פרויקטים, אינו בעל סיכויים רבים להצלחה בסביבה זו שיש בה הרבה איטרציות, ולכן יש צורך בגישות חדשות לניהול איכות. קבוצה חשובה ביותר זו של שיטות כוללת: יצירת אבטיפוסים, ובכלל זה פיתוח יישומים משותף (וחסוחקס!6ט6כ תסוו04ו!קק4/ זתוס1), פיתוח יישומים מהיר (הסתק0ס|6ט6 ת0800ו![קק 6וקת), ושיטות מוכוונות אובייקטים (611005וח 160ח16ז0-+60[טס). אף שעד כה לא התגלו מודליס יסטנדרטייס' של מחזורי חיים בלתי-קוויים, ארגוניס רביס פועלים בשיטות בלתי-קוויות, ומנסיס להגדיר לעצמס מתודולוגיה ומחזור חייס משלהם. ספר זה טוען שהגישות יהמסורתיות' לניהול איכות לא תוכלנה לשרת בצורה נאותה את השיטות הבלתי-קוויות, משוס שהתקניס עליהס מבוססות מערכות לניהול איכות, נכתבו לפי תהליכיס קוויים. נושאים אלה יידונו בפרקים 7, 8, ו- 9. פיתוח התפתחותי (אבולוגיוני) שיטות פיתוח המתפתחות תוך כדי התהליך, מכירות בעובדה שלא ניתן לנתח בצורה נאותה את הדרישות ו/או לייצגן כבר בתחילת הפרויקט. שיטות אלו מבקשות להשתמש בארכיטקטורה לבניית מערכת, שבמסגרתה יכול הפיתוח להימשך עד לשעה בה יוגדרו הדרישות וייושמו סופית. בדרך כלל, שיטות אלו כרוכות בסדרה של שלביס התפתחותיים, שכל אחד מהם מספק פונקציונליות נוספת, עד למועד בו עוניס על 8 ניהול איכות תוכנת התפיסה של הדרישות. המוצר הראשון של מערכת כזו הוא בדרך כלל הארכיטקטורה הבסיסית, המספקת את המבנה בו ניתן לחקור את תחומי הפיתוח הצפויים. שיטות שנעשה בהן שימוש בפיתוחיס מסוג זה, כוללות בדרך כלל צורה כלשהי של טכנולוגיות ליצירת אבטיפוסים. טכניקות ספציפיות יידונו בפרק 8. פיתוח מוכוון-אובייקטיק שיטות מוכוונות-אובייקטיס (160ח6!זס 601(טס) הן בעלות אופי התפתחותי (אבולוציוני), וגס מייצגות גישה מיוחדת בתחוס הגדרת ופירוט הדרישות. כך הן יוצרות פתח למבני מערכות שוניסם מאלה שמחוללות השיטות היתבניתיות' (60זטוסטזז5) והמקובלות יותר. אופי הגישה מוכוונת-האובייקטיס מצריך יסגנון' שונה של פיתוח, וזה מוליך אל מודלי פיתוח חדשיס. בדומה לטכנולוגיית יצירת אבטיפוסיסם, שיטות מוכוונות-אובייקטיס מחייבות מודל נפרד לניהול פרויקטים ואיכות. שיטות אלו מתוארות בפרק 9. (יהול פרויקט תוכנה בעיית ניהול פרויקטיס לפיתוח תוכנה אינה כה מורכבת ובלתי נשלטת, כפי שיכול היה להשתמע מניסיוננו עד כה, לפחות לא לגבי פרויקטיס המאמציסם מחזור חיים קווי, ובתנאי שקיימת תרבות מבוססת של הנדסת תוכנה. תכנון פרויקטיס משמש תמיד יסוד לניהול טוב של פרויקטים, ותוכנית פרויקט המאמצת מודל מוגדר היטב, ומאגדת את כל המשמעויות של תרגילי הפיתוח ותכנון האיכות, יש לה רוב הסיכוייס להיות תוכנית מציאותית. בפרק 3 נדון בקשייס ונציע מספר פתרונות. תוכנית פרויקט אינה יכולה להיות שלמה כבר בתחילת הפרויקט, ולכן דיסציפלינה של עדכוניס סדיריס היא רכיב חיוני בה. קביעה מראש של כלליס ברוריס וקוויס מנחיס למפתחים, תסייע לשמור על תרבות הפרויקט ותאפשר למנהל לזהות את הסיכוניס ולנהלס. תפקיד המערכת לניהול איכותי הוא לספק אוסף נהלים, הוראות עבודה, ותקנים שיגלמו את תרבות הנדסת התוכנה. חיוני שגישת ניהול הפרויקט תבוסס על תרבות האיכות (של הנדסת התוכנה), כדי שהתוכניות תהיינה מציאותיות וכדי שחברי הצוות יוכלו לפרשן בדרך עקבית. מערכת ניהול איכותית המוגדרת היטב, מפשטת בצורה משמעותית את משימת ניהול הפרויקט. מערכת ניהול איכותי מגלמת בתוכה את מדיניות האיכות של החברה, כמו הכרה בעובדה שזול יותר לפתור בעיות תוך כדי הפיתוח מאשר בזמן מחזור התחזוקה. בגישה זו יקטן הסיכון שמהנדסים, או מנהלי פרויקטיס ינקטו בקיצורי דרך, בשל ההנחה המוטעית שיהפריון חייב לקבל קדימות על פני האיכות'י. העדפת האיכות היא הדרך היותר משקית בתיי היומיוס, אס כי רק לעיתיס רחוקות מרגישיס כך תוך סערת הקרב. מערכות לניהול איכות מסייעות לנו לקיים את השיקוליס שהתקבלו באווירה הצוננת והרציונלית, גס בהיותנו שרוייס בעיצומו של הקרב. זה אחד מיגילוייי המפתח שהובנו לאחר התנסות במספר רב של כישלונות. פרק 1: הנדסת איכות תוכנת | 39 הדיסציפלינות של ניהול איכות וניהול פרויקטים אינן ניתנות להפרדה זו מזו. הן מייצגות שני רכיבים של גישה הוליסטית לנושא הניהול. אין החלטות בתחוס האיכות שאינן משפיעות על פרויקטים, ואין החלטות בתחוס הפרויקטים שאינן משפיעות על האיכות. מערכת לניהול האיכות נועדה ליצור סביבת ניהול בה שני פרמטרים חשוביס אלה שזוריס זה בזה. גישת תקן 9000-3 ספ ל(יחול איכות תוכנה הרעיונות שהוצגו בפרק זה הציגו את הצורך בגישה דיסציפלינרית להנדסת התוכנה, שמבוססת על עקרונות הנדסייס, ותואמת עס זאת גם את האופי הייחודי של פיתות תוכנה. מפרטי האיכות והשגתם חייבים למלא תפקיד מרכזי בתוך דיסציפלינה זו. הראינו כי להשגה עקבית של האיכות יש קשר לתהליכים בסיסיים שנעשה בהס שימוש בתְיכגּן ובבניית מוצריס. הרעיון של מערכת לניהול איכות התגלה כהגדרה רשמית של תהליכי התשתית, עליהם מורכבים מנגנוני איכות חיוניים, כגון אבטחת האיכות ובקרת האיכות. מתווה זה של מערכת לניהול איכות עבור סביבת פיתוח תוכנה, מורחב בתקן 01 150, (או תייי 2001 בארץ, בעתיד: ת'יי 9001 150) לכלל מודל של מערכת לניהול איכות, בתוספת קוויס מנחים עבור היבטי התוכנה המגולמיס בתקן 9000-3 150 (או תייי 2000-3 בארץ). השיטות היבלתי-קוויות' מספקות גישה של פיתוח המוכוון על ידי המוצר, מה שמביא בעקבותיו קבוצה חדשה של אתגריס איכותיים. עלינו ללמוד להכיר את אופי בעיות האיכות שניצבות בפני אתגרים אלה, ואת שיטות האיכות שניתן לאמצן כדי לספק סביבת פיתות יבטוחהי יחסית, בה ניתן לבצע את לימוד אופי הבעיה תוך סיכון מזערי. תחילה, לפני שנפליג במסע חקר מפורט של הבעיות שהועלו בפרק זה ושל הקוויס המנחים של תקן 9000-3 150, ננסה להרתיב את הדיבור על הערות המבוא המתייחסות למערכות לניהול האיכות. זה יהיה נושא פרק 2. 0 ניהול איכות תוכנת פכק 2 מערכות לניהול האיכות - לשם מה? מבוא מהן מערכות לניהול איכות ומדוע אנו זקוקים להן? פרק זה מתאר את הסיבות שבעטיין נחשבת האיכות לנושא בעל חשיבות ראשונית, ומציג את הדרך בה אנו מטפלים באתגר האיכות. למרות שיש ערך מסוים לכל הגישות השונות, בחרנו לתאר באופן מפורט את הנתיב של תקני 'מערכת ניהול איכות' 0₪5 (צווצּט וח5%6ץ5 +הפַהחחִפִהַבּח3א), משום שלגבי ארגונים רבים זהו הצעד האקטיבי הראשון בדרך אל האיכות. סכימות כלל-ארציות, כדוגמת הסכימה ד!ואסוד אש, שמרחיבות את גישת התקן הבסיסי, מסייעות לקדם את החברות העסקיות על ידי זיהוי הזדמנויות לשיפור מערכת 05 שלהן. היעד הסופי הוא סביבת איכות כוללת, בה האיכות היא חלק בלתי נפרד מתרבות הניהול; מדידה ועריכת מבדקים (סָחואז3וחה0ח6פ) בהשוואה למתחרים הם נוהג של קבע; ושיפור מתמשך הוא יעד עסקי בסיסי. אתגר האיכות מדוע אנו זקוקיס לאיכות! עשריס וחמש שניס הצלחנו להסתדר בלעדיה, אז למה כל ההתרגשות הזאת עכשיו! השימוש במילה ילהסתדרי משקף באמת את מצב הענייניס הנוכתחי. הולכות ומצטברות הוכחות שפיתוח תוכנה הוא מהלך יקר עד כדי ייאוש. גרוע מזה, העלות האמיתית של רכישה, בעלות ושימוש במוצרי תוכנה קריטיים, משבשת את פעולת החברות, וללא ספק חורגת ועוברת במספר רב של מקרים, אס לא בכולס, את התועלת המוחשית המושגת באמצעות התוכנה. במרוצת הזמן הוצעו הערכות שונות למדידת העלות האמיתית של התוכנה. ההערכה לה עלינו להיות מודעיס מאוד, היא זו המודדת את היחס שבין מספר האנשיס שעוסקיס בבניית יישומי תוכנה חדשיסם, לבין אלה שימתתזקיס' יישומים קיימיס. בהקשר זה, תחזוקה פירושה דאגה לכך שהתוכנה תמשיך לתפקד כמות שהיא, ללא הרחבות נוספות. היחס הוא ממש מהמם, 1:1. אנו צורכיס את מחצית משאבי פיתוח פדק 2: מערכות לניהול האיכות | 41 התוכנה בהתמודדות עם בעיות שנוצרו תוך כדי תהליך הפיתוח. זו הסיבה שהאיכות היא כה חשובה; אנו חייביס למצוא דרכיס שתאפשרנה לנו לצמצס בהמשך הדרך את העלויות הכרוכות בבעלות על התוכנה, על ידי אספקת מוצרים טוביס יותר. נושאי פרק זה הס: המשמעות של מוצרים טובים יותר, ודרכיסם לשפר את איכות מוצרים אלה בדרך משקית. כאשר עובד בקו הייצור עושה שגיאה, הוא משליך הצידה את הרכיב הפגום. מנהל העבודה מבקש אחר כך לדעת מדוע ערמת הפגומים היא כה גדולה. אנו עושים כל הזמן את אותו הדבר בזמ] כתיבת התוכניות, אלא שאיש אינו יכול לראות את ערימת הפגומים. יאן גוסטפסון (1993 ,1א50) מהי הדרן אל האיכות כדי להשיב על שאלה זו עלינו להתמודד עס מספר משתנים. ראשית, יש דעות מנוגדות בדבר מהות האיכות והדרכים להשגתה; את אלו יש לבחון בתשומת לב. שנית, עלינו להבהיר לעצמנו למה אנו מתכוונים כאשר אנו מדברים על איכות תוכנה. שלישית, עלינו לשאול את עצמנו מה הדבר שמייחד את התוכנה כל כך, מדוע יש לנהוג בה בדרך שונה מזו שבה אגו נוהגיס בכל מוצר אחר? לאחר שנשאל את עצמנו את השאלות האלו, עלינו לקבל החלטה. עלינו להחליט מה לעשות כדי לפתור את הבעיה של תוכנה שאיכותה ירודה, ואנו חייביס להיות מסוגליס להוציא אל הפועל את דרך הפעולה בה בחרנו. איננו מחפשיס פתרון אידיאלי, או פתרון שייתן לנו את מירב היתרונות, משוס שדבר זה יחייב זמני עיצוב ויישוס ממושכים. הצורך הוא דחוף, ולכן מטרתנו מוגבלת יותר והיא, בחירת דרך פעולה שאפשר להתחיל בה מיד ואשר תביא לשיפור מהיר של המצב. מאוחר יותר נדון באחדות מאפשרויות הטווח הארוך יותר. עלינו לעשות זאת כדי לוודא שהאסטרטגיה שלנו סבירה ועקבית, ואמנם מטפלת ביעד החשוב ביותר - היכולת לשיפור מתמשך. עס זאת, בשלב זה תהיה גישתנו פרגמטית בלבד. להי איכות תוכנה נאמניס לגישתנו הפרגמטית, לא נחפש הגדרה מחמירה. ננסה רק ללכוד אחדות מהסוגיות המעשיות הנוגעות לנושא האיכות. 2 ניהול איכות תוכנה מה אגו מחפשיק כיצד אנו יכוליס להבחין באיכות שבמוצר תוכנה! [, המוצר מבצע את מה שמצפים ממנו שיבצע. המוצר אינו מבצע את מה שלא מצפים ממנו. המוצר מתנהג בדרך עקבית. המוצר מתנהג בצורה אמינה. המשתמשליס במוצר יכוליס להשתמש בו בדרך אפקטיבית. 8 ₪ 5 שש ם המוצר ניתן לשינוי בקלות יחסית, להחלפה או להרחבת הפונקציות שלו. רשימה זו של סוגיות רחוקה מלשמש כהגדרה. עס זאת, אין ספק שאילו מספר גדול יותר של מוצרי תוכנה היה עונה על הדרישות הלגיטימיות שפורטו לעיל, לא היינו צריכיס להיות מוטרדיס כל כך בנושא האיכות. כיצד נוכל להתחילל לענות על הסוגיות האלו! ראשית, עלינו לנסות להבין את מהותן. נשיס לב שניתן לאגד את הסוגיות האלו בארבע קטגוריות : = סעיפים 1 ו- 2 עוסקיס במתן מענה לציפיות ; = סעיפים 3 ו- 4 עוסקיס בהתנהגות הכוללת - הס משקפים את איכוו; התיכון ; = סעיף 5 עוסק בתחושות המשתמש; >= סעיף 6 עוסק בפוטנציאל התָיכוּן לטווח ארוך. מתן מענה לציפיות והשגת התחושות הנכונות של המשתפמיי, כרוכיס בתקשורת :עילה ומתמשכת עס הלקוח שלנו, כדי לוודא שהגענו להבנה נכונה ושלמה של ציפיות ותחושות הלקוח. זה מחייב שיעמוד לרשותנו תהליך כל צהו להמרת הבנה זו לאיזה שהוא מוצר תוכנה מוגמר. אם נרצה להגיע לכלל +ייכ"ת בצורה מתמשכת ועקבית, נזדקק לתהליך שניתן יהיה לחזור עליו. איכות התיכון ופוטנציאל העיצוב הט בעלי אופי שונה - הס מותניסם בכישוריס ובמקצועיות המעצביס שלנו, ותלוייס פחות בתהליך עצמו. את התיכוּן הטוב אי אפשר לבטא בצורת תיאור נהלי פשוט, אס כי גם כאן ניתן להסתייע בתהליך תיכון עקבי. אס כן, תהליכים שעליהם ניתן לחזור, אינס יכולים לפתור בשלמות את בעיותינו, עס זאת, אין ספק שיש בכוחס למלא תפקיד נכבד. תפקיד זה תשוב, משוס שהאלמנטיס הנהליים של בעיותינו קשוריס לעקביות, נכונות ושלמות (60176010655 ,ץ6ח600515%6 005 6תג). תהליכיס שניתן לחזור עליהם, אין בהס כדי להבטיה את העיצוב הטוב, או להעניק נופך יצירתי. עס זאת, הבעיוות הקשורות במוצרי תוכנה מתמקדות, בדרך כלל, בנושאי האמינות הבסיסית וביכולת התחזוקה של המוצר. מה שדרוש לנו הוא קבוצה של נהלי איכות אשר יסייעו במאבק להשגת העקביות. פרק 2: מערכות לניהול האיכות ‏ 43 ----₪--₪ תהליכי איכות למה אנו מתכווניס במיליס תהליך איכות (6655סזק /1ו081))! כוונתנו לתהליך המאגד מידה מספקת של פעולות אימות (חסו₪641!ז6ע), כדי לוודא שהושלסם בצורה נכונה, והוא מכיל מנגנון כלשהו לבדיקת תקפות (ח0ו41/081), כדי לוודא שהוא מספק מוצר קביל. גישה זו אינה מחוסנת לחלוטין מפני פגמיס, אך מהווה צעד בכיוון הנכון. תהליך איכות צריך להכיל את כל האלמנטיס המוצגיס בתרשים 2.1, או חלקם. פלט התהליך מושווה מול איה שהוא מדד של מבחן קבלה. כל פלט שאינו עומד במבחן מדדים זה ייפסל, או יועבר לעיבוד חוזר. המדדיס למבחן הקבלה יכוליס להתבסס על מידע השאוב משלושה מקורות : = הקלט המוזן לתהליך, כדי לוודא שהבאנו בחשבון תנודות באיכות הקלט; > תקנים, המייצגיס את רמת האיכות ותואמיס את המדיניות הכוללת שלנו; *= מידע המתקבל מתהליכים מאוחריס יותר, כדי שנוכל להביא בתשבון תקלות כלשהן שיהסתננו דרך הרשתי. לתהליך המוגדר בצורה זו, יש את היכולת להשיג פלט עקבי, גם לנוכח תנודות באיכות הקלט. /אוסוש6ז ]6 וח6זט5ה6)/ סא 5 טוג צשץ )אסא זנ בי וח63זו5חאו0 תדשים 2.1 תהליך איכות 4 ניהול איכות תוכנה רעיוו זה יכול לשמש כמודל לתהליך עיצוב האיכות, כפי שמוצג בתרשיס 2.2, בו השתמשנו בסקר התיכון (שסוצ6ז ה98וצ00) כדי לבחון את איכות הפלט המתקבל מתהליך התִיכוּן. במקרה זה משתמש הסקר בתקניס ובתבניות שהשתמש המעצב, כדי לוודא שמסמך התְיכוּן המוגמר תואס להס. הסקר משתמש גס בקריטריוניס של מבחני הקבלה כדי לוודא שפלט התְיכוּן נכון, והוא משתמש ברשימות תיוג (וצו!אסטו[6) כדי להנחות את הבודקיס בחיפושיהס אחר חולשות פוטנציאליות. רשימות התיוג הן מנגנון רב עוצמה לרישוס מידע, המתייחס לתקלות העבר באמצעות שאלות המנחות את הבודקיס לחפש אחר סימפטומיס אופייניים של בעיות שכיחות. רישוס יסודי של התוצאות יאפשר לנו להשתמש בממצאיס לבדיקה מחדש של התקנים ורשימות התיוג שבידינו, כדי לשמור על העדכניות והרלוונטיות לסוגי הבעיות בהן אנו נתקליס. מתוך התהליכים שתוארו, משתמעים התקנים העוסקים בתוכן ובמתווה (וטסעג!) מסמכי מפתח. תהליכי איכות צריכיס להגדיר את מה שחייב להיעשות ואת הדרך בה נוכל לדעת אס התהליך הושלס בצורה נכונה. , תט0ו!בסווטטק 5‏ + , 58קחטו זחטוחטסטכ] - , 6ז63ח313 חשופטכן י , י , , , . חקואט וחטזאצ5פ ₪ --+< אזטאטת 5 חקוס 7------- - ההזדדרררדרדהר--- 8 ה---יי--> ו ₪ ₪ פסץ 6 7? ץנ ?7 שסןט6ז 66016 ות 665180 ווח תדשים 2.2 תהליך עיצוב איכות פדק 2: מערכות לניהול האיכות | 45 8 יי ד ה הו ו ₪ מערכות איכות מערכת אלכות (ו516ע5 ע20411)) היא מערכת בה כל התהליכיס הס תהליכי איכות, ואף למעלה מזה. עד עתה תיארנו בתהליך האיכות שלנו רק כיצד צריכה העבודה להתבצע ולהיבדק, אך יש גם סוגיות אחרות בהן עלינו לעסוק, למשל, מה יקרה כאשר משתתפיס בביצוע העבודה יותר מאשר עובד אחד! על מי תוטל האחריות לכך שהדברים ייעשו בדרך הנכונה! ברור שכדי להתגבר על חולשה זו עלינו להקצות תחומי אחריות בתוך התהליכים עצמם. ומה יקרה כאשר התהליך כרוך בתקשורת בין מחלקות שונות, או בינינו לבין הלקות! בדרך כלל, אלה תחומיס שחשופיס לתקלות, ולכן עלינו להקדיש תשומת לב מיוחדת להגדרת ממשקיס אלה. אנו חייביס לוודא שתהיה הגדרת אחריות לניהול התקשורת על פני ממשקים, ועלינו גם לוודא שהגדרנו את התקשורת הדרושה, כדי שהתהליך יוכל להסתייס בהצלחה. הרחבנו את הדיבור על רעיון תהליכי איכות כדי שיכללו נהליס שמטרתם לקייס בקרה על הממשקיס והקצאת תחומי אחריות לכל התהליכיס ונהלי הממשקיס. עתה יש ברשותנו דבר שנוכל לתאר במידה מסוימת של טבירות כמערכת, משוס שהוא מכסה את כל התהליכים והממשקים העיקריים. תחוס שטרס כיסינו הוא רכיב הניהול שימיר מערכת איכות זו ממעמד של מנגנון לשיפורים טכניים, למעמד של מערכת אמיתית החובקת את כל מה שאנו מבצעיס, ומעודדת יצירת תרבות אפקטיבית ועקבית של איכות. מחויבות ההנהלה היא הדבק המאחד את מערכת האיכות לכלל שלמות אחת. ההנהלה מגדירה את מדיניות האיכות ואת היעדים, מקצה תפקידים ותחומי אחריות, ומספקת משאביס כדי לאפשר לתהליכי האיכות לתפקד ביעילות. ההנהלה מחליטה אם לתמוך (או לא לתמוך) באיכות, כאשר לחציס מסחריים מעורריס את הפיתוי להשתמש בקיצורי דרך. מערכת הפועלת בדרך זו ומצליחה לעמוד בפני לחצים היא באמת מערכת לניהול איכות. מערכות לניהול איכות מערכת לניהול איכות היא אם כן מערכת המכילה את כל הרכיבים העיקריים : * מהויבות ההנהלה; * תהליכי איכות מוגדרים, כולל תקניס למוצר המוגמר; * תחומי אחריות מוגדריס ; * הגדרת הממשקים העיקריים; = מנגנוני אימות לבדיקת התהליכים; * מנגגנוניסם לבדיקת תקפות לצורך בדיקת המוצריס. 6 ניהול איכות תוכנה השאלה הבאה עוסקת בדרך בה מיישמים את המערכת. לפנינו שלוש אפשרויות : >= לבחור עובדיס מומחים במיוחד, לומר להס מה נדרש מהם, ולהניח להסם למצוא את הדרך להשגת התוצאות הרצויות. + להדריך את העובדיס בשימוש בשיטות ובתהליכיס שאנו רוציס, ולהניח להסם למצוא את הדרך להשגת הרמה הרצויה של שיתוף הפעולה. = לתעד את כל נהלי ותהליכי האיכות, הממשקיס ותחומי האחריות, ולדרוש מהעובדיס לפעול לפי המערכת המתועדת. שלוש גישות אלו כבר נוסו בעבר, ואפשר למצוא בענף התכנות דוגמאות של כל אחת מהן. אין כל עדות תקפה שתאמר איזו מהגישות עדיפה משמעותית על האחרות. עס זאת, האפשרות של יצירת מערכת איכות מתועדת, גובשה כבר בתקן הבינלאומי - 1 1500 (או ת'יי 2001 בארץ). נוסף לכך שתקן זה מספק מודל למערכת ניהול איכות, הוא גס מזהה נהלים ספציפיים שיש לתעד בכל מקרה כמינימוס. רמת פירוט ההגדרה והיכולת הנלווית אליה מאפשרות להעריך את מידת ההיצמדות למפרטי מערכת האיכות, ולכן גרמו לארגוניס רביס לבחור בתקן זה כאפשרות המועדפת. היתרון הראשי של מערכת איכות מתועדת פשוט למדי: המערכת המתועדת יכולה לשמש כנקודת מוצא מוחשית. בכל מקרה שמתעוררות בעיות איכות, ניתן לנתח את המערכת המתועדת ולשנותה, כדי לתקן את הבעיה ולהימנע מהישנותה בעתיד. לאחר שהמערכת תתבסס היטב, ומוצרי איכות יהיו לדבר שבשיגרה, אפשר יהיה להשתמש במערכת המתועדת כבקרש קפיצה לשיפורים עתידייס. הצגת תיאור שלס של המערכת הנהוג לפי גישה זו מקנה לה יתרון מכריע על פני כל הגישות האחרות. מאידך, מערכות איכות מתועדות יכולות לעודד הסתגלות עיוורת לנהליס בלתי יעילים וביורוקרטייס. אין ספק שבכל מערכת פורמלית מובנית אינרציה מסוימת, ותקניםס עלוליס להניע את האנשיס להסתפק במינימוס מסוים, במקום לשאוף מעלה, אל הטוב ביותר שניתן להשגה. עם זאת, חולשות אלו אינן בלתי נמנעות, וארגון בעל הרגשת מחויבות יכול להימנע ממהמורות אלו. ות רק כתירוץ לאי השגת האיכות. הימנע מלבנות אימפריות של איכות. אלה משמש : / : : קמרון לאו (1993 501 סדות התקניפ 9000 150 0 1500 (בארץ, ת'יי 2000) היא משפחה של תקניס וקווים מנתיס שנועדה לתת תמונה כוללת של ניהול איכות, להציב תקניס בהקשרס הנכון, ולספק הדרכה לגבי חלק מהפירוט הנדרש ליישוס מערכות אפקטיביות לניהול איכות. התקניס 9001 150, 12 1500, ו-9003 150 (באר, תייי 9001, תייי 9002 ותייי 9003 בהתאמה), מספקיס תבניות שעל פיהן אפשר לשפוט את המערכות לניהול איכות. מתוך תקניס אלה, תקן 1 150 הוא הכוללני ביותר וישיס בכל מקרה שמערכת לניהול איכות עוסקת בתיכוּן ובפיתות. פרק 2: מערכות למיהול האיכות | 47 ודיי שיר 7 7 דרישות תקן 900 180 הדרישות המפורטות של תקן 1 150 מתוארות במסמך 1994, 9001 150 אש 85 (בארצ תייי 1 150). אנו כוללים כאן את סיכוס הדרישות כדי לאפשר השוואה עס המודל הכללי של מערכת ניהול איכות שהוגדרה על ידינו. מהנדסים אזרתיים חייבים לפעול לפי תקנים, אחרת יתמוטטו הגשרים שלהם. בתחום התזכנה צריכים עוד ליפול הרבה גשרים עד שנלמד את הלקת. לס האטו]ן דרישות תקן 9001 150 מאורגנות בצורה שנועדה לשקף את הייצור, מכיוו שהתקנים נכתבו מלכתחילה עבור המגזר התעשייתי. כדי להבין את מה שהתקן מנסה להשיג, מן הראוי לשקול שלושה תחומים של סוגיות עיקריות בהן הוא עוסק. >= אחריות ההנהלה; >= ארגון וניהול העבודה עצמה; >= פעילויות התמיכה המאפשרות את נהגי העבודה ומספקות שיפורים מתמידים. התקן מכיל 20 סעיפיס אשר ממוספריס במספרי סעיפים מ- 4.1 ועד 4.20. הדיון שבהמשך מתייחס אל מספרי הסעיפים האלה. 90 50 - 20 הסעיפיס 41 אחריות הנהלה (ע650005191111ז 1ח6ח886ח8וח). 142 מערכת האיכות (וח6ז5/5 עזו[טף). 143 סקר החוזה (עש6/16ז ז80זזחסס). 4+ בקרת התָיכוּן ((0זותס6 ח46518). 5 בקרת התיעוד ([0זוח60 0818 0ח8 זח6ותט606). 146 רכש (8ַחו45חסזטכ). 17 בקרת מוצר שמסופק על ידי הלקוח (זסט0סזק 001160ט5-ז51010ט6 +0 1701ת60). 48 זיהוי המוצר ועקיבותו (ע806801]11:] 6ח8 ח0ו118681ח106 01ט06זכ). 149 בקרת תהליך ([110ת00 655ססזכ). 0 בתינה ובדיקה (8ח!165 6ח8 ח0ו5060ח1). 1 בקרת ציוד הבחינה, המדידה והבדיקה (זהסותקוטף6 165 36 פַתוזט95סוח ,חסוזס6קפת 01 01זזהס6). 2 מגצב הבחינה והבדיקה (05ו513 ]165 806 ח0וז5060ח/). 3 בקרת מוצר לא-מתאי5ם (ז0ט6סזק קהווזס)הססתסה +0 [סזוהסס). 64 פעולה מתקנת ומונעת (ח0ו801 6ץוזח6ט6זק 6ח8 60776011/6). 5 שלנוע, אחסון, אריזה, שימור והספקה (6צ06]1 6ח8 ח0וז8/ז656זק ,פח%881ס8ק ,5007856 ,חו[חגת). 6 בקרת רשומות איכות (660765ז עזו[8טף ]0 |0זוחסס). 8 ניתול איכות תוכנה 7 מבדקי איכות פנימייס (30618 8[1טף [8חז6זחו). 8 הדרכה והסמכה (פחוחוגזו). 9 מתן שלרות (פתוסוצז59). 0 ככניקות סטטיסטיות (65טף01ת60+ [5181151168). אחויות ה(הלה אחריות ההנהלה היא הנושא הראשון בו עוסק התקן. סעיף 4.1, אחריות ההנהלה, כולל דרישות שמחייבות להציג בבהירות את מדיניות האיכות של הארגון (4.1.1), להגדיר את הארגון שבמסגרתו אמוריס להשיג את האיכות (4.1.2), ולסקור דרך קבע את ביצועי מערכת ניהול איכות (4.1.3). מדיניות האיכות מוגדרת ב'מדריך האיכות' ([גטח3]א עו[4ט)), שמפרט את הרמה הגבוהה ביותר של תיאור מערכת ניהול איכות. כל העובדיס אמוריס להיות בעלי אחריות מוגדרת היטב, ובעלי הסמכות הנדרשת להפעלת האחריות. נציג ההנהלה חייב להיות בעל אחריות כוללת לנושא האיכות. התקן מחייב קיוסם סקוי הנהלה שגרתיים, כדי לוודא את המשך קיוס 'מידת ההתאמה והאפקטיביותי של המערכת לניהול איכות. בתקן כלולים שלושה סעיפים חשובים נוספים, בהם מוצגיס היבטי אחריות ההנהלה: = סעיף 4.2 מציין את הדרישה לתעד את מערכת ניהול איכות. = סעיף 4 דורש נקיטת פעולה מתאימה לתיקון בעיות במוצריס ובתהליכים. = סעיף 4.17 דורש לקייס מבדקיס מתוכננים תקופתיים של מערכת ניהול האיכות. היבטיס אלה של התקן יתוארו בפירוט רב יותר בפרק 5. תתוס העבודה תהליכי האיכות של חברה עוקביס אחר זרימת העבודה בעסק. סקר החוזים (4.3) מכסה את כל הפעילויות המשפיעות על הקשריס החוזיים עם לקוחות, כולל ניתוח הדרישות וכל עבודה הנדרשת, כדי לפתור בעיות הקשורות בעמידה בדרישות אלו. בקרת התְיכוּן (4.4) ובקרת תהליכיס (4.9) עוסקות בכל ההיבטיס של תָיכוּן וייצור המוצריס. במשך שלבי התִּיכוּן והייצור יש צורך לשקול בתינות ובדיקות (4.10) של מוצרי בינייס ומוצריס סופיים, שעשויים לחייב את השימוש בציוד בדיקה מכויל (4.11). בעיות כלשהן המתגלות במשך שלבי התִיכוּן והייצור, מחייבות תשומת לב מיוחדת, כדי לוודא שרק מוצריס קביליס יגיעו אל הלקוח, ומוצריס שאינס תואמיס את התקן יחויבו בבקרה מיוחדת (4.13). כל בקרה הנדרשת במשך שלבים אלה, מתאפשרת על ידי זיהוי דקדקני של פריטי הייצור (4.8) והשלביס שעובר כל אחד מהם (4.12). פרק 2: מערכות לממיהול האיכות | 49 שינוע, אחסון, אריזה ומשלוח (4.15) קובע את התקנים אשר נועדו לוודא שהמוצריס , יגיעו אל הלקוח במצב הנכון, ומתן השירות השוטף (4.19) מגדיר קשרים נמשכים עס הלקוח שעשויים להתקייס גס לאחר שהמוצר סופק. פעילויות תומכות כדי שאפשר יהיה לוודא את האפקטיביות של מערכת ניהול איכות, יש צורך במספר פעילויות תומכות. בקרת תיעוד (4.5) מחייבת שהתיעוד הרלוונטי יהיה נתון לבקרה כדי לוודא שהעותקים הנכוניס של המסמכים הרלוונטייס יהיו זמיניס בכל מקוס בו הס נדרשיס. רשומות האיכות (4.16) עוקבות אחר פעילויות האיכות ומספקות עדות ליישוםס האפקטיבי. הרכש (4.6) מזהה את הצורך בבחירת ספקיס ומוודא שפריטיס שנרכשו נבדקיס עס קבלתס ומוגדריס בדייקנות. מוצר המסופק על ידי הלקוח (4.7) מרחיב את הטיפול בחומריס עבור חומריס השייכיס ללקוחות ומוחזקים עבורס בחצרות הספק. הדרכה (4.18) קובעת את הדרישות לזיהוי הדרכה חיונית ומוודאת שצורכי ההדרכה ומתן ההדרכה יימצאו דרך קבע תחת בקרה. אחרון אך לא פחות חשוב, טכניקות סטטיסטיות (4.20) מצביעות על הצורך למדוד את מאפייני המוצר והתהליך, כדי לאפשר שיפורים מתמידים. מה טיוחד כל כך גתוכ(ה תקן 9000 150 חל באופן שווה על כל ענפי התעשיה. זהו תקן כללי, אשר מכוון אל כל המרכיבים של מערכות איכות, לאו דווקא לתהליכים המונחים בתשתיתם. לרוב ענפי התעשייה הפרשנות לתקן זה מצומצמת למדי, אך האופי של תהליך פיתוח התוכנה עושה את פרשנות התקן בנושא זה לקשה יותר. קיימות שלוש סיבות לכך: 1. התהליך מפיק פונקציונליות או התנהגות, וכמעט שוס דבר אחר מלבד זאת. תהליך הייצור עצמו טריוויאלי; תהליך העיצוב הוא לב לבו של פיתוח התוכנה. צורת תהליך הפיתוח - מחזור התיים - היא בעלת חשיבות מיוחדת, וחובה להתאימה בקפדנות לפיתוח בו עוסקים. דגש זה על מחזור החיים של הפיתוח חייב להשתקף במסמך ההנחיות. 3 פעולות מסוימות, כגון ניהול התצורה, ממלאות תפקיד תומך וחשוב, וצריך להדגישן ולהתייחס אליהן במונחים המוכריס למפתחי תוכנה. מסיבות אלו, גובשה קבוצה של קווים מנתיס שנועדו להשלים את תקן 9001 150. 0 ניתול איכות תוכנה הקווים המנחיפ 9000-3 0פ תקן 9000-3 50! (בארץ, תייי 2000-3) - בנוי בצורה שונה מזו של 9001 150. הדבר נעשה בחלקו כדי לאפשר את שינוי הסדר, תוך התאמה לרעיון של מחזור החיים של הפיתוח, ובחלקו בשל הוספת נושאיס חדשיס, שעבורס אין סעיף מקביל בתקן [0 150. תרשיס 2.3 מציג את הקשר בין המבניס ואת המקומות בהס 9000-3 150 מציג חומר חדש. המטרות העיקריות של 9000-3 150 הן: קידוס היבט חדש של ניהול איכות המונחה על ידי מחזור החייס והדגשת תחומיס מסוימיס בהס יש צורך בדגש מיוחד בהקשר של פיתוח תוכנה. 13 0 - פירוט הסעיפיסם 4 מערכת איכות - מסגרת: 141 אחריות הנהלה (ע00510111ק65ז 1ח6וח886חגוח). 2 מערכת איכות (וח516ש5 עזוט). 13 מבדקים פנימיים של מערכת האיכות (800105 וח5/516 עזו!4טף |גחז6זחו). 14 פעולה מתקנת (ח0ס!]40 6011/6זז60). 5 מערכת איכות - פעילויות במחזור החיים: 5.1 כללי ([614ח86). 2 סקר החוזה (ש6וט6ז 119401ח60). 3 מפרט דרישות הלקות (ח52661003110 16015ח6ז6001ז 5'ז856ת6זגוק). 4 תכנון הפיתוח (פתותח13ק 1ח6ותקס|6ש46). 5 תכנון האיכות (קתותחג!ק ו!4טף). 6 תִּיכגּן ויישוס (חסוז4ח6וח6!קוח! 0ח8 ח06518). 7 בדיקה והוכחת תקפות (מ0וז91!69 806 8ַתוז65)). 8 קבלה (66ח40060)4). 9 שכפול, מסירה והתקנה (מ513|]40100ח1 6ח8 עזסטו!66 ,ח10ז168!ק6ז). 5-10 תחזוקה (6סח4ח6זחו4ות). 6 מערכות איכות - פעילויות תומכות: 1 ניהול תצורה (1ח6וח826ח4ו ח0סו41זט8ו חסס). 2 בקרת מסמכיסם ([0ז6001 6ח6וחט400). 3 רשומות איכות (660:65ז עו!טף). 4 מדידה (זח6וח6זט635וח). 5 כללים, נהגיס ומוסכמות (5תסו)ח6/ח60 806 6011065זכ ,165ז). 6 כליס וטכניקות (010(065ת160 6ח3 [סס)). 7 רכש (פַחו45ח6זטק). 8 מוצר תוכנה משולב (06001זק 6ז4 או 50 610666ם1). 9 הדרכה (פחותגזו). פרק 2: מערכות למהול האיכות | 51 וט ות [חז6וחן ץזו[הּטף 2005 )4.17( זז 300 )4.14( קַחו01ה118 | ח0ג661ק5ה1 6 | 6 36 5 אזסאו שד וי זר ח8ופס תי 34 ב 615 )44( (4.5) [0זוח60 0313 36 ]ח6וחטססכ] ו [זות 0 : 1 1 קחוחסקקטפ ץזו[טכ) | !סזוחס6 | .קפחו זסות !פטס 5ננו 5 1 .טוח 15001 | 66ו|קקט5 -חסת ₪ | 88חו1730 | 65טףותת66ו | | |סטשסזק -07ס זו |פטן ו שחופהחסזטץ חסו601ק5ה] | ו )412( )411( | )413( )47( )0( תדשים 2.3 א) מבנה תקן 9001 150 9000-3 50 מעוכת איכות - מסגות ההיבטים של אחריות ההנהלה הכלולים בתקן 9000-3 150 דומיסם לאלה שבתקן 1 150. אותה קבוצת רעיונות הקשוריס זה לזה נכללת תחת הכותרת 'מערכת איכות - מסגרת'. בתוספת ציון של מספר נקודות. התוספות החשובות ביותר מכוונות להשגת שיתוף פעולה גדול יותר בין הספקיס לבין הלקוחות, על ידי שימת דגש על אחריות ההנהלה של הלקות (4.1.2) ועל ידי המרצה לביצוע סקר חוזר בשלבים קריטיים של פיתוח פרויקטים (4.1.5). תוכניות איכות אמורות להיות חלק ממערכת איכות מתועדת (4.2.3). 2 ניהול איכות תוכנה זט השק בחבות זז תסווסב [הוח6זח] ץזו!הּטף ]וגג (3+) )44( 5| 58 כד. בי = -] 66 58| "'-ן -- 4 ב 5 סוסעס בת ₪ | 5 |פ. ₪ נ--] 5 3 55|83|כ | 55 5 ₪< | ₪ | 2|2ש | 2 | ם 9 55 > 55| | 5 | 5 5 - 5 > | ₪| 5 ב| | בם ₪ (5.9) (5.7()5.8)| (5.5|)5.6)| (5.4) | (5.3) (6.1) וחסוח6הַבּת3ו חסוו3זטקו/ת0) (6.4) זת6וח6זט1635א החווזסקקט5 (6.5) 5ח0ן1ה6ח60 6ת3 401/065זק ,65וט בו (6.6) 65ט1חח166 306 0015 6 6ז 0 יי [ח6וחהט6ס [סזותסס פתו5הת6זטץ ץזו|הּטוכ) 5 שחוחובזך )6.2( )6.3( )6.7( )6.8( )69( (פ) תלש:ם 2.3 ב) מבנה תקן 9000-3 150 3 ה מערכת איכות - פעילויות בלתחזור החייפ המטרה כאן היא להפנות את תשומת הלב לאופי דמוי מחזור-חייס של תָיכוּן התוכנה והפיתוח בכללותס, ולהדגיש את אזורי הסיכון המחייביסם תשומת לב מיוחדת בפיתות התוכנה. תחת הכותרת 'מערכת איכות - פעילויות במחזור-החיים', מופיע ארגון מחדש רדיקלי של סעיפי תקן 9001 150 יחד עס תוספות משמעותיות. סעיף סקר התוזה (5.2) כולל הנחיות בדבר מה שיש לבדוק (5.2.1) והנחיות ספציפיות בדבר סעיפי איכות בחוזה (5.2.2). סעיף חדש בדבר מפרט דרישות הלקוח (5.3) כולל יעוץ נוסף בדבר שיתוף פעולה הדדי (5.3.2). פרק 2: מערכות לניהול האיכות | 53 תכנון הפיתוח (5.4) כולל הנחיות בדבר ההיבטיס הטכניים וניהול פרויקטים, מוסיף קטע שעוסק בשיטות כלים לפיתות (5.4.2.3) ומספק הנחיות בדבר סוגי הקלט והפלט ל הפיתוח. תכנון האיכות זוכה לסעיף נפרד משלו (5.5), וכולל הנחיות בדבר תוכנית האיכות (5.5.2). תיכון ויישום (5.6) מתייחס ישירות לפיתוח תוכנה, וקורא באופן משמעותי לעריכת סקירות של התְּיכוּן המתועד כחלק בלתי נפרד מתהליך הפיתוח. בדיקה והוכחת תקפות (5.7) מדגיש את תכנון הבדיקה (5.7.2) ומתייחס למינוח ולנהגיס המקובלים בתעשיית התוכנה, מבחני הקבלה זוכיס לסעיף נפרד (5.8). סעיף בנושא השכפול, במסירה וההתקנה (5.9) עוסק בסוגיות המיוחדות של תעשיית התוכנה. בדיקות שנועדו לוודא את נכונות העותקיס וכי הובאו בחשבון סוגיות של זכויות יוצריס והרשאות, מהוות סוגיות ראשיות שיש לטפל בהן לפני שאפשר יהיה להמשיך בהספקה ובהתקנה. בסוף חלק זה של הקווים המנחיס יש סעיף ראשי חדש על תחזוקה (5.10), אשר דן בשלב חשוב זה שבמחזור החייס של התוכנה, נושא שאינו מטופל כראוי ב- 9001 150. 3 0פ מערכת איכות - פעילויות תומכות תחת הכותרת 'מערכת איכות - פעילויות תומכותי, מזהה התקן 9000-3 150 אחדיס מתחומי המפתת שאינס קשורים לשלבים מוגדריס במחזור התיים, אך מהוויס נושא לתשומת ליבו הכללית של מפתח התוכנה. אחדיס מתחומיס אלה אינם אלא הד לתקן 9001 150: * בקרת מסמכים (6.2); * רשומות איכות (6.3); * רכש(6.7); + הדרכה(6.9). תחומיס אחריס הס חדשים, ומייצגים סוגיות ייחודיות חשובות : * כללים, נהגים ומוסכמות (6.5); * כלים וטכניקות (6.6); * מוצר תוכנה משולב (6.8). שני תחומים מייצגיס תוספות עיקריות לגישת התקן: 1 ניהול תצורה (6.1) עוסק בתכנון, זיהוי ויכולת המעקב, בקרת שינויים ודיווח המצב (6%800) בפירוט מסוים. 2 מדידה (6.4) עוסקת גס במדידת המוצר וגס במדידת התהליך, ומרחיקה לכת מעבר לתקן 9001 150, משוס שהיא מנסה לקדסם את תרבות השיפורים המתמידיס. 4 ניהול איכות תוכנה מערכת ל(יהול איכות למפתחי תוכג(ה התקנים 9001 1580 ו- 9000-3 150 מספקיס מפרט למערכת ניהול איכות שמנסה לענות על הצרכיס המיוחדיס של תעשיית התוכנה. 9001 150 מכיל גישה בדוקה ומנוסה לניהול איכות. 9000-3 150 מנטה להדגיס את מידת הרלוונטיות של סעיפי 9001 150 עבור מפתתי תוכנה, ומציע קוויס מנחיס ליישומס. פרקים 3, 4 ו- 5 בוחניס את הקוויס המנחים המוצעים על ידי 9000-3 150 ומספקים מספר עצות שימושיות בדבר הדרכיס ליישוס תקן זה בסביבת פיתוח תוכנה שגרתית. יותר ויותר פוניס המפתחים אל שיטות פיתוח פחות שגרתיות, שתאפשרנה להס להשיג סבב מהיר יותר ופריון גבוה יותר. טכניקות כגון שימוש באבטיפוס ובפיתוח מוכוון- עצמיס עלולות לאיים על מערכת ניהול איכות המתבססת על תהליכים שגרתייס; או מאידך, מערכת ניהול איכות תגרוס לדיכוי האלמנטים החדשנייסם של הגישות המהפכניות לנושא הפיתוח. האס יש מקוס למציאת פשרה בין השתיים! פרקים 7, 8, 9 ו- 10 חוקרים סוגיות אלו. איכות תוכ(ה - עוכדות התייתם תוך כדי עיוו בפרטים, מן הראוי שלא נתעלס ממספר עקרונות יסוד המאגדים את השאיפה שלנו להנדסת תוכנה יעילה, ואת הדאגה לאיכות. מערכת איכות לפיתוח תוכנה שהיא גס מעשית וגס מציאותית חייבת להתייחס לעקרונות בסיסייס כדוגמת העקרונות של איכות התוכנה שהצגנו, ועקרונות הנדסת התוכנה שהוצגו בפרק 1. בפרקיסם הבאים נשתדל לזהות ולתאר את האלמנטיס הדרושיס כדי שנוכל להיצמד בפועל לעקרונות שקולים, יחד עס תאימות לתקן של מערכת ניהול איכות. עקרונות איכות תוכנה 1. נוהלי איכות אינס יכוליס להשיג דבר, אלא אס כן תיישמס בפועל. 2. השינויים בלתי נמנעיס, בעיקר בתחוס הדרישות. הבא אותס בחשבון בעת התכנון! 3 פיתוח תוכנה הוא תהליך איטרטיבי, תכנן תמיד לקראת חזרה על פעולות. עדיף ומהיר יותר להכין טיוטה מהירה שממנה יסולקו השגיאות בהמשך, מאשר לנסות להגיע לתוצאות נכונות כבר בסיבוב הראשון. 4. ייתכן שהפקת תוכנה באיכות טובה נמשכת זמן רב יותר, אך תוכנה זו אכן תפעל כאשר תגמור לבנותה, ותוכל גס לשנותה כאשר תצטרך לעשות זאת. 5 קל ומהיר יותר להפיק מסמכים או קוד באמצעות תבנית מאשר בלעדיה, ואין בכך כדי לפגוס ביצירתיות שלך. פרק 2: מערכות לניהול האיכות | 55 6. סקרים עולים זמן וכסף, אך הס יכוליס לגלות שגיאות יקרות מאוד, כאשר תיקון השגיאות האלו הוא עדיין זול יחסית. 7 כלים וטכניקות עולים כסף רב. ללא הדרכה מתאימה הס רק צעצועים, ואפילו צעצועים יקרים מאוד. 8 אם אין ביכולתך לתכנן ניסוי עבור מפרט מסוים, יהיה זה נבון יותר אס לא תעצב אותו כלל. 9. מפרטי בדיקות הנכתבים ממש לפני ביצועם, יבדקו את התוכנה שכתבת, במקוס שיבדקו את התוכנה שהיית אמור לכתוב. 0. הבדיקות יקרות וגוזלות זמן. כשלונות במתן השירות יקרים יותר, גוזליס זמן רב יותר, וגם אינס אהודיס על הלקוחות. 1|. הלקוחות אומריס תמיד שהם רוצים את התוכנה כבר מחר. מה שהס אומריס בפועל הוא, שהס רוצים את התוכנה בהקדם וכי הס רוציס שהיא גס תתפקד. 2. פיתוח תוכנה ללא תוכניות עבודה, הוא תמיד יותר משעשע ויותר מרגש, כל עוד אינך צריך לחשוש מפני הבעיות בפניהן תעמוד כאשר תמסור (אי פעם) את המוצר. -- םש תת חק רה 6 ניהול איכות תוכנה ח ל ק ‏ 2 -- 0 יישוס ניהול איכות תוכנה באמצעות 9000-3 150 חלק 2 של הספר עוסק באיכות התוכנה בסביבה 'קווית'. אף שיש לצפות לכך שבשלב כלשהו יהפוך פיתוח התוכנה לבעל אופי איטרטיבי, כלומר תהליך הכולל בתוכו חזרות בספר זה אנו מגדירים את הפיתוח ה'קווי' בתור מחזור חיים של פיתוח שהוא ברובו המכריע בעל אופי רציף. מחזור החיים הקרוי 'מפל המים' הוא דוגמה לכך. אחר כך נעמת גישה (מסורתית) זו מול פיתוחים 'לא-קוויים', בהם מחזור החיים מאגד חזרה (איטרציה) משמעותית בתוך התהליך הבסיסי. מחזור החיים הספיראלי הוא דוגמה לגישה לא-קווית טיפוסית. מטרת חלק 2 היא לקבוע כיצד ניתן ליישם את הקווים המנחים של 9000-3 150 לתחום פיתוח התוכנה ולספק :יעוץ שימושי בדבר יישום אפקטיבי של מערכות לניהול איכות תוכנה. חלק זה של הספר מחולק לשלושה פרקים: 0 פרק 3: ניהול איכות, סיכונים ופרויקטים 0 פרק 4: תהליך הפיתוח הבסיסי 0 פרק 5: לב מערכת האיבות כל פרק בנוי לפי תבנית דומה: תחילה אנו בוחניס את הסוגיות הראשיות שיש לדון בהן; אחר כך מעייניס בקו המנחה של 9000-3 150; ולבסוף מגישים ייעוץ שימושי בדבר הדרך ליישום אפקטיבי. פרק 3 שוקל את הסיכונים המאיימים בדרך כלל על פרויקטים של תוכנה ומציג דרכים להימנע מהם, או להתמודד איתם. תכנון האיכות הינו חלק בלתי נפרד מתכנון הפרויקט ומוטבע בדיסציפלינה הכוללת של ניהול פרויקטים. פרק 4 מתבונן בתהליך פיתוח התוכנה עצמו, ושוקל את הסוגיות העיקריות הכרוכות בהמרת תהליך זה לתהליך הניתן לשליטה. מכאן מוליכה הדרך לדיון מסוים בקטע הגדול יותר של 9000-3 150. פרק 5 שוקל את המבנה של מערכת לניהול איכות, כדי לוודא שלא רק הסוגיות שמצאו את ביטוין בפרקים 3 ו- 4 יזכו לטיפול נאות, גם המערכת הכוללת תהית נתונה לבקרה עצמית, לתחזוקה עצמית ואפילו לשיפור עצמי. לכשתסיים את חלק 2, אתה אמור להיות כבר בעל ידע מעשי בתקן 9000-3 150, ולהבין את מה שהקטעיס הראשיים שלו מנסים להשיג. אתה אמור גם להיות מסוגל ליישם מערכת לניהול איכות שתעמוד בדרישות לגבי מחזור חיים קווי שגרתי. הגישות הלא-קוויות יידונו בחלק 4 של ספר זה. רעיונות המפתח של חלק 2 מוצגים בתרשים ח.2.1, מפה של תפיסה כללית. 2 57 2קלח‎ 1 8 ניהול איכות תוכנה תרשים ח.2.1 דוגמה למפת תפיסה כללית של החלק השנני ד--ו ----7 יר לש איז ---05 "ו 5 עשטוסטטוו6וא 2 % **., % ב מא *.. י | פפטסטזט ., % 4 ב 7" ש|סעס 1.06 וו - 0 . ו / 6 / 7 א ו . ל ה]זטוה 0 ה ץ / 0 6 % ה %" 7 2% 2 ו ו / 0 6 ל סד אאוטו/ט / בה "2 = ה , , - , , - 0 .2 / אסא וא"., וז ו , 0 ש << ו ] 6 55 555ם הסווב0ו[ג . וח9%16 % -י כץ "אטואץס.וטטטס /2--. 9% 2 ו[ עשוי 7 כ 9 ו יש יח | , ----ררדיופו 4 -- ...| שחווגטיך / שי א, שר 4 0 606 2-ורוידללה 2 : גי בוו = , ₪ > % 0 א - = 4 % 2% / / .5 / חסווסב וט בשש נוי 4 1 "א בול 5 0 ן 9 הדירי 600 100 210560) ב / כ ו לחוה 0 2 ו [ ה ' אי 1 - 4 4 א 2% ור ו היח '-י- ה 7 0 7 היחה -. ותו 2 1-ו ב . 0 ער באל 07 3 פכק 34 ניהול איכות, סיכונים ופרויקטים מבוא מה גורם לכך שפרויקטים של תוכנה משתבשים תמיד? כל כישלון מלמד אותנו דבר מה, אבל נוצר רושם שתמיד מופיעות דרכים חדשות שמוליכות שוב לקראת כשלונות. האם כשל זה הוא בלתי נמנע? האם פרויקטים של תוכנה סתם כך קשים ומורכבים, עד שבני אדם אינם יכולים לשלוט בהם? ייתכן, אך בינתיים טרם הגענו לנקודה בה מסקנה זו תהיה בלתי נמנעת. למען האמת, עלינו להודות, שכמעט לא התחלנו לנצל את הטכניקות העומדות לרשותנו. בסופו של דבר, ההצלחה תבוא כתוצאה מכך שנבין בדיוק את מה שנדרש מאתנו, ומכך שלצורך השגת הדרישות, נשתמש בתהליך מוגדר בבהירות ומובן היטב על ידינו. אם נתמודד עם פיתוח התוכנה בצורה שיטתית, לפחות נוכל להפריד בין הדברים שאנו מכירים לבין אלה שאינם ידועים לנו. את הדברים המוכרים אפשר לעבד לכלל תוכנית פיתוח, והדברים הלא ידועים יאפשרו לנו להעריך את הסיכונים, ולנסח דרכים לצמצומם במסגרת תוכנית איכות. הצעד הראשון לקראת ההצלחה מותנה ביכולת שלנו לשזור יחד שני מרכיבים אלה שבכל פרויקט. (יתוח הסיכות לכישלון פרויקטיפ מה הדבר שמשתבש בפרויקטיס התכנות שלנו! כידוע, אין גבול לכושר ההמצאה של האדס, אך עס זאת יש כמה הסבריסם שכיחים לכישלון. ניתוח אירועים פשוט :וכל לסייע לנו לגבש במקצת את קו המחשבה. תרשיס 3.1 ממחיש את אחת השיטות השכיחות יותר שמבטיחות כישלון. הבה נבחן את הפרויקט שלב אחר שלב. פדק 3: סיכונים ופרויקטים | 59 7-ה 0 50 1 6טזך 'עסקגתי 60166סזק ץק וחפווחווק0 - 1 !6 -2 5 --3 זו3ק6 -4 וחפוסוחץ6 - 5 חסוו 693 -6 ד ו 4 5 6 68 |6זגך שו ץז6ט[06 ץזטעו|06 תרשים 3.1 פרויקט תוכנה טיפוס: שלג 1 - אופטימיות שלב 1 מתחיל כשמתגלה לקוח שיש לו דרישה הנראית לנו מוכרת במעורפל. ההיכרות היא כזו שמאפשרת לנו לשכנע את עצמנו שיש ביכולתנו לספק את הדרישה במתיר תחרות: ביותר, ובלוח זמניס צפוף למדי. לחילופין, על מחלקת טכנולוגיית המידע (ד]) של חברה כלשהי הוטלה המשימה להשיג מערכת מידע ניהולי (15/א) שהיא חיונית להישרדות החברה; האספקה חייבת להיות בלוח זמנים צפוף מאוד יבגלל סיבות עסקיות קריטיותי. בשלב זה יש רק מעט מאוד מידע מכדי שאפשר יהיה לקייס ניתוח מלא של הדרישות, ונראה שאין מנוס מלקבל החלטה בהקדם שיש להתחיל בפעולה. הדאגות המושמעות על ידי הסגל הטכני אינן זוכות לתשומת לב, משוס שאלה תמיד משמיעים קולות דאגה בשלב זה, אך לעולסם אין הס יכוליס לבסס את דאגותיהס על איזו שהיא טענה מוגדרת. היחס אליהס הוא כאל אנשיס המייצרים מראש תירוציס לכישלון העתיד לבוא. מתקבלת החלטה להמשיך במשימה. שלג 2 - התפכחות במשך שלב 2 מתחילות להתגלות הדרישות האמיתיות, והערכות גסות מרמזות על מועד אספקה ועלות שיחרגו בכ-50 אחוז מההערכות המקוריות. תתזית זו מבוססת עדיין על מידע לא שלס ותוכניות שהושלמו רק בחלקן, אך היא כוללת כבר מרוות ביטחון נכבד עבור סיכונים שטרס זוהו, והקצאה משמעותית עבור אבטחת איכות 0 ניהול איכות תוכנה ובדיקות. בהתחשב במידת הערפול של התוכניות, אין ההנהלה משוכנעת שהיעדיס ההתחלתיים אינס ניתניס להשגה. בהתחשב בכך שמלכתחילה הקצינו חלק גדול מהמאמצ (קרוב ל-20 אחוז) לאבטחת איכות ולבדיקות, סיכונים בלתי מוגדריס נמחקיס מרשימת השיקוליס שיש להביא בחשבון. שלב 3 - תקוות לאחר מנת היתר של ההתפכחות בשלב השני, מוכן צוות הפרויקט להתארגן לעבודה בסביבה נוחה יותר. כעבור זמן הס שוכתחיס את כל ההתרגזויות ומתחיליס להאמין שאכן יש להס סיכוי להגיע למטרה. התֶּיכגּן מתנהל פחות או יותר כשורה, והערכות הזמן והעלויות מתבייתות על היעד הרצוי. מתחילה הצטברות של דחיות פעוטות ובעיות בתֶיכוּן, אך בכוח ההתלהבות מצליחיס לשמור אותן בתוך המסגרת, עד למועד שמנהל הפרויקט מתחיל לחשוד שהעבודה שעדיין נותרה לא-בדיוק תתאיס למסגרת : הזמן העומד לרשותו. מאידך, אין הוא יכול להאיץ את הפרויקט מבלי להגדיל את ההוצאות מעבר לתקציב שממילא כבר מתוח למדי. הוא מתריע בפני ההנהלה. שלב 4 - ייאוש ההנהלה ציפתה למתקפת הייאוש של מנהל הפרויקט. הס מרגיעים אותו ואומריס לו שהס עומדיס מאחוריו ויש להס אמון ביכולתו להשליס את הפרויקט בזמן ובמסגרת התקציב. יתרה מזאת, צפוי לו פרויקט משמעותי יותר כאשר יסייסם את הפרויקט הנוכחי. מובן שאם הפרויקט הזה אמנס יתדרדר, לא כל כך בטוח שצפוי לו פרויקט אחר אחריו. בינתיים, ביקורות התֶּיכּן ממשיכות לחשוף פגמיס עד שמפסיקיס את הביקורות כדי לחסוך בזמן. התוכניתנים, שרוצים להפיק יותר קוד ומהר יותר, חוזרים להשתמש בטריקיס של תכנות החביביסם עליהם. הניפוי נמשך קצת יותר זמן מהצפוי, עד שמגיע הרגע שבו נמסר הקוד למחלקת אבטחת האיכות, מספר ימיסם לפני המתוכנן. מסתבר שצוות הפרויקט לא הספיק לבדוק את כל התוכנה, אך הזמן והמאמץ שהושקעו בניפוי, מראים את נחרצותס בחיפוש השגיאות. יש עדיין מספר דיווחים על בעיות פתוחות, אך אלו יתבהרו עוד לפני מועד האספקה. במשך היומייס שהוקצבו לה לבדיקות מגלה מחלקת אבטחת האיכות 20 שגיאות קשות. מתקבלת החלטה לשחרר את התוכנה, בעיקר לאור העובדה שהבעיות הפתוחות כבר טופלו בינתייס (אס כי לא נבדקו במלואן). התוכנה מסופקת, כולל היתיקוניסי האחרוניס שהוכנו על ידי צוות הפרויקט ואשר מחלקת אבטחת האיכות טרס ראתה. שלב ל - גיגיות התוכנה נמסרת, אך לא מצליחיס להתקינה. כעבור יומייס מצליח צוות ההתקנה, המונה שלושה אנשיס, לפתור את הבעיה והמערכת מותקנת בהצלחה. המערכת פרק 3: סיכונים ופרויקטים | 61 וו ינופלתי מיד לאחר שנמסרה למשתמשים לעבודה. צוות מומחיס נשלח למקום ומקדיש שלושה ימיס לליבון הבעיה. בהתחשב בתנאיס ובדחיפות המצב, לא מעדכנים את התיעוד ומכניסים את היתיקוניסי לתוך הקוד ישירות. מתחילים בעיבוד חוזר של המוצר, כדי להתגבר על אחדות מהבעיות שהתגלו בימי ההפעלה הראשוניםס. במשך תקופה של שלושה חודשיס, עסוק צוות הפרויקט אך ורק בקיוס מצב עבודה של המערכת. מאחר שהס פועלים תחת לחץ לא רגיל, מוותריס להםס על משימות לא חיוניות, כגון בקרת התצורה ותיעוד. לאחר חמישה חודשי עבודה, הלקוח מסכים שהתוכנה עונה על דרישות המפרטים המקורייס ומתאימה לפעולה. התוכנה נמסרת רשמית. שלב 6 - פיטורין מנהל הפרויקט נתבע להגיש את התפטרותו. רוב חברי צוות הפרויקט מתפטריס כדי לעבור לבית תוכנה אחר, שבו הס מאמיניס, המצב יהיה שונה. צוות התחזוקה משליס עם הצורך לצאת למסלול כבד וממושך: הטמעת אוסף הדרישות לשינוייסם בתוך התוכנה הלא-מתועדת, והתצורה הלא-ידועה המבוססת על תֶיכגּן ימקוצצי. כדי לפצות על המאמץ הנוסף שהושקע בפרויקט זה, מוצא מנהל המכירות פרויקט אחר שניתן לטפל בו בקלות, כהרחבה קלה יחסית של הפרויקט הקודס ומסכס על מחיר טוב המבוסס על אספקה מהירה, וחוזר חלילה. מה השתבש כאן החברה הדמיונית באירוע שלנו, הכניסה את עצמה למעגל קסמיס מוכר היטב. לדאבוננו, התנאים המוליכים למעגל זה שכיחים למדי. לעיתים תכופות הלחצים המסחריים מאלצים אותנו להיכנס למצביס שבהם אנו מעדיפים לקבל את אפשרות הכישלון בתור המחיר שנשלם עבור הצלחה אפשרית בעתיד. מעגל הקסמים מתהדק באמת כשאנו מעדיפים להתעלם מהבעיות, או מעמידים פניס כאילו אנו שולטים במצב. כיצד נמנעים מסיכוניס ממין זה! על ידי הקדשת תשומת לב נאותה לתהליכי ניהול פרויקטים ופיתוח תוכנה. הבעיות שזוהו בעת ניתוח פרויקט שנכשל ישמשו כבסיס התחלתי ליצירת קבוצת דרישות בסיסית לתהליך ניהול פרויקט, שאליה נוכל להוסיף עכשיו קטע בדבר ניהול סיכוניס. ---7-]-]-]-]-]------------------ ויו ויוי עשרה סיכונים מיותרים בפרויקט תוכנה ---7]7]7]7]7 ₪ 6 ו [. אין בידינו ידע מספיק על עסק הלקוח, שיאפשר לנו להבין את ציפיותיו במלואן. 2 איננו מנתתיס ומתעדיס את הדרישות די הצורך. 3 איננו מקיימיס בקרה רשמית מספקת על השינויים בדרישות. 2 ניהול איכות תוכנה = איננו מתכנניס תכנון מציאותי. אנו מרשיס לעצמנו להיות מונעים על ידי האירועיס. כאשר אנו נמצאיס תחת לחץ, איננו נצמדים לדיסציפלינות שקבענו לעצמנו. איננו מזהיס את כל הבעיות הצפויות ואיננו מטפליס בהן. איננו מקיליס על הגשת דיווחיס על בעיות. 5 6 7 8 איננו מקדישיס תשומת לב מספקת לסימניס המעידיס על בעיות. 9 איננו מגדיריס באופן ברור את תחומי האחריות. 0 [. איננו דואגיס לעדכן את כל חברי הצוות בהתקדמות הפרויקט. במילים פשוטות, איננו מעריכים את כל הסיכונים הנלווים לפרויקט, ואיננו מתכננים כיצד להימנע מהם או לצמצמם. , (יהול סיכוניפ פיתוח תוכנה, בדומה לכל פעילות יצירתית, מכיל בחובו וודאות של עשיית שגיאות. שגיאות המתגלות, מוליכות בדרך כלל, לחזרה מסוימת על פעילויות כדי לסלקן. עבודה נוספת זו, שנגרמת עקב תקלות, גורמת לאיחור בביצוע הפרויקט, אלא אס תוכננה מראש אפשרות זו והוקצה זמן לעבודות חוזרות. במקרה שהפרויקט מבוסס על מועד אספקה מוגדר, או שהוא מוגבל לתקציב מסוים, העבודה התוזרת עלולה לאייס על עמידה מוצלחת ביעדי הפרויקט (שגיאות שלא נגלה, יועברו בירושה ללקוחות ולמשתמשים, ואלה לא יאחרו לגמול לנו על כך). כדי למנוע מצב של חריגה בתקציב וגלישה בלות הזמניס צריך לפעול להערכת הסיכוניס וטיפול בחריגות. זהו ניהול סיכונים (1ח6וח886חגוח 315%). עבודה לא מתוכננת (כלומר, מטלות שיצורפוי במהלך הפיתותח, ללא תכנון מוקדס) משמשת דוגמה לסוג הסיכון המשותף לרוב הפרויקטיס של פיתוח תוכנה; סיכון זה הוא אחד הרכיביס המציאותייס של התכנון שהזכרגו בסעיף הקודס. צפוי שיופיעו גס סיכוניס אחרים, רביס מסיכונים אלה קיימים, במידה קטנה או גדולה, בכל הפרויקטים. מהס סיכוניס אלה! סיכונים שכיחיפ שיש להישמר מפניהפ סיכוניפ שמקוופ בלקוח >= דרישות בלת: ידועות, או לא מובנות במלואן; + דרישות מעורפלות, אך ציפיות גבוהות; >= העדר תחושת בעלות: האחריות מושארת למפתחיס; פרק 3: סיכוניס ופרויקטים ‏ 63 / 4 .= פיגוריס בהגדרת מידע קריטי; = שינויים תכופים של הדרישות ; .= מחיר המבוסס על ניתוח לא שלס של הדרישות. סיכוגיפ שמקוופ במפתחים = הגדרה לא מספקת של מוצרים מוגמרים ; = <ותר מדי חדשנות בדרישות. ניסיון להטמיע יותר מדי תפיסות חדשות; >= עובדים שאינס די מאומניס ומנוסיס לביצוע הפרויקט; + צורך בכלים ו/או בטכניקות מיוחדים שאינס זמיניס כרגע; = שיטות ו/או כלי פיתוח שאינס הולמיס את המשימה הנוכחית. סיכוניפ שמקורפ בתכנון > לא קייס תכנון לאימות ולבדיקת התקפות ; * לא הוקצו משאביס עבור עבודה חוזרת (%ז0ש6ז) ; + לא הוקצה די זמן לפיתוח; + התוכניות מבוססות על ציפיות הלקוח, ולא על יכולת המפתחיס לספק את המוצר, או המוצריס ; > לא הוקצה די זמן לבדיקות. יש צורך לסלק, או לטפל בכל מה שיכול לאיים על הפרויקט, כדי לוודא שמשעה שנתחיל בפעילויות הפיתוח, נוכל לעמוד בהצלחה ביעדים. ייתכן שאופי האיומיס האלה ימנע את האפשרות להבטיח סיוס מוצלח, וייתכן שעלות סילוקם של כל הסיכונים תהיה גבוהה ביותר. לעומת זאת, היתרונות הצפוייס מהצלחה מלאה של פרויקט מצדיקיס הוצאה מסוימת על צעדיס שמטרתם צמצוס הסיכוניס. עלינו לבחור באסטרטגיה כזאת : * שתזהה, תכמת ותתריע בפני כולס על הסיכוניס שאנחנו צופיס שיהיו; * שתסלק או תצמצם בצורה משמעותית את הסיכונים שמהוויס את האיוס הגדול ביותר; *= שתאפשר לנו לבקר ולשלוט בסיכונים הנותרים ; + שתקיים לעיתים מזומנות סקירת מצב הסיכוניס. אסטרטגיית ניהול סיכונים מעשית תזהה את כל הסיכוניסם המהוויס את האיוס החמור ביותר על הפרויקט. לגבי כל סיכון, עלינו לתכנן צמצוס אפשרות הופעתו, או צמצוס השפעתו עד לרמה נסבלת, במקרה ולא ניתן למנוע אותו כליל. הבחירה בין הימנעות מוחלטת מסיכוניס, לבין הסתייעות בתוכניות לשעת חירוס לטיפול בסיכוניס אלה, מותנית בממדים ובאופי של כל סיכון וסיכון. מה שאסור לעשות הוא להתעלם מסיכונים, או לקוות שהס פשוט לא יקרו. יש מקוס להתלטה שלא ניתן לסלק או 4 ניהול איכות תוכנה לטפל בדרך נאותה בסיכון מסויסם. עס זאת, עלינו להיות מודעיס לקיומו, כדי שנוכל לעקוב אחר המצב ולקבל החלטות מושכלות על הדרך בה ננהג במקרה שיחולו שינוייס בנסיבות. יש לצפות שניהול הסיכוניס ינקז חלק ממשאבי הפרויקט לכיוון של נקיטת צעדיס הגנתיים: הדבר עשוי להקטין את הפריון, להגדיל עלויות או לחייב את צמצוס הדרישות. האסטרטגיה שנאמץצ, חייבת להיות גס קבילה וגס כזאת שתוכל להגדיל במידה משמעותית את סיכויי ההצלחה של הפרויקט שיותאס לנסיבות. , אמאופ הסיכונים - תכנגון האיכות תכנון האיכות הוא 'הצד השניי של תכנון הפיתוח. בשעה שתוכנית הפיתות יוצרת מתודולוגיה לסיוס מוצלח של הפרויקט, תוכנית האיכות מחפשת לסלק, או לקזז את כל ההשפעות הפועלות בניגוד להשלמתו המוצלחת. ניתוח הסיכונים המתבצע כחלק מתכנון הפיתוח אמור לזהות כל איוס אפשרי לסיוס מוצלח של הפרויקט. תוכנית האיכות חייבת להיכנס לפעולה נגד כל אחד מהאיומים האלה. במקריס רביס, האיוס הראשי על כל פרויקט, הוא האיוס של תוהו ובוהו ואי-סדר. אי ודאות בדבר דרישות הלקוח או של יעדי האיכות, עלולה להוליך לדיסהרמוניה, בעוד אחדיס מעובדי הצוות ממשיכיס לשקוד בתריצות על השגת מה שנראה להסם כיעדיס הלגיטימיים של הפרויקט. בדיקות חיוניות ופעולות ביקורת עשויות שלא להתבצע, משוס שלא נקבעה האחריות לביצועם. דברים אלה נכוניס במיוחד במצביס בהס נתון הפרויקט בלחץ, וביצוע בדיקות וסקירות מייצגים מחסומיס בדרך למסירתו של קטע תוכנה שאספקתו התאחרה. משוס כך, המשימה הראשונה של תוכנית איכות היא לוודא את זמינות הדרישות, יעדים, ותחומי אחריות. משימה זו צריכה לכלול את הצורך לשקול בקפדנות את האסטרטגיה של האימות ובדיקת התקפות, תוך הבאה בחשבון של הסיכוניס הטכניים המזוהיס. תוכנית בדיקות הנבנית בשלב מוקדס זה, יכולה לאפשר התייחסות לכל הסוגיות הקריטיות לפני שיחל המרוץ נגד הזמן, עליה להגדיר גישה לנושא הבדיקות שתגדיל את הסיכוייס לאספקת מוצריס באיכות מניחה את הדעת. תוכנית האיכות מונעת תוהו ובוהו ואי-סדר משום שהיא מוודאת שכל מקרה, צפוי או בלתי צפוי, יימצא בתחזם האחריות של מישהו מאנשי הצוות. קיימות דרכיס למדד בדיקות, כגון יחס של כל משפטי הקוד שעברו כבר את הבדיקות, או מספר הפונקציות שצריך לבדוק בנפרד. יש באלה כדי לסייע לכימות רמת הבדיקות הנדרשת. התוכנית שהוכנה מראש היא הדבר הראשון שאנו יכוליס להסתמך עליו, במקרה שבמועד מאוחר יותר מתתיל הלחץ להוות בעיה משמעותית. במקרה שהלתצ נעשה כה גדול, עד כדי פיתוי לנטילת סיכונים, כגון צמצוס מספר הבדיקות המתבצעות, נוכל להסתייע במדידות אלו שתאפשרנה לנו לכמת את גודל הסיכון שאנו נוטליס על עצמנו. פרק 3: סיכונים ופרויקטים | 65 עובד המבצע את הבדיקות ומגיב על הדרישה לקיצוציס בתלונה בלבד שלא ניתן לו מספיק זמן לצורך זה, אינו מספק למנהל הפרויקט נתונים בדבר מידת החוכמה או האיוולת שבקיצוציס אלה. לעומתו, מבצע בדיקות המציין שהושלמו 57 אחוז מהבדיקות הפונקציונליות המתוכננות, אך אלה כללו רק 49 אחוז של הקוד, וכי במשאביס הקיימיס ניתן יהיה להשלים את שאר הבדיקות תוך 17 יוס, או תוך 12 יום במקרה שיוקצה לו עובד נוסף, יזכה למלוא ההקשבה והפתיחות של מנהל הפרויקט על האסטרטגיה היעילה ביותר שיש לנקוט בשלב זה של הפרויקט. האיוס השני המשותף לכל הפרויקטים הוא ההשפעה של שינויים בלתי מבוקרים. שינוייס יחולו תמיד בכל פרויקט תוכנה. תוך כדי התקדמות הפרויקט צפויות להתגלות דרישות שאינן שלמות, או שאינן נכונות; עלוליס לחול שינוייס בהבנת האופי האמיתי של דרישות המזמין; שגיאות שהתגלו בזמן הפיתוח, מתוקנות וגורמות לפעמים ליצירת שגיאות חדשות. כל אלה מהוויסם מרשס לשינויים תכופיס ומפליגים. בהעדר בקרה קפדנית, אנו עלוליס לגלות שחלקיס שוניס של המערכת אינס תואמיס עוד, או שחלקיס של המוצר המוגמר אינס תואמיס את הדרישות הנוכתיות. משעה שנפגמת יכולת המעקב והקישור בין הדרישות לבין המוצריסם המוגמרים, תהיה ההתאוששות קשה יותר. משימתה השנייה של תוכנית איכות תהיה אם כן, לוודא שכל שינוי יהיה מבוקר, בין אם מקורו בפגמים, ובין אס מקורו בדרישות חדשות. כדי לעשות זאת תצטרך התוכנית להגדיר את הכללים ואת תחומי האחריות לגבי שינויים מכל הסוגיס. איוס שלישי נובע מהחדשנות ומהמורכבות. אם הפרויקט מכיל אלמנטים חדשים עבורנו או מורכביס מאלה שעסקנו בהם לפני כן, יהיה עלינו לנטר את הפרויקט ביתר זהירות ולעיתיס תכופות יותר, כדי לוודא ש'איננו סוטיס מהמסלולי. פעילויות אימות נוספות, כגון סקירות ובדיקות, עשוייס להידרש כדי לספק את נקודת המבט הנדרשת, ואת אלה יש לכלול בלוח הזמניס של התוכנית. משימתה השלישית של תוכנית איכות היא לוודא שהתוכנית תהיה מציאותית בכל האפשר. חייב להיות ביטחון מלא שניתן להשלים את הפרויקט בהצלחה, במסגרת הזמן והמשאביס שהוקצבו בתוכנית הפיתוח. אחרת יש חשש שתוכנית הפיתוח תאבד במהרה את אמינותה ויתעלמו ממנה. משימה נוטפת, אחרונה, של תוכנית האיכות היא תיעוד כל סיכון אחר שלא נדון קודס לכן וזיהוי אסטרטגיית ניהול הסיכון הנדרשת, או מניעתו. ייתכן שנחליט לא להכין תוכנית פעולה לגבי כל אחד מהסיכונים, אך עס זאת, עלינו לנהל מעקב אחר כל הסיכוניסם בהס החלטנו לא לטפל, אחרת הס עלוליס לבצבץ ולפגוע בעיתויים הפחות צפוייס. שימת מחטום לסיכונים היא מרכיב יסוד של תוכנית איכות. 6 ניהול איכות תוכנה .========= 7 מה צריכה להכיל תוכנית איכות טובה 1 .0 כללים ותחומי אחריות, בעיקר אלה הכולליס אחריות וסמכות, כגון: 0% סמכות להגדרת דרישות. 0 סמכות לביצוע תָיכון. 0 סמכות להרצת בדיקות ולשילוב (מ10ז6918זחו). בדיקות ייתכן שתהיה תוכנית בדיקה נפרדת עבור פרויקטיס גדוליס יותר, אך צריך לנסת כאן את אסטרטגיית הבדיקות הכוללת, בתוספת המדדים שישמשו לקביעה מתי אפשר לקבוע שהמוצר נבדק די הצורך. ניהול התצורת ייתכן שתהיה התייחסות לתוכנית נפרדת. יש צורך להגדיר את המנגנון הבסיסי של זיהוי ויכולת המעקב, וגם את נהלי בקרת השינוייס. דיווח בעיות ותקלות יש להגדיר לכל העובדים את השיטות בהן יש להשתמש כדי לדוות על בעיות ותקלות שונות. מדדים צריך להגדיר את כל המדדיסם שישתמשו בהס עבור המוצר או תהליכי הפיתוח. יש להסביר לכל העובדים בפירוט מספיק את איסוף הנתוניס הדרוש, כדי לוודא שהבינו את שנדרש מהם. אישוריס יש לקבוע את האנשיס שתוענק להס הסמכות לאשר את כל מסמכי הפרויקט. סיכונים לצורך ידיעה והנחייה של העובדים, יש לכלול רשימה של כל הסיכוניס הכרוכים בפרויקט ושל אסטרטגיות הניהול שיש לנקוט. כך אפשר לוודא שהעובדים לא ייכנסו לתחומי סיכון לא מתועדים, שאין עבורס תוכנית מילוט מתאימה. יעדי איבות יש להגדיר את היעדים שנקבעו למוצרים המוגמרים, יחד עס הגדרות של דרישות איכות כלליות, כגון רמת הבדיקות המזערית הקבילה לגבי הפרויקט. קריטריונים ותוכניות למבחני קבלה יש להגדיר את הקריטריונים שנקבעו למבחני הקבלה, ולכלול התייחסות לתוכניות הבדיקה של מבחני הקבלה. תאריכי מפתתח יש לזהות ולהגדיר את אבני הדרך הראשיות. פרק 3: סיכוניס ופרויקטים 67 []. סקירות חוזרות יש להגדיר את המדיניות לגבי סקירות חוזרות של המסמכים והקוד, בנוסף לכללי התנהגות. 2. הרצות נסיוניות על ידי המשתמש בכל מקרה שהפרויקט כולל הרצות נסיוניות על ידי המשתמש, יש להגדיר את הדרישות ואת התוכניות שהוגדרו או אוזכרו לצורך זה. 3. כללי עיצוב וקידוד יש להגדיר או לאזכר את הכללים והנהלים עבור כל פעילויות התִיכוּן והקידוד. הגהרה מַלאה של הדרישות עד כה עסקנו רק בניהול הפרויקט, אך לא בהגדרתו. דיסציפלינת הניהול יכולה להיות מעולה ככל שתהיה, לעולס לא תוכל להצליח, אלא אס יהיה המאמצ מכוון כהלכה לקראת היעד. זו מטרת ניתוח הדרישות. עלינו להכין תיאור בהיר ושלס של הציפיות הלגיטימיות של הלקוח, הפונקציונליות והבלתי פונקציונליות, ולתעד אותן בצורה תמציתית, בהירה, ועקבית, רק כך הלקות יוכל לאשרן ולפעול על פיהן. אנחנז חייבים להאזין ללקוחות ולהשתמש בשפתם. לדוגמה, הגדרת המילה 'באיחורי יכולה להיות בעלת חשיבות עילאית. קאמרון לאו (1993 ,0% הגדות תפקוד המוצר יש דרכיס רבות להגדרת הדרישות. הכליס המשמשים לכך יכולים לכלול, החל מניסות מילולי בלתי מובנה, עד לשפת מפרטים רשמית, או ממסמכיס שבכתב עד לאבטיפוס דינמי. קיימים כמה קריטריונים חיוניים להשלמת פעולת ניתוח הדרישות, מבלי להתייחס לדרך בה מתבצעת המשימה. קריטריוניס אלה כולליט : קיוס רישוס קבוע כלשהו, אשר יכיל את הדרישות המוסכמות, ושישמש בסיס להסכמה על מה שצריך ולא צריך להיעשות ; * מזהה ייחודי של גרסת הדרישות המוסכמת, כדי שאפשר יהיה לעקוב אחר שינוייס בדרישות על ידי יצירת סדרת גרסאות חדשות, המייצגות מצב חדש של הדרישות; * קבוצת קריטריונים לקבלת המוצר, שישמשו בסיס להסכמה על מה שנחשב כקביל בשלב המסירה. 8 ניתול איכות תוכנה המשימה הבאה, לאתר קביעת קו הבסיס הרשמי, היא ארגון הדרישות להקלת התְּיכוּן, היישוס והסקירה. המפתחים צריכיס להיות מסוגליסם לוודא, שכל הדרישות זכו לטיפול בכל אחד משלבי הפיתוח, ושלא נעשתה, או שלא תיעשה כל עבודה בהיבטיס שאינס כלוליס בקו הבסיס הרשמי. המפתתיסם צריכיס לדעת את החשיבות היחסית של הדרישות השונות, כדי שאפשר יהיה לתכנן את הבדיקות. הבדיקות הן פעילות מדגמית, וצוות הבדיקה ירצה להיות בטוח שהבדיקות המתוכננות מתמקדות בתחומי הדרישות בעלות העדיפות הגבוהה יותר. יש גס ערך רב ליכולת לזהות אילו חלקיס של הדרישות מיושמיס על ידי איזה חלקיס של המערכת. למידע זה תהיה חשיבות מיוחדת במועד מאוחר יותר, כאשר יהיה צורך לשקול את השפעת השינוייס לפני מתן אישור לשינוי כלשהו. הגדרת דוישות האיכות השגת האיכות מותנית בקיוס הגדרה הולמת של תכונות האיכות ובידיעת מימדי כל תכונה. בהקשר זה המילה יהולמת' פירושה אובייקטיבית, ניתנת לכימות ולמדידה. במציאות, רק לעיתים רתוקות אפשר להגיע להגדרה סגורה שאינה מותירה מקוס לספקות. המפתתים נאלציס להתפשר לעיתיסם תכופות על דרישות איכות סובייקטיביות שצורת הצגתן אינה תמיד כה מגובשת. השגת איכות התוכנה היא אס כן פחות ממאמצ מדעי מושלס. הגברת השימוש בשיטות דיסציפלינריות ומובנות, ותכנון זהיר, לצמצוס השפעת סיכוניס ידועים, אינה אלא תחליף בלתי מושלס לתהליך שחייב, בדרך כלל, לספק בדיוק את הנדרש. עס זאת, זו הדרך הטובה ביותר העומדת לרשותנו בשלב זה. מתוך ידיעת מגבלות אלו, חשוב מאוד לשאוף להבנה אפשרית טובה ביותר של הדרישות, לפני שנתחיל לשקול את האסטרטגיות בהן נוכל להשתמש להשגת דרישות אלו. "מוצר איכות': מוצר המבצע את רוב הדברים שאנו רוצים שיבצע, ואשר יש ביכולתנו להשלים עם פגמיו. פאזול הרצליך, ))זוווסשם 6וז6זצע5. (1993 ,30%6) כמה מתכונות המפתח האיכותיות עשויות לפעמיס להשתמע ולא להיאמר במפורש. כאשר תכונות אלו הן ביסוד תרבות המשתמש, ייתכן ולא ניתן יהיה לזהותן בצורה מוגדרת. לעובדת היותן מעין יטבע שניי בקהילת המשתמש, יש כמעט משוס ערובה שהמפתחים לא יבינו אותן במלואן. מאידך, ייתכן שקהילת המשתמש לא תהיה מסוגלת להבין בעצמה את דרישותיה במידה שתאפשר לה להכיר את כל השלכותיהן האיכותיות. בכל מקרה, נטל הזיהוי, כימות ותיעוד הדרישות הבלתי פונקציונליות חל על המפתחים, ויש להביאו בחשבון בעת ניתוח הדרישות. פרק 3: סיכונים ופרויקטים | 69 ורוו לאחר זיהוי תכונות האיכות, חייב המפתח לוודא שהלקוח מסכים עם מה שתועד, וכי יש לו ידיעה ברורה על הדרך בה יתנהג המוצר שיתקבל. כך אפשר יהיה להגדיר מבתני קבלה מתאימים שימדדו את המוצר מול מדד (קריטריון) כלשהו של התאמה, אשר יישקף את ציפיות המשתמש. קבוצת דרישות שסוכס עליה רשמית, חיונית להגדרת המדדיס לקבלת המוצר, ולמבחני הקבלה שישמשו בסופו של דבר, בסיס להסכמה בדבר קבילות המערכת. המפתתיס ישתמשו בדרישות מוסכמות אלו כבסיס לְתָּיכוּן, כך שיהיה להם הביטחון שהם אכן *וצריסם מוצר העונה על ציפיות המשתמשים. גס במקרה שבשלב מוקדם זה, הדרישות מובנות רק באופן חלקי, חובה לקבוע רשמית קו-בסיס ידוע ומוכר, ממנו ניתן להמשיך בפעילות בביטחון. מאוחר יותר, אס וכאשר יחולו שינוייס בדרישות, חייבת להיות אפשרות לעקוב בהצלחה אחר השלכות השינוייס האלה במהלך עבודת הפיתוח המוגמרת, כדי לוודא שלא נתעלס מאחת מהן. בדומה, יש צורך לאפשר מעקב אחורה, אחר שינוייס בתִיכגן, כדי לקבוע אס ומהן ההשפעות שיש לשינוייס אלה על הדרישות. מעקב ובקרה של שינוייס הס היבט חשוב מאוד של ניהול התצורה, וברור שיש צורך במערכת אפקטיבית לניהול התצורה כבר מהתחלת כל תרגיל בפיתוח תוכנה. מתודולוגיה מוגדרת היטב חשובה באותה מידה, כך שאפשר יהיה לעקוב אחר התיכוּן, ולהעריך בדייקנות ובמהירות את השלכות השינוייס. מדידת איכות המוגאר כדי שנוכל לקבוע את המועד בו המוצר יהיה מוכן למסירה, ראוי להגדיר מדדיס של התכונות הצפויות שלו. גישה זו מהווה שיפור רב של מדיניות בדיקות הנמשכות כל עוד אנו יכולים להרשות זאת לעצמנו, ואז לקוות שכשל המוצר לא יהיה דרמטי יותר מדי לאחר המעבר להרצה! רוב המפתחים נוהגים כאילו הם מצפים למשוב שלילי כלשהו מלקוחותיהם, דבר המצביע שהס עצמס סבורים שהאסטרטגיה שלהס היא פחות ממושלמת. קבוצה של תכונות מכומתות, יכולה לספק למפתחים יעד ברור לפעולה, ואף תיתן להס קבוצת מדדיס חד-משמעית לבדיקת המוצר. לדאבוננו, כאשר עוסקים במוצרי תוכנה, קשה מאוד להגדיר תכונות הניתנות למדידה. אם לא די בכך, לא קיימת תרבות מדידה בענף התוכנה, ואלה המבקשיס לכלול את המדידה בתהליך הפיתוח, נתקלים לעיתים תכופות בהתנגדות חריפה מצד ההנהלה, העובדים, וגם הלקוחות. למרות שבעיקרון כולם מסכימיס שמדידה היא דבר טוב כשלעצמו, מעטים מוכנים להוציא כסף לצורך זה. אחת הבעיות שבהנהגת תרבות מדידה, מקורה בחוסר יכולת להשוות בין המדדיס המעטיס שנבדקו על ידי חברות שונות. כל מאמץ מדידה דומה לאי המנותק מכל פעילות מדידה אחרת. כל עוד פעילות המדידה נעשית בקנה מידה קטן, אין תמריצ לשיתוף מידע, אפילו בהגדרות המדידה. בפרק 6 נעסוק בסוגיה זו ביתר הרחבה. 0 ניהול איכות תוכנה דרישות המעקב אחת הבעיות הניצבות בפני המפתחים היא כיצד לוודא שכל הדרישות מטופלות בצורה נכונה תוך כדי תהליך התְיכוּן, כלומר, התִּיכּן עונה על כל הדרישות. לעומת זאת, בעיה לא פחות חשובה היא היכולת לוודא שרק הדרישות בלבד מטופלות על ידי התֶּיכּן - שְהתֶּיכגּן הוא מינימלי, ואינו גולש מעבר לדרישות עצמן. נושא זה יכול להיות חשוב בעיקר במצב של התקשרות חוזית במתיר קבוע, כאשר היתוספות' יכולות לצרוך זמן ומשאביס שלא נדונו בהצעה המקורית. ככל שהפיתוח מסתעף לתחומיס מפורטיס יותר ויותר, יש צורך בשיטה שתבטיח עבודה לאור הדרישות. בכל שלב של התהליך נזדקק לדרך פשוטה שתאפשר לקבוע אס אמנס ענינו על הקריטריוניס החיונייס של שלמות ומינימליות. סקר התוזה הגדרה דקדקנית ככל האפשר של הדרישות אינה המשימה היחידה שעלינו לבצע לפני התחלת הפיתוח. עלינו לוודא שהעבודה תוכל להסתיים לשביעות רצוננו ורצון הלקוחות גס יחד. עבודה המתבצעת עבור לקותח ועל פי חוזה, מחייבת כמובן הגדרה כלשהי של הסיוס המוצלח, שישמש תנאי לתשלום. כיצד נוודא שלא נתקשר בחוזיס שאין ביכולתנו לעמוד בהםס בהצלחה: כיצד יכוליס הלקוחות להתגונן מפני האפשרות שנבטיח להס יותר ממה שנוכל לספק, ובלבד שנזכה בחוזה? מטרת הסקר החוזה היא יצירת בטחונות עבור שני הצדדיס על ידי התייחסות לשאלות מפתת, עוד לפני שהצדדים מקבליםס על עצמס התתייבויות חוזיות. הדרישות והקריטריוניס לקבלת המוצר, עס כל חשיבותם, אינס הסוגיה היחידה. לוחות הזמניס לאספקה :כולים להיות קריטייס ללקות. יש צורך לסכס גם על שיטת ומקוס האספקה. התקנת תוכנה בתחנת כוח אטומית בסיביר, אינה דומה לאספקת כמה תקליטונים באמצעות הדואר. הניסיון מלמד על מספר לא מבוטל של מלכודות הממתינות לאלה שאינסם נזהריס, והמְפַתח החכם ייטיב לעשות אם יפעל לפי רשימה מוכנה מראש של סוגיות שיש לטפל בהן לפני חתימת החוזה. גס ללקוחות של מפַתתי התוכנה יש רשימות משלהם. ברור אפוא, שחשוב מאוד ששני הצדדיס ישקלו את כל הסוגיות שלפניהם, ואף ידונו ויסכמו אותן ביניהס. חשוב לזכור שחוזה נאה ומסודר, המכיל את כל הדרישות שסוכס עליהן בעת הסקר שלו, הוא חריג ולא מצב מקובל. בדרך כלל, נמשכיס הדיוניס בדרישות ובמדדיס לקבלת המוצר, זמן רב לאחר חתימת החוזים. במקרים אלה אנו זקוקיס לדרך שתאפשר מציאת פתרון לקשייס שעלוליס להתעורר, בעת הגדרת הדרישות ,או מאוחר יותר, בעת ביצוע החוזה. היבט חשוב אחד שיש לסכס בעת סקר החוזה הוא המנגנון שבאמצעותו ניתן יהיה למצוא פתרון למחלוקות בנושאים אלה. שמות אנשי קשר שישמשו לתקשורת בין הצדדים, ונהלים להעלאת סוגיות חוזיות ופתרונן. אלה יכוליס להיות חלק משגרת הסכמות שבזמן חתימת החוזה. לעומת זאת, קשה יהיה ללבן דבריס אלה במקרה ויתעוררו סוגיות חוזיות במועד מאוחר יותר. פרק 3: סיכונים ופרויקטים | 71 מספר שאלות שצריכות להישאל בעת סקר החוזה האס אנו יודעיס מהן הדרישות, ומביניס אותן? האס הדרישות כתובות ומנוסחות בבהירות, ומזוהות בצורה נאותה?! האם אנו מצפים לבעיות טכניות כלשהן? האס אנו יכוליס לעמוד בלוח הזמניס! האס יש לרשותנו די משאביס להשלמת הפרויקט בזמן! האס אנו זקוקיס לכלים ו/או לטכניקות מיוחדות כלשהם? האס בוצע ניתוח סיכוניט! האם מינינו איש קשר למגעיס עס הלקוח? ₪9 5 ₪ 5 4 ₪ ספ האם בוצעו או תוכננו סקריס במשותף עס הלקוח? כיעד מטפל תקן 9000-3 90 בסוגיות אלו אחד המשפטיס החשובים ביותר בתקן 9000-3 150 כלול בסעיף תמים למראה (5.1) שנושא את הכותרת 'כלליי. ההנחיה המופיעה בסעיף 5.1 אומרת בפשטות, שפרויקטיס של פיתוח תוכנה צריכים להיבנות על פי מודל מחזור החיים. השאלה של מחזור החיים הקווים המנחיס נמנעיס במפורש מהתייחסות למודל כלשהו של מחזור החיים, אך מתאר הגישה הכללית יתאים למדי למודל מסוג מחזור החיים מטיפוס % שמתואר בתרשים 3.2. פירוט מודל זה אינו מענייננו ברגע זה; חשוב רק שנוכל לזהות את השלבים, הקשרים, והיחסים שביניהס. במקרה זה קייס רצף של תְיכגּן ראשוני, אך יש גם קישוריס בין פעילויות התְּיכּן והבדיקה. הצורה הכללית ומבנה המודל מספקיס את המסגרת, לאו דווקא את הפירוט הספציפי של השלבים, אך כאשר הקלט והפלט של השלבים השונים מוגדרים בפירוט רב יותר, יסייע הדבר בניסוח מתודולוגיית הפיתוח. אז ניתן יהיה להקים סביב למתודולוגיה, את מבני תוכניות הפרויקטים. תכנון פרויקטיפ תכנון פרויקטים מכיל מספר רב של רכיבים. בדומה לתוכניות הפיתות, המזהות וקובעות לוחות זמניס לפעילויות הפיתוח היצירתיות, יכולות גם תוכניות איכות, תוכניות לניהול התצורה, תוכניות לבדיקות, תוכניות למבחני קבלה על ידי המשתמשים, תוכניות יישוס, תוכניות תחזוקה, ועוד הרבה אפשרויות אחרות. תקן 23 0 מציין במפורש תוכניות פיתוח, תוכניות איכות, תוכניות לניהול התצורה ותוכניות תחזוקה, אך אין לצפות שכל אחת מאלו תצדיק בהכרח יצירת מסמך ספציפי. במספר מקרים, יכולים כל ההיבטיס האלה להיכלל במסמך יחיד של תכנון 2 ניהול איכות תוכנה פרויקטים. המדד העיקרי הוא, האס ניתן במקוס כלשהו, ביטו: נאות לסוגיות שהועלו על ידי תקן 9000-3 1580. בפרק זה נדון בהיבטיס העיקרייס של תכנון הפיתות ותכנון האיכות. ץ+ץ. וז 77, . . חג]ק 1651 06חב1ק4606/ 4 06 83 4006018006 1 אצ הרק ו אב ביא שוט ברו מו צר צוס סו פבך ותא אוש צר אקי ה 5ח6וחטזוטסטת 5 חג1ק ]65) וח516ע5 7 2 - הדדדדרדדדה- פְ -דדדד-ד יר . . * | חסוו0ס/זקש חסו!הזק6וח[ | 1 8₪ו05 , תרשים 3.2 מתזור חיים מטיפוס ץ תכנון הפיתות משעה שפותח מודל מחזור התיים, הופכת פעולת תכנון הפיתוח לפעולה פשוטה יחסית. משימת תוכנית הפיתוח היא, לקחת מודל כללי וליצור ממנו מודל מוגדר שיאומ להשגת המוצר הנדרש. דבר זה יכול להתבטא בפשטות בהפעלת המודל של מחזור החיים בשלמותו, או שייתכן שיהיה צורך להמציא מודל חדש לגמרי עבור הפיתוח המסויס. בכל מקרה נזדקק לימפת דרכים' מפורטת שתזהה את אשר יש לעשות, על ידי מי ומתי. הפעילויות שבתוכנית ינבעו מהשלבים של מחזור התייס תוך כדי יישומו לבעיה שבטיפול. המוצרים הסופייס של השלב תייביסם להיות מגובשיס וספציפייס ולא פרק 3: סיכומיס ופרויקטים ‏ 73 וו ורוו כוללניים, ועלינו לשקול כיצד בדיוק ניתן יהיה לאמת כל אחד מהס לפני שהפרויקט , יעבור לשלב הבא. כל הנושאים האלה נדונים בסעיף 5.4.2.1 של הקוויס המנחים, וכל אחת מהסוגיות המזוהות שס מורחבת בתת-סעיף נפרד. תת-הסעיף של הניהול (5.4.2.2) מאזכר את הגדרת תחומי האחריות, את חלוקת העבודה בתוך הפרויקט, את הממשקים הארגונייס שמחוצה לו, מזהה את לוחות הזמנים לאספקה ואת הדרישה לבקרת התקדמות מתוכננת. ההיבט היחיד של סעיף 5.4.2.1 שאינו מוסבר בפירוט יתר, הוא הפריט האחרון שנקרא 'ניתוח בעיות פוטנציאליות הקשורות לשלבי הפיתוח ולעמידה בדרישות המפורטות'י, שלמעשה אינו אלא התייחסות לצורך בניתוח הסיכונים. סיכוני הפרויקטים מטופלים בתוכנית האיכות, שיכולה להיות חלק מתוכנית הפיתוח, ואילו תכנון האיכות הוא נושא סעיף 5.5. תקן 9000-3 150 מספק בסעיף 5.5.2, מספר הנחיות שימושיות בדבר תוכן תוכנית האיכות. (יתוח הדרישות וסקר התוזה ניתוח הדרישות וסקר החוזה מטופלים בצורה ישירה, ובכלל זה הצעה לתתוס האחריות של הנהלת הקונה (כלומר הלקוח). ההתייחסות ללקוחות יכולה להיות רק בלתי ישירה, על ידי כך שהספק מביא לתשומת לב הלקוחות את ההמלצות האלו, משוס שהקוויס המנחיס מיושמיס לגבי הספק, ואין הס יכוליס להטיל אחריות על הקונה. עס זאת, הקוויס המנחיס מציינים לפחות את הנושא, ונותניס לספקים את ההזדמנות להצביע לפני הקוניס על כך שהקווים המנחיס מציעים הנחייה בלתי תלויה לדרכי פעולה טובות. סעיפים 4.1.2 ו- 4.1.3 מעודדיס את הלקוחות לשתף פעולה עס ספקיהם על ידי מסירת כל המידע הדרוש במועדים הנכונים, למנות נציג שיעמוד בקשר עס הספק בנושאים החוזיים, ולהשתתף בסקרים חוזריס משותפיס שיתועדו לצורך התייחסות בעתיד. מהקוויס המנחיס לא ברור מה צריכה להיות תגובת הספק, במקרה שהלקות אינו מוכן לשתף פעולה. ככלל, תהיה זאת אסטרטגיה לא נכונה להצביע על האיוולת שבדרך התנהגות הלקוח, הדבר יכול להיות גס מסוכן כאשר הלקוח הוא גדול ועשיר. עס זאת, חשוב שיהיה תיעוד כלשהו שייעוץ זה הובא לתשומת לב הלקוח, ושנעשה ניסיון ליישס זאת, לדוגמה, על ידי הקמת מנגנון משותף לסקרים חוזריס. סעיף 4.1.2 מעלה את השאלה הרגישה של שכנוע הלקות לקחת חלק באחריות על המוצר שבפיתוח. זהו תחוס שההתייחסות אליו היא לעיתיס תכופות כאל פרט מעשי שרק מעורר רוגז. בדרך כלל, גישת המפתחים היא שהקונה לא יאהב בכל מקרה את מה שמייצרים עבורו; אך גם הקוניס פועלים לרוב לפי העיקרון שהמוצר המוגמר לא יענה על צורכיהס. במידה שקיימת איזו שהיא תחושת בעלות על המוצר, תהיה זאת לעיתיס תכופות יותר מצד הספקים מאשר מצד הקונים. לכן, לעיתיס תכופות הספקיס נמצאים בעמדת התגוננות בדבר ביצועי המוצר, ושבעטייה הקונים אינס 4 ניהול איכות תוכנה דואגיס לפתח תרבות עבודה בה יוכל המוצר המוגמר לתפקד במלוא הפוטנציאל שלו. זה מצב המשווע לתחושת שותפות ולהבנה מציאותית של מה שניתן לעשות. הדגש העיקרי בסעיף 4.1.2 הוא על הצורך לוודא שהקונה ימנה אדס בעל סמכויות מתאימות, שיסכס עס הספק את כל הפרמטרים העיקרייס. נציג זה צריך להשגיח גס על הדרישות הטכניות וגס על התנאיס החוזייס. חשוב שנציג הקונה ישמש כמקשר יחיד עס הספק, כך שאפשר יהיה לצמצם עד למינימוס את העלול להיראות כאי-הבנות שהן בלתי נמנעות. חשוב גס שנציג זה יוכל לאשר אישית מוצריס המתקבלים מהספק, כך שנקודת קשר יחידה זו תיראה על ידי שני הצדדים כמתאימה להשלמתו המוצלחת של החוזה. כדי לוודא שמנגנון הקישור לא רק יוגדר, אלא גס ייושס בפועל, מציע סעיף 4.1.3 סדרת סקריםס משותפיס המכסים את השלבים הראשייס של תהליך הפיתוח. למרות שרמה זו של תשומת לב לממשק שבין הספק ללקות היא עדיין פחות מאידיאלית, היא יכולה להוות בסיס להסכמה פורמלית חשופה פחות לאי-הבנות שבהמשך שעלולות להוליך גס לאכזבות. בסופו של דבר, אין תחליף ליצירת תרבות נכונה המשותפת לשנל הצדדיס. תחושה של מסע משותף לקראת תוצאה מוצלחת, רבים סיכוייה להפיק מוצריס שישביעו את רצון הקונה, וימנעו מרירות המחלחלת בפרויקיייס בהם כל צד מחופר בעמדותיו החוזיות. תקן 9001 150 מכיל דרישה לסקר חוזר של החוזה, כאמצעי שנועד לוודא שהקונה והספק יפתחו במשותף הבנה של דרישות הקונה וכוונות הספק למילוי דרישות אלו. סעיף 5.2 של הקוויס המנחים חוזר ומאשר את הדגש שהתקן שס על הצורך בסקר חוזר רשמית של החוזה, ומוסיף מספר פרטיס (5.2.1) בדבר האלמנטיס שהתוזה האופייני צריך לכסות. חשוב לציין כאן שלא די שהחו.ה יעסוק בנושאיס מובניס מאליהם, כגון קריטריוניסם למבחני הקבלה. עליו גם לזהות את השיטה שיש לנהוג לצורך טיפול בבעיות ובשינויים הקשורים בחוזה עצמו. במקוס לעסוק בבעיות לאחר שהן מתעוררות, ותוך כדי כך לסכן את מערכת היחטים שבין הקונה לספק. אנו ממליציס לחזות מראש את תחומי הבעיות הפוטנציאליות, ולדון בהן לפני האירוע, באווירה שקטה ובלתי מאיימת. לבסוף (5.3), הקוויס המנחיס מגישים ייעוץ בדבר הצגת מפרטי דרישות הקונה. יחד עס זיהוי התוכן המתאיס של מפרטי הדרישות, מדגיש סעיף זה את הצורך בשיתוף פעולה הדדי, כך ניתן לוודא שהגדרת הדרישות תיעשה בצורה של פעילות משותפת, בה ייעשה כל מאמץ ליצירת האווירה הנכונה לשיתוף פעולה לטוות ארוך, לכל משך קיומו של הפרויקט. גקות הדוישות לאחר קביעת הדרישות וקבלת הטכמת הלקוח לגביהן, צריך הספק לקייס בקרה על דרישות אלו. כך יוכל לוודא שלא ייעשו בהן שינויים בלתי מורשיס או מקרייס, שישפיעו על ההסכמה החוזית, ואולי אף יעמידו בסכנה את כל פרויקש הפיתות. פרק 3: סיכונים ופרויקטים | 75 תקן 43 1900 מכיל שני סעיפים ראשייס העוסקיס בבקרת הדרישות: בקרת מסמכים (6.2) וניהול התצורה (6.1). הראשון בא לוודא קיוס בקרה על שינוייס במסמך הדרישות, ואילו השני, קובע זיהוי ברור של הגירסה ההתחלתית של הדרישות, ומנגנון שיאפשר את המעקב. תוכנה שתיוצר על פי מפרט של דרישות, תזוהה בסופו של דבר כתוצאה של גירסה מסוימת של הדרישות. יגד (וודא התחלה מוצלחת של פרויקטיפ (יתות ותיעוד הדרישות מקובל על הכל שניתוח הדרישות הוא השלב במחזור החייס של פרויקט, שהוא הקשה והחשוף ביותר לשגיאות, והוא גם השלב החשוב ביותר. תיקון טעויות והשמטות בתיעוד הדרישות, יהיה יקר יותר משעה שמתחילים בעבודת הפיתוח, והדבר עלול גם להוליך לכישלון מלא של הפרויקט. לכן, נהוג להפקיד את ניתוח הדרישות בידי העובדיס המנוסיס והמיומנים ביותר שבסגל הפרויקט, וגם אז משתלס לתת כל סיוע אפשרי לביצוע משימה זו. קיימות כאן שתי בעיות: כיצד מפיקים את הדרישות מהלקוח, וכיצד מתעדיסם אותן באופן שהתיעוד יהיה נגיש למשתמשים הצריכיס לבדוק ולאשר אותו, והמפתתיס לא יגלו אי בהירויות בניסוח הדרישות. אפשר להקל במידה רבה על הפקת הדרישות על ידי טכניקות כגון יצירת אבטיפוס והדמיות. יצירת אבטיפוס של הדרישות משתמשת במודלים :יצוגיים פשוטיס של המערכת המוצעת. מטרתם לספק למשתמשים :יצוג מציאותי יתלת ממדיי של הדרישות, בו יוכלו להסתייע כדי לבחון את הדרך בה הס מביניס את השפעתה הצפויה של המערכת שתסופק להם. השימוש באבטיפוס שכיח :ותר בתחוס הממשק למשתמשים, ופחות במידול פונקציות של המערכת בקנה מידה רחב יותר. ההדמייה יכולה לסייע בהערכה של הפונקציונליות הכוללת, על ידי מידול תרומתה הצפויה של מערכת התוכנה להתנהגות הכוללת של המערכת הרחבה *ותר (כולל תרומתה לבני האדס). בדרך כלל, משתמשת ההדמייה במסמכים מוכנים המחליפים פעולה של מערכת תוכנה במסגרת תרחישים מצומצמים. על ידי תכנון והכנה מדוקדקים אפשר להשתמש בצירוף של אבטיפוס והדמיות, להצגת מודל מקיף של התנהגות המערכת. אמצעי פשוט שאפשר להסתיניע בו ליצירת מסמכים שלמיס ועקביים של הדרישות הוא אספקת מיתאר (טחו!זטס) ערוך בצורת תבנית (806!קוח6)). התבנית מגדירה את מיתאר מסמך הדרישות ומנחה את מכין המסמך על התוכן הנדרש. המסמכיס המתקבלים עקביים יותר, גס בצורתם וגם בתוכנם, כך הס גס קליס יותר לסקירה. השימוש בתבניות המלוות ברשימות תיוג, מסייע גם הוא לאלה המתכונניס לסקר של המסמכים. על ידי בקרה מתמדת של התבניות ורשימות התיוג, ניתן לצבור ניסיון שישפר את תהליך ניתוח הדרישות ויצמצם את המאמץ ועלות הפקת התיעוד הנדרש. 6 ניהול איכות תוכנה קטלוג הדרישות קטלוג הדרישות איננו אלא בסיס נתוניסם שנבנה ממשפטי הדרישות, שהוסרו מהן כל המיליס הבלתי חיוניות. בסיס נתוניס ממין זה מורכב מאוסף של משפטיס פשוטים, שכל אחד מהס מכיל דרישה אחת - טבלה בת עמודה אחת. אנו יכוליס לסקור את בסיס הנתוניס הזה, ולהחליט אס הוא שלס ומינימלי, ולספק את קו הבסיס של הדרישות לצורך מעקב אחר התיכון ההולך ומתפתח. לאחר הסקירה והאישור, הופך קטלוג הדרישות, בסיס לכל עבודת הפיתוח. תרשים 3.3 מציג את הדרך בה ניתן לבנות את הקטלוג. מספר תיאור הדרישה קריטריון לקבלה טעיף מבחן דרישה קבלה 11 המערכת תספק אמצעי לקליטת בדיקה פונקציונלית 1+ הזמנות 12 אמצעי לסקירת החוזה יהיה זמין בדיקה פונקציונלית 2+ ממסך קבלת ההזמנות 13 אישור ההזמנה יבוקר על ידי בדיקה פונקציונלית 1-3 סיסמת המשתמש 14 המערכת תיצור תעודות משלות בדיקה פונקציונלית 14 אוטומטית עס אישור ההזמנה 15 המערכת תאפשר קליטת הזמנות | בדיקה פונקציונלית 5 באמצעות עד 6 מסכיס לפי 6 מסכים פעילים 11 הצורך, כדי להגיע לקצב קליטה קצב הזמנות, 600 2+ מזערי של 600 הזמנות ליוס הזמנגות ו- 1200 3 ו- 1200 שורות הזמנה ליוס שורות הזמנה ליוס - 77 תרש:ם 3.3 קטלוג דרישות עס התקדמות הפיתוח, אנו מוסיפיס עמודה חדשה לטבלת הדרישות עבור כל שלב בתהליך. בעמודה החדשה אנו רושמיס את האלמנטים של תיכון השלב הנוכתי, המצטרפיס למפה של כל אלמנט מהשלב הקודסם. בצורה זו, בשלב התיכון הלוגי בו נוצר המפרט הפונקציונלי, אנו מקשריס כל פונקציה אל הדרישה שיצרה אותה. על ידי כך אפשר לאמת כל שלב מול השלב הקודס בכל הנוגע לשלמות, ולוודא שלא תתווסף פעילות כלשהי ואף מוצר שאין עבורס דרישה שהוסכם עליה רשמית. בסוף תהליך הפיתות יש לרשותנו רישוס מלא של יכולת מעקב מהדרישות אל המוצריס המוגמריס. בכל שלב אנו גס יכוליס להפיק הוכחות לכך שכל אלמנט נוצר מתוך הדרישות, וכי כל הדרישות יושמו במלואן. פרק 3: סיכונים ופרויקטים | 77 קווי פעילות וטבלאות של קווי פעילות טבלאות של קווי פעילות (6405זח1 /461//18) הן הרחבה של קטלוגי הדרישות, והשימוש בהן קשור לבעיה הכאובה של בדיקות קבלה. בבדיקות אלה יש צורך ברמה כזו של הבנת הדרישות, שתאפשר לקהילת המשתמשים להגדיר מדדי קבלה מכומתים שניתן יהיה לבדוק מולס את המערכת. הגדרת המדדים לקבלה היא אחד ההיבטיס הקשים יותר של ניתוח הדרישות, ורק לעיתיס נדירות היא מתבצעת כהלכה. בדרך כלל, הנימוק המושמע הוא שהדרישות אינן מובנות די הצורך עד כדי יכולת להגדיר מדדי קבלה. במקרה והדבר נכון, הרי שהדרישות מייצגות בסיס רעוע מכדי שאפשר יהיה לבסס עליו את הפיתוח. למעשה, יכולתנו לבנות מדדי קבלה מכומתים, היא אחד המבחנים הטוביס יותר לאיכות קבוצת הדרישות. כיצד יכולה טבלת קווי הפעילות לסייע לנו: מכיון שטבלה זו היא גם קטלוג של דרישות, הרי שבמקרה והכל תקין, היא אמורה להכיל קבוצה של דרישות בדידות. עלינו לעבור עכשיו לאחור משלב הדרישות, כדי לאחזר את הפעילויות העסקיות מהן הופקו הדרישות. הפעולות העסקיות, קווי הפעילות, הן הבסיס הטוב ביותר להבנת המשתמש את ההשפעה הפוטנציאלית של המערכת שבפיתוח. פעולות אלו תהיינה גס התיאור הנגיש ביותר של התנהגות המערכת, שעל פיו ניתן יהיה להגדיר מדדיס להצלחת הפרויקט. בניית טבלת קווי הפעילות היא חלק חשוב בתהליך הקמת בסיס יציב לפיתוח. תרשים 3.4 מציג כיצד ניתן לשלוף את קווי הפעילות מתוך ידיעת התהליכיס העסקיים הבסיסיים. התרשיס הוא מודל פשוט של התהליכים העסקיים הבסיסיים של חברה למכירת ספריס בדיוור ישיר. בצד שמאל, ההזמנות מתקבלות ונבדקות לפני העיבוד והעברתן למתסן. המחסן בודק ומאשר את זמינות הסחורה, לבסוף מכיניסם את החשבונית. רצף זה מייצג את קו הפעילות הפשוט ביותר, בו מתקבלות הזמנות שגרתיות עבור ספרים רגיליס הנמצאים במלאי. כל המצבים האחריס של ההזמנות, כגון מלאי שאינו מספיק, הס ואריאציות על הנושא הבסיסי. בצד ימין אנו רואיס את התהליך הבסיסי של השלמת המלאי, ובאמצע מופיעות אחדות מהפעולות המתבצעות במחסן. ברור שאחדיס מהתהליכיס המוצגיס יהיו ידנייס ואחריס ממוחשבים, וחלק מהסם יניעו בוודאי תהליכים במערכות אחרות. בזמן ניתוח הדרישות, תפקיד המנתח ליצור קבוצה עקבית וסבירה של דרישות מוגדרות היטב. המנתח מנטה להמיר את תיאור דרישות המשתמשים, תיאור המבוטא בשפה שלהס וספוג בתרבותס, למשפטי דרישות מנוסחיס בבהירות, בתמציתיות, ניתנים לכימות, וכיוצא באלה. לתהליך זה יכולות להיות תופעות לוואי לא רצויות יכול להיות שמשפטי הדרישות יהיו מובנים פחות למשתמשים מאשר הגירסה המקורית של דרישותיהם. כתוצאה מכך, ייתכן שההסכמה הרשמית לדרישות שלאחר הניתוח, לא תיתן למשתמשים את מידת הביטחון שהיינו רוצים שתהיה להם. הס אפילו עשוייס להתקשות בהמרת דרישותיהם, כפי שהם מביניס אותן, לקבוצה ברורה של קריטריוניס לקבלת המוצר. 8 ניהול איכות תוכנה מסתבר שזה המחתיר שעלינו לשלס עבור הניסיון להגיע לדרישות מוגדרות היטב. עס זאת, נוכל לנטרל מגבלה זו אס נמשיך להחזיק במשפטיס המקוריים של הלקוח, המתייחטים לכוונות הכלליות, שאולי אינס מוגדרות די הצורך. משפטיס אלה, לאחר שיפוץ מסויס שמטרתו הבהרת הביטויים, יוכלו לשמש בתור עמודה ראשונה של טבלת קווי הפעילויות, שתבוא לפני הדרישות עצמן. 6066 0% ]תוהזו טף6ז זז זו[ ]0 זו זז זז שו16/16 5 0% 5 5חן זז זז / | הת6!ק6ת . 0% זז 6 זט ץז6טו[6 6סת 85 טח ההתהסס .> אסגת | ]83 זז זו 500) 0% 5 ]16166 ב שת זסטו|6 תרשים 3.4 ממיתות קו פעילות עבור תהליך הזמנה בדואר כל קו בטבלת קווי הפעילויות עשוי להביא ליותר מאשר דרישה אחת. אנו יכוליס להשתמש בטבלת הקווים כדי שתסייע לנו בסקירת הדרישות, כדי לוודא שכל הקוויס מוצאיס את ביטוייס בדרישות, וכי הדרישות מבטאות רק את כוונות המשתמשים כפי שהובעו בקווי הפעילות. תרשיס 3.5 מציג את הדרך בה אפשר לבנות את לוח קווי הפעילויות. קו 1 הוא תהליך ההזמנות הבסיסי, והוא משמש כקו הראשון משוס שזהו התהליך היסודי ביותר. אס תהליך זה לא יפעל בצורה נכונה, אין סיכוי שאף אחד מהתהליכים יוכל לפעול (המספריס מתיחסים לפירוט בתרשיס 3.5 שלהלן). קו 1 מתולל שש דרישות של המערכת, עבור הצעדיס השוניס שבתהליך. לצעדיס 1.1 ו- 1.2 יש רכיב פרק 3: סיכונים ופרויקטים | 79 משלים ידני שצריך להתבצע על ידי פקידי ההזמנות; דבר זה צריך להשתקף בנהלים המתאימים. מצעד 1.5 משתמע חיבור אל מערכת ניהול המחסן, שהיא מערכת מחשב נפרדת. כך שבשלב כלשהו חייבים לבוא הגדרה ובדיקה של שילוב מערכות. בעמודה הבאה, רוב הדרישות מחוללות פונקציית מערכת יחידה. עם זאת, דרישה 1.2 זקוקה להגדרה מפורטת יותר, ותיושס על ידי שתי פונקציות נפרדות. קו 2 מגדיר את הקו השני בחשיבותו, חידוש פשוט של המלאי, וכן הלאה. ==? קו תיאור הקו דרישות המערבת פונקציות 1 הזמנות רגילות 1.1 קליטת הזמנות 141 (ללא הזמנות | 1.2 סקירת החוזה 1 חיפוש בבסיס נתוניס ממתינות וללא ‏ 1.3 אישור ההזמנה 3 השהיית הזמנה ימיוחדיס') 4 *צירת תעודת משלות 1.3 5 אישור זמינות 14 6 הכנת חשבונית 15 1-6 2 חידוש מלאי 1 בדיקת המלאי 2.1 (ללא מיוחדים) 2.2 הפקת פקודת רכש 22 3 קבלת סחורה 23 4 חידוש מלאי 1 עדכן רמות מלאי 2 עדכן הזמנות ממתינות 3 הוסף החצזרות מלקוחות 3 ניהול המחסן | 3.1 קבל תעודת משלוח 2.1 2 אשר זמינות 2 3 בדיקת סחורה נכנסת | 3.3.1 בדוק מול פקודת רכש 4 החזרות מלקוחות 2 בדוק מיוחדיס 5 עדכן רשומות מלאי 1 בדוק מצב , 2 הוסף למלא תרשים 3.5 טבלת קווי פעיכויות של חברה למכירת ספרים בדיוור ישיר טבלת הקוויס שבתרשים 3.5 אינה שלמה, משום שהיא מציגה רק אחדים מהקוויס וכוללת ניתוח רק עד לרמת הפונקציה. ניתן להמשיך את התהליך דרך תהליך הפיתוח, תוך הוספת עמודות לטבלה בכל פאזה, עד שכל מודולי הקוד וכל היישויות של בסיסי הנתונים יהיו מקושרים אל קו אחד או אל מספר קוויס. צוות הפיתוח יהיה מסוגל לוודא בכל שלב, שהתיכון תואס בדיוק את תיאור השלב הקודם, וכך ייושמו כל הדרישות בשלמותן, ולא ייושס דבר שלא צוין כדרישה. כעת מכילה טבלה מוגדלת זו לא רק את דרישות הבסיס, אלא גס את קווי הפעילות העסקית ממנה הן נובעות. כך אנו מקיימים את המגע בין המשתמשיס לבין המערכת המתפתחת; הם יכולים לקשר כל דבר חזרה לאחור אל רעיונותיהס שהובעו בדרכס. למשתמשיס קל יותר יהיה לכמת ולתת עדיפויות לקוויס מאשר לדרישות, וגס קל יותר יהיה להגדיר קריטריוניס לקבלה, ולתכנן את בדיקת הקבלה. 0 ניהול איכות תוכנה בשלב הפיתות המוצג בתרשיס 3.5, המשתמשיסם אמוריס להגדיר כבר את גורמי ההצלחה הכללייס של הפרויקט, ואת המדדיס לקבלה לגבי כל דרישה. מצביעי הצלחה קריטייס הן המדידות שבעזרתן יתליטו המשתמשיסם אם הושגו יעדיהם העסקיים. אלה מוגדריס בדרך כלל ברמה של הקו, כלומר, קצב עיבוד ההזמנות. המדדיס לקבלה הס אלה שיש עליהס הסכמה בין המשתמשים והמפתחים כעל מדדי הקבילות של מערכת התוכנה בעת הקבלה, כלומר, זמניס ממוצעיס לחיפוש בבסיס הנתונים. מהמדדיס של המשתמשים אמוריס המפתחים להגדיר גורמי מפתח של הביצועיס, שישמשו כמדדיס טכניים לביצועי המערכת, שנדרשים לעמידה במדדיסם של המשתמשים. לדוגמה, מהירות מינימוס של המעבד תיקבע לפי פרמטרים כגון אלה הנדרשיס בהתאס לקצב העיבודים, ולגודל הצפוי של בסיס הנתונים. תרשים 3.6 מדגיס את הקשריס שבין מדידות אלו. טבלת הקוויס היא גס מכשיר רב ערך להגדרת אסטרטגיית הבדיקות. צריך יהיה לדרג בקפדנות את סדר העדיפות של כל הבדיקות המובנות המצריכות תכנון, החל ממודולים ייחודיים של תוכניות ועד מערכות שלמות. כך עס הופעת לחצי הזמן הבלתי נמנעים, נוכל להחליט החלטות שקולות בדבר ביטול, או שינוי תוכנית בדיקה כלשהי. דירוג סדר העדיפות של הבדיקות מאפשר להעריך חשיבות של קבוצת בדיקות נתונה, ואת המשמעויות הצפויות כתוצאה מקיצוץ, או ביטול בדיקות אלה. על ידי כך, לא רק נימנע מקיצוצים סיטונייס ומנוגדים-לפריון בתוכנית הבדיקות, אלא נהיה גס בעמדה שתאפשר לנו לשקול את הסיכונים הנלוויס לכל קיצוץ שנחליט עליו. על ידי הגדרת מדידות מתאימות עבור פעילות הבדיקות, נוכל לכמת את השלמות ויעילות הבדיקות, וכך לקבוע רמות סיכון למקרה שהבדיקות יקוצצו באחד השלבים. פיתות אסטרטגיית בדיקות המבוססת על טבלת הקווים תידון ביתר פירוט בפרק 4. היתרון הסופי שאנו מפיקים מטבלות הקוויס, הוא היכולת להציג את הציפיות בהמשך הדרך. הקווים רושמיס את הציפיות שמעבר לקבלת המוצר, וגם בתוך פרק השימוש התפעולי של המערכת. שישה חודשים ומעלה לאחר קבלת המערכת, נוכל להעריך אס הפקנו ממנה את היתרונות המתוכנניס. (יתוח דרישות וניהול פרויקט מתוך הִהֶקָשר בעולס אידיאלי, לקוחותינו היו מחליטים מראש מה נדרש להס ומעבירים לנו את דרישותיהם. כך היינו יכוליס לנתחן ולבנות מערכת תוכנה שתענה על דרישות אלו. את הסיוס המוצלח של הפרויקט שלנו היינו מוודאים על ידי ביצוע כל העבודה, לפי תוכנית שהיתה מותווית בתתילת הפרויקט ומבוססת על המתודולוגיה שבחרנו כמתאימה ביותר עבור הפרויקט. בפועל, החייס אינס פשוטיס כמו האידיאל. ככלל, הלקוחות אינס מסוגלים להגדיר את דרישותיהס במלואן, בבהירות ובצורה חד-משמעית; התקשורת רחוקה מלהיות מושלמת ואף מוסיפה שגיאות ואי-רלוונטיות שמסיטות אותנו מהסוגיות החשובות יותר, בנוסף איננו בטוחיס לגמרי בשיטות הפיתוח שלנו. כל הפגמיס האלה מצטבריס ומהוויס מקור דאגה ממשי למנהלי פרויקטים - הסיכון. פדק 3: סיכוניס ופרויקטים | 81 הסיכון הוא ההסתברות המוחלטת שהענייניס אכן ישתבשו ויגרמו לפרויקטים שאנו מפתחיס לסטות מהתוכנית. אס לא מטפליס בהס במהירות ובהחלטיות, הסיכוניס יובילו לבעיות כבדות, ואולי אף לכישלון מוחלט. בשל תופעת הסיכון, אנו חייביס לתכנן בזהירות רבה יותר, ולכלול בתוכניתנו את הפעולות שעלינו לנקוט כדי לנטרל את הסיכונים שביכולתנו לחזות. הערכת סיכוניס היא חלק חיוני של התכנון, וניהול סיכוניס הוא חלק יסודי של ניהול פרויקטים. בהתחשב בהשפעה השלילית שיש לסיכונים על תוכנית העבודה שלנו, עלינו להיות בטוחיס שאנו מביניס את מה שהפרויקט שלנו אמור להשיג ושהגדרנו את התהליך (או את המתודולוגיה) בפירוט. כך נוכל לפקח על ההתקדמות ולגלות כל חריגה מהתוכנית כבר בשלב מוקדם, כאשר האחזור אפשרי עדיין, וללא השלכות חמורות על העלויות, או על לוחות הזמנים. הגדרת מודל מחזור חיים מספקת מסגרת לתכנון פרויקטים מציאותי, ומהווה את הבסיס למתודולוגיה כוללת לניהול פרויקטים. על ידי ניתוח ותיעוד הדרישות בפירוט רב ככל האפשר, ניתן להגדיר נקודות התחלה וסיוס ברורות של הפרויקט. אנו משליכים מהדרישות קדימה, לעבר סיוס הפרויקט, על ידי הגדרת מדדי הקבלה, המבוססים אך ורק על הצגת הדרישות שבקטלוג הדרישות. טכניקות כגון טבלת קווי הפעילויות, מסייעות לוודא שהלקוחות יישארו בתמונה של המוצריס המתפתחים, ויוכלו לקשרס אל היעדים העסקיים מהס נבעו הדרישות. גישה זו מעודדת את הלקוחות לשמר את תחושת הבעלות על המוצרים במשך הפיתוח, ומעודדת את הדו- שיח בין הלקוחות לבין המפתחים. ז שש 5 5400655 111081ז0) ב סוט[ מ ]סוה / % וי 906) 6860זהרך ו 5 5 660חג וח 0]ז6ק 655חופט טל 4ולך 0005565ז0 8 גנד 8 זו שופ 006 008 וח516ץ5 85 65 וח6זו 16 ו ו ןוז וזו 5561 | 66תהתח0)זשק 66 [ההס))סהטן ורי 5 ב 5601030 8 ]וושחסקוחס 6 50 )5601001 פותשחזסקוחס6 ]חק 660 תרשים 3.6 מדידת ביצועי המערכת 2 ניתול איכות תוכנה מדידות שמקורן ביעדיס ההתחלתייס של הלקות ושנבנו סביב הצגת הדרישות, יכולות לספק לנו אבני דרך במפת הדרכים לאורך תהליך הפיתוח, ומאפשרות לנו להיות בטותיס שהגענו אל הנקודה הנכונה, כאשר הפרויקט מסתיים. תרשים 3.6 מציג את מנגנון הבקרה של הלולאה הסגורה שנוצר על ידי ימדדי ההצלחה' אלה. כעת, כשעומדת לרשותנו המסגרת לתהליך ניהול פרויקטים, נוכל להפנות את תשומת הלב להגדרת תהליך הפיתוח בפירוט רב יותר. עקרונות כסיסייפ של (יהול פרויקטיפ בפרק 2 זיהינו אחדיס מעקרונות איכות התוכנה וסיכמנו, שמערכת איכות מציאותית חייבת לענות על עקרונות בסיסייס אלה. דבר זה נכון במידה שווה גס לגבי ניהול פרויקטיס. ניהול פרויקטיס הוא נושא רחב ומורכב, וטיפול מקיף בנושא זה היה חורג מתחוס ספר זה. לעומת זאת, ניהול מציאותי של פרויקטיס אינו יותר מאשר היצמדות למספר מועט של עקרונות חשובים. נציג כאן מספר עקרונות בסיסיים שיצביעו על סוגי הנושאיס בהס יש צורך לטפל. אין לצפות שרשימתנו תהיה שלמה, ואפשר יהיה גם לטעון שיש נושאים חשוביס יותר מאלה שנכללו בה. הנקודה החשובה היא רכישת מודעות לקיוס העקרונות. - יה -----/-/]/]-- עשרת העקרונות של ניהול פרויקטים [. פיתוח תוכנה הוא תהליך הכולל חזרות (איטרטיבי), וכך גם צריך לתכננו. המשימות תתבצענה טוב יותר בשניים או בשלושה שלביס. תכנן לקראת אספקה מהירה של טיוטות, עבור עליהן ועבד אותן מחדש. 2 תכנן עריכת בדיקות. הקצה בתוכניותיך זמן מספיק להשגת רמה טובה של אימות ובדיקת תקפות. בדרך כלל יוקדשו כ- 40 אחוז מהמאמצ הכולל לפעילות זו. 3 אם אינך מסוגל לכלול בלוח הזמנים גם את הפיתות וגם את הבדיקות והניסויים, צמצס את דרישותיך או ספק אותן בשלבים. מוטב לאכזב במקצת את המשתמשים ואחר כך לספק את המוצר במועד, מאשר לגרוס להס לרוגז רב בשל אספקה מאוחרת מבלי לענות על הדרישות. 4. ערוך בדיקות לפי תוכנית. לאחר שהוקצה זמן לבדיקות, תכנן זמן זה בקפדנות כדי שתוכל להפיק מהבדיקות את הערך המירבי בזמן ביצוען. 5. היה מציאותי. אס העבודה אינה יכולה להתבצע בזמן שהוקצה, צמצוס הערכות הזמן לא יביא כל תועלת. יש להניח שהיית יותר מדי אופטימי כבר מלכתחילה. פרק 3: סיכונים ופרויקטים | 83 .10 הכן תכנון מפורט. פצל את הפעילויות לרמה שתתן לך אפשרות לראות את קצב ההתקדמות על בסיס שבועי. הקפד על קיום בקרה. בדוק את ההתקדמות בצורה סדירה ובמקרה של פיגוריסם, ברר את הסיבה לכך. תמיד קיימת סיבה, ואס אין מטפלים בה, הפיגורים ילכו ויגדלו. פקח עין על השינוייס. שינוייס בדרישות יכולים להיות יקריס ביותר וחייבים להעריכס בזהירות. כל השינוייס האחריס מחייבים אף הס פיקוח. אלה עלולים להכיל גם פצצות זמן. הכן עצמך לקראת הופעת פעילויות 'במעט קריטיות'. הנתיבים הקריטיים נוהגיס להתחלף מדי פעם. כאשר הדבר קורה, הס חושפים פעילויות קריטיות חדשות שאין לך כמעט שליטה עליהן. פקח עין על פעילויות אלו. שמור על עדכון המדדים. החלט מה הס הדבריס החייבים מדידה והמשך למדוד אותס בכל תנאי. מידע זה הוא בעל ערך רב ביותר כאשר אתה יממש נתקל בוי, וזה הזמן שדווקא בו מתעורר הפיתוי לחדול מאיסוף הנתוניס. ----------------000000000--0--------------- 70 הוווווווווקווקוווקווהקוד-----.. הכן לעצמך את רשימת עקרונותיך, והשתמש בה כדי לעורר דיון בסוגיות המפתח ובחשיבותן היחסית. לכשתגיע להסכמה כללית, בנה סביב לעקרונות המוסכמים את כללי ההתנהגות שלך לניהול פרויקטים, ודאג שכל התחוס הזה יהיה נתון לסיקור מתמיד. משימתנו הראשונה היא גיבוש תהליך מוסכס ושימושי על ידי העלאתו על הכתב. משעה ששיטתנו עומדת לרשותנו בכתב, נוכל לשקול דרכיס לשיפורה. 4 ניהול איכות תוכנה סכק 4 תהליך הפיתוח הבסיסי מבוא טיפול נכון בתהליך הפיתוח הבסיסי הוא מפתח לייצור ותחזוקה מוצלחים של תוכנה. הפיתוח על פי מחזור חיים משקף את תרבות הארגון בכך שהוא מגדיר פאזות ומוצרים מוגמרים מציאותיים של מחזור החיים. בניית מודל של מחזור חיים אידיאלי יכולה להיות מענגת למדי, אך לא תהיה בו תועלת רבה, אם לא נוכל להיצמד למבנה המוגדר על ידו. יישום מעשי של תהליך פיתוח מציאותי ומוגדר היטב, יכול לוודא את השגת סביבת האיכות הטובה ביותר עבור כל יחידת עבודה שאנו מקבלים על עצמנו. המאמץ הכרוך ביצירת תהליך פיתוח מתועד אינו זניח, אך היתרונות המופקים - מפצים בהרבה על המאמץ. מלהו התהליך הכסיסי תהליך פיתוח התוכנה הבסיסי הוא התהליך היחיד החשוב ביותר שעל מערכת ניהול האיכות ללכוד. אם נסלק ממנו את כל הכליס, הטכניקות והשיטות המסייעות לו, או בולמות אותו, תהליך הפיתוח הבסיסי יורכב רק מארבעת האלמנטיס החיוניים: * המסגרת עבור התהליך - מודל של מחזור חייס ; + קבוצה מסוימת של שלבים ומוצריס מוגמריס - מתודולוגיה; * אמצעים שיאפשרו לוודא אס המוצרים המוגמריס נכונים, אס לאו - אימות ובדיקת תקפות ; * אמצעים לזיהוי מוצרי תוכנה ולבקרת השינוייס - ניהול התצורה. כשארבעת אלמנטים אלה מצורפים יחד, הס תואמים את שמונת העקרונות שנדונו בפרק 1. קייס עוד תחוס חמישי בעל משמעות רבה, שאינו בהכרת חלק מתהליך הפיתוח הבסיסי, ועס זאת, מהווה חלק ראשי של מחזור החיים הכולל של. מוצר תוכנה. הכוונה לנושא תחזוקת התוכנה. אנו דניס בו בפרק זה בשל הקשר ההדוק שלו לגישת הפיתוח הבסיסית. לכל דבר יש חשיבות רק במידה שהוא תורס לאחד מארבעת האלמנטיס האלה, בהס נעמיק כעת את הדיון. פרק 4: תתליך הפיתוח הכסיס: | 85 -- 2... מחזורי תיים מודל מחזור חייס של פיתוח תוכנה אינו אלא מיפוי של התהליך הכולל, לא יותר ולא פחות מזה. הוא מגדיר מהס השלבים שהתהליך מגלם, וכיצד הס קשורים זה לזה. קייס מגוון רחב של מודלים יסטנדרטייסי לייצוג מחזור חיים, וכל אחד מהם מציע גישה שונה אל משימת הפיתוח. עס זאת, כל ארגון העוסק בפיתוח תוכנה זקוק למודל, או למודלים שישקפו את התרבות והפילוסופיה שלו. מודליס מעשייס של מחזור חיים יכולים להיות מבוססיס על מודלים יסטנדרטייסי, אך אין הכרח בכך. ואכן, רק ארגוניס מעטים מיישמיס את הגישה היסטנדרטית' לפיתוח התוכנה. מודל מפל המיפ 665 8 [03ווסתט 560 0: הסוזג)ח6וח6!קוח] % 0 תדשים 4.1 מודל מפל המים תרשים 4.1 מציג את מה שהוא אולי הוואריאציה הפשוטה ביותר של מודל מפל המים. במודל זה, התהליך הבסיסי הוא סודר (וגוחסטוף50). למרות שייתכנו חזרות בכל אחד מהשלביס, התהליך עצמו מתקדס משלב לשלב בצורה קווית רציפה. הרצף כולל בדרך כלל בניית מפרט דרישות בשיתוף המשתמשים, ואחר, שימוש במפרטי הדרישות להפקה של מפרט פונקציונלי שעל המפתחים ליישם. אחר בא מפרט התיכון שמומר מאוחר יותר לקוד, ובו מתבצעות בדיקות. 6 ניהול איכות תוכנה מודל זה וכה לביקורת ממספר סיבות, החשובה שבהן היא העובדה שמשאירים את הבדיקות לשלב מאוחר מאוד בתהליך. הרחבות של תהליך זה כוללות פעולות אימות בכל שלב, אך הרצף ממשיך להיות המאפיין הראשי שלו. מודל הפיתוח של מפל המיס נמצא בשימוש נפוץ ביותר במפעלי תעשייה, ולעיתיס תכופות כברירת מחדל במקומות בהס לא הוגדר מודל פיתוח רשמי אחר. מודל התילזון ב קַחו561 פופץ!3ח4 אפו 5 וסוסזץ חסו1ג)ת6וח6!קות1 קחותתג[7 תרשיס 4.2 מודל התילזון תרשים 4.2 מציג את מודל החילזון ([4זוק5). בניגוד למפל המים, מודל זה הוא בתמציתו איטרטיבי. יש צורות רבות של המודל, אך כולן מדגישות את האופי האיטרטיבי של התהליך, אף שאחדות מהוואריאציות שלו ממליצות שהשלב האחרון בפיתוח החלזוני יהיה פיתוח של מפל מיס באיטרציה הסופית של התיכון. על פי המודל החלזוני בוניס סדרה של אבטיפוסיס, שכל אחד מהס מוערך אל מול הדרישות עד שמתגלה פתרון קביל. בנקודה זו אפשר להשתמש באבטיפוס לצורך יצירת מפרט דרישות ואז לסלקו, או שאפשר להציג ולמסור את האבטיפוס, בתור המערכת שעונה על הדרישות. המודל ממליץ שהגישה אל הפיתוח תהיה ללא הגדרה סופית (כלומר פתוח), גישה שקשה יהיה לנהלה באמצעות טכניקות מסורתיות של ניהול פרויקטים. מודל החילזון לא היה עד כה בשימוש נפוץ, אך הוא מתחיל להיות מקובל *ותר, ככל שגדלה הפופולריות של טכניקות האבטיפוס. טכניקות חלזוניות, או ילא-קוויותי, יידונו בחלק 4 של הספר. פרק 4: תהליך הפיתוח הבסיס: | 87 מודל מסוג צ 6 1 הג 1651 00618066 - 56 1 חג!ק 1651 וח5516 - תסוזג3זק6)ח] ובו 60 בו חסוו6ז/ [3חסווסחט] חסו1641 560 סזו60 וז חגזק 651) ח0ו81זק6וח] ו 657 חסוו60]וזט/ ח0ו601])ז6 תדשיס 4.3 מודל מסוג ץ מודל מסוג ‏ מוצג בתור פיתוח של מודל מפל המים, והוא הולך ונעשה פופולרי יותר ויותר. מודל % הוא דוגמה של המודל התיאורטי שרק לעיתים רחוקות מיושס בשלמותו, אך עס זאת, משמש כהשראה לרבים ממחזורי החייסם המעשיים. תרשים 4.3 מציג מודל מסוג %. למרות שבתמציתו זהו מודל המבוסס על רצף, המודל שלפנינו מתרכז בבדיקות בשלב הרבה יותר מוקדסם מאשר מפל המים. אופי האימות ובדיקת התקפות שבמודל, והתפקיד והמטרה שיש למתודולוגיה, יידונו בפירוט מסויס בהמשך הפרק. בפרקים הבאיס ישמש המודל כאמצעי לתיאור והשוואת שיטות וטכניקות. מתודולוגיות מהי מתודולוגיה! כיצד נכיר אותה לכשניתקל בה: מתודולוגיה - אוסף שיטות שבשימוש בענף פעילות מסוים. מילון אוקספורד המקוצר מכל בחינה מעשית, מתודולוגיה של פיתוח תוכנה היא שיטה, או שיטות אשר ישימות לאחת או יותר משלבי מחזור חיים; בתנאיס אידיאליים תהיה המתודולוגיה ישימה לגבי כל השלבים. 8 ניהול איכות תוכנה המתודולוגיות לפיתוח תוכנה כוללות בדרך כלל: = :יצוג גרפי ו/או טקסטואלי; = הגדרה של השלבים שיינקטו ומטרותיהס; = הגדרה של הקלט והפלט הדרושים עבור כל שלב; = תבניות של המוצריס המוגמריס הנדרשיס מכל שלב. ההגדרה אינה מכתיבה כלליס חד-משמעיים. כל דבר שיענה על המדדיס הרשומיס לעיל, יהיה בו כדי לספק את רוב היתרונות שניתן להפיק ממתודולוגיה, כל עוד הוא הולס את צרכינו. לשס מה להשתמש במתודולוגיות! האס אין בהן משוס תקורה ביורוקרטית המאיטה את קצב הפיתותח! הדבר ייתכן מאוד! למעשה, בחירה במתודולוגיה שאינה הולמת, כגון מתודולוגיה המכילה יותר שלבים, או דרישות לרישוס מכפי הדרוש לנו, תגרוס לעיתיס תכופות לתקורה מיותרת ותצמצס את הפריון. עס זאת, יש להיזהר מהמסקנה האומרת שכל דבר נחשב לתקורה רק משוס שהוא גורס לנו לעשות דבריסם שקודס לכן לא נהגנו לעשותס. כדי שמתודולוגיה תוסיף עבורנו ערך, עליה להגביר בדרך כלשהי את הפריון שלנו. כיצד יש ביכולת המתודולוגיה לעשות זאת? [. על ידי הקטנת מספר השגיאות והעיבודיס החוזריס הנלוויס להן, בעיקר כאשר מדובר בשגיאות הנעשות בשלביס המוקדמיס של התהליך, שבדרך כלל גורמות לעבודה חוזרת יקרה לקראת סופו של מחזור החיים. 2 על ידי צמצוס מספר השגיאות שעלינו לתקן לאחר האספקה, דבר המאפשר לנו לצמצס את המשאביס המוקצביס לתחזוקה. 3 על ידי כך שהיא מאפשרת לנו להגדיר כלים שיסייעו בפעילויות היותר שגרתיות, ולקשר יחד את הכליס ליצירת סביבת פיתוח אפקטיבית. הסיבה הראשית לשימוש במתודולוגיה היא היתרונות הנובעיס משימוש באוסף שיטות עקביות וסבירות. היכולת להגדיר ולנצל שפה משותפת, מילולית וגרפית, מהווה צעד עצוס לקראת הסרת מחסומי התקשורת שקיימים באופן בלתי נמנע בין הלקות, המפתת ושלבי הפיתוח. ללא שפה משותפת זו, לא יהיה בסיס לדבר חשוב יותר, והוא תרבות משותפת. כאשר אנשיס מתחיליס להבין את המידע המועבר להם, גדלים הסיכוייס שיהיו אוהדיס יותר לנקודת הראות של מעביר המידע. תועלת יחידה זו כשלעצמה יש בה כדי להצדיק לחלוטין את המאמצ של יישוס המתודולוגיה, אלא שעל אלה מתוסף יתרון נכבד. גם מנהל הפרויקט יוצא נשכר מגישת המתודולוגיה. המנהל נמצא תחת לת רב שנגרס ממאמציו להעריך את עלות העבודה ולהרכיב תוכנית סבירה עבור הפיתות. המתודולוגיה יכולה לסייע לעדן את מיתאר הפרויקט שנוצר על ידי מחזור החייס הנבחר. משעה שמנהל פרויקט מחליט על מחזור החייס הבסיסי, המתודולוגיה, מבנה פלק 4: תהליך הפיתוח הבסיס: | 89 השלבים, הסיכוניס, ופעילויות האיכות המתאימות שינהלו את הסיכונים, מאותה שעה, למעשה, הפרויקט כבר די מתוכנן ורמת הפירוט תגרוס לכך שיהיה קל יותר לאמוד את הפעילויות. כיצד ניתן ליישם את המתודולוגיה למודל %! פשוט, על ידי הגדרת המוצריס המוגמריס שיתקבלו מכל שלב, כולל צורתם, וקביעת הדרך בה יאומתו. לדוגמה, נוכל להגדיר את פלט שלב ניתוח הדרישות כדלקמן (הקודים מתייחסיס למסמכי תבנית הפרויקט של האירוע שבדוגמה בהמשך): [. | מפרט דרישות, שצריך להכיל את הכותרות שבתבנית 851 ולכסות את הנושאים שברשימת התיוג 6%[1. את ההקשר הכולל יש לתאר בתרשיס זרימת נתוניס הנתמך על ידי מילון נתוניס ומפרטי תהליך מתאימים. כללים לבניית תרשימי זרימת נתוניס כלולים ב-6071. 2 מפרט של מבחן קבלה, שחייב להכיל הפנייה צולבת אל כל דרישה נפרדת ולהצביע על הקריטריוניס לקבלת כל דרישה. מפרט בדיקת הקבלה צריך להיות ערוך על פי תבנית 411 ולענות על הסוגיות שהוגדרו ב-6%2. יש לערוך טבלה שתראה את הקשרים בין כל הדרישות לבין מפרטי בדיקתן. 3 אימות שני המסמכים צריך להיעשות תוך בדיקה חוזרת של התיכון בנוכחות הרשויות הקובעות את הדרישות, את התיכון, ואת הבדיקות ולפחות נציג אחד של המשתמשים. אם כל שלבי מחזור החיים של הפיתוח יוגדרו בדרך זאת, תתקבל תוצאה שתהיה מתודולוגיה שימושית. אימות וכדיקת תקפות שני המונחיס האלה נדונים לרוב כאילו הס מהוויס חלק של טכניקה יחידה. דבר זה נכון מבחינות מסוימות. אף מוצר אינו יכול להיחשב כראוי לשימוש, אלא אס כן עבר אימות ובדיקת תקפות (ח0וז8!!03/ 0ח8 מסוז₪08!וזסט), אלא ששתי הפעילויות נבדלות זו מזו ומשיגות מטרות שונות. נטיב להמחיש זאת על ידי עיון חוזר בחלקיס המרכיביס את מחזור החיים /. מחזור החיים, כפי שעיבדנו אותו באמצעות המתודולוגיה המתאימה, כולל עתה אוסף של שלבים מוגדרים היטב, כאשר אל כל אחד מהס מקושרת קבוצה של יחידות פלט מוגדרות ומתועדות. אס נשקול שלב של מחזור החיים במבודד, נמצא שיש לו קבוצה של מוצריס מוגמריס הזקוקיס לאימות ולבדיקת תקפות (תרשים 4.6). אימות המוצריס המוגמריס המתקבלים מאחד השלביס הוא בעיקרו סוג מסויס של סקר (צוסוצ6ז). בהנחה שיש צורך בעקביות של הקלטים לשלביס השונים, יתמקד סקר זה בהשוואה בין יחידות הפלט הנוצרות בשלב זה, לבין יחידות הפלט המתקבלות מהשלב הקודם - המוגדרות כקלט לשלב הנוכתי - ובכך שתוודא שהמוצרים המוגמריס יהיו תואמים לתקנים המוגדרים, כגון תבניות המסמכים ורשימות התיוג. 0 ניהול איכות תוכנה פפסחופט 5חטוחטזוטףטז 0 א]חסותטזוטסטת חג1ק 1051 0001066 ונ 5ח6וח6זוט6 חסו]ב0ו 5601 !| |החס|סתט] | חסו108]ו6טק3 תרשים 4.6 המוצרים המופקים משלב הדרישות ניתן להגיע לאימות גם בשלב מוקדם, על ידי כך שבוחניס אס המוצרים המוגמרים הנוכחיים מתאימיס לשמש כקלט לשלב הבא, ואס המערכת שתיבנה בסופו של דבר ממוצריס אלה תענה על צורכי הלקוח. (ש016) 061!6:80165 56בחק פטסוט6זק 005 6ח3 4060086 -- ח0וז1163ב/ 6 6ת!1 ]0 הסוזוחו/06 ]0 (00ו50601/1031 71654) ב ץ0ח60051516 6₪ח8 5 חונו (ש6וש6) 6 סו וטקחו 85 ע86ט06/ -- הסוו1/00ב/ (ש16ש66) 350חק !אשת ח ופ תרשיס 4.5 בדיקת המוצרים המופקים של שלב התיכון ההיבט האחר של האימות הוא בעל חשיבות קריטית. ניתן להשיגו בצורה האפקטיבית ביותר על ידי הגדרת הבדיקות המתייחסות למוצר שיתקבל משלב זה, לכשהמערכת תיבנה לבסוף. במיליס אחרות, אנו מביטיס אל הצד הימני של תבנית-צ ומגדירים את הבדיקות שנשתמש, לכשנגיע לנקודה זו. תרשים 4.5 מציג את משטר הבדיקות עבור מוצר אופייני של שלב בתיכון. זוהי דיסציפלינה מחמירה ביותר ורק לעיתיס רחוקות ניתן לבצעה בפועל. לעיתיס תכופות מושמעת הטענה נגד הניסיון לקבוע את מפרטי פרק 4: תהליך הפיתוח הבסיס: | 91 הבדיקות כבר בשלב הזה, משום שרמת ההגדרה עדיין אינה מאפשרת את קביעת מפרט הבדיקות. ואס כן, האס ניתן להגדיר את התיכון בצורה שתאפשר להתקדם בביטחון אל שלב הפיתוח הבא! יש תמיד מקום לעידון המפרטיס ככל שמתקדס הפיתוח. עס זאת, העוסק בפיתות וממשיך קדימה, מבלי לעגן את שלב הפיתות על ידי קביעה מראש של מוצרי התיכון והגדרת הבדיקות הנלווים להם, מזמין לעצמו צרות בדמות מחלת הדרישות הזוחלות. (יהול תגורה ניהול תצורה (וח6ו486חגות ת0ו41זטקותס6) הוא למעשה, הדבק המאחד את פיתות התוכנה. אין קושי לעסוק בקטעי קוד המופעלים כל אחד בפני עצמו. לעומת זאת, המשימה נראית אחרת לגמרי כאשר יש צורך לקחת דרישה ולחולל ממנה מערכת אשר תכלול עשרות מודולים, שיפעלו בצורה נכונה, ויצטרפו בהצלחה ליצירת התוצאה הכוללת הרצויה. הדיסציפלינה (ואכן יש כאן צורך בדיסציפלינה), של ניהול תצורה, משמעותה התבוננות קדימה אל הנקודה בה אולי תמצא את עצמך כשברשותך עשרות מודולים שונים, שלכל אחד מהס מספר גרסאות. אס תעשה זאת, תמצא את עצמך עסוק כל הזמן בסילוק שגיאות, ומהרהר בשאלה כיצד תדע איזו היא הגירסה הנכונה של כל אחד מהס שיש לצרף למוצר הסופי. ניהול תצורה הינו תהליך בן שלושה חלקיס, שלכל אחד מהס נודעת חשיבות עליונה: [. זיהוי (ח0וז004/זח66/). מתן שמות ייחודייס לכל פריט, וסימני זיהוי לגרסאות כדי שתוכל להבחין תמיד בין פריט לפריט. בקרת שינויים ([סזותס6 6פַחגתס). מנגנון לבקרת שינויים, כדי להבטיח שכל מרכיבי הפעילות יהיו במסלול ובקצב הנכון. כשחל שינוי בפריט כלשהו, עלינו לוודא שכל הפריטים האחריס המתקשרים עם פריט זה, או משתמשים בו, ישונו אף הס (במידת הצורך) בצורה שתאפשר להס לפעול עס הפריט ששונה. יכולת מעקב (עו!46099זו). מנגנון שיאפשר לנו לעקוב אחר הנתיב המוליך אל היווצרות כל פריט. למשל, במקרה שמשתנים מפרטי התיכון, עלינו לדעת מי הפריטיס שנוצרו לפי מפרטי תיכון אלה, כך שנוכל לוודא שכל הפריטים ישקפו את המפרטיס החדשים. ניהול תצורה קשה ליישוס ובלתי-אהוד, משוס שהוא נוטה להאט את הקצב ולשיס מכשוליס בדרכם של מפתחים נמרצים. בדבר אחד אנו יכולים להיות בטוחים - כישלון בניהול התצורה, יביא לאסון במוקדס או במאוחר. ניהול גרוע של התצורה יכול להתבטא בצורות רבות. ביניהן, מוצרים הנמסריס ללקות ועדיין מכיליס שגיאה שדווחה ונפתרה כבר לפני שלושה חודשים, התקנות הכושלות בשל העדר קובץ מסוים, או עדכוניס הגורמים לנפילת מערכת, משוס שתוכנית שנכללה בעדכון מנסה לגשת אל קובץ מערכת שתבנית הנתוניס בו שונתה. 2 ניהול איכות תוכנת תחזוקת תוכנה יש חשיבות לתחזוקת התוכנה, משוס שהיא צורכת כמות משאבים גבוהה בהרבה מזו של פיתוח התוכנה. מוצר התוכנה הממוצע ימבלה' רק 20 אחוז מחייו בפיתוח, שאר הזמן עובר בתחזוקה. בדרך כלל, התחזוקה נחשבת כפחות משמעותית מאשר הפיתוח משוס שמשימותיה, לרוב שינוייס במערכות הקיימות, קטנות יחסית כאשר משוויס אותן לפרויקטיס הגדוליס של הפיתותח. זוהי טעות חמורה, לא רק משוס שהתחזוקה צורכת חלק גדול יותר יחסית של המשאבים שלנו, אלא גס משוס שרבים משינויי התחזוקה הס קריטייס לתפקוד האפקטיבי של המערכת. העובדה שהשינוי מתבטא במספר קטן של שורות הקוד המושפעות ממנו אינה עושה את השינוי לבלתי חשוב, או לנטול סיכוניס. הכללת שינוייס בני ישורה אחת בלבדי בתוך השורות של קוד כלשהו עס מינימוס של בדיקות או בכלל לא, אך מסתכמת בתוצאות הרות-אסון, היא תרחיש שכיח מדי. לתחזוקה בעיות ודרישות מיוחדות משלה. בעיות תחזוקת התוכנה 1. חוסר תיעוד. התיעוד לא היה שלס בזמן האספקה וגס לא הושלס לאחר מכן, או שהתיעוד לא עמד בקצב השינוייס. התוצאה היא שכל השינוייס מעוצביס ברמת הקוד. 2 בדיקות בלתי מספקות. הבדיקות מבוססות על גודל השינוי, במקוס להיות מבוססות על הסיכון הכרוך בשגיאות תוכנה. שינוייס קריטיים זוכיסם לאותו מאמ שזוכיס שינוייס טריוויאלייס. 3 חוסר מתודולוגיה. שינוייס קטניס אינס מצדיקיס את התקורה של התיכון ושל בדיקות הביקורת. התוצאה היא שכל אחד יעושה את החלק שלוי. שימוש שגוי בנתונים, ממשקי תוכנה לא נכונים וסגנונות תכנות ייחודייס, כל אלה תורמיס להגברת הסיכויים לשגיאות. 4. אין ניהול תצורה. הזמן הנדרש למעבר דרך נוהל בקרת השינויים גדול מדי עבור כל שינול טריוויאלי. תוכניתן המבצע שינוי בתוכנית וחושף באג תוך כדי כך, סביר שיתקן אותו תוך כדי ביצוע השינוי. בינתיים, נפגסם הממשק בין המודול יהמנופהי לבין מודול שנמצא במקוס אחר. 5 אין תכנון. כל דבר מתבצע יתוך כדי תנועהי, והתוצאה היא ששינוייס נוטים להתנגש זה בזה. פרק 4: תהליך הפיתוח הבסיס:י ‏ 93 התחזוקה מותנית כמעט לחלוטין בנהגי פיתוח טוביס, שיאפשרו לוודא שפעילות התחזוקה תתחיל ממוצר מוגדר היטב, שהוא בעל תצורה מנוהלת וגס מתועד כהלכה. באותה מידה, חשוב שהמוצר יהיה פרי תיכון המביא בחשבון את התחזוקה. סיכוייו של מבנה מודולרי ברור עם ממשקים ברורים ופשוטים, להמשיך ולשמור על שלמותו, רבים יותר מאשר סיכוייו של יכדור ספגטלי. כיעד תומך תקן 9000-3 180 ברעיונות מפתח אלה ה(חייה ב(ושא לחזור החיים כל מבנה 9000-3 180 מבוסס על העיקרון שפיתוח התוכנה יתנהל בהֶקְָשר מחזור חיים של פיתוח. בסעיף 5.1, מתבטאת ציפייה זו בקביעה שההתייחסות למחזור חיים, אין לפרשה כהפנייה אל מודל זה או אחר של מחזור החיים. אם כן, תקן 9000-3 150 מצפה מאתנו שנשתמש במודל מחזור חייס להגדרת המסגרת עבור נהגי הפיתוח. עם זאת, הוא אינו מנסה להכתיב מחזור חיים ספציפי, ואפילו אינו מציע ייעוץ לגבי מה שיכול להיחשב כמחזור חייס יטובי. ה(חייה ב(ושא מתודולוגיות מתודולוגיות מופיעות בתקן 9000-3 180 תחת שלוש כותרות נפרדות : [. שיטות וכלים לפיתוח (5.4.2.3). הציפייה היא שתוכניות הפיתוח עבור פרויקטיס יזהו את האמצעיס שנועדו לוודא שהפעילויות מתבצעות בצורה נכונה. נוסף לכלים ולטכניקות, מאזכר סעיף זה כללים, נהגיס ומוסכמות לפיתוח. תָכָן ויישום (5.6). מאוזכרות מתודולוגיות תיכון וגס מתודולוגיות יישוס. פעילויות תומכות. מאוזכרים כלליס, נהגים ומוסכמות (6.5), בלים וטכניקות (6.6) מאוזכרים שנית, אך הפעם בהקשר של הארגון הכולל. הקווים המנחים מספקיס מסר חזק ביותר שיש לבחור ולהשתמש בכלים, טכניקות ושיטות על בסיס כלל-ארגוני. בעת התחלת פרויקט יש לתת את הדעת על הכלים, הטכניקות והשיטות עבור הפיתוח המסוים ולבחור אותס מבין אלה הזמיניס בארגון. במקרה שכל אלה אינם זמינים או מתאימים, חייבת תוכנית הפיתוח לזהות גישה ספציפית לפרויקט בנושאיס אלה. זוהי גישה מובנית מאוד, אך אין לראות בה מרשס מחייב. הבחירה מסורה לחלוטין בידי המפתח, וזאת צריכה לכלול רק את הנוהג הקיים בתוך הארגון, בתנאי שיש בו הגדרה הולמת של התהליך. היתרונות הגדוליס הנובעיס מגישה זאת הס בדיוק אלה שקשורים בהגדרת מחזור החיים, כולס יודעים מהי הגישה שאושרה. יש להניח שלא כל אחד בצוות הפיתוח יהיה מאושר עס הגישה שנבחרה, אך מערכת מתועדת יכולה לשמש בסיס לדיון מושכל בדבר שיפורים שיוכנסו במערכת. 4 ניהול איכות תוכנה הנחיות בנושא אימות תקן 9000-3 150 מציג את נושא האימות בכל שלב בצורה חזקה ביותר (סעיף 5.4.6), וממליץ לערוך תוכנית לאימות פלט בכל שלב. קיימות גס גישות חלופיות לנושא האימות, אך הגישה של סקירות חוזרות של העיצוב מוצגת כגישה מתאימה. ההגדרות של תקן 9000-3 180 לאימות ולבדיקת התקפות הן כדלקמן 1. אימות (לגבי תוכנה). זהו התהליך של הערכת מוצרים (פַּחוזזְגט[94צ6) שהופקו בשלב מסוים, כדי לוודא נכונות ועקביות של המוצריס והתקניס שהוזנו כקלט לשלב זה. 2 בדיקת תקפות (לגבי תוכנה). התהליך של הערכת התוכנה, כדי לוודא עמידה בדרישות מוגדרות. הקוויס המנחיס מרחיקיס אל מעבר לקביעת דיסציפלינה בסיסית. הם מצפים לכך שהתוצאות של פעילויות האימות ושל כל הפעולות שתינקטנה לתיקון שגיאות, תרשמנה ותיבדקנה בסוף כל פעילות. ואף למעלה מזה, הס מצפים לכך שרק המנות המאומתות של הפלט המיוצר על ידי הפיתוח, תוגשנה לניהול התצורה ותתקבלנה לשימוש מאוחר יותר. הקוויס המנחיס ממליצים גס (5.4.4 ו- 5.4.5) שהדרישות לשלבי הפיתוח והתוצר של כל שלב פיתות יוגדרו ויתועדו במלואס. המטרה העיקרית היא לאפשר אימות חיובי של פעילות השלב, אך גס כדי לוודא שמידע כגון קריטריוניס לקבלה יועבר הלאה אל השלב המתאיס במחזור החייס. המקרה הפרטי של קלט השלב ההתחלתי - הדרישה עצמה - זוכה בצדק לאזכור מיוחד. אזכור קצר אבל חריף! כל דרישה חייבת להיות מוגדרת בצורה כזאת שתאפשר לנו לאמת שהיא אכן הושגה. ממשפט פשוט זה משתמעת הגדרה של קריטריוני קבלה מכומתיס או ניתניס למדידה, או שתתקייס הדגמה אובייקטיבית שתוכיח את השגת הדרישה. למשפט זה מתוספת העצה שדרישות בלתי שלמות, מעורפלות או מנוגדות, תטופלנה עס הדרגיס האחראיס לניסוח הדרישות. ה(חיות בנושא סקויפ סעיף 5.6.4 של תקן 9000-3 150 ממליץ על סקרים כאמצעי שמוודה עמידה בדרישות, ושבודק אם שיטות העבודה שהוגדרו מתבצעות כהלכה. בהמשך לכך מופיע המשפט החשוב הבא : אסור שהעיצוב או תהליך היישום יתקדמו כל עוד לא נפתרו בצורה משביעת רצון התוצאות של כל הפגמים הידועים, או כל עוד לא ידוע מהו הסיכון שבהמשך העבודה ללא פתרונות אלה. פלק 4: תהליך הפיתוח הבסיטי | 95 ל 2-ו עצה זו היא בעלת חשיבות רבה ביותר. לאחר כל ההמלצות בנושאי המתודולוגיה, הכללים וכל האמצעיס האחרים שנועדו להגביר את חשיפת הסיכונים, מומל לשקול את הסיכוניס שזוהו כבר, ולהחליט אס יש ביכולתנו להמשיך בביטחון בעבודה. ה(חיות כנושא גדיקות והוכחת התקפות תקן 13 150 נותן *יעוץ כללי מסוים, בכך שהוא מציין שהבדיקות עשויות להידרש במספר רמות; אלא שבדיקת תקפות, בדיקות שדה ומבחני קבלה עשויים גס הס להיות חלק מאותה פעילות. קיימות מספר גישות שניתן לאמץ. כל גישה שנאמץ חייבת להיות מוגדרת בתוכנית בדיקות, שעשויה להיות חלק ממסמך אחר (כגון תוכנית איכות או תוכנית הפרויקט), או שתוכנית ה בדיקות תהיה מוגדרת במספר מסמכים (כגון תוכנית בדיקות של יחידת תכנות, תוכנית ליישוס כוללת, ותוכנית למבחני קבלה). נראה שמרחב הפעולה גדול למדי. בנקודה זו הופך תקן 9000-3 150 להיות מאוד לא-מסייע! תחת הכותרת יתכנון הבדיקהי (5.7.2) נאמר שהספק צריך ליצור ולבקר מסמכיס שוניס הקשוריס בבדיקות. ניתנת שס רשימה של תחומיס המחייביס תשומת לב. רשימת המסמכים כוללת מפרטי בדיקה, נהלים ותוכניות, אך אין הוא מחכים אותנו בכל הנוגע למה שצריך להיכלל במסמכים אלה. אנחנו חייביס אם כן, לבנות בעצמנו את הגדרות הפעולה שלנו. הנחיות גנושא (יהול תצורה תקן 9000-3 150 מקדיש קטע שלס (6.1) לניהול תצורה, בו הוא מכסה את כל הסוגיות שנסקרו לעיל. קיימים ארבעה תחומים נוספים בהס יש חשיבות לניהול התצורה: |. בקרת מסמכים (6.2) מהווה סוגיה בפני עצמה, אך בקרת העילצוב ותיעוד הניסויים קשורים קשר הדוק לבקרת השינויים. לתחזוקה מוקדשים שני תחומי טיפול שבהם הזיהוי הוא קריטי: זיהוי המצב ההתחילי של המוצר (5.10.3) ונהלי המסירה, או השחרור של המוצר (5.10.7). שכפול, הספקה והתקנה (5.9) כוללים בדיקות שמטרתן לוודא שהתיעוד הנכון אכן זמין. סעיף זה עוסק גס בצורך להחזיק עותקי גיבוי המשקפים את מצבו הנוכחי של המוצר. סעיף הבדיקה (5.7.3) מציין שהשינויים יכוליס להוליך לבדיקות חוזרים. כאן מתעוררות מספר סוגיות. השאלה בדבר מה שיש לבדוק בשנית ואיזה סוג של בדיקות חוזרות לבצע, תטופל מאוחר יותר. הסוגיה בה ניהול התצורה צריך לעסוק היא ששינוייס בפריט תוכנה עשויים לחייב שינוייס בבדיקות שנועדו לבדוק את תקפותו. לכן חייביס פריט התוכנה ובדיקתו להיות מקושריס בדרך כלשהי על ידי מערכת ניהול תצורה. 6 ניהול איכות תוכנת ה(חיות ב(ושא תחזוקת התוכ(ה סעיף 5.10 של הקוויס המנחים דן בבקרה וברישוס של פעילויות התחזוקה. למרות שהס מספקיס הנתיות מסוימות בדבר מנגנוני הבקרה הבסיסיים, אין הקווים המנחים טורחיס הרבה בהדגשת החשיבות של התחזוקה, או על יצירת הקישור עס הפיתוח. (הלי פיתות תוכ(ה מחזור החיים הוא המפתח לזיהוי נהלי פיתוח התוכנה הדרושים לך. מתוך מודל זה של מחזור התיים ינבעו כל פעילויות האיכות שלך. ההחלטה בדבר הצורה הבסיסית של תהליך הפיתות שתבחר בו, היא ההחלטה היתידה הגדולה ביותר שיהיה עליך להתליט אי פעם בהקשר למערכת איכות. אס אתה סבור שעבודת פיתוח תוכנה היא יותר מדי מגוונת מכדי שאפשר יהיה לתאר אותה במודל יחיד, אל דאגה! ייתכן שתזדקק ליותר מאשר מודל אחד, כלומר, מודל אחד לפיתוחיס מובניס ומודל אחד לעריכת אבטיפוס. ייתכן גס שמודל אחד יוכל לענות על כל האפשרויות, אלא שאתה לא תהיה מעונין לכלול בו כל פעילות בכל פעס שתשתמש בו. יש מוצא עבור כל מגוון האפשרויות האלו. הדבר התחיוני באמת הוא פגישה משותפת שלך ושל כל עובדיך כדי לסכס על תהליך הפיתות. תרגיל זה להשגת הסכמה משותפת של קבוצת מומחי תוכנה לתהליך הפיתוח, יכול להפתיע במידת הקושי שבו. מאידך, תוכל למצוא עידוד בעובדה שככל שיגדל הקושי בקבלת ההסכמה, כך במרוצת הזמן, יגדל גם ערך המודל שייבחר. מה הס הנהליס הדרושיס לך! לאחר שתגדיר את מחזור התיים, יהיה עליך לזהות את תהליכי המפתח הכלולים בו ולתעדם בהתאם. ברמה המפורטת, יידרשו מספר כללים לתיכון וקידוד, יחד עס הנחיות בדבר השימוש באותן מתודולוגיות ותבניות שבחרת, לצורך יצירת מסמכי המפתח שמחזור התיים שלך מצפה שיופקו על ידי המפתחים. הנהלים יכולים לסייע בתיאור הגישה הכוללת אל האימות באמצעות בדיקות, ואל בדיקת התקפות באמצעות סקרים. עס זאת, בתחוס זה, ארגוניס רבים אינס חורגיס מעבר למתן הנחיות בלבד, כשהס מניחיס למנהלי הפרויקטים להגדיר בתוכנית האיכות את הגישה הנדרשת. ניתן גם להפיק נהלים לניהול פרויקטיס שיהיו תואמים לתהליך פיתוח התוכנה. מתודולוגיות מעשיות המתודולוגיות קיימות כדי למלא שתי מטרות חיוניות: *= להקל על פיתוח המבוסס על צוות; * להגדיל את שקיפות תהליך הפיתוח ולצמצס את הסיכוניס. פרק 4: תהליך הפיתות הבסיס: | 97 - 7 ברור שבפרויקטיס גדוליס יש חשיבות לשני ההיבטיס. במקרים כאלה, יש רק מידה מועטה של אי הסכמה בין המפתתים כל הוצאות התקורה הקשורות בשימוש במתודולוגיה מסוימת מתקבלות כהכרח הנדרש להגבלת הסיכוניס למסגרת בעלת גבולות סביריס. בפרויקטיס קטניס יותר, בהס הצוותים בדרך כלל קטניס ומלוכדים, נראה תהליך הפיתוח כפחות בעייתי וניהול הסיכון הוא נראה כבעיה העיקרית. אין ספק שהתקשורת בתוך הצוות אמורה להיות קלה יותר וחשופה פחות לשגיאות מאשר בצוות גדול יותר, יחסית, גס קל יותר לטפת את התרבות המשותפת ואת צורת התיעוד. לכן, קשה יותר להצדיק בפני צוות הפיתוח את התקורה הכרוכה בשימוש במתודולוגיה, בעיקר את הזמן המוקדש לתיעוד. אף על פי שחלק גדול מהביקורת המוטחת כלפי המתודולוגיות מכוון לרוב נגד כל ניסיון להנהיג שיטת בקרה, אין להתעלם מכך שטמונה כאן בעיה אמיתית. את המתודולוגיות יש לבחור עבור מטרות מסוימות. אכיפת מתודולוגיה שרירותית על פרויקט קטן יכולה לשמש סיבה לגיטימית לדאגה. עס זאת, יש בכל זאת יתרונות למתודולוגיות ואין להיפטר מהן בקלות. מה שנדרש כאן, הוא איזון זהיר בין היתרונות לבין התקורה. כך ניתן להגיע לסביבת פיתות המצמצמת את הסיכוניס ומגדילה עד למקסימום את ההזדמנות לעבודת צוות (במקרים המתאימים), מבלי לדכא את יוזמות התיכון הפתוחות לפני המפתחים. כיצד ניתן לעשות זאת? ראשית, על ידי סיווג הפרויקטים במונחים של גודל וסיכון, כך שאפשר יהיה להגדיר את רמות ניהול האיכות עבור כל סוג וסוג, במקוס להסתפק בהתייחסות כוללנית עבור כל הארגון. במסגרת סכימה כזאת, יכולים להיות לנו חמישה סוגיס של פרויקטיסם : ו ויויווווורוורורו וו ור סיווג הפרויקטים ---------------- 7-ה וווהוקיי-הההווההה-להה-ההלולוולהה-ה-לווהו היו וקד . [. גדול ו/או יקר, שיש בו גורמי סיכון רבים. למשל, למעלה משישה חודשי זמן פיתוח; צוות פרויקט גדול מארבעה איש; שימוש בטכנולוגיה תחדשה. כ גודל בינוני או גדול, עם גורמי סיכון נמוכים יחסית. למשל, שלושה עד שישה חודשי פיתוח עם צוות פרויקט של שלושה איש, או שישה חודשים אך ללא גורמיס חדשניים. 3 פרויקטים קטנים או בעלי סיכון נמוך. למשל, פרויקט של איש אחד עד לשישה שבועות; 4. משימות תחזוקה, שיטופלו בצורה שונה מזו של פרויקטי פיתות; פרויקטים פנימיים ליצירת אבטיפוס למטרת הערכות, או הדגמות בלבד. -----ְ-ְ]7--/-/-0ר0ר0000000------------------77 ות בעזרת סכימה ממין זה אנו יכולים להגדיר רמות תכנון, ותמיכת מתודולוגיה המתאימה לכל רמה. אנו גם יכוליס להניח למנהלי פרויקטים לשפוט בעצמס לאיזה סוג משתייך הפרויקט שלהס. 8 ניהול איכות תוכנה וריש שוציוי הויוויייקטוהווורולילווויקוווור רסו ור רררש/רררר הר )...רב - שנית, אנו יכוליס לנקוט בגישה מיתוצרת ביתי להגדרת המתודולוגיה, על ידי הגדרת כלליס, קודי התנהגות, סטנדרטיס, תבניות ורשימות תיוג. כל אלה צריכיס להתאים לפעילויות שונות, שידוע שהן מכילות סיכון של שגיאות ממין מסוים. גס במקרה זה יש למנהלי הפרויקטים יכולת בחירה במתודולוגיה, שהפעס היא בנויה מיערכהי של רכיבים. נדון כאן בשתי דוגמאות של רכיביס כאלה. = כללי תיכון; * נהגי תכנות. כללי תיכון כללי תיכון המבוססיסם על היגיון פשוט יכולים לסייע בקביעת לנהגי תיכון טובים. הנחיות פשוטות בדבר פיצול פונקציות למודול תוכניות, הגודל האופטימלי לגודל תוכנית, מורכבות מבני נתוניס, ותבנית להגדרת ממשקים. כל אלה ישמשו ליצירת יסודות בריאיס. ערכי מדידה כגון זיווג (פתו![קטס6), לכידות (ח0ו60005) ומורכבות (עואס!קוחס6), יכולות לספק לנו מדידות כמותיות של התיכון. גס אס היעדים שייקבעו יהיו שרירותיים, רישומי הביצוע בפועל יאפשרו אופטימיזציית יעדיס במרוצת הזמן. קוויס מנחים מעשייס בדבר השגת יכולת הבדיקה, התחזוקה ויכולות מסוגיס אחרים, יסייעו למעצביס למקד את תשומת הלב בסוגיות משמעותיות יותר של התיכון. הצבת כללים כרוכה בסיכון מסוים. מה יקרה אס הכללים שגויים, ואנו נשיג פריון נמוך, או שאמינות המוצר תהיה ירודה! כל אלה מחזקים עוד יותר את הצורך בשיתוף מספר גדול ככל האפשר של מפתחים בדיון על הכללים, עוד לפני הפעלתם. משעה שנתחיל להשתמש בכללים אלה, ההשוואה בין מדידות ההצלחה שהושגה לבין הפרמטריס שנקבעו בכללים, תאפשר בטוות הארוך *ותר להנהיג את ההתאמות הדרושות לאופטימיזציה של מידת אפקטיביות כללי התיכון. (הגי תכגנות נהגי התכנות הס מקרה פרטי בתוך כללי התיכון, אך הס מתייחסים *ותר לגילוס הפיסי של התיכון, ולא לרעיונות המופשטיס מאחוריו. יש חשיבות לצורה בה אנו כותביס תוכניות אלו. במקריס מסוימיסם החשיבות גבוהה יותר מאשר במקריס אחריסם, אך היא קיימת תמיד. ביישומיס מסוימיס מהירות הביצוע, או צמצוס עד למינימוס של השטח הנדרש לנתוניס עשוייס להוות שיקולים מרכזיים. ביישומיס אחרים, היבטיס של השפה שבשימוש עלוליס להיות כרוכים בסיכוניס. בכל המקרים, מי שצברו ניסיון בשפה וביישוס יודעיס מאיזה מכשוליס עליהס להימנע וכיצד לעשות זאת. הס גם מכיריס את השגיונות האופיינייס לכל שפת תכנות ומהדר בהס הס משתמשים. עדיף להעלות על הכתב את כל הידוע ולהביא אותו לידיעת עובדיס מנוסיס פחות, מאשר להניח לכל אחד ללמוד מתוך שגיאותיו. גם אס ידוע רק מעט יחסית אודות פרק 4: תהליך הפיתות הבסיס: 99 השפה או היישוס, היתרון שברישוס הדבריס הוא בכך שהם יכוליס לשמש בסיס לתיקוניס ולשיפוריס במועד מאוחר יותר. החשוב מכל הוא שאין לאכוף מתודולוגיה מסוימת, ואפילו לא לזהות את סוג הכללים או התבניות שצריך להשתמש בהם, צריך לוודא שנשקלו כל האפשרויות ונשאלו השאלות המתאימות. נהוג להגדיר כלליס לצורת העריכה של הקוד, כדי לפשט את הכנת הסקר. כללים המתייחסיס למורכבות המודולים יש בהס כדי להביא תועלת, משוס שהם מסייעים לשמור את הבדיקות של המודולים בתוך גבולות סבירים. אפשר להשתמש בכללים אלה כדי להתריע על הצורך בבדיקות מיוחדות כאשר המעצב סבור שיש מקוס לחרוג מהגבולות שנקבעו. לפעמיס דרושיס כלליס הקובעיס את השימוש במבני תכנות מיוחדיס כדי להשיג תוצאות מסוימות (כגון הגישה העדיפה למבני לולאה), או איסור השימוש במבנים מיוחדיס שהשימוש בהס עלול לערער את המערכת (כמו במערכת רגישה לבטיחות). למעשה, כל אחד מאתנו חייב להפעיל את שיקול דעתו, כדי לקבוע מה הולם את הסביבה והיישוס המסוימים שלו. פיתוח הטבוסס על טכ(ולוגיית 'הדור הרכיעיי טכנולוגיית הדור הרביעי מהווה מבחינות מסוימות גשר בין שיטות ידניות לשיטות ממוחשבות. היא מציעה נתיב יקיצור דרך' אל מוצרי תוכנה, שבאפשרותו לחולל אוטומטית מוצריס מוגמריס של אחד, או יותר מהשלביס של מחזור החיים. מוצרי הדור הרביעי, החל במחוללי קודיס המפשטים את משימת התכנות, דרך מחוללי יישומיסם המחליפים כמעט לגמרי את שלב העיצוב הפיסי, מציעיס יתרונות המחשוב במונחים של הפריון ההתחלתי, אך תוך עלות במונחיס של ניהול המוצר לטווח הארוך. שני מאפיינים מחייביס תשומת לב מיוחדת : 1 אי אפשר להשתמש בשלב שעבר הפשטה, או הוצא ממחזור החיים, כדי לחולל בדיקות של מוצרי התוכנה ההולכים ומתהוויס. הכוונה היא, שכלי שממיר מודל של נתונים לקוד, מדלג על שלב העיצוב הפיסי מהדרג הגבוה. על ידי כך קשה, או שנמנעת האפשרות להגדיר בדיקות בארכיטקטורה הכוללת של התוכנה. האופי והממדים של הבעיה יבואו לידי ביטוי בדיון הבא בנושא הבדיקות. לעיתים לא ניתן לשנות בנקל את המוצריס המוגמרים שמתחוללים אוטומטית. גם שינוייס קטנים למדי יכולים לחייב אותנו לחולל מחדש את כל מערכת התוכנה. 0 ניהול איכות תוכנה פיתוח מבוסס חבילות יישומיפ סטנדרטיות או מותאלות חבילות יישומים (886א80ק ת6000ו!קק8) מייצגות יישומיס שלמיס הבנויים על פלטפורמה מסוימת של חומרה ותוכנה, כדי לענות על דרישות כוללניות בתחוס של יישוס מסויס. אפשר להשתמש בהן כמות שהן, או להתאים אותן התאמה אישית כדי שיענו על דרישות מוגדרות של הלקות. בעיות אופייניות לחבילות יישומים 1. לא סביר שהחבילה תענה בדיוק על דרישותיך, לכן עליך להחליט אס ברצונך להשליס עס הפערים, או להתאיס את חבילת היישומיס לצרכיך. 2 אס תחליט להתאיס את החבילה, תצטרך להחליט אס לבצע בעצמך את העבודה (אם אתה יכול), או לבקש מהספק שיתאיס אותה עבורך. 3 אס ספק החבילה מבצע את ההתאמות, יהיה עליך להחליט כיצד לאפיין את הדרישות, ולא פחות חשוב, כיצד ייערכו מבחני הקבלה. מבחן קבלה מלא מתייב מפרט מלא של הדרישות. 4. מבלי להתייחס לשאלה מי יבצע את ההתאמות, עליך להחליט איזה מהשינוייס חיוני, ואיזה מהס אפשר לדחות או אפילו לוותר לגמרי. חשוב להיות פרגמטיים בתחוס הזה, כדי להימנע משלב מורכב ומתמשך של פיתוח ובדיקה. - 00 7777777700 קקקקקקקקקקס שיקוליס אלה רחוקיס מלהיות קלי ערך. אין לקבל בקלות החלטה לביצוע התאמות, ועליך להיות בטוח שהחבילה הסטנדרטית לא תוכל לענות על צרכיך. ההתאמות יכולות להיות קשות ואיטיות, ועדיין אין ביטחון שתקבל בדיוק את מה שאתה רוצה. אתה מקבל על עצמך את הסיכונים הנלווים לפיתוח, ורק יתרונות מועטיס במקרה שתצליח. במקרה הטוב, תצטרך להשקיע מאמצ ניכר ביצירת תוכניות איכות ובדיקה כדי לוודא שאתה והספק שלך תגיעו להבנה בדבר מה שאתה מצפה שיסופק לך בתוס מאמצ ההתאמה. מסוכן להניח שהחלקיס שלא חל בהס שינוי יפעלו כולס כהלכה, ולא יהיו זקוקיס לבדיקות. ללא קשר להחלטתך בדבר ההתאמות, עליך לוודא שתבחר בתשומת לב רבה בחבילה הסטנדרטית, תוך שימוש בגישה כפי שמוצגת בקטע הבא. הגחירה והשימוש בכלי תוכנה השימוש בכלי תוכנה (10013 6ז8ש508) מהווה מקור דאגה נכבד לכל מפתחי התוכנה. בקטגוריה זאת נכלליס כלים שנועדו לסייע בתהליך הפיתות (כלי 6455), כלים שנועדו לסייע בבדיקות (כלי 0457), וכלים שנועדו לסייע בניהול פרויקטיס. כלי 5 ו-0451 משווקיס בצורות רבות, ולא ייעשה כאן כל ניסיון לסווג או להעריך את כל הכלים הרבים המוצעים למכירה בשוק. מה שחשוב ביותר מנקודת הראות של האיכות הוא שהכלים שבשימוש יתאימו למשימה וייושמו בהצלחה. פדק 4: תהליך הפיתוח הבסיס: | 101 הערכה ובחירה של כליפ באיזה כליס נשתמש! רבים הארגוניס שטעו בבתחירה והתוצאה היתה שמשאביס יקרים לא נוצלו די הצורך, ובמספר מקרים, גם לא נוצלו כלל. יש כמה עקרונות חשוביס שיש לשקול בעת הבחירה. בראש וראשונה, חשוב לזכור שהסיבה העיקרית לקניית כלי תוכנה נועדה בדרך כלל להגדלת הפריון. זאת תושג על ידי מחשוב חלקיס מתאימים של התהליך, ובמקריס רבים, על ידי הקטנת מספר השגיאות הנעשות תוך כדי תהליך. כלי התוכנה יכול להיות שימושי בהגברת הפריון בדרך זו, אך ורק אס התהליך שאותו יש ברצוננו למכן הובן היטב ומיושס בצורה אפקטיבית. מחשוב תהליך שאינו מובן כהלכה מהווה סיכון חמור, משוס שהוא מרשה לכלי להגדיר את התהליך. אנו עלוליס למצוא שהצלתנו למתשב את התהליך, אלא שהתהליך אינו זה שהתכוונו אליו מלכתחילה. התוצאות יכולות לכלול עלויות הדרכה נוספות, ואפילו התנגשות בין תרבויות עבודה, משוס שהתהליך החדש יהיה זר לשאר חלקי הארגון. באותה מידה, התקנת כלי תוכנה לתמיכה בתהליך שאינו מיושס כהלכה, כמוה כהזמנה לבעלי התהליך להשתמש בכלי, כדי לתגבר את התהליך כפי שהם רואיס אותו. התוצאה היא, שלעיתים תכופות נעשה בכלי שימוש שונה בחלקיס שונים של הארגון, בדרכיס שאינן תואמות כלל זו את זו. כלל הזהב הוא: החלט תתילה על התהליך, או על המתודולוגיה, ויישם אותם. לאחר מכן חפש דרכים לתגבר אותם באמצעות כלים. משעה שברורה המטרה לה נדרש הכלי, ביכולתנו להרכיב רשימה של מאפיני הדרישות שמולה נוכל להשוות את הכליס המוצעים ולהתחיל לחפש את הכליס שיכוליס לענות על הדרישות. נזדקק גס למספר קריטריוניסם שכלי התוכנה יצטרך לעמוד בהס. קריטריונים לבחירת כלים 1. מחיר. 2 מידת ההתאמה לסביבת החומרה המסוימת. 3 מתן תשובה לשאלות כגון: 0 באיזו קלות יוכלו העובדים ללמוד את השימוש בכלי 0 כמה ארגוניס אחריס משתמשים בכליו 0 מהו המיקוס של המשתמשים האחרים, באר או מחוצה לה? 0 מה דעתס של המשתמשים הנוכחיים על הכליז 0 היכן ניתנת התמיכה לכלי, בארץ ומחוצה לה? תשובות לשאלות אלו יש לרכז ולתרגם למדדים ניתנים לכימות, כגון: 2 ניהול איכות תוכנה 4. | העובדיס צריכיס להיות מסוגליס להשתמש בכלי לאחר הדרכה בת יומיים לכל היותר. פיתוח הכלי והתמיכה תייביס להיות במדינת האס. 6. | חייביס להיות לפחות עוד חמישה משתמשיסם אחריסם. דד רר.|(7>(=-[7-]-77- הקריטריוניס המכומתיס תייבים להיות מסוכמיס ומתועדים עוד לפני התחלת תהליך הבחירה, כדי שהבחירה תהיה אובייקטיבית. צפוי שתזדקק גס למספר משימות שהכליס המועמדיס לבתירה יצטרכו לבצע. כך תוכל להשוות בצורה הוגנת בין הכלים. הקפד תמיד לבקש מהספקיס להתקין את כלי התוכנה על החומרה שלך ולהריץ הרצה נסיונית. תוכל ללמוד רבות על הכלי ועל המפיציס במהלך שלב זה של תהליך הבחירה. לאחר שתשליס את כל אלה, יוכלו הבדיקות והבחירה להתבצע בקלות רבה למדי. ההכ(ה וההרצה של כלי התוכנה בחירת כלי התוכנה אינה עדיין סוף המסע. אנו צריכיס עדיין להתקין אותו וללמד את המשתמשים כיצד להפיק ממנו את כל היתרונות הצפויים. במקרה שעומד לרשותך תקציב נתון, אל תיפול למלכודת של הוצאת כל הכסף על כלי התוכנה עצמו. זכור שההכנות לקליטת כלי תוכנה זהדצתו, צפויות לעלות לא פחות מאשר הכלי עצמו. מה כרוך בהכנות! ההדרכה היא הרכיב הראשון והבולט ביותר. אסור לקמץ בהדרכה - כליס משיגיס את מלוא ערכם, רק כאשר המשתמשיס חשים ביטחון בשימוש בהס ומכיריס לפחות את רוב הדבריס שכלי התוכנה יכול לבצע עבורס. צפויות סוגיות נוספות שיחייבו טיפול. עלינו לוודא שהכלי פועל בעולס המציאות ולא רק במעבדת הבדיקה. דבר זה יהיה כרוך בהקמת פרויקט חלוץ כלשהו, כדי לסלק בעיות מוקדמות. נצטרך לקייס מרכז תמיכה זמני כל עוד המשתמשיס רוכשים בקיאות בכלי. עלינו להביא בחשבון :רידה בפריון העובדיס בשלבים המוקדמים של השימוש בכלי, ולהתאיס את יעדינו בהתאס. אם נשקול את כל הבעיות לפני שננסה להשתמש בכלי, תהיה הצלתתנו גדולה יותר כאשר ננסה להשתמש בו יבשעות לחצי. (יהול הכליפ חשוב לזכור שבדרך כלל ניתן להשתמש בכלי התוכנה ביותר מאשר בדרך אחת. גם ייתכן במקריס מסוימים לקבוע תצורה שונה של הכלי, בצורה שתשנה את הפונקציונליות שלו. נתון זה מוסיף לעצמת הכלי, כל עוד השינוייס יהיו מבוקריס. עלינו להישמר מפני האפשרות שחלקיס שונים של הארגון יפתחו נהלי שימוש שוניס בכלי. אהו מתכון בטוח לכך שבפועל תהיה בידינו משפחה של כלים הקשורים זה לזה, פדק 4: תהליך הפיתוח הבסיס: | 103 אך גם שונים זה מזה. לא רק שכתוצאה מכך תהיה התמיכה קשה ומורכבת יותר, אלא שייתכן שנאבד גס את היתרונות הנובעיס מהפעלתו של כלי יחיד על פני כל הארגון. תמיד יש מקוס לשקול מינוי של 'מנהל כלים' (יז480ח4וז [0סז') שיהיה אחראי לתמיכה בכלי ולפיתוח היישוס שלו בדרך מובנית ועקבית. כך, שכל חלקי הארגון ייהנו מפירות השיפוריס וכל השימושיס בכלי יישארו תואמיסם זה לזה. מנהל כלים בקיא היטב בכלי יכול גם לשמש כזרז לשיפוריס של השימוש בכלי. פיתות כליפ בארגון הרהור אחרון בנושא הכלים מתייחס לאותס כליס שאנחנו בונים עבור עצמנו, אולי משוס שלא נמצא כלי מתאיס אחר בשוק. לעיתיס תכופות יהיו כלים אלה קטניס ופשוטיס יחסית, אם כי לא תמיד. אם אנו מודאגיס בנושא איכות המוצר אותו שוקדיס לפתחת, עלינו לזהות את התרומה שיתרוס הכלי למוצר המוגמר. אם הכלי הוא חלק תיוני של תהליך הפיתותח או ההספקה, עלינו להיות בטוחיס שאינו מהווה חוליה חלשה בשרשרת האיכות שלנו. עלינו לוודא שהכלי מתנהג בדיוק בהתאם למה שהתכוונו לו. כלומר, עלינו לאפיין את ההתנהגות הרצויה של הכלי, ולאחר מכן לבדוק את התקפות שלו מול אותו אפיון. (יס וי תכנון הבדיקה (חג]ק 031ו) או הניסוי שאנו מצפיס או מתכוונים לבצע הוא ללא ספק האלמנט היחיד החשוב ביותר של תהליך הבדיקה. רבים התירוצים לאי-הכנה מוקדמת של תוכנית בדיקה. רוב התירוצים הס בנוסח של יהמוצר ישתנה ממילא עוד לפני שננסה אותו, אז לשס מה לתכנן!י אלה תירוצים כוזביס לחלוטין המונחיס ביסוד חולשות האיכות שכולנו מצטערים עליהן. תכנון בדיקה מאפשר לשקול בהקדם את אופי וממדי הבדיקה ההולמיס את המוצר, או את המערכת שבפיתוח. הדבר אינו מחייב ידע מפורט של התיכון, אך כן דורש הבנה באופי היישוס שבפיתוח, ושל הסכנות הנובעות מהפיתוח המסוים הזה. כל הבדיקות צריכות להיות מותאמות לסיכון המשוער. הערכת הסיכון נמנת עס הפעילויות שקישרנו עם תכנון האיכות, והיא יכולה לשמש אותנו עכשיו כאשר אנו מתכנניס את הבדיקות. רמות הכדיקה רצוי לשקול את ההכנות לבדיקה בשלוש רמות : 1. קביעת הדרישות ותוכניות הבדיקה כתגובה להערכת הסיכוניס. 2. קביעת מפרטי הבדיקה על ידי הגדרת הבדיקות שיש צורך לבצע. 3. תיכון בפועל של הבדיקה. 4 ניתול איכות תוכנה 0. בגישה זו, צריך להיות ברור שעד למועד סמוך לביצוע הבדיקות בפועל, איננו זקוקיס לתיכון מפורט של הבדיקה. אפשר לדחות את העבודה המפורטת עד לאחר כתיבת התוכניות, ולצמצס בכך את הסיכוייס לשינויים. אנו יכוליס להרשות לעצמנו את הדחייה הזו, משוס שמפרטי הבדיקה הגדירו כבר את אסטרטגיית הבדיקה במידת הפירוט המספיקה, כדי לקבוע שהמוצר המוגמר יענה על הדרישות. עס זאת, יש לזכור שאסטרטגיית הבדיקה מונעת על ידי תוכניות הבדיקה והדרישות, המשקפות את הסיכוניס הצפוייס ואת התכונות הצפויות של המוצר. תכנון הכדיקה מה צריכה תוכנית הבדיקות לכלולי על התוכנית לקבוע את דרישות הבדיקה ואת הגישה שיש לנקוט כדי להשיגן. מבחינה זאת, דומה תכנון הבדיקה במובן הרחב לתכנון כולל של פרויקט. חשוב לזכור שתוכנית הבדיקות תצרוך כמחצית מהמשאבים ומהזמן הכולל של הפרויקט כולו, ולכן הנושא ראוי גם לשיקול דעת מתאים. עס גמר הכנת תוכנית בדיקה מחושבת היטב, מוגדרות גס פילוסופיית הבדיקה והקשר שלה לתהליך הייצור. בעוד שהפרטים עשוייס להשתנות ובוודאי גסם ישתנו, המסגרת מובטחת, משוס שהיא קבועה כבר במדיניות. אס המדיניות לא תשתנה, דבר שיחייב את הסכמת קובע המדיניות, לא יוכלו ליהתמסמסי שרירותית מפרטי הבדיקה הבלתי מוגדרים עדיין. הכנת מפרטיס אלה יכולה להדחות ללא חשש עד למועד שבו נגיע לרמת הפירוט הנכונה, ועד שתהליך הפיתות יגיע לרמת יציבות שתצדיק את מידת תשומת הלב המפורטת יותר שנדרשת למפרטי בדיקה. עס זאת, מן הראוי להשמיע כאן מילת אזהרה. אחת הסיבות השכיחות לדחייה בהכנת המפרטים והתיכוניס של בדיקה, מקורה בעובדה שהמסמך שממנו יש לבנות את מפרטי הבדיקה אינו מכיל פירוט שיש בו כדי לקבוע מה צריכות הבדיקות לכסות. למרות זאת, תהליך הת:כון נמשך לעיתים מאותו תיעוד שעליו נאמר שהוא מכיל פירוט בלתי מתאיס. אם אין ברשותך מידע מספיק לבניית הניסוי, הרי שגם אין לך מידע שיאפשר להמשיך בעיצוב בביטחון. אס לא קייםס מידע מספיק שיאפשר להחליט אס המוצרים שהוגדרו במפרט אכן הופקו בהצלחה (תפקיד מפרטי הבדיקה), אין ספק שיש מעט מדי מידע שאפשר יהיה לבסס עליו את המשך מאמצ הפיתוח. על ידי כך שנמשיך בתהליך התיכון לנוכח מצב זה, נצליח רק להעמיק את אי הוודאויות. פרק 4: תהליך הפיתות הבסיס: | 105 מה אמורה תוכנית גדיקה להכיל לפנינו מספר נושאים שתוכנית בדיקה אמורה לעסוק בהם : [. דרישות הבדיקה דרישות הבדיקה אמורות להתייחס אל דרישות המערכת, או המוצר, ולעסוק בהיבטיס של כל אחת מהן, כולל פירוט תכונות איכות רצויות, פריט אחר פריט. דרישות הבדיקה חייבות לעסוק גם בכל הסיכונים שאותרו ובמשמעותם לגבי הבדיקה. לעיתים תכופות יכולה טבלת מטריצה לשמש כאמצעי להפנייה צולבת שאפשר לסקור אותה באופן בלתי תלוי בכל הנוגע לשלמות. אפשר להשתמש בטבלאות קווי פעילות, שכבר הזכרנו קודס. 2. מדיניות הבדיקה מתוך הדרישות לבדיקה ניתן להרכיב מסגרת כוללת. מסגרת זאת תציג את רמות הבדיקה השונות שנבחרו ואת הקשרים שביניהן. היא תזהה את אופי ומטרת הבדיקה שבכל רמה. המדיניות צריכה לקבוע את ממדי הבדיקה הנדרשיס במידה שתקנה לנו את מידת הביטחון הנאותה, והיא יכולה להגדיר את רמת הכיסוי הנדרשת ברמה המבנית ו/או הפונקציונלית. כאן המקוס לקביעת מדיניות התשתית הכוללת של הבדיקה; כלומר, דרישות לרישוס התוצאות, שמירת הנתונים, השימוש בכליס או בטכניקות מסוימים, ומידת מעורבות המשתמשיסם. 3 סביבת הבדיקה סביבת הבדיקה כוללת את פירוט תצורת החומרה והתוכנה עבור הבדיקה, את מנגנון בקרת השינויים, ואת הניהול הכולל. 4. המשאבים לבדיקה משאבי הבדיקה עשויים לכלול כלים, אך אין ספק שהם :כללו גם עובדים. אומדן המאמ הכולל הנדרש והכישורים הדרושים בכל שלב יאפשר לדאוג להדרכה מתאימה. תוכנית הבדיקה צריכה לזהות דרישות מיוחדות להדרכה ואת המועדיס בהס תידרש הדרכה זו. 5. ארגון ותתומי אחריות נוסף לדרישות הכוללות למשאבים, עלינו לדעת גם כיצד *אורגנו המשאבים. מי יהיה אחראי לאסטרטגיית הבדיקה הכוללת ולניהול כל רמת הבדיקה: כיצד ינוהל רישוס השגיאות! מי יקבל את ההחלטות בדבר בדיקה חוזרת של תוכנה לאחר שיבוצעו בה התיקונים ובדבר הצורך בבדיקה רגרסיבית (ראה סעיף יבקרה ורישוס של בדיקותי בַהמשך)! מי יאשר את קבלת התוכנה בשלב הקבלה!? מי יחליט אס להמשיך, או להשהות את הבדיקה כאשר מתגלות שגיאות! מי יאשר את הבדיקה החוזרת לאחר תיקון שגיאות! 6. לוחות זמנים לבדיקה לאחר שיובאו בחשבון כל השיקולים הנזכרים, נוכל לתכנן את לוח הזמנים לבדיקה. לוח הזמניס צריך לכלול פעילויות מוקדמות כגון מפרטיס ותיכון הבדיקה וכן את בדיקת המוצרים המוגמרים. תוכניות הבדיקה אמורות להצביע גם על 6 נהול איכות תוכנה שיעורי הכשל הצפוייס בכל רמה, כדי שניתן יהיה לאמוד את ממדי העיבודיס החוזריס והבדיקות החוזרות, וגס להצביע על המשמעויות המוטבעות לתוך תוכנית הפרויקט הכוללת. לוחות הזמניס חייביס להיות מדויקים ככל האפשר במונחים של זמן ומאמציס שנדרשים. עס זאת, הס חייביס להיות מבוססים על אירועים, כגוו הספקה של תצורות תוכנה מסוימות, ולא על תאריכים קלנדרייס. על ידי כך, תישמר נכונות תוכנית הבדיקה על אף התוהו ובוהו שמסביבה. מפרט הבדיקה ותיכון הביצוע התיכון ומפרטי הבדיקה יימצאו כעת בפרספקטיבה הנכונה, כאשר נדון בפירוט המדיניות ויעדיה, כפי שנקבעו בתוכנית הבדיקה. במקריס רביס מתמזגיס המפרטים והתיכון למסמך אחד, אך חשוב עדיין להפריד בין הנושאים שכל אלמנט עוסק בהם. מפרטי הבדיקה עוסקיס במה שחייבים לנסות, בעוד תיכון הביצוע עוסק בדרך שבה יש לבצע את הבדיקה. בשלב המפרטיס יש צורך לטפל בשלוש סוגיות מפתת: = מה הס יעדי הבדיקה! >= באילו טכניקות נשתמש בבדיקה! * כמה בדיקות צריך לבצע! התשובות לשאלות אלו אמורות להתקבל מהיעדים הכלליים ומהתוכנית, אלא שלגבי רמת בדיקה מסוימת עלינו לדון בהן בפירוט. יעדי הבדיקה עוניסם על השאלה ילמהי! למה לנסות ברמה הזאת! מה הן הסוגיות המעסיקות אותנו: מה הדבר שברצוננו להדגים! היעדים צריכיס להיות מפורטים במידה שתאפשר לזהות את הטכניקות המתאימות יאת הממדים הדרושים של הבדיקה. ברור שבדיקת כל אחד ואחד מהמוצרים, תהיה מטרה שלא ניתן להשיגה, ולכן לבחירה במדגס מייצג כבסיס לבדיקה תהיינה משמעויות לגבי האיכות (המדגם צריך להיות גדול במידה שתוכל להשרות תחושת ביטחון), והעלויות (מדגם גדול מהדרוש לא יגביר בהרבה את תחושת הביטחון, אס בכלל, אך וודאי יעלה יותר). קביעת יעדיס מציאותייס תסייע בקביעת המדגם הנכון. הטכניקות שנשתמש בהן מותנות במספר נושאיס: > אופי התוכנה שבוחנים, או מנסיס ; + הכלים הזמינים ; + רמת הכיסוי הנדרשת ; >= הטכניקה שנשתמש בה ברמות האחרות. בסופו של דבר תצטרך הבחירה לוודא שיינתן הטיפול הנכון לסוגיות השייכות לרמה הזו, ושאיכות המוצריס שמרמה זו תתאיס לשמש כקלט לרמה הבאה. פרק 4: תהליך הפיתות הבסיס: | 107 ממדי הבדיקה כרוכים במידה רבה בבתירת הטכניקות. מבלי להתחשב במדדים שנבחרו, חיוני לבצע כמות מספקת של בדיקות שיהיה בה כדי לוודא עמידה ביעדי הבדיקה. ניתן להגדיר זאת במונחיס של כיסוי מבני (כגון, נבדקו 85 אחוז של כל ההחלטות), או של כיסוי פונקציונלי (כגון, הופעלו כל שגרות אימות הקלט), או שניתן להגדיר זאת במונחיס של המשתמשים (כגון, יש לבדוק את התרחישיס הבאיסם). בהעדר קביעה ברורה של ממדי הבדיקה הנדרשיס להשגת היעדים, קיימת סכנה של קיצור הבדיקה במקרה שהפרויקט אינו עומד בלוח הזמנים. החלטה בדבר הכיסוי הדרוש, לא רק שהיא ממקדת את תשומת הלב על פונקציית הבדיקה, אלא שהיא גס מספקת קנה מידה מסויס לגבי הבדיקות שבוצעו בפועל, אס וכאשר יש צורך לקבל החלטה לקצץ באחד משלבי הבדיקה. לעיתים מחליטים שאין יותר אפשרות להמשיך בבדיקה משוס שהלקוח זועק לקבלת המערכת. לעיתיס מפסיקיס ביאמצע הדרך'י, כאשר למשל הושלמו 43 אחוזיס של הבדיקות הפונקציונליות וכי 38 אחוזים של הקוד טרס נבדקו. מובן שמנהל זכאי להחליט שיש לעצור את הבדיקה, אלא שכאשר הנתוניס מכומתיס ההחלטה מתקבלת תוך ידיעה מלאה או טובה יותר, של התוצאות הצפויות. דרישה מכומתת לניסוי, מוליכה למדידת הישגי הבדיקה ולמידע מציאותי שניתן לבסס עליו החלטות בדבר הבדיקה. לפני התחלת הבדיקה צריך להגדיר ולאשר את הנהלים הבסיסיים. מי שיבצעו את הבדיקה יזדקקו להוראות ברורות בדבר הדרך בה עליהם לבצע את הנהלים, כיצד לפרש את התוצאות, כיצד לרשום אותן ומה לעשות במקרה שהתוצאות לא יה משביעות רצון. את נהלי הבדיקות אפשר לפרסס כמסמך נפרד, או שבמקריס פשוטיס ניתן לכלול אותס בתוך מסמכי הבדיקה. ללא קשר לדרך שבה יושגו תכני הבדיקה המפורטים, יש תועלת רבה בהפקת מסמכי בדיקה שיכילו את כל המידע הרלוונטי עבור מבצע הבדיקה ומקוס לרישוס התוצאות, ובמקרה הצורך, גם דוגמאות של תבניות צפויות של הפלט. מסמכי הבדיקה מקלים על משימת הבדיקה ומצמצמיס את החשיפה לשגיאות, הס גם מספקים את המכשיר ליצירת הרישומיס הדרושים ללא צורך בהעתקה, או בשינוי צורת המידע. תרשיס 4.6 מדגיס כיצד מצטרפות פעילויות האימות ובדיקת התקפות ליצירת מחזור חייס כולל. 8 ניהול איכות תוכנה אטוז ססחה)קטסטג 6תג 8ז8010] פפטססטא [צשוווזי> 0 >)חטוחטזוטט )אטן אזאץ1ו:חה 1 סז חג]ק 1631 טסחג)קטסס/ ו 0 פס מבי = *ל לטה 607 6 - 0 . סטשסן ₪ ן עטנ ח0וו:50001/16 1ט) וחטופץ5 וסחוי ]16 וסטקא וש 5 ד 1 תשוצים חווט סוק קופס 6חה תדשים 4.6 מודל מחזור חיים לפיתוח תוכנה גקרה ורישופ של בדיקות הבקרה של פעילות הבדיקה ניתנת להשגה בקלות רבה למדי באמצעות מסמכי הבדיקה. הפקה של מסמכי בדיקה משמשת אסמכתא לביצוע הבדיקה, ואילו החזרת מסמך הבדיקה למתאס הבדיקה המתאיס, מהווה את ההשלמה של המשימה. המעקב אחר המשמעויות של מקרי כשל יהיה בתחוס אחריותו של המתאם, שתייב לוודא שהשגיאות דווחו ולשמש כמקשר עס צוות הפיתוח, כדי לוודא שהשגיאות אכן תתוקנה במסגרת של פרק זמן סביר. בשלב זה חשוב לוודא שייעשו זיהוי והערכה של כל ההשפעות התוצאתיות של שגיאות ותיקונים, על חלקיס אחריס של המערכת. המעקב אחר השפעת הבעיות וזיהוי ההשלכות הרחבות יותר של תיקוניס שהתבצעו כבר, יהיו בדרך כלל, המשימה של צוות הפיתוח. עס זאת, האחריות לוודא שננקטו כל הפעולות המשלימות הדרושות, מוטלת על מתאס הבדיקה. זו דוגמה אופיינית לחשיבות שיש לממשקים ארגוניים וטכנייס. מכאן משתמעת חשיבות הטיפול בממשקיס אלה בתוכניות הפרויקט, ושל הצורך לוודא שתחומי האחריות יהיו ברוריס בכל אחד מצדדי הממשק. פרק 4: תהליך הפיתוח הבסיס: | 109 משעה שנעשה ניתוח ההשפעות (ו5ע|4ח8 401קוחו), אפשר לקבוע את לוח הזמנים לבדיקה משלימה (8ח16511 קט-אוס!01)). חזרה על בדיקה בה נמצאה שגיאה היא דרישה בסיסית, אך יש להניח שיהיה צורך בבדיקות רגרסיביות. בדיקות אלו נועדו לוודא שתחומיס שלא היו אמורים להיות מושפעים על ידי שינויים ימשיכו להתנהג כראוי גס להבא. ייתכן שיהיה צורך לשנות תחומים המושפעים על ידי שינויים, ואלה עשוייס להוליך לשינויים נוספים ולדרישה לשלבי בדיקה נוספים. המשמעויות של שינויים יכולות להיות מרחיקות לכת. ניהול התצורה הוא רכיב חיוני בניסוי אפקטיבי. בכל הנוגע לניהול הרישומיס השונים, דרישה זאת אמורה להיות מוגדרת בתוכניות הבדיקה. תפקיד מתאס הבדיקות לוודא את הפקת הרישומיס הדרושים. חלק מתהליך הרישוס צריך לכלול תיעוד של תצורות החומרה והתוכנה שבשימוש בשלבי הבדיקה השונים. לבסוף, משהושלמה הבדיקה יש לנסות ולהעריך את מידת ההתאמה ורלוונטיות הבדיקה. הדבר נעשה מתוך מגמה להשלים, במידת הצורך, את הבדיקות שהתבצעו עד עתה תוך מגמה להשיג את היעדים. קכלת הפוצר סוף סוף מגיעים לתהליך הקבלה (פ6ססזק 06ח8/ק4006). לכל פעילות קבלה יש שני שותפים, הלקוח והספק. לכל אחד מהס תפקיד חיוני, ושיתוף הפעולה ביניהס הכרתי. לקבלה שלושה שלבים : * הלקות מגדיר את מדדי הקבלה. + הספק מאמת את המוצר המוגמר. * הלקוח מקבל את המוצר שנמסר לו. הגדרת מדדי הקבלה היא אחת הסוגיות שצריך היה לדון בה במשותף בשלב ניתות הדרישות. באופן אידיאלי, צריכים המדדיסם להיות מכומתים בכל מקוס שהדבר מאפשר. במקרים שאי אפשר להגדיר מדדיס מכומתים, יש לשאוף ליכולת הדגמה של המוצר. עם זאת, כאשר מגדיריס אותס, צריכיס המדדיס להיות אובייקטיבייס ולא סובייקטיביים. דרישה מהסוג שאומר: ימסך בן 24 שורות שעומד בתקן אבג/123 של החברה, יחד עם אמצעי עזרה רגישים לטקסטי ניתן להדגים בצורה הולמת ואובייקטיבית; לא כן הדבר בדרישה מסוג יממשק ידידותי למשתמשי. בדיקת תקפות המוצר השלם מחייבת את הספק לכלול רמת בדיקה שתהיה דומה לזו של הקבלה, בכך שמנסים את כל המערכת בתנאיס הקרובים ככל האפשר לסביבה התפעולית. במטפר מקרים, זוהי הבדיקה היחידה שמבצעת הספק, אך בדרך כלל זו השכבה העליונה של אסטרטגיית בדיקה מובנית. 0 ניתול איכות תוכנה פעילות הקבלה אמורה אף היא להיות מתוכננת. בדומה לקריטריוני הקבלה. שיטת ההערכה וסביבות התפעול של החומרה והתוכנה אמורות להיות מוסכמות זמן רב מראש. שיטת הטיפול בבעיות שמתגלות במשך הקבלה אמורה אף היא להיות כבר מוסכמת ומתועדת, אחרת יש להניח שיתעוררו ויכוחים ודחיות. ככל שמתקרבת פעילות הקבלה, אפשר להגדיר את לוחות הזמניס ואת המשאביסם שיידרשו לניהול הבדיקה, ויש צורך בהסכמה משותפת לגביהס. (יהול תצורה בעיית יסוד בפיתוח תוכנה נעוצה בעובדה שהמוצריס בלתי נראים לעין, וניתניס לשינוי בקלות. להתקן אחסון המחזיק יחידת תוכנה אין שיטה אוטומטית להצגת תוכנו, והוא אינו מסוגל לשקף את העובדה שתוכנו השתנה. כתוצאה משתי עובדות לא נעימות אלו, מחייב הצורך בזיהוי ומעקב אחר התוכנה לאורך כל תהליך הפיתוח, נהליס מפורטיס וממושמעיס ביותר. העונש על העדר בקרה על התוכנה תוך כדי הפיתוח יכול להתבטא בזאת שנמסור ללקוח את המוצר הלא נכון, או את הגירסה הלא נכונה של מוצר, או שהדבר יתבטא בהופעה חוזרת של כשל שתוקן כבר קודסם לכן, או בהכללתה המקרית של פונקציונליות שפותחה בכלל עבור לקוח אחר ובהוצאות גבוהות. אלה אירועיס מביכים ויש בהס פוטנציאל לתוצאות הרות אסון לגו וללקוחותינו. הדרך היחידה להתגונן מפני אלה היא בקרה קפדנית על כל הגרסאות של כל המוצרים מרגע יצירתס, לכל אורך חייהסם עד לרגע מסירתם הסופית. תהליך זה נקרא ניהול תצורה (1ה6 6 ח4ות ה8110זט18 תס6). זיחוי ויכולת מעקב הצעד הראשון ואולי החשוב ביותר של ניהול תצורה הוא הקמת מנגנון שיש בו קבוצת כללים מוגדרת היטב המשמשת לזיהוי הייחודי של כל אחד מרכיבי המערכת. כדי להבין מדוע, עלינו להתבונן קדימה בזמן לאותה נקודה בה נשקול ביצוע שינויים. אין זה משנה אם השינוי קורה לאתחר המסירה הראשונית של המוצר, או במרוצת מחזור החייס של הפיתוח, התוצאות תהיינה דומות במידה רבה ומנגנוו הבקרה יהיה זהה. שינויים יכולים לקרות בשל מגוון סיבות, אך צפוי שתהיה להם אחת מהתוצאות הבאות: היישוס הקייס יתוקן, או יורחב מבלי לשנות את הפונקציונליות, או את המטרות הבסיסיות, או שהשינוי ייושס כדי לתולל יישוס חדש, או שונה משמעותית תוך שימוש ביישוס המקורי כבסיס לחלק מהפונקציונליות הנדרשת. במקרה הראשון, אנו מתייחסים לשינוי כאל יצירת גירסה חדשה (תסוצז6צץ ש6ח); במקרה האחר, נשתמש במונח עדכון (זח9!זבץ). במקריס בהם נדרש שינוי גירסה, אפשר לאתחל את השינוי בכל אחד משלבי מחזור התחייס של הפיתות. יכול להיות שינוי במפרטי הדרישות שיוליך לשינוייס בתיכון ובקוד, וייתכן שיהיה זה שינוי ברמת הקוד שנועד לתקן השמטה מקרית. במקרה של פרק 4: תהליך הפיתוח הבסיס: | 111 עדכון חשוב לזהות את נקודת ההתחלה בה נוצר העדכון, ואת השינויים הקשוריםס ו ביצירתו; מנקודה זו ואילך ניתן לעקוב אחר גרסאות בעדכון עצמו, במקביל לגרסאות המוצר המקורי. בכל אחד ממקרים אלה, נצטרך לוודא מספר דבריס חשובים : = התיעוד שנוצר, החל מהדרישות ועד לקוד ישקף בצורה בהירה את המצב האמיתי של התוכנה הנמסרת. = המסמכים והקוד :ציינו בצורה בהירה איזו גירסה של איזה מסמך מתייחסת למצב הנוכחי של התוכנה הנמסרת. > ניתן יהיה לאתזר במקרה הצורך את הגירסה הנוכחית וכל גירסה קודמת של התוכנה שנמסרה, תוך דרישה לזיהוי כל הכליס ותוכניות השירות ששימשו ליצירת גירסה כלשהי של התוכנה. >= אירועי הבדיקה (64565 ז165) ורשומות הנתוניסם, משקפים בצורה נכונה את המצב הנוכחי של המערכת, תוך דרישה לזיהוי כל מידע הנוגע לבדיקה והגירסה או הגרסאות של התוכנה שנמסרה, במקרה שהדבר ישים לגביה. קבוצת דרישות מחמירה זו אינה מותירה מקוס לשאננות. במקרה שמתעורר צורך בשינוי ונעסוק רק בבעיית הזיהוי, לא נוכל להביא בחשבון את כל הבעיות האלו. חיוני להגדיר כבר מההתחלה את מנגנון הזיהוי, כך שבעת יצירת כל מסמך, תוכנית או אירוע בדיקה (0856 656)), ניתן יהיה לזהותם בצורה ייחודית ולקבוע את הקשר שלהם לרכיביס המבוקריס האחריס. אחת המטרות היסודיות של ניהול התצורה היא יכולת המעקב מכל דרישה אל המוצר המוגמר המתאים, כדי שנוכל לוודא שניתן מענה לכל דרישה. יכולת המעקב לאחור מהמוצר המוגמר אל הדרישה גם תאפשר לנו לוודא שכל מוצר מוגמר מקורו בדרישה מוגדרת (ולכן תצדיק גם את העלות והמאמץ שהושקעו בבניית יכולת זאת). דבר אחרון שמנגנון הזיהוי מאפשר הוא הגדרת מצב הבנייה (0608ז5 6!וטט), המשקף את מצבס הנוכחי של כל הרכיביס מהס מורכב המוצר. מצב בנייה יחיד משקף שילוב אוסף מסוים של רכיבים הנושאים מספר גירסה. אס נוכל להגדיר באותה עת צירוף מסוים של רכיבים מבוקריס המהווים במשותף גירסה מסוימת של המוצר בכללותו, נוכל לזהות את מצב הבנייה הנדרש בעת מסירת המוצר. הפער בין מצב הבנייה הנוכתי לבין מצב הבנייה הנדרש לאספקה, יגדיר את תוכן התוכנית לבנייה ולאספקת המוצר. סוגיות זיהוי אלו הן הבסיס לבקרה, המנגנון הבסיסי חייב להיות מטופל בתוכנית לניהול התצורה (אס קיימת כזו), בתוכנית האיכות, או בתוכנית הפרויקט. גקרת שינוייפ בקרת השינויים ([0זוחסס 6פַתגת6) בפריטי תוכנה היא אבן הפינה בניהול התצורה. להגדרות הזיהוי הייחודיות שנקצה לפריטיס אלה תהיה משמעות רק אס נבקר את תהליך הצירוף של כל פריט חדש, גירסה או עדכון. כך נוכל לדעת איזה מהס אושר אחרון. כדי שהדבר אכן יקרה, לא מספיק לתת לגירסה האחרונה את המזהה הייחודי שלה; עלינו לוודא גס שכל מי שמשתמש בגירסה ידע שחל בה שינוי ושיינתן לו עדכון 2 ניהול איכות תוכנה כתחליף לגירסה הקודמת. רק על ידי דיסציפלינה מסוג זה נוכל לוודא שבמשך תהליך הפיתוח תימצא בידי כל אחד הגירסה האחרונה. חובה לדאוג לכך שתהליך בקרת השינוייס יתבצע כהלכה: מעט מדי או מאוחר מדי פירושס אסון פוטנציאלי, יותר מדי או מוקדס מדי מוליכים לחנק תהליך הפיתוח. מהו הזמן הנכון בו נפעיל בקרה על התוכנה! הכלל הפשוט ביותר קובע שיש לדחות כל צורת בקרה עד לשלב שבו יש ליותר מאיש אחד צורך בגישה אל פריט. החל מנקודה זאת קיימת סכנה אמיתית במקרה שיבוצעו שינוייס בצורה בלתי מבוקרת. לפני אתחול הבקרה תצטרך להיות צורה כלשהי של מנגנון מאשר, כדי לוודא שהפריט נמצא במצב שמאפשר את השיתוף בו, כלומר, עריכת סקר. תוצאת הסקר תהיה מסמך, או פריט תוכנה במצב ידוע (כפי שדווח בעת הסקר), ומצב ידוע זה :וגדר כגירסה מטפר 1. לעיתיס תכופות יהיה צורך להשתמש בצורת בקרה כלשהי עוד לפני נקודת בקרה זו. ניתן להשיגה באמצעות גרסאות טיוטה, תוך שימוש בסדרה נפרדת של סקרים. טיוטת סקר 4 תשקף מצב מוגדר אך לא בהכרח תעבור את תהליכי הסקר והאישור. שינוייס במסמך כזה יכוליס להימשך בצורה לא רשמית תוך התגבשות המסמך, משוס שבכל מקרה לפני המהדורה הרשמית יבוא סקר רשמי בו יוגדר מצב המסמך במלואו. משעה שמופעלת בקרת שינויים, תתחיל האבטחה הפיסית להוות שיקול רציני. את המהדורה הרשמית הראשונה יהיה צורך לשכן בספרייה נפרדת, וכל המהדורות העתידיות יצטרכו להעשות רק באמצעות הספרייה. אם נקפיד על כך שגרסת הספרייה תוכל להתעדכן רק דרך בקרת השינוייס הרשמית, נוכל להיות בטוחיס שכל מי שיבקש מהספרייה עותק של המסמך, יקבל תמיד את הגירסה המאוחרת ביותר. במקרה שמספר אנשלי צוות עובדיס בו-זמנית על אותו פריט תוכנה, הספרייה תוודא שכל העדכונים מסונכרניס בדרך הנכונה. במקרה ופריט מהווה חלק מתוך יותר מאשר מוצר אחד, הספרייה תתאס את עדכון כל המוצריס המושפעים מהשינויים. הספרייה תצטרך גס לנהל רישוס של המחזיקיס בעותקיסם של כל פריט או מסמך, כדי לוודא שיקבלו הודעה על עדכון. אחזקת רישוס מתזיקי מסמכים, או פריטי תוכנה תהיה אס כן, משימה המוטלת על הספרייה. תהליך בקרת השינויים עצמו חייב להיות בעל מספר מאפייניס חשוביס. מאפיין ראשון הוא האמצעיס לאתחול שינוי, כגון טופס דרישה לשינוי שיהיה נגיש לכל אלה שיכוליס לחולל שינויים. דרישות אלו יצטרכו להיבדק לפני אישור השינוי, כדי לוודא שהשינויים המוצעיסם ישימיס ורצויים. לאתר אישור השינוי נצטרך לדעת את משמעויותיו במונחי ההשפעה שתהיה לו על מוצר או מוצריס שהפריט המועמד לשינוי הוא חלק מהם. ניתוח ההשפעות ישאף לזהות את כל ההשפעות הנובעות משינוי נתון. אס ניתוח ההשפעות אינו מגלה תופעות לוואי בלתי רצויות, ניתן להתחיל ביישוס השינוי ובבדיקתו. הבדיקה תצטרך לכסות לא רק את השינוי הפונקציונלי שנקבע, אלא גס להיות בטוחיס שהפונקציונליות הנשארת תמשיך להתנהג כפי שמצפים ממנה. צורה זו של בדיקות רגרסיביות צריכה להיות מיושמת גס לכל התחומים שזוהו על ידי ניתוח ההשפעות כתחומיס שצפוייס להיות מושפעיס מהשינוי. פרק 4: תהליך הפיתוח הבסיס: | 113 לאחר שנעבור בהצלחה מכשולים אלה, ניתן יהיה להכניס את השינוי לספרייה ולהודיע על כך לכל מי שדרוש. יש לעדכן את רישומי הספרייה כדי שייראו הקשרים בין הגירסה החדשה לבין הדרישה לשינוי שחוללה את השינוי, או את השינויים. לבסוף, הספרייה תודקק ליכולת להפיק דוחות תצורה שיזהו את מצב פריטי התוכנה ויעקבו אחר השינויים שאירעו מאז כניסתס לראשונה למערכת הבקרה. תכנון (יהול תגורה רבות מהסוגיות שנידונו תהיינה בעלות משמעות כללית ולכן תצטרכנה להוות חלק מהמדיניות הכוללת של הארגון לניהול התצורה. עס זאת, יש תחומיס שיצטרכו להיות מוגדרים עבור כל פרויקט: = ארגון ותחומי אחריות, כגון מי יהיה אחראי לאשר שינוייס ומי יהיה הספרן; > פעולות ניהול התצורה שיש לבצע, כגון בקרת השינוייס ; = כלים, טכניקות ושיטות בהן יש להשתמש; == השלב בו יש לכלול פריטים במסגרת בקרת התצורה גיפד משתלג תהליך הפיתוח הבסיסי כמערכת (יהול איכות (פואם) שלנו בפרק זה בחנו אחדות ממשמעויות תהליך הפיתוח הבסיסי שעלינו להיות מודעים להן דרך קבע, בשל הסכנות הפנימיות הנובעות מטיפול בדבר כה תובעני כמו פרויקט ניהול תוכנה. עס זאת, התהליך הבסיסי חייב להיות המוקד הראשוני שלנו. תהליך הפיתוח הבסיסי חייב להיצמד לשמונת עקרונות הנדסת התוכנה שהגדרנו בפרק 1, וזאת דאגתנו הראשונה. האלמנטיס המרכזיים של עקרונות אלה : אלמנטים מרכזיים של תהליך פיתוח [. הגדרות של: 0 מחזור חיים של פיתוח תוכנה; 0 מתודולוגיה; 0 אסטרטגיה לאימות ובדיקת תקפות; 0 דיסציפלינה לניהול תצורה. 2 נהלים לפיתוח תוכנה נהלים אלה מתארים את התהליכים היסודיים עבור חלק זה של העסק, עליהס לכלול הנחיות בדבר בניית המפרטים. 4 נלהול איכות תוכנה ככ וו 3 תכנון פעילויות הפיתוח תוכנית הפיתוח מגלמת את לוח הזמניס לפעילויות הפיתוח, המבוסס על מודל מחזור החייס והמתודולוגיה שנבחרו עבור הפרויקט. לכן, מסגרת הפיתוח חייבת להיות קיימת עוד לפני שניגשיס לתכנון הפרויקט. 4 תכנון פעילויות האיכות פעילויות האיכות שהוגדרו בתוכנית האיכות מסייעות לבלימת הסיכוניס הכרוכים בפרויקט, הן חייבות לכלול את אסטרטגיית האימות ובדיקת התקפות הייחודיות לפרויקט זה, כולל הדרישות לבדיקה חוזרת של התיכון ולתכנון הבדיקה. 5 כללים וסטנדרטים תהליכיס יצירתיים כדוגמת התיכון והתכנות אינס יכוליס להיות כבוליס בתוך מסגרת של נהלים, אך הנחיה ונהגים טוביס יסייעו לשפר את העקביות ולפשט את קיוס הסטנדרטיס. 6. תבניות למסמכים מתאריס של מסמכי מפתח, המראים את המתאר הדרוש ומגדירים את התוכן הצפוי מקליס על עריכת מסמכים ובדיקתס האפקטיבית. 7 כללי התנהגות בתחוס בו הנהגים נמצאיס עדיין בשלבי התפתחות ושיפור, יש תועלת בתיעוד המצב הנוכחי של הפיתוח, כדי לקדס עקביות מסוימת ולעודד ויכותים בנושא השיפורים. 8 מנגנון לבקרת התצורת דיסציפלינה לניהול התצורה מחייבת יישוס מעשי באמצעות כלליס לזיהוי, ליכולת המעקב ולבקרת השינויים. יש צורך בקיוס ספרייה שתאפשר בקרת תפוצה של מסמכיס ותוכנה. 9 אסטרטגיית המדידת התחזוקה והשיפור של תהליך פיתוח התוכנה הבסיסי יזדקקו למידע כמותי בדבר הביצועיס הנוכתייס. אסטרטגיית המדידה תזהה את המדידות הדרושות ותגדיר כיצד לאסוף, לנתח ולשמור אותן. 7-0 77 ככתכתרתכת כעת, יש ברשותנו שני נתיביס אינטראקטיביים במערכת האיכות: ניהול הפרויקט ופיתוח התוכנה. עלינו לנהל ולשפר פעילויות הדדיות אלו בכך שנשכן את כל המבנה בתוך סביבה ניהולית תומכת ומעוררת, כדי שלא נסתפק בקיוס התקנים בלבד, אלא גס נשתדל לשפרסם. זאת תהיה המשימה של מערכת איכות, בה נדון כעת. פרק 4: תחליך הפיתוח הבסיס: | 115 סַכַק 5 עיקֶרי מערכת האיכות - לך המערכת מבוא מערכת איכות חייבת להיות ערוכה להישרדות ולשיפורים מתמידים. כאשר נערמים הקשיים, ההישרדות מחייבת שמערכת האיכות לא תהיה הקורבן הראשון, והיא צויכה להיות איתנה די הצורך לעמוד בלחצים של הטווח הקצר. השיפורים המתמידים חייבים להוות מנגנון מובנה שיספק למערכת מידע בדבר ביצועיה, ושעל פיו ניתן יהיה לקבוע את המדיניות לעתיד. יש בכך כדי לוודא את ההתמדה במאמץ האיכות. לגבי תקן 9000-3 50!, תחזוקת המערכת היא הדרישה הראשית, אולם בחיפושינו אחר תמורה ארוכת-טווח לכספנו, אנו חייבים להתבונן אל מעבר לתחזוקה, באמצעות תוכנית שיפורים מתוכננת. פרק זה מאגד מספר נושאים שטופלו על ידי תקן 9000-3 50! ומצעיד אותם הלאה. מטרת פרק זה לזהות ולחקור היבטים של מערכות האיכות, שתרומתם רבה ביותר לתחזוקה ולשיפורים לטווח הארוך. לקו עיקר מערכת איכות מנגנןני האיכות שזיהינו עד כה התמקדו בתהליך יהינדוסי התוכנה (מלשון 6ז ו ו בעוד שדיסציפלינות אלו תיוניות ויסודיות למערכת איכות תוכנה *"לקטיבית, כשלעצמן אין בהן כדי להבטיח את המשך האפקטיביות של מערכת האיכות. 1 חדיסציפלינות, ככל שתהיינה מבוססות ונתמכות היטב, כמעט תמיד נוטות להתפורר במרוצת חזמן. שינויים בהרכב העובדים מביאים לשינויים בנקודת המבט ויש בהם כדו להוליך לסחף הדרגת: במחויבות המשותפת שסיפקה את הדחף ההתחלתי -. ---. ב ו 0 עש 9 ת הדיסציפלינות האלו. לקוחות חדשיס ורעיונות בדבר וך במרוצת - לייב גישות חדשות. דיסציפלינות שהזו חיוניות בעבר, עלולות להפוך חזמן למנוגדות לפרקון. פרק 5: עיקרי מערכת האיכות | 117 ₪ כיצד נוכל לשמור על המשך קיומה של מערכת איכות לנוכח שינוייס מבפנים, ועס זאת לאפשר לה לשנות את עצמה, כדי להיענות לשינוייס שמבחוצ! יציבות וגמישות הן תכונות הסותרות זו את זו. המנגנון שנפעיל להשגתן יצרוך אף הוא משאבים, ועל ידי כך יפגוס בפריון הכולל. התשובה לכך היא ביצירת מצב יציב המלווה בגישוש אחר שינויים, פנימייס וחיצונייס, ונקיטת פעולה מתאימה בתגובה לכל שינוי שנחוש. גישה זו מונחת ביסוד בקרת הלולאה הסגורה, כפי שהיא מוצגת בתרשים 5.1. סוט זטקוס ו חס8וז קוח 0 תדשיס 5.1 בקרה בלולאה סגורה פעילויות עיקריות במערכת האיכות מערכות איכות מתוחזקות על ידי מערכת בקרה בלולאה סגורה. פירוש הדבר, שעליהן להיות מסוגלות לקבוע יעדים, לחוש בסטיות, ולשנות את התנהגות המערכת כדי להחזירה לכיוון היעד. במערכת איכות, התנהגות על פי יעדים נקבעת על ידי הגדרת הדרך בה צריכה המערכת לפעול. עלינו להתייחס לשלושה היבטים : + מדיניות האיכות מגדירה את מטרות האיכות הכוללניות ; + נהלי האיכות מפרטים את המדיניות ומגדיריס את הדרכיס להשגתה; + תפקידים ותחומי אחריות מגדיריס את הדרך בה צריכיס העובדים להפעיל את המערכת. כל אחת מההגדרות צריכה להיות מתועדת פורמלית ולהיתמך במתן הדרכה, כדי לוודא את יישומן העקבי. ההתנהגות בפועל של המערכת צריכה להיות נתונה למעקב על ידי תהליך ניטור שיוודא גילוי סטיות מההתנהגות הרצויה ותיקונן בהזדמנות הראשונה. דבר זה מצריך: = מבדקי איכות (טז86 עווגטף), שיספקו נקודת מבט עצמאית על דרך פעולת מערכת האיכות ויזהו סטיות מהמערכת המתועדת ברמה התפעולית ; 8 ניהול איכות תוכנה = מדידה (זחסותסזט645וה), שתאסוף מצביעי ביצועיס עיקריים, גסם של המוצרים וגס של התהליכים ; = מנגנונים לפעולה מתקנת (פוח15ח8ת66וח ה0ס:861 6צו601זזס6), שיוודאו את הטיפול בבעיות, בזמן וביעילות ; . סְקרי הנהלה (אי16ש6ז ]ח6וח450ח4וז), שיסקרו דרך קבע את מערכת האיכות ואת תהליך הניטור, כדי לוודא טיפול בסוגיות רחבות יותר של המדיניות. [החז6וה] ץוו|בטף ג 5 ץז ו9טכ) 6605 | | החסופץ5 06 חסווסבּ פוטקת] ץסו!סק ץזו[4טכ) ש6וש6ז ]ה6וח326ח3]א 1 5 זוא (1ח5/6ע5 ע1ו[טף 01 5ט)518) תלשיס 5.2 בקרה בלולאה הסגורה של מערכת איכות כל הפעולות האלו שהן לב המערכת, עולות כסף וצורכות משאביס שניתן היה להפנותס לייצור. לכן, על ההנהלה להיות בטוחה שיש אמנס צורך בפעילויות האיכות וכי הן מתבצעות בדרך האפקטיבית ביותר. מחויבות ההנהלה חיונית לפעולה האפקטיבית ולהמשך הישרדות מערכת האיכות. מערכת איכות אינה יכולה להישרד ללא מחזיבות ברורה של ההנהלה. אין בעולס האיכות דבר שהוא חשוב ממחויבות ההנהלה. גם אס נצליח להקיס מערכת פעילה בטוות הקצר, הרי שבלי מעורבות פעילה של ההנהלה, קלושים סיכןיי ההישרדות של מערכת זו מעבר למשבר הראשון. מחויבות ההנהלה יכולה להתבטא בשלוש דרכים: * על ידי הודעה פומבית בדבר גישת הארגון לאיכות במסגרת מדיניות האיכות; + על ידי הקצאה מחייבת של משאבים להשגת מדיניות האיכות ; + על ידי סקרים סדירים של ביצועי מערכת האיכות ונקיטת הפעולה הנדרשת לתיקון הבעיות שתתגלנה. נבחן כל אחד מרכיביס אלה על ידי כך שנתבונן במבנה מערכת הבקרה בלולאה סגורה, המהווה חלק מדרישות תקן 9001 180. פדק 5: עיקרי מערכת האיכות | 119 תקן 3 ספ ומֶה שמעבר לו עיקרי מערכת האיכות הקווים המנחים של תקן 9000-3 150 משקפיס בדייקנות את דרישות תקן 9001 150 בכל הנוגע לפעילויות העיקריות. זה מרמז על גישה שונה במקצת מזו של חלקי הנדסת התוכנה של המערכת, בהס הקווים המנחים מאפשרים לנו מרחב תמרון מסויס. בתחוס העיקרי, לב מערכת האיכות, 'הקווים המנחיסי משקפים סעיפי חובה שבתקן 01 150, שאנו חייביס לעמוד בהס, אס ברצוננו למלא אחר דרישות התקן: בפרק זה נחקור את פעילויות לב מערכת האיכות בשלוש דרכים : .> על ידי הצגה והסבר פעילויות לב מערכת האיכות המוגדרות בתקן 9000-3 180; > על ידי תיאור מספר פעילויות נוספות (שהוגדרו בתקן 3 15600 כיפעולות תמיכהי) שאפשר לראותן כחלק של לב המערכת. על ידי הצעת גישה ליישוס לב מערכת הא:כות, המתבוננת מעבר לקווים המנחים המיידיים של תקן 9000-3 150 לכיוון אסטרטגיה של תהליך שיפור לטוות הארוך. התחומיס שהוגדרו בתקן 9000-3 150 כחלק של לב מערכת האיכות הם: + תחומי אחריות ההנהלה, הכולליס : 0 מדיניות האיכות; 0 ארגון ותחומי אחריות; 0 נציג ההנהלה; 9 סֶקרי הנהלה; * תיעוד מערכת האיכות; מבדקים פנימיים (81ַ9) של מערכת האיכות ; > פעולות מתקנות. נעסוק גס בארבע פעילויות הקשורות לנושא: * בקרת תיעוד; * רשומות איכות; + הדרכה; >= מדדים. הגישה בפרק זה שונה במקצת מזו שבשני הפרקיס הקודמים, בכך שהדיון בתקן 3 1500 ובהנחיות המעשיות של היישום, מוצגיס יחד. 0 ניהול איכות תוכנה מדיגניות האיכות תקן 9001 150 מחייב להגדיר ולתעד את מדיניות ויעדי האיכות, ובכלל זה הכרזה בדבר מחויבות הארגון לאיכות, לוודא שדברים אלה יובנו, ייושמו וגם יקוימו בכל הדרגיס שבארגון. לעיתיס, מתבצעת חובה זו על ידי הכרזת מדיניות קצרה הנכללת בחוברת האיכות, הצהרה המתייחסת לפעולה על פי תקני 9001 150 ו- 9000-3 150. עס זאת, אפשר לעשות יותר מזאת כדי לחולל תחושה אמיתית של מחויבות. כל ארגון זקוק ליעדיס. בלעדיהס לא יהיה לו בסיס למדידת ביצועיו או להבעת כוונותיו לעתיד. יעדי איכות קובעיס את המטרות להשגת האיכות ומתארים את תרומתה הצפויה של האיכות להשגת היעדיס הכלליים. מדיניות איכות מגדירה את הגישה הכוללת לאיכות ומזהה את הדרך בה יש להשיג את יעדי האיכות. במסגרת מדיניות האיכות תיכלל הודעה על מה שמצפים מעובדי החברה והודעה בדבר צעדיס שהחברה תנקוט בהם, כדי לתמוך בעובדיה להשגת יעדי האיכות. האלמנט האחרון הוא ביסודו הודעה בדבר מחויבות הארגון לאיכות. הכרזה ברורה בדבר מדיניות האיכות חובקת את כל האלמנטיס הנזכריסם, בהכרזה ברורה ופשוטה המתווה את השותפות שבין הארגון לעובדיו, ומכוונת להפיק את מירב הביצועיס לתועלת הכול. טוב יותר יהיה אס מדיניות האיכות אף תזהה את המדידות הדרושות כדי להציג את ההתקדמות לעבר יעדי איכות. תפקיד מסמך האיכות להרחיב בנושא מדיניות האיכות ושאר חלקי מערכת האיכות. עליו גם להציג בפירוט כיצד יש ליישס את המדיניות בפעילויות היומיומיות של הארגון. הגדרת מדיניות איכות טובה והפגנת מחויבות ההנהלה כלפיה היא הדרך הטובה ביותר להשגת מחויבות אמיתית של העובדים, שעליה בנויות רוב מערכות האיכות המצליחות. כיצד צריכה להיראות מדיניות איכות טובה! אין כלליס חד-משמעיים לכך, העיקר הוא שמדיניות האיכות שלך תשקף את מטרותיך, את יעדיך ואת תרבות העסקים שלך. עס זאת, יש מספר קוויס משותפים לכל אלה. בצ --- שש כותרות למדיניות האיכות 1 הצהר על כוונתך לפעול על פי התקנים (אס אמנס זוהי כוונתך). 2 הצהר על מחויבות ללקוחותיך אמירות כגון יאפס תקלותי, או ינכון תמיד כבר בפעס הראשונהי, אין בהן תועלת רבה, אלא אס תסביר למה בדיוק אתה מתכוון בהן. הכרזות בדבר רמת הבדיקה שאתה מבצע, או על תגובתך לתקלות, יהיו בוודאי בעלות משמעות רבה יותר. 3 הכרז על מידת האחריות של עובדיך לאיכות הודעה ברורה שכולס אחראים לאיכות, ושיישפטו על פי מידת המחויבות שתופגן על ידם. פרק 5: עיקרי מערכת האיכות | 121 4. הכרז על מחויבות ההנהלה שלך לאיכות במיוחד, עליך להבהיר שההנהלה תתמוך בפונקציית האיכות ותימנע תמיד מלאכוף שיקולים מסחרייס על שיקולי איכות. 5. זהה מספר יעדי איכות ברורים אלה צריכיס להיות כללים המכווניס לשיפור השירות ללקוח, כגון צמצוס מספר הבעיות המדווחות מהשדה; וכן שיפור הביצועים הפנימיים, כמו צמצוס עלות העיבודיס החוזריסם. 6. זהה מדידות שיאפשרו השוואת ביצועים מול יעדיס התחייב לפרסס מדידות אלו. ו 0--- מדיניות איכות טובה מטפלת בבהירות בכל אחד מיעדי האיכות ומסייעת לזהות את הנדרש להשגתם. אם היעד הוא לצמצם את מספר העיבודיס החוזרים, תוכל המדיניות לכלול דרישה למדוד את כל התקלות, כדי שאפשר יהיה לזהות את העיבודיס החוזריס ולחשב את עלותם. ייתכן אף שהדבר יחייב פיתוח גישה מובנית לאימות ולבדיקת התקפות, שתוכל לאתר את מירב השגיאות בהקדס האפשרי. למדיניות ממין זה משמעויות חשובות במונחיס של הדרך בה נתכנן ונקצה משאבים לפרויקטים, כדי שאלה יפעלו ככוח מניע לפיתוח מחזורי חייס ומתודולוגיות מתאימות. מדיניות איכות טובה קובעת תמיד במפורש את תחומי האחריות. יימשימתך כעובד היא להגיע לתוצאות נכונות; השגת האיכות מותנית בביצועיך. אס אינך יכול לבצע את עבודתך כהלכה, עליך להביא זאת לידיעת מנהלך הישיר. אנו נתחייב לתת לך הדרכה מתאימה ונתייחס ברצינות להצעותיך לשיפוריסיי. זו הצהרה פתוחה ומעורפלת במקצת, אך עדיפה על מדיניות האומרת בפשטות יינכון תמיד כבר בפעם הראשונהיי. תוכל לדעת אס אמנם הצלחת להציג את המדיניות הנכונה, רק כאשר תוכל לזהות רכיב של המדיניות ואת המדידה שתאשר (או לא תאשר) שהושג כל אחד מהיעדים. ארגון ותחומִי אחויות אחת המשמעויות של מדיניות האיכות היא ארגון המשאביס בדרך שתאפשר את השגת יעדי האיכות. דבר זה אין פירושו בהכרח שיש צורך לזהות מחלקת איכות; וגם אין לראות ביצירת מחלקת איכות גישה נבונה. הארגון עשוי להזדקק לאנשיס בכל רמה, שלהס אחריות מיוחדת לאיכות. אין הס חייבים לעסוק בפעילויות האיכות במשרה מלאה, ואין הס חייביס להיות מומחים לאיכות. מטרת זיהוי תחומי אחריות לאיכות היא לוודא שהחלטות עקרוניות לא יתיפולנה בין הכסאות' של הארגון. במציאות, כל אחד בארגון אמור לדעת מה מצפים ממנו וכיצד יוערכו ביצועיו. על ידי הגדרת תחומי אחריות נוכל לוודא למשל, שהוגדרו ממשקים בין אזוריס פונקציונליים, שהמוצרים המוגמריס אומתו, תקפותם נבדקה, וכי שאילתות הלקוחות מטופלות במהירות. 2 ניהול איכות תוכנת מהדרג העליון ומטה צריכה להיות אפשרות לוודא, שתחומי האחריות עבור כל האלמנטיס של מדיניות האיכות מוצאיס את ביטוייס בהגדרות תפקידים, או בכתבי מינוי. צריכה להיות גס יכולת לבדוק, מטה כלפי מעלה, שכל תהליכי המפתח והממשקים שהוגדרו בנהלי האיכות מאוישים באנשיס שקיבלו הכשרה מתאימה ומביניס את דרישות תפקידס. ולבסוף, צריכה להיות אפשרות לוודא שנבנתה לתוך הארגון שלנו יכולת להשיג את יעדי כל פרויקט, וכי ברשותנו מספר מספיק של עובדים מיומניס ומנוסיס לצורך השלמתו המוצלחת של הפרויקט. (פיג הה(הלה האלמנט היחיד בארגון המוכתב על ידי המערכת הוא מינויו של ינציג ההנהלהי שיהא אחראי על הביצוע הכולל של פונקציית האיכות. נציג ההנהלה אינו חייב להיות בעל מקצוע בתחוס האיכות ואינו חייב לשאת במינוי הנקרא ימנהל האיכותי. החשוב הוא שלנציג הממונה תהיה סמכות מספקת לצורך ביצוע התפקיד ימר איכות' בארגון. בדרך כלל, מדיניות איכות חזקה תתייב 'נציג הנהלה' בעל אישיות חזקה כדי לוודא סילוק מהיר של מכשולים המפריעיס לאפקטיביות המערכת. מינוי אישיות בכירה בעלת סמכויות ביצוע, הוא אחת הדרכיס להעברת מסר ברור לעובדיס וללקוחות החברה, על מחויבות ההנהלה. הדרכה הדרכה היא רכיב חיוני ביותר כדי להגיע לערך ופוטנציאל מקסימלייס של הארגון, וביכולת להתמודד עס השינוייס והפיתותחיס המתרחשים בשוק. ברוב המקריס ואף למעלה מזה, עלות ההדרכה משתלמת ומתבטאת באפקטיביות העובדים וביכולתס להבין כיצד לבצע את משימותיהסם. תקן 9000-3 150 קובע עיקרון כללי האומר שעובדיס חייבים להיות מיומניס בביצוע המשימות המוקצות להם, והוא מצביע על מספר תחומי מפתח שיש לבחון, כגון כליס ייחודיים, טכניקות, מתודולוגיות, משאבי מחשב והיכרות עס היישוס. התקן מזהה אף את הצורך לקייס רישומיס מתאימיס בדבר ההדרכה ו/או הניסיון המעשי. יסוד הדבריסם הוא תהליך הרקע שנועד לוודא זמינות מספקת של עובדיס בעלי הכשרה מתאימה, שיכוליס לבצע את כל היעדיס המתוכננים של הארגון. כדי להשיג זאת עלינו לכלול את תכנון ההדרכה כחלק משולב בקביעת :עדי האיכות. לכן, נצטרך לבצע את ההדרכה הנדרשת בצורה מבוקרת, כדי שההתקדמות תיעשה תוך בקרה ותהא תואמת לתוכניות האחרות של הארגון. נוסף לשיקוליסם האסטרטגיים של ההדרכה, קיים גסם צורך לזהות את ההדרכה שתידרש עבור פרויקט מסויס במקרה שזו לא נכללה כבר בתוכנית ההדרכה הכוללת. הזמן הנכון ביותר לעסוק בכך הוא שלב בדיקת החוזה, ובאחריות מנהל הפרויקט ליישמו. עס זאת, יש צורך בקישור לאחור אל תוכנית ההדרכה, כדי לוודא שההנהלה תכלול בשיקוליה ובתכנון צורכי ההדרכה בעתיד גם את ההדרכה הדרושה לביצוע הפרויקט. פרק 5: עיקרי מערכת האיכות | 123 אס כן, להדרכה שלוש רמות יישוס. ברמת הפרט, ההדרכה ניתנת ונרשמת ברישומיס של כל פרט. ברמת המחלקה, ניתנת הרשאה לביצוע כחלק מתוכנית ההדרכה. ברמה המפעלית, נקבעות הדרישות ומדיניות ההדרכה ונסקרות תקופתית; במקביל מתנהל מעקב אחר הביצוע מול התוכנית. אחד המנגנוניס לקביעת דרישות ההדרכה הוא טבלת קישוריס המזהה את הכישורים הנדרשיס לכל משרה בארגון. מחויבות לאספקת ההדרכה שהוגדרה בטבלת הכישוריס יכולה לשמש בפועל כאחד האלמנטים של מדיניות האיכות; יתרונה הוא בהיות המחויבות הגלויה לעין עובדי הארגון בצורה שתביא להס תועלת כפרטיסם בארגון, ותשפר את הפוטנציאל של כל הארגון. אחת הדרכים שיכולה לספק להנהלה שיטה מובנית לניטור ביצוע ההדרכה גס ברמת הפרט וגם ברמת הארגון היא הכללת ההדרכה בהערכה השנתית של כל עובד. בעת ראיון ההערכה ניתן לאשר לכל עובד את תוכנית ההדרכה שלו לשנה הבאה. חשוב לציין שההדרכה יכולה להינתן בכל רמה החל מהדרכה בפיקוח תוך כדי עבודה דרך קורסים חיצוניים. אפשר גס לשקול התנסות מעשית מתאימה. מידת ההתאמה של ההדרכה, או של הניסיון המעשי הניתן, היא הקובעת. יש לזכור גס את הצורך לנהל רישוס של ההדרכה, מכל סוג שהוא, כדי שניתן יהיה להציג זה מול זה, את מה שנעשה ואת דרישות ההדרכה. כחלק מהמסגרת שפורטה לעיל, יישלחו אנשים לקורסי הדרכה מסוג זה או אחר, כדי שבעתיד יוכלו למלא יעדי ביצוע מסוימיס. התועלת המופקת מקורסים אלה תהיה גדולה יותר, אם האנשים המעורבים ידעו מראש מה הס יעדי הביצוע, כדי שיוכלו להתמקד ברכישת הכישוריס הדרושיס ולהעריך את הקורס על פי יכולתו לספק זאת. כאשר חוזר עובד מהדרכה, מדידה כלשהי של אפקטיביות ההדרכה תסייע לוודא שהושגו יעדי ההדרכה, ותספק לחניך עצמו הזדמנות לסקור את החומר זמן קצר לאחר השלמת ההדרכה. משתי הבחינות, דוח קצר על רעיונות המפתח של הקורס יכול להיות לתועלת ולשמש כביקורת מתמשכת על האיכות ומידת ההתאמה של ההדרכה שניתנה. לא פחות חשוב, לערוך בהקדס האפשרי (לאחר קבלת ההדרכה) תוכנית לשימוש בכישורים שנרכשו. ערך ההדרכה יאבד במהירה אס לא ימומשו הכישוריס שנרכשו. תכנון המינויים לתפקידיס שלאחר הקורס, חייב להיעשות כבר תוך כדי מהלך הקורס. מגדקי איכות פנימייפ תפקיד מבדקי איכות פנימיים (ו0ט3 ע)ו[4טף [4תזסזחו) לספק סקירה בלתי תלויה על ביצועי מערכת האיכות. התהליך הוא פשוט: נדרש לכך מבקר מאומן שיסקור את העבודה המתבצעת בתחוס מסויס של הארגון למול דרישות מערכת האיכות באותו תחוס. הפלט ממבדקים אלו יכול להיות רב ערך. הוא יכול לכלול: *= עדויות לחולשות תוכנית האיכות המתועדת ; *= עדויות לחולשות ביישוס תוכנית האיכות המתועדת ; * אירועיס מסוימיס של אי-ציות לתוכנית האיכות והצעות לפעולה מתקנת ; 4 ניהול איכות תוכנה . ,שר דש = | זיהוי בעיות מסוימות שיש צורך לטפל בהן באמצעות המנגנון לפעולה מתקנת ; = | זיהוי נהגיס טוביס שיש מקוס לעודדס במקומות אחריס בארגון; = נתוניס על ביצועי מערכת האיכות. על ידי תכנון מראש של מבדקי האיכות (5ו0ַט83 ע1ו!4טף), הארגון יכול להבטיח ביקורת בכל התחומיס על בסיס שגרתי, וכי כל הנושאיס הקשוריס לאיכות יבוקרו על פי לוח זמניס סביר. תוכנית המבדקיס הפנימית היא האמצעי הראשי של הארגון שבאמצעותו הוא יכול לבדוק ולהיווכח שהמערכת פועלת ביעילות כל הזמן. מטרת המבדקיס היא לוודא שכל תחוס ותחוס שבארגון יבוקר באורח סדיר ושהתחומים היותר חשוביס או קריטייס יבוקרו בשכיחות התואמת את חשיבותם או את הקריטיות שלהס. הבסיס לכל המנגנון הוא תוכנית המבדקיס הממפה את הביקורות שתיערכנה על פני תקופה מסוימת, שנה בדרך כלל. תוכנית ביקורת בנויה כהלכה ממתישה את עדיפויות הארגון ומספקת תשתית מוצקה להערכת הביצועים. ככל שהתוכנית הולכת ונפרשת, יכול המצב להשתנות ולחייב תכנון חוזר. בדיקות שגרתיות חוזרות של התוכנית יכולות לוודא שהיא ‏ ממשיכה לשקף את החשיבות וקריטיות התחומים שנבדקו. תרשיסם 5.3 הוא דוגמה לדרך רישוס טובה עבור תוכנית לעריכת מבדקים, המראה את מצבה של כל פעילות ביקורת. 6 ]וחק 660 חסוזסטטסזץ זו תרשים 5.3 דוגמה של תוכמת מבדק פנימית תוכנית המבדק הפנימית מחוללת מידע ספציפי רלוונטי לתיקון בעיות ולחיפוש אחר שיפורים, אך אפשר להשתמש בה גס לבניית תמונה של ביצועים כוללים של מערכת האיכות. זו יכולה לשמש כקלט חשוב לסקירה התקופתית של מערכת האיכות על ידי ההנהלה הבכירה. פרק 5: עיקרי מערכת האיכות | 125 מובן שיש לכך גס מגבלות. הביקורת פוגמת בפעילויות היצרניות וצורכת משאביס שנדרשים כדי לערוך את המבדק ולדווח על תוצאותיו. קיימת גס סכנה שבודקיס פנימייס קפדנייס ונלהבים מדי לתפקידם, עלולים לגרוס לחיכוכיס בתוך הארגון ולצמצס את מסירות העובדים לנושא האיכות. יש לחשוש גס להתעלמות מנושא האיכות בפרק הזמן שבין המבדקים, מתוך ציפייה שהביקורת תתקן כבר את כל הליקויים. הבעיות האלו יכולות להתעורר וגס תתעוררנה בארגון, אלא אם תרבות האיכות תהיה מושרשת די הצורך, ובחירת המבקריס תיעשה בזהירות ותתבסס על התאמתס לתפקידס. המבקרים הפנימיים יודקקו להדרכה כדי לוודא שתקני של הביקורת יהיו הולמים ועקביים. כדי לוודא שהמבקרים יהיו מודעים למדיניות האיכות הכוללת של הארגון וליעדי הביצוע השוטפיס יש צורך במידה מסוימת של הדרכה פנימית, או מפגשים עם נציג ההנהלה. המבקריס יכולים להוסיף ערך בכך שיזהו מצביס בהם הנהגים אינס תואמיס למערכת האיכות המתועדת, ועל ידי דיונים עס התחומיס המבוקרים על מידת האפקטיביות של המערכת הקיימת. צריך לקיים מרווח פעולה שיעודד הגירת נהגים טובים מתחוס אחד לתחומים אחרים של הארגון, ושיזהה היכן תחום מסויס נוטה לפגר (או להשתער קדימה) לעומת התחומיס האחרים, ובכך יסייע לכלל ביצועי הארגון להיצמד למטרה. כתב מינוי ברור ומפורט עבור כל פעולת ביקורת, בלוויית רשימות תיוג שתורכבנה עבור כל מבדק ספציפי, יסייעו למבקר להיות ממוקד די הצורך. מעקב אחר הדוחות יספק הזדמנויות לתשאל את המבקרים, ולהשוות לטוות הארוך את ביצועי המבקרים, מתוך מגמה להשיג עקביות בנהגי וכללי הביקורת. אחד החלקים החשובים יותר בתפקידי נציג ההנהלה הוא פיקוח על ביצוע תוכנית המבדק הפנימי. יש חשיבות מיוחדת לבדיקת פעולות המעקב ולזיהוי הצורך בהסלמה עס ההנהלה במקרים בהם נראה שהפעולה המתקנת נמשכת זמן רב מזה שסוכם עליו מלכתחילה, או ממה שנחשב כזמן הולס בעיני המבקר. אלה מהוויס חלק חשוב של יכיוונוןי המערכת. בארגוניס רביס משתמשים במדידות פשוטות כדי לזהות היבטיס חלשים יותר של המערכת (כלומר, סעיפי התקן בהס מדווחת כמות גבוהה ביותר של אי-ציות לתקן), ואת מצב הפעולה המתקנת שננקטת בכל תחוס של הארגון. מידע מסוג זה יכול לסייע בזיהוי מוקדים בעייתיים לפני שאלה הופכים לבעיות חמורות. פעולה מתקנת המנגנונים לפעולה מתקנת כוללים נהליסם שמטרתם לזהות בעיות, או בעיות פוטנציאליות, במוצריס או בתהליכיםס. המידע שמתקבל מאפשר לשפר את הנהלים או למנוע אירועים עתידיים של הבעיה. בתחומי התחזוקה והשיפזרים משתקפת מחויבות ההנהלה בצורה הבולטת ביותר. יש צורות שונות למנגנוני הדיווח על פגמים, החל בתלונות לקוחות, דרך שאילתות למרכז התמיכה, פגמים המתגלים בעת בדיקה, ועד לשגיאות הנחשפות בסקרים. כל דבר המשקף את מצב איכות המוצרים, או התהליכים עשוי להיות כלי דיווח על פגמים מסוג כלשהו. 6 ניהול איכות תוכנת בכל מקרה יש צורך באמצעיס שישמשו לתיקון הפגם, ויומן תקלות יוכל להיות שימושי ביותר, כדי לוודא שבכל אחת מהתקלות הטיפול ינסגרי. זהו קו ההגנה הראשון. המערכת תוכל להיות יעילה יותר אם תנסה לזהות את מקור הפגם ולחסל אותו, על ידי כך שתפנה את הפעולה המתקנת לתהליך היסוד וגם לפגם עצמו. זהו קו ההגנה השני. את התועלת הגדולה ביותר ניתן, כמובן, להפיק מכך שנתבונן בכל מנגנוני הדיווח השונים כדי לאהות סיבות משותפות ותחומי חולשה. תוכנית המבדק הפנימי תוכל לעקוב אחר הסיבות, כדי לספק בחינה מעמיקה יותר של התהליכים הנתוניס בסימן שאלה. יש גם מקוס להגדיר מדידות מסוימות של השיפורים, כדי שישמשו לבקרת הביצוע העתידי של השיפורים בתחומי היעד. גישה זו מציעה לא רק את היכולת לקיים את ביצועי מערכת האיכות אלא אף לשפרם. זהו הבסיס לשיפורים מתמידים. עשרה צעדים בדרך לפעולה מתקנת יעילה [. זהה בעיות השתמש בדוחות על פגמים, תלונות לקוחות, מבדקים פנימיים, או כל דבר החושף בעיות. 2. חקור את הבעיות חשוף את אופי הבעיה ונסה לזהות את הסיבות שגרמו לה. 3 תקן את הבעיה טפל בבעיה המיידית כדי שתוכל לסלק את הסימפטומים של הפגם שדווח עליו. 4. חפש מקריס אחרים ייתכן שהבעיה היא אירוע יתחיד, הראשון מתוך רבים, או שזוהי בעיה שכיחה אופיינית שלא נחשפה קודסם לכן בצורה זאת. 5 הבא בחשבון את המשמעויות הרחבות יותר ייתכן שהבעיה אירעה במקוס אחר בצורה שונה במקצת, או שתחומים אחרים יכולים להיות חשופים לה, אם כי עד עתה לא אירעה בהס תקלה כזו. 6. זהה את הסיבה השורשית נסה לגלות מדוע אירעה התקלה, על ידי כך שתתבונן בכל הממצאים ותנסה לזהות את הבעיה היסודית, ולא רק את הנקודה בה התגלתה הבעיה לראשונה. השתדל לתקן את הבעיה האמיתית ולא רק את הסימפטומיס. 7 אמוד את מידת הסיכון של חזרות על האירוע לפני שתחליט על פעולה מתקנת, נסה לאמוד אם יהיה בה כדי למנוע או לצמצס משמעותית את הסיכון של מופע חוזר של התקלה, או הבעיה. פרק 5: עיקרי מערכת האיכות | 127 8 סלק את הבעיה השורשית נקוט בפעולה מתקנת כדי לסלק את הסיבה השורשית של הבעיה ונסה למנוע את חזרתה. דבר זה יכול לחייב נקיטת סדרת פעולות ולא רק פתרון פשוט אחד. 9. עדכן את תוכנית המבדקים הפנימיים לעקוב בקפדנות אחר הפעולה המתקנת כדי לוודא את האפקטיביות שלה. דבר זה יחייב מבדקיס פנימיים שכיחים יותר וייתכן שיהיה גס מקוס להגדיר מדידות נוספות למעקב אחר הביצועיס. 10. אמוד את חומרת הבעיה אס הבעיה חמורה או נפוצה במיוחד, או אם אתה צופה שהיא תהפוך לבעיה גדולה יותר בעתיד אס לא תינקט פעולה בדרג בכיר יותר, הוסף את הבעיה לסדר היוס של פגישת הסקר התקופתית, או המיוחדת, של ההנהלה. בשש שש םשש בש ב שבי שי שב גשיה שש שב שב וי ים. של שש בו כ בשש ב ו סקר חוזר של הה(הלה סקר הנהלה (16ע6ז )ת82000ח8וה) היא בדיקה שיטתית של ביצועי מערכת האיכות, המתבצעת על ידי מנהלים בכירים. מטרתו לוודא שמערכת האיכות ממשיכה להיות אפקטיבית, על ידי טיפול בסוגיות או בבעיות שמחייבות פעולה מצד ההנהלה. תקן 9000-3 150 ממליץ שסקר ההנהלה יכלול בדרך כלל הערכה של תוצאות ביקורות האיכות הפנימיות, שיכולות לשמש כבסיס. עם זאת, יש ביכולתנו להתבונן עמוק שותר במערכת, רק על ידי סגירת הלולאה וגם על ידי בדיקת המצב והביצועים של מנגנוני הפעולה המתקנת. מבט בתלונות הלקוחות ובתגובות הספקים יכול לספק מבט לעומק, אל הביצועים החיצוניים של המערכת. במקרה שהגדרנו מדדים למוצריס ולתהליכיס (ראה פרק 6) שנועדו לאפיין את ביצועי המערכת, ניתן לבודקם מול יעדי הביצוע כדי לזהות תחומים חלשים. תמצית של פגישת סקר הנהלה אפקטיבי מבוססת על הגדרת מינימוס המשתתפים בפגישה ועל נושאי חובה החייביס להיכלל בסדר היוס. נציג ההנהלה הוא זה שצריך להיות אחראי לבניית דוח שיעסוק בכל הסעיפים שעל סדר היוס ויספק את הבסיס לדיוניס בבעיות מפתח. הוא צריך גם להיות אחראי לרישוס הדיונים ולנהל מעקב אחר הפעולות הנדרשות. זהו תחוס חשוב ביותר וצריך להתייחס אלין ברצינות. ההנהלה אמורה להיות ההנהלה הבכירה ולכלול מספר גדול ככל האפשר של חברי הצוות הביצועי. נושאי סדר היוס חייבים להיות יסודיים, צופים אל העתיד ובוחנים את העבר. עבור ההנהלה זוהי הזדמנות לוודא שמדיניותה מתבצעת בהצלחה, ושהוקצו המשאביס והארגון הדרושיס להשגת מדיניות זו. תשומת לב בלתי הולמת לסקר זה היא סימפטוס קלאסי למחויבות רפויה מצד ההנהלה ומוסיפה על הבעיות שנגרמות על ידי מדיניות שאינה מוגדרת כל צרכה. 8 נלהול איכות תוכנה ---ש-ש <=%%גג%ָג<="'ּת"'"*?"ְּ|ּ|]|ּ ‏ - מדידות ומדדיפ המדידות והמדדים (ג!071167 06ת8 ₪607105) נזכריס כאן כדי לבסס את מעמדס הראוי בתור אלמנט יסוד במנגנון שיפור התהליך. ניתנו כאן מספר דוגמאות, אך הרחבה רבה יותר ניתנת בפרק 6. יצירת מדיניות מדידה אפקטיבית היא פרויקט לטווח ארוך המתייב את כל תשומת הלב שיכול לתבוע פרויקט גדול, אך אין בכך כדי למנוע בדיקה מוקדמת במספר מדדים מוגבל, שנועדה להשיג אך ורק שיפורי תהליך צנועיס. זהו סוג פעילות בסיכון נמוך, שיכול לשמש כמדידת חלו אידיאלית, ושאפשר להשתמש בו לרכישת ביטחון בשימוש במדידה כבכלי ניהולי. גקרת התיעוד בקרת התיעוד המשפיע על האיכות, היא דרישה בולטת שמיושמת בצורה גרועה בארגוניס רביס. תקן 9000-3 150 מסייע לפחות בזיהוי המסמכיס שטעונים בקרה: כל אלה שמגדיריס נהלי איכות; כל המידע הנוגע לתכנון ולהתקדמות; כל תיעודי המוצרים, כולל המוצריס המוגמריס של הפאזות של מחזור חיים. כלי הבקרה התיונייסם גם כן ברורים: כל המסמכים שנתונים לבקרה חייבים לקבל אישור לפני הפקתם; כל השינוייס במסמכים שנתונים לבקרה צריכים להיות מאושריס על ידי הרשות המנפיקה; כל הסוגיות הרלוונטיות שבכל המסמכים צריכות להיות זמינות במקומות בהס יזדקקו להן. יש לציין שבקרת תיעוד יכולה להיות מאוד ביורוקרטית, ואין ספק שיש מקרים בהס תהליך האישור מונע את ההנפקה המהירה של מוצר מוגמר הנדרש בדתיפות. לעומת זאת, יותר בעיות נוצרות על ידי בקרה גרועה של תיעוד מאשר על ידי בקרת יתר. רשומות האיכות הרשומות נדרשות כהוכחה שאכן בוצעו פעילויות האיכות. אין בכך משמעות מיוחדת עבור מי שעוסק בפיתוח התוכנה - פרט לאותו צורך לנהל רשומות מתאימות לשם תמיכה במערכת הא:כות : רשומות א*כות (600:065ז ע0ו41טף). רכש בדרך כלל, רכש הוא נושא בעל חשיבות מועטה בענף התוכנה. לגבי מפתחי התוכנה הרכש התשוב ביותר הוא רכש כלים; הבחירה והיישוס של כלים אלה מטופלים ביתר הרחבה בפרק 4. נושאיס משמעותייס אחריס יכוליס להיות הפעלה של קבלני משנה בעלי התמחות בנושאים ייחודיים, ובעיקר בקבלניס להדרכה. תחוס ראשי הראוי לתשומת לב יהיה לרוב ההערכה והבחירה בקבלני משנה. כללי היסוד פשוטיס למדי: החלט על מה שאתה מעונין בו; שקול את המדדיס החשוביס פלק 5: עיקרי מערכת האיכות | 129 ביותר לגבי ספקים פוטנציאליים ותעד אותס; הערך את הספקים הפוטנציאליים על פי אותם מדדיס ובתר על פיהס. השוני היחיד המאפיין את קבלני המשנה לתוכנה, יכול להתבטא בכך, שהיחסים ספק/לקות, משנקבעו, יכולים להישרד משך זמן רב. האפשרות לעבור לספק חדש במקרה שהענייניס אינם מסתדריס :כולה להיות לא מעשית במקרה של ספקים בעלי התמחויות מ:וחדות. לכן, חשוב לנסות להקיס מערכת יחסיס שמבוססת על טווח ארוך, בה שני הצדדים שואפים לשיפוריםס מתמידים. עליך להמשיך ולעקוב אחר ביצועי הספק שלך. בעיות פוטנציאליות יטופלו על ידי משא ומתן ותמיכה הדדית ולא על ידי הפעלת סעיפים עויניס בחוזה. שיפור התהליך עתה צירפנו יחד את שלושת מרכיבי המפתח של מערכת אפקטיבית לניהול איכות התוכנה: = מדיניות ונהלים לניהול פרויקטים (פרק 3); + מדיניות ונהליס לפיתוח תוכנה (פרק 4); * מדיניות ונהליס עבור לב מערכת האיכות (פרק 5). כל מערכת איכות התואמת מבנה זה ומטפלת בסוגיות שנידונו בצורה מציאותית, תהיה מסוגלת לעמוד בדרישות התקנים 9001 150 ו- 9000-3 180. חשוב יותר, תהיה זו מערכת אפקטיבית באמת. עד עתה התמקד הדיון בעיקר בכך שמערכת האיכות תשמור על קיום דרישות תקן 1 150. דבר זה הוא בסדר כשלעצמו, אך אפשר להפיק ממנו תועלת רבה יותר. אנו יכולים לכוון את עיקר הפעילויות שלנו להשגת שיפורים של ממש, בכך שנחיה יותר שאפתנים בציפיותינו ממדיניות האיכות ובהקצאת המשאבים שנזדקק להם, כדי להשיג מטרות איכות נמרצות יותר. שיפור תהליכים אינו שונה ביסודו מתחזוקת מערכת איכות, אלא ששני תחומיס טעוניס הרחבה משמעותית: נוסף על תיקון חולשות, מנגנוני הפעולה המתקנת חייבים להיות מסוגליס להשיג שיפורים בפועל. המדידות חייבות להיות מתותכמות יותר, כדי לאפשר את מדידת הביצועים הכוללים של מערכת האיכות. רכיב המדידות הוא החשוב והקשה ביותר בשיפורים אלה. דבר זה יידון בפירוט רב בפרק 6. סוגיות אחרות יכללו את אימוץ מחזורי חיים וטכניקות חדשות. אלה יידונו בפרקים 7, 8 ו- 9. עד עתה הגענו רחוק ככל האפשר בעמידה פשוטה בתנאי תקן חיצוני. מכאן ואילך הדברים תלוייס אך ורק בנו. 0 ניהול איכות תוכנה עשרה צעדים - מתחזוקה לשיפור מתמשך ----7------7-------------₪3-00006תככתכתכ0כ0-0-0---------------------------- שש [. עצב מודליס לכל תהליכי המפתח, כדי שתכיר את כל נקודות הבקרה והממשקים. 2. זהה בעיות ותן להן קדימויות, כדי שתוכל לזהות איזו מהן ראויה להיות ראשונה לטיפול. 3 בחר בחמש הבעיות הראשונות כמועמדות התחלתיות לשיפור תהליכים. 4. תכנן אסטרטגיית שיפוריס שתקיף את חמשת התחומיס שבחרת. 5 הגדר יעדיס מכומתיס לשיפורי תהליכים, כדי שתוכל לקבוע אס היתה לשינוי השפעה מועילה על המערכת בכללותה. 6. יישס את השינוי הראשון על ידי הפעלה מלאה של תוכניתך בתחוס אחד. 77 עמוד על משמר אפקטיביות השינויים על ידי מדידת השפעתם על המערכת בכללותה. במקרה שלא חל שינוי או שיש הידרדרות, חזור אל צעד 6 ושקול מחדש את השיפור. 8 יישם את השיפור הבא בסדר הקדימויות, לאחר שהשיפור הראשון ייושס כהלכה ויתחיל לתת פרל. 9 קדס תחוס נוסף מאלה שברשימתך עד לגמר הטיפול בכל התחומיס הבעייתיים הנותריס. 0. המשך את התהליך ללא הגבלה. == - ב פרק 5: עיקרי מערכת האיכות | 131 חהלק7ק 5 == .-.--. חלק 3 של ספר זה מורכב מפרק אחד בלבד - פרק 6: מדידה ושיפור תהליכים. מטרת פרק 6 היא להציב את המדידה בהקשרה הנכון בתוך המערכת לניהול איכות, בכלי שנועד לשקף את ביצועי העבר ואף לחזות את ביצועי העתיד. בפרק זה נבחן את הנחיות תקן 9000-3 1502 בתחום המדידה ונדון במשמעויות המעשיות שלהן. לאחר הצגת מספר רעיונות בנושא המדידה, נעיין ברעיון ה'תהליך', אך הפעס נהרהר בדרכים לשיפור תהליכים. נדון באסטרטגיות לשיפור המשתמשות בטכניקות מדידה, כדי לקבוע מטרות לטווח ארוך שאינן עוסקות בשיפורים שרירותיים, אלא בהשגת מטרות כדאיות וברות- הישג. חלק זה של הספר מהווה ציר מרכזי, משוס שהוא מציג את המנגנון החשוב ביותר המאפשר לקיים בצורה אפקטיבית את המערכות לניהול איכות, ואף מספק אמצעים להמרת מערכות המבוססות על תקנים חיצוניים למערכות המציבות ומשיגות את מטרותיהן הפנימיות להשגת שיפורים מתמידים. רעיונות המפתח של חלק זה מוצגים בתרשים ח.3.1, מפת התפיסה של הפרק. 0 133 3קלח‎ 4 ניהול איכות תוכנה תדשים ח.3.1 מפת התפיסת של חלק שליש: וששזגיך ךר - ו או6קזב חב - ]2-2 = = וינה '"- "שה - 1 7 א טצוו)טקוווט> |מטוה66ההתהן ,/ = 5 = .שי לח קת ורס - א 77 6 %' 0 ור ב ואס - 8 "7 7<-- = , > |חטחן 9 5 ₪ - =₪ 3 כ א בי , = ב בש שש - ₪ ו . , וטטזטצושם צ|ססיד בצאלדדדדחה-. ב רה 7 7 % ' ₪ ו לרוא 77 > |חסחטזטפטטוא בל ל ב = % , טשזטצחטי) 0 . 5 2 > ל , %, % עטט]סטט הטוא >--=> קה : צ / , 8 א : ו /. ' 5 / / 7% חטוזו]חטגטזץ . : אפ טוא 0 : / ת60-קסיך + | דאטואטצסטאשואו סאה 1 , % דהההוהידדה-קחל"הח "הזה % ו תטוחטזטפהטו / - 59 : ץצ / 1 / ! / - יי צטטווזופ " 1 . . 0 0 . . ה / עטטגזום , ל " 9% , 7 7 צטןקוסחוזק / 4 : " , / 0% : ' קט-וח0ס!301 ללקל 1 ארי %ש בול י 2 . הל חריהרהחקרה ה החדה בגפרדהדדל-.. 7 שר , > = עמסטווך / - , , גב ד " 9 ל 7 משססקמ 7 70 ףא ּ, - ו ₪ " ה רלור - 4 5% ה-א עפ ; ""-....--- המדדרה] % . "0 ל שק + , . ] 100085 [ . ₪ *- ]| יי 7- 1 . יי 5 0-ה 3 8 % "1 5 תס וח6טסזקוח! אפטססזק :א ₪ 9 -₪-- 0-9 63% וי - ו זוז סכק 6 מדידה ושיפור תהליכים מכוא המדידה ()670090:ט685ה) היא אבן יסוד בהנדסה ובמדע. כדי שיתייחסו אליה ברצינות, חייבת הנדסת התוכנה לפתח דיסציפלינת מדידה כלשהי. הבעיה שניצבה תמיד בפני מהנדסי התוכנה התבטאה בשאלה מה עלינו למדוד. המחסור החמור במודלים של תהליכי פיתוח תוכנה מקובלים על הציבור, הקשו על אפשרות השוואת קבוצה אחת של נהגים עם קבוצה אחרת, או אפילו על היכולת לשפוט אם קבוצה נתונה של נהגים יש בה כדי לספק מוצרי איכות. חייבים להיות לנו מודלים ומדידות של תהליכים אשר יאפשרו לנו להעריך, ובסופו של דבר גם לשפר, את איכות המוצר והתהליך. אין די בכימות ובשיפור תהליכים; עלינו גם להראות שהמוצרים המוגמרים עונים על דרישות מוגדרות ומכומתות. אג(י היסוד של המדידה קאת תיאוריה מה הס העקרונות הבסיסיים של המדידה! על פני השטח, המדידה, בדומה לרבים מענפי המתימטיקה, פשוטה למדי, עס ואת היא מסוגלת לבלבל לחלוטין את הזריס לנושא. אין בכוונתנו להעמיק ולחקור בתאוריות, אך עלינו להבין את כללי היסוד בעזרתם נוכל למנוע שימוש לא-נכון במדידות, ולהימנע מלהגיע למסקנות שגויות בעקבות מדידות אלו והיניתוחי שלהן. הבה נתחיל בהגדרה יפשוטה': מדידה - הקצאת יעד אמפירית של מספר (או סמל) לישות כלשהי, כדי לאפיין תכונה מסוימת. (פנטון, 1991] מונחיס טכנייס יכוליס לערפל בקלות את המשמעות, אך במקרה זה נזדקק לדיוק מסויס בהגדרה מרכצית צו. פדק 6: מדידה ושיפור תהליכים | 135 מדידה עוסקת בשימוש במספרים או בסמלים לייצוג מאפיינים (פסזט10זו41) או דבריס (ישויות - 166זח6) שאנו מעונייניס בהס. לדוגמה, אנו מעונייניס במאפיין העובי של ספר (ישות), או באורך תוכנית, או בעלויות שיגרוס לנו פגם בתוכנה. כשאנו אומריס שהספר הוא בעובי שישה סיימ אגו מקציס מספר למאפיין העובי, ומספר זה יאפיין את הספר בכל הנוגע לעוביו - הוא דק יותר מספר שעוביו 12 סיימ ועבה יותר מספר שעוביו 3 סיימ. מובן שלא נוכל להסיק מכך דבר באשר לתוכן הספר, או לאיכותו. הרעיון שהמספר המוקצה צריך להיות אמפירי ואובייקטיבי, אומר למעשה, שעל המספר להיות מבוסס על התבוננות ועל הניסיון המעשי, ולא להיות מותנה במבצע המדידה. כשאני אומר שעובי הספר הוא שישה סיימ, אבל אתה מודד אותו ומוצא שעוביו תשעה סיימ, לא צריך להיות מקוס לספק באשר לאמת. כנראה שאחד מאתנו שגה במדידה, אחרת אין למדידה משמעות. הקושי שבמדידה אמפירית ואובייקטיבית מודגס על ידי הדוגמאות שזה עתה ראינו. מהו אורך תוכנית! זו נראית שאלה ישירה מאוד, אך בפועל, המדידה מותנית בשאלה האס אנו סופריסם משפטים או שורות, האס אנו כוללים הערות או לא, וכך הלאה. אין ספק שאורך תוכנית יכול להימדד בדרך אמפירית ואובייקטיבית, אלא שעלינו להיזהר בבחירת המונחיס שאנו משתמשיס בהס; אחרת אנו מסתכנים בחוסר בהירות במדידה שלנו, רק משוס שיכוליס להיות לנו רעיונות שוניס באשר למשמעות הפרמטריס. מאידך, עלות של פגם, היא הרבה יותר בעייתית. בכל הנוגע לאורך תוכנית, הרבה יותנה בדרך בה אנו מודדים. אלא שכאן ניצבת בפנינו בעיה נוספת והיא, שאנשיס שוניס מודדים בשל נימוקיס שוניס. למונחים יש סיבות שונות עבור אנשיס שוניס משוס שהם שוקלים אותן מנקודות ראות שונות. הסיבה אינה משוס שאיננו יכוליס להסכים על המשמעות, אלא משום שאיננו יכוליס להסכיס על משמעות שהיא בעלת אותו ערך לכל אחד מאתנו. העלות היא מסוג המדידות שיש להן משמעות שונה לאנשים שונים, על פי היחס והקשר שלהם לבעיה. לקוח המודד את עלות הפגם בתוכנה שלנו יכלול בדרך כלל רכיבים שאנו לא היינו כוללים. אנו עשוייס להתעניין כמה יעלה לנו לתקן את הפגס, כולל עלויות נוספות הנגרמות כתוצאה מהפרעה בעבודה אחרת, אשר גורמת לנו לחפש את הפגס. הלקוחות לא יתעניינו בעלויות הנוספות שלנו, אלא בעלויות הנוספות שלהם, למשל, העלות של עסקים שנדחו או אבדו. הגדרת אמצעי אמפירי ואובייקטיבי למדידת עלות הפגמים, בה נוכל להשתמש באופן אוניברסלי אינה בעיה פשוטה, וייתכן שלא יימצא עבורה פתרון. עלינו לשאוף להשגת הגדרות מקומיות למדידות כאלו, שיש לעשותן בזהירות רבה, כדי שגסם האחרים ידעו איזו משמעות לייחס למדידות שלנו. הס עשוייס להשתמש במדידות אחרות, או להגדיר אותן מדידות בדרך שונה, אך כולנו צריכיס לדעת אם יש ביכולתנו להשוות בביטחון את המדידות השונות שלנו. טוב יותר יהיה לכולס, אס המדידות תהיינה בנות-השוואה. אסור לנו להניח מראש שקיימת אפשרות להשוואה כאשר זו אינה קיימת. 6 ניהול איכות תוכנת עתה, לאחר שעומדת לרשותנו הגדרה שאפשר לפעול לפיה, יש עוד להבהיר כמה רעיונות לפני שנוכל להתחיל להשתמש בה. הרעיון הראשון עוסק בנושא הייצוג. מן ההכרת הוא שאפשר יהיה לומר, שכל מספר או סמל המוקציס לתכונה כאמצעי מדידה, אכן מייצגיס את אותה תכונה. כלומר, הקצאת מספריס תואמת להבנתנו את עולס המציאות - סָפר ארוך יותר יוצר ערך מִספרי ארוך יותר לייצוג אורך הספר. הרעיון השני, ההקצאה של מספר מסויס חייבת להיות בלבדית. ייתכן ששתי מדידות שונות יקצו מספר שונה לאותו מאפיין, במקרה זה צריכות המדידות עצמן להתייחס זו אל זו בבהירות ובצורה מתאימה. לדוגמה, מדידה של אורך תוכנית הכוללת הערות, ומדידה שאינה כוללת הערות, יתנו ערכיס שוניס עבור אותה תוכנית, אך נוכל להמיר בקלות את הערך האחד לשני ולהיפך. לבסוף, המדידות חייבות להיות בעלות משמעות. למעשה, זהו רעיון מורכב, אך נוכל להסתפק בהבנה פשוטה שלו, לפחות עד כמה שהדבר נוגע לתחוס ההתעניינות המיידי שלנו. מדידה בעלת משמעות, היא מדידה המאפשרת לבנות עבורה משפטיס ישיש בהס היגיון', וכל התמרוניס הסטטיסטיים שעלינו לבצע, חייבים להיות תקפיס לגבי מדידה זו. תוכנית 6 בת 50 שורות, אי-אפשר לומר עליה שהיא ארוכה כפליים מתוכנית 'פסקלי בת 25 שורות, גם אס נהיה זהיריס מאוד בהגדרת ישורהי. התמיכה התיאורטית בהגדרה של מה שמהווה את המדידה היא כמובן בעלת חשיבות, ועלינו להיזהר לא לפגוע בכללים, בנסיון לתמרן בין המדידות. מתודולוגיית המדידה פרט אחרון לפני שנצא לדרך המדידות! אנו זקוקיס למתודולוגיה לביצוע המדידות, כשם שאנו זקוקיס לה לפיתוח תוכנה - כדי שתספק לנו מסגרת המכילה קבוצת כללי עבודה שיסייעו לנו לבחור את היישויות והמאפיינים הנכוניס עבור המדידה. בעזרת המתודולוגיה אנו יכוליס לתכנן ולבקר את הפעילות וגם לתקשר ביחס לתהליך המדידה עצמו. כך יש ביכולתנו לשפר את תהליך המדידה. קיים תמיד הפיתוי למדוד כל דבר, מתוך תקווה שלפחות חלק מהמדידות יביא תועלת. לדאבוננו, יש כמה ליקויים בגישה זו. בעיה ראשונה היא, שלעולס נדמה לנו שאין ברשותנו כל המידע הדרוש לנו כדי להגיע לשיפוט מאוזן על נושא כלשהו. הסיבה לכך שהמדידות שערכנו כדי לסייע לנו להגיע לכלל החלטה אינן ממוקדות די הצורך בתחוס הרלוונטי. שנית, אלה העוסקיס במדידה מקבלים על פי רוב משוב מועט מהמדידות שלהם, אם בכלל, ובמרוצת הזמן הס מאבדים עניין בנושא. שלישית, המנהלים, אליהס מוזרמות כל המדידות, מוצפיס בפרטיס בעלי משמעות מועטה לגביהם, אס בכלל, והס מגליס שיכולתס להשתמש במידע המדידה הזה הולכת ופוחתת. השיתוק שהוא תוצאת הניתוח הולך ומשתלט. פלק 6: מדידה ושיפור תהליכים | 137 אלו כמובן קריקטורות, אלא שכל הקריקטורות מבוססות על האמת, ומדגישות את ההיבטיס המגותכיס והמשעשעים של המציאות. אנו נשתמש כאן בגישת ימדד שאלת היעדי (10ז161! ח0וז65ט?) [008 - 1א2כ00, בזילי את רומבך, 1988) לנושא המדידה, ולו רק בשל העובדה שגישה זו הוכיחה את עצמה כהולמת ושימושית במיגוון רחב של ארגוניס. זאת אינה המתודולוגיה הזמינה היחידה וגס לא בהכרת הטובה יותר, אך יש בה כדי לספק נקודת מוצא טובה. עלינו לדעת תמיד מדוע אנחנו מודדים את מה שאנחנו מודדים. אחת המטרות הראשיות של |א00 היא לספק את המוקד הדרוש, אשר יאפשר לטו לענות לשאלות ספציפיות מסוימות, להימנע ממצבי שיתוק ומהבעיה של משוב חסר אצל העוסקים במדידה. 1א60 יאפשר לגו להתמקד בתחומיס החשובים יותר למדידה ולנקוט בצעדיס שימושיים ומשמעותיים, אשר יאפשרו לנו להגיע למסקנות ועשויות להוליך לשיפורי תהליכים. שיפורי תהליכים אינס השימוש היחיד שאפשר לעשות ב- ]א00, בפרק זה נתמקד ביישום זה. יעדיפ, שאלות ומדידות יעדים, שאלות (מדידות (פסוזוסות 6ת8 פחסו)פסטף ,808[5) קשורים זה לזה בקשר היררכי. יעד אחד מהווה פתח לסדרה של שאלות, ואלו מוליכות לאוסף של מדידות. מטרת כל מדידה, לסייע במתן תשובה לשאלה אחת או יותר. מטרת כל שאלה, להפיץ אור על הדבריס הרלוונטיים להשגת היעד הדרוש. המודל הבסיסי מוצג בתרשים 6.1. שו פַחו/ו6ו 50 ]00 06/66 0 זחטשור 4ז פת0ח6וו) 065105 ]שו עס 1תםט6|6ז 5סוזו6)ת 5סוזו6) סגו 6תו סו תדושים 6.1 גישת 60% 8 נלהול איכות תוכנה דירי -- לפני שנתבונן במודל זה ביתר פירוט נשיס לב שלכל מדידה (מדד פסוזו6וח) תהיה כוונה ספציפית מאוד הקשורה ליעד יחיד, ולכל שאלה שאנחנו מחליטיס לשאול, תוגדר מדידה אחת או יותר, כדי לוודא שכל המידע הדרוש יהיה זמין לצורך הטיפול בשאלה הנדונה. בקצרה, השגנו התמקדות ונמנענו ממדידות מבוזבזות. מהו יעד ([808)! בכל הנוגע ל-1א00, יעד הוא דבר שאתה רוצה להשיג במקוס שהמדידה אמורה למלא בו תפקיד. אנו יכוליס לשאוף להקטין את מספר נפילות התוכנה שלנו בשדה (מסוג המטרות שעלינו להביא בחשבון, שכפי שמשתמע מתקן 3 15600). נוכל לקבוע לנו יעד, כמו יירידה של 10 אחוז במקרי הנפילות המדווחים מהשדהי. לחילופין, אנו עשוייס להיות מעונייניס לגלות אס השימוש בכלי 6455 חדש ישפר את הפריון שלנו. נוכל לקבוע יעד האומר יבדיקת ההשפעות על הפריון שתהיה לכלי 2צא של 6455י. והיעד השאפתני מכולם, אנו יכוליסם לשאוף לשפר את תהליך פיתוח התוכנה הכולל. במקרה זה נוכל לנסת מטרה, כגון 'צמצוס עלות העבודה הנעשית מחדש ב-10 אחוזיסי. בכל הדוגמאות האלו עלינו להיזהר מאוד, ולוודא בדיוק את המשמעות המעשית של מונחים כגון פריון, או עלות העיבודיס החוזריס. הנקודה העיקרית היא הצורך לזהות מטרה יחידה וברורה שתהיה ברקע פעילויות המדידה שלנו. 606 עס אזסש6ז )0 1% 5 !| 6ז ?7 צע !603 355917 ץל פזסזז6 5 6 5 וגת/ ]0 ?סוס 5 66 / סו אזס 16 שחו 6זג וגה [גקו6חוזק 7 6 6ז תסוחוח 00 ו ץ]ו355) על פזסזז6 וק זסק 051 ץֶל זסדו6 5 זס 205 ץס זסזזס 6[סזק חש ו תרשים 6.2 ניתוח 00% של עלות העיבודים החוזרים מייד לאחר שנתמקד על *עד, כגון צמצוס העבודה הנעשית מחדש, צצות השאלות (5ח65)10טף). האס מוצרי תוכנה מסוימים מחוללים כמות עיבודיס חוזרים גדולה יותר מזו של מוצריס אחריס! האס בעיות מסוימות משותפות ליותר מאשר מוצר אחד! האם פגמים מסוימיס חמוריס יותר מאחריס! היכן מושקע רוב המאמץ! נוכל לסער מוחות בשאלות כאלו עד שנרגיש שזיהינו את משתני המפתח, ואז להתחיל לנסח את פרק 6: מדידה ושיפור תהליכים | 139 השאלות החשובות ביותר לטיפול בהיבטיס בעלי ההשפעה הרבה ביותר של היעד, או של הבעיה. אין לצמצוס מספר השאלות חשיבות משל עצמו, אך יש בו כדי להקל על שמירת 'ניקיון' החשיבה והתמקדות בבעיה שבטיפול. תרשיסם 6.2 מציג אחדים מהשלבים המוקדמיס של חשיבה אודות היעד יצמצוס העיבודים החוזריםי. בשלב זה אנו יכוליס לראות שעלינו להיות מסוגליס לאסוף נתוניס בנוגע לשגיאות, אלא שעלינו ליצור גס מספר מרשמיס עבור שיטת הסיווג, כדי שנוכל להפיק את מלוא התועלת מהמידע. סביר להניח שהמדידות שזיהינו עד עתה יסייעו לנו להבין טוב יותר את הבעיה שלפנינו, וזה עשוי להוביל לכך שנשאל מספר שאלות חדשות, או שונות. עלינו להיות מוכניס לחזור שוב ושוב על התהליך עד שתהיה לנו אסטרטגיה ברורה של הדרך להשגת היעד. היתרון של ]00 בכך, שהוא מסייע לנו להתמקד בבעיה האמיתית, במקוס למדוד כל דבר שנוכל רק להעלות על הדעת תוך תקוות-שווא שמשהו מכל אלה יהיה, אולי, שימושי עבורנו. ------------]/-/]/- 7707700000 7 ה חשיכה לסתעפת-מתכ(סת חשיבה מסתעפת (פחואחוון) זתסאזסטו4) עניינה בקריאת דרור לדמיון ונתינת חופש ליכולת ההדמיה, בעוד אנו משאירים את כושר הביקורת שלנו מחוץ לתהליך. המטרה העיקרית היא לחולל מספר רעיונות רב ככל האפשר, מבלי לנסות להעריך אותם. החשיבה המתכנסת (פחואחום! זה6פזטתס6) נוקטת בגישה ממושמעת יותר כלפי הרעיונות שנולדו. חשיבה זו מותחת ביקורת, מסלקת כמה מהם במקרה הצורך, ומציבה את הרעיונות בסדר עדיפויות כלשהו, כדי שנוכל ליישמס בצורה מובנית. לניגוד בין שני סגנונות החשיבה יש חשיבות רבה, משוס שהוא שומר על העניין ועל ההתעסקות שלנו בבעיה שלפנינו. התעסקות רבה מדי בסגנון המתלכד (האנליטי) גורמת לנו לעייפות וללחץ - במוקדס או במאוחר אנו מתחילים להשתעמם או להירדס, ולא מתקדמיס הרבה. החשיבה המסתעפת משעשעת יותר ומעוררת את היצירתיות שבנו ואת הרצון הטבעי לשחק במשחקים. בדרך כלל, אנו נהנים מסוג החשיבה המסתעפת, אך מעטיס הסיכויים להפיק בדרך זו רעיונות מעשיים שניתן ליישמס. על ידי מחזורים של חשיבה מסתעפת ואחריה חשיבה מתכנסת לסירוגין, אנו מביאים למקטימוס את היצירתיות שבנו. כך אין בזבוז זמן בנסיונות ליישס ירעיונות שנשלפים מן השרוולי, ואף נמנעיס מהשעמום ומהעייפות שבחשיבה אנליטית מתמשכת. כדאי לך לנסות - זה גם עובד וגם משעשע ------]-]-]-]--------------- יווד דה===דדדדדדו בפועל, ]00% עשוי להיות כרוך במספר חזרות על שלבי יעד ושאלה. היעדים עשויים לחייב הבהרה ופיצול לתת-יעדים; השאלות עשויות להזדקק לעידון ולבנייה מחדש, כדי לספק רמה הולמת ועקבית לחלוקת היעד למרכיבים. זוהי פעילות יצירתית שבעקבותיה באה בחירה קפדנית. הכוונה הכללית היא לבחור ולמסגר בזהירות את השאלות, אשר לפי הערכתנו יסייעו לנו מאוד בהשגת היעד שקבענו. 0 ניתול איכות תוכנה אם נציג נכונה את השאלות, או לפחות נציג אותן ברמה הנכונה, צפוי שהמדידות תבחרנה את עצמן מאליהן. מטרתנו היא לזהות מדדיס שאינם חורגים מהכללים התיאורטייס ושיוכלו להיות שימושיות בקבלת תשובות לשאלות. לדוגמה, על שאלה ששאלנו, האס פגמיס מסוימיס חמורים יותר מהאחרים, ניתן לענות על ידי שנגדיר מספר קטגוריות לייצוג רמת החוּמרה של פגמיסם, ואחר כך נספור את מספר הפגמים ששייכיס לכל קטגוריה. נוכל גם למצוא איזה מוצריס מחוללים את רוב הפגמים, על ידי שנקצה קוד לכל פגם שאנו סופרים. אם נרצה להעמיק עוד יותר בבחירה, נוכל לספור פגמיס גס לפי מוצר וגם לפי מידת החוּמרה. לאחר הגדרת כל המדדים, נוכל להתחיל באיסוף בפועל של נתוניס לצורך מתן תשובה לשאלות, אך ניתוח מכין זה הוא חשוב מאוד ואסור להיתפז בו. המדידה אינה דיסציפלינה המפיקה תוצאות מיידיות, ואס לא ננהג בה בזהירות וביסודיות אנו עלוליס למצוא שהיא אינה נותנת לנו שוס דבר שהוא בעל ערך. ה(חיות תקן 9000-3 שס תקן 9000-3 150 מציע מספר הנחיות ברורות ומפורשות בדבר השימוש במדידות גם לגבי המוצרים וגס לגבי התהליכים. בתחוס המוצר, ההנחיות מכירות בכך שלא קיימות מדידות המקובלות על הכל בדבר איכות התוכנה. עס זאת, ההנחיות עומדות על כך שיש הכרח לאסוף מספר מדידות מפתח, שמייצגות את המקריס המדוותים על כשל בשדה ו/או פגמיס, מנקודת ראותו של הלקות. ההנחיות מגדירות גס את השימושיס שיש לעשות במדידות המוצר: *+ לאיסוף נתוניס ולדיווח ערכיס מדידיס בצורה סדירה; * זיהוי רמת הביצוע הנוכחית על פי כל אחד מהמדדיס ; * נקיטת פעולה מתקנת במקריס של הרעה ברמות המדדיות, או של חריגה מעבר לרמות שנקבעו ; * קביעת יעדי שיפוריס ספציפיים, תוך שימוש במונחים של המדדים. מכאן משתמע שעלינו להחליט על יעדים (181860) עבור כל מדד של מוצר, ולהשתמש בהס לניהול תהליך פיתוח המוצר. כך נוכל לזהות אם יש נסיגה בביצוע, וגס נוכל לפעול לקראת שיפוריס ספציפייס במרוצת הזמן. בתחוס התהליך, הליעוץ הוא פוזיטיבי פחות. מדדי התהליך אמוריס לשקף: * עד כמה מיטיב תהליך הפיתוח להתבצע במונחיס של אבני דרך ועמידה בלות הזמניס של יעדי איכות שבתוך התהליך. * עד כמה מצלית תהליך הפיתוח לצמצם את אפשרות החדרת תקלות, או את אי-זיהוין של תקלות שחדרו פנימה. אלו הן מטרות מצומצמות ביותר. בעיקרון, הן עוסקות בניהול הפרויקט ובהימנעות משגיאות. אנו מסוגליס ליותר מזה. פרק 6: מדידה ושיפור תהליכים | 141 כיפד ליישפ בפועל את ועיונות המדידה אין לנו עניין בתורת המדידה כשלעצמה, אלא רק במקוס בו נוכל לרתוס אותה ביעילות ובדרך מעשית להשגת מטרות המדידה שלנו. מה שדרוש לנו הוא קבוצה של עקרונות מנחיס שתסייע לנו להקיס אסטרטגיית מדידה עקבית ושימושית. נוסף לידיעת המגבלות התיאורטיות ולציות לכללים, אנו זקוקיס למספר רעיונות בסיסיים ושימושיים שיענו לנו על מה שיכול, או לא יכול, לפעול בהצלחה. נוכל לקודד רעיונות שימושייס אלה לתוך קבוצה של עקרונות מדידה. 0-00 - אחד עשר עקרונות בסיסיים למדידה [. לעולם אל תגסה לשנות דבר עד שלא תמדוד את ביצועיו הנוכחיים ותקבע מטרות לביצועים בעתיד (אלא אם אין למעשה כל חשיבות מעשית לתוצאה). 2. לעולם אל תנסה למדוד דבר כל עוד אינך יודע לשס מה אתה מודד אותו. 3 ביחס למדידה, נקוט תמיד גישה של מלמעלה למטה כשנקודת המוצא היא מטרה או יעד-מדידה ברורים, אלא אס יש צורך בגישה של מלמטה למעלה. 4. זהה תמיד את היתרונות שעובדיך עשוייס להפיק בהמשך הפעולה, לפני שתבקשס לבצע מדידות כלשהן, ודאג להזין להס את התוצאות מאוחר יותר. 5 והה תמיד את היתרונות שמנהלך עשוי להפיק בהמשך הפעולה לפני שתבקשו לאשר את ההשקעה במדידה, אל תשכח להציג את התוצאות לכשתשיגן. 6. התחל תמיד בקטן והרחב לאט לאט. דאג להציג את התוצאות תוך כדי הרחבת הפעילות. 7 אל תצפה רק לחדשות טובות ממדידותיך, דאג שמנהלך יהיה מודע לעיקרון זה. 8 התחל בפרויקט תלוץ, פרויקט שיאשר כמה מהדעות הקדומות של ההנהלה שלך. 9 אל תצפה לתוצאות מוצלחות כבר בפעס הראשונה, ואפילו לא בפעם השנייה. אל תתלה את כל הקריירה שלך בפרויקט החלוץ של המדידה. 0. וודא שיש לצידך בכיר בהנהלה שיתמוך במאבקך. 1. אל תשתמש בעקרונות של אחרים. רשום לעצמך את קבוצת עקרונות המדידה שלך, שתהיה תואמת לתרבותך הארגונית. סה ו נ--תתת.': הכגת המדדית דרך הצגת המדדיס יכולה להיות מכרעת לגבי קבילותם. דף פלט מהמדפסת :כול לנסוך שינה על המקבלים אותו, בעוד שתמונה גרפית ברורה יכולה לעורר שאלות נוספות, או פעולות מיידיות. חשוב ביותר לוודא שהמדדיס שאתה מציג יענו על צרכיו של המקבל ויוצגו בדרך האפקטיבית ביותר. 2 ניהול איכות תוכנה יהיה זה רעיון טוב לערב בפעולה את היקהלי הפוטנציאלי שלך, בעוד אתה מתכנן את תוכנית המדידה ובוחר בנתוני המדידה שתאסוף. נוסף לרכישת המחויבות שלהס לתוכנית המדידה, תוכל לבקשס לזהות את המדידות שהסם מצפים לראות, ואיזה שימוש הס מקוויס לעשות בהן. תשובותיהס יסייעו לך להחליט מהי צורת התצוגה הטובה ביותר. ככלל, עליך לזכור שנתוניס מעובדיס קליס יותר לקליטה מאשר מספרים גולמייס סתם. נתוניסם השוואתיים ונתוניס על קצב השינויים הס לעיתים בעלי ערך רב למקבלי ההחלטות. בנוסף, זכור שמנהליס הם, בדרך כלל, אנשים עסוקים ויש להם זמן מוגבל ללימוד מדדיס. חשוב שיוכלו לעכל במהירות את המידע ולראות את הקשר בין הפרמטריס. תרשיס 6.3 מציג כיצד יכול עיבוד קטן של הנתוניס לסייע בתהליך קבלת ההחלטות. קסופ - 6 | / תסוזט3) 5 <- ₪ 00 תרשים 6.3 רמות עיבוד של מדדים דרך מקובלת להצגת מדידות מפתח היא בצורת ילוח מחווניסי. בדומה ללוח המחווניס של המכונית, לוח המחווניס של המדדיס מציג רק את המידע החשוב ביותר. בצורה זו יכולה להתגלות משמעות המידע תוך כדי סריקת הנתונים, ולא מתוך עיון ארוך ומפורט. לוח מחווניס המיועד להנהלת חברה עסקית עשוי לכלול למשל, תזריס מזומנים, רווחים, ערך הזמנות שנתקבלו, וערך עבודה בתהליך. מנהל עסוק יודע פחות או יותר למה עליו לצפות. הוא יבקש למצוא את צורת התנהגות הנתונים ובוודאי ירצה גסם להשוות חודש מול חודש, או רבעון מול רבעון. רובנו משתמשיס באותו עיקרון כאשר אנו בודקיס את תשבון הבנק ואת תיובי כרטיס האשראי. אם הכל פחות או יותר כצפוי, איננו טורחיס לרדת לפרטיס. אנו וקוקיס ללוח מחווניס שונה עבור מפתחי תוכנה. מה צריך להיכלל בלוח זהז שגיאות לפי מוצר, שגיאות מול מספר שורות קוד, שגיאות לפי פונקציה, מאמץ נדרש לשורת קוד, מאמץ לפונקציה, עלות ממוצעת לשגיאה, תלונות לקוחות, או דרישות לשינוייס שטרס טופלו. כל אלה מועמדיס לתצוגה ויש בוודאי רביס אחרים. החיפוש אחר מה שמפתחיס ירצו לראות בלוח המחווניס שלהס הוא בדרך כלל, תרגיל כדאי כשלעצמו. תרשיס 6.4 מציג את עיקרון לוח המחוונים. אידיאלית, יש להציג את המדדיס בצורת מוניס המראיס ערכיס של קו הבסיס, מטרות, מצב נוכחי ואס אפשר, גס אס המדד משתנה יבכיוון הנכון'. פרק 6: מדידה ושיפור תהליכים | 143 ג קוח 0 ) אזסזז 6 זט 6זסט/ טפזטצ 8 כ 86 32 8 כ 6 ₪ 3 זז 2 0 ₪ 32 זז 5זסזזט 9 |גוסד פ 0 פ 8 8 6 4 4 1065 5 006 6 6 תרשים 6.4 לוח המחווניסם של מפתח תוכנה רעיון נוסף ואחרון בנוגע לתצוגה מתייחס למדדים מורכבים - מדדים המתייביס שימוש במספר מדידות להרכבת יתמונה' של תכונה מעניינת. לדוגמה, יכולת התחזוקה עשויה להיות מושפעת מאיכות התיעוד, ממורכבות הקוד, ממידת יהתבניתיותי של התיכון, וממספר השינוייס שהוכנסו במערכת. קשה לנבא כיצד ישפיעו מדדים אלה זה על זה. כל ניסיון לחזות כיצד יפעלו מדדיס אלה הדדית יהיה משופע בקשיים, ולכן יש לחשוש שגס לא יזכה לאמון רב. דרושה לנו שיטה להצגת משותפת של המדדים השונים, כדי שנוכל לראות מהי ההשפעה שיש לכל אחד מהס על המדד הכולל של יכולת התחזוקה. תרשים קיוויאט (זגצוא) הוא גרף מרובה-צירים. ראשית הציריס נמצאת במרכז התרשים, ולכל אחת מהמדידות הנפרדות יש ציר משלה שמתפשט מהמרכז החוצה. כאשר נשרטט את הערך של כל מדידה ומדידה על גבי הציר המיוחד לה, נקבל צורה אופיינית שמייצגת את המדד המורכב. תרשים 6.5 מראה כיצד יכול תרשים קיוויאט להיראות במקרה כזה. הייצוג שבתרשים קיוויאט אינו מכיל מידע מדידתי נוקשה; הוא רק מאפשר לנו לראות את כל המדידות השונות כשהן מוצגות במשותף בתמונה אחת כוללת. כעת, נוכל לחקור את השפעת כל אחת מהאסטרטגיות המועמדות על שיפור התמונה הכוללת, כדי להגיע להבנה טובה יותר של הקשרים בין המדידות השונות, ושל סוג ההשפעה לה ניתן לצפות כתוצאה מהכנסת שינויים במדידות אלו. לאחר מספר תרגולים נוכל לקבוע יצורות מטרהי עבור מדדיס מורכביס כאלה. 4 ניהול איכות תוכנה זט !טכ חטז]ו:)טוחטטי) 0 זטתוחטא 6 זט הט עוואט!קוחטס 2 כ קְ שטוחטוחט!קוחו חעואטם פטח60זט]!6וח91 תרשיס 6.5 תרשים קיוויאט עבור יכולת תחזוקה לה הפ התהליכים תהליך הוא כל קבוצה של פעילויות שיש להן מטרה מוגדרת וגס קלט ופלט מוגדרים. בהקשר של פיתוח תוכנה, אנו מעונייניס בעיקר בתהליך פיתוח התוכנה עצמו, כלומר בתהליך הממיר את דרישות המשתמשים למוצרי תוכנה. מחזור החיים של הפיתות מקיף תיאור של התהליך הכולל. את מחזור החיים ניתן לפצל לשלבים, שכל אחד מהם גם הוא תהליך. ביכולתנו ללמוד את תהליך התיכון, או את תהליך הבדיקות, כל אחד בפני עצמו, וגס ללמוד את תהליך הפיתוח בכללותו. שיפור תהליכיפ שיפור תהליכים הוא כל אסטרטגיה המכוונת לגרוס לתהליך שייעשה אפקטיבי יותר. לדוגמה, את מחזור החייס של פיתוח התוכנה נוכל לשפר, אם נוכל לשנותו כך שיפיק מוצרי תוכנה מהר יותר וללא ירידה כלשהי באיכותס. בפועל, נעשו כבר נסיונות ליצירת אסטרטגיות לשיפור תהליכים ממין זה. שיטות פורמליות ועיצוב מבני הס דוגמאות לאסטרטגיות שיפור עבור תהליכי פיתוח תוכנה. שיפור תהליכים הוא שיטה מבוססת-מדידה, לשם השגת תוצאות טובות יותד. האס הצליחה האסטרטגיה שלנו המשתמשת בשיטות פורמליות לשיפור תהליכי פיתות תוכנה! אין ביכולתנו לומר בוודאות, משוס שלא נעשה כל מידול (8חו!!8066ח) מכומת שיאפשר לנו למדוד את התהליך לפני ואחרי יישוס אסטרטגיה כצו. בפועל, הרגשתינו פרק 6: מדידה ושיפור תהליכים | 145 לגבי אסטרטגיות כאלו מבוססות על דעותינו האישיות, על דעותינו הקדומות ועל יהתחושה החמה' שהדברים אכן הולכיס ומשתפרים. בקצרה, עד עכשיו אין דרך מדעית מכובדת שבאמצעותה נוכל להתליט אס השיטות הפורמליות שיפרו את תהליך פיתוח התוכנה. כיצד נוכל לתקן את המצב! רק על ידי שימוש במודלים של תהליך ובמדידות היבטי המפתח של מודליס אלה, שיאפשרו לנו לערוך ניסוייס בגישות שונות ולהעריכן. בעזרת הנחיה מסוימת מצד התיאוריה והמעשה של המדידה, נוכל להתבונן עתה בתהליכים עצמס ולנסות לקבוע כיצד הס פועלים, תוך מגמה לחקור אפשרויות שונות לשיפור התהליכים. נעשה זאת בשלבים. תחילה נבדוק את הדרכים למידול תהליכים, כדי שנוכל לקבל מושג ברור על הדרך בה פועלים התהליכים. רק אז ננסה לכמת את הביצועים במונתים של משתנים עיקריים שמתגלים על ידי המודל. את ביצועי כל תהליך אפשר למדוד אז כהקדמה לקביעת מטרות לביצוע, ולבחירת אסטרטגיה לשיפור התהליך. טכניקות למידול תהליכיפ מטרת מידול תהליכים (פָחו[|006וח 06635זק) היא לעשות את התהליך גלוי לעין ונגיש לבחינה מפורטת. סביר להניח שכלי המידול החזקיס ביותר הם אלה שנוסו ונבתנו ביישומיס אחרים, כגון תרשימי זרימה (של הפעילויות) ותרשימי זרימת נתוניס. תרשימי זרימה (ראה תרשים 6.6) מתרכזים במבנה הלוגי של התהליך; הם מזהים נקודות החלטה ומתעדים את ההחלטות המעורבות בתהליך. תרשימי זרימת נתוניס (ראה תרשים 6.7) מתרכזים בתנועת המידע דרך התהליך וסביב לו, ומאפשריס את ניתוח הפונקציה של עיבוד המידע. בעזרת המראה המבני והפונקציונלי של התהליך, יש ביכולתנו לזהות את התוצאות האפשריות של שינוייס במבנהו. במודל התהליך אפשר להשתמש לזיהוי מבני בקרה, או המרות נתוניס הנותניס לתהליך את אופיו. אפשר לראות אם יש דבריס המגבילים את ביצועי התהליך, ולזהות את סוג השיפורים האפשריים. 'מנהליי הביצועים צריכים להימדד כעת, כדי לאפשר תרגול בבבדיקות המכוונות לזיהוי הדרך הטובה ביותר לחיפוש ביצועיס משופריס. 6 ניתול איכות תוכנת = א|חטוחטזוטףש 5 חטוח6זוטס6ת חסו601/1031ק5 חן צ)ח6וחטזוטף6 אופץ[החה ץוק 006 8 6 1 חפופטק 5 תרשיס 6.6 תרשים זרימה המייצג תהליך פיתות תוכנה פרק 6: מדידה ושיפור תהליכים | 147 |ה6וחקס|66 6 6 ות .5000 .66 5חס6וחטזוטף6ת 66 8 6 65 זו 6 בוו ב 6זט!וג) 6 חן 6 8ח6וה6זוטף6 5060116310 65 וח6זוטף6ת סז בי 000 5 5 ח6זוטף6 חסן103] וס 4 זסס ו טוט השוצשש 6 העו5ס 6 ח8ופ6ש הסו1091 )וז 0065 6 6טסזקק א 06 וקהו תדשים 6.7 תרשים זרימת נתוניס המייצג תהליך פיתוח תוכנה 8 ניהול איכות תוכנה אסטוטגיות לשיפור תהליכיס מהאמור לעיל משתמע, שיכולות להיות שתי גישות לנושא שיפור התהליכים: מלמעלה למטה (כשמתחיליס במודל מוכלל של התהליך), ומלמטה למעלה (כשמתחילים במודל מפורט של הנוהג הקייס בארגון). למעשה, שתי הגישות צריכות להשתלב לאסטרטגיה אחת של שיפור תהליכיס. שיפור תהליכים מתמקד ביעדי הארגון בתהליכים ובמוצרים הכרוכים בהשגת יעדים אלה. גישת 'מעלה-מטהי הגישה 'מעלה- מטה' (תש60-קס!) מתחילה במודל מוכלל של תהליך פיתוח התוכנה, כגון התהליך המגולס בתקן 9001 150 ובתקן 9000-3 150, ומיישמת אותו בארגון כדי לוהות את הפעריםס הקיימיס בין הנוהג הנוכתי לבין דרישות המודל. לאחר זיהוי הפערים, מכינים ומיישמיס תוכנית פעולה, שמתאימה את התהליכים שבארגון לאלה של המודל. גישה זו מתרכזת בתהליכי איכות כללייסם האמורים להימצא בכל ארגון העוסק בפיתוח תוכנה. גישת מעלה-מטה מסייעת ביצירת תשתית איכות יציבה, בשילוב עס מדיניות איכות, ונהליסם מתועדיס שנועדו לכסות תחומיס כגון ביקורת פנים, פעולה מתקנת, סקרי הנהלה ופעולות הדרכה. היא לא מספקת סיוע רב ביצירת נהליס לתיעוד התהליכים העסקיים הייחודיים לארגון, כגון תהליכי פיתוח תוכנה, או תהליכי תמיכה ללקוחות. בעוד שהמדידה היא חלק בלתי נפרד מיישוס התקנים 9001 150 ו- 9000-3 1580, מסמכים אלה אינס מגדיריס במפורש את אסטרטגיית שיפור התהליכים. יישום התקניס נוטה אם כן, לעודד ארגונים לשפר את תרבות האיכות שלהם רק עד לרמה הנדרשת להשגת ההסמכה (ה0וז66711₪08), אך אינו תורס לשאיפה שמעבר לרמה זו. גישת 'מטה-מעלהי הגישה ימטה-מעלה' (קט-ותסאספ) ממוקדת :ותר במצב המקומי. היא מתחשבת במאפייניס הייחודיים והמיוחדים של הארגון, בתהליכיםס ובמוצרים שלו. לגבש אסטרטגיית שיפורים שתפעל עבור הארגון המסויס ותגיע לאופטימיזציה של תרבות הארגון וקבוצת התהליכיס המיוחדת לו. גישת מטה-מעלה מתאימה הרבה יותר לניתוח ולתיאור תהליכים אפקטיביים שיבצעו את פעילויות המפתח בארגון. גישה זו אינה מוליכה בהכרת למערכת איכות מאוזנת, בה ייכללו מנגנוני הניטור והמשוב הדרושיס כדי לוודא שהמערכת תישאר אפקטיבית לטווח הארוך. אופייה היפתוחי של גישת מטה-מעלה לא מציע גבולות כלשהס בנושא שיפור התהליכיס. באותה מידה, הוא גם אינו מספק כל אמצעי ביטחון כנגד הסחף בתרבות האיכות. פדק 6: מדידה ושיפור תהליכים | 149 אסטרטגיה משולגת יתרון אחד הקשור בשימוש בתקניס 9001 150 ו- 9000-3 150 הוא העובדה שהשימוש בהס איגו בעל אופי מחייב. יש מרחב פעולה גדול לאופטימיזציה מקומית, אך באותה עת, יש בו גם דרישה עקבית להפעלת תהליכי מפתח מסוימים. אסטרטגיית מעלה-מטה המבוססת על תקן 9000-3 150 אינה שוללת את השימוש בקבוצת תהליכיס המותאמים ביותר לארגון; אדרבא, היא אפילו מעודדת גישה זו. עם זאת, פעולה על פי תקנים 9001 150 ו- 9000-3 150, יכולה להצעיד את הארגון רק עד למרחק מסוים. עבור השגת שיפוריס נוספים, יש צורך בתוכנית שיפוריס המוגדרת ומותאמת בצורה האופטימלית ביותר לצרכיס המקומיים. היא משתמשת במבנה הבסיסי של 9001 150 ושל 9000-3 150 כבנקודת מוצא, ומוסיפה אסטרטגיה לשיפור תהליכיס המבוססת על מדידות, כמתואר בתרשיס 6.8. 50 3 :205 עס ק[ט* 6 ץְחהקוחס;) ז66ז) |ווא [|4ז6צ , ַזוהטכ) 6זט)סח)5 ]החטב הגוא 4ב ונ אזסשש6וח3גז] ו 6 0005565זק 6065 [1003 וס 6 5 זו תרשים 6.8 מנגנומיס לשיפור תהליכים 0 ניתול איכות תוכנת מדדיפס מעשייפ לשיפור תהליכיפ איןו ספק שהדרך הטובה ביותר בה אפשר להחליט מה הן המדידות הדרושות לניהול תרגיל לשיפור תהליכים, היא לבחון את מודל התהליך ולקבוע יעדיס לשיפור. אחר כך, ניתן לחוקר אותס בגישת 001 (שאלת מדד היעד). מדידות המתגלות בניתוח זה תמקדנה את תשומת הלב בדיוק על המשתניס העיקרייס בתהליך הנמצא בבדיקה. לדוגמה, כאשר משתמשיסם במחזור החיים מסוג צ, אנחנו יכוליס לחשוש שתרגיל ניתוח הדרישות לא יהיה מספק, משוס שבזמן מבדק הקבלה אנו מוצאיס הרבה יותר שגיאות מהצפוי, אף על פי שמבדקיס אחריס מסתיימיס בהצלחה. כיצד נוכל לתקוף את הבעיה האמיתית! היעד שלנו הוא במצוס מספר השגיאות המתגלות בזמן מבדק הקבלה. השאלות העיקריות שיעסיקו אותנו יהיו בוודאי יהאס אין ביכולת ניתות הדרישות לזהות את כל הדרישות!'י; יהאס מבחני טרוס הקבלה אינס מצליחים לגלות שגיאות!'; יהאם מבחני הקבלה הס באמת בבואה נאמנה של הדרישות!י שאלות אלו ניתנות לפירוק לשאלות פשוטות יותר, כגון: ימהו סוג השגיאות שאנו מגליסיי; ימהו התחוס הפונקציונלי של המערכת שמפיק את רוב השגיאותנ?י; ילאילו מהתוכניות ניתן לייחס את השגיאות שהתגלו!' וכן הלאה. לאחר שנדע את התשובות לאחדות מהשאלות הדומות לאלו שפורטו לעיל, נהיה בעמדה שתאפשר לנו להטיב לזהות ולסלק את הסיבות השורשיות. כאשר התהליך עוסק בפיתוח תוכנה, אנו יכוליס להשתמש בניסיון העבר שיספק לנו עמדת זינוק לניתות התהליך. פעילות מידול התהליך היא בכל זאת תיונית לאפקטיביות לטווח ארוך של שיפור התהליכים. עם זאת, אפשר יהיה ללמוד אודות התהליך שלפנינו במידה שתאפשר לנו לפתוח בהתחלה נסיונית בכיוון אסטרטגיית השיפורים, עוד לפני סיוס פעולת המידול, על ידי בחינה של מספר מדידות שנתגלו במספר משמעות: של סביבות שונות ובמודלים שוניס של מחזור החייס. דבר זה יכול לספק מידע מסוים שניתן יהיה לבסס עליו את ניתוח 1א(00 ההתחלתי. לפנינו מבחר מדידות שמן הראוי לנסותן בתחילת הפעילות. מבחר של מדידות שימושיות [. פרופיל תפעולי הפרופיל התפעולי הוא מדידת השכיחות של כל פונקציה במערכת, שנמדד בדרך כלל על ידי ניטור הבחירות מתוך התפריט. פרופילים תפעוליים חזויים יכולים לתאר באופן שימושי את הדרך בה צפוי שנשתמש במערכת. פרופילים תפעולייס מציאותייס יכולים לסייע בקביעת סדר עדיפויות לעבודות התחזוקה והבדיקות. 2 חומרת האירועים חומרת האירועים היא מתכונת לסיווג האירועיס המדווחים, בה אירוע הוא כל דבר הגורס בעיות למשתמש (לא בהכרח שגיאת תוכנה). מדידת האירועים לפי מידת החומרה תסייע למקד את פעילויות השיפוריס. הדרכה, או שיגוי נהליס יכוליסם להועיל יותר מאשר תיקון שגיאות סתסם. פרק 6: מדידה ושיפור תהליכים | 151 ממדי הבדיקות היקף הבדיקות הוא ערך המראה איזה חלק של התוכנית נבדק כבר. מדידת היקף הבדיקה באמצעות משפטי תכנות ופקודות הסתעפות מגלות עד כמה הש הבדיקות אפקטיביות בהפעלה של הקוד. נושא זה נדון בפרק 4. שגיאות שדווחו ספירה פשוטה של שגיאות שדווחו במערכת מסוימת נותנת מדידת קו-בסיס של מצבה הנוכחי של התוכנה. השוואת השגיאות המדווחות על בסיס שבועי, או חודשי מספקת מדידה של היציבות, ומסייעת לגלות מגמות כלשהן. שגיאות בזמן הסקר החוזר שגיאות שנתגלו בזמן הסקר מספקות אומדן גס לאיכות המוצר המוגמר. שגיאות במסמך התיכון מספקות הכוונה לבעיות שיש לצפות בשעת הבדיקות, ספירה גבוהה של שגיאות שנתגלו בזמן הסקר מראה לעיתיס תכופות על סיכויים רביס לאחוז דומה של שגיאות בזמן הבדיקה. ניתוח שגיאות שמתגלות בזמן הסקר יכול לשמש לזיהוי שיפוריסם בתהליך הפיתוח. נקודה זו משמשת נושא לדיון רחב יותר בהמשך. שגיאות בזמן הבדיקה שגיאות בעת בדיקות לפי שלבים, מציגות מדד של מצב המוצר תוך כדי התקדמות הבדיקות. בשלביס המוקדמים, ההשוואות השבועיות מגלות את מידת יציבות הקוד, דבר שהוא גורס חיוני בהחלטה מתי ניתן להתחיל בשילוב החלקיס השוניס של התוכנה. תיקוני שגיאות שהושלמו ספירה שבועית של תיקוני שגיאות שהושלמו, מוסיפה למדידה של שגיאות בזמן הבדיקה. כאשר מציגיס אותן באותה מערכת ציריס, מספקות השגיאות שדווחו והשגיאות שתיקוניהן הושלמו, תמונה טובה וכוללת של יציבות התוכנה ומסייעות להחליט אס יש צורך במשאביס נוספיס בצוות הפיתוח. המאמץ ומשך המשימות מדידות המאמ ומשך המשימות השונות, דרושות עבור בקרת הפרויקט. עס זאת, הן מספקות גס ערכים באמצעותם ניתן לכייל את מודל מחזור החייס המשמש לתכנון הפרויקט. התרעות מוקדמות אפשריות גם כן על ידי ניטור מגמות המעידות על כך שמוקדשת תוספת זמן ומאמץ לפעילויות התיכון. עלות על פי סוג שגיאה מדידות העלות לתיקון כל סוג שגיאה מדווחת, מספקות משוב לתהליך הפיתוח ומצביעות על המקומות בהס יש צורך רב יותר בשיפורים. מדידות אלו יכולות לסייע בקביעת סדר העדיפויות בעבודת תיקון השגיאות. שגיאות לתוכנית ספירת שגיאות לפי תוכנית יכולה להיות שימושית בחשיפת תוכניות שיש מקוס להחליפן או לעצבן מחדש. 2 ניהול איכות תוכנה מגדקיפ ומדידת ביצועיפ מבדקים (קחואזפוההסת6פ) או השוואת ביצועים ראוייס לאזכור מיוחד, משוס שזו טכניקה המכוונת במיוחד לקביעת יעדי שיפוריס והשגתם. בספר זה איננו מעונייניס רק במבדקי תחרות, כלומר, קביעת יעדיסם המבוססים על ביצועי הטובים שבמתחרינו. אנו מעונייניס גס בעיקרון הבסיסי של קביעת יעדי ביצועים, מבוססים על מידע אובייקטיבי של מה שהוא בר-הישג, או הושג בפועל, ולא להשתמש ביעדים שרירותייס של אחוזי השיפור. למשל, נוכל להציב לנו יעד: להקטין בשנה הבאה ב-10 אחוזים את כמות התקלות המדווחות על ידי הלקוחות. אך אס כל מתחרינו עוברים אותנו בלמעלה מ-10 אחוזים בתחום זה וביצועיהם משתפרים ב-15 אחוז לשנה, הרי שאנו צפויים לצרות. אס ברצוננו להיות יהטוביס בכיתהי, עלינו להגביה את רף היעד כך שנוכל לא רק להתאזן עס המתחרים, אלא אף לעבור אותס. זהו הבסיס למבדקיס תחרותיים. עס זאת, אנו עלולים להחטיא את היעד שקבענו, אס המתחרים כבר השיגו אותנו. הניסיון לעבור אותס רק יביא אותנו לרפיון ידיים. אנו זקוקיס לגישה שתספק לנו סדרת מבדקים, כדי שנוכל לבחור באסטרטגיה שתוביל אותנו לרמת ביצועיס הישגייס באמצעות סדרת צעדים בני-הישג בפרק זמן מציאותי. קיימות ארבע טכניקות הנמצאות בשימוש נרחב: [. מבדקים פנימיים, שעורכיס השוואות בין חלקי אותו ארגון ומשתמשים במוצלחיס ביותר כבקנה מידה שהאחריס אמוריס להשתדל להשיג אותו. 2 מבדקים תחרותיים, שמשווים ביצועים עס ארגונים תחרותיים, במיוחד עס המוליכיסם בשוק, או עס אלה שיש להס יתרון תחרותי מסויס. 3 מבדקיס פונקציונליים, שמשוויס פעולות פונקציונליות מסוימות עם ארגוניס אחריס העוסקיס בתחומים פונקציונליים דומיס החברות המשמשות להשוואה אינן חייבות להיות בהכרח חברות מתחרות. הן יכולות להיות חברות הידועות כאפקטיביות ביותר באותו תחוס פונקציונלי בענף תעשייתי אחר. 4 מבדקים כלליים, שמשווים תהליכים עסקיים שלמים עס חברות אחרות (לאו דווקא מאותו ענף), שמשתמשות באותו תהליך בסיסי. בדרך כלל התהליכים חוציס גבולות פונקציונליים אינדיבידואלייס. לכל אחת משיטות אלו יתרונות ומגבלות. בין התחומים הקשים ביותר ניתן לציין את איסוף המידע השימושי אודות המתחרים, ואת הקושי הכרוך ביישוס רעיונות חדשים, או מענייניס הלקוחיס מענפים אחריס. בתור מפתתי תוכנה, נוכל להשתמש בטכניקות אלו בדרכיס שונות : * על ידי השוואת פיתוח תוכנה עס פונקציות פנימיות אחרות בארגון שלנו; * על ידי השוואת כלל הפעילות העסקית שלנו עס גוף מתחרה, כאשר שנינו נמצאים בעיסוק הראשוני של פיתוח תוכנה. כלומר, בית תוכנה אחד המשתמש בבית תוכנה אחר לקיוס מבדקיס תחרותייס ; פדק 6: מדידה ושיפור תהליכים | 153 = על ידי השוואת מתחלקת זז (טכנולוגית המידע) שלנו עס זו של חברה אחרת, ואולי בענף תעשייתי אחר; = על ידי השוואת תהליך פיתוח התוכנה שלנו מול התהליך הקייס בחברה אחרת שעוסקת בפיתוח תוכנה בתנאיס דומים. האפשרות שנבחר תקבע במידה רבה על ידי סוג העסק שלנו, אם כל יכולות להיות לפעמים כמה אפשרויות בחירה. מודל המערכת לניהול האיכות שמסופק על ידי התקנים 9001 150 ו/או 9000-3 150 הוא, למעשה, צורה מסוימת של מבדקים. היא מעידה שכל הארגונים שנרשמו בהצלחה (שעמדו בתנאי התקנים) והגיעו לסטנדרט משותף של ניהול האיכות. עס זאת, תהליך הרישום אינו מודד את הביצועים במובן הרחב יותר, ולכן אינו שימושי כגורס השוואתי אלא רק בזירת האיכות. עם זאת, יש סכימות כדוגמת 'פרס האיכות האירופל' (6זגאו4/ /4[11ט2) ם68קסזטם) שמיישמות מודל סטנדרטי של הארגון ומודדות לפי פרמטרים שונים, כולל ביצועים. ארגוניס המשתמשיס באותו מודל ניתניס להשוואה ישירה. אחת השיטות לעריכת מבדקיס יכולה להתבסס על הצטרפות לארגון כגון ייהמוסד האירופי לניהול האיכות" (1א0) ולהשתתפות במידע עס ארגוניס אחריס, שאינס בהכרח מתחרים ישיריס, בכל הנוגע לביצועים בהשוואה למודל של ]א (הערה: ספר זה נכתב באירופה ומתייחס למצב הקיים שם, גס בישראל יש מודל לפרס האיכות בתעשיה, המנוהל על ידי איגוד תעשיות האלקטרוניקה, ראה נספח). מכדקי פיתות תוכגה פיתוח התוכנה הוא פעילות המשותפת לארגונים רביס מתחומיס עסקייס שוניס. מכיון שכך, יכולים להימצא ארגונים רביס שעוסקיס בפעילויות פיתות הניתנות להשוואה, ושאינס בהכרח מתחרים. עריכת מבדקיס יכולה להיות פעילות פורייה, ועס זאת אין בה סיכוניס הכרוכיס בהתקרבות יתר אל המתחרה. דרך טובה להשגת רמה שימושית של שיתוף במידע היא על ידי יצירת 'מועדוני מבדקים' ('פטט[6 פתואזגוחת6ת6פ'). החברים במועדוניס אלה מחליפיס ביניהם מידע על התהליכים והביצועים שלהם לתועלת כל הנוגעיס בדבר. מועדוני מבדקיס קיימיס כבר במגזריס תעשייתיים מסוימים. מועדון מבדקים לתוכנה יכול להיות פתוח לכל ענפי התעשייה, והנושא המשותף יכול להיות מידת המעורבות של ההנהלה בפיתות תוכנה. על החברות במועדונים כאלה ותועלתה אפשר ללמוד מימועדוניסי קיימים, כגון האגודה הבריטית - קטסזנ) ]1605מ1 ]526018115 ץ500161 זסוטקות20) מפוווזם, או איגודיס אחרים במישור הבינלאומי. מה ישמש נושא למבדקים! אנו יכולים להעלות על הדעת מספר מדידות. ביצועים יכוליס להימדד במונחים של מספר שגיאות מול מספר שורות קוד, או על ידי היחס שבין מספר השגיאות לבין מספר הפונקציות שהושלמו, כפי שנמדדו על ידי הלקוחות. ניתן להעריך את הפריון במונחים של מאמץ הפיתוח מול שורות קוד, או מול פונקציות 4 ניהול איכות תוכנה שסופקו. איכות התוכנה שנמסרה יכולה להימדד גס על ידי מדידת מאמץ התחזוקה המוקדש אך ורק לפעילויות תיקון שגיאות. את האפקטיביות אפשר להעריך על ידי מדידת היחס של מצביעי הצלחה קריטייס שהושגו שישה חודשים לאחר האספקה. זהו מבדק שימושי במיוחד במקרה שנקטנו בצעדיס לשיפור תהליכים, כדי לצמצס את מספר השגיאות שיתגלו במבחני הקבלה. נראה שהמדידות עליהן הצבענו גסות למדי, ובפועל, מדידתן תהיה שונה מארגון לארגון. לכן, ערך ההשוואות הפשוטות יהיה מוטל בספק רב בתחילת כל תרגיל מסוג זה. עס זאת, יצירת פרמטריס סטנדרטייסם שיימדדו באותן הדרכיס בארגוניס השונים תוכל להביא תועלת רבה במרוצת הזמן. השקעת זמן וכספים יוצרת בסיס לפעולת המבדקיסם, ויחד עס זאת, מעשירה את נהגי המדידה בכל הארגונים המשתתפים בפעולה זו. מוזידת ביצועי פיתות התוכגה הדבר הראשון בו יש להכיר בתחוס מדידת הביצועים של כל תהליך, הוא שהמדידה מתחילה להיות בעלת משמעות רק כאשר התהליך הנמדד הוא יציב. כלומר, שהתהליך בשימוש רציף וסדיר על ידי כלל העובדים השייכים לנושא, ושהתהליך הבסיסי אינו נתון לשינוייס יסודייס, או תכופיס. מכל זה ברור, שהתהליך מתועד גס בכתב. בעיקרון, מנגנון שיפור הביצועיס פשוט למדי. 7 לוש מרשם פשוט לשיפור ביצועים [. החלט על הפרמטריס העיקריים של התהליך. 2 מדוד את כל הפרמטריס האלה ורשוס את ערכיהס. 3 החלט על יעדים עבור כל פרמטר. 4 בחר באסטרטגיות שיפוריסם מתאימות לשיפור של אחד, או יותר מהפרמטריס האלה. הפעל טכניקת שיפוריסם אחת שמכוונת לשיפור פרמטר אחד. עקוב אחר הביצוע עד שתגיע למצב יציב חדש. אמוד את הערך של השיפור המוצע. אס הצלחת, השאר את השיפור במקומו והפעל שיפור חדש לגבי פרמטר אחר. 0 ₪93 ₪ בכל שלב, אס אחת מדרכי השיפור אינה מצליחה לשפר את הפרמטר שבחרת בו, או שיש לכך השפעה לא רצויה על פרמטר אחר, עצור ונתח את המצב לפנל שתמשיך. 0. המשך עד שכל אפשרויות השיפור שבחרת תופעלנה במשולב. 11 קבע לעצמך יעדיס חדשים. עס פרק 6: מדידה ושיפור תהליכים | 155 ההחלטה החשובה ביותר שעליך לקבל מתייחסת לבתירת הפרמטרים העיקריים. טבעי שהפרמטריס העיקריים עבורך מותנים במחזור החיים המסוים של הפיתות שלך ובתרבות העסקית. עס זאת, יש כמה קווי פעילות משותפיסם שתרמו להבנה רבת ערך אצל מפתחים רבים. רוב האנשיס מתחילים במדידת פגמים. אלה קליס יחסית למדידה, ובדרך כלל מספקים תמונה די ברורה של מידת ההצלחה בהימנעות משגיאות, או סילוקן מתהליך הפיתות. זהו בדיוק מה שתקן 9000-3 150 מצפה ממך, ולכן כדאי הדבר, ולו רק מהבחינה הזו. עס זאת, מדידת הפגמים מגלה הרבה בכל הנוגע ליציבות תהליך מחזור החייס שאתה נוהג לפיו, ובדבר יתרבות האיכות'י שלך. יהיה עלינו להרחיב יותר את הדיבור בשתי סוגיות אלו לפני שנחזור לנושא מדידת הפגמיס. היציבות נחשפת מייד על ידי נסיונותיך להקים את תהליך המדידה עצמו. לעיתים תכופות מתעוררות בעיות ברגע שנודע לאנשיס שיש תוכנית למדוד תפוקת שלב מסויס של מחזור החיים. מתעוררים ויכוחים על המקוס המתאים ביותר למדידת הפרמטר הנדון, או על המשמעות הנכונה של הפרמטר, אס יש לו בכלל משמעות. ויכוחיס מסוג זה יעכבו את תוכנית המדידה שלך, אך אל תתפתה לקיצורי דרך כדי לפצות על הזמן שאבד. הוויכותחים הס חיונייס. עדיף היה אילו הס היו מתעורריס קודס לכן, אך עתה אסור להמשיך בלעדיהס. משעה שמסתיימים הוויכוחים, יש לפניך תהליך יציב ובסיס טוב יותר לשיפור תהליכים, שלא לדבר על הערך הרב של התרגיל בתקשורת, שתרס לפתרון הבעיות. תרבות האיכות היא אותה נטייה אמיתית, אך בלתי מוחשית, לשיפור תהליכים. ארגון בעל מחויבות ושואף קידמה בדרך כלל תופס בשתי ידיים כל הודמנות לשיפור תהליכים ומצעיד אותה קדימה בעוז. ארגון בעל מחויבות נמוכה יותר ופחות נמר>, מוצא מכשולים ותירוציס לחוסר הקידמה, בהתאם לרמת המחויבות שלו. ייתכן שספירת הסיבות הניתנות לאי נקיטת פעולות לשיפור תהליכיס היתה יכולה לשמש כלי מדידה טוב למידת המחויבות לאיכות. מדוע לעסוק בפגמים! הפגמיס מאפשרים לנו מבט לאחור אל תוך תהליך הפיתוח, ויכוליס לחשוף חולשות. נוסף לכך, יש בהס כדי להשליך אל התקופה של השימוש התפעולי ולנבא את הבעיות ואת רמת התמיכה שעשויה להידרש. ספירת הפגמיס יכולה להיות פשוטה בתנאי שתנהל רישוס של האירועיס ותנסה לסלקם (אם לא תעשה זאת, מעטים הסיכויים שיהיה לך תהליך המסוגל להשתפרות שיטתית). ניתוח הנתוניס שאתה אוסף הוא קצת יותר מסובך, ובקטע הבא נעסוק בו ביתר פירוט. ספירת הפגמים אינה הפרמטר היחיד שיש בו עניין, ולא תמיד הפרמטר החשוב ביותר בכל המקרים, עם זאת, הוא משמש כאן כדוגמה פשוטה לדרך בה אפשר להתחיל בתרגיל שיפור התהליכים. ככל שתמשיך, תמצא בוודאי שמתגלים פרמטרים אחרים המתחרים על תואר יהפרמטר החשוב ביותרי. שיפור תהליכיס הוא תהליך איטרטיבי, והאסטרטגיה האפקטיבית ביותר לטווח ארוך היא לנסות לבצע שינוייס קטניס על בסיס מתמשך. מדידה וניתוח נתוני הפגמיס הם דוגמה טובה לאחד השיפוריס הקטניס האלה. 6 ניהול איכות תוכנת שיפור תהליכיע מעשי הנכת מטרות סאיאותיות לשיפוריפ כשאתה מודע לבעיות כבדות, סביר שתרגיש שכל שיפור מביא לך תועלת. אם לעומת זאת, יש לרשותך תהליך יציב ומפותח היטב, שמזה זמן אתה מקפיד לשפרו, יש להניח שתהיה מעוניין בלא פחות מאשר עריכת מבדק (אזגותהסחסס) שישווה בינך לבין מפתת התוכנה היעיל ביותר שתוכל למצוא. רוב הארגוניס נמצאיס בין שני קצוות אלה. מה אס כן יכול להוות יעד סביר! שבעה צעדים קלים כדי להיות 'הטוב ביותרי 1. הקס תהליך יציב ומתועד. החלט על הפרמטרים העיקריים. 2 ערוך ביקורת של התהליך מול הנהלים המתועדיסם, ותקן את כל הפגמים שייחשפו. 3 מדוד את הפרמטריס העיקריים, קבע קו-בסיס לביצועים, ופעל לגבי ליקויים בביצוע. 4 קבע מטרות שרירותיות לשיפורים (נניח 5 עד 10 אחוזים), כדי להחליט עד כמה קל או קשה לבצע שיפורים. 5 קבע יעדיס קשיס אך ניתניס להשגה, ושפר בהתמדה את התהליך עד להשגתם. 6. קבע יעדי מבדק חיצונייס ושפר בהתמדה את התהליך עד להשגתם. 77 קבע יעדיסם למבדק של יהטוב ביותרי ושפר את התהליך, עד שתעבור את היעדים שקבעת, באחוז שולייס גדול מהשיפוריס שאתה מצפה שיבצעו מתחריך. תוכל להתחיל את תוכניתך לשיפור התהליכים מכל נקודה שנראית לך מתאימה ולסיימה בכל נקודה שהיא (או כאשר ייגמר לך המר>). מחזור הסט מחזור .200 מוצג בתרשים 6.9. הוא מייצג את המראה הפשוט ביותר האפשרי של תהליך שיפור התהליכיס : חג!2, סכ, 66%ת0, 461 (תכנן, בצע, בדוק, עשה). תכנן את השינוייס שאתה מצפה לבצע ואת דרך הביצוע. בצע את השינוייס. בדוק את אפקטיביות השינויים על ידי מדידת הפרמטרים המתאימים. פעל על פי המדידות, בכך שתחזור על התהליך. התבוננו כבר בחלקי הביצוע והבדיקה. עתה דרושיס לנו אמצעים אפקטיביים כדי להחליט איזה שינוייס לבצע. פרק 6: מדידה ושיפור תהליכים | 157 תרשים 6.9 מחזור 2064 טכניקות וכליפ נחזור אל תרחיש ספירת הפגמים. נניח שאנו מספקיס תוכנה שיש בה פגמיס בשיעור של 35 פגמיס בשנה, לפי דיווחי הלקוחות. האס זה מספר משמעותי: מה מידת חומרת הפגמים! איזה מוצרים מייצריס את המספר הגבוה ביותר של פגמיס: כמה עולה לתקן את הפגמים! מדידה אחת מובילה לשאלות חדשות שמחייבות מדידות נוספות. כאשר אנו מציביס לעצמנו את המטרה הפשוטה של צמצוס מספר הפגמיס ב-10 אחוז, נוכל להשתמש בגישת ]600% (יעד, שאלה, מדד) ולעורר מספר גדול ככל האפשר של שאלות. במקוס זאת, נשתמש בפגמים אלה כדי לחקור את התהליך עצמו ביתר פירוט. כדי לפשט את חקירותינו, נבחר במקרה בו אנו מספקיס ותומכים במערכת אחת בלבד, הנמצאת בשימושו של ארגון אחד, ובו רק משתמש אחד. מניין צצות כל השגיאות האלו אחת הדרכים בהן נוכל לברר זאת, היא ימכשורי התהליך על ידי מדידת פגמים בכל שלב. שגיאות שהתגלו בסקר התיכון, שגיאות שהתגלו בבדיקת יחידות, שגיאות שהתגלו בזמן בדיקות שילוב היחידות, ושגיאות שהתגלו בזמן בדיקת המערכת, כל אלו מספרות לנו דבר מה על התהליך. היכן מתגלות רוב השגיאות! מהו סוג השגיאות שמתגלה בכל שלב! כדי לנהל חקירה ממין זה, אנו זקוקיס להגדרות ברורות של מה שאנו מחפשים בכל שלב, של מה שאנחנו מגדירים כפגס. אנו גס זקוקים למנגנון לסיווג הפגמיס שנגלה, כדי שנוכל לקבוע מהי מידת החוּמרה של כל פגם. דרך אחרת בה נוכל לחקור את מקורות הפגמים היא לנסות, בשיטת סיעור מוחות, להעלות על הדעת סיבות אפשריות לפגמים. לאחר מכן, צריך לחקור את הפגמיס המדווחים, ולשייך לכל אחד מהס את אחת הסיבות שהעלינו בדעתנו. פגמיס שעבורס לא יימצאו סיבות מתאימות יפתחו פתח למציאת סיבות לקטגוריות נוספות של סיבות. כך לא יקשה עלינו לזהות מהן הסיבות הפוטנציאליות הגורמות לרוב התקלות, ולטפל בסיבות אלו בעדיפות גבוהה ביותר להשגת שיפוריס. 8 ניהול איכות תוכנה פרק 6: מדידה ושיפור תהליכים | 159 תדשיס 6.10 דיאגרמת אישיקאווה לבעיית שגיאות יתר במכחני הקבלת סא 1% .60 חס 58560 ]40 % . % > % 8 % ₪ / . ד % 6 זז 00 6 לצ > 4% 9 0 5 *ב. ₪ %6סא -זטוח9]0טס 8 66)זסקטז 4 01 אטקחהון) 5 טסחג)קטטסה חו עה > זר וס חטזט6 60 וטא 9 646 606011 וסצן ל ב 0 6 5 ₪ 25 "6% ב | זססק ב ₪ 5 0 גי 6 זט זססין , 5 וט ת!ז 6160טטז וסצן צן.. תרשים 6.10 הוא דוגמה של דיאגרמת אישיקאווה (וח8ז38וכ] 88א1511) לבעיה, כאשר הלקוחות מדווחים על שגיאות רבות מאוד. דיאגרמה זו מהווה מנגנון יעיל ביותר להקמת מבנה לפעילות של סיעור מוחות ולרישוס התוצאות. הדיאגרמה נבנית על ידי העברת קו אופקי יחיד המייצג את הבעיה, כגון רמה גבוהה של פגמים. המשתתפים משמיעים את כל הסיבות האפשריות. הסיבות הנראות כסבירות ביותר נדונות ומוערכות, והמשמעותיות ביותר נרשמות בדיאגרמה בצורת קוויס המסתעפים מהקו המרכזי בדומה לעמוד שדרה של דג. לפיכך, דיאגרמות אלו נקראות לעיתיס בשםס 'דיאגרמת אידרת-הדג' (וזגז0/48 0006 ח₪5). לאחר זיהוי הרמה הראשונה של הסיבות האפשריות, אפשר לנתח כל אחת מהן ניתוח נוסף באותו תהליך, כדי לזהות את הרמה השנייה של סיבות אפשריות. בדרך זו, ניתן לבנות עץ שלס של סיבה-תוצאה ולנתת אותו, כדי לקבוע את הסיבות השורשיות לבעיות. זהו ניתוח חשוב מאוד. מאמץ שיושקע בסילוק סימפטומים, או אפילו סיבות מהרמה הראשונה, לא יסלק, בדרך כלל, את הבעיות. בדרך כלל, חוזרים על כל התהליך עד שלבסוף מתגלות הסיבות השורשיות. אס מצליחיס להכיר את הסיבות השורשיות ולסלק אותן כבר בשלב אחד, חוסכיס מאמצ רב בהוצאות ובזמן. דוגמה נוספת לניתות מסוג שגיאה וסיבה ניתנת בתרשים 6.11. זהו :ומן שגיאות שהתקבל מסקר התיכון. יומן השגיאות נוצר על ידי ספירת השגיאות שדווחו בסוף סקר התיכון והקצאתן לאחת, או יותר מהסיבות האפשריות. השגיאות סווגו לסיבות ראשיות ומשניות; שגיאה ראשית הוגדרה כשגיאה שיכולה לגרוס לכשל של תוכנית, ואילו שגיאה משנית הוגדרה כשגיאה שלא תגרוס בהכרח לתפקוד לקוי של התוכנית, אך היא פוגעת באחד הכללים. חריגה מדיסציפלינת התכנות למשל, תסווג כמשנית. נוסף -- 2 א 6 = ה ₪6 כ כ ₪ ש ראשי: שגיאה שמובילה לכשל במערכת ; משני: שגיאה בתיעוד, או בהיצמדות לכללים; כ - וסזפסו0 וס 000 - תרשים זרימת נתונים תדשים 6.11 :ומן שגיאות תיכון 0 ניהול איכות תוכנה השימוש במונח ימשניי אולי אינו התווית ההולמת ביותר שגיאות אלו. נכון שמתייחסים אליהן לעיתיס כאל שגיאות פשוטות ומובנות, אך לפעמים, תוצאותיהן יכולות להיות הרות אסון. כל שגיאה ימשניתי מייצגת בעיה פוטנציאלית עבור צוות התחזוקה שיצטרך לתמוך במוצר, תוך כדי מתן השרות. שגיאה ימשניתי כדוגמת פגיעה בדיסציפלינת התכנות עלולה להוליך מאוחר יותר לבעיות ביישוס שינוייס שהס פשוטיס למראית עין. באותה דרך, מחדלים ימשנייסי בתיעוד יכולים להותיר את עובדי התמיכה במצב בו יהיה להם מידע מועט מדי למעקב אחר בעיה. כל שגיאה ימשנית' יכולה להפוך לבעיה ראשית מרגע שמכניסיס את התוכנה לשימוש. אין לשכוח שתקופת השירות הניתנת לתוכנה, היא בדרך כלל, ממושכת יותר מאשר תקופת הפיתוח שלה. שגיאות מסוימות שכיחות יותר מאחרות, ויש שגיאות שקל יותר לזהות מאשר אחרות אך אף שגיאה אינה פשוטה (משנית) באמת. סיווג השגיאות יהיה מבוסס על ניסיון אישי, ושונה לגבי כל סוג מסמך שתסקור. מה שיילכד בסיווג השגיאות הוא מידע אודות סוגי השגיאות החשוביס ביותר, אשר תרצה לעקור מן השורש. בסקר התיכון שבדרג העליון, בדרך כלל, ישקפו השגיאות סוגיות הנוגעות לשלמות ולעקביות, בעוד שברמת התוכנית הן תתייחסנה (בדרך כלל) לשימוש הנכון והלא נכון במבני תכנות מסוימים, או לטיפול נכון בסוגי נתוניס מסוימיס. המידע שביומן השגיאות יכול לשמש אותך לפחות בשלוש דרכים: שיפור התהליך כלפי מעלה; שיפור התהליך כלפי מטה; ושיפור תהליך סקר התיכון. ראשית, תהליך הסקירה (655ססזק ש6וש6ז). אחת הבעיות הראשיות הנלוות לסקריס היא שמירה על עקביות ועל התמקדות בסוגיות החשובות ביותר. דרך פשוטה להשגת שתי מטרות אלו היא שימוש ברשימות תיוג מחושבות לכל פרטיהן, בהן יכולים הסוקרים להשתמש כסיוע להכנות לקראת פגישת הסקר. רשימות התיוג ממקדות את תשומת הלב בסוגיות החשובות ביותר ומסייעות לשמור על העקביות, משוס שהן שואלות שאלות שמצביעות אל רמת הפירוט בה יש לעסוק בשעת ההכנה לפגישת הסקר. לרוע המזל, יש נטייה להזניח את רשימות התיוג, או לעשות בהן שימוש לא נכון. הסיבה לכך היא שהסוקרים נעשיס בקיאיס בהן יותר מדי, או שהרשימות עצמן חדלות לשקף שינוייס שחלו במרוצת הזמן, וכך לפנינו קבוצה חדשה של יבעיות חשובות ביותרי. יומן השגיאות (פַס! זסזז6) מסייע לזהות שינוייס אלה, משוס שהוא מראה איזה מהם נעשיס שכיחים. כך הוא מספק עדות מוחשית למידת יעילות תהליך הסקירה. ניטור יומני השגיאות מספק התרעה מוקדמת לכל התדרדרות בתהליך הסקירה ומדרבן להכנסת שינוייס ברשימות התיוג של הסקרים כדי שישקפו את הסוגיות הנוכתיות. בדוגמה שבתרשיס 6.11, היינו מצפיס שהרשימה שהניעה סקר זה תתייחס לשגיאות האופייניות לדיאגרמה של זרימת הנתונים, כגון, עקביות ודירוג לפי רמות כפי שנחשפו תוך כדי הסקירה. במקרה ולא, צריך לעדכן את הרשימות כדי שישקפו חולשה זו. פרק 6: מדידה ושיפור תהליכים | 161 שנית, התהליך כלפי מעלה (00659זק וח68זופקט). מה מספר לנו יומן השגיאות על התהליך כלפי מעלה! הוא יכול להוות מצביע אמין לגבי החולשות שבתהליך הפיתוח, בכך שיראה באיזה מטכניקות התכנות יש סכנה גבוהה יותר ליצירת שגיאות. למידע זה נוכל להגיב על ידי מתן הנחיות או הדרכה למתכננים, על ידי עדכון הנהלים, או אפילו על ידי שינוי או החלפת הטכניקות בהן אנו משתמשיס. בכל החלטה, יומן השגיאות יכול לשמש לניטור ההתקדמות, להבהיר לנו אס השגיאות צומצמו או חוסלו, או לא. בתרשיס 6.11, השגיאות שבתרשיסם זרימת הנתוניס נותנות שוב מקוס לדאגה, ומצביעות על הצורך בהמשך מתן הדרכה כדי להזכיר למפתחיס את הטכניקות שבשימוש בתהליך. לבסוף, התהליך כלפי מטה (6658סזק ו60זו5ח/00). במורד התהליך נמצאים כל שלבי הבדיקה שאנו עוסקיס או אמוריס לעסוק כעת בתכנונם. יומן השגיאות של סקר התיכון מציג בעיות שנתקלנו בתיכון, ומהו אופי השגיאות שעשינו עד עתה. מידע זה אנו יכולים לשקף כעת בתוכנית הבדיקות על ידי כך שנוודא שהתחומיס החלשים שבתיכון ייבדקו ביעילות במהלך הבדיקות. עלינו גס לוודא שהבנו את ההשפעות האפשריות הרחבות יותר של השגיאות שגילינו בסקר, ושכללנו בדיקות שימנעו את התממשות שגיאות אלו. נגראה שבתרשים 6.11 יש לנו חולשות אחדות במפרטי המודולים. כדאי יהיה להקדיש למודוליס אלה תשומת לב מיוחדת בעת עריכת בדיקות היחידות הבודדות. כיפד מתחיליע בהכנת האסטרטגיה למדידה ולשיפור תהליכיס פרק זה הציג מספר נושאים ודרכים של המדידה ושל השימושיס בה בשיפור התהליכים. באיזה מהם רצוי לך להשתמש בארגון שלך! קל מאוד להתקע בפרטי תוכניות ובפרויקטי מדידה. יש צורך לעסוק כאן בכמות גדולה של פרטים חשובים, וכמעט וודאי שכל דבר שניתן למדידה יש לו ערך פוטנציאלי כלשהו עבורך. הבעיה היא שאין אפשרות להשתמש בו-זמנית בכל המידע הזה, שיש לו חשיבות פוטנציאלית. מה שדרוש לך הוא אסטרטגיה; אסטרטגיה חייבת לכלול תמיד חוש כיוון. וודא שהתהליכיפ יהיו (כוניס = -----------------0000000-/-]-7-7ְ7ְ------ צעדי מפתח ביצירת אסטרטגיית מדידה 1. התחל בהחלטה לאן ברצונך להגיע. נסה לגלות את הבעיות הרציניות ביותר שעומדות בפני ההנהלה הבכירה (משוס שהיא תצטרך לממן את תוכנית המדידה). 2 ניהול איכות תוכנה 2 בחר בחמשת הנושאים הבעייתיים ביותר וטפל בהם לפי התור, התחל מהחמוּר ביותר. 3 טפל רק בבעיה אחת בזמן נתון. 4 אם הצלחת לקבל סמכויות לטפל בבעיה החשובה ביותר להנהלה שלך, הצלחת להתגבר על המכשול הראשון והקשה ביותר שלפניך. 5. תכנן ויישס בזהירות את אסטרטגיית המדידה שלך, ואז תהיה בעמדה חזקה בכל הנוגע להחזרת ערך ממשי למנהליך. 6. לכל אורך הדרך צפוי שתגלה סוגיות חדשות הטעונות טיפול. אל תרשה לעצמך לסטות מהמסלול. עס זאת, נהל רישוס של סוגיות אלו והצג אותן כמטרות לפרויקטיס עתידיים ככל שתגבר אמינותך. 7 תוכניות מדידה הולכות וצומחות. הנח לתוכניתך להתפתת בקצב טבעי, כדי שתוכל לצבור חוזק וחיגּת. 8 לא יהיה לך קשה להחליט מה יהיה נושא המדידה הבא. הבעיה שתעמוד לפניך תהיה, מה לדחות בעוד אתה עוסק בנושאיס מעדיפות גבוהה יותר. המדידה היא דיסציפלינה שהכל סובב סביב צירה: היא מאפשרת לכמת יעדי איכות; היא מאפשרת להשוות ביצועים מול יעדים; היא מאפשרת לגבש ולנסת יעדי שיפורים. ללא מדידה, האיכות יכולה להיות מושג מעורפל בלבד. מה גדבו איכות הסמואו? בסופו של דבר, מה שחשוב לנו הוא איכות המוצריס שאנו מפיקים. תהליכיס טוביס יכוליס להיות האמצעי הטוב ביותר להשגת איכות המוצר. עס זאת, התהליכים תמיד יהיו האמצעי ולא המטרה. מה שלא נעשה בתהליכים שלנו, עדיין אין בכך ערובה שיהיה בהס כדי לספק מוצרי איכות. כיצד נוודא את איכות המוצר! לנושא זה שני אלמנטים. הראשון הוא נוכחותן של תכונות איכות רצויות כגון אמינות, ידידותיות למשתמש ויכולת של שימוש חוזר ברמות הנדרשות על ידי הלקוח. האלמנט השני הוא השימושיות הכוללת של המוצר. האס זהו באמת המוצר שהלקוח רוצה! כאשר אנו מעצביס מוצר לשיווק המוני, לא די בכך שהמוצר יענה על הדרישות הפונקציונליות שעל הנייר. מה שיקבע יותר מכל יהיה הערך הפנימי של המוצר עבור הלקוחות הפוטנציאליס שלו. אין אסטרטגיה לשיפור תהליכים שיש בה כדי לקדס היבט זה של האיכות. יידרשו לכך צירוף של ניסיון, כישורים, חדשנות וידע שקשור קשר הדוק אל מחלקת הפיתות המסוימת, אל השוק ואל סביבת הפיתות שבה היא פועלת. כישורים אלה הס כישורי התיכון. בפרק הבא נדון באחדיס מהיבטי התיכון. פרק 6: מדידת ושיפור תהליכים | 163 ניהול איכות ושינויים טכנולוגייס חלק 4 מציג נושאי תהליכי פיתוח תוכנה ומחזורי חיים 'לא-קוויים', בצורת פיתות המסתמך על יצירת אבטיפוס ופיתוח מוכוון-עצמים. 0 פרק 7: איכות ומחזורי חיים לא-קוויים. 0 פרק 8: פיתוח יישומים מהיר. 0 פרק 9: פיתוח מוכוון-עצמים. מטרת חלק זה של הספר היא להעשיר את הבנתנו בכיוון חדש של טכנולוגיית התוכנה ולדון במשמעותו לגבי הגישה של מערכת ניהול איכות שהצגנו עד עתה. בפרק 7 אנו מגדירים למה אנו מתכווניס בשם 'לא-קווי' (יז69תו!-חסת') ומתווים את סוגי טכנולוגיות התוכנה המשתייכות לקבוצה זו. לראשונה אנו גם מנסים להגדיר את דרישות האיכות עבור פרויקטים לא-קוויים. בפרק 8 נתבונן במיוחד בטכניקות המבוססות על יצירת אבטיפוס כגון 'פיתוח יישומים מהיר' (כ₪41 - )ח6וק6[0ש26] 5ח63)00ו!קק4 6וקְגת) ו'פיתות יישומים משותף' (כ141. - +ח6וחק126/610 5ח63410ו1קק 4 +חו0(), וננסה לזהות את משמעויותיהן לגבי ניהול איכות. סגנון פיתוח התפתחותי אבולוציוני מחייב אסטרטגיית פיתות התואמת לטבניקה, ולכן אנו דנים באסטרטגיית איכות עבור כ8%. בפרק 9 אנו דנים בגישה מוכוונת-עצמים אל הפיתוח, ומוצאים שזוהי גישת כלאיים המורכבת משיטות תוספתיות ואבולוציוניות (ץְזהחסו)ט!0ץ6 4תג |3)תסוח6זסהו 5ח) כאחד. גם כאן נדון במשמעויות, ונתווה אסטרטגיה לטיפול בהן. אחת ממטוות חלק זה של הספר היא להמחיש את העובדה ששיטות לא-קוויות מחייבות גישה גמישה, אך גם מבוקרת. תקן 9000-3 150 נשאר תקף, אך כאן הוא מסוגל לסייע פחות מאשר בשיטות הקוויות. דרושות לנו הנחיות התואמות יותר לכיוון שלקראתו הטכנולוגיה מתקדמת. סיטואציה זו דומה למצב שיצר את תקן 3 150 - טיפול בשיטות 'לא-סטנדרטיות' הקשורות בטכנולוגיית פיתוח התוכנה. בסוף חלק זה נוכל להבין את משמעויות האיכות של השימוש בשיטות לא-קוויות וכיצד לטפל בהן בפיתוח יישומים מהיר (42/ַ) ובפרויקטים מוכווני-עצמים. תרשים ח.4.1 הוא מפת תפיסה המציגה את הקשרים בין רעיונות המפתח שבחלק. הלק 165 6 נלהול איכות תוכנה תרשים ח.4.1 מפת תפיסה המציגה את הקשרים בין רעיונות המפתת שבחלק | שחוחחגוק שזוספו 7-7 ו וו -% "7 פוחטוחטזוט6 9 זחסווט|סטם 15 לא שוצפ יד בדחההההה-ר לע , , אאטאזו-אסא דאטואץס וטצטס ו031! ושאו סכק 7 איבות ומחזורי חיים לא-קוויים מכוא מאז ומתמיד הופעל לחץ על שיטות פיתוח התוכנה להגיע לפריון גבוה יותר, ותמיד בהנחה שפירוש הדבר יותר קוד בפחות זמן ומשאבים. תביעות אלו לפריון גבוה יותר וללוחות זמנים מקוצרים מוליכות את מפתחי התוכנה לאמץ גישות איטרטיביות והתפתחותיות, בהן אחת המטרות היא למזער את תקורת התיעוד ולהגביר את המאמץ המוקדש לתיכון. האם שיטות לא-קוויות אלו הן בטוחות? האם פקעה זכות הקיום של השיטות המובנות? האם פירוש המגמה הנוכחית הוא, שהענף המתבגר אינו זקוק יותר לתמיכת תהליכי התיכון המובנה, או שפירוש הדבר כניעה סופית לתוהו ובוהו אשר איים תמיד לשטוף את קהיליית התוכנה? איך שלא נתבונן במצב, בעתיד, המעבר לשיטות אפקטיביות לניהול האיכות בסביבה זו, יהיה קריטי להצלחה, ואפילו להישרדות. מחזורי חייפ קווייפ ולא-קווייס מהו מחזור חיים! איזו מטרה הוא משרת! את כל מה שאמרנו עד עתה קישרנו למודל של מחזור חייס (6/016 116). הדבר מצביע בבהירות על החשיבות שאנו מייחסים לרעיון של מודל מחזור החיים כדיסציפלינה יסודית וכקו-בסיס עבור כל הפרטים של שיטות, כליס וטכניקות. מחזורי התייס בהס השתמשנו עד כה היו קווייס כולס. במונח 'קווי' (זגּסחו!) כוונתנו לרצף מוגדר שמתחיל מהדרישות, דרך התיכון והיישום, אל מסירתו הסופית של המוצר. בהכרח, חייב הרצף לכלול מידה מסוימת של איטרציה, כמו למשל, לצורך תיקון שגיאות, או לצורך הכללת שינוייס מבוקשים; אך האיטרציה עצמה משנית לרצף הפעילויות. במחזור חייס קווי, הרצף המוגדר מאפשר לנו לבנות תוכניות מפורטות של תהליך הפיתוח, ולייחס תוכניות ואבני דרך לרמות המתפתחות של פירוט התיכון. החשיבה הקווית היא תהליך טבעי לנו. היא מייצרת תחושה של יקונקרטיותי, כלומר גישה מעשית ועניינית. היא גסם מטפחת את הביטחון התיוני ביכולתנו לספק מוצר איכות שעונה על הדרישות. תרשים 7.1 מדגים את האופי הרציף של מחזור תיים מסוג +, פרק 7: איכות ומחזורי חיים לא-קוויים | 167 למרות שהתזרה ממלאת בו תפקיד ראשי משוס שהיא מוודאת את היכולת להגיע לפתרון שלם ונכון. במחזור חיים קווי, האיטרציה ממלאת תפקיד חשוב באימות ובבדיקת התקפות (ח0וז041/64); יש לה השפעה נכבדה על הערך והאיכות של מוצר, למרות העובדה שהיא יוצרת קשיים רצינייס בתכנון ובבקרה. 006 1 5ח6וח6זוטף6ת וח556 .סחטת 0% .0 וחסז] פזסזז ופ / ו ו , חסווגזק6וחו ח8ו65 חסווגזק6וחה] וח6ו5ע5 ו 1 ח8ו65 ש 5 8 וחסז] שסוע6ז סז 05 וח )וח תקו06 וחט || 008 סןץ16 | 6 (ל) (8) תדשים 7.1 מחזור חיים רציף: (₪ הרצף (0) איטרציה של שלב ההתעקשות להיצמד לתוכנית ערוכה ברצף, אחראית לכשלונות רביס בזמן מבתני הקבלה; שגיאות שהוסתרו במשך תקופה ממושכת צפות ועולות על פני השטח. כמו כן, הפיתוי לשוב ולחזור על תהליכים עד לרגע בו תושג סוף סוף השלמות, אחראי אף הוא למספר רב של פרויקטים שיוצאים משליטה ובסופו של דבר נונחים. הסיבות להזנה שונות: אס משוס שהפרויקטים יקרים מדי, או משוס שהס הופכים ליזוללי משאביסי. איזון בין שני קצוות אלה מושג בתוכנית האיכות. זהו המקוס בו מנהל פרויקט זהיר משליט מדיניות ברורה המאפשרת קבלת הערכה נאותה של הסיכונים והשגיאות בכל אחד מהשלבים, מבלי לעודד שיתוק היכול להתפתת כתוצאה מגישה קנאית מדי לאיכות. מה קורה כאשר מחזור החיים הוא 'לא-קווי' (ז68ח:!-תסח): כאשר אנו אומרים לא-קווי כוונתנו שהתהליך הראשי הוא איטרטיבי או התפתחותי, כרוך בפיתוח פונקציונליות באמצעות מודל או אבטיפוס, אשר מתקרבים אל הפתרון הנדרש תוך סדרה של שיפורים ועידונים. תרשיס 7.2 מציג את האופי האיטרטיבי של מחזור החיים החלזוני (הספיראלי), אף שבדרך כלל תידרש סדרה של מודלים כדי להגיע לפתרון קביל. במחזור חיים לא-קווי, התהליך האיטרטיבי הבסיסי פועל כספק הראשוני של עוך ואיכות, ואילו הרצף נדרש כדי לוודא שתהליך בניית המודל מתקרב לפתרון קביל. הרצף הוא חלק מהדרך בה מוודאים את ההתקדמות העקבית לקראת מטרות ויעדיס 8 ניתול איכות תוכנה מוגדרים, אך בנקודת המוצא, מספר השלביס בו ואורך כל שלב אינס ידועים עדיין. מטבע הדבריס, התכנון והבקרה קשיס יותר מאשר במחזור חיים קווי. במקרה של מחזור חייס לא-קווי, תשומת לב רבה מדי שניתנת לאיטרציות על חשבון הרצף, עלולה להוביל לפרויקטיס לא ממוקדים. עס זאת, ייתכן שמהבתינה הפוטנציאלית תושגנה תוצאות בעלות ערך רב, כתוצאה מתרגילי אבטיפוס. לעיתיס תכופות קורה שפרויקטיס נזנחיסם משוס שהעלות והמאמץ הכרוכיס בהפקת תוצאות שימושיות כלשהן עובריס כל גבול. מאידך, ניסיוו המבקש להתקרב מוקדם מדי למודל יסופיי, מוליך לעיתיס תכופות לפתרונות מורכבים ולא גמישיס. גס כאן, תוכנית האיכות היא המקוס המתאים בו יש להשליט איזון בין האיטרציה לבין הרצף. עס זאת, האם יש ביטחון שדיסציפלינות האיכות הפועלות בהצלחה במחזור חיים קווי, תפעלנה בהצלחה גס בתהליך האיטרטיבי או ההתפתחותי! פיד ץון[החסווסתט] א סז 4 ]====== = 83 2 ן 5חו5ס!ו]וא 6ווויך (ל) (6 תדשיס 7.2 מחזור תיים איטרטיבי: (ג)א הספירלה האיטרטיבית הבסיסית (0) רצף של ספירלות מהן השיטות הלא-קוויות לצורך הדיון שלנו נגדיר את השיטות הלא-קוויות כשיטות בהן האיטרציה ממלאת תפקיד משמעותי יותר מאשר בשיטות הרצף המקובלות. נכלול גישות תוספתיות והתפתחותיות (₪602065 /זאתסווט[סט6 6חג |4זה6וח6זסהו), פיתותחים מבוססי-חבילת- תוכנה ותחזוקה שגרתית. בתרשיס 7.3 מוצעת דרך למיון השיטות הלא-קוויות. באווירה הכוללת של שיטות לא-קוויות, מתבלטות שתי טכניקות כבעלות משמעות מיוחדת: פיתוח מהיר של יישומים, ופיתוח מוכוון-עצמיס. בטכניקות אלו ניתן להשתמש בכל אחת מהגישות הלא-קוויות (בפיתות מוכוון-עצמיס משתמשיס גס במסגרת הקווית). בשני הפרקיס הבאיסם נעסוק בטכניקות אלו, בשל המשמעות וההשפעה הרבה שיש להן על הא:כות. פרק 7: איכות ומחזורי חיים לא-קווייס | 169 בשאר חלקי פרק זה, נבחן את אופי השיטות הלא-קוויות, ונתבונן בדרכיס בהן יכוליס לסייע לנו הקוויס המנחיס של תקן 3 1500 לשימוש בשיטות אלו. 65 ז649חו!-חסאן האס 77. 6 ץזגחסווט!סש וי !66 ג '/ זו 6 ח6)חוב3וא שחוקץזסוסזץ . 0 , , 066008 7% י "3 2 6 0 0 ]ח6וחקט!6צטכ] >)ח6וח6זוטףשת , ל"ש כ -- וסוס + , י 0 + >חסו)ב6ו!קק 4 "5/5 מ 3ושותוש:תוס .2:5 ב == 6חושַח6 0356 גוג "., 001-94566ך " חסוז63ו!קקג 7-.., | סגנ/סאה / תדשים 7.3 דרך למיון שיטות לא-קוויות התפתחות התוכגה התפתחות מתוכננת ולא מתוכננת כל תוכנה נוצרת, בין אם כתוצאה מתוכנית מחושבת מראש, ובין אס כתוצאה מאי יכולת להשיג את היעדים הרצוייס בניסיון הראשון. פרויקטיס יומרנייס רביס סובלים מתוצאות לא-נמנעות של הניסיון לדחוס כמות פיתוח מרובה ללוח זמניס קבוע מראש. בפרק 3 בחנו תרחיש קלאסי, בו חקרנו את ההשפעות האפשריות של אילוץ פרויקט פיתוח, שלא הוגדר כהלכה, לתוך תקציב ולוח זמניס ספציפיים. העתקנו את תרשים 1 כתרשים 7.4, כדי להזכיר לך את הבעיות בהן נתקלנו. שם הגענו למסקנה שגס אם הפרויקט מסתיים בזמן, יש מקוס לצפות שהוא יכיל פעריס וחולשות נכבדים. איכות התוכנה לא איפשרה עבודה מחדש (אזסש6ז), ולמעשה, ביצוע חוזר של פעילויות שהיינו נוקטיס כדי לנסות להביא לכך שלכל הפחות ניתן יהיה להשתמש במערכת. בדרך כלל, ההיבטיס רבים ולא-צפויים של המערכת היו 0 ניהול איכות תוכנה 4 מביאיס לעבודה חוזרת. בסופו של דבר, התוכנה יכולה היתה להימסר במצב שמיש, אך ירגישי במקצת. בשלב זה נוצר צורך לטפל, במסגרת שלב התחזוקה, באוסף הגדול של שינוייס מבוקשיס (ש'הוקפאוי כדי לאפשר את השלמת העבודה מחדש). 01 1 שוח 1 6666[סזק 5 וחצווחווקס - 1 וחפו|63 - 2 סו - 3 זו653 -4 וחפ!וסוהץ6 - 5 חסוזהחקו69ת -- 6 גד סחוי ונ 6 א זג ץזסטו[66 ץז6ו[06 ל6צו|6 תדשיס 7.4 תהליך פיתוח סכימתי עס מגבלות שנקבעו במסגרת זאת, עבודה מחדש מייצגת חלק גדול ביותר של כלל השקעת המשאביםס בפרויקט. אין זה בלתי שכיח שבתנאים מסוימים, מגיעה עלות העיבוד החוזר עד כדי 0 אחוז מהעלות הכוללת של הפרויקט. בשל אופי העבודה הזו, מעטיס הסיכוייס שנוכל לתכננה היטב. בהיותה מונעת על ידי דוחות של שגיאות ועל ידי דרישות לשינוייסם, רביס הסיכוייס שפאזת העיבוד החוזר תתנהל כתרגיל לא מתוכנן ביצירת אבטיפוסיס, ותסתייסם כתוצאה מלתץ גובר והולך לספק את המערכת גם אם הפתרונות שנעזרו באבטיפוסיס לא עובדו במלואס. שלב התחזוקה הוא תרגיל נוסף ודומה בתרגיל ההתפתחותי, אלא שהוא משתרע על פני לוח זמנים ארוך יותר ומבוסס על הבסיס הלא-יציב של התוכנה, שהועבר לשלב התחזוקה בגמר העבודה מחדש. פרויקט זה, שתוכנן כפיתוח רציף יחיד, נמסר בסופו של דבר כהתפתחות תלת-שלבית. בכל הפרויקטיס, בין אס הס מבוססיס על שיטות קוויות או לא-קוויות, כרוכים שנל שלבי התפתחות : שלב הפיתוח ושלב העבודה החוזרת. מעטיס הפרויקטים המתוכנניס כפיתוחיס התפתחותייס. ראוי היה שהפרויקט שלנו יתוכנן בשלביס, כשכל שלב נבחר על סמך העדיפויות של המשתמשיס ועל הערכה מציאותית של הניתן להשגה. בדרך זו, הסיכוייס להשגת תוצאה מוצלחת עבור המשתמשים, היו עולים בצורה דרמטית. בנוסף, ניתן היה למנוע את ההשפעות השליליות על עיצוב התוכנה. כתוצאה מכך, המוצר היה במצב בו הפיתוח בטווח הארוך, היה נעשה קשה פחות. / פרק 7: איכות ומחזורי חייס לא-קוויים 11 יתרונות החשיבה ההתפתחותית גלויים לעין, אלא שיש גס צורך לשכנע את המשתמשיס שלהתפתחות יש גם יתרונות עבורס. ככלות הכל, ככל שנראה לעין, הגישה ההתפתחותית כרוכה באיחור באספקה של חלק מדרישות המשתמשים. נקודה חיונית שיש לעכלה כאן היא, שהגישה הקווית לא תמיד מספקת את כל הדרישות בזמן. רוב הארגונים המזמיניס פרויקטיס גדולים, שנמשכים למעלה מ- 12 חודשים, למשל, מגלים שבעיות מהסוג שתיארנו שכיחות למדי. כלומר, התאריך שנמסר בפועל כתאויך היעד, לא רק שאינו שלם, אלא גם ייתכן שלא ישקף את הדרישות הדחופות ביותר של המשתמשים. כדי להתגבר על בעיה צו, עלינו לתכנן בכיוון גישת אספקה התפתחותית המשקפת את דרישות המשתמשים. יותר ויותר הולך ומתברר שמועטים סיכוייהם של פרויקטיס בעלי אופק תכנון העולה על שישה חודשים, להצליח. את הסיבה לכך ניתן לייחס רק בחלקה לעובדה שהמפתחים מתקשים לתכנן, או ליישס פרויקטיס מסדר גודל זה. עוד יותר חשובה העובדה שהמשתמשיס מתקשים לקבל על עצמס מחויבות מלאה לפרויקטיס החורגיס בהרבה מאופק התכנון האישי שלהם. רובנו מרגישיס לא בנוח עס הרעיון של התבוננות בעתיד מרוחק מדי; זה נכון במיוחד כאשר אנו מתכנניס שינוי משמעותי. אנו יכולים להקיף במחשבתנו יעדים ארוכי טווח, ואפילו חלומות לטווח ארוך עוד יותר, אך לא תמיד אנו יכולים להמיר את כוונותינו לתוכניות מגובשות. הניסיון מלמד, שיכולתנו לדמיין בדיוק תוצאות של תוכנית מפורטת, מצטמצמת לטווח של שישה חודשים. לכן, תוכניות המשתרעות אל מעבר לשישה חודשים קדימה, נתונות לסיכונים כבדים. אינסטינקטיבית, כבר מלכתחילה איננו נותנים אמון רב בתוכניות המתרחבות מעבר לאופק זה. כתוצאה, המשתמשים מציבים את ההשתתפות בפרויקטים ארוכי טווח במקוס נמוך בסולס העדיפויות שלהסם. הס דוחיסם זאת למועד בו נמצא הפרויקט בתוך ששת החודשיס שלפני מועד האספקה. במועד זה כבר מאוחר מדי לתרום תרומה שימושית כלשהי, מבלי לגרוס להפרעות רציניות. שיטות התפתתחותיות ההחלטה על נקיטת גישה התפתחותית (ה80סזקק3 /זאתסוזט!סט6) לפיתוח, משאירה פתוחה את השאלה של דרך הגישה אל תרגיל הפיתוח. עד עתה נסב הדיון על שיטות פיתוח מסורתיות המלוות בגישה התפתחותית אל התכנון. עס זאת, יש שיטות אחרות התואמות טוב יותר לסגנון ההתפתחותי. שיטות שמשתמשות ביצירת אבטיפוס יידונו בפרק 8, ובפרק 9 נעסוק בשיטות המשתמשות בגישה מוכוונת-העצמים. פיתוח תוספתי לצורך דיון זה נגדיר את הפיתוח התוספתי (זמסוחקס!6ש46 [8]ח6וחסזסה:) כגישה הכרוכה בפיתוח או באספקת מערכות, קטע אחר קטע. כל תוספת מכילה חלק מהפונקציונליות של המערכת הכוללת. ניתן להשוות את התהליך להרכבת חלקים של חידת פאזל, בה כל חלק מכיל קטע תמונה חיוני, אך נעזר בשכניו להשלמת הפאזל. 2 נלהול איכות תוכנה סגנון הפיתוח התוספתי כרוך במספר איטרציות גבוה יותר מזה המקובל בפיתוח הקווי המסורתי. עס זאת, ניתן עדיין לנהל את הפיתוח התוספתי בתוך מסגרת פרויקט קווי. תרשים 7.5 מציג אחדות מהצורות הרבות של פיתוח תוספתי המבוססות על מחזור החיים בסגנון צ המוכר לנו. 6 56ב6|6] 61656 2 ]ח6וחקס!6ש6כ 5 1 10 16518 2 )( שוךד | - 3 2 1 חסנובזקטום1 6( תלשים 7.5 גישות של פיתוח תוספת:: (ג) גרסאות בריבוי מערכות; (0) גרסאות בריבוי פיתוחים; (6 הספקה בריבוי תוספות תרשים 8(7.5) מציג ריבוי גרסאות מערכת (6|6856ז וח6ו5ע5 6!קט!טוח) המבוסס על פיתוח מקביל של קטלוג דרישות, מפוצל למחיצות. במקרה זה, תוכלנה התוספות להתבסס על קווי קישור פונקציונליים (6465זח1 [4חסוזסתט)), על יישומים הניגשיס אל אזורים שוניס בבסיס הנתוניס, או על כל מתיצה שמספקת מידה מסוימת של אי-תלות בין המחיצות, הדבר מאפשר לפתח אותן במקביל. צפוי שיהיה מספר גבוה של איטרציות כאשר משלביסם בתוך ההספקה הבאה את הבעיות ואת השינוייסם שנדרשו בעת ההספקה הקודמת. תרשיס 7.5(פ) מציג ריבוי גרסאות פיתוח (6|64565ז זת6וחקס!6ש66 16קו[טוח), המועברות מהפיתות אל ניסויי פיתות עצמאיים. התיכון והקידוד המפורטיס צפויים כאן לאיטרציות בין הגרסאות השונות של ניסויי הפיתוח. פרק 7: איכות ומחזורי חיים לא-קוויים = 173 תרשים 07.5) מציג ריבוי הספקות (6וזסטו[66 [8]חסוח6זסת! 6!קט!טות) מתיכון יתיד. במקרה זה מחולקים שלבי היישום והבדיקות, כך שניתן לבצע הספקה בחלקים, כתוספת. כך עולה אמון הלקוח, וכך גם מתאפשרת עליה באיכות ההספקות התוספתיות, כתוצאה מתיקון שגיאות בשלב מוקדס של מחזור האספקה. בדרך כלל, התוספות מבוססות על קווי קישור פונקציונלייס ומסופקות לפי סדר העדיפויות. למודלים פשוטיס אלה חלופות רבות, אך כולן מתאפיינות ברכיב איטרטיבי המשולב בתוך מחזור חיים קווי. פיתוח תוספתי הוא למעשה, הכלאה של שיטות קוויות ולא-קוויות, ויש להתייחס אליו בהתאס. התכנון לקראת פרויקט תוספתי צריך להיות מבוסס על מודל קווי. עס זאת, יש להיזהר בתכנון השלביס האיטרטיביים. שלא כמו הפיתוח ההתפתחותי שאינו מוגבל בזמן, השלב האיטרטיבי של הפיתוח התוספתי חייב לספק את המוצר במסגרת לוח זמניס נתון. התוכנית חייבת לזהות אבני דרך בסוף השלבים האיטרטיביים, שתציינה את המועד שבו השלב האיטרטיבי חייב להסתיים. שיסות טגוססות-תכבילת-תוכ(ה 5 50006855 [11108ז0) 0 [ 26 5 ופט 5 66 5רט 5 וו ש6שו|6 6 6 65 טף6ז 6 ח0סו]56160 8 2100655 5 5 5 6 חסו]56[66 06 1665 06 1 86 חסוז108ו60ק5 5 רוי 86 006 ה 4 סק 5 68 6 ב | [גטסזקקה 6 06 תדשים 7.6 מחזור חיים של פיתות מבוסס-חבילת-תוכגה 4 ניהול איכות תוכנה 8 ייה הספקת יישומים המבוססת ע הפיתוח הלא-קווי. אי - 0 6 - / 6 משנה אס צריך להכניס שינוייס בחבילה. - מקרה חייב ו - תכונן הארגון לקראת התקנת החבילה, למשל על ידי כתיבת -. 2 וגו לקראת השלב בו תיושס החבילה בפועל. פעילויות אלו דומות . , אלא שהן מיושמות לגבי הארגון, ולא לגבי יישוס התוכנה בדרך , הן כוללות הדמיה של סביבת היישוס החדשה. ל חבילות תוכנה סטנדרטיו ו בו צריך לשנות חבילה סטנדרטית לפני יישומה, ידמה שלב הפיתוח מאוחריס יותר של הפיתוח ההתפתחותי. אלא שכאן יש צורך גם בשלב של ניתוח הדרישות כדי לוודא שהשינויים הוגדרו במלואם ובצורה הנכונה. מחזור התיים המתקבל ידמה למחזור צ קטום, עבור האספקה הראשונה. לאחר מכן יחזור להיות (2 מחזור חייס התפתחותי, שעה שבמקביל נעשים בארגון שינוייס בנהלים ובתוכנה, כדי להגיע לשילוב מתקבל על הדעת. תרשיס 7.6 מציג את מחזור החייס של פיתוח מבוסס-חבילה. התחזוקה כתהליך התפתחותי תחזוקת מוצר תוכנה כלשהו, ואין זה משנה כיצד פיתחו אותו, כרוכה בהכנסת שינוייס בתיכון קייס. התחזוקה יכולה להיות כרוכה בתיקון שגיאות, הרחבה או העשרה של יישוסם, ותיתכן אף התקנה של מספר שינויים בו-זמנית. קיים סיכון שההתפחות תתנהל בכיוון לא רצוי, או ששינוייס בתחוס אחד יפגעו במשתמשיס בתחוס אחר, אלא אס כן כל השינוייס יתוכננו ויוערכו מראש. התפתחות (אבולוציה) באמצעות תחזוקה, מחייבת תוכנית התפתחותית מבוססת על קבוצת יעדיס עסקייס מתאימים. שינויים מוצעים התואמיס למטרות אלו יכוליס לקבל אישור במינימוס השהייה. עס זאת, אישור זה יהיה כפוף לאישור כל קבוצות המשתמשים המעוניינות. שינוייס שאינס כלוליס בתתוס היעדים המוגדריס, טעונים שיקול דעת זהיר. אישור שינויים אלה משמעותו שינוייס מסוימים ביעדים הכלליים, ולכן הוא חייב להישקל על ידי הרשות המתאימה. בכל מקרה, יש צורך לסקור את היעדיס הכללייס אחת לשנה. מיושמות לשיטות לא-קוויות תק 43 1500 ישים גם לגבי שיטות לא-קוויות! תקן זה אינו מכתיב את ו :, אך הנחיית התקן מוצגת בצורה קווית, ומבנה המסמך חפט שבסגנון +. מובן שאין משתמע מכך שיש להעדיף את זאת היה עלינו לעמול קשה כדי להתאים חלק מהנחיות , השימוש במחזור חייס קוו תואס להפליא את מחזור ה מחזור החייס בסגנון +. עס תקן 43 150(0, לשיטה לא-קווית. פרק 7: איכות ומחזורי חיים לא-קונייס | 175 =. תקן 9000-3 ספ ומחזורי חייפ לא-קווייפ שיטות לא-קוויות מציבות מספר בעיות בבואנו לפרש את הנחיות תקן 9000-3 150. היכן מתעוררות הבעיות! בעיקר בקטע הדן בפעילויות של מחזור החיים (המספרים שבסוגרייס מתייחסים לסעיפי התקן, ראה פרק 2): > תכנון הפיתוח (5.4), ובמיוחד: 0 הגדרת השלביס; 0 לוח זמניס של הפרויקט, כולל ויהוי כל המשימות לביצוע. = שלבים (5.4.2.1), במיותחד קלט ופלט של השלביס. > הנהלה (5.4.2.2), במיוחד לוחות זמניס. >= בקרת התקדמות (5.4.3). = דרישות לשלבי הפיתוח (5.4.4). > תוצר שלבי הפיתוח (5.4.5). = אימות כל שלב (5.4.6). *+ תכנון האיכות (5.5). * | תֶכֶן ויישוס (5.6), ובמיוחד סקרים (5.6.4). *+ תכנון הבדיקה (5.7.2), ובמיוחד: 0 תוכניות עבור פריט תוכנה, שילוב, ניסויי מערכת, ובדיקות קבלה; 0 עיצוב בדיקות עבור בדיקות ביניים ; *= בדיקות (5.7.3), ובמיוחד בדיקות רגרסיה. כל התחומיס האלה מחייביס פרשנות מדוקדקת. אחרים, כגון ניהול התצורה, טעוניס תשומת לב מיוחדת בעת היישוס. (יהול פרויקט - הגדרת שלבי הפרויקט ניהול הפרויקט מטופל ראשון משוס שזהו תחוס הסיכון הבולט ביותר. אחד המניעיס העיקריים להגדרת מודלים של מתחזורי חיים קוויים, הוא הצורך לספק למנהל הפרויקט מסגרת לתכנון ולבקרה של הפרויקט. המודל הלא-קווי, שהוא יחסית חסו תכונות (6!635זטז68]) או מאפיינים, כמעט ואינו מספק נקודות אחיזה יציבות; אבני הדרך היחידות שמוגדרות הן התחלה, וסיוס מחזור המידול. מהו ישלבי בשיטה לא-קווית! המועמד הבולט לתואר זה הוא מחזור המידול היחיד, אך השיטות המעשיות נוטות לעשות את פיתוח המודל לתהליך מתמשך; המודל מתפתתח כל הזמן. כדי לזהות ישלביסי באותה משמעות שתקן 9000-3 150 מגדיר אותה (סעיפים 3.5 ו- 5.4.2.1), נצטרך להרכיב איזה שהוא מבנה-על מעל לתהליך ההתפתחותי. מבנה העל מספק אלמנט קווי, בכך שהוא ממיר את הספירלה לסדרת ספירלות קטנות יותר, כפי שמוצג בתרשים 7.2(ט). 6 נלהול איכות תוכנה כפייה זו של הרצף על התהליך האיטרטיבי, יוצרת מבנה בו נוכל לדמיין לעצמנו בדרך קלה יותר את התכנון והבקרה. עס זאת, אסור להניח לפונקציות התכנון והבקרה להשתלט על התהליך האיטרטיבי, ובכך לגרוע מיתרונות ההתפתחות השלבית (איטרטיבית). כל ספירלה ממשיכה להיות איטרטיבית, אך התהליך בכללותו מפוצל למספר צעדים התפתחותיים. ניתן לתכנן כל צעד התפתחות: כחלק מהפיתוח הכולל, ולהופכו בכך לישלבי. כל ישלבי בפני עצמו, ניתן לחלוקת משנה נוספת במקרה הצורך, ואפשר לכוונו אל יעד ספציפי, שהוא כשלעצמו רכיב של יעדי הפרויקט הכוללים. (יטור ההתקדמות ניטור ההתקדמות מנצל את מבנה התכנון כמסגרת בסיסית לזיהוי ולמדידת ההתקדמות. במקרה הלא-קווי, מבנה התכנון מגושס יחסית ובדרך כלל (במקרה הטוב), מספק רק את הרצף ההתחלתי של מחזורי המידול, בהתבסס על ניתוח כולל של היעדיס העסקיים. תוכנית השלב מכילה פירוט מספיק המאפשר לעקוב ולדעת אם מתחזורי המידול המתוכננים הסתיימו אס לאו. עס זאת, אין בפירוט זה כדי לדעת מהי ההתקדמות בפועל, בכיוון השגת היעדים העסקיים. ייתכן שנמצא שאנו עומדים בקצב, בכל הנוגע לתוכנית הפיתוח, אך המודלים שתוכננו בתחילה אינס מתאימים יותר להשגת יעדי העסק. תקן 9000-3 150 מצפה שסקרי ההתקדמות יוודאו את הביצוע האפקטיבי של תוכניות הפיתוח (5.4.3). משמעות הדבר, עיון חוזר בתוכנית עצמה ועדכונה בהתאם לצורך, כדי לוודא שהיא משקפת בצורה נכונה את יעדי העסק. עדכון התוכנית מטופל בעיקר בסעיף 5.4.1. דרושה מידה מסוימת של הערכת כל מודל בסוף מחזור הפיתוח, כדי לקבוע אס המודל המסויס השיג את מטרותיו, ואס הפרויקט הכולל :כול עדיין להשיג את היעדים הכולליס. ניטור ההתקדמות חייב להיות יותר מאשר תיוג סתם, לציון עובדת הסיוס של שלב בפרויקט. עליו לאפשר לנו להגיע לכלל הבנה אמיתית לגבי המקום שבו נמצא הפרויקט. עלינו לדעת את הדבריס הבאים : * האס הפרויקט מסוגל עדיין לעמוד ביעדים; * במקרה שלא, מה הס השינויים שיש להכניס ביעדיס ההתחלתיים; * מתי יש סיכוייס להשגת היעדים ; + העלות של השלמת הפרויקט; * האס הפרויקט ממשיך להיות בעל זכות קיוס. המידע הדרוש לנו צריך להיות איכותי וכמותי גם יחד, ובהשגתו חייבים להיות מעורבים גם נותן החסות לפרויקט וגס צוות הפיתוח. הבנת מצבו האמיתי של הפרויקט, מעצס טבעה, קשה יותר מאשר במקרה של תהליך קווי מובנה. היא נסמכת במידה רבה, על התעניינות מתמשכת ומעורבות נותן החסות פרק 7: איכות ומחזורי חיים לא-קוויים | 177 העסקי. הוא צריך להיות מסוגל לשייך את יעדי כל אחד משלבי המידול למקומו, כחלק מהיעדים הכלליים, ולהגיע למסקנות על מצבו הכללי של הפרויקט. תכנון ותכנון חוזר תהליך לא-קווי צריך להיות בעל שתי שכבות תכנון: = תכנון כולל של הפרויקט ברמת המאקרו, בצורת רצף שלבי מידול; >= תוכנית ברמת המיקרו, עבור כל אחד משלבי המידול. חיוני שהתוכנית ברמת המאקרו תיווצר מתוך היעדים הכוללים, עוד לפני התחלת העבודה. תוכניות ברמת המיקרו, לעומת זאת, תהיינה מותנות בתוצאה של הערכת המודל הקודס. תכנון ותכנון חוזר הס במהותס פעילויות דינמיות, ומהוויס במידה רבה חלק מתהליך הפיתוח עצמן. המודל הקווי של תהליך הפיתוח, יחד עס תהליך ניהול פרויקט, שהוא מקביל וגס עצמאי במידה רבה, פותחיס פתח למודל של שני תהליכיסם הקשוריס ושזורים זה בזה, ומותניס במידה מכרעת זה בזה בכל צעד. תקן 9000-3 150 מתמקד בתוכנית פיתוח, המתעדכנת באופן סדיר. לעומתה נמדדת דרך קבע ההתקדמות שמתאימה למודל הפיתוח הקווי, ועם זאת, אינה מותחת את תכונות המפתח של תהליך הפיתוח הלא-קוולי. תכנון איכות עבור פיתוח לא-קווי תכנון איכות עוסק בקביעת יעדי איכות, ובהגדרת תהליכי ניהול מתאימים כדי לוודא את השגתס (9000-3 150 סעיף 5.5). כיצד משפיע תהליך לא-קווי על קביעת יעדי איכות ועל השגתס! מבחינות רבות, סוגיות תכנון האיכות זהות לאלו של התהליכיס הקוויים. בעיות מסוג מדיניות האיכות, משאבים, הדרכה ושאר סוגיות ההנהלה הכלליות, נשארות ביסודן ללא שינוי; את השינויים נמצא בדינמיקה של הפרויקטיס. תוכנית האיכות היא שדה הקרב בו מתאחד המאבק לאיכות עס הפיתוח הלא-קווי. זה המקום בו הקרבות האידיאולוגייס הפנימיים חריפים ביותר. מן הצד האחד, נמצאת התרבות המונעת על ידי תוצאות, ממנה צומחות, בדרך כלל, השיטות הלא-קוויות. בתרבות זו, כל הנראה כתקורה לא-חיונית משמש כמועמד לחיסול מיידי, וכל דבר הקשור לתכנון איכות, נראה כמטרה נוחה לחיסול. פעילויות איכות מאופיינות (בדרך כלל) כדבר איטי וקפדני, שאינו מסוגל לתרוס לערך העסקי. הגישה הלא-קווית נתפשת כמי שמנחיתה מהלומה על הביורוקרטיה. מן הצד השני, ניצביס חסידי האיכות החושדים עמוקות בשיטות המונעות על ידי תוצאות. זאת משוס שלעיתים תכופות בעבר, הן שימשו כהסוואה לגישה לא ממושמעת ולא מבוקרת לנושא הפיתוח. ההיסטוריה מראה שיישוס שיטות כאלו נדון לכישלון לעיתים תכופות, אך היה גם מספר מספיק של הצלחות שדי בו כדי לא לתת 8 ניהול איכות תוכנת 1 לוויכוח לדעוך. מובן שאנו רוציס להימנע מביורוקרטיה מיותרת, אך אס עד כה עלה בידינו לספק תוצרת כלשהי, הרי זה רק בשל גישתנו הקפדנית לצורך בסקירות חוזרות ובניסויים. גסם אס הפעולה לוקחת זמן רב יותר, לפחות התוצאות הן בסדר, או לפחות, ככל האפשר בסדר, בהתחשב בעובדה שהמשתמשים משנים את דרישותיהס כל הזמן! תפקיד תוכנית האיכות הוא למקד את הדיסציפלינות המגולמות במערכת איכות לתוך פרויקט ספציפי. כך, כל פעילויות האיכות התיוניות ייכללו בו, וברמה הנכונה. עס זאת, ניתן למנוע הכללת פעילויות לא-חיוניות , כברירת מחדל. בפיתוח קווי, תוכנית האיכות היא לעיתיס רק רכיב קטן בתוכנית הפרויקט, רכיב זה מכיל מספר התייחסויות לנהלי איכות בהס יש להשתמש, אך לא יותר מזה. למרות שזה כל מה שנדרש במקריס מסוימים, גישה זו מתעלמת מן הפוטנציאל האמיתי של תוכנית האיכות, המתבטא ביכולתה לשמש כתוכנית כל הפעילויות לניהול הסיכוניס. בפיתוח לא-קווי חייבת תוכנית האיכות לזהות את שלבי המידול, את מנגנון ההערכה ואת המדדיס שישמשו להערכת התוצאה המתקבלת מכל שלב. בתפקיד זה הופכת תוכנית האיכות לחוליה החיונית שבין הפיתוח לפעילויות ניהול הפרויקט. בתוכנית האיכות מוגדרת שזירת שני תהליכים אלה, ובה מחליטים על האיזון שבין הרצף לאיטרציה, כלומר הפעולות שחוזרות על עצמן. יצירת תהליך מבוקר ועס זאת גמיש שמספק שקיפות של ההתקדמות, אך ללא ביורוקרטיה, היא אתגר נכבד ביותר. בתוכנית האיכות עבור פיתוח לא-קווי, הסוגיה היחידה החשובה ביותר שיש לטפל בה, היא שאלת אופי פעולת ההערכה שיש לבצע בסוף כל מחזור מידול. ההערכה חייבת לכלול קלט מכל שחקני המפתח, מצוות הפיתות וגם מקהילת המשתמשים. עם זאת, יש לבצעה בצורה שלא תעכב את ההתקדמות. עיכוביס יכוליס להיווצר גס בעת ביצוע ההערכה עצמה וגס בעת יישוס ההחלטות המתקבלות כפלט ממנה. מנגנון ההערכה חייב להיות : * כפוף ללוח זמניס מדויק ביותר, כדי שכל המשתתפים יוכלו להתפנות מראש לזמן הנדרש לביצוע ההערכה; + מאורגן לפי כללי התנהגות מוגדרים היטב, כדי שלא יבוזבז זמן על נושאיס נהלייס בזמן ביצוע ההערכה; * מבוסס על קריטריוניס מוגדרים מראש כדי לוודא אובייקטיביות מירבית; * להסתיים בהחלטה, או החלטות, על השלב הבא ועל הפרויקט בכלל. בפרקיס הבאים נעסוק ביתר פירוט במנגנון ההערכה עצמן. אימות ובדיקת תקפות גישת מחזור החייס הקווי של סקרי התיכון (9000-3 150, סעיף 5.6.4) ושל הבדיקות המובנות (5.7.2), מבוססת על ההנחה שהמוצרים המוגמרים של פרויקט הפיתות נוצריס בדרך מובנית ברמות גבוהות יותר של פירוט לפני הקידוד, וברמות גבוהות יותר של פירוט הפונקציונליות הכללית אחרי הקידוד. ברור שהנחה זו אינה תקפה פלק 7: איכות ומחזורי חיים לא-קוויים | 179 לגבי פיתוחים לא-קוויים, בהס מוחלפת הגישה המובנית על ידי גישת המידול האיטרטיבי. מה יהיה התחליף! הדרך הטובה ביותר להשגת האימות היא באמצעות סקירת תהליך (ש6וטסז 6055סזק), סקרים נפרדים של האיכות או של התיכון, דורשיס זמן הקמה רב ועשויים אף לחולל פעולות הכרוכות בעבודות חוזרות, אינס עוליס בקנה אחד עס אופי הפיתות ההתפתחותי. לכן חייבים הסקרים להתבצע במסגרת הערכות המודל, ומסקנותיהס חייבות להילקח בחשבון בעת תכנון שלב המידול הבא. במקריס בהס נדרשת עבודה חוזרת, צריך יהיה לשלבה בעבודת פיתוח המודל של השלב הבא. גם לאימות באמצעות בדיקות יש חשיבות, אלא שאי אפשר לבצעו בדרך מובנית שקשורה עם הפיתוחים הקווייס, משוס שאין הוא מפיק מוצריס כלשהס פרט למודלים, ואלה נמצאים כבר בפונקציונליות המלאה, או קרוב אליה. הבדיקות הקריטיות ביותר הן בדיקות הקבלה המבוססות על היעדים העסקיים שנקבעו בתחילה, וצריכות לכלול את כל הפרמטריס הדרושים של הביצוע. בדיקות הקבלה צריכות להירשס ולקבל אישור לפני התחלת המידול. בסוף כל שלב מידול, ניתן להריץ את בדיקות הקבלה ולציין את החריגות; אלו ישמשו מודד לגודל ולאופי הפער שבין המודל לבין הדרישות וישמשו כקלט ראשוני לתהליך ההערכה. בעת ההערכה, יכול השלב השני של המידול להתמקד בשיפור חולשות ספציפיות ובהרחבת המודל, או שניתן לעבד מחדש את המודל כדי לתת לו כיוון שונה. במקרה שההערכה מצביעה על שינוי ביעדים הכוללים, ניתן לעבד מחדש את בדיקות הקבלה כדי שישקפו את השינויים, עוד לפני בדיקת שלב המידול הבא. האימות ובדיקת התקפות דומים בעיקרון לאלה שבפיתוח הקווי, הם שוניס בביצוע בפועל. הבדל זה מורגש במיוחד בפרשנות של ההנחיות לתקן 9000-3 150 סעיף 5.7, בו מצביעים בבהירות על גישה מובנית המבוססת על תיכון המאורגן בצורה היררכית. (יהול התצורה ניהול התצורה חשוב במיוחד לפיתוח התפתחותי, אך המנגנוניס יכוליס לדמות בתמצית לאלה של הפיתוח הקווי. השינוי היסודי ביותר הוא התהליך לבקרת שינויים, שחייב להיות משולב בהערכת המודל. בשלב ההערכה, מתקבלות החלטות על המצב הנוכחי של המודל, ושינויים כלשהם חייבים לקבל אישור לקראת שלב המידול הבא. מנגנון בקרת השינויים חייב לקיים את יכולת המעקב החל מהדרישות ההתחלתיות, דרך כל המודלים שאושרו, ועד למערכת הסופית כפי שתימסר בגמר התהליך. צפוי שיהיו מודלים שלא יאושרו ליישוס. עס זאת, יש מקוס לשמור חלק מהפונקציונליות שלהס או את כולה, לעיון בשלב מאוחר יותר. חיוני שכל המודלים האלה יהיו תחת בקרה, וכי ידוע יהיה השלב בו נוצרו ברצף המודלים, כדי שבמועד הנכון, אפשר יהיה לקבל החלטה על הכללתם בתהליך, באופן מלא או חלקי. 0 ניהול איכות תוכנה 4 להנחיות תקן 9000-3 1500 יש ערך רב והן אינן יוצרות בעיות פרשנות חדשות כ כאשר מיישמים אותן לפיתוח הלא-קווי. אלא שיש לזכור, שהשימוש בהנחיות להיות משולב אפקטיבית עס התכנון הלא-קווי ועם מנגנוני הבקרה. מה הכ היתרונות והמכשוליפ שבגישה הלא-קווי ככלל, הפיתוח הלא-קווי נותן למשתמשיסם בקרה רבה יותר על תהליך הפ ותחושת אחריות גדולה יותר לתוצאות. לכן, רמה גבוהה של מחויבות ההנהלו תנאי מוקדס וחיוני לפרויקטים מוצלתים. לפנינו מספר יתרונות וחסרונות. פיתוח לא-קווי - יתרונות וחסרונות היתרונות 1. אספקה מוקדמת יותר, אפילו של מערכת חלקית, מאפשרת הערכות מלאות והזדמנויות רבות יותר לשיפוריס. 2 הגישה מספקת תוצאות. כתוצאה מכך, במקרה של קיצוציסם בתקצ במשאבים, אין סכנה שנישאר רק עס עיצוב על הנייר שלא-מיושס. 3 ההנהלה יכולה לשנות קדימויות, או במקרה שהכל לא מצליח, היא יכולה פרויקטים חסרי ערך, לפני שאלה יצרכו את רוב המשאבים המוקציס ! בניית פונקציונליות שאין בה צורך. 4. סביר להניח שיהיה קל *ותר לקבל אישור לפרויקטים שהם רבי ערך, : מסוכניס במקצת, תוך התבססות על כך שהסיכונים ניתניס לשליטה. ביכולתנו להשיג שיפורים ממשיים במערכות, במקוס להעסיק עצמנו 1 יבטוחות' לכאורה. החסרונות 1 העדר מחויבות ברורה של ההנהלה יכולה להותיר את הפרויקט ההתפתחור תחושת כיוון ; וסביר להניח גם, שיגרוס להשתתפות לא מספקת של המשתנ 2 הפיתות ההתפתחותי מבוסס לעיתים תכופות על שימוש בכלים של אבטיפוס. תלות-יתר בכלים אלה :כולה להביא להטיה בכיוון של פתרון המועדף על ידי הכלים. 3 חוסר בבקרה אפקטיבית על צוות הפיתות :כול להוליך להתרחקות מהיעדיס העסקיים, לעבר פתרונות קוסמים יותר מהבתינה הטכנית. 4. מנגנון הערכה לא אפקטיבי וכול להוביל לחזרות על שלבים ומתוך כך גכ חוזר של עבודות, מתוך רצון לעמוד ביעדיס לא עקביים, או משתניס. פרק 7: איכות ומחזורי חיים לא-קווייכ שיטות לא-קוויות מציעות יתרונות משמעותייס במחיר מספר סיכוניס רציניים, ומהוות אתגר למנגנוני האיכות הממוסדים. כל העקרונות שנקבעו בפרקיס קודמיס עדיין אפקטיבייס ומתאימיס למטרה שקבענו. יישוס השיטות בסביבה חדשה זו מחייב גישה חדשה. שני הפרקים הבאים מוסיפיס לחקור נושאים אלה בהקשר של שתי טכניקות ספציפיות. 2 ניהול איכות תוכנת 8 9 יצירת אבטיפוס ופיתוח יישומים מהיר מבוא פיתוח יישומים מהיר (₪40 - )הסוהקס!|6צ₪6 פחסו)3סו|סק 6ו30א) כולל אוסף טכניקות שמטרתן העיקרית היא לאפשר הספקת יישומים למשתמשיהן במהירות גדולה יותר מזו שהתאפשרה בשיטות המובנות המסורתיות. במקרים רבים מנצלת גישה זו את השימוש בטכניקות של יצירת אבטיפוס, ובכלים המכוונים לסייע למנגנוני הספקה מהירים. עם זאת, תופעות אלו אינן תמצית הגישה. בלב הגישה מצויים פילוסופיה התפתחותית וסגנון פיתוח לא-קווי, המעניקים לגישה ביטוי מעשי. שיטת 40א עוסקת בהגבלת פרויקטים לתחום של מה שאפשרי במסגרת זמן סבירה, הספקתם במהירות תוך השתתפות מירבית פעילה של המשתמש בתהליך, התייחסות לאסטרטגיה ההתפתחותית לטווח ארוך, שתרום לה כל אחד מהפרויקטים השונים. מנקודת הראות של איכות התוכנה, סגה מהווה סטייה משמעותית ממה שהפך לקביל ומסורתי. פיתוח יישומים מהיר מהווה אתגר משמעותי לאלה שאימצו את השיטות המובנות ואת מערכות ניהול האיכות. יפירת אבטיפוס בתהליך הפיתות יצירת אבטיפוס בתוכנה - ימיה כימות פיתוח התוכנה; יצירת אבטיפוס כשיטה למידול ולהערכת עיצובים עתיקה עוד :ותר. לכן, הגישות של שימוש באבטיפוס בפיתוח תוכנה אינן פתרון תדשני או מקורי במיוחד לבעיות הנדסת התוכנה. ניתן לומר על שיטה זו, שמצאה את מקומה הנכון במארג הכללי של הדברים. תיאור היסטוריית התכנות חייב לפתותח בהופעתו ככישור !וא חדש הקשור במחשביס. בשניס המוקדמות של פיתוח תוכנה, נחשב ייצור התוכניות לכישור המרכזי של המחשוב. כאשר התחילו להתייחס להנדסת התוכנה כאל שיטה לשיפור איכות התוכניות (ובכך גס לשיפור הפריון לטווח ארוך של התוכניתניס), הוסטה תשומת הלב מהתכנות, ששוב לא נחשב כדיסציפלינה המרכזית. השיטות המובנות שהופיעו בהדרגה תרמו להגדרה מפורשת (פורמלית) של תהליך הפיתוח, והגדילו את הסיכוייס להגיע לסיוס מוצלח, אך במתיר אובדן מסויס של היעילות ולוחות זמניס מוגדליס. פדק 8: יצירת אבטיפוס ופיתוח יישומים מחיר ‏ 183 ככל שהוסיפה הנדסת התוכנה להתבגר, נעשו השיטות המובנות מקובלות :ותר ואף הצליחו חלקית לפחות, לספק יישומיס בדרך מבוקרת. עס זאת, עלות הבקרה המוגברת התבטאה בצמצוס מסוים בגמישות, ופרויקטים נמשכו זמן רב יותר ועלו יותר ככל שגבר השימוש בשיטות מובנות. חשיבות מיוחדת נודעה לשתי תופעות : [. השיטות המובנות נטו להגדיל את האמון בתהליך הפיתות וגס עודדו את הארגוניס להיכנס לפרויקטיס גדוליס מאלה שהיו אפשרייס בעבר. כתוצאה מכך הופיעו בעיות חדשות של גודל ומורכבות. 2 לעיתים תכופות נעשה השימוש בשיטות מובנות ללא אבחנה, ללא כל ניסיון להתאים את השיטה לתרבות הארגונית, או לאופי היישומיס. מצב זה הותיר את המפתחיס עס תקורה מיותרת ועם עזרה מועטה, או ללא כל עזרה בבעיות הפיתוח. מפתחי תוכנה רביס אינס חשיס בנוח עס התהליכים הפורמליים של הנדסת התוכנה. הם רואים בשימוש באבטיפוס הזדמנות להתחמק מהתהליך המובנה, וממשיכיס להפיק יישומים על ידי כתיבת קוד, כמעט ללא ניסיון לתעד את המפרט התיכון שלפיו ייבנה הקוד. לשימוש באבטיפוס יצא שם רע בין אלה שיש להס מחויבות לגישה מובנית יותר. צוטטו גס דוגמאות רבות של חריגה בעלויות ובזמן, בפרויקטיס של אבטיפוס שלא הצליחו להגיע לפתרון, או סטו מהמטרה לחלוטין. באקלים של סביבת עסקים המשתנה במהירות ותובעת תגובה מהירה ממערכות המידע של הארגון, מושמעות כל הזמן טענות נגד התקורות של הפיתוח המובנה. יתר על כן, שמירה על מחויבות המשתמשים ומעקב אחר דרישות מורכבות ומשתנות על פני פרק זמן ממושך של הפיתוח, מתברריס במקריס רביס כבלתי אפשריים. מחד, אנו מוכרעיס על ידי הממדיס והמורכבות. ומאידך, בו-זמנית, אנו נתבעיס להגיב במהירות רבה יותר לצורכי מערכת המידע. השימוש באבטיפוס במסגרת דיסציפלינרית שצמחה מתוך ניסיון בשיטות מובנות, חוזר אל הבמה בדמות 'פיתוח יישומים מהירי ( /6). שני סגנונות של שימוש באבטיפוס מקובלים היוס בענף: [. יצירת אבטיפוס של הדרישות (תרשים 8.1), שנקראת לעיתים יצירת אבטיפוס לצורך בירורי גישוש, או לשימוש חד-פעמי. בשיטה זו משתמשיס בתחילת תהליך הפיתוח כדי לברר את הדרישות עם המשתמש. לאחר מכן מניחים בצד את האבטיפוס וכותבים מפרט מלא של הדרישות. תהליך דומה של שימוש באבטיפוס משמש להגדרת ממשקי המשתמש, תוך הסתייעות בעיצובי מסך, תבניות דוחות, וניווטיס במסך ובתפריטיס. כ פיתוח התפתחותי (תרשים 8.2) כרוך ביצירת מודליס של המערכת הנדרשת, שהס בעלי ערך הולך וגדל עבור המשתמשים. כל הספקה התפתחותית (אבולוציונית) מכוונת להיות שלמה בכל הנוגע להבנה הנוכתית של הדרישות. אלא שבהדרגה, תוך כדי רכישת הניסיון, נעשות הדרישות עצמן מפורטות יותר, והתוכנה מפותחת כדי לעמוד בניסוח החדש שלהן. גישה זו ניתן להשוות לברבור המתפתח מתוך דמות הברווזון המכוער שהיה בתחילה. 4 ניהול איכות תוכנה - שחו[וטס 5ח6ח6זוטף6ז ]חשוהקס|6ש6] וג6! 6 68 הזו ט6ז :א 5ת6וח6זוטף6ז 6ח111טס ז56 .1 ]וחק ס!66 601665 56ע1ּחב פזשקס!6ש26] .2 (1006|)5ח 6!ק0ח!5 60051061 פז6קס!6ש6 .3 (₪1006|)5 01 ע801111/ק2006 חס 309156 5ז56 .4 (1006[)5 וח0ז] 5)ה6וח6זנטף6ז 1607311 5ז56ט/5ז6קס!6צ6 .5 6 16| ות6וחקס|6ע66 [החסוזח6שח 60 .6 תדשים 8.1 אבטיפוס של הדרישות :5 6 זסק0696!0 6חב 565 .1 ץז [|בזסטס חס וח6זוטף6ז 1 56גתק 06016 105619 .2 1 56 הק 601616 5ז6קס!66 | .3 5168 161511 806 1 6פבחק 400671 זספע .4 8 1 56בחכ 35 3565חכ [003וו/400 .5-7 006 |[בחו] - . תרשים 8.2 אבטיפוס התפתתותי (אבולוציוני) פרק 8: יצירת אבטיפוס ופיתות יישומים מתיר | 185 פיתוח יישומיק משותף גס בגישת האבטיפוס לנושא הפיתוח עדיין אנו זקוקיס להצגת הדרישות על ידי המשתמש, ודבר זה יכול להוות בעיה. הגישה אל המשתמשים הראשיים כדי לוודא שניתות הדרישות יכסה את הסוגיות החשובות ביותר, היא כשלעצמה נושא לדאגה. גם אס נצליח להשיג מעורבות זו בשלב מוקדם, עלינו לוודא גם שנוכל להמשיך בה. הערכה מתמשכת של המערכת על ידי המשתמשים חיונית להצלחת השימוש ההתפתחותי באבטיפוס. פיתוח יישומים משותף (14 - זחסוחקס!6ש26] ת0:ז08ו!קק4/ זהוס1) התגלה כתשובה מתאימה לצורך במעורבות מוקדמת של משתמשלי המפתח. פיתוח זה מתמקד על השגת מעורבות עמוקה של המשתמשים בתתילת הפרויקט, על ידי כך שהוא קובע פרצ קצר של אינטראקציות מובנות ביותר בין המשתמשים למפתתים. המאפיין המשמעותי ביותר של 10 הוא המנגנון להגדרת יעדים באמצעות מה שמוגדר בדרך כלל בשם סדנאות ‏ 142. לנוהג זה יש מספר חלופות, אך לכולן עיקרון בסיסי אחד והוא, להעסיק את משתמשי המפתח ואת המפתחים בפעילות משותפת, שמכוונת להפקת דרישות עבור הפרויקט, ששני הצדדיס יתחייבו לגביהן. באומרנו ימשתמשי מפתחי ו'מפתחיסי כוונתנו לאותס אנשיס היכוליס לקבל אחריות למערכת ולתהליך העסקי בו היא אמורה לתמוך. משתמשי מפתח הס מי שיכולים לקבל החלטות מחייבות בנוגע למה שהוא קביל, ומסוגליסם לקבל החלטות בדרג ההנהלה במקרים שקיימת תחרות בין משתמשים שוניס. מפתחי המפתח הם אלה שיש להס הידע והסמכות לקבל התחייבות בשם הארגון המְפַתֶח. שאלת ההיתכנות (עוו[ו9ו645) או ישימות של הדרישות מותנית במידה רבה בממדי הזמן המוקצה לפרויקט. רוב הדרישות יכולות להתבצע בפרק זמן כלשהו, אלא שבסביבת 42 עלינו להגביל את עצמנו ליישומים שניתן לספקס במסגרת לוח זמניס קצר, כזה שחופף את אופק התכנון של כל משתמשי המפתח. במקרים רבים, המנגנון המשמש לכך הוא סדנה המונחית על ידי מתאם, שתפקידו לוודא שהסדנה תגיע לסיכום מוצלח, מבלי להיתקע ביריבויות פוליטיות ואישיות ומבלי לפגוש במכשולים שאין לדעת איך לפותרס. כאשר קיימת נוכחות של משתמשי המפתח, יש לסדנה סמכות לקבל התלטות. הסדנה עשויה גם לשקול ויתוריס הדדיים בין הדרישות של המשתמשים השונים, או בין ציפיות שהן רצויות באופן כללי אך אינן מתיישבות זו עס זו. בנוכתחות המפתחיס הראשיים, ניתן לקבל החלטות מחייבות בדבר ההיתכנות. בסוף הסדנה, או בסוף שלב הסדנה, במקרה של סדנאות אחדות, חייבות להתקבל דרישות מוצקות, לפחות עבור החלק הנוכחי של הפרויקט. תרשים 8.3 מציג את התהליך. לוחות הזמנים המוצגיס בתרשים אינס בלתי אופייניים לפרויקטים קטנים עד בינונייס. אלה משתמשיס בטכניקת האבטיפוס כדי להשיג פתרון מערכתי קביל, שלאחר מכן מעובד לצורה המתאימה להפצה בין המשתמשים. החלופה :כולה להתבטא בהארכת השלב האיטרטיבי למשך 90 יום, בהם ייבנה אבטיפוס שיהיה ניתן למסירה בכל אחד מהשלבים. 6 ניהול איכות תוכנה סק קחוהחגוק 1 עזסוו03ק6ז 0856 זסקקנ 5חסו!וח66/1 [6ט16-תקות 6 6ב 1161165 זא 12 | *- -5ע03 10 - > [6 5 חסוזבסו!קקבּ . 065120 6ט11בז6ו1 טס 300 [*- - -9ע03 20 - > תדשיס 8.3 פיתות יישומים משותף - כ44 השימוש בכלי 64585 בסדנאות 140 אינו חיוני לטכניקה זו, אלא שכלים מתאימים יכוליס לפשט ולזרז את שלבי הפיתוח של הפרויקט. כליס הולמיס הס כליס הפועליס כמסד מידע (עזסזופסק6:) עבור מידע תיכון מדרג גבוה, שמאפשר לבנות ולטפל במודליס תפיסתיים של המערכת המוצעת. מתוך מסד המידע של התיכון ניתן לבנות יישומיס, לפעמים תוך שימוש בטכנולוגיית 0455, כדי לחולל תוכנה באופן אוטומטי למחצה. התוצאה שתתקבל משלב כ 1 היא קבוצה מוסכמת ומתועדת של דרישות שתהווה את הבטיס לעבודת הבנייה של האבטיפוס ולמבחני הקבלה הבאים בעקבותיה. פיתות יישוטית להיר - טא בעוד ששיטת פיתוח היישומיס המשותף (כ14) עוסקת במעורבות המוקדמת של המשתמשים, פיתוח היישומים המהיר (כ) עוסק בעידוד המשך שיתוף פעולה של המשתמשים. את 84 אפשר לראות כהרתבה טבעית של 2 1, בה משתמשיס באותו תהליך בסיסי, אלא שלוחות הזמניס מוגבלים בצורה חמורה, כדי לאכוף הספקה מהירה של אבטיפוס. העיקרון הראשי של כגא הוא היכולת לפעול במסגרת אופקי תכנון סביריס למשתמשים. יש קושי בשמירת ההתעניינות ומחויבות המשתמשים ובהשגת גישה נאותה אל משתמשלי מפתח על פני מחזור מורחב של מחזור החיים של הפרויקט. קושי זה הוביל לקיצור מחזור החיים לתקופה שתימצא בתוך תחום המיקוד המיידי של המנהלים המעורבים. בדרך כלל, שישה חודשים נחשבים כגבול הזמן שלאורכו ניתן למתוח התעניינות זו. פרק 8: יצירת אבטיפוס ופיתות יישומים מהיר | 187 הדרישות המוקדמות החלות על 14 חלות גס על 54: רמת מחויבות גבוהה של המשתמשים, ונכונות לחקור את הדרישות בדרך אינטראקטיבית. גם בשיטת 8.0 דרוש בדרך כלל, מתאם שתפקידו לעודד דו-שיח מוקדס קריטי, ולנהל את האינטראקציה בין משתמשים למפתחים. עס זאת, בשיטת 0 84 מוצבות תביעות שונות לצוות המפתחיס. לוחות הזמניס הלחוציס הקשורים בפרויקטים מסוג 84 מחייביס ניהול קפדני ביותר. מנהלי פרויקטים חייביס להיות מסוגליס : >= להעריך בדייקנות את לוחות הזמנים ; >= להעריך בדייקנות את הדרישות למשאביס ; >= לבקר את ביצוע העבודה במסגרת הפרמטריס המשוערים, כדי לקיים את האמון והמחויבות של המשתמשים. צוות לפיתוח יישומיפ מלהיר צוות הפיתוח בשיטת 8/2 חייב להיות בעל בסיס רחב, בעל הבנה יסודית גס בכלי הפיתוח וגס בסביבת המשתמש, ובעל כישורים בין אישייסם מעבר למקובל. צוות זה צריך לכלול (ארתור, 1992): * מומחה לכלי פיתוח, כדי לוודא את השימוש הטוב ביותר בקבוצת הכליס ; * מומחה לעסקים, כדי לוודא שהיישומים ישקפו ערכים עסקיים ; * משלב יישומים, כדי לוודא שהיישומיס תואמיס זה לזה במסגרת האסטרטגיה הכוללת ; * מומחה לממשק אדס/מחשב, כדי לוודא עקביות במסכיס ובתיבות הדו-שית; * ספרן, לצורך הבקרה על המוצרים המוגמרים ; * פותר בעיות, לצורך זיהוי פתרונות המחשוב הטובים ביותר; * מומחה כללי, כדי לוודא שלא ימציאו את הגלגל פעמיס רבות מדי; + מומחה לבדיקות, לוודא שהמוצרים המוגמריס יהיו ראוייסם ומוכניס לשימוש. לא כל התפקידים האלה מחייבים מעורבות ישירה בכל פרויקט וגם אינס מחייביס אדס נפרד, אך כולס תורמים למתודולוגיה הכוללת של 0 ג 5. המשתמשים זקוקים למינימוס מובטח של מוצריס מוגמרים, כדי לעודדם לקבל על עצמס את הסיכון שביציאה לפרויקט כה דינמי. אפילו במסגרת של כ ג1, הצבת דרישות יציבות שאנו בטוחיס בהשגתן, בפרויקט של לוח זמניס קצר, אין בה משוס וודאות מלאה. התשובה היא בקביעת פרויקטי 842 בתוך האסטרטגיה שמקיפה את המבט הרחב ביותר האפשרי, של צורכי מערכת המידע. אסטרטגיה רחבה זו מעודדת פיתות ארכיטקטורת מידע כוללת, בה ניתן להגדיר פרויקטים יחידים של מערכות מידע. במסגרת כזאת ניתן להקצות יעדים ספציפיים לפרויקטי 84 נפרדים. תוך כדי 8 נלהול איכות תוכנה התקדמות הפיתוח, ניתן להתבונן בפיגורים בהספקה בתוך ההקשר הרחב יותר, ובמקרה הצורך, להפנות מקרים אלה לפרויקטים אחרים שבתוך המסגרת, כדי לצמצם , את הפגיעה במשתמשים. אפילו כך, אמון המשתמשים קשור קשר הדוק להצלחה, והספקת קטלוג שלס של הדרישות המוסכמות הוא למעשה התוצאה הקבילה היחידה. יֶירת אסטרטגיה התפתחותית דבר אינו חשוב יותר בכל אחד מענפי פיתוח התוכנה מאשר קבוצת *עדיס ברורה, מכומתת ובנויה לפי סדר עדיפויות. זה נכון במיוחד כאשר שוקלים שימוש באבטיפוס כבשיטת פיתוח, משוס שצוותיס העוסקים ביצירת אבטיפוס זקוקיס למידה מסוימת של אוטונומיה בקבלת החלטות יומיומיות, העוסקות בכיוון בו יתפתח המודל שלהם. טוס גילב (1988 ,פ!01) הצביע על כך שבאבטיפוס אנו מבקשים לצעוד את הצעד הבא הטוב ביותר שאפשרי מהמקום בו אנו נמצאים בפיתוח, וכי מה שנוכל להשיג בצעד זה יוגבל על ידי זמן ומשאבים. נעצור כאשר יהיה עלינו לעצור, ונרצה להפיק את התוצאות הטובות ביותר שנוכל להשיג במסגרת הזמן והמשאבים הזמינים. כדי להגדיל את היתרונות, אנו זקוקיס לחופש בקבלת החלטות תוך כדי התקדמות. והתבססות על מה שהושג עד כה. חפט 005 בולוציוגית: תרשים 8.4 האסטרטניה התתפתחותית /א . או תהיה מקובלת על מנהלי פרויקטיס - הפרויקט. אך כך נמצא את עצמנו תהיה לנו נקודת התייחסות חיצונית גמישות בקבלת החלטות יפה מאוד, ובווד המתקשיס לתכנן ולחזות את ההתקדמות בת בתוך מעגליס ההולכים ומצטמצמים, אס לא נפוס ופיתוח יישומי 8 וצור אבט מים מחור = 189 כלשהי. נקודת ההתייחסות היחידה שראויה למעקב היא ההגדרה של הדבר שהמשתמשיסם רוציס להפיק מכל זאת במונחיס תועלתייס. תרשיס 8.4 מדגיס כיצד הרכיביס של האסטרטגיה ההתפתחותית קשוריס זה לזה. שיסם לב שלא השתמשנו כאן במילה 'דרישות'; למילה זו יש משמעויות נלוות מסוימות, ביניהן ההנחה שאלה שניסחו את הדרישות ידעו באמת מה הס רוציס. מצב זה הוא כה נדיר, עד שקשה להבין מדוע אנשיס מתעקשיס לנסות ולהעלות על הכתב דרישות מפורטות של המערכת, שלא לדבר על תכנון וניהול פרויקט גדול להשגת דרישות אלו. עלינו להתפשר על משהו מציאותי יותר, אם כי גם הוא אינו קל להגדרה, והכוונה היא ליעדיס עסקיים. כאשר אנו יכוליס לראות פחות או יותר לאן אנו הולכיס, על ידי הגדרת היתרונות העסקיים המבוקשים, אנו מוגניס לפתות מההיסתפות הגורלית המוליכה אותנו בכיוון ההפוך לגמרי. אם נוכל לתאר את היעדיס העסקייס שלנו במונחים של מציני ההצלחה הקריטיים, כפי שנדונו בפרק 3, נקבל בסיס לתכנון לטווח ארוך. טווח ארוך בהקשר הזה יכול להיות ארוך יותר מאשר הפרויקט בו אנו דניס באותה עת. אדרבא, ימצייני ההצלחה הקריטיים' (05[1 - 101080018 5006655 |8סוזוזכ)) יספקו כיוון ברור להתפתחות לטווח ארוך יותר, שהפרויקט הנוכחי יתרוס לה, או לספק לה קו בסיס. השלב הבא יזהה יגורמי ביצוע עיקריים' (671 - 801015] 6סחגוחזס)ז6 ע6א) עבור המערכת. גורמי +?% הס תכונה של המערכת, הניתנת למדידה, ותורמת לאחד או לאחדים ממצביעי ההצלתה הקריטייס (051). = מאפשריס למפתחי המערכת להבין מה מצפים מהם, כך, שהשגתם תאשר שאנו אכן מתקדמיס לעבר השגת מציני ההצלחה הקריטייס. לדוגמה, עבור חברה לשיווק בדיוור ישיר שמקבלת 600 הזמנות ביוס, מציין הצלחה יתבטא בכך שהמערכת החדשה תביא לשיפור של 10 אחוז ביכולתה הנוכחית. במצב הקיים, מועסקים ארבעה פקידי קבלת הזמנות, ניתוח התהליך מגלה ש-15 אחוז מההזמנות המתקבלות אינו מעובד מסיבה זו או אחרת. המערכת החדשה תאפשר לשישה איש לעבוד בו-זמנית. זה מרמז על שני גורמי ביצוע עיקריים (:קא): [. המערכת צריכה להיות מסוגלת לעבד עד 660 הזמנות ליוס, כשלרשותה עד שישה עובדים. 2. המערכת צריכה להיות מסוגלת לבצע קליטת הזמנות בקצב של 759 הזמנות ליוס (660 ועוד 15 אחוז), כשלרשותה עד שישה עובדיס. דבר אינו חדש. בפרק 3 כבר הצגנו דרך בה נוכל להשתמש בגישה זו באמצעות טבלאות קווי פעילות (20165] 686זו!), כדי לעקוב אחר כל התפתחות. עס זאת, מן הראוי לשוב ולציין כאן, כי גישה זו תקפה לגבי פיתוח המבוסס על אבטיפוס. למעשה, קבוצת גורמי ביצוע עיקרייס הערוכה בעדיפויות, היא בסיס חיוני לדיון עס המשתמשיס בעניין דרישות ספציפיות. בשלביס המוקדמיס של פרויקט המובנה על אבטיפוס, בעת שאנו מנסים להרכיב תוכנית כוללת ברת-ביצוע, עלינו לדון ביעדים קצרי טוות, בקריטריוניס להערכת אבטיפוס מוגמר, וביויתוריסי שעלינו לעשות כדי להשיג את היעדיס החשוביס יותר. 0 ניהול איכות תוכנה תוכנית הפרויקסט ההתחלתית תעסוק ביעדים הכלליים ותמפה קבוצה ארעית של שלביס ביצירת אבטיפוס, כל שלב והמטרה הספציפית שלו. אס הכל יתנהל כשורה, הס יספקו את גורמי הביצוע העיקריים. במקרה שהפרויקט הנוכחי הוא חלק מאסטרטגיה התפתחותית לטווח ארוך יותר, תצטרך התוכנית לזהות גם את התרומה של הפרויקט, וכיצד אפשר יהיה להעריכה מול התוכנית האסטרטגית הכוללת. בשלב זה, ניתוח יסודי מאוד של הדבריס האפשריים ושל הדבריס שהסם ללא ספק מעבר ליכולתנו, יסייע לנו לוודא אס הציפיות מציאותיות ולהגדיל את הסיכוייס שהפרויקט יספק את גורמי הביצוע העיקריים. תוכנית זו חייבת להיסקר בזהירות ולקבל את הסכמת המשתמשים לפני ביצוע עבודת תכנון או פיתוח כלשהי. תוכנית כללית מוסכמת היא נקודת המוצא לתכנון מפורט יותר. משוס שאנו יודעיס שנזדקק לגמישות כדי שנוכל להתאימה תוך כדי פעולה, נגביל את עצמנו ונתכנן בפירוט את השלב הבא בלבד. התוכנית של השלב המסויס תתבסס על יעדיו שהוגדרו בתוכנית הכוללת, תפתח אסטרטגיה ליצירת אבטיפוס שתהיה מיועדת להשיג יעדיס אלה, ותענה על המטרות המכומתות שיהוו את הבסיס להערכה בסוף השלב. הערכת השלב בסופו משמשת להחלטה אם אמנסם הושגו יעדי השלב. במקרה ולא, תעמודנה בפנינו שלוש אפשרויות : + הגדלת יעדי השלב הבא, כדי להשליס כל חסר שנוצר בשלב הנוכחי; * השלמה עס החסר, ותיכון השלב הבא כדי שיחזירנו למסלול המקורי, או קרוב אליו ככל האפשר ; * ויהוי ההשפעה שיש לתסר מהיעדים המקורייס, והחלטה על תיקון היעדים הכוללים. חסוזסחט] סק * זגו [אחו] ו ו 5 856 0 8 הירוסו הור דיחי ב חסוובט!גע -77-777ד7-י-------------------| 3 04565] חסוזוו!60 600061 5 סז או תסוובט|4צ 1 46 = 1 תסווצט|4 1( 0203 1 בח 5אסטטוהוך 1 נין .4 וש 6חוך תרשיס 8.5 תכנון התפתחותי (אבולוצינני) פרק 8: יצירת אבטיפוס ופיתוח יישומים מהיר | 191 כל שלב בתהליך יכול לעצב מחדש את האסטרטגיה ההתפתחותית הכוללת, את הפרויקט הנוכחי, או את השלב הבא (תרשים 8.5). לא ניתן להטיל ספק בחשיבות שבקביעת מטרה ברורה וארוכת טווח. תכנון פרויקט כשיטת פיתוח יישומיס מהיר כיצד ניגש לשאלת התכנון לקראת 842! התשובה הפשוטה היא שתוכניות חייבות להתפתח יחד עס התוכנה. הדבר יקרה לא על ידי התעלמות משאלות מפתח, אלא על ידי קבלת החלטות תכנון ארעיות ומוקדמות שינחו את הפיתוח הכולל. כמו כן, עלינו לאפשר לפרטים לצוף ולעלות ככל שהפיתוח מתקדס. תכנון ראשוני המהלך הראשון של התכנון צריך להיות בעל טווח רחב אך לא מפורט ביותר, ועס זאת ממוקד על יעדיס מוגדריס בבהירות, גס אס יש עליהס הסכמה ארעית בלבד. התוכנית הראשונה (תרשיס 8.6) תבקש לזהות מה מספר השלבים ההתפתחותיים הנדרש, מה צריך כל אחד מהס לנסות להשיג, וכיצד יוערך כל אחד מהס בשעת הסיוס שלו. שבד * וטו )טח חטוזט!קוחט) 3 טאו חק חטוזט!|קוחט) 2 שפגחץ שַחוחחג[ק 2 טפגהץ חטוזבט]בם 1 שצהחץ זאטך 1 שפגחהץ טוט | 6פההק ' % ' ----777-7-7-----4% צחג!ק טפההק שו ₪ = ששו כ ₪ שש 5 שי = שושושום ₪ = = %יי--דדדדדדדדרדדההד---- שוחוך 15 בי 1 ן 3 1 5 8צ08 5 צָב צ03 62% ! / תרשים 8.6 תכנון ראשוני לפרויקט 4 2 ניהול איכות תוכנה לתכנון האיכות יש חשיבות מיוחדת, כדי שההתקדמות בשלבים הלא-מובניס יחסית (שמשתמשיס בדרך כלל באבטיפוס) תוכל להתבצע ללא ניטור יתר וללא הסיכון שבהפקת מוצרים מוגמריס בעלי פגמיס חמוריס. תוכנית האיכות צריכה להתייחס למרכיביס אלה : > תקניס שיש לאמ; >= תבנית ותוכן המוצריס המוגמרים ; > אחריות לביצוע ההערכה; *= שיטות וטכניקות בהן יש להשתמש בפיתוח; > ניהול פעילויות יצירת האבטיפוס. חלק גדול של ניטור האיכות יצטרך להעשות בסוף כל שלב פיתוח, במקביל להערכה העסקית של אותו שלב. התכנון מהווה חלק בלתי נפרד של תהליך ההערכה, כדי שכל שלב יוכל להיות מתוכנן מקו הבסיס של הישגי השלב או השלבים הקודמים. יש צורך גס לסקור את התוכנית הכוללת ואת היעדיס בסוף כל שלב. גקרת תהליך פיתוח יישומיפ מהיר אף אחת מהטכניקות שתוארו אינה חדשה ואינה כזאת שטרם נוסתה, ובכולן נעשה שימוש לא נכון בעבר. בבניית אבטיפוס הצליחו לעיתיס ללכוד את דמיון המשתמשים עד שנמצאו גס לקוחות שביקשו לספקם להם כמוצר, ולאחר מכן גילו שהפונקציונליות החלקלקה של האבטיפוס אינה יכולה לעמוד בטיפול האכזרי של השימוש הרגיל. היו גס מקריס של הספקת אבטיפוס עם יותר מדי פוקציונליות ופחות מדי איכות. הדבר נובע מכך שתהליך יצירת האבטיפוס התמקד אך ורק על הוספת פונקציות חדשות, על חשבון הבדיקה שהיתה אמורה לוודא עוד לפני ההספקה הסופית, שהפונקציות שהתקבלו כבר, עמידות ואמינות. בכל אחד ממקרים אלה קייס רצון כן לספק במהירות מוצר שיסב עונג ללקוח, ואמנס את הרצון הזה יש לעודד. אלא שהבעיה טמונה באמצעיס בהם מטפליס במטרה זו. בפועל, לעיתיס תכופות מדי, תרגיל האבטיפוס איגו תחת שליטה, והעוסקים בו מורשיס לספק את מה שנראה להם לראוי. מדוע! הסיבות האפשריות רבות, כגון: * לא הוגדרו יעדיס ברוריס; * העוסקיס ביצירת האבטיפוס אינס מביניס את הסביבה העסקית; * המשתמשיס אינס משתתפיס בתהליך יצירת האבטיפוס; * העוסקיס ביצירת האבטיפוס אינס מדוותיס למשתמשים על תוצאות ביניים; * העוסקים ביצירת האבטיפוס נלהביס ומנסים להשיג יותר מדי בזמן שלרשותס; * רק קומץ אנשיס מבין את הכליס המשמשיסם ליצירת אבטיפוס. פרק 8: יצירת אבטיפוס ופיתות יישומים מהיר ‏ 193 במישרין או בעקיפין, כל הגורמים האלה, עניינס בבקרת התהליך ליצירת האבטיפוס. בקרה זו היא הסוגיה החמורה ביותר בה יש לטפל לפני שאפשר יהיה לנצל את שיטות השימוש באבטיפוס. יצירת תוכנית מדורגת, מלווה ביעדיס חד-משמעיים עבור כל שלב, די בה כדי לספק את המסגרת לבקרה אפקטיבית. במשך כל שלב, צריך לבקר את הכנת האבטיפוס על בסיס יומיומי שוטף, כדי לנסות להשיג את היעדיס של כל אחד מהשלביס. זוהי בעיה סבוכה. כל ניסיון לבקרת תהליך שנועד להיות גמיש מחד, ומאידך נותן חופש לחקור מספר רב ככל האפשר של אפשרויות פעולה לעוסקיס בתהליך, מסתכן בהתנקת הגמישות. לעומת זאת, כאשר מפקידיס את יצירת האבטיפוס בשלמותה בידי הנחשבים לימומחיםי לזה, רביס הסיכויים שהפעולה תסטה מהיעדים הרצויים, ותגרוס לבזבוז זמן ומשאביס בחיפוש עקר אחר הפתרון הלא-נכון. כפי שקורה לעיתים כה תכופות, התשובה יכולה להיות במציאת פשרה. הבקרה תתאפשר כאשר אופק הזמן קצר ביותר. כך ניתן להניח לעוסקיס בנושא האבטיפוס לערוך בדיקות ללא פיקוח או השגחה, במסגרת הפרמטריס שנקבעו על ידי התוכנית המיידית. טכניקה זו ידועה כשימוש ביתיבות זמן' (פחואסטסותוז). גישת תיבות זמן לוקחת שלב מתוך התוכנית ומפצלת אותו לקטעי עבודה קטנים יותר, לתיבות זמן. בכל תיבה צריך להיות מידה מספקת של אוטונומיה וניתן לזהות בה מוצר מוגמר כלשהו. לעוסקיס ביצירת אבטיפוס ניתנת תקופת זמן קבועה, תיבת זמן, בה עליהס להפיק את המוצר הרצוי. עם זאת, הס נדרשים להפסיק לעבוד בסוף תיבת הזמן מבלי להתחשב בתוצאות מאמציהס. בסיום כל תיבת זמן מתבצעת הערכה של ההישגיס ומתקבלת החלטה בדבר תיבת הזמן הבאה. ב אסטטוחוך זו >+--- הר 6 ו ]א חסוצז6/ 6חו6 ה 6 6 5 + חו פחסנוגזסוו א 6ופטוט וו ]חטוח6!קוח] ]א חסופזט/ ]א ח0פז6 06 ץזס!וסוש תדשים 8.7 גישת תיבת הזמן 4 ניהול איכות תוכנה השימוש בתיבות זמן (תרשיס 8.7) הוא בתמציתו רמת תכנון נוספת. כעת יש לנו החל רצף של תוכניות ברמות גדלות והולכות של פירוט, מהיעדיס ההתפתחותייס שלטווח ארוך, ועד לרמה המאפשרת לעוסקים באבטיפוס לפעול בתוך מסגרת מוגדרת היטב, כדי להשיג מוצר מוגמר בתקופת זמן נתונה. למרות שבתיאור זה יש הצגה פשוטה של הנושא, והוא משמיט מספר רב של קשיים מעשיים, יש בו עס זאת, גילוס של העיקרון הבסיסי הבא לוודא שכל עבודה שמאושרת בתוך הפרויקט, תתרוס במופגן ליעדים הכוללים. מבחינה זו לפחות, השימוש באבטיפוס אינו שונה מהגישות המובנות המסורתיות יותר. (יהול איכות בסגנון הגישה החופשית היחסית הזו, איזה מקום נותר לבקרת איכות (עזווגטף 1 או לאבטחת איכות (06ח8זט855 עזו[ג4טוף): הגישות המסורתיות של סקריס (פצוס1צ6ז) ושל בדיקות מובנות אינס נראיס מתאימים לסגנון זה. לא סביר להניח שתיכון אבטיפוס יפיק אוסף של תוכניות נפרדות שאפשר לנסותן כל אחת בפני עצמה ולשלבן יחד לאחר מכן. גס הכללתן בתהליך של סקרי תיכון, כדי שישמשו כאבני דרך לצורך אישור המוצרים, אינה נראית מתאימה. יש להביא בחשבון שגישת האבטיפוס מלווה בהכרח בסיכונים. בסביבת פיתוח אשר נועדה במפורש להימנע ממגבלות הגישה המובנית, אי טיפול בבעיות האיכות יהיה בלתי אחראי וגסם לא-תכס. דרושה גישה חדשנית, שתהלוס את תרבות וסגנון השימוש באבטיפוס, ועס זאת, תספק ניהול סיכוניס אפקטיבי. תוכנית איכות עבור פרויקט שיטת פיתוח יישומים מהיר (40א), מחייבת דגשיס מיוחדיס ואמורה לכסות עשר נקודות כמפורט להלן: ויו ורוו ו יוור עשר נקודות עבור תוכנית איכות ל-40א 1. תחומי אחריות עבור: הגדרת מדדיס לקבלה; הגדרת תיבות זמן ; אישור מוצריס מוגמריס בסוף שלביס; 0 0 0 0 בניית אבטיפוס ; 0 בדיקות אבטיפוס ; 0 ניהול הספרייה; 0 ניהול הכליס. 2 קריטריוניס לקבלה. תוכנית בדיקות קבלה. 4. תוכניות בדיקות שלב. פרק 8: יצירת אבטיפוס ופיתוח יישומים מהיר | 195 הערכת השלב ואסטרטגיית הסקירה. מנגנון הערכה. ניהול התצורה, ובמיוחד בקרת שינוייס. 5 6 7 8 דיווח בעיות. 9 כלים שיש להשתמש בהס. 0 1. סביבת הפיתוח. סוכל ורוו ויו קורי ור ור ריר אחד האלמנטיס החשובים של גישת האיכות הוא יצירת תקניס מקיפים עבור עבודה באבטיפוס. העוסקיםס בעבודה זו צריכים לדעת כיצד צריכים להיראות מוצריס מוגמרים שלביים ואיזה תיעוד יש להפיק בהם. הם גם יצטרכו לדעת לפי איזה כללי תיכון עליהם לפעול ומה צריכה להיות תבנית הקוד. סוגיית איכות חשובה נוספת היא שאלת כמות הבדיקות שצריכה להתבצע על כל מוצר. יש להגדיר אסטרטגיית בדיקות שתכלול את: מפתתחי האבטיפוס שבודקיס את המוצרים שהם מייצרים, המשתמשים שבודקים את המוצריס בשלב מתאים, ואת בדיקות האיכות שיתבצעו בשלבי מפתח של הפרויקט. כל פעילות הבדיקות צריכה להתנהל במשך שלבי ההערכה, כאשר משהיס את הפעילות באבטיפוס. לסקרים שמור עדיין תפקיד בפיתוח של אבטיפוס. בדיקות איכות הבוחנות את ההיצמדות לתקנים מסייעות לוודא עקביות ושמירה על גישה ממושמעת. סקרי איכות חייבים להוות חלק מההערכה המתבצעת בסיוס כל שלב, כדי להקנות אמון ביציבות התיכון, המוצרים ובכיוון העסקי הכללי. התחוס הקריטי מכולס בפיתוח ההתפתחותי הוא תחוסם בקרת השינויים. ניהול התצורה אינו רק דיסציפלינה חיונית, יש הכרח ליישמו בצורה שתאפשר לבצע שינויים במהירות ובקלות, ועם זאת גס תחת בקרה רשמית. פיתוח שיטות אלו ויישומן האפקטיבי במסגרת כל פרויקט, חייבים למצוא את ביטויס המלא בתוכנית האיכות, כדי לוודא שכל המעורב בפרויקט יבין באופן ברור את המנגנוניס בהם יש להשתמש. האפ פיתות יישוסיק להיר (כט 6) הוא עוד אופנה חולפת (סא 0) רעיונות לשיטות פיתוח חדשות באים וחולפים. רק מעטיס שורדים לזמן רב. השימוש באבטיפוס נמצא כבר זמן רב בשטח, ולא נראה שהוא עומד להיעלם, ולו רק משוס שהוא מוצא חן בעיני אלה הרוצים להאיץ את הספקת התוכנה. עס זאת, לאבטיפוס יש היסטוריה רבת תהפוכות והמאבק לזכייה בהכרה עדיין נמשך. פיתוח יישומים מהיר ופיתוח יישומים משותף (840 ו-140, בהתאמה) מייצגיס תדמית קבילה של השימוש באבטיפוס. כלומר, אלו הן גישות מובנות להספקה מהירה, שמכילות את הניהול והבקרה הדרושים לאבטחת אמון מסויס בתוצאה. 6 ניהול איכות תוכנת ה מ ה מהן סוגיות המפתח שהועלו על ידי .ה ו-סג1! עשר סוגיות איכות לפיתוח ו ו ו [. | דע לאן אתה הולך פעל תמיד בתוך אסטרטגיה ברורה וכוללת בעלת ,עְדים מוגדרים. 2 דאג לכך שהפרויקטים יהיו קצרים הישאר בתחוס אופק 'חתכגוו של המשתמשים שלד, פחות משישה חודשים. 3 בחר בקפדנות את הצוות ליצירת אבטיפוס דרושיס להם כישוריסם טובים ביחסים בין-אישיים, כישורים טכניים כ והבנה טובה בנושאיס עסקיים. אידיאלית, הם אמוריס להיות מסוגליס לו פני המים, אבל יהיה עליך להתפשר בתחום הזה. 4 עקוב מקרוב אחר פעולת יצירת האבטיפוס קבע יעדיס ברוריס עבור כל שלב, דאג לכך שהשלביס יהיו קצרים, והש שלב בזמן. 5 תכנן תוך כדי ביצוע דאג שהתוכנית תהיה בבדיקה כל הזמן, והיה מוכן לתכן מחדש את כל הפר 6. אבחן ופתור מראש את כל בעיות האיכות וודא שיוחלט מראש מה לעשות בכל הבעיות הקשות עוד לפני תחילת ה הקצה תחומי אחריות לכל ההחלטות האמורות להתקבל במשך הפרויקט. 77 הנח להנהלת הפרויקט לנהל מנהלי פרויקטיסם זקוקים לסמכויות כדי שיוכלו לשלוט בפעילויות. אס נו שהס אינס ברמה הדרושה, הדרך אותם, או הבא מנהליס חדשים. 8 דאג לכך שבדיקות הקבלה יהיו ברשותך לפני שתתחיל בעבודה אתה חייב לדעת אס כל אבטיפוס בפרויקט מתקדס בכיוון הנכון. תוכל לד! על ידי השוואה למודל המוצר הסופי שברשותך, כלומר לבדיקות הקבלה. 9 בחר בכלים הנכונים אס אתה משתמש בכלים, עליהס להיות הכליס הנכונים ולהימצא תחה מתאימה. צוות האבטיפוס חייב לדעת כיצד להשתמש בהס ביעילות. 0. וודא שההנהלה שלך נמצאת 'בראש אחד' אתך אס אין לך את המחויבות של ההנהלה, אתה מסתכן בהפסקת הפרויקט שהדברים יתנהלו שלא לפי התוכנית, וזה דבר צפוי בהחלט. ה יר השימוש באבטיפוס למן ההתחלה, אינו הדרך היחידה לבנייה מהירה של 5' שימוש חוזר במה שבנינו לפני כן, מציע נתיב פורה עוד יותר ובטוח יחסית, לכיוון פיתוח יישומים מהיר (כ /). זהו התחום של פיתוח מוכוון-עצמיס. פרק 8: נצגרֶת אבטיפול ופיתוח יישומיס מהיל קוור וי פכק 9 פיתוח מוכוון-עצמים מכוא מה כל הרעש הזה בנוגע לשיטות מוכוונות-עצמים (060ח6וז0-+66[פ0 - אסס 35)? האם השיטות המובנות אינן פועלות יותר, או אולי גילינו פתאום את סוד הגישה אל כל מערכות התוכנה שהובטחו לנו תמיד, אך מעולם לא נמסרו לנו? אדם מציאותי יודע שאין אחיזה לטענות ממין זה. יש סיבות רבות לכך ששיטות מוכוונות-עצמים ראויות לתשומת לב מסוימת, אך יש סיבה אחת מכרעת שבגינה עלינו לשקול מעבר לשיטה מוכוונת-עצמים. שיטה זו מביאה את המתרחש בנבכי המחשב קצת קרוב יותר אל המתרחש בעולם המציאות, כפי שאנו מבינים אותו. כל דבר שגורם למחשבים ולתוכנה שיהיו מוּבָנים יותר למשתמשיהם ראוי לעיון רציני, גם אם הוא גורר בעקבותיו מספר בעיות. מהו עצפ התשובה מותנית במי שהנן אם אתה מפתת תוכנה, רבים הסיכויים שהעצם (אובייקט) ייראה לך כדרך הסתכלות בתוכניות המאגדות את הנתונים והתהליכים הקשורים להם במבנה אחד. הרעיונות הבסיסייס הס הרחבה טבעית של גישות מוקדמות יותר שהתמקדו במבני נתוניס, או במבני תהליכיס. הדבר היה בגדר חזון עד שפותחו שפות יתכנות מוכוון-עצמיס' (?00 - פחוממותגזקסז? 166ת16ז0(601-0) שאיפשרו לבנות תוכניות ומערכות תוכנה הפועלות על פי מודל תכנות חדש זה ועל פי נהלי "עיצוב מוכוון-עצמים' (ק00 - 26518 160ת020(601-02716)). לעומת זאת, אס אתה משתמש, סביר שתרגיש יותר בנוח בתפיסה שהעצמים הם דרך למידול העולם המציאותי. כלומר, מודל הלוכד את המאפייניס הבלתי-משתנים של הדברים בהסם אנו מעונייניס ואת יחסי הגומלין הדינמייס שביניהס. האם יש מִתְאָס בין שתי השקפות אלו! אין ספק בכך. השקפה מוכוונת-עצמיס על העולס מספקת דרך לניתוח מצביס והכרה בהזדמנויות לניצול עיצוב מוכוון-עצמים (002) ותכנות מוכוון-עצמיס (002). 'ניתוח מוכוון-עצמים' (160ת16ז0[601-0כ) 4 - 515ע1את/4/) משלים באופן טבעי את הטכניקות האחרות. פרק 9: פיתוח מוכוון-עצמיס | 199 טכניקות מוכוונות-העצמיס הולכות ונעשות שכיחות בענף התכנות, אך טרס הגענו אל השלב בו תוכלנה טכניקות אלו להיחשב כחלופה מלאה לגישות המבניות בענף זה. שיטות וטכניקות שנועדו לאפשר את השימוש והתמיכה בגישה המובנית לנושא פיתוח התוכנה, היו זמינות במשך עשרות שנים, אך גישה זו טרס הצליחה לחלחל ולהגיע אל כל תעשיית התוכנה. מעטים הסיכויים שבטוות הקצר שיטות מוכוונות-העצמיס תצלחנה להתבסס היטב, למרות היותן יהזינוק הגדול קדימהי כטענת חסידיהן. לרתיעה טבעית זו נוסף הקרע הקייס עדיין בין כמה מתומכי גישת תכנות מוכוון- עצמים (?00), שרואיסם בה בעיקר, או רק, שיטה להשגת מאפיינים מסוימים בתוכניותיהס; לבין המספר הגדל והולך של משתמשיס עסקיים שרואיס את הניתות מוכוון-העצמיס (002/4) ועיצוב מוכוון-העצמיס (00) כדרך למידול עולס המציאותי, אך יודעיס מעט מאוד, או לא כלום, על תכנות מוכוון-עצמים (?00), או על השיטות הנלוות לגישה זו. נראה שיש הצדקה להנחה ששיטות מוכוונות-העצמים יכולות לספק מעבר יללא תפריסי מהעולס המציאותי אל יישוס תוכנה בעלת מאפייני איכות חיובייס, אלא שעד עתה היתה רק התקדמות מעטה בהמחשת פוטנציאל זה. = -------------------]--- -3---------- מספר מונחים שכיחים בשימוש בעולם מוכוון-העצמים * עצם 00[600). הפשטה של ישות עסקית בעולם המציאותי, או של יישות טכנית. * עצם עסקי (00[600 51₪655ש0). הפשטה של ישות עסקית, כגון לקות או הזמנה. * עצס טכני (00[601 |168חו60)). הפשטה של ישות טכנית מהרמה הנמוכה, כגון רשימה או שולחן. * מחלקה (01855). אוסף של עצמים בעלי תכונות משותפות. * שיטה (₪861100ז). פעולה המתבצעת על ידי עצם או על העצס. * הודעה/מסר (655886וח). פרוטוקול המורכב משיטה והפנייה לעצס. אינטראקציה בין עצמיס מתקיימת על ידי העברת הודעות שדורשות מעצמיס אחרים להפעיל את שיטותיהס. * הסתרת מידע (פַחו6ו חסוז8וחזס/חו). הפרדת הייצוג של עצס או של מחלקה, מפרטים הממשק לציבור. * הפשטה (ח0ו)8051:80). סילוק הפרטים הלא-חיוניים מהמודלים, כגון סילוק המפרטים, כדי להגביר את היכולת להבינס. * הצמדה דינמית (פַתו0חול סומ8תץ4). קישור בין מזהה לעצם בזמן הרצת המערכת. * הורשה (06ה8)וז6ו]ח!). מערכת קשרים בין שתי מחלקות עצמים, שבה אחת המחלקות לוקחת את כל התכונות הרלבנטיות של האחרת. >= בסיס נתונים מוכוון-עצמים (00228). בסיס נתוניסם המבוסס על מודל נתוניס בו מיוצגת כל ישות של עולס המציאות על ידי עצס של מודל נתוניס יחיד. > ניתוח מוכוון-עצמים (/00). שיטת ניתוח המתמקדת במידול ישויות של עולס המציאות כעצמים בעלי מבנה ומספקיס שירותים. 0 ניהול איכות תוכנה 4 | 4 ₪ עיצוב מוכוון-עצמים (002). שיטת עיצוב למידול מערכות תוכנה כאוסף של עצמיס משתפי פעולה. = תכנות מוכוון-עצמים (0002). שיטת פיתוח המבוססת על עצמים שמופעלים על ידי כל חלק של המערכת, ולא על פונקציות. ------------7---000000/מ//-/-/-/-/-000-0---------- ה | מטרת הטיפול בשיטות האיכות בספר זה היא לספק בסיס לדיוניס בסוגיות האיכות. אין הוא מכוון לשמש כחומר הדרכה, אם כי הוא דן במספר היבטים של הגישה בפירוט יחסי, כדי שיוכל להצביע על יתרונות וחסרונות הגישה מנקודת ראות של איכות התוכנה. חשוב מזה, עלינו לדון בסוגיות המעשיות בהן עלינו לעסוק במהלך פרויקט המבוסס על גישת פיתוח מוכוונת-עצמים. טכניקות מוכוונות-העצמיס העיקריות מוסברות בתתילה, תוך התייחסות לרעיון המקובל של מודל עצם ([086ו ז60[פ0). מהו מודל עצפ למודל העצם ([066וח +60(טס) אמורות להיות שלוש תכונות ברורות: 1. עליו להוות הפשטה טובה של העצם שהוא מייצג. כלומר, עליו להיות פשוט, אך בלי להשמיט פרט חיוני כלשהו. 2. עליו להיות ניתן ליישוס בסביבת החומרה והתוכנה שתשמשנה לבניית המערכת שהוא מייצג חלק ממנה. 3 עליו לספק תמונה ברורה וקריאה של העצס המיועד ושל הדרך בה יוכלו משתמשי העצס לתפעלו. אזק זג קְגּות [₪6 ] בוב בו 6 00] [6סות שד (פ) א%זגק 6וסו 6 6 (4) תרשים 7.1 מודכ עצם שכ חניון (₪ התממון ; (5ו המודק פדק 2: פיתות מוכוון-עצמים 201 את הרעיון של מודל עצם קל יותר לתאר על ידי התייחסות לתמונה כדוגמת זו שבתרשים 9.1, שמייצגת הפשטה פשוטה של מגרש חנייה, שבו כלי רכב מכל סוג שהוא, יכוליס לחנות בכל עת. מודל העצס שבתרשים 9.1 מייצג עצס יחיד. למידול בעיות אמת, אנו זקוקיס למודלים כאלה המייצגיס אוספי עצמים ואינטראקציות שביניהם, כדוגמת זה שמוצג בתרשיס 2, בו הוחלף חניון כללי בחניונים נפרדיס למכוניות, לאוטובוסיס ולמשאיות. תרשים 2 מראה את יחסי הגומלין הדרושיס בין העצמים כדי ליצור מודל של ההתנהגות בה אנו מעונייניס. התרשים איגו מראה את פרטי הממשק של כל עצס שעשוי להוות את השלב הבא של פיתוח המודל. כ |( ך4-[ ₪ - 7 תרשים 9.2 מודל עצם של מסוף מעבורת ניתוח מוכוון-עפמיפ מטרת ניתוח מוכוון-עצמים (004) היא ליצור מודל עצס שממנו ניתן להתחלל בתיכון. זו אינה משימה פשוטה ומיידית. יש לה חשיבות יסודית, משוס שהמבנה העתידי של המערכת (ארכיטקטורת המערכת) יותנה במודל המציאות שממנה הוא נבנה. מנתחי המערכת צריכים להבין את הבעיות שעומדות בפניהם ולהיות מסוגלים לנתחן במונחים של העצמים החשובים ביותר, מאפייני המפתח שלהם, ושל יחסי הגומלין והפעולות שבין עצמים אלה. במרוצת הזמן נוצר מגוון של רישומיס ושיטות לטיפול בשלב קשה זה שבתהליך. 2 ניתול איכות תוכנת תיכון: מוכוון-עגמיפ תיכון מוכוון-עצמים (002) מספק את החוליה החיונית בין המבט מוכוון-העצמיס על העולס, לבין אוסף של תוכניות מוכוונות-עצמים. עיצוב זה קובע את ארכיטקטורת המערכת, שהיא המבנה היסודי של המערכת והמסגרת לכל יחסי הגומלין בין העצמים. היכולת לבנות מודלים משופרים בעלי אופי אינטראקטיבי של רבות ממערכות עולם המציאות, תרמה באופן משמעותי להתגברות העניין במערכות מוכוונות-עצמים. בעיות לא היררכיות תצמחנה באופן טבעי מודלים לא-היררכיים של המציאות, שמהס תעוצב בסופו של דבר מערכת תוכנה. אם כן, מערכת מוכוונת-עצמיס תהיה בגויה אחרת מאשר מערכת המאורגנת בצורה היררכית. כאשר מודל העצם משקף את המאפיעים החשובים של עולם המציאות, וארכיטקטורת המערכת מאפשרת יישוס מוכוון-עצמים של המודל, יש סיכויים רבים יותר שמערכת התוכנה שתתקבל אכן תהיה תואמת לבעיה. ארכיטקטורת מערכת מתאימה מאפשרת להשיג פתרון המתאים היטב לבעיה, שמיש ומובן למשתמשים, ומגלס בתוכו מבני תוכניות טובים ועקרונות תכנות יציבים. לבוא ולומר שמערכות מוכוונות-עצמים משיגות כבר עתה מטרה זו במלואה, יהיה משוס תיאור מוגזס של המצב, אך אין ספק שהדבר יושג בעתיד. תכנות מוכוון-עמיפ תרשיס 9.1 מציג אחדיםס מרעיונות המפתח. המשבצת הגדולה מייצגת את גבולות העצס. כל דבר שהוא במסגרת גבולות אלה נחשב כשייך רק לתחומו של העוסק בפיתוח. המשבצות הקטנות יותר שמגשרות על פני הגבולות מייצגות את הממשק של העצס עס סביבתו. כלומר, אלה הס המנגנוניס שבאמצעותס מקייס העצס את הקשר עס סביבתו. המשבצות שעל הממשק מייצגות ישיטות' ציבוריות ('65ס₪!סו' טו!פטק), שמהוות את הדרכיס הסטנדרטיות בהן יכול המשתמש בעצס לפנות אל המידע וההתנהגות שיוצרו כמודל על ידי העצס. אין דרך אחרת לקבלת גישה אל העצם. בין השיטות הציבוריות ייכללו האמצעים לכניסה וליציאה מהתניון, ולקביעה אס התניון מלא. בתוך גבולות העצס נמצאות פיסות מידע, שמרכיבות יחד מודל סטטי של המאפייניס המבנייס של התניון. החשוב שבהס הוא שלתניון יש מספר מירבי של מקומות חנייה לכלי רכב. יכולות להיות לנו גס כמה ישיטותי פנימיות (פרטיות ‏ 005ת!6וח' 816טוזק) לתפעול מידע זה. השיטות הפנימיות הן פרטיות למפתח, ואינן נגישות למשתמשיס אחריס בעצסם; אפשר להשתמש בשיטות אלו כדי לעדכן את המודל, או כדי לספק חלק מהפונקציונליות שביסוד הממשק הפשוט של המשתמש. אחד מיתרונות המפתח של תכנות מוכוון-עצמים (002) הוא היכולת הזו לבנות תוכניות המשקפות את מודל העצס בצורה שמאפשרת למידע המבני להיות מוסתר ממשתמשי העצם. כך, שאפשר לטפל במידע זה רק באמצעות השיטות הציבוריות פרק פ: פיתוח מוכוון-עצמיס | 203 שסופקו. הממשק חייב להיות מתועד באופן מלא, כדי שאפשר יהיה לנצל את יכולות העצם במלואן, וכדי לוודא שמשתמשים פוטנציאליים יבינו בדיוק מהי דרך הגישה אל השיטות של העצס. זה חל על מודליס בכל הרמות, ובמיוחד ברמת התכנות, בה מיושם הממשק בתוכנה כדי שיגיב רק להודעות שמכילות את הפרוטוקול הנכון. הבעיה של גישות התכנות המסורתיות היתה שניתן היה לבצע בהן שינוייסם, שבדרך כלל גם התבצעו, על ידי שינוי ישיר של המודל. במרוצת הזמן הפך המודל למורכב וממוקד יותר בסוגיות מסוימות שגרמו לשינוייס הקודמים, עד שנעשה קשה לבצע את השינוי הרצוי הבא שנדרש במודל. גרוע מכך, יישוס תוכנת המודל נעשה מורכב יותר ויותר, ותמיד היתה קיימת הסכנה שהשינוי ישפיע על שינוייס קודמיס ויביא לידי תוצאות לא צפויות. הגישה מוכוונת-העצמים, עם כל כוח המשיכה שבה, אינה ניתנת ליישוס מלא בשפות תכנות מסורתיות, שאינן בנויות סביב תפיסת העצמים. שפות מובנות מסוימות התפתחו עד לנקודה בה הן מאפשרות הגדרה של מבנים דמויי עצמים, אך הכימוס (ח0ו08050181ח6) או יאריזת המשאביסי, היא רצונית בלבד. אין דרך לאכיפת גבולות העצס שתאל את המשתמשיס לבצע את הגישה אליו רק דרך הממשק. שפות תכנות מוכוונות-עצמים עוצבו במיוחד, כדי להשיג תפיסת מבנה חדשה זו. מובן שיידרשו שינוייס במודל כדי להרחיבו ולשפרו, אך אסור להניח לשינוייס אלה לפגוע בפונקציונליות שהושגה כבר. היכולת לאפשר לשינויים להשפיע על פיתוחים בעתיד, אך לא על ההתנהגות הקיימת, מחייבת גישה חדשה שתאפשר לשינוייס להשפיע על ההתנהגות העתידית, ועס זאת לא תשתקף אחורה בזמן. זוהי התפיסה של ההורשה (66חג]וזסתחו). ההורשה היא המנגנון שמאפשר ליהעביר הלאה' תכונות, או מאפייני עצס אחד אל עצם אחר. בעצס היורש אפשר לשנות, או לדרוס את המאפייניס שהתקבלו בהורשה. כך ניתנת היכולת לבנות צורות שונות של עצס נתון, או להרחיב פונקציונליות של עצס באמצעות תוספות. תרשים 8(9.3) מדגיס כיצד ניתן היה לשנות את העצם של התניון הכללי, לחניון מכוניות, לחניון משאיות ולחניון אוטובוסים; תרשים 9.3(ט) מדגים כיצד ניתן להרחיב את התניון לקולנוע ידרייב-איןי. עס ההזדמנויות שמספק מגנון ההורשה ליצירת שיטות חלופיות, צומחת הזדמנות חדשה. בחניון שמשמש גם למכוניות וגם למשאיות, עלינו ליצור הבחנה בין כלי הרכב, כדי שנוכל ליישם את השיטות הנכונות. לדוגמה, כאשר מגיעה מכונית, עלינו לשלוט בכניסתה באמצעות שיטת יכניסת מכוניות' ולא בשיטת 'כניסת משאיותי. ההבחנה בין השתיים מחייבת תוספת לוגיקה, כדי שתוכל להיקרא השיטה הנכונה, וכל אלה יצטרכו להיות מקודדים לתוך התוכנית לפני ההידור שלה. כאן באה לעזרתנו גישת ריבוי-צורות (ותפותקזסותץ!סק). למושג ריבוי-צורות יש חשיבות בפיתוח מוכוון-העצמיס. הוא מאפשר לנו ללכוד את ההיבטים הגנריים (4:0608 סוז6ח6ם, כלליים) של תהליך ברמה אחת, ולהאציל כלפי מטה פרטל יישומים ספציפיים של התהליך הגנרי, שלעיתים תכופות מערפלים את ההיבטים הגנרייס וגורמיס לבלבול. לדוגמה, תהליך הדפסת פלט המשותף למספר רב 4 ניהול איכות תוכנה של יישומי תכנות. הפרטיס המתייחטיס להדפסת מסמך טקסט, דמות גרפית או פלט מובנה, כגון גיליוו אלקטרוני, שוניס מאוד זה מזה. אך בכל מקרה, הכוונה הכללית זהה. אס נוכל לאפשר לתוכניתן היישוס להצביע רק על כך שנדרש תהליך הדפסה, תוכנית היישוס תהיה פשוטה וברורה יותר מאשר אילו היינו צריכיס לכלול בה את כל הפרטים של תהליכי ההדפסה השונים. בפועל, הפרטים קשוריס אל סוג העצס שדורש את התהליך, וכך אנו יכוליס להאציל את פרטי התהליכיס השוניס להגדרה של סוגי העצמיס. אזפק ס[ס1ת0/ אזהק 61016 פ] 6166 פטח6כ * 5 ז0 6080865 ,65החס] זס1 סח 60608 * קבוח אזגק אוסח 65סטטסזוה[ * חו-6טוזק ו זס) 161₪065ח 4005 * וחסחוס 10 ץזוח6 חס עַגק- פוח]!] 8ח56160]1- תזססקסק 8ַהועטט- 60 ל (6 תרשים 7.3 הורשה: (ג) יצירת חמון לפי סוגי המכוניות; (0) יצירת קולנוע דרייב-אין. בעזרת ריבוי-הצורות, יכולה מערכת זמן-ההרצה (הסביבה בה מורצות התוכניות) להבחין בין סוגי עצמים. לצורך דוגמת החניון שלנו, כל מה שנדרש בתוכנית המשתמשת בשיטות כניסה הוא, להצביע על כך שיש צורך בשיטת כניסה. המערכת של זמן ההרצה מוודאת שימוש בשיטת הכניסה הנכונה על ידי זיהוי סוג העצס המבקש את הכניסה, וקריאה לשיטה הנכונה, מתוך אוסף השיטות הזמינות. תוכנית היישומיס שלנו צריכה להכיל התייחסות לעובדה שכלי רכב כלשהו נכנס לחניון. עס זאת, היא לא תכיל פרטיס בדבר זיהוי הרכב, או מנגנון הכניסה. תכנות מוכוון-עצמים מאפשר תוכניות פשוטות וקלות יותר לתחזוקה, שאפשר לשוב ולהשתמש בהן ולהרתיבן כדי לענות על דרישות חדשות. השימוש החוזר (56ט6ז) חוסך זמן ומאמץ בתיכון, מצמצס את הסיכונים ואת מאמצ הבדיקות. על צד השלילה, פרק 9: פיתוח מוכוון-עצמיס 205 תוכניות מוכוונות-עצמיס גדולות יותר בשל ספריות המחלקה השוכנות בהן, והרצתן איטית יותר מאשר תוכנית מסורתית מקבילה, משוס שלמערכת זמן-ההרצה יש עבודה רבה יותר לבצע בזמן ההרצה. לדוגמה, זיהוי סוגי עצמיס ובחירת השיטות המתאימות מתוך הספרייה, הן משימות תקורה הקשורות בריבוי-הצורות, ואלו חייבות להתבצע בכל שימוש בשיטת ריבוי-הצורות. לא כל השיטות משתמשות בגישת ריבוי-צורות, והתקורה בפועל תשתנה בהתאם, מותנית בגישת התיכון המסוימת שנקבעה. יתרונות איכות עיקריים של תכנות מוכוון-עצמים 1. רעיון הכימוס או 'אריזת המשאביס' של נתוני העצס ושל הפונקציונליות, פועל כהגנה בפני מספר רב של חולשות בגישות תכנות מוקדמות *ותר, בהן היתה לתוכניתניס גישה לכל מקוס, ובכל עת. 2 יצירת ממשקים מוגדרים היטב מגדילה את הסיכוייס לשוב ולהשתמש בעצם בכל זמן שהוא בעתיד. 3 בניית ספריות של ימחלקותי (תבניות עצמים) היא אחת הדרכים כדי להשיג את משימת העשרת איכות התוכנה, וצמצוס הסיכון הכרוך בפיתות יישומיס. גישת הפיתוח מוכוון-העפמיפ לגישת הפיתוח מוכוון-העצמיס שתי תכונות יסודיות : 1. גישה מבוססת-מוצר (58566 +00₪6) גישת הפיתוח המובנית אימצה את תהליך ניתוח הדרישות ויצירת מערכות בצורה המאפשרת למוצריס להופיע בהדרגה. ככלל, המוצר אינו נראה לעין כמעט עד לסוף התהליך. זוהי גישה מבוססת תהליך (הססזקקג 08560 655ססזק). בגישה מבוססת מוצר (תססזקקג 08566 ]סט6סזק), המוצרים הסופיים מופיעים במועד מוקדס ותוך כדי התהליך משפרים, מרחבים או בוניסם אותס מתוך רכיביס מוגמריס של השלביס השוניס. גישה לא-קווית (ז63מו!-מסם) כ כפי שהוסבר בפרק 7, במחזור חייס לא-קווי, התהליך פשוט יחסית, ומה שמוליך לבסוף לאספקת המוצר או המוצרים, הוא החזרות על התהליך בוואריאציות קטנות בלבד. פיתוח מוכוון-עצמיס כולל גישת כלאיים, המשתמשת בטכניקות איטרטיביות ותוספתיות בתוך תהליך רציף. גישת הכלאייפ (%6סצם) גישה איטרטיבית היא כמעט לחלוטין גישה החוזרת על עצמה, ותוך כך בונה מודליס שנעשיס מפורטיס ומדויקים יותר עד שמתקבלת גירסה קבילה שמסופקת למשתמש. בדרך כלל, הגישה התוספתית מקימה ארכיטקטורה ומפצלת אותה למקטעים שניתן לבנותס פחות או יותר עצמאית, ולבסוף מחברת אותם יחד. גישת הכלאייס משתמשת 6 ניתול איכות תוכנת בשני הרעיונות לסירוגין. היא יוצרת צירוף של גישות רציפות, איטרטיביות , ותוספתיות. בתרשיס 9.4, השלביס ראשון ואחרון נמצאים ברצף עם השלב האמצעי; השלב האמצעי גדול בהרבה מאחריס והוא תוספתי, אך כל תוספת מפותחת באופן איטרטיבי. פיתוחיס מוכווני-עצמיס מאמציס לעיתים תכופות הכלאה של סגנונות, האיטרטיבי והתוספתי, אך ניתן להשתמש בהם בגישת פיתוח היישומיס המהיר, שנדונה בפרק 8. 5600 תלש'סם 7.4 פיתות כלאיים גוזפעת ירת אבסיפוס עפ מחלקות בפיתוח מוכוון-עצמיס ניתן ליישס את יצירת האבטיפוס במספר רמות. ברמת המחלקה, ניתן לעצב מחלקות פשוטות בתתילת הפיתות ולעדכנן בהדרגה עס ההתקדמות. ברמת הארכיטקטורה, יישוס פשוט יחסית של מודל העצם (66[טס [06) יכול להתפתת ולהתרתב כדי ללכוד מאפיינים ותכונות נוספים של עולס המציאות. ברמת המערכת, ניתן להציע מודל עצס פשוט בתחילת הפיתוח ולהרחיבו ככל שמתברריס פרטיס נוספים. גישה זו דומה לגישה ההתפתחותית אל הפיתות. פרק 9: פיתוח מוכוון-עצמים | 207 ניתן היה לאפשר לשלוש השכבות של יצירת אבטיפוס להתנהל בו-זמנית, אך הדבר היה גורר בעקבותיו גישה לא מבוקרת אל הפיתוח. כך היה נמנע, או לא היה קיים כלל ניהול הפרויקט. כדי שהתהליך יהיה ניתן לשליטה, אנו זקוקים למודל מחזור חיים המנצל את הסגנונות האיטרטיבייס והתוספתייס בצורה מבוקרת, כדי שאפשר יהיה להעריך, לתכנן ולשלוט בפרויקט. מחזור חייפ מוכוון-עפמיס מחזור החיים החלזוני (ספיראלי) הוצג בפרק 1 כדוגמה של מחזור חייס לא-קווי. בפועל, זהו מודל פתוח מדי שאינו מאפשר את רמת הבקרה לה אנו זקוקיס בפרויקטיס מציאותיים. דרושה לנו גירסה מתוחמת (66ח51781ח60) של מודל החלזון או של מודל חלופי אחר, מודל זה יספק מסגרת גמישה לניצול הגישה מוכוונת-העצמיסם, יספק למנהל הפרויקט מבנה לבסס עליו אומדניסם ותוכניות ויאפשר לו את בקרת התהליך. ץזגזס!] 0|855) , וי 6 ;| 50006 שַחו!|006וח , עזגזסון (15ח6ות6זוטף6ז) , 0135565 ,' , הח6ו5ץ5 ב | חסווגזק6וח1 1 0010041 6 ץְזגזסו.1 5 [ 5 058 כ | 5 0006 תרשים 9.5 מודל ? משופר, עבור גישה מוכוונת-עצמים 8 ניהול איכות תוכנה אחת הדרכים לטיפול בבעיה היא להתחיל בדבר מוכר שניתן להפעלה בסביבה אחרת, כגון המודל /. ניסיון ראשון לשינוי שיתאים לגישה מוכוונת-העצמים, נראה כמו תרשיס 9.5. הוא נאמן למדי לצורה הכוללת של תהליך הפיתוח, אך אי אפשר לבסס עליו מתודולוגיה. הצורה הכללית מזכירה את התילזון, אך עס מחזוריס מוגדריס יותר של החזרה. יש בה גם הדים לגישה של תיבת הזמן (אסטסוחוו). דבר זה מרמז על קביעה כוללת של יעד ועל קבוצת אבני דרך שהגישה אל כל אחת מהן היא באמצעות שיטה איטרטיבית או תוספתית. שלב קביעת יעד, צפוי שיהיה איטרטיבי; הוא מסתייס במודל מְתָּאר של עצס, ובשלב זה נעשה חיפוש אחר מחלקות מועמדות. הצעד הבא יהיה הגדרת ארכיטקטורת המערכת, וחיפוש אחר אסטרטגיית הפיתות. זו תהיה צירוף כלשהו של התוספתי והאיטרטיבי, עס מדיניות של אבטחת איכות ובדיקות. למשל, נוכל להחליט לבצע מספר בדיקות בכל איטרציה ואחר כך לבצע מבדק קבלה סופי. נוכל גם לבצע ניסוי מערכת כאשר חלק מסוים של התוספות הבודדות יהיה מוכן. אנו גם זקוקיס למדיניות סקריס והערכה של מודלים איטרטיביים. יש אסטרטגיות חלופיות רבות, אך כולן כוללות את תכנון האיכות כפעילות בעלת חשיבות קריטית שבאה לפני הפיתות. לבסוף, כיצד נסיים את הפרויקט? מה יהיה מנגנון הקבלה הסופי! עלינו לקבוע שיטה להגדרת 'אבטיפוס סופיי ולספקו בשלמות יחד עס אוסף תיעוד חיוני. זה לא יהיה בהכרח תהליך ישיר בסביבה כה נזילה ונעה במהירות, ולכן יש לראות בו מועמד נוסף להגדרה בשלב מוקדס. 5 ]| עזזסון 5 7 0 קחו|[006וח ח0ו501001 7 7+-| 6זט601!וחטז ה חקו וח56ץ5 65 ב 06% ]וזו פשוזסטו]|6 ץזגזטו 1 2%5 סז 1 עזשט)]0 שעןוזטו] [ושותקס)טיו ב 0006 תרשים 9.6 מחזור חיים מוכוון-עצמים פרק 9: פיתוח מוכוון-עצמיסם ‏ 209 הצורה הסופית של תהליך מחזור החיים הבסיסי נוטה במידה רבה לעבר תכנון בתחילת הדרך, שאחריו תבוא סדרת צעדיס מוגדרים, עס אפשרות של שינוי הצעדיס הספציפיים ככל שהפיתוח נמשך. ולסיוס, שלב סופי של המסירה הרשמית. תרשיסם 9.6 מדגיס את הרעיונות הבסיסיים. (יחול פיתוח מוכוון-העפמיפ כיצד נוכל לנהל סביבה דינמית זו של יצירת אבטיפוס כדי להכניס את הפרויקטים למגבלות ההכרתיות של לוח זמניס ותקציב! אין ספק שאנו חייביס לנהל. אחרת, נהיה נתוניס לחלוטין בידי כל גחמה נוספת של המפתחים. ברור לא פחות שאיננו יכוליס לאכוף מבנה פורמלי וביורוקרטי מאוד לניהול הפרויקט וניהול האיכות. הרי ברצוננו לשמר חלק מהאפשרויות של התיכון החדשני באמת ומוסיף ערך, עבורו נבנו השיטות מוכוונות-העצמיס. הפשרה המתבקשת היא: שלב תכנון זהיר ומפורט המקדיס את הפיתוח, בו נקבעיס כללי יסוד ברוריס ביותר להערכת ההתקדמות ולשינוי התוכניות. מעת שיותחל בפיתוח, יקבל הפרויקט תאוצה משלו ולתהליכיס בלתי מוגדריס תהיה נטייה להישאר בלתי מוגדריס. איננו יכוליס להרשות לעצמנו את המותרות שבתהליכיס בלתי מוגדרים ואת התוצאה של תנועה חופשית במדרון שנגרמת בגינס. לא נוכל לאפשר מצב של חוסר הגדרות בתוכניותינו, ולכן עלינו להבטיח לעצמנו יכולת לנהל בעקביות את משאבי הפרויקט לעבר היעדיס ארוכי הטווח. הגישה שננקוט דומה באופן כללי לגישה של תיבת הזמן שתוארה בפרק 8, אלא שהפעם יש לנו פחות אי-ביטחון בתוצאות. נשתמש בשיטות איטרטיביות ותוספתיות כדי לאפשר גישת תיכון ישירה יותר, אך בשלבים קלים יחסית. הגישה הישירה מסייעת לנו לפקוח עין על היעד, בעוד השלביס הקליס גורמיס לתהליך להיות נתון יותר לניהול. כמו בשיטות של יצירת אבטיפוס, אנו פותחים ביעד כולל וביארכיטקטורת פרויקטי המזהה סדרת שלבי פיתוח ויעדיהם (הארעיים). אפשר לתכנן בפירוט את השלב הראשון, בו תוגדר ארכיטקטורת המערכת ותזוהינה המחלקות המועמדות. שלבים עתידיים יפתחו איזו שהיא קבוצת משנה של הארכיטקטורה הכוללת, על ידי צירוף מחלקות שנבחרו מתוך הספרייה, הגדרה ובנייה של מחלקות חדשות, או שילוב כלשהו של שתי הדרכים. בכל שלב פיתות, חייב להתבצע סקר של התוכנית כדי לקבוע: >= אם השלב שזה עתה הושלס השיג את יעדי התיכון שלו ; >= אם יש צורך להתאיס בצורה כלשהי את יעדי השלב הבא ; > אם השלבים שהוגדרו מלכתחילה הס עדיין השלביס הנכוניס, ואם יעדיהס מוגדריס כהלכה; = אם היעדיס הכוללים הם עדיין ברי-תכנות; במקרה שלא, מה צריכיס להיות היעדיס המתוקנים. 0 ניהול איכות תוכנה יר זה וסט[סזק 1 בי סז חסוז16קוחסס 5 זגו |[ 1 5 356 הג!ק ז0[60ז? 666 5516 חגזק 356חק עזחסוזטוסצ הדההררד-ר) שחוחתגּ!ק6ת 18 חסו31)ם6וח6!קנח[ ו -ר-קרברוון.. | 000000000 "טטר .]| תגוק ‏ % אשמשת ַ = 5- גת 600 "ל 1 1 856חק , : מו סוק ותס) ו ש6וצ6 006 1 77856 תרשיס 2.7 ממיהול פרויקט עבור פרויקטים מוכווני-עצמים במסגרת כל שלב, ניתן להגדיר וליישס את עבודת הפיתוח הממשית בצורה קווית, או שניתן לטפל בה בגישת האבטיפוס. הבחירה תותנה בעבודה בה נעסוק באותו שלב, שעשויה להלות פחות או יותר מוגדרת כבר. מתודולוגיה זו לניהול פרויקטיס מתוארת בתרשים 9.7. סקירה מתמדת של יעדיס ברוריס ומכומתים היא, כמו בכל הפיתוחיס הלא-קווייס, בעלת חשיבות יסודית. בקרה של פעילויות הפיתוח היא לא פחות קריטית, וחייבת להיות נתונה לאותן דיסציפלינות כמו כל גישה של שימוש באבטיפוס. תכנון האיכות הוא סוגיה נכבדה בשל רמת הסיכון. אפילו המתודולוגיה הבסיסית אינה נחלת הכלל עדיין, והכישוריס הנדרשיס עבורה גס הס אינס כה נפוציס. מלהן סוגיות האיכות מהן סוגיות האיכות שמעוררות שיטות מוכוונות-עצמיס! הסוגיות רבות, אך מתחלקות לקבוצות נבדלות. להבנת הסוגיות המפורטות חיוני שתהיה לגו תפיסה מתאלמה של סוגיות מדיניות האיכות. פרק 9: פיתוח מוכוון-עצמים | 211 2 סוגיות חשובות בנושא מדיניות האיכות לפיתוח מוכוון-עצמים .12 האס כל המעורביס מביניס את המינוח, והאס הבנה זאת אחידה לגבי כולס! האס עומדיס לרשותנו שיטה הולמת וסביבה וכליס לפיתוח, והאם קיבל כל הסגל הרלבנטי הדרכה מתאימה! האס משמעויות הטכנולוגיה מובנות להנהלה! האס יש לנו מתודולוגיה לניהול פרויקטיס לצורך ניהול אמין של הפרויקטיס האלה! האס אנו יודעים כיצד לנסות מודלים מוכווני-עצמים! האס זמיניס לנו כלים מתאימיס וטכניקות הולמות, שיאפשרו להגדיר אסטרטגיית בדיקות?! האס יש ברשותנו מומחיות במספר מספיק של תחומי הארגון, שתאפשר לנו לבצע אפיון אפקטיבי וסקרי התיכון? האס אנו מביניס את ההשלכה של הטכנולוגיה החדשה על המערכות המסורתיות שלנו ((ח516ע5 ע6886!)! האס התוכניות מוכוונות-העצמיסם החדשות תפעלנה יחד עס מסדי הנתוניס (הטבלאיים) הקיימיס שלנו! האס העובדיס בסגל האיכות הקיים שלנו מביניסם את הטכנולוגיה, והאס הס פיתחו כבר בעבר מתודולוגיית איכות עבור מערכות מוכוונות-עצמיס! . האם שקלנו את הדרכיס למדידת הביצועיסם של התהליך והמוצריס החדשיס מנקודת ראות של שיפוריס לטווח ארוך! . האם כל חלקי הארגון מסכימיס להגדרת היעדיס! במקרה שלא, האם יש ברצונס להפעילס בצורה שונה? האס תכננו לשלב את כל היישומים מוכווני-העצמיס שלנו במועד כלשהו בעתיד! אם כן, האס שקלנו כיצד ינוהל הדבר ועל ידי מי! - 7-7 בהיותנו מצוידים בתובנות אלו של המדיניות, נוכל להתפנות אל היבטיס ספציפייםס יותר של הטכנולוגיה ושל ניהולה. 1 סוגיות טכנולוגיות סוגיות אלו מתייחסות לסיכוניס הקשוריס בשימוש בטכנולוגיה חדשה ובלתי מנוסה יחסית. הסוגיות כוללות : 0 המפתתים חייביס לקבל הדרכה מתאימה כדי להכינס לעבודה שלפניהם ; 0 חייבים להיות לנו מחזור חייס ומתודולוגיה מוגדריס היטב; 0 חייביס להיות לנו תקניס ונהלים עבור סביבת הפיתוח החדשה ; 0 חייבת להיות לנו קבוצת כליס מתאימה ; 0 אנחנו חייבים להיות מסוגליס לבחון יעדיס ומערכות מונחות יעדים. 2 ניהול איכות תוכנה 2 סוגיות של ניהול פרויקטים סוגיות אלו מתייחסות לסיכוניס שבניהול פרויקטיס ע הסוגיות כוללות : לי תהליך פיתוח חדש. 0 חייבת להיות מתודולוגיה לניהול פרויקטיס שתהיך, הפיתוח המוסכם ; ' מבוססת על תהליך 0 חייבת להיות שיטת תכנון עבור פיתותי כלאייס; 0 חייבים להיות מסוגליס להעריך בדיוק את הזמן יחעלות של פעיל מוכוונת-עצמים, ת של פעילות פיתוח חייבת להיות לנו שיטה לסקירת פעילויות הפיתוח כדי פ קבוע אס הן יכולות להסתייס בהצלחה ולספק תוצאות קבילות; חייביס להיות לנו אמצעיס לניטור ההתקדמות בשלבים האיטרטיביים של הפיתות; חייביס להיות מסוגליס לחזות את המאמץ והזמן הדרושים עד להשלמה, לגבי פרויקטיס שהושלמו רק בחלקם. 3 סוגיות של ניהול האיכות סוגיות אלו מתייחסות למידת הבנתנו את תהליך הפיתות שביסוד הדבריס, ואת דרך ניהולו. הסוגיות כוללות: 0 חייבת להיות לנו מדיניות ברורה לדרך הטיפול בטכנולוגיה חדשה זו. אחדות מסוגיות המדיניות החשובות ביותר כבר נדונו; 0 חייבת להיות לנו הגדרה ברורה של תהליך הפיתוח, כדי שנוכל לעקוב אחריו ביעילות ; 0 חייבת להיות לנו אסטרטגיה של אימות ובדיקת תקפות עבור פרויקטים מוכווני-עצמיס ; 0 חייבים להיות לנו מדדים שימושיים למוצר ולתהליך, כדי שנוכל להמשיך ולשפר את שיטותינו. מספר בעיות איכות מעשיות והחשובות ביותר הן: [,. ניהול התצורה קרת שינוייס. דאגתנו הסופית תהייה שתימסר 0 9 ביותר אס שאנו עלולים לגרוס 3 - ה 6% 1 ל הנ ו פתוח להימשך במקביל ללא בקרה מת לריבוי פעולות נאפשר פרק : פיתות מוכוון-עצמים | 213 ויוי .אהההאטוהוווווה מוכוון-עצמיס מגביר את הבעיה משוס שקיימות בו רמות אחדות של מודלים, וכל רמה נתונה לשינוייס שעשויים להשפיע על הרמות האחרות. 2 ספריות מחלקת רביס מהיתרונות של פיתוח מוכוון-עצמיס מחייבים יצירה וניהול ספריית מחלקה (עזגזט!! 61456) שתשמש כמסד מידע (עזסז051ק6ז) להגדרות העצמים שנבגו ונבדקו כבר, ויכוליס להביא תועלת בפיתוחיס עתידייס. ספרייה כזו מחייבת בקרת הגישה וניהול רשומות, ממש כמו כל ספריית פרויקט אחרת. יש גם סוגיות אחרות הקשורות בניהול הספרייה, כגון בחירת תוספות, הגדרה ואכיפה של תקניס לעצמיס המופקדים בספרייה, וניהול מעקב אתר המקומות בהס משתמשיס בעצמי הספרייה. 3 הגדרות עצמים מערכת מידע כלל-מפעלית רבת עוצמה מחייבת שכל היישומיס יתפעלו את אותס העצמים, כך שייעשה שימוש חוזר בעצמיס של הספרייה בכל הארגון, וכל היישומים יכילו ממשקיס אל עצמים עסקיים סטנדרטיים. כדי שזה יהיה המצב, יש צורך בהסכמת כל המשתמשיסם להגדרה של כל עצס. כשיש לעצמיסם הגדרות פשוטות מאוד אין ההסכמה מהווה בעיה, אך הספרייה מתמלאת במספר גדול מאוד של עצמיס פשוטיס ואובדיס יתרונות השימוש החוזר, משוס שהיישומיס נעשים מורכבים כמו מערכות שאינן מוכוונות-עצמיס. ככל שהעצמים מועשרים בתוכן עסקי, כן גדליס הסיכויים לאי-הסכמה נרחבת ביחס לפרטיס. 4. מהימנות העצמים עצמיס בתוך ספרייה חייביס להיות אמיניס מאוד ומוגדריס היטב, משוס שהס עתידיס להוות את 'ליבסי של יישומיס מסוגיס שונים. איכות הפיתוח של עצמי הספרייה חייבת להיות בעלת חשיבות עליונה, גס כאשר בוניס את העצמיס בתהליך של יצירת אבטיפוס איטרטיבי. 5 מסדי נתוניס טבלאיים יישומים מוכווני-עצמיס רבים יידרשו לפעול עס מערכות קיימות של ניהול מסדי נתוניס טבלאיים. דבר זה יהיה כרוך בבניית ממשקיס מתאימים בין הטכנולוגיות השונות זו מזו, יגדיל את המורכבות ביישומיס ויקטין את הגמישות והמהימנות. 6. בחירת עצמים בכל פעס ששוקלים התחלת פרויקט חדש, צריך להחליט אס לעשות שימוש חוזר בעצמים קיימים, או לבנות עצמיס חדשים. הרצון להפיק את מירב היתרונות מהשימוש החוזר מחולל לחץ להשתמש בו, אלא שדבר זה עלול להתבטא בצורך לבנות תוכנות יישומיס חדשות כדי למלא את הפערים שיווצרו על ידי השימוש החוזר בעצמיס קיימים, שלא תמיד עוניס על הדרישות במדויק. התוצאה עלולה להיות הגברת המורכבות. 4 ניהול איכות תוכנה תכנון האיכות האם אמנס יש בגישה לא-קווית מסוימת זו יכולת להתאים את עצמה לגל האיכות שתקן 9000-3 150 מעדיף! אין סיבה שלא, א 2' יש צוְרְך בפרשנ ויש נושאיס שצריך לטפל בהם, שלא כוסו ברשימת התכנים שהומלצה על יז המנחים. תכנון איכות עבור פיתוח מוכוון-עגמים תוכנית איכות עבור פיתוח מוכוון-עצמיס אמורה לכסות את כל סוגיות הקריטיות : 1 .10 ספריות מחלקה מהן ספריות המחלקה הזמינות! מי ינהל את ספריית המחלקה של הפר יחליט על הארכיטקטורה ומי יבחר את מחלקות הספרייה: ניהול התצורה באיזה תהליך בקרת שינוייס נשתמש וכיצד יזוהו המודלים! בדיקות מה תהיה אסטרטגיית הבדיקות הכוללת! באילו טכניקות נשתמש? כיצ הבדיקותניסוייס בעצמיס הבודדים (לצורך הכללתס בספרייה)! קבלת מהם הקריטריוניס לקבלה ובאיזו דרך יודגמו! מה יהיה מנגנון המ? המוצר! תכנון הפרויקט מה תהיה צורת התוכניות! מה תהיה שכיחות עדכונן: הגדרת עצמים מי יהיה אחרא? להשגת התאמה בין עצמים עסקיים לבין המשתמשים והל סביבה באיזה שיטות וכליס נשתמשז בקרה , בי הפרויקט! מהס הקריטריונים שננדירן את השלמת שלבי הפרויק להמשיך לשלב המידול הבא, ועל ידי מי! כיצד יינתן , תיכון עצמים . לכו העצמיס במונחיס של ממשקים ציבורי:ו שישלטו בתיכון ה מהס הכללים ל אחד מהעצמים! חליט על הרמה ההולמת עבור ? ההכללה: מל ?2 טוגיות בפרויקטיס , שתוכנית איכות מטפלת בהן. יש צורך לטפל בכל הסוגיות יהסטנדרטיות 5+ פיתוח מוכנון-עצמיכ .ת"ר האפ פיתוח מוכוון-העמיפ הוא אמ(פ התשובה ה(כו(ה? פיתוח מוכוון-העצמיס מייצג התקדמות טבעית משיטות פיתוח מבניות שהיו מקובלות משנות ה-80. במבט ראשון נראית שיטת פיתוח זו כמהפכנית למדי ושונה מכל קודמותיה. עיון מעמיק יותר יגלה, כי היא מהווה הרחבה של עקרונות המבניות שנחשבו כאבני יסוד להנדסת תוכנה. עס זאת, שיטה זו קוסמת לאלה המעדיפים גישה בלתי פורמלית יחסית לפיתוח, משוס שהיא מעודדת את סגנון יצירת אבטיפוס. מה בנוגע לנקודת המבט של האיכות! גם בתחוס זה, יש תכונות המוסיפות על יתרונות השיטות התבניתיות המוקדמות יותר; בעיקר, ההורשה והשימוש החוזר, שמצמצמיס את היקף הפיתוח החדש ואת השפעת השינויים על תוכנה קיימת. שני גורמים אלה היוו בעבר תחומי סיכון משמעותיים לגבי טכנולוגיות התוכנה. עס זאת, העובדה שהטכנולוגיה צעירה יחסית ומחייבת שימוש בכישורי תיכון חדשים, מחוללת סיכוניס חדשים. אלה ייעלמו במרוצת הזמן, אך מהוויס לפי שעה מגבלה רצינית לכל מי ששוקל פיתוח מוכוון-עצמיס לראשונה. מנקודת ראות של ההנהלה, פיתוח מוכוון-עצמים יוצר בעיות חדשות עבור מנהל הפרויקט ומציע הזדמנויות חדשות למנהלים בתחומים העסקיים. סוג חדש של מחזור חייס, עס קווי דמיון למחזורי החיים בסגנון צ והחילזון; מתודולוגיות הכוללות פיתוחיס בסגנון רציף, איטרטיבי, ותוספתי; מבני תוכניות שיוצריס אתגרי בדיקה חדשיס; כל אלה מצטרפים לכלל מבחן חמור להנהלה וסביבה מחמירה מאוד בכל הנוגע להספקת תוצאות בזמן ובמסגרת התקציב. אם כן, האם הפיתות מוכוון-העצמיס מהווה אמנס את התשובה הנכונה? ניסיון העבר מרמז שיש לנקוט זהירות רבה בכל פעס שמתעוררת שאלה ממין זה. עס זאת, אין ספק שפיתוח מוכוון-עצמיס הוא צעד בכיוון הנכון. ימיס יגידו לאן הוא יהיה מסוגל להביא אותנו, אך כבר עכשיו ברור שאין זה פתרון רגעי לבעיה הוותיקה של ניהול פיתות התוכנה. עלינו ללמוד לרתוס כלי חדש זה ולהשתמש בו באפקטיביות לפני שנוכל להעריך את התרומה שהוא יכול לתרוס. לאלה שטרס עשו את יהטבילה הראשונה' בפיתוח מוכוון-העצמים, לפנינו מספר נקודות ציון: הק תת 7 סשקססססאח | עשרה צעדים לעוסק בפיתוח מוכוון|-עצמים 1[. הדרכה לכל דאג להדרכת אנשי המפתח בהקדס האפשרי. לא רק המפתחים: אנשי האיכות, משתמשים ומנהלים צריכיס להבין את העקרונות ושפת היומיוס המקצועית. 2. צור מספר תקנים קבל את הסכמת המפתחיסם והעוסקים באיכות במספר נושאי מפתח טכניים. 6 ניהול איכות תוכנה תכנן את דרך התכנון לפני התחלת העבודה, קבע את מבנה הפרויקטים ומה תהיה צורת התוכניות. החלט כיצד לבצע בדיקות בעבודתך תזדקק למספר טכניקות וסטנדרטיס; שקול את הדרך בה תוודא את תקפות התוכנה לפני שאתה מתחיל בכתיבתה. מכור להנהלה את מה שהכנת וודא שההנהלה שלך מודעת לסיכוניס וכי היא עומדת מאחוריך. דאג להתעניינות המשתמשים הכנס את המשתמשים לתוך התהליך, כדי שיוכלו לראות את היתרונות ולהעריך את הקשיים. תרגל את הטכניקות לפני השימוש בהן השתמש בפעילויות בשיטת הסדנה, כדי לעבור על צעדיס פשוטיס לפני שתשתמש בטכנולוגיה ברצינות. דאג שכולס יהיו מעורביס בסדנאות. הקס את הספרייה שלך צור ספריית מחלקה, עבד את דרך השליטה בה, ומנה את יהממונה על המחלקותי. דאג למבנה נכון של הצוות החלט מהס הכישורים הדרושים בצוות הפיתוח, ובחר בקפדנות את האנשים שיאיישו אותו. ראה צוות זה כמי שיהיה במרכז תוכניותיך העתידיות. . עכשיו אתה מוכן לפרויקט-חלוץ פשוט כל ההכנות האלו הביאו אותך לנקודה בה אתה יכול כבר לשקול מעבר לעבודה ממשית. עס זאת, וודא שהפרויקט יהיה קטן ולא קריטי מדי. וק לאחר שתתחיל במתודולוגיית הפיתוח שלך, תוכל לחזור אל רשימה זו ולעדכנה, או להכין רשימה משלך. מומל> לעשות זאת, משוס שתרגיל מסוג זה הוא בדיוק הדבר שמניע אותנו להרהר בסוגיות החשובות באמת, ומסייע לנו להימנע מתלות משעבדת בשיטות ובגישות שיש צורך להתאימן להתנסות שלנו. פרק 9: פיתוח מוכוון-עצמים | 217 עתיך איכות התוכנת חלק 5 עוסק בהתבוננות אל העתיד. הוא מכיל פרק אחד בלבד - פרק 10: הדוך שלפנינו, מה שמעבר לתקן 9000-3 150. מטרת פרק 10 היא לשמש כעין 'אחרית דבר' ולהבליט מספר רעיונות מפתח שיש לבוחנס למען העתיד. הספר זיהה עוצמות וחולשות בגישת התקנים 9001 150 ו- 9000-3 150. הוא גס עסק בגישות אחרות לנושא ניהול איכות. פרק 10 מציב את הגישות החלופיות במסגרת הקשר זה, ומזהה את המגבלות הפוטנציאליות המשמעותיות ביותר, שיש בחלקן או בכולן. בהסתמך על טיעונים שהושמעו בחלקיו השונים, מחפש הספר אחר אסטרטגיה ההולכת ומתהווה ואשר תשרת את צרכיה של תעשיה צעירה ומתפתחת. רעיונות המפתח והקשרוים שביניהם מוצגים במפת התפיסה הכללית שבתרשים ח.5.1. - ל הלק 219 0 נלהול איכות תוכנה תדשים הח.5.1 מפת התפיסה הכללית להסווטסצ 8 ו 5 0 - ", 0/0 1; , . זא , דדחדד-. , ותטו!!וזיד ב ו שחואזו:וחו! סח % ---ידה ה דדה<=.., ל הדי הההררווקיר 7 5וחסוחסעסזקוח1 ₪ == ער אשי הסוזגזטזכףטוח1 ו סכק 10 הדרך שלפנינו טכנולוגיית המידע (דו) היא המשרת של התעשיות המשתמשות בה כדי לנהל ולהעשיר את פעולותיהן. בכל דרך בה תשתנינה תעשיות אלו בעתיד, שביעות הרצון של הלקוחות תספק בצורה זו או אחרת את ההנחיות, בעיקר את ההנחייה השימושית ביותר בתחום האיכות. האם יוכל תקן 9000-3 150 להמשיך ולהשפיע אפקטיבית בסביבה ההולכת ומתפתחת? איזו גישה של ניהול האיכות תשרת את שיטות הפיתוח החדשות, ההולכות ומתגלות לעינינו? מהי האסטרטגיה ארוכת הטווח עליה נוכל להמליץ, אם בכלל? האפ אנו זקוקיפ לדרך קדימהז לפני שאנו מפליגים לחיפוש רציני אחר איכות תוכנה, עלינו לשכנע את עצמנו שיש אמנסם צורך בחיפוש כזה. האס איכות התוכנה גרועה עדיין עד כדי כך שכל העת עלינו לחפש דרכיס חדשניות יותר כדי לקדמה! התשובה חיובית באופן חד-משמעי. ההתקדמות במהלך למעלה מ- 40 שנה של פיתוח תוכנה היתה צנועה למדי במונחי האיכות, וגם אס הטכנולוגיה מסנוורת, האיכות היא שקובעת בסופו של דבר את קבִילוּת מוצרי תוכנה. ואס עלינו להמשיך בדרך האיכות, לאן עלינו לפנות! כנקודת מוצא, גראה שמן הראול לבחון תחילה את היוזמות הקיימות. מהן אפוא האפשרויות הפתוחות לפנינו: קיימות היוס ארבע גישות של המגמות הראשיות: * פיתוח תקנים של מערכת ניהול איכות, בהן כבר דנו; * גישת בשלות התהליך (עוזטזגות 655ססזק) המגדירה רמות בשלות כמטרות לשיפורים ; * גישת ההערכה העצמית (0ח6וח455655-)561), המספקת מודלים שניתן לערוך מולס הערכות מכומתות; * גישת שיפור התהליכים ()חשות6טסזקותו 655ססזק), המעודדת מידול תהליכיס ושיפור-תהליכיס המבוסס על מדידות. נסקור בקצרה כל אחת מארבע גישות אלו. פרק 10: הדרך שלפמנו | 221 הגישה המבוססת על תקניפ כבר בחנו גישה זו בפירוט מסוים וזיהינו אחדות מחולשותיה, לכן נוכל להגביל עצמנו כאן לסיכום בלבד. מהן החולשות העיקריות! > מערכות ניהול איכות (15א0) יכולות להפוך לביורוקרטיות מאוד, וקשה לעצור את הסתף בכיוון זה; = מערכות ניהול איכות מגדירות רק את המינימוס הקביל של רמת ההישגים, ואינן קובעות יעדיס שיש בהס אתגר; + סכימות הרישוס מעודדות את הארגונים לשמור על המצב הקייס, במקוס לחפש אחר שיפוריס מתמידים ; > הפרשנות שניתנת לתקניס אינה תמיד חד-משמעית ; = סכימות הרישוס מהוות תקורה גבוהה עבור מבצעיה. בעיקר אס מדובר בחברות קטנות יחסית בעלות מנגנון קטן וארגון פשוט. * גס כאשר בוחריס בזהירות את המעריכיס, לא תמיד הס מביניס בצורה מספקת את התעשיות בהן חבריס הארגוניס שהס נקראיס להעריך. בבריטניה, סכימת 110%11 - סכימה סקטוריאלית עבור תעשיית התוכנה, ניסתה לטפל באחדות מסוגיות אלו, בעיקר בסוגיה האחרונה. סכימת 11א716 הצליתה מאוד במשיכת חברות תוכנה לבקש הסמכה (061118641100), אך היא סובלת בכל אאת ממספר פגמיסם שאת חלקם לפחות ניתן ליחס למגבלות תקן 9000-3 150. כיום, לאחר שתקן 9000-3 150 נמצא בשימוש תקופה ארוכה למדי שיש בה כבר כדי להשפיע השפעה אמיתית, מתעורר הצורך לשקול את העתיד. האס ימשיך תקן 313 150 לשקף את הנוהג הטוב יותר בטכנולוגיית המידע (11) בעשור הבא! ככל שמתפתחות התעשיות שטכנולוגיית המידע משרתת ומשתניס צורכיהן, כן חייבת להשתנות טכנולוגיית המידע שמשרתת אותן. הצבענו כבר על אחדות מהמגבלות הפוטנציאליות של תקן 9000-3 180, וכאן ננסה לחבר את קצות החוטיס ולהטיק מספר מסקנות. בעיית מלחזור החיים תקן 9000-3 150 אינו מחייב שימוש במחזור חייס מסויס דווקא. אחד היתרונות של תקן זה הוא שימת דגש על גישת מחזור החייס, אך מבלי להכתיב דבר. עס זאת, ממבנהו וצורת הצגתו משתמע מודל מסויס של מחזור החייס שקראנו לו בשס מחזורי חיים קוויים (6]65ץ6 116 זגסחון). תקן 9000-3 150 מזכיר במקומות שונים את עניין שלבי הפיתות. בתקן מודגש שהשלבים האלה אינם מתייחסים לשלבי מודל, או מתודולוגיה מסוימיס של מחזור חיים. עס זאת, תיאורי גישת השלבים כפי שהיא מומלצת בתקן זה כרוכה בסדרת שלבים, כשפלט שלב אחד משמש קלט לבא אחריו. מכאן משתמעת בהחלט גישה קווית של שלב אחר שלב, לנושא פיתוח התוכנה. 2 ניהתול איכות תוכנה לא נטען שתקן 9000-3 150 אינו מכיר באופי האיטרטיבי של תהליך הפיתוח. עם זאת, ההנחה היא שהשלביס הס חלק מרצף פעילויות הולך ונמשך. האיטרציה כרוכה בתזרה אל שלב מוקדס, ותזרה עליו, במקוס להתקדם. זו גישה השונה ביסודה מגישה שמצפה שהתוכנה תתפתחת דרך איטרציות של מערכת הבאות זו אחר זו, כאשר כל איטרציה מתקרבת אל המטרה הסופית. קראנו לגישה זו בשס שיטת פיתוח לא-קווית (61106גת זת6נתקס16/61 ז68ת11-תסת). גם לא נטען כאן שאי אפשר להשתמש בתקן 9000-3 150 בסביבת פיתוח תוכנה המבוססת בעיקר על שיטות לא-קוויות. העקרונות שאומצו בקוויס המנחיס של תקן 3 1500 ישימים וניתנים לשימוש במגוון מצבים, אך השפעתס תהיה גדולה יותר במקומות בהס קל לפרש וליישס את הקוויס המנחיס כמות שהם. ניהול פרויקטיפ לא-קווייפ כפי שנראה, פיתוח תוכנה מתרחק ממתודולוגיות קוויות וימובנות' אל גישות לא- קוויות, הכרוכות בשימוש בשיטות אבטיפוס ומוכוונות-עצמיס. האס תקן 9000-3 150 מספק הנתיות מתאימות עבור מפתחים המשתמשים בשיטות איטרטיביות ועבור מנהלי פרויקטיס שמנהלים ושולטים בפרויקטים לא-קווייס! במקרה ולא, תלך ותגבר אי-הרלוונטיות של תקן זה, והתוצאה עלולה להיות חזרה אל שיטות הפיתוח יאד-הוקי שקדמו לו. איננו צריכיס להניח ששיטות לא-קוויות מייצגות בהכרח את עתיד הנדסת התוכנה. לעומת זאת, נראה שיהיה מסוכן יותר להניח ששיטות מובנות קוויות ימשיכו לשלוט ברס הראשי של פיתות התוכנה, אם אמנם היו אי פעם במעמד זה. לעדכון תקן 3 1850, כדי להביאו לשקף את השיטות הלא-קוויות, יכול להיות ערך בטוות הקצר. הסוגיה העיקרית היא, האס ניתן לשמור על רמת עדכון התקניס והקווים המנחיס הנלוויס להם, כך שתשקף את מגמות הטכנולוגיה הנוכתיות. הסיכון גבוה ביותר לגביי המשתמשיס בטכנולוגיות החדשות, וזו גס הקבוצה שתקבל את התמיכה המועטה ביותר מגישה זו. מיומגנות הבותחניפ בעיה נוספת הקשורה בגישה המבוססת על תקנים, היא הצורך במעריכיס בעלי יכולת טכנית, שרכשו ניסיון בתעשיה בה מתבצעת ההערכה. עד עתה מתקבל הרושס שהסכימה הבריטית של 116817 פתרה בהצלחה את הבעיה ההתחלתית של גיוס והדרכת קבוצת מעריכים. עס זאת, נותרה עדיין בעיית תחזוקת היכולת הטכנית של המעריכים. בהנחה שהתוכנה היא תעשיה הנתונה לשינוייס מהיריס, בה ההסמכה ניתנת לשלוש שנים בלבד ולאחריהן יש כבר צורך בהערכה חוזרת, כיצד יוכל מעריך שעוסק בהערכות במשרה מלאה לרכוש את הניסיון הדרוש בטכנולוגיות המתפתחות, כדי לשמר את האמינות שלו! הדרכה יכולה לסייע, אך יש הכרח גם בניסיון מעשי כדי להיות מסוגל להבין לאשורן את הבעיות שעומדות בפני המפתחים. פרק 10: הדרך שלפמינן | 223 הגישה המבוססת על מודליפ מודליס לאיכות וסכימות הערכה יותר ויותר אנו רואיסם סכימות הערכה המבוססות על איכות טוטלית (10 - עו|4) [10%), כגוו הערכת מלקולס באלדרידג' בארהייב והערכות דמינג ביפן. הגישה נשענת במידה רבה על הערכה עצמית (1ח8556556-)561), ונתמכת על ידי הערכה רשמית ובמידת הצורך גם יותר בלתי תלויה, כבסיס לקביעת יכולת החברה. אם כי המודלים שמשמשיס לסכימות השונות ייחודייס כולס, יש קווי דמיון מרשימיס ביניהס. יש כמובן גס קווי דמיון ברעיון של הערכה בלתי תלויה מול תקן כדוגמת 1 150. המודל האירופי שמשמש להערכת האיכות מוצג בתרשיס 10.1 ומתואר בתור דוגמה (1994 ,18%65). 6 0 ח0וז530ו331 6 ההוח ץסו|סק 6 צפטוהזו5 חט ו6גקוה] ץ1ו300 5נ טפט סח 2 חפט טוח 510 ב 5 ח0וו4115/00 וז 1 תדשים 10.1 המודל האירופי להערכת האיכות המודל מזהה תשעה גורמים שאובחנו כתורמים לאיכות. כל גורסם מקבל ציון אינדיבידואלי. הגורמיס האינדיבידואלייס מכונסיס לשני תחומים, תחוס המייצג את הגורמים שמאפשרים את האיכות (כיצד מנוהלות פעילויות האיכות של הארגון ומובאות לאופטימיזציה), ותחוס המודד את השיפורים העסקיים בפועל. לשתי הקבוצות משקל שווה במודל. המודל מאגד לא רק את האמצעיס להשגת איכות, הוא גס מודד את הביצועים התפעוליים והכספייס ואת ההשפעה שיש לארגון על החברה והסביבה. לכל אחד מהגורמיס שבמודל יש תיאור נלווה המתאר את מה שהגורס מבקש למדוד, וכיצד ניתן להעריך את הארגון מול גורס זה. מעריכים מיומנים יכולים לבצע השוואות אובייקטיביות בין ארגוניס על סמך גורמיסם אלה, וסכימת המודל האירופי להערכת האיכות משתמשת בהערכות כאלה לבחירת הזוכיס. 4 ניהול איכות תוכנה אפשר להשתמש במודל גס לצורך הערכה עצמית, על ידי הדרכת מעריכים מתוך הארגון. זאת הופכת להיות שיטה משמעותית להשגת שיפורים מתמידים, במסגרת שמאפשרת השוואות מול ארגוניס אחרים, ללא צורך בתחרות על הערכה חיצונית. המודל הישראלי לניהול איכות בתעשיה מפורט בנספח. גשלות התהליך והערכת היכולת תחילתה של 'תנועת' בשלות התהליך היתה למעשה, בשנות ה-80, כאשר המכון להנדסת התוכנה של אוניברסיטת קָרנגי-מָלון פיתח עבור מחלקת ההגנה של ארהייב שיטה להערכת תהליך התוכנה ומודל בשלות היכולת (- ₪006 עוזטזגוח 040801110 וא]א6). המטרה המקורית היתה לספק אמצעים להערכת קבלני פיתוח התוכנה. המודל הבסיסי שביסוד ההערכות מכיר בחמש רמות של בשלות. תרשים 10.2 מתווה את המודל. סכימות אחרות, כגון <יתוח האיכות והפריון של התוכנהי והישיטה להערכת תוכנהי של בריטיש טלקום, אימצו גישה דומה, אך מותאמת לתרבותם המסוימת. 5 עווזטוגות מו [ט6ן חסו1ה2ווחווקס יי 05 5 פווסווווווזסס ווח טוש , א ו 4 , 6 [וזשווושטס-זקקווו 8 ו , חסוזותו/06 / [שומ6טסזקחווו 6655סז] 6 3 6 2 605 וס 05060 הוח 5 0וו1605וו 00655ז] | 2 6 5 :ופשח 00161 50/6 1 קחזזס6תופח6 גת 1005!ו6וח 40 5 וה תרשים 10.2 מודל בשלות התהליך הנדסת תוכנה היא דיסציפלינה צעירה מאד. ככזאת, ניטור רמות הבשלות הינו חלק מתמונת הנוף שלה לעוד שניס רבות. להן מגבלות הגישה המבוססת על מודליפז הגישה המבוססת על מודלים מציגה קווי דמיון רבים לגישה המבוססת על תקנים. המודליס מכסים תחומיס רחביס יותר מאשר תקני האיכות, ומשקפים ערכים עסקיים במידה נרחבת יותר. עס זאת, תהליך הערכת הביצועים מול מודל המוגדר חיצונית דומה בתמציתו. כתוצאה מכך, גם על גישה זו חלות אותן מגבלות בסיסיות. פרק 10: חדרך שלפנינו | 225 הגישה המבוססת על מודלים היתה :כולה לטעון שהיא מחוללת פחות תקורות ביורוקרטיות ועלויות, אך ההערכה עדיין מהווה תכונה של גישה זו והיא התקורה הגבוהה מכולן. ההערכה מציבה גס בעיות אחרות. התחוס הרחב של המודלים לניהול האיכות מצריך מעריכים בעלי ניסיון רחב מאוד, ובעיית הגיוס, ההדרכה ואורך תקופת שירות חריפה יותר אפילו מזו של גישה המבוססת על תקנים. הפרשנות הדקדקנית של המודל יכולה גס היא ליצור בעיות, ומבחינה פוטנציאלית אלו גרועות יותר מאלו של הגישה המבוססת על תקנים משוס שהמודלים לניהול האיכות משפיעים על חלק גדול יותר של העסק. ככלל, הגישה המבוססת על מודליס היתה צעד לכיוון הנכון, אלא שהיא לא התגברה על כל מגבלות הגישה המבוססת על תקנים. גישת שיפור תהליכיס גישת שיפור התהליך מושרשת היטב בתנועת האיכות הכוללת (1)2 - שו[4טף [14סד). בפרק 6 דנו בנושאיס העיקרייס של הרעיונות והטכניקות, וגילינו שהמדידה היא נוהל המפתח של הגישה. שיפור מתמיד המבוסס על מדידיות הוא רעיון רב עוצמה, שיש בו פוטנציאל לא מוגבל לשיפורים, ועס זאת אינו מציג מודל של הנוהג הטוב ביותר. תקן 9000-3 150 מספק הנחיות לנוהג הקביל המזערי, ופעולה על פיו אינה יותר מאשר קו-בסיס מוצק לשיפורים. תקן 9000-3 150 דן במדידת התהליך והמוצר לצורך תחזוקת מערכת ניהול האיכות, אך בפועל, אינו מגדיר דרישה לשיפור מתמיד. כאשר קובעים את תקן 9000-3 150 כקו-בסיס סביר עבור הנוהג שלנו, ומשתמשיס בטכניקות של שיפורים מתמידים, יש לנו מנגנון לפיתוח מערכת איכות לטוות ארוך. תקן 9000-3 150 ינחה אותנו לעבר מערכת איכות מתועדת, וזו תשמש לנו כמגן מפני היסחפות שיכולה לקרות בכל מערכת שאין בה כלליס מוגדריס בבהירות. תרשים 10.3 מציג את תפקידה של מערכת איכות מתועדת בתור 'עוגןי שימנע את מערכת האיכות מפני השפעות הסתף. המערכת גוררת אחריה את העוגן כדי לוודא שכל רווח שיופק מהמנגנוניסם של השיפור המתמיד יהיה מוגן. משקל העוגן מייצג את התקורה הביורוקרטית של מערכת האיכות המתועדת. ללא ספק, עוגניס כבדים מאיטים את קצב ההתקדמות, אך גם שומרים על יציבות האוניה במיס הסועריס. תקן 9000-3 150 אינו רק קלט שימושי עבור המערכת שלנו. יש תחוס רחב של תקנים והנחיות של 150, 51א4, ואחריס שניתן לגייסם לשירות בתור קו הבסיס שלנו כדי שישמשו כנוהג הטוב ביותר. מודלים של בשלות התהליך ומודלים של הערכת איכות מספקים שכבה נוספת של הנוהג המשופר, והמבדקים (פחואזהמזהסת6ס), או השוואת ביצועיס, יכוליס לספק מטרות אתגריות יותר בטווח הארוך. 6 נלהול איכות תוכנה ואסד / תרשים 10.3 מערכת ניהול האיכות (0₪15) בתור עוגן תוכניות לשיפור מתמיד יכולות להתגבר על מגבלות הגישות המבוססות על תקניס וגישות המבוססות על מודלים, ועס זאת הן זקוקות לקו-בסיס של נוהג טוב. לתקניס ולמודליס יש אם כן תפקיד חיוני עדיין. לארגוניס רביס, הנתיב המוביל יהיה כדלקמן: * צור מערכת ניהול איכות מתועדת שעומדת בדרישות התקנים 9001 150 ור 9000-3 150; * צור תהליך לשיפור האיכות שיהיה מבוסס על מדידות; * שפר את המערכת הבסיסית כדי שתהיה תואמת למודל נבחר מסוים, או שתגיע לרמת בשלות ; * המשך לשפר את המערכת לאחר מבדקים, תוך התקדמות לעבר מטרת הטוות הקצר שמיועדת להשיג את מתחריך המיידיים ולעבר מטרת הטווח הארוך, שהיא השגת אלה המוליכיס בשוק. גישה זו משתמשת בכל הגישות הזמינות כדי שהאחת תשלים את האחרת, וכדי ל מנגנון שיתגבר על רוב המגבלות של כל אחת מהגישות בפני עצמה. לאן עכשיוז לאן אנו הולכיס עכשיו: כיצד נראה עתיד הנדסת התוכנה! לנוכת ההתקדמות הטכנית של העשור האחרון, קשה לחזות מה :כול לקרות בעשור הבא. הטכניקות והכלים ישתפרו ללא ספק, והשינוי עשוי להיות כה גדול עד שאי אפשר יהיה להכירס כשנשווה אותס לטכנולוגיה של ימינו. דרושה מסגרת שתציג את הגישה ההתפתחותית (אבולוציונית) לפיתוח תוכנה, בכך שתיצור ארכיטקטורה ותאכלס אותה ביישומים הספציפיים המתאימיס ככל שהם נעשיס זמינים. בהקשר האיכות, הפעולה המקבילה תהיה יצירת מסגרת בה ניתן יהיה להכניס תקנים, מודלים, טכניקות, או כליס ככל שהם נעשים זמינים. במקוס להמשיך ולפתח כל הזמן קבוצה ספציפית של קוויס מנחים כגון תקן 43 15600, נוכל להגדיר קבוצה נוכחית של תקני קו-בסיס. אלה מהוויס את ההגדרה הטובה ביותר של הנוהג הטוב, שתהיה זמינה לציבור הרחב באותה עת. הנוהג הטוב פרק 10: הדרך שלפמנן | 227 ישתנה באופן בלתי נמנע, וצפוי שקצב השינוייס יוא במרוצת העשור הבא, אך המקור של הנוהג הטוב לא יהיה במסמך אחד יחיד. תהיה לנו גישה אל ספרייה שלמה של תקניס ומודליס ההולכיס ומתפתחיסם ומשימת המפתח תהיה זיהוי של תת-הקבוצה של מסמכים אלה, שתהיה החשובה ביותר באותה עת. גיכוש הגישות בעת כתיבת שורות אלו מנסה הפרויקט - 52105 (זח6ות6טסזקות] 2700655 6:ז8ש508 00נו8הוהה6ו65 עזו|ו80ק04), לכנס יחד את האלמנטים העיקרייסם של השיטות הקיימות. בתרשיס 10.4 (וראה גס תרשיס ח.5.1), משלבת גישת 52165 את תהליך ההערכה בידי מעריכים מאומנים, יחד עם הנחיות לנוהג הטוב ביותר, וקוויס מנחיס לשיפור התהליך. כיוון מקביל עוסק בנושא הגדרת היכולת, כך מתאפשרים זיהוי העוצמות והחולשות וקביעת מטרות ספציפיות לשיפורים. פרויקט 52105 מגלס היבטיס של גישות המבוססות על תקניס וגישות המבוססות על מודלים, והוא אמור לפחות לגבש מצב שבעבר התחרו בו למעשה זו בזו מספר גישות חלופיות. ברור פחות, אס יוכל לספק את היכולת ההתפתחותית המהירה שתאפשר לו לשקף דרך קבע את המצב הנוכחי של הטכנולוגיה והטכניקות ואת הנוהג הטוב ביותר בניהול האיכות. ו וו [ גל ג סו ב ]355055 בי )ח6ות6שסזקוחו ץז 6330 חסוזבחווחזט61 סו 606) קסות תרשים 10.4 מסגרת פרויקט 57165 מסגות להתפתחות מה צריכה להכיל מסגרת התפתחותית (אזסאוסות8ז) /זהחסווט!סצ6): ודאי שעליה לשמר לפחות את כל החלקיס הטוביס שיש בגישות הקיימות. עס זאת, עליה להשתדל גס ליצור מבנה ארכיטקטוני בו יוכלו להיטמע בנקל כל הפיתוחים החדשים תוך מינימום מוחלט של תקורה מנהלית. ההשהיות הנאכפות היום על השיטות הנוכתיות עקב 8 ניהול איכות תוכנה הצורך בניסוח מסמכי התקניסם ואישורם, תהיינה בלתי נסבלות בטכנולוגיה העתידית המואצת. מה תכיל הארכיטקטורה ההתפתחותית? אין כל ספק שנצטרך למצוא דרכים טובות *ותר לטיפול בפיתוח הלא-קווי האיטרטיבי, משוס שברור שעוד נרבה לראות דרך פיתוח זו, אחריה יוסיפו לבוא שיטות עס מחזורי חיים אקזוטיים יותר. שיפור תהליכים, מבוסס על מדידות, שיתבסס על תרבות האיכות הכוללת (13), יהיה ללא ספק הצעד הבא עבור אלה שאימצו כבר את מנגנון אישור ההסמכה. עבור אחריס שמפקפקיס במנגנון זה, יהיה זה תחליף מתאים. עס זאת, כדי שהדבר יתאפשר, יהיה צורך לפתת נהגים לשיפור תהליכים שיתאימו לארגונים, משוס שבשעה שהס מתחיליס בתוכנית השיפורים, מודעותם לנושא האיכות מצומצמת מאוד, או כלל לא קיימת עדיין. נוכל לדמיין לעצמנו עתיד בו יתפסו הארגוניס מקומות שונים בטבלת האיכות. יהיו כאלה שינצלו את הטכנולוגיה המתקדמת ביותר, ואת נהגי ניהול האיכות המתקדמים באותה מידה; אחריס ישתמשו בטכנולוגיה הבסיסית ביותר, ולמעשה ללא נהגי איכות שיתמכו בהם; ויהיו גם כאלה שיימצאו בשלביס שונים שבין קטביס אלה. תרשיס 5 מציג את הטבלה המציגה מיקומים שוניס ברשת. הניסיון מלמדנו שההתקדמות לעבר האזורים יהטוביסי של הטבלה רצוי שתיעשה בשלבים. כל ניסיון להתקדס רחוק מדי בכיוון מסוים, מבלי להתקדס במקביל גס לאורך הציר האחר מהווה הזמנה לכישלון. תופעה דומה נצפתה עם המעבר לשימוש בכלים לסיוע בשיפור התהליך. עודף אוטומציה בפרויקט שלא הוגדר כהלכה מוליך לסיכונים מוגברים; תמיכה מועטה מדי בשיפור התהליכים יכולה להוביל לעודף ביורוקרטיה. כדי להיות שימושית בכל המצבים, חייבת מסגרת שיפור האיכות לאפשר לארגוניס לזהות היכן הס נמצאיס בשני הצירים, ולנסת תוכניות שיובילו אותס בכיוון הנכון. דבר וה משמעותו, לא רק הערכת יכולת התהליך אלא גס הערכת היכולת הטכנית ותמיכת הכלים, והגדרה ברורה של השאיפות העתידיות של הארגונים, במונחיס של שיטות וטכניקות שלדעתס יצטרכו להיות מסוגלים לנצל. כדי להיות אפקטיבית באמת, חייבת המסגרת להגדיר את הארכיטקטורה של עצמה ולדאוג לממשקיס סטנדרטיים עבור כלים, טכניקות ומדידות שיהיו תואמים אותם. למשל, כל טכניקה חדשה לפיתוח תוכנה, יהיה צורך להגדיר במונחיס של כלי הבקרה העיקרייס שיוטבעו בה, המדידות העיקריות שתידרשנה לבקרה ולשפרה, והכלים שיימצאו מתאימים לתמיכה בה. בדומה לכך, כל כלי לשיפור תהליכים יהיה אמור להדגים את יכולתו לאסוף ולנתח את המדידות הקשורות לתהליכיס הרלוונטיים. המסגרת המתוארת כאן מרחיקה מאוד מעבר ליכולת הנוכחית, עס זאת היא מייצגת הצעה לפיתוח עתידי. זו השעה הנכונה לקבלת החלטות בדבר הכיווניס העתידיים. כשפרויקט 52105 יהיה זמין, הוא יספק תמיכה ביוזמות איכות קיימות, תוך תכנון ויישוס יוזמות עתידיות. פרק 10: הדרך שלפמנו | 229 ץוו|ט הוח וז !16600 666חג 40 660 86 וח6!%ע5 ע]ו|4טף טזטוגוח 6חה ץזו|הטף טזטוהות הוושש וחטו9 זו שחוזט6הופח6 660 0 9 ץקה ת6ט 030060 ץח 60 3516 זו |הטף [הוחזס] 1/1016 וטט 5 100 007 806 ]ו טט הגוה תרשים 10.5 טבלת הבשלות האיכותית/טכנולוגית בדומה לכל פיתוח התפתחותי, המסגרת מייצגת יותר משאפשר להשיג בפרויקט יחיד. היא מייצגת אסטרטגיה רחבה, ארוכת טווח שאפשר ליישמה ככל שהמשאבים נעשים זמינים. כל צעד בפיתוח יחשוף אפשרויות חדשות ובעיות שלא צפו קודס, ודבר זה יאפשר תכנון חוזר והתאמת היעדיס הסופיים. הדבר החשוב מכל הוא נוכחותס המתמדת של יעדיס לטווח ארוך המנחיס את מאמצ הפיתוח של הטווח הקצר. שאלות, שאלות נחתוס בהצעת מספר שאלות שיש לשקול בעת הגדרת אסטרטגיה לטווח ארוך. אלו שאלות שעלינו לשוב ולשאול תמיד, ושלעולס לא תהיה להן תשובה סופית. אילו שיטות הן הטובות ביותר? עד כמה חשוביס התקנים! אילו כליסם הס הטוביס ביותר! איזה חלק מכל זה עלי לבצעז מה עלי למדוד! אילו טכניקות חדשות עלי ללמוד! למעשה, אין סוף לשאלות, וכל תשובה תהיה זמנית בלבד. לכן חשוב לסקור כל הזמן את התגובותיך לשאלות אלו, כדי לוודא שחשיבתך מתקדמת יחד עס העולס סביבך. 0 ניהול איכות תוכנה או וד על אף כל השינויים ואי-הוודאות, יש עדיין עקרונות כלליים שראוי לשקול, כדי לוודא שתוסיף להימשך כל העת אל כיווניס חדשיס, כתגובה לאופנות המתחלפות. ב-... וו וו" העקרונות הנצחיים של פיתוח התוכנה 1 כ סי .0 המדידה כמעט שאינה מנוצלת עדיין מרביס לדבר היוס אודות המדידה, אך עדיין קשה מאוד לגלות ברוב הארגוניס פעילות ממשית בתחוס זה. למי שיקדיס ללמוד כיצד לנצל ביעילות את המדידה יהיה יתרון מוקדם וחשוב על פני מתחריו. השתמש בתקנים הקיימים בתור קו-בסיס בפרק 1 אמרנו שההנדסה היתה מבוססת על עקרונות רחבים ונצחיים. על אף כל החולשות שחשפנו בתקנים, בכל זאת הס מגלמים עקרונות נצחייס ממין זה ולכן, מספקים נקודת התחלה מוצקה מאוד בתחום האיכות. בחזרה אל היסודות העקרונות הנצחייס של ההנדסה (ושל מקצועות אחרים) אכן נצחיים, משוס שהםס מבטאיס את הרעיונות הבסיסיים ביותר ללא כל תוספות. אין זה מקרה שהחזיקו מעמד במשך דורות. למד מהס. נסה לקבוע את קבוצת העקרונות שלך והערך את ארגונך מול עקרונות אלה. המשך לשוב ולהגדיר את האיכות ההגדרות צריכות להיעשות במונחים של הלקוח כדי שמאמצי האיכות שלך יצטרכו לעמוד כל הזמן באתגרים של רעיונות חדשיס, אשר יאלצו אותך לשקול את השפעת מערכת האיכות שלך כלפי חוץ במקום כלפי פנים. המשך במאמצי ההערכה והתייצב מול הסיכונים הנוכחיים מה מאיים על איכות מוצריך: מהן הציפיות החדשות שלקוחותיך עתידים להביע בשבוע הבא או בשנה הבאה!? מה עושים מתחריך כדי להעשיר את איכות מוצריהם! חפש כל הזמן אחר מבדקים (05ז6104ח56) מדוד עצמך מול מבדקים אלה, כדי שתוכל לקיים את התמריץ לשיפורים. המשך לחפש דרך התפתחותית (אבולוציונית) המהפכות הן כמעט תמיד עקובות מדם וגם לא יציבות. הישמר מפני ידענים שמוכרים רק רעיונות אתה חייב למכור מוצרים. הישמר מפני מומחים להנדסת תוכנה שבא להם רעיון מבריק בשנה הבאה יהיה להס בוודאי רעיון חדש שיעשה את הרעיון הנוכתי למיושן. הישמר מפני פטנטים וגימיקים איכות אמיתית מוצגת כמעט תמיד בלשון ההמעטה - היא מדברת בעד עצמה. == | פרק 10: הדרך שלפמנו ‏ 231 [ספת ₪! תקן ישראלי ת''י 2000-5 1500 23 תקני ניהול איכות והבטחת איכות הנחיות ליישוס ת''י 2001 לשס פיתוח, הספקה ותחזוקה של תוכנה הועתק ברשות מאת מכון התקנים הישראלי. בכל מקרה מחייב התקן העדכני של מכון התקנים הישראלי. כל הזכויות שמורות למכון התקנים הישראלי. אין לצלם, להעתיק, לפרסם או לתרגם תקן זה או קטעים ממנו ללא רשות מראש ובכתב ממכון התקנים הישראלי 69 1992. נספח א': ת''י 2000-3 = 233 תוכן הענייניס מילות מפתת |[ || -/-/-..-;];;/[/[/]/-///// 0 רשימת מונחיס ו .|| .0 = ₪ רש 2 .5 נספח א: הפניה הדדית בין סעיפי תייי 2000-3 לבין תייי 2001 נספח ב: הפניה הדדית בין סעיפי תייי 2001 לבין ת'יי 2000-3 הקדמה תחוס התקן איזכוריס || .|| .|| הגדרות 0 מערכת איכות - מסגרת ןווי | | 1 אחתריות ההנהלה 0 2 מערכת איכות ...]|| 2 - 3 מיבדקי איכות פנימיים 4 פעולה מתקנת || מערכת איכות - פעילויות במחזור החייס 1 כללי ה 2 סקר החוזה 3 מפרט דרישות הלקות 4 תכנון הפיתותח 5 תכנון האיכות 6 תֶּכֶן ומימוש ו ה 7 בדיקה והוכחת תקיפות 8 9 שכפול, מסירה והתקנה 0 תחזוקה || ו מערכת איכות - פעילויות תומכות 1 ניהול תצורה ו | || ....- 2 בקרת מסמכים .]|| .. 3 רשומות האיכות 4 מדידה 0 5 כללים, נהגים ומוסכמות 6 כלים וטכניקות 7 רכש /--/-/]-/-.----- | | 8 מוצר תוכנה משולב 4 ניהול איכות תוכנה ו ב 0 ו ב כ ב ו ב מילות מפתח: הבטחת איכות 6 811 מערכות הבטחת איכות 65 06מ18ט355 ע11|בּטף תכנות תק סזק טכניקות תוכנה 65 506 עיבוד נתוניס 8ַת006551זק 6818 רשימת מונחים: בדיקות תקדימיות 5 בדיקות קצה . 5 ג מטסס גופן ]הס כילולי 46 שטוו כילוליות םוז זק6זתו תכן 6518 נספת אז'י: תייי 2000-3 205 0. הקדמה עם התפתחות טכנולוגיית המידע גדלה כמות מוצרי התוכנה, וניהול האיכות של מוצרי התוכנה הפך חיוני. אחת הדרכיס להקים מערכת ניהול איכות היא באמצעות הנחיות ברורות להבטחת איכות תוכנה. הדרישות ממערכת איכות כללית, למצביס בהס שני צדדים חתומים על חוזה, פורסמו זה מכבר בתקן הישראלי תייי 2001 - יימערכות איכות - מודל להבטחת איכות בתיכון, בפיתוח, בייצור, בהתקנה, במתן שירות ובתחזוקהיי. אולס תהליך הפיתוח והתחזוקה של תוכנה הינו שונה ממרבית הסוגים האחרים של המוצרים התעשייתיים. לכן, יש צורך לספק בתחוס טכנולוגי אה, המתפתח במהירות, הנחיות נוספות למערכות איכות שמעורבים בהן מוצרי תוכנה. הנחיות אלו צריכות לקחת בחשבון את מצבה הנוכחי של טכנולוגיה זו. אופי הפיתוח של תוכנה הוא כזה, שפעילויות מספר קשורות לשלביס מסוימים של תהליך הפיתוח, בעוד שאחרות מתבצעות בכל שלב של התהליך. מבנה ההנתיות נועד לשקף את ההבדלים הללו. אין התאמה ישירה בין תסדיר מסמך זה לתסדיר תייי 2001, ולכן מובאיס להלן שני אינדקסיס (נספתח אי ונספת בי), המיועדים לסייע בכל התייחסות לתקן זה. חוזים בין שני צדדיס למטרת פיתוח תוכנה יכוליס להופיע בצורות שונות. במקריס מסוימים לא ניתן ליישס הנחיות אלו בחוזה בין שני צדדים, אפילו אס יינתפרו" במיוחד למטרה זו. לכן חשוב לקבוע אם ישנה התאמה מספקת בין יישומו של תקן זה לחוזה. תקן זה דן בעיקר במצביס שבהס תוכנה ספציפית מפותחת כחלק מחוזה ובהתאס למפרט הלקוח. אולס התפישה המתוארת יכולה להיות בעלת ערך גס במצביס אחרים. הערות : 1. שימוש בלשון זכר במסמך זה אינו אלא עניין של נוחות, וכל התייחסות לאנשיס כוללת גם את הנשיס. באופן דומה, שימוש ביחיד אינו בא להוציא מהכלל שימוש ברבים (ולהיפך), וזאת כאשר ההיגיון מרשה זאת. בכל מקוס במסמך זה שבו לא ניתנו הנחיות חדשות, הובא הטקסט של הסעיף הרלוונטי מתוך ת'יי 2001 והוא מודפס בגופן (ותס+) שונה. במסמך זה יש מספר רשימות שאף לא אחת מהן אינה נחשבת מלאה. הרשימות מובאות כדוגמות בלבד. " 1. תחום התקן חלק זה של תייי 2000 מציג הנחיות הבאות להקל על יישוס ת'יי 2001 בארגוניס המפתחים תוכנה, מספקים תוכנה ומתחזקיס אותה. 6 ניהול איכות תוכנה הכוונה היא לתת הנחייה במקריס שבהס חוזה בין שני צדדים מצריך הוכחה ליכולתו של הספק לפתח מוצרי תוכנה, לספקס ולתחזקס. ההנחיות בחלק זה של תייי 2000 מיועדות לתאר את הבקרות המוצעות ואת השיטות ליצירת תוכנה, שתעמודנה בדרישות הלקוח. הדבר מושג בעיקר על ידי מניעת אי התאמה בכל השלבים, החל מהפיתוח ועד לתחזוקה. ההנחיות בחלק זה של ת'יי 2000 מתאימיסם למצבים של חוזים למוצרי תוכנה שבהם: א. החוזה דורש במפורש מאמצ תֶכְן (ם66518), והדרישות מהמוצר מוגדרות בעיקר במונחי ביצוע, או שיש להגדיר אותן. ב. ביטחון במוצר יכול להיות מושג על ידי הדגמה נאותה של יכולת ספק מסויס לפתח מוצר תוכנה, לספקו ולתחזקו. 2. איזכורים בתקניס המפורטיס להלן ישנה הכנה לתוספות עתידיות. חלק מתוספות אלו מתמלא על ידי הפניות מטקסט זה. תוספות אלו מהוות שינוי למהדורה הקיימת של אותס תקנים ולמעשה הן מהוות מהדורות חדשות. בזמן הפרסוס היו המהדורות המצוינות להלן בתוקף. כל התקנים צפויים לשינוייס ועל הצדדיס השותפים להסכמים המבוססיס על תקניס אלה, לבדוק את האפשרות להשתמש במהדורות האחרונות של התקנים המפורטיס מטה. לחברי 186 ו-150 יש רשימה מעודכנת של התקנים הבין- לאומיים שבתוקף. בסעיפיס שוניס של התקן הבין-לאומי ישנה הפניה לתקנים בין-לאומיים, במקומס באיס תקניס ישראליים כמפורט להלן: תייי 1432 (8402 150) | איכות - הגדרות מונחים. תייי 2000 (9000 150) תקני ניהול איכות והבטחת איכות - הנחיות לבחירה ולשימוש. תייי 2001 (9001 150) מערכות איכות - מודל להבטחת איכות בתיכון, בפיתוח, בייצור, בהתקנה, במתן שירות ובתחזוקה. תייי 2004 (9004 150) מערכות איכות - אלמנטים במערכות איכות וניהול איכות : הנחיות. תייי 1080 חלק 1 (2382/1 150) עיבוד נתוניס אוטומטי - הגדרות מונחיס: מונחיס בסיסייס. 3 הגדרות למטרות תקן בינלאומי זה יפה כוחן של הגדרות התקן הישראלי ת"י 1432 (8402 כ150), התקן הישראלי תייי 1080 חלק 1 (2382/1 150) והגדרות אלו: נספח א': תייי 2000-3 27 1 תוכנה: יצירה אינטלקטואלית אשר כוללת תוכניות, נהליס, חוקיס וכל תיעוד הקשור אליהס, המתייחסים להפעלה של מערכת עיבוד נתונים. הערה 4: התוכנה אינה תלויה במצע שעליו היא נרשמה. 2 מוצר תוכנה: מכלול תוכניות מחשב, נהלים, תיעוד נלווה ונתוניס המיועדיס למסירה למשתמש. 3 פריט תוכנה: חלק של מוצר תוכנה שאפשר לזהותו והנמצא בתהליך פיתוח או בסיומו. 4 פיתוח: כל הפעילויות הדרושות ליצירת מוצר תוכנה. 5 שלב: קטע מוגדר של עבודה. הערה 5: שלב אינו מרמז על שימוש במודל של מחזור חייס כלשהו, ולא על פרק זמן בתהליך הפיתוח של מוצר תוכנה. 6 אימות (לתוכנה, ם10ז164ז6צ): התהליך של הערכת המוצריס בשלב נתון, כדי להבטיח נכונות ועקיבות ביחס למוצריס ולתקניםס שסופקו כקלט לשלב זה. 7 הוכתת תקפות (לתוכנה, םסגז43ג1ג+) : התהליך של הערכת תוכנה, הבא להבטית התאמה לדרישות מפורטות. 4. מערכת איכות - מסגרת 1 אחריות ההנהלה 1 אחריות הנהלת הספק 1 מדיניות האיכות הנהלת הספק תגדיר ותתעד את מדיניות האיכות שלה, את מטרותיה ואת מחויבותה לאיכות. הספק יבטיח שמדיניות זו תובן, תיושס ותישמר בכל דרגי הארגון. [תייי 2001: 1990, 4.1.1] 2 ארגון 1 אחריות וסמכות חלוקת האחריות והסמכות ויחסי הגומלין שבין כל העובדיס אשר מנהלים, מבצעיס או מאמתיס עבודות, המשפיעות על האיכות, יהיו מוגדריס היטב. חשוב להגדיר זאת במיוחד לגבי אותס עובדיס, הזקוקיס לעצמאות ארגונית ולסמכות לבצע את הפעולות שלהלן: א. ליזוס פעולות שימנעו אי-התאמה של המוצר. ב. לזהות ולתעד בעיות באיכות המוצר. 8 ניהול איכות תוכנה הדורקידדחן לייהידהדההיזודדהורידדחה" הור החחר--=---- ג. | ליזוס, להמליץ או לספק פתרונות בדרכים הקבועות בארגון. די לוודא את יישוס הפתרונות. ה. לבקר את. המשך העיבוד, ההספקה או ההתקנה של מוצר לא-מתאים עד שליקויו יתוקן, או עד שיתוקן מצב שהיה לא משביע רצון. [ת"י 2001: 1990, 4.1.2.1] 2 א'ימות - משאבים ועובדים הספק יזהה את דרישות האימות התוך-ארגוניות ויקצה משאביס נאותיס ועובדיס מיומנים לפעילויות האימות (ראה סעיף 6.9). פעילויות האימות יכללו בחינה, בדיקה וניטור של תהליכי התיכון, הייצור, ההתקנה של המוצר או מתן השירות. סקרי תיכוּן ומיבדקיס של מערכת האיכות, של התהליכים או של המוצר יבוצעו על ידי עובדיס, שאינס תלוייס באלה שלהס אחריות ישירה לעבודה המבוצעת. ת''י 2001: 1990, 4.1.2.2] 343 נציג ההנהלה סמכות הספק ימנה נציג הנהלה, אשר בלא קשר לתפקידיו האחרים, יהיה בעל ואחריות מוגדרות, כדי להבטיח שדרישות תקן זֶה ייושמו ויישמרו. [ת''י 2001 : 1990, 4.1.2.3] 3 סקר ההנהלת ים לדרישות הנהלת הספק תסקור תקופתית את מערכת האיכות שנבחרה כדי להתא ול תקן זה, ותבטיח בכך את ההמשכיות של התאמת מערכת האיכות ואת ה שלה. הרישומים של סקריס אלה יישמרו. ר, י האיכות הערה: סקרי ההנהלה כוללים, בדרך כלל, הערכה של תוצאות מ 0 איכות הפנימיים, הנערכים על ידי הנהלת הספק או בשמה, להבדיל מביצוע כ פנימי על ידי העובדים והמנהליס האחראים ישירות למערכת האיכות. [תייי 2001 : 1990, 4.1.3] 2 אחריות הנהלת הלקוח כן יחליט הלקוח ישתף פעולה עם הספק ויספק לו בומן את כל המידע הדרוש. כמו כן הלקות בנושאים העומדים על הפרק. , 0 הלקוח ימנה נציג שיהיה אחראי לניהול משא ומתן עם הספק בנושאים הקשורים לחוזה. לנציג וה תהיה הסמכות, בהתאס לצרכים, לנהל משא ומתן עס הספק בנושאיס הכוללים את הפרטים שלהלן, אך שאינס מוגבליס על ידם א. הגדרות הדרישות של הלקוח מהספק; ב. מתן תשובות לשאלות הספק; נספח א': תי 2000-3 | 239 ג. | אישור הצעות הספק; ד. הבאה לידי הסכסם עס הספק; ה. הבטחה שארגונו של הלקות מקייס את ההסכמים שנערכו עס הספק; ו. | הגדרת קריטריוניס ונהליס לקבלה; ז. | טיפול ברכיבי תוכנה שסופקו ללקוח ונמצאו לא מתאימים לשימוש. 3 סקרים משותפים יש לקבוע לוח זמניס לסקרים משותפים לספק וללקות, כדי שיובטחו ההיבטים הבאים: א. התאמת התוכנה למפרט הדרישות המוסכס עס הלקוח; ב. תוצאות האימות; ג. | תוצאות בדיקת הקבלה. התוצאות של סקריס מסוג זה יהיו מוסכמות ויתועדו. 2 מערכת איבות 1 כללי הספק יקים ויקיים מערכת איכות מתועדת. מערכת האיכות תהיה תהליך כילולי (16818160ת1) לכל אורך מחזור התיים, כדי להבטיח שהאיכות היא חלק מתהליך הפיתוח, ולא דבר המתגלה בסופו של התהליך בלבד. יש להתמקד במניעת בעיות, ולא בתיקון לאחר שהתגלתה בעיה. הספק יבטיח שמערכת האיכות המתועדת תמומש בצורה יעילה. 2 תיעוד מערכת איבות יש לתעד בצורה ברורה, שיטתית ומסודרת את כל אלמנטי מערכת האיכות, את הדרישות ואת ההוראות. 3 תוכנית איכות הספק יכין תוכנית איכות ויתעדה, כדי לממש פעילויות איכות לכל פיתוח תוכנה על בסיס מערכת איכות, וכדי להבטיח שהיא מובנת ומקוימת על ידי הארגוניס הנוגעיםס בדבר. 3 מיבדקי איכות פנימיים הספק יפעיל מערך מקיף של מיבדקי איכות פנימיים, מתוכנניס ומתועדים, כדי לאמת שפעילויות האיכות מתאימות לסידוריס המתוכנניס וכדי להעריך את האפקטיביות של מערכת האיכות. 0 ניהול איכות תוכנה מיבדקי האיכות יתוזמנו בהתאס למצבה ולתשיבותה של הפעילות. עורכיס את המיבדקיס ואת פעולות המעקב לפי נהליס מתועדיס. מתעדיס את תוצאות המיבדקים ומעביריס אותן לאחראיס לתחומים שנבדקו. המנהל האחראי לתחוס שנבדק ינקוט במועד פעולה לתיקון הליקוייס שנתגלו במיבדק. (תייי 2001: 1990, 4.17] 4 פעולה מתקנת הספק יקים, יתעד ויקיים נהליס שישמשו כלהלן: א. לחקור את הגורמיס למוצר לא-מתאים ולפעולה המתקנת הנדרשת למניעת הישנותס. ב. לנתח את התהליכים, שיטות העבודה, אישור החריגים, רשומות האיכות, דוחות השירות ותלונות הלקותות, כדי לגלות ולסלק את הגורמים הפוטנציאלייס למוצריס הלא-מתאימים. ג. | ליזוס פעולות מנע לטיפול בבעיות ברמה המתאימה לסיכונים הצפויים. ד. | להפעיל בקרה כדי להבטיח שהפעולות המתקנות ננקטו ושהן אפקטיביות. ה. ליישס ולתעד את השינוייס בנהליס הנובעיס מהפעולות המתקנות. [תייי 2001 : 1990, 4.14] 5. מערכת איבות - פעילויות במחזור החיים 1 כללי פרויקט של פיתוח תוכנה יאורגן בהתאם למודל של מחזור התיים. פעילויות הקשורות לאיכות יתוכננו וימומשו בהתאם לאופי המודל של מחזור החיים שנבחר. חלק זה של תייי 2000 מיועד ליישוס ללא קשר למודל של מחזור החיים שנבחר. אפשר ל לתת פירושים אחדים לכל תיאור, הנחיה, דרישה או מבנה, אך אין בכך כדי להצביע שהדרישה או ההנחייה מוגבלות למודל כלשהו. 2 סקר החוזה 1 כללי הספק יקים ויקיים נהליס לסקר החוזה ולתיאוס בין פעילויות אלו. כל חוזה ייסקר על ידי הספק, כדי להבטיח מילוי תנאיס אלה: א. תחוס החוזה והדרישות מוגדריס ומתועדים; ב. החלופות וסיכוניס אפשרייס מזוהים; נספח א': תייי 2000-3 = 241 ג. = המידע שבבעלות הספק מוגן בצורה מספקת ; ד. כל דרישה השונה מזו הכלולה במכרז תידון בנפרד; ה. לספק יש היכולת לעמוד בדרישות החוזה; ו. | אחריות הספק לעבודה של קבלני משנה מוגדרת ; ז. | המינות מוסכם על שני הצדדים ; ח. ללקוח יש היכולת לעמוד במגבלות החוזיות. רשומות של סקרי חוזה מסוג זה יישמרו. 2 סעיפי איכות בחוזה בין השאר, בדרך כלל, מתאימיס הסעיפיס שלהלן להיכלל בחוזה: א. קריטריוניס לקבלה; ב. טיפול בשינוייס בדרישות הלקוח במהלך הפיתוח; ג. | טיפול בבעיות שהתגלו לאחר הקבלה, לרבות בטענות הקשורות לאיכות ובתלונות הלקות; ד. | פעילויות המבוצעות על ידי הלקוח, ובמיוחד, תפקידו של הלקוח בעת הגדרת מפרט הדרישות, בעת ההתקנה ובעת הקבלה; ה. אמצעים, כלים ופריטי תוכנה שיסופקו על ידי הלקוח; ו תקניס ונהליס שישתמשו בהס; ז. | מספר העותקיס הנדרש (ראה 5.9). 3 מפרט דרישות הלקוח 1 כללי כדי להתקדם בפיתוח התוכנה, יהיו בידי הספק דרישות פונקציונליות מפורטות וחד- משמעיות. גוסף על כך צריכיס להיכלל בדרישות אלו כל ההיבטיס הדרושיס כדי לספק את צורכי הלקוח. להלן רשימה של היבטים אפשריים, אך שאינס מוגבליס לביצועים, בטיחות, אמינות, אבטחה ופרטיות. דרישות אלו יצוינו בצורה ברורה ומדויקת, כדי שניתן יהיה להוכיח תקיפות בעת קבלת המוצר. דרישות אלו רשומות במפרט דרישות הלקותח. במספר מקריס מסופק מסמך זה על ידי הלקות. אם לא, יִפַתָח הספק דרישות אלו בשיתוף פעולה הדוק עס הלקותח. הספק יקבל את אישור הלקוח לפני היכנסו לשלב הפיתוח. מפרט דרישות הלקות יהיה כפוף לבקרת תיעוד ולניהול תצורה כחלק מהתיעוד של שלב הפיתוח. במפרט יפורטו דרישות הלקוח במלואן, בצורה ישירה או על ידי הפניה, כל המישקים שבין מוצר התוכנה לבין תוכנות אחרות, או מוצרי חומרה. 2 ניהול איכות תוכנה ו 2 שילתוף פעולה הדדי במהלך פיתוח מפרט דרישות הלקוח, מומלצ לשיסם לב לנושאיס אלה: א. מינוי אנשיס (משני הצדדים) האתראים לכתיבת מפרט דרישות הלקות; ב. שיטות הסכמה לדרישות ואישור שינויים ; ג. | מאמציס למניעת אי הבנות באמצעים, כגון: הגדרת מונחים או הסבריםס הקשוריס לרקע הדרישות; ד. רישוס תוצאות הדיוניס על ידי שני הצדדיס וסיקורן. 4 תכנון הפיתוח 1 כללי תוכנית הפיתוח תכלול את הנושאיס האלה: א. הגדרת הפרויקט בהתייחס לפרויקטים קשורים של הלקוח, או של הספק, לרבות הצהרה על מטרות הפרויקט; ב. ארגון משאבי הפרויקט, לרבות מבנה צוות הפיתוח, תחומי אחריות, שימוש בקבלני משנה ובמשאביס חומרייס ; ג. | שלבי הפיתוח, כמוגדר בסעיף 5.4.2.1 ; ד. | לוח זמנים של הפרויקט, אשר ניתן לזהות בו את המשימות לביצוע, את המשאביס והזמן הדרושים לכל משימה ולכל קשרי הגומלין בין המשימות; ה. זיהוי תוכניות הקשורות בנושא, כגון: - | תוכנית איכות; - | תוכנית ניהול תצורה; - | תוכנלת כילולית (4164זק6וחו) ; - | תוכנית בדיקה. תוכנית הפיתות תעודכן ככל שהפיתוח מתקדם, וכל שלב יוגדר כמפורט בסעיף 1, לפני שמתחילים בפעילויות הקשורות לאותו שלב. השינויים יסוקרו ויאושרו לפני הביצוע. 2 תוכנית הפיתוח 1 שלביס תוכנית הפיתוח תגדיר תהליך מסודר או שיטה להפיכת מפרט דרישות הלקוח למוצר תוכנה. לשם כך ייתכן שיהיה צורך לחלק את העבודה לשלביס ולזהות את הפרטים האלה: א. שלבי פיתות לביצוע; ב. הקלטיס הנדרשים בכל שלב; נספח א'; תייי ג-2000 23 ג. = התוצרים הנדרשיס מכל שלב; ד. נוהלי אימות שיש להפעיל בכל שלב; ה. ניתוח בעיות פוטנציאליות הקשורות לשלבי הפיתות ולעמידה בדרישות המפורטות. 2 ניהול תוכנית הפיתוח תגדיר כיצד ינוהל הפרויקט, לרבות זיהויס של פרטיס אלה: א. לוח הזמניס של הפיתוח, המימוש וההספקה ; ב. בקרת התקדמות העבודה; ג. | תחומי אחריות ארגוניים, הקצאת משאביס ומטלות עבודה; ד. מישקים ארגוניים וטכניים בין קבוצות שונות. 43 שיטות וכלים לפיתוח תוכנית הפיתוח תזהה שיטות שיבטיחו שכל הפעילויות יבוצעו בצורה נכונה. אפשר לכלול בתוכנית פרטיס אלה: א. כללים, נהגיס ומוסכמות לפיתוח; ב. כלים וטכניקות לפיתוח; ג. | ניהול תצורה. 3 בקרת התקדמות סקרי התקדמות צריכים להיות מתוכננים, מבוצעיס ומתועדים, כדי להבטית שתפתרנה בעיות יוצאות דופן בהקצאת משאבים, וכדי להבטיח ביצוע אפקטיבי של תוכניות הפיתוח. 4 דרישות לשלבי הפיתוח הדרישות לכל אחד משלבי הפיתוח יוגדרו ויתועדו. בעיות הקשורות בדרישות דו- משמעיות, סותרות או שאינן שלמות, ייפתרו עס האחראיס לכתיבת הדרישות. 5 תוצר שלבי הפיתוח התוצר הנדרש בכל שלב פיתוח יוגדר, יתועד ואומת ויעמוד בדרישות אלו: א. ימלא אחר דרישות רלוונטיות; ב. יכיל או יתייחס לקריטריוני קבלה, כדי להתקדס לשלבי הפיתוח העוקבים ; ג. | יתאים לנהגים ולמוסכמות מתאימים של הפיתוח, בין אס פורטו במידע הקלט ובין אם לאו ; ד. יזהה את מאפייני המוצר החיונייס לבטיחותו ולפעולתו התקינה ; 4 ניהול איכות תוכנה ה. יתאיס לדרישות תחיקה ישימות. 6 אילמות כל שלב הספק יתווה תוכנית לאימות כל התוצריס של שלבי הפיתוח, בסוף כל שלב. אימות הפיתות יקבע שהתוצריס של שלבי הפיתוח יעמדו בדרישות המתאימות, באמצעיס של בקרת פיתוח, כגון: א. ביצוע סקרי פיתוח בנקודות מתאימות בשלבי הפיתוח; ב. השוואה, אס אפשר, של תֶּכֶן חדש עס תכן דומה שהוכיח את עצמו; ג. | עריכת בדיקות והדגמות. טות תוצאות האימות ופעולות נוספות שנדרשות כדי להבטיתח שהדרישות . ממולאות, יירשמו וייבדקו כאשר מסתיימות הפעילויות הנוספות. רק תוצר מאומתים יימסרו לניהול תצורה ויתקבלו להמשך השימוש. 5 תכנון האיכות 1 כללי כחלק מתוכנית הפיתות יכין הספק תוכנית איכות. ים לכל שלב תוכנית האיכות תעודכן תוך כדי התקדמות הפיתוח, והסעיפים הנוגעים ל יוגדרו במלואס לפני תחילת השלב. היא תוכנית האיכות תיסקר פורמלית על ידי כל הארגוניס המעורביס במימושה, וה תהיה מוסכמת עליהס. י (שכותרתו המסמך המתאר את תוכנית האיכות (ראה 5.5.2) יכול להיות מסמך 0 ו יתוכנית איכות'), או חלק ממסמך אחר, או יכול להיות מורכב מכמה מסמ תוכנית הפיתוח. 2 תוכן תוכנית איכות תוכנית איכות תציין את הנושאיס המפורטים להלן, או תתייחס אליהם: א. יעדי האיכות, המבוטאים ככל האפשר, במונחיס הניתניס למדידה; ב. | קריטריונים מוגדריס לדרישות ולתוצריס בכל שלב של הפיתוח; ג. | זיהוי סוגי פעילויות שיבוצעו לצורך בדיקה, אימות והוכחת תקפות; , ד. תכנון מפורט של פעילויות הבדיקה, האימות והוכחת התקפות שיבוצעו, לרבות לוח זמנים, משאבים וסמכויות מאשרות; ה. תחומי אחריות ספציפיים לפעילויות איכות, כגון: - | סקריס ובדיקות; - | ניהול תצורה ובקרת שינוייס; נספח אז': תייי 2000-3 = 245 - | בקרת פגמים ופעולות מתקנות. 6 תְכַן ומימוש 1 כללי פעילויות התכן (תק!465) והמימוש הן אלו המתמירות את מפרט הדרישות של הלקות למוצר תוכנה. בגלל מורכבות מוצרי התוכנה חלה חובה לבצע פעילויות אלו בצורה ממושמעת, כדי ליצור מוצר בהתאם למפרט, ולא בהסתמך על פעילויות הבדיקה והוכחת התקפות להבטחת איכותו. הערה 6: רמת החשיפה של המידע שיסופק ללקוח צריכה להיות מוסכמת הדדית על שני הצדדים, מכיון שבדרך כלל, תהליכי התכן והמימוש הינס סודות מסחריים של הספק. 2 תְכֶן נוסף על הדרישות המשותפות לכל שלבי הפיתוח, יש להביא בחשבון את ההיבטיס המפורטיס להלן, שהס חלק בלתי נפרד מפעילויות התכן: א. זיהוי שיקולי תכן: נוסף על מפרטי הדרישות והתוצרים ייבחנו היבטים, כמו כללי תכן והגדרות לממשקיס פנימיים ; ב. שיטת תכן: יש להשתמש בשיטת תכן, המתאימה לסוג מוצר התוכנה שנמצא בפיתוח; ג. | שימוש בניסיון העבר בתחוס התכן: יש להשתמש בלקחים שנלמדו מתוך ניסיון העבר בתהליכי תכן. הספק ימנע הישנות של בעיות דומות או זהות; ד. התהליכים הבאיס: תכן המוצר יאפשר בדיקה, תחזוקה ושימוש נוחים. 3 מימוש נוסף על הדרישות המשותפות לכל פעילויות הפיתוח, יש להביא בחשבון את ההיבטים המפורטים להלן בכל פעילות מימוש: א. כלליס: יש לציין ולבחון כלליס כמו כללי תכנות, שפות תכנות, שימוש עקבי בשמות, קידוד וכללי הוספת הערות ; ב. שיטת המימוש: הספק ישתמש בשיטות מימוש ובכליסם מתאימים, כדי לעמוד בדרישות הלקוח. 4 סקויס הספק יערוך סקרים כדי להבטיח שהמוצר עומד בדרישות ושהשיטות שהוזכרו לעיל מבוצעות בצורה נכונה. אין להמשיך בתכן, בביצוע, או בתהליך המימוש, עד אשר כל הליקוייס הידועים יתוקנו בצורה משביעת רצון, או עד אשר יוודע הסיכון שבהמשך העבודה ללא תיקוניס. יש לשמור את הרשומות של סקריס כאלה. 6 ניהול איכות תוכנת 7 בדיקה והוכחת תקיפות 1 כללי ייתכן ויהיה צורך בבדיקות במספר רמות, מרמת פריט תוכנה בודד ועד לרמת מוצר תוכנה מוגמר. יש מספר גישות לבדיקה ולכילגליוּת (מסנ1גזפטזתו). במספר מקרים ייכללו בפעילות אחת הוכחת תקפות (מסנז41183ט), ניסוי בתנאי שדה ובדיקות קבלה. המסמך המתאר את תוכנית הבדיקה יכול להיות מסמך נפרד, חלק של מסמך אחר, או יכול להיות מורכב ממסמכיס אחדים. 2 תכנון הבדיקה הספק יקבע את תוכניות הבדיקה, המפרטים והנהלים ויסקור אותם לפני תחילת הבדיקות. יש להתחשב בפרטיס אלה: א. ב. ו ז. תוכניות פריט תוכנה, כילוליות, בדיקת מערכת ובדיקת קבלה; בדיקות מקדמיות (64565 651), נתוני בדיקה ותוצאות צפויות; סוגי הבדיקות שיש לבצע. לדוגמה: בדיקות פונקציונליות, בדיקות קצה (16519 עְזג0תגוסט), בדיקות פעולה ובדיקות שימוש; סביבת בדיקה, כלים ותוכנת בדיקה; קריטריוניס לבחינת סיוס הבדיקות; תיעוד המשתמש; כוח אדס הדרוש ודרישות הדרכה. 43 בדיקה יש להקדיש תשומת לב מיוחדת להיבטי הבדיקה האלה: א. ב. ג. ד. ה. תוצאות הבדיקה יירשמו כפי שמוגדר במפרט הרלוונטי; תצויין כל בעיה שהתגלתה והשפעתה האפשרית על חלקים אחרים של התוכנה. יש ליידע את האחראים לכך ולאפשר מעקב עד לפתרון ; חלקים שהושפעו כתוצאה משינוי כלשהו יזוהו וייבדקו מחדש; יוערכו התאמת הבדיקה והרלוונטיות שלה; תצורות החומרה והתוכנה יישקלו ויתועדו. 4 הוכחת תקפות לפני מסירת המוצר להפצה ולקבלת הלקות, יוכיח הספק את תקפות פעולתו של המוצר כמוצר שלס וככל האפשר, בתנאיס דומים לסביבת היישוס כמצוין בחוזה. נספח א'; תייי 2000-3 | 247 5 ניסוי בתנאי שדה כאשר יש צורך בניסוי בתנאי שדה, יש להתייחס לנקודות אלו: א. התכונות שייבדקו בתנאי סביבה של השדה (וםסותתסזנעת6 1616) ; ב תחומי האחריות הספציפייסם של הספק והלקות בנוגע לביצוע הניסוי ולהערכתו; ג. = התזרת סביבת המשתמש למצבה הקודם (לאחר הניסוי). 8 קבלה 1 כללי כאשר הספק מוכן למסור את המוצר לאחר שעבר הוכחת תקיפות, ישפוט הלקוח אם אפשר לקבלו בהתאס לקריטריונים מוסכמיס מראש ובאופן שצוין בחוזה. שיטת הטיפול בבעיות המתגלות בעת הליך הקבלה וסילוקן תהיה מוסכמת על הלקות ועל הספק ותתועד. 2 תכנון בדיקות קבלה לפני ביצוע פעילויות קבלה, יעזור הספק ללקוח לזהות את הפרטיס האלה: א. לוח זמנים ; ב. נוהלי הערכה; ג. | סביבות תוכנה-חומרה ומשאביס ; ד. קריטריוניס לקבלה. 9 שכספול, מסירה והתקנה 1 שכפול שלב השכפול יבוצע לפני המסירה. לפני השכפול יש לתת תשומת לב לפרטיס אלה: א. מספר העותקים של כל פריט תוכנה שיש למסור; ב. סוג המצע (מדיה) לכל פריט תוכנה, לרבות התסדיר והגירסה בצורה הניתנת לקריאה; ג. | קביעת התיעוד הדרוש, כגון ספרי עזר ומדריכיס למשתמש; ד. ענייני זכויות יוצריס ורישוי שנדונו וסוכמו; ה. שמירת העותק המקורי ועותקי הגיבוי, אס אפשר, לרבות תוכנית להתאוששות ממצבי חירוס ; ו. | תקופת ההתתייבות של הספק לאספקת עותקיס. 8 ניהול איכות תוכנה || שי שו 8 ממה שר | 2 מסירהת יוכנו אמצעיס שיאפשרו לאמת את נכונות העותקיס של מוצר התוכנה שנמסרו ואת שלמותס. 3 התקנה יש להגדיר בצורה ברורה את התפקידים, את תחומי האחריות ואת ההתתייבויות של הספק ושל הלקוח, ולהביא בחשבון את הפרטיס האלה: א. לותח זמניס, כולל שעות חריגות וסופי שבוע; ב. אפשרות כניסה למתקני הלקות (תגים, סיסמאות, ליווי; ג. | זמינות של עובדיס מיומניס ; ד. | ומינות של מערכות הלקות וציודו וגישה אליהם ; ה. קביעה בחוזה את הצורך בהוכחת תקפות כחלק מההתקנה; ו | נוהל פורמלי לאישור של כל התקנה לאחר סיומה. 0 תתחזוקהת 1 כללי נ כאשר תחזוקה של מוצר תוכנה נדרשת על ידי הלקוח לאחר -. -% א הראשונית, היא תעוגן בתוזה. הספק צריך ללהקים ולקיים נהליס לפעילויות תחזוק ויאמת שהן תואמות לדרישות התחזוקה הספציפיות. ממייניס את פעילויות התחזוקה למוצרי תוכנה, כלהלן: א. פתרון בעיות; ב. שינוי הממשק; ג. | הרחבת התפקוד, או שיפור ביצועיס. ים. להל בחוזה יצוינו הפריטים שיש לתחזק ופרק הומן שבו הם יהיו מתותוקיס דוגמאות של פריטיס כאלה: א. תוכנית או תוכניות; ב. נתונים ומבניהס ג. | מפרטים; ד. תיעוד ללקות או למשתמש; ה. תיעוד לשימוש הספק. נספח א': ת'יי 2000-3 | 249 2 תוכנית תחזוקה כל פעילויות התחזוקה יבוצעו וינוהלו בהתאם לתוכנית תתזוקה מוגדרת ומוסכמת על הספק ועל הלקוח. התוכנית תכלול: א. תחוס התתזוקה; ב. | זיהוי המצב התחילי של המוצר; ג. | הארגון/ (או הארגוניס) התומך; ד. פעילויות תחזוקה; ה. רישומי תחזוקה ודוחות. 3 זיהוי המצב התחילי של המוצר המצב התחילי של המוצר המיועד לתחזוקה יהיה מוגדר, מתועד ומוסכם הן על ידי הספק והן על ידי הלקוח. 4 ארגון תומך ייתכן שיהיה צורך להקים ארגון שיתמוך בפעילות התחזוקה ושיהיו בו נציגים הן של הספק והן של הלקות. מכיון שהפעילויות בשלב התחזוקה אינן מתבצעות תמיד על בסיס של לוח זמניס קבוע, צריך ארגון זה להיות גמיש מספיק כדי להתמודד עס בעיות לא צפויות. ייתכן שיהיה גס צורך לזהות מתקניס ומשאבים שישמשו לפעילויות התחזוקה. 5 סוגים של פעילויות תחזוקה כל שינויי תוכנה (מסיבות של פתרון בעיות, שינוי ממשק, הרחבת תפקוד ושיפור ביצועים) המבוצעים במהלך התחזוקה, ייעשו ככל האפשר בהתאס לאותם נהלים שישמשו לפיתוח מוצר התוכנה. כל השינוייס האלה יתועדו בהתאס לנוהלי בקרת המסמכים וניהול תצורה. א. פתרון בעיות: פתרון בעיות כרוך באיתור, ניתוח ותיקון של אי-התאמות תוכנה הגורמות לבעיות תפעול. אפשר לבצע תיקון זמני, כדי להקטין את זמן ההשבתה של המערכת, ולבצע שינוייס קבועיס בשלב מאוחר יותר. ב. שינויי ממשק: שינויי ממשק עשוייס להידרש, כאשר מבוצעיס תוספות או שינוייסם במערכת החומרה או ברכיביס המבוקרים על ידי התוכנה. ג. | הרחבות פונקציונליות או שיפור ביצועיס: הרחבות פונקציונליות או שיפור ביצועים עשויים להידרש על ידי הלקוח בשלב התחזוקה. 6 דוחות ורשומות תחזוקה כל פעילויות התתזוקה יירשמו ויישמרו בתסדירים מוגדריס מראש. ייקבעו כלליס מוסכמיס להגשת דוחות תחזוקה. 50 ניהול איכות תוכנה זז וחד ָזְדיקו זץ זפורילר קרי . רשומות התחזוקה יכללו את הפרטיס שלהלן, לכל פריט תוכנה מתוחזק: א. רשימת בקשות לסיוע, או דוחות תקלות שהתקבלו והמצב הנוכחי של כל אחד מהם ; ב. הארגון האחראי להיענות לבקשות סיוע או למימוש הפעילות המתקנות המתאימות ; ג. | הקדימויות שנקבעו לפעולות המתקנות; ד. תוצאות הפעולות המתקנות; ה. נתוניס סטטיסטיים על התרחשות תקלות ועל פעילויות תחזוקה. רשומת פעילויות התחזוקה יכולה לשמש להערכת מוצר התוכנה ולשיפורו, ולשיפור מערכת האיכות עצמה. 7 נוהלי שחרור הספק והלקות יסכימו על נהלים להכנסת שינוייס במוצר תוכנה, הנובעיס מהצורך לשמור על רמת ביצועים, והס יתעדו נהליס אלה. הנהלים יכללו: א. כללי יסוד שיקבעו מתי יש צורך בשינוייס (או תיקוניס) זמניים ומתי יש צורך בעותק מלא ומעודכן של מוצר התוכנה; תיאור סוגי השחרורים (הגירסות) בהתאס לתדירות הופעתס ובהתאם להשפעה שיש להן על פעילות הלקוח ועל יכולתו לבצע שינויים בכל נקודת זמן כלשהי; יים; ג. | שיטות שעל פיהן יונחה הלקות בדבר שינויים נוכחיים או שינוייס עתידייס; ד. | שיטות שיאפשרו לוודא שהשינויים שיבוצעו לא יגרמו לבעיות נוספות ; ה. דרישות לרשומות שמצוין בהן איזה שינויים מומשו ובאיזה מקומות, עבור אוסף של מוצריס ואתריס. 6. מערכת איכבות - פעילויות תומכות (ללא תלות בשלב כלשהו) 1 ניהול תצורה 1 כללי ניהול תצורה מספק מנגנון לזיהוי, לבקרה ולמעקב אחר כל גירסה של כל פריט תוכנה. במקריס רביס יש לתתחזק ולבקר גם גירסות קודמות הנמצאות עדיין בשימוש. המערכת לניהול תצורה צריכה: א. לזהות בצורה ייחודית את הגירסות של כל פריט תוכנה; נספח א': תייי 2000-3 251 ב. לזהות את הגירסות של כל פריט תוכנה, המרכיבות יחד גירסה ספציפית של מוצר שלס ; ג. | לזהות את מצב הבניה של מוצרי תוכנה הנמצאיס בפיתוח, או שסופקו והותקנו; ד. לבקר עדכון של פריט תוכנה שנעשה סימולטנית על ידי יותר מאדס אחד; ה. | לתאם עדכון של אוסף מוצריס באתר אחד, או יותר, כנדרש ; ו. | לזהות ולעקוב אחר כל הפעולות והשינויים הנובעיס מבקשה לשינוי, החל מהייזוס ועד לשחרור. .6 תוכנית ניהול תצורה פק יפתח ויממש ותוכנית ניהול תצורה, אשר תכלול: א. גופיס המעורביס בניהול תצורה והאחריות המוטלת על כל אחד מהם ; ב. פעילויות ניהול תצורה שיש לבצע; ג. | כלים, טכניקות ושיטות שיש להשתמש בהם בניהול תצורה; ד. השלב שבו צריך להכניס פריטיס לבקרת תצורה. .> פעילויות ניהול תצורה 2 זיהוי תצורה ומעקב פק יקבע ויקיים נהלים לזיהוי פריטי תוכנה במהלך כל השלבים, החל מהגדרת פרטים דרך הפיתוח והשכפול ועד למסירה. אם נדרש בחוזה, אפשר להשתמש זלים אלה גס לאחר מטירת המוצר. לכל אחד מפריטי התוכנה יהיה זיהו? ייחודי. להשתמש בנהלים כדי להבטיח שאפשר יהיה לזהות את הפרטיס שלהלן עבור כל "סה של פריט תוכנה : א. המפרטים הטכניים והפונקציונלייס ; ב. כל כלי הפיתוח המשפיעים על המפרטיסם הטכנייס והפונקציונליים; ג. | כל הממשקים לפריטי תוכנה אחרים ולחומרה ; ד. כל המסמכים וקובצי המחשב הקשוריס לפריט התוכנה. זוי פריט התוכנה יתנהל בצורה כזו, שניתן יהיה להראות את הזיקה שבין הפריט רישות החוזה. ור מוצרים ששוחררו, יהיו נהליס שיקלו על המעקב אחר פריט התוכנה או אחר לוצר. 23 בקות שינויים 1 2 ניהול איכות תוכנה הספק יקבע ויקייס נהלים לזיהוי, לתיעוד, לסיקור ולהרשאה של כל השינויים בפריטי התוכנה הנמצאיס בניהול תצורה. כל השינויים בפריטי התוכנה יבוצעו בהתאס לנהלים אלה. לפני שמתקבל שינוי, תאושר תקפותו, תזוהה השפעתו על פריטים אחרים ותיבדק. יסופקו שיטות כדי לידע את הנוגעיס בדבר לגבי השינוייס ולהראות להס את העקיבות בין השינוייס לבין החלקים של פריטי התוכנה ששונו. 3 דוח מצב תצורה הספק יקבע ויקיים נהלים לרישוס, לניהול ולדיווח של מצב פריטי התוכנה, של הבקשות לשינוי ושל מימוש השינוייסם המאושריס. 2 בקרת מסמכים 1 כללי הספק יקבע ויקיים נהלים לבקרת כל המסמכים המתייחסיס לתוכן חלק זה של תייי 2000. אלה כולליס : א. | הגדרת המסמכים שנוהלי בקרת מסמכים יחולו עליהם ; ב. | אישור נהלים והוצאתם; ג. = נוהלי שינוי הכולליס דחייה ולפי הצורך שתרור. 2 סוגי מסמכים הנהלים לבקרת מסמכים יחולו על המסמכיס הרלוונטיים, כלהלן: א. מסמכי נוהל המתארים את מערכת האיכות, שיש להחיל במחזור החיים של התוכנה; ב. מסמכי תכנון המתאריס את התכנון של כל פעילויות הספק ואת התקדמות|ן, ואת פעולות הגומלין שלו עס הלקות; ג. | מסמכי המוצר המתארים מוצר תוכנה מסויס, לרבות: - | דרישות לשלבי הפיתוח; - | תוצריס של שלבי הפיתוח; - | . תוכניות אימות ותקפות ותוצאותיהן; - | תיעוד ללקותח ולמשתמש; - | תיעוד תחזוקה. 3 אישור מסמכים והוצאתם כל המסמכים צריכיס להיסקר ולעבור אישור של צוות עובדים מורשה לפני הוצאתס. יש להגדיר נהליס שיבטיחו: נספח א': תי 2000-3 | 253 א. המסמכים המתאימים :היו זמינים במקומות שבהם מבוצעות פעולות החיוניות לתפקוד האפקטיבי של מערכת האיכות ; ב. מסמכיס שפג תוקפס יסולקו מיד מכל האתרים שבהס נופקו או יושמו. כאשר משתמשים בקובצי מחשב, יש להקדיש תשומת לב מיוחדת לנוהלי אישור, גישה, הפצה ושמירה בארכיון. 4 שלינולים ועדכונים במסמכים שינוייסם במסמכיס ייסקרו ויאושרו על ידי אותס בעלי תפקיד, יחידות וארגוניס מוסמכיס, שסקרו את המהדורה המקורית ואישרו אותה, אלא אס מונו אחריס לבקר את השינוייס והעדכונים. לארגוניס המוסמכיס תהיה גישה למידע רקע ישים, שעליו יבססו את סיקורס ואישורס. במקוס שהדבר מעשי, יזוהה אופי השינוי במסמך או בנספחיס נאותיס. רשומות-אב או מסמך שקיל לבקרת תהליך התיעוד יוכנו, כדי לאהות את הגירסה המעודכנת של מסמכים וכדי למנוע שימוש במסמכים שָאינס ישימים. מסמכים ייערכו מחדש ותפורסס מהדורה חדשה שלהם, לאחר עריכת מספר סביר של שינוייס ועדכוניס. [תייי 2001 : 1990, 4.5.2] 3 רשומות האיכות הספק יקיס ויקיים נהליס לזיהוי, לאיסוף, למספור, לתיוק, להחסנה, לתחזוקה ולהמשך הטיפול ברשומות האיכות. הספק ישמור את רשומות האיכות ויציג אותן כראיות להשגת האיכות הנדרשת ולהפעלה האפקטיבית של מערכת האיכות. רשומות איכות של קבלני המשנה הנוגעות למוצר יהוו חלק מהרשומות שהוזכרו לעיל. כל רשומות האיכות יהיו ברורות וקריאות וניתנות לזיהוי כלפי המוצר. מחסינים את רשומות האיכות, שיהיו נגישות בקלות. מחסיניס אותן בסביבה מוגנת, המקטינה את קלקולן, את הפגיעה בהן ואת אובדנן. זמן השמירה של רשומות האיכות ייקבע ויתועד. כאשר הדבר הוסכס בחוזה, תהיה תקופה מוגדרת, שבה יהיו רשומות האיכות נגישות לבדיקה על ידי הלקוח או על ידי נציגו. [תייי 2001: 1990, 4.16] 4 מדידה 1 מדידת מוצר מדדים ידווחו וישמשו לניהול תהליך הפיתוח והמסירה, ויהיו רלונטיים למוצר התוכנה המסויס. 4 ניתול איכות תוכנה אין כרגע דרכי מדידה לאיכות תוכנה, המקובלים באופן אוניברסלי. אולס כמינימוס יש להשתמש במדדים כלשהם המייצגים דיווח של מספר כשלים בשדה, או את מספר הפגמים מנקודת מבטו של הלקות. המדדים הנבחריס יתוארו באופן שאפשר יהיה להשוות את התוצאות. הספק של מוצרי תוכנה יאסוף נתוני מדידה כמותיים על איכות מוצרי התוכנה. יינקטו אמצעיס אלה כדלי: א. לאסוף נתוניס ולדווח באופן קבוע על ערכי המדדיס; ב. לזהות את רמת הביצועים הנוכתית בכל מדד; דרה ג. | לבצע פעולה מתקנת, אם רמות המדד יורדות אל מעבר לרמה שהוגדרה מראש, או עולות עליה; ד לקבוע יעדי שיפור מוגדרים במונתים של המדדים. 2 מדידת תהליך ים אלה ישקפו נתוניס אלה : באיזו מידה א. באיזו מידה התנהל תהליך הפיתות לפי אבני דרך שנקבעו, ו ים; הושגו יעדי איכות במהלך התהליך בהתאם ללוח הזמנים ; תקלות ב. מידת היעילות של תהליך הפיתוח בהקטנת ההסתברות להיווצרות שיתגלו, או שלא יתגלו. משות כאן, בדומה למדדי המוצר, הדבר החשוב הוא -. --- ה לבקרת התהליך ולשיפורו, ולא באיזה מדדיס -. שיש לספק. ייתכן ומדדיס לתהליך ואס אפשר, ישפיעו ישירות על איכות התוכנ שונים יתאימו למוצרי תוכנה שונים המיוצרים על ידי אותו ספק. 5 כללים, נהגים ומוסכמות יכות המתוארת בחלק הספק יספק כללים, נהג'ים ומוסכמות כדי להפוך את מערכת הא - הצורך. זה של ת'ייי 2000, לאפקטיבית. הספק יבדוק את הכללים והמוסכמ 6 כלים וטכניקות האיכות הספק ישתמש בכלים, אמצעים וטכניקות, כדי להפוך את - ו יכוליס המתוארת בחלק זה של תייי 2000, לאפקטיבית. כלים, אמצעיס וטכנ פק ישפר כלים ס להיות אפקטיביים הן לצורכי ההנהלה והן לפיתוח המוצר. הספק וטכניקות אלה לפי הצורך. נספח א': ת''י 2000-3 | 255 7 רכש 1 כללי הספק יבטיח שהמוצר או השירות הנרכשיס עומדיס בדרישות המצוינות. מסמכי הרכש יכילו מידע המתאר בצורה ברורה את המוצר ואת השירותיס שהוזמנו. לפני שחרור המוצר יסקור הספק את מסמכי הרכש ויבדוק את התאמתס לדרישות הספציפיות, ויאשרס. הערה 7: מוצר נרכש יכול להיות פריט חומרהאו תוכנה, המיועד להיכלל במוצר הסופי, או כלי המיועד לעזור בפיתוח המוצר הנדרש. 2 הערכה של קבלני משנה הספק יבחר לו קבלני משנה לפי יכולתם להתאיס לדרישות קבלנות המשנה ודרישות האיכות בכלל זה. הספק יקים ויקיים רשומות של קבלני משנה קביליס. בחירת קבלני המשנה, אופי הבקרה והיקפה, כפי שתופעל על ידי הספק, יהיו תלוייס בסוג המוצר ולפי הצורך ברשומות על הביצועיס והיכולת המוכחיס של קבלני המשנה בעבר. הספק יבטיח שהבקרה של מערכת האיכות אפקטיבית. [ת'יי 2001 : 1990, 4.6.2] 3 הוכחת תקפות המוצר הנרכש הספק אחראי להוכחת תקפות עבודתו של קבלן המשנה. ייתכן ולשס כך יידרש קבלן המשנה לתאם את התכן וסקריס אחריס עס מערכת האיכות של הספק. אם כך, ייכללו דרישות אלו בחוזה המשנה. כן תיכלל בחוזה המשנה כל דרישה לבדיקות קבלה שיערוך הספק על תוצאות עבודת קבלני המשנה. כאשר מצוין בחוזה, יש לאפשר ללקות או לנציגו לבחון במהלך העבודה אצל קבלן המשנה או בעת קבלת המוצר, אם המוצר עומד בדרישות המצוינות. הוכחת תקיפות על ידי הלקות, אינה משחררת את הספק מאחריות לספק מוצר ראוי לשימוש, ואינה מוציאה מכלל אפשרות דחיית המוצר בעתיד. כאשר הלקות או נציגו בוחריסם להוכיח תקפות באתר של קבלן המשנה, אין הספק :כול להשתמש בכך כעדות לבקרה אפקטיבית של האיכות הנעשית על ידי קבלן המשנה. 8 מוצר תוכנה משולב ייתכן שהספק יידרש להשתמש במוצר תוכנה שסופק על ידי הלקוח, או על ידי צד שלישי. הספק יקבע ויקיים נהלים להוכחת תקפות, אחסון, הגנה ותחזוקה של מוצר כזה. יש לתת את הדעת לתמיכה במוצר תוכנה כזה בכל חוזה תחזוקה המתייחס למוצר הסופי. 6 ניהול איכות תוכנה קש שווזיזום וש שומ מממממממממהרש םוט קט טל ,ה מוצר שסופק על ידי הלקוח ונמצא בלתי מתאים לשימוש יירשם וידווח על כך ללקוח. הוכחת תקפות על ידי הלקוח אינה משחררת אותו מהאחריות לספק מוצר ראוי לשימוש. 9 הדרכה הספק יקבע ויקייס נהליס לזיהוי צורכי ההדרכה ויאפשר הדרכה לכל העובדים העוסקיס בפעילויות המשפיעות על האיכות. המועסקים במשימות מסוימות יוסמכו על בסיס השכלה נאותה, הכשרה, או לפי הניסיון המצטבר שרכשו. הנושאיס שיש להתייחס אליהם יוגדרו בהתאם לכלים, לטכניקות ולשיטות ספציפיים ובהתאס למשאבי המחשב שישתמשו בהם לפיתות ולניהול של מוצר תוכנה ולניהולו. ייתכן שיהיה צורך לכלול הדרכה, הכוללת הקניית מיומנויות וידע הקשוריס לתתום המיוחד שהתוכנה תטפל בו. יש לשמור על רישומים הנוגעיס להדרכה ולניסיון. נספח א': תייי 2000-3 | 257 נספח א (לידיעה בלבד) הפניה הדדית בין סעיפי תייי 2000-3 לבין תייי 2001. הסעיף בתייי 2000-3 הסעיף בתייי 2001 1 אחריות ההנהלה 21 2 מערכת איכות 42 3 מבדקי איכות פנימייס 1417 4 פעולה מתקנת 1-14 2 סקר התוזה 443 3 מפרט דרישות הלקות 3, 4.4 4 תכנון הפיתות 4+ 5 תכנון האיכות 2, 4.4 6 תכן ולישוס 4, 4.9, 4.13 7 בדיקה והוכחת תקפות 4, 4.10, 4.11, 4.13 8 קבלה 14150 9 שכפול, מסירה והתקנה 0, 415 0 תתזוקה 193 1 ניהול תצורה 4, 4.5, 4.8, 4.12, 4.13 2 בקרת מסמכים 5+ 3 רשומות איכות 6 4 מדידה 1[(20 5 כללים, נוהגיס ומוסכמות 1199 6 כלים וטכניקות 19 7 רכש 146 8 מוצר תוכנה משולב 247 9 הדרכה 8|+ 88 ניהול איכות תוכנה זו ו שי או ו ומוס המוה המומ מתתּ[נבנק התה תה ,בר 6 .0 נספח ב (לידיעה בלבד) הפניה הדדית בין סעיפי תייי 2001 לבין ת'יי 2000-3. הסעיף בתייי 2001 000 הסעיף בת"י 2000-3 4 דרישות מערכת איכות 4, 5, 6 121 אחריות ההנהלה 41 42 מערכת איכות 2+ 243 סקר החוזה 2, 5.3 44 בקרת התכן 3, 5.4, 5.5, 5.6, 5.7, 6.1 15 בקרת התיעוד 1 62 46 רכש 47 147 מוצר המסופק על ידי הלקוח 8 48 זיהוי המוצר ועקיבה 1 49 בקרת תהליך 6 6.5, 6.6 0 בתינה ובדיקה 7, 5.8 5.9 1 ציוד הבתינה, המדידה והבדיקה 7, 6.5, 6.6 12 מצב הבתינה והבדיקה 1 3 בקרה של מוצר שאינו תואס 6 5.7, 5.9, 6.1 4 פעולה מתקנת 44 5 שלנוע, החסנה, אריזה והספקה 598 6 רשומות האיכות 43 7[ מבדקי איכות פנימייס 23 8 הדרכה 0-9 1.19 שירות 1.0 0 טכניקות סטטיסטיות 4 גספח אז': תייי 2000-3 = 259 / '% 8% יי לו התאחדות התעשיינים 8 אוגוד הקשות בש המרכז לאיכות ומצוינות האלקטרוניקה משרד התעשיה והמסחר [ססת כ/ הפרס הלאומי לאיכות בתעשיה תקנון מגוא הצטיינות היא תנאי להצלחה עיסקית ואף לשרידות בשנות ה- 90. האיכות הכוללת של חברה תעשייתית מקיפה את מוצריה, שירותיה, כל מרכיבי תפקודה הפנימי והתיצוני. הצטיינות תושג כתוצאה מניהול לאיכות על בסיס תהליכי שיפור מתמיד בכל רמות ופעילויות הארגון. מתוך הכרה בעובדות אלה החליטה ממשלת ישראל כי ראש הממשלה יעניק מדי שנה את פרס האיכות בתעשיה למפעלים מצטיינים. את התקנון המפורט לקבלת הפרס אפשר לקבל בוועדת פרס האיכות / איגוד תעשיות האלקטרוניקה, ת.ד. 50026 תל-אביב 61500. בטלפון : 03-5198862/3 מטרות הענקת הפרס * לתת פומבי ולפתח את המודעות לחשיבותה של איכות כוללת. . דירבון חברות וארגוניס להיכנס לתהליך קבוע של שיפור. * עידוד שיתוף פעולה בין חברות כמנוף לשיפור תחרותיות בעולם. * לפרסס בארצ ובעולס שהתעשיה בישראל שואפת ופועלת להשגת הצטיינות. * להתוות את הדרך להשגת איכות באמצעות הקריטריוניס של הפרס. נספח ב': הפרס הלאומי לאיכות כתעשיה ‏ [26 = להקנות לזוכיס כלי שיווקי בארץ ובעולס ולהוות הכרה בהישגיהס. אמות מידה ומדדיק המאפייניס של ארגוניס מצטיינים והקריטריוניס על פיהס תבוצע הערכת מועמדיס הס: מנהיגות לאיכות הכוללת מעורבות מנהלים, קביעת מדיניות איכות, תכנון אסטרטגי לאיכות ותרומה לסביבה. שביעות רצון של הלקוחות. קיוס תהליך מתמשך של שיפור. תוצאות איכות בפועל. תשתית לאיכות. שיפור ומיצוי המשאב האנושי. איכות במידע ומערכות דוות. הקריטריוניס יבדקו ויעודכנו במידת הצורך מדי שנה. השיטה א. 22 התחרות פתוחה לחברות ומפעלים בכל גודל וליחידות משנה של חברות בתנאי שאלה מקיפות לפחות תחוס עסקיסם מסוייס ומהוות יחידות עיסקיות (8512655 5ם)) דהיינו כוללות את מגוון הפעילויות המאפיינות עסק העומד בזכות עצמו. התחרות תתקייס בשתי הקבצות : 0 מפעליס קטנים - עד 150 עובדים במפעל. 0 מפעלים גדוליס יותר. הזוכיס בפרס יעזרו במידע והדרכה למפעליס אחריס ליישס מערכות איכות כוללת. ניהול איכות תוכנה וו פווווּ[ּ ּ‏ ה 7 טופס הערכה - קריטריוניס לבחינת וכאות לפרס (סהייכ 1000 נקודות) הערה: הניקוד משמש מדד חשיבות יחסי לנושא ההערכה. 1. מנהיגות לאיכות (150 נקודות) 1 מדיניות איכות ברורה ומחייבת ליצירת תרבות איכות 1 מדיניות האיכות והדרך בה מדיניות זאת מועברת ומושרשת לכלל עובדי הארגון. 2 מעקב אחרל חדירת הערכים לכל רובדי הארגון. 2 יעדי איכות הנגזרים מן המדיניות 1 שללוב יעדי איכות הנגזרים ממדיניות האיכות, בתכנון לטווח קצר וארוך. 2 מעקב אחר שילוב יעדי איכות אלה בכל רובדי הארגון וההתקדמות להשגתס. 3 מחויבות לאיכות ומעורבות אישית של ההנהלה הבכירה 1 פעולתה של ההנהלה הבכירה ופעולתס של חברי ההנהלה בהשרשת תרבות האיכות החל מתכנון והצבת יעדים, דרך מעקב ביצוע, וסייס בהכרה בהישגי איכות. 2 השתתפות אישית של מנהליס בכירים בצוותי שיפור פנימייס ובקידוס האיכות במסגרות הרחבות. 4 הכרת מדיניות ויעדי האיכות על ידי כל רובדי הארגון 1 מקסגרות בהן מועברים ונדונים מדיניות ויעדי האיכות של הארגון. 2 מעקב אחר הכרת המדיניות והיעדים על ידי כל רובדי הארגון. 3 השתלבות ערכי האיכות והיעדים בפעילות היוס-יומית. 5 ניהול לאיכות 1 השרשת נושא שילוב האיכות בכל רמות הניהול. 2 שיתוף פעולה ועבודת צוות בכל דרגי הניהול לקיוס ושיפור האיכות. 3 מעקב, מדידה ופעולות תיקון ליישוס העקרונות הנזכרים. נספח ב': הפרס הלאומי לאיכות בתעשיה = 263 6 שללוב איכות בתכנון לטווח קצר 1 קביעת יעדי הארגון להבטחת תחרותיות והצטיינות. 2 תהליכי איסוף ועיבוד מידע לקביעת היעדיס האלה. 3 קיוס ושיפור תהליך מוגדר של תכנון לטווח ארוך עס דגש על איכות. 7 סיוע לספקים לעמוד בדרישות האיכות 1 בתירת ספקים על בסיס איכות, ולא רק מחיר. 2 טיפוח הקשרים עס הספקים ושילובס בתוכניות האיכות הכוללת של הארגון. 3 הגדרת מדד לאיכות ספקים והנחיית הספקים בשיפורו. 4 תהליך צמצוס בדיקות קבלה על ידי הבטחת איכות המוצריס והשרותים המסופקיס בידי הספקים. 8 תמיכה והשתתפות בגופי תקינה, צוותי חשיבה, חינוך והוראה לאיכות 1 השתתפות עובדי הארגון בגופי תקינה, חינוך והדרכה, תוך שימת דגש על נושא האיכות. 2 טפפוח תודעת האיכות והחלפת מידע עם גופים חיצונייס ומוסדות ציבור בסביבה הקרובה והרחוקה. 9 הקפדה על שיפור האיכות 1 תרומת הארגון לנושאי בריאות, בטיחות ואיכות הסביבה, הן בין עובדי המפעל והן מחוצה לו. 2. שביעות רצון לקוחות, פנימיים וחיצוניים (200 נקודות) 1 קיום מערכת לאיפיון צורכי הלקוחות וציפיותיהם 1 זיהוי דרישות וציפיות הלקוחות לטווח קצר וארוך. 2 הגדרת מגזרי שוק, איפיון הצרכיס והגדרת המוצרים . 3 מעקב אחר התאמת התחזיות לתוצאות . 2 קיום מערכת למדידת שביעות רצון הלקוח 1 שיטות ומדדיס המשמשים לאבחון שביעות רצון הלקוחות. 2 השימוש באלה להפקת לקתים והגדרת פעולות תיקון. 3 הדרכים והשיטות בהם מעביר הארגון ללקוחותיו את חשיבותס וחשיבות דעתם בעיני הארגון. 4 ניהול איכות תוכנה 3 שימוש אפקטיבי ויעיל בממצאי שביעות רצון הלקוחות 1 שיטות ומדדיס לריכוז תלונות הלקוחות והשימוש בהס למטרות הגדרת פעולות תיקון ושיפור המוצריס/השירות. 2 מודעות כלל עובדי הארגון לתחשיבות שביעות רצון הלקוחות ולמדדיס הרלוונטיים. 4 מתן משוב ללקוחות (פנימיים וחיצוניים) 1 שיטה וזמן תגובה ומעקב למתן משוב, הערות לבקשות, תלונות ודרישות לקוחות. 2 רמת המודעות של ההנהלה וכלל העובדיס לנושא. 5 שיפור בפועל של שביעות רצון לאורך זמן 1 דוגמאות למגמות במדדים של שביעות רצון לקותות שהוזכרו בסעיפים קודמיס. 3 קיוס תהליך מתמשך של שיפור (150 נקודות) 1 *יעדים מוגדרים לשיפור בכל תחומי פעילות הארגון 1 יעדי השיפור שהוגדרו, סיבת בחירתם והדרך בה הוגדרו (שיתוף עובדיס, החלטת הנהלה, אילוצים חיצוניים). 2 מערכת מדידת נתונים ודיווח של ממצאים ומגמות 1 בסיסי הנתונים התומכיס במערכת השיפוריס האלה. 3 שיטות ותהליכים לשיפור 1 תהליכי השיפור (ישיבות ו/או דוחות תקופתיים, חד-פעמיים, צוותי חשיבה וכדי). 2 הדרד בה מובטחת השרשת תהליכים אלה בתרבות המפעל. 4 מעורבות מנהלים ועובדים בתהליכי השיפור 1 השתתפות של מנהלים בכירים והערכתס. 2 *צירת אווירה המעודדת עבודת צוות. 5 תוצאות בפועל של פעולות שיפור 1 דוגמאות למגמות ותוצאות בפועל של פעולות שיפור. נספח ב': הפרס הלאומי לאיכות בתעשיה | 265 4. תוצאות איכות בפועל (160 נקודות) 1 דיוותי איכות כמותיים וקבועים, ניתוחס הסטטיסטי ונקיטת פעולות תיקון ומַנַע 1 השיטה/הדרך בה נבחריס הפרמטריס ומקורות הדיוות. 2 שליטות העיבוד ומעקב אחר פעולות מנע/תיקון עליהן הוחלט. 2 שללוב נושאי האיכות בנושאיס תפעוליים 1 שלוב נושאי האיכות (בצורה כמותית) בנושאיס תפעולייס בכל תחומי הפעילות. 3 רמת הכיסוי והפירוט של מדידת האיכות 1 פריסת מערך מדידת האיכות בכל תחומי הפעילות בארגון ומקורות מידע, אחריות איסוף ואחריות דיווח. 4 תוצאות פרמטרי האיכות ומגמות שיפור 1 מגמות ונתוניס עדכנייס של כל הנתוניס העיקרייס המתאריס את איכות המוצר, תהליך וכדי. 2 במידת האפשר, השוואה עס נתוניס של המתחריסם, התעשיה וכדי. 5 התאמה בין התוצאות בפועל לבין הדרישות 1 השיטה בה נקבעיס היעדיס הכמותייס בכל תחוס ודרישות לקוחות, סטנדרטיס, מתחרים וכדי. 6 שיפור בפועל בהתייעלות ופריון 1 ההישגים בפועל בנושאי התייעלות ופריון. 7 שללוב דיווח עלויות איכות בדוחות ונהלים של הארגון 1 תיאאור קצר של מערך דיווח עלויות איכות, ניתוח הנתוניס והפצת המידע. 5. תשתית לאיכות (120 נקודות) 1 שיטות וכלים לאיכות בפיתוח 1 מערכת נהליס להגדרת תהליך הפיתוח. 2 שלוב דרישות איכות בשלביס מוקדמיס של פיתוח המוצר. 43 סקר תיכון ואישור מעבר משלב לשלב. 4 שללוב גופי הייצור והשירות בשלביס האלה. 6 ניתול איכות תוכנה מו 7 ח|ותו ו| תאזה ואו וצ מממ מממ המו א (*) כאשר חברה אינה עוסקת בפיתוח, לא ילקח סעיף זה בחשבון בעת הערכת החברה. 2 בחירת ספקים ואמצעי ייצור על בסיס שיקולי איכות 1 תהליד שיפור איכות ספקיס. 2 הערכה ודירוג הספקים ושימוש בהס לבחירת הספקים על בסיס שיקולי איכות. 43 בתינת ביצועי האיכות של אמצעי ייצור והתחשבות בממצאים. 3 תכנון ומימוש שיטת בקות איכות 1 מדדים ויעדי איכות בכל תחומי הפעילות בארגון. 2 שיטות בקרת התהליכים. 3 שי"מוש שגרת: בכלים סטטיסטיים לבקרה ושיפור תהליכים. 4 קיום תהליך סיקור (0ַ4) פנימי, שוטף וממוסד 1 תהליך סיקור - הגדרה, ארגון, שיטת פעולה, דיוות והפקת לקחים. 5 קיוס נהלים מבוקרים, מפרטיס ותקנים לבקרת איכות ושיפורה 1 נהלל איכות (גּגות3)]/ עז1ַ41ט0). 2 נהלים מעודכנים ומבוקרים הנגזרים מנוהלי האיכות. 3 הפצה, בקרה ושימוש בנהלים אלה. 6 קיוס תשתית ואמצעים מוגדריס לבקרת איכות ושיפורה 1 ארגון אבטחת איכות ושילובו במערכת הכללית :ול הארגון. 2 הימצאות הכליס והאמצעים הנדרשים לפינילות צוות אבטחת איכות. 3 מעקב ודיווח באיכות בכל תחומי פעילות הארגון. 7 מערך כיול ותחזוקה של האמצעים התפעוליים 41 מערך כיול ותתזוקה והנוהלים המגדירים את הפעילות. 2 רישום הציוד והתחזוקה, או כיול הנדרשים ולות זמניס מחייב. 3 מערכת בקרה, דיוות וניתוח ממצאיס. 6. שיפור ומיצוי המשאב האנושי (140 נקודות) 1 תכנון וביצוע הדרכה והכשרה בכל הדרגים 1 קביעת צורכי ההדרכה של עובדי הארגון. נספח ב': הפרס הלאומי לאיכות כתעשיה , 207 2 מסגות ההדרכה בארגון (שיטה, תוכניות, אמצעים, זמן וכדי. 3 קביעת צורכי ההדרכה ותיאור תכניות ההדרכה לאיכות של עובדי הארגון בכל הרמות. 4 קיום מעקב אחר יעילות ההדרכה, תוצאותיה, היקפה ותהליך שיפוך מתמשך. 2 עידוד וניצול תרומות עובדים לשיפור 1 קיוס האווירה המעודדת והמסירות ליזמות ו/או שיפור על ידי העובדיס. 2 תהליד הטיפול (שיטה, זמן וכדי) בהצעות שיפור של העובדיס. 43 דרכיסם להגדלת היקף ואיכות הצעות השיפור. 4 מדיניות ההכרה והתיגמול לעובדים שתרמו לשיפור. 3 עבודת צוות ומדידת אפקטיביות של מעורבות עובדים 1 האוירה והמסגרות המאפשרים מעורבות של כל העובדיס בשיפוך הארגון ופעולותיו. 2 מדדים למעקב אחר היקף עבודת צוות ואת התהליך הבודק את ההשפעה על הארגון ועובדיו. 3 עידוד הארגון לעבודת צוות על ידי תְגמול אלה שתרמו לעבודת צוות. 4 ניהול המשאב האנושי 1 פיתוח תוכניות משאבי אנוש מתוך יעדי הארגון. 2 יקיוס אסטרטגיה ויעדיס כמותיים בנושאי גיוס, הדרכה וכדי. 3 קיום תהליך של תכנון וקידוס קריירה. 4 ניתוח המידע על המשאב האנושי לשיפור והתייעלות בכל תחומי הפעילות בארגון. 5 הכרה בתרומה לאיכות, תגמול לאיכות 1 השתלבות מסגרות ההכרה והתגמול במדיניות האיכות. 2 הערכת התרומה לשיפור האיכות ועומת תרומה לשיפור לוח זמנים, עלויות וכדי ושילובה בתהליך הערכת העובדיס. 3 מערכת תָגמול על שיפור באיכות, לעובדים ולצוותיס ומעקב ושיפור המערכת. 6 עילדוד השתתפות בהשתלמויות וכנסים מקצועייס 1 מדיניות עידוד השתלמות מקצועית. 2 מסגרת להכשרה מקצועית והעשרה. 43 מעטקב אחר השתתפות עובדיס בפעולות השתלמות והכשרה והרחבתה. 8 נלהול איכות תוכנה 7 איכות חיי העבודה 1 קיוס מערכת למדידת מורל העובדיס. 2 מערכת קבועה לטיפול בבעיות אישיות של העובדים. 3 מערכת קבועה לשיפור רווחת הפרט. 7 איכות במידע ומערכות דיוות (80 נקודות) 1 תקניס ונהלים פנימיים לתיעוד. 2 רמת המחשוב בארגון. 3 עדכון, בקרה והפצה של נהלים בארגון. 64 ארכיון. נספח ב': הפרס הלאומי לאיכות בתעשיה 209 אינדקס תרשימים .1 0 0 2 0 1 תרשיס 1 מפת התפיסה של הספר 0 00 080 .. ה תרשים ח.1 מפת התפיסה של הספר ||||-|-|- | פרק 1: הנדסת איכות הת(כנה .0 0 ל תרשיס 1.1 מחזור החייס של מפל המים ינ[ תרשיס 1.2 מחזור החיים שבסגנון + | || תרשיס 1.3 מחזור החיים במודל החילזון (הספירלי) 0 פרק 2: מערכות לניהול האלכ(ת - לש₪ מ .וווזוזויויויווויווווווווויוי---.81 תרשיס 2.1 תהליך איכות .-.--- -2.-.-ה-/- / ו תרשיס 2.2 תהליך עיצוב איכות ל תרשיס 2.3 אי מבנה תקן 9001 150 ||[ || תרשים 2.3 בי מבנה תקן 9000-3 180 0 "יי תרשיס ח.2.1 דוגמה למפת תפיסה כללית של חלק שנל 0 פרק 3: ניהול איכות, סיכונים ופרויקטים יי 0 0 0 תרשים 3.1 פרויקט תוכנה טיפוסי ]|| || תרשיס 3.2 מחזור חייס מטיפוס | || | || | תרשים 3.3 קטלוג דרישות ו | .|| תרשים 3.4 ניתוח קו פעילות עבור תהליך הזמנה בדואר 95 תרשים 3.5 טבלת קווי פעילויות של חברה למכירת ספרים בדיוור ישיר וו תרשים 3.6 מדידת ביצועי המערכת 0 אינדקס תדרשימים 2201 פרק 4: תהליך הפיתוח הבסיס: 0 7 תרשיס 4.1 מודל מפל המיס ו || תרשים 4.2 מודל החילזון ב תרשים 4.3 מודל מסוג צ ש.י תרשים 4.4 המוצריס המופקיס משלב הדרישות 91 תרשים 4.5 בדיקת המוצריס המופקים של שלב התי:כון 1 תרשים 4.6 מודל מחזור חייס לפיתוח תוכנה 107 פרק 5: עיקרי מערכת האיכות - לב המערכת || 117 תרשיס 5.1 בקרה בלולאה סגורה ל 110 תרשיס 5.2 בקרה בלולאה הסגורה של מערכת איכות 1 תרשיס 5.3 דוגמה של תוכנית מבדק פנימית 0 יי ו תרשיס ח.3.1 מפת התפיסה של חלק 3 107.02 פרק 6: מדידה ושיפור תהליכים 7-ל תרשיס 6.1 גישת ]000% 1 תרשיס 6.2 ניתוח 001 של עלות העיבודיס החוזריס 139 תרשיסם 6.3 רמות עיבוד של מדדיס 1 תרשים 6.4 לוח המחווניס של מפתח תוכנה 2 146 תרשים 6.5 תרשים קיוויאט עבור יכולת תחזוקה || תרשים 6.6 תרשיסם זרימה המייצג תהליך פיתוח תוכנה 1 תרשיס 6.7 תרשים זרימת נתוניס המייצג תהליך פיתוח תוכנה 1 תרשים 6.8 מנגנוניס לשיפור תהליכיס 0 1 תרשיס 6.9 מחזור 2264 ל תרשיס 6.10 דיאגרמת אישיקאווה לבעיית שגיאות יתר במבחני הקבלה 1-4 תרשים 6.11 יומן שגיאות תיכון 10 2 ניהול איכות תוכנה |[ | ורי תרשיס ח.4.1 מפת תפיסה המציגה את הקשרים בין רעיונות המפתח שבקטע. 166 פרק 7: איכות ומחזורי חיים לא-קו(לים ..... 5 0 167 תרשיס 7.1 מחזור חייס רציף: (3) הרצף (ט) איטרציה של שלב 1 תרשיס 7.2 מחזור חייס איטרטיבי: (3) הספירלה האיטרטיבית הבסיסית (ט) רבצף של ספירלות || תרשים 7.3 דרך למיון שיטות לא-קוויות 170 תרשיס 7.4 תהליך פיתוח סכימתי עס מגבלות שנקבעו 1712 תרשים 7.5 גישות של פיתוח תוספתי: (9) גרסאות בריבוי מערכות; (ט) גרסאות בריבוי פיתוחים; () הספקה בריבוי תוספות 173% תרשים 7.6 מחזור חיים של פיתוח מבוסס-חבילת-תוכנה 17% פרק 8: יצירת אב- טיפוס ופיתוח יש(מלם מה?( 4 1 תרשיס 8.1 אבטיפוס של הדרישות 1 תרשיס 8.2 אבטיפוס התפתחות: (אבולוציוני) 8[ תרשים 8.3 פיתוח יישומים משותף - 12 17 תרשיס 8.4 האסטרטגיה ההתפתחותית (אבולוציונית) 180% תרשיס 8.5 תכנון התפתחותי (אבולוציוני) .|| || תרשיס 8.6 תכנון ראשוני לפרויקט 83 1 תרשים 8.7 גישת תיבת הזמן > || פרק 9: פיתוח מונחה-עצמ?ם.....5 0 ה 0 1 תרשים 9.1 מודל עצס של חניון (9) החניון; (ט) המודל || || תרשיס 9.2 מודל עצס של מסוף מעבורת 2 תרשיס 9.3 הורשה: (9 יצירת חניון לפי סוגי המכוניות; 2 (פ) יצירת קולנוע דרייב-אין. 0 תרשיסם 9.4 פיתוח כלאיים אוזסעגת 07 תרשים 9.5 מודל צ משופר, עבור גישה מוכוונת-עצמיס ממ 08 תרשים 9.6 מחזור חיים מוכוון-עצמים ,27007 תרשים 9.7 ניהול פרויקט עבור פרויקטים מוכווני-עצמים ל אינדקס תרשימים 223 מ4ק 5 וו 0 0 הוור ו,. תרשיס ח.5.1 מפת התפיסה הכללית 2 פרק 10: הדרך שלפנינו.....> 0 0 221-555 תרשיס 10.1 המודל האירופי להערכת האיכות שג 277 תרשים 10.2 מודל בשלות התהליך 05505 וק תרשים 10.3 מערכת ניהול האיכות (15א0)) בתור עוגן 9[ תרשיס 10.4 מסגרת פרויקט 50105 2 תרשים 10.5 טבלת הבשלות האיכותית/טכנולוגית 0 4 ניתול איכות תוכנה אינדקס עברי א אבטחת איכות 28, 33, 195 06מ2550:8 ע1ו[3טף אבטיפוס 36 0006:)סזק דרישות | 184 מחלקות ‏ 207 פיתוח ‏ 183 אובייקטיס (עצמים), מוכוון 38 066מ00[60%016 אחריות | 810111%0ת16520 הנהלה 49 |מסות6קגחגות תחוס ‏ 122,67 אידרת הדג, דיאגרמה 160 :0438 6ח000ם₪5 איכות 26 ע8411טף אבטחה 33,28 06ם4550:8 בקרה 28 6000101 רשומות 129,50 160065 טוטלית (כוללת) 224 226 108 מבדק 125,118 |/6נ2 פנימיים | 124 |4מש6ותו מדידה | 70 )ת6450:6(6ות מדיניות ‏ 121 ץסו|0ק מדריך 49 [4טתגת מוצר | 163 6%ט4סזק מערכת | 5/7968 איכות | 117 ו[604 ניהול | 33, 41, 46 )תסות6קגתגות תהליך 44,33 655ססזק תוכנה | 42,32, 55 תכנון 215 שתומםג!ק , אימות 36, 44, 90, 95, 168, 179 | 61862000/ אישיקאווה, דיאגרמה 160 6323 10189 ארגון תחומי אחריות ‏ 122 אירוע בדיקה ‏ 112 16980856 אינדקס ענרי | 275 ב בדיקה | 67,49,30 16518 אירוע | 112 0856 בחינה 48 ת5060010ם1 בקרה ורישום. 9 שם:660:6ז 6 601101 דרישות 106 משלימה 110 קט-שס!10 רמות 104 | 1668 תכנון | 105,104 תגוק תקפות | 90,36 ת%8104810 ביצוע 66ת8מחס)זסק גורמיס עיקרייס 0 אסא שיפור ‏ 155 תיכון 107 ם66%818 בנייה, מצב | 112 58405 6[וטס בסיס נתוניס מוכוון עצמיס 200 0028 בקרה [₪0ם60 איכות 28, 195 עו|8טף דרישות 75 8)תש6ות6ז!600ז רישוס בדיקות 109 8ם65%10881) רשומות איכות 50 1660165 ש4110טף שינוייס ‏ 112,92, 196 86ם08 תהליך 48 658ססזק פיתוח יישומיס ‏ 193 |]ת6ממקס|6ש66 ת08000ו1קק9 תִיכוּן 48 ת66818 תיעוד | 50, 76, 129 04)8 6ת8 זתסותטס0 בשלות עזוזוגות יכולת, מודל 225 ]אס תהליך ‏ 225,221 658ססזק ג גורמי ביצוע עיקרייס ‏ 190 עס גיבוש גישות 228 פסתסגּסזקקג 116 8ם60050110811 גירסה ם510ז6ע חדשה ‏ 111 ם0ס6:50ץ ש6ת ריבוי גרסאות במערכת 173 6|628565 גת5/5%6 111016גורת ריבוי גרסאות פיתוח 173 662565 )ת6נתקס[6ט66 1)1016גוות 6 ניתול איכות תוכנה זז זז הזו זו זו ץע וקד אשוופמו משודקמרמ ומת זפעממפשוו וש /-<‏ =-|=-=- = םר | גישה (שיטה) 0 6₪ס)סו1 בשלות התהליך 221 עווזוגת 655ססזק התפתחותית | 169 ץזגתסט|0טס מבוססת | 029566 מודל | 225 0668 מוצר 206 60ט6סזק תהליך 206 655ססזק תקנים 222 כלאייס | 206 6מסעת מעלה-מטה 149 תש60-קס1 מטה-מעלה ‏ 149 קט-מסחסט שיפור תהליכים | 226 תוספתית | 169 |])תשות6זסתו . דיאגרמה 88ז6140 אישיקאווה 160 האגאוםת1 אידרת הדג 160 6ת00ת15 קיוויאט 144 )טוא דרישות 5!ת6ות6ז1טף6ז אבטיפוס .184 6קץ0%:סזק בדיקה 106 6868 בקרה 75 [000ת060 הגדרה 69 ם0(:םת660 מעקב 71 פִת840ח ניתוח 68, 74 פַַעְ4ח8 קטלוג ‏ 77 פתוקס|08!4 תיעוד | 76 ם))ת6ןתט600 תקן 48 02:0ת58 ה הדרכה והסמכה 50, 123 פפותוגז1 הודעה/מסר 200 655826ות הורשה | 204,200 6סתג8ת6חתג היתכנות | 186 ש011סו635] הנהלה ]ת6ממתסקגתגות אחריות 49 ע111ס51ת0ק65ז סקר 119,49, 126 ש6ש6ז נציג ‏ 123 אינדקס עברי 207 הנדסה 8מתססתוַקת6 עקרונות 27 תוכנה 30,29, 117 2:6א/50 תהליך 33 655ססזק הסמכה 149 222 0011110410 הסתרת מידע 200 ₪מ161ת תסוזהמתס)תו הערכה עצמית 221 224 ]ם8556585(6-)561 הפשטה 200 ב805140010 הצגת מדדיס 142 66זט685ות הצמדה דינמית | 200 פ8תו6תוס סננמא8תץ6 השוואת ביצועיס 153 )ת6ן6זט635ו 66ת8מהס)זסק השפעות, ניתוח | 110 5515/ו4ת8 80%קח1 התפתחות 169 189 עְזַַת0וט[0ש6 באמצעות תחזוקה ‏ 175 גישה 169 46סג)ת לא מתוכננת | 170 מסגרת 228 אזסש6ג] 170 תננכותמ‎ ז זיהוי 111,92 תס0ו)61104ת146 זיהוי תכונות 30 65זטס8111 זיווג ‏ 99 פת:1קט00 זמן, תיבה 194 שתואסס6וח ח חבילת 6קַּאסאק יישומיס ‏ 101 ם00800!קק8 תוכנה 174 50/)0/8:6 חוזה, סקר 71,48 ש16ש6ז)080ת00 חילזון, מודל 36, 87, 168 [86סת [8ז501 חסר תכונות 176 16800:6]658 חשיבה פ>תואמות) מסתעפת 140 )ַת86ז6ץ61 מתכנסת 140 )ת6קז6טת60 8 ניהול איכות תוכנה >י י ו 0 טבלת קווי פעילות 78, 190 16865 ץ]1ש400 טכני, כלי 158 טכניקות סטטיסטיות 50 5סטף1םמת66 |5181151108 י יומן שגיאות ‏ 161 08 ז0ה6 יישומיס 5 פיתוח מהיר ‏ 183, 187. פגת בקרה 193 תכנון פרויקט 192 פיתוח משותף 186 פגך יכולת הערכה 225 מודל בשלות 225 ]אא מעקב 111,92‏ 880680110 יעדים 138 80815 ישויות 136 11165ת6 כ כישור | 183 5611 כלי תוכנה 101 0015) 5010/9416 הכנה והרצה ‏ 103 מנהל 104 זסקגתגות ניהול ‏ 103 פיתוח | 104 קריטריוניס ‏ 102 כללי תיכון | 68, 99 ל לא-קוו? ז69םו]-תסת מחזור חיים ‏ 167, 175 ניהול פרויקטיסם 223 פיתוח 181, 223,206 תכנון איכות | 178 לוח מכוונים 143 לכידגּת 99 606800 מ מאפייניס 136 401100165 מבדק ‏ 153,41, 226 | קממאזגותהסת6ס איכות | 125,118 ש:[004 כלליים ‏ 153 פונקציונליים 153 פנימייס 124 [4םז0זת1 תחרותייסם 153 פיתוח תוכנה 154 מדידה 54, 67, 70, 118 | 6מ6גת6ז68507ות ביצועיס ‏ 153 יעדיסם ושאלות 138 5מ65100טף 6ת8 50415 מדדיס 128 5סנ1זסות הצגה 142 מתודולוגיה ‏ 137 עקרונות 142 שיפור תהליכים 135, 151, 162 מדיניות האיכות ‏ 121 מדריך איכות 49 |גטתגגת ץ111טף מודל | 668סו1 איכות ‏ 224 בשלות א וזנחגות יכולת ‏ 225 א0 תהליך 225 חילזון 36 51:88 מחזור חיים 34, 72, 82 616ץ6 116 צ- 36, 88 חילזון 36, 87, 168 מפל מים ‏ 34, 86 עצם 201, 207 60%[סס מוכוון | 016166 עצמים (אובייקטיסם) | 38 00[6065 בסיס נתוניס מוכוון עצמים | 200 0028 מחזור חייס 208 ניהול פיתות | 210 ניתוח 199, 202,200 008 עיצוב 201,199 002 פיתוח 197 206 שיטות 199 [אתא0 תכנות 199 | 002 0 ניהול איכות תוכנה מוצר | 37 60ט6סזק תהליך ‏ 37 200658 תיכון ‏ 31 | ם60%5 מועדוני מבדקים 154 פ>ט[6 פתאזגותסתסט מוצר | 0%ט6סזק איכות ‏ 163 ץ00811 מוגמר ‏ 27 6611/0806 מוכוון | 37 0666 מורכבות ‏ 99 צע1א6!ק60 מחזור 2264 | 157 מחזור חיים ‏ 29 94 66ע6 116 לא-קווי 167 68תו|-םמסם מודל [46סג1 צ- 36, 88 חילזון 36, 87, 168 016ע6 116 [4זוק5 מפל מים 34, 86 ג זסוָ4א מוכוון עצמיס 208 פעילות ‏ 51 מערכת איכות ‏ 51 פיתוח| 30 |]תסממק0ס|6ש66 חבילת תוכנה 174 קווי 7, 222 זגסמם:ן מחלקה 200, 207 0[2858 מטה-מעלה, גישה 149 סט-ותסטסט מידול תהליכים 146 פ>תו||66סו 6655סזק מידע, הסתרה 200 פִת16ת מסוזגותזסותו מיומנות ‏ 223 מיתאר ‏ 76 מנגנון גתפ8ומ4ם60ות הערכה 179 פעולה מתקנת 119 8010 606011/6 מנהל כלים 104 זסקגמגת [100 מסגרת ‏ 51, 228 מסד מידע ‏ 187 162051007 מסר/הודעה 200 655886ות מסתעפת, חשיבה 140 %ת6קז0ץו6 מעלה-מטה, גישה 149 םא0ס6-קס) מעקב, יכולת 111,92 40620110 אינדקס ענל: | [28 מערכת 556 איכות ‏ 117 ניהול איכות 33, 41 46 5956 זמ6תסקַ8ת3)/ ע411טכ) - 61/85 ריבוי גרסאות | 173 6!]64565: ג5%68ע5 16ק1[טות מפל מים, מודל 34, 86 | 46סג !]8 ז910ש מפת תפיסה 22,20 פ5כגת שתנות מצב בנייה 112 588058 6!וטס מצייני הצלחה קריטיים | 190 081 מתודולוגיות 88, 94, 97, 137 מתווה 45 זטסץ12 מתכנסת, חשיבה ‏ 140 )םסקזסעת00 , נהלי פיתוח תוכנה | 97 נוהג 01006גזק תכנות 59 נטול מסגרת 37 664מ6 מסקס ניהול ]מסנח6ק4מגות איכות ‏ 195 אבטחה ‏ 195 בקרה | 195 כלים ‏ 103 1008 מערכת ניהול איכות 33, 41, 46 5/5061 ]מ42610מגגת ץ8111טף סיכונים ‏ 63 188 פיתוח מוכוון עצמיס 210 פרויקט ‏ 83, 176 לא קווי 223 תצורה 31, 54, 67, 92, 111, 114, 180, 196 תסוזגזט18)תסס תוכנה | 39 תקן 40 ניטור ההתקדמות 177 8םמס)ותסגת 658זקסזק ניתוח 5ַ5ַעוַּת3 דרישות 68, 74 השפעות 0 0%הק1 מוכוון עצמיס 199, 200, 202 40417515 166מ02116) +00[60) - 0004 סיכוניס 65 נציג הנהלה | 123 12 ניהול איכות תוכנה סִ סדנת 142 | 186 סודר 86 018)ת5606 סיכון 82 15% ניהול | 63 )מסות6פגמגות ניתוח | 65 סיבות | 59 צמצוס ‏ 65 סכימות הערכה 224 506866 8₪3:6 סקר ש46ַ6ז אימות | 90 ת6180880ע הנהלה | 119,49, 128 זתסות6קגחגות הנחיות 55 חוזה 71,48 60808 חוזר 68, 128 תהליך 180,161 66%5ססזק תיכון 45, 160 66518 ע עדכון ‏ 111 6ת8:)8? עיצוב (תיכון) מוכוון עצמיס 199, 1 68 166ח16ז0) ז60(ט0 - 00 עצס (אובייקט) | 200,38‏ 00[606 בסיס נתונים מוכוון 200 0008 טכני 200 108ם602) 201 לדומ‎ ניתוח מוכוון 199, 200, 202 003 פיתוח מוכוון 39, 197, 199 0116166 עיצוב (תיכון) מוכוון 9, 201, 203 000 עסקי 200 5פ6תנופטס שיטות 199 אס תכנות מוכוון 9 פתוותתתגזק סז? 106ת16זכ) 0060 - 007 5 פגמיס | 156 פיתוח )תסנמקס![6ש66 ידור רביעיי 100 התפתחות (אבולוציה) | 38, 184 | מסטש|0ש6 יישומים 38 5ת0800!קק8 אינדקס עכרי | 283 חבילות| 101 8265אסגק ת102))0[קק8 מהיר ‏ 187,183 192 86 משותף 186 0%[ לא- קווי | 167, 175, 178, 181, 206, 223 זג6ת!|-מסם מוכוון עצמיס (אובייקטיס) 9, 197, 199, 206, 210 | 64)ת16ז0 60%[סס מחזור חיים 30 616ע6 116 ריבוי גרסאות | 173 6|68566: ]תסותקס[6ש66 16ק1]טות תהליך ‏ 31 יצירת אבטיפוס | 183 תס0ו)גזסת86 00/26זסזק תוכנה 97 500/0/4:6 מבדקים 154 מדידה ‏ 155 עקרונות ‏ 231 תוספתי 172 |4)מ6מ6זסתו תכנון 73 פעולה מתקנת, מנגנון | 126,119 |ת(8|[ת8ם60ג ת80110 6ש601776001 פרויקט 52105 228 מםסג)גת1וח6006 ע030801[11 זםסות6טסזקנת1 2700655 500/816 פתיחות 38 156ק50506 2 צורות, ריבוי 204 התפותכסומע!סק ק קבלה, תהליך 110 006858זק 800601866 קווי ז68תו1 מחזור חיים 167 222 616עס 1116 קישור פונקציונליים 173 6866ז1] [4תס!)סתנת קיוויאט, תרשים 144 מגז8ק0!3 |זגוט1 קישור פונקציונלי ‏ 173 68065זם [8תסו!סתנת קטלוג דרישות | 77 קווי פעילות, טבלאות | 78, 190 685זם] ץ8011/1 ר ריבוי | 6[ק8!טות הספקות ‏ 174 66|/665 [8מסנת6זסת1 גרסאות מערכת 173 16108566 בת5/516 גרסאות פיתות ‏ 173 664565 ]מסנמקס61ש66 צורות 204 םמפותקסותץ!סק 4 ניתול איכות תוכנה רישוס בדיקות 109 רכש 50, 129 פמופגתסזטק רשומות איכות, בקרה 50, 129 | 60065 ע4111טוף 01 01ז1ת00 רשימות תיוג | 45 65[א0260 ש שאלות | 138 5ת%0פסטף שגיאות, יומן ‏ 161 0:105ח6 שיטה (גישה) | 200 6סג)ת שיטות מכוונות עצמים 199 ]אס שינוייסם, בקרה 92, 112 [0שת00 86ם004 שיפור )ת6בת6טסזקותן ביצועים ‏ 155 תהליכיס 151,149,145, 221 226 655ססזק מדידה 162 מתזור 004 1577 שרטוטל תיכגּן 28 15ַ8זק613 ם66518 ת תבנית 76 תהליך 145 6858ססז2 איכות | 44,33 ע604|1 בשלות, גישה 221, 225 שגות הנדסת תוכנה 33 קתה6סתוקת6 5010416 כלפי מטה 162 מ5003מ60₪ כלפי מעלה 162 |688חפ5קט מוכוון | 37 6646)ם00 מדידה 162 )תמ450:6סות מידול 146 8ם[66סות סקירה 161 אסןץס6: פיתות ‏ 114,31 |תסותקס|6ע66 קבלה | 110 06ם2)ק40000 שיפור 145, 149, 151, 157, 221, 226 |]תסות6טסזקותו תשתית 40 תוכנה 25 6:ז4ש50/0 איכות 32, 42, 55 | שו!גטף הנדסה 29, 30, 117 8תת66תוקת6 תהליך ‏ 33 6688ססזק התפתחות מתוכננת/לא מתוכננת 170 אינדקס עברי 25 חבילה | 174 כליס | 101 1005 פיתוח נהליס ‏ 231,97 תחזוקה 131,93,85 תחוס, אחריות 49, 67, 122 ע5101110ת16500 תחזוקת התוכנה | 131,93,85, 175 תיבת זמן 194 קתואסט6חו תיוג, רשימות 45 060%[56 תיכון/ עיצוב 26 ם66518 ביצוע 107 בקרה 48,28 [60₪80 כלליס 68, 99 מוכוון ‏ 203,31 66)ם16ז0 סקר 45, 160 ש6ש6: תיעוד, בקרה 50, 76, 129 [0ש0ת60 6368 6ת3 זמ6ותט600 תכונות 30 80110165 חסר תכונות | 176 1620176655 תכנון | תג!ק איכות | 215 בדיקה 104 66%) חוזר 178 ניהול תצורה ‏ 114 73 חותיפ‎ לא קווי 178 קווי 167 פרויקט 72, 192 ראשוני ‏ 192 תכנות מוכוון עצמיס 203,199 002 תצורה, ניהול 1, 54, 67, 92, 111, 116, 180 תסוזגזט18])מסס )מ6ות26התגות תקן 0:ז03ם518 גישה 222,40 8006585 דרישות 48 68)תשנת60016 מסגרת ‏ 51 אזסשסותג) סדרת 9000 150 | 47 קוויס מנחים ‏ 51 65מ[66וש8 תקפות, בדיקה 90,44,36, 179,168 | ם8[:6800 תרשים קיוויאט ‏ 144 חגזקג!6 )8וט1 תשתית, תהליכים | 40 6 ניהול איכות תוכנה אינדקס לועזי 4 הפשטה 200 20518010 תהליך קבלה 110 6655סזק 8666218866 טבלת קווי פעילות 78,190 106805 ע!וצו801 ניתוח 5ו5ש41ת8 0 )80קוחו 2 ,200 ,199 515ע4081/ 01168166 00[601 - 004 יישומיס ןוקק פיתוח משותף 186 כג1 פיתוח מהיר 187 ,183 380 תכונות, מאפייניס 136 ,30 6וטפזווג חסר תכונות 176 61655זט)ג6] סכימות הערכה 226 566665 6זבג 5 מבדק 41,153,226 פת!אזגוחם0ם6ל 4 5סט[6 5 זזו|גטף מטה-מעלה, גישה 149 פט-ותסווסט מצב בנייה ‏ 112 518185 6[וטט 6 הסמכה 149,222 ם66111816841/0 שינויים, בקרה 92,112 |0ז1ת60 6886 רשימות תיוג | 645 066811588 מחלקה 207 ,200 61855 מודל בשלות ‏ 225 ]א]א לכידּת 99 ת0ן6065 מורכבות 99 עזוא6ןקו 60 גיבוש גישות 228 65ה6גסזקק4 6ת! 0-5 חוזה, סקר 48,71 6 60801 בקרה 601101 6 אינדקס לועוי | 287 8 66918 9 ,76 ,50 %ת6000116 8 00688 3 )|מסגתקס[6ש66 מ0ס:1ז1108כק3 5 ,28 ע1ז811גו 9 ,50 1600168 5 185מ016ת16001 9 פתושפסן 165% חשיבה מתכנסת 140 %ם6שז6טםת00 מנגנון פעולה מתקנת 126 ,119 (18מ6028ת ת80110 0011601146 זיווג 99 שתו[קט00 מצייני הצלחה קריטיים | 190 091 כ תיכון/ עיצוב 26 ת665]8 8 [10מ00, 3 066)םת0116 7 6סתאותתס)ז6ק 0 ,45 ש16%16 שרטוטי תיכגּן 28 6180:8[85 ת66518 פיתוח 100 6610 8 ם1/68000סק8 6 %ת01[ 1 800886 2 ,183 8016ץ 4 ,38 תסו6ט6/01 2 [8)ת6גת6זסת1 0 61]6ע6 1116 3 761685655 ]ת6ותקס66761 1)1016גוחת 3, ,1789 ,175 ,167 ז68ת:1-תסת 0 ,206 ,199 ,197 ,39 166ת16זס 60%[ס0 3 ת61810ת86 26ץ%01)סזק 1 ,154 ,97 5010216 דיאגרמה ַ8גז130ו6 אידרת דג 160 6תססת15 אישיקוואה 160 גש8א1ם15 קיוויאט 144 ז8ש%1 חשיבה מסתעפת | 140 |מת6706צ:ו6 תיעוד, בקרה | 129 ,50,76 6001 6812 תג )0006 הצמדה דינמית | 200 שמושתנס סותתגתץ4 8 ניהול איכות תוכנה מ הנדסה פַת66תופח6 7 5008:6 3 00658זק ישויות 136 0166ַת6 יומן שגיאות 161 8ס!|ז0ח6 התפתחות 189 ,175 ,170 ,169 עזגםסווט[60 8 א:0ש6וגז] 9 6סת1שות ץ היתכנות | 186 /6851011) חסר תכונות 176 16801:6655 דיאגרמת אידרת הדג 160 :613278 6תססת5ת קישור פונקציונלי 173 6866זם1 |4תסו!6תט] 60 יעדים 138 2085 % דיאגרמת קיוויאט 144 (גז7קג6 וגוצוא גורמי ביצוע עיקרייס 190 "לא 1 זיהוי 92,111 ם11863000ח166 ניתוח השפעות | 110 55ץגמםג ]סהקות1 שיפור )םשוח6טסזקותג 5 6סחאמת0)ז6ק 6 ,149 ,145 00655זק 7 6כץ הסתרת מידע 200 פַתו6ום מסגזפותזס)חן הורשה 200,204 61)8006מת1 דיאגרמת אישיקאווה 160 ₪חג6/221 גאוג16מ15 1 6 סג א כ לועז 209 5 מתווה | 45 )טסעגן מחזור חיים 29,94 616ע6 116 0 )מסותקס61ש66 2 680מ11 1 8 ,36 0/016 1116 51781 8 6 ,34 1811 ז6ז8/ 7 ז68מ1!-תסת קווי ז69םו1 3 176865 [8מ6110מגת 2 0606 1116 ]א הנהלה )מ6גת6פגחגות 6 ,92 ,67 ,54 ,31 ם11801801:0ת60 5 +81 6 35/90 9 :1680051011 סקר 119,126 ,49 16/16 3 188 9 50104:6 0 08:10ם518 3 001585 בשלות עווזגחגות 5: | 0 5 0066*%5זש מדידה | 151,162 ,142 ,118 ,70 ,67 ,54 )מ6ות6זט85סות 8 5ם65610גוף 6 80815 8 105:)סות 3 6סתגוז0)]זסק הצגת מדדיס 142 65זט685ות הודעה/מסר 200 655866ות גישה (שיטה) 200 006ג)6ו1 6 5 [86סות 6 00658%צש 6 0600%זק 0 ניהתול איכות תוכנה 9 קט-נמסזוסס 9 עגמסוזט]6/0 6 6תפעם 9 [411)מ6וח6ז0םמ1 1 זנ גת 00655זק 9 תא100-60 מתודולוגיות 88, 94, 97, 137 611060102165ות מפת תפיסה | 20,22 פקגח 6תגנת מודל מהזור חיים 82 ,72 ,34 016ץ6 1:6 8 6 ,34 [!4] 9161 ץנ ות 5 א 00160 4 עוןטף 6 ]זנק 1 | יבול 6|קוז[טנת 7 16168565 ]מ6מזק 066% 4 1 :66ע66[1 [8זת6ח2>זסמו 4 נמי15מס:0מ1עוסק ".1 16168565 ות5/516 א לא-קוול ז64חו!-חסת 3 ">.י2 ,181 1מ0וזי9ק666[0 5 >>66ע0 1106 3 0[606%זק 0 מוכוון אובייקטים (עצמים) ‏ 197,199,200 ,39 ,38 4טוזס 01601 0 655תןפווס 06928 1 116 006 8 1 |[*פאסז1 שיטות מכוונות עצמים 199 ]א]אס 00 2 3 סכ 60מ6וז0 09[661 - 00 0 0008 9 פתוותותגזקסז? 016166 ןל - 00 אינדקט לוען: 201 ]'( )'( 7 060585ז] 7 600%סזקש 0 16001688 נטול מסגרת 37 666ת6 מס6קס ק חבילת 486אסגק 1 800סו1סק8 4 50808:6 7 04ס?ץ ביצוע 66ת8:ס)]ז6ק תיכון 107 66518 גורמיס עיקריים 190 תא השוואת ביצועים 153 זם6ן(6זַט645 66תגוחזס)ז6ק תכנון | תגוק 4 תס:80זט18ת60 3 )ת6מתקס[66/6 7 זגס6תו1 8 -68ת:]-תסת 2 ,72 60%[סזק 811 + 5 4 10865 ריבוי צורות 204 ומפותקזסותץ!וסק תהליך 145 06858ס0זק 0 006ת8006018 4 ומס6ותקס[6ש66 2 ג50:688ת/ש60 56,,, ,1499 ,145 )ת6ות6שסזקותו 5 א'ווטגות 2 %|ת16ת6850116ות 6 פת66[]1סות 7 166ם10ז0 4 ++ש811נוף 1 שס6!ש6ץ 3 פתוז60תופחס 6ז8/שז501 2 ְ51:680קט מידול תהליכים 146 8ת!0061 655ססזק מוצר | )סט6סזק 0611/612016 7 7 166ת0116 ניהול איכות תוכנה 3 זזו1טף ניטור ההתקדמות 177 פַם!ז0!ותסות 655זקסזק אבטיפוס | 184,207 ,183 ,36 6קץזסוסזק רכש 50,129 אתופ8תסזטק 0 איכות 26 ע 081 אבטחה 195 ,33 ,28 06ת8ז8550 מבדק 118,125 וו4גג 4 [84ח6)ח1 בקרה 28 [0ז1ת60 רשומות 129 ,50 1600165 9 [4טתגות מדידה 70 ]ת6ות6זט645ות 5 אחותמג!|ק 1 עסו!סק 4 0065%ז2 3 |0סט6סזק 5 ,42 ,32 6ז8או]50 הת6ו5ץ5 6 ,41 ,33 ]מ6ות6ק4חגות 7 עוו!גצטף 6 ,224 [1018 שאלות | 138 5ח0ו(65ט) ג מסד מידע 187 ץזסווצסקטז דרישות 6)ח6וחטזוטף6ז 8317515 68, 4 7 פחושסן3ובט 5 [0ז6001 הגדרה 69 חסווותו]66 6 חסו41)ח6ותט6ס אבטיפוס 184 טקץוסוסזק תקן 48 6ז03ח518 6 06 מעקב 71 שתוסגזו אחריות | 49,07,122 עוו|וסופתסקפטז סקר אשוטש6ז 600 1 אינזקס לועזי 293 234 0 ,45 66818 8 ,49 ]מסות6 התאוה 0 ת0ס)111608ז6ש סיכון 82 15% 5 80817515 3 +ת6ו6ק החגות 5 הערכה עצמית 221,224 זת4855655(16-)|56 כישור ‏ 183 56111 תוכנה 25 50416 29,307 8ם!ז66תוקת6 3 006858%זש 5 ,42 ,32 8110 3 ,0 10015 4 ז480חגות 8 תסוזתנגותז6ז65 6240901111 1ת6ות6שסזקנת1 2706655 6ז8/ו60 - )עפ חילזון, מודל 168 ,87 ,36 [66סג |[4זוק3 תקן 6ז043ת5)8 8606585 40, 2 1 אס 86 1 65ם[80166[1 105 9000 7 8 15מ6נת6ז!ף76 טכניקות סטטיסטיות 50 65טףותת160 [518)151168 פתיחות 38 0[16ק50506 מערכת ההח5/5)60 3 61685665 הת5/516 111016גווח 46 ג 5908 1ת16ת86ת3]א עזו[8טכ) - 615 7 עזו!8טף ד אירוע בדיקה ‏ 112 60856 |65) בדיקה 30,49,67 ₪ַת50סן 0856 2 9 שת660:6ז .6 [0ז)מ00 0 קט-אסו101 8 תס1)ט6קס5חו 4 6[]%5ש16 5 גו ניהול איכות תוכנה תקפות 90 ,36 םס0ז41103ש חשיבה פמואתותז מתכנסת 140 1מ86ז6/מ60 מסתעפת 140 ]ַת6שז6ץן4 תיבת זמן 194 פתואסס6חט מנהל כלים 104 זספגתגות |100 מעלה-מטה, גישה 149 תש60-קסז יכולת מעקב 111,92 ו[466801ז1 הדרכה והסמכה 50 123 פ>חוחוגזו ץ בדיקת תקפות 36,44,90,168,179 ת00ג0ו|גצ עדכון 111 %הג!ז%9 אימות | 168,179 ,95 ,90 ,44 ,36 ח686800 גירסה תסו5ז6 3 1616565 זת6ותקס[6ש66 6!קנז!טות 3 6|64565ז ות5/516 16ק1![וות 1[ אסשת שש מפל מים, מודל 34 86 |₪006 ||8] ז46א אינדקס לועזי 25 הוצאת הוד- עמי לספרי מחשבים הראובני 6, ת.ד. 6108, הרצליה 46160 טלפון: 09-9564716 פקס: 09-9571582 ]ז.ו6ו.תסופטוס(6וום הס קטלוג 3.97 לקבלת ק טלוג ממוחשב עם כל הספרים בתמונה וצבע: אינטרנט, חנות וירטואלית: /60.17.זון[אט. שתועש//:ק1ו אינטרנט, דואר אלקטרוני: ]ושח חסנצושעטו6)ווחם 4סו! פקסס: 09-9571582 או טלפן: 09-9564716 5 )0ס05זסו]] זז 6560 ב =]) 1 | 3 1 פע., ו 5 פו0 תו 5/0065 ו בספרי הוד-עמי תמצא גלויית החזר על חשבוננו. מלא את פרטיך ושלח בדואר (אין צורך בבול). אנו נעדכן אותך בספריס חדשים, חומר עדכני, תקליטוריס חדשים, מבצעים ונשלח לך את עלון הוד-עמי למשתמשי חלונות המכיל טיפיס לעבודה בחלונות, אינטרנט ו-6זסש. 1 ספרים שנכתבו במקור בעברית ספריס על 0 ספרים על מערכת הפעלה 95 0 ספריס על ++6 ספרים על 6 6זס/ ספריס על 5 8661 ספרים על 7 661א5 ספרים על 7 6זס/ 0 00 0 0 2 םת הוצאת הוד-עמ* לספרי מחשביט הראובני 6, ת.ד. 6108 הרצליה 46160 טלפון: 09-9564716 פקס: 09-9571582 ]1 זש מסזפזעוסוזפ6זוו. 0סו פשימת/הסיפק2ס:97. 63שששצלצל לקבלת/ק טל טק קלנט שו | עמ ] ₪2 | מחירי | ככ 9'3'0!מ/מ 95 פשססח;שע 2000 !ממ 95 5שססחושש זסו 7 סזס/ש + 60 לומדע 2070 12'9'2מ'מ 95 8שססחוש זסו 7 סזס/ע לק 9'9%2!מ/מ 95 פשססחו/ זסו 7 ו6סא=] לק 19/9%0מ/מ 95 5שססחושש זסז 7 והוססזפשס 0000 19'9%20מ/מ. 95 פ5שסטחוש זסז 84 7 ופסא 207 3%2'/ממ 95 5שססחושש זסו 7 06655 02 9'9'2/מ/מ 95 5ששססחו/ש זסז 2 זסזסוסא= ]6חז6וחו 2000 9/9'2/ממ המחשב האישי שלי עס 95 פשססחו/עש 2002 4'9'2/ממ. 95 פשסטחושש זסו !דרו 2000 9/9'2/ממ. 95 5שססחוש זסז 3 ₪6)50806 צעדיס ראשונים ב- 95 5שש60חו/ עובריס ל- 95 8/ש60חו/ 5 פששס6ת:\ בקלות 7 010/ במשרד הממוחשב 7 [66אם מהצעד הראשון + תוכנת 2צ 10018-% ם 7 [66א₪ למי שכבר יודע קצת 5 8או1800/ טיפיס לעבודה ברשת ץזז5וקסת 95 5/ו60מו/ בשליטה מלאה 6 !/\ 62016108 למשתמש המקצועי 5 60ת/ זס] זא6ז() צעד-אחר-צעד ד ו ₪ ש סי כ ₪0 0 / ₪ 8 , 9 ש - - ₪5 0 צ סי ₪ ב ס צר 9 5 ל מס - 4 5 ₪ |שש | ₪ = |ס |תש כ |5 | ₪ - |= סי |פי |9י 0 וס ש |ש | 1 ₪ | כ | 9 תוכנות 27116-8) לחלונות 3.11 (מתאים גס לעבודה ב-95 חו/) 6 6זס/ במשרד הממוחשב 6 %016 בבית-הספר 6 016/ צעד-אחר-צעד 5 [66א5 במשרד הממוחשב + תוכנת 2ץ 700158 - א נש = 2 2 ₪ ת% ₪0 - 09 2 66653// פיתוח יישומיס ללא קוד המחשב האישי לשירותך (חלונות, 895או00ח\, אינטרנט, 06ח/0) הדי 2 5סתג/ 107 1א16() בעד-אחר-צעד -] יש 5 ₪ | ₪ | | .₪ סל ₪ סי ספרי 177655 1/0:050[1/ בעברית 6% כ[116 ספר התמיכה .| יש | יש ש | שת 5 | ₪ 0 | 0 ב 4 3 5 אינטרנט אא דא >] )( +4 = סס = 2002 כ5'ל'ל/מ/מ 95 פשסטחו/ זס) 2 זסזסוקאם וסחזוחו (ת?6] כסלכק כַ'ליל/מ ית - 95 פשססחו// זסז 3 6150806 כ 0 [60] 89 | 9 | | | | | | | המודם באוטוסטרדת המידע. ‏ 7 77 0 00 0 0 | 30 [₪] 65 | וו שווכקכהקוקתב קוו תבככמ פה ה המכסה וו מ ם ממה | ₪ | | | .| הנשמו | 081% למתתיליסוות- ‏ ה ה ור ור ה 0 | | 96| | קסופו יכפוהה הוה | 6 - חומרהותוכנה 7 ה ו 00 0000 | | השבחת המחשב האישי - עשה זאת בעצמך ‏ ה | | המחשב האישי למשתמש המקצועי (מחדורה 5). ...= | המדריך השלם לטכנאי 6 ורשתות תקשורת ?6 וטו תכנות 18/8 עס + +1 15041 כ 4 | | מ | 3% | | 695 משבר המחשוב של שנת 2000 | 3 |₪| 15 מבוא למדעי המחשב עם + +6 לצ | |[שן 9% | גרפיקה בחלונות עס + +-6 6ח80713 47 + +0/6 - פונקציות ספרייה - ערכת כלים למתכנת || ₪ | + +6 בקלות 9 הדי? | 4% | 9 ₪ | המדריך לשפת + 6 תלת מה עצפו 100 םה | 6% חשומים מתקדמים 7 7 אה |שן ה ו | חמדריך חשלם לעפת 6 טוונ | ןמ ₪ | שפת אסמבלי למחשב האיש 7 ו 0 0 כ |288 פסקל מהצעד הראשון טורבו-פסקל - תוכניות, בעיות ופתרונות -פסקל. | | טורברפסקל - תכנות מבני למתחילים ומתקדמים ו[ 40 ] | מלאכת מחשב- 1 009086 7 ה |[ ]| 5 | מלאכת מתשב- 3- 08109480 תכנות מתקדם | 1-0 ₪9 | ₪2 | ת וווממסכמימשופווומוומ ה ד | מחופל יישומים ונטוטו נתונים --- ו וון | | 00 ופיז/תית 55 7 הכש | 6 | | | 396 | || ו 0 ארגון נתוניס וקבציס 2 60655 פיתוח יישומים ללא קוד בסיסי נתוניס טבלאייס ושפת .5)(1 100 כלי פיתוח תוכנה ותרגול 15-4020555 8 - 2 5 60%/8ת1/ טיפיס לעבודה ברשת לצ 256 שרת דא, 3.51 ז6צז56 א 60₪5חו\ - כרך א' + עדכון ל-9 | 4 200 שרת 1א, 3.51 56461 ידא תא - כרך ב' + עדכון ל-% | 4 הכל על תקשורת ורשתות במחשב האישי 4 2 |נר נש | לש 5 | ס |יש ₪ |פ = | רשת נובל - מדריך הפעלה ושירות. 3.12 6]/8:6צ [[6טסצך רשת נובל - 4.1 6זג/\61צן כרך אי רשת נובל - 4.1 816 \)6צ1 כרך בי כ רשת נובל - 4.1 61/816א1 כרך גי כקנצ 110 19 5סתו\ זס] 1א16() צעד-אחר-צעד רק 9'92/מ/מ 95 5שססחוש/ זסז 7 סזס/ש 7 6ז0/ במשרד הממוחשב 6 016/ במשרד הממוחשב 6 6זס/\ בבית-הספר 6 6ז0/ צעד-אחר-צעד .₪ פס ו 4 99 שי סיר נש ₪ | ה ₪ ב | םב 2 ₪0 כס|5 ס סרק 19'9%2/מ 95 פשססחוש זסז 7 ו8סא= 7 [066א5 מהצעד הראשון + תוכנת 2צ 70018- א 7 [06א למי שכבר יודע קצת 9 צר סל ג₪ ₪ צר סי ת נ סס = נש ספ -: 5 58661 במשרד הממוחשב + תוכנת 2צ 10018- 9 ש |=- ספ |= | ₪ - - ת> = סס מס 5% קן[116 ספר התמיכה משבר המחשוב של שנת 2000 מערכות שרת/לקוח - טכנולוגיות ויישומיס ז561%6/)חסו1?) 8 ם. * המחירים בש"ח כולל מע"מ ומשלוח חינ ₪ ₪ קסצכק ק13'?7מ1 חלונות 95 | 29902 כַ/ג/גוועא. :5%- 5 65חו תשובות לבעיות יומיומיות דוגמאות צעד- אחר-צעד טיפים וקיצורי דרך הדרך המהירה, הפשוטה והקלה לעשות דבריס ב- 5 פאו60חו/: עבודה עס סמליס, קבציס ותיקיות. למתחיל ולמתקדס. 6 496% עמי וְַסִַתַי גנא :7 וס/ש - ו זס) תשובות לבעיות 5 בלו יומיומיות ל , ל ל הוגמאות ]| + 1 צעד-אחר-צעך ב % טיפים / 7 וקיצורי דרך הדרך המהירה, הפשוטה והקלה לעשות דבריס ב-7 6זס/: עריכת טקסט, טבלאות, עיצוב, הדפסה, שילוב גרפיקה ותמונות ועוד. 6 8955 עמי קסצכק 1330 29309 פיי3ימויעיא שר 5 55 85ו00מ:]) זס) בל + תשובות לבעיות 1 צעד-אתר-צעד 3 : : טיפים השק 26 הדרך המהירה, הפשוטה והקלה לעשות דבריס ב-7 466055 : יצירת מסדי נתונים, עיבוד נתוניס רבים ועוד. 6 384 עמי 27300 3'3/9י/א. ₪- המחשב האישי שלי עמ 95 00%5חו)\ תשובות לבעיות [<- יומיומיות %%< דוגמאות י צעד-אחר-צעד טיפים 2 4 .₪2 וקיצורי דוך הדרך המהירה, הפשוטה והקלה להכיר ולהתקין את רכיבי המערכת, ולהפעיל: 95 5אוסשחו\, מולטימדיה, אינטרנט ועוד. למנהליס. 6 448 עמי הוצאת הד - עמ השפרכי יזיא 7 9[ תשוכות לבעיות יוזיומיות : := ל 5 = זוגמאות 6 5 צער-אחר-צעד טיפים % וקיצורי דרך הדרך המהירה, הפשוטה והקלה לעשות דבריס ב-7 661א₪ : גיליונות מרהיבים, עיבוד נתונים, חישוביס מורכבים, גרפיקה עסקית ועוד. ָ 6 664 עמי הוצאת ה (ד- עמ? כסככת ק'גו :9 6 5 סו ו 2 7 תשובות לכעיות יומיומיות דוגמאות צעז-אחר-צעד וק* שי דוך הדרך המהירה והפשוטה לעשות דבריס באינטרנט עס 3 615686א] : גלישה ברשת, מולטימדיה, קניות, דואר אלקטרוני, הורדת קבציס ועוד. צור לוין 10/96 270 עמי קסצכקת 23101?1?%20 הוצאת ה17ד = ע 912 = 29302 כִיגִינָיע | 6 20002 /כ'/9ו//2 :5%- סק סוק , ו 5 5או800:] זס) | | 95 80068ו) זס) 2 5 7 ו | | = הדעס ₪ אמומוהלכעיות 2 << ?.. -צעד | 0 ------ (>> שי < | אהש-אדי הלות הדרך המהירה, הפשוטה הדרך המהירה, הפשוטה והקלה לעשות דברים ב- והקלה לעשות דברים לימוד מתקדס של 8% [66א₪ : מאקרוס, ב-7 +חו0?ז6אוסץ : בניית התוכנה והדגשה על בניית יישומיס ועוד. מצגות מדהימות, שילוב 5 פוסטתוא'. הדרכת כיצד להפיק מ-661א₪ גרפיקה ותמונות, לעבודה במולטימדיה הרבה יותר. אנימציה והכל בעברית. ואינטרנט. בתקליטור: 8 ו כלים, תמונות ועוד... 6 7686 עמי 1'ק/4 הוצאת ה1ד- עמ? זאד ל זז 9 4 1 וו 08 ספר לימוד עצמי למתחילים ולמתקדמים גוסאות 601 1-ל לחלונות 3.11 וחלונות 95 ]16!0 065% ספר התמיכה ספר הדרכה של מתשביס שומריס את :004 <-. ₪ ב 5 )11670506 ללימוד השנה בשתי ספרות. ספר ללימוד עצמי תכנון, הקמה ותפעול של 6 זה 96 ושנת 2001 המיועד למשתמשיס בכל 6% 16[0. זה 01 וכאן הבעיה. איך הרמות - מתחיליס יוצאיס מזה! הכל בספר ומתקדמיס כאחד. ובדיסקט. 6 384 עמי 6 600 עמי 6 336% עמי ' מלוטעבנננו טבמ תבג נבת ה ,8 95 11! עוברים ל- 5 %8ו0םו בעדים ראטוניס לכ ותמשי 1 אאמ])הו \ לזלד הלקה 17 הרשה ודוק ומגדנת ** 304458 אבור ₪ הספר למהגריס ולאלה שיודעיס חלונות 3.11 ורוציס לעבור מהר לחלונות 95. קל, מהיר ופשוט. 6 112 עמי מ1[!4מ. 95 המחשב האישי ל שירותך כולל 95 %ו00ח1\ בעברית ופרק מורחב על אינטרנט - חטבר שכל ניתחיל צריץ + הצק תור 4 מס 2 רגא נן- סיס "ועו מיועד לנרתעים מלגשת למחשב בפעם הראשונה. הדרכה צעד-אחר-צעד: מבנה המחשב, חלונות, תוכנות פופולריות למשרד ולבית. 6 360 עממי הוצאת ה17 - ע מל 5 וחמ | |*עלים ראשונים ב= > 5 6 ב 2" סבר לסתהיליס בסכרנת רקכעלר 55 24:56 א ספר למתחיליס במערכת ההפעלה 95 5או00ח1/. מסכיס רבים, הנחיות, טיפים והערות, כדי להצליח בהפעלת התוכנה. 6 1600 עמי 55 5ש�0חו) טיפים 3 -. לעבודה := : ברשתי הספר מכסה את א 0506ז110א, |ו/א, משלוח וקבלת פקס ו-+6ט501160 - כל הכלים לעבודה ברשת. 6 25565 עמי לימוד 95 5אוס6חו/\ על ידי 100 משימות מעשיות ומשעשעות. בצעדיס פשוטים וקליס תלמדו כיצד לעבוד עס מערכת ההפעלה. דרור מימון 7/96 280 עמי הוצאת ה 1 - ע2מ? לאלה הרוציס לדעת הרבה יותר כיצד פועלת 5 %5ו00חוא. הבנת המבנה, היכולת והאפשרויות הגלומות ב-7ז160051]. 6 4888 עמי כ !כמ 6 אצ 00 מ₪ צבעד-אחר-צעד או מדו'ך טרער מכארט במהמיל הלטהוכדם בשרעה הרוקרים. גישה מובנית צעד- אחר-צעד, אשר תנחה אותך משלבי הלימוד הראשונים ועד לשליטה מלאה בתוכנה. הספר ל-6 6זס/צ. 5 560 עמי הוצאת ה 1ד = ע מן9 6 0 6 ס6זס/ במשהד;:הממוחשב לעובדי המשרד הרוציס לדעת תכל'ס, איך עובדיס ב-6 6זס/. מתאים ללימוד עצמי, בבית, במשרד ובכיתת לימוד. יהודית סלע 5/96 240 עמי מ !כמ 7 גצ 30כקי קימוקויעא :7 סיסע 5אוס0ח!) זס] טר 7% : תשובות לבעיות: 7 0 יומיומיות ( דוגמאות | | צעד-אחר-צעד, או - > טיפים 7 וקיצורי דרך הדרך המהירה, הפשוטה והקלה לעשות דבריסם ב-7 4זס%: עריכת טקסט, טבלאות, עיצוב, הדפסה, שילוב גרפיקה ותמונות ועוד. 6 496% עמי לעובדי המשרד הרוצים לדעת תכליס, איך עובדיס ב-7 6זס/. מתאים ללימוד עצמי, בבית, במשרד ובכיתת לימוד. יהודית סלע 9/96 240 עמי בבית. הסופיר לחר נדרך רצלח לכש לבויה פה יואר ולקכל 2 שוג יואר כל מה שנדרש לעבודה שוטפת בבית הספר ובבית. מיועד לתלמידיס בחטיבות הבינייס ובחטיבה הגבוהה. ויליאס פרגיון 7/96 הוצאת הוד-עמי 00555 2 0מך-00 פיתוח יישומים ללא קוד 6 עקרתות וטכניקות עיציב על בסיס* נתווים 8 ₪ כיתוח מהיר ומקניעי של בסיסי נתונים זייטומים ₪ רכעלת מאקיוס לטילוג אובייקטים ₪ טאלות ותונול בכל כרק סליה גישה מעשית ומובנית המנחה אותך לעיצוב בסיסי נתוניס טבלאייס. פיתוח יישומיס מורכבים בעזרת אובייקטיס. 5 435 עמי וו שששי==סס, 1/4661 5 0 1 א לא למתחילים 3 ב ופיכה בויליץ ללמה" ידות לפבכפיקי] אפי :ל 6 נתל ספקום או תה לגיר , סף גי ג" לו 5 שמ בו למשתמש העובר מתוכנת 4 [6סאם או תוכנות אחרות. להפקת המירב מהתוכנה והגעה לרמות ביצוע שלא התנסית בהן בעבר. 5 3064 עמי 0 ספר הפונקציות. ספר הדרכה ללימוד מעמיק של כל הפונקציות ב-61סאש מבית 2655 050/1זס)1/. הסבריס ודוגמאות לשילוב בגיליון. 6 388 עמי ככ 7 %661 902כַכ זוי :₪ [66ט 5 ו זו ן 8 " | תשובות .- יומיומיות | 7 = דוגמאות | .] 2 3 צעד-אחר-צעד טיפים | .ו - וקיצורי דוך הדרך ה המהירה, הפשוטה והקלה לעשות דבריס ב-7 061א₪ : גיליונות מרהיבים, עיבוד נתוניס, חישוביס מורכבים, גרפיקה עסקית ועוד. 6 68%5 עמי ספר למתתילים ולעושים צעדיס ראשוניס באקסל בשיטת ייראה ועשהיי. ישראל מליחי 12/96 הוצאת ה (ד - עמ 5 [-27 ו ו בי[ ב לעובדי המשרד הרוציס לדעת תכליס, איך עובדיס ב-5 |66א5. מתאים ללימוד עצמי, בבית, במשרד ובכיתת לימוד. יהודית סלע 280 עמי הוצאת ‏ 1(7= עמי למשתמש העובר מתוכנת 4 [66א5 או תוכנות אחרות. להפקת המירב מהתוכנה והגעה לרמות ביצוע שלא התנסית בהן בעבר. 5% 304 עמי 6.126/₪ חלונות 3.11 ו- חלונות 95 הוראות ברורות ומפורטות, דוגמאות רבות, מאות קטעי קוד. תכנות מכוון אובייקטיס ועבודה במולטימדיה. 6 336 עמי תלמד בקלות ובמהירות כיצד לגלוש באינטרנט, לשלוח ולקבל דואר אלקטרוני, מולטימידה, ועוד. צור לוין 256 עמי ,6.126 חלונות 95 59302 כי'3'3ןיעא, :%₪- 8 % 100 זט 3% 7 תשובות לבעיות : יומיומיות דוגמאות צעד-אחר קצער טיפים וקיצורי דרך הדרך המהירה והפשוטה לעשות דבריס באינטרנט עס 3 615686א : גלישה ברשת, מולטימדיה, קניות, דואר אלקטרוני, הורדת קבצים ועוד. צור לוין 10/96 270 עמי 2009 פי3י3ווא, 8+ וו 1 תשובות לבעיות <> יומיומיות + דוגמאות . צעד-אחר-צעד טיפים וקיצורי דרך הדרך המהירה והפשוטה לעשות דבריס באינטרנט עס ז6זס!א₪ )6הז6)ה[ : גלישה, מולטימדיה, קניות, דואר אלקטרוני, הורדת קבצים ועוד. 6 224% עמי הוצאת הוד-עמי אינטרְנט. מנטיס נ-6 % טבד סקיף ומעמיק על כל = | נלי החימיט גאינטותס = = )) סאות כתונית של קטלונים, | סנתעי חיכוש ואינדקסים = חיממט נבאנרי מידת נענרית ₪06 וזגמאות חיבוט. ,| רשאת תי עב 2 הספר המקיף לכלי חיפוש באינטרנט בכלל וב-60/ בפרט. כיצד עובדיס ה-5ז50166, ה-₪0006 וחבריהס... לוי, עמיהוד 2/96 180 עמי הוצאת ה17ד = ע 913 20902 -כ'9/9!י/וא, -8%- ד -----------י תשובות לבעיות קפ -* תצות1 יומיומיות מכ 1 מב-שבבעחבג % דוגנזאות / ד צעו-אחר-צעדר חכ טיפים 2 <. וקיצורי דוך 1 0 . הדרך המהירה והפשוטה ליצור דפיס באינטרנט מרהיבים, מדהימיס ושובי עין. מולטימדיה באינטרנט! 6 43535 עמי 3.11 11! מאות צעדיס המכילים את המרכיבים השימושייס ואת כל הפעולות הבסיסיות. 5 3520 עמי התנייך לחלונות. 1001 צעדיס וטיפיס המכילים את כל הייסודותיי ואת כל הפעולות שעליכס להכיר. כולל קובצי [א] ועבודה ברשת. 4% 968 עמי 6 4אק3!שיס השבחת המתשנ האיש התש -- ₪ | וה לעוש עשֶה ואת ו ₪ הדרכה צעד-אחר-צעד בלווי מאות תמונות ואיוריס להתקנת חומרה ותוכנה במחשב שברשותך. 6 288 עמי המחשב האישי למשתמש המקצועי שליטה בחוסרו; וגתוכנה של תטוערכת ררה ספר יסודי ומעמיק בייקרבייסיי של המחשב האישי. מהדורה 5 ומורחבת 6. מ. קלייג ע. שרון 480 עמי הוצאת ה (1 = ע 9/3 הוצאת ה (ד- 93 2 יי 0% מכנאי 0 ורשתות תקשורת <כנדת שת מש שדמכעי 4 התקנות, פתרון בעיות, חומרה ותוכנה, התמודדות עס תקלות. דורון סיור 11/96 432 עמ ).++ 311222253 6 . ננל קד למהגריס משפת 6 ולעושיס צעדיס ראשוניס ב- ++6. דוגמאות רבות, איוריס והסברים. מהדורה 2. 6 4830 עמי )?/):++ 7 לא צדיך כהמניא את הולגל. א ש * 800 מנקניות טסכדיית ג הכיתח טל -- + ער, ואס 7 > תיאוד, אבות טיכזס, 1 / כרמטרים זערך מיוחגר > מחת בץ מקוכות הנעלה - > הסבדים, דוגמאות ותונניות 2 . א תיאור, אבות טיפוס (סק/זסזסזק), ערך מוחזר של 800 פונקציות מספריית הפיתוח של ++0/0 6תג!זסם. אבי בוץ 1/96 336 עמי )6++ 311222253 6 למי שכבר יודע והתנסה בפיתוח יישומים ב- ++0 ורוצה להתקדם לעולס האובייקטיס ולנצל את אפשרויותיו המגוונות. שמעון כהן. 6/95 576 עמי של 7 טכניקות חדשות בתכנות ב- 32 סיביות, עיצוב ממשק משתמש עדכני וריבוב משימות. מתבסטס על ספריית 21.א. בספר עשרות דוגמאות תכנות. 7 4880 עמי הוצאת 117 = ע 9/3 > לחת קוד סי מ 2 לשברו שהטנים 1 למידה ראשונית של עקרונות מדעי המחשב בסביבת ++6. מיועד לסטודנטיס ותלמידי תיכון. שפע דוגמאות, תרגיליס ופתרונות. דייר ע. ערמון 11/96 504 הוצאת 117 = ע 3( חסוך זמן תכנות ואל ייתמציא את הגלגליי. למד איך לנצל ביעילות קוד מעוצב כראוי הפועל ללא תקלות. כלים ועזוריס לעבודה גרפית. וריע הוצאת ה1ד- עמ 6 כ כ[1מ. ++6/6 הוראות ברורות ומפורטות, דוגמאות רבות, מאות קטעי קוד. תכנות מכוון אובייקטיס ועבודה במולטימדיה. לימוד הנושאיס הבסיסייס בשפה בצורה עניינית. הסבריס קצרים, דוגמאות ותרגילי תכנות. ספר לימוד שפת 6 מהמסד ועד הטפחות המדגיש טכניקות תכנות מתקדמות. 6 335 עמי הוצאת ה וד- ע2מ? רש, ליכטמן 408 עמי יואב נתיב 6 כ כ[1מ. 84 ל | תנכות נסביגת רעבודה 55 4 =" - 4% פיתוח ממשקי משתמש ויישומיס מתקדמיס מדריך ייחודי ללימוד שפת תכנות מתקדמת. מקור רב עוצמה ללימוד עקרונות ותהליכים תחת פשסחו/. גישה מובנית ללימוד צעד-אחר-צעד. גירסה 3. 5 3-60 עממי לפיתוח יישומים : עיצוב ממשקים, 015, הקמת קובצי ק!116, התקנה יישומים. גירסה 4. 6 370 עמי מספר רב של דוגמאות העושות את הייקשהיי לפשוט וברור. גירסה 4. 16 6 ממכ[!מ פסק 4 לתלמידיס המתחילים בלימוד השפה. מותאסם ל-3 יחידות לימוד. על פי תוכנית הלימודים. ויליאם פרגיון 256 עמי ספר לימוד מקיף לתלמידיס. מותאם ל-5 יחידות לימוד. על פי תוכנית הלימודיס. אבא אנגלברג 400 עמי 20112243 6 במפזובותי מוחפ ] 0 1 24 הש 3 ספריס בסדרה יחידה במינה, ללימוד עצמי של 6 אסוט() בדרך של התנסות ופתרון משימות תכנות. דרור מימון ספר מפורט על פקודות שפת אסמבלי למעבדי אינטל 8088/8086 : דוגמאות, תרגיליס עס פתרונות מפורטים. אלי כהן 11/93 288 עמי הוצאת ה1(7= עמי לימוד בדרך של ניסוי, תרגול ותשובות. המשך ישיר לספר פסקל - תכנות מבני. 200 שאלות ותרגילים. רון בורדו 432 עמי הוצאת [117= עמי אזאשט מדריך מקיף למשתמש המתחיל ולמי שרוצה להרחיב את ידיעותיו. הדרכה מפורטת צעד-אחר-צעד. 5 4889 עמי כ6מ1מ. מק9/6מ 8 המעלה] 0 הרול ור ספר חובה בידיו של כל מנהל רשת ומשתמש! מותאס עד גירסה 3.12. 4 306 עמ כ 6 יסוזות התקעוב מותאס לתוכנית הלימודים ומיועד לסטודנטים, תלמידיס ומנתחי מערכות. גדעון קוך 11/95 352 עמי 3 כרכים המרכיביס יחד את הספר השלם ביותר לרשת נובל. מיועד למנהלי רשת, מקימי רשתות ולמשתמש המתותכם. 6 12256 עמי ו ייק הנל על תקשוות 3 וושתות במחשב 0-4 ספר מקיף על עולס התקשורת: חומרה, תוכנה וטכנולוגיות עס דגש על 26 ושילובו ברשתות מסוגים שונים. 6 760 עמי הוצאת 17 - עמ שרת זא זא 5אוספאו/ [3.5 5:05 כוך 5 - הכנה 2 כרכים המהווים יחד את הספר המקיף ביותר להתקנה, הפעלה ואחזקה של שרת דא 1 ז 56 דא התאמה ל- 4.0 דא . 6 6860 עמי הוצאת הוד- עמי מז וע 4 ₪2 ל 0% - 2" . 1 / בש . שו מדריך ייחודי ומקיף למערכות שרת/לקות : חומרה, תוכנה, טכנולוגיות ויישומיס. 5 464עמי כשחושבים מחשבים.. קוראים הוד-עמי. הוצאת הוד-עמי לספרי מחשבים, הגדולה והמובילה בישראל ו מציעה לכם מגוון מקצועי ומעודכן של ספרי הדרכה למחשבים: - 8 5 פאו00חו/צ, אינטרנט, תוכנות 03081ד6ו1א, שפות תכנות ועוד. = הוד-עמ'י ספרים שמדברים אליך ניהול איכות תוכנה מה זה, ולשם מה? ניתוח מערכות והנדסת תוכנה מבטאים את העבודה המעשית הכרוכה בפיתוח מערכת תוכנה. אולם, מהי דמותה של המערכת ומה איכותה ויכולתה לעמוד במבחן המציאות? הדרך היחידה למסור ללקוח מערכת איכות, הינה באמצעות ניהול איכות תוכנה-- עזו/8כ) 6זהשוז601 זחסחסהָהח3/. עבודה על פי כללי איכות הינה "דרך חיים" שיש לה משמעות ותוקף עבור הלקוח וגם עבור מפתח התוכנה, כדי להשיג תוצאות אפקטיביות. הספר מציג את גישת ניתוח המערכת מתוך ההיבט של ניהול האיכות באמצעות תקני 71 ו- 80-9000-8ו. הוא הופך את התקן הפורמלי לכלי עבודה מעשי ועושה אותו נגיש ומובן לכל מתכנן, מעצב ומתכנת. הספר גם מציג שני נושאים מרכזיים: מדידה, המאפשרת שיפור בעתיד מתוך השוואה למצב קיים; וטכניקות איטרטיביות ומבניות בתחום הנדסת התוכנה. תוכל גם לראות כיצד ליצור סביבת פיתוח משולבת שתתרום לתוצאות, ולא תכביד על הארגון. מכון התקנים הישראלי הסב את תקני 580-9001 !ו- 80-9000-3!ו לסביבת העבודה בישראל, וכינה אותם ת"י 2001 ו- ת"י 2000-3 בהתאמה. נספח א' כולל את ת"' 2000-3 במלואו. מה תמצא בספר? * הנחיות מעשיות להבנת תקני 580-9001 !ו- 80-9000-3ו ויישומם. * מבט מקיף והדגשת מהלכי המדידה של שלבי הפיתוח. * שיקולים והבחנה בין תהליכי פיתוח איטרטיביים ומבנים והשלכותיהם על המוצר הסופי - מערכת התוכנה. * ניתוח ההשלכות של תהליכי פיתוח חפוזים ושל פיתוח מוכוון עצמים על פי כללי האיכות. המחבר, בריאן המבלינג, הינו מהנדס אלקטרוניקה שהתמחה בפיתוח תוכנה. עוסק בניהול צוותי פיתוח מערכות תוכנה ומוסמך זואסוד. מדריך ומנחה יועצי פיתות מערכות ומהנדסי תוכנה בתחומי ניהול איכות. מחיר לצרכן: 129 שייח וו דאנאקוד 259-10155 מסתייב 965-361-124-0 158
לצפייה בתוכן