يكي از بزرگترين مشكلات مديران در برخورد با يك تيم پروژه توسعه نرم افزار غير قابل مشاهده و غير قابل لمس بودن آن است. پروژه توسعه نرم افزار بر خلاف ساخت يك پل است كه هر فردي مي‍تواند پيشرفت آن را مشاهده نمايد. به خاطر اينكه نتيجه فيزيكي پروژه توسعه نرم افزار همانا اجراي برنامه كاربردي است كه به صورت مداوم توسعه مي‍يابد و به آساني قابل مشاهده نيست و خيلي سخت است كه بتوان وضعيت پروژه را تشخيص داد و يا اينكه تصوري از پيشرفت فيزيكي آن را در ذهن متصور بود. براي مقابله با اين خصوصيت نامريي بودن، اولين وظيفه در پروژه استفاده از abstraction است. به عنوان نمونه معمار يك مدل UML دارد، آناليست يك مدل نيازمندي‍ها يا use case، آزمونگر يك برنامه تست دارد و برنامه پروژه نيز ابزار معادلي براي مديريت پروژه است. آن (ابزار) خلاصه سازي يا مدلي است براي مدير پروژه كه با آن كار كند و يا آن را با تيم به اشتراك بگذارد و به منظور اجراي آناليز پيچيده و فشرده از آن استفاده كند.

در محيط‍هاي جديد توسعه‍اي نرم افزار، برنامه پروژه يا Project Plan به عنوان وجود ديدگاهي پارامتريك از يك پروژه به منظور اشتراك و دستيابي تيم قطعي است.

يك برنامه پروژه خوب عملكردها و يا وظايف زير را اجرا مي‍كند:

×???? كمك به مدير برنامه ريزي به منظور كنترل جريان نقدينگي و برنامه ريزي پروژه

×???? برقراري ارتباط به منظور تعيين اينكه چه چيزي در چه زماني تحويل داده خواهد شد

×???? تعيين اينكه كدام يك از منابع بايستي در دسترس باشند و چه زماني به آن‍ها نياز است

×???? كمك به جلوگيري برخورد و تصادم بين منابع رقابتي در فعاليت‍هاي متفاوت

×???? كمك به تيم براي درك اينكه چه كسي چه كاري را در پروژه انجام مي‍دهد

×???? توليد اساس و پايه براي اندازه گيري درصد پيشرفت و هزينه

×???? دادن نقاط بحراني به برنامه ريز براي پشتيباني برنامه ريزي مجدد فعاليت‍ها

×???? كمك به مشتري و مديريت براي اينكه مشاهده كنند چه چيزي به اشتباه در زمان اجراي پروژه، اتفاق افتاد

يك برنامه پروژه خوب داراي مشخصات كليدي زير است:

×???? برنامه بايستي مقصد محور باشد، به عبارتي بايستي مشخص كند كه چه چيزهايي بايستي در پروژه تحويل داده شوند. اگر برنامه‍اي كه مورد استفاده است بخواهد به عنوان يك محرك تيم براي حركت به سوي اهداف تعريف شده كمك كند، بايستي مقاصد روشني را، هم براي تيم و هم به صورت انحصاري به منظور تعيين كارايي آنها در برابر برنامه، توليد كند

×???? برنامه بايستي مدير پروژه را قادر به درك اين مطلب كند كه كدام يك از اعضا تيم در حال كار بر روي كدام يك از وظايف هستند و چه وابستگي بين وظايف وجود دارد

×???? برنامه بايستي ديدگاه‍هاي مختلفي از اطلاعات را بر اساس نيازهاي مشتريان، اعضا تيم و مديريت توليد كند. به عنوان مثال بايستي يك برنامه coarse-grained، يك برنامه artifact، يك برنامه delivery و يك ليست كارهايي كه بايستي انجام شوند از بين چيزهاي ديگر را توليد كند

