שאלה בקשר לתעוד...

yair24

Member
שאלה בקשר לתעוד...

שלום, את השאלה הזאת אני מפנה למי שעובד בתכנות במקום עבודה מסודר שיש בו כמה וכמה מתכנתים שמתכנתים ביחד איזשהו פרויקט... נודע לי שחייבים לתעד הכל ושיש איזשהם תקנים לתעוד התוכנה כמו למשל : באיזה משתנים השתמשתי, מה תפקיד כל מודול בתוכנה מה הוא מחזיר מה הוא מקבל כפרמטרים, איך בדקתי את התוכנה הגיע אליי איזשהו מסמך שמכיל את המושגים הבאים: SRS SDD V&V PLAN V&V RESULTS יש כאן מישהו שכבר ניתקל במושגים האלה או בחלק מהם? מוזר שאת הדברים האלו לא לומדים במכללות (אני לא יודע לגבי הטכניון אם שם לומדים את זה או לא) כל מידע על זה יתקבל בברכה גם תשובות בנוסך: "אני עובד בחברת כך וכך ואף פעם לא נדרשתי לתעד את התוכנות שעשיתי ואין לי מושג על איזה תקנים אתה מדבר" תודה מראש יאיר צוות "המפתח לבית הספר"
 

galh

New member
אוטופיה תכנותית

אני זוכר רק את SRS - Software Requirements Specification מתוך המושגים שציינת. בתיאוריה ניתן לקבוע תקן ISO לתכנות שכולל בתוכו תהליך מסודר של פיתוח החל משלב הרעיון והדרישות, דרך הפיתוח ותיעודו ועד למוצר סופי לאחר בדיקות ואישור הלקוח. אולם בפועל כל התהליך המסודר מוקרב על מזבח ה-"אין זמן". מהניסיון שלי, מתכנתים לא אוהבים לתכנן מראש (לכתוב גם מסמך), לקבל בקורת על העבודה שלהם ולעדכן את התיעוד כל פעם שמתקנים משהו בקוד. ראש הצוות או מנהל הפיתוח מעדיפים גם הם לראות עמידה בלוח זמנים שקצר בהרבה מהזמן האמיתי שדרוש למחזור של תיעוד-סקירה-פיתוח-בדיקה וחוזר חלילה. מיקרוסופט הצליחה להחדיר באנשים את המושג של "מספיק-טוב", כלומר אין צורך לכתוב את המוצר הטוב ביותר כדי להצליח, אלא צריך לכתוב מוצר שיהיה מספיק טוב כדי למכור אותו ולנסות להשיג את נתח השוק הגדול ביותר לפני שמתחרים אחרים ינסו להשיג את חלקם. בצורה זו של "מספיק-טוב" מוותרים על תיעוד מסודר, סקירה של התכנון, כתיבה נכונה ויעילה של קוד ותהליך בדיקה )QA( מלא. כך שלסיכום, הדברים שהצגת קיימים למרות שלא מלמדים אותם באקדמיה, אולם הדברים נכשלים במבחן המציאות.
 

yair24

Member
אני עכשיו קורא על זה...

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

פינצ

New member
זה באמת דבילי

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

yair24

Member
מה ענינים פינצ ../images/Emo13.gif

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

פינצ

New member
בעיקרון

ב SRS צריך שיהיה כתוב תכנון כללי של המערכת, איך זה נראה מבחינת GUI, מה הזרימה בין המרכיבים השונים של המערכת מנקודת מבט המשתמש (אצלנו זה לא שיעורי בית ובדרך כלל אין לנו צורך לכתוב מה הבעיה במצב היום ולמה המערכת שלנו באה לשפר אותו). יש להכין SRS עבור כל רכיב (לא תוכנית, רכיב) של המערכת ואחד כללי על כולה. ב Detailed Design יש לכתוב דברים יותר לעומק, מהצד של התוכניתן, ריכיבי DB אם יש, טבלאות, אוביקטים, Interfaces וכו´ את שאר הדברים לא כתבתי מעולם, אין לי מושג
 

yair24

Member
אם הבנתי נכון...

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

פינצ

New member
אתה טועה

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

Godfather

New member
תיעוד תוכנתי

קודם כל כן מלמדים את זה במכללות - מבוא להנדסת תוכנה. מעבר לזה ישנו ספר בשם software engineering של roger s. pressman מהדורה רביעית שעוסק בנושא זה!!!!!
 

philips

New member
המממ....

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

yair24

Member
שאלה לפיליפס..

מה זה UML זה שפת תיכנות? צריך להוריד משהו מהרשת, לקנות משהו? יאיר צוות "המפתח לבית הספר"
 

philips

New member
הממ..

Unified Modelling Lang. - שפה המורכבת מדיאגרמות שמתארות כל אספקט אפשרי במערכת שהינך מתכנן לפתח ומקנות שפה אחידה לכל אנשי צוות הפיתוח/תכנון. לאחר שהמערכת מתוכננת כמו שצריך - מתועדת חלקית , ניתן בקלות יחסית להתאים את הכל לתקן , או שהתקן יתאים את עצמו ל UML.. אין לי כ"כ זמן לתשובה מפורטת יותר , אז אפנה אותך לאתר בנושא ואם יש לך שאלות , שאל.... http://odl-skopje.etf.ukim.edu.mk/uml-help/ לגבי שאלתך לפינצ´ - אני חושב שהיא התכוונה לדיאגרמות USE CASE ב UML או לקונספט מאחוריהן.. כמובן שיש גם ספרים מצויינים בתחום - ככל הידוע לי , רק באנגלית
 

yair24

Member
שאלה לפינצ

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

פינצ

New member
המממ

לא משהו מסובך האמת, יש מקומות שדורשים יותר אצלנו דורשים משהו פשוט ומובן כמו תרשים זרימה למשל שאתה עושה (יש בכלל מישהו שעושה תרשים זרימה) לתוכנית שלך. לדוגמה עם יש לך מערכת מידע על לקוחות של מפעל מסויים, ויהיו לך מרכיבים של עדכון הפרטים שלהם (GUI ותוכנה), הוספה של לקוח חדש, בירור של פרטי לקוח, הדפסה של הזמנות של לקוח ספציפי או רשימת לקוחות. בגדול כל דבר כזה הוא מרכיב של מערכת (אני מדברת על OOD) שמורכב מהרבה מרכיבים אחרים. את אותם מרכיבים (לא הפנימיים יותר) תציג במין תרשים שיראה מה קשרי הגומלין בינהם (שלי לערב איך תעשה את זה בתוכנה או מה סוג בסיסי הנתונים שלך). אחרכך תציג לדוגמה תכנון של מסכים עבור על רכיב ומה יקרה בכל מסך וכו´. וכך הלאה וכך הלאה, נראה לי שזה ברור מספיק
 
למעלה