מערכות קטנות

מבוא והסבר כללי

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

במילים אחרות: מהם מחזור החיים והתיעוד המינימליים שיש לדרוש גם בפרויקט קטן?

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

הגדרת מערכת קטנה

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

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

 ·         עלות כוללת עד 25,000$ (כולל הכל!) באופק הזמן הנ"ל.

 ·         איש מקצוע אחד מנתח/מתכנת העוסק בפיתוח.

 ·         עבודה בתחנה עצמאית ללא רשת (או ברשת בסיסית של עד 3 משתמשים)

 ·         מומחה יישום/משתמש אחד "צמוד" שיש לו את מלוא האחריות והסמכות לקבל את כל ההחלטות הדרושות. אפיון המערכת ובדיקתה הם באחריותו המלאה.

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

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

בהגדרות מפת"ח אפשר לומר שמדובר בפרויקט בהיקף ג0 שאיננו בהכרח מוצר מדף "נטו" ויש בו גם אלמנט מסוים של תכנות. או התאמות מוגבלות לחבילת תוכנה פשוטה ומוגדרת היטב (עלות כוללת של עד 25,000$!), או אפילו תכנות ללא חבילת בסיס.  ובלבד שההגבלות הנ"ל יישמרו.

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

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

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

הצעת מפת"ח

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

 ·         הגדרה ברורה ומחייבת מה היא "מערכת קטנה"

 ·         שימוש בעץ מערכת מינימלי, מותאם ו"מתגלגל"

 ·         ניהול לפי מחזור חיים מיוחד

 ·         שימוש בכלי פיתוח מתאימים

 ·         בקרה שוטפת שאכן התנאים הנ"ל מתקיימים ואין "גלישה"

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

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

מחזור חיים למערכות קטנות

מחזור החיים של מערכות קטנות אינו משתנה בעיקרון, אלא הוא נעשה גמיש ופתוח יותר וניתן לקצר בשלבים מסוימים, לאחד שלבים ולעתים גם לוותר על שלב מסוים בכלל. פיתוח המערכת נעשה ע"י עבודה ב"מעגלי פיתוח" של ניסוי ותהייה (Trial & Error), בסבבי פיתוח ויחידות עבודה דוגמת המודל הספירלי (Mini\Micro Life Cycles) ובשילוב צמוד של מומחה היישום (JAD\RAD). מעגלי פיתוח אלה מכילים, למעשה, אלמנטים בסיסיים של מחזור החיים הגדול: ייזום, אפיון (עם הכלי), סבבי עיצוב ובנייה וכו', אלא שהם מבוצעים באופן יותר דינמי כולל "חיתוך" וחפיפה בין השלבים.

במדריך זה מובאות שתי גישות לבניית מחזור החיים של מערכת קטנה:

 ·         מחזור חיים מותאם – מייזום עד תחזוקה עם התאמות נדרשות

 ·         מחזור חיים מקוצר – שני שלבים עיקריים: פיתוח ותפעול

מחזור חיים מותאם

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

ייזום

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

 ·         גישה מינימליסטית: מערכת קטנה = ייזום מקוצר.

ראה מסמך ייזום מקוצר וטופס ייזום בקיט ייזום בכרך יסודות\מחזור חיים.

 ·         גישה מקסימליסטית: מערכת קטנה = ייזום +.

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

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

אפיון

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

עיצוב ובנייה

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

1.       בנייה מחודשת של שטחי עבודה, ספריות, הגדרות קבצים, שמות וכו', על מחשב הפיתוח הסופי.

2.       החלטה על חלוקה ליחידות עבודה לפי תת-מערכות / פונקציות ראשיות שהוגדרו בסעיפים 2.3 או 2.5 של תיק המערכת.

3.       עיצוב/בנייה וליטוש סופיים

4.       בדיקות יחידה

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

פעולות 2-1 מתבצעות פעם אחת, בעוד שפעולות 5-3 מתבצעות ב"סבבים". בכל סבב מתמקדים ביחידת עבודה אחת. כל יחידה N+1 מוסיפה ומתחברת ל- N היחידות הקודמות.

לבקשות של המשתמש שהן למעשה דרישות חדשות המשנות באופן מהותי את תצורת המערכת מומלץ לענות, בהתאם לנסיבות, באופן הבא:

 ·         בוא נסגור את המהדורה הזו, נתנסה בה ואח"כ נרחיב (אם צריך).

 ·         קבלת דרישות חדשות אלה תאלץ אותנו לחזור להנהלה וסביר שהיא תחזיר את הפרויקט למסלול הפיתוח התקני של פרויקטים רגילים.

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