×???? برنامه بايستي از لحاظ زماني و موارد تحويل داده شده قابل اندازه گيري باشد. اغلب وقتي در رابطه با درصد پيشرفت فيزيكي سوال مي‍شود، مدير پروژه مي‍تواند گزارشي از زمان و هزينه خرج شده ارايه دهد. اما نمي‍تواند از نظر كمي بگويد كه چه مقدار از سيستم تحويل داده شده است. اين مطلب كه الان در چه وضعيتي از پروژه هستيم و اينكه چه مواردي تحويل داده شده است و يا چه مواردي در شرف تحويل است، براي مدير پروژه و اعضا تيم مهم است.

×???? برنامه بايستي به روز باشد، بايستي به برنامه‍هاي واقعي كه در پروژه اجرا مي‍شوند متصل باشد، به گونه‍اي كه مدير پروژه بتواند درصد پيشرفت را تشخيص دهد. اگر يك برنامه پروژه در زمان تشخيص كارايي سطح دوم باشد، به صورت صحيح استفاده نشده است.

مشخصات يك پروژه RUP

يك پروژه RUP داراي دو جنبه اساسي است كه براي برنامه پروژه مهم است:

×???? پروژه‍هاي RUP تكراري هستند

×???? پيشرفت پروژه، بر اساس نقاط بحراني واضح اندازه گيري مي‍شود

توسعه تكراري

اكثر پروژه‍هاي RUP به صورت تكراري تعريف مي‍شوند. RUP يك فرآيند افزايشي است كه در آن پروژه به فازهاي مختلف و تكراري شكسته مي‍شود. تكرارها ريسك محور هستند – به عبارتي در جهت تخفيف ريسك – و هر يك بايستي يك برنامه اجرايي را تحويل دهند كه قابل شرح و قابل تست بر اساس نيازهاي پروژه و usecase ها باشد.

مدير پروژه از برنامه‍هاي تكراري براي مديريت پروژه استفاده مي‍كند. عموماً كارها و فعاليت‍هاي خارج از يك برنامه تكرار جزو تعهدات نيست.

يك برنامه تكرار:

×???? شرح مختصري براي فازهاي كاري در آينده نزديك را تهيه مي‍كند

×???? تعريف نقش كاركنان درگير، فعاليت‍هاي لازم و محصولات قابل تحويل در يك تكرار

×???? مجموعه‍اي واضح و روشن از رئوس مطالب و ضوابط ارزيابي كه بوسيله آن‍ها بتوان در طول تكرار و در انتهاي ارزيابي پيشرفت را تشخيص داد

×???? تعريف تاريخ‍هاي شروع و پايان مشخص و تاريخ‍هاي تحويل

تشخيص سايز و تعداد تكرارهاي مورد نياز يك پروژه در ادامه اين مستند تشريح خواهد شد.

نقاط بحراني

متدولوژي RUP براي توسعه پروژه‍ها چهار فاز شناسايي كرده است. هر فاز از يك منظر مشخص كه مرتبط است با تعدادي نقاط برجسته بر روي تيم پروژه تمركز مي‍كنند. اين نقاط كليدي و برجسته به مديريت پروژه كمك مي‍كند تا پيشرفت پروژه راتشخيص دهد و مطمئن شود كه پروژه قابليت‍هاي مورد نياز را با كيفيت تحويل خواهد داد. فازها و مواردي كه آن‍ها بر آن متمركز مي‍شوند عبارتند از:

×???? فاز آغازين

تمركز اين فاز بر روي درك قلمرو و محدوده پروژه است

×???? فاز جزييات

در انتهاي اين فاز بايستي معماري و نيازمندي‍هاي محصولاتي كه مي‍بايست توليد شوند، شناسايي شده باشد

×???? فاز ساخت

در اين فاز نرم افزار بايستي ساخته و توليد شود

×???? فاز گذار

در اين فاز نرم افزار بايستي ترخيص و به مشتريان تحويل داده شود

در مفهوم توسعه تكراري، نقاط كليدي يك فاز بر روي تمركزهاي آن فاز تمركز مي‍كند. هر تكرار پروژه را از ميان نقاط كليدي و يا بحراني حركت مي‍دهد. براي مثال، تكرار در داخل فاز آغازين بايستي ساخت يافته در حول درك محدوده پروژه باشد.