ארכיטקט תוכנה – הבדלי גרסאות
מאין תקציר עריכה |
הרחבה |
||
| שורה 3: | שורה 3: | ||
דמות ארכיטקט התוכנה החלה להתגבש עם התרחבות השימוש ב[[תכנות מונחה-עצמים]], ב[[שנות ה-90 של המאה ה-20|שנות התשעים]] המאוחרות של המאה ה-20, ובתחילת [[העשור הראשון של המאה ה-21|שנות האלפיים]]. תכנות מונחה-עצמים איפשר ליצור [[יישום מחשב|יישומים]] גדולים ומורכבים מאי פעם, מה שבתורו הצריך יותר תכנון ופיקוח ברמה הגבוהה. כמו כן, עם צמיחת הפופולריות של שימוש ב[[ארכיטקטורה רב-שכבתית]] ב[[פיתוח תוכנה]], גדל מספר האפשרויות השונות שבהן ניתן לממש יישומים. בעקבות התרחבות זאת, גדל במידה ניכרת גם הסיכון שפרוייקט לפיתוח תוכנה ייצור בטעות מוצר "חדש", אשר למעשה כבר היה קיים קודם. גורמים אלה הביאו לצורך בתפקיד החדש, של "ארכיטקט תוכנה" בפרוייקטים גדולים של פיתוח תוכנה. |
דמות ארכיטקט התוכנה החלה להתגבש עם התרחבות השימוש ב[[תכנות מונחה-עצמים]], ב[[שנות ה-90 של המאה ה-20|שנות התשעים]] המאוחרות של המאה ה-20, ובתחילת [[העשור הראשון של המאה ה-21|שנות האלפיים]]. תכנות מונחה-עצמים איפשר ליצור [[יישום מחשב|יישומים]] גדולים ומורכבים מאי פעם, מה שבתורו הצריך יותר תכנון ופיקוח ברמה הגבוהה. כמו כן, עם צמיחת הפופולריות של שימוש ב[[ארכיטקטורה רב-שכבתית]] ב[[פיתוח תוכנה]], גדל מספר האפשרויות השונות שבהן ניתן לממש יישומים. בעקבות התרחבות זאת, גדל במידה ניכרת גם הסיכון שפרוייקט לפיתוח תוכנה ייצור בטעות מוצר "חדש", אשר למעשה כבר היה קיים קודם. גורמים אלה הביאו לצורך בתפקיד החדש, של "ארכיטקט תוכנה" בפרוייקטים גדולים של פיתוח תוכנה. |
||
== תחומי אחריות == |
|||
תחומי האחריות של ארכיטקט תוכנה כוללים: |
|||
* הגבלת כמות האפשרויות הזמינות במהלך הפיתוח, על ידי: |
|||
** בחירה של דרך סטנדרטית להשגת המטרות בזמן פיתוח התוכנה. |
|||
** יצירה, הגדרה או בחירה של [[שלד תוכנה|תשתיות תוכנה]] המשמשות לפיתוח היישום. |
|||
* זיהוי אפשרויות לשימוש מחדש (reuse) בתשתיות קיימות במסגרת ה[[ארגון]] או בתוך ה[[יישום מחשב|יישום]], על ידי: |
|||
** תצפית והבנה של ה[[מערכת]] והסביבה במובן הרחב. |
|||
** גיבוש [[הנדסת תוכנה מבוססת רכיבים|עיצוב הרכיבים]] וה[[מודול (תוכנה)|מודול]]ים שירכיבו את המערכת. |
|||
** הכרת היישומים האחרים בארגון. |
|||
* חלוקה של יישום מורכב לחלקים קטנים ונוחים יותר לניהול בשלב התכנון. |
|||
* הבנת הפונקציות של כל רכיבי המערכת. |
|||
* הבנת האינטראקציות והתלויות בין רכיבים. |
|||
* העברת רעיונות אלו למפתחים. |
|||
== ראו גם == |
== ראו גם == |
||
גרסה מ־13:01, 19 בספטמבר 2013
 |
הערך נמצא בשלבי עבודה: כדי למנוע התנגשויות עריכה ועבודה כפולה, אתם מתבקשים שלא לערוך את הערך בטרם תוסר ההודעה הזו, אלא אם כן תיאמתם זאת עם מניח התבנית.
| |
| הערך נמצא בשלבי עבודה: כדי למנוע התנגשויות עריכה ועבודה כפולה, אתם מתבקשים שלא לערוך את הערך בטרם תוסר ההודעה הזו, אלא אם כן תיאמתם זאת עם מניח התבנית. | |
ארכיטקט תוכנה (באנגלית: software architect) הוא מתכנת בכיר המקבל החלטות הנוגעות לעיצוב תוכנה ברמה הגבוהה (high-level), ותפקידו להכתיב סטנדרטים טכניים לגבי טכניקות תכנות, כלים, תשתיות תוכנה ופלטפורמות מחשוב.
דמות ארכיטקט התוכנה החלה להתגבש עם התרחבות השימוש בתכנות מונחה-עצמים, בשנות התשעים המאוחרות של המאה ה-20, ובתחילת שנות האלפיים. תכנות מונחה-עצמים איפשר ליצור יישומים גדולים ומורכבים מאי פעם, מה שבתורו הצריך יותר תכנון ופיקוח ברמה הגבוהה. כמו כן, עם צמיחת הפופולריות של שימוש בארכיטקטורה רב-שכבתית בפיתוח תוכנה, גדל מספר האפשרויות השונות שבהן ניתן לממש יישומים. בעקבות התרחבות זאת, גדל במידה ניכרת גם הסיכון שפרוייקט לפיתוח תוכנה ייצור בטעות מוצר "חדש", אשר למעשה כבר היה קיים קודם. גורמים אלה הביאו לצורך בתפקיד החדש, של "ארכיטקט תוכנה" בפרוייקטים גדולים של פיתוח תוכנה.
תחומי אחריות
תחומי האחריות של ארכיטקט תוכנה כוללים:
- הגבלת כמות האפשרויות הזמינות במהלך הפיתוח, על ידי:
- בחירה של דרך סטנדרטית להשגת המטרות בזמן פיתוח התוכנה.
- יצירה, הגדרה או בחירה של תשתיות תוכנה המשמשות לפיתוח היישום.
- זיהוי אפשרויות לשימוש מחדש (reuse) בתשתיות קיימות במסגרת הארגון או בתוך היישום, על ידי:
- תצפית והבנה של המערכת והסביבה במובן הרחב.
- גיבוש עיצוב הרכיבים והמודולים שירכיבו את המערכת.
- הכרת היישומים האחרים בארגון.
- חלוקה של יישום מורכב לחלקים קטנים ונוחים יותר לניהול בשלב התכנון.
- הבנת הפונקציות של כל רכיבי המערכת.
- הבנת האינטראקציות והתלויות בין רכיבים.
- העברת רעיונות אלו למפתחים.