שיחה:הנדסת תוכנה/ארכיון 1

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

---

דברים שיש עוד לעשות בערך

• שיכתוב של הערך עצמו כך שלקוראי התמצית יהיה מושג טוב יותר על הערך בוצע רנדום 21:19, 14 בספטמבר 2006 (IDT)
• המשך הכתיבה על השיטות העיקריות בהנדסת תוכנה בוצע רנדום 03:27, 4 בפברואר 2007 (IST)
• חסרה סקירה היסטורית - אזכור משבר התוכנה, No Silver Bullet וכדומה
• עברי,דבר עברית בוצע רנדום 21:19, 14 בספטמבר 2006 (IDT)
• הרחבת-מה בנושא אימות תוכנה בוצע רנדום 03:27, 4 בפברואר 2007 (IST)
• הרחבה בנושאי הנדסת דרישות הרלוונטיים לתחום
• שכתוב והרחבת החלק הדן בבדיקות תוכנה
• הרחבה בנושא בניה

שלג דאשתקד

הערות לטקסט, כפי שהיה עד ל 13/12/05 נתונות בסוגריים. בהתאמה בוצעו שינויים בטקסט כך שיבטא נתונים ולא הצהרות אישיות

לרוב, הגישה הנאיבית הנדסת תוכנה מבלבלת בין התוצר ההנדסי לפיתוחו, ומבקשת לייחס את איכות התוצר ההנדסי לתהליכי הפיתוח של התוכנה. היינו, כשם שהתוצר ההנדסי (לדוגמא מטוס) עומד בקריטריונים מחמירים של יעילות, עמידות ודיוק, כך גם תהליכי פיתוח התוכנה עצמם חייבים לעמוד בקריטריונים דומים.[גישה כזו היא אמנם נאיבית, אך אינה קשורה לתהליך הפיתוח ההנדסי, גם לתהליכי פיתוח בתחומי הנדסה אחרים אין לבלבל בין התהליך ובין התוצר, ותהליכי הפיתוח ההנדסי אינם עומדים בקריטריונים דומים למוצרים] גישה זו מיושמת במתודולוגיית פיתוח התוכנה הידועה כמפל-המים (באנגלית Waterfall) המורה על פיתוח תוכנה בתהליך קווי, חד-כיווני. [ראשית יש עוד הרבה מתודולוגיות פיתוח "הנדסיות", שנית אין לבלבל בין תהליך פיתוח הנדסי ובין תהליך היצור של מוצר הנדסי] הדומה לפס-ייצור של מוצר הנדסי. במתודולוגיה זו, [כבמתודולוגיות פיתוח אחרות לא ליניאריות] ישנה הפרדה ברורה בין ההליך התכנוני של התוכנה לבין ההליך הייצורי שלה, הדומה בעיקרו להרכבתו של מוצר הנדסי בפס הייצור. מהנדסי התוכנה משולים לעובדים בפס-הייצור [לא ברור המקור למשל, הם אם כבר משולים למהנדסים], ואלו מביניהם שאתרע מזלם [כאן כבר יש בלבול מושגים בין מהנדסי תוכנה ו\או מנתחי מערכות ובין מתכנתים (שאינם מנתחי מערכות) ] להשתמש בכלים גרפים לייצוג התוכנה (לדוגמא UML) משולים למהנדסים מסורתיים וללוחות השרטוט שלהם. אכן, המטאפורה של פס-הייצור [לחלוטין איננה] במקומה, אך המחיל אותה בדייקנות על דיסצפלינת הנדסת התוכנה מוצא כי המהדר הוא פס-הייצור והעובדים לצידו גם יחד, והחלוקה להליכי תכנון/ייצור היא מלאכותית [החלוקה לאפיון, תכנון, ופיתוח (כתיבת קוד) אינה מלאכותית, גם כאשר היא מבוצעת על ידי אותו אדם] מכיוון שהליך פיתוח התוכנה הוא תמיד תכנוני, הן בכתיבת קוד והן בתכנון גרפי. [ תהליך כתיבת הקוד אינו תמיד תכנוני , בעיקר כאשר מתשמשים בתוכנות כגון כלי CASE אשר מייצרות קוד או חלקים של הקוד באופן אוטומטי] ariek 22:31, 13 דצמבר 2005 (UTC)