בדיקות

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

התקנה והרצה

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

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

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

שלב התפעול ושלב התחזוקה

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

מהדורות נוספות

סבבי פיתוח של מערכות ממוחשבות אינם מתמצים רק בסבבים פנימיים של אפיון, עיצוב ובנייה (Mini\Micro Life Cycles) כמוסבר לעיל, אלא מכילים גם סבבים גדולים יותר של יחידות מסירה, היינו, חזרה לשלב האפיון ועיצוב ובנייה לצורך בניית מהדורות חדשות (Macro Life Cycles). דבר זה לגיטימי גם במערכות קטנות, אפילו רצוי. עם זאת, יש להיזהר מאד משימוש בסבבים אלה לצורך "ניפוח" המערכת והפיכתה מ"מערכת קטנה" למערכת רגילה בדלת האחורית. הגדרת מערכת קטנה והמגבלות עליה הן כמוגדר לעיל בסעיף הגדרת מערכת קטנה לעיל, כולל כל סבבי הפיתוח ויחידות המסירה (מהדורות) באופק הזמן שהוגדר!.

מחזור חיים מקוצר

אפשרות נוספת, קצרה עוד יותר, היא חלוקת מחזור החיים לשני שלבים בלבד:

 ·         פיתוח

 ·         תפעול

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

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