מכיוון שהחלק הראשון במאמר בא להדגיש כי עדיין אין הסכמה באשר לטיבה של הנדסת התוכנה, התיקונים שהכנסת אינם במקום. מקומם בסעיף אחר על מתודולוגיות פיתוח תוכנה. רנדום 16:28, 6 ינואר 2006 (UTC)

"תוכנה מסוכנת" ?

למישהו יש סימוכין לנטען בערך? זה נראה לי כמו הגזמה והכללה שאינם במקומם. הא? 20:37, 8 מאי 2006 (IDT)

אפשר להתווכח על הניסוח, אבל ברור שביישומים קריטיים העניין קיים. כשלים של תוכנות שקשורות לבנקאות, חלל, מסחר מאובטח ומאגרי מידע מתבטאים בנזק עצום, כספי או אחר, ובהתאם מושקעים מאמצים רבים למנוע אותם. האומדנים הכספיים בערך סבירים בהחלט. נפילת הרשת של MCI ב-99 הייתה ארוע קטסטרופלי. הוצאות ה-IT של חברות במטרה להגן על עצמן מהתקפות ווירוסים שמנצלים פרצות בתוכנה הן עצומות. אבל את השם "תוכנה מסוכנת" אפשר להחליף ב"תוכנה ביישומים קריטיים" או משהו דומה, כי התוכנה אינה מסוכנת, אבל טעויות בה הן מסוכנות בהחלט. odedee • שיחה‏ 21:37, 8 מאי 2006 (IDT)

הדברים מתבססים על דברים שאמר בארי בוהם, אני מנסה למצוא את הציטוט המדוייק --רנדום 00:45, 1 יוני 2006 (IDT)

גם התבליט "טעות יקרה" אודות מערכת טלפוניה בעייתי. הניסוחים "נזהרי דיבה" האלו לא הולמים אנציקלופדיה. או שנביא את הדברים כעובדות שאין להתווכך, להתבייש או להצניע, או שלא נביא אותם כלל. הא? 13:55, 2 בספטמבר 2006 (IDT)

אני מפנה אותך לדבריי לעיל... רנדום 18:09, 2 בספטמבר 2006 (IDT)

מתקפת איכות

אני מתחיל שכתוב רציני לערך. רנדום 09:40, 2 בספטמבר 2006 (IDT)

פיסקה לא ברורה: "פיתוח התוכנה כתהליך סוציולוגי של יצירת קניין רוחני"

התבליט האחרון בפרק "הנדסה, מדע או אומנות?" אינו ברור ודורש הבהרה משמעותית. הייתי עושה זאת בעצמי, אך לא צפוי שאעשה בנושא זה עבודה טובה במיוחד. הא? 13:15, 2 בספטמבר 2006 (IDT)

אני מגיע לזה... רנדום 16:02, 2 בספטמבר 2006 (IDT)

הגבלת ה-TOC

האם יש דרך להגביל את העומק שיוצג ב-TOC הנמצא בראש הדף? הגעתי כבר לרמה חמישית והיד עוד נטויה... הייתי רוצה שה-TOC יציג רק את 4 הרמות הראשונות. רנדום 00:02, 20 בספטמבר 2006 (IDT)

טילי הפטריוט

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

עד כמה שאני יודע לא מדובר בבעיה באיפיון המערכת אלא בבאג מטופש של איבוד דיוק בעקבות שימוש במשתנה שלם, במקום שבו היה צריך להשתמש בנקודה צפה. --אפי ב. • שיחה • 22:55, 20 בספטמבר 2006 (IDT)

פיצול

נקודת פיצול טבעית היא כמובן בגבול בין תחומים לבין שיטות, ייתכן ואעשה זאת בהמשך. גודל הדף כשלעצמו אינו סיבה מספקת. רנדום 19:49, 18 באוקטובר 2006 (IST)