הפתרון הוא במגוון אמצעים וטווחי זמן :

 ·         שמירה על מודל הנתונים (והממשקים

 ·         הצמדות לתיק המערכת המתגלגל

 ·         בקרת אבני דרך ומשאבים.

 ·         ייזום מורחב

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

עץ מערכת למערכות קטנות

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

בנוסף, ניתן לבצע קיצורים בגוף העץ עצמו ע"י:

 ·         ויתור על רכיבים

 ·         איחוד רכיבים

 ·         קיצור המידע המתועד ברכיבים

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

ויתור על רכיבים

ניתן לוותר, בתנאים המפורטים להלן, על רכיבים (סעיפים) הבאים:

 ·         1.4 הקשר ארגוני עסקי - עם זאת, יש להקפיד על רכיב 1.5 שהוא הקשר לתכנית העבודה השנתית (מערכת ניהול משימות).

 ·         1.6 ישימות ועלות/תועלת

             ·         1.6.1 סיכונים: ניתן לוותר בהנחה שלא צפויות בעיות ישימות או סיכונים בהקמת המערכת ובתפעולה.

             ·         1.6.2 עלות/תועלת: ניתן לוותר בהנחה שאת הצידוק למערכת ניתן לקבל בפשטות מ"הצלבת" פרק היעדים עם פרק העלות.

 ·         1.7 אופק זמן - בתנאי שבסעיף המימוש ברורים תאריכי היעד העיקריים של המערכת.

 ·         2.1 אופי ומצב כללי - צריך להתקבל מהתרשמות כללית מהרכיבים האחרים.

 ·         2.1.4 מילון מונחים - מונחי המערכת מוגדרים באופן טבעי ברכיבים המתאימים, למשל: ישויות המידע העיקריות מתועדות ברכיב 2.11/2.12 קבצים.

 ·         2.10 טבלאות - אין "מערכת" מיוחדת לניהול טבלאות, טבלה היא קובץ רגיל.

 ·         2.15 דו"חות - אם הדו"חות מופקים ישירות ממסכי שאילתות.

 ·         2.16 טפסים - נמצאים בד"כ במסכים ובדו"חות.

 ·         2.20 חיתוכים והצלבות

 ·         2.23 דרישות מיוחדות

 ·         3.33 טכנולוגיות משיקות.

 ·         4.3 השלב הבא - כל המידע הקשור בתכנית העבודה יהיה ברכיב 4.2.

 ·         4.4 תפעול - "תיק תפעול" המערכת מתמזג עם המדריך למשתמש, ראה 4.7 להלן.

 ·         4.5 אינדקס תיעוד. תמ"מ - תיק המערכת (המתגלגל) הוא התיעוד הנדרש.

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

איחוד רכיבים

ניתן, בתנאים המפורטים להלן, לאחד את הרכיבים (סעיפים) הבאים:

 ·         1.2 מטרות עם 1.3 בעיות.

 ·         2.5 תהליכים:

             ·         תהליכים מקוונים יתלכדו עם רכיב 2.4 ממשק משתמש (מסכים)

             ·         תהליכי אצווה (batch) יתלכדו עם 2.7 מודולים

 ·         2.6 טרנזקציות ישולב עם 2.5 תהליכים ו/או 2.4 מסכים.

 ·         2.9 שגרות עם 2.7 מודולים - שגרה היא מודול לכל רגיל.

 ·         2.11 קבצים לוגיים עם 2.12 קבצים פיסיים

קיצור רכיבים

ניתן, בתנאים המפורטים להלן, לקצר ברכיבים (סעיפים) הבאים:

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

 ·         2.3 תיחום פנימי - אין בד"כ תת מערכות. זה עצמו מבחן שאכן המערכת היא קטנה.

 ·         2.5 תהליכים - רק תהליכי אצווה (Batch). ראה סעיף ב' איחוד רכיבים לעיל.

 ·         2.7 מודולים - מספיקה הפניה לספרייה, רצוי גם רשימה קצרה.

 ·         2.13 מילון שדות - אין למערכת "מילון נתונים" מסודר. מספיקה רשימה קצרה של כל השדות האחידים והמרכזיים.

 ·         2.19 ניתן להסתפק בסיסמת כניסה + נעילה פיסית של החדר/מסוף/מחשב. יוגדרו שתי רמות הרשאה: מנהלן המערכת ומשתמש רגיל.

 ·         2.21 עומסים וביצועים - בהנחה שאין למערכת "עומסים" מיוחדים ושדרישות הביצועים של המערכת הן "סטנדרטיות".

 ·         2.22 ממשקים - למערכות קטנות אין כמעט ממשקים (ראה סעיף 0.4 הגדרות לעיל).

 ·         את פרק 3 טכנולוגיה ניתן לחלק לשלושה תת סעיפים כדלהלן:

             ·         3.1 חומרה מרכזית ומחשב לקוח

             ·         3.10 תוכנות תשתית

             ·         3.30 תקשורת

 ·         4.1 גורמים מעורבים - מומחה היישום  / המשתמש העיקרי (1.1) הוא גם "ועדת ההיגוי". לצדו פועל "צוות מקצועי" המורכב מאיש מקצועי אחד (מקסימום שניים!). אין כמעט שום מעורבים נוספים.

 ·         4.6 שירות ותחזוקה - המערכת תקבל "שירות ותחזוקה" במסגרת מערכת גדולה יותר, או שתצטרף למסגרת שירות ותחזוקה קיימת.

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

 ·         5 עלות – אפשר לוותר על תת רכיב 5.5 עלות כוללת ותת רכיב 5.3 עלות תצורות. אין לוותר על סעיפים 5.1 עלות הקמה, 5.2 עלות שוטפת ו- 5.4 מחירון. קשה להגדיר אותם? אולי המערכת לא קטנה!

 ·         רכיבי נקודות פתוחות 98.X - אם יש כאלה - ירוכזו בנספח 98 בסוף המסמך.

 ·         רכיבים/דרישות עתידיים 99.X - אם יש כאלה - ירוכזו בנספח 99 בסוף המסמך.

גלופת עץ מערכת

גלופת עץ מערכת שלהלן היא למעשה התמ"מ (תיק המערכת המתגלגל). ברור שזו דוגמא/המלצה בלבד. כל מערכת תבנה את עץ המערכת המתאים לה. ניתן להיעזר גם בגלופות מפת"ח האחרות, בפרט בגלופת עץ מערכת - רמה שנייה.

אבטחת איכות

סביר שלפונקצית אבטחת איכות בארגון לא יהיו המשאבים ללוות פרויקט מסוג זה. אבטחת האיכות של מערכות קטנות תיעשה ע"י איש המקצוע עצמו ומומחה היישום המלווה אותו, בשיטת הבדיקה העצמית וברוח הכלל: Quality is free if we do everything else right.

להלן מספר הנחיות עזר לבדיקה עצמית זו.

שילוב כלים ובדיקה מתמדת

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

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

ג.        כלי נוסף חשוב אחר הוא תוכנה לניהול משימות כגון Outlook או Lotus Notes, המאפשרות לרשום את הפעילויות הקשורות בפיתוח המערכת ולעקוב אחריהן, כולל כל הגורמים המעורבים בפיתוח, גורמים פנימיים וחיצוניים. במערכות קטנות סביר שלא ייעשה שימוש בשיטות ניהול פרויקטים מלאות: תרשימי גאנט, נתיב קריטי וכו'. כלי לניהול משימות הוא, אפוא, תחליף חיוני ביותר.

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

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

             ·         כלי הפיתוח עצמו

             ·         חלוקה לספריות ותקן לשמות כתחליף לניהול תצורה מלא

             ·         חיבור לכלי מתעד כנזכר לעיל

             ·         חיבור לכלי לניהול משימות.