אינו סיבה כשלעצמו, אלא רק מדד כמעט ישיר לכמות הטקסט בערך זה (שעוד עתידה לגדול). אני חושב שאין הרבה חילוקי דעות על כך שערך זה נעשה גדול מידי, וראוי שיפוצל בעתיד. שכוייח על כל העבודה הברוכה, הא? 20:05, 18 באוקטובר 2006 (IST)

אקסטרים פרוגרמרינג

"שמה ניתן לה בשל העבודה שהשיטות המשמשות אותה הן חמורות מאד" - לא ברור למה הכוונה. אם הכוונה היא שהשיטות הן נוקשות וקפדניות, יש לומר "מחמירות" ולא "חמורות". עניינית, זה לא נכון למיטב ידיעתי, והשם ניתן מכיוון שהשיטה היא יישום מוקצן של עקרונות הנדסיים מסוימים. (ולא כיוון שהיא מחמירה עם ההולכים לפיה). ד.ט 22:42, 21 בפברואר 2007 (IST)

שתי ההערות במקום. אכן "מחמירות" ולא "חמורות". באשר למקור השם, "יישום מוקצן" הוא דבר יחסי ולא מוחלט, וברוח זו כתבתי את המשפט. לדוגמה, כתיבת הבדיקות קודם לכתיבת הקוד היתה שיטה מקובלת בפרויקטים רבים בשנות השישים והשבעים, שהמפורסם שבהם הוא פרויקט מרקורי של נאסא. רנדום 03:04, 22 בפברואר 2007 (IST)

סדר

לדעתי, הסדר הנכון והמקובל הוא:

• הערות שוליים
• ראו גם
• לקריאה נוספת
• קישורים חיצוניים

בברכה, אבינעם 22:44, 13 במרץ 2007 (IST)

תודה על הערתך. לפני זמן-מה שאלתי בדלפק הייעוץ על המבנה הרצוי למאמר, וזה מה שנאמר שם: שיחת ויקיפדיה:מדריך לעיצוב דפים#מבנה תקני של מאמר. רנדום 00:24, 14 במרץ 2007 (IST)

נראה לי שכמספר השאלות, מספר התשובות (אך כמובן לא יותר מ-4 עצרת). בשיחת ויקיפדיה:מדריך לעיצוב דפים#סדר ההפניות יש אמירות אחרות. אולי כדאי לעשות סדר בנושא, פעם אחת ולתמיד. בברכה, אבינעם 00:34, 14 במרץ 2007 (IST)

אני בעד. רנדום 00:37, 14 במרץ 2007 (IST)

ממשק תוכנה

לשאלתך רנדום, ממשק תוכנה הוא בעצם ממשק בין שני רכיבי תוכנה. בשפות תכנות מודרניות כדוגמת java/c# הממשק אפילו זכה למילה שמורה משלו. להבנתי הערך ממשק הפך לדף פירושונים ולכן כנראה נוצר "ממשק התוכנה". המונח האנגלי הוא interface ובויקיפדיה האנגלית הערך מכונה en:Interface (computer science). לדעתי, בכל מקרה יש זכות קיום לממשק ,גם אם לבדו וגם עם התוספת "תוכנה, עם או בלי סוגריים. דרך אגב, הסרתי את ההצבעה המוטעית מהערך האנגלי שהצביע בטעות ל"ממשק משתמש". שרשר • שיחה 23:07, 17 ביוני 2007 (IDT)

הערה במקום. אני מקבל את התיקון שלך. רנדום 23:20, 17 ביוני 2007 (IDT)

הערות צדדיות אגב קריאת הערך

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

"האם אתם מייצרים יש מוחשי? האם אפשר למשש את התוצרת שלכם".

"הו, בוודאי, כבוד השופט, אתה בהחלט מוזמן למשש את החשמל שאנחנו מייצרים". דוד שי 22:50, 7 באוגוסט 2007 (IDT)

:-) רנדום 00:08, 8 באוגוסט 2007 (IDT